轉向 Codex 與產品地圖 Part 02｜我為什麼從 OpenClaw 轉向重度使用 Codex

我把 OpenClaw 接到 Discord 之後，遇過一種很煩的狀況：Agent 明明有跑，最後一則訊息卻沒回到 Discord。

模型答錯反而比較好查，我可以回頭看 prompt、context，或是模型到底哪裡理解錯。訊息直接不見就麻煩很多，Gateway、Session、Queue、Discord plugin、Provider、Network，甚至剛升版的 config 都可能要翻。

OpenClaw 好用的地方其實也就是這些。它很早就把常駐 Agent、Channel、Memory、Skills、Plugins、MCP、Routing、Cron 和 Background Tasks 放進同一套 self-hosted runtime 裡。[1][2] 我到現在還是會用它，尤其是需要跨 Channel、長時間在線的 personal-agent 工作。

只是我後來每天真正花最多時間處理的，已經變成 Repository 裡面的 implementation、平行修改、Review、Debug 和 Verification。這些工作我越做越常直接開 Codex，用久了之後，主力自然就慢慢移過去了。

我覺得 OpenClaw 拿來當常駐 Agent 就還挺適合的

OpenClaw 本來就是走 multi-channel gateway for AI agents 這條路。WhatsApp、Telegram、Discord、iMessage 這些入口都可以接到同一個 Gateway，Session、Routing 和 Channel connection 也都在這一層處理。[1]

這其實很符合我一開始想要的使用方式。Agent 放在自己的機器上，我平常直接從 Discord 找它；幾個小時之後再回來，Session、Memory 和 Workspace 還在。它比較像一個一直在線的工作者，不是每次要用才重新開一個 coding session。

OpenClaw 的 multi-agent 架構也做得蠻完整。不同 Agent 可以有自己的 Workspace、agentDir、Auth Profile、Session Store、Skills 和 Model，Gateway 再按 Channel、Account 或 Peer 做 routing。[2] 後來也有 /steer、subagent steering、MCP 和 Plugin 管理。[3][4]

所以我一直不太喜歡拿功能表一格一格比。很多東西兩邊都有，實際用起來差最多的，反而是你每天到底在管什麼。

我後來每天其實都在管 Git state

Codex App 出來之後，Projects、Threads、Worktrees、Diff、Review、Skills 和 Automations 都放在同一個 App 裡，多個 Agent 也可以平行處理工作。[5]

我很快就開始依賴 Worktree。

OpenClaw 比較自然的隔離方式，是把不同 Agent 分開。Workspace、Session、Auth、Skills 各自有自己的邊界，Gateway 再決定 Discord 或 Telegram 的訊息要送去哪個 Agent。拿來做 personal assistant 很合理。

但我在 Repository 裡每天碰到的問題通常不是「這是哪個 Agent」，而是「這個 Agent 現在到底改哪一份 working state」。

兩個 Agent 會不會碰到同一批 uncommitted changes？我要 Review 哪個 Diff？哪一條工作線可以進主要 Branch？這些才是我真的一直在處理的東西。

Git worktree 剛好把這些問題拆開。一個 Agent 在自己的 worktree 裡改，另一個 Agent 可以同時做別的變更；我最後看各自的 Diff，再決定怎麼收。[5]

用久了之後，我就會覺得 Repository 當工作中心比較順。因為我每天花時間管的是 code 和 change，不是 Agent identity。

長任務做到一半歪掉，能直接拉回來差很多

GPT-5.3-Codex 上線時，OpenAI 同時強調 mid-turn steering。Agent 還在工作，我可以再送新的指示，不用整個 context 丟掉重開。[6]

這對長一點的工程任務真的很好用。Agent 可能漏看一個檔案，也可能做到一半跑去一條我不想要的 implementation path。有時候 requirement 是我自己中途改的。

這種情況我通常不想叫它全部重來，只想補一句：「不要走這條，先看另外兩個檔案。」然後讓它接著做。

OpenClaw 也有 /steer、/subagents steer 和 queue controls。[3] 我自己比較常在 Codex 裡用，是因為 Thread、Worktree、Terminal、Diff、Review 和 Approval 都在旁邊。看到哪裡不對，就直接拉回來，不用另外切去別的控制面。

OpenAI 的 Harness Engineering 文章也讓這件事更容易理解。Repository、Tests、CI、Documentation、Observability、Review 和 Feedback Loop，本來就都是 Agent 能不能把工程工作做好的一部分。[7]

我後來看 Agent 產品也很少只看模型強不強。我會看 Context 怎麼進來、Tools 能碰什麼、Workspace 怎麼隔離、出錯怎麼查、做完之後怎麼驗。

