智谱 ZCode「静默上传」事件回顾及分析

说明：以下内容基于 2026 年 9 月 16 日至 21 日期间的公开报道（SCMP、华尔街见闻、经济通、tech360、Tokenstead、Odaily/BlockBeats 等）、技术博主 ferstar、独立开源贡献者冯若航（Vonng）的逆向分析与复现、太原承明科技有限公司的律师函，以及智谱官方声明整理。部分社区传言（如「普通用户上传量普遍 50GB 以上」）尚无独立证据支撑，本文不予采信。个别财经媒体标题中出现的「股价跌 50%」系「4.9%」的误译，以正文数据为准。

背景：智谱（全称北京智谱华章科技股份有限公司，国际品牌 Z.ai，港交所代码 02513.HK）是中国头部大模型公司之一，由清华大学技术成果转化而来，以 GLM 系列模型的开源与商业化闻名，2026 年 1 月上市，被称为港股「大模型第一股」；ZCode 是其 AI 编程工作台。

---

一、事件时间线

---

二、技术细节拆解

2.1 发现的起点：一个删不掉的 313MB 文件

ferstar 在排查 ZCode 本地目录时注意到硬盘占用异常，在 ~/.zcode/v2/checkpoints 下找到一个 313MB 的加密压缩包，处于「待上传」状态，已失败 564 次。另有一个来自公开仓库的工作区快照（538 个文件，压缩加密后约 15KB）被服务端接收。压缩包源自一个 345MB、42,411 个文件的商业项目工作区。他手动删除后，约半小时 ZCode 自动重新生成了一份新的打包文件，重试计数继续累加。失败即重试，删除即重建。华尔街见闻的评价很克制：「删了还会再建，这或许不是一个可有可无的辅助功能应有的执着程度。」

2.2 上传内容构成

打包清单以明文形式存在本地，内容具体到可以逐项核对：

86.6% 是 Git 历史，而非当前代码。这一点的分量需要展开：Git 对象库不是工作区的一张快照，而是仓库自诞生以来的完整谱系。在后续提交中删掉的 API 密钥还在里面。未推送的分支名会暴露未发布的产品计划。.git/config 里有内部主机名和仓库路径。一份被截获的归档，是数年的工程史，不是你当时打开的那几个文件。此外，快照每次还会把 ZCode 自身的全局配置一并打包，跨项目带走。

2.3 上传链路（从 app.asar 逆向还原）

测试期间，运行中的客户端与 zcode.z.ai 及两个阿里云 OSS 节点维持着持久连接。

关键点是私钥只在智谱云端。ferstar 尝试用本机全部私钥解包均失败。用户硬盘上的密文，用户自己和 ZCode 客户端都打不开，只有智谱后台能解。用一个通俗的比喻：公钥是锁，任何人都能用它把东西锁进箱子；私钥是钥匙，只有持钥者能开。ZCode 的做法是锁由服务器临时发放，钥匙只在服务器那头。ferstar 的结论只有一句：「一把只有服务器能用的钥匙，只有一个用途：确保服务器想读你代码的时候随时能读。」

2.4 触发时机与决定权

上传在两个时间点触发：用户向 AI 发送请求之前、任务结束之后。一次活跃会话中观察到多达 62 次快照记录。冯若航的补充分析进一步表明，客户端每次发送提问都会无条件向服务端申请上传凭证，服务端发凭证就采集，不发就不采集。也就是说，采集与否的决定权完全在云端，客户端只是执行器。这意味着即便某个版本的客户端「看起来不上传」，只要代码路径还在，服务端一个开关就能重新开启。

2.5 过滤规则的顺序缺陷

ZCode 的文件筛选逻辑按顺序判定，.git 目录的放行规则排在密钥过滤和体积限制之前。这导致：

• 针对 .pem、.key 等敏感文件的过滤对 .git 内的内容不生效。
• 1MB 单文件体积上限对 .git 内的内容不生效。
• 任何曾经提交后又删除的密码、密钥，都会以 Git 对象的形式原样上传。

