OpenAI 旗下程式設計工具 Codex 近期發生了一項影響開發者工作流的底層變更：自 6 月初 起，主智慧體向子智慧體分派任務時所傳遞的指令被加密處理。開發者原本可以在會話歷史中檢視可讀的任務描述，現在看到的只是一串 不可讀的字串，無法再追蹤任務如何在內部被委派給各個子智慧體。

這一變化發生在程式設計工具日益轉向智慧體系統的背景下。當前的主流程式設計助手已不再只是補全程式碼，而是將複雜任務拆解、分派給多個子智慧體，並在後台自主做出決策。正因如此，使用者能否繼續跟蹤這些內部過程變得尤為關鍵。GitHub 上的一份缺陷報告直接向 OpenAI 提出請求，希望能在本地儲存一份可讀的任務副本，與加密版本並存。

加密策略在不同模型版本上的實施力度並不相同。此前，GPT-5.5 一度連開發者手動關閉加密的開關都失效，完全切斷了可見性，但 OpenAI 後來似乎將其恢復為可讀路徑。強制加密目前主要落在更大的 GPT-5.6 變體 Sol 和 Terra 身上，只有最小的變體 Luna 仍保留開放路徑。

新系統在實際使用中也暴露出可靠性問題。多位開發者反映，加密後的交接內容有時無法被正確解密，導致向子智慧體的任務移交失敗。個別案例中，即便主智慧體和子智慧體執行在同一個模型下，這種解密失敗依然會發生。

OpenAI 至今未對加密智慧體間通訊的原因做出解釋，僅確認了變更本身。社群成員普遍猜測，公司可能將這些提示視為類似原始推理痕跡的敏感材料，意圖阻止競爭對手利用這些資料進行模型訓練。這一懷疑並非毫無根據——此前 智譜 AI 的開源模型 GLM-5.2 曾被懷疑從 GPT-5.5 和 Opus 4.8 中蒸餾而來。智慧體之間的通訊本身就是極具價值的訓練資料，能夠幫助較弱模型向更強模型的水平靠攏，加密處理相當於將這些材料擋在競爭對手的觸及範圍之外。

另一種同樣合理的解釋則更為簡單：OpenAI 的 API 本身就會對中間狀態進行加密，以便在後續請求中轉發，而無需在伺服器上以明文形式儲存。這種做法本身屬於常規的資料隱私保護手段。

無論背後的動機是防止蒸餾、保障資料隱私，還是兩者兼而有之，這一變更已經對開發者的日常除錯與監控產生了實質影響。對於依賴 Codex 進行多智慧體任務編排的團隊而言，內部決策鏈的透明度下降意味著排查問題、最佳化流程的難度上升。在 OpenAI 給出正式說明之前，開發者只能在功能可見性與系統安全性之間接受這一新的平衡。