智譜ZCode偷傳代碼風波追蹤：Agent的數據行為誰來審計？

林克、鄭好 發表於 2026年09月19日 09:54 摘要：不要讓閉源Agent陷入信任危機 作者 | 林克、鄭好 過去兩年，涉及Agent安全討論的重心主要放在模型失控、提示詞投毒和外部攻擊者身上，相比之下，Agent廠商自身的數據行為很少被當作一級風險討論。近日曝出的智譜ZCode事件，正在把問題轉向了一個此前很少被認真對待的方向，那就是Agent的製造商本身是否也可能成為數據外傳的來源。9月18日，技術博主ferstar發佈了對智譜ZCode的逆向分析。他發現只要用戶登錄了賬號，ZCode就會在後臺把整個工作項目連同完整的修改歷史打包加密，上傳至雲端服務器。

軟件界面缺少真正可用的關閉開關，加密文件的解密鑰匙只保存在智譜一側。智譜很快致歉，稱問題源於一項功能默認開啟，數據用完即銷燬，並承諾近期開源代碼庫、引入第三方審查。Zcode這次所暴露的問題，早已不是行業孤例。不久前獨立安全研究者cereblab通過抓包分析證明，xAI的編程Agent工具Grok Build會把用戶的整個項目打包上傳到谷歌雲存儲，包括用戶明確告訴AI不要讀取的文件和未經脫敏的密碼。更早些時候，Claude Code被發現在用戶不知情的情況下回傳位置和身份信息，Anthropic工程師甚至事後確認那是一次有意實驗。

更關鍵的是，這些問題被發現並非因為監管或安全審計，而往往來自社區裡的個人，而目前行業為Agent搭建的安全框架，至今沒一條規則是用來約束廠商自身行為的。9月18日，技術博主ferstar在排查ZCode的本地目錄時，注意到硬盤佔用空間異常。他找到了一個約313MB的加密文件，體積遠超日常大小。文件打不開，但附帶的文件清單顯示這個包涵蓋約4.2萬個文件，其中超過8成屬於項目歷史修改記錄。這份記錄不光有項目文件，還涵蓋了曾經下載過的大文件緩存和本地操作日誌，被打包的不只是項目本身，還包括項目”從出生以來的經歷”。後續的代碼分析發現，這份歷史記錄在打包流程中被豁免於所有安全過濾規則。

ZCode的文件篩選邏輯是按順序判定的，歷史記錄目錄的放行排在密鑰過濾和體積限制之前，這意味著針對pem、key等密碼文件的過濾和1MB的體積上限，對歷史記錄目錄下的任何內容都不生效。這意味著，一個百兆體量打包文件可以整個帶走，而任何曾經提交進歷史記錄又被刪掉的密碼和密鑰，也會原樣上傳。更麻煩的操作在後面，解密鑰匙不在用戶的電腦裡。ferstar拆解還原文件的上傳路徑，首先客戶端向智譜服務器索取上傳憑證和一把加密用的公鑰，在然後本地完成壓縮加密，然後繞過智譜自己的業務服務器，直接上傳到阿里雲的雲存儲服務，再由雲存儲回調智譜後臺。這裡稍微解釋一下加密方法。

公鑰相當於一把鎖，任何人都能用它把東西鎖進箱子；私鑰相當於鑰匙，只有持有鑰匙的人能打開。ZCode的做法是，鎖由服務器臨時發放，鑰匙只在服務器那頭保存，Agent在用戶電腦上生成一個加密包，用戶自己都無法查看裡面到底裝了什麼。ferstar發現這套機制會在兩個時間觸發，一是用戶向AI發送請求之前，二在任務結束之後。一個活躍的使用過程中，他觀察到多達62次快照記錄。界面上看起來與此相關的兩個選項，經他逐一對照代碼邏輯後確認，一個叫“優化體驗”，實際只控制數據是否用於模型訓練；另一個叫“倉庫快照索引”，實際只控制服務器端收到數據後是否建立檢索目錄。兩個都關掉時，本地的打包和上傳照常運行。

