让 Codex 指挥 Cursor Agent 干活：一个省额度的多 Agent 工作流

最近在用 Codex 做比较长的工程任务时，遇到一个很现实的问题：Codex 的体验很好，但额度并不是无限的。

如果一个任务要长时间读仓库、查资料、反复写文档、跑验证，Codex 的周额度和短周期额度会降得很快。与此同时，Cursor 那边也有 Agent 和 GPT 模型，额度按月算，池子更宽裕。直觉上，这两边应该能配合起来：Codex 负责我真正想待着的主工作台，Cursor 负责分担一部分可以独立完成的活。

难点在于，Cursor 并不是 Codex 的一个后端模型接口。不能简单理解成「Codex 直接调用 Cursor API」。更现实的做法是把 Cursor Agent 当成另一个可被命令行唤起的 worker：Codex 把任务说明、工作区、边界和输出格式写清楚，通过 cursor-agent 派出去；Cursor 做完后，Codex 再接回结果，复核、验证、决定要不要采用。

这篇文章记录的是这套流程怎么落地。

为什么不是直接全部用 Cursor

如果只看模型和额度，很容易得出一个简单结论：既然 Cursor 额度更宽裕，那就多用 Cursor。

但实际做工程任务时，工具体验也很重要。Codex 的线程、文件编辑、终端输出、验证流程和长期上下文更适合做主控。很多任务不是一次 prompt 就结束，而是需要一边读代码、一边调整判断、一边跟用户解释取舍。

Cursor Agent 可以做很多事，但它作为 worker 更合适：

  • 宽范围代码搜索。
  • 找调用链和相似实现。
  • 出一版方案或文档初稿。
  • 做第二视角 review。
  • 承担局部、可复核、可丢弃的机械改动。

这些任务有一个共同点：结果可以被主控 Agent 验收。Cursor 不需要知道当前对话里所有细枝末节，只要拿到清楚的任务包，就能产出有用的中间结果。

因此这套工作流不是「谁替代谁」，而是「谁站在主控位，谁做 worker」。

主控和 worker 的边界

我最后采用的是这样的分工：

角色 负责什么 不负责什么
Codex 理解用户目标、整理上下文、决定分派、验证结果、最终交付 不把所有耗时搜索和初稿都自己扛完
Cursor Agent 在明确边界里读代码、找证据、出计划、写局部初稿 不接管主线、不直接对用户交付、不自行扩大任务范围

这个分工的核心是：Cursor Agent 只做子任务，Codex 保留最终判断权。

Cursor 给出的结论不能直接贴给用户。Codex 至少要做几件事：

  • 只读结论要回到源码、命令输出或官方资料核验。
  • 如果 Cursor 改了文件，要看 git status --short、git diff --stat 和关键 diff。
  • 根据风险跑必要验证，比如 typecheck、lint、测试、构建或本地预览。
  • 最终回复里区分哪些是 Cursor 建议，哪些已经由 Codex 确认，哪些还没有验证。

这里最容易犯的错，是把两个 Agent 都当成主控。这样上下文会分叉，文件修改会混在一起，最后反而更费额度。

为什么要写进 AGENTS.md

一开始，我只是写了一个 Skill，告诉 Codex 在额度紧张时可以调用 Cursor。

这不够。

Skill 的问题是：它通常要被触发后才会加载。可真正想要的不是「用户每次提醒一句用 Cursor」，而是每个非轻量任务开始时，Codex 都主动问自己一句：有没有一块工作可以交给 Cursor？

所以这条规则应该放进全局 AGENTS.md，而不是只放在某个 Skill 里。

全局规则大概像这样：

## Codex / Cursor Agent 分工默认规则

- 每个新对话和每个非轻量任务开始时，都要主动判断能不能把一部分工作交给 Cursor Agent。
- Codex 负责主控、上下文整理、复核验证和最终交付；Cursor Agent 负责分担可隔离、可验收、可复核的子任务。
- 如果 Codex 额度吃紧，或观察到 Codex 消耗明显高于 Cursor 消耗，默认进入主动分流状态。
- 调用 Cursor 前先把任务包写清楚：工作区、允许做什么、禁止做什么、已知线索、输出格式、是否只读。
- Cursor 结果必须由 Codex 验收，不能直接转述给用户。

这段规则解决的是「会不会想起来」的问题。

真正的细节仍然放在 Skill 里，例如命令怎么写、模型怎么选、什么任务适合分派、Cursor 输出怎么验收。全局 AGENTS.md 负责把分流意识放到每个对话里；Skill 负责把流程写完整。

先把 Cursor Agent 当成命令行 worker

