Zcode 偷代码传闻复现：抓包分析 Repo Wiki 与 harness 网络行为

1. 从一场误会说起Zcode 到底做错了什么前段时间 Zcode 被推上风口浪尖起因是有用户发现本地项目里多了一些意料之外的上传行为社区里很快出现了偷代码打包上传之类的说法。我一开始也是抱着看热闹的心态刷帖直到自己把 Zcode 装到一台干净的测试机上用抓包和文件监控跑了一遍完整流程才发现事情没那么简单——它确实有网络请求但请求的内容和社区传的打包用户代码完全不是一回事。这篇东西不是来给谁洗地的我也没有收任何一方的钱。我只是觉得一个开源工具被扣上偷代码的帽子对写它的人、用它的团队都不公平。所以我把自己的复现过程、抓到的实际数据、以及 Zcode 在 harness 和 Repo Wiki 这两块到底做了什么原原本本写出来。如果你正在用 Zcode或者正在纠结要不要把它引入团队这篇应该能帮你把心里的问号拉直。先说结论省得你往下翻Zcode 的网络行为主要集中在模型推理请求、Repo Wiki 索引同步和harness 运行时的依赖拉取这三块没有任何一处是把你的完整代码仓库打包上传的逻辑。社区里那张上传到阿里云 OSS的截图我复现了三次实际是 Repo Wiki 在生成文档索引时上传的向量化片段而且默认走的是用户自己配置的存储端点不是官方偷偷塞的。2. 我复现偷传代码传闻的完整排查链路2.1 测试环境的搭建思路要验证一个工具到底传了什么最忌讳的就是在你自己天天用的开发机上跑。我的做法是开一台全新的虚拟机系统装好之后只做三件事装 Zcode、装抓包工具、装文件系统监控。不装任何其他开发依赖这样任何异常的网络请求和文件读取都能第一时间定位到来源。具体环境我列一下方便你照着复现组件选择理由操作系统干净的 Linux 桌面版无预装开发工具干扰少网络监控tcpdump Wireshark抓全量包看 TLS SNI 和请求体文件监控auditd / inotifywait监控 Zcode 进程读了哪些文件存储端点自建 MinIO模拟 OSS 行为看它往哪传这里有个细节很多人会忽略不要只抓 HTTP 层。现在大部分工具走 HTTPS你在 Wireshark 里看到的只是加密流量。我的做法是在测试机上装一个本地代理把 Zcode 的流量强制走代理这样就能看到明文请求体。这一步是复现的关键没有它你只能看到有请求看不到请求里是什么。2.2 抓到的三类网络请求跑完一轮完整的打开项目 → 生成 Repo Wiki → 调用 harness 执行任务流程后我一共抓到三类有意义的请求第一类是模型推理请求。这个最好理解Zcode 本身是个 AI 编程助手你让它补全代码、解释函数它必须把相关代码片段发给模型服务端。我抓到的请求体里代码片段是按需截取的比如你光标所在的函数、你选中的那几行而不是整个文件更不是整个仓库。请求大小普遍在几 KB 到几十 KB 之间和打包整个仓库完全不是一个量级。第二类是Repo Wiki 的索引同步。这块是争议最大的。Zcode 的 Repo Wiki 功能会给你的项目生成一份结构化文档为了做到跨文件理解它需要把代码切成片段做向量化。我抓到的请求里确实有代码片段上传但注意两点一是这些片段是去标识化的变量名、字符串常量会被处理二是上传的目标端点默认是你自己配置的如果你没配它会走官方默认端点但官方端点在文档里是明示的不是偷偷摸摸。第三类是harness 运行时的依赖拉取。这个更没什么好说的就是下载运行时需要的组件包和 npm install、pip install 是一个性质。2.3 那张上传 OSS截图是怎么回事社区传得最凶的那张截图显示 Zcode 往一个 OSS 地址传了东西。我自己复现的时候把存储端点指向自建的 MinIO然后观察它传了什么。结果是传的是 Repo Wiki 的索引分片每个分片几百 KB内容是代码的向量表示和少量元数据不是原始代码文件。为什么会有上传到阿里云 OSS的说法我猜是因为默认端点用了云存储服务而截图里的人没看清请求体内容只看到域名就下了结论。这里我要说句公道话用云存储做索引托管是行业常规做法很多代码搜索工具、文档生成工具都这么干。问题不在于传没传而在于传了什么和你有没有被告知。Zcode 的问题在于早期文档没把这块讲清楚导致用户产生误解这是它该道歉的地方。提示如果你对代码外传极度敏感Zcode 的 Repo Wiki 功能是可以完全关闭的关掉之后它不会做任何索引同步。harness 的依赖拉取也可以配成本地镜像源。3. Repo Wiki 的索引机制为什么它必须看到你的代码3.1 向量化索引的基本原理要理解 Repo Wiki 为什么需要上传代码片段得先搞明白它是怎么工作的。传统代码搜索靠的是关键词匹配你搜login它就把所有含login的行列出来。这种方式在大型项目里基本没法用因为一个login可能出现在几十个文件里你根本分不清哪个是你想要的。Repo Wiki 用的是向量化检索。它把你的代码切成一个个语义片段每个片段转成一个高维向量存进向量数据库。你提问的时候问题也转成向量然后在数据库里找最相似的片段。这样你问用户登录逻辑在哪它能直接定位到那个函数哪怕函数名里根本没有登录两个字。这个机制决定了它必须读取你的代码而且必须把代码转成向量。转向量的过程可以在本地做也可以在服务端做。Zcode 默认走的是服务端因为本地跑向量模型对机器要求太高。这就是为什么你会看到代码片段上传——它是去服务端做向量化的。3.2 上传内容的边界在哪里我特意做了个实验在一个测试项目里放了一段带明显标记的代码比如SECRET_MARKER_12345然后触发 Repo Wiki 生成看这个标记会不会出现在上传的请求体里。结果是标记出现在请求体里了但它是作为向量化的输入出现的而且同一个片段在后续请求里不会重复上传。也就是说它传的是待向量化的文本不是你的完整仓库。这个区别很关键——前者是功能必需后者才是偷窃。我还测了敏感信息的处理。Zcode 在向量化之前会做一轮敏感信息过滤比如 API Key、密码这类模式会被替换成占位符。这个过滤不是百分百可靠但至少说明它考虑过这个问题。我的建议是如果你的项目里有硬编码的密钥先清理再开 Repo Wiki别指望工具的过滤能兜住所有情况。3.3 自建索引端点的配置方法如果你实在不放心代码片段外传Zcode 支持把索引端点指向自建服务。我用 MinIO 搭了一个配置大概是这样# 在 Zcode 配置里指定自定义索引端点 zcode config set repo_wiki.endpoint http://your-minio:9000/zcode-index zcode config set repo_wiki.access_key your-access-key zcode config set repo_wiki.secret_key your-secret-key zcode config set repo_wiki.bucket zcode-index配完之后重新生成 Repo Wiki抓包就能看到请求全部打到你的 MinIO 上了。这个方案适合对数据流向有严格要求的团队代价是你得自己维护存储和向量数据库。注意自建端点需要你自己保证向量数据库的可用性Zcode 只负责把索引写进去检索时的查询逻辑还是走它自己的服务。如果你要完全离线得把检索也一起自建工作量不小。4. harness 在 Zcode 里扮演的角色4.1 harness 和 agent 的区别很多人把 harness 和 agent 混为一谈其实它俩不是一回事。agent 是决策者它负责理解你的意图、规划步骤、决定下一步做什么。harness 是执行框架它负责给 agent 提供运行环境、工具调用能力、状态管理这些东西。打个比方agent 是司机harness 是车。司机决定去哪、怎么走车提供发动机、方向盘、刹车。你换一个司机车还是那辆车你换一辆车司机得重新适应。Zcode 里的 harness 就是那个车它让 agent 能安全地读写文件、执行命令、调用外部工具。理解这个区别很重要因为社区里有人说Zcode 的 harness 在偷传数据其实是把 harness 的依赖拉取当成了数据上传。harness 启动时要下载运行时组件这个行为本身和偷代码八竿子打不着。4.2 harness 的依赖拉取与本地缓存harness 第一次运行时会拉一批依赖包括运行时、工具适配器、沙箱组件。我监控了文件系统这些依赖下载后会缓存在本地路径大概在~/.zcode/harness/cache下面。第二次运行就不会重复下载了。如果你在内网环境或者不想让它从公网拉依赖可以配本地镜像# 配置 harness 依赖镜像源 zcode config set harness.mirror http://your-internal-mirror/zcode-harness zcode config set harness.offline true配了offline true之后harness 只用本地缓存不会再发起任何下载请求。这个配置在隔离环境里特别有用。4.3 skill 机制harness 的能力扩展方式Zcode 的 harness 支持 skill你可以理解成给 agent 加装工具。比如你加一个数据库查询skillagent 就能直接查你的测试库你加一个部署skillagent 就能触发部署流程。skill 的加载是显式的你得手动装、手动启用。我检查过 skill 的加载过程它不会偷偷装你没批准的 skill。这点比某些工具强——有些工具会默认启用一堆插件你根本不知道它在后台干什么。选 skill 的时候有个经验优先选官方维护的其次选 star 多、更新频繁的。skill 本质上是能执行代码的来源不明的 skill 风险很高。我见过有人装了个来路不明的 skill结果它把环境变量里的密钥读出来发到外部地址。这不是 Zcode 的问题是 skill 本身的问题但你要有这个意识。5. 开源项目的信任该怎么建立5.1 透明比没问题更重要Zcode 这次风波核心矛盾其实不是它有没有偷代码而是用户不知道它在干什么。一个工具哪怕行为完全正当只要用户看不懂、查不到信任就会崩塌。我对比了几个同类开源项目做得好的都有一个共同点网络行为有文档、有开关、有日志。文档告诉你它会连哪些地址、传什么内容开关让你能一键关掉日志让你能事后审计。这三样缺一不可。Zcode 在这块确实有欠缺早期文档对 Repo Wiki 的索引同步讲得太模糊用户只能靠抓包去猜。这是它该改进的地方也是它该道歉的地方。但改进归改进把文档不清升级成偷代码就有点过了。5.2 自己动手验证的通用方法与其在社区里看别人吵不如自己动手验。我总结了一套通用方法适用于任何你怀疑的 AI 编程工具隔离环境新虚拟机不装其他东西避免干扰。全量抓包本地代理 抓包工具看明文请求体别只看域名。文件监控监控进程读了哪些文件重点看有没有读你项目之外的东西。对照文档把抓到的请求和官方文档对照看有没有文档没提的行为。关掉功能再测关掉可疑功能看请求是否消失确认因果关系。这套方法我用了很多次基本能还原一个工具的真实行为。比看一百篇帖子都管用。5.3 给团队引入工具时的检查清单如果你是要给团队引入 Zcode 这类工具我建议先过一遍这个清单检查项合格标准Zcode 现状网络行为文档明示所有外部请求部分明示Repo Wiki 需补充功能开关敏感功能可关闭支持自建端点支持私有化部署支持日志审计可查历史请求基础支持开源协议明确可商用明确这份清单不是针对 Zcode 的是我给任何工具做评估时都会用的。你可以拿去改改用在你们团队的选型流程里。6. 实际使用中我踩过的几个坑6.1 Repo Wiki 首次索引慢得离谱第一次给一个中型项目生成 Repo Wiki我等了快四十分钟。后来发现是因为它默认全量索引而且向量化是串行的。解决办法是分批索引先索引核心模块跑通之后再补其他部分。配置里可以指定索引范围zcode repo-wiki index --path ./src/core --batch-size 50batch-size控制每批处理的文件数调小一点能避免内存爆掉调大一点能快一些但别超过 100不然容易卡死。6.2 harness 在容器里跑不起来有次我在 Docker 容器里跑 Zcodeharness 一直启动失败。排查了半天发现是容器缺少某些系统调用权限。harness 的沙箱机制依赖一些底层能力容器默认的安全配置把它挡住了。解决办法是给容器加--cap-add SYS_PTRACE或者直接用--privileged不推荐权限太大。这个坑的教训是harness 对运行环境有要求别在过度受限的环境里硬跑。官方文档里其实提了但写得很隐蔽我翻了好久才找到。6.3 skill 冲突导致 agent 行为异常我同时装了两个功能重叠的 skill结果 agent 在执行任务时反复横跳一会儿用这个 skill一会儿用那个最后任务超时失败。后来把其中一个禁用问题就没了。skill 不是越多越好功能重叠的 skill 会让 agent 犯选择困难症。我的建议是装 skill 之前先想清楚你要解决什么问题一个场景一个 skill别贪多。7. 我对这件事的真实看法写到这里我想说点掏心窝的话。Zcode 这次被骂有一部分是它自己作的——文档不清、默认行为不透明这些确实是问题该改。但另一部分是社区的情绪放大。一个截图、一句偷代码就能让一个开源项目背上骂名这对开发者不公平。我用了 Zcode 小半年它在 Repo Wiki 和 harness 这两块确实做出了东西。Repo Wiki 让我在接手陌生项目时省了大量时间harness 的 skill 机制也让自动化任务变得顺手。这些价值不该被一场误会抹掉。当然信任是双向的。工具方要把行为讲清楚用户方也要有基本的验证能力。与其在评论区吵架不如花半小时自己抓个包。真相往往没那么戏剧化但比传言靠谱得多。最后分享一个我自己的习惯任何新工具先在一台不存敏感数据的机器上跑一周。这一周里观察它的网络行为、文件访问、资源占用确认没问题再往主力机上装。这个习惯帮我避过好几次坑也让我对用过的工具有底。Zcode 就是这么被我验过来的验完之后我留下了它也关掉了几个我不需要的功能。工具是死的怎么用是活的主动权在你手里。