强强联手！把 Codex 接入任何智能体(Claude Code, OpenClaw, Hermes, ...)

最近在 Claude Code 里写文章，临时想让 Codex 帮我生成一张封面图。我下意识的反应是：开个新终端，跑 codex，进交互模式，再粘提示词。三步走完，原本在 Claude Code 里的上下文也断了 - 出完图回来还要把路径手动贴回去。

这种「切换上下文做一件小事」的体感太熟了，熟到值得拿出来认真处理一次。我研究了一圈 mrfacecheck/codex-bridge - 一个用 MCP 把 Codex 包成服务的实现，证据收集、Git diff、worker 进程一应俱全。但对我这个场景来说，那一套太重了。我只是想让 Claude Code 这一类 agent 在需要的时候，调一次 Codex，拿到结果，继续自己手上的事。

于是有了 codex-cli skill。这篇想聊聊它是怎么来的、为什么这么做、以及一个跟我一样会被 Codex 出图的「藏文件」行为坑到的人，能从里面拿走什么。

核心其实就一行命令

很多人不知道，Codex CLI 早就支持非交互式调用：

codex exec "Explain what this repository does"

codex exec 接一个提示词，跑完打印结果就退出 - 跟 curl 一次 API 调用没什么区别。要管路径、用沙箱、要 JSON 输出，再加几个 flag：

codex exec -C /path/to/project -s read-only "Review the architecture"
codex exec --json -o /tmp/codex-out.md "Analyze this repo"

Claude Code 这边其实有一模一样的接口：

claude -p "Explain this repository"
claude -p "Summarize this" --output-format json

两边都有 -p / exec，都有 JSON 输出，都能从 stdin 接长文本。这意味着只要在任何一个 agent 里能跑 shell，它就能调另一个 agent - 不需要 MCP，不需要 SDK，不需要桥接进程。一行 codex exec，就是 agent 与 agent 之间最薄、最稳的协议。

那为什么还要做 skill？因为「能跑」跟「跑得对」中间还隔着几件事：要先确认 CLI 装没装、要按 Codex 推荐的格式组提示词、要知道 Codex 出图会把文件偷偷藏在哪。这些细节要让每个 agent 在每次调用前自己重新摸索，不现实 - 装一个 skill 一劳永逸。

codex-bridge 的启发与取舍

回头说一下 codex-bridge 的设计 - 它有一招我特别认同，但我没把它搬进 skill 里。

它最聪明的地方是 run-scoped diff：Codex 跑之前先用临时 Git 索引把整个 worktree 快照一次，跑完再快照一次，diff 拿的是「这一次 Codex 跑」造成的变化，而不是「workspace 跟 HEAD 的差」。如果你的仓库本来就有未提交的改动，这一招能干净地把 Codex 的产出和你手上的脏状态分开。

为什么我没搬？因为 skill 的定位是「让另一个 agent 知道怎么用 Codex」，不是「替另一个 agent 监视 Codex」。Claude Code 自己就有 git diff、有 Edit 工具、有 TodoWrite，它完全有能力在 Codex 跑完之后自己看一眼仓库状态。skill 只要负责把命令拼对、把图找回来、把口径报准 - 剩下的留给宿主 agent 自己决定。

少做事，是为了让这层薄到任何 agent 都愿意装。

skill 真正在做的几件事

SKILL.md 体量不大，但每条规则都对应着我踩过的一个坑。

第一件：先验证 codex 是不是真的在。 Skill 启动时先跑 command -v codex 和 codex exec --help。后者还有一个作用 - 它是 CLI flag 的真相源。Codex CLI 还在快速演进，今天的 -s workspace-write 明天可能换名字。让 skill 在跑的时候去问一次本机的 help，比让我把 flag 写死在文档里要稳得多。

第二件：按 Codex 官方推荐的格式组提示词。 OpenAI 在 Codex Best Practices 里给的提示词四件套是：

Goal:
Context:
Constraints:
Done when:

这四行写出来，Codex 的输出会显著更聚焦。Skill 里明确要求宿主 agent 在委托非平凡任务时用这个结构组提示词 - 不是建议，是默认动作。

第三件，也是最关键的：把 Codex 偷偷藏起来的图找回来。 这是我第一次让 Codex 帮我生成 16:9 黑香蕉时翻车的地方。Codex 跑完打印了「图已生成」，但既不给路径，也不在当前目录留东西。最后是我自己摸到了它的小金库：

