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排除掉然后跑同样的任务再看日志。如果配置生效日志里就不应该再出现这个文件。如果还出现说明要么配置路径写错了要么这个文件的读取走了不走排除规则的路径。后者是更麻烦的情况需要你进一步定位是哪个操作触发的。我把这三步整理成一个对照表方便你操作时参考验证步骤观察对象预期结果异常信号特征文件测试本地上下文日志只包含授权范围内的文件出现未授权文件网络流向观察进程网络请求仅官方 API 域名出现陌生第三方地址排除配置验证日志中的文件列表被排除文件不出现排除文件仍被读取这三步做完你对这个工具在你机器上的行为就有了第一手的认识。别嫌麻烦涉及代码安全的事花这点时间值得。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 能帮你做的事越少。反过来放得越开效率越高风险越大。没有标准答案取决于你的项目性质和个人接受度。我的建议是先按最严的来用一段时间觉得哪里太碍事了再逐步放开而不是一上来就全开然后提心吊胆。这个度得你自己找。
