一个你一定遇到过的场景#

你让 Codex 帮你做一个全仓库的代码审计。它开始噼里啪啦地改文件，改了 A 文件之后去改 B 文件，改着改着发现 C 文件也有问题，然后回头去修 A 文件里刚改过的地方。整个过程像一团乱麻，最后给你一个看起来很完整的结果，但你完全不知道它经历了什么，也没法验证中间步骤是否正确。

这就是单次推理模式的局限性。模型在一个对话流里同时承担规划、执行、检查和总结四个角色，任务一旦复杂起来，上下文窗口就开始捉襟见肘，中间步骤的证据也会被冲掉。

Claude Code 最近推出了 Dynamic Workflows（动态工作流）来解决这个问题。它把大型任务显式拆分成多个阶段，并行处理独立子任务，最后汇总验证。听起来很香，但这个功能是 Claude Code 的原生特性，Codex 没有。

不过，Codex 有自己的武器库：Skill 系统。通过一个精心设计的 Skill 文件，我们可以让 Codex 复刻出同样的动态工作流行为。

Claude Code 的 Dynamic Workflows 做了什么#

先理解目标。Dynamic Workflows 的核心思路是把大任务拆成显式的阶段：

  • 规划（Plan）：分析任务，拆分成可独立执行的子任务
  • 拆分（Split）：把子任务分配给不同的并行代理
  • 执行（Run）：多个子代理独立工作，互不干扰
  • 检查（Check）：验证每个子任务的产出
  • 整合（Integrate）：汇总所有结果，生成最终答案
  • 验证（Verify）：用测试、构建、lint 等手段确认最终状态

这个流程和软件工程里的 CI/CD 管道异曲同工。区别在于，Dynamic Workflows 是在一次 AI 对话中完成的编排。

Anthropic 还提供了一个 ultracode 模式，让 Claude Code 自动判断什么时候该启动工作流，什么时候直接执行就够了。对于全仓库 bug 排查、大规模迁移、安全审计这类任务，Dynamic Workflows 的优势非常明显。

但代价也不小。Anthropic 警告说，Dynamic Workflows 的 token 消耗可能远超普通会话，首次触发时还会弹出确认框。

Codex 的 Skill 机制：被低估的编排能力#

Codex 没有原生的 Dynamic Workflows，但它有两个关键组件：

Skill 文件（SKILL.md）：放在 ~/.codex/skills/ 目录下的 Markdown 指令包。Codex 启动时会自动加载这些 Skill，把内容注入到对话上下文中。模型经过专门训练，会严格遵循 Skill 中的指令。

子代理（Subagents）：当宿主环境支持时，Codex 可以通过 spawn_agent 调用独立的子代理来执行子任务。子代理有自己的上下文窗口，完成后把结果返回给父会话。

这两个组件组合起来，就能构建出和 Dynamic Workflows 等价的工作流引擎。

Ultracode Skill：三模式编排框架#

社区开发者 PabloNAX 创建了一个叫 Ultracode 的 Skill，把上面的思路落地成了可用的实现。它定义了三种工作模式：

模式一：Direct（直接模式）#

适合小任务。修一个错别字、读一个文件、回答一个简单问题。不需要任何工作流开销，直接执行。

判断标准很简单：如果任务可以在一个步骤内完成，就用 Direct 模式。

模式二：Workflow（工作流模式）#

适合中等复杂度的任务。需要一个计划，但不需要并行代理。

Skill 会在本地创建一个 .workflow/ultracode/ 目录，记录整个过程：

.workflow/ultracode/<run-slug>/
  plan.md          # 任务计划
  orchestration.md # 编排说明
  state.json       # 状态跟踪
  packets/         # 子任务数据包
  results/         # 各阶段产出
  integration.md   # 整合说明
  final-report.md  # 最终报告

这些文件就是"证据"。你可以在任务完成后回溯整个过程，看 Codex 是怎么想的、怎么做的、每一步的产出是什么。

模式三：Delegated（委托模式）#

适合可以拆分成独立子任务的大任务。当子代理可用时，Codex 会启动多个并行代理：

  • Explorer 代理：负责探查代码，收集事实
  • Worker 代理：在写入范围明确后执行编辑
  • 父会话：负责整合所有子代理的结果
  • 验证步骤：用测试、构建、lint 确认最终状态

