AI 系统的演变已经达到了一个有趣的转折点，单代理方法正在达到其极限。进入多代理系统——多个 AI 代理协作解决超出单个代理能力的复杂问题的架构。这篇文章探讨了构建生产就绪多代理研究系统的技术原则、架构决策和来之不易的经验教训。
什么是多代理研究系统？
多代理研究系统是部署多个专业代理并行工作以调查复杂研究问题的 AI 架构，每个代理处理特定方面，如信息收集、综合、引用验证和分析。与受限于一个上下文窗口和一个推理路径的单代理方法不同，多代理系统通过跨可以协作、协调和组合其发现的专业代理分布工作来实现卓越的研究结果 [来源：Anthropic Research: Multi-Agent Orchestration Patterns, 2025]。
多代理架构的案例
研究任务体现了使它们成为多代理系统理想候选者的复杂性完美风暴。与确定性工作流不同，研究涉及：
- 不可预测的探索路径，下一步取决于当前发现
- 跨多个源和领域的并行信息收集
- 基于中间发现的动态策略适应
- 经常超出单代理容量的上下文要求
基本洞察是研究反映了人类协作调查。就像人类研究团队划分工作、追求并行轨道和综合发现一样，多代理系统可以利用这种自然分解。
我们的内部评估证明了这种方法的力量：使用 Claude Opus 4 作为编排器与 Claude Sonnet 4 子代理的多代理系统在研究任务上比单代理 Claude Opus 4 实现了 90.2% 更好的性能。这种改进源于解释 95% 性能方差的三个关键因素：
- Token 预算利用（80% 的方差）
- 工具调用频率
- 模型选择
该架构通过跨具有单独上下文窗口的代理分布工作来有效扩展 token 使用，实现单代理无法实现的并行推理。
架构模式和设计决策
编排器 - 工作者模式
核心架构遵循编排器 - 工作者模式，其中主导代理协调研究过程，同时委托给专业子代理。这种模式提供几个优势：
- 关注点分离：每个子代理专注于研究的特定方面
- 并行执行：多个子代理可以同时工作
- 上下文隔离：每个代理维护自己的上下文窗口
- 故障隔离：一个子代理的问题不会级联到其他代理
动态 vs 静态检索
传统 RAG 系统使用静态检索——获取与输入查询相似的块。多代理研究系统采用动态检索：
- 基于中间发现适应搜索策略
- 基于结果质量迭代细化查询
- 探索调查期间出现的横向连接
- 跨多个搜索迭代综合信息
处理管道
系统遵循结构化管道：
- 查询分析：主导代理分析用户查询并制定初始策略
- 子代理生成：主导代理创建具有特定目标的专业子代理
- 并行搜索：子代理使用不同工具和策略执行搜索
- 综合：主导代理整合发现并确定是否需要额外研究
- 引用处理：专用引用代理确保适当的源归属
- 结果交付：带有引用的最终研究结果返回给用户
多代理协调的提示工程
多代理系统引入了需要复杂提示工程的协调复杂性。关键原则包括：
代理心智模型
理解代理如何解释和执行提示至关重要。我们使用生产系统中的确切提示和工具构建了模拟，允许我们逐步观察代理行为。这揭示了失败模式，如：
- 代理在已经获得足够结果时继续工作
- 过于冗长的搜索查询降低了有效性
- 特定任务的工具选择不正确
委托策略
编排器必须向子代理提供清晰、详细的指令，包括：
- 清晰目标：查找什么具体信息
- 输出格式：如何构建和呈现已发现
- 工具指导：使用哪些工具以及何时使用
- 任务边界：不调查什么以避免重叠
像”研究半导体短缺”这样模糊的指令导致重复工作和不一致的调查。具有清晰劳动分工的具体指令被证明是必不可少的。
努力程度扩展启发式
代理难以判断适当的努力程度，所以我们嵌入了明确的扩展规则：
- 简单事实查找：1 个代理，3-10 次工具调用
- 直接比较：2-4 个子代理，每个 10-15 次调用
- 复杂研究：10+ 个子代理，具有清晰划分的职责
工具接口设计
代理 - 工具接口与人机接口一样关键。有效的工具设计需要：
- 不同的目的：每个工具应该有清晰、独特的功能
- 质量描述：工具需要准确、全面的文档
- 使用启发式：关于何时以及如何使用每个工具的明确指导
- 错误处理：工具失败时的优雅降级
我们发现 Claude 4 模型擅长改进工具描述——当给定有缺陷的工具和失败示例时，它们可以诊断问题并提出改进建议，导致任务完成速度提高 40%。
搜索策略模式
有效的搜索策略反映了专家人类研究：
- 从广泛开始，然后缩小：从简短、一般的查询开始，然后深入具体细节
- 评估景观：在承诺特定方向之前评估可用信息
- 渐进细化：使用结果告知后续搜索
思维过程指导
扩展思维模式作为代理的可控草稿本：
- 主导代理使用思维来规划方法、评估工具和定义子代理角色
- 子代理使用交错思维来评估结果质量、识别差距和细化查询
- 所有代理受益于提高指令遵循的显式推理链
多代理系统的评估策略
评估多代理系统提出了独特挑战，因为代理可能采取不同的有效路径来达到相同的目标。当”正确”步骤不是预先确定时，传统的逐步评估会崩溃。
灵活评估方法
专注于规定性步骤检查而不是：
- 基于结果的评估：系统是否实现了预期目标？
- 过程合理性：鉴于上下文，采取的步骤是否合理？
- 资源效率：系统是否使用了适当的努力程度？
小样本快速迭代
在开发早期，变化有巨大影响。效应大小足够大（成功率提高 30% 到 80%），20 个查询的小型测试集可以清楚显示变化的影响。不要等待大型评估套件——立即开始用代表性示例测试。
LLM-as-Judge 评估
对于自由形式的研究输出，LLM 评委在多个标准上提供可扩展评估：
- 事实准确性：声明是否与源匹配？
- 引用准确性：引用的源是否支持声明？
- 完整性：是否涵盖了所有请求的方面？
- 源质量：是否使用了权威源？
- 工具效率：是否正确使用了正确的工具？
单个 LLM 调用输出 0.0-1.0 分数被证明比多个专业评委更一致。
边缘情况的人工评估
人工测试对于捕获以下内容仍然至关重要：
- 不寻常查询上的幻觉答案
- 自动化测试中未捕获的系统故障
- 源选择中的微妙偏见
- 代理交互产生的新兴行为
人工测试人员识别了我们早期代理对 SEO 优化的内容农场的偏见，而不是权威源，导致改进的源质量启发式。
生产工程挑战
从原型到生产引入了多代理系统独有的重大工程挑战。
有状态执行和错误处理
多代理系统在长时间运行的过程中维护状态，使错误处理至关重要：
- 持久执行：系统必须优雅地处理故障而不丢失进度
- 智能恢复：当工具失败时使用模型智能适应
- 检查点系统：能够从故障点恢复而不是完全重新启动
- 重试逻辑：在自适应智能旁边实施确定性保护
调试和可观察性
非确定性代理行为使调试具有挑战性：
- 完整生产跟踪：跟踪代理决策和工具使用
- 模式监控：观察代理决策模式和交互结构
- 隐私保护可观察性：在不访问对话内容的情况下监控系统行为
- 根本原因分析：区分系统性问题和边缘情况
部署协调
有状态多代理系统需要仔细的部署策略：
- 彩虹部署：逐渐将流量从旧版本转移到新版本
- 状态保留：确保运行中的代理不被更新中断
- 版本兼容性：为进行中的研究维护向后兼容性
并行化瓶颈
当前同步执行创建限制：
- 顺序协调：主导代理等待子代理完成
- 有限的引导：无法在过程中调整子代理方向
- 阻塞操作：单个慢子代理阻塞整个系统
未来异步执行可以实现额外的并行化，但在结果协调和状态一致性方面引入了复杂性。
性能特征和权衡
多代理系统伴随着显著的性能权衡：
Token 使用扩展
- 单代理：基线 token 使用
- 代理系统：比聊天交互多约 4 倍 tokens
- 多代理系统：比聊天交互多约 15 倍 tokens
这种扩展需要仔细考虑经济可行性和任务价值。
速度改进
尽管 token 使用更高，但并行化提供了巨大的速度改进：
- 并行子代理创建：同时生成 3-5 个子代理
- 并行工具使用：每个子代理同时使用 3+ 个工具
- 时间减少：复杂查询的完成时间减少高达 90%
最佳用例
多代理系统擅长：
- 高价值任务，其中性能提高证明成本合理
- 可并行化的工作，具有独立子任务
- 跨多个源的信息综合
- 需要专门接口的复杂工具编排
它们不太适合：
- 共享上下文要求，所有代理都需要相同信息
- 高度依赖的任务，具有紧密协调要求
- 需要即时代理间通信的实时协作工作
未来方向和新兴模式
随着多代理系统的成熟，几种模式正在出现：
基于工件的通信
直接将子代理输出到外部系统可以绕过协调器瓶颈：
- 文件系统输出：子代理将工作存储到外部系统
- 轻量级引用：协调器接收指针而不是完整内容
- 专门提示：子代理针对特定输出类型优化
- 减少 token 开销：避免通过对话历史复制大输出
记忆和上下文管理
长时段对话需要复杂的记忆策略：
- 阶段摘要：在继续之前压缩已完成的工作
- 外部记忆：在上下文窗口外存储基本信息
- 新鲜上下文生成：用干净上下文创建新子代理
- 智能交接：跨上下文边界维护连续性
新兴协作模式
多代理系统发展出意想不到的交互模式：
- 隐式协调：代理在没有显式编程的情况下发展工作关系
- 自适应劳动分工：基于代理能力的动态任务分配
- 集体智能：从代理交互中出现的系统级洞察
多代理系统构建者的经验教训
基于我们的生产经验，以下是关键建议：
- 从清晰的架构模式开始：编排器 - 工作者提供坚实基础
- 大力投资提示工程：代理协调主要是提示挑战
- 尽早建立可观察性：理解代理行为对调试至关重要
- 拥抱快速迭代：小型测试集可以揭示大效应大小
- 为失败设计：多代理系统放大成功和失败
- 考虑经济权衡：token 使用随代理计数显著扩展
- 专注于高价值用例：确保任务价值证明系统复杂性
结论
多代理研究系统代表了 AI 能力的重大演变，使解决方案能够解决单代理无法处理的问题。该架构需要仔细关注协调、评估和生产工程，但对于适当的用例，结果证明了复杂性是合理的。
关键洞察是智能通过协作扩展，而不仅仅是个人能力。就像人类社会通过集体智能变得指数级更有能力一样，多代理 AI 系统可以实现个人代理无法达到的性能水平。
随着模型继续改进和协调机制成熟，我们预计多代理系统对于需要协作问题解决出现的灵活、适应性智能的复杂、开放式任务将变得越来越重要。
AI 的未来不仅在于使单个代理更聪明，还在于有效地编排它们一起工作。多代理研究系统只是这个协作智能革命的开始。
Frequently Asked Questions
Q：多代理系统变得值得的最低复杂性是什么？
基于我们的生产经验，多代理系统在以下情况下证明其开销合理：需要超过 10-15 次工具调用的任务、受益于并行信息收集的研究、需要不同专业知识的不同阶段的问题，以及上下文窗口限制将迫使单代理丢弃重要信息的任务。对于简单查询或直接事实查找，单代理仍然更有效。交叉点因领域而异，但我们通常在单代理需要超过 2-3 分钟的任务上看到多代理优势出现。
Q：与单代理相比，多代理系统实际成本是多少？
Token 使用显著扩展：单代理约 1 倍，具有编排开销的代理系统约 4 倍，多代理系统约 15 倍，与基线聊天交互相比。然而，更有意义的指标是每个成功结果的成本。多代理系统在 5 分钟内完成任务，而单代理需要 30 分钟，可能通过显著更快的时间价值证明 3 倍更高的 token 成本合理。基于任务价值计算 ROI，而不仅仅是 token 消耗。
Q：我们将面临的最大生产挑战是什么？
四个最困难的挑战是：(1) 有状态执行——当多步骤过程运行几分钟时优雅地处理故障而不丢失进度。(2) 调试——理解当多个代理以非确定性方式交互时系统为什么做出特定决策。(3) 部署——更新系统而不中断进行中的长期研究任务。(4) 评估——当解决方案的有效路径变化很大时评估质量。每个都需要特定技术解决方案而不是一般方法。
Q：我们如何公平评估多代理系统性能？
使用基于结果的评估而不是逐步评估。系统是否实现了其目标？鉴于上下文，采取的步骤是否合理？它是否使用了适当的资源？LLM-as-judge 方法对研究质量评估效果很好——让单独的模型评估事实准确性、引用质量、源权威性和完整性。对于开发期间的快速迭代，20 个代表性查询的小型测试集可以揭示提示改进的 30-80% 效应大小变化。
Q：构建有效多代理系统的学习曲线是什么？
预计需要 2-3 个月才能达到生产能力。第 1 阶段（第 1-4 周）：学习模式，构建简单的编排器 - 工作者系统，理解协调的提示工程。第 2 阶段（第 5-8 周）：添加复杂评估，实施有状态执行，优化 token 使用。第 3 阶段（第 9-12 周）：根据生产反馈细化，探索高级模式如基于工件的通信。从像 LangGraph 或 CrewAI 这样的既定框架开始可以通过提供护栏和示例来加速这个过程。
Q：我们应该构建还是购买多代理编排框架？
从购买开始——使用现有框架（LangGraph、CrewAI、Antfarm）学习模式并了解你的特定要求实际上是什么。一旦你遇到框架限制或有清晰的专门需求，考虑为这些特定组件构建自定义编排，同时继续使用框架用于一般功能。“构建与购买”决策不是二元的——大多数成功团队使用结合框架优势与自定义扩展的混合方法。
Q：多代理研究系统如何与新兴的”Antfarm”模式相关联？
Antfarm 代表多代理模式成熟为编排专业代理团队的标准方法。这篇文章中的概念——编排器 - 工作者、动态检索、并行搜索、基于工件的通信——是 Antfarm 系统化的基础模式。将这篇文章视为”为什么”，Antfarm 视为”如何”——这些模式在生产框架中的具体实现。理解这里原则的团队可以更有效地采用 Antfarm 或类似系统。
About the Author
Vinci Rufus 是一位自 2022 年以来一直在构建生产 AI 系统的软件工程师，特别专注于研究和知识工作的多代理架构。他领导开发了一个每天处理数千个复杂查询的多代理研究系统，学习了当代理大规模协作时实际有效的艰难经验教训。他撰写关于来自生产经验的实用模式，而不是理论可能性。在 Twitter @areai51 或 vincirufus.com 上找到他。
最后更新：2026 年 2 月 27 日
这篇文章基于构建生产多代理研究系统的洞察。有关实施细节和示例提示，请参阅 Anthropic Cookbook。