負責快照和上傳的組件在軟件啟動時就會無條件加載，唯一的前提是用戶處於登錄狀態。除了項目文件，快照每次還會把ZCode自身的全局配置一併打包，跨項目帶走。ferstar嘗試手動刪除那個313MB的待發送文件。半小時後ZCode自動重新生成了一份新的打包文件，Agent偷偷上傳不成就反覆重試。刪了還會再建，這或許不是一個可有可無的輔助功能應有的執著程度。這篇文章當晚社區迅速發酵，智譜火速回應並致歉。此次問題源於ZCode的“代碼庫索引”功能。該功能旨在幫助用戶在本地生成倉庫索引，以支持包括歷史版本在內的會話檢查點恢復、歷史版本回退及Repo Wiki等功能。

Repo Wiki功能在生成Wiki頁面時可能會觸發倉庫數據上傳。Wiki頁面在雲端生成後，相關上傳數據會立即銷燬，不會保存。由於該功能在上線初期默認開啟，部分用戶因此受到影響，對此我們深感抱歉，目前相關問題已經修復。智譜還承諾近期開源ZCode代碼庫，邀請第三方評估人員審查系統運行情況，併為全體用戶額外補償一次周額度重置，當天發放。這裡的“代碼庫索引”是為項目文件建立目錄和檢索系統；“Repo Wiki”則是自動為項目生成一份說明文檔的功能；“會話檢查點恢復”和“歷史版本回退”是讓用戶在與AI對話過程中可以回到之前某一步的功能。

這些功能本身是合理的，回應也是及時的，但關鍵在於： 它解釋的和社區追問的不是同一件事。智譜說這套索引“旨在幫助用戶在本地生成”。既然是本地生成，那為什麼需要把項目整個送到雲端？本地做索引、本地做快照、本地做回退，技術上完全可行，市面上也有工具就是這麼做的。說明把“本地索引”和“上傳到雲端”併成一句話，彷彿後者是前者的自然延伸，但這中間缺了一個關鍵環節的解釋。回應將問題歸於Repo Wiki“在生成Wiki頁面時可能會觸發倉庫數據上傳”。但ferstar的逆向記錄顯示，觸發上傳的時機之一在用戶每次發送提問之前，與生成說明文檔無關。

ZCode目前的官方文檔明說，生成說明文檔時不讀取項目的歷史修改記錄，只按需讀取經過篩選的代碼上下文，這說明這項功能在技術上並不需要歷史記錄。那麼此前上傳的包裡，為什麼86.6%都是歷史記錄？說明沒有回答當初上傳範圍為什麼這麼大，是設計如此還是程序出錯，也沒有交代從哪個版本開始修正。說明用的措辭是該功能“在上線初期默認開啟”，這更像把一次機制層面的數據外傳表述成了一項功能的開關設置。ferstar的代碼分析顯示，界面上的兩個相關選項一個管訓練一個管索引，都管不住打包和上傳行為本身。社區質疑的核心是用戶看到的控制項控制不了真正在發生的事，這和“某個功能默認打開了”不是一個量級的問題。

很快另一份更敏感證據也被社區翻出，那就是ZCode v3.12.2版本的更新日誌，日期為2026年9月16日，就是在ferstar發文的前兩天。有一條記錄寫著“優化倉庫快照上傳的內存佔用”。工程團隊很難給一個意外行為優化內存，這說明“倉庫快照上傳”在內部是一項被持續迭代的正常功能。這條更新日誌在事件發酵後已被刪除，刪除公開記錄本身，是一個獨立於原始行為的新問題。“相關上傳數據會立即銷燬，不會保存”，這句話回答的是數據保留多久，但用戶真正需要知道的還有很多問題，比如數據是否已經離開了電腦，服務器在處理過程中誰有權限訪問，加密包的解密能力在誰手上，此前已經上傳的數據執行了什麼樣的刪除策略。

