Codex 可以通过生成多个专门化智能体并让它们并行工作，来运行子智能体工作流，从而并发地探索、处理或分析任务。
本页解释的是核心概念与取舍。有关设置、智能体配置和示例，请参见子智能体。
为什么子智能体工作流有帮助
即使上下文窗口已经很大，模型依然有极限。如果你把大量带噪的中间输出，例如探索笔记、测试日志、堆栈追踪和命令输出，全部塞进主会话里，也就是你正在定义需求、约束和决策的地方，这个会话随着时间推移就会越来越不稳定。
这通常会被称为：
- 上下文污染（Context pollution）：有用信息被带噪中间输出埋没
- 上下文腐化（Context rot）：随着对话被越来越多低相关细节塞满，整体表现下降
背景资料可参考 Chroma 关于 context rot 的文章。
子智能体工作流通过把高噪声工作移出主线程来缓解这个问题：
- 让主智能体继续聚焦在需求、决策和最终输出上
- 让专门化的子智能体并行处理探索、测试或日志分析
- 让子智能体返回摘要，而不是把原始中间输出全部灌回主线程
当任务可以独立并行运行时，它们也能节省时间；当任务规模较大时，把问题拆成边界清晰的小块，也会让任务更易处理。例如，Codex 可以把一份数百万 token 的文档分析拆成多个较小的问题，再把提炼后的结论返回给主线程。
作为起点，可以优先把并行智能体用在探索、测试、分诊和总结这类读操作较重的任务上。对于并行写操作较重的工作流则要更谨慎，因为多个智能体同时修改代码容易引入冲突，并带来更高的协调成本。
核心术语
Codex 在子智能体工作流中会用到几个相关术语：
- 子智能体工作流（Subagent workflow）：Codex 运行并行智能体并汇总结果的工作流
- 子智能体（Subagent）：Codex 为某个特定任务启动的委派智能体
- 智能体线程（Agent thread）：某个智能体对应的 CLI 线程，你可以通过
/agent查看和切换
触发子智能体工作流
Codex 不会自动生成子智能体，只有当你明确要求使用子智能体或并行智能体工作时，它才应该这样做。
在实际使用中，这意味着你需要给出直接指令，例如“生成两个智能体”“并行委派这项工作”或“每个点位用一个智能体”。由于每个子智能体都会单独进行模型调用和工具调用，子智能体工作流相比单智能体执行会消耗更多 token。
一个好的子智能体提示词应该说明如何拆分任务、Codex 是否要等所有智能体完成后再继续，以及最终需要返回什么样的摘要或输出。
Review this branch with parallel subagents. Spawn one subagent for security risks, one for test gaps, and one for maintainability. Wait for all three, then summarize the findings by category with file references.选择模型与推理强度
不同智能体需要不同的模型和推理设置。
如果你没有固定 model 或 model_reasoning_effort，Codex 会为任务自动选择一个平衡智能、速度和价格的配置。对于快速扫描，它可能倾向于 gpt-5.4-mini；而对更吃推理的任务，它可能偏向更高推理强度的 gpt-5.4 配置。当你想要更细粒度控制时，可以在提示词中引导这项选择，或直接在智能体文件中设置 model 和 model_reasoning_effort。
模型选择
gpt-5.4：大多数智能体都应该从这里开始。它兼顾强大的编码、推理、工具使用和更广泛的工作流能力。主智能体，以及需要协调含糊或多步骤任务的智能体，通常适合用它。gpt-5.4-mini：适合那些更看重速度和效率而不是深度的智能体，例如探索、读操作密集型扫描、大文件审查或处理辅助文档。它特别适合那些并行工作、最后只向主智能体返回提炼结果的 worker。gpt-5.3-codex-spark：如果你拥有 ChatGPT Pro，可以在延迟比通用能力更重要时，使用这个研究预览模型做接近即时的纯文本迭代。
推理强度（model_reasoning_effort）
high：适合需要追踪复杂逻辑、检查假设或推演边界情况的智能体，例如 reviewer 或偏安全方向的智能体。medium：大多数智能体的平衡默认值。low：适合任务本身比较直接、且速度优先的场景。
更高的推理强度会增加响应时间和 token 使用量，但对于复杂任务，通常能带来更高质量。更多细节见 模型、配置基础 和 配置参考。