这是开发者最容易忽视的一点：当前工作区干净 ≠ Git 历史干净。承明科技律师函中列举的数据库密码、云服务凭证，很可能正是通过这条路径带走的。

2.6 界面开关的「装饰性」

界面上两个看似相关的选项，经 ferstar 逐一对照代码后确认：

• 「优化体验」（optimizeAgentExperienceEnabled）：只控制数据是否授权用于模型训练。
• 「仓库快照索引」（repoSnapshotIndexingEnabled）：只控制服务端收到数据后是否建立检索目录。

两个都关掉，本地打包和上传照常运行。负责快照与上传的 sidecar 组件在软件启动时无条件加载，不受任何用户偏好门控，唯一前提是能拿到有效的登录 JWT。

2.7 一个更深的结构性发现：上传不在 Agent 的工具清单里

公开的提示词收集库 OrcaPromptVault 中留存了 ZCode 一份 131KB 的系统提示词和 31 个工具的完整定义，提供了第二份独立佐证：

• 检查点/回滚功能确实接入了系统提示词：「Workspace rewind applied. rewindId, checkpointId, strategy, restoredFiles」 这一模板出现了五次，这是快照管线面向用户的那一端。
• 但 31 个工具中没有任何快照、上传或遥测工具。整个 131KB 的指令里，没有出现 Aliyun、OSS、upload 或 privacy 任何一个词。

这解释了为什么没有任何权限设置能拦住它：外传管线不是 Agent 的工具，而是运行在工具循环之外的宿主级 sidecar。Agent 自己都不知道它的存在，用户在对话里让 AI「不要读某个文件」，对这条通道毫无意义。另有一个 ReadSessionContext 工具可按会话 ID 读取其他已持久化的 ZCode 会话：会话内容既在本地持久化，也被云端捕获。

2.8 唯一有效的本地防御

删除待发送文件无效（半小时内重建）。ferstar 验证过的可行方案是在文件系统层面让检查点目录不可写：

# Linux
rm -rf ~/.zcode/v2/checkpoints
mkdir -p ~/.zcode/v2/checkpoints
sudo chattr +i ~/.zcode/v2/checkpoints

# macOS
rm -rf ~/.zcode/v2/checkpoints
mkdir -p ~/.zcode/v2/checkpoints
chflags uchg ~/.zcode/v2/checkpoints

代价是检查点回滚 UI 失效，而这恰恰是那个需要先上传你代码才能工作的功能。对话、补全、工具调用均不受影响。恢复用 chattr -i 或 chflags nouchg。

---

三、问题分析

3.1 官方解释与技术证据的矛盾

智谱首份声明的核心表述是：「该功能旨在帮助用户在本地生成仓库索引……Repo Wiki 功能在生成 Wiki 页面时可能会触发仓库数据上传……由于该功能在上线初期默认开启，部分用户因此受到影响。」这段话至少有五处与证据不符：

1. 「本地生成」与「上传云端」被并成了一句话。既然索引旨在本地生成，为什么要把整个项目送到云端？本地索引、本地快照、本地回退在技术上完全可行，市面上有工具就是这么做的。声明把后者说成前者的自然延伸，中间缺了最关键的一环解释。
2. 范围不匹配。ZCode 官方文档明确 Repo Wiki 生成「不读取项目的历史修改记录，只按需读取经过筛选的代码上下文」。一个技术上不需要 Git 历史的功能，为何上传包 86.6% 都是历史？是设计如此还是程序出错，声明没有回答。
3. 时机不匹配。Repo Wiki 是低频操作，但快照在每次提问前后都触发，一次会话 62 次。
4. 控制项不匹配。如果只是「某个功能默认开启」，那应该存在一个能关掉它的开关。事实是没有任何客户端开关能阻止打包上传。社区质疑的核心是「用户看到的控制项控制不了真正在发生的事」，这和「某个功能默认打开了」不是一个量级的问题。
5. 迭代痕迹。9 月 16 日的更新日志「优化仓库快照上传的内存占用」表明这是一项被持续维护的正常功能：工程团队不会为一个「意外行为」优化内存。而事后删除这条公开日志，本身构成独立于原始行为的新问题。

3.2 加密设计的双重含义

