Codex Subagents 配置更新:GPT-6.1 Sol、Luna 怎么分工?明确要求才调用

AI教程

Codex Subagents 配置更新:GPT-6.1 Sol、Luna 怎么分工?明确要求才调用

3559 字 18 分钟

大家好,这里是一万 AI 分享,我是一万。

2026 年 10 月 2 日更新: 这次按我本地的 AGENTS.md、config.toml 和 agents/*.toml 更新使用逻辑:explorer 保留 GPT-6 Luna Max,开发与复查改用 GPT-6.1 Sol,complex_worker 改为 Sol Max。更重要的是,主 Agent 默认独立完成任务,只有我在当前会话明确要求使用子 Agent 时,才在指定任务范围内调用。 任务复杂、适合并行或需要复查,都不能代替这一步明确要求。

本文记录的是我本机当前采用的配置,不代表旧模型已下线,也不代表所有账户都能使用相同型号和推理等级。复制前先检查自己的 Codex 客户端和账户支持情况;模型可用性与弃用信息以 OpenAI 模型目录、弃用公告 及实际客户端为准。

为什么要重新配置 Subagents?#

Codex 的子 Agent 可以独立探索、编写代码或审查结果。根据 Codex Subagents 官方文档,如果没有为子 Agent 指定模型和推理等级,它可能继承父 Agent 的设置。主 Agent 选了 Astra,不代表每个负责搜索文件的子 Agent 都需要 Astra。

不过,继承模型不等于额度必然“几分钟熔断”。消耗量取决于实际调用次数、上下文、并发量和账户限制;子 Agent 也会带来额外上下文与协调开销。下面是我早期使用时的额度截图,仅作个人经历展示,不是所有账户都能复现的固定结果。

早期使用 Astra 时的额度截图
早期使用 Astra 时的额度截图

早期使用 Astra 时的额度截图
早期使用 Astra 时的额度截图

因此,这次调整既更新模型分工,也把调用时机交回用户:先明确是否需要子 Agent,再按任务选择角色,避免无意义的额外调用。

当前本机分工:谁来指挥,谁来干活?#

角色本机实配模型与推理等级什么时候使用
主 Agent保持用户手动选择的模型和推理等级默认独立完成任务,负责拆解、重大决策、验收与汇总;用户明确要求后才委派
explorergpt-6-luna · max · 只读有明确边界的代码搜索、文件定位和资料整理
workergpt-6.1-sol · medium常规开发、修复和相关测试,只修改分配的文件或模块
complex_workergpt-6.1-sol · max需要更高推理预算的高歧义、跨模块复杂任务
reviewergpt-6.1-sol · high · 只读独立检查真实差异、正确性、安全、回归和测试缺口
未指定角色时的默认子 Agentgpt-6.1-sol · medium为已授权的调用提供默认值,不是自动调用的许可
sol_advisor_sol_reviewer不固定模型与推理等级;调用时显式传入主 Agent 实际手动选择的值仅在用户明确指定 Yiwan Sol Advisor / sol-advisor:orchestration,且明确要求本任务使用子 Agent 时,承担该流程的只读终审

上表来自本地配置文件的静态检查。角色、模型和推理等级以 ~/.codex/agents/*.toml 为配置来源;未指定角色的默认值保留在 ~/.codex/config.toml 的 [agents] 中。全局 AGENTS.md 只记录调用边界和调度规则,不再重复维护模型映射,避免改了一处却漏掉另一处。实际运行是否使用这些设置,仍要看启动记录。

并发建议: 先把最大并发设为 4。这是本文的保守建议,不是官方规定的最佳值。并发上限不是任务指标;单文件小修或紧密耦合的工作,主 Agent 自己做往往更稳。

本机对应的配置如下,已有配置时应合并到原来的 [agents],不要重复添加同名表:

[agents]
enabled = true
max_concurrent_threads_per_session = 4
default_subagent_model = "gpt-6.1-sol"
default_subagent_reasoning_effort = "medium"

这里的 enabled = true 表示启用工具能力,不表示允许自动调用。max_concurrent_threads_per_session 限制同时打开的子 Agent 线程,不包含主 Agent;具体含义见 官方配置说明。

调用边界:明确要求以后再分工#

我现在把这几条规则放在全局 AGENTS.md 中:

  • 默认由主 Agent 独立完成。只有用户在当前会话明确要求子 Agent、多 Agent 或并行 Agent,才在指定任务范围内调用。
  • 复杂度、复查收益、规则、Skill 或主 Agent 判断都不能代替用户明确要求;授权不延伸至无关任务或其他会话,撤回后停止新增调用。
  • 子 Agent 不得自行扩展团队。派生任务也需要当前用户对该任务的明确授权,以及主 Agent 的具体分配。
  • 每项工作一个责任 Agent;可写 Agent 不并发修改同一文件或强耦合模块。主 Agent 检查实际差异与验证证据。
  • 仅在实际调用后汇报参与角色、实际模型、已确认的推理等级、成果和未完成事项;没有调用就省略这段汇报。

普通的“帮我修复这个问题”不触发子 Agent;“请用子 Agent 检查登录模块,主 Agent 汇总结果”才明确授权了该任务的委派。后者也不授权其他模块或下一次会话的调用。

我本地还装有 Yiwan Sol Advisor。只有明确指定该流程时才进入它;进入流程本身不扩大子 Agent 或其他操作的授权。其 sol_advisor_sol_reviewer 不写死模型和推理等级,主 Agent 调用时必须显式传入自己实际手动选择的值,否则可能落到通用子 Agent 默认值;无法确认时先澄清。

可直接复制:新版“让 Codex 配置 Codex”Prompt#

下面这段 Prompt 的重点是先检查、再备份、最小合并、最后验证。配置完成后默认仍由主 Agent 独立工作;真实子 Agent 试跑需要单独明确要求。

请帮我在这台电脑上配置 Codex Subagents。目标是采用 GPT-6.1 Sol/GPT-6 Luna 的角色分工,并且仅在我于当前会话明确要求使用子 Agent 时才调用。本次只授权检查和修改配置,不授权启动子 Agent。请以当前 Codex 官方文档和本机实际支持的配置为准:
https://learn.chatgpt.com/docs/agent-configuration/subagents?surface=app
一、先做只读检查,不要立即改文件
1. 找到实际 CODEX_HOME;未设置时再检查当前用户的 ~/.codex。读取 Codex 版本、config.toml、agents/ 目录、全局 AGENTS.md,以及当前项目的 AGENTS.md。识别已有自定义角色、同名覆盖、模型和推理等级设置。
2. 检查本机/当前账户能否选择 gpt-6.1-sol、gpt-6-luna;核对各自支持的 reasoning 等级。不能确认时标注“未验证”,不要假装已验证,也不要自行换成其他型号。
3. 检查原有审批、沙箱、Skills、MCP 和其他自定义规则;这些与本任务无关,不得重置或覆盖。发现冲突、无法安全合并或模型不可用时,先说明问题和最小解决方案,再等我决定。
二、在确认可执行后,备份并最小修改
1. 为即将修改的文件制作可恢复备份,记录原路径、备份路径和时间。保留 UTF-8 编码;合并已有内容,不要覆盖整个 config.toml 或 AGENTS.md。不要打印或复制 auth.json、API Key、Cookie 等凭据。
2. 保留我当前手动选择的主 Agent 模型和推理等级,不改全局主模型。配置 Subagents 默认模型 gpt-6.1-sol、默认 reasoning medium,最大子 Agent 并发线程数 4;仅使用当前版本官方支持的配置键。如果已有更严格或更合适的并发限制,先说明,不要擅自放宽。启用工具不代表允许自动调用。
3. 优先复用/覆盖内置 explorer、worker,避免重复角色。为以下普通角色同时明确 model 与 model_reasoning_effort,避免意外沿用其他推理档位;Sol Advisor 专用角色按第 6 项处理:
- explorer:gpt-6-luna,max,read-only;只做定向搜索、读取和定位。
- worker:gpt-6.1-sol,medium;负责有边界的开发、修复和相关测试。
- complex_worker:gpt-6.1-sol,max;处理需要更高推理预算的高歧义、跨模块复杂工作。
- reviewer:gpt-6.1-sol,high,read-only;独立检查正确性、安全、回归和缺失测试,不代替实际测试。
每个自定义角色按官方格式提供 name、description、developer_instructions。不要为了凑角色而创建无用途的重复 Agent。
4. 在全局 AGENTS.md 中以简短、可识别的小节记录调度规则;若已有同类小节,更新而非叠加。不要在 AGENTS.md 重复模型映射,角色设置以 agents/*.toml 为准,通用默认值以 config.toml 的 [agents] 为准。规则必须包含:
- 主 Agent 保持用户手动选择的模型,默认独立完成任务,负责拆解、重大决策、验收和汇总。
- 只有用户在当前会话明确要求子 Agent / 多 Agent / 并行 Agent 时,才可在指定任务范围内调用。复杂度、复查收益、规则、Skill 或主 Agent 判断均不能代替用户明确要求;授权不延伸至无关任务或其他会话,撤回后停止新增调用。
- 获得明确要求后,按任务选择必要角色,复用已有结果,不为凑角色而调用。每项工作一个责任 Agent;可写 Agent 不并发修改同一文件或强耦合模块,主 Agent 检查真实差异和验证证据。
- 子 Agent 派生任务也必须具备当前用户对该任务的明确授权和主 Agent 的具体分配,不得间接扩张授权。把这条边界写入每个角色的 developer_instructions。
- 任何 Agent 都不得越过当前用户授权、审批或项目规则。
5. 不要添加“关闭 Fast”之类无法从当前官方配置确认支持的字段,也不要写死未来所有任务必须调用子 Agent。
6. 如果本机已安装 Yiwan Sol Advisor,保留其专用角色与流程;未安装则不额外安装。仅用户明确指定 Yiwan Sol Advisor / sol-advisor:orchestration 时进入该 Skill,不因此扩大子 Agent 或其他操作的授权。sol_advisor_sol_reviewer 不固定 model 或 model_reasoning_effort;调用时显式传入主 Agent 实际手动选择的模型和推理等级,不能套用通用默认值,无法确认时先澄清。
三、验证并交付证据
1. 检查修改后的 TOML 能解析,角色文件和全局规则无重复冲突;给出具体修改文件与备份位置。
2. 本次只做静态验证,不启动子 Agent。只有我随后明确要求在当前任务中使用子 Agent 试跑,才在指定范围内执行;不自行追加 worker/reviewer 测试。区分“配置静态有效”和“真实子 Agent 已启动”。实际试跑时从启动记录核实角色、模型与推理等级;无法从记录确认的项目标为“未验证”,不得凭配置文件推断运行时已生效。
3. 汇报测试结果、尚未验证的环节、恢复备份的明确命令或步骤。不要声称“额度一定降低”或“绝对只读”。若发生解析错误或测试失败,先停止并恢复本次改动,说明原因。
以后仅在实际调用 Subagent 后,简要汇报实际角色、模型、已确认的推理等级、成果和未完成事项;未确认的模型或推理等级写“未确认”,不要编造文件数、测试数或不存在的 Reviewer 结论。无调用时省略。

为什么普通角色要同时指定模型和推理等级? 官方文档说明,角色文件只设置模型时,会保留此前解析出的推理等级;显式调用参数、[agents] 默认值和父级设置都可能影响解析结果。因此普通角色同时写明两项,减少意外沿用其他档位的情况。Sol Advisor 的专用终审角色是本机规则中的例外:它由调用者显式传入主 Agent 实际设置。查看配置优先级说明

配好以后,怎么判断它真的生效?#

完成静态检查后,再明确授权一个范围很小的只读任务试跑,例如:

本次明确要求使用一个 explorer 子 Agent,只读定位这个项目的登录鉴权入口,
告诉我相关文件和调用顺序;主 Agent 汇总并检查证据。
不要修改文件,不要调用其他角色,也不要派生更多子 Agent。
请汇报实际启动的角色,以及能从启动记录确认的模型和推理等级;
无法确认的项写“未确认”。本次授权仅限这个定位任务。

看三件事:是否真的启动了子 Agent、它实际使用了什么模型、它有没有越过只读任务的边界。config.toml 写对了,只能证明静态配置;看到子 Agent 的运行记录,才能证明这次调度实际发生。也不要根据一张额度截图,就断言你的账户会节省多少。

Codex 子 Agent 调度示例截图
Codex 子 Agent 调度示例截图

还有一个容易忽略的细节:自定义角色的 sandbox_mode = "read-only" 可以限制其工作方式,但实际权限仍受当前会话及平台策略影响,不能把一个配置字段描述成绝对不可突破的安全隔离。重要仓库依然要做好 Git 版本管理与备份。查看官方权限说明

最后说一句#

我现在的配置是 Luna Max 做窄范围探索,GPT-6.1 Sol Medium 做普通开发,Sol Max 做复杂任务,Sol High 做独立复查。主 Agent 继续使用我手动选择的设置;日常默认自己完成,只有当前会话明确要求后才委派。

模型和限额会变化,分工原则比某一组写死的型号更长寿。复制 Prompt 前先看一眼你的模型菜单;执行后再看运行证据,别把“配置成功”误当成“实际调度成功”。

我是一万,我们下期见。

支持与分享

如果这篇文章对你有帮助,欢迎分享给更多人或赞助支持!

赞助

目录