ZCode 快照事件之后：开源能挽回多少信任

事情经过

9 月 18 日，开发者 ferstar 清理磁盘时注意到 ~/.zcode 目录占了不少空间。逆向客户端、分析网络请求之后，他发现智谱旗下的编程工具 ZCode 会生成本地工作区快照——不只是当前代码，还包括 .git 历史、Git LFS 缓存和 reflog——并且存在把加密快照上传到阿里云 OSS 的链路。

他分析的一份具体快照约 313MB、42,411 个文件，约 87% 来自 .git 目录；状态文件显示它经历过 564 次上传尝试，因超过大小限制一直停在本地、没有传成功。他随后用一个较小的公开仓库复现了上传。

加密不等于你持有钥匙

快照用 AES-256-CTR 加密，加密密钥再由服务端下发的 RSA 公钥封装，对应的私钥在云端。按他逆向出的链路，客户端先向 ZCode 服务端要 snapshot ID、RSA 公钥和 OSS 上传凭证，本地打包加密后直接把密文传到 OSS，绕过 ZCode 服务端——这也意味着审计和策略控制能力都受限。

这里的加密防的是第三方，不防厂商本身。

厂商的回应

智谱称问题来自代码库索引功能，它支撑本地索引、会话检查点、历史回退和 Repo Wiki；Repo Wiki 在云端生成时可能触发仓库数据上传。这项功能早期默认开启，相关数据在 Wiki 生成后销毁、没有用于模型训练，并就此道歉。

三天后智谱把 ZCode 整体开源，采用 Apache 2.0，包括桌面端、Web、后端、Agent CLI 和 Agent Runtime；v3.14.0 删除 Repo Wiki，并切断本地快照的生成与上传链路。智谱还请中国信通院和绿盟科技做安全核查，前者确认相关 OSS bucket 已是零数据。

仍然没有回答的

InfoQ 的报道提了三个问题，值得原样留下：

1. 今天公开出来的 ZCode，还有哪些数据会离开本机？
2. 为什么开源仓库没有保留事故之前的 Git 历史？
3. 一款能读整个代码库、跑 Shell、连 MCP、调用插件、可能接触企业凭据的编程智能体，发生过数据边界争议之后，「代码开源加第三方核查」能在多大程度上重建信任？

本条依据 InfoQ 中文的报道；ferstar 的逆向分析原文未经本站单独核对。

可迁移的一点

把它和本站已发的 Kiro Crew 那条放在一起看。Kiro Crew 的防护——敏感路径拦截、凭据脱敏、签名审计日志——写在系统层，没有一条写在提示词里。ZCode 这次的问题不出在模型，而出在一个默认开启的产品功能：它在用户看不见的地方，替用户决定了哪些数据可以离开这台机器。

所以评估一款编程智能体，要问的不只是它能做什么，还有三件事：什么数据会离开本机；谁持有解密的钥匙；这个默认值是谁定的。