三月那一串 Codex 更新剛好都在補這些東西。Local 和 Worktree thread handoff、GitHub / PR workflow、integrated terminal、Automations、Diff / Review navigation、過往 Thread 搜尋，還有把 Skills、App integrations 和 MCP configuration 包在一起的 Plugins，都慢慢接到同一條工程 workflow 上。[8]

我不是看到哪一條 release note 就決定換工具。比較像是用了一陣子之後，發現同一件工程工作要切來切去的地方少了很多。

Discord 沒回訊息時，我就得自己一路往下查

OpenClaw 連 Discord 之後，我碰過 Agent 已經把事情做完，但最後訊息沒有送回來的狀況。

這種問題很煩，因為你第一眼根本不知道哪一層有問題：

Discord
Gateway
Session
Queue
Provider
Agent
Reply

旁邊還有 Plugin、Network、Config、Version、Auth 和 Timeout。每一個都可能要看。

OpenClaw 更新很快，我自己的環境升版之後，也常會再確認一次 Channel、Gateway、Provider、Config 和 Plugin 有沒有一起正常。這不算什麼奇怪的事情，開源專案跑很快本來就會這樣，只是最後花時間排查的人還是我。

OpenClaw 的 issue tracker 上也有兩個跟我遇到的狀況很像的案例。一個是升到 2026.5.4 之後，Discord 第一則 outbound reply 正常，後面的 reply 會 silent drop；另一個則是 Gateway event-loop degradation、Discord heartbeat timeout，連 local status call 都會卡到大約 50 秒。[9][10]

我不會因為這兩個 issue 就說 OpenClaw 普遍不穩。比較像是看到別人也遇過同一類問題，至少知道不是只有我這套環境會踩到。

如果我要的是一個跨 Channel、一直在線的 Agent，這些維護成本我可以接受。因為 Gateway 本來就是我要的東西。

但我只是要改 code、看 Diff、跑測試、Debug UI 的時候，我就會開始想：那我幹嘛還要多顧這一層？

Codex 比較接近我真的在 Debug 的流程

Codex App 後來可以碰到的東西越來越多。In-app browser、Computer Use、Chats、PR workflow、Artifact Viewer、Multiple Terminals、SSH remote connections 這些東西都慢慢進來。[11]

對我比較有感的是 Browser 和 Terminal。

Codex 已經可以讀 integrated terminal，後來又可以操作 in-app browser，在 local development server 或 file-backed page 上點 UI、重現 visual bug，再看 local fix 到底有沒有真的修好；同一批更新還加入 automatic approval reviews。[12]

所以 frontend debugging 可以一路這樣跑：

Edit code
↓
Run
↓
Read terminal
↓
Inspect UI
↓
Reproduce
↓
Fix
↓
Verify
↓
Review / Approve

OpenClaw 用 Browser、Shell、Tools 和 Plugins 當然也能組類似流程。[3][4] 只是我自己真的在做事的時候，Codex 少很多 setup 和切換。

Terminal、Browser、Worktree、Diff、Review 原本就在我眼前。Debug 一個 frontend bug 的時候，我不用先想 Gateway 要怎麼接，也不用把一堆結果搬來搬去。

現在我看一個 Agent 工具，會很在意它說「完成」之後，我還剩多少事情要自己補。

如果最後還是得自己去看 terminal、開 browser、對 diff，再把結果整理回 Agent，那我會覺得前面自動化得還不夠完整。

人不在電腦前，現在也沒那麼依賴 OpenClaw 了

我一開始很喜歡 OpenClaw 的一個原因，就是人不在電腦旁邊也能從 Discord 找它。

後來 Codex 也可以從 ChatGPT mobile app 連回正在跑 Codex App 的 Mac。工作還是在那台機器上跑，手機端可以接回同一套 Projects、Files、Credentials、Plugins、Skills 和 Configuration。[13]

OpenClaw 在 multi-channel 這件事上還是明顯更自由。Discord、Telegram、WhatsApp 都可以當入口，Agent 也可以長時間在線。

但如果我只是人在外面，想看一下工程進度、補一句指示、處理 approval，現在不一定要為了這件事另外養一套 Gateway。

Plugin 也是差不多的感覺。OpenClaw 已經有自己的 Plugin、Skill 和 MCP surface。[3][4] Codex 的 Plugin model 則把 Skills、App integration 和 MCP config 放在同一個 bundle 裡，也可以按 user 或 repository 安裝。[8]

我做 repo work 時比較喜歡這種方式。某個專案需要什麼能力，就跟這個 Repository 一起想。真的要做跨 Channel、長時間常駐的 personal workflow，我還是會回 OpenClaw。

