最近在重构一个 Agent 系统，从单智能体改成了多智能体架构。改完之后效果确实好了，但回头一看成本：Token 消耗翻了快 10 倍，代码复杂度也上去了。

这让我开始反思：什么时候真的需要多 Agent？什么时候其实是过度设计？

这篇文章就聊聊这个。不是理论分析，就是踩过的坑和一些实践经验。

一、我为什么会想拆 Agent

先说问题从哪来的。

项目最开始是单 Agent 架构，跑了一段时间后发现一个很明显的问题：对话越长，Agent 越容易”失忆”。

具体表现：

  • 重复之前已经失败的操作
  • 忽略用户早期提到的约束条件
  • 在一堆中间日志里迷失方向，找不到重点

最离谱的一次，我让它修复一个 bug，它前面试了 3 种方案都失败了，结果第 4 次又回到第 1 种方案重试，就好像完全不记得之前发生了什么。

这时候你会想：是不是该拆成多个 Agent，每个负责一个干净的子任务？

但问题来了——怎么拆？拆完之后会不会引入新问题？

二、多 Agent 到底解决了什么问题

在真正动手拆之前，我先梳理了一下：到底哪些场景是多 Agent 能解决、单 Agent 很难搞定的？

1. 上下文污染

这是我遇到的核心问题。

单 Agent 在执行任务时，上下文会不断累积。有些信息是有用的（用户需求、关键决策），但更多是噪声（中间步骤的原始输出、失败的尝试、调试日志）。

举个例子：

你让 Agent 分析一个用户的行为数据。它会：

  1. 查数据库，拉回来 3000 tokens 的原始记录
  2. 做清洗，又产生 1000 tokens 的中间结果
  3. 生成分析报告，500 tokens

到第 3 步时，上下文里已经塞满了前面的原始数据和中间结果。如果后续还要做决策（比如推荐下一步行动），这些历史数据都是噪声。

多 Agent 怎么解决？

拆一个 DataFetchAgent，让它在独立的上下文里完成数据查询和清洗，只返回一个干净的摘要（比如 “用户最近 7 天活跃度下降 30%，主要流失在功能 A”）。

主 Agent 只看到这个摘要，上下文保持干净。

但要注意： 这不是说所有查询都要拆 Agent。如果查询结果本身就很简洁（比如 “订单状态：已发货”），拆 Agent 反而多此一举。

2. 并行探索

有些任务天然适合并行，串行执行就是浪费时间。

我的场景：

需要对一个技术方案做可行性分析，包括：

  • 技术栈 A 的成熟度调研
  • 技术栈 B 的成熟度调研
  • 竞品是怎么做的

这三条路径完全独立，互不依赖。单 Agent 只能一个一个来，多 Agent 可以同时开工。

但有个隐藏成本： 并行不等于更快。

你虽然同时跑了 3 个 Agent，但每个 Agent 都要有完整的上下文初始化，总 Token 消耗可能是单 Agent 的 5-10 倍。省的是时间，花的是钱。

所以我的判断标准是：如果这个任务时效性很强（比如实时分析），并行值得；如果不急，单 Agent 串行更经济。

3. 工具选择过载

这是我后来才意识到的问题。

最开始我的 Agent 有 30+ 个工具（文件操作、数据库、API 调用、代码执行……）。跑了一段时间发现：工具越多，选错的概率越高。

不是模型能力不行，而是”选择过多”本身就是个认知负担。

类比一下： 就像你去餐厅，菜单上有 10 道菜，你很快就能决定；但如果有 100 道菜，你反而不知道该点什么，最后可能随便选一个。

后来我拆成了几个专业化的 Agent：

  • FileAgent：只有文件相关的 10 个工具
  • DBAgent：只有数据库相关的 8 个工具
  • APIAgent：只有外部 API 调用的 12 个工具

每个 Agent 只看到自己领域的工具，选择准确率明显上去了。