「加密上传」在公关话语中常被用作「安全」的证明，但这里需要拆开看：

• 它证明的是传输途中第三方无法截获。
• 它不能推出智谱自身无法解读内容。恰恰相反，这套信封加密的设计目标就是「只有智谱能解」。

更进一步，正因为只有智谱能解，「用完即销毁、不会保存」这一承诺在结构上无法被外部验证或证伪。用户能看到的只是数据离开了自己的电脑，之后发生了什么完全取决于厂商的自我约束。TNW 的评论切中要害：「智谱把包加密成只有智谱能打开，现在也只有智谱能说它已经删了。」

「立即销毁」回答的是「数据保留多久」，但用户真正需要知道的还有：数据是否已经离开了电脑（冯若航已证实至少一台是）、服务器处理过程中谁有权限访问、解密能力在谁手上、此前已上传的数据执行了什么删除策略。这些问题在两份声明中都没有正面回答。

3.3 隐私政策的覆盖缺口

ZCode 隐私政策英文版描述的收集范围是用户「通过对话（through conversation）」提交的文本、文件和代码，这是所有 AI 编程工具都会做的标准推理上下文披露。后台自动打包整个工作区显然不在此范围内：「在对话中向我们提交」和「后台自动打包整个项目」是两码事。ferstar 遍查政策、FAQ、更新日志，没有找到任何关于打包上传整个工作区与 Git 历史的说明。

更尴尬的是，该政策自己写明：当新功能涉及与原始目的没有直接或合理关联的信息收集时，应通过页面提示、交互流程等方式另行告知并取得用户同意。这一条款事实上被自己的产品违反了。再加上那位高管「不会实现网站所列功能以外的任何东西」的公开承诺：工作区快照并不在 ZCode 网站的功能列表上。

3.4 危机应对的得与失

得：道歉、承诺和补偿在争议发酵数小时内全部给出，反应速度不像准备长期隐瞒。开源客户端、引入信通院与绿盟审计、设立漏洞奖励，这些动作方向正确。绿盟出具的「存储桶零数据、上传链路已切断」确认，是事件中第一个可被指认的第三方证据。三天内走完致歉、整改、审计、开源全流程，在同类事件的处理中属于快的一档。

失：

• 首份声明将「机制层面的数据外传」表述为「某个功能的开关设置」，被社区视为轻描淡写。
• 没有交代问题从哪个版本开始存在、历史上传数据的删除策略与凭证。
• 「全体用户额外一次周额度重置」作为补偿，与被上传的内容不在同一个价值量级，对企业客户尤其如此。
• 相比 xAI 处理 Grok Build 事件时「服务端关闭上传 → 研究者复测确认 → 公布零保留政策」的可验证闭环，智谱初期缺少「可被第三方复测」的环节。

审计与开源的边界都需要说清：信通院与绿盟确认的是「当下」存储桶为零数据，这不等于证明事发期间的数据从未被访问、导出或用于其他目的。这一层边界，开源也没有跨过去。

9 月 21 日，ZCode 代码库在 GitHub 公开（zai-org/ZCode，Apache-2.0）：6,973 个文件、约 103 万行代码一次性提交，仓库里只有两个提交：一个空的初始提交，和一个「feat: open source」；没有 tag、没有 release，开发历史被整体压平；PR 通道关闭，Issues 停用。ferstar 在 9 月 21 日的更新里逐项核对了这份代码：上传链路相关实现（上传凭证接口、OSS 直传、AES-256-CTR 加密与公钥下发）被完整剥离，全仓库检索零命中；检查点回滚的代码实现是纯本地工具，调用本机 Git 执行 diff、元数据存于本地目录，与云端毫无关系。官方把上传放进「代码库索引」功能的叙事里，与之一同被提及的还有会话检查点恢复、历史版本回退与 Repo Wiki。如今检查点与回退被智谱自己的代码证实为纯本地，Repo Wiki 则按官方文档不读取历史修改记录；上传包为什么需要带走 86.6% 的 Git 历史，依然没有答案。

