这篇是 Codex Plugin CC Rescue 原理 专题入口。原来的长文已经拆成学习地图:先看全景,再逐层拆桥接设计、Claude 入口、Node companion、Codex app-server、任务状态机和知识盲区。本文基于 openai/codex-plugin-cc 的公开仓库结构和已确认源码入口整理。

学习地图

建议按这个顺序读: 1. [[ai/Codex Plugin CC 01 桥接架构设计|Codex Plugin CC 01 桥接架构设计]]:先理解它为什么是桥,而不是一个普通命令。 2. [[ai/Codex Plugin CC 02 Claude 入口层|Codex Plugin CC 02 Claude 入口层]]:看 slash command 和 subagent 如何把请求送出去。 3. [[ai/Codex Plugin CC 03 Node Companion 层|Codex Plugin CC 03 Node Companion 层]]:看真正精妙的协议转换、job store、前后台管理。 4. [[ai/Codex Plugin CC 04 Codex App Server 层|Codex Plugin CC 04 Codex App Server 层]]:看 thread、turn、resume 为什么必须交给 Codex runtime。 5. [[ai/Codex Plugin CC 05 任务生命周期状态机|Codex Plugin CC 05 任务生命周期状态机]]:看 background、status、result、cancel、resume 如何串起来。 6. [[ai/Codex Plugin CC 06 知识盲区速查|Codex Plugin CC 06 知识盲区速查]]:补齐理解这套设计需要知道的概念。

先给结论

/codex:rescue 的精妙点不在“它会调用 Codex”,而在于它把一个跨 runtime 的复杂协作拆成了几条清晰边界:

flowchart LR
  U["用户在 Claude Code 输入 /codex:rescue"] --> C[Claude Slash Command]
  C --> A[Claude Subagent: codex-rescue]
  A --> N[Node Companion]
  N --> S[Job Store]
  N --> X[Codex App Server]
  X --> T[Codex Thread / Turn]
  T --> W[本地 Workspace]
  W --> X
  X --> N
  N --> C

每一层都只做一类事:

层级做什么不做什么
Slash command/codex:rescue 路由到 subagent不分析代码,不管理 job
Subagent把请求转给 Node 脚本不自己解决任务
Node companion参数解析、任务协议、状态管理、前后台不直接模拟 Codex agent
Codex app-serverthread/turn、模型调用、工具执行不关心 Claude 命令语义
Job store保存 jobId、log、threadId、结果不执行任务

为什么原来的长文不够好?

原来的写法把所有层混在一篇里,看起来像一条长流水账。真正该学的是边界设计

  • Claude 插件层如何把“用户命令”变成“可转发任务”。
  • Node companion 如何把“命令行参数”变成“可追踪 job”。
  • Codex app-server 如何把“job 请求”变成“thread/turn 执行”。
  • job store 如何让后台、恢复、查询、取消这些能力不用污染 Claude 层。

如果要复用这套思路做自己的工具,最值得抄的是“每层只翻译一个边界”,不是具体的 /codex:rescue 命令。

源码入口


相关笔记