这是系列文章的第5篇，本文借助 Codex subagent，介绍一下子智能体的常见概念和用法。

重点会放在主 Agent 如何委派一个或多个子智能体做事，再把结果汇总回来。而不会涉及另一类多 Agent 协作模式 —— Agent Team 相关的概念。两者的区别是：前者是主 Agent 掌控全局，进行信息分发和汇总，是星型拓扑；后者 SubAgent 之间可以通信，更像是网状拓扑。

在文章的最后，我也会比较一下 OpenAI 和 Anthropic 在使用 SubAgent 上的设计哲学和使用差异。

一、为什么 subagent 有用

Codex 当前版本默认支持子智能体工作流。ChatGPT 桌面 App、Codex CLI 和 IDE 扩展都会展示子智能体的活动。

即使上下文窗口很大，模型仍然有极限。如果把探索笔记、测试日志、堆栈追踪和命令输出等带噪中间结果全部放进正在定义需求、约束与决策的主对话，会话会逐渐变得不可靠。

这通常称为：

• 上下文污染（Context pollution）： 有用信息被带噪的中间输出淹没。
• 上下文腐化（Context rot）： 随着对话充满低相关细节，整体表现下降。

子智能体工作流把带噪工作移出主对话线程：

• 让主智能体聚焦需求、决策与最终输出。
• 让专用子智能体并行处理探索、测试或日志分析。
• 让子智能体返回摘要，而不是原始中间输出。

当工作可以独立并行时，这种方式还能缩短时间，并把大任务拆成边界清晰的小块。例如，Codex 可以把数百万 token 的文档分析拆成多个较小问题，再把提炼结果交还主对话线程。

由于每个子智能体都会独立进行模型调用和工具调用，子智能体工作流会比同类单智能体任务消耗更多 token。

建议先把并行智能体用于探索、测试、分诊和总结等读操作较重的任务。并行写操作更容易产生代码冲突和协调开销，应谨慎使用。

二、如何使用多子Agent

你可以在 App 任务中直接要求 Codex 把互不依赖的工作委派给子智能体。当前本地 Codex 版本会在你明确提出要求，或适用的 AGENTS.md、skill 指令要求委派时启动子智能体。App 会展示每个子智能体对话线程，方便你检查其工作以及返回主任务的摘要。

这里有三个核心术语先要厘清：

• 子智能体工作流： Codex 运行并行智能体并汇总结果的工作流。
• 子智能体： Codex 为特定任务启动的委派智能体。
• 智能体对话线程（Agent thread）： 子智能体执行工作的对话线程；受支持的客户端允许你打开它查看进度和结果。

如何触发

可以直接要求 Codex 使用子智能体或并行智能体。适用的项目指令或 skill 指令也可以要求委派。

手动触发时，应使用明确指令，例如 “spawn two agents（派生两个智能体）”、“delegate this work in parallel（并行处理这个任务）”等

Codex 负责所有编排工作，包括：

• 生成新的子智能体
• 给不同智能体路由后续指令
• 等待结果
• 关闭子智能体对话线程

当多个智能体并行运行时，Codex 会等待所有要求的结果都返回后，再给出一份汇总答复。当前本地 Codex 版本会在直接请求，或适用的项目与 skill 指令要求时启动智能体。

说回来，好的提示词要说明如何拆分工作、是否等待全部智能体完成，以及最终需要返回什么摘要或产物。

请并行启动三个 subagent 审查当前分支：
1. 一个只看安全风险；
2. 一个只看测试缺口；
3. 一个只看可维护性。
等三个 subagent 都完成后，再由主线程汇总结果。

结果也是会如我们预期的一样，汇总在一起：

如何查看

subagent 不只是一个后台黑盒。它更像主任务下面的一条可追踪支线。

• 从主对话线程中的活动记录打开子智能体对话线程，检查其工作。
• 在 CLI 中使用 /agent，可以在活跃智能体对话线程之间切换，并查看正在运行的对话线程。
• 你也可以直接要求 Codex 去引导某个正在运行的子智能体、停止它，或关闭已经完成的智能体对话线程。

内建智能体

Codex 自带三种内建智能体：

• default：通用回退智能体。
• worker：偏执行，适合实现和修复类任务。
• explorer：偏只读，适合代码库探索类任务。