另一半问题则失去了被核对的入口。两个提交、零 tag 的仓库没有留下「何时引入、何时移除」的任何轨迹：Repo Wiki 与快照上传是什么时候写进客户端的、9 月 16 日前后改了什么、修复具体删掉了哪些代码，都无从追溯。那个被追问数日的问题（开源的是修复后的版本还是事发时的版本），等来的是第三个答案：一份历史被压平、与线上产品并不完全一致的代码切片。独立博主 Silent Star 的逐行对照显示，App 端构建比开源仓库领先一个小版本，机器人接入、远程控制等若干功能块未随开源发布，构建记录还指向一个不在仓库内的内部提交。开源兑现了「可检查」的承诺，但可检查的范围仅限于当下：被压平的历史、已经离开电脑的那批数据，都无法核对。

3.5 故意还是疏忽？

社区存在两派解读。

「故意论」的依据：加密只有服务端能解、开关是装饰性的、删除后重建、隐私政策不提及、更新日志被删。ferstar 本人的措辞偏向此派。

「疏忽论」的依据：如果目标是系统性采集训练数据，更精确的做法是只抽提问和代码改动，没必要把几百兆 LFS 缓存和操作日志一起打包。云存储有成本，大量个人练手项目的训练价值有限。对付费企业客户的数据出手，风险收益比极不划算。这种过度采集的形态，更像是工程团队开发快照功能时复用了一套通用打包逻辑，把与索引和回退相关的全部文件一股脑装了进去。

但这里必须补上华尔街见闻提出的一个关键视角：社区为什么始终不买账「只是为了生成说明文档」。如果一家厂商真的想收集用户数据，它最想要的未必是代码本身：公开代码托管平台的语料已经足够，私有代码文本的边际训练价值并不高。真正稀缺的是三样东西：

1. 改动的因果链。Git 历史存的不是一张张快照，而是「改之前长这样、因为什么、改成了那样」的完整过程，这是训练编程模型最理想的材料。
2. 带结果标注的使用轨迹。ZCode 在每次提问前拍一次全景快照，同时具备回退功能。两者组合，天然记录了「提问＋操作前状态＋操作后状态＋用户是否满意（有没有撤销）」的完整循环。这种数据在 AI 训练中极其昂贵，通常需要专门雇人标注。
3. 没有被任何模型见过的真实项目。公开评测题几乎都已被各家模型在训练时「做过一遍」，真实的私有项目是内部能力评估最有价值的原料。

这三样东西与 ZCode 上传包的构成高度吻合。这就是为什么「Repo Wiki」的解释在技术社区几乎没有说服力：不是因为大家认定智谱一定在做这件事，而是因为这套机制恰好把最有价值的训练数据以最完整的形态送到了只有智谱能解的地方，而智谱给出的理由却是一个不需要这些数据的功能。

笔者的判断是：激进的产品决策叠加工程层面的偷懒，比「智谱故意想搞点什么」更贴合已有证据。但必须强调，主观无恶意不减轻后果的严重性。对被上传了数据库密码和员工个人信息的企业客户来说，厂商「本意是做 Wiki」毫无意义；而「利用这些数据改进模型的动机是成立的、路径是现成的」这一事实本身，就足以让任何企业安全负责人做出禁用决定。

3.6 法律层面的潜在风险

• 《个人信息保护法》：员工与终端用户个人信息被打包上传，未经告知同意，且隐私政策自身的「另行告知」条款未被履行。
• 《数据安全法》/《网络安全法》：企业源码、系统架构、云凭证属于重要商业数据，未经授权采集。
• 数据跨境：承明科技追问上传主体是境内实体还是离岸实体、OSS 节点位置与访问主体是否构成出境。这是智谱迄今未清晰回应的问题，也是律师函中最具杀伤力的一条。
• 合同层面：付费企业用户可依据服务协议追究违约责任，承明科技要求的「访问日志、导出日志、删除凭证」正是为此铺路。

---

四、这不是孤例：2026 年 Agent 厂商的「批量越界」

三起事件的共同点令人警醒：没有一次是由厂商自查、行业审计或监管巡查发现的：一次靠配置失误泄露源码，一次靠研究者主动抓包，一次靠博主对硬盘空间不对劲的警觉。

