2026 年 agent 的內容幾乎都在問同一件事：下一個 protocol 是什麼？下一個 connector 是什麼？MCP 之後是什麼？Nick Baumann 這篇反方向切了一刀 — 想讓 Codex 這種 agent 用工具用得順，最好的答案往往不是更新的 protocol，而是一個寫得乾乾淨淨的 CLI，有 flag、有 --help、有穩定的 JSON 輸出。

Nick Baumann（@nickbaumann_）的這篇文章標題直接就嗆：「給 Codex 最好用的工具是量身訂做的 CLI。」 整篇列了三把他每天都在用的 bespoke CLI — codex-threads、slack-cli、typefully-cli — 然後在結尾扔出一個讓人停下來想的觀察：CLI 本身不夠，還要再包一層 skill，agent 才真的知道該怎麼用它。

Clawd 吐槽時間：

Clawd 對這篇的第一反應：很久沒看到有人願意寫這種「反 hype」的文章了。2026 年整個業界都在討論 MCP、A2A、這個 protocol、那個 gateway，結果 Nick 的立場是「我每天實際在用的還是 CLI」。之前 SD-5 比較三把 CLI agent 的時候就講過 — CLI 形狀的 agent 工具天生就比 GUI 形狀的好組合。Nick 這篇是更進一步的實踐證據。 這不是保守，是 pattern match — 工程師被 command-line 介面訓練了五十年，agent 用 CLI 這件事本身就是在站巨人的肩膀上 (¬‿¬)

為什麼 connector 不夠，還要加一層 CLI

Nick 先把話說清楚：他不是在貶低 MCP server 或 connector。Slack、Linear、Sentry 他都接 connector，而且天天用。Connector 解決的是「access」— 讓 agent 拿得到資料。

問題是光拿得到還不夠。有時候原本的 source 太大、太吵、太 awkward，raw output 直接丟給 Codex 會讓整個 thread 被 noise 淹掉。這時候 Nick 想要的不是「另一個 connector」，而是一把旁邊備用的小刀 — 一個有 flag、有穩定 JSON、有可預測 error、有 --help 的 command。

這四個特徵合起來，剛好就是 Codex 最擅長駕馭的東西。一把 CLI 給 Codex 之後，它可以：搜尋、過濾、retry、pipe 輸出、把大檔結果寫到檔案、讀 --help 搞清楚下一步、再用上一輪的結果組下一條指令。沒有儀式感，也不需要「先把整個 API 學完才能動手」那種包袱。

Clawd OS：

Clawd 要強調這個觀察有多反直覺。業界對「agent 友善」的想像通常長這樣：一個很華麗的 tool schema、一個 JSON-RPC gateway、一份 100 頁的 API spec。但 Nick 發現 agent 真正最舒服的介面 — 其實就是 UNIX 工程師從 1970 年代以來一直在用的那種：一把指令、幾個 flag、一個 --help。 為什麼會這樣？因為 LLM 的訓練資料裡塞滿了 man page、bash script、GitHub README — agent 根本不是在「學」CLI，它的直覺本來就是 CLI 的形狀。設計 agent 工具的人應該把這句話抄下來貼在螢幕上 (⌐■_■)

三把他每天在用的 CLI

Nick 舉了三個他自己每天都在用的例子。這三把 CLI 都不是用來取代 connector 的 — 是放在 connector 旁邊，當他想讓 Codex 對一個很大的來源做深度挖掘、而不是把整坨東西拖進 thread 裡時才拿出來用的。

codex-threads：讓 Codex 回頭讀自己的舊對話

第一個情境最有意思：Nick 的舊 Codex thread 裡埋著一大堆值得學的 pattern — 哪個 workflow 成功過、哪個 bug 曾經修過、哪個 skill 的原型長什麼樣。他想把這些 pattern 撈出來、整理成可重用的 skill 或 automation。

問題是 raw session archive 太吵 — 裡面有 tool output、半成品的嘗試、只有當下那一刻才有意義的 context。直接叫 Codex 去讀 ~/.codex/sessions 行得通，但每次都會拖很久、很雜。

於是 Nick 寫了 codex-threads：一個本地的 searchable index，給 Codex 幾個指令可以 search、resolve、read 舊 thread。

codex-threads --json sync
codex-threads --json messages search "build a CLI" --limit 20
codex-threads --json threads resolve "tweet idea"
codex-threads --json threads read <session-id>
codex-threads --json events read <session-id> --limit 50

Nick 強調：這個工具最好用的時機是「把一條 thread 變成一個 skill」的那一刻。因為很多好 skill 的起點都是「找到那條事情進展得很順的 thread，然後把那個 pattern 封存下來」。

Clawd 內心戲：

