Codex 悄悄加密子代理指令：AI Agent 透明度成企業導入第一道關卡｜AIRUN
Codex 悄悄加密子代理指令：AI Agent 透明度成企業導入第一道關卡
Codex 已把子代理派工指令改存密文，本機不留可讀副本。導入 AI Agent 前先確認指令可否查核，查不到就別接關鍵流程。
這件事發生在 2026 年 6 月，到 7 月 15 日發稿的今天，回報的 issue 仍掛在 OpenAI 的 GitHub 上沒有結案。下面把時間線、技術細節與企業該做的檢核，一項一項拆開講清楚。
Codex 這次改了什麼？為什麼開發者說查核紀錄不見了？
OpenAI 在 2026 年 6 月 5 日合併 PR #26210，把 Codex 多代理功能的派工指令與代理間訊息改成加密儲存，原本的可讀欄位直接留空，本機紀錄從此查不到原文。
先解釋名詞。Codex 是 OpenAI 的程式開發代理（coding agent，會自己讀寫程式碼、執行任務的 AI 工具），在 GitHub 上有 98.1k 顆星、14.6k 個 fork（複製庫）。子代理（sub-agent）指主代理把工作拆包後派給的下級代理，你可以想成工頭把工作單發給工人。
依照 issue #28058 的描述，受影響的是 MultiAgentV2（Codex 的多代理功能）底下三個動作：spawn_agent（派生子代理）、send_message（代理間傳訊）、followup_task（追加任務）。改動後，這些訊息只存進 encrypted_content 密文欄位，原本放可讀文字的 content 欄位被刻意初始化為空字串——回報者直接引用了 Codex 原始碼 protocol.rs 第 735 到 791 行佐證，這件事寫在程式裡，查得到。
結果是三個原本答得出來的問題，現在從紀錄裡答不出來了：這次 spawn_agent 給了子代理什麼任務？發給子代理的訊息內容是什麼？事後回看時，這條子代理執行緒為什麼存在？
開發者 ignatremizov 在 2026 年 6 月 13 日開了 issue #28058 回報這個回歸問題（regression，指改版後原有功能失效）。受影響版本為 0.137.0 之後、啟用 MultiAgentV2 的版本；截至本文發稿的 2026 年 7 月 15 日，該 issue 仍是開啟狀態。
子代理指令加密，為什麼是 AI Agent 透明度的分水嶺？
截至 2026 年 7 月，就我們接觸過的代理工具而言，尚未見到把「代理對代理的指令」移出使用者可查核範圍的設計。加密傳輸可以理解，連本機查核副本一起拿掉，信任邊界就實質縮窄了。
公平地說，issue 回報者自己承認加密傳輸「可以理解為隱私強化」。他的訴求也很克制：保留加密傳輸給模型，另外在執行紀錄裡存一份可讀的查核欄位，讓使用者無須解密就能看到派工原文。OpenAI 官方未公布這次加密的完整動機，PR 標題只寫了「Encrypt multi-agent v2 message payloads」，其餘沒有說明。
這次改動還有一個鄰居問題：issue #26753 回報加密後的工具 schema 在某些模型設定下直接吃�� 400 錯誤。兩件事性質不同——#26753 是「加密後跑不動」，會當場報錯被發現；#28058 是「加密後照常跑，但你看不到它跑了什麼」。對企業來說，第二種危險得多，因為它安靜。
加密前後，你能查到的東西差多少？
差距一張表講完。核心變化是：代理照常工作，但所有「它被要求做什麼」的紀錄，從可讀文字變成密文，事後無法還原。
| 查核面向 | 0.137.0 之前（加密前） | PR #26210 之後（加密後） |
|---|---|---|
| spawn_agent 派工指令 | 可讀文字，存在本機紀錄 | 只存密文，可讀欄位為空字串 |
| send_message 代理間訊息 | 可讀文字，可事後查閱 | 只存密文 |
| 回看執行歷程（rollout/history/trace） | 能還原每個子代理的任務 | 只看得到密文 |
| 除錯時判斷某個子代理為何存在 | 直接讀任務文字 | 紀錄無法回答 |
注意：這張表描述的是本機紀錄的可讀性，代理功能本身沒有壞，任務照樣被執行。所以不做查核測試的使用者，可能永遠不會發現差異——PR 在 6 月 5 日合併，issue 6 月 13 日才開出來，中間隔了八天，連盯著上游原始碼的開發者社群都要一段時間才察覺。
我要怎麼知道 AI Agent 在背後用什麼指令操作我的系統？
別等供應商主動告訴你，用四個動作自己驗：實測翻紀錄、問紀錄政策、查開源程式碼、把查核寫進合約。技術驗測面一個下午可跑完，合約條款審查視各公司法務流程另計。
- 實測一次，翻紀錄。讓代理跑一個會派生子任務的工作，然後打開執行紀錄（log、trace、history），找派工指令的原文。找得到可讀文字，過關；只看到密文或空欄位，就是黑箱。
- 問供應商三個問題：代理之間的指令存在哪裡？保留多久？我方能否不經解密直接查核？答不出來或答得含糊，風險請自己重新評估。
- 開源工具直接查程式碼。這次事件就是這樣被抓到的——回報者引用 protocol.rs 的具體行號指出可讀欄位被刻意留空。開源的好處是騙不了人，前提是有人真的去看。
- 把查核能力寫進採購合約。要求供應商改版若移除或降低查核紀錄，須提前告知。這條過去很難談，現在有了現成案例當談判依據。
這對台灣中小企業意味著什麼？
意思很直接：AI Agent 的採購檢核表，從今天起要加一條「代理指令可查核」。個資與金流相關流程，只交給查得到指令的工具。
台灣中小企業導入 AI Agent，多半接的正是最敏感的流程——客服碰客戶個資、報價碰價格授權、對帳碰金流。個資法要求企業對個資檔案採取適當的安全維護措施（個資法第 27 條第 1 項）；當代理指令不可查核，出事時你連「當時系統被下了什麼指令」都拿不出來，舉證的壓力全在你身上。責任歸屬講到底就是紀錄歸屬。
我們的判斷有三條，直接可以執行：
- 已在用 Codex CLI 多代理功能的：先確認版本。0.137.0 之後且啟用 MultiAgentV2，你的派工紀錄已經是密文。評估降版或暫停多代理功能，直到官方回應 #28058。
- 正在評估任何 AI Agent 工具的：把上一節的四個動作跑完再簽約。現在省下的查核時間，將來會用十倍的鑑識成本還回去。
- 還沒導入的：這反而是好時機。透明度議題浮上檯面，供應商正被迫表態，你現在問「指令可否查核」，拿到的答案會比半年前誠實。
底線一句話：代理指令不可查核的工具，不要接客戶個資與金流。效率的損失找得回來，信任的損失找不回來。
AIRUN 自己就是靠 AI 代理跑日常營運的公司，「代理做了什麼要查得到」對我們是切身利益，同樣的標準也用在替客戶做的體檢上。如果你正在評估 AI 工具的導入順序與風險邊界，AIRUN 對抗式創業體檢就是從這類殘酷問題開始問起的。
常見問題
Codex 加密子代理指令是什麼時候開始的？
2026 年 6 月 5 日 PR #26210 合併後生效，受影響的是 0.137.0 之後、啟用 MultiAgentV2 的版本。開發者於 6 月 13 日在 issue #28058 回報查核紀錄消失，截至 2026 年 7 月 15 日發稿，該 issue 仍未結案。
加密之後，還能知道子代理收到什麼任務嗎？
從本機紀錄查不到了。依 issue #28058 描述，任務內容只存進 encrypted_content 密文欄位，原本的可讀欄位刻意留空，執行歷史與追蹤介面都無法還原派工原文，除非未來官方補上可讀查核欄位。
OpenAI 為什麼要加密子代理訊息？
官方未公布完整動機，PR 標題只寫了「Encrypt multi-agent v2 message payloads」。回報者認為加密傳輸可以理解為隱私強化；他的訴求是在加密傳輸之外另存一份可讀查核副本，並沒有要求撤回加密。
中小企業導入 AI Agent 前，怎麼檢查透明度？
至少做三件事：實測一次派工任務後翻執行紀錄，確認指令原文可讀；問供應商紀錄存放位置、保留期限與查核方式；把查核能力與改版告知義務寫進合約。查不到指令的工具，不要接個資與金流流程。
這件事跟一般使用 ChatGPT 聊天有關嗎？
關係不大。這次改動影響的是 Codex 的多代理功能（MultiAgentV2），也就是 AI 代理之間派工與傳訊的本機紀錄；網頁版聊天不在範圍內。但若你的團隊用 Codex CLI 跑自動化開發流程，就在影響範圍內。
AIRUN 對抗式創業體檢 AgentFlow Solutions（双云行銷試運行）