终极 Agent 设计：唤醒 Claude × Codex [最新版本]

即使被要求"给出更具体的指令"，我也希望有人能帮我从那个"具体的部分"开始。

你心里有想做的东西，但在向 AI 提问前做前期调研时，手却停住了。这感觉很不划算。

比如，假设你想做一个可以登记案件并按截止日期排序的 App。你能说出这些。但如果被问到数据存储方式或如何排查 bug，需要调研的内容就突然变多了。

在调研过程中，你会开始砍掉原本想加的功能，想着"这次没有它们也许也行"。这不是因为实现起来难，而是你想把一切控制在自己能处理的范围内，万一出问题也好兜底。

我其实并不想在提问前准备好每一条细枝末节的指令。我希望你能发现我可能遗漏的地方。如果你能用清晰的方式让我在两个选项里做决定，然后根据我的决定继续推进工作，那就太好了。

本文要搭建的开发团队，就是为了让这类需求更容易落地，使用的是 Claude Code 和 Codex。

• Claude Code：需求的对接窗口。负责整理必要的确认事项和分工。
• Codex：负责实现与检查。

对于一个案件管理 App，除了创建界面，你还要准备验证任务。如果字段为空就提交会怎样？刷新页面后记录还在吗？如果 bug 没修好，就把尝试过的修复方案和残留症状总结出来，交给另一个 agent。

人类要做的是在过程中做出必要判断，并在最后验证实际运行情况。为此，你需要建立一套机制，让规格说明、变更内容和验证结果都能顺利回到你手上。我们一步步来搭建，从连接方式到任务交接，再到停止条件。

保持 Claude 开启的同时把工作派给 Codex

有一种方法可以把需求从 Claude Code 传给 Codex，而不需要把之前的回答粘贴到另一个 AI 里。那就是 OpenAI 发布的"Claude Code 用 Codex 插件"。

根据官方文档，它支持以下用途：

• 检查当前变更的 review

• 委派调查或修复任务

• 对话交接

本文基于 2026 年 10 月 16 日验证过的官方文档，介绍如何在本地环境的 Claude Code 中使用它。

前提条件

• 已安装 Claude Code 的环境

• Git

• Node.js（官方要求：18.18 及以上）

• 已通过 Codex 认证的 ChatGPT 账号，或 OpenAI API key

该插件调用的是你本地的 Codex。连接并不意味着 Codex 消耗的是 Claude 的额度；Codex 的使用会消耗 Codex 自己的额度。

另外，虽然这套配置处理的是本地文件，但 AI 推理不一定完全在你的电脑上完成。请先用一个不含机密信息的练习文件夹开始。

安装插件

在 Claude Code 的输入框中，从上到下逐条执行以下命令。这些是在 Claude Code 内部添加插件的操作，不是粘贴到普通终端里的命令。

1/plugin marketplace add openai/codex-plugin-cc
2/plugin install codex@openai-codex
3/reload-plugins
4/codex:setup

最后的 /codex:setup 可以用来检查 Codex 的安装和认证状态。如果找不到 Codex 但 npm 可用，会出现安装指引；请查看内容并按提示操作。

如果未认证，在终端运行 codex login 并按提示操作。

在 Windows 上，确保运行 Claude 的环境和安装 Codex 的环境不是分开的。别因为提示"not found"就反复重装。

先试试 Review

从不改写代码的 review 开始。在一个由 Git 管理的练习项目中准备一个小改动，然后执行：

1/codex:review --background

• 查看进度：/codex:status

• 查看已完成的结果：/codex:result

当有多个请求同时进行时，请指定显示的 Job ID，以免混淆结果。

Amazon 的公开示例对任务分工很有参考价值

关于角色分工的参考，可以看看 Amazon 云业务部门 AWS 发布的开发示例。在 GitHub 的 aws-samples 上有两个相关仓库：

• sample-codex-agent-team（面向 Codex）

• sample-claude-code-agent-team（面向 Claude Code）

Codex 版本包含六个角色：

决定如何构建注册界面，与考虑可扩展性、维护成本等，是两种不同的工作。把功能实现和运维咨询分开，能让向特定 agent 提出的问题更具体。

轻量级 review 并不是用来随意处理高风险变更的。它是一种分工方式，避免每次对文档编辑或机械替换这类低风险任务都进行重度检查。

两个示例的任务交接方式不同：

• Claude Code 版本：Agent 从共享任务列表中领取任务（使用实验性的 agent teams，需要额外配置）

• Codex 版本：按照划分了责任文件的工作计划推进

这两个是独立的示例。即使都安装了，也不会自动合并成一个团队。

