理解 Subagents 的分工模型

Codex 可以通过 spawning specialized agents in parallel 来运行 subagent workflows，让它们并发

Codex 可以通过 spawning specialized agents in parallel 来运行 subagent workflows，让它们并发 explore、tackle 或 analyze work。

这篇解释核心概念和取舍。setup、agent configuration 和 examples 见 Subagents。

为什么 subagent 工作流有帮助

即便有 large context windows，模型仍然有边界。

如果你把 main conversation，也就是定义 requirements、constraints 和 decisions 的地方，塞满 noisy intermediate output，例如 exploration notes、test logs、stack traces、command output，session 会随着时间变得不稳定。

这通常被描述为：

概念	含义
Context pollution	有用信息被 noisy intermediate output 淹没。
Context rot	conversation 填满低相关细节后，performance 下降。

背景说明可看 Chroma 关于 context rot 的文章。

Subagent workflows 的作用是把 noisy work 从 main thread 中移走：

让 main agent 专注 requirements、decisions 和 final outputs。
让 specialized subagents 并行处理 exploration、tests 或 log analysis。
让 subagents 返回 summaries，而不是 raw intermediate output。

当工作可以独立并行时，subagent workflows 也可以节省时间。它们还能把 larger-shaped tasks 拆成 bounded pieces，让任务更容易处理。

例如，Codex 可以把 multi-million-token document 的分析拆成小问题，再把提炼后的 takeaways 返回给 main thread。

起步时，优先把 parallel agents 用在 read-heavy tasks，例如 exploration、tests、triage 和 summarization。

parallel write-heavy workflows 要更谨慎，因为多个 agents 同时编辑 code 可能造成 conflicts，并增加 coordination overhead。

核心术语

Codex 在 subagent workflows 中使用几个相关术语：

术语	含义
Subagent workflow	Codex 运行 parallel agents，并整合它们结果的 workflow。
Subagent	Codex 启动来处理具体 task 的 delegated agent。
Agent thread	某个 agent 的 CLI thread，可以通过 `/agent` inspect 和 switch。

触发 subagent 工作流

Codex 不会自动 spawn subagents。只有当你明确要求 subagents 或 parallel agent work 时，它才应该使用 subagents。

实际触发方式是直接写清楚，例如：

"spawn two agents"
"delegate this work in parallel"
"use one agent per point"

Subagent workflows 会比类似 single-agent runs 消耗更多 tokens，因为每个 subagent 都会做自己的 model 和 tool work。

好的 subagent prompt 应该说明：

如何 divide work。
Codex 是否应该等待所有 agents 完成后再继续。
需要返回什么 summary 或 output。

示例：

请用 parallel subagents review 当前分支。分别启动一个 subagent 检查 security risks，一个检查 test gaps，一个检查 maintainability。等待三个 subagents 全部完成后，按类别汇总 findings，并附 file references。

选择模型和推理强度

不同 agents 需要不同 model 和 reasoning settings。

如果没有 pin model 或 model_reasoning_effort，Codex 可以为任务选择平衡 intelligence、speed 和 price 的 setup。它可能用 gpt-5.4-mini 做 fast scans，也可能在需要更高 reasoning 时选择 higher-effort gpt-5.5 configuration，如果该 model 可用。

需要更细控制时，可以在 prompt 中说明，或在 agent file 中直接设置 model 和 model_reasoning_effort。

多数 Codex tasks 中，gpt-5.5 可用时从它开始。rollout 期间如果 gpt-5.5 还不可用，继续使用 gpt-5.4。需要更快、成本更低的轻量 subagent work 时，用 gpt-5.4-mini。如果你有 ChatGPT Pro，并希望 near-instant text-only iteration，gpt-5.3-codex-spark 仍以 research preview 形式可用。

模型选择

Model	适用场景
`gpt-5.5`	可用时，用于 demanding agents。适合 ambiguous、multi-step work，需要 planning、tool use、validation，以及在更大 context 中 follow-through。
`gpt-5.4`	当 `gpt-5.5` 还不可用，或 workflow pin 到 GPT-5.4 时使用。它结合了强 coding、reasoning、tool use 和更广泛 workflow 能力。
`gpt-5.4-mini`	适合偏 speed 和 efficiency，而不是 depth 的 agents，例如 exploration、read-heavy scans、large-file review，或处理 supporting documents。它适合作为 parallel workers，向 main agent 返回 distilled results。
`gpt-5.3-codex-spark`	如果你有 ChatGPT Pro，当 latency 比 broader capability 更重要时，可用这个 research preview model 做 near-instant、text-only iteration。

推理强度（`model_reasoning_effort`）

Effort	适用场景
`high`	agent 需要 trace complex logic、check assumptions 或处理 edge cases 时使用，例如 reviewer 或 security-focused agents。
`medium`	多数 agents 的 balanced default。
`low`	task straightforward 且 speed 最重要时使用。

更高 reasoning effort 会增加 response time 和 token usage，但可能提升复杂任务质量。

更多细节见：

Models：https://developers.openai.com/codex/models
Config basics：https://developers.openai.com/codex/config-basic
Configuration Reference：https://developers.openai.com/codex/config-reference