Cursor 提供了命令行入口。官方介绍里也把 Cursor CLI 描述成可以在终端、脚本和自动化流程里运行 Agent 的方式，并展示了模型选择能力。

Cursor CLI 页面展示了 Cursor Agent 可以在终端里运行，并且可以选择模型。实际脚本里仍要以本机 cursor-agent --help 和 cursor-agent models 输出为准。

开始前先做几个低成本检查：

command -v cursor-agent
cursor-agent status
cursor-agent models
cursor-agent --help

我本机看到的关键能力包括：

  • --print：非交互输出，适合脚本调用。
  • --mode ask：问答式只读任务。
  • --mode plan：只读规划任务。
  • --workspace <path>：指定工作区。
  • --model <model>：指定模型。
  • --trust、--sandbox：控制 headless 场景下的信任和沙箱行为。

因此最基础的只读调用可以写成：

cursor-agent --print \
  --mode ask \
  --workspace <PROJECT_PATH> \
  --model gpt-5.5-extra-high \
  "请只读分析这个问题，不要修改文件。..."

受控执行可以写成：

cursor-agent --print \
  --trust \
  --sandbox enabled \
  --workspace <PROJECT_PATH> \
  --model gpt-5.5-extra-high \
  "请只修改以下范围，保持 diff 最小，最后列出改动文件和验证方式。..."

但我更建议再包一层脚本，避免每次手写参数。

~/.codex/skills/codex-cursor-agent-delegation/scripts/run-cursor-worker.sh \
  --workspace <PROJECT_PATH> \
  --mode ask \
  --model gpt-5.5-extra-high \
  --prompt-file /tmp/cursor-task.md

这层脚本不需要很复杂。它只要统一 --print、--workspace、--mode、--model、--sandbox、--trust 这些参数，让 Codex 每次分派时少犯错。

Fast 开关不要假装已经配上

Cursor UI 里可以看到 GPT-5.5 的 Fast 开关。这个地方要单独说明，因为它很容易被误解。

截至我本机测试的 cursor-agent 2026.05.28-418efe5，headless CLI 里没有独立的 --fast 或 --speed 参数，cursor-agent models 也没有列出 gpt-5.5-extra-high-fast 这类模型 ID。也就是说，在脚本里传 --model gpt-5.5-extra-high，只能保证选择 GPT-5.5 Extra High，不能保证等价于 UI 里打开了 Fast。

这条边界应该写进 Skill，避免后续误以为脚本已经开了 Fast：

- 不要把 `gpt-5.5-extra-high` 等同于 Cursor UI 里的 `GPT-5.5 Extra High + Fast`。
- 当前 headless CLI 只有 `--model`，没有稳定可传入的 Fast 参数。
- 如果将来出现 `gpt-5.5-*-fast` 这类模型 ID，或 CLI 新增 `--fast` 参数，再更新脚本默认值。

这是一个典型的工具边界：UI 里能看到的选项，不一定已经以同样形态暴露给 headless CLI。

任务包比模型选择更重要

让另一个 Agent 干活，最重要的不是命令，而是任务包。

Cursor 不会自动继承 Codex 当前对话里的所有隐含上下文。任务包写得含糊，它就只能猜；猜得越多，Codex 后面验收结果越费劲。

我现在给 Cursor 的任务包通常长这样：

# Cursor Worker Task

## 背景

一句话说明用户目标，以及为什么这部分任务交给 Cursor。

## 工作区

- repo: `<PROJECT_PATH>`
- 当前状态：如已知则写；未知则要求 Cursor 自己只读确认。

## 你要做什么

- 列出 3-5 条明确任务。
- 如果是只读，写明「不要修改文件」。
- 如果允许修改，写明允许改哪些路径、禁止改哪些路径。

## 你不要做什么

- 不要提交。
- 不要 push。
- 不要发布。
- 不要操作线上数据。
- 不要覆盖用户未提交改动。

## 已知线索

- 文件路径、报错、接口名、关键词、已有结论。

## 输出格式

1. 核心结论
2. 证据：文件路径、行号、命令输出或文档链接
3. 建议改法或已改内容
4. 验证方式
5. 风险和需要 Codex 复核的点

这里有几个细节很重要。

第一，任务包要写「不要做什么」。对 Agent 来说，边界和目标一样重要。

第二，要求输出证据。没有文件路径、行号、命令输出或链接的结论，复核成本很高。

第三，写明 Codex 会复核。这样 Cursor 的角色会更稳定，它会更像 worker，而不是另一个试图接管全局的主控。

哪些任务适合交给 Cursor

