我给 Codex 写了一份“员工手册”。下一次任务里，研究员跑在 Terra medium，机械整理交给 Codex Spark medium，独立审稿却升级到 Sol high。我用 Sol Ultra 做总负责人，但没有把每件事都交给最强、最贵的模型。
我原本以为，换上 GPT-5.6 Sol Ultra 以后，最大的变化会是答案更好、上下文更长、代码更强。结果真正让我兴奋的，是终端里几行不起眼的状态：同一个任务，几个 Subagent 正在使用不同模型、不同推理深度。 长材料研究被分给 Terra medium，短文本整理落到 Codex Spark medium，到了高风险的独立复核，又切回 Sol high。这一刻我意识到：GPT-5.6 Sol Ultra 真正值得讨论的，可能不是“一个更强的大模型”，而是它开始像我的技术负责人——自己抓总，把不同工作派给不同的大脑。
先说清楚：这不是 Sol Ultra 看一眼任务就凭空变出的魔法。
我提前在 AGENTS.md 里写了一套分工制度，又为不同角色配置了模型、推理深度和权限。我让 Sol Ultra 读懂这些规则、拆任务、调度 Subagent，再把结果收回来验收。
真正让我兴奋的，是这套机制已经从“我每次手工点模型”，变成了“把组织规则写进项目，以后反复执行”。
我不再让最强模型亲自做完所有工作
我最初使用大模型时，也有一个很朴素的逻辑：
越难的问题，我就用越强的模型；既然已经选了最强模型，我就让它包办一切。
但我面对的真实工作从来不是一道孤立的题。
我做一次技术调研，里面可能同时有资料搜索、长文阅读、表格整理、代码验证、事实复核和最终写作。这些环节对智能、速度、上下文、成本与权限的要求完全不同。
让 Sol Ultra 从头到尾亲自做，当然能做。但在我看来，这就像请来一个 CTO，让他白天逐页抄数据，晚上再审核自己的结论。
这样一来，我没有把能力用在刀刃上，也没有真正获得独立复核。
OpenAI 最新的模型说明其实已经给了我一套清晰分工：我可以把 Sol 用于复杂推理与编码，让 Terra 在智能和成本之间取平衡，再把 Luna 留给成本敏感、高吞吐的工作负载。Codex 的 Subagent 文档更直接：我可以把读多写少的探索、大文件审阅和辅助材料处理交给 Terra；把近即时、纯文本迭代交给 Codex Spark。更重要的是，如果我有 ChatGPT Pro 订阅，Spark 在研究预览阶段有独立的 rate limit，其消耗不计入标准额度，因此我可以用它减少主模型的标准额度消耗，进一步分层使用资源；但这项独立限额会随需求调整。复杂逻辑和边界检查，我则会提高 reasoning effort。（见文末参考资料 1、4、6）
所以，我现在追求的用法不再是“永远选最强”。
而是：我让最强模型负责分工、判断和验收。
我看到的三次分流
第一类，是长材料研究。
它要读很多文件、理解图片、跨材料找矛盾，但不一定需要最高强度的最终判断。我把它交给 Terra medium。它像一个速度很快的研究员，先把大量材料压缩成主线程能消费的证据。
第二类，是短、纯文本、低风险的整理。
比如把既有内容转成固定结构、抽取字段、整理清单。这类工作机械、边界清楚、结果容易复核，我让 Codex Spark medium 来做。这里追求的不是“多想十分钟”，而是低延迟地把活干净做完。
第三类，是高风险独立复核。
当内容涉及安全、权限、发布边界，或者一个判断一旦错了就会造成明显损失，我会再启动一个只读 reviewer，使用 Sol high。它不参与前面的写作，只负责找问题、查假设和守住边界。
在我的工作流里，这三个 Agent 不是谁替代谁，而是在同一条生产线上承担不同工位。
我不是靠一句提示词，而是靠三层配置让它生效
第一层：AGENTS.md 是“组织制度”
我把 AGENTS.md 当成持久的项目指导。OpenAI 官方说明，它会在 Agent 开始工作前生效，我可以在其中记录审查要求、项目约定和目录级指令。（见文末参考资料 2）
更关键的是，我可以分层使用它：我把个人全局规则放在 ~/.codex/AGENTS.md，再在仓库和子目录继续放各自的 AGENTS.md；越靠近当前工作目录的规则优先级越高。（见文末参考资料 2）
因此，我会在全局文件里写下共同原则：
## Subagent 路由
- 主线程负责拆解、汇总和最终验收。
- 短、纯文本、低风险、易复核的任务，交给快速 Agent。
- 长上下文、图片或跨文件判断，交给研究 Agent。
- 安全、权限和发布前复核，交给只读 Reviewer。
- 并行写入前，必须划清文件所有权与验收标准。
我再在具体子项目里补充：这个项目哪些任务风险更高、哪些验证必须执行、哪些 Agent 不允许写文件。
我写下的不是一次性 Prompt，而是我的 AI 团队以后都要遵守的制度。
第二层：自定义 Agent TOML 是“岗位合同”
对我来说，仅仅写“找个研究员”还不够。我还要定义这个研究员是谁、什么时候调用、用什么模型、想多深、能不能写文件。
Codex 官方支持我把个人 Agent 放到 ~/.codex/agents/，或者把项目 Agent 放到 .codex/agents/。这里不是只建一个总配置文件，而是一个 Agent 对应一个独立的 .toml 文件。文件名理论上可以自定，真正的识别依据是文件里的 name；为了以后好维护，我让文件名和 name 保持一致。（见文末参考资料 1、5）
例如，我把研究员写进这个具体文件：
~/.codex/agents/research_reader.toml
name = "research_reader"
description = "阅读长材料、图片和跨文件证据，返回带出处的摘要。"
model = "gpt-5.6-terra"
model_reasoning_effort = "medium"
sandbox_mode = "read-only"
developer_instructions = """
只做研究，不修改文件。
区分已证实事实、推断和未知项。
向主线程返回精炼结论与证据位置。
"""
我再把独立 reviewer 写进另一个文件：
~/.codex/agents/risk_reviewer.toml
name = "risk_reviewer"
description = "对安全、权限和公开发布内容做独立复核。"
model = "gpt-5.6-sol"
model_reasoning_effort = "high"
sandbox_mode = "read-only"
developer_instructions = """
不要续写正文，只找真实风险。
检查事实依据、隐私泄露、权限边界和遗漏的反例。
按严重程度报告发现。
"""
我把模型、推理深度和权限都写在这份岗位合同里。若我省略这些可选项，官方文档说明它们会从父会话继承。（见文末参考资料 1）
如果我要把短、纯文本、低风险任务交给 Spark，我会再新建第三个文件：
~/.codex/agents/fast_text_worker.toml
name = "fast_text_worker"
description = "快速完成边界清楚、容易复核的纯文本整理。"
model = "gpt-5.3-codex-spark"
model_reasoning_effort = "medium"
sandbox_mode = "read-only"
developer_instructions = """
只处理纯文本整理、字段抽取和结构转换。
不要扩展任务范围，不修改项目文件。
把结果以便于主线程核验的结构返回。
"""
第三层：Sol Ultra 是“总负责人”
岗位都配好以后，我仍然需要一个主线程决定：这次任务要不要拆、拆成什么、哪些可以并行、何时等待、最后由谁验收。
这正是我把 Sol Ultra 放在总负责人位置的原因。
我不只让它输出最后一段文字。我让它维护目标和约束，判断何时调用哪个 Agent，过滤中间噪声，最后对交付物负责。
OpenAI 也解释了 Subagent 的另一个价值：把搜索记录、测试日志和中间输出移出主线程，避免有用信息被噪声淹没。子 Agent 返回的是摘要，主线程保留的是需求、决定和最终结果。（见文末参考资料 1）
一个容易被忽略的细节：不配置，也可能会选；但配置后才可控
官方文档写得很明确：如果我没有固定 model 或 model_reasoning_effort，Codex 可以按任务在智能、速度和价格之间选择配置。它可能让我的快速扫描偏向 Terra，也可能为更难的推理选择更高 effort 的 GPT-5.6。（见文末参考资料 1）
这让我确认，“动态选模型”本身已经进入产品机制。
但在自己的生产环境里，我不能只依赖“它大概会选对”。
对我而言，真正可用的系统必须允许我把关键边界写死：审稿必须独立、敏感任务必须只读、某类工作必须高推理、并行写入必须划分所有权。
所以我的做法是：普通任务允许继承，让 Codex 有选择空间；高风险岗位固定模型、推理强度和权限。
我把灵活性留给低风险工作，把确定性留给关键节点。
这套方法真正改变的，是 AI 的成本结构
我最初谈多 Agent 时，也容易只谈“更快”，但实际使用后，我还会算三笔更重要的账。
第一笔，是 token 账。
官方提醒我：每个 Subagent 都会独立进行模型和工具工作，多 Agent 通常比单 Agent 消耗更多 token。对我来说，并行不是免费午餐，我不能把每个任务都无脑拆成十份。（见文末参考资料 1）
第二笔，是注意力账。
我的主线程不再吞下所有搜索日志、测试输出和试错过程，长任务更不容易被中间噪声拖垮。我花更多并行 token，换来的是更干净的主上下文。
第三笔，是错误账。
我不再让写作者自己审自己。我把高风险复核交给独立、只读的 Sol reviewer，降低“前面一个错误假设一路传到结尾”的概率。
我做的不是简单省钱，而是把最贵的推理放到最值钱的位置。
我从三个 Agent 开始，而不是一次建十个
我自己的起点只有三个角色：
一个读多写少的研究员；
一个边界清楚的执行者；
一个只读的独立 reviewer。
然后，我在 AGENTS.md 里回答四个问题：
什么任务应该委派？
什么任务不值得委派？
哪些任务允许并行写入？
最终由谁验收，拿什么证据验收？
运行后，我不会只看 Agent 的昵称。我会打开各自线程，确认真正使用的模型和推理深度；同时检查它有没有遵守只读、写入边界和验证要求。
我会先让这三个角色配合稳定，再扩充自己的 AI 团队。
结尾：我不再只问“谁有最强模型”
我手里的 GPT-5.6 Sol 参数当然很强：官方给出的上下文窗口达到 105 万 token，最大输出 12.8 万 token，并支持多档 reasoning effort。（见文末参考资料 3、4）
但用过这套 Subagent 路由以后，我越来越觉得，下一阶段真正拉开差距的不会只是模型参数。
而是我能不能把经验写成制度，把任务定义成岗位，把风险设计成独立复核。
没有这些，我手里的最强模型只是一个非常聪明的个体。
有了这些，它才开始成为我的一支团队。
对我这个 AI 用户来说，真正稀缺的已经不只是会回答问题的模型，而是我能不能设计清楚：谁来回答、想多深、做到哪一步、最后由谁验收。
参考资料
OpenAI, Subagents
OpenAI, Customization / AGENTS Guidance
OpenAI, GPT-5.6 Sol Model
OpenAI, Models — Choosing a model
OpenAI, Configuration Reference
OpenAI, Introducing GPT-5.3-Codex-Spark
