多智能体架构决策与工程实践
为什么需要多智能体系统？
随着大语言模型能力增强，单智能体的局限性逐渐暴露。现实问题往往需要多种专业能力协作、分工互补和思维碰撞，多智能体系统在这些场景下优势明显。
单智能体 vs 多智能体架构选择
决策原点：单智能体优先
选择架构时，默认从单智能体开始。这是 Anthropic 强调的"简单优先"原则——只有当引入复杂性能够显著改善结果时，才应该考虑它。
单智能体的三类硬性瓶颈
当单智能体遇到以下瓶颈时，才考虑升级为多智能体：
- 上下文容量瓶颈 —— 单智能体的上下文窗口有限，处理海量信息（如同时分析几十个网页）时会被撑爆
- 单一路径依赖的高失败风险 —— 单智能体像侦探只能沿一条线索追查，一旦路径错误整个任务失败；多智能体可并行探索多条路径降低风险
- 效率瓶颈 —— 串行处理耗时过长，业务要求短时间完成时需要并行提速
多智能体方案的双重过滤器
即使发现瓶颈，启动评估不等于直接采用，还需通过两个过滤器：
技术可行性过滤器 —— 任务能否拆分为独立可并行的子任务？
- 适合：市场分析报告（可拆分为竞争对手研究、宏观趋势分析、用户反馈抓取）
- 不适合：代码编写（需要强共享上下文，模块间依赖高，易产生冲突）
商业价值过滤器 —— 任务价值能否支撑高昂花费？
- Anthropic 经验：多智能体架构 Token 消耗可能是普通聊天的 15 倍
- 必须评估任务创造的价值是否值得如此高的成本
决策框架
单智能体优先作为基准方案，然后通过三步评估流程判断是否需要升级：
- 评估单智能体是否存在硬性瓶颈
- 评估任务在技术上是否具备并行可行性
- 评估方案在商业上是否具备足够价值
只有当这三个条件全部满足时，我才会采用多智能体架构。因为多智能体方案不仅成本更高，对技术实现的要求以及系统的不稳定性也会相应增加。
Anthropic Research 工程实践
研究的本质是信息压缩
多智能体系统的核心价值在于通过并行化实现信息压缩。子智能体（Subagent）各自拥有独立上下文窗口，能够同时探索问题的不同维度，然后将最重要的信息浓缩返回给主研究智能体。每个子智能体提供关注点分离（ Separation of Concerns）——不同的工具、提示词和探索路径，从而减少路径依赖，实现彻底且独立的调查。
见：How we built our multi-agent research system
Token 消耗是性能的首要决定因素
Anthropic 的内部评估显示，在 BrowseComp 评测中，三个因素解释了 95% 的性能方差：Token 使用量（单独解释 80% 方差）、工具调用次数、模型选择。 这意味着多智能体架构本质上是通过分布式上下文窗口来增加并行推理能力。Claude 模型作为 Token 使用效率的乘数，升级到新版本模型的性能增益甚至超过在旧版本上翻倍 Token 预算。
代价是多智能体系统消耗 Token 极快——典型情况下，智能体交互使用约 4 倍于普通聊天的 Token，而多智能体系统使用约 15 倍。因此，多智能体系统只适用于任务价值足以支付性能溢价的高价值场景。
Orchestrator-Worker 架构设计
Claude Research 采用主从协调模式（Orchestrator-Worker Pattern）：
- Lead Agent（主智能体）：分析查询、制定策略、协调子智能体
- Subagents（子智能体）：并行执行专门的研究任务，作为智能过滤器迭代使用搜索工具收集信息
与静态检索的 RAG 不同，这种架构使用多步动态搜索，能够根据新发现自适应调整，并分析结果以生成高质量答案。主智能体将研究计划保存到 Memory 中以持久化上下文，因为当上下文超过 20 万 Token 时会被截断。
提示工程八项原则
- 像智能体一样思考——通过模拟观察智能体逐步工作，建立准确的心理模型
- 教导协调者如何委派——子智能体需要明确的目标、输出格式、工具指导和清晰的任务边界
- 根据查询复杂度调整投入——简单事实查找 1 个智能体 3-10 次调用，复杂研究可能需要 10+ 子智能体
- 工具设计与选择至关重要——工具描述质量直接影响智能体决策，糟糕的描述会将智能体引向错误路径
- 让智能体自我改进——Claude 4 模型可以成为优秀的提示工程师，甚至能重写工具描述以减少失败，使任务完成时间减少 40%
- 先广后深——搜索策略应模仿专家人类研究：先探索全景，再深入细节
- 引导思考过程——扩展思考模式（Extended Thinking）可作为可控的草稿本，用于规划方法、评估工具适配性
- 并行工具调用改变速度与性能——主智能体并行生成 3-5 个子智能体，子智能体并行使用 3+ 工具，可将研究时间缩短 90%
多智能体系统的评估策略
- 立即用小样本开始评估——早期改动影响巨大，20 个代表性查询足以发现变化影响，不必等到构建数百个测试用例才开始
- LLM-as-Judge 可扩展——使用单一 LLM 调用输出 0.0-1.0 分数和通过/失败判定，评估事实准确性、引用准确性、完整性、来源质量和工具效率
- 人工评估捕捉自动化遗漏——包括幻觉答案、系统故障、微妙来源选择偏见（如早期智能体倾向选择 SEO 优化的内容农场而非权威学术 PDF）
生产可靠性的工程挑战
- 状态持久化与错误恢复——智能体可能运行很长时间，需要 durable execution 和从错误点恢复的能力，而非从头重启
- 调试需要新方法——智能体决策是动态的、非确定性的，需要完整的生产追踪（Tracing）来诊断失败原因
- 彩虹部署（Rainbow Deployment）——避免更新代码破坏运行中的智能体，通过逐渐将流量从旧版本转移到新版本
- 同步执行的瓶颈——当前主智能体同步等待子智能体完成，异步执行将带来额外并行性但增加协调复杂度
- 长对话的上下文管理——当对话跨越数百轮时，智能体需要总结已完成的工作阶段，将关键信息存储到外部记忆，并在接近上下文限制时生成具有干净上下文的新子智能体
Cognition 上下文工程原则
上下文工程（Context Engineering）是 Agent 构建的核心
"Prompt engineering" 是为聊天机器人编写理想格式的任务描述，而 "Context engineering" 是更高级的概念——在动态系统中自动完成这一过程。这是构建生产级 AI Agent 工程师的首要工作。 即使是最聪明的模型，没有上下文也无法有效工作。
多智能体架构的根本缺陷
典型的多智能体架构（主任务拆分为子任务，由子智能体并行执行，最后合并结果）非常脆弱。关键失败点在于：
- 上下文丢失——子智能体缺乏完整上下文，容易误解任务。例如"构建 Flappy Bird 克隆"被拆分为"游戏背景"和"可移动的小鸟"，但子智能体 1 可能误解为 Super Mario 风格
- 隐式决策冲突——即使子智能体都收到完整任务描述，它们基于未被预先规定的冲突假设做出决策，导致结果不一致（如视觉风格完全不同）
Cognition 认为这些原则如此关键，以至于默认应排除任何不遵守它们的 Agent 架构。
单线程线性 Agent 是默认选择
遵循上下文工程原则的最简单方式是使用单线程线性 Agent——上下文连续传递，没有并行子任务带来的信息丢失风险。这种架构能应对大多数场景，Claude Code 就是典型例子：虽然会生成子任务，但从不与主 Agent 并行执行， 且子 Agent 通常只负责回答问题而非编写代码。
长上下文任务的压缩策略
对于真正长时间运行的任务，可引入专门的 LLM 作为上下文压缩器——将行动历史和对话压缩为关键细节、事件和决策。这很难做对，需要投入精力识别关键信息，甚至可能需要针对领域微调小型模型。收益是 Agent 能在更长上下文中保持有效， 但终究会达到极限。
2025 年多智能体协作的现实局限
让多个决策者"相互对话"达成共识看似理想，但 2025 年的 Agent 尚不具备这种能力。人类能高效传递最重要的知识，但这种效率需要非平凡的智能。目前运行多 Agent 协作只会产生脆弱系统——决策过于分散， 上下文无法在 Agent 间充分共享。只有当单线程 Agent 能更好地与人类沟通时，跨 Agent 上下文传递问题才会迎刃而解。
Claude 官方多智能体决策指南
多智能体系统的三种适用场景
文章明确指出，只有在以下三种情况下，多智能体系统才能持续优于单智能体：
- 上下文保护（Context Protection）——当子任务产生大量上下文（超过 1000 Token）但大部分信息与主任务无关时，子智能体提供隔离，每个在专注于特定任务的干净上下文中运行
- 并行化（Parallelization）——并行运行多个智能体允许探索比单个智能体更大的搜索空间，特别适用于搜索和研究任务。主要收益是彻底性（thoroughness），而非速度
- 专业化（Specialization）——不同任务有时需要不同的工具集、系统提示词或专业领域知识。工具数量过多（20+）、跨领域混淆、添加新工具降低现有任务性能时，考虑专业化
见：Building multi-agent systems: When and how to use them
单智能体优先与 Token 开销
多智能体系统引入开销：典型情况下比单智能体方法多使用 3-10 倍 Token（早期 Anthropic 工程博客提到：智能体交互使用约 4 倍于普通聊天的 Token，而多智能体系统使用约 15 倍）。开销来源于：
- 跨智能体复制上下文
- 智能体间的协调消息
- 交接时总结结果
关键洞察：采用以上下文为中心的视角而非以问题为中心的视角进行分解。有效边界包括独立研究路径、具有清晰接口的独立组件、黑盒验证；问题边界包括同一工作的顺序阶段、紧耦合组件、需要共享状态的工作。
验证子智能体模式
一种始终有效的多智能体模式：专门负责测试或验证主智能体工作的独立智能体。这之所以有效，是因为验证需要最少的上下文转移——验证者可以对系统进行黑盒测试，无需了解构建过程的完整历史。
最显著的失败模式：未进行彻底测试就将输出标记为通过。缓解策略包括具体标准、全面检查、负面测试、明确指令。
工具搜索工具（Tool Search Tool）
在考虑多智能体之前，可尝试的缓解措施：让 Claude 动态发现工具而非预先加载所有定义，可将 Token 使用量减少多达 85%，同时提高工具选择准确性。
未来发展趋势
融合趋势
框架间已出现融合苗头：
- AutoGen 引入更结构化的控制机制
- DeepAgents 尝试变得更对话化、更灵活
- CrewAI 不断增强处理复杂任务的能力
可能的演进方向
- 混合架构：既可对话驱动，也可计划驱动
- 自适应协作：根据任务不同自动切换协作方式
- 跨框架互操作：不同框架的智能体能无缝协作
Harness 随模型能力演进的剥离原则
新模型发布时应重新审视 Harness 设计，主动剥离不再必要的脚手架。Opus 4.6 出现后，Anthropic 团队移除了 Sprint 构造——模型已能原生处理任务而无需此类分解。
评估器并非固定存在的"是/否"决策点，其价值取决于任务是否超出当前模型的可靠 solo 能力。当模型能独立完成时，Harness 的复杂度成为纯粹开销。有趣的 Harness 组合空间不会随模型进步而缩小，而是转移——旧约束消失， 新可能性涌现。
见：Harness design for long-running application development：Anthropic Labs 团队关于长时应用开发的 Harness 设计实践