三层编排配方主会话子代理顾问

一条千赞的实操贴把 Claude Code 的三层编排写成了可直接抄的配方：主会话放最高推理档，只做计划与交付；三个子代理——读代码的探索者、改代码跑测试的执行者、查文档的研究者——统一压在中档跑例行工作；再挂一个顾问模型常驻待命，平时一言不发，只在三个时刻开口。

官方文档在 code.claude.com/docs/en/adviso… ，配置项逐条列了对照。

三个触发点是这份配方里最值钱的部分：计划成型之前问一句"这个方向对吗"，同一个错误反复出现时问一句"我是不是找错地方了"，任务自称完成之前问一句"我漏了什么"。这三处恰好是人类代码评审里最常出价值的位置——方向性错误、盲区、收尾疏漏——让读过全部会话与每一次工具调用的顾问在这三处开口，等于把评审集中在刀刃上，而不是每一步都打断。

"高档规划、中档执行、顾问待命"这条原则可以往下再套一层。同构的做法在决策模型上也成立：不需要动脑的分叉——选哪个文件、调哪个工具、重试还是停——交给轻量模型半秒内处理，大模型只看真正需要判断的节点。两层结构说的是同一件事：把确定性的工作压到便宜的层，把判断留给贵的层，贵层被调用的次数决定账单。

配置落地有三个容易漏的点。子代理的角色如果已有现成的就不要重建，只补缺的角色并统一设中档；主会话的推理档位与顾问模型写进全局设置；最关键的是排查那些会静默关掉顾问的开关——环境变量里禁用顾问工具、禁用特性开关的配置，会让上面的三层结构形同虚设，三层跑成了两层甚至一层，账单又回到单层烧钱的状态。文档里对这几项都有对照清单，逐条核对一次即可。

这套结构对账单的影响可以直接算。单层用最高档跑全部调用，等于让计划、检索、执行每一步都付最高推理的钱；分层之后，最高档只出现在计划成型和交付验收两处，检索与执行这类占大头的调用落在中档，顾问更是只在三个触发点产生消耗。按典型任务的调用比例估算，最高档调用次数能降一个数量级，而任务质量的差异主要取决于计划与验收两处的准确度，恰好是保留最高档的地方。

子代理的角色划分也有讲究。探索者只读不改，避免读代码的过程污染编辑上下文；执行者带着明确任务去改并跑测试，产出可验证的结果；研究者负责把外部文档压缩成摘要回传。三个角色都设中档，是因为它们的输入输出结构固定——给定文件或给定问题，产出是确定格式的答案，这类任务对推理深度不敏感。真正需要深想的是"下一步该做什么"，那属于主会话。

"每改动一项都留 diff"的验收习惯同样重要。贴子里的提示词特意要求先给出全部改动对照、经确认后才动手——这把一次性大改拆成可审阅的小步，也和三层结构的思路一致：贵的模型负责把关，便宜的模型负责生产，人类只在结构变化时出现一次。

跨工具迁移时，配置的可移植性决定这套结构的寿命。角色定义、触发规则、验收标准尽量写进与具体工具无关的描述文件，换工具时迁移的是规则而不是重学一套。绑定某一家工具的专有开关越多，下次迁移的代价越大；能平移的配置才是真正沉淀下来的资产。

盘点自己任务的顺序值得照抄：把最近一周的工作按"需要判断"和"重复执行"分两堆，前者标进高档队列，后者写成可复用的子代理；再把三个顾问触发点写进项目协作说明，让每次计划、报错、交付都强制过一次这三问。改动不大，但模型调用结构会立刻从单层烧钱变成三层分工。