译者编注: 这篇文章最值得看的地方，不是它在讲“怎么把多个 AI 组织起来”，而是它先把一个更关键的问题摆在前面：你到底有没有必要上多智能体。很多团队会本能地把系统做复杂，但这篇文章提醒我们，只有当单智能体真的碰到边界时，多智能体的额外成本才是值得付出的。
正文开始
发布时间：2026年1月23日
多智能体系统是一种架构，其中多个 LLM 实例以独立的对话上下文运行，并通过代码进行协调。存在多种协调模式（智能体群、基于能力的系统以及消息总线架构），但本文聚焦于编排器-子智能体模式：一种层次化模型，其中领导智能体为特定的子任务生成并管理专门的子智能体。这种模式提供了一个直接的协调模型，对于刚接触多智能体系统的团队来说是一个很好的起点。我们将在下一篇文章中详细探讨其他模式。
如今，多智能体系统常常被应用于单个智能体本可以表现更好的场景中，不过随着模型的改进，这种权衡也在不断变化。在 Anthropic，我们看到团队花费数月时间构建复杂的多智能体架构，结果却发现对单个智能体进行更好的提示工程就能达到同等效果。
在构建多智能体系统并与在生产环境中部署它们的团队合作之后，我们确定了三种情况下多智能体始终优于单个智能体：当上下文污染降低性能时，当任务可以并行运行时，以及当专业化改进工具选择或任务聚焦时。在这些情况之外，协调成本通常超过收益。
在本文中，我们将分享如何识别单个智能体的局限性，确定多智能体系统擅长的三种场景，以及避免常见的实现错误。
从单个智能体开始的理由
一个设计良好、配备适当工具的单个智能体所能完成的任务远超许多开发者的预期。
多智能体系统会引入开销。每一个额外的智能体都代表着另一个潜在的故障点、另一套需要维护的提示词，以及另一种意外行为的来源。
我们观察到团队构建了复杂的多智能体系统，设有专门的规划、执行、审查和迭代智能体，结果却发现每次交接都会丢失上下文，并且花费在协调上的 token 比执行上的还多。在我们的测试中，对于同等任务，多智能体实现通常比单智能体方法多使用 3 到 10 倍的 token。这种开销源于跨智能体复制上下文、智能体之间的协调消息，以及为交接而总结结果。
多智能体系统的决策框架
多智能体架构在解决单个智能体无法克服的特定约束时提供价值。这意味着多智能体架构应保留用于那些能带来明确好处、证明额外成本合理的情况。
以下模式代表了我们在其中持续观察到这种投资获得正回报的案例。
上下文保护
大型语言模型的上下文窗口是有限的，随着上下文的增长，响应质量可能会下降。当一个智能体的上下文累积了来自某个子任务的信息，而这些信息与后续子任务无关时，就会发生上下文污染。子智能体提供了隔离性，每个子智能体在其自己的、聚焦于特定任务的干净上下文中运行。
考虑一个客户支持智能体，它需要在诊断技术问题的同时检索订单历史。如果每次订单查找都向上下文中添加数千个 token，智能体推理技术问题的能力就会下降。
单智能体方法：
# 单智能体将所有内容累积在上下文中
conversation_history = [
{"role": "user", "content": "我的订单 #12345 无法使用"},
{"role": "assistant", "content": "让我检查您的订单..."},
# 工具结果添加了 2000+ token 的订单历史
{"role": "user", "content": "...（订单详情、过往购买、配送信息）..."},
{"role": "assistant", "content": "现在让我诊断技术问题..."},
# 上下文中现在充斥着智能体不需要的订单详情
]
智能体必须在上下文中保留 2000+ token 的无关订单历史的同时推理技术问题，这分散了注意力并降低了响应质量。
多智能体方法：
from anthropic import Anthropic
client = Anthropic()
class OrderLookupAgent:
def lookup_order(self, order_id: str) -> dict:
# 具有自己上下文的独立智能体
messages = [
{"role": "user", "content": f"获取订单 {order_id} 的基本信息"}
]
response = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=1024,
messages=messages,
tools=[get_order_details_tool]
)
# 仅返回必要信息
return extract_summary(response)
class SupportAgent:
def handle_issue(self, user_message: str):
if needs_order_info(user_message):
order_id = extract_order_id(user_message)
# 只获取需要的信息，而不是完整历史
order_summary = OrderLookupAgent().lookup_order(order_id)
# 注入紧凑的摘要，而不是完整上下文
context = f"订单 {order_id}: {order_summary['status']}, 购买于 {order_summary['date']}"
# 主智能体上下文保持干净
messages = [
{"role": "user", "content": f"{context}\n\n用户问题: {user_message}"}
]
response = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=2048,
messages=messages
)
return response
订单查找智能体处理完整的订单历史并提取摘要。主智能体只接收它实际需要的 50-100 个 token，使上下文保持聚焦。
上下文隔离在以下情况下最有效：子任务产生高上下文量（超过 1000 个 token）但大部分信息与主任务无关；子任务定义明确，有清晰的信息提取标准；以及需要在使用前进行过滤的查找或检索操作。
并行化
并行运行多个智能体允许你探索比单个智能体所能覆盖的更大的搜索空间。这种模式已被证明对于搜索和研究任务特别有价值。
我们的研究功能使用了这种方法。一个领导智能体分析一个查询，并生成多个子智能体来并行调查不同的方面。每个子智能体独立搜索，然后返回精炼后的发现。通过允许在更大的信息空间中探索，多智能体搜索显示出比单智能体方法显著的准确性提升。
核心实现是将一个问题分解为独立的方面，并发运行子智能体，然后综合结果。
import asyncio
from anthropic import AsyncAnthropic
client = AsyncAnthropic()
async def research_topic(query: str) -> dict:
# 领导智能体将查询分解为研究方面
facets = await lead_agent.decompose_query(query)
# 生成子智能体并行研究每个方面
tasks = [
research_subagent(facet)
for facet in facets
]
results = await asyncio.gather(*tasks)
# 领导智能体综合发现
return await lead_agent.synthesize(results)
async def research_subagent(facet: str) -> dict:
"""每个子智能体都有自己的上下文窗口"""
messages = [
{"role": "user", "content": f"研究: {facet}"}
]
response = await client.messages.create(
model="claude-sonnet-4-5",
max_tokens=4096,
messages=messages,
tools=[web_search, read_document]
)
return extract_findings(response)
这种覆盖率的提升是有代价的。对于同等任务，多智能体系统通常比单智能体方法多消耗 3 到 10 倍的 token。这是因为每个智能体都需要自己的上下文，智能体之间必须交换消息进行协调，并且在智能体之间传递结果时必须对结果进行总结。虽然与顺序运行所有工作相比，并行化有助于减少总执行时间，但由于总计算量的纯粹增加，多智能体系统通常比单智能体系统花费更长的时间。
并行化的主要好处是彻底性，而不是速度。当你需要在大信息空间中搜索或调查一个复杂问题的多个角度时，并行智能体比在其上下文限制内工作的单个智能体可以覆盖更多的领域。其代价是更高的 token 使用量，并且通常为了获得更全面的结果，总执行时间也更长。
专业化
不同的任务有时受益于不同的工具集、系统提示词或专业领域。与其为单个智能体提供数十种工具的访问权限，不如使用与它们职责相匹配的聚焦工具集的专门智能体来提高可靠性。
工具集专业化
当一个智能体可以访问太多工具时，性能会受到影响。有三个信号表明工具专业化会有所帮助：
- 数量。一个拥有太多工具（通常超过 20 个）的智能体难以选择合适的工具。
- 领域混淆。当工具跨越多个不相关的领域（数据库操作、API 调用、文件系统操作）时，智能体会混淆哪个领域适用于给定的任务。
- 性能下降。添加新工具会降低现有任务的性能，这表明智能体已经达到了其工具管理能力的极限。
系统提示词专业化
不同的任务有时需要不同的角色、约束或指令，这些在组合时可能会相互冲突。一个客户支持智能体需要有同理心和耐心；一个代码审查智能体需要精确和批判。一个合规性检查智能体需要严格的规则遵循；一个头脑风暴智能体需要创造性的灵活性。当一个智能体必须在冲突的行为模式之间切换时，将其分离成具有定制系统提示词的专门智能体可以产生更一致的结果。
领域专业知识专业化
某些任务受益于深度领域上下文，而这些上下文会使通才智能体不堪重负。一个法律分析智能体可能需要关于判例法和监管框架的大量上下文。一个医学研究智能体可能需要关于临床试验方法的专业知识。与其将所有领域上下文加载到单个智能体中，不如让专门智能体携带与其特定职责相关的聚焦专业知识。
示例：多平台集成。 考虑一个集成系统，其中智能体需要跨 CRM、营销自动化和消息平台工作。每个平台有 10-15 个相关的 API 端点。一个拥有 40 多个工具的单个智能体常常难以正确选择，混淆跨平台的类似操作。将其拆分为具有聚焦工具集和定制提示词的专门智能体可以解决选择错误的问题。
from anthropic import Anthropic
client = Anthropic()
# 具有聚焦工具集和定制提示词的专门智能体
class CRMAgent:
"""处理客户关系管理操作"""
system_prompt = """你是一位 CRM 专家。你管理联系人、
机会和客户记录。在更新前始终验证记录所有权，并在相关记录间维护数据完整性。"""
tools = [
crm_get_contacts,
crm_create_opportunity,
# 8-10 个 CRM 特定工具
]
class MarketingAgent:
"""处理营销自动化操作"""
system_prompt = """你是一位营销自动化专家。你管理
活动、潜在客户评分和邮件序列。优先考虑数据卫生并尊重联系人的偏好。"""
tools = [
marketing_get_campaigns,
marketing_create_lead,
# 8-10 个营销特定工具
]
class OrchestratorAgent:
"""将请求路由到专门的智能体"""
def execute(self, user_request: str):
response = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=1024,
system="""你协调平台集成。将请求路由给合适的专家：
- CRM：联系人记录、机会、账户、销售管道
- 营销：活动、潜在客户培育、邮件序列、评分
- 消息：通知、警报、团队沟通""",
messages=[
{"role": "user", "content": user_request}
],
tools=[delegate_to_crm, delegate_to_marketing, delegate_to_messaging]
)
return response
这种模式反映了有效的专业协作：拥有与其角色匹配的工具的专家比试图在所有领域保持专业知识的通才协作得更有效。然而，专业化引入了路由复杂性。编排器必须正确分类请求并委派给正确的智能体，错误路由会导致结果不佳。维护多个专门智能体也增加了提示词维护的开销。专业化在领域清晰可分离且路由决策明确无误时效果最佳。
超越单智能体架构
除了通用框架之外，某些具体的信号表明单智能体模式已被超越：
接近上下文限制。 如果一个智能体经常使用大量的上下文，并且性能正在下降，那么上下文压力可能是瓶颈。请注意，上下文管理的最新进展（例如压缩）正在减少这一限制，使单个智能体能够在更长的范围内保持有效记忆。
管理许多工具。 当一个智能体拥有 15-20 多个工具时，模型会花费大量的上下文和注意力来理解其选项。在采用多智能体架构之前，可以考虑使用工具搜索工具，它让 Claude 可以按需动态发现工具，而不是预先加载所有定义。这可以将 token 使用量减少高达 85%，同时提高工具选择的准确性。
可并行化的子任务。 当任务自然分解为独立的部分（跨多个来源的研究、多个组件的测试）时，并行的子智能体可以提供显著的加速。
这些阈值将随着模型的改进而变化。当前的限制代表的是实用指南，而不是根本性约束。
以上下文为中心的分解
当采用多智能体架构时，最重要的设计决策是如何在智能体之间划分工作。我们观察到团队经常错误地做出这一选择，导致协调开销抵消了多智能体设计的好处。
关键的见解是在分解工作时采用以上下文为中心的视图，而不是以问题为中心的视图。
以问题为中心的分解（通常适得其反）。 按工作类型划分（一个智能体编写功能，另一个编写测试，第三个审查代码）会产生持续的协调开销。每次交接都会丢失上下文。编写测试的智能体缺乏对为什么做出某些实现决策的了解，代码审查者缺乏探索和迭代的上下文。
以上下文为中心的分解（通常有效）。 按上下文边界划分意味着处理一个功能的智能体也应该处理它的测试，因为它已经具备了必要的上下文。只有当上下文可以被真正隔离时，才应该拆分工作。
这一原则源于对多智能体系统失败模式的观察。当智能体按问题类型拆分时，它们会陷入“传话游戏”，每次交接都会降低信息保真度。在一个按软件开发角色（规划者、实现者、测试者、审查者）专门化的智能体实验中，子智能体花费在协调上的 token 比实际工作还要多。
有效的分解边界包括：
- 独立的研究路径。 调查“亚洲市场趋势”与“欧洲市场趋势”可以并行进行，无需共享上下文。
- 具有清晰接口的独立组件。 在定义良好的 API 契约下，前端和后端工作可以并行进行。
- 黑盒验证。 一个只需要运行测试和报告结果的验证器不需要实现上下文。
有问题的分解边界包括：
- 同一工作的顺序阶段。 同一功能的规划、实现和测试共享太多上下文。
- 紧密耦合的组件。 需要不断来回沟通的组件应属于同一个智能体。
- 需要共享状态的工作。 需要频繁同步理解的智能体应保持在一起。
验证子智能体模式
一种跨领域始终有效的多智能体模式是验证子智能体。这是一个专门的智能体，其唯一职责是测试或验证主智能体的工作。
值得注意的是，能力更强的编排器模型（如 Claude Opus 4.5）越来越能够直接评估子智能体的工作，而无需单独的验证步骤。然而，当使用能力较弱的编排器时，当验证需要专用工具时，或者当你想在工作流中强制执行显式的验证检查点时，验证子智能体仍然很有价值。
验证子智能体之所以成功，是因为它们绕过了传话游戏问题。验证本质上需要最少的上下文传递，因此验证器可以对系统进行黑盒测试，而无需了解其构建的完整历史。
实现
主智能体完成一个工作单元。在此之前，它会生成一个验证子智能体，并附带要验证的工件、清晰的成功标准以及执行验证的工具。
验证器不需要理解工件为何以某种方式构建。它只需要确定工件是否满足指定的标准。
from anthropic import Anthropic
client = Anthropic()
class CodingAgent:
def implement_feature(self, requirements: str) -> dict:
"""主智能体实现功能"""
messages = [
{"role": "user", "content": f"实现: {requirements}"}
]
response = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=4096,
messages=messages,
tools=[read_file, write_file, list_directory]
)
return {
"code": response.content,
"files_changed": extract_files(response)
}
class VerificationAgent:
def verify_implementation(self, requirements: str, files_changed: list) -> dict:
"""独立的智能体验证工作"""
messages = [
{"role": "user", "content": f"""
需求: {requirements}
更改的文件: {files_changed}
运行测试套件并验证：
1. 所有现有测试通过
2. 新功能按预期工作
3. 没有明显的错误或安全问题
你必须在标记为通过之前运行完整的测试套件。
不要在只运行了几个测试后就标记为通过。
运行: pytest --verbose
只有在所有测试都通过且没有失败时才标记为 PASSED。
"""}
]
response = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=4096,
messages=messages,
tools=[run_tests, execute_code, read_file]
)
return {
"passed": extract_pass_fail(response),
"issues": extract_issues(response)
}
def implement_with_verification(requirements: str, max_attempts: int = 3):
for attempt in range(max_attempts):
result = CodingAgent().implement_feature(requirements)
verification = VerificationAgent().verify_implementation(
requirements,
result['files_changed']
)
if verification['passed']:
return result
requirements += f"\n\n之前的尝试失败: {verification['issues']}"
raise Exception(f"在 {max_attempts} 次尝试后仍未通过验证")
应用
验证子智能体对于以下方面是有效的：
- 质量保证。 运行测试套件、代码检查、根据模式验证输出。
- 合规性检查。 验证文档是否符合政策要求，根据规则检查输出。
- 输出验证。 在交付前确认生成的内容符合规范。
- 事实核查。 让一个独立的智能体验证生成内容中的声明或引用。
早期胜利问题
验证子智能体最显著的失败模式是在没有进行彻底测试的情况下就将输出标记为通过。验证器运行一两个测试，观察到它们通过，就宣布成功。
缓解策略包括：
- 具体标准。 指定“运行完整的测试套件并报告所有失败”，而不是“确保它工作”。
- 全面检查。 要求验证器测试多个场景和边缘情况。
- 负面测试。 指示验证器尝试应该失败的输入并确认它们确实失败。
- 明确的指令。 指令“你必须在标记为通过之前运行完整的测试套件”是至关重要的。如果没有全面验证的明确要求，验证智能体就会走捷径。
前进之路
多智能体系统很强大，但并不普遍适用。在增加多个协调智能体的复杂性之前，请确认：
- 存在多智能体能够解决的真正约束，例如上下文限制、并行化机会或专业化需求。
- 分解遵循上下文，而不是问题类型。 根据工作需要什么上下文来分组工作，而不是根据它是什么类型的工作。
- 存在清晰的验证点，子智能体可以在那里验证工作而无需完整的上下文。
我们的建议？从可行的最简单方法开始，并且只有在有证据支持时才增加复杂性。
这是关于多智能体系统的系列文章中的第一篇。有关单智能体模式的更多信息，请参阅 构建有效的智能体。有关上下文管理策略，请参阅 AI 智能体的有效上下文工程。要深入了解我们如何构建多智能体研究系统，请参阅 我们如何构建多智能体研究系统。
致谢
作者：Cara Phillips，贡献者：Paul Chen、Andy Schumeister、Brad Abrams 和 Theo Chu。
正文结束
译者大白话
核心观点：别一上来就搞多 AI 合作，先试试单个 AI 够不够用
- 很多团队花几个月搞复杂的多 AI 系统，结果发现单个 AI 好好调教一下就能达到同样效果。
- 多 AI 系统会有额外开销：多花 3 到 10 倍的 token（钱），更容易出错，维护也更麻烦。
- 所以，只有三种情况才值得用多 AI：① 上下文太乱需要隔离；② 任务可以同时并行做；③ 需要专业分工。
什么时候该用多 AI？
1. 上下文保护（避免“上下文污染”）
- 问题：单个 AI 干活时，聊天记录越攒越多，里面掺了很多无关信息，AI 就被搞晕了。
- 解法：把“查资料”这种脏活分给一个专门的小 AI，它只把最重要的摘要（比如 50 个字）拿回来。主 AI 的上下文保持干净清爽。
- 例子：客服 AI 要查订单详情（几千字），同时还要诊断技术问题。分开做，主 AI 只看到“订单号12345，状态：已发货，购买日期：3月5日”这样一句话。
2. 并行化（同时干多件事）
- 问题：单个 AI 一次只能想一件事，探索的范围有限。
- 解法：把一个大问题拆成几个互不相关的方面，同时派出多个 AI 分别调查，最后汇总结果。
- 例子：研究“全球AI发展趋势”，可以让一个 AI 查美国，一个查欧洲，一个查亚洲，同时开工。
- 注意：这样做不是为了快（实际上总 token 消耗更多），而是为了查得更全、更彻底。
3. 专业化（各管一摊，各用各的工具）
- 问题：给一个 AI 太多工具（超过 20 个），它就会挑花眼，经常用错。
- 解法：按领域拆分。CRM 的 AI 只用 CRM 的工具，营销的 AI 只用营销的工具。再配一个“组长 AI”负责把任务分给正确的专家。
- 例子：一个系统要同时操作 CRM、营销平台和消息推送。三个 AI 各管一摊，比一个 AI 管四十多个工具靠谱得多。
怎么拆任务？一个关键原则：按“上下文”拆，不按“工作类型”拆
- ❌ 错误示范：按角色拆——一个写代码、一个写测试、一个审查。每次交接都会丢失信息，变成“传话游戏”。
- ✅ 正确示范：按上下文边界拆——谁做这块功能，谁就负责写它的测试，因为这个人已经知道这块的全部上下文。只有真正能隔离开的才拆开。
好拆的边界：
- 独立的研究方向（亚洲 vs 欧洲市场）
- 有清晰接口的组件（前端 vs 后端，API 说好了就行）
- 黑盒验证（只负责跑测试，不需要知道内部怎么实现的）
不好拆的边界：
- 同一项工作的顺序步骤（规划→实现→测试，太耦合了）
- 需要频繁来回沟通的组件
- 需要共享大量状态的工作
一个特别有效的模式：验证子智能体（专门挑错的 AI）
- 主 AI 干完活，交给一个专门挑错的 AI 去检查。
- 这个挑错的 AI 不需要知道这活是怎么干的，只需要知道“什么算好”，然后运行测试、检查规范。
- 常见的坑：验证 AI 偷懒，只跑一两个测试就说“通过了”。所以要明确要求它“跑完所有测试才能说通过”。
译者总结
多智能体不是银弹。先问自己三个问题：单个 AI 是不是真的不够用？是不是因为上下文太脏、任务能并行、或者工具太多需要分工？如果都不是，那就老老实实优化单个 AI，别为了炫技搞复杂系统。