強強聯手！把 Codex 接入任何智能體(Claude Code, OpenClaw, Hermes, ...)
整理版優先睇
用 codex exec 一行命令，讓任何智能體（Claude Code、OpenClaw 等）直接調用 Codex，配合 skill 封裝驗證、提示詞格式同圖片處理細節，徹底解決切換工具斷上下文的問題。
作者本身喺 Claude Code 寫文章，想用 Codex 生成封面圖，但要開新終端、跑 codex、貼提示詞，搞掂返嚟個上下文就斷咗。呢種「為咗做一件小事而切換工具」嘅體感令佢好睏擾，於是研究點樣可以令 agent 之間直接互相調用。佢睇過 codex-bridge，但覺得用 MCP 包裝太重型，唔適合只係「叫一次 Codex 做嘢」呢個簡單場景。
佢嘅解決方案係一個得 200 行 SKILL.md 嘅 codex-cli skill。核心得一句：codex exec，呢個指令本身就係 agent 之間最薄最穩定嘅協議，唔使 MCP、SDK 或者橋接進程。Skill 只係喺上面包裝咗驗證 CLI 係咪存在、按官方格式組織提示詞、自動揾返 Codex 生成嘅圖同埋抄去項目入面呢啲常用細節，令宿主 agent 唔使每次自己重複摸索。
作者刻意唔做 MCP 伺服器、唔做 worker 監控、唔假裝見到 Codex 冇講嘅嘢。佢嘅設計哲學係：少做事，先至可以令呢層薄到任何 agent 都願意裝。成個 skill 就係一條 exec 命令加一個提示詞模板，裝咗之後直接講人話就可以叫 Codex 做分析、生成圖像之類嘅任務。
- 結論：一行 codex exec 就係 agent 之間最薄最穩定嘅協議，唔需要 MCP 或 SDK。
- 方法：用 SKILL.md 封裝驗證 CLI、按官方格式組織提示詞（Goal、Context、Constraints、Done when）、自動找回圖片同複製到項目。
- 差異：同 codex-bridge 相比，唔做 run-scoped diff，留畀宿主 agent 自己用 git diff 處理，skill 只做最薄嘅一層。
- 啟發：少做事係為咗令呢層薄到任何 agent 都願意裝，避免過度設計令 adoption 成本增加。
- 可行動點：直接 npx skills add 安裝，然後喺任何支援 skills 嘅 agent（Claude Code、OpenClaw、Hermes）入面講人話觸發。
codex-cli skill
用 codex exec 將 Codex 接入任何智能體嘅 Skill，封裝驗證、提示詞格式、圖片找回同複製。
從煩惱到解法：為何要做 codex-cli skill？
作者喺 Claude Code 寫文時想用 Codex 生成封面圖，但「開新終端 → 跑 codex → 貼提示詞 → 出圖 → 手動貼路徑」呢個流程，徹底打斷咗原本嘅上下文。佢話呢種「切換工具做一件小事」嘅體感太熟，熟到值得認真處理。
於是佢整咗 codex-cli skill，一個得 200 行 SKILL.md 嘅輕量方案，核心就係 codex exec 呢個非互動式指令。
最薄嘅協議：一行 codex exec
Codex CLI 本身已經支援 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</highlight-inline> 接口。兩邊都有 -p/exec、JSON 輸出、stdin 接長文本，即係只要任何一個 agent 能跑 shell，佢就能調另一個 agent——唔需要 MCP、SDK、橋接進程</highlight-inline>。
skill 真正做嘅四件事
- 1 首先驗證 codex 是否存在：用 command -v codex 同 codex exec --help。後者係 CLI flag 嘅真相源，避免硬編 flag 喺文檔。
- 2 按官方格式組織提示詞：OpenAI 喺 Codex Best Practices 四件套係 Goal、Context、Constraints、Done when，skill 要求宿主 agent 喺非平凡任務時用呢個結構組提示詞。
- 3 自動揾返 Codex 生成嘅圖：Codex 會將圖藏喺 ~/.codex/generated_images/</highlight-inline> 下嘅 session id 資料夾。Skill 會先抓 session id，然後用 find 按修改時間排序，最後用 sips/file 驗證真實尺寸，報告例如「effectively 16:9」。
- 4 將圖複製到項目內：如果用戶係打算用圖做封面，skill 會喺確認權限後將圖抄入項目目錄，避免清理 ~/.codex 時誤刪引用。
呢四件事加埋，令宿主 agent 唔使記任何 flag，直接講人話就用到 Codex 嘅能力。
刻意唔做嘅事：保持薄度
作者有幾件事故意唔做：唔做 MCP 伺服器，因為 codex exec 已經同步執行，唔需要 IPC 常駐進程；唔做 worker 監控，因為宿主 agent 自己係長跑進程，等同步返回完全冇問題；唔假裝見到 Codex 冇講嘅嘢</highlight-inline>，例如唔報圖像元數據入面唔存在嘅後端模型。
安裝好簡單：npx skills add sugarforever/01coder-agent-skills/skills/codex-cli</highlight-inline>，之後喺 Claude Code、OpenClaw、Hermes Agent 入面直接講人話就觸發到 Codex。
最近喺 Claude Code 寫文章，臨時想叫 Codex 幫我生成一張封面圖。我自然反應係：開個新終端，執行 codex，入互動模式，再貼提示詞。三步做完，原本喺 Claude Code 嘅上下文都斷咗 — 出完圖返嚟仲要手動貼返個路徑。
呢種「切換上下文做一件小事」嘅感覺太熟啦，熟到值得拎出嚟認真處理一次。我睇咗一圈 mrfacecheck/codex-bridge — 一個用 MCP 將 Codex 包成服務嘅實現，證據收集、Git diff、worker 進程樣樣齊。但對我呢個場景嚟講，嗰套太重手。我只係想俾 Claude Code 呢類 agent 喺需要嘅時候，叫一次 Codex，拎到結果，繼續自己做緊嘅嘢。
於是就有咗 codex-cli skill。呢篇想傾下佢點樣嚟、點解咁做、同埋其他智能體究竟可以從 Codex CLI 得到啲乜。
Codex CLI skill：
https://github.com/sugarforever/01coder-agent-skills/blob/main/skills/codex-cli/
核心其實就係一行命令
好多人唔知，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 冇講嘅嘢。 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。
最近在 Claude Code 裏寫文章，臨時想讓 Codex 幫我生成一張封面圖。我下意識的反應是：開個新終端，跑 codex，進交互模式，再粘提示詞。三步走完，原本在 Claude Code 裏的上下文也斷了 - 出完圖回來還要把路徑手動貼回去。
這種「切換上下文做一件小事」的體感太熟了，熟到值得拿出來認真處理一次。我研究了一圈 mrfacecheck/codex-bridge - 一個用 MCP 把 Codex 包成服務的實現，證據收集、Git diff、worker 進程一應俱全。但對我這個場景來說，那一套太重了。我只是想讓 Claude Code 這一類 agent 在需要的時候，調一次 Codex，拿到結果，繼續自己手上的事。
於是有了 codex-cli skill。這篇想聊聊它是怎麼來的、為什麼這麼做、以及其他智能體究竟能從 Codex CLI 得到些什麼。
Codex CLI skill:
https://github.com/sugarforever/01coder-agent-skills/blob/main/skills/codex-cli/
核心其實就一行命令
很多人不知道，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 沒說的事。 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。