OpenAI Codex rust-v0.167.0 新增代理控制功能並修復工作階段復原

OpenAI 於 11 月 6 日發布 OpenAI Codex rust-v0.167.0，新增代理控制功能，並修復在模型供應商變更後的工作階段復原問題。此更新針對程式編碼代理的一項實際矛盾：開發者可以委派工作，但仍需要可靠的方法去尋找、檢視及繼續處理該工作。OpenAI 的改動聚焦於周邊工作流程，而非提出新的程式編碼基準測試。

此版本新增未讀提示、已連接後端之間的切換、圖片預覽，以及在核准提示期間檢查修補內容的功能。後端是工作階段所連接的服務。這些改動合起來，令終端機介面更適合監督進行中的工作，特別是開發者在不同對話或執行環境之間切換時。

Claude Code 可作為相關的競爭參考，其程式編碼協助可透過終端機及其他開發介面使用。此版本並未確立其相對該競爭對手的效能領先地位。相反，它反映 OpenAI 正投資於連續性：隨着工作流程日益複雜，讓草稿、對話記錄、待決決定及已完成結果保持可存取。

OpenAI Codex rust-v0.167.0 的改動

發布說明將 0.167.0 列為正式發布版本，而非預發布版本。GitHub 記錄顯示，它於 2026 年 11 月 6 日 01:40 UTC 發布。其重點功能涵蓋指令介面、工作階段導覽、附件、登入選項、Proxy 設定及核准檢閱。

核心改動是更好地控制 Codex 內已在進行的工作。

開發者可以透過 codex agents --no-daemon 開啟代理指令中心。指令中心及工作階段選擇器現會標示未讀結果，讓用戶可清楚分辨已檢視的工作與仍待留意的輸出。

當多個對話爭相需要注意時，未讀標記的作用便不只表面看來那麼小。從程式碼審查返回的開發者，需要知道自己離開期間哪項工作已完成。工作階段標題列表可提供導覽，而未讀狀態則補充哪些項目應優先檢查的資訊。

終端機工作階段選擇器亦支援在已連接的後端之間切換，同時保留草稿。這處理了決定提問內容與選擇在哪裏繼續工作之間的轉換。在代理甚至尚未開始工作前，因導覽而遺失未完成請求會造成可避免的重工。

OpenAI 亦表示，在變更模型供應商後，已儲存的對話仍然可見。模型供應商提供對話所用模型的存取權。當已儲存對話無法繼續時，用戶仍可閱讀其記錄，並為新對話準備可編輯的提示。

這些改動彼此相關，但解決的是不同問題。切換已連接後端可改善可用服務之間的導覽；在供應商變更後保留存取權，則可在已儲存對話周邊配置不再符合原有條件時，保護對話歷史。

此版本亦在受支援終端機中新增撰寫訊息時的本機圖片預覽功能。已檢視的本機圖片可透過可點擊的記錄路徑開啟。對於討論介面缺陷或比較視覺輸出的開發者而言，這些改動縮短了訊息與其佐證資料之間的距離。

在核准提示仍然開啟時，修補詳情現可直接在記錄中展開。修補內容描述對檔案提出的變更。讓這些細節在決策時刻保持可見，用戶便能在毋須先關閉提示的情況下檢查所要求的修改。

其他改動的可用範圍較窄。macOS 與 Windows 的系統 Proxy 支援為實驗性選項。Google Cloud Vertex AI 設定精靈需要明確啟用功能設定，因此不應把此版本理解為會自動啟用所有重點功能。

這個範圍很重要，因為發布摘要可能會模糊實作改動與廣泛產品承諾之間的界線。此處有文件記錄的事件很具體：OpenAI 推出了介面及復原功能改進。這些改進會否帶來更短的審查時間或更少中斷，仍有待在發布公告以外觀察。

工作階段連續性成為開發者生產力議題

這些改動的直接受眾包括會重訪已儲存工作、切換供應商，或監督多個代理對話的開發者。他們的問題不只是生成另一個答案，而是在中斷之間維持決定、未完成請求及結果的可用記錄。

即使模型停止回應，程式編碼工作階段仍然具有價值。

記錄可包含被否決的方法、儲存庫細節、測試結果，以及建議修改背後的解釋。如果在供應商變更後，該記錄從一般導覽中消失，開發者便失去方便存取工作推理脈絡的途徑。單靠檔案未必能解釋當中的選擇。

