最近一年，Multi-Agent 系统持续发热发烫，融资不断，火了起来。
从 AutoGPT 到 MetaGPT，从 CrewAI 到 LangGraph，各种多代理框架层出不穷。国内现象级的 Manus，以及当天由 MetaGPT 的同学开源的 OpenManus。OpenAI 的 Swarm、微软的 AutoGen，还有 Anthropic 的 Claude Code，每个大厂都在探索自己的 Multi-Agent 方案。GitHub 上相关项目的 Star 数动辄上万，社区讨论热度持续攀升。
从这股热潮，我们可以看出 AI 应用的一个重要趋势：从单一模型调用走向多智能体协作。就像软件开发从单体应用演进到微服务架构，AI 系统也在探索如何通过多个专门化的 Agent 协同工作，完成更复杂的任务。
当我们仔细观察这些 Multi-Agent 系统的架构时，会发现一个规律：
MetaGPT 里有个产品经理角色，负责协调其他工程师角色；AutoGen 支持 Manager-Worker 模式；Claude Code 更是明确采用了主循环引擎加子任务代理的设计。在 OpenAI Swarm 中，也能看到 Orchestrator Agent 的影子。
这些系统都采用了某种形式的「主从」架构------有一个 Agent 负责全局协调，其他 Agent 提供专门化支持。
为什么？巧合吗？
今天我们就聊聊 Multi-Agent 系统的主从架构。从大模型的底层原理开始。
1 从大模型的原理说起
1.1 大模型的「注意力」机制
要理解为什么需要主从架构，得先理解大模型是怎么「思考」的。
大模型的核心是 Transformer 架构，而 Transformer 的灵魂是注意力机制（Attention）。简单来说，模型在生成每个 token 时，会「注意」到输入中的所有相关信息（上下文窗口内），然后综合这些信息做出决策。
这里有个关键点：大模型的每次决策都是基于它能「看到"」的全部上下文。
这就像你在做一道数学题。如果题目是"小明有 5 个苹果，给了小红 2 个"，你要回答"小明还剩几个"，你必须同时看到"5 个"和"给了 2 个"这两个信息。如果你只看到其中一部分，就无法得出正确答案。
大模型也是如此。它的智能来源于对上下文的完整理解（其智能还来源于预训练时学到的知识，模式识别、知识迁移等能力）。一旦上下文缺失或者矛盾，模型的输出质量就会急剧下降。
1.2 多个模型协作的挑战
当多个大模型（Agent）需要协作时，如何保证它们都拥有必要的上下文？
假设我们有三个 Agent 并行进行开发部署工作：
- Agent A：负责前端开发
- Agent B：负责后端开发
- Agent C：负责部署运维
理想情况下，它们应该像一个经验丰富的全栈工程师一样，时刻知道其他部分的设计决策。但实际上，每个 Agent 都是独立的大模型实例，它们各自维护着自己的上下文。
这就产生了第一个问题：上下文分裂。
Agent A 决定使用 React，Agent B 决定用 Python Flask，这本来没问题。但当 Agent A 后续生成代码时假设后端返回 GraphQL，而 Agent B 实际提供的是 REST API，最终代码就无法正常工作。
并且大模型有个特性叫「自回归生成」------每个新的输出都依赖于之前的所有输出。这意味着一旦某个 Agent 做出了错误假设，这个错误会在后续生成中不断放大。
2 主从架构的设计哲学
2.1 为什么主从架构有效
主从架构的核心思想很简单：一个指挥，多个执行。一个主 Agent 掌控全局，其他从 Agent 提供子领域专业化的支持。
这个设计直接解决了上下文分裂的问题。主 Agent 始终维护着完整的任务上下文，它知道：
- 整体目标是什么
- 已经做了哪些决策
- 各个部分如何配合
- 当前的优先级是什么
从 Agent 则像是主 Agent 的「外脑」------当主 Agent 需要专门知识时，会调用相应的从 Agent，但最终的决策和执行都由主 Agent 完成。
在我们做具体实现的时候，每个不同的从 Agent 都有自己的角色和系统 Prompt。
2.2 Claude Code 的实践印证
Claude Code 的设计诠释了主从的理念。根据 Github 上逆向工程的分析，它的架构中：
nO 主循环引擎（主 Agent）负责：
- 维护完整的代码上下文
- 协调所有子任务
- 做最终决策
- 生成实际代码
I2A 子任务代理（从 Agent）负责：
- 回答特定问题
- 提供专业建议
- 探索可能的解决方案
Claude Code 刻意避免了子 Agent 的并行修改。当需要调查多个方向时，主 Agent 会有限范围内并行地咨询不同的子 Agent，确保每个决策都基于最新的完整上下文。
这种设计看起来「低效」，但实际上避免了大量的错误和重做，总体效率反而更高。
2.3 生物学的启发
并且，主从架构在生物界也是有比较多例子的。
人脑就是一个典型的例子。前额叶皮质充当「主 Agent」，负责高级决策和规划。而各个专门脑区（视觉皮层、听觉皮层、运动皮层等）就像「从 Agent」，处理特定类型的信息。
所有的感官输入最终都会汇聚到前额叶皮质，由它整合信息并做出决策。即使是反射动作，大脑也会在事后「知晓」并可能调整后续行为。
这种中心化的架构经过了数亿年的进化验证。
3 主从架构的技术实现
3.1 上下文管理
实现主从架构，最核心的是上下文管理。主 Agent 需要：
1. 维护完整但精简的上下文
并不是所有信息都同等重要。主 Agent 需要智能地压缩和总结历史信息。Claude Code 使用了一个策略：
当 token 使用量达到阈值的 92% 时，触发压缩机制。关键决策被保留，而从 Agent 的中间探索过程被压缩或丢弃。这样既保持了决策的连贯性，又避免了上下文爆炸。
2. 构建结构化的决策记录
不要只是简单地拼接所有的对话历史。需要结构化地记录：
- 任务目标和约束
- 已做出的关键决策
- 各决策之间的依赖关系
- 待解决的问题队列
3. 动态调整上下文窗口
根据任务的复杂度和当前阶段，动态调整传递给从 Agent 的上下文量。初期探索阶段可以更开放，后期执行阶段需要更精确。
3.2 Agent 的设计原则
Agent 不是越智能越好，而是要专注 和可控：
1. 明确的能力边界
每个从 Agent 应该有清晰定义的能力范围。比如：
- 代码审查 Agent：只负责发现潜在问题
- 重构 Agent：只负责改进代码结构
- 测试 Agent：只负责生成测试用例
2. 标准化的输入输出
从 Agent 的接口要标准化，这样主 Agent 可以用统一的方式调用它们。输出格式也要规范，便于主 Agent 解析和整合。
3. 无状态设计
从 Agent 最好是无状态的，每次调用都是独立的。这样可以避免状态管理的复杂性，也便于并行化（当任务确实独立时）。
3.3 协调机制的关键点
主 Agent 的协调能力决定了整个系统的表现：
1. 任务分解策略
并不是所有任务都要分解。主 Agent 需要学会判断：
- 简单任务直接处理
- 复杂任务分解但保持上下文
- 探索性任务可以并行但结果需要串行整合
2. 冲突检测与解决
即使在主从架构下，从 Agent 的建议也可能相互矛盾。主 Agent 需要：
- 检测潜在的冲突
- 评估不同方案的优劣
- 做出最终决策并保持一致性
3. 优雅降级
当从 Agent 失败或不可用时，主 Agent 应该能够：
- 尝试从其它从 Agent 获取
- 降级到自己处理
- 调整任务策略
4 主从架构的优势与局限
4.1 主从架构的核心优势
1. 全局一致性保证 主 Agent 作为唯一的决策中心，天然保证了架构决策的一致性。不只是技术栈的选择（比如统一使用 REST 还是 GraphQL），更重要的是接口约定、错误处理策略、命名规范等细节都能保持统一。这种一致性在复杂项目中价值巨大。
2. 清晰的决策链路 每个决策都有明确的来源和依据。你可以在主 Agent 的对话历史中追踪每个架构决定是如何做出的，为什么选择某个方案。这种可追溯性在调试问题或向他人解释系统设计时非常有价值。
3. 优雅的错误处理 主 Agent 掌握全局状态，当某个子任务失败时，它可以准确判断影响范围并制定恢复策略。比如，如果数据库设计出错，主 Agent 知道哪些 API 设计需要相应调整。而在去中心化系统中，这种级联影响很难追踪和修复。
4. 上下文利用最大化 看似串行的决策流程，实际上优化了整体效率：
- 避免了重复劳动（多个 Agent 不会各自生成相似的代码）
- 减少了协调开销（不需要 Agent 间的大量通信）
- 上下文复用充分（主 Agent 的决策历史可以直接传递给从 Agent）
在 Claude Code 的实践中，这种设计让系统能在有限的 token 预算内完成相当复杂的编程任务。
4.2 主从架构的局限性
1. 主 Agent 成为性能瓶颈 所有决策都要经过主 Agent，当需要并行处理多个复杂子任务时，主 Agent 的串行决策会限制整体效率。就像一个项目经理同时管理太多团队，协调成本会急剧上升。
2. 对主 Agent 能力的高度依赖 系统的智能上限取决于主 Agent 的能力。如果主 Agent 对某个领域理解不深，即使有专业的从 Agent，整体表现也会受限。这就像一个不懂技术的经理，很难充分发挥技术团队的潜力。
3. 缺乏真正的协作智能 主从架构本质上是"分解-执行-组合"的模式，缺少 Agent 之间的平等协商和创造性互动。在需要头脑风暴或多视角探索的任务中，这种层级结构可能限制了解决方案的多样性。
4. 任务分解的粒度难题 主 Agent 需要准确判断任务分解的粒度。分得太细，协调成本高；分得太粗，从 Agent 可能无法胜任。而且随着任务复杂度增加，找到合适的分解方式越来越难。
4.3 适用场景分析
主从架构特别适合：
1. 工程化任务
- 代码生成
- 系统设计
- 文档编写
这些任务需要高度的一致性和结构化。
2. 有明确目标的任务
- 问题诊断
- 数据分析
- 流程自动化
目标明确时，中心化协调更高效。
3. 需要可控性的场景
- 金融交易
- 医疗诊断
- 法律咨询
这些领域不能接受不可预测的行为。
不太适合：
1. 创意生成
- 头脑风暴
- 艺术创作
- 探索性研究
2. 大规模并行处理
- 日志分析
- 图像批处理
- 分布式爬虫
3. 对等协作
- 多人游戏 AI
- 群体仿真
- 去中心化系统
5 小结
随着大模型能力的提升，主从架构也在演进：
- 更长的上下文窗口：GPT-4 已经支持 128K 的上下文，Claude 3 甚至到了 200K。这意味着主 Agent 可以维护更完整的历史，减少信息损失。
- 更好的指令跟随：新一代模型在指令跟随上有显著提升，从 Agent 可以更准确地理解和执行主 Agent 的指令。
- 原生的工具调用：模型开始原生支持函数调用，这让主从 Agent 之间的接口更加标准化和可靠。
如果你要实现一个主从架构的 Multi-Agent 系统，以下是一些建议：
1. 设计清晰的 Agent 角色：不要让从 Agent 职责过于宽泛。每个从 Agent 应该像 Unix 工具一样------做一件事，并做好。
2. 实现鲁棒的错误处理
从 Agent 失败是常态，不是异常。主 Agent 需要：
- 超时机制
- 重试策略
- 降级方案
- 错误隔离
3. 优化上下文传递：控制上下文的边界，并不是所有上下文都需要传递给给到 Agent。根据任务类型，精心设计上下文的内容和格式。
4. 监控和可观测性：记录所有的决策点和 Agent 交互，后面调试和优化用得上。
Multi-Agent 的主从架构，本质上是在解决一个古老的问题：如何组织多个智能体高效地完成复杂任务。
从生物进化到人类社会，从计算机架构到分布式系统，我们一次次地发现：在需要一致性和可控性的场景下，某种形式的中心化协调是必要的。
大模型的出现并没有改变这个规律。相反，由于大模型对上下文的强依赖，主从架构变得更加重要。
随着大模型能力的提升和 Agent 技术的成熟，我们会看到更多创新的架构出现。但无论如何演进，那些基本的原则------上下文一致性、决策可控性、错误可恢复性------都是我们在实践中需要谨慎考虑的。
以上。