从2277个子代理说起:新版收益实测

特别企划 · 144个主会话×2277个子代理,两个月真实数据验证 w30-w34 六项更新 《智能编码进化论》系列 · 数据报告体 · 2026-08

上一期《将帅无能,累死三军》,我们谈的是"将帅"——规划力、上下文传递力、验收力,收了五条军规。选完将,该盘点粮草装备了。这一期,我们拿自己两个月的真实会话记录做了一次家底盘点:144 个主会话、2277 次子代理调用,验证 w30 到 w34 五个版本的六项更新,到底治好了哪些病,哪些病根本没指望版本治。

开篇:从 2277 个子代理说起

两个月,我们数了数家底。

144 个主会话、2277 次子代理调用、805MB 会话记录——这是羲和Lab 60 天全部工程会话攒下的数据。2277,意味着平均每个主会话派发 15 次以上——多智能体协同已经不是实验,是我们的日常负载形态。我们把每一次"没跑通"的调用都翻了出来,按失败次数排序,得到一份痛点清单。

先交代数据口径,免得数字被误读:

• 144 个主会话,来自 60 天全部工程会话,未做筛选
• 2277 次子代理调用,成功与失败都算在内,其中失败(terminated)22 次
• 痛点 Top5 统计的是"触发失败的调用次数",不是总调用次数
• 基线对比:60 天总工具调用量约 3.5 万次,各痛点占比见交叉矩阵

与版本更新相关的痛点,按失败次数排序 Top5:sandbox 拦截 97 次、rate_limit 84 次、/compact 压缩 71 次、Agent terminated 22 次、Prompt-too-long 13 次。

但矩阵里还有更大的数字,它们不在"版本相关"这个视野内:248 次 TAPD API 失败、179 次 timeout、147 次 file-not-read、130 次 git 冲突。它们和版本更新没有对应关系,指向另一类问题,我们叫它"流程病"。完整交叉矩阵如下:

痛点	次数	对应更新	治好了吗
sandbox 拦截	97	auto mode 默认化	✅ 基本治好
rate_limit	84	预算闸门+缓存复用	✅ 部分缓解
/compact 压缩	71	Opus 5 1M context	✅ 频率下降
Prompt-too-long	13	1M context + 输出瘦身	✅ 基本治好
Agent terminated	22	200 上限移除+fork	✅ 基本治好
TAPD API 失败	248	—(流程病)	❌ 版本治不了
timeout	179	—(流程病)	❌ 版本治不了
file-not-read	147	—(流程病)	❌ 版本治不了
git 冲突	130	worktree 隔离	🟡 部分缓解

于是问题变成两个:版本更新治好了哪些病?哪些病根本不该指望版本治?

主线一:模型换代,1M 上下文治"压缩焦虑"

主攻痛点:/compact 压缩 71 次、Prompt-too-long 13 次

71 次压缩是什么概念?60 天 71 次,平均每天超过一次。每次 /compact 都是一次"断舍离":旧上下文被摘要化或丢弃,主智能体的记忆被迫瘦身。

压缩本身不是问题,压缩导致的遗忘才是。我们的会话记录显示,压缩后的返工大多来自"重新解释"——背景被摘要化之后,主会话记不清当初的决策细节,子代理交回结果时,还得从头对齐一遍。一次压缩,可能带来十分钟的隐性返工。这类成本不会出现在任何错误日志里,但它真实存在。

13 次 Prompt-too-long 更直接:prompt 超长,调用直接失败。这类失败多发生在长会话后期——上下文堆到接近上限,再塞新任务就报错。它和 /compact 是同一枚硬币的两面:容量不够,要么主动压缩,要么被拒绝。

两个痛点的病根是同一个:上下文容量不够用。Opus 5 的发布,正好治这个病:

• 1M context,长会话几乎不截断。以前做到一半就触顶的会话,现在能一口气跑完,中途不需要"断舍离"。
• 压缩频率下降。/compact 从"被迫定期做"变成"可选清理",压缩导致的上下文丢失随之减少。
• Fast mode 补齐速度短板。1M 上下文不是只有慢速模式,低延迟场景照样有得选,不再为了速度牺牲容量。

一句话:模型换代把"压缩焦虑"从高频事故降级成低频操作。矩阵里这一格写的是"频率下降",不是"彻底消失"——1M 不是无限,超长会话该压缩还是得压缩,但触发次数和压缩后的损失,都小了一个量级。

主线二:兵力上限解除,200 子代理限制移除

主攻痛点:2277 次子代理调用、Agent terminated 22 次

