Codex 也能定义 Agent：和 Claude Code Agent 到底差在哪

Fri, 10 Apr 2026 00:00:00 +0000

Codex 也能定义 Agent：和 Claude Code Agent 到底差在哪

最近看一些 agent 对比资料时，我发现一个很常见但已经过时的说法：Codex 不能定义 agent，Claude Code 才可以。

这个结论现在已经不准确了。

OpenAI 官方已经单独写了 Codex 的 subagents 文档，明确说明可以在 ~/.codex/agents/ 或项目内 .codex/agents/ 定义自定义 agent，而且是用独立的 TOML 文件来配置。

所以现在更值得问的问题，已经不是“Codex 能不能定义 agent”，而是：Codex 和 Claude Code 都能做 agent 之后，它们的设计重点到底差在哪。

如果你之前已经看过我写的 AI 编程 CLI 总览文和 skills 对比文，这篇可以理解成下一层专题：它不再泛谈工具选型，而是专门讲 agent 这一层机制到底怎么分化。

写在前面

先给结论。

Codex 和 Claude Code 现在都支持自定义 agent，但两边的重心并不一样。

Claude Code 的 subagent，更像是一个已经深度融入主工作流的“专门分身系统”。它强调自动委派、上下文隔离、工具边界、权限模式、skills 注入、后台运行、worktree 隔离和持久记忆。

Codex 的 subagent，则更像是一个“可编排的显式多代理机制”。它同样支持自定义 agent，也支持模型、沙箱、MCP、skills 配置继承，但官方文档最强调的点是：只有在你明确要求时，Codex 才会 spawn subagent。

换句话说：

Claude Code 更像“主会话会主动用 agent 帮你拆任务”
Codex 更像“你明确下令后，它再把任务派给子 agent”

这不是谁强谁弱的问题，而是两种很不一样的交互哲学。

核心概念

虽然大家平时都习惯说“agent”，但两边官方文档里更准确的术语其实都是 subagent。

它们共同解决的是一类问题：

主对话不想被大段搜索结果、日志、文件内容淹没
某一类任务会反复出现，希望有固定的专用提示词和工具边界
希望把研究、审查、修改、排查这些工作拆成不同角色处理

从这个角度看，Codex 和 Claude Code 的目标很像，都是把“一个大助手”拆成“一个主会话 + 多个专门助手”。

但一旦继续往下看，就会发现它们在五个地方分化得很明显：

定义文件怎么写
主会话什么时候会委派
子 agent 能拿到哪些能力
配置和上下文怎么继承
工程化边界做到什么程度

先看一张总表

维度	Claude Code	Codex
官方术语	Subagents	Subagents / custom agents
定义位置	`~/.claude/agents/`、`.claude/agents/`、`--agents`	`~/.codex/agents/`、`.codex/agents/`
定义格式	Markdown + YAML frontmatter + Markdown body	TOML
最核心必填项	`name`、`description`，正文作为 system prompt	`name`、`description`、`developer_instructions`
默认委派方式	Claude 可根据 `description` 自动 delegate，也可显式指定	官方明确写明：只有你显式要求时才会 spawn subagent
工具控制	`tools`、`disallowedTools`、`permissionMode` 很细	以 `sandbox_mode`、父会话审批/沙箱继承为主
MCP 支持	支持按 subagent 配 `mcpServers`	支持按 custom agent 配 `mcp_servers`
skills 关系	subagent 可显式加载 `skills`，且不继承父会话 skills	custom agent 可配 `skills.config`，未写时继承父会话
后台运行	支持 `background: true`	官方页重点在线程与并发，不是固定后台 agent 配置
仓库隔离	支持 `isolation: worktree`	官方 subagents 页未把 worktree 隔离作为 custom agent 核心字段
持久记忆	支持 `memory: user/project/local`	官方 subagents 页未把持久记忆列为 custom agent 核心字段
嵌套限制	官方明确：subagent 不能再 spawn subagent	通过 `agents.max_depth` 控制，默认 1

