多Agent协同无效？烧32亿Token试错后：此路不通

背景

随着大语言模型（LLM）能力的提升，多 Agent 协同（Multi-Agent Collaboration）曾被视为解决复杂任务（如长篇小说写作、复杂代码开发、全栈网站构建等）的终极方案。许多 AI 初学者和开发者尝试利用 OpenMoss 等工具搭建多 Agent 工作流，期望通过模拟人类团队的分工协作（如产品经理、程序员、测试员各司其职）来突破单模型的局限。

然而，在实际的高强度应用中，这种模式暴露出了严重的问题。有开发者在消耗 32 亿 token、跑空 3 个不同厂商的高级会员后得出结论：多 Agent 协同流程在大多数场景下只是一个“美好的空想”。它不仅未能带来更好的交付质量，反而因为巨大的 Token 消耗和结果偏移，证明了当前主流的多 Agent 架构存在根本性的逻辑缺陷。

核心内容

1. 多 Agent 协同的迷思：人类协作模式的误用

多 Agent 系统的流行，很大程度上是因为它满足了人类对于“团队协作”的直觉想象。其基本逻辑是：将复杂任务拆解，为每个 Agent 设定独立的提示词（Prompt）和角色，让它们独立工作，最后汇总或按流程层层交付结果。

然而，这种模式是基于人类能力边界制定的。在人类团队中，成员可以通过会议、非正式沟通等方式实时修正偏差，且人类具备将工作往主目标靠拢的“默契”和“文化”。但 LLM 的特性与人类截然不同：

• 无职业边界：同一个模型既能写 PRD 也能写代码，不存在真正的专业壁垒。
• 瓶颈不同：模型的瓶颈不在于注意力广度，而在于推理深度和信息完整性。
• 角色标签的副作用给 Agent 贴上“产品经理”标签，并不会让它更专业，反而会让它拒绝越界，封死了 AI 最有价值的“边界推理”能力。

2. 核心缺陷：信息损耗与推理链断裂

多 Agent 系统最严重的问题在于 Agent 之间的交付方式。

• 只交付结论，不交付过程：Agent 之间传递的是最终结果，而非推理过程。
• 意图衰减：随着工作流变长，原始意图逐渐衰减。由于多 Agent 系统大多是单向传递，缺乏双向沟通和“回头”纠错机制，无法弥补信息损耗。
• 局部正确，全局偏离：最终得到的结果往往是局部逻辑正确，但整体严重偏离用户设想。当出现错误时，由于缺乏中间推理状态的透明化，用户甚至不知道从哪个环节入手纠错。

3. 头部厂商的真实实践：Context Engineering

当 Anthropic、OpenAI、Google 等头部厂商构建生产级 Agent 系统时，其工程文档中几乎找不到“角色扮演”或“部门分工”的字眼。真正的解决方案并非模拟人类分工，而是通过工程手段管理上下文状态：

• Anthropic 的做法（Context Engineering + 显式状态文件）：
  • 理念升级：从“Prompt Engineering”升级为“Context Engineering”。核心挑战在于如何让 Agent 在离散的 Session 中工作，因为每个新 Session 对之前的事情没有任何记忆。
  • 类比：将 Agent 视为“轮班工程师”，新班次到岗时对上一班工作一无所知。
  • 解决方案：
    1. claude-progress.txt：一个跨 Session 的工作日志。Agent 在每个 Session 结束时更新，下一个 Session 开始时读取。
    2. Git History：作为状态锚点，记录每一个增量变化。
    3. Initializer Agent：仅在第一个 Session 运行，负责建立环境、展开 Feature List、写好 Runbook，供后续所有 Session 使用。
  • 关键洞察：推理链的连续性不靠模型“记住”，而是靠显式的外部状态来锚定。

4. 当前建议：回归简单

基于上述分析，对于当前阶段的 AI 应用：

• 避免过度复杂化：大于 3 个 Agent 的系统极易失控，遇到复杂任务时完全没有抓手，只能眼睁睁看着结果跑偏。
• 推荐方案：2-3 个不同的 Agent 协同尚可控，但更推荐直接使用 Subagent 模式。Subagent 已经能解决大部分用户的实际问题，无需盲目追求多 Agent 协同的高昂成本。

关键要点

• 多 Agent 协同并非万能：在 Coding、写作、网站开发等大多数场景中，多 Agent 流程除了消耗海量 Token 外，并不能带来更好的交付质量，甚至可能导致结果完全偏离预期。
• 人类协作逻辑不适用于 AI：LLM 没有职业边界，角色标签会限制其推理能力。AI 的瓶颈在于推理深度和信息完整性，而非分工。
• 信息损耗是致命伤：Agent 间仅传递结论而不传递推理过程，导致原始意图随工作流延长而衰减。单向传递机制缺乏纠错能力，造成“局部正确，全局偏离”。
• 工业级实践转向 Context Engineering：头部厂商（如 Anthropic）不再依赖“角色扮演”，而是通过显式状态文件（如 claude-progress.txt）、Git History 和初始化 Agent 来锚定推理链的连续性，解决 Session 间记忆丢失问题。
• 当前最佳实践：现阶段不建议轻易尝试超过 3 个 Agent 的系统。对于大多数用户，Subagent 模式足以解决问题，多 Agent 协同在当前技术阶段属于“此路不通”的高成本陷阱。

意义与影响

这篇文章对当前 AI 应用开发领域具有重要的纠偏意义。它揭示了“多 Agent 协同”热潮背后的工程误区，指出许多开发者错误地将人类组织管理的逻辑套用于 AI 系统，导致了资源浪费和效果不佳。

其影响主要体现在两个方面：

1. 工程方法论的转变：推动了 AI 开发从“Prompt 角色扮演”向“Context Engineering（上下文工程）”和“显式状态管理”转变。强调通过外部工具（如日志、版本控制）来维持 AI 推理的连续性和一致性，而非依赖模型内部的幻觉或隐式记忆。
2. 用户预期的管理：提醒开发者和用户理性看待 AI 能力，避免陷入过度复杂的 Agent 架构陷阱。在现阶段，简化工作流、利用 Subagent 等更轻量级的方案，往往比构建庞大的多 Agent 网络更具性价比和可控性。这有助于降低 AI 应用的试错成本，引导行业向更务实、更工程化的方向发展。