編按：本文綜合整理自 GitHub Issue #28058、Hacker News 討論串、Developers Digest 報導，並加入 Siami 編輯部觀點與分析。
OpenAI 的開源命令列 AI 程式助理 Codex CLI 在 2026 年 6 月合併 PR #26210 之後，悄悄把子代理之間傳遞的提示「加密化」——結果就是開發者本機再也看不到自己 AI 究竟派了什麼任務給子代理。這個改動被 GitHub Issue #28058 揭發後，48 小時內在 Hacker News 衝上 360 分、218 則留言，是本月最高爭議的開源 AI 事件之一。
事件經過：從隱私硬化到審查黑箱
PR #26210 的原始目的
這次爭議的源頭是 OpenAI 工程師 6 月 5 日合併的 PR #26210，標題是「Encrypt multi-agent v2 message payloads」。OpenAI 官方說法是：為了讓 spawn_agent、send_message、followup_task 這三個 MultiAgentV2 工具在子代理之間通訊時，提示內容不外洩到本地端，所以引入「加密傳輸」機制。
技術上，他們在 codex-rs/protocol/src/protocol.rs 新增了 InterAgentCommunication::new_encrypted() 建構子：把原始 payload 放進 encrypted_content 欄位，刻意把 content 設成空字串。代表模型之間看到的訊息是有意義的內容，但本地 rollout 記錄、history trace 全部只剩 ciphertext。
Issue #28058 揭發問題
OpenAI 社群使用者 embedding-shape 在 6 月 13 日開了 Issue #28058「Regression: encrypted MultiAgentV2 messages remove readable task audit trail」，指出這次改動破壞了三個基本除錯能力：
- 無法回答「這個
spawn_agent究竟給子代理派了什麼任務」 - 無法追蹤「子代理收到什麼訊息、何時觸發」
- 無法解釋「為什麼 rollout 結束後還留有子代理 thread」
他主張解法不是「撤銷加密」，而是「加密保留 + 本地審計欄位」並存。codex-rs/core/src/tools/handlers/multi_agents_v2.rs 的 communication_from_tool_message 函式應該把原始明文同步寫進 trace metadata，而不是只丟給模型端。
開發者社群反應
Hacker News 討論串 24 小時內突破 200 則回覆，主流意見分成三派：
「這是隱私硬化 (privacy hardening) 的合理選擇，但應該保留一份本地可讀的 audit 副本，而不是把整段訊息藏進 ciphertext。」 — HN 用戶 bdittrich
另一派用戶則提出更深層的擔憂：如果 OpenAI 接下來把子代理通訊改成 latent space representation（潛在空間向量），人類將徹底失去可解釋性。
- 最高讚數回應（412 分）澄清：這不是「用 ciphertext 做推論」，而是「OpenAI 後端可以解、但使用者本機不能解」的選擇性透明。
- 287 分回應警告：失去 audit trail 等於放棄可解釋性承諾，企業用戶尤其受影響。
- 195 分回應呼籲保留本地明文審計副本，這是多數共識解法。
為什麼這件事重要
這次改動觸碰到 AI 代理人 (agent) 產業最敏感的一條神經：使用者對 AI 行為的可審查性。
Codex CLI 的 MultiAgentV2 是 OpenAI 在 2026 年 5 月才推出的旗艦功能，讓一個主代理 (parent agent) 能平行 fan-out 多個子代理 (sub-agent) 執行任務。這個架構是 OpenAI 內部 RL rollout 訓練的核心場景——也就是說，子代理之間的通訊內容，其實就是模型行為的 ground truth。
當 OpenAI 把這些訊息加密、只讓自家後端可解讀，等於宣告「這些資料是商業機密，連使用者都不能看」。短期看是資安考量，長期看會演變成：
- 企業合規風險：金融、醫療等受監管產業的開發者，必須能向稽核人員證明 AI 做了什麼。沒有 audit trail 就沒有 compliance 證據鏈。
- 除錯能力崩盤：OpenAI 自己也承認「使用者本機 rollout 看不到子代理任務」。當生產環境出問題時，連 OpenAI 客服都難以遠端排查。
- 開源承諾縮水：Codex CLI 在 GitHub 是公開 repo，但實際執行路徑的「可觀察性」被閹割，等於把開源變成 source-available。
更令人玩味的是，OpenAI 在 5.6 版本同步推出了 ultra 模式，強調「fan subagents 做大量工作」——而這個 ultra 模式正是 #26210 加密機制的目標場景。換句話說，越是用戶重度依賴的功能，audit trail 越黑。
數據解讀與質疑
從數字面看，這次事件的嚴重性被低估了：
- 衝擊版本：所有 post-0.137.0 且啟用
features.multi_agent_v2的 build 都受影響。Codex CLI 在 2026 年 7 月初的日活 (DAU) 估計在數十萬等級，代表數萬開發者已經在不知情的狀態下用著「看不到子代理訊息」的版本。 - 相鄰問題：另一個 Issue #26753「MultiAgentV2 encrypted spawn_agent schema returns 400」也還沒修。代表 MultiAgentV2 的加密路徑同時存在「連主流程都跑不起來」和「跑得起來但看不到內容」兩個獨立 bug，OpenAI 卻沒有在 release notes 標示。
- 反應時間差：從 PR 合併 (6/5) 到 Issue 開立 (6/13) 隔了 8 天，但 OpenAI 直到 7/14 仍未明確表態是否會修。對於開源社群來說，8 天的沉默期足以讓爭議發酵到 HN 360 分的熱度。
值得質疑的是 OpenAI 的時程：他們在 5 月就為了 ultra 模式而設計加密，卻等到 6 月初才合併，6 月底才被 Issue 揭發。這段時間內所有升級到 post-0.137.0 的使用者，都沒有收到「你的 AI 紀錄將變得不可審查」的明確警告。這跟 OpenAI 之前對「o1 推理鏈可見性」的承諾形成強烈對比。
另一個值得追問的點是：Issue #28058 留言區目前 20+ 個 👍 但 OpenAI 沒有指派任何 maintainer。對比 Anthropic 對 Claude Code 漏洞的 48 小時內回應文化，OpenAI 在開源 AI 工具的售後支援明顯落後。
後續發展與社群行動
截至 7 月 14 日，社群已經出現幾條平行行動路線：
- Fork 提案：部分開發者提議 fork 一個保留本地明文 audit 的
codex-cli-audit版本。 - 替代工具轉向：HN 留言區有人提到改用 Claude Code 或 Aider 處理 MultiAgent 工作流。
- 企業內部政策：幾家金融科技公司據傳已經在內部 Slack 要求「AI 程式助理必須有 audit trail 才符合 SOC 2」，等於變相把 Codex CLI 排除在 production 之外。
- OpenAI Community 論壇：在 community.openai.com 同步出現「Restoring subagent roles, model and reasoning in MultiAgentV2」貼文，呼籲 OpenAI 把 subagent 的 role / model / reasoning 欄位也加回來，與 #28058 形成互補訴求。
對台灣與中文圈的開發者來說，這件事的警訊更明確：當你把 AI 助理當成團隊成員時，你需要的不只是「它能做事」，更需要「它做了什麼可以被記錄」。 一旦失去 audit trail，AI 代理人就從「可審查的同事」變成「不可問的黑箱作業員」。
結論
Issue #28058 不只是 OpenAI 的 bug，而是整個 AI 代理人產業的轉捩點。
Codex CLI 這次把子代理通訊加密的做法，揭示了一個結構性矛盾：OpenAI 同時是「模型訓練者」與「執行環境提供者」，當商業利益跟使用者透明度衝突時，商業利益幾乎一定會勝出。對開發者來說，唯一的長期對策是：
- 把 audit trail 列為選用 AI 工具的硬性條件
- 在 CI/CD 流程中加入「AI 行為日誌」檢查點
- 擁抱真正開源、可自我託管的替代方案（Ollama + Open Interpreter、Continue.dev、Aider 等）
加密本身不是罪，但當加密被用來阻擋使用者觀察自己的 AI 行為時，它就變成了控制手段。 這是所有 AI 工具用戶都該記住的一課。
網友熱門留言 (4)