~/.codex/generated_images/<session-id>/ig_<hash>.png

<session-id> 是 Codex 这次会话的 ID，在标准输出和 --json 事件流里都会出现。Skill 把这套行为写进流程：

• 优先从 Codex 输出里抓 session id，直接 ls "$CODEX_HOME/generated_images/<session-id>"
• 抓不到就退一步，find 按修改时间排序找最新的
• 找到之后再用 sips 或 file 验一遍真实尺寸，确认是不是用户要的 16:9

最后一条很要紧 - 生成图的实际尺寸经常是 1672 x 941 这种「数学上不是精确 16:9 但取整后就是」的值。Skill 报告时要把真实尺寸亮出来，告诉用户「effectively 16:9」，不糊弄。

第四件：项目要用的图，绝不能只躺在 ~/.codex 里。 这条是兜底纪律。如果用户的本意是「给我项目当封面」，skill 必须在确认权限后把图复制到项目内 - 否则下次清理 ~/.codex 的时候，blog 引用的封面就全空了。

不打算做的事

Skill 设计的时候，有几件事我故意没做，记一下，免得未来的我或别人接手时一冲动加上去。

不做 MCP 服务器。 因为它不需要进程常驻、不需要异步、不需要跨 session 持久化。codex exec 已经够了。MCP 适合的是「我要把一个外部世界的能力接进来」，但 Codex CLI 本来就在同一台机器上，再起一层 IPC 是没必要的开销。

不做 worker/进程监督。 codex-bridge 用 detached worker 是为了「客户端断了，Codex 还能继续跑完」。我的场景里宿主 agent 自己就是个长跑进程，等 codex exec 同步返回没问题，反而能让宿主 agent 第一时间拿到错误。

不做敏感文件过滤。 codex-bridge 里有一套 .env 指纹识别、防止 Codex 把 secrets 复制到别名文件里偷出去的逻辑。这套机制非常聪明，但属于「写文件场景下的额外防护」。skill 默认走 read-only 沙箱 - 只读模式下 Codex 根本写不了文件，这个攻击面被沙箱本身堵掉了。需要写入时，宿主 agent 应该用自己的安全机制把关，不该由这层薄 skill 越位。

不假装看到了 Codex 没说的事。 Skill 明文写了：如果 Codex 说生成了图但 ~/.codex/generated_images 里没文件，照实说「没找到」，不编路径。同样，Codex 的图 PNG 元数据不暴露具体后端模型，所以 skill 不允许声称「用的是 gpt-image-2」之类 - 没证据就不说。

这几条「不做」加在一起，整个 skill 才能稳定地保持在 200 行左右的 SKILL.md。一旦超出去，说明它在替宿主 agent 做事，该退回去。

装一下试试

仓库在 sugarforever/01coder-agent-skills。装法跟其他 Vercel skills 一样：

npx skills add sugarforever/01coder-agent-skills/skills/codex-cli

装完之后，在任何支持 Agent Skills 的 agent 里 - Claude Code、OpenClaw、Hermes Agent 都行 - 直接说人话就能触发：

让 codex 看一下这个仓库，找出可能的 bug。

或者：

让 codex 生成一张 16:9 的黑香蕉封面图。

宿主 agent 会自己 codex exec、组提示词、抓图、验尺寸、报路径 - 你不需要去记任何一个 flag。

写在最后

我意识到这件事可能是个更大趋势的开端：agent 与 agent 之间最自然的协议，不是 API，不是 MCP，而是 CLI。

每个有出息的 coding agent 都给了自己一个非交互式入口 - Codex 是 codex exec，Claude Code 是 claude -p，未来更多 agent 会加进来。这些 CLI 之间天然兼容：能跑 shell 就能互相调，传文本就行，不需要任何一方做特殊适配。Skill 在这中间扮演的角色，是把每个 CLI 的怪癖（藏起来的图、特定的 flag 顺序、推荐的提示词结构）封装成一个可装的能力包，让宿主 agent 不用为每个被调方重写一套调用逻辑。

强强联手不是把它们焊在一起，而是给每一个都留一条窄门，然后让它们自己决定什么时候喊对方上场。

---

• codex-cli skill 仓库：01coder-agent-skills/skills/codex-cli
• Codex 官方最佳实践：developers.openai.com/codex/learn/best-practices
• 启发来源 codex-bridge：github.com/mrfacecheck/codex-bridge