回到 2277 这个数字。开篇说过,它意味着平均每个主会话派发 15 次以上。其中失败(terminated)22 次,成功率超过 99%——子代理调用本身是可靠的,真正的问题在别处:配额、上下文、权限,这些才是失败集中出现的地方。

但日常负载撞过墙。Agent terminated 22 次:22 次子代理调用被终止。回顾终止记录,相当一部分与配额相关——单会话累计子代理数触顶,任务做到一半被掐断,整个分支作废重来。这种失败最伤士气:活干了,账不算。

w32 的更新移除了每会话 200 子代理的上限,只保留并发 20 的限制。对我们的意义:

• 长周期批量任务不再撞"配额墙"。之前大任务要拆成几段、分几个会话接力跑,现在一个会话内能连续派发,不用自己当调度员。
• 并发 20 的护栏还在。防止"派兵无度"——这和《将帅无能》里将帅五律"先规划再派发"是同一个道理,只不过从规则变成了产品约束。规则靠自觉,约束靠系统。

w33 起 fork 模式默认开启,这是第二重收益。fork 把当前会话复制一份到后台,旁支任务在副本里跑,不污染主线;实验失败,丢掉的只是一个副本。附带的好处是:fork 继承上下文和 prompt cache,旁支任务不用重新解释背景——输入侧省钱,这个收益在主线四还会细算。

22 次 terminated 里,还有一部分是主动终止:主线判断派错了活,直接掐掉重派。这一部分版本治不了,只能靠规划——将帅多想十分钟,三军少干两小时。解除上限不等于可以乱派:并发 20 的护栏还在,加上将帅五律的规划纪律,兵力才真正可控——多,是能力;不乱派,才是本事。

主线三:权限摩擦归零,auto mode 默认化

主攻痛点:sandbox 拦截 97 次

97 次 sandbox 拦截,在版本相关痛点里排第一。典型场景:命令要访问外部网络或敏感路径,权限系统要求裁决,调用被挂起或直接失败。

我们此前的沙箱规则里写过一条经验:"被拦截时直接重试同命令,不要换写法"——因为部分拦截是误伤,重试能过。但重试也是成本:一次拦截,轻则几秒,重则整条链路重跑,还得人工盯着确认弹窗。97 次拦截,是实打实的摩擦时间。

8/14 起,auto mode 成为默认权限模式,直接治这个病:

• 权限裁决自动化。常见操作不再逐条确认,工具调用一路绿灯,sandbox 拦截数量大幅下降。
• 关键细节:分类器调用不计费。权限裁决本身不消耗 token——以前"确认一次"的成本藏在调用里,现在这条成本线直接消失。省 token,不只是省一次确认,是省一整类开销。

auto mode 默认化之后,我们会话记录里的拦截集中在真正的高危操作上:敏感路径写入、凭据相关访问。这反而是对的——该确认的确认,不该确认的不再打扰。权限摩擦从"高频打扰"变成"低频把关",97 次这个数字,基本成了历史。

主线四:tokens 消耗优化

主攻痛点:rate_limit 84 次、/compact 71 次压缩浪费

84 次 rate_limit,是"钱和额度"直接引发的失败:调用触达速率或额度上限,请求被拒。71 次压缩浪费,是"压缩后重新解释"的隐性成本。一笔明账,一笔暗账,都指向 tokens 消耗。这一章分两侧算:输入侧怎么省,输出侧怎么管。

4.1 输入侧省钱:fork 复用 prompt cache

tokens 账单上,输入侧往往占大头——尤其是每轮都要重述的上下文。

fork 的输入侧收益:继承父会话的上下文和 prompt cache,旁支任务直接复用,不用把背景重讲一遍。我们最典型的场景是"一次实验的两个方向":主线不解释,两个 fork 各自开工,重复的输入消耗几乎为零。没有 fork 之前,这类场景要么复制粘贴上下文,要么让子代理盲猜——前者烧 token,后者烧正确率。

另一个变化在模型定价。Opus 5 的 Fast mode 迁移后,输入侧定价大幅下调:输入约 $10/MTok 级别,输出约 $50/MTok 级别,准确值以官方页面为准,官方页面更新常有滞后。定价下调叠加输入量下降,输入侧的钱,两头都在省。

4.2 输出侧瘦身与预算硬约束

输入省了,输出也得管。输出侧的三个更新:

• /code-review 后台化:代码审查跑在独立 context,不膨胀主会话。审查是长输出任务,以前拖慢主线,现在隔离出去,主会话保持轻装,该写的代码不排队。
• Concise 输出风格(v2.1.237):直接给结果,不铺垫、不总结过程。输出侧瘦身,对长会话的累积效果明显——每轮少输出,几十轮下来省下的量相当可观。
• --max-budget-usd 覆盖子代理:并发失控的硬闸门。子代理跑飞,预算上限一刀切,不等到月底看账单才发现超支。预算不是记账工具,是闸门。

