.png?table=collection&id=cbe6506e-1263-8358-a4d7-07ce62fcbb3f&t=cbe6506e-1263-8358-a4d7-07ce62fcbb3f){kind=small}
ARTICLE SIGNAL
智谱ZCode风波深度解读：开源与补偿能否重建信任？
智谱ZCode数据风波,AI编程工具数据安全,Coding Agent隐私边界,大模型代码泄露,开源重建信任,AI资讯,AI新闻,AGI,大模型,人工智能,探讨ZCode从争议到开源的全过程。
type
status
date
slug
summary
tags
category
icon
password
网址
在近期备受关注的AI新闻中，智谱旗下AI编程工具ZCode的数据风波无疑是开发者社区讨论的焦点。从9月中旬开发者曝光ZCode在后台悄悄打包上传本地代码库快照，到智谱官方火速道歉、下线功能、删除云端数据，再到最终宣布将产品整体开源并给出丰厚的代币补偿，整个危机公关过程仅仅用了十天。作为一家专业的AI门户，我们认为这一事件不仅关乎单一产品的存亡，更触及了当前大模型（LLM）和人工智能开发工具的核心痛点：隐私边界与信任危机。
对于每天关注AI资讯和AI日报的开发者来说，额度重置卡和“1亿token”确实能安抚一时情绪，但一款能够读取整个代码库的Coding Agent，究竟把哪些数据带离了本地？开源与第三方核查，真的足以彻底打消用户的疑虑吗？本文将为您深度拆解这一事件背后的技术细节与行业隐患。更多前沿AGI与AI技术动态，欢迎访问我们的AI门户 https://aigc.bar 获取。
事件始末：从本地磁盘异常到信任危机
这场风波的起点，源于开发者ferstar在清理MacBook磁盘时的一次偶然发现。他注意到本地的
~/.zcode 目录占用了异常庞大的空间。经过对客户端的逆向工程和网络请求分析，一条隐秘的数据上传链路浮出水面：ZCode不仅会生成当前代码文件的快照，还会将 .git 历史、Git LFS缓存等核心敏感内容打包，采用AES-256-CTR加密后，直接上传至阿里云OSS。在ferstar的测试中，一个包含4万多个文件的快照（约313MB）因体积过大一直处于pending状态，但另一个较小的测试仓库则被服务端成功接收。这一发现迅速在开发者社区引发轩然大波，事情很快从一次单纯的技术排查演变为一场严重的信任危机。
面对质疑，智谱的响应不可谓不迅速。官方解释称，问题源于“代码库索引”功能中的Repo Wiki生成机制，并强调数据未用于大模型训练。随后，智谱不仅切断了上传链路，邀请中国信通院和绿盟科技进行安全核查，更是直接将ZCode的核心组件（采用Apache 2.0许可证）全面开源，试图以最大的透明度挽回开发者。
核心争议未解：Coding Agent的数据边界究竟在哪？
随着ZCode的开源，最受争议的
repoSnapshot 上传管道确实被移除了。然而，这并不意味着ZCode变成了一个纯粹的“本地沙盒”程序。在开源仓库的NOTICE文件中，智谱详细列出了ZCode目前依然存在的外部交互面。作为一个强大的Coding Agent，它能够读写文件、启动进程、访问网络，其MCP（Model Context Protocol）可以连接外部服务，内嵌浏览器能截取网页，插件系统更是能带入自动执行的Hook。甚至在特定的yolo模式下，普通工具操作可以跳过用户的逐次确认。
在人工智能编程助手的应用场景中，数据边界远比单纯的“是否上传代码”复杂得多。模型API需要获取上下文，MCP Server会接触企业凭据，Browser Agent可能获取登录态。在这个执行链条中，哪些数据留在了本地？哪些进入了openai、claude或智谱自身模型的上下文？哪些行为需要用户显式授权？这些问题目前依然缺乏一张清晰、完整的数据流图来解答。
开源的“断层”：缺失的历史记录与取证难题
智谱选择开源是一步好棋，但外部开发者很快发现了另一个问题：开源仓库的Git history极其干净。整个仓库只有两个Commit，其中包含103万行代码的提交是整改完成后的快照。
在软件安全事件的调查中，溯源（provenance）至关重要。那段引起争议的上传代码是什么时候加入的？最初服务于什么功能？经历了哪些迭代？这些本可以通过Git版本差异（Diff）提供的关键线索，随着历史记录的抹除而无从查证。
这导致了一个尴尬的局面：“当前状态的验证”与“历史事件的取证”被割裂了。第三方安全机构确认了目前的OSS bucket是“零数据状态”，但这无法完全还原历史上传数据的规模、服务端的访问日志以及加密私钥的生命周期。如果开源不仅是为了分享代码，更是为了重建信任，那么保留完整的代码演进历史作为安全证据，显得尤为必要。
行业警示：从ZCode到Plugin4Shell的安全挑战
ZCode事件并非孤例。就在同一时期，安全公司AIR Security披露了名为Plugin4Shell的供应链漏洞，影响了包括Claude Code、OpenAI Codex、GitHub Copilot和Gemini CLI在内的多款主流工具。（值得一提的是，Google在回应中表示Gemini CLI已弃用，建议用户迁移至不受该漏洞影响的Antigravity）。
Plugin4Shell揭示了Coding Agent在插件安装机制上的脆弱性。攻击者可以通过控制插件仓库，绕过哈希校验，将恶意代码植入开发者的工作目录。一旦恶意插件进入Agent的执行链，它将继承Agent的高权限，直接威胁到私有代码库、SSH key和云端凭据。
过去我们在讨论AI编程安全时，往往聚焦于Prompt注入或模型是否会生成有漏洞的代码。但现在，Harness、Git、Plugin、MCP等组件已经构成了庞大的攻击面。Coding Agent不再仅仅是一个高级的自动补全工具，它正在变成一个拥有极高系统权限的“超级代理”。
结语：重建信任需要更彻底的透明
智谱ZCode风波为整个AI行业敲响了警钟。当开发者将核心代码资产和系统权限交给AI助手以换取效率提升，甚至期望通过AI工具实现AI变现时，厂商必须提供足够坚实的安全承诺。
开源和第三方核查是重建信任的良好开端，但要真正说服社区，厂商还需要建立可持续审查的数据流机制、开放漏洞报告渠道、保留完整的代码审计追踪，并明确各个组件的权限边界。在这个AGI加速到来的时代，能力越大的Agent，需要的透明度也就越高。
想要了解更多关于大模型安全、chatGPT及各类AI工具的深度解析与最新AI新闻，请持续关注我们的AI门户：https://aigc.bar，与我们一起探讨AI技术的未来走向。
Loading...