如果只看表格，最醒目的差异其实就两条：

Claude Code 更强调“单个 subagent 的能力边界”
Codex 更强调“多 agent 调度时的显式控制和并发参数”

定义方式：Claude 更像写角色卡，Codex 更像写配置文件

这是两边最直观的区别。

Claude Code：Markdown 文件就是 agent 本体

Claude Code 的 subagent 文件本质上是一段带 frontmatter 的 Markdown。前面写元信息，后面整段正文就是这个 subagent 的 system prompt。

官方支持的字段很多，常用的包括：

name
description
tools
disallowedTools
model
permissionMode
maxTurns
skills
mcpServers
hooks
memory
background
effort
isolation
color
initialPrompt

这种设计的好处是很直观。

你在定义 Claude subagent 时，脑子里的问题往往是：

这个角色是谁
它该在什么时候被调用
它能用哪些工具
它应该遵守什么规则
它需要什么附加技能和记忆

也就是说，Claude 的 subagent 文件天然更接近“角色说明书”。

Codex：TOML 更偏配置驱动

Codex 的 custom agent 是 TOML 文件。官方页目前明确列出的必填项是：

name
description
developer_instructions

常见可选项包括：

nickname_candidates
model
model_reasoning_effort
sandbox_mode
mcp_servers
skills.config

官方还说明，custom agent 文件可以承载其他受支持的 config.toml 键。

这说明 Codex 的思路不是“正文 prompt 外挂一点配置”，而是更明显地把 custom agent 当成一种派生 session 配置层。

换句话说，Claude 更像“定义一个专门助手”；Codex 更像“定义一种被 spawn 出来的工作模式”。

委派机制：这可能是两边最大的分水岭

如果只允许我挑一个最值得写进文章标题下方的差异，那我会选这一条。

Claude Code：可以自动委派

Claude Code 官方文档明确写到，Claude 会根据每个 subagent 的 description 判断什么时候把任务 delegate 给它。

这意味着 Claude 的 agent 系统并不只是“你手动点名才会用”，而是会融入主会话自己的决策流程。

比如：

代码库搜索任务，Claude 可能自动丢给 Explore
计划模式里的研究任务，可能自动丢给 Plan
复杂多步骤操作，可能自动丢给 general-purpose

自定义 subagent 也可以走同样路线，只要 description 写得足够清楚。

Codex：只有显式要求才会 spawn

Codex 这边官方表述更直接：Codex only spawns subagents when you explicitly ask it to.

这句话非常关键，因为它直接决定了使用心智。

在 Codex 里，subagent 更像一个你主动调度的资源，而不是主会话会自动替你判断的分身系统。

这会带来两种体验差异：

第一种差异是可控性更高。

你想并行开几个、让谁做什么、何时停止，基本都更偏显式。

第二种差异是自动化程度更低。

如果你习惯 Claude 那种“我只描述目标，系统自己判断要不要起 agent”的方式，切到 Codex 时会明显感觉它更依赖你的调度意图。

继承规则：Claude 更强调边界，Codex 更强调沿父会话继承

两边都支持“没写的配置从父会话继承”，但重点不太一样。

Claude Code 的继承重点

Claude Code 文档里有几个点特别值得注意。

第一，tools 如果省略，就继承父会话工具；disallowedTools 则是在继承后的工具集上继续扣减。

第二，model 默认是 inherit。

第三，skills 不会从父会话自动继承。只有你在 subagent 文件里显式写了 skills:，它才会在启动时把这些 skill 的内容直接注入上下文。

第四，项目级 subagent 支持从当前工作目录向上发现 .claude/agents/，但 --add-dir 只给文件访问权限，不会顺带扫描 subagent 配置。

这套规则的核心味道很明显：Claude 很在意“一个 subagent 拿到什么，不拿到什么”。

Codex 的继承重点

Codex 当前官方页对继承的描述也很清楚，但口味更偏“子 session 叠层”。

