单个 Agent 的能力会被上下文容量和角色冲突卡住，多 Agent 用分工换并行与专注，代价是协调开销、状态一致性和翻倍的 Token 账单。这篇文章讲清单 Agent 的天花板在哪、三种编排模式怎么选、Agent 之间如何传递状态，以及哪些场景根本不该拆。

单 Agent 的天花板在哪里

一个 Agent 就是一个模型加一套工具在一个循环里跑，任务变大后有两个结构性问题：

  1. 上下文装不下，也看不准。调研型任务可能抓回几十个网页，原始材料、工具日志全部堆进同一份上下文后，关键指令被稀释，模型开始”看得多、记得乱”。即便窗口够长，注意力质量也会随长度下降。
  2. 角色互相打架。让同一个 Agent 既当创作者又当批评者，等于让它一边写一边挑自己的毛病——自我评价天然偏宽容，评审环节很容易沦为走过场。生成与评审分离，是质量保障的起点。

此外还有权限粒度问题：检索角色只需要只读搜索，编码角色需要写文件，评审角色只需要看 Diff。全塞给一个 Agent，等于给每个角色都开了超集权限，攻击面和误操作面同时放大。

先问要不要拆，再问怎么拆

多 Agent 不是默认架构。判断标准很朴素：单 Agent 配上好工具已能在可接受的成本与延迟内完成任务，就不要拆。拆分带来的调度、结果归并、失败恢复工作量是实打实的。

值得拆的信号有三个：

  • 各环节需要明显不同的工具、权限或上下文（检索 vs 编码 vs 评审）；
  • 任务能分成几个相对独立的方向，可以并行推进；
  • 每个角色能交付结构化产物（带引用的结论、代码 Diff、测试报告），而不是几段自由文本。

反面信号同样清晰：角色之间频繁依赖彼此的中间结论、必须反复同步完整上下文、或拆完只是让几个 Agent 各写一段相似总结——这些情况下拆分是纯损失。上线前用同一批任务做对照实验：单 Agent 对多 Agent，比质量、耗时、Token 与失败率，没有可衡量的收益就保留简单实现。

三种主流编排模式

流水线（Sequential / Pipeline）

代码按固定顺序调用各 Agent，前者的产出是后者的输入，独立环节可并行。以股票分析为例：”研究员产出基础结论 → 技术分析师与舆情分析师并行补充 → 投资经理汇总”，阶段顺序由代码控制，阶段内部才交给各自的 ReAct 循环。优点是流程可预测、好测试、预算好控制；缺点是灵活性有限、时延逐级累加。业务步骤稳定的任务优先选它。

主管-工人（Supervisor / Orchestrator-Worker）

主管 Agent 拿到问题后动态拆解，把子任务派给若干工人 Agent，回收结果再决定继续派活还是收工。开放式调研最典型——不同问题要查的方向天差地别，事先画不出固定流程图。代价是主管成为瓶颈与单点：每轮派活决策都消耗 Token，协调逻辑复杂后主管自身的上下文也会膨胀。

辩论与评审（Debate / Evaluator-Optimizer）

生成者产出，评审者挑刺，循环往返直到达标或触顶。适合结论可被证据检验、分歧本身有价值的场景，如代码审查、方案评审。风险是”无限打磨”：没有明确的评分标准与退出条件，两个 Agent 会互相客套或抬杠到天荒地老。辩论不保证更正确，只保证分歧被暴露。

通信协议与共享状态

Agent 之间默认不需要”聊天”。进程内流水线用参数和返回值交付结果就够了；消息总线、远程 Agent 协议是拆成独立服务之后才要考虑的事，复杂度（鉴权、重试、顺序、重复投递）也随之而来。

