多 Agent 的吸引力很强：规划、检索、执行、审阅各有一个角色，看上去像一支随时待命的小团队。但复杂度不会凭空消失，它只是从提示词内部转移到了角色之间的协作关系里。

因此，开始一个 Agent 项目时，更稳妥的路径通常不是先搭建多个角色，而是先做一个边界明确的单 Agent 闭环。

什么时候单 Agent 已经足够

如果任务满足以下条件，单 Agent 往往更容易调试，也更容易稳定交付：

  • 输入来源少，所需上下文可以一次装入
  • 工具权限一致，不需要额外的审批边界
  • 任务步骤较短，失败后可以从头重试
  • 结果可以用少量确定性规则校验

例如，根据一份结构化需求生成接口草稿、从知识库中回答问题，或把一段文本转换为固定格式，都可以先从单 Agent 做起。

单 Agent 的目标不是「无所不能」，而是把一次调用做成可观察、可重放的工作单元：输入是什么、引用了哪些上下文、调用了什么工具、输出是否通过校验，都应当能被记录下来。

多 Agent 真正解决的问题

只有当不同步骤的上下文、权限或优化目标确实不同，拆分角色才有价值。常见的分工包括：

  • 路由器：判断请求属于哪类问题，并选择后续流程
  • 规划器：把目标拆成可执行步骤，但不直接操作外部系统
  • 执行器：在有限工具集内完成检索、写入或调用
  • 审阅器：根据明确规则检查结果，而不是重新「猜一次」答案

关键不在角色名称，而在每个角色的输入和输出是否是稳定的协议。若规划器输出的是一段自由文本，执行器只能靠猜测理解，那么多加一个 Agent 只会多加一个不确定性来源。

三条必须写下来的契约

1. 输入与输出契约

角色之间应传递结构化数据，而不是未约束的自然语言。一个最小的计划对象可以包含目标、步骤、依赖和验收条件：

{
  "goal": "生成发布说明",
  "steps": [
    { "action": "collect_changes", "acceptance": "变更列表完整" },
    { "action": "draft_release_note", "acceptance": "包含影响与回滚说明" }
  ]
}

结构化输出的意义不是让模型永远不犯错，而是让错误可以被程序发现、拒绝或回退。

2. 状态契约

任务状态应由系统保存，而不是寄希望于模型「记住」。至少区分 pending、running、waiting_for_approval、failed 和 completed，并记录每一步的输入摘要、工具结果与重试次数。

这样一来，某个工具超时后可以从失败步骤继续；人工介入后，也不会丢失之前已经完成的工作。

3. 权限契约

规划不应自动拥有执行权限，读取不应自动拥有写入权限。尤其是涉及生产系统、代码推送、邮件发送或费用消耗的工具时，应让权限随角色和步骤收窄。

一个实用原则是：默认只读，升级权限时显式说明目标、范围和预期副作用。

一条渐进式演进路径

可以按下面的顺序推进，而不是一次性引入完整的多 Agent 框架：

  1. 做一个单 Agent + 少量工具的最小闭环。
  2. 为每次调用补齐日志、超时、重试和结果校验。
  3. 将上下文准备与工具执行拆出，先形成清晰模块边界。
  4. 只有当模块需要独立上下文或权限时，再将它变为独立角色。
  5. 用真实任务回放评估：成功率、耗时、成本和人工介入次数是否真的改善。

不要忽略可观测性

评估 Agent 系统不能只看最终回答是否「看起来不错」。每次运行至少应关注：

  • 任务完成率与失败原因
  • 每一步的模型调用和工具耗时
  • 输入、输出和检索上下文的 token 使用量
  • 工具调用成功率，以及重试是否掩盖了系统性问题
  • 人工接管的频率与原因

这些数据会直接决定下一步应该优化提示词、检索、工具可靠性，还是流程设计。

结语

多 Agent 适合解决边界清晰的协作问题，不适合用来掩盖一个尚未定义清楚的任务。先让单 Agent 在受控范围内稳定工作，再基于上下文、权限和失败模式拆分角色，系统会更容易演进，也更值得信任。