Anthropic 说：多智能体别乱搭，Claude Code 提示词砍了 80%

Anthropic 的这篇文章可以看看，《构建智能体：何时把子智能体合并回主智能体循环》 文里提出了一个观察就是我们目前的大多数公司的 Agent 架构，不知不觉就变成了公司内部组织架构图的翻版。意思就是说比如做客服或企业中台，市场部、财务部、订单部各自造一个独立的 Subagent，然后中台团队在上面搭一个中央调度器。其实在我们的视角来看的话是很好的，很清晰和完整的分类。

但在实际生产中不是。每个子 Agent 都有自己独立的 Prompt 和上下文，跨智能体转交任务就像玩传话游戏，每一次 handoff 都在丢失关键细节。而且呢各个业务线为了向其中加入自己的规则，最后把系统提示词搞成了一个人格分裂的弗兰肯斯坦，而且呢架构中的多层嵌套的 LLM 循环直接让端到端延迟翻了整整一倍。

Anthropic 的应用 AI 团队在实际帮企业调优后给出了一种方法：他们把绝大多数调度器和 Subagent 砍掉，收进单一大模型的主循环里。���们发现，随着 Opus 4.5 到 5.5 这代前沿模型自带的思考和自我修正能力大幅进化，原本靠外部复杂框架硬编码约束的很多繁琐环节，模型自己就能处理得很好。他们把子智能体的业务经验降维沉淀为 Skill，把数据读写拆解为标准的 MCP Tools，主循环只加载极短的描述，只有在模型实际需要调用时才动态加载细节。

Anthropic 透露，他们自己用这套思路把 Claude Code 的系统提示词直接精简了 80% 以上。当然官方并不是完全否定多智能体，对于多 agent ，官方认为可以依据一下来判断你是否需要保留多 agent 。只有当单上下文确实出现了可量化的性能衰减、需要用完即弃的新上下文去并行跑多条完全独立的探索路径，或者指令出现不可调和的逻辑互斥时，才值得单独开一个 Subagent。

除此之外的绝大部分业务，单一共享上下文的效果反而更好，因为模型能够直接看到之前每一步真实的工具返回原始数据，而不是阅读被子智能体压缩失真后的总结。其实这从我们日常写代码、做 Agent 时就能明显感受到，我相信很多动手搭过多智能体系统的人都有体会。最开始大家觉得多智能体架构分工明确、图谱漂亮，但之后的链路调试，或者说子 Agent 等等的问题可以说是很折磨人。

我们的 agent 始终要向着效果看齐。能用少的开销，还有一个基本干净的的上下文能很好的把工作做好，其实就是我们所需要开发的 agent。不要过度设计，把子智能体打散成按需加载的 Skills 和 Tools 是一个很好的轻量思路。

原文：