还有一层讽刺：ZCode 7 月上线时的宣传直接对标 Claude Code，正值 Claude Code 遥测争议刚过数周，ZCode 把自己定位成「可以摆脱被厂商远程控制」的替代选项。Grok Build 的上传事件几乎与 ZCode 上线同月。三个月后，同样性质的问题在 ZCode 自己身上被翻出来，数据范围还更大。打信任牌的人先翻了车，这大概是今年 AI 工具竞争中最具警示意味的一幕。

---

五、社论：公域大模型的数据安全，信任不能靠「承诺」维系

1. 「开放权重」不等于「开放行为」

智谱以开源 GLM 权重赢得了全球开发者社区的信任，而 ZCode 事件暴露的正是这份信任的错位。事件讨论中有不少人误以为 ZCode 是开源的，因为 GLM 是开源的。它不是。权重开放，harness 闭源，而 ZCode 正是智谱为自家模型打造的第一方 harness，卖点是「第三方编辑器无法比拟的深度集成」。

模型开源解决的是「你能否在本地跑它」，而不是「厂商的客户端在你机器上做了什么」。Tokenstead 的评论把这一点说透了：一个本地运行的模型，被一个向云端打电话的 harness 包着，就不是本地的。模型外面那一层——桌面应用、更新管线、遥测——同样是信任面的一部分。开放权重是信任的起点，闭源客户端是信任的漏斗。当一家公司以「摆脱厂商远程控制」为卖点，却在自己的客户端里内置了一条服务端可遥控的采集通道，这种反差本身就是最大的信任损耗。

2. 授权者与受害者的错位是结构性问题

在 ZCode 和 Grok Build 的场景里，点击「同意」的是开发者个人，承担泄露后果的是雇主、客户、乃至终端用户，后者从头到尾没有出现在任何同意流程里，也没有渠道知道自己的数据曾被打包上传。承明科技的案例正是这一错位的具体化：一个员工安装了一款工具，公司的数据库密码和终端用户的个人信息就进了别人的存储桶。

风险的承担者和授权者不是同一个人，个人层面的知情同意在结构上就解不了这个问题，无论弹窗写得多清楚、开关放得多显眼。这意味着企业必须把 AI 编程工具当作供应链的一部分来治理，而不是当作员工的个人生产力选择。

3. 「加密」和「销毁」不能成为免检标签

行业需要建立一条共识：当解密密钥只在厂商手里时，「加密」是对第三方的防护，不是对厂商的约束；当数据只有厂商能读时，「已销毁」是一份声明，不是一份证据。真正有效的保证只有两种形态：要么数据根本不离开用户设备（本地优先架构），要么离开后的每一步都能被独立第三方复测（可验证的零保留）。xAI 事后允许研究者复测并确认上传已关闭，是值得借鉴的最低标准；智谱邀请绿盟确认存储桶清零，是朝这个方向迈出的一步，但它证明的是「现在没有」，不是「当时没做什么」。

4. 现有安全规则的盲区：只朝外，不朝内

Agent 过去一年拿到的权限超过此前任何一类装在个人电脑上的软件：读取项目目录全部文件、自主执行命令、始终保持与厂商服务器的连接、后台接收远程配置更新。此前几乎没有哪种消费级软件同时满足这四个条件。

围绕这些新权限的规则确实在快速更新：2025 年底 OWASP 发布首份面向自主 Agent 的十大风险清单。2026 年 1 月新加坡出台首个 Agent 治理框架，要求每个 Agent 携带可验证数字身份；2 月美国 NIST 启动 AI Agent 标准倡议；8 月 2 日欧盟 AI 法案高风险义务正式生效；行业层面也出现了面向编程 Agent 的认证标准。

但这些规则防的全是工具被外部攻击者利用：被恶意指令劫持、被诱导越权调用其他系统。整套防线的设计假设是「厂商站在用户一边，威胁从外面来」。ZCode 和 Grok Build 的外传通道恰好落在这个假设的盲区里：它们不在 Agent 的能力清单上，不受权限审批管辖，运行在整套工具循环之外，AI 助手本身都感知不到它们的存在。拿现有任何一份安全框架逐条审查，这些行为都不会触发警报。

