子代理的价值是隔离过程信息
整理于 2026-07-16。参考《拯救 5.6 Sol｜用子代理隔离上下文：Codex Multi-Agent 工作流总结与思考》与 Codex Subagents 官方文档。本文沉淀工作流原则，不把模型名、实验开关和配置字段当成长期事实。
Multi-Agent 的核心价值不是“同时多几个模型思考”，而是把不同生命周期的信息放进不同上下文：
- 主上下文保留需求、约束、架构事实、决策理由和最终验证状态。
- 子代理上下文承接搜索结果、测试日志、失败路径、外围材料和临时假设。
- 返回主上下文的内容应是压缩后的事实、出处、推断和未覆盖范围。
当检索过程留在临时线程、稳定结论带着出处返回时，子代理实际承担的是一个可核验的信息压缩层。并行只是可能获得的额外收益，不是使用子代理的充分理由。
主代理与子代理需要非对称分工
如果多个 Agent 都能自由分析、决策、修改和验证，系统很快会出现重复劳动、写入冲突和责任不清。更稳定的分工是：
| 工作对象 | 默认责任方 | 原因 |
|---|---|---|
| 需求解释、边界和任务拆分 | 主代理 | 这些信息决定整项工作的方向 |
| 跨文件检索、日志分析、测试结果归纳 | 子代理 | 读取范围宽、过程噪声大，适合独立压缩 |
file:line、符号名、关键原文和缺口说明 | 子代理 | 为主代理提供低成本复核抓手 |
| 架构取舍、最终判断和代码修改 | 主代理 | 保持单一决策与写入责任 |
| 关键证据抽查、最终测试和交付 | 主代理 | 子代理结果是输入，不是责任转移 |
这不是能力高低的划分，而是上下文和责任的划分。子代理可以很强，但它的交付物仍应是证据包；主代理可以依赖证据包，但不能把最终责任一起外包。
是否委派取决于总成本
任务大，不代表一定适合拆给子代理。可以用一个简单模型判断：
直接处理成本
= 定位 + 阅读 + 综合
委派成本
= 定义任务 + 派发与等待 + 子代理执行
+ 结果压缩 + 证据抽查 + 协调开销当委派成本更低，或者独立上下文能明显提升核验价值时，才值得委派。
适合委派的任务通常同时具备几个特征：
- 范围宽，读取量或日志量大；
- 子问题彼此独立，可以并行；
- 边界清晰，能用明确输出验收；
- 以探索、测试、排查、归纳为主；
- 即使失败，也不会直接污染最终产物。
更适合主代理直接处理的内容包括：
- 已知位置的小文件、少量代码或单一事实；
- 即将修改的确切代码；
- 决定后续判断框架的架构文档、设计文档等奠基材料；
- 描述任务和复核结果的成本不低于直接完成的工作。
委派任务本质上是一份可验证的 Spec
隔离上下文之后，子代理无法依赖主线程里的隐含信息，因此任务必须自包含。一个可用的委派合同至少包含：
- 目标：要回答哪个具体问题。
- 范围：允许读取哪些目录、文件、日志或数据。
- 边界：哪些内容不处理，是否禁止修改和继续派生。
- 证据格式：是否必须返回
file:line、符号名、命令输出或关键原文。 - 覆盖声明：查过什么、没查什么、哪里存在冲突或不确定性。
- 返回结构：事实、推断、缺口分开表达。
可以把默认返回模板压缩成：
结论：
事实：
证据：
推断：
未覆盖与存疑：这和把需求写成可验证的 Spec是同一个思路：先定义什么算完成，再让执行过程围绕可复查的结果展开。
复核的目标是抽查，不是重做
子代理摘要不能直接当作事实，但复核也不应变成重新通读全部材料。更合理的方式是沿着它提供的路径、行号、符号名和关键原文抽查承重结论。
如果主代理每次都需要完整重读子代理处理过的范围，说明至少有一项出了问题：
- 任务本来就不适合委派；
- 子代理没有返回足够精确的出处；
- 输出没有区分事实与推断；
- 主代理没有提前定义验收标准。
有两类内容仍应由主代理亲自完整阅读：即将修改的确切代码，以及建立全局判断框架的奠基材料。子代理可以帮助定位，但不能替代主代理建立一手理解。
常见失效模式
| 失效模式 | 表现 | 修正方向 |
|---|---|---|
| 伪并行 | 派发后主代理继续做相同搜索，多个线程重复劳动 | 派发独立子问题，等待结果后再综合 |
| 摘要无证据 | 只有结论，没有路径、行号或关键原文 | 把出处和覆盖声明写进委派合同 |
| 上下文全量继承 | 子代理带着主线程的噪声和既有假设做核验 | 只传任务必需背景，减少无关历史继承 |
| 并行写入 | 多个 Agent 同时修改同一工作区 | 默认把子代理限制为读取、测试和核验 |
| 递归扩散 | 子代理继续拆分，调度树失控 | 限制嵌套深度，由主代理统一编排 |
| 配置即原则 | 把某个模型名、实验开关或字段复制成永久方案 | 原理长期保存，配置按当前版本核验 |
我的默认工作流
- 先确定哪些信息必须留在主上下文：需求、边界、架构事实、决策和验证状态。
- 主代理亲自阅读奠基材料和即将修改的代码。
- 把宽而重、彼此独立、以读取为主的工作拆成自包含任务。
- 要求子代理返回带出处的证据包，而不是泛化总结。
- 派发后避免重复探索；结果返回后抽查关键出处，再做方案取舍。
- 由主代理完成修改、最终测试和交付说明。
衡量这套工作流是否有效，不看同时启动了多少 Agent，而看四个结果：
- 主上下文是否更干净；
- 关键判断是否能沿出处复核；
- 总耗时和总消耗是否下降；
- 最终正确率是否提高。
Codex 配置的版本边界
截至 2026-07-16，Codex 官方手册说明：当前本地客户端默认具备子代理能力，可由用户明确请求，或由适用的 AGENTS.md、Skill 指令触发；自定义 Agent 放在 ~/.codex/agents/ 或项目级 .codex/agents/；全局并发和嵌套限制仍记录在 [agents] 配置下。
参考文章里的 multi_agent_v2、特定模型名、元数据隐藏和等待参数属于特定版本或环境快照，不能直接当作长期配置指南。更值得保留的是背后的约束：
- 子代理尽量少继承无关上下文；
- 轻量探索与复杂决策使用不同资源；
- 控制并发、嵌套和写权限；
- 当前字段和默认值以使用时的官方文档及客户端行为为准。
具体配置问题继续放在Codex config 配置说明中维护，避免原理笔记被版本细节淹没。