技术 · 深入
子代理的活，越窄越稳
判断留主线，读写交子代理
这是按职责边界给主线程和子代理分工的方法：主线负责理解需求、定方案、做最终判断，子代理只接读多写少的窄活（查文件、读代码、跑检查），一个子代理对应一类动作。解决的是「子代理什么都能干，结果什么都只干一半、主线还得整段重做」的问题。
方法 · 一图看懂
1
主线定方案 — 理解需求、拆方案、做最终判断，这三件事不下放。
2
划窄职责 — 子代理只做读多写少的活：查文件、读代码、跑检查；一个子代理只对应一类动作。
3
写进规则文件 — 分工写进 AGENTS.md 与 config，而不是每轮口述一遍。
4
五步启动 — 先侦察→主线判断→确认后修改→跑最小测试→主线汇报。
5
保留判断 — 子代理的输出只作材料，结论由主线写。
档位差异：按力气分 vs 按职责分
初档只关心「这一步该用多大的模型」，深档多出一层职责边界：子代理该多窄。判断标准有两条——①这个动作是不是读多写少（是就适合下放，否则留主线）；②它需不需要知道全局（需要就别下放，给了它也处理不好）。七牛云的 Codex 教程把这套落到配置里：主线程用强模型负责理解与判断，子代理用轻模型做查文件、读代码、跑检查，scout 与 fixer 两个窄职责 Agent 写进 config，再把分工规则写进 AGENTS.md。
三个必须写清的边界
①不承诺总 Token 下降——子代理会独立调用模型，拆开可能更贵，收益在「主线上下文干净」，不在省钱；②「只读」是角色指令，不是沙箱——想让子代理真的写不了文件，只能靠权限控制，不能靠提示词；③写操作要回主线确认——子代理只报告「建议怎么改」，改不改、怎么改由主线定。这三条不写清，子代理越用越像「另一个乱改东西的自己」。
原理 · 为什么有效
为什么有效：主线的上下文是最贵的资源。让它去读十几个文件、翻几十屏日志，真正需要判断的时候上下文已经被材料占满，判断质量随之下降。把读多写少的活下放给窄职责子代理，主线只接收结论性的材料（在哪、是什么、建议怎么改），上下文占用被压缩；同时窄职责让子代理的产出变得可预期——它只做一类动作，输出格式固定，主线核对成本低。分工真正的收益，是让判断那一步始终在干净的上下文里进行，而不是把任务并行跑得更快。
适用场景
适用：任务需要大量读文件、读代码、跑检查才能判断，而真正要动脑的只有几步——代码排查、仓库摸底、日志筛查、上线前检查。不适用：任务本身就是以「写」为主（一口气写完一个模块），下放再收回反而多一轮；也不适合子代理必须知道全局才能做的判断——它看不到全貌，交回来的结论只会是残缺的。更不适合把提示词当权限：需要真正限制子代理能力时，必须落到运行时权限。
自测 · 5 问
这个动作，是不是读多写少？
子代理要不要知道全局才能做对？
分工是写在规则文件里，还是我每轮口述一次？
我把「只读」当成了权限，还是只当成了角色指令？
子代理交回来的是材料，还是我又让它直接给结论了？
怎么上手 · 验证步骤
第一步，把当前任务按「读」和「判」分开：读材料、查文件、跑检查的归子代理，定方案、写结论的留主线。第二步，建 1 至 2 个窄职责子代理（例如 scout 只负责查、fixer 只按指令改），把职责与输出格式写进 AGENTS.md 和 config。第三步，用固定五步启动：先侦察→主线判断→确认后修改→跑最小测试→主线汇报。第四步，跑两轮后回看：主线的上下文是不是变干净了、返工是不是变少了。
跑完一轮检查三件事：主线是不是还在读原始文件（是说明下放不够）；子代理的输出是不是还要主线重新整理一遍（是说明输出格式没定）；有没有出现子代理越权改文件（有说明「只读」只写在了提示词里）。