5. 审计与开源各有边界，但都比「没有」好

有人主张像审计上市公司财报一样审计 Agent 的数据行为。这个类比部分成立：定期、标准化、独立第三方、买方能读懂的报告，形式是对的。但差异也很明显：财务审计审的是法律强制保留的账本，而「什么数据离开了用户电脑」没有任何法规要求厂商记录，证据本身就是不足的；Agent 客户端每周更新、甚至每小时轮询远程配置改变自身行为，年度审计出具那一刻就已过期；上市公司审计背后有证券法和审计机构的连带赔偿责任，Agent 审计背后目前什么都没有。

开源是另一条路径。智谱事后开源 ZCode，OpenAI Codex CLI、Gemini CLI 早已开源。开源能让社区检查客户端里有没有外传机制，透明度本身构成约束，这次它兑现了可兑现的部分：社区核对确认，客户端里的上传机制确已移除。但开源有几条天然边界，ZCode 的案例逐条应验：它只照得到客户端，照不到服务端；仓库以两个提交交付、没有开发历史，「何时引入、何时移除」无从追溯；线上 App 的构建来自仓库之外的内部提交，且包含未随开源发布的功能代码，编译产物与公开源码并不能画等号；可复现构建验证依旧缺位。做过逐行对照的博主 Silent Star 对这次开源的总结值得引用：公开一份经过清洗、滞后于线上产品的切片，能证明诚意，不能证明线上版本的安全。

在这两条「大路」之外，有三条更务实的路径值得业界推动：

• 出口声明：要求厂商公开 Agent 会连接哪些服务器地址、传输哪些类别的数据。cereblab 对 Grok Build 的分析用的就是标准抓包工具，有了出口声明作为基线，任何人都能低成本比对异常流量。
• 本地可读的外传日志：在用户自己的电脑上留一份可导出的记录，写明每次发送的体积、目的地和数据类别，直接解掉「加密包在你机器上生成而你看不到里面有什么」这个最刺眼的设计。
• 责任保险：让承保方而非认证机构来评估厂商的数据行为。前者判断失误要赔钱，是目前唯一能把「认真审查」变成经济利益的机制。

这些方案技术上都不难，难在动力。目前推动它们落地的力量只有两种：企业客户的采购审查，以及偶发的社区曝光。前者只覆盖企业版，后者全凭运气。

6. 对监管的期待：从「防外部攻击」转向「约束厂商自身」

ZCode 事件应当推动监管补上另一半：厂商自身的数据采集行为需要被列入合规清单：包括强制披露客户端所有出站数据通道、默认关闭非必要采集、提供可验证的删除机制、对企业级客户提供数据不出境与不出设备的技术选项。此事恰逢中美元首会晤前夕，AI 隐私与网络安全被多家外媒列为可能议题；主管部门是否会以此为契机出台针对 AI 编程助手的专项要求，值得关注。

7. 对国产大模型出海的连带影响

不能回避的一点是：这起事件发生在中国 AI 公司集体出海、努力对冲「数据安全」指控的关键时期。SCMP 引述上海开发者 Tuxi 的判断颇具代表性：事件对社区信任的伤害将大于对模型本身的伤害，「这基本上就像从用户那里偷东西」；GLM 海外用户可以换用 Codex 等其他工具继续调用模型，但对智谱品牌的信任不会随之迁移。Longbridge 的市场分析则指出，事件为 Cursor、GitHub Copilot 等能证明本地优先处理的竞品创造了「信任溢价」，并显著抬高了智谱 B 端扩张的执行风险。

这不只是智谱一家的信任危机，而是整个国产大模型阵营在海外企业客户面前的信誉损耗。修复这种损耗，靠的不是公关，而是在数据实践上做到比对手更透明、更可验证。

8. 最可能的走向：分层

现实的走向大概率是分层。大型企业会在采购合同中加入数据行为条款和审计权，为此付出的成本最终体现在价格里。个人开发者使用的消费版则继续处于一个没人来审、也没有人为之负责的状态。