OpenAI 的工作階段復原改動直接描述了這項失敗情況。切換供應商可能令已儲存對話無法在繼續處理的查詢中找到，或無法開啟。這項改動讓歷史記錄在因供應商不符、缺少設定或政策衝突而無法繼續時，仍然可供閱讀。

實作上區分了閱讀對話與繼續對話。無法繼續的對話可作為唯讀歷史開啟。用戶其後可利用引用已儲存討論、尚未送出的可編輯提示，準備一個新對話。

這項區分避免把可見的記錄視為完全相容的證明。開發者可復原有用的脈絡，毋須假設原有工作階段能在另一供應商下執行。即使繼續執行需要新對話，記錄的存取權仍會保留。

設想一名開發者調查一項失敗的整合，然後在返回任務前更改供應商設定。這是一個說明情境，並非已報道的客戶個案。實際問題是該調查能否繼續被找到，以及其脈絡能否為下一次嘗試提供參考。

有文件記錄的復原流程處理了這種情況，同時不會自動提交替代請求。開發者仍有機會檢查及編輯延續提示。當原先調查包含應隨新環境改變的假設時，這點尤其有用。

草稿保留在較小規模上服務相同的更廣泛目標。開發者可能在選擇正確的工作階段或後端前，已開始描述某項故障。保留該段文字，令導覽維持為日常操作，而不是可能導致輸入遺失的來源。

這些改動不僅對產品設計，也對團隊的評估方法構成要求。只透過一次成功的初始回應比較程式編碼代理，會忽略恢復工作時發生的情況。重新開啟、切換、復原及審查，均應納入整體體驗的評估。

工程經理亦有理由留意。採用代理的團隊需要實際了解工作如何跨越中斷而保留。工作階段連續性會影響另一名開發者能否理解一項調查，即使原先操作者已經離開。

與文件工作的關聯很直接。已在建立可搜尋知識庫的團隊，需要讓決定及技術脈絡持續可檢索。Codex 的復原改動處理其自身對話介面內的存取，而更廣泛的文件實務則決定哪些知識能在該介面以外留存。

上述內容並不確立可量度的生產力提升。此版本為團隊提供具體行為以供評估，而非要他們接受數字化說法。這令連續性成為具體的產品準則，卻不會把每次介面修復都視為軟件交付更快的證據。

代理控制將監督帶進終端機

指令中心、未讀結果及內嵌修補檢閱共享同一設計方向：它們令終端機不僅是啟動代理工作之處，亦成為監督代理工作的地方。用戶需要看見已發生的事、判斷哪些事情值得注意，並在授權前檢查變更。

只要工作在用戶即時焦點以外持續進行，委派便會產生導覽問題。

未讀提示為這個問題的部分範圍提供輕量答案。它們不會判斷結果是否正確，亦不會判斷任務是否需要介入。它們只標示用戶尚未檢視的輸出，將實質審查留給開發者。

值得清楚說明這項限制。完成標記與品質判斷是不同訊號。此版本記錄了對結果的認知有所改善，卻未能證明 Codex 可可靠地判斷哪一項結果對特定專案最重要。

內嵌修補檢查處理的是更具影響力的決策時刻。OpenAI 的修補檢閱改動讓記錄的揭示控制項可在模態提示開啟時運作。模態提示會暫時優先於其他介面互動。

這項改動亦考慮檢閱後的情況。當展開修補詳情中斷自動跟隨新輸出時，介面可在核准結束後恢復跟隨。手動捲動及文字選取會獲得保留，而不會被自動跳轉取代。

這種行為反映一般開發限制：檢查修改往往需要在記錄中停留於某個位置。若介面反覆移離正在檢閱的內容，即使名義上提供了核准步驟，也會變得較難使用。

設想一名開發者正在檢查代理對設定處理提出的修改。真正有用的問題，是在核准仍待處理時，確切修改能否保持可見。當支持細節可在同一時刻取得時，授權行動的請求才有更實際的價值。

此版本亦改變了網絡核准行為。OpenAI 表示，當底層請求結束時，提示會關閉。對同一端點的並行請求會逐一提示，減少針對同一目的地而重疊的決定。

這些是介面及生命週期修正，並非證明每項網絡行動都合適。端點是網絡請求所聯絡的目的地。整理核准提示有助用戶理解請求，而實際的權限決定仍取決於脈絡及政策。

競爭比較關乎這整個工作介面。Anthropic 描述Claude Code 工作流程可跨終端機、桌面及開發環境運作。因此，兩款產品都在程式編碼、檢查及任務管理本已發生的場所接觸用戶。