四笔账合起来看,rate_limit 84 次是"部分缓解":预算闸门挡住的失控少了,但速率上限本身在平台侧,缓存复用只能缓解,不能根治。所以矩阵这一格写"部分缓解",不是"治好"。

所有定价数据截至 2026 年 8 月,官方页面可能有更新。

主线五:跨会话沟通协同

主攻痛点:144 会话多工程并行,接口变更靠人工同步(未单列失败次数)

144 个主会话并行跑,最大的成本不是 token,是"同步"。接口变更了,改的人知道,用的人不知道——以前全靠人工传话:截图、粘贴、转发,一个变更同步一轮。这一章按"解决什么"组织,五步:

1. 发现会话:多会话并行,第一步是"看到"彼此。ListAgents(v2.1.224)让会话之间互相可见,不再是信息孤岛——先知道有谁在,才知道该找谁。

2. 定向沟通:看到之后要能说话。SendMessage 互发 + @-mention 指定会话(v2.1.232),消息轻量直达,而且绝不携带对话历史——要传的是结论,不是整个上下文。轻,才能快。

3. 异步通知:等长任务不再靠轮询。notify_when_idle(v2.1.236),目标会话空闲了才通知——轮询是反复打扰,通知是一次到位。

4. 隔离实验:/fork 复制会话进独立 worktree,自动 commit+push。实验和主线物理隔离,坏了不影响主线,好了直接合。git 冲突 130 次(见开篇矩阵)的部分缓解,靠的就是这一条。

5. 跨机器:v2.1.225 起,可以向其他机器的会话发起对话。多机协作时,同步不再依赖人工转发,机器之间直连。

这五步合起来,把"人工传话"降级成"机器直连"。接口变更、状态同步、实验隔离,各自有产品能力兜底。矩阵里 git 冲突那一格写着"部分缓解":worktree 隔离把并发写同一文件的冲突挡在门外,但跨工程的文件归属冲突,还需要流程层面解决。

主线六:安全产品化,Claude Security 插件

主攻痛点:凭据与敏感信息泄漏(纪律类,无失败计数)

六项更新里最短的一章,但分量不轻。我们仓库里有一份凭据管理规范,讲的全是"纪律":secret 不写明文、凭据走环境变量、发现泄漏立即轮换。纪律靠人,人总会忘——规范写得再细,也拦不住一次手滑。

Claude Security 插件把防护从提示词纪律变成产品能力:敏感信息检测、凭据扫描,从"写完自查"变成"系统拦截"。它与凭据管理规范互补:规范定义该怎么做,插件保证做不到的时候有人兜底。

安全这条线,最好用的状态是"没有故事"。60 天里,凭据管理规范覆盖的会话中,未发生一起密钥泄漏——这个"零"是纪律的功劳。Claude Security 插件的价值,是把"零"从纪律的成果变成系统的默认。这一章没有数据,因为它的价值恰恰体现在数据的缺失上。

结尾:升级清单,和没治好的病

回到交叉矩阵,结论分三类:

• 治好的:sandbox 拦截 97 次、Prompt-too-long 13 次、Agent terminated 22 次,分别被 auto mode 默认化、1M context、上限移除治好;/compact 71 次频率下降;rate_limit 84 次部分缓解。
• 治不了的:TAPD API 失败 248 次、timeout 179 次、file-not-read 147 次。这是流程病——接口不稳定、文件路径对不上,是流程设计问题,不是产品问题,版本更新再快也治不了。
• 部分缓解:git 冲突 130 次,worktree 隔离把并发写同一文件的冲突挡在门外。

五条可执行的升级清单:

1. 升级到最新版——本文所有能力都依赖版本,旧版本一样都拿不到
2. 开 fork——旁支任务隔离,顺手省输入侧的钱
3. 开 Concise——输出侧瘦身,长会话越用越省
4. 配 --max-budget-usd——给失控上硬闸门,不等账单
5. 多会话用 SendMessage——把人工传话换成机器直连

最后留一个钩子。矩阵里最大的两个数字——248 次 TAPD API 失败、147 次 file-not-read——和版本无关,和流程有关。它们值得单独一篇:接口不稳定怎么治,文件找不到怎么防。下一篇,我们聊聊流程病。

免责声明

本文内容仅供学习交流,所述方法需结合实际场景灵活运用。AI 工具输出结果仅供参考,关键业务决策请结合人工判断。

本文由 AI 辅助创作,经人工审核编辑后发布。

---

《智能编码进化论》特别企划 · 数据报告体 · 2026-08-25