另外，Codex 版本包含了基于未发布连接设置的模型指定。示例本身也说明了这些无法直接在所有人的账号上运行。与其原封不动地复制到公司关键项目里，不如只采用它的角色分工逻辑，并适配到你可用的环境中。

本文从一个小型结构开始：由 Claude Code 充当接口，把有限的实现和检查任务交给 Codex。

注意：这是一个参考公开示例的独特操作案例。它既不是保证 AWS 集成 Claude 和 Codex 的产品，也不是实测行为的报告。

动手之前先统一"可保存"的含义

当你无法详细描述想做什么时，不要立刻开始实现。先让 Claude 整理确认事项。你不需要懂所有技术术语；只要把它们转化成你能回答的问题就行。

我想做一个个人案件管理 App。请先整理必要的规格说明，然后一次问我一个需要决定的问题。对于技术选型，请简要说明对用户的影响以及推荐的理由。在我批准之前不要开始实现。

比如，关于保存：记录只要在同一浏览器里保留就够了，还是希望在手机和电脑之间共享？这两者需要完全不同的机制。默默选一种会导致后续返工。

对于这个练习，缩小范围：

• 范围内：在同一台电脑/浏览器上使用，刷新后记录保留

• 范围外：多设备同步、登录、对外发布、客户真实数据

用运行结果而不是"好用"来定义完成标准：

• 可以登记案件

• 按截止日期排序

• 可以更改状态

• 空内容提交时会显示原因

• 刷新后内容保留

把规格说明和任务请求保存到文件

把确定的内容保存到 docs/spec.md，作为所有人参考的规格说明。这里的文件名只是示例；它们不会自动分发给所有 AI，所以每次提需求时都要指明"读这个"。

把确定的规格说明、完成标准和范围外的功能保存到 docs/spec.md。不要把未决定的事项写成已确认。把需要暂停实现的事项与可以用临时设置继续推进的事项分开。

接下来，在 docs/tasks.md 中为实施者整理任务请求。光写任务名是不够的。要包含阅读材料、可编辑的文件、不可编辑的部分、验证方法和预期输出。

把规格说明拆分成可实现的单元。在 docs/tasks.md 中写明分配的文件、前置任务和验证方法。提前决定 UI 和存储逻辑之间的共享项。不要安排两个 agent 同时编辑同一个文件。

让两个 AI 看到同一份规格说明

持续性指令可以写在 Claude 的 CLAUDE.md 和 Codex 的 AGENTS.md 里。这是有文档说明的机制。不过，不要以为一份文件对另一方也能起同样作用。让两者引用同一个规格说明文件。

指令保持简短：

• 规格说明文件的位置

• 不要在请求范围之外做修改

复制规格说明会有其中一方过时的风险。这样可以避免这个问题。

并行任务前先隔离工作区

多个 AI 一起干活看起来更快，但用不同策略改写同一个文件只会给人类制造清理工作。

初次并行工作时，把"UI 构建者"和"测试规划者"配对。在格式确定之前分别实现 UI 和存储，会增加不匹配的问题。

用 Git Worktree 隔离文件夹

这里 Git worktree 很有用。它是 Git 的官方功能，允许为同一个项目创建独立的工作文件夹，各自包含不同的变更。

创建之前，确保规格说明和基础代码已经提交到 Git。未提交的草稿文件可能不会带到新位置。确认分支名和目标文件夹未被占用。

1git worktree add -b feature/ui ../case-app-ui
2git worktree add -b feature/storage ../case-app-storage
3git worktree list

三点注意事项：

1. 创建文件夹并不会改变 AI 的工作区。 要在每个目录下打开独立的会话，并在开始前确认位置和分支。

1. 插件使用调用者的环境。 连接 Claude/Codex 不会自动隔离。初期请坚持"一个位置一个编辑器"。

1. Worktree 主要隔离文件。 共享数据库或端口会引起冲突。请分开测试用的存储/端口，或者错开启动顺序。

限制 Codex 中的并发任务数

要在 Codex 中增加子 agent，需要限制并发线程数。子 agent 从父 AI 那里接收有限的任务。当前在 .codex/config.toml 中的配置：

1[agents]
2enabled = true
3max_concurrent_threads_per_session = 2

• 不要重复填写条目

• 只在受信任的项目中使用（项目设置只在受信任的上下文中加载）

• 该限制针对的是"该会话中除主 agent 之外的并发线程数"，而不是跨 Claude/会话的总数。

AWS 示例中的 14 个线程只是他们的选择，并非强制要求。他们的 max_threads 是旧版别名；请使用当前的名称。

