子智能体

Codex 可以通过并行生成专门的智能体来运行子智能体工作流，从而并行地探索、处理或分析工作。

本页介绍了核心概念和权衡。有关设置、智能体配置和示例，请参阅 子智能体.

为什么子智能体工作流有帮助

即使有较大的上下文窗口，模型也存在局限性。如果你在主对话（用于定义需求、约束和决策）中填入嘈杂的中间输出（如探索笔记、测试日志、堆栈跟踪和命令输出），会话的可靠性可能会随着时间推移而下降。

这通常被描述为：

• 上下文污染: 有用信息会被淹没在嘈杂的中间输出中。
• 上下文腐烂: 随着对话充斥着相关性较低的细节，性能会随之下降。

有关背景信息，请参阅 Chroma 关于 上下文腐烂.

的文章

• 子智能体工作流通过将嘈杂的工作移出主线程来提供帮助： 保持 主智能体
• 专注于需求、决策和最终输出。 并行运行专门的 子智能体
• 返回 进行探索、测试或日志分析。 摘要

（而不是原始中间输出）来自子智能体。

当工作可以独立并行运行时，它们还可以节省时间；并且通过将大型任务分解为有界片段，使其更易于处理。例如，Codex 可以将对数百万 token 文档的分析拆分为更小的问题，并将提炼后的要点返回给主线程。

作为起点，请将并行智能体用于繁重的读取任务，例如探索、测试、分类和摘要。对于并行的繁重写入工作流需更加谨慎，因为多个智能体同时编辑代码可能会产生冲突并增加协调开销。

核心术语

• Codex 在子智能体工作流中使用了几个相关术语：: Codex 运行并行代理并汇总其结果的工作流。
• 子智能体工作流: 由 Codex 启动以处理特定任务的委派代理。
• 子智能体: 代理的 CLI 线程，您可以进行检查并在其间切换，使用 /agent.

智能体线程

触发子智能体工作流

Codex 不会自动生成子智能体，并且仅在你明确要求使用子智能体或并行智能体工作时才应使用它们。

在实践中，手动触发意味着使用直接指令，例如“生成两个智能体”、“并行分配此工作”或“每个点使用一个智能体”。子智能体工作流比类似的单智能体运行消耗更多的 token，因为每个子智能体都会进行自己的模型和工具工作。

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.

一个好的子智能体提示应说明如何划分工作、Codex 是否应在继续之前等待所有智能体完成，以及要返回什么摘要或输出。

选择模型和推理

不同的智能体需要不同的模型和推理设置。 model_reasoning_effort, Codex 可以选择为任务平衡智能、速度和成本的配置。它可能倾向于 gpt-5.4-mini 如果你不固定模型或 gpt-5.5 用于快速扫描，或更高强度的 model and model_reasoning_effort 配置以进行要求更高的推理。当你需要更精细的控制时，请在提示中引导该选择，或直接在智能体文件中设置

模型选择

• gpt-5.5: 要求较高的代理请从此处开始。它最适合需要规划、工具使用、验证以及在更广阔上下文中进行后续跟进的模糊、多步骤工作。
• gpt-5.4: 当工作流固定使用 GPT-5.4 时请使用此选项。它结合了强大的代码编写、推理、工具使用和更广泛的工作流能力。
• gpt-5.4-mini: 用于优先考虑速度和效率而非深度的代理，例如探索、读密集型扫描、大文件审查或处理辅助文档。它非常适合用于将提炼后的结果返回给主代理的并行工作器。
• gpt-5.3-codex-spark: 如果您拥有 ChatGPT Pro，请在延迟比广泛功能更重要时，使用此研究预览模型进行近乎即时的纯文本迭代。

推理强度 (model_reasoning_effort)

• high: 当代理需要追踪复杂逻辑、检查假设或处理边缘情况时使用（例如审查员或注重安全的代理）。
• medium: 适用于大多数代理的平衡默认选项。
• low: 当任务简单明了且速度最重要时使用。

更高的推理强度会增加响应时间和 token 使用量，但可以提高复杂工作的质量。有关详细信息，请参阅 模型, 配置基础，且 配置参考.