上边我贴的例子中，就是用的 Codex 内建的 multi-agent/subagent 能力。

Codex 启动的是只读 review/explorer 类子智能体：它们在同一个仓库上下文里独立审查代码，然后把 findings 回传给主线程；最终由在主线程汇总、判断和执行修改。它们不是外部插件，也不是单独安装的第三方工具。

自定义智能体

如果你要定义自己的智能体，可以在下面两个目录之一中放置独立的 TOML 文件：

• 个人级：~/.codex/agents/
• 项目级：.codex/agents/

每个文件定义一个自定义智能体。Codex 会把它作为一个“额外配置层”应用到生成的会话中，所以自定义智能体能覆盖的键，基本与普通 config.toml 可覆盖项一致。

每个自定义智能体文件都必须定义：

• name
• description
• developer_instructions

像 nickname_candidates、model、model_reasoning_effort、sandbox_mode、mcp_servers、skills.config 这样的字段都是可选的；如果省略，就继承父会话。

Codex 官方文档也给了一个 reviewer.toml 自定义 subagent 的例子：

name = "reviewer"
description = "PR reviewer focused on correctness, security, and missing tests."
model = "gpt-5.4"
model_reasoning_effort = "high"
sandbox_mode = "read-only"
developer_instructions = """
Review code like an owner.
Prioritize correctness, security, behavior regressions, and missing test coverage.
Lead with concrete findings, include reproduction steps when possible, and avoid style-only comments unless they hide a real bug.
"""

还有一些允许同时打开的智能体对话线程上限的 agents.max_threads 等参数可以配置在项目配置或者个人配置中：.codex/config.toml

[agents]
max_threads = 6
max_depth = 1

三、Subagent在Codex和Claude Code中的不同

在 Codex 和 Claude Code 中使用 Subagents，除了配置方式不同之外，还有一个明显差异：Codex 更偏显式编排，Claude Code 更偏自动匹配与显式调用结合。

Codex 显式触发优先。通常需要你在提示词里明确说“spawn…”、“use one agent per…”、“并行启动三个 subagent”之类的指令，或者由 AGENTS.md、skill 指令要求委派。它更像一个主控台清晰的并行任务调度器：主线程负责拆任务、派发任务、等待结果和最终汇总；每个子智能体有自己的线程，可以点进去查看过程。

这种体验的好处是可控、可审计，特别适合安全审查、测试缺口分析、代码库探索、日志归因这类边界清晰的并行任务。代价是你需要更明确地告诉 Codex 怎么拆、怎么汇总。

Claude Code 则更偏自动匹配与显式调用结合。它可以根据任务和 subagent 的描述，自动选择内建或自定义 subagent；你也可以显式要求它使用某个 subagent。它更像一个主动的结对工程师：你交代目标后，它可能先安排探索和规划，把资料铺好，再回到主对话里给你结论。

需要注意的是，这里讨论的仍然是 subagent 工作流，不是完整的 Agent Team。无论 Codex 还是 Claude Code，subagent 的基本形态都是主 Agent 委派子 Agent，子 Agent 独立处理一段上下文，再把结果返回主对话。真正的多 Agent 网状通信、互相协商、共享任务板，是另一类更复杂的协作模式。

所以，这不是简单的谁更先进。产品往往会泄露一些公司气质：OpenAI 把“可控、可审计、可编排”放在更前面；Anthropic 把“自然、自动、少打扰”放在更优先的位置。

四、小结

Subagent 最容易被误解成“多叫几个 Agent 干活”。但真正有用的地方，其实是把主线程从脏活累活里摘出来。

很多任务不是模型不会做，而是中间过程太吵：日志太长、分支太多、尝试太碎。全塞进一个对话里，主线很快就会被淹没。让子 Agent 去跑这些支线，再把结论带回来，主 Agent 才能继续保持判断力。

当然，这也不是免费午餐。子 Agent 开多了，token 会涨，协调成本也会涨。尤其是大家一起改代码时，看起来是在并行，实际可能是在制造冲突。

我会把 Codex subagent 先看成一种“并行调查”工具：适合审查、定位、对比、梳理，不急着让它们一起下手改东西。真正需要多个 Agent 长时间协作、共享状态、互相讨论时，那已经是 Agent Team 的问题了，不是这篇文章要解决的范围。