实践上有几条共识：

  • 交付结构化结果，而非完整对话。检索角色给评审者的应是结论摘要、引用、数据时间和原始材料存储地址（Artifact URI），需要核对时按地址回读原文，而不是重放整个检索过程。
  • 共享状态分槽写入。每个 Agent 只更新自己负责的状态槽，权威字段（如最终报告）只允许归并节点写。两个 Agent 同时覆盖同一字段，线程安全容器只能保证数据不损坏，保证不了业务上该保留谁。
  • 区分结论冲突与写入冲突。技术分析师看 60 日 K 线判断偏多，舆情分析师发现短期情绪偏空——这不是谁错了，是时间尺度不同，应保留各自来源交给归并者裁决。而两个分支重复发通知属于副作用冲突，要靠单一执行者、幂等键和唯一约束解决，指望 Prompt 自觉是防不住的。

职责还要落成运行时可强制执行的契约，而不是 Prompt 里的形容词：

class AgentTask(TypedDict):
    task_id: str
    role: str                    # 角色：researcher / reviewer / ...
    goal: str                    # 子目标与成功标准
    dependencies: list[str]      # 依赖的上游任务
    allowed_tools: list[str]     # 运行时收窄的工具白名单
    output_schema: str           # 交付物结构约定
    max_iters: int               # 迭代上限
    deadline_seconds: int        # 阶段超时
    max_attempts: int            # 重试次数

契约的意义在于：工具范围、超时、重试由代码控制，模型只接收完成当前子任务所需的最少信息。

成本与延迟：绕不开的账

多 Agent 的开销是乘法而非加法：

  • Token 成倍增长。每个角色都要携带自己的系统提示、工具描述与上下文；主管模式下主管每轮还要重读全局状态。公开工程实践中，多 Agent 研究类系统的 Token 消耗达到单轮对话的数倍乃至十几倍并不罕见。
  • 延迟由最慢分支决定。并行能压缩墙钟时间，但端到端耗时仍取决于最慢分支加归并节点。并行没提速时，先查并发限额、外部接口限流和归并耗时。
  • “电话游戏”式衰减。长链路上每个角色只传自然语言摘要，信息逐级丢失，最终决策者拿到的可能是被稀释过三轮的转述。结构化交付加证据回链是主要缓解手段。

工程上必须监控各角色的调用次数、Token 与重试分布；评测时把总成本与质量放在同一张表上，防止”质量好 5%、成本翻四倍”。

失败恢复与观测

子任务失败不能一刀切重试：输入缺字段是契约问题，修一次或直接失败；接口超时是瞬时故障，有界重试加退避；某分支整体超时，按事先写进契约的成功门槛处理——保留已完成结果、标记缺失项、决定下游是否继续。恢复动作要落在正确层级：角色内部消化模型与工具失败，编排层决定取消分支、保留产物与下游去留。

观测上，一次运行是一棵树：根 Span 是整次任务，每个角色是子 Span，模型与工具调用挂在角色下面，重试挂在原角色下并记录第几次尝试。跨 Agent 的关联 ID 是让这棵树可回放的前提。

面试视角

什么时候该用多 Agent？ 三个条件同时满足才考虑：单一上下文装不下或角色互相干扰；子任务可独立并行；每个角色能交付结构化产物。先证明单 Agent 不够，再谈拆分。

编排模式怎么选？ 步骤稳定用流水线；方向事先无法枚举用主管-工人；需要暴露分歧用辩论评审。实践中常组合，例如固定外框加并行分支加归并节点。

怎么防止多 Agent 变成成本黑洞？ 任务契约写死迭代上限、超时与重试预算；监控各角色 Token 与调用次数；评测时总成本与质量同表对照。

小结

  1. 单 Agent 的天花板在上下文容量与角色冲突；多 Agent 的本质是用分工换并行与专注。
  2. 拆分前先证明单 Agent 不够；只换 Prompt 不换工具、上下文和权限的”多 Agent”只是改了名字的 Prompt 链。
  3. 编排三模式：流水线稳、主管灵活、辩论暴露分歧，可按阶段组合。
  4. 通信默认走结构化结果与分槽状态；结论冲突保留证据交归并者，写入冲突靠幂等与单一写者。
  5. 成本是乘法、延迟看最慢分支；契约、预算与 Trace 是防止失控的三件套。