关于 Multi-Agent，我目前的一些思考
最近在做一个多 Agent 协同的项目，目前还在构思阶段。趁这个机会，梳理一下我对多agent协同的思考。
一、为什么需要 Multi-Agent
我个人认为，需要引入 Multi-Agent 主要有以下几点原因。
并行完成任务。多个 Agent 同时工作，可以最大程度地利用时间，提高执行效率。
上下文隔离。对于某些模式的 Agent 来说，上下文隔离本身就是一个很重要的优势。通过让每个 Agent 拥有更干净的上下文，可以做出质量更高的任务输出。
应对复杂任务。如果做到了以上两点，就可以比较高效地完成那些对单个 Agent 来说相对吃力的复杂任务。
实现长程 Agent。Multi-Agent 也让长程 Agent 的实现变得更加可能。长程 Agent 系统里，有两个维度在同时发挥作用：一是串行的 handoff——当某个 Agent 的上下文接近上限时，通过 handoff 机制把任务传递给下一个 Agent，让它接力继续完成；二是不同领域 Agent 的并行——各自负责不同职责的 Agent 同时推进，共同支撑整个任务的进展。串行保证了任务在时间轴上的延续，并行保证了任务在同一时间段内的深度和广度。两者结合，才让运行时间较长、复杂度较高的任务真正变得可行。
值得补充的一点是：使用 Multi-Agent 的理由，并不只是"单个 Agent 完成不了"。很多时候，单个 Agent 也能完成任务，但对于庞大且复杂的任务，Multi-Agent 之间"上下文隔离"的特性，往往能同时带来效率和质量上的提升。你能用更少的时间，得到质量更高的产出。这是我认为 Multi-Agent 真正有价值的地方。
二、Multi-Agent 的协作方式
在具体讨论协作方式之前，我想先梳理一下目前常见的几种 Multi-Agent 架构模式。这里主要参考了 Claude Code 的源码架构分析，以及 Anthropic 的一篇关于多 Agent 协调模式的博客。
几种常见模式
Generator-Verifier（生成器-验证器）最简单也是部署最广泛的模式之一。一个 Agent 负责生成输出，另一个负责验证，验证不通过则将反馈返回给生成器，循环迭代直到通过或达到最大次数。适合有明确评估标准的质量关键型任务，比如代码生成、合规验证等。
Orchestrator-Subagent（编排器-子 Agent）由一个主 Agent 负责规划和调度，子 Agent 各自承担具体工作并返回结果，主 Agent 负责综合。Claude Code 就采用了这种模式——主 Agent 自己写代码、编辑文件，同时在后台派发子 Agent 去搜索代码库或调查独立问题，子 Agent 返回提炼后的发现，主 Agent 的上下文始终聚焦在主任务上。这个模式适合任务分解清晰、子任务边界明确的场景。
Agent Teams（Agent 团队）与 Orchestrator-Subagent 的核心区别在于 Worker 的持久性。子 Agent 不是用完即丢，而是会跨多个任务保持活跃，在过程中积累上下文和领域专注度。适合并行、独立、长期运行的子任务——比如把一个大型代码库从一个框架迁移到另一个，可以让每个 Agent 负责一个独立的服务模块，自主完成迁移全流程。
Message Bus（消息总线）和Shared State（共享状态）这两种模式适合更复杂的场景。消息总线适合事件驱动的管道，工作流从事件中涌现而非预先确定；共享状态则适合多个 Agent 需要实时共享彼此发现的协作研究类场景，Agent 之间通过读写同一个持久化存储来协调，不需要中央协调器的介入。
我的判断
这几种模式各有适用场景，Orchestrator-Subagent 是其中最通用的起点，能以最低的协调开销覆盖最广泛的问题。我个人也认为，在大多数实际场景里，编排器与子 Agent 这样的主从结构会是更常见的选择。
对于 Agent Teams，我目前还没有想到非常适合它的场景。根据 Anthropic 那篇博客的描述，它要求子任务具有相当高的独立性且颗粒度非常细。一旦各个 Agent 的工作之间存在交叉，就容易产生冲突，而且 Agent 之间没有直接通信，中间发现的信息只能通过协调器路由，这本质上又退回了 Orchestrator 模式的逻辑。
三、Orchestrator-Subagent 的设计挑战
由于我目前在做的项目采用的就是 Orchestrator-Subagent 这种组合形式，我的思路是：Orchestrator 仅负责发布命令、执行调度，不直接参与具体实施；Sub-agent 负责具体执行，汇报进度并拿到反馈，然后继续完成任务。
这种设计在通信上相对 Agent Teams 没有那么复杂，但它也带来了几个我目前还在思考的问题。
权限控制与沙盒
如果 Orchestrator 只负责调度，那它是否需要拥有一定的权限，可以自行审批 Sub-agent 的某些操作请求？这实际上要求 Orchestrator 具备相当强的判断力——知道哪些事情可以放行，哪些需要上报人类。
在实际使用中，我觉得很多命令其实不需要人类逐一审批。但放宽权限的代价是：一旦出错，带来的影响也会更不可控。我理想中的状态，是 Orchestrator 能对 Sub-agent 进行及时的纠偏和命令审批，让人类可以尽量少地介入到系统运行的中间过程里。要实现这一点，核心在于一个足够可靠的沙盒环境——它能在 Agent 操作出问题时提供兜底，而不是让人类不得不时刻盯着每一步。
并行冲突与 Git Worktree
当多个 Sub-agent 同时在同一个代码仓库上工作时，读写冲突是一个绕不开的问题。
这里先简单说一下 git worktree 的原理。通常我们用git clone或git init创建的仓库，只有一个工作目录。而 git worktree 允许在同一个仓库的基础上，额外创建若干个"链接工作树"——它们是独立的物理目录，每一个可以检出不同的分支，但共享同一套底层的 git 对象库，不会重复占用磁盘。具体操作是用git worktree add <路径> -b <新分支名>在指定路径创建新的工作目录并检出独立分支；完成后用git worktree remove清理即可。
Claude Code 的 AgentTool 支持isolation: 'worktree'隔离模式，原理就是给每个 Sub-agent 分配一个独立的 git worktree，让它在自己专属的工作目录和分支上进行操作。这样在物理层面上，多个 Agent 同时写文件时操作的是各自的目录，不会产生直接的文件写入冲突。
但 worktree 解决的本质上是文件系统层面的冲突，解决不了语义层面的冲突。比如两个 Agent 分别在自己的 worktree 上修改了同一个模块的接口，各自提交完之后，当这些分支需要合并时，冲突依然会暴露出来。worktree 只是把冲突从"同时写"推迟到了"合并时"，并没有消除冲突本身。
因此，就算引入了 worktree 隔离，任务拆解时仍然需要尽量保证各个 Sub-agent 的工作边界在逻辑上是清晰且不重叠的。如果发现任务在设计上必然会产生交叉，那就需要强制串行处理——但一旦串行，效率相对并行就会更低。这个串并行的判断本身，也是对 Orchestrator 能力的一个考验。
上下文管理与结构化摘要
Orchestrator 的另一个核心挑战是上下文管理。
Sub-agent 把信息传回时，摘要的粒度很难拿捏。信息太少，Orchestrator 对全局的掌控就会变弱，容易做出偏差较大的调度决策；信息太多，又会大量占用 Orchestrator 的上下文窗口，让它陷入细节，反而模糊了对整体任务进度的判断。
我目前倾向于让 Sub-agent 输出结构化文本来缓解这个问题。大概的思路是：不让 Sub-agent 自由叙述完成了什么，而是要求它按照固定格式输出几个字段，比如任务状态、关键发现、阻塞点、建议的下一步操作。这样 Orchestrator 在读取的时候，不需要从一大段叙述性文字里自己提炼关键信息，而是可以直接定位到它做决策时真正需要的那几个维度。
这个方法能奏效的前提，是你对"Sub-agent 要汇报什么"和"Orchestrator 需要什么来做决策"事先有比较清晰的设计。如果格式设计得不好，结构化输出反而可能截断掉一些重要的上下文。具体怎么设计这个格式，我打算在做到 Multi-Agent 协作这块的时候，通过实际跑起来的效果来迭代——这种事情在纸面上想清楚，和在实践里跑通，之间还是有不小的距离的。
对 Orchestrator 能力的要求
综合以上这些问题可以看出，Orchestrator 其实需要承担相当多的职责：
- 任务分配与决策：如何合理拆解和分配任务，如何根据 Sub-agent 汇报的信息决定下一步操作
- 资源调配：相对简单的任务可以指派给调用成本更低的 Agent，要求较高的任务才调用更强的模型，实现动态的成本与能力配比
- 全局把控：始终对整体任务进度有清晰的认知，不被细节淹没
- 纠偏与审批：对 Sub-agent 的操作进行及时的判断，既不让整个系统频繁等待人类审批，也能在关键时刻介入纠正
这对 Orchestrator 的建模和提示词设计都提出了比较高的要求。
四、我对 Multi-Agent 适用场景的判断
其实以前我对 Multi-Agent 的想法是相对保守的——如果一个任务能靠单个 Agent 解决，就尽量不去开启 Sub-agent。
我最早认为，需要多 Agent 协同、尤其是主从结构的场景，通常是这样的：给了一个非常大的代码仓库，希望了解它的具体实现。这时派出一批 Agent 去并行探索并传回摘要，是一个很经典的协作模式——原因很直接：高效读取（并行执行只读不写的工作），以及节省主 Agent 的上下文（代码内容不会过度挤占主线程）。主 Agent 通过读取摘要，对整个仓库有全局了解，然后据此写文档或做进一步分析。
这种主从结构的一个特点就是：Sub-agent 之间互相不通信。我认为这个设计比较合理。如果让 Sub-agent 也互相通信，既有主从之间的通信，也有同级子 Agent 之间的讨论，上下文很快会变得混乱——那些 Agent 之间的讨论未必真正有意义，但却占用了宝贵的上下文空间。
现在，我的判断有了一些调整。需要使用 Multi-Agent 的场景，通常具备以下特点：任务庞大且复杂，需要比较长的时间才能完成。在这样的场景下，虽然使用单个 Agent 接力也可以完成任务，但引入 Multi-Agent，往往能用更少的时间得到质量更高的产出——因为上下文隔离带来的并行效率和输出质量的提升，在庞大且复杂的任务上体现得最为明显。
但我仍然认为，这种模式不适合对质量要求极高的精细任务。比如，想让多个 Agent 协作完成一个复杂系统的编写，并且希望人类尽可能少地介入其中——这目前还是一个比较理想化的场景，仅在少数任务边界足够清晰的情况下才真正可行。对于多数复杂场景，人类的介入仍然是必要的。
在我看来，Multi-Agent 比较理想的实施方式是：人类只在"发布任务"和"验收结果"这两端出现，中间的过程完全由 Orchestrator 掌控。但要真正做到这一点，对 Orchestrator 的调度能力、沙盒的可靠性，以及任务边界的设计，都有相当高的要求。
这不是对 Multi-Agent 能力的否定，而更像是一个当前阶段的现实判断：Multi-Agent 能做很多事，但要让它在复杂任务上真正做得好，可靠的沙盒、合理的任务边界设计、以及 Orchestrator 足够强的调度能力，缺一不可。
大概下个星期会正式做到 Multi-Agent 协作这一块，到时候依靠实践来验证和迭代这些想法吧。
参考资料
Claude Code 多 Agent 架构分析. 基于 Claude Code 源代码.
Anthropic. (2025).Multi-agent coordination patterns: Five approaches and when to use them. Retrieved from https://claude.com/blog/multi-agent-coordination-patterns