ZCode更新后数据上传行为实测：AI编码Agent的代码安全与隐私控制

1. 从"偷偷上传"风波说起：ZCode这次更新到底改了什么

ZCode 19号这波更新，圈子里讨论度最高的不是新功能，而是那个被念叨了很久的"偷偷上传"问题。官方更新日志里写的是"已修复"，但作为一个从早期版本一路用过来的老用户，我对这种一句话带过的修复说明向来是持保留态度的——修复到什么程度、是彻底堵死还是只做了表面文章、有没有引入新的副作用，这些都得自己上手验证一遍才踏实。

先把背景交代清楚。ZCode 是智谱推出的一款 CLI 形态的编码 Agent 工具，定位跟 Claude Code、Cursor 的 Agent 模式属于同一赛道，核心能力是让模型直接在你的本地项目里读写文件、执行命令、跑 git 操作。它接入的是 GLM 系列模型，最近讨论比较多的是 GLM5.3 这个版本。所谓"偷偷上传"，指的是早期版本里，工具在用户没有明确感知的情况下，把项目里的部分文件内容、代码片段甚至 git 仓库信息传到了远端服务。这件事在开发者社区里炸过一次锅，因为对于很多在公司内网、私有仓库里干活的人来说，代码外传是红线问题。

这次 19 号更新，官方口径是修复了。但"修复"这个词太模糊了。我关心的具体问题是：哪些数据还会上传、哪些不上传了、上传前有没有明确的用户确认、日志里能不能看到上传行为、能不能完全关掉。这几个问题不搞清楚，光看一句"已修复"是没法放心用的。

这篇文章我打算把这次更新拆开揉碎讲一遍。适合两类人看：一类是正在用或者打算用 ZCode 做日常开发的，另一类是对 AI Agent 工具的数据流向比较敏感、想搞清楚这类工具到底在你机器上干了什么的。我会从这次更新的实际改动讲起，然后聊怎么验证上传行为、怎么配置才能把风险控制住，最后说说这类 CLI Agent 工具在数据安全上的通用思路——毕竟今天讨论的是 ZCode，明天可能是别的工具，方法论是通用的。

需要提前说明的是，我手上没有官方的内部文档，下面涉及具体行为的部分，一部分来自我自己的实测抓包和日志观察，一部分来自社区里其他用户的反馈汇总。凡是推测的地方我都会标出来，你自己用的时候还是要以实际观察为准。

2. 这次更新里跟数据流向相关的几处实际改动

2.1 上传行为从"默认静默"变成了"需要确认"

这是这次更新里最核心的一处变化。早期版本的逻辑是，当 Agent 需要理解你的项目上下文时，它会自动扫描工作目录，把相关文件内容打包发给模型服务端，整个过程用户端只有一个模糊的"正在思考"提示，看不到具体传了什么。19号版本之后，至少在几个关键节点上，行为变成了需要用户显式确认。

具体来说，我实测下来观察到这么几个变化点。第一，首次在一个新目录里启动 ZCode 时，它会弹出一个上下文范围的确认提示，告诉你它打算读取哪些路径下的文件。第二，当 Agent 判断需要读取工作目录之外的文件时，会单独再问一次。第三，涉及 git 操作的时候，比如它要读取 commit 历史或者 diff 内容，也会有提示。

不过这里有个坑要注意：确认提示不等于每次传输都确认。它更像是"授权范围"的确认，一旦你同意了某个目录，后续在这个目录内的读取就不会每次都问了。所以如果你在一个包含敏感配置的目录里工作，第一次的授权范围一定要看清楚。

2.2 本地日志里现在能看到上下文组装记录

第二个变化是日志。以前你想知道它到底传了什么，基本只能靠抓包，门槛不低。现在 ZCode 在本地会记录上下文组装的日志，你能看到它这次请求里包含了哪些文件、大概多大的内容。

