你有没有过这种纠结：这个任务该用 Sol 还是 Terra？切到轻量模型是省了钱，但会不会丢精度？切回大模型又怕慢又怕贵。

我越来越确信一件事：在一个长会话里，真正稀缺的从来不是模型能力的上限，而是「干净的上下文」。模型够不够强，往往没那么要命；要命的是主线程被日志、diff、搜索结果一点点「腌入味」，到最后连自己要干什么都忘了。

Codex 的多 Agent 能力，恰好是把这个问题从「人肉切模型」变成「让主 Agent 自己调度」的一把钥匙。但要用对，得先分清两套长得很像、其实完全不同的东西。

一、Codex 的子 Agent，到底是什么

官方把 Subagent workflow 定义得很清楚：Codex 启动多个子 Agent 去处理专门任务，主线程负责收集和整合结果。几个关键点：

• 默认就开着。当前 Codex 版本默认启用子 Agent 工作流，App、CLI、IDE 都能看到子 Agent 的活动。
• 可观察、可切换。CLI 里用 /agent 就能查看和切换活动线程。
• 触发方式有三种：你直接说「用两个子 Agent 并行查」；AGENTS.md 里写了规则；或者某个 Skill 要求。
• 子 Agent 有独立上下文。它自己推理、自己调工具，所以通常比单 Agent 更费 token——这笔账第六节再算。

一句话：子 Agent 不是「多开几个聊天框」，而是把一部分工作隔离到一个干净的小房间里，干完把结论递回来。

二、两个长得很像、其实完全不同的 Multi-agent

这是整篇文章里最容易写错、也最容易误导读者的地方。务必在脑子里钉死：

所以当你看到有人写「Codex 让每个子 Agent 自动用不同模型」，要分清他说的是本地自定义 Agent（成立）还是 Responses API（当前不成立）。别把两件事写成一件事——这是 2026 年多 Agent 文章里最常被踩的坑。

三、Sol、Terra、Luna，到底怎么分

最实用的分工是：主线程固定一个强模型持续掌舵，把边界清楚、独立的小活交给子 Agent。一个广为流传的角色分配：

示意图：主 Agent 把独立工作委派给不同角色的子 Agent，只回收压缩后的证据。

注意，这不是硬性规则。任务风险、上下文规模、失败成本，比「模型越强越好」重要得多。一个底层 CRUD 的实现，让 Terra 做足够；一个涉及并发安全的改动，才值得升到 Sol 审查。

推理强度（reasoning effort）也要跟着路由：官方建议把 medium 当多数任务的平衡点；简单、延迟敏感用 low，复杂审查才上 high。别凭手感长期钉死高推理——那是纯纯的烧钱。

四、一套可复制的本地配置（三层控制）

想逼近「自动路由」的体验，靠的是显式规则，不是后台魔法。分三层：

① 全局默认：~/.codex/config.toml

[agents]
enabled = true
max_concurrent_threads_per_session = 3
default_subagent_model = "gpt-5.6-terra"
default_subagent_reasoning_effort = "medium"

并发 3 是个稳妥起点，不必一上来就追更大的线程数。最佳值取决于任务独立度、token 预算、工具限流和写冲突风险。

② 角色配置：~/.codex/agents/*.toml

三个窄职责 Agent，每个独立配模型、推理强度和沙箱：

# fast_explorer.toml —— 只读侦察
name = "fast_explorer"
description = "用于只读侦察、代码定位和证据收集。"
model = "gpt-5.6-luna"
model_reasoning_effort = "low"
sandbox_mode = "read-only"
developer_instructions = """
只做探索和证据收集，不修改文件。
优先精确搜索，返回文件位置、关键事实、
未确认项和下一步建议。不要把完整日志倒给主线程。
"""
implementation_worker.toml —— 边界明确后实现
name = “implementation_worker”
description = “用于边界清楚的实现、修复和测试补充。”
model = “gpt-5.6-terra”
model_reasoning_effort = “medium”
developer_instructions = """
只处理主线程明确分配的范围。
做最小且可辩护的改动，运行与风险匹配的测试。
如发现任务边界错误，停止扩大修改并报告主线程。
"""
risk_reviewer.toml —— 高风险只读审查
name = “risk_reviewer”
description = “用于安全、并发、数据一致性和复杂回归审查。”
model = “gpt-5.6-sol”
model_reasoning_effort = “high”
sandbox_mode = “read-only”
developer_instructions = """
像代码所有者一样审查，但不修改文件。
优先找可复现的正确性、安全、并发、数据一致性问题。
每条发现给出严重度、证据位置、触发条件和验证方式。
"""

③ 路由策略：AGENTS.md

全局放跨项目的路由原则，项目里放仓库特有的测试、写权限和并行限制。Codex 从根目录到当前目录逐层加载，越靠近当前目录的规则越晚合并、可覆盖上层——默认合并上限 32 KiB，所以规则要短、要稳，别写成长篇小说。

三个开箱即用的提示词模板（直接复制进对话）：

五、什么时候「不要用」多 Agent

多 Agent 不是银弹。以下情况，老老实实单 Agent 反而更好：

还有六个高频误区，顺手列一下：

• 误区一：Multi-agent = 模型自动切换（其实主线程模型基本不变，变的是子 Agent 配置）。
• 误区二：Agent 越多越快（不可分 / 共享状态多 / 单慢调用时，只增协调与 token 成本）。
• 误区三：轻量模型只能干低价值活（文件定位、日志分类、文档核验可能非常关键）。
• 误区四：子 Agent 给结论就算完（没文件位置/测试/复现步骤，进不了主线程决策）。
• 误区五：AGENTS.md 越长越好（32 KiB 上限，重复冲突会挤占上下文）。
• 误区六：Codex Subagents ≙ Responses API Multi-agent（异构配模 vs 同请求共享模型）。

六、真实成本：别被「看起来快」骗了

多 Agent 的账得这么算：

所以并行减少的是「等待时间」，不一定减少「花费」。并行写代码还有协调成本（谁改哪个文件、冲突怎么解）。

官方也建议：用评测而不是直觉来定配置。挑 10–20 个你真实会做的任务，比较三种方式——

给你的落地清单（5 条）