Codex掛鉤讓代理框架真正成形

OpenAI於2026年5月14日將Codex導入ChatGPT行動應用程式。公告中更關鍵的訊號藏在後段：Remote SSH與掛鉤已正式開放使用，Business與Enterprise方案也推出程式化存取權杖。¹

這改變了工作本身。Codex不再像是守在單一終端機裡、等待指令的程式碼助理。它更像一層運作層，能讓工作橫跨機器、核准流程、對話串、差異、測試、截圖、外掛、憑證與本地工具。²

Codex掛鉤讓代理框架真正成形。一旦代理能從手機操作、連到遠端開發環境，並執行生命週期掛鉤，團隊就需要在模型外圍建立控制系統：證據、核准、Git保管、來源紀律與品味。

重點摘要

Codex現在支援代理團隊一直在內部打造的工作流程形態：長時間執行的工作、遠端執行、行動引導、核准、掛鉤、限定範圍的憑證與稽核訊號。¹²³提示仍然重要，但運作層更重要。

實務問題不是「我們該如何提示Codex？」而是「Codex必須證明什麼，我們才信任結果？」團隊應透過掛鉤與設定，把審查關口、安全邊界、公開寫作標準與發布紀律寫進流程。私有機制應保持私有；公開的應是模式、驗收條件與已驗證的成果。

重要結論

對工程團隊： - 將Codex掛鉤視為流程基礎設施，而非裝飾。 - 先建立證據、核准、Git保管與發布檢查，再加入聰明的自動化。

對代理工具建構者： - 圍繞Codex真正提供的介面來建構：行動控制、Remote SSH、沙箱模式、核准政策、專案指示、掛鉤、遙測與版本控制。 - 移植要完成的任務，不要移植舊式斜線命令的外形。

對公開寫作者： - 使用OpenAI官方文件確認最新Codex行為。 - 將私有實務標示為作者分析，並避免在公開文案中揭露私有提示、掛鉤內容、檔案路徑、來源清單、憑證與評分內部規則。

5月14日改變了什麼？

OpenAI在5月14日的公告，使Codex更接近一個持續存在的工作介面。ChatGPT行動應用程式中的Codex可以連上執行Codex的機器，載入該環境的即時狀態，並讓使用者從手機審閱輸出、核准命令、切換模型、開始工作，以及追蹤差異、終端機輸出、測試結果、核准與截圖。¹

同一則公告也提到Remote SSH已正式開放使用。Codex可以連入遠端環境，從SSH設定偵測主機、建立專案，並在遠端機器中執行對話串。¹開發者文件則更具體地說明遠端連線：遠端存取會使用連線主機上的專案、對話串、檔案、憑證、權限、外掛、Computer Use、瀏覽器設定與本地工具。²

OpenAI也將掛鉤推進到正式開放使用。公告列出具體用途：掃描提示中的機密資訊、執行驗證器、記錄對話、建立記憶，以及針對儲存庫與目錄自訂Codex行為。¹掛鉤文件將掛鉤定義為一套可把指令碼注入Codex迴圈的擴充框架；設定參考則公開了features.hooks，可載入來自hooks.json或行內設定的生命週期掛鉤。⁷⁶

這些細節很重要，因為它們把代理工作從聊天往返，轉成受治理的作業流程。

為什麼掛鉤比行動控制更重要

行動存取改變的是人能在哪裡介入。掛鉤改變的是系統能強制執行什麼。

手機讓操作者離開桌面時也能回答問題。掛鉤則能在高風險動作之前、檔案編輯之後、完成之前，或發布檢查期間攔住代理。手機解決延遲問題；掛鉤解決標準問題。

Codex已經有第一方控制介面來處理沙箱與核准。OpenAI的安全文件指出，Codex結合了沙箱模式與核准政策：前者定義代理在技術上能做什麼，後者定義Codex何時必須停下來詢問再行動。³同一份文件也指出，網路存取預設為停用；本地預設的workspace-write模式也會保持網路存取停用，除非使用者啟用。³

掛鉤位於這些控制旁邊。目前的掛鉤事件包含SessionStart、PreToolUse、PermissionRequest、PostToolUse、UserPromptSubmit與Stop；PreToolUse可以攔截受支援的Bash呼叫、透過apply_patch進行的檔案編輯，以及MCP工具呼叫，但OpenAI文件提醒，它不會攔截每一條shell路徑、WebSearch，或其他非shell、非MCP工具呼叫。⁷因此，掛鉤是審查與引導層，不是沙箱的替代品。

掛鉤可以把本地標準變成可執行流程：

模型可能忘記規則。掛鉤能在規則真正重要的時刻重新執行規則。

代理框架就是運作層

代理框架是模型外圍的運作層：權限、記憶、工具、掛鉤、來源檢查、發布關口、審查包與回復紀律。這個詞聽起來或許私密又複雜，但任務其實很明確：把意圖轉成可問責的工作。

Codex現在已提供足夠的官方介面，使這一層能被明確定義。遠端連線會承載主機環境。沙箱模式與核准政策定義行動邊界。設定檔定義模型、專案、權限、MCP伺服器、技能、掛鉤、遙測與功能。⁶OpenTelemetry可以記錄使用者提示、核准決策、工具執行結果、MCP使用情形，以及網路代理決策等事件。³⁴

這組介面形成了有用的分工：

供應商應持續改善執行環境。判斷仍由團隊負責。

團隊應先寫入哪些規則？

從4個關口開始。它們會立刻產生價值。

證據關口