不要每次都从零开始向实施者解释

在 Codex 中，通过 .codex/agents 下的 TOML 文件定义自定义 agent。创建 task-builder.toml 并写入必要条件：

1name = "task-builder"
2description = "仅按已确认的规格说明实现分配的范围"
3developer_instructions = """
4先阅读 docs/spec.md 和 docs/tasks.md。
5仅实现分配的范围；如果需要修改规格说明则停下来报告。
6不要回滚其他 agent 的变更、读取密钥或对外发布。
7返回变更的文件、执行的测试、结果以及未确认的事项。
8"""

避免在这里固定模型名称。默认会继承父级设置。公开示例中的模型在你的合同里未必可用；硬编码不可用的名称会在角色描述生效前就导致启动失败。

放好文件后，在新的 Codex 会话中确认是否识别成功，并委派一个小任务。如果是从 Claude 发起请求，请指定在 Codex 中使用 task-builder。

请求 Codex 把 docs/tasks.md 中仅存储逻辑的部分委派给 task-builder。开始前确认 agent 是否被识别以及实际文件夹。如果不可用，请报告而不是悄悄换方法。

注意：写"不要修改"和移除写权限是两回事。官方文档指出 Codex 子 agent 会继承父级权限（沙箱设置）。角色名叫"reviewer"并不能创建安全的只读环境。

如果修复反复失败就切换 Agent

如果 AI 说"找到原因了"但同样的操作又失败了，不要急着做下一次修复，而是记录下改了什么、没改什么。这样更容易交接。

官方插件提供了 rescue 入口，用于把调查/修复委派给 Codex。尽管名字叫 rescue，它适用于限定范围的任务，不只是 bug。

明确标记调查为只读

如果只是做原因分析，要明确说明不做写入。内部流程默认 rescue 是可写的，除非特别指定。把调查和修复区分开。

1/codex:rescue --fresh 调查为什么刷新后登记内容会消失，只读模式。对比 docs/spec.md 和代码。返回复现步骤、有证据的原因、需要的检查项。不要修改文件。

--fresh 会发起新请求；--resume 会继续上一个（省略时会提示）。恢复时请指定权限。如果要转入修复阶段，请界定范围。

1/codex:rescue --resume 基于已确认的原因，以最小改动仅修复存储逻辑。不要改动 UI/规格说明。展示修复前失败的测试和修复后的结果。

用 Transfer 转移整个对话

• 只传递任务 → rescue

• 把对话移到 Codex → transfer

1/codex:transfer

官方文档说明：它会创建一个 Codex 线程来延续当前的 Claude Code 对话，并显示恢复命令。如果不支持，请更新 Codex。

转移对话 ≠ 转移电脑状态。未保存的变更、认证信息、正在运行的应用都不会跟着走。请在目标端确认文件和状态。

"做完"之后用另一个 AI 验证

实施者自己测试有帮助，但如果他们误解了规格说明，通过的测试也不等于你想要的行为。

给检查者提供经人工确认的规格说明和实际变更，而不是实施者的解释。不要分享"完美修复"的评价；让他们独立检查是否符合要求。

独立对比 docs/spec.md 和实际变更。用证据指出未满足的完成标准。不要假定实施者的自我评价是正确的。把可复现的问题、潜在隐患和未验证事项分开。现在不要修复。

让对立面配对：

• Claude 实现的 → 加上 Codex 常规 review 作为独立检查

• Codex 实现的 → 让 Claude 检查，可选再加一个新的 Codex review

常规 Review 与对抗性 Review

用 /codex:review 调用常规 review。将分支与 main 对比：

1/codex:review --base main

如果没有 main 分支，请使用实际的基线分支。review 期间不要碰变更内容。

注意：常规 review 不接受类似"只检查存储部分"的自由文本聚焦指令。官方规范禁止优先级指令。如果想挑战设计假设或特定风险，请使用 adversarial-review。

1/codex:adversarial-review --background 检查保存失败是否会显示为成功，从两个标签页编辑是否会丢失记录，验证当前的设计假设。

这不是语气严厉，而是挑战所选方案/假设。两种 review 都是发现问题，不修代码。确认结果后，再单独委派修复。

整理发现结果，注明适用的完成标准、用户影响和验证方法。不要自动修复需要修改规格说明的问题；把选项和差异呈现给人类。

初期跳过 Review Gate

自动化选项："Review gate"会在 Claude 每次完成回复时插入 Codex review。用 /codex:setup --enable-review-gate 启用。

警告：官方文档提示，长时间修复循环可能在 Claude/Codex 之间快速消耗额度。

