AI编程工具，正在偷看你代码

你以为是AI在替你写代码，其实可能是你的整个项目在替厂商打工。

9月18日，技术博主ferstar对智谱旗下编程Agent ZCode的逆向分析引发连锁反应：只要登录账号，ZCode就会把用户整个工作项目连同完整修改历史打包加密，上传云端。更微妙的是，这件事不是被监管发现的，也不是被安全审计发现的，而是被一个排查硬盘异常的个人博主发现的。

这暴露出Agent行业一个长期没人愿意正面讨论的问题：过去两年，所有人都在防模型失控、防提示词投毒、防外部攻击者，唯独没人防Agent厂商自己。

🕳️ 一个313MB的文件，掀了桌子

事情的开头毫无戏剧性，甚至有点无聊。

ferstar只是在排查ZCode的本地目录时，注意到硬盘占用空间异常。他找到了一个约313MB的加密文件——体积远超日常大小。文件打不开，但附带的文件清单显示，这个包涵盖约4.2万个文件，其中超过八成属于项目的历史修改记录。

换句话说，这不是一次简单的日志上报，而是一次对用户工作目录近乎完整的扫描、打包与外传。且根据逆向结果，只要用户登录了账号，这个流程就在后台自动进行；软件界面缺少真正可用的关闭开关；加密文件的解密密钥，只保存在智谱一侧。

用数据流来看，整条链路是这样的：

这条链路的每个环节单看都似曾相识——遥测、备份、云端同步，SaaS产品都这么干。问题在于组合方式：全量、默认、不可关闭、密钥不在用户手里。

智谱的回应很快：致歉，称问题源于一项功能默认开启，数据用完即销毁，并承诺近期开源代码库、引入第三方审查。态度不算差，但两个关键问题仍悬而未决——既然密钥只在厂商一侧，用户拿什么验证用完即销毁？开源与第三方审查的时间表和范围，目前也没有细则。

产业层面的判断是：这不是智谱一家的工程失误，而是整个Agent赛道在产品哲学上的系统性越界。只是这一次，被掀了桌子。

🔍 这不是第一次，也不会是最后一次

如果把镜头拉远，会发现ZCode根本不是孤例，而是一条清晰的行业光谱。

• 更早些时候：Anthropic的Claude Code被发现在用户不知情的情况下回传位置和身份信息，Anthropic工程师甚至事后确认，那是一次有意实验；
• 不久前：独立安全研究者cereblab通过抓包分析证明，xAI的编程Agent工具Grok Build会把用户整个项目打包上传到谷歌云存储——包括用户明确告诉AI不要读取的文件，和未经脱敏的密码；
• 9月18日：ferstar发布ZCode逆向分析，全量项目打包上传曝光；
• 随后：智谱致歉，承诺开源与第三方审查。

三起事件，三种姿态，放在一张表里看更刺眼：

共同点比差异更值得注意。

第一，三家都是头部玩家，不是作坊团队。连资源最充足的厂商都会在这条线上反复试探，说明这大概率不是能力问题，而是优先级问题——在Agent功能迭代的速度压力下，用户数据边界被排在了后面。

第二，三起事件全部由社区个人发现：一个技术博主、一个独立安全研究者。没有一起来自监管检查，也没有一起来自厂商自己的安全审计。行业的守门人，实际上是几个用爱发电的逆向工程师。

这样的发现机制，注定是低覆盖率、高偶然性的。被发现的是少数，没被发现的呢？这个问题没有答案，恰恰是最大的问题。

⚠️ 安全框架里，没有一条规则管厂商

回到一个被长期回避的命题：Agent安全到底在防谁？

过去两年的行业讨论，几乎全部指向外部威胁——模型失控怎么办、提示词投毒怎么办、外部攻击者入侵怎么办。学术会议、安全白皮书、企业采购清单，密密麻麻都是这些条目。但ZCode、Grok Build、Claude Code这三起事件，指向的是完全不同的方向：数据的合法持有者，本身就可能成为外传的源头。

这就是当前Agent安全框架的结构性空洞：

