上一篇談的是為什麼工程工作愈來愈常往 Codex 移。再往下問一步，問題會變得更實際：同樣一句「把這個登入測試修到過」，丟進一般聊天視窗和交給 Codex，工作過程為什麼差這麼多？

如果聊天視窗沒有直接接上你的 repo 和執行環境，模型一樣可以幫忙讀錯誤、看程式碼、推測原因；只是檔案要人貼進去，修改要人套回 repo，測試也要人自己跑，再把新的結果搬回對話。那個循環主要靠人在搬。

Codex 把其中很多接縫接了起來。它可以自己找檔案、讀 repo、執行 terminal、改 code、拿到測試結果，再根據新的結果往下一步走。模型仍然負責判斷，但它不再孤零零地只吐出一段文字。

OpenAI 把模型外面這套東西叫做 Agent Harness。

本文的知識截止日是 2026 年 5 月 20 日。5 月 21 日之後出現的 Codex 功能，不放回這篇歷史文章裡。

一句「把測試修過」，背後有一整個工作循環

把登入測試這個例子攤開，其實是一串很普通的工程動作：先找到相關檔案，判斷問題，修改，執行測試，看輸出；如果還是失敗，再回頭修。

Codex 的 agent loop 做的，就是把這串動作接成可以反覆走的流程。模型決定下一步，Harness 負責把工具叫起來，工具碰到真正的工作環境，結果再送回模型。OpenAI 在 2026 年 1 月公開的 Unrolling the Codex agent loop 裡，拆的就是這個循環。

Codex Harness 如何把模型、工具、工作區與結果串成一個循環

圖裡的幾個框不需要背。先抓住關係就夠了：Model 負責判斷，Context 提供題目，Tools 負責動手，Workspace 是事情真的發生的地方，Results 把現實世界的結果送回來。 Permissions 則卡在執行邊界上，決定哪些動作能直接做、哪些必須先停下來。

這也解釋了為什麼只看模型名稱，常常看不出一個 Coding Agent 實際好不好用。模型的 reasoning 和 code quality 當然重要；到了 agent workflow，context 是否正確、工具能不能用、repo 狀態是否清楚、測試能不能跑，會一起影響最後的結果。

2 月 4 日 OpenAI 公開 Codex Harness / App Server 的設計時，還補了一個很有用的角度：Web、CLI、IDE、桌面 App 可以共享同一套 Codex Harness。操作入口可以不同，真正把模型、工具、執行和狀態串起來的那層仍然是同一套系統。

App Server、MCP 和更底層的 protocol 留給後面的專文；要先理解 Harness，沒必要先鑽進架構考古。

多個 Agent 一起動手，Worktree 才會突然變重要

一個 Agent 修登入 bug 沒什麼戲劇性。三個 Agent 同時改同一個 repo，問題就來了。

假設 A 在修登入，B 升級 dependency，C 改設定頁。三個工作如果共用同一份 working directory，A 還沒收尾的檔案可能已經被 B 看見，C 跑出的測試也可能帶著別人的未完成修改。最後留下來的 diff 混在一起，review 會變得很痛苦。

Worktree 做的事情很單純：替平行工作切出各自的施工區。

Codex 透過 Command Center 指派多個 Agent，在各自獨立的 Worktree 中平行工作

2026 年 2 月 2 日推出 Codex App 時，OpenAI 就把 multi-agent、parallel work、isolated worktrees、diff review 放在同一個產品設計裡。這幾個功能擺在一起很合理：能同時派很多 Agent 只是第一步，接下來得讓它們不要互踩，還要讓人看得懂每一份修改是怎麼來的。

Skills 和 Automations 也在這個階段一起進到 Codex App。這篇不展開它們的操作細節，只要先知道它們服務的是同一件事：Codex 開始承接一段可以被安排、重複、檢查的工作，而不只是一段 code 回覆。

Git、Branch、Worktree、PR 到底怎麼分，後面會另外拆一篇。現在先把 Worktree 記成「隔離平行施工」就好。

Command Center 把人的注意力往上移

OpenAI 在 2 月推出 Codex App 時用了 command center for agents 這個說法。這個名稱描述得很準：人的注意力開始從每一條 command，往任務、diff、方向和權限移。

原本自己打 command、改檔案、跑測試的那些細節，可以交給 Agent 往下做。人留下來看的是另一層：這個任務要不要繼續、方向有沒有偏、哪一份 diff 值得接受、哪個高風險動作要批准。

於是工作會長成這樣：

  • 交代任務
  • 讓不同 thread 或 Agent 各自往前跑
  • 看 diff、command output、test result
  • 中途 steering
  • 碰到權限邊界時 approve 或拒絕

