多 Agent 协作的工程真相：不是把 Prompt 串起来，而是设计任务边界

一、先说失败长什么样

第一次做多 Agent 系统，绝大多数人会写出这样的结构：一个「规划 Agent」输出 JSON 任务列表，一个「执行 Agent」逐条执行，一个「审核 Agent」检查结果。Demo 阶段它跑得非常好，因为任务简单、数据干净、没有并发。上线两周后，故障开始集中出现：规划 Agent 输出了一条执行 Agent 无法解析的字段，执行 Agent 静默跳过；审核 Agent 认为结果不合格，把任务打回，规划 Agent 又生成了一条几乎相同但措辞不同的任务，系统在两条路径之间反复循环；上下文越滚越长，Token 成本在第三轮就超过了预算；最后用户看到的是一段「已完成」的总结，而实际数据一行都没有写进去。

这些问题的共同点不是模型不够强，而是边界没设计。多 Agent 的价值来自「职责隔离」，代价也全部来自「职责隔离」——一旦隔离得不干净，系统就会同时获得两者的缺点：既没有单体系统的确定性，也没有多 Agent 的并行收益。

二、任务边界：先定义输出契约，再定义角色

一个 Agent 在系统里的身份，不应该由它的 System Prompt 决定，而应该由它的输入契约和输出契约决定。判断一个 Agent 是否划分得合理，只需要问三个问题：

第一，它的输出能不能被下游程序直接消费，而不需要下游再「理解」一次？如果下游 Agent 还要用自然语言去猜上游的意思，这两个 Agent 之间其实没有边界，只是一个被切成两半的 Prompt。

第二，它失败的时候，错误能不能被局部化？如果一个 Agent 的失败会让整条链路重跑，那它承担的责任就太重了，应该继续往下拆。

第三，它能不能被单独测试？给一组固定输入，跑一百次，输出是否稳定可判定。做不到这一点的 Agent，本质上是一个不可测试的黑盒，放进生产环境只是把不确定性挪了个位置。

实践中最有效的一条约束是：Agent 之间只传结构化数据，不传自然语言对话历史。对话历史看起来信息量更大，实际上是把上一跳的推理噪音原封不动地传给下一跳，既贵又容易污染判断。用 schema 约束的 JSON 传递，配合一个明确的 status 字段（ok / retry / fatal），链路的行为会立刻变得可预测。

三、状态共享：黑板模式比消息传递更容易失控

多 Agent 的协作方式大致分两类：消息传递（Agent 之间点对点发消息）和共享黑板（所有 Agent 读写同一个状态存储）。

消息传递的优点是解耦清晰，缺点是当 Agent 数量超过 3 个之后，消息路径会迅速变成一张无法维护的图，任何一次重试都可能触发消息风暴。共享黑板的优点是可观测、可回放，缺点是所有人都能写，最终会演变成「谁都能改，谁都不负责」。

比较务实的做法是分层黑板：把状态拆成三层——input（只读，任务输入）、scratch（各 Agent 私有，可随意写）、result（共享，只能由声明的 owner 写）。每一层用不同的写入权限约束，Agent 在 scratch 里怎么折腾都行，但要把结果写进 result，必须通过一次显式的校验。这一层约束带来的收益，远大于换一个更强的模型。

四、失败回滚：幂等是唯一可靠的地基

多 Agent 系统的重试几乎不可避免，因此每一个有副作用的动作都必须是幂等的。这不是一句口号，需要落到具体设计上：

• 每个任务携带一个稳定的 task_id，下游服务以它作为幂等键，重复请求直接返回首次结果；
• 写操作前先写一条「意图记录」，完成后更新为「已确认」，崩溃恢复时靠这条记录判断该重试还是该补偿；
• 把「不可逆」的动作（发送、扣款、删除）集中到一个专门的 Agent 里，让整个系统的不可逆面收敛到一处，便于审计和人工兜底。

回滚策略上，宁可选「补偿」而不是「撤销」。撤销要求系统能精确还原到某个历史状态，这在外部系统参与时几乎做不到；补偿只要求定义「如果这一步错了，怎么把影响抵消掉」，实现难度低一个量级，也更容易在业务上被接受。

五、可观测性：trace 的粒度决定排障速度

多 Agent 系统出问题时，最痛苦的不是报错，而是「没有报错但结果不对」。这时候唯一能救命的是一份粒度合适的 trace。建议在每一次 Agent 调用上固定记录五样东西：输入摘要、输出摘要、耗时、Token 消耗、决策依据（为什么选这条路径）。

特别要强调的是决策依据。很多团队只记录输入输出，排障时看到「Agent 输出了 A，但正确答案是 B」，仍然不知道为什么。把模型选择路径的那一句推理单独抽出来落库，排障时间通常能从小时级降到分钟级。

六、成本与延迟预算：先定预算，再定架构

多 Agent 的成本不是线性的。一次串行的三步链路，如果每步都携带完整上下文，Token 消耗大致是单 Agent 的三倍以上；如果还带重试，实际可能是五到八倍。因此在动手之前，先算一笔账：单次任务可接受的 Token 上限是多少，可接受的端到端延迟是多少，然后反推能串几个 Agent、每步能带多少上下文。

一个经验值是：把「必须串行」的步骤压到三步以内，其余全部并行或合并。能用一个 Agent 加一次工具调用解决的问题，不要拆成两个 Agent。多 Agent 的收益来自「不同角色需要完全不同的上下文和工具集」，而不是来自「Agent 数量多」。

结语

多 Agent 系统真正的难点，从来不在 Prompt 写得多漂亮，而在于你是否愿意像设计分布式系统一样设计它：定义契约、约束写入权限、保证幂等、记录决策、控制预算。这五件事做到了，哪怕用的是最普通的模型，系统也能稳定跑起来；这五件事做不到，换再强的模型也只是把失败推迟到下一个版本。