你的Agent系统里，有几个子Agent？
如果数不清，或者这个数字还在涨，Anthropic刚发的这篇文章值得看完。Applied AI团队对比多家企业级部署后发现：配备Skills的单Agent，质量上常常跑赢子Agent架构，单任务成本和延迟还更低。Claude官网知乎
这不是空口劝。有家公司的客服Agent里塞了12个专家子Agent，结果品牌调性难以统一，延迟把体验拖垮；另一家客户把多Agent换成单Agent循环，运行快了约2倍。知乎知乎
拆多了，坑大多出在交接上
按问题类型把任务拆给不同子Agent，它们就会像玩传话游戏：每次交接，信息保真度都掉一层。有开发者的吐槽很精准——子代理交回来的报告里，最常丢的就是那句「顺便提一句」。知乎哔哩哔哩
为什么单Agent现在反而行得通？官方给了三个理由：
共享上下文，看过前面每一步结果的模型能把线索串起来，比子代理交回的一堆摘要更有洞察，交接损耗也更少；渐进式披露，Skills和工具只在需要时才加载完整内容，系统提示词不必塞满一切，Claude Code为新模型砍掉了超过80%的系统提示词；模型变强，从Opus 4.5起，模型在单个循环里能管住的事，比多数团队预想的多。知乎
三种情况，还是得留子Agent
官方没把话说死，满足任一条就该保留：单Agent循环因上下文膨胀出现可测量的性能退化；多个任务需要并行跑，且上下文用完即弃；单Agent选不对工具，或系统提示词里指令互相打架——工具定义超过30到50个，选对工具就开始变难。知乎知乎
注意，Anthropic自己的多Agent研究系统还在跑。真正被劝退的是另一种拆法：每个团队、每类问题都配一个子Agent，架构长成了公司组织架构图的复印件。这是康威定律在Agent开发里的翻版。知乎
光听厂商的不够，有人真量过
一位开源多智能体项目作者做了对照实验：同一个任务，1个、4个、6个Agent各跑30次，隔两个月换一个模型再跑一轮。结果是，从6个砍到4个，token少57%到60%，成本少47%到54%，多出来的两个节点没换来更好的报告；10月那轮，6个Agent的组30次只完成23次，卡点在于审稿Agent反复通不过格式校验。知乎
他的结论更直白：多Agent不会天然更强，但一定更贵、故障点更多。评论区点赞最多的补充也很现实——三个Agent一起做错事，你会看到一串互相指向的记录，每个都说自己按约定做了，责任比单Agent难查得多。知乎知乎
当然也有相反的体感：有人实测复杂度低的任务换Skills更快，复杂度高的会崩。架构合理性本身就是变量，别人的结论不能直接搬。知乎
想动手合并，先建评测集
官方的迁移路径可以浓缩成三步：先建一套端到端评测集，10个黄金样例就够起步；然后从最常用的子Agent开始合并，优先处理输出彼此串联、访问同一份数据、经常被一起调用的；过渡期不用急，暂时保留的子Agent可以降级成工具调用。知乎
合并时最容易踩的坑：别只看总分，要看哪些任务翻转了。官方在一个示例客服Agent上发现，把子Agent并回后延迟确实降了，但一个原本通过的流程挂了——主Agent拿着订单查询工具自己给了答案，没问配送专家要送达日期。所以每个任务至少跑两次，这种问题可能只出现一次。知乎
拆不拆，其实就看一个问题：下一步需要的，是结论和依据，还是一大块共享上下文？前者适合拆出去，后者就该留在同一个循环里。
Anthropic最后那句话值得贴在工位上：与其纠结于某种具体架构，不如先测量、一次只改一个变量、留下经得起评测的方案——这个原则不会过时。
