关于 Claude code 子代理的小测试，引发对自己使用习惯上的思考

引言: 这是一个我只是想了解 claud code 如何锁定子代理为 sonnet5 ，然后主代理 opus4.8 主动提出可以做 sonnet5 vs opus4.8 的 debug+对抗性审查的测试，最后 opus 发现自己也有问题的故事。

过程：

1. 开始

提示词 1

进行一个和项目无关的小测试，关于子代理：
刚才在 vscode 的 claude code 插件里设置了 `environmentVariables`
`{ "name": "CLAUDE_CODE_SUBAGENT_MODEL", "value": "claude-sonnet-5" }`
你照常调用下子代理随便做点什么，看看是否生效呢

第一阶段回答:

更推荐的做法：分层控制
默认不设这个 env 变量，让子代理继承父会话模型（你主力 Opus 时，子代理也 Opus ，语义一致）。
在具体 agent 的 frontmatter 里按需降级——.claude/agents/*.md 加 model: claude-sonnet-5 ，只给 Explore 、纯搜索类代理设。重推理的 arch/Plan 保持 Opus 。
临时需要时，派生那一次传 model 参数覆盖即可。
这样"省钱"和"保质量"是两个独立旋钮，而不是一个。

什么时候全局 Sonnet 反而 OK
你日常主力就是让子代理干搜索/探索/批量机械活，几乎不用它们做深度规划；
或者你本身是成本/速度优先，愿意接受个别重活质量略降。
那么你现在这套设置就挺合理，属于合法的偏好选择，谈不上"错"。

一句话建议：如果你会用到 arch 这类规划型子代理，别用全局 env 一刀切；改成"默认继承 + 给轻量代理单独在 frontmatter 里降 Sonnet"。如果你几乎只拿子代理做搜索杂活，那保留现状也没问题。

优先级链最后那环（ env 变量 vs. frontmatter 谁大）我有把握但没在你机器上实证——要的话我可以起一个带 model: frontmatter 的临时子代理测一下，确认 frontmatter 能压过这个环境变量。

2. GO ON

提示词 2

如果是 ultracode 模式让子代理对抗性审查呢？ sonnet5 是否足够

Opus 回复并启动

你开了 ultracode ，我就搭一个小对抗审查工作流：拿同一段（我故意埋了 3 个难度递进 bug 的） Go 代码，让 Sonnet 5 和 Opus 4.8 各跑 3 个独立的对抗审查子代理，再用一个强模型裁判对照 ground truth 打分。这样"Sonnet 5 够不够"就有数据了。

先看我埋的题（子代理看不到答案，只有裁判看得到）：

Bug 1 （并发·中）：Release/Available 没加锁，和持锁的 Allocate 竞争 map → 数据竞争/concurrent map writes panic
Bug 2 （越界·较隐蔽）：Allocate 循环 i < len-1 ，每次少扫一个槽 → 明明有空 IP 却误报 pool exhausted
Bug 3 （边界·隐蔽）：NewIPPool 不校验空切片 → % len 除零 panic

最终审查回答 (笑

图一乐的同时，不禁想到某种弊端，审查者 review 的对象是代码，用 n 个审查者可以更全面的找到问题。

但 judge 始终只有 1 个，那么 judge 出问题，只有人类亲自检查。但是在越发浮躁的 vibe coding 时代，真的会有耐心去挨个看子代理的返回结果吗？

那么 coding agent 的下一个发展方向，会是多 judge 交叉 review reviewer 的结果再出一份报告吗🙈

彩蛋

User:

"哈哈你干的不错，和你协作很愉快"

Opus:

" 😄 我也挺享受这轮的——你给的这个"顺手验一下"的小测试其实挺有意思:本来是个配置确认题,结果一路做成了"用对抗审查去审查我自己对对抗审查的解读",最后还真把我一句过度自信的话给揪出来了。这种能被数据打脸、也愿意认的协作,做起来确实痛快。

留个小尾巴给你,回到你最初的实际决定:

finder 用 Sonnet 5 → 放心用； judge 用哪个 + 全局一刀切还是按角色配 → 别照搬我的先验,你真在意就自己各跑几轮测一下,而且别只信一个裁判 "