現有證據並不足以支持任何一方在功能層面全面勝出。OpenAI 的公告記錄了其自身改動，而 Anthropic 的文件描述其自身產品。兩個來源均未提供對審查時間、復原成功率或用戶錯誤的受控比較。

較狹義的觀察仍然有意義。Coding agent 不僅透過生成的程式碼競爭，也透過周邊的互動設計競爭。工作階段選擇器、易讀的修補內容，或獲保留的草稿，都可能決定一項原本有用的功能能否融入日常工作。

對於 OpenAI Codex rust-v0.167.0 而言，這套周邊介面正是最清晰的主線。此版本改善了用戶管理 agent 活動的方式。模型品質、專案特定的正確性，以及相對生產力，仍是另外需要探討的問題。

供應商設定擴展，同時設有明確限制

此版本將替代登入方式重組至「Sign in another way」之下，並包含適用於 Google Cloud Vertex AI（Google Cloud 的託管 AI 平台）的設定精靈。該精靈接受專案資料，並支援既有的應用程式憑證或憑證檔案。

更簡易的供應商設定可減少配置阻力，但不會消除部署要求。

OpenAI 的 Vertex AI onboarding 變更指出，該精靈預設為停用。用戶必須啟用 features.gcp_setup_wizard 才能顯示它。這項條件對理解此版本實際提供了甚麼至關重要。

設定程序會收集專案 ID、可選的位置，以及可選的憑證檔案。將檔案留空會使用 Application Default Credentials，即 Google 用於從執行環境尋找憑證的機制。這提供了一條不同於手動提供檔案的設定路徑。

實作會將憑證驗證和設定持久化交由 app server 處理。介面會顯示進度，並容許在出錯後重試。這些細節描述的是引導式設定流程，而非聲稱每個雲端環境都毋須額外準備便可運作。

對於已使用 Google Cloud 的機構，這個流程提供了較直接的切入點。它並不代表模型可用性、專案權限、區域適用性或遵守內部要求已獲確立。這些仍取決於機構的部署和配置。

這正是此版本的延續性主題與企業複雜性交會之處。支援額外設定路徑，讓用戶有更多方式使用 Codex。當用於連接模型的配置其後改變時，讓已儲存的對話仍可存取會有所幫助。

這種關係不應被誇大。設定精靈和復原畫面並不會令供應商變得可互換。它們改善的是一項面對多個供應商、憑證和政策的工具之不同運作環節。

實驗性系統 proxy 支援處理另一項環境限制。系統 proxy 會透過作業系統所設定的中介者路由網絡流量。此版本讓 macOS 和 Windows 用戶可透過 /experimental 選用這些設定。

實驗性標籤對推出決策很重要。它表示用戶應在自身環境中評估其行為，而非假設它符合既定預設值。相關說明沒有依據讓人聲稱其與企業網絡安排普遍相容。

文件變更亦值得審慎解讀。OpenAI 表示，app-server README 現已涵蓋受管理網絡限制，以及要求重新獲得人類批准的指令規則。這解釋了支援的控制項，但並不能確立任何特定機構如何配置它們。

由此形成的圖景是營運範圍更廣。Codex 必須在本機終端、雲端憑證、已連接服務、網絡安排及機構政策之間運作。此版本處理了這種廣度造成阻力的若干具體位置。

對企業買家而言，有用的回應是按實際部署需要評估這些位置。相關的設定路徑可提升採用率，而不相關的設定路徑價值有限。此版本不足以支持將其 changelog 的篇幅視為適用性的替代指標。

復原修正並不能證明編碼品質

最有力的懷疑解讀很直接：這些變更修復了可用性問題，但其對已完成工程工作的影響在此仍未量度。易讀的記錄可支援復原，卻不能保證復原後的計劃對新環境而言準確、最新或合適。

營運延續性與編碼正確性需要不同的證據。

此版本包含對自動 context compaction 的修正；該功能會縮短對話歷史，以配合模型可用的輸入容量。OpenAI 表示，先前的計算方式可能遺漏來自失敗回應，或缺乏可用用量資料的回應中仍被保留的輸出。

文件所述的修正會追蹤最後一份可用用量報告所涵蓋的邊界，然後估算在該邊界後加入的項目。這處理了隨著對話材料累積、可能延遲壓縮的特定計算問題。

這與長時間運作的工作有關，因為未完成的回應不一定會留下空白歷史。保留的材料仍需納入計算。此變更涉及系統何時辨識到 context 壓力，而非增加模型本身的 context 容量。