Codex最初的發布文章強調可驗證證據：任務完成期間的終端機記錄、測試輸出與可追蹤步驟。⁵這項期待應成為不可妥協的標準。有意義的完成應清楚列出變更檔案、執行命令、觀察到的行為、失敗檢查與剩餘缺口。

對公開工作而言，證據包含來源連結，以及主張與來源是否一致。對網站發布而言，證據包含已渲染路由、中繼資料、schema、探索檔案、部署狀態、快取新鮮度與線上變更標記。對翻譯而言，證據包含語系覆蓋、品質關口、儲存列或快取檔案，以及必要時的母語者審查狀態。

核准關口

不要把所有動作套用同一種核准姿態。OpenAI的核准文件區分了安全的唯讀瀏覽、工作區編輯、需要核准的網路存取、不受信任的命令、自動審查模式，以及危險的完整存取。³強健的本地政策也應保留相同形態：低風險讀取安靜通過，有副作用的工作需要審查，破壞性或對外可見的工作則需要明確證據。

Git保管關口

代理工作需要可回復的控制點。Codex自己的安全文件指出，Codex最適合搭配版本控制：委派前保持狀態乾淨、頻繁提交、執行目標式驗證、審查差異，並在提交訊息中記錄決策。³

這項建議應轉化為流程。於一致且已驗證的存檔點後提交。只暫存精確路徑。依可獨立回復的關注點拆分提交。除非發布流程已授權發布，否則推送前先詢問。不要因為代理碰巧看見無關的未提交檔案，就把它們一併掃進提交。

品味關口

AI寫程式降低了實作成本。實作越便宜，品味越有價值。

品味不是裝飾偏好。它代表工作是否改善了整個產品。它代表代理能拒絕一條技術上可行、但會削弱成果的路徑。它代表公開寫作避免私有機制、缺乏支持的主張與填充文字。它也代表，即使本地修補正確，只要使用者可見路徑仍然故障，依舊算失敗。

品味關口應提出這些問題：

Mozilla展現了同樣模式

Mozilla於5月7日發表關於使用Claude Mythos Preview強化Firefox的文章，從不同技術棧說明了同一件事。團隊表示，早期LLM程式碼稽核嘗試展現潛力，但誤報太多，難以規模化。代理式框架改變了成本結構，因為它們可以建立並執行可重現的測試案例，動態驗證漏洞假設。⁸

Mozilla真正重要的一句話，不只是關於模型本身。團隊指出，發現問題是必要條件，但並不足夠。有用的系統必須整合完整的安全漏洞生命週期：目標、去重、漏洞追蹤、分流、修補與發布。⁸作者也表示，該管線反映了Firefox程式碼庫的語意、工具與流程。⁸

這正是Codex的啟示。更好的模型很重要。但模型周圍的作業系統，才決定工作是否能成為可信輸出。

什麼不該公開

公開的Codex文章不應傾倒私有工作系統。

請避免在公開文案中揭露：

• 私有提示與掛鉤內容；
• 敏感的本地路徑；
• 精確來源對照與評分內部規則；
• 帳號識別資訊與憑證處理方式；
• 私有工作流程捷徑；
• 尚未發布的外掛行為；
• 任何會幫助陌生人重建內部作業的內容。

應公開的是模式：關口保護什麼、要求哪些證據、能抓出什麼失敗，以及團隊如何使用Codex官方介面實作這個想法。

這條界線能保護信任，也會讓文章更好。私有機制通常讀起來像內部傳聞；公開的驗收條件，則能幫助其他團隊思考自己的系統。

實用的Codex代理框架地圖

建立最小、但能證明有用工作的控制地圖。

先求明確。執行一項真實任務。記錄關口在哪裡有幫助、又在哪裡造成阻礙。只提升那些能改善使用者可見成果的部分。

快速總結

Codex掛鉤、Remote SSH、行動控制、沙箱、核准、設定、遙測與版本控制，都指向同一個方向：程式碼代理需要包覆它們的作業系統。¹²³⁴⁶代理可以撰寫程式碼；代理框架決定什麼才算工作。

最好的團隊不會靠產出最多代理內容取勝。他們會讓代理工作可檢視、可回復、有來源、有品味，並值得發布。

FAQ

什麼是Codex掛鉤？

Codex掛鉤是可從hooks.json或行內設定執行的生命週期掛鉤能力。OpenAI公告指出，掛鉤可以掃描提示中的機密資訊、執行驗證器、記錄對話、建立記憶，並針對特定儲存庫與目錄自訂Codex行為；掛鉤文件則列出PreToolUse、PermissionRequest、PostToolUse、UserPromptSubmit與Stop等事件。¹⁷

為什麼Codex掛鉤重要？

掛鉤讓團隊能把標準放在決策點，而不只是依賴提示。當代理行動或嘗試完成時，掛鉤可以檢查證據、來源品質、Git狀態或發布準備度。

Codex行動控制會取代本地代理工作流程嗎？

不會。行動控制讓使用者能離開桌面也能引導工作，但連線主機仍提供專案、檔案、憑證、權限、外掛與本地工具。²團隊仍需要本地政策、安全憑證、版本控制與驗證。

Codex代理框架一開始應包含什麼？

先從專案指示、沙箱與核准姿態、機密資訊邊界、證據停止關口、精確路徑Git保管、公開主張的來源驗證，以及使用者可見工作的發布關口開始。

團隊應該公開自己的Codex掛鉤嗎？

公開模式與驗收條件，而不是私有掛鉤內容或敏感工作流程細節。有用的公開文章可以說明掛鉤的任務，而不暴露私有路徑、來源對照、提示、憑證或評分規則。

參考資料