关于 Multi-Agent System 的一些反思：为什么在当前阶段，大多数 MAS 是没有必要的

过去一年，我持续在做 Multi-Agent System（MAS）的工程实践，主要基于 LangGraph、CrewAI、n8n 等框架，尝试构建不同形态的 Agent 系统，用于研究、分析和自动化任务。

在这个过程中，一个结论逐渐变得清晰：
MAS 并不是一个默认正确的方向，在当前模型能力水平下，很多场景中它反而会带来性能和稳定性的下降。

这个判断并非来自理论推演，而是来自两个来源：
一是工程实践中的反复试错；二是 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 的架构设计。

在与 ChatGPT、Gemini 的 Deep Research 功能对比中，Claude Research 在复杂研究类任务上呈现出明显优势。但如果认真阅读这篇文章，会发现它的核心并不在于“Agent 数量”或“系统复杂度”。

Claude Research 的关键特征可以概括为：

单一 Agent 负责与人类对齐
多个子任务并行执行，但上下文严格隔离
子 Agent 只负责探索，不参与最终判断
所有筛选、收敛与验收，集中在一个对齐节点完成

这并不是一个强调自治的 MAS，而是一个以广度搜索为目标、以强对齐为前提的工程系统。

MAS 失效的根因：不是调度，而是对齐

在大量 MAS 实践中，一个反复出现的现象是：
每个 Agent 看起来都在“合理地工作”，但系统整体却无法收敛。

我认为问题并不主要出在调度策略，而在于一个更底层的事实：

LLM 并不知道人类是如何验收结果的。

在未经特定领域 meta-learning 或 fine-tune 的情况下，LLM 对以下问题并没有稳定认知：

什么状态算“完成”
什么时候应该停止
错误的代价和优先级是什么

当这样的模型被放入 MAS 结构中，问题会被放大：

不同 Agent 对目标的理解存在偏差
Agent 之间缺乏统一的验收预期
审查、执行、规划角色容易形成对抗

最终的表现不是能力不足，而是系统层面的不收敛。
这本质上是一个对齐问题，而不是模型能力问题。

健康 MAS 的前提：唯一对齐锚点，而不是固定拓扑

结合 A 社两篇文章的设计思路，以及我自己的工程经验，我并不认为 Master–Subagent 是唯一合理的 MAS 形态。
引入路由机制、基于能力或任务的动态分发，在工程上同样是合理的。

真正关键的并不是拓扑结构本身，而是一个更底层的前提：

MAS 系统中必须存在唯一的对齐锚点。

在 A 社的实践中，这个锚点通常由 Master Agent 承担；
在引入 Router 的 MAS 中，这个角色可能体现为：

Orchestrator
Router + Evaluator
或显式的人类对齐节点

但无论形式如何变化，有几点必须被严格约束：

Subagent 不应与人类直接对齐
Subagent 不应拥有最终验收与收敛权
系统中只能存在一个最终“判断者”

一旦多个 Agent 同时承担对齐职责，系统就会自然退化为对抗结构，表现为：

目标漂移
迭代成本快速上升
无法稳定收敛

因此，Master–Subagent 架构之所以常见，并不是因为它“更高级”，而是因为它在工程上最容易保证对齐单点。
当路由型 MAS 能够同样清晰地约束对齐关系时，它在原则上是完全等价的。

Subagent 的真实价值及其优先级

在对齐锚点明确的前提下，Subagent 的作用其实非常有限，并且可以清晰排序。

1. 上下文隔离（最核心，也是根因）

在 Agentic 系统中，Context Rot 是一个被严重低估的问题。

随着多轮任务推进：

上下文快速膨胀
无关信息不断污染推理
性能下降往往是非线性的

从工程实践来看，当前大多数 MAS 的真实构建动机，并不是为了提升智能，而是为了避免系统因 Context Rot 直接失效。

Master / Router + Subagent 的分层结构，本质上是一种上下文隔离机制：

Subagent 在独立上下文中消耗 token
对齐锚点只接收高度压缩的结果
核心决策上下文得以长期保持稳定

2. 广度搜索优先的任务

并非所有任务都需要深度推理，很多任务的瓶颈在于搜索空间。

典型场景包括：

市场与行业调研
企业数据洞察
生命科学与文献研究

在这类任务中，Subagent 的价值在于并行探索，而不是自治决策。
只要探索与对齐严格解耦，MAS 的收益才会显现。

Claude Research 正是这一模式的代表实现。

3. 大量工具调用（但重要性正在下降）

工具隔离曾经是 MAS 的一个重要理由，但这一点正在快速退化。

随着新一代模型能力的提升：

原生工具搜索
MCP Server Discovery
Skills 等机制

单一 Agent 已经不再需要一次性加载全部工具定义。
因此，仅仅因为“工具多”而构建 MAS，在当前阶段已经很难成立。

新一代 MAS 的两个典型失败模式

在 Claude 3.7、Gemini 2.5 Pro、GPT-5 这一代模型出现后，MAS 反而暴露出新的结构性问题。

Agent 对抗导致的不收敛

当审查 Agent 的能力过强，或被赋予过多否定权时，系统容易进入持续否定状态。
这不是 prompt 能解决的问题，而是博弈与收敛性问题。

一致性上下文被破坏

在代码审查、架构设计、复杂重构等任务中，全局上下文至关重要。
MAS 的上下文隔离机制在这里反而成为负担。

单一 Agent 的能力已经发生质变

我认为一个明确的拐点已经出现：

超长上下文成为常态
原生上下文工程能力增强
Agentic 生态逐步成熟

在这一背景下，单一 LLM-based Agent 的能力被系统性低估了。

很多过去依赖 MAS 的场景，如今用一个 Agent，反而更稳、更可控。

结论

MAS 不是通用解，而是一种高成本工具。

在当前阶段：

大多数企业与应用场景，并不需要 MAS
过早引入 MAS，往往会引入新的对齐与收敛问题

只有当单一 Agent 已经明确触及能力或上下文边界时，MAS 才是合理选择。

否则，它更可能只是画蛇添足。