为什么会出现这个空白？一个现实的解释是利益结构。安全框架大多由厂商参与制定或至少深度影响，让规则制定者给自己上枷锁，动力天然不足。对厂商来说，用户的工作目录是最高价值的数据——它包含真实的业务代码、组织结构和决策上下文，是打磨下一代Agent最稀缺的训练养料。在Agent竞争极度内卷的当下，谁能拿到更多真实工程场景数据，谁的产品迭代就更快。

于是出现了一个微妙的灰色地带：上报遥测可以包装成产品改进，全量打包可以包装成云端备份，模糊的隐私条款成为兜底。每一次越界，都有一个听起来合理的理由。

但商业逻辑不能替代边界。用户把代码交给Agent，隐含的契约是工具在本地处理、结果按需返回，而不是整栋房子被搬走存进别人家保险柜——钥匙还在别人手里。

🤔 默认开启，是产品哲学而不是意外

智谱回应中最值得琢磨的词，是默认开启。

这意味着在产品设计的某个时点，有人做出了选择：这个功能要让尽可能多的用户走到。如果它是可选的、需要主动勾选的，覆盖率和数据量都会断崖式下降。默认开启，是数据驱动型产品最经典的增长杠杆——也正因如此，把它简单归为一次事故，是不够的。

再看用完即销毁这个说法。逻辑上它无法被外部验证：加密文件上传到厂商控制的云端，解密密钥也在厂商手里，销毁与否完全依赖厂商自证。这就是为什么智谱承诺的开源代码库和第三方审查如此关键——它们是把自证变成他证的唯一路径。但截至目前，开源的范围（客户端还是全链路）、审查机构的选择、审查结果的公开方式，都还没有细节。

ZCode事件真正的行业价值，是给了所有人一个重新审视采购清单的机会。理想的Agent数据治理，至少应该包含这几层：

有意思的是，这份清单里没有任何一条需要颠覆性技术。全都是产品设计层面的选择。也就是说，问题从来不是能不能做到，而是想不想做——在没有外部压力的情况下，厂商显然缺乏自觉的动力。

🎮 游戏公司，别把Agent只当提效工具

这件事对游戏行业不是隔岸观火。

游戏项目的工作目录，可能是所有软件品类里最敏感的之一：未公布的版本代码、数值配置表、美术资产管线脚本、运营活动逻辑。一个使用编程Agent的策划或程序，随手登录账号的那一刻，整个项目的修改历史就可能已经在了云端。对动辄数年、宣发节点精确到天的游戏研发来说，版本信息泄露的代价，远高于一般软件行业。

现实中的风险场景其实很具体：核心项目组某位成员用了某个Agent工具，项目结构被全量上传；某款未公布产品的代码出现在第三方存储上；竞品情报机构拿到的是带完整迭代史的代码库，而不只是快照。这些场景没有一起已经发生，但ZCode和Grok Build事件证明，技术路径是通的。

给游戏厂商的启示可以很落地：其一，把Agent数据行为纳入供应商安全评估，上传范围、密钥归属、销毁机制写进采购合同，而不是只看模型跑分；其二，核心项目环境做网络隔离，生产代码目录与Agent工具默认权限分离；其三，关注厂商是否开放开源审计通道——这一次智谱的承诺能不能兑现，本身就是行业的一次试金石。

更深一层说，游戏行业过去吃过的数据泄露亏足够多，本该是最早建立起工具数据警惕性的群体。提效和守门，从来不是二选一。

结语：守门人不能只是几个博主

ZCode事件的走向尚未完结：开源承诺、第三方审查、监管是否会跟进，都还是未知数。但有三点判断可以先行记下。

第一，Agent厂商自身的数据行为，已经从边缘话题变成一级风险，安全框架补上厂商这一环只是时间问题。第二，个人逆向工程者成为行业事实上的安全审计力量，这种偶然性的守门机制不可持续，制度化监督迟早要补位。第三，对包括游戏在内的所有行业用户来说，评估Agent工具的维度必须从能力扩展到数据治理——毕竟，你交给AI的是代码，它带走的可能是整个项目。

下一次硬盘异常弹出提示时，希望我们已经不用再靠一个博主的直觉，来发现整个行业的问题。