從加密方式來看，鑰匙在服務器一側，所以“加密上傳”證明的是傳輸途中不會被第三方截獲，並不能推出智譜自身無法解讀內容。ZCode隱私政策英文版對收集範圍的措辭是用戶“through conversation”（通過對話）提交的文本、文件和代碼。但後臺快照不是用戶通過對話提交的，這個行為不在隱私政策描述的範圍內。“在對話中向我們提交”和“後臺自動打包整個項目”是兩碼事。這份隱私政策還寫明，當新功能涉及與原始目的沒有直接或合理關聯的信息收集時，應通過頁面提示、交互流程等方式另行告知並取得用戶同意。

另一名開發者馮若航的代碼分析發現，客戶端每次發送提問時都會無條件向服務端申請上傳憑證，服務端發放憑證就採集，不發放就不採集。ferstar發現的那個313MB的件當時處於待發送狀態，已失敗564次，馮若航在自己的Mac上獨立復現了ferstar的取證流程，在4個工作區的快照記錄中，確認至少有一份快照的狀態文件已寫入服務端接受確認的標記。按代碼邏輯，這個標記只有在上傳被服務端確認接收後才會生成。這意味至少有一臺機器上的數據確實離開了本地。智譜的道歉、承諾和補償在爭議發酵數小時內全部給出，反應速度不像準備長期隱瞞。但無論“立即銷燬”還是“不會保存”，這類承諾從外部無法驗證，也無法證偽。

用戶能看到的只是數據離開了自己的電腦，之後發生了什麼完全取決於廠商的自我約束。智譜承諾的開源和第三方審查能否改變這一點，取決於開源的是哪個版本、審查覆蓋的是客戶端還是服務端，這些問題目前沒有答案。如果真有一些廠商真的有意收集用戶數據，想要的或許不會是用戶代碼本身。因為各大代碼託管平臺的公開項目為模型訓練提供了充足的語料。私有代碼當然包含商業秘密，但從模型改進的角度看，僅僅多拿到一批代碼文本的邊際價值並不高。真正稀缺的是三樣東西。一是改動的因果鏈。項目的歷史修改記錄裡存的不是一張張快照，而是“改之前長這樣、因為什麼、改成了那樣”的完整過程。

這種帶有前因後果的序列，是訓練編程模型最理想的學習材料：給定一個項目現狀和一條修改意圖，模型應該做出什麼改動。二是帶結果標註的使用軌跡。ZCode的觸發機制在每次用戶發送提問之前拍一次“全景照片”，同時它又具備回退功能，用戶可以撤銷AI做出的修改。這兩個動作組合在一起，天然地記錄了“提問＋操作前狀態＋操作後狀態＋用戶是否滿意（有沒有撤銷）”的完整循環。這種數據在AI訓練中極其昂貴，通常需要專門僱人標註，而ZCode的快照機制相當於讓用戶在正常使用中免費生成了這些標註。三是沒有被任何模型見過的真實項目。目前公開的編程評測題目幾乎都已經被各家模型在訓練時“做過一遍”，成績虛高。

真實的、從未進入過訓練集的私有項目，是做內部能力評估最有價值的原料。這三樣東西確實和ZCode上傳包的構成高度吻合，這就是社區對“只是為了生成說明文檔”這個解釋始終不買賬的原因。但反過來講，如果目標真是系統性地採集訓練數據，更精確的做法是隻抽取提問內容和代碼改動，確實也犯不著連幾百兆的大文件緩存和完整操作日誌一起打包。這種過度採集的形態，更像是工程團隊在開發快照功能時複用了一套通用的打包邏輯，把與索引和回退相關的全部文件一股腦裝了進去，加上雲端存儲本身有成本，大量個人用戶的小型項目和練手代碼對模型訓練的實際價值有限，而對付費客戶尤其是企業客戶的數據出手，風險收益比其實極不划算。