关键设计原则是：子代理只产出部分结果，最终答案由父会话整合生成。这避免了多个代理各自为政、互相矛盾的问题。

实际效果对比#

维度单次推理Dynamic Workflow（Skill）
任务规划隐式，混在推理流中显式，有独立的 plan.md
中间证据被上下文窗口冲掉持久化到文件系统
并行执行不支持子代理独立工作
错误定位只能看到最终结果可以回溯每一步
Token 消耗较低较高（多个代理各自消耗）
适用场景小任务、快速迭代审计、迁移、安全检查

对于"全仓库重构"这类任务，使用 Dynamic Workflow 的最大收益不是速度，而是可追溯性。当 Codex 给你一个最终结果时，你可以打开 final-report.md 看到完整的推理链路。这在团队协作和代码审查场景下价值巨大。

什么时候该用，什么时候不该用#

适合用 Dynamic Workflow 的场景：

  • 全仓库级别的代码审计
  • 大规模框架迁移（比如从 Express 迁移到 Fastify）
  • 安全漏洞扫描和修复
  • 涉及多个独立模块的功能开发
  • 需要独立验证的高风险变更

不适合用的场景：

  • 改一个错别字
  • 修一个单文件的 bug
  • 多个子任务会重复搜索相同内容的情况
  • 对 token 消耗敏感的日常小任务

核心原则：小任务保持简单，大任务留下证据。

安装和使用#

安装过程非常简单：

# Codex
mkdir -p "${CODEX_HOME:-$HOME/.codex}/skills"
cp -R ultracode "${CODEX_HOME:-$HOME/.codex}/skills/"

# Claude Code（也可以用）
mkdir -p "$HOME/.claude/skills"
cp -R ultracode "$HOME/.claude/skills/"

重启工具后生效。使用时只需要在 Prompt 中加上 $ultracode：

用 $ultracode 实现这个功能，端到端完成并验证。

如果任务可以拆分成并行子任务：

用 $ultracode。任务可以拆分时使用并行代理，
整合工作留在父会话，最后验证整个补丁。

第二句话就是委托规则。它告诉 Codex 什么时候该启动子代理，什么时候该自己处理。

为什么不需要 Python 运行时#

有些工作流系统依赖辅助脚本来管理流程。但 Ultracode Skill 的核心不是一个运行器，而是一个指令文件（SKILL.md）。

在 Codex 中，子代理由 Codex 自己启动。在 Claude Code 中，Dynamic Workflows 由 Claude Code 自己管理。一个可移植的 Skill 应该把编排工作交给宿主工具，自己只定义行为规则。

这也是为什么 Ultracode 同时兼容 Codex 和 Claude Code。它不是一个绑定到某个工具的插件，而是一个跨平台的行为规范。

更大的图景：Skill 生态的可能性#

Ultracode 只是 Skill 机制的一个应用实例。它揭示了一个更大的可能性：Codex 的 Skill 系统是一个开放的行为编程接口。

你可以用 Skill 来定义：

  • 代码审查的检查清单和优先级
  • 测试生成的覆盖率目标和断言风格
  • 文档更新的触发条件和格式规范
  • 依赖升级的安全检查流程
  • 部署前的验证步骤

每个 Skill 都是一个 Markdown 文件，不需要写代码，不需要安装依赖，只需要用自然语言描述你希望 Codex 怎么做。这种"行为即文档"的范式，可能是 AI 编程工具最被低估的能力之一。

写在最后#

Claude Code 的 Dynamic Workflows 是一个优秀的原生功能，但 Codex 通过 Skill 机制达到了几乎相同的效果。两者的实现路径不同，但核心理念一致：复杂任务需要显式的编排，而不是把所有工作塞进一个对话流里。

如果你经常用 Codex 处理大型任务，强烈建议试试 Ultracode Skill。它不会让你的 Codex 变快，但会让它的产出更可靠、更可追溯、更容易被团队信任。

参考来源：Ultracode for Codex: Claude-style Dynamic Workflows with a Skill（dev.to，2026-05-31）