但要注意： 这个方案只适用于工具集本身有明确领域边界的场景。如果工具之间关联度很高（比如”读文件”和”解析 JSON”经常一起用），强行拆开反而增加通信成本。

三、但它的代价比你想的大

说完好处，得说说代价。这是我在实际落地时踩的坑。

1. Token 成本暴涨

这是最直观的代价。

我做过一个对比：

  • 单 Agent 完成一个任务：平均 15k tokens
  • 多 Agent 完成同样任务：平均 80k tokens

为什么差这么多？因为：

  • 每个 Sub-agent 都要初始化一遍系统提示词
  • Agent 之间传递消息也要花 tokens
  • 结果要总结才能传给下一个 Agent

这还不算最坑的。 最坑的是：你花了更多 Token，但很多都用在”通信”上，并没有真正用在推理上。

我把这个叫 “通信税”——就像分布式系统的网络开销，单机不需要考虑延迟，但一旦拆成微服务，网络通信本身就成了新的瓶颈。

所以我的经验是： 拆完之后，算一下信息传递消耗的 Token 占总 Token 的比例。如果超过 40-50%，说明你可能在错误的地方画了线。

2. 信息在传递中损耗

这是更隐蔽的代价。

举个例子：

我让一个 Sub-agent 搜索相关代码文件。它找到了 5 个候选文件，经过分析排除了 4 个，最终选择了 file_a.py。

但返回给主 Agent 时，它只能说：”找到了 file_a.py，它处理用户认证逻辑。”

那它为什么排除了另外 4 个文件？这个决策过程丢了。

如果后续主 Agent 需要理解为什么选择 file_a 而不是 file_b，它只能重新推理一遍，或者干脆盲目信任 Sub-agent 的选择。

这就是信息损耗的本质： 探索过程中的上下文线索被压缩掉了，只保留了结论。

3. 隐式决策链断裂

这是我最近读到的一个观点，来自 Cognition 的博客（做 Devin 的那家公司），我觉得特别准确。

他们提出：Actions carry implicit decisions（每个行动都暗含决策）。

什么意思？

比如，一个 Agent 选择修改 file_a.py 而不是 file_b.py，这背后隐含了它对架构的某种理解。但这个”隐式决策”没有被显式写下来，只是体现在行为序列中。

当你拆成多个 Agent 并行工作时，这些隐式决策就断了。

我遇到的实际问题：

Agent A 在处理前端逻辑时，选择了某种数据结构（基于它对后端 API 的理解）。Agent B 在处理后端逻辑时，不知情地引入了不兼容的依赖。

冲突的根源不是”代码写错了”，而是决策上下文碎片化——两个 Agent 各自做了”局部最优”的选择，但放在一起就不兼容了。

类比一下： 就像两个人在不同房间各自装修，都觉得自己设计得很合理，但一合起来发现风格完全不搭。

四、所以，什么时候该拆？

说了这么多问题，你可能会想：那是不是别用多 Agent 了？

也不是。关键是要找对边界。

我自己总结的判断标准是：按上下文耦合度拆分，而不是按功能阶段拆分。

错误的拆法：按工作流程

很多人（包括我一开始）会这么想：

  • Agent A 负责需求分析
  • Agent B 负责编码
  • Agent C 负责测试
  • Agent D 负责审查

看起来很合理，就像敏捷开发的分工。

但问题是：这恰好在上下文耦合度最高的地方画了线。

编码的 Agent 不知道需求分析时为何排除了某些方案。测试的 Agent 不知道编码时遇到了哪些权衡。审查的 Agent 更不知道前面发生了什么。

结果就是典型的”电话游戏”——信息在每次传递中被简化、误解，到最后一环已经面目全非。

正确的拆法：按上下文耦合度

什么叫上下文耦合度？

就是两个子任务需要共享多少上下文才能各自正确完成。

低耦合的例子：

  • 并行搜索不同市场的趋势（亚洲 vs 欧洲）
  • 黑盒测试最终产物（不需要知道实现细节）
  • 独立的数据清洗任务（输入输出明确）

