9月18日，技术博主ferstar在排查硬盘空间异常时，发现了一个约313MB的加密文件。它来自智谱的编程Agent工具ZCode，打包了约4.2万个文件，其中86.6%是项目的完整修改历史。解密的钥匙不在用户电脑里，只在智谱的服务器上。
这不是一起普通的隐私泄露。它暴露的是一个结构性问题：过去一年建立的整套Agent安全规则，几乎全部朝外设计——防模型失控、防提示词投毒、防外部攻击者——却没有一条是用来约束厂商自身的。
一、上传是设计出来的，不是漏洞
先把事实链条摆清楚。ferstar的逆向分析显示，ZCode在两个时机会打包上传：一是用户每次向AI发送提问之前，二是任务结束之后。一个活跃使用日里，他观察到多达62次快照记录。
用户有没有办法关掉它？界面上的两个开关经逐一对照代码逻辑后确认：「优化体验」只控制数据是否用于模型训练，「仓库快照索引」只控制服务器收到数据后是否建立检索目录。两个都关掉，本地的打包和上传照常运行。
更刺眼的是三个细节。其一，历史记录目录在打包流程中被豁免于所有安全过滤——针对pem、key等密钥文件的过滤和1MB体积上限，对历史记录里的内容一律不生效，曾提交又被删掉的密码会原样上传。其二，ferstar手动删除那个313MB的待发送文件后，半小时内ZCode自动重新生成并反复重试，该文件当时已失败564次。其三，另一名开发者冯若航独立复现了取证流程，在自己4个工作区的快照记录中，确认至少一份快照的状态文件带有服务端接受确认的标记——按代码逻辑，这个标记只有在上传被服务端确认后才会生成。至少有一台机器上的数据，确实离开了本地。
还有一条后来被删除的证据：ZCode v3.12.2版本（9月16日，事发前两天）的更新日志里写着「优化仓库快照上传的内存占用」。工程团队很难给一个「意外行为」做内存优化——上传在内部是一项被持续迭代的正常功能。而删除公开记录本身，是一个独立于原始行为的新问题。
二、回应解释的，和社区追问的，不是同一件事
智谱的道歉来得很快：问题源于「代码库索引」功能默认开启，Repo Wiki生成Wiki页面时可能触发上传，数据云端生成后「立即销毁，不会保存」，并承诺开源代码库、引入第三方审查。
但这份说明存在一个关键的逻辑错位。官方说索引「旨在帮助用户在本地生成」——既然是本地生成，为什么需要把整个项目送到云端？本地做索引、快照、回退，技术上完全可行，市面上也有工具就是这么做的。说明把「本地索引」和「上传云端」并成一句话，仿佛后者是前者的自然延伸，中间缺的那个环节恰好没人解释。
「立即销毁」回答的是数据保留多久，回答不了：数据是否已经离开过电脑、服务器处理过程中谁有权限访问、解密能力在谁手上。从加密方式看，公钥锁箱、私钥只在服务器一侧，「加密上传」只证明传输途中不会被第三方截获，推不出厂商自己无法解读。而ZCode隐私政策写明收集的是用户「通过对话」提交的内容——后台自动打包整个项目，根本不在这个描述范围内。
三、真正稀缺的不是代码，是三种数据
如果厂商真想收集数据，想要的会是什么？社区始终不买「只为生成说明文档」这个账，原因在于上传包的构成恰好对上了训练数据的三样稀缺品。
一是改动的因果链。历史记录里存的是「改之前长这样、因为什么、改成了那样」的完整过程——给定项目现状和修改意图，模型应该做什么改动，这是训练编程模型最理想的材料。二是带结果标注的使用轨迹。每次提问前拍一张「全景照片」，加上用户可以撤销AI的修改，两个动作组合天然记录了「提问＋操作前状态＋操作后状态＋用户是否满意」的完整循环——这种数据通常需要专门雇人标注。三是从未进入任何训练集的真实私有项目，这是做内部能力评估最有价值的原料，公开评测题早已被各家模型「做过一遍」。
但也要说句公道话：如果目标是系统性采集训练数据，更精确的做法是只抽取提问和改动，犯不着连几百兆的大文件缓存和完整操作日志一起打包。过度采集的形态，更像是激进的默认开启决策叠加工程偷懒——复用了一套通用的打包逻辑，一股脑全装进去。激进的产品决策加工程偷懒，比「故意搞点什么」更贴合现有证据。但这不减轻问题的严重性：密钥文件照样可能离开用户的电脑。
四、这不是孤例，是「单向信任陷阱」
把今年三起事件放在一起看，模式就清楚了。7月，安全研究者cereblab抓包证实xAI的Grok Build会把整个项目上传到谷歌云存储——包括用户明确说「不要读取」的文件和未经脱敏的密码，一个12GB的测试项目上传超过5GB；关闭「改进模型」选项后上传照常。3月，Claude Code被发现每小时轮询一次远程配置，配置里包含可以强制退出程序、绕过权限提示的开关；它还读取用户的代理地址和时区等环境信号回传服务端，Anthropic工程师事后确认那是一次主动实验。
三起事件的发现路径同样值得警惕：一次靠配置失误，一次靠研究者的主动抓包，一次靠博主对硬盘空间的警觉。没有哪次来自厂商自发的debug、行业审计或监管巡查。
更讽刺的是，ZCode今年7月上线时，智谱的宣传直接对标Claude Code，正打着「可以摆脱被厂商远程控制」的信任牌。三个月后，同样性质的问题在自己身上被翻出来，数据范围还更大。
可以把这个模式命名为单向信任陷阱：Agent拿到了前所未有的权限组合——读取全部项目文件、自主执行命令、保持与服务器的连接、接受后台远程配置更新。而2025年底OWASP的Agent十大风险清单、2026年1月新加坡的Agent治理框架、2月NIST的Agent标准倡议、8月生效的欧盟AI法案高风险义务，防的全是工具被外部利用。整套防线的假设是厂商站在用户一边，威胁从外面来。厂商自己的外传通道恰好站在盲区里：它不在AI能力清单上，不受权限审批管辖，运行在整套安全循环之外。拿任何一份现有安全框架逐条审查，这些行为都不会触发警报。
五、怎么办：承认同意结构已经失效
有人提议像审计上市公司财报那样审计Agent的数据行为。形式是对的，但照搬有三个缺口：法规不要求厂商保留「什么数据离开过用户电脑」的记录，证据先天不足；客户端可能每周更新甚至每小时轮询配置，年度审计报告出具即过期；财报审计背后有证券法和连带赔偿责任，Agent审计背后什么都没有。
开源能照到客户端，照不到服务端；只开源修复后版本对过去的行为零证明力。更务实的三条路径：厂商公开声明Agent连接哪些服务器、传输哪些类别的数据，让异常流量可以被独立工具比对（cereblab用的就是标准抓包工具，有了出口声明验证成本会大幅降低）；在用户电脑上留一份可读可导出的外传日志，写明每次发送的体积、目的地和数据类别；用责任保险让承保方评估厂商的数据行为——前者要为判断失误赔钱，是目前唯一能把「认真审查」变成经济利益的机制。
但最深的矛盾不在技术。在ZCode和Grok Build的场景里，点下「同意」的是开发者个人，承担泄露后果的是他的雇主和客户——后者没有出现在任何同意流程里，也没有任何渠道知道自己的代码曾被打包上传。
授权者和风险承担者不是同一个人，个人层面的知情同意在结构上就解不了这个问题。无论弹窗写得多清楚、开关放得多显眼。
现实的走向大概率是分层：大型企业会在采购合同里加入数据行为条款和审计权，成本最终体现在价格里；个人开发者的消费版则继续处于没人审、也没人负责的状态——而这恰好是绝大多数人写代码的地方，也是他们最容易用个人账号打开公司项目的地方。下一次点「同意」之前，值得先问一句：这个按钮，到底替谁签的字。
来源备注：本文事实链基于ferstar的ZCode逆向分析、冯若航的独立复现、cereblab对Grok Build的抓包分析及智谱官方回应，综合36氪《智谱ZCode传包风波，那些没回答的事》整理。