它明确写到，custom agent 里未指定的可选项会从父 session 继承。更重要的是，spawn 子 agent 时，父 turn 当下的 runtime overrides 也会重新套用，包括：

审批设置
沙箱设置
交互过程中临时改过的运行参数
--yolo 这类高权限运行状态

这意味着 Codex 的 custom agent 虽然可以自己声明一些默认配置，但真正运行时，它依然深受当前父会话状态影响。

这种设计很适合“当前会话就是一个大工作流控制器”的用法。

能力边界：Claude Code 在 subagent 这层给的旋钮更多

如果你关心的不是“能不能开多个 agent”，而是“每个 agent 能不能像单独岗位一样严格收口”，那 Claude Code 这边会更有吸引力。

Claude Code 能直接在 subagent 层定义的东西更多

Claude 不只是让你选模型和工具，它还允许你直接在 subagent 里定义：

权限模式 permissionMode
生命周期 hooks
持久记忆 memory
后台运行 background
工作目录隔离 isolation: worktree
effort 等级
初始提示 initialPrompt

这意味着一个 Claude subagent 可以非常像“仓库里的正式岗位”：

代码审查员只能读文件
安全检查员只能用有限工具
某个 agent 永远后台跑
某个 agent 永远在临时 worktree 里改代码
某个 agent 还有自己的长期记忆目录

Codex 的 custom agent 更像核心运行参数覆写

Codex 当然也支持重要能力开关，比如：

sandbox_mode
mcp_servers
model
model_reasoning_effort
skills.config

但从官方页当前呈现出来的重点看，它更像是在告诉你：

这个 agent 用什么模型
推理强度多高
运行在什么沙箱里
接哪些 MCP
技能配置怎么带进去

也就是说，Codex 的 custom agent 已经足够实用，但它在“岗位制度化”这一层，没有 Claude Code 展开得那么细。

工程化能力：Claude 更像内建工作流，Codex 更像多线程调度器

这部分特别适合团队用户看。

Claude Code 的工程化味道

Claude Code 的 subagent 文档会让你明显感觉到，它不是只想解决“多开几个分身”，而是要把 subagent 做进整个 CLI 工作流里。

比如：

/agents 可以直接图形化管理
支持 project / user / managed / plugin 多层来源
同名 agent 有明确优先级覆盖规则
支持后台任务
支持 worktree 隔离
支持 persistent memory
支持和 skills、hooks、MCP 联动

这种设计非常适合长时间维护的团队仓库。

因为团队真正需要的，不只是“多一个 agent”，而是“这个 agent 在组织里怎么分发、怎么收权限、怎么和现有流程接起来”。

Codex 的工程化味道

Codex 这边更突出的，是并发和深度控制。

官方页给了统一的 [agents] 配置段，用来控制：

agents.max_threads
agents.max_depth
agents.job_max_runtime_seconds

其中官方页写得很明确：

agents.max_threads 默认是 6
agents.max_depth 默认是 1

这说明 Codex 对 subagent 的定位，很大一部分就是“可控的并行 worker 体系”。

它非常适合这种场景：

把一堆独立检查任务并发跑出去
做批量审查
做一批对象的一致性核对
让多个 worker 收集证据，再由主线程统一汇总

所以如果你更常见的任务是“把一个复杂问题拆成多个并行检查项”，Codex 的这套设计会很顺手。

一个很实际的判断：谁更适合什么人

如果你平时的使用方式更接近下面这种：

我只说目标，不太想手动编排
我希望系统自己判断什么时候该起 agent
我希望 agent 有明确的工具边界、权限模式和长期角色定义
我希望它和项目里的 skills、hooks、MCP、worktree 一起协同

那 Claude Code 的 subagent 机制通常会更贴手。

如果你的使用方式更接近下面这种：

我要明确地控制何时 spawn 子 agent
我要按任务拆很多并行 worker
我要给不同子任务设置不同模型或沙箱
我更关心线程数、深度、批量 job 这种编排能力

