“偷传代码”风波升级：企业发函要求 12 项答复，智谱要过哪几关？

“偷传代码”风波升级企业发函要求 12 项答复智谱要过哪几关【免费下载链接】ZCodeZCode 是 AI 编程工作台提供桌面应用、浏览器界面和终端 Agent。本仓库包含客户端、后端服务、共享 UI以及 Agent CLI 与运行时源码。项目地址: https://gitcode.com/zai-org/ZCode一个本应“让开发者更省心”的开源编程 Agent正在经历一场从技术争议到商业合规的连环拷问。事情的主角是智谱开源的 ZCode——一个提供桌面应用、浏览器界面和终端 Agent 的 AI 编程工作台代码全部沉淀在本仓库zai-org/ZCode中。导火索来自一名开发者的发现ZCode 在运行过程中将用户代码仓库上传到了阿里云 OSS。随后“偷传代码”的说法在社区快速发酵从 CSDN 上的实测长文到开源社区的技术讨论再到澎湃新闻报道“一企业发函要求作出 12 项答复”这场风波已经从个人开发者的隐私焦虑升级为企业级客户的白纸黑字。本文不打算重复“到底算不算偷”的情绪化争论而是做两件更有价值的事一是沿着公开报道还原这场风波的完整时间线二是打开 ZCode 的真实源码用工程事实回答企业函件里最可能被追问的几个合规问题——数据流向、留存、删除、权限与遥测最后推演信任危机的三种走向。从开发者举报到企业发函风波升级的完整时间线把社区情报中的零散线索拼起来这条时间线大致清晰事件背景风波爆发之前ZCode 正处于高歌猛进的上升期。官方宣称用户突破 100 万并上线了多项新功能此前的 ZCode 3.0 正式发布全面切换为自研 ZCode Agent 内核同期 GLM-5.3 拿下多个开源 SOTA与 ZCode 形成了“模型 智能体”的组合叙事。在 README.md 的仓库描述中ZCode 的定位是“AI 编程工作台提供桌面应用、浏览器界面和终端 Agent”Agent CLI 与运行时源码就放在 apps/zcode-cli/ 下随仓库一起克隆主打开源可审计。引爆点据 Pasquale Pillitteri 的公开发现ZCode 曾将开发者的代码仓库上传到阿里云 OSS。对于一个被贴上“开源、可审计、可私有化部署”标签的工具而言这个发现击穿的是信任底线——开发者以为代码只在本地和模型 API 之间流转却发现了意料之外的云存储上传行为。发酵期社区进入“技术解剖”模式。CSDN、掘金等平台密集出现了大量实测与争议解析文章主题高度集中ZCode 的 OSS 上传逻辑是否必要、遥测与权限机制如何工作、网络请求是否可审计、敏感项目应该如何隔离。可以说是社区的自发审计把一场个例发现变成了系统性的信任拷问。官方回应数据上传争议事件后智谱公布了补偿方案。补偿只能缓解个体情绪无法替代合规层面的实质承诺。升级澎湃新闻披露一家企业正式发函要求智谱就相关问题作出12 项答复。至此事件性质彻底变化——它不再只是开发者社区内部的隐私声讨而是进入了“客户—供应商”之间的正式合规质询流程。12 项答复问了些啥数据流向、留存与删除的合规清单企业函件的 12 项答复原文并未公开但以企业采购 AI 编程工具的合规惯例推断问题必然围绕“数据离开本机后去了哪里、待了多久、谁能删掉”这几个轴心展开。好消息是ZCode 是开源的这些问题大部分可以从源码里得到验证级答案。我们把函件最可能追问的合规面逐一映射到仓库真实代码上。第一关数据流向——谁能说清楚代码究竟去了哪任何 AI 编程 Agent 都存在一个无法回避的事实要让大模型理解并修改代码代码必然要作为上下文发送给模型服务。关键在于发给了谁、通过什么协议、用户能否替换。看内置 Provider 配置 config/provider/zcode-builtin.jsonZCode 的模型接入面非常清晰{ templateId: zai-api, api: { type: anthropic-messages, baseUrl: https://api.z.ai/api/anthropic } }同样一份配置里还并列着bigmodel-standard-apihttps://open.bigmodel.cn/api/paas/v4、DeepSeek、Kimi、MiniMax、阿里云百炼、OpenAI、Anthropic、xAI、OpenRouter 等十余套模板协议覆盖anthropic-messages、openai-chat-completions、openai-responses三种形态。这意味着代码外发的“目的地”是配置可见、用户可换的不想走智谱的端点就换成 DeepSeek 或其他服务商甚至接本地模型。这正是开源与闭源工具在“数据流向可审计性”上的本质差别。至于“上传到阿里云 OSS”这一被举报的行为属于历史版本中超出模型请求之外的云存储上传。OSS 暂存有工程动因长会话、跨端同步等场景需要暂存对象但对企业客户而言任何非模型推理必需的字节外发都必须单独列明用途、触发条件与关闭开关。这正是 12 项答复中“数据流向”这一关的核心开源源码摆在那里能自证清白但需要给出逐条对账式的说明。第二关权限机制——代码不是“想传就能传”ZCode 在工程上把“工具调用边界”做成了显式的权限模型。看配置 Schema apps/zcode-cli/packages/adapters/src/config/schema.tsconst permissionSchema z.object({ mode: z.enum([plan, build, edit, yolo, auto]).optional(), allowedTools: z.array(z.string()).optional(), disallowedTools: z.array(z.string()).optional(), autoApproveHighRisk: z.boolean().optional(), allowMediumRiskInAuto: z.boolean().optional(), });五种模式从“只规划不动手”的plan到全自动的yolo依次递进配合工具白名单allowedTools、黑名单disallowedTools与高危操作自动放行开关autoApproveHighRisk构成了一个可编程的安全边界。系统提示词中对此也有明确约束——apps/zcode-cli/packages/core/src/context/sections/identity.ts 的 Harness 块写道“Tools run behind a user-selected permission mode; a denied call means the user declined it”。启动时apps/zcode-cli/packages/bootstrap/src/app/create-app.ts 会读取这些配置构造PermissionServiceconst permissionService new PermissionService({ allowedTools: new Set(configResult.config.permission.allowedTools), autoApproveHighRisk: configResult.config.permission.autoApproveHighRisk, disallowedTools: new Set(configResult.config.permission.disallowedTools), allowMediumRiskInAuto: configResult.config.permission.allowMediumRiskInAuto, });对企业函件而言这套机制的意义在于高危动作包括网络上传、写文件、执行命令具备可配置的审批关卡企业完全可以把默认模式钉死在plan或build并利用 hooks 体系见 apps/zcode-cli/README.md 中的PreToolUse、PermissionRequest事件拦截任何未经批准的工具调用。质疑“偷传代码”其实要先回答“它的权限闸门有没有被正确配置”。第三关留存与删除——本地数据到底存了多久、能不能清干净企业关心的第二个问题是数据“待了多久”。ZCode 的本地存储布局在配置层有明确默认值——apps/zcode-cli/packages/adapters/src/config/file-config.adapter.ts 定义了DEFAULT_BASE_DIR ~/.zcode/cli。在这个目录下会话记录、工具产物、图片/PDF/视频缓存、执行输出分别落盘启动流程还会执行日志保留清理scheduleStartupLogRetentionCleanup。也就是说本地侧的数据留存是有目录、有清理机制的企业可以自行定位并删除。真正的合规难点在云侧模型服务端通常会留存对话记录用于改进模型或风控OSS 暂存对象也有生命周期。开源只能证明“客户端传了什么”证明不了“云端存了多久、删没删”。这正是智谱必须书面答复的部分会话数据在服务端的留存期限、OSS 对象的 TTL 策略、删除请求的处理 SLA、以及是否提供企业版的数据驻留Data Residency承诺。补偿方案能安抚个人开发者但企业采购合同需要的是可审计的留存矩阵和删除凭证。第四关遥测与元数据——除了代码还传了什么“偷传代码”之外企业还会追问遥测边界。仓库中的遥测引导代码 apps/zcode-cli/packages/bootstrap/src/telemetry-bootstrap.ts 展示了其设计取向export async function prepareZCodeTelemetryEnv(env, options) { const prepared await prepareModelTelemetryEnv({ ... }, { ... }); const deviceMid prepared.ZCODE_TELEMETRY_DEVICE_MID; return deviceMid ? { ...env, ZCODE_TELEMETRY_DEVICE_MID: deviceMid } : env; }注意文件头注释的表述“只把准备出的 device MID 放回业务 envOTLP Header 等私密配置仍保留在进程内捕获区不进入 Tool/MCP 子进程环境。”这是一种收缩遥测暴露面的设计——设备标识MID与鉴权头分离避免敏感配置泄漏到子进程。企业会继续追问遥测开关是否默认关闭、采集字段是否包含文件路径与代码片段、能否在企业内网部署时完全切断外联。答案同样需要逐项书面化。若答复不及预期开源项目信任危机的三种走向12 项答复的结果将决定这场风波走向哪条路径。基于开源生态的普遍规律可以推演出三种可能的走向走向一工程加固信任重建。最理想的情形是智谱逐条答复、修复历史版本中的非必要上传路径把“OSS 上传”这类行为收敛为显式声明且默认关闭的可选项同时提供企业版的数据驻留与删除凭证。开源项目的一个独有优势是——修复代码会直接落入 apps/zcode-cli/ 的仓库任何人都能 diff 出“上传逻辑是否真的删了”。社区实测文章已经在做的事网络抓包审计、配置审查、git diff 复核会自发地成为修复进度的第三方验证。这条路若走通风波反而会成为 ZCode 的信任背书被公开审计过的工具比从未被质疑过的工具更可靠。走向二生态分化两头撕裂。若答复模糊、修复迟缓开发者社区会迅速分化个人开发者转向更保守的用法本地模型推理、敏感项目隔离、全程断网运行企业客户转向私有化部署或竞品。社区文章中反复出现的“敏感项目隔离、本地模型替代、配置审查、网络监控”五条安全实践本质上是用户用脚投票的预案。开源生态的残酷之处在于信任一旦出现裂缝fork 和替代品会立刻出现且很难再合流。走向三监管入场合规前置。企业发函是第一步接下来可能是监管质询、行业自律公约乃至数据出境审查。一旦进入这个阶段问题就不再是“ZCode 该不该上传”而是“AI 编程工具的数据跨境与个人信息保护义务如何界定”。整个赛道——包括闭源的海外竞品——都会被拖入同一条合规标准线。这对 ZCode 未必是坏事如果它能借这次风波率先建立可审计、可删证、可驻留的合规体系反而可能在企业市场拿到先发优势。结语回到最初的问题智谱要过哪几关数据流向关、留存删除关、遥测边界关以及最难的信任重建关。ZCode 的开源身份是它最大的资产也是这场风波里唯一的“免死金牌”——因为一切质疑都可以被源码证伪或证实。12 项答复能否从“公关话术”走向“工程事实”将直接决定这个用户刚破百万的国产 AI 编程工作台是把危机变成教科书式的信任重建案例还是成为开源生态又一个“技术很强、但不敢再用”的教训。对开发者而言这场风波真正的价值或许在于在把代码交给任何 AI 工具之前先学会读它的权限配置、看它的网络请求、查它的数据留存。开源给了这把尺子剩下的是每个使用者自己的功课。【免费下载链接】ZCodeZCode 是 AI 编程工作台提供桌面应用、浏览器界面和终端 Agent。本仓库包含客户端、后端服务、共享 UI以及 Agent CLI 与运行时源码。项目地址: https://gitcode.com/zai-org/ZCode创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考