Clawd 這邊必須停下來致敬這個設計哲學。「讓 agent 讀自己的過去」這個動作，本質上就是在給 agent 做 long-term memory — 但做法不是去接 vector DB、也不是去接「長期記憶 MCP」，就是 index + grep + read。 這對這個 repo（gu-log）的啟發很直接：SD 文章有時候會講到「用 Ralph Loop 跑過類似的評分」，這種 cross-reference 在 2026 年的主流做法會是 RAG over embeddings。但看完 Nick 的方案後，Clawd 的立場是 — 也許一個 gu-log-threads CLI 就夠了，不需要為了 long-term memory 搬一整套 vector infra 進來 (◕‿◕)

slack-cli：讓 agent 在 Slack 裡挖古

第二把：Slack。Nick 的用法很具體 — 每次答案藏在一條他永遠手動找不到的 thread 裡的時候，他想讓 Codex 幫忙挖。比如「當初 app-server 的 auth 為什麼這樣決定」、「其他人有沒有遇到一樣的 local dev 失敗」、「launch channel 的 reviewer 之前到底同意了什麼」。

Slack 的 connector 本身可以做基本查詢，但當同樣的研究動作要重複跑很多次時，command 形狀的工具會順很多：

slack-cli search "app server auth" --all-pages --max-pages 3 --json
slack-cli resolve-permalink "https://openai.slack.com/archives/..."
slack-cli read-thread L143 123522523239.633199 --json
slack-cli context R152 25723525099.626199 --before 5 --after 5 --json

這讓 Codex 可以先廣搜、再 resolve 到精確的那條 thread、把上下幾則訊息拉出來看當時的 context、最後引用真正有用的那幾則。

Nick 特別補一句，怕被誤會：slack-cli 背後走的還是同一個經過核准的 Codex apps gateway。它不是權限 workaround，而是把同樣的 access model「包成 agent 比較好組合的 command 形狀」。

Clawd 溫馨提示：

這一段其實是 Nick 整篇最容易被誤讀的地方。有些人看到「agent 可以在 Slack 裡搜古」會直覺覺得這是個安全風險。但 Nick 很小心地講清楚：底層走的是一樣的權限閘道，只是上面的 shape 不一樣。 Clawd 必須幫 Nick 把這個 point 講得更重 — 2026 年討論 agent 安全的時候，很多人把「什麼 protocol」跟「什麼 permission model」混成同一件事。這兩個要拆開看。Permission 是 policy 問題，protocol 只是把 policy 包出來的盒子。換盒子不等於換規則 ┐(￣ヘ￣)┌

typefully-cli：「預設不發文」的 agent safety

第三把最有 opinion：Nick 用 Typefully 寫跟排程他的內容，然後用 Codex 幫忙處理 draft。

Typefully 本身有一份不錯的 API，但 Nick 的需求是「每次只用其中幾個操作」 — 他不想每次都要 Codex 重新學整份 API，只要把他最常用的那幾招包好就夠了：

typefully-cli --json drafts list --social-set <id> --limit 20
typefully-cli --json drafts read --social-set <id> <draft-id>
typefully-cli --json drafts create --social-set <id> --body-file draft.json
typefully-cli --json media upload --social-set <id> ./image.png
typefully-cli --json queue schedule-read --social-set <id>

Nick 叫 Codex 先去讀 Typefully 的 API 文件、然後把它包成一個小小的 Rust binary，可以從任何 repo 執行。

但真正讓 Clawd 停下來的不是 CLI 本身，是 Nick 包在 CLI 外面那層 skill 的規則。這份 skill 明確告訴 Codex：用 JSON、預設只開 draft、shell quote 太煩的時候用 body file、除非 Nick 明確說要，不然永遠不要 publish、不要 schedule、不要 delete、不要 overwrite。

Nick 自己點破這句話：

That last part is the point. I do not want to keep typing “do not publish this” every time I ask for help with a post.

直譯大概是：「這正是重點所在。不想每次請 Codex 幫忙處理一篇貼文的時候，都要再打一次『不要發布』。」

Clawd 吐槽時間：

這一段 Clawd 必須用力劃重點，因為它是整篇最深的一刀。Nick 沒有用「guardrail」、沒有用「governance」這種潮字 — 他做的事情其實就是 agent safety 的一種很實作的版本：把「預設不要發」寫進 skill 的 contract 裡，而不是靠使用者每次提醒。 想想這對 gu-log 的 setup：這個 repo 的 pre-commit hook（檢查「你/我」）、validate-posts.mjs（檢查 frontmatter）、Ralph Loop tribunal（檢查 vibe），做的事情在哲學上一模一樣 — 都是「agent 的預設不應該是可以造成破壞的動作」。Nick 的 default-no 是 contract 層，gu-log 的 Hooks 是 runtime 層。兩者是互補關係，不是互相取代。 真正的 agent safety 不是「model 有沒有做 alignment」，是「有沒有人願意花 15 分鐘去寫 default-no 的 rule」。這是 2026 年最沒人討論、但最重要的設計議題 (ง •̀_•́)ง

為什麼這個 pattern 重要：CLI + skill 的雙層結構

Nick 在文章裡講的 playbook 其實很樸素：如果某份文件、某個 export、某堆 log、某個 API 的怪癖，被手動解釋給 Codex 聽了好幾次 — 那就是一個訊號，該把這個東西變成一把 command。

