过去一年，我把大把工作时间砸在了 Multi-Agent System（MAS）上。从 LangGraph、CrewAI 到 n8n，各种形态的 Agent 拓扑搭了一圈，用来跑深度研究、代码分析和自动化流水线。
折腾到最后，一个极其清醒的结论砸在脸上：
MAS 从来就不是什么默认正确的方向。在当下的模型能力水平下，很多场景强行上多 Agent，纯粹是花钱买罪受，换来的是稳定性和性能的断崖式暴跌。
这个判断是踩了一年真实工程坑换来的，同时也印证了 Anthropic（下文简称 A 社）此前发布的那篇关键工程复盘：
https://www.anthropic.com/engineering/multi-agent-research-system
一、Claude Research 赢在收敛，而不是堆 Agent 数量
2025 年年中，A 社发布了 How we built our multi-agent research system，把 Claude Research 的架构底牌掀了个底朝天。
在与各类 Deep Research 功能横向对比时，Claude Research 啃复杂长任务的稳定性明显高出一截。很多人一眼看过去，觉得这是“多智能体协同的伟大胜利”。仔细扒开它的架构，会发现它干的事恰恰相反：
- 永远只有一个单一 Agent 负责跟人类对齐目标
- 派出去的子任务并行跑，上下文彻底物理隔离
- 子 Agent 充当纯粹的探路工兵，完全没有最终裁决权
- 所有的信息筛选、权重收敛与最终验收，全部收拢在同一个对齐节点
这套设计压根不搞什么分布式自治，它的本质是以广度搜索为目标、以强中心对齐为底线的漏斗工程。
二、MAS 崩盘的根因：模型根本不知道人类怎么验收
在大量多 Agent 的流水线里，最让人头疼的现象莫过于：
每个 Agent 单独看都在认真干活，但合在一起就是无法收敛。
调度策略写得再精妙也没用，底层横着一条死穴：
LLM 本身对人类的真实验收标准缺乏内在锚点。
只要没经过特定业务场景的深度调优，模型对这几件事的感知极其脆弱：
- 什么时候算真正“完成”
- 什么时候该果断停手
- 犯错的严重程度与优先级排序
把几个这样的模型丢进网状协同里，灾难立刻呈指数级放大：写代码的觉得自己写完了，审查代码的挑刺停不下来，调度中心不知道该听谁的。两边在上下文里反复拉扯，Token 跑得像流水，最后交出一堆七拼八凑的半成品。
这说明系统在对齐层面彻底散架了。
三、健康系统的底线：唯一的对齐锚点
对照 A 社的设计和我自己的踩坑记录，Master–Subagent 结构之所以管用，核心在工程上牢牢锁死了唯一的对齐点。
你可以用路由机制，也可以按任务动态分发。但不管拓扑画得多么花哨，必须守住铁律：
- 子 Agent 绝不能直接跟人类对话或承担全局对齐责任
- 子 Agent 绝不能拥有最终验收与收敛的生杀大权
- 全局只能留一个最终仲裁者
一旦放权让两个以上的 Agent 同时去猜人类的意图，系统会迅速退化成互相推诿的草台班子：目标漂移、死循环重试、产出失控。
四、Subagent 的真实价值：做脏活与上下文隔离
如果把对齐做扎实，Subagent 能发挥价值的地方其实就剩这么两点：
1. 上下文物理隔离（头号刚需）
上下文腐烂（Context Rot）是长链路任务的隐形杀手。
随着任务一轮轮往下滚：
- 上下文迅速膨胀
- 无关报错和废话污染推理链
- 模型的智商出现断崖式下跌
目前大多数多 Agent 架构能跑通，核心贡献是给上下文建防火墙。子 Agent 在独立的沙盒里消耗 Token、试错报错，最后只把干货摘要交回主节点。主脑的上下文得以保持干净清爽。
2. 纯粹的广度搜索
很多活儿不需要复杂的嵌套推理，瓶颈全在翻找资料的物理耗时上（比如行业信息地毯式搜集、多库并行检索）。
这种时候把探索和决策拆开，派一堆子 Agent 并行跑腿，才能真正赚到并发红利。
至于以前常说的“工具太多所以必须拆 Agent”，在 MCP Discovery 和原生动态工具检索普及后，这个理由已经站不住脚了。
五、新一代模型的单兵质变
随着 Claude 3.7、Gemini 2.5 Pro 这一代模型把超长上下文、反思能力和工具编排刻进骨子里，局面彻底变了。
过去为了防止单一模型犯蠢而设计的复杂 Agent 委员会，现在往往成了最大的绊脚石：
- 审查 Agent 权力过大，陷入无限否定的博弈死锁
- 上下文被切得稀碎，丢失了对大型代码库或复杂业务的全局大局观
一个人带上趁手的工具就能干净利落搞定的事，硬要拉五个 Agent 开闭门会议，除了给云厂商贡献账单，没有任何收益。
六、收尾
MAS 是精密的重武器，也是极易失控的复杂度放大器。
在眼下的工程阶段：
- 绝大多数业务和自动化场景，一个带好工具的单 Agent 已经能打下 90% 的江山
- 盲目上多 Agent，往往只是在用虚假的系统复杂度掩盖对齐能力的匮乏
只有当单 Agent 确实撞上了上下文或探索宽度的物理天花板，才是把任务拆出去的唯一合理时机。