那 Codex 的 subagent 机制会更符合习惯。

常见问题与解决方案

问题一：现在还能说 Codex 不支持自定义 agent 吗

不建议这么说。

更准确的说法应该是：Codex 已经支持自定义 agent / subagents，但它和 Claude Code 的定义方式、委派机制和工程化边界不一样。

如果继续把“Codex 不支持 agent”写进对比文，今天已经容易误导读者。

问题二：Claude Code 和 Codex 的 agent，能不能简单理解成同一种东西

不能完全这样理解。

它们当然都属于“主会话委派子助手”的范畴，但 Claude 更强调自动委派和子 agent 的独立岗位边界，Codex 更强调显式调度和并发执行。

所以它们属于同一类能力，但不是同一种产品哲学。

问题三：如果我要给团队写一套 agent，先选哪边更省事

如果你的重点是“项目里沉淀一套长期可维护的角色体系”，Claude Code 往往更省事，因为字段更完整，和项目工作流结合得也更深。

如果你的重点是“把问题拆成多个并发 worker 来跑”，Codex 往往更顺手，因为它把并发、深度和 job 时限这些控制点摆得更前面。

问题四：agent 和 skills 是一回事吗

不是。

不管在 Claude Code 还是 Codex 里，skills 更像可复用知识包或流程包；agent 更像执行这些事情的专门角色。

这也是为什么我更建议把它们拆开理解：

skills 解决“这件事怎么稳定复用”
agent 解决“由谁、以什么边界、在什么上下文里去做”

关于三家工具的 skills 差异，可以接着看我前面那篇 skills 对比文；如果你想单独理解 CODEX_HOME 为什么会影响 Codex 的 skills、配置和状态目录，也可以再看那篇 CODEX_HOME 专题。

总结

很多旧资料还停留在“Claude Code 有 agent，Codex 没有”的阶段，但现在这个判断已经落后了。

今天更准确的结论应该是：

Codex 可以定义自定义 agent，而且 OpenAI 已经给了官方 subagents 文档
Claude Code 也可以定义 subagent，而且工程化边界展开得更完整
真正的差异不在“有没有”，而在“怎么定义、何时委派、边界收得多细、工作流整合有多深”

如果把一句话压缩到最短：

Claude Code 更像带权限、记忆、skills、worktree 的角色化 subagent 系统
Codex 更像由你显式调度的多线程 subagent 编排系统

也正因为如此，后面再看到有人把 Codex 写成“不能定义 agent”，你就要多留一个心眼了：问题很可能不是结论本身，而是资料已经过期了。

参考资料：

OpenAI on 记录点滴 - 分享

Codex 也能定义 Agent：和 Claude Code Agent 到底差在哪

Codex 也能定义 Agent：和 Claude Code Agent 到底差在哪

写在前面

核心概念

先看一张总表

定义方式：Claude 更像写角色卡，Codex 更像写配置文件

Claude Code：Markdown 文件就是 agent 本体

Codex：TOML 更偏配置驱动

委派机制：这可能是两边最大的分水岭

Claude Code：可以自动委派

Codex：只有显式要求才会 spawn

继承规则：Claude 更强调边界，Codex 更强调沿父会话继承

Claude Code 的继承重点

Codex 的继承重点

能力边界：Claude Code 在 subagent 这层给的旋钮更多

Claude Code 能直接在 subagent 层定义的东西更多

Codex 的 custom agent 更像核心运行参数覆写

工程化能力：Claude 更像内建工作流，Codex 更像多线程调度器

Claude Code 的工程化味道

Codex 的工程化味道

一个很实际的判断：谁更适合什么人

常见问题与解决方案

问题一：现在还能说 Codex 不支持自定义 agent 吗

问题二：Claude Code 和 Codex 的 agent，能不能简单理解成同一种东西

问题三：如果我要给团队写一套 agent，先选哪边更省事

问题四：agent 和 skills 是一回事吗

总结