Tbye.
返回手记
AI 架构··8 min read

Multi-Agent 架构：什么时候该拆，什么时候别拆

Multi-Agent 很热，但不是任务一复杂就该把 Agent 越拆越多。本文结合 Anthropic、OpenAI、LangChain 与 AutoGen 的一手资料，讲清常见多 Agent 架构、适用边界与真实代价。

Multi-Agent 架构：什么时候该拆，什么时候别拆

这半年里，Multi-Agent 几乎成了 Agent 圈子的“默认升级路线”：一个 Agent 不够，就加 planner、reviewer、coder、browser、critic，最后拼成一个团队。

问题是，多 Agent 并不天然更强，它只是把“模型能力问题”换成了“系统协调问题”。

Anthropic 在《Building Effective AI Agents》里给了一个很重要的提醒：很多成功案例并没有用复杂框架，而是先从简单、可组合的模式做起。OpenAI Cookbook 也强调，很多场景里真正需要的只是清晰的 routine、明确的 handoff 和合适的工具。我的判断是：Multi-Agent 是解决复杂性分布的办法，不是制造复杂性的借口。

为什么单 Agent 会撞墙？

单 Agent 最大的优点是简单：上下文集中、链路短、调试直观。但任务一旦变成“长流程 + 多工具 + 多目标”，它会同时遇到三类压力：

  • 上下文拥挤：规划、执行、校验全塞进一个 prompt，信息互相挤压。
  • 决策过载：工具太多、分支太多，模型更容易选错路径。
  • 状态不稳定：任务跨多个回合后，单 Agent 容易遗忘中间假设，或者过早宣布完成。

这正是多 Agent 出场的地方：不是为了模拟“公司组织架构”，而是为了把不同职责拆开，减少单个 Agent 一次要处理的变量。

三种最常见的 Multi-Agent 架构

1. Manager-Worker：最实用的主从式

这是现实里最常见的一种：一个主 Agent 负责拆任务、控节奏，多个 worker 负责写代码、查资料、跑测试、做评审。

Manager → 分解任务 → Worker A / Worker B / Worker C
        → 汇总结果 → 决定下一步

优点是可控、好观测，适合工程流程；缺点是 manager 容易变成瓶颈。如果主 Agent 判断失误，下面所有 worker 都会在错误方向上高效努力。

2. Handoff：按场景切换专家

OpenAI Cookbook 里的 handoff 思路更像“接力”：客服 Agent 识别到退款问题，就把上下文交给退款 Agent；识别到技术问题，再交给支持 Agent。

这种模式的核心不是并行，而是角色切换。它适合意图分流明确的系统，比如客服、销售、运营后台。它的难点在于：handoff 一旦做得含糊，用户上下文就会在切换中丢失，体验会变得像被反复转接电话。

3. Generator-Critic：生成-评审闭环

AutoGen 和很多代码 Agent 框架都喜欢这一套：一个 Agent 负责产出，一个 Agent 负责找错，再由前者继续修改。

Generator → 输出草稿
Critic    → 指出问题
Generator → 迭代修正

这类架构特别适合代码、写作、分析报告，因为“先做出来，再被挑错”本来就是高价值流程。但它也最容易失控：如果没有明确的停止条件，系统会在“继续优化”里空转，成本和时延一起上升。

Multi-Agent 真正解决了什么？

LangChain 文档说得很直接：开发者想要多 Agent，通常是因为需要专业化、上下文隔离和并行处理。这三个词，基本概括了它的真实价值。

  • 专业化：不同 Agent 拿不同提示词、工具和知识，减少“一个 Agent 什么都懂一点”的稀释。
  • 上下文隔离：研究任务不必带着部署日志，测试任务也不必背着产品需求全文。
  • 并行处理：可独立的子任务同时推进，降低整体等待时间。

但这里有个经常被忽略的事实：并行只对“可并行的问题”有效。 如果所有子任务都依赖同一份未确认的前提，多开几个 Agent 只会更快地产生一批错误答案。

最大误区：把“分工”当成“能力增强”

很多团队第一次做 Multi-Agent，会犯两个错误。

第一，过早拆分。单 Agent 连工具调用、状态记录、基础验证都没做好，就直接上四五个角色，结果不是能力提升，而是日志变多、责任更难追。

第二，角色命名很漂亮，职责边界却不清楚。比如 planner 既能改计划又能直接写代码，reviewer 既评审又能重构，最后谁都能做一切，系统复杂度上去了，结构化收益却没有出现。

我的建议是：先把单 Agent 做到“能稳定完成一个完整闭环”，再考虑拆分。 如果一个任务还没有稳定的输入、输出和验收标准，多 Agent 只会放大混乱。

一个更务实的落地顺序

如果你正在设计 Agent 系统，我更推荐这条升级路线：

  1. 单 Agent + 好工具：先确认任务能跑通。
  2. 单 Agent + 强验证：补上测试、评估、日志和状态记录。
  3. 主从式 Multi-Agent：只把最重、最独立的子任务拆出去。
  4. 再考虑并行与评审环：在可观测性足够时逐步增加复杂度。

换句话说，Multi-Agent 的门槛不是“任务复杂”，而是“你是否已经能管理复杂性”。

结论

Multi-Agent 架构确实重要，但它最适合的不是“让 AI 看起来更聪明”，而是让系统在复杂任务里保持清晰分工、有限上下文和可验证流程。它解决的是工程组织问题，不是魔法问题。

所以我的结论很明确：默认先用单 Agent，遇到明确的上下文拥堵、工具过载或子任务可并行时，再引入 Multi-Agent。拆得越晚，往往越稳；拆得越有边界，收益才越真实。

参考资料

  1. Anthropic, Building Effective AI Agents, 2024. https://www.anthropic.com/engineering/building-effective-agents
  2. OpenAI Cookbook, Orchestrating Agents: Routines and Handoffs. https://developers.openai.com/cookbook/examples/orchestrating_agents
  3. LangChain Docs, Multi-agent. https://docs.langchain.com/oss/python/langchain/multi-agent
  4. Microsoft Research, AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation. https://www.microsoft.com/en-us/research/publication/autogen-enabling-next-gen-llm-applications-via-multi-agent-conversation-framework/