高耦合的例子：

  • 编写功能和编写测试（需要理解设计意图）
  • 前后端并行开发（API 变更时需要频繁同步）
  • 需求分析和架构设计（决策高度关联）

我的判断标准：

  • 低耦合（<20% 上下文重叠） → 可以拆
  • 高耦合（>80% 上下文重叠） → 不要拆
  • 中等耦合（20-80%） → 谨慎评估，默认不拆

一个几乎不会错的模式

如果你实在不确定该不该拆，有一个模式几乎不会踩坑：Verification Subagent（验证子智能体）。

为什么它这么稳？因为验证 Agent 不需要知道主 Agent 是如何构建输出的，它只需要黑盒测试最终产物。

工作流程：

  1. 主 Agent 完成一个功能（比如写了一段代码）
  2. 生成一个验证 Agent，给它：
    • 待验证的产物（代码）
    • 验收标准（”所有单元测试通过” + “性能指标达标”）
  3. 验证 Agent 跑测试，报告结果
  4. 如果不通过，主 Agent 根据反馈修改

为什么不会踩坑？

需要传递的上下文非常少——只有产物和标准，没有实现细节，没有探索过程。信息损耗降到最低。

类比一下： 就像代码审查时，Reviewer 不需要知道你是怎么写出这段代码的，只需要判断”它是否符合规范”。

Anthropic 的博客里也提到这个模式是他们实践下来最稳定的一种，我自己用下来确实如此。

五、我的建议

总结一下，如果你在考虑多 Agent，可以按这个流程走：

1. 先穷尽单 Agent 的优化空间

别急着拆。先看看：

  • Prompt 是不是写得够清晰？
  • 上下文有没有做压缩？（只保留关键信息，丢弃中间步骤）
  • 工具描述是否准确？
  • 有没有用 Tool Use 的最佳实践？

我的经验： 很多看似需要多 Agent 的问题，实际上是单 Agent 的上下文管理没做好。

比如，你可以在每个阶段结束时，让 Agent 自己总结关键信息，丢弃无用的中间结果。这样就能在单 Agent 内部实现”上下文压缩”。

2. 识别明确的瓶颈信号

只有当你看到这些信号时，才考虑拆分：

  • 上下文窗口接近极限 → 表现为幻觉率上升、忽略早期指令
  • 工具选择频繁出错 → 工具集过大（20+ 个）
  • 需要并行覆盖大信息空间 → 单 Agent 串行太慢

如果没有这些信号，别拆。

3. 按上下文耦合度画线

拆的时候，问自己：

  • 这两个子任务需要共享多少上下文？
  • 如果拆开，信息传递的成本有多高？
  • 拆开后，会不会出现”决策上下文碎片化”？

如果答案是”需要共享很多上下文”，那就别拆。

4. 监控”通信税”

拆完之后，跑几个任务，算一下：

通信税 = 信息传递消耗的 Token / 总 Token

如果超过 50%，说明你的拆分方案有问题，需要重新调整边界。

六、最后想说的

多 Agent 不是银弹。

它解决的是特定问题：上下文隔离、并行探索、工具专业化。如果你的场景不符合这三种，单 Agent + 好好写 Prompt 可能更靠谱。

我很喜欢 Anthropic 博客里的一句话：“Start with the simplest approach that works, and add complexity only when evidence supports it.”

从最简单的方案开始，只在有证据支持时才增加复杂度。

那接下来问题就来了：怎么量化”上下文耦合度”？20% 算低，80% 算高，中间那段怎么办？

也许真正该做的不是定义精确的阈值，而是建立一套成本收益评估机制——投入多少 Token，得到多少性能提升，这笔账是否划算？

这可能是下一个值得深入的方向。

参考资料

  • Anthropic: Building multi-agent systems: When and how to use them
  • Cognition: Don’t Build Multi-Agents

如果你也在搞 Agent 系统，欢迎留言聊聊你遇到的坑。