Codex MultiAgentV2 加密與稽核軌跡的喪失

MultiAgentV2 訊息加密導致本地稽核能力喪失

Codex 在 MultiAgentV2 中為子代理（sub-agent）提示詞引入了加密機制，這有效地從本地部署歷史（rollout histories）、追蹤縮減（trace reductions）和除錯介面中移除了人類可讀的任務與訊息文本。雖然此項變更作為模型對模型通訊的隱私強化措施，但它透過在父端日誌中以密文取代明文指令，造成了稽核能力的倒退。

此問題影響合併了 PR #26210 之後的 Codex CLI 版本（post-0.137.0），特別影響 MultiAgentV2 框架內的 spawn_agent、send_message 和 followup_task 函數。

技術根本原因：不透明的訊息酬載（Opaque Message Payloads）

此項倒退源於 InterAgentCommunication::new_encrypted() 的實作，該函數刻意將 content 欄位初始化為空字串，並僅將酬載儲存在 encrypted_content 欄位中。

當系統透過 to_model_input_item() 將這些通訊轉換為模型輸入項目時，它會檢查 encrypted_content 是否存在。如果發現，它會發送一個 AgentMessageInputContent::EncryptedContent 項目。因此，接收端模型會在伺服器端接收密文進行解密，但依賴這些相同項目的本地歷史紀錄則僅記錄了加密字串。

因此，開發者不再能輕易回答關鍵的除錯問題，例如：

在 spawn_agent 調用期間，分配給子代理的具體任務是什麼？
傳輸給子代理的確切訊息是什麼？
為什麼在部署後審查期間創建了特定的子執行緒？

建議修復方案：雙內容契約（Dual-Content Contract）

為了在不損害加密傳輸路徑的前提下恢復稽核能力，建議採用「雙內容」方法。這涉及在維持用於模型傳輸的加密酬載的同時，引入一個獨立的、非加密的欄位用於本地稽核。

實作規範

必要的明文欄位：為 v2 通訊工具增加一個必要的明文伴隨欄位（例如，針對 spawn_agent、send_message 和 followup_task 的 task_message）。
驗證：在處理器邊界拒絕空的明文稽核值，以確保日誌保持可用性。
雙重建構：使用 encrypted_content（供接收端模型使用）和 content（供本地稽核副本使用）來填充 InterAgentCommunication。
保留傳輸方式：保持 to_model_input_item() 不變，使接收端模型繼續僅接收密文。
稽核持久化：確保明文伴隨欄位在父端工具調用、部署（rollout）以及結構化追蹤邊緣（structured trace edges）中得以持久化。
關聯性：使用密文或唯一 ID——而非明文相等性——來將工具調用與傳遞的子項目進行匹配。

社群觀點與影響

加密子代理提示詞的引入引發了關於現代 AI 編排器（orchestrators）「黑箱」性質的重大討論。

隱私 vs. 透明度

部分使用者認為這是防止請求被代理用於訓練競爭對手模型，或保護專有推理過程的必要步驟。一位使用者將其比作 Claude 處理「思考」密文的方式：

"Presumably the thinking is either considered proprietary, or, more likely, it leaks embarrassing or confidential information."

安全與安全疑慮

其他人則認為，失去對子代理指令的可視性會造成安全風險。有人提出了一個關於報告事件的觀點，在該事件中，據稱一個 GPT 5.6 子代理刪除了使用者的家目錄，隨後引發了關於缺乏對子代理意圖的可視性是否導致了該失敗的問題。

策略性鎖定（Strategic Lock-in）

有一種普遍的看法，認為這些變更旨在透過使代理的內部推理與編排對使用者而言變得不透明，來增加供應商鎖定，從而有效地將產業推向「黑箱家電」模式，即使用者提供數據與支付，卻無法看見執行過程。

Codex MultiAgentV2 加密與稽核軌跡的喪失"}],