它同樣不能證明 compaction 會保留開發人員關心的每個細節。更準確地安排操作時機，以及保留正確資訊，是相關但不同的問題。版本說明支持前者的修正，卻未提供後者的全面評估。

其他維護變更同樣有明確界限。Linux musl builds 使用較少的 allocator arenas，即 allocator 使用的記憶體管理池。OpenAI 說明目標是在對話卸載後減少閒置記憶體，但版本摘要沒有提供已量度的降幅。

此版本亦表示，隨着即時對話增長，已完成的語音內容會保持儲存。這修復了語音互動的延續性，但不能證明轉錄準確度，也沒有顯示與打字請求相比，語音輸入是否改善工程成果。

這些區分避免一系列有用修正被轉化為欠缺支持的效能敘事。此處沒有經驗證的結果顯示 0.167.0 版本可產出更佳修補內容、通過更多專案測試，或勝過競爭 agent。已記錄的變更涉及的是圍繞這些成果的行為。

資料來源亦限制了對用戶反應可以作出的陳述。官方版本說明和已合併的實作描述解釋預期行為，卻不能證明廣泛用戶滿意度、獨立驗證，或開發人員對此版本重要性存在共識。

因此，正面的解讀建基於修正的具體性。OpenAI 已識別具體失效模式，並記錄旨在處理它們的變更。懷疑的解讀則會問：在實際配置變更、被中斷的請求及持續維護下，這些路徑是否仍然可靠。

兩種解讀可以並存，而毋須虛構爭議。曾經失去聊天存取權的開發人員，有明確理由重視復原功能。另一名從不更換供應商的開發人員，可能不會即時感受到該項修正的好處。

相關的問題是：哪一項已記錄的問題符合讀者的工作。將每項功能都視為同樣有價值，會掩蓋這個判斷。此版本為評估工作階段管理提供了較有用的基礎，卻不足以用來宣稱其一般編碼智能有所提升。

版本推出後值得留意的事項

下一輪評估應追蹤 OpenAI 已變更的行為，而非對 coding-agent 市場作出無關的預測。未來數月，工作階段復原、審閱延續性和供應商設定將提供具體訊號。每項都測試此版本營運方向的不同部分。

最有力的後續證據，將顯示開發人員能否在不失去對工作掌控的情況下完成被中斷的流程。

首先，留意供應商變更後的工作階段復原。若報告顯示已儲存對話仍可被找到、閱讀和用於準備新工作，將加強延續性的論點。即使一般新聊天運作良好，若這些路徑反覆失敗，仍會削弱該論點。

在這項評估中，閱讀與恢復工作階段的區別應保持清晰。成功開啟記錄很有價值，但並不證明不相容的工作階段可以繼續。復原應按 OpenAI 實際記錄的行為來評斷。

其次，留意持續輸出期間的批准審閱。有用的證據會顯示修補細節仍可存取，並且用戶能保留自己選擇的閱讀位置。涉及排隊 prompts、消失 context 或意外捲動的回歸問題，將會挑戰此版本對監督功能的改進。

這個訊號很重要，因為批准是一項決定，而不僅是暫停執行。介面需要保留足夠的相關資料，讓用戶能作出決定。若隱藏了建議的變更，較短的互動未必自動代表更佳審閱。

第三，留意此版本引入或開放的供應商設定路徑。若 Vertex AI 能在已記錄的憑證選項中成功配置，將支持引導式上線流程的理據。持續的驗證失敗或不清晰的設定狀態，則表示仍存在阻力。

實驗性 proxy 設定亦屬於同一營運評估，雖然它服務的是不同的配置需要。其成熟度或文件的變化，將有助用戶決定應多廣泛地採用。它的存在本身並不能證明在受管理網絡中有可靠表現。

這些訊號令評估維持與可觀察的產品行為相連，也避免把後來的每項改善都歸因於此版本。後續的模型更新、伺服器變更或新配置，都可能獨立於此處所述的終端變更而影響體驗。

OpenAI Codex rust-v0.167.0 為開發人員提供了一組可供檢驗的具體主張：更清晰的 agent 導航、保留的草稿、可存取的歷史記錄，以及可供審閱的批准。先從最耗費團隊精力的中斷情境開始，然後在採用前後比較該確切流程。記錄哪些內容仍可閱讀、哪些可以恢復，以及哪些需要重新開啟對話。當決定仍在等待時，詢問審閱者修補內容檢查是否感覺更清晰。根據實際環境檢查實驗性設定選項。利用這些觀察決定更新是否改善日常工作，並把編碼品質視為需要測試和程式碼審閱支持的獨立問題。