LLM Agent 本质上就是分布式系统
多 Agent LLM 系统面临和分布式系统相同的挑战：协调开销、共识、故障模式，以及披着新外衣的 CAP 定理。
Sarah Chen
AI 社区正在构建多 Agent 系统：一组 LLM 分工协作、相互通信，去解决单个模型无法胜任的问题。一个“研究员”Agent 负责收集信息，一个“程序员”Agent 负责编写实现，一个“审查员”Agent 负责检查质量，一个“协调员”Agent 负责管理整个工作流。这个构想很有吸引力：各司其职的 Agent 像一支管理得当的工程团队那样协同工作。
如果这听起来很熟悉，那很正常。分布式系统领域的研究者已经研究了四十年如何协调相互独立的进程。多 Agent LLM 系统正在从第一性原理出发，重新发现分布式系统社区几十年前就已解决（或证明无解）的问题。理解这些相似之处，能让你少走弯路，也能避免构建出那些以可预见、人所共知的方式失败的系统。
协调的代价
分布式系统的第一课：协调是有开销的。两个进程各自独立处理不同任务，速度确实是一个进程的两倍。但如果两个进程要处理同一个任务，并且需要相互协调，它们往往比单个进程还慢，因为通信和同步的开销超过了并行带来的收益。
多 Agent LLM 系统很快就会碰到这个问题。“研究员”Agent 产出一份报告，“程序员”Agent 需要读懂报告才能写代码，“审查员”Agent 则要同时理解报告和代码，才能给出有用的反馈。每一次交接，都需要把上下文序列化进 prompt，再由接收方的 Agent 解析和理解。这正是分布式系统中的共享状态问题，而且 Agent 越多，问题越严重。
Single agent vs. multi-agent for a coding task:
Single agent:
1. Understand the problem (1 LLM call)
2. Research relevant APIs (2 LLM calls)
3. Write implementation (1 LLM call)
4. Review and fix (1 LLM call)
Total: 5 LLM calls, full context throughout
Multi-agent (researcher + coder + reviewer):
1. Coordinator describes task (1 LLM call)
2. Researcher reads and plans (1 LLM call)
3. Researcher does research (3 LLM calls)
4. Researcher summarizes findings (1 LLM call)
5. Coder reads summary (1 LLM call) ← context lost here
6. Coder writes implementation (1 LLM call)
7. Reviewer reads code + summary (1 LLM call) ← context lost here
8. Reviewer provides feedback (1 LLM call)
9. Coordinator synthesizes (1 LLM call)
Total: 11 LLM calls, context degraded at each handoff
More agents = more communication = more cost = worse context.用分布式系统的话说，这就是阿姆达尔定律在通信上的体现：并行带来的加速比，受限于那些无法并行化的串行通信环节。对于需要紧密协作的任务，不断增加 Agent，只会让系统变慢，而不是变快。
共识问题
当多个 Agent 处理同一个任务时，它们必须就很多事情达成一致：需求是什么？采用什么方案？这个实现是否正确？在分布式系统中，这就是共识问题，而且它在理论上就很难解决。FLP 不可能性结论表明：在异步系统中，哪怕只有一个进程可能出错，确定性的共识也是不可能实现的。
在共识方面，LLM Agent 甚至比传统的分布式进程更难搞，因为它们是非确定性的。同一个问题问同一个 Agent 两次，得到的答案可能不同。两个 Agent 审查同一段代码，可能对它是否正确意见相左。如果让一个“协调员”Agent 来裁决分歧，它很可能像掷硬币一样随意。
多 Agent 框架通常的做法有两种：一是指定一个拥有最终决定权的协调员 Agent（即中心化共识模型，简单，但会形成单点故障）；二是多数投票（代价高昂，每个决策至少需要三个 Agent）。两种方式都能用，但它们解决的问题，恰恰是因为你一开始就把工作拆给了多个 Agent 才产生的。
似曾相识的故障模式
多 Agent 系统的故障方式，分布式系统工程师一眼就能认出来。
- 级联故障。Agent A 产出了错误的结果，Agent B 基于 A 的输出工作，得到更糟的结果。负责审查 B 工作的 Agent C 没能发现最初的错误，因为它继承了错误的假设。这相当于分布式系统中的错误传播：垃圾进，垃圾出，并且在每个环节被不断放大。
- 死锁。Agent A 等待 Agent B 的输出才能继续，Agent B 又等待 Agent A 的反馈才能继续，两者都无法推进。在实践中，这表现为无限循环，Agent 之间反复传递任务，却始终无法收敛。
- 脑裂。两个处理相关任务的 Agent 对问题形成了不一致的认知。一个假设 API 返回 JSON，另一个假设返回 XML。它们各自的输出都没问题，但彼此无法兼容。
- 惊群效应。协调员 Agent 同时把任务分发给多个 Agent，它们全都打向同一个 API，耗尽同一个速率限制，或者同时去修改同一个文件。这种资源争用，单个 Agent 永远不会遇到。
多 Agent 什么时候真正有用
分布式系统的类比是双刃剑。分布式系统确实能为特定问题带来实际收益，多 Agent 系统也一样，前提是用在那些确实能从任务拆分中获益的问题上。
天然可并行的任务。如果你需要在 50 个代码库中查找同一种模式，那么 50 个 Agent 独立工作，确实能快 50 倍。无需协调，每个 Agent 处理一个独立的输入，产出一个独立的输出。这就是 MapReduce 模式，它用在 LLM Agent 上和用在分布式数据处理上一样有效。
多元视角。让三个使用不同 system prompt 的 Agent 审查同一段代码，可能会发现单次审查漏掉的问题。这就是冗余模式，类似于让多位评审员来审阅同一个 PR。代价是三倍的算力，但覆盖面更广。
职责专一，接口清晰。一个接收文本并返回译文的翻译 Agent，接口很清晰；一个接收文档并返回摘要的摘要 Agent，接口同样清晰。把它们组合起来（先翻译，再摘要）效果很好，因为两者之间的接口很简单。对应到分布式系统，就是那句老话：接口定义清晰的微服务，远比接口复杂、交互频繁的微服务好用。
分布式系统的经验教训
如果你正在构建多 Agent LLM 系统，分布式系统几十年积累的经验可以直接套用。
- 优先选择少而强的 Agent，而不是大量专用 Agent。设计良好的单体应用，往往胜过设计糟糕的微服务架构。同理，对于大多数任务，一个配合良好 prompt 的强大 Agent，往往胜过一个由众多狭窄 Agent 组成的团队。只有在证明单个 Agent 确实无法胜任工作负载时，才增加 Agent。
- 在 Agent 之间定义清晰的接口。每个 Agent 的输入和输出都应该有明确的定义。含糊的交接（例如“弄清楚研究员发现了什么，然后把它实现出来”）会导致上下文丢失和理解偏差。Agent 之间采用结构化的数据契约，比自由格式的文本更可靠。
- 让 Agent 具备幂等性。如果某个 Agent 在中途失败，你应该能够用相同的输入重新启动它，并得到正确的结果。这要求 Agent 不持有隐藏状态，并且在确认输出正确之前不产生副作用。
- 加上可观测性。记录每一条 Agent 间的消息、每一个决策、每一次失败。当多 Agent 系统输出错误结果时，你需要能追溯到是哪个 Agent 在什么原因下做出了错误决策。没有可观测性，调试就只能靠猜。
- 为部分失败做设计。任何 Agent 都可能失败、输出垃圾结果或超时。系统应当优雅地处理这些情况：重试、退回到更简单的方案，或者请求人工介入。永远不要假设所有 Agent 都会成功。
令人不太舒服的真相
大多数多 Agent LLM 系统，如果换成一个配合良好 prompt 的单 Agent，效果反而会更好。对于单个模型就能胜任的任务，多 Agent 架构的协调开销、上下文丢失和故障模式，几乎总是超过它带来的收益。随着 AI 工具的演进，构建复杂多 Agent 系统的诱惑只会越来越大，但分布式系统的教训很明确：不要把本不需要分布式的东西分布式化。
例外情况确实存在：天然可并行的任务、接口清晰的真正专业化分工，以及超出单个模型上下文窗口的问题。除此之外，一个结构良好、工具齐全、重试策略周全的单 Agent，通常会胜过一支 Agent 团队。它在架构上没那么激动人心，但效果更好。最好的分布式系统，就是你不必去构建的那个。
