跳到主要内容

多 Agent 方案为什么总是看起来很强，落地却很难

· 阅读需 5 分钟
一介布衣
一介布衣
全栈开发者 / 技术写作者

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-07-24 09:10。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

多 Agent 方案之所以特别容易让人兴奋，是因为它在演示里几乎总是成立：

  • 一个负责规划
  • 一个负责检索
  • 一个负责执行
  • 一个负责复核

界面一铺开，消息一串起来，整个系统会显得非常聪明，也很有“组织感”。但真正往生产环境里放，你很快就会发现它比单 Agent 或工作流系统更难稳住。

我后来总结下来，根本原因不是“多 Agent 不行”，而是很多团队把它当成能力叠加问题，实际上它首先是一个协作成本问题。

为什么它在 demo 里总显得特别强​

因为 demo 通常有三个天然优势：

1. 任务边界被人为压缩了​

演示里的任务一般都很干净，例如“围绕一个主题查资料并写一篇总结”。
输入、工具、时长、目标都被提前限制过。

2. 失败不会真的外溢​

即使某个 Agent 理解错了、规划偏了、重复调用了工具，最多是 demo 不完美，不会真的影响线上状态。

3. “分工”本身就很有戏剧性​

人天然会觉得“多个角色协作”比“一个流程按步骤执行”更高级。
这其实是一种展示优势，不是工程优势。

落地为什么马上变难​

一旦进生产，多 Agent 方案最先暴露出来的不是模型能力，而是这几类成本：

1. 任务拆分不稳定​

“先规划、再执行、再审查”听起来很合理，但现实任务经常没有那么整齐。
如果子任务边界模糊：

  • 规划 Agent 会拆得忽大忽小
  • 执行 Agent 会拿到半成品目标
  • 审查 Agent 也很难判断到底该审什么

最后你看起来有 4 个 Agent，实际上只是把一个模糊问题复制成了 4 份模糊。

2. 共享上下文很容易漂​

多 Agent 最大的隐藏成本不是 token，而是上下文一致性。

谁拿到的是最新计划？ 谁知道上一步失败过一次？ 谁知道某个工具结果已经过期？

如果没有强约束，Agent 之间很快就会形成各自版本的“事实”，然后互相在错误前提上继续推理。

3. 重试和幂等会一下子变复杂​

单 Agent 或固定工作流出错，你通常只需要重试一个节点。
多 Agent 出错时，问题就变成：

  • 是重跑当前 Agent
  • 还是回到规划阶段
  • 还是只重做某个工具调用
  • 会不会重复执行副作用操作

只要这里没有很强的任务状态设计，线上就会开始出现重复写入、重复发通知、重复发布。

4. 评测会突然很难做​

单步系统通常还能问“结果对不对”；
多 Agent 系统经常会变成“中间看起来都挺合理，但整体还是没做好”。

这时你很难回答：

  • 是规划错了
  • 是某个 Agent 拿错上下文了
  • 是执行策略不稳定
  • 还是最终裁决规则有问题

评测一旦没法落到节点级，系统就很难持续迭代。

我踩过的一个典型坑​

有一次我们试着把内容处理链路拆成四个 Agent：

  1. 选题分析
  2. 资料检索
  3. 草稿生成
  4. 审核修订

纸面上非常漂亮，但真正跑起来以后问题一堆：

  • 检索 Agent 和写作 Agent 对“这篇文章到底要写给谁看”理解不一致
  • 审核 Agent 经常重复挑已经在上一步修过的问题
  • 任务一旦超时，恢复点完全不清楚
  • 整条链路的日志很多，但真正可复盘的信息很少

最后我们反而把系统收回成“单调度器 + 明确节点”的结构，稳定性明显高了一截。

我现在更推荐什么结构​

大多数团队真正需要的不是“多个会聊天的 Agent”，而是：

  • 一个负责总控的调度器
  • 一组输入输出明确的工具节点
  • 必要时少量专用子代理

更像下面这种：

{
  "orchestrator": "content_pipeline",
  "steps": [
    "collect_context",
    "generate_draft",
    "run_checks",
    "human_review",
    "publish"
  ],
  "retryPolicy": {
    "generate_draft": "retryable",
    "publish": "idempotent-only"
  }
}

这个结构不花哨，但好处非常现实：

  • 状态边界清楚
  • 每一步都能观测
  • 失败后知道从哪恢复
  • 副作用节点容易做幂等

什么情况下我才会认真上多 Agent​

现在只有在下面几个条件同时满足时，我才会考虑多 Agent：

  1. 子任务可以独立验证，不是纯靠主观感觉
  2. 子任务之间有清楚的输入输出接口
  3. 某些分支确实可以并行，而且并行后收益明显
  4. 失败后能在节点级恢复，而不是整条链重来

如果这四条做不到，多 Agent 往往只是把复杂度提早引进来。

多 Agent 最容易被忽略的一条现实原则​

角色分工不等于系统分工。

“研究员 Agent、程序员 Agent、审稿 Agent”这种命名很容易让人产生组织幻觉，好像系统天然更专业了。
但工程上真正重要的是：

  • 数据怎么传
  • 状态怎么记
  • 失败怎么退
  • 结果怎么验

这些问题如果没有被设计好，角色再多，也只是更多对话，不是更强系统。

总结​

多 Agent 方案为什么总是看起来很强，落地却很难？因为它的难点从来不在“多几个模型角色”，而在“有没有能力承受多节点协作带来的状态、恢复、幂等和评测成本”。

演示里最迷人的，往往正是生产里最贵的。对大多数团队来说，先把单调度器和清晰节点做稳，比提早迷恋多 Agent 更接近真实收益。