Anthropic实测，拆3个子agent反而慢54%、花费翻倍，单agent加skills更优

Anthropic近期发布的技术实践文章《When to fold subagents into your main agent loop》引发关注。该文并非理论推演，而是基于真实企业部署与本地实验的结论：在多数场景下，采用单一主agent配合渐进式加载的skills与工具，其效果、成本与延迟均优于传统多子agent并行架构。

文章由Anthropic Applied AI团队成员Diane Sarkis撰写，面向企业级Agent系统搭建者。其核心主张直指当前AI工程实践中一个普遍误区——将“任务可分工”等同于“应拆分子agent”。实测数据表明，这种直觉往往适得其反。

以一个典型跨目录代码审查任务为例：在Claude Code中，对包含约95个Python文件、另含Swift macOS App与Web面板的开源项目cc-statistics，要求找出所有计算美元费用的函数，并判断其价格逻辑来源与缓存行为。使用单agent模式（主agent自行读取、分析、总结），平均耗时93秒，费用0.87美元；若改为拆分为3个子agent并行处理不同模块后再汇总，平均耗时升至143秒，费用达1.92美元——时间增加54%，成本翻倍至2.2倍。四次重复实验的答案核心结论完全一致，说明性能损失未换来质量提升。

这一结果与Anthropic客户案例高度吻合：某企业将多agent架构重构为单agent循环后，任务运行速度提升约2倍。原文指出，问题根源不在并行本身，而在“交接成本”——每新增一个子agent，就需额外生成系统提示、重复读取代码上下文、压缩摘要回传，主agent收到摘要后往往还需二次核验。这些操作均按token计费，且易导致细节丢失。

更深层的问题在于组织层面。Anthropic将“每个团队开发一个子agent”的现象称为康威定律的现实映射：数百个职能重叠、标准不一、责任模糊的子agent共存，最终拼出一个规则冲突的“Frankenprompt”。例如某公司客服Agent内置十余个专职子agent，结果品牌口径混乱、响应延迟攀升。

技术演进也削弱了拆分子agent的必要性。自Opus 4.5起，模型单轮处理能力显著增强，“主agent在需要时动态加载skill内容”即可应对上下文容量限制，无需提前拆分。Anthropic自身优化Claude Code时，通过将skills与工具改为渐进披露，系统提示精简超80%。

值得注意的是，工具数量存在明确拐点：当系统提示中定义的工具超过30–50个，模型选工具准确率明显下降。建议按用户意图分组工具，而非“一个API对应一个tool”。

那么，何时仍应保留子agent？Anthropic提出三条明确保留条件：

① 单agent因上下文膨胀导致可测量的性能下降；

② 多个任务必须真正并行执行，且各自产出需独立完成功能（如code-review后立即运行测试）；

③ 主agent无法准确定位所需工具，或系统提示中指令存在冲突。

若不符合上述任一条件，则优先考虑将子agent功能折叠为主agent的skills或MCP工具调用。具体实施路径包括：将专职agent的prompt转为skill描述，其调用的API转为MCP工具；工具按意图分组，总量控制在30–50个以内；并建立评估闭环——先构建10条eval样本，每轮迭代对比一次效果。

这一趋势与Anthropic内部AI应用深度绑定。数据显示，其工程师人均代码提交量半年增长约5倍，Agent总工时已于2024年3月超过人类员工，研究部门甚至达人类工时的19倍。但产出激增并未伴随质量下滑——Agent生成代码被删除或回滚的比例与人工代码基本持平。

背后逻辑清晰：编程任务目标明确、验证快速，AI可通过反复试错逼近最优解。而人类角色正转向“Meta-work”——设计任务流程、构建监控体系、判断执行结果。此类工作在员工与Agent交互会话中的占比已从10%升至22%。招聘标准随之转变：自主性、判断力及AI协同能力取代具体技术经验成为核心考察项。

这不仅是工程优化问题，更是人机协作范式的迁移。当主agent能通过skills动态扩展能力边界，架构设计的重心就应从“如何分工”转向“如何让主脑更高效决策”。过度拆分子agent，本质是将系统复杂性转嫁给通信成本与协调损耗——正如图中所示，多花的钱，最终都花在了“交接”上。

Anthropic的建议并非否定并行价值，而是强调：架构选择应基于实证度量，而非任务表象。在模型能力持续跃升的当下，简洁、集中的单agent循环，反而更接近高效智能体的未来形态。