最近翻到 Anthropic 一篇工程博客，讲的是他们 Applied AI 团队在企业里落地 agent 时发现的一件反直觉的事。
事情是这样的。很多公司一开始搭 agent，习惯按部门或者问题类型拆：客服一个、物流一个、退款一个、技术支援一个……每个"专家"各管一摊，主 agent 负责把用户的问题转给对应的那个。听起来很合理，组织架构照搬到代码里，谁都看得懂，汇报也方便。
但跑起来之后，问题来了。有一家做客服的公司，光是对外的 agent 里就塞了十几个 specialist subagent。结果呢？品牌调性很难统一——用户问同一个问题，转到不同"专家"那里，语气和口径都不太一样。更烦的是延迟，每转一次手就多一截等待，用户体验直接往下掉。
Anthropic 的团队把这类部署拉出来做了对比，结论有点打脸：他们拿了三种设计来 pk:
第一种，一个超长提示词把所有事塞给一个模型；
第二种，按上面那种拆法，搞一堆 subagent；
第三种，单个 agent 跑一个开放的工具循环，配合"技能（skills）"和"工具（tools）"。
最后胜出的，往往是第三种。质量不输甚至更好，单任务的成本和延迟还经常更低。
为什么？
因为他们发现，前面那套复杂的 subagent 结构，很多是在替模型干它早就不用人帮着干的活。模型本身的能力涨得比团队架构迭代快。从 Opus 4.5 那一代开始，一个模型在一个 loop 里能管的事，远超大多数团队的预期。结果 rigid 的多 agent 结构反而把新模型的本事框住了。
更深一层的原因是"传话游戏"。当 agent 按问题类型拆分，问题得在几个"专家"之间传来传去，每次交接都会丢一点保真度——就像公司里跨部门传话，传到最后意思都歪了。与其让信息在多个上下文窗口之间搬来搬去，不如大家待在同一个上下文里，一起看同一份材料，答案反而更准。
那是不是 subagent 就该彻底扔了？也不是。博客里把该留的情况讲得很清楚，我把它翻成大白话：
第一，上下文撑爆了。单个 loop 因为塞太多东西，性能肉眼可见地往下掉，这时候就得拆出去。
第二，要并行干好几件互相独立的事，而且每件干完就能把临时上下文整个扔掉——这种用 subagent 干净利落。
第三，单个 agent 老是选错工具，或者你的系统提示里几条指令互相打架，那也该拆。
除了这三种，大部分"我们按业务线分一下吧"的拆法，都值得先打个问号。
有意思的是他们用的一个招，叫"渐进式披露"。说白了就是：模型平时只看到一个工具或技能的"目录"和一句话说明，真要用到的时候，完整内容才加载进来。你可以把它想象成收拾得很整齐的文件夹——你桌上只摆着标签，需要哪份文件才打开哪份，而不是把公司所有文档都摊在桌面上。这既保证了大家共享同一份上下文（答案更准），又不会一上来就把窗口撑爆。Claude Code 自己就用这招，把系统提示砍掉了超过 80%。
具体到落地，博客把 agent 的零件分了三类，这个分法对写代码的人挺有用：MCP tools 适合"做事"和拿实时数据，比如调个接口、查个库存；skills 适合装团队的"经验"，比如这一步该怎么判断、那条规则不能碰；knowledge bases 就是偶尔要翻的参考资料，放后面按需查就行。但工具别撒太开，一个 API 一个 tool，定义超过三五十个就开始退化。
不过得先泼盆冷水。这套思路不是让你立刻把所有的 subagent 删光，博客自己也强调，架构远没有背后的原则重要。对小团队来说，最现实的做法是先别急着上复杂框架——很多时候一个写得清楚的系统提示，加上三五个薄薄的数据工具，再配几条硬性的输出护栏，就能覆盖大部分场景。等真碰上前面说的那三种该拆的信号，再去拆，反而心里有底。
如果你手头正有一个拆得过细的 agent，想往回并，博客给的路线是"先用评估兜底，再动手"：
先建一个端到端的任务完成评估集，十个黄金样例就够起步。然后从用得最频繁的 specialist 开始合并，优先合并那些本来就在互相调用、操作同一份数据、或者总是被一起叫到的。并完一轮，拿评估集跑一遍，看分数掉了没——没掉就留着，掉了的那块再退回去。
写到最后，其实想说的就一句话：agent 该怎么搭，没有标准答案，但有一个靠谱的判断顺序——先量、一次只改一样、跑评估、留得住的才留。别看谁家架构花哨就跟风，也别为了"显得专业"把简单问题复杂化。少，有时候真的是多。
#agent #AI #Anthropic