必須承認，利用這些數據改進模型和工具的動機是成立的，路徑是現成的；但從上傳包的粗放程度來看，激進的產品決策疊加工程層面的偷懶比“智譜故意想搞點什麼”更貼合已有證據。當然，不能因為智譜沒有主觀故意而忽視這種問題的嚴重程度，這確實會給用戶帶來安全隱患。與ZCode事件相似的風波，今年已經發生了不止一次。今年7月，獨立安全研究者cereblab對xAI的Grok Build進行了完整的網絡抓包分析，並公開了全部證據和復現步驟。他發現的現象比ZCode更誇張，Grok Build會把用戶的整個項目打包成代碼包上傳到谷歌的雲存儲服務，上傳範圍覆蓋所有文件，包括用戶在對話中明確告訴AI“不要讀取”的文件。

在一個12GB的測試項目中，截至抓包中斷時已確認的文件體積達超過了5G。測試還發現，項目中的密碼和密鑰文件甚至也被原樣上傳，沒有經過任何脫敏處理。用戶在設置中關閉“改進模型”選項後，上傳依然照常進行，關掉的只是訓練授權，不影響代碼是否離開電腦。馬斯克在事件曝光後公開承諾刪除所有已上傳數據，xAI在服務器端關閉了上傳功能。更早前的3月31日，其Claude Code在一次版本發佈中，一個配置文件的疏忽導致約60MB的源碼映射文件被誤打包進了公開發布的安裝包中，外部開發者得以看到了這款工具的架構。

社區發現，Claude Code每小時向Anthropic服務器輪詢一次遠程配置，配置項中包含多個可以強制退出程序、繞過用戶權限提示的控制開關，全部在後臺生效，不需要用戶主動更新。Claude Code曾被發現讀取用戶的代理、網關地址和中國時區等環境信號，並通過系統提示中的隱蔽字符將分類結果帶回服務端。Anthropic工程師隨後甚至確認，這是一次用於反賬戶濫用和反蒸餾的主動實驗。按主觀故意程度，Claude Code是廠商自己承認的有意實驗，Grok Build至今沒有否認上傳機制的存在，ZCode的意圖尚無定論。

按數據採集範圍，Grok Build連用戶明確說“不要讀”的文件都傳走了，ZCode打包了86.6%的項目歷史。Claude Code傳的是行為元數據，量級不同但性質同樣涉及知情權。三起事故值得警惕的是它們被發現都是源於偶然，一次靠配置失誤導致源碼洩露，一次靠安全研究者的主動抓包，一次靠博主對硬盤空間不對勁的警覺，沒有哪次來自廠商自發的debug或者行業審計、監管巡查。ZCode今年7月上線時，智譜的宣傳直接對標Claude Code，正值Claude Code遙測爭議剛過數週，ZCode把自己定位成“可以擺脫被廠商遠程控制”的替代選項。

而Grok Build的上傳事件也發生在7月，幾乎與ZCode上線同月。三個月後，同樣性質的問題在ZCode自己身上被翻了出來，數據範圍還更大。打信任牌的人先翻了車，這大概是今年AI工具競爭中最具警示意味的一幕。Agent過去一年拿到的權限，超過了此前任何一類裝在個人電腦上的軟件。它能讀取當前項目目錄中的全部文件，能自主執行命令行操作，同時始終保持和廠商服務器的連接，還能在後臺接收遠程配置更新。在此之前，幾乎沒有哪種消費級軟件同時滿足這四個條件，圍繞這些新權限的安全規則確實在過去一年得到了迅速更新。

2025年底，國際應用安全組織OWASP發佈了首份面向自主AI Agent的十大風險清單；2026年1月，新加坡出臺了首個針對自主AI Agent的治理框架，要求每個Agent攜帶可驗證的數字身份；2月，美國國家標準與技術研究院啟動了AI Agent標準倡議；8月2日，歐盟人工智能法案的高風險義務正式生效。行業層面也已出現專門面向編程Agent的認證標準。規則數量在增長，但它們防的是工具被外部攻擊者利用，比如被惡意指令劫持，被誘導超越權限調用其他系統。整套防線的設計假設是廠商站在用戶一邊，威脅從外面來。

