来源:Anthropic 官方博客
原文链接:https://claude.com/blog/building-multi-agent-systems-when-and-how-to-use-them
过去一段时间,多 Agent 系统几乎成了 AI Agent 领域最容易被“过度设计”的方向之一。Anthropic 在这篇文章里的核心判断其实很克制:
大多数团队并不需要多 Agent。
所谓多 Agent,指的是多个 LLM 实例分别运行在独立会话上下文中,再通过代码完成协调。原文重点讨论的是一种最常见也最容易落地的模式:orchestrator-subagent,也就是“主代理统筹、子代理执行”的层级结构。
这篇文章最有价值的地方,不是告诉你怎么堆更多 Agent,而是给出一个很务实的判断标准:
- 为什么应该先从单 Agent 做起
- 多 Agent 真正稳定有收益的三种场景是什么
- 为什么任务拆分应该围绕上下文,而不是围绕岗位分工
- 为什么“验证子代理”是少数长期有效的模式
- 多 Agent 最常见的失败点到底在哪
一、为什么应该先从单 Agent 开始
Anthropic 的经验很直接:很多团队花了几个月搭复杂的多 Agent 架构,最后发现,一个提示词更合理、工具配置更清晰的单 Agent,效果几乎一样。
原因并不复杂。多 Agent 系统天然会引入额外成本:
- 更多潜在故障点
- 更多 prompt 需要维护
- 更多不可预期的协同行为
- 更多上下文复制与摘要传递
原文特别提到,在他们的测试里,多 Agent 方案通常会比等价的单 Agent 方案多消耗 3 到 10 倍 token。主要开销来自三部分:
- 每个代理都要带一份自己的上下文
- 代理之间需要发送协调消息
- 结果交接时还要做摘要和压缩
这意味着,如果你的问题本来就能被一个 Agent 解决,那么拆成多个 Agent 往往只是在增加系统复杂度,而不是提升结果质量。
所以一个更稳妥的起点应该是:
- 先把单 Agent 的 prompt、工具定义、上下文管理做到位
- 只有在出现明确瓶颈时,再考虑多 Agent
这也是全文最重要的前提。
二、多 Agent 真正适合的三种场景
Anthropic 总结的结论很明确:只有三类约束下,多 Agent 才会持续优于单 Agent。
1. 上下文污染已经影响效果
大模型的上下文窗口是有限的。随着上下文不断变长,模型注意力会被稀释,回答质量可能下降。
真正的问题不只是“上下文大”,而是上下文里混入了大量对当前任务无关的信息。这就是原文说的 context pollution。
例如一个客服 Agent 既要查订单历史,又要分析技术故障。如果每次查订单都把几千 token 的历史记录塞回主上下文,主 Agent 在分析技术问题时就不得不背着一堆并不需要的订单细节。
单 Agent 写法
# Single agent accumulates everything in context
conversation_history = [
{"role": "user", "content": "My order #12345 isn't working"},
{"role": "assistant", "content": "Let me check your order..."},
# Tool result adds 2000+ tokens of order history
{"role": "user", "content": "... (order details, past purchases, shipping info) ..."},
{"role": "assistant", "content": "Now let me diagnose the technical issue..."},
# Context is now polluted with order details the agent doesn't need
]
多 Agent 写法
from anthropic import Anthropic
client = Anthropic()
class OrderLookupAgent:
def lookup_order(self, order_id: str) -> dict:
# Separate agent with its own context
messages = [
{"role": "user", "content": f"Get essential details for order {order_id}"}
]
response = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=1024,
messages=messages,
tools=[get_order_details_tool]
)
# Returns only essential information
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)
# Get only what's needed, not full history
order_summary = OrderLookupAgent().lookup_order(order_id)
# Inject compact summary, not full context
context = f"Order {order_id}: {order_summary['status']}, purchased {order_summary['date']}"
# Main agent context stays clean
messages = [
{"role": "user", "content": f"{context}\n\nUser issue: {user_message}"}
]
response = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=2048,
messages=messages
)
return response
这个模式的关键不是“多一个 Agent”,而是把高噪音子任务隔离出去,只把必要摘要交回主 Agent。
原文认为,这类场景通常具备几个特征:
- 子任务会产生大量上下文,往往超过 1000 token
- 但大部分信息对主任务并不重要
- 子任务本身边界清晰,容易定义“该提取什么”
典型适用场景包括:
- 检索类任务
- 查询类任务
- 需要先过滤再使用的信息获取任务
2. 任务天然可以并行
第二类适合多 Agent 的场景是:问题可以被拆成多个互不依赖的研究面、搜索面或执行面,并行展开。
Anthropic 在文中用自家的 Research feature 举例:主 Agent 先分析用户问题,再把不同研究方向分发给多个子 Agent 并发调查,最后再汇总结果。
import asyncio
from anthropic import AsyncAnthropic
client = AsyncAnthropic()
async def research_topic(query: str) -> dict:
# Lead agent breaks query into research facets
facets = await lead_agent.decompose_query(query)
# Spawn subagents to research each facet in parallel
tasks = [
research_subagent(facet)
for facet in facets
]
results = await asyncio.gather(*tasks)
# Lead agent synthesizes findings
return await lead_agent.synthesize(results)
async def research_subagent(facet: str) -> dict:
"""Each subagent has its own context window"""
messages = [
{"role": "user", "content": f"Research: {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)
这里要特别注意,原文明确提醒:
并行化的主要收益是覆盖度,不是速度。
这点很容易被误解。多 Agent 并行看起来像是“更快”,但在真实系统里,它往往会带来更高总计算量,因此总体耗时不一定比单 Agent 更短。真正得到提升的是:
- 搜索空间更大
- 调研面更全
- 复杂问题的覆盖更完整
所以并行多 Agent 更适合:
- 多来源搜索
- 多角度研究
- 可拆成独立子问题的大型分析任务
而不适合那种强依赖顺序推理、每一步都要继承上一步细节的问题。
3. 专业化可以提升工具选择或任务聚焦
第三类场景是专业化。原文把它拆成三个层面:
- 工具集专业化
- 系统提示词专业化
- 领域知识专业化
工具集专业化
当一个 Agent 挂了太多工具时,性能会下降。原文给出了几个明显信号:
- 工具数量太多,常见阈值是 20 个以上
- 工具跨了多个不相关领域,模型容易混淆
- 新增工具后,原有任务表现反而变差
系统提示词专业化
有些任务对行为模式要求冲突很大。
- 客服 Agent 需要有同理心、耐心
- 代码审查 Agent 需要严格、批判性
- 合规检查 Agent 需要死板守规则
- 头脑风暴 Agent 需要更开放、更发散
把这些人格和约束混在一个 Agent 里,容易互相干扰。拆成多个专业 Agent,往往更稳定。
领域知识专业化
某些任务确实需要深领域背景,例如法律、医学、监管合规等。如果把所有领域上下文都塞进一个通用 Agent,很容易过载。更合理的做法是让不同 Agent 只携带自己负责领域的上下文。
文中的多平台集成例子很典型:CRM、营销自动化、消息系统各自都有十几个 API。如果全塞给一个 Agent,它会频繁选错工具。
from anthropic import Anthropic
client = Anthropic()
# Specialized agents with focused toolsets and tailored prompts
class CRMAgent:
"""Handles customer relationship management operations"""
system_prompt = """You are a CRM specialist. You manage contacts,
opportunities, and account records. Always verify record ownership
before updates and maintain data integrity across related records."""
tools = [
crm_get_contacts,
crm_create_opportunity,
# 8-10 CRM-specific tools
]
class MarketingAgent:
"""Handles marketing automation operations"""
system_prompt = """You are a marketing automation specialist. You
manage campaigns, lead scoring, and email sequences. Prioritize
data hygiene and respect contact preferences."""
tools = [
marketing_get_campaigns,
marketing_create_lead,
# 8-10 marketing-specific tools
]
class OrchestratorAgent:
"""Routes requests to specialized agents"""
def execute(self, user_request: str):
response = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=1024,
system="""You coordinate platform integrations. Route requests to the appropriate specialist:
- CRM: Contact records, opportunities, accounts, sales pipeline
- Marketing: Campaigns, lead nurturing, email sequences, scoring
- Messaging: Notifications, alerts, team communication""",
messages=[
{"role": "user", "content": user_request}
],
tools=[delegate_to_crm, delegate_to_marketing, delegate_to_messaging]
)
return response
这个模式的前提是:领域边界足够清楚,路由判断足够明确。否则你只是把工具选择错误换成了“路由错误”。
三、什么时候说明你真的快到单 Agent 上限了
在给出三类正向场景后,原文还补了一组“升级信号”。这些不是硬阈值,但值得关注。
1. 上下文压力越来越明显
如果单 Agent 经常消耗大量上下文,而且效果持续下降,就说明上下文可能已经成为主要瓶颈。
不过原文也提醒:随着上下文管理技术进步,例如 automatic context compaction,单 Agent 的可用边界正在被继续推高。
2. 工具数量已经很难管理
如果 Agent 已经挂了 15 到 20 个以上工具,模型会花大量注意力理解“我到底有哪些选择”。
但在直接上多 Agent 之前,Anthropic 先推荐另一个更轻量的方案:用 Tool Search Tool 让 Claude 按需发现工具,而不是一开始就把全部工具定义塞进去。
原文给出的说法是,这种方式可以 最多减少 85% 的 token 使用,同时提升工具选择准确率。
3. 任务确实能被拆成独立并发单元
如果一个任务天然可以被切成多个互相独立的子块,比如:
- 多来源调研
- 多组件测试
- 多维度搜索
那并行子代理通常会更有价值。
四、上下文中心拆分:这是多 Agent 设计里最重要的原则
这是全文最值得单独拿出来讲的一部分。
Anthropic 观察到,很多团队做多 Agent 时,拆分方式一开始就错了。他们按“工作类型”来拆:
- 一个 Agent 负责规划
- 一个 Agent 负责实现
- 一个 Agent 负责测试
- 一个 Agent 负责评审
表面上看像是在模仿团队协作,实际上往往会把系统拖进无穷无尽的交接损耗里。
原文把这叫作:problem-centric decomposition,也就是按问题类型、按岗位类型拆分。这通常是反效果。
为什么?
因为同一个功能的规划、实现、测试,本来就共享大量上下文。每一次交接,都像在玩“传话游戏”:
- 上一个 Agent 的完整思考过程没法完整转移
- 摘要会丢信息
- 下一个 Agent 不知道前面为什么这样做
- 最后大量 token 花在协调上,而不是花在真正执行上
更合理的方式是:按上下文边界拆,不按岗位边界拆。
原文把这叫 context-centric decomposition。
有效的拆分边界
相互独立的研究路径
例如“研究亚洲市场趋势”和“研究欧洲市场趋势”接口清晰的独立组件
例如前后端只通过明确 API 合约协作黑盒验证任务
验证 Agent 只要跑测试并反馈结果,不需要知道完整实现过程
有问题的拆分边界
同一件事情的顺序阶段
例如把同一个功能拆成“规划 Agent / 开发 Agent / 测试 Agent”高耦合组件
如果两个部分需要不断来回同步,就不该硬拆强共享状态任务
只要频繁同步理解,拆分往往得不偿失
如果把整篇文章压缩成一句设计原则,那就是:
只有在上下文真的可以隔离时,才值得拆成多个 Agent。
五、验证子代理模式:少数持续有效的多 Agent 模式
在各种多 Agent 结构里,Anthropic 特别点名了一个“长期有效”的模式:verification subagent,也就是验证子代理。
它的职责很单一:不负责生成,只负责验证主 Agent 的产物是否通过。
原文也做了一个现实判断:随着更强的 orchestrator 模型出现,例如 Claude Opus 4.5,某些情况下主 Agent 自己也能评价子代理的工作。但在这些场景里,验证子代理依然有价值:
- 主控模型能力没那么强
- 验证本身需要专门工具
- 你希望流程里强制存在明确的验证关卡
之所以它好用,是因为它天然避开了前面提到的“传话游戏”问题。
验证通常只需要:
- 被验证的产物
- 清晰的通过标准
- 执行验证所需的工具
它不需要知道“这个东西为什么这样设计”,因此上下文转移成本非常低。
验证子代理示例
from anthropic import Anthropic
client = Anthropic()
class CodingAgent:
def implement_feature(self, requirements: str) -> dict:
"""Main agent implements the feature"""
messages = [
{"role": "user", "content": f"Implement: {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:
"""Separate agent verifies the work"""
messages = [
{"role": "user", "content": f"""
Requirements: {requirements}
Files changed: {files_changed}
Run the test suite and verify:
1. All existing tests pass
2. New functionality works as specified
3. No obvious errors or security issues
You MUST run the complete test suite before marking as passed.
Do not mark as passing after only running a few tests.
Run: pytest --verbose
Only mark as PASSED if ALL tests pass with no failures.
"""}
]
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\nPrevious attempt failed: {verification['issues']}"
raise Exception(f"Failed verification after {max_attempts} attempts")
这个模式适合哪些任务
原文给了几类典型应用:
- 质量保障:跑测试、跑 lint、校验 schema
- 合规检查:核对文档或输出是否满足规则
- 输出校验:交付前确认内容符合规格
- 事实核验:检查生成内容中的事实或引用
六、常见失败点:多 Agent 不是拆得越细越好
原文里最值得警惕的几个失败模式,基本都和“错误拆分”与“验证偷懒”有关。
1. 把顺序阶段错误拆给不同 Agent
这是最常见的问题。一个功能如果从规划到实现再到测试都共享大量上下文,那么硬拆只会增加交接损耗。
结果通常是:
- 丢上下文
- 摘要失真
- 决策理由无法传递
- token 大量消耗在协调上
2. 工具多了,但只是把混乱换了个地方
很多团队以为“把 40 个工具拆成 4 个 Agent”就结束了。其实没有。你只是把工具选择问题变成了路由问题。
如果 orchestrator 不能稳定判断请求属于哪个领域,结果一样会劣化。
3. 并行化被误当成提速手段
并行子代理真正擅长的是扩大覆盖面,而不是天然更快。若任务本身不适合并行拆分,强行并行只会让成本更高。
4. 验证 Agent 提前宣布胜利
这是原文专门强调的 early victory problem。
也就是验证子代理只跑了一两个测试,看到通过,就直接宣布“没问题”。这在工程里是非常危险的。
Anthropic 给出的缓解策略很具体:
用具体标准替代模糊要求
例如写“跑完整测试套件并报告全部失败项”,而不是“确认它能工作”要求覆盖多个场景与边界条件
明确要求负向测试
也就是故意输入应当失败的情况,并确认它们确实失败用强约束语句显式要求完整验证
例如:
You MUST run the complete test suite before marking as passed.
原文的判断很明确:如果你不把“必须完整验证”写进要求里,验证 Agent 很容易走捷径。
七、一个实用决策框架
如果你正在评估是否引入多 Agent,可以先用下面三个问题做过滤。
你面对的是不是真的有单 Agent 解决不了的约束? 例如上下文限制、可并行子任务、明确的专业化需求。
你的拆分方式是不是围绕上下文边界? 如果只是按岗位或流程阶段拆,大概率会适得其反。
你有没有明确的验证点? 如果没有可靠验证,多 Agent 往往只是把错误放大得更快。
只有这三个问题都能回答得足够清楚,多 Agent 才更可能是增益,而不是负担。
八、结语
Anthropic 对多 Agent 的态度并不激进,反而很像一条成熟工程建议:
先用最简单、最便宜、最稳定的方式把问题解决,再在证据明确时引入多 Agent。
这也是我认为这篇文章最有价值的地方。它没有把多 Agent 包装成通用答案,而是提醒我们:
- 单 Agent 的上限比很多人想象得高
- 多 Agent 的成本比很多人想象得重
- 只有在上下文隔离、并行探索、专业化路由这些约束下,多 Agent 才真正稳定有收益
进一步阅读:
- 原文:https://claude.com/blog/building-multi-agent-systems-when-and-how-to-use-them
- 单 Agent 模式:https://www.anthropic.com/engineering/building-effective-agents
- 上下文工程:https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
- 多 Agent Research 系统:https://www.anthropic.com/engineering/multi-agent-research-system
- Tool Search Tool:https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/tool-search-tool