智谱ZCode补偿方案公布：开源之后能否重建信任？

9 月 28 日，智谱公布 ZCode 数据上传争议补偿方案：付费用户及一个月内回归的付费用户获赠 4 张周额度重置卡和 4 张 5 小时额度重置卡，有效期一个月；9 月 28 日至 10 月 7 日，ZCode 每日向全体用户发放十万份“1 亿 token”。智谱重申，仓库快照上传链路已移除，涉事云端数据已删除，并经第三方核查确认。

事件始于 9 月 18 日。开发者 ferstar 发现 ZCode 会生成本地工作区快照，包含代码文件、.git 历史、Git LFS 缓存、reflog 等，并存在将加密快照上传至阿里云 OSS 的链路。一次具体快照约 313MB、含 42,411 个文件，其中约 87% 来自 .git 目录，曾经历 564 次上传尝试，但因超限未成功上传；另一较小公开仓库测试中，快照被服务端实际接收。快照采用 AES-256-CTR 加密，密钥由服务端 RSA 公钥封装，私钥掌握在云端。

智谱回应称，问题来自代码库索引功能，Repo Wiki 云端生成时可能触发仓库数据上传，该功能早期默认开启，数据在 Wiki 生成后销毁，未用于模型训练，并就此道歉。三天后，智谱将 ZCode 整体开源，采用 Apache 2.0 许可证，包含 Desktop、Web、Backend、Agent CLI 和 Agent Runtime 等组件；v3.14.0 删除 Repo Wiki，并切断本地仓库 snapshot 生成和上传链路。中国信通院确认相关 OSS bucket 已处于零数据状态，绿盟科技确认相关数据对象和 bucket 已删除。智谱承诺建立长期漏洞响应和奖励机制。

从质疑到道歉、下线功能、删除数据、引入第三方核查、开源产品，再到补偿方案，前后不过十天。但事件留下的核心问题仍未完全回答：一款能读取整个代码库的 Coding Agent，究竟把哪些数据带离开发者电脑，外界能在多大程度上验证？

目前公开源码中，争议数据链路确已移除，ferstar 重新对账后未再找到 repoSnapshot 上传管道，Repo Wiki 相关功能也已消失。但 ZCode 并非“数据不离开本机”的程序。其 NOTICE 文件列出仍存在的外部交互面：文件、Git、Terminal、Shell、Node REPL 可在宿主权限内读写文件、启动进程和访问网络；插件可带入自动执行 Hook、本地程序和远端工具；MCP 可使用命令、环境变量、认证 Header 或 OAuth 连接外部服务；内嵌浏览器可访问网页、读取页面、截图、上传下载文件；远端 Workspace、SSH、Web 服务各有网络和权限边界。ZCode 还提醒，共享 Agent Runtime 默认不提供操作系统级 Sandbox；独立 CLI 使用 --prompt 非交互执行且未指定 mode 时进入 yolo 模式，普通工具操作可不经逐次确认。

因此，判断 Coding Agent 的数据处理方式，仅确认“是否上传 repository”不够，还需知道哪些数据留在本地、哪些进入模型上下文、哪些传给智谱服务器或第三方模型，MCP、插件和 Browser 分别能获得哪些数据，哪些行为需用户确认，数据保存多久，以及服务端由谁拥有解密和访问能力。目前公开信息尚不足以形成完整数据流图。

另一个问题是开源仓库的 Git history 极其简单：一个空 initial commit，加一个 feat: open source 提交，后者一次性加入约 6973 个文件、103 万行代码。外界拿到的主要是整改后的代码快照，此前包含 Repo Wiki、repoSnapshot 和上传逻辑的历史版本未随开源仓库出现。这直接影响外部复盘：上传链何时加入、最初服务哪个功能、经历哪些修改、默认开启对应哪次产品决策、哪些正式版本包含该代码、最终删除时改了什么，原本可通过 Git history 和版本 diff 还原，现在很难直接从开源仓库还原。

公开 100 多万行当前代码仍有价值，外部开发者可审查现有实现，也可基于 Apache 2.0 许可证自行构建、修改和部署。但若开源同时承担安全事件后恢复信任的作用，代码历史同样是重要安全证据。软件安全事件调查常需追踪 provenance：功能从哪来、何时进入代码、如何演化、修复改变了什么。只公开整改后 snapshot，可帮助确认现在还有没有这段代码；至于事故发生时代码状态，现有仓库提供的信息有限。

智谱最初解释该链路与“代码库索引”“历史版本检查点恢复”“Repo Wiki”有关。ferstar 在开源版本中检查后认为，checkpoint 机制主要体现为本地 Git diff，而非云端 repository snapshot；目前 checkpoint 核心实现是调用本地 Git CLI，通过 git diff --name-status 和 git diff --numstat 计算变化，元数据保存在本地 ~/.zcode/checkpoints/。由于事故前代码未进入公开 Git history，外部研究者暂时很难从版本演进层面核对这些功能过去的关系。

数据端类似。信通院确认检查时 OSS bucket 已是“零数据状态”，绿盟确认数据对象和 bucket 已删除。这些核查说明检查发生时的数据状态，但此前数据生命周期仍需更多信息才能还原，例如过去成功上传过多少 repository snapshot、涉及多少用户、对象平均保存多久、服务端哪些系统或人员具备访问能力等。