最近在做一个多 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 TeamsAgent 团队与 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