這也是 Harness Engineering 那篇文章裡「Humans steer. Agents execute.」最容易落地的地方。人沒有離開流程，只是不需要再當每一步的鍵盤手。

這個分工還會反過來要求 repo 本身更清楚。文件、測試、CI、專案規則如果一團亂，Agent 能拿到的訊號也會很差。OpenAI 在同一篇文章裡把 docs、tests、CI、observability 和 feedback loop 都放進 agent-first engineering 的環境裡，原因就在這裡。

所以長任務也不該只靠模型「記住全部」。規格放在文件裡、狀態留在 repo 裡、驗收寫進測試裡，Agent 需要時重新讀。比起把整個專案永遠塞在 context window 裡，這種 externalised state 更接近正常工程工作的做法。

能做更多事之後，權限和驗收會變得更重要

Harness 把工具接得愈完整，Agent 的手就愈長。能讀寫檔案、跑 shell、用 browser、碰 network，確實能少掉很多人工搬運；同一時間，誤操作的範圍也跟著變大。

權限因此不能只當成設定頁裡的一個選項。OpenAI 5 月 8 日公開 Running Codex safely at OpenAI 時，把 sandbox 和 approval 分開談。Sandbox 劃的是技術邊界，例如可以寫哪裡、network 能不能出去；Approval 處理的是「這一步需不需要人先點頭」。模型知道怎麼執行一個 command，跟系統允許它直接執行，是兩回事。

驗收也是同樣的道理。Agent 回一句 done，對工程工作沒有太大證明力。測試有沒有過、build 有沒有成功、diff 到底改了什麼、scope 外的檔案有沒有被碰到，這些才是可以檢查的東西。

Harness 還負責把 command output、test result、diff 這些回饋接回流程。失敗可以再修，人最後也有 evidence 可以 review。OpenAI 在長任務與 Harness Engineering 的文章裡反覆強調 acceptance criteria、validation command 和 done-when 條件，背後就是這個邏輯。

Hooks 比較像「在固定時機插一個檢查」，不是新的權限層

5 月 14 日 Hooks 進入 GA 後，Codex workflow 多了一個很實際的接點：可以在 lifecycle 的特定時機掛上 validator、secret scan 或其他既有規則。ChatGPT & Codex changelog

例如一個 task 做完後，本來團隊就要求跑 secret scan，那個檢查可以接在固定 lifecycle point，不必每次都靠人記得補一句 prompt。這和 Skill 有點像，都能減少「每次重新提醒」；但 Hook 比較像事件到了就觸發某段檢查或動作，Skill 則是 Agent 在做某類工作時要遵循的一套 procedure。

Hook 也不是安全通行證。某個 validator 被叫起來，只能證明它有執行；要不要接受結果，還是得看那個 validator 實際檢查了什麼、輸出是什麼。它不會因為掛在 lifecycle 上，就自動把 done 變成可信的 completion evidence。

這一點放回 Harness 很好理解：Harness 不只把模型和 tools 接起來，也要讓 repo 裡原本存在的 checks 在對的時機出現。真正的 correctness 仍然要回到 tests、build、diff、validator output 和 acceptance criteria。

到同一個 5 月 14 日，控制面也往外延伸了一點：OpenAI 公開手機端的 Codex preview，可以從手機看 thread、terminal output、diff、test result 並進行 steering。這裡只把 Remote preview 和 Hooks 當成 5 月 20 日以前的里程碑，不往後面的 Goal 或其他功能倒灌。

把 2026 年初排成一條線，方向會清楚很多

單看 release note，1 月到 5 月像是一串互不相干的更新。排在一起之後，脈絡比較明顯：先把 agent loop 接起來，再處理多 Agent、Worktree 和共用 Harness，接著讓 repo、測試、CI 變成 Agent 能利用的工作環境；4 月擴大觀察與操作能力，5 月再把執行邊界、遠端監工和 lifecycle control 補上。

2026 年 1 月到 5 月 20 日間，Codex 的 Harness 能力如何逐步補齊

這張圖特別把 May 20 畫成截止線。它不是 Codex 發展的終點，只是這篇文章能使用的知識邊界。5 月 21 日以後的功能，留給後面的文章。

之後再看任何 Coding Agent，可以多問幾個很實際的問題：它拿得到哪些 context？有哪些 tools？工作狀態放在哪裡？多個 Agent 怎麼隔離？權限邊界在哪？它說完成時，能留下什麼 evidence？

模型仍然是整套系統裡最重要的零件之一。Codex 的日常體驗，最後落在模型怎麼跟 repo、工具、權限、驗收接起來。

下一篇會把這張地圖往日常操作拉近：Plan、Steering，以及不同操作 surface 該怎麼選。

參考資料