问题在于，消费版恰好是绝大多数人在工作之余继续写代码的地方，也正是他们最容易用个人账号打开公司项目的地方。承明科技的 32,932 个文件，很可能就是这样流出去的。分层解决的是企业的合规问题，解决不了数据实际流动的路径问题。

---

六、给开发者与企业的实操建议

个人开发者

• 审视所有 AI 编程工具的出站流量：用代理或 Little Snitch / OpenSnitch 类工具监控，关注非 API 域名、尤其是对象存储域名的大流量 POST。
• 定期检查 ~/.zcode、~/.cursor、~/.claude 等本地目录，留意异常体积的缓存或待上传文件，ferstar 的发现起点就是硬盘空间不对。
• 对仍在使用 ZCode 的用户，可按 2.8 节的方式将检查点目录设为不可写：本次开源版本经社区核验、上传链路确认移除（见 3.4 节），不过客户端支持热更新，不妨多留一道保险。
• 清理 Git 历史中的敏感信息（git filter-repo、BFG），并把密钥管理从「提交后删除」改为「从不提交」，历史里的秘密比工作区里的更危险。
• 对商业项目，优先考虑本地模型或提供零保留承诺、且允许网络审计的企业方案；对任何 harness 问两个问题：登录后它传什么，谁能解开它存的东西。

企业

• 将 AI 编程工具纳入软件供应链治理，建立准入白名单，明确禁止用个人账号在公司项目上使用未审批工具。
• 在网络层部署 DLP 与出站控制，对未审批的对象存储域名（OSS、S3、GCS）默认拦截，三起事件的目的地全是云对象存储。
• 要求供应商提供数据流图、出站端点清单与可复测的删除机制，写入合同，并保留审计权。
• 对已使用 ZCode 的团队，按承明科技的路径评估风险：清点涉及的工作区，轮换所有可能出现在 Git 历史中的凭证（不只是当前配置里的），评估个人信息泄露的法定报告义务，必要时向智谱索取访问与删除凭证。

---

结语

ZCode 事件最值得记住的不是那个 313MB 的文件，而是它被发现的方式——一位博主觉得硬盘空间不太对劲。在一个 AI Agent 拥有读写文件、执行命令、访问网络全部权限的时代，用户对厂商的信任前所未有地脆弱，而验证这种信任的手段却几乎为零。今年三起同类事件，三种偶然的发现方式，零次来自制度性的监督。

智谱用一次周额度重置和两份道歉声明换不回被打包走的 Git 历史。但如果这个行业能从中真正建立起「可验证而非可承诺」的数据实践标准：出口声明、本地外传日志、可复测的删除、把厂商自身行为纳入安全框架，这次事故的代价才算没有白付。否则，下一次仍然要靠某个人在某个深夜觉得硬盘不太对。

---

主要参考来源

• ferstar，《Inside ZCode: Silently Uploading Your Entire Git History to the Cloud》及 9 月 19 日、21 日两次更新，2026-09-18/21
• Silent Star，《我在 ZCode 的本地快照里找到了 Git 历史》《ZCode 开源首日：把安装包拆开，和 GitHub 源码做了逐行对照》，2026-09-18/21
• 智谱官方声明（2026-09-18/21）与 ZCode 开源仓库（github.com/zai-org/ZCode），2026-09-20/21
• 华尔街见闻（林克、郑好），《智谱 ZCode 偷传代码风波追踪：Agent 的数据行为谁来审计？》，2026-09-19
• Tokenstead，《ZCode uploads your entire git history, and only Z.ai holds the key》，2026-09-18
• South China Morning Post，《Chinese AI firm Z.ai faces reputation hit after users spot unauthorised uploads》，2026-09-20
• Odaily / BlockBeats（经 KuCoin 转载），太原承明科技律师函相关报道，2026-09-20
• 经济通（经 Longbridge 转载），智谱股价及整改声明报道，2026-09-21
• tech360.tv，《Z.ai's ZCode Secretly Uploaded User Data, Trust Declines》，2026-09-21
• Longbridge AI 事件分析（引用虎嗅），2026-09-20