最近開始注意到，蠻多人也在討論區問「多這一層到底值不值得」之類的問題

V2EX 上就有人直接問：「OpenClaw 跟我遠程操作 Claude/Codex 的區別在哪？」討論裡提到的問題其實跟我的感覺很像：很多 coding 工作直接在 Claude Code 裡就能做，OpenClaw 還要多處理 Login、Skills、Browser automation 和穩定性。[14]

後來又多了一個很現實的問題：錢。

Anthropic 告知使用者，Claude subscription limits 不再涵蓋 OpenClaw 這類 third-party harness；如果還要繼續這樣用 Claude，就要另外走 pay-as-you-go usage 或 API billing。[15]

同一段時間，Claude Code 本身也在往長任務走。Anthropic 公布的資料裡，最長那一批 interactive turns 已經拉到 45 分鐘以上；5 月 6 日又把 Claude Code 的 five-hour rate limits 對 Pro、Max、Team 和 seat-based Enterprise 用戶加倍。[16][17]

OpenClaw 的 Web traffic 那時候也掉得很明顯。非凡產研公布的 4 月數據估計，月訪問量約 1,420 萬，環比下降 50.67%；獨立訪客約 631 萬，環比下降 46.98%。這個我只把它當成熱度的 signal，不能直接說成一半使用者都跑了。[18]

Codex 的官方使用數字剛好往另一個方向走。OpenAI 4 月 21 日說，4 月初每週使用 Codex 的開發者超過 300 萬，兩週後超過 400 萬。[19]

我不覺得這些數字可以證明大家都從 OpenClaw 搬去 Codex。比較像是 coding-heavy 的人開始有更多理由直接待在 first-party coding harness 裡。需要常駐 personal agent 的人，還是會有另一套需求。

我現在大概就這樣分

Workload	我會先開	原因
Persistent multi-channel assistant	OpenClaw	Gateway、Channel、Session 本來就是工作的一部分
Self-hosted personal automation	OpenClaw	我需要長時間在線與本機控制
Repository implementation / refactor	Codex	Worktree、Diff、Review 都在同一個工程工作面
多條平行 code change	Codex	Working state 比 Agent identity 更需要隔離
Frontend debugging / verification	Codex	Terminal、Browser、Review 的來回比較短
離開電腦後查看工程進度	Codex 或 OpenClaw	看我要的是 Project continuity 還是 Channel continuity

這個分工以後一定還會變。

如果哪天我主要都在做跨 Channel 的 personal automation，OpenClaw 應該又會吃掉更多時間。

但現在我每天一直碰的是 repo state、review、debug 和 verification，所以 Codex 自然就變成主力了。

References

1. OpenClaw, v2026.3.31, OpenClaw documentation: What is OpenClaw?, 25 March 2026.
2. OpenClaw, v2026.3.31, Multi-Agent Routing.
3. OpenClaw, v2026.5.7, Slash commands, including /steer, subagent steering, /mcp, and /plugins.
4. OpenClaw, v2026.5.7, Plugins.
5. OpenAI, Introducing the Codex app, 2 February 2026.
6. OpenAI, Introducing GPT-5.3-Codex, 5 February 2026.
7. OpenAI, Harness engineering: leveraging Codex in an agent-first world, 11 February 2026.
8. OpenAI, ChatGPT & Codex changelog, March 2026 entries, especially 3, 11, 12, 19, 24 and 25 March.
9. OpenClaw GitHub issue #78104, Discord outbound silent-drop regression report, opened 5 May 2026.
10. OpenClaw GitHub issue #77995, Gateway event-loop / Discord heartbeat regression report, opened 5 May 2026.
11. OpenAI, Codex for (almost) everything and Codex changelog, 16 April 2026.
12. OpenAI, ChatGPT & Codex changelog, 23 April 2026: Browser Use and Automatic Approval Reviews.
13. OpenAI, ChatGPT & Codex changelog, 14 May 2026: Work with Codex from anywhere.
14. V2EX, OpenClaw 跟我遠程操作 Claude/Codex 的區別在哪兒？, 5 March 2026. Community anecdote, used only as evidence that this question was already being discussed.
15. TechCrunch, Anthropic says Claude Code subscribers will need to pay extra for OpenClaw usage, 4 April 2026, reporting Anthropic’s customer notice and public explanation.
16. Anthropic, Measuring AI agent autonomy in practice, 18 February 2026.
17. Anthropic, Higher usage limits for Claude and a compute deal with SpaceX, 6 May 2026.
18. 非凡產研 via 新浪財經, OpenClaw April 2026 web-traffic report, 11 May 2026. Web-traffic data, not an active-user measure.
19. OpenAI, Scaling Codex to enterprises worldwide, 21 April 2026.