10月22日，Anthropic 应用AI团队发了一篇工程博客，标题就叫《Building agents: When to fold subagents into your main agent loop》。核心主张一句话：子代理不是荣誉徽章，没必要的就该折回主循环，质量反而可能更好、更快、更便宜。Claude官网
接下来一周，中文圈跟着炸了：知乎译介帖攒下三百多个收藏，小红书有人把自家电脑里一个月的230个 Claude Code 会话全扒了一遍，发现 Claude 自己拆子代理的频次在暴跌；有人同一个任务连跑12遍，把分工的成本账算成了数据图；B站搬运的标题直接说多智能体架构要变天了。小红书
这篇内容服务的人群很具体：从今年年初开始，在 Claude Code 里搭"数字开发团队"的中度用户——代码审查agent、测试agent、检索agent、文档agent，再挂一个 orchestrator 统一调度。脚手架搭得越豪华，看到这条官博时心里越打鼓。他们要回答的不是"要不要跟风官方"，而是"我配的那一套，哪些该留、哪些该折、怎么折才不会把跑顺的流程弄坏"。
一、官方说了什么（比你刷到的标题克制得多）
博客给出的对比结果是：「一个主 Agent Loop + 渐进式披露的 skills 与 tools」在质量上同时跑赢了两个极端——“一个巨型提示词包打天下"和"多子代理编排”，而且成本和延迟往往更低。知乎
最扎的是那个康威定律类比：不少公司的 agent 架构，就是组织架构图的复印件——每个团队各做一个 agent，中央平台团队再在上面盖一个 orchestrator。 而"意图分类器+固定多步流水线+用户分群+独立推荐分支+再叠一个编排器"这套经典老五样，干的很多活儿模型已经不需要别人替它干了：一个清晰的系统提示词、4到5个薄薄的数据工具、加上严格的输出护栏，就能覆盖绝大多数场景。知乎Claude官网
单循环不是"裸奔"：一个模型、一个上下文窗口跑开放式工具循环，harness 只管预算——轮次上限、成本上限、写操作门禁；上下文通过 skills 渐进加载，工具通过 tool search 渐进加载，平时只看到简短描述，用到才完整载入。 换句话说，官方推荐的形态是"循环极简、基础设施极厚"。知乎
有一条数字必须标注边界：博客提到某客户改成单循环后运行快了一倍，这是单一客户的说法，转述过这组实验数据的社区实测者就专门提醒过，这个倍数不能当成普遍结论。 这篇官博真正硬的产出是方法论和保留清单，不是这个倍数。小红书
二、子代理的三张成本账单
为什么官方口径转变得这么直接？把博客和社区实测拼起来，是三张账。
第一张，交接税。按团队拆的多agent，交接丢上下文、提示词互相打架、延迟层层叠加。有用户把自己230个会话的前后期数据摆了出来：同一个 Opus 5.5，开子代理的会话占比从21%降到13%，派出的子代理总数从267跌到61、降幅77%，单次会话最多派出从75个缩到16个，拐点在10月初，之后没再回头。 这是单机个人日志，不是官方遥测，只能当个体信号——但注意，几乎唯一派发量上升的任务类型，是"汇总大量消息"这种天然适合并行的活。小红书
第二张，token 与通过率。有人对照了南京大学、UIUC 等团队的公开论文：Claude Code 在小任务集上，串行通过率大约83%，一开原生动态并发掉到约59%，token 消耗是串行的1.4到3.3倍，很多时候时间也不更短；这项研究覆盖354个任务、2124次执行的可控对比，收益主要出现在长任务那一头。小红书arXiv
第三张，"每一行"的钱。折叠进单循环后，每条 Skill 描述、CLAUDE.md 每一行都是成本，每一轮都在付费。 这也是为什么 Claude Code 作者本人会说每6个月把 CLAUDE.md 删光重来。 规则不会过期报错，它只会安静地摊在你的每一轮账单里。小红书小红书
三、但"全删"不是结论——反例也在同一批数据里
有实测者在一个12个源文件的小项目里，同一任务跑了12遍，结论是分层的：小活别分工，不派子代理最快也最省；但子代理买的是深度——全开 high effort 账单贵3.6倍，每遍也能多挖出3个问题。 检索找东西的活交给 Haiku 子代理，一遍约0.004美元，便宜到可以忽略。他同时标了边界：只测了12个源文件的小项目，大仓库没测，分工可能反而划算。小红书
所以官方的完整口径是：子代理只在"测出来更好"时才留，而不是见一个删一个，包括研究前沿在内的场景确实仍需要它们。 保留情形就三条：单 Loop 因上下文膨胀出现可测量的性能退化；多个任务真的需要并行、且各要一份用完即弃的干净上下文；单个 agent 选不对工具、或系统提示词里的指令互相冲突。Claude官网
顺带澄清一个被"变天"标题搞出来的疑惑：同期 Claude Code 桌面端更新的重点，是从单个会话执行任务走向协调多个子会话。 这和"砍子代理"看起来打架，其实不矛盾——官方砍的是"一个会话里事事派子代理"的架构冗余，桌面端多会话属于"真并行+干净上下文"，恰好落在官方说要保留的那一类里。功能名称与版本支持，以客户端当前说明为准。哔哩哔哩
四、留还是折：先对表再动手
优先折回主循环 | 暂时保留 |
|---|---|
串行调用、碰同一份数据、经常一起被调起的"专员agent" | 长时间调研、跨仓库/大规模找bug等真并行活 |
"角色扮演式"分工：架构师/编码者/测试者三件套 | 权限隔离需求强的任务（如只读审计代理） |
按团队、按模块一人一个、照组织架构图复印出来的agent | 主agent确实选不对工具、提示词指令打架的场景 |
每个小改动都要拆一轮、纯粹"显得专业"的派发 | 还没测出上下文膨胀退化的任务 |
五、迁移检查单：官方反复强调一个字——稳
先建评估，再动手术：中央团队一套端到端 eval 集，每个 Skill 自带小评估集，哪怕只有10条黄金样本也够起步。还在用 orchestrator 时追踪路由准确率；折叠之后，改看 agent 是否加载了正确的 Skill、调用了正确的工具。
一次只折一个，折完做对比。 官方博客还放出了配套的迁移工具包 single-agent-loop-kit，动作就三步：Measure（建基线）→ Combine（把总是一起跑的 subagent 合并）→ Fold（剩下的逐个拆成 Skill 和工具）。 注意它是参考实现，官方声明不维护、不收贡献，拿来抄流程可以，直接当生产依赖要三思。知乎知乎GitHub
规则同步做减法：CLAUDE.md 先备份再删，只有"同一个错误反复出现"才把对应行加回去。
留好观察信号：token 账单变化、code review 实际挖出的问题数、以及 AI 开始反问你本来它自己能查到的信息——上下文丢失的征兆，往往先从对话里冒出来。
别信"折完就完事"：官方博客自己就给过很难看的失败案例——客服 agent 折叠后延迟确实降了，却弄坏了一个本来能通过的流程，主 agent 拿着订单查询工具自己就把答案编出来了，没去问物流专员确认送达日期，而且这个毛病两次评估只出现一次。 所以每个评估任务都要多跑几遍，别测一次就上线。知乎
结尾：军备竞赛的方向换了
前两年大家晒的是"我能编排多少个 agent"；从这个10月开始，值得比拼的变成了"能不能让一个 agent 带着完整上下文、用最瘦的 Skills 把活干到底"。
不用急着把搭建具拆个干净，也不用装死不动。今晚就能做一件成本最低的事：挑一个你最常派发的子代理，先给它备10条黄金样本跑基线，再把它折进一个带渐进披露的 Skill 复测。分数没掉的，删了就是白赚的账单；分数掉的，那是你该理直气壮留着的那个——也是这轮"减法潮"里，少数经得起评测检验的资产。
评论区聊聊：你现在的 CLAUDE.md 和子代理配置，有多久没删过了？