我会优先分派这几类任务：

  • 大范围代码搜索：找入口、找调用链、找同类实现。
  • 只读第二意见：让 Cursor 独立判断方案风险、漏测点和边界条件。
  • 文档结构草稿：让 Cursor 先列结构、证据清单和初稿，再由 Codex 改成最终文章。
  • 机械性初稿：局部类型补齐、测试样例补齐、重复代码调整。
  • Review worker：让 Cursor 看 diff，Codex 判断哪些 finding 真成立。

这些任务都有一个特点：结果可复核。

不适合分派的任务也要明确：

  • 极短问答。
  • 依赖当前浏览器、飞书页面、桌面状态或登录态的任务。
  • 涉及密钥、账号、线上写操作、删除、发布的任务。
  • 无法复核的大范围重构。
  • 高度依赖当前对话细碎上下文的任务。

多 Agent 协作不是为了让所有活都被拆掉。它的价值在于把可隔离的中间工作拆出去，把主控 Agent 的额度留给判断、复核和交付。

Cursor worker 也应该有自己的 Skill

如果只给 Codex 写规则，Cursor 被调用时仍然可能不知道自己是谁。

所以我还给 Cursor 侧写了一个很小的 worker Skill。它的核心不是增加能力，而是固定角色：

# Codex Cursor Agent Worker

## 角色

你是 Cursor worker，不是当前任务的最终主控。

- Codex 负责用户沟通、主线判断、最终复核和交付。
- 你负责完成 Codex 交给你的独立子任务。
- 输出必须方便 Codex 验收：少讲空泛判断，多给文件路径、行号、命令、改动范围、验证结果和剩余风险。

这类 Skill 的正文不需要长。它只要让 Cursor 明白：自己应该按任务包边界工作，不能自行扩大范围，也不能把没有证据的判断包装成最终结论。

Codex 的 Skill 能不能像包一样安装

可以做到一部分，但它和 npm / Homebrew 不是同一种成熟度的包管理模型。

从官方说明看，Codex 已经有 Skill 的可视化入口。OpenAI Academy 的 Plugins and skills 里提到，可以在 Codex 左上角进入 Plugins，然后查看推荐或已安装的插件、浏览插件库、创建新插件；Skill 也可以从同一个入口访问，想在对话里调用 Skill 时，可以按 $ 选择。

OpenAI 在 Introducing the Codex app 里也提到，Codex app 有创建和管理 Skills 的专门界面；Skill 可以显式调用，也可以根据任务自动使用；创建的 Skill 可以在 app、CLI 或 IDE extension 里使用，也可以放进仓库给团队共享。

所以，UI 层面是有的：可以浏览、创建、管理和调用 Skill。

命令层面也可以做到一部分。Codex Skill 本质上是一组本地文件，实际结构通常是：

~/.codex/skills/
  <skill-name>/
    SKILL.md
    agents/openai.yaml
    scripts/
    references/
    assets/

如果一个团队想要一条命令安装，可以把 Skill 放进 Git 仓库，再写一个很薄的内部安装脚本，把指定目录复制或同步到 $CODEX_HOME/skills。语义大概是：

./scripts/install-codex-skill.sh \
  https://github.com/<owner>/<repo>/tree/<ref>/<path-to-skill>

./scripts/list-codex-skills.sh

但它还不是 npm 那种完整包管理器。

npm / Homebrew 通常会处理版本、依赖、升级、卸载、冲突、锁定和 registry 搜索。Codex Skill 现在更像「可被 Codex 识别的一组本地 playbook」，可以通过 UI 创建管理，也可以通过团队自写脚本从 Git 仓库安装，但还不应该假设它具备完整包管理器语义。

如果要给团队使用，我更推荐三层做法：

  • 通用 Skill 放进 Git 仓库，保留 SKILL.md、agents/openai.yaml、scripts/、references/、assets/。
  • 用安装脚本从 GitHub 路径拉到 $CODEX_HOME/skills。
  • 对仓库强相关的规则，直接放在项目 AGENTS.md 或仓库内 Skill，让团队成员 checkout 后就能读到。

这样既能像「安装包」一样复用，又不会把 Skill 当成 npm 包那样过度设计。

这套方法真正解决了什么

这套工作流解决的不是「让 Cursor 更像 Codex」，也不是「让 Codex 偷用另一个模型接口」。

它解决的是更实际的问题：当一个人同时拥有多个 Agent 工具时，怎么把它们组织成一套可控流程。

主控 Agent 负责理解目标、保护上下文、做最终判断。worker Agent 负责承担可隔离的中间工作。中间用任务包传递上下文，用 Skill 固化边界，用脚本降低调用成本，用复核清单保证结果可信。

这听起来比「直接多开几个 Agent」麻烦一点，但它更稳定。

真正让多 Agent 工作流可用的，不是同时运行多少个模型，而是每个 Agent 知道自己站在哪个位置。