ZCode和Grok Build的外傳通道恰好站在這個假設的盲區裡，它們不在AI工具的能力清單上，不受權限審批流程管轄，運行在整套工具循環之外，AI助手本身都感知不到它們的存在，只拿現有的任何一份安全框架來逐條審查，這些行為都不會觸發警報。有觀點提出，應該像審計上市公司財報那樣審計Agent的數據行為。這個類比部分成立，定期的、標準化的、由獨立第三方出具的、買方能讀懂的審查報告，這個形式是對的。

但財務審計審的是法律強制要求企業保留的賬本，“什麼數據離開了用戶的電腦”這種記錄沒有任何法規要求廠商保留，證據本身是不足的； Agent客戶端可能每週更新，有的甚至每小時輪詢一次遠程配置來改變自身行為，年度審計報告在出具的那一刻就已經過期。上市公司審計背後有證券法和審計機構的連帶賠償責任，Agent審計背後目前什麼都沒有。開源是另一條被廣泛討論的路徑，智譜在這次事件後承諾開源ZCode代碼庫，OpenAI的Codex CLI和此前的Gemini CLI都採用了開源協議。開源能讓社區檢查客戶端裡有沒有類似的外傳機制，這種透明度本身就構成約束力。但開源有幾條天然邊界。

它只照得到客戶端，照不到服務端，數據送到廠商服務器之後發生了什麼沒人能看到。如果只開源修復後的版本而不公佈事發時的代碼，它對過去的行為零證明力，而且用戶從應用商店或安裝器拿到的是編譯好的成品，與公開的源代碼是不是同一個東西，除非做了專門的可復現驗證，否則無從核實。目前更務實的幾條路徑更具有可行性。一是要求廠商公開聲明Agent會連接哪些服務器地址、傳輸哪些類別的數據，讓異常流量可以被獨立工具比對。cereblab對Grok Build的分析就是用標準的網絡抓包工具完成的，如果廠商主動提供了出口聲明，驗證成本會大幅降低。

二是在用戶自己的電腦上留一份可讀、可導出的外傳日誌，寫明每次發送的體積、目的地和數據類別，直接解掉“加密包在你機器上生成而你看不到裡面有什麼”這個最刺眼的設計。三是責任保險機制，讓承保方而非認證機構來評估廠商的數據行為，前者需要為判斷失誤賠錢，是目前唯一能把“認真審查”變成經濟利益的機制。這些方案在技術上都不難，難在動力。目前推動它們落地的力量只有兩種，企業客戶的採購審查，以及偶發的社區曝光。前者只覆蓋企業版，後者全憑運氣。所以最終這場事故的隱性矛盾，可能比安全技術方案都更難處理。

在ZCode和Grok Build的場景裡，點下“同意”按鈕的是開發者個人，承擔數據洩露後果的是他的僱主和客戶，後者從頭到尾沒有出現在任何一個同意流程裡，也沒有任何渠道知道自己的代碼曾經被打包上傳。風險的承擔者和授權者不是同一個人，個人層面的知情同意在結構上就解不了這個問題，無論彈窗寫得多清楚、開關放得多顯眼。現實的走向大概率是分層。大型企業會在採購合同中加入數據行為條款和審計權，為此付出的成本最終會體現在價格裡；個人開發者使用的消費版則繼續處於一個沒人來審、也沒有人為之負責的狀態，但這恰好是絕大多數人在工作之餘繼續寫代碼的地方，也正是他們最容易用個人賬號打開公司項目的地方。

風險提示及免責條款 市場有風險，投資需謹慎。本文不構成個人投資建議，也未考慮到個別用戶特殊的投資目標、財務狀況或需要。用戶應考慮本文中的任何意見、觀點或結論是否符合其特定狀況。據此投資，責任自負。AI全知道 收藏 分享 0條評論 發送