先从手动 review 开始，了解会发现什么问题。离开时请禁用。用 /codex:setup --disable-review-gate 停止，并检查待处理的请求。

把成功的请求留到下一个任务复用

与其反复粘贴长指令，不如把成功的工作流保存下来。Skills 允许把任务流程存成文件以便复用。

Anthropic 文档说明：把流程放在 .claude/skills 下。创建 team-brief 文件夹，其中的 SKILL.md 包含交接前的检查项。

1---
2name: team-brief
3description: 从规格说明中整理范围和验证项
4disable-model-invocation: true
5---
6阅读 docs/spec.md 和 docs/tasks.md，仅针对当前变更。
7整理范围、禁止的改动、前置条件、完成标准和验证项。
8为 agent 创建请求文本，把未决定的事项留给人类确认。
9在此流程中不要修改代码、对外发布或启动 Codex。

在 Claude Code 中调用：

1/team-brief 想增加按截止日期排序的功能

这是自定义命令，不是标准命令。disable-model-invocation: true 确保由人类把握触发时机。Claude 不会自动启动。流程本身不会强制启动 AI 或检查；先试试"只复用准备工作"。

大型任务的 Dynamic Workflows

对于更大范围的场景，Claude Code 提供了 Dynamic workflows（2026 年 5 月公布），可以编排多个 agent。在付费计划/API 中可用。

• 普通聊天：Claude 每次都自行选择下一个任务

• Dynamic workflows：用脚本控制分支/结果收集，可重复运行

例如：分别调查多个页面的保存失败、输入校验、布局错乱问题，然后交叉比对发现。不要为了小 App 启动庞大的 agent；当需要在更大范围内应用相同检查时再考虑。

创建 Dynamic workflow 来调查拆分后的页面，并用独立的 agent 验证发现结果。先列出目标、agent 数量和退出条件。不要修改代码；批准后在小范围内执行。

小贴士：

• 在 Pro 计划中通过 /config 启用

• 用 /workflows 监控进度/用量，可随时停止

• 在 /config 中选择规模（small 等）；官方文档称这些是估算值，不是严格限制。不要认为 agent 数量有保证。

这运行的是 Claude 侧的 agent。Codex 不会自动加入。先用于 Claude 内部的调查/验证；把委派给 Codex 当作单独的阶段。

端到端运行案件管理 App

把各组件连成一个完整的 App 构建。下面是解释性的开发示例，不是完成的体验报告；请在你的环境中验证。

构建目标

• 字段：案件名称、截止日期、状态、备注

• 状态：未开始 / 进行中 / 已完成

• 按案件名称搜索

• 查看按截止日期排序的未完成案件

初始请求

交给 Claude。目标是新的练习文件夹，而不是现有的关键项目。

在练习文件夹中构建个人案件管理 App。先确认环境和规格说明。包含名称、截止日期、状态、备注的登记/编辑/搜索/排序/持久化。排除登录、同步、对外发布。

候选存储方案：localStorage。不支持多设备同步/备份；清除浏览器数据会删除记录。不要放有价值的生产信息。

构建基础，定义共享部分

由单个 agent 构建基础。确认 App 能启动、空界面能正常显示。如果需要隔离工作区，先把规格说明和基础代码提交到 Git。

• 给 UI agent：显示字段、操作映射

• 给 Storage agent：记录格式、读取/新增/更新方法、失败处理

不要让任何一方自创字段名。如果状态字段叫 status，两边都用它。不要为了方便把一边改成 state；共享部分的变更要交回给 Claude 统一调整。

向 Codex 提出实现请求

指定可写入的位置，以及必须输出的证据。

1/codex:rescue --fresh 阅读 docs/spec.md 和 docs/tasks.md。仅实现分配的存储逻辑和测试。返回变更的文件、命令、测试结果和未确认事项。如果需要修改规格说明或改动其他 agent 的文件，请停下来报告。

同时，Claude 不要横向修改相同的文件。专注于完成检查和测试数据准备；等结果返回后再决定下一步。

准备验证数据

• 截止日期是昨天，"未开始"

• 截止日期是今天，"进行中"

• 截止日期是下周，"已完成"

• 多个截止日期相同的案件

• 超长的案件名称

这样才能做具体的排序/显示检查。

在规格说明中记录详细规则：

• 排序：截止日期相同时按登记顺序

• 空字段：名称/截止日期必填；备注可选。显示缺失的字段。

• 日期：定义日期切换的假设。时区/时间处理导致跨天会让 App 表面好看却无法使用。

提前定义规则可以避免实现后检查标准不一致。

集成与测试

实现准备好后，让 Claude 读取变更列表/测试结果，确认集成。如果用了 worktree，把变更收集到一个验证分支里。集成后重新运行那些单独通过的测试。

用 Playwright 做 UI 自动化。目前的指南为 AI agent 提供了 CLI/Skills；MCP 不是唯一方式。

把"AI 浏览器控制机制"和"可重复的测试"分开。用 Playwright Test 来做可重复运行的从登记到刷新的流程。

创建 Playwright Tests 验证登记、空内容拒绝、搜索、状态变更、截止日期排序、持久化。分离启动配置和测试数据。不要为了让测试通过而改变 App 行为或完成标准。

在新练习项目中的设置：

1npm init playwright@latest

如果已经安装，在添加之前先确认现有的启动/测试配置。

确保浏览器已安装，配置好 App 启动方式，然后运行：

1npx playwright test
2npx playwright show-report

关键点：不要把"未发现测试"或"全部跳过"当成"通过"。

失败时要定位原因：是存储 bug，还是测试在找一个不存在的按钮？不要为了让结果变绿就删测试；对照原始规格说明决定修复目标。

最终的人工验证

手动检查视觉效果。有隐藏文字吗？临近截止日期的案件容易找到吗？测试报告全通过不代表 UX 没问题。

从 Claude 那里接收四项内容，而不是长日志：

• 启动方法

• 已验证的行为

• 剩余的限制

• 下一步修复候选

自己登记一条数据，刷新，确认是否保留。然后标记完成。

何时停止持续修复

随着团队规模扩大，要定义终点。我们是在同一个 bug 上打转，还是在依次解决问题？状态不明确会影响后续指令。

设定停止标准

把"每个问题最多修两次"作为指导原则。这不是官方推荐，而是一条操作规则，用于在卡住时把判断权交还给人类。

如果同一个 bug 尝试两次仍未修复，停止进一步改动。总结尝试过的操作、做出的变更、残留的症状和需要的决策。不要扩展到无关功能。

光靠指令不能保证一定会停。要监控用量，用 /codex:cancel 取消不必要的后台请求。确认 agent 真的停了。

单独追踪成本

ChatGPT 认证的 Codex 额度和 API key 计费不同。并行的 agent 会消耗推理/工具资源。

不要把微小的文本编辑都经过两个 AI/大型 review。

分类：

• 单人可完成的任务

• 需要第二视角的任务

• 可独立并行的任务

这有助于决定投入和额度的分配。

留意过时的模型指定

旧的模型指定会导致失败。OpenAI 更新：面向 ChatGPT 认证 Codex 的 GPT-5.5 已于 2026 年 10 月 15 日（JST）下线。API key 认证不受影响。

把旧的规格说明/角色文件更新为当前可用的模型。确认可选的模型和接受的 reasoning 设置，而不只是改个名字。

检查权限与 Hooks

Claude 的权限不一定会传递给 Codex。要确认两边的执行权限。不要用生产凭证练习。删除、对外发布、计费操作需要单独审批。

使用公开示例前，先检查其中的 hooks。Hooks 会在设定时间自动执行；要看清实际运行了什么，别只盯着那些图方便加上去的东西。

如何衡量“做得快”

不要只比较生成时间。

• 你重新解释的次数

• 集成/修复耗时

• 剩余缺陷与完成标准的对比

把这些因素考虑进去，才能判断下次是否还能用同样的分工方式。

从每周的小工具开始

非工程师最容易在“自己能判断对错”的地方拿到成果。

• 咨询记录追踪

• 订单截止日期检查

• 排序规则统一的 CSV 格式化

先从能描述清楚的使用场景入手。

想优先处理快到期的？去掉已完成的？缺少输入时提醒？日常需求就是 AI 的完成标准。

不需要先精通编程；根据条件搭建原型，边用边修。注意：客户数据系统或公共服务不能只靠原型跑通，还需要专业验证。

初期团队这样搭配就够了：

1. Claude 整理需求规格

1. Codex 执行单个任务

1. 换个角度验证返回结果

把有用的请求和验证方法存下来，做下一个应用时就不用从头再解释一遍。

感谢阅读。

LINE Open Chat「Niku 的 AI 速度战略」免费发放 8 件套资料。

• Codex/Claude Code 入门指南

• 复制粘贴指令集

• 速查表

• 50 个迷你应用

• 50 个图像提示词

• yomiyasu 安装教程

• 标题生成器

• X 变现流程/收益金额

点击这里领取 👇 https://x.gd/VtPmw