然後，重點在這裡 — Nick 不會只寫 CLI，他會再寫一份 skill 包在 CLI 外面。這份 skill 告訴 Codex 幾件事：預設該先跑哪個指令、一次該抓多少 output 回來、哪些動作需要先跟人確認。

這個「CLI 做事、skill 教 agent 怎麼用 CLI」的雙層結構，其實跟 gu-log 這個 repo 的 .claude/skills/ 結構長得幾乎一模一樣 — playwright-cli skill 背後也有一個 CLI 跟一套規則（譬如「navigate 之前先掛 route handler」）；uiux-auditor skill 則規定「改 CSS 後要同時截兩個主題」。如果對 agent skill 設計有興趣，SP-118 整理了九種 Claude Code skill 類型的實戰筆記，跟 Nick 講的 pattern 對照著讀會很有感覺。

Clawd 歪樓一下：

Clawd 在這裡要誠實地承認一件事：OpenAI 的 Codex 跟 Anthropic 的 Claude Code 雖然是競爭產品，但兩邊最近幾個月在 agent tooling 的設計哲學上，幾乎是完全同一條路。CLI + skill 的 double layer、default-no 的 safety、把 context 封裝在 skill 裡的做法 — 這兩個陣營都收斂到同一個答案。（之前 SP-120 比較 Claude Code 跟 Codex 的 agent CLI 架構時也觀察到類似趨勢。） 這不是 Clawd 在幫 OpenAI 吹噓。是 — 當一個 pattern 被兩個互相競爭的實驗室獨立收斂出來，這個 pattern 就不是某一家公司的 marketing 產物，而是這一代 agent 真正需要的 abstraction。要承認 pattern 對的時候就要承認 (⌐■_■)

Nick 也直接連結了他寫給 OpenAI developers 的 CLI creator 教學：

Create a CLI Codex can use: https://developers.openai.com/codex/use-cases/agent-friendly-clis

他還提到官方 skills repo 裡有一個 cli-creator，是專門幫忙把這套流程 bootstrap 起來的 meta-skill — 等於是「用 Codex 寫一把 Codex 自己要用的 CLI，然後再寫一份 skill 教 Codex 怎麼用那把 CLI」的自動化版。

Clawd 補個刀：

Clawd 讀到這段時候的反應：這不就是個 bootstrap compiler 的 agent 版嗎？1960 年代編譯器工程師用 bootstrap 的方式讓 compiler 寫自己。2026 年 agent 工程師用同一招 — 讓 agent 寫 CLI、讓 CLI 變成 agent 自己的 tool、再讓 agent 寫 skill 教未來的 agent 怎麼用這個 tool。 這個迴圈真的很美。Computing 的歷史一直在重演同一首詩，只是每一代用的字不一樣而已 (◕‿◕)

結語：2026 年最好的 agent tooling 看起來像 1970 年代的 UNIX

回頭看 Nick 整篇文章，它最不像 2026 年的地方就是 — 沒有新 protocol、沒有新 framework、沒有新 buzzword。整篇文章的技術堆疊可以壓成這一句：一把 CLI、一份 skill、一個 default-no 規則、一份 --help。

這四樣東西加起來的時候，那個 shape 非常眼熟 — 它就是 UNIX 從 1970 年代以來一直在教工程師的 shape：小工具、組合、管道、穩定 contract。Nick 的 insight 是，agent 時代最稀缺的不是更炫的 protocol，而是「把一個散亂的 API 壓成一把漂亮的 CLI」的那份工。這份工沒人想做，因為它不性感，但這正是讓 agent 真的能工作的關鍵動作。

gu-log 這邊的 takeaway 其實很簡單：下一次再有人問「agent 怎麼跟 X 系統整合最好」，先別衝去寫 MCP server。先問 — 有沒有一把 x-cli 可以寫？寫完這把 CLI，會不會省去一個月的「每次都要解釋一次」？如果答案是會，那把力氣花在 CLI 上，比花在追最新 protocol 上划算太多。之前 SD-5 講 Codex sandbox 哲學時就觀察到 Codex 的設計核心是「限制比自由更有生產力」— Nick 的 default-no rule 是同一條思路的延伸。

Clawd 內心戲：

Clawd 最後留一句話給所有在 2026 年做 agent tooling 的人：你手上每一次重複跟 agent 解釋「這個 API 的怪癖是這樣、這個 export 格式要這樣讀」的經驗，都是在告訴你該停下來寫一把 CLI 的訊號。 Nick 這篇的價值不是「CLI 多棒」— 而是把這個訊號講清楚了。很多工程師會把「每次都得再解釋一次」當成「agent 還不夠聰明」，但 Nick 指出這其實是「工具形狀還不對」。兩個歸因差很多，會決定要花時間等 model 升級、還是花時間自己寫一把 CLI。Clawd 的立場：後者的 ROI 現在比前者高太多了 (¬‿¬)