日志的位置一般在用户目录下的配置文件夹里，不同系统路径不一样。Windows 上通常在%USERPROFILE%\.zcode\logs这类位置，macOS 和 Linux 在~/.zcode/logs附近。日志是分日期滚动的，找当天的那个文件就行。

我建议你第一次用的时候，专门开一个测试项目，放几个特征明显的文件进去，然后跑一次 Agent 任务，再去翻日志，看看它到底读了哪些、传了哪些。这个动作花不了十分钟，但能让你对工具的行为有个直观认识，比看任何说明文档都管用。

2.3 新增了上下文排除配置

第三个变化是配置层面。现在支持通过配置文件排除特定路径或文件类型，被排除的内容不会被纳入上下文。这个功能对于有敏感文件的仓库特别有用，比如你项目里有.env、密钥文件、内部文档目录，都可以配进去。

配置的写法大致是在项目根目录或者用户配置目录下放一个忽略规则文件，语法类似.gitignore。我实测下来，它对常见的通配符支持是OK的，*.key、secrets/、config/local.*这类写法都能生效。

注意：排除配置生效的前提是 Agent 走的是标准的上下文组装流程。如果某个操作是直接执行命令然后把输出回传（比如它跑了一个cat命令），那排除规则不一定拦得住。这一点后面会细说。

2.4 关于"已修复"这三个字的理性看待

官方说修复了，我的判断是：主要的高风险静默上传路径确实被堵上了，但"修复"不等于"零上传"。任何云端模型驱动的 Agent 工具，只要它需要模型来理解你的代码，就必然要把一部分内容发到服务端。这是这类工具的工作原理决定的，不是 bug。

所以正确的期待不是"它再也不传数据了"，而是"它传什么我能知道、能控制、能审计"。这次更新在这三点上确实有进步，但离"完全透明可控"还有距离。下面几节我会讲怎么自己动手把可控性拉满。

3. 自己动手验证：三步确认你的代码有没有被传出去

光听我说没用，你得自己验证。这一节我给出一个可复现的验证流程，不需要多高深的技术背景，会看日志、会用基本的网络工具就行。

3.1 第一步：用特征文件做标记测试

准备一个干净的测试目录，创建几个内容独特的文件。比如建一个canary.txt，里面写一段独一无二的字符串，像ZCODE_CANARY_20240619_ABCDEF这种，确保这个字符串在别的地方绝对搜不到。

然后在这个目录里启动 ZCode，让它做一个需要读取文件的任务，比如"总结一下这个目录里所有文件的内容"。任务跑完后，去翻本地日志，看canary.txt有没有出现在上下文记录里。如果出现了，说明它确实读了这个文件并准备发送。

这一步能帮你确认"读取范围"是否符合你的预期。如果连你不想让它读的文件都进去了，那排除配置就没配对。

3.2 第二步：观察网络请求的目标和内容

这一步稍微技术一点，但也不难。核心思路是看 ZCode 进程往外发的请求都去了哪里、带了什么。

在 macOS 和 Linux 上，可以用系统自带的网络监控工具，或者用tcpdump抓一下特定进程的流量。Windows 上可以用资源监视器看网络活动，或者用 Wireshark 这类工具。如果你只是想看请求的目标域名和大致频率，资源监视器其实就够了。

重点观察两件事：一是请求的目标是不是只有官方的 API 域名，有没有意料之外的第三方地址；二是请求的频率和体积，是不是跟你实际的操作量匹配。如果只是问了个简单问题，却看到大量数据外发，那就值得警惕了。

需要说明的是，现在的 API 通信基本都是加密的，你抓包看到的是密文，看不到具体内容。所以这一步主要验证的是"流向"和"体量"，内容层面的验证要靠第一步的日志。

3.3 第三步：对比排除配置前后的差异

第三步是验证你的排除配置到底有没有用。还是用第一步的测试目录，这次在配置里把canary.txt排除掉，然后跑同样的任务，再看日志。

如果配置生效，日志里就不应该再出现这个文件。如果还出现，说明要么配置路径写错了，要么这个文件的读取走了不走排除规则的路径。后者是更麻烦的情况，需要你进一步定位是哪个操作触发的。

我把这三步整理成一个对照表，方便你操作时参考：

这三步做完，你对这个工具在你机器上的行为就有了第一手的认识。别嫌麻烦，涉及代码安全的事，花这点时间值得。

4. 把可控性拉满：ZCode 的配置与使用习惯建议

验证完之后，接下来是日常使用中怎么把风险控制住。这一节讲的是习惯和配置层面的东西，都是我自己踩过坑之后总结出来的。

4.1 工作目录的隔离原则

最重要的一条：不要让 ZCode 在你存放敏感信息的目录里裸奔。我的做法是给每个项目单独开工作目录，敏感配置、密钥、内部文档这些不放在 Agent 的工作范围内。

具体操作上，我会把项目结构做成两层：外层是 Agent 能看到的代码目录，内层是敏感配置目录，通过环境变量或者本地配置文件引用。这样即使 Agent 扫描了整个工作目录，也扫不到真正的敏感内容。

对于必须放在一起的情况，就用上一节说的排除配置兜底。但我的经验是，排除配置是第二道防线，目录隔离才是第一道。别把宝全押在配置上，配置总有写漏的时候。

4.2 git 相关操作的注意事项

ZCode 这类工具跟 git 的交互很频繁，因为它需要理解代码变更历史。这里有几个点要注意。

第一，它读取 git 历史的时候，会把 commit message、diff 内容纳入上下文。如果你的 commit message 里写了敏感信息（比如内部系统地址、账号），这些也会被带出去。养成写 commit message 时不放敏感信息的习惯。

第二，涉及git commit --amend这类会改写历史的操作时，Agent 有时候会自作主张。我建议把这类操作设成需要确认，别让它自动执行。改写历史在团队协作里是高风险动作，让 AI 自动做容易出事。

第三，如果你用的是 Gitee 或者自建的 git 服务，配置密钥的时候注意别把私钥文件放在工作目录里。密钥文件应该放在用户目录下的.ssh里，并且确保它不在 Agent 的扫描范围内。

4.3 什么时候该关掉 Agent 的自动执行

ZCode 有个能力是自动执行命令，比如跑测试、装依赖、启动服务。这个能力很方便，但在几种情况下我建议关掉或者设成手动确认。

一种是在生产环境相关的目录里。哪怕只是读操作，自动执行也可能触发意料之外的副作用。另一种是在你不熟悉的项目里，第一次跑的时候让每一步都确认，看清楚它想干什么再放行。还有一种是在网络环境敏感的时候，比如你在公司内网，自动执行可能会触发一些内网服务的访问，这些访问会被记录，可能引起不必要的麻烦。

配置上，一般是在设置里把自动执行关掉，或者设成"每次确认"。具体选项名称各版本可能不一样，你找跟"自动执行""auto execute""确认模式"相关的设置就行。

4.4 定期审计日志的习惯

最后一条是习惯层面的：定期翻日志。不用天天看，但每周花个十分钟扫一眼，看看有没有异常的读取行为。

重点看两类记录：一类是读取了你没预期它会读的路径，另一类是请求频率异常高的时候。前者可能是配置漏了，后者可能是某个任务触发了大量的上下文组装，值得查一下原因。

日志这东西，平时看着烦，真出问题的时候就是唯一的线索。养成看的习惯，比出事之后再去找强得多。

5. 从 ZCode 看 AI Agent 工具的数据边界问题

聊完具体的，往上抽一层，说说这类工具的通病。ZCode 不是个例，所有云端模型驱动的编码 Agent 都面临同样的问题，理解了这个共性问题，你换任何工具都能心里有数。

5.1 Agent 工具为什么天然要读你的代码

这个问题的答案其实很直接：Agent 要帮你改代码，它就得先看懂代码。而看懂代码这件事，目前主流方案是把代码发给大模型去理解。模型不在你本地，在服务端，所以数据必然要出你的机器。

这跟传统的本地 IDE 插件有本质区别。传统插件比如语法高亮、代码补全，很多是在本地算的，不联网也能用。但 Agent 的"理解"和"决策"能力来自大模型，这个能力没法完全本地化（至少目前消费级硬件上跑不动同等水平的模型）。

所以对这类工具，正确的期待是"可控的上传"，而不是"零上传"。任何宣称完全不上传又能提供同等智能的工具，你都要多留个心眼，要么是能力打了折扣，要么是宣传有水分。

5.2 本地模型是不是解法

有人会说，那我用本地部署的模型不就行了。这个思路方向是对的，GLM5.3 这类模型确实有本地部署的方案，社区里也有在特定硬件上部署的讨论。但现实是，本地部署的门槛不低。

硬件上，要跑得动有实用价值的模型，对显存的要求很高，普通开发机基本没戏。部署和维护上，也不是装个软件那么简单，涉及环境配置、模型量化、推理优化一堆事。对于个人开发者，除非你有明确的合规要求或者特别在意隐私，否则本地部署的性价比要打个问号。

我的看法是，本地部署适合两类场景：一是数据敏感度极高、绝对不能外传的，二是你有现成的硬件资源并且愿意折腾。普通日常开发，还是用云端服务加严格的数据管控更实际。

5.3 判断一个 Agent 工具数据行为是否可信的几个信号

最后给几个判断标准，你评估任何一款 Agent 工具都能用。

看它有没有明确的上下文范围提示。好的工具会告诉你它打算读哪些文件，而不是闷头就扫。看它有没有本地日志。能让你审计的工具，至少说明它不怕你看。看它有没有排除配置。这是给用户控制权的基本功能。看它的更新日志里有没有把数据行为的变化写清楚。如果每次更新对数据流向的变化都含糊其辞，那就要警惕。

反过来，如果一个工具对这些问题的回应是"你不用担心""我们很安全"这种空话，而不给具体的技术说明和用户控制手段，那不管它功能多强，我都会谨慎使用。

6. 几个实际使用中的小技巧和踩坑记录

这一节零散记录一些实操中的细节，都是我自己或者社区里朋友遇到的，不成体系但实用。

关于 Windows 上的使用，ZCode 的 CLI 在 Windows Terminal 里跑体验比在老的 cmd 里好很多，尤其是涉及中文路径和彩色输出的时候。如果你在 Windows 上遇到奇怪的编码问题，先换到 Windows Terminal 试试。

关于 git 配置，如果你用 Gitee，配置密钥的时候注意 SSH 和 HTTPS 两种方式的区别。Agent 执行 git 操作时用的是你本地配置的凭据，所以确保你的凭据配置是对的，不然会出现 Agent 说操作成功但实际没推上去的情况。

关于日志排查，如果你发现日志里出现了乱码或者截断，可能是编码问题。日志文件一般用 UTF-8，用支持 UTF-8 的编辑器打开，别用系统默认的记事本，容易出问题。

关于上下文大小，Agent 每次请求能带的上下文是有限的。项目大的时候，它不会把所有文件都带上，而是根据相关性挑选。所以有时候你会发现它"忘了"某个文件的内容，不一定是 bug，可能是上下文预算不够。这种情况可以手动把关键文件指给它。

关于更新后的行为变化，每次更新之后，建议你重新跑一遍第3节说的验证流程。工具行为可能随版本变化，上次验证过不代表这次还一样。养成更新后复查的习惯。

最后说个心态上的事。用这类工具，安全和效率是要权衡的。你把管控设得越严，用起来越麻烦，Agent 能帮你做的事越少。反过来，放得越开，效率越高，风险越大。没有标准答案，取决于你的项目性质和个人接受度。我的建议是，先按最严的来，用一段时间觉得哪里太碍事了再逐步放开，而不是一上来就全开然后提心吊胆。这个度，得你自己找。