1. 那场风波到底怎么回事先把时间线捋清楚。Zcode 这个工具刚在圈子里传开的时候口碑是相当不错的——一个面向开发者的 AI 编程助手能接各种模型能跑 agent 任务安装也不算复杂。我自己大概是在它热度起来后没多久就装上了当时主要看中它支持多模型切换还有一套看起来挺完整的 skill 机制。然后事情就变了。有人在社区里发帖说抓包发现 Zcode 在运行过程中有向阿里云 OSS 上传数据的请求帖子标题起得很吓人大意是你的代码正在被偷偷传走。这个帖子传播速度极快因为戳中了所有开发者最敏感的那根神经——代码是我的命根子你一个工具凭什么动我的东西紧接着各种衍生说法都出来了有人说打包上传的是用户完整代码有人说是对话记录有人说是配置文件。版本越传越离谱甚至出现了Zcode 偷代码这种直接定性式的说法。那段时间只要在群里提 Zcode基本就是两派吵起来一派说实锤了别用一派说你倒是把抓包证据放全啊。我当时的反应比较冷静原因很简单我自己也在用而且我习惯在隔离环境里跑这类工具如果真有大规模上传行为我这边应该能观察到异常流量。但我没有立刻站出来说话因为我不确定自己看到的就是全部真相。后来事情慢慢有了反转。有技术能力比较强的用户开始做更细致的分析把请求的完整链路、上传内容的实际结构、触发条件都拆开来看。结论逐渐清晰那些 OSS 请求确实存在但上传的不是用户代码而是匿名化的运行日志和崩溃诊断信息而且这个行为在配置里是可以关掉的。更关键的是它的用途是帮助定位 agent 执行失败的问题——也就是那个让很多人头疼的 agent execution terminated due to error 场景。所以标题里那句来给 Zcode 道歉了说的就是这件事。当初骂得最凶的那批人里有一部分在看完完整分析后回过头来承认自己判断下早了。我写这篇东西不是要替谁洗地而是想把这件事里真正值得学的东西讲清楚一个开源工具的数据行为该怎么看OSS 上传到底意味着什么以及为什么抓到一个请求和证明偷代码之间隔着十万八千里。这篇适合几类人看正在用或打算用 Zcode 的开发者、对 agent 框架和 harness 机制感兴趣的人、以及任何关心我本地跑的工具到底往外发了什么的谨慎派。如果你只是想找个结论站队那可能会失望因为我更想给你的是判断方法而不是一个简单的好或坏。2. 把 OSS 上传这件事拆到骨头里2.1 为什么有上传不等于偷代码这是整件事里最核心的认知误区值得单独拎出来讲。普通用户看到抓包工具里出现一个指向*.aliyuncs.com或者 OSS 域名的请求第一反应就是我的数据被传走了。这个反应可以理解但技术上不成立。一个 HTTP 请求能携带的信息量取决于它的 body 结构而不是它的目标域名。目标域名只能告诉你数据发往了哪个存储服务不能告诉你发了什么。打个比方你看到一辆快递车从你家小区开出去你不能因此断定它拉走了你家的家具。你得看它装的是什么、谁下的单、有没有你的签字。抓包也是一样域名是车牌body 才是货物。在 Zcode 这个案例里真正需要看的是三样东西请求的触发时机是每次启动都发还是只在特定错误发生后发body 的实际内容是代码文本还是结构化的日志字段配置项这个行为能不能关默认开还是默认关我自己的排查习惯是遇到这类质疑先不急着下结论而是把这三样东西逐一确认。当时我看到的请求触发时机集中在 agent 任务异常终止之后body 里是错误堆栈、执行阶段标识、耗时统计这类字段没有出现我项目里的源码片段。这跟偷代码的描述对不上。2.2 OSS 在这套架构里扮演什么角色很多人对 OSS 的理解停留在网盘层面觉得往 OSS 传东西就是上传用户文件。实际上在工程架构里OSS 更常见的角色是低成本、高可用的日志与诊断数据落地点。为什么是 OSS 而不是自建服务器这里有几个很实际的工程考量考量维度自建日志服务对象存储OSS 类突发流量承载需要预估容量容易被打爆弹性扩容几乎无上限存储成本服务器磁盘长期成本高按量计费冷数据极便宜运维负担要自己维护、备份、扩容托管服务基本零运维数据生命周期手动清理支持自动过期策略对于一个用户量可能快速波动的开发者工具来说把诊断日志丢到对象存储是相当标准的选择。这不是 Zcode 独有的做法很多开源项目、甚至一些本地优先的工具在需要收集崩溃信息时都会走这条路。关键在于收集什么、怎么告知用户、能不能关闭而不是用了 OSS 就有问题。顺带说一句热词里出现的minio 数据迁移到 oss、阿里云 oss这些其实反映的是同一类工程需求——对象存储作为通用数据底座被大量项目当作默认的落盘方案。理解了这个背景再看 Zcode 的 OSS 请求就不会那么容易被上传两个字带偏。2.3 harness 与 agent先搞懂这对概念再谈对错要真正理解这次风波绕不开 harness 和 agent 这两个词。热词里harness和agent区别、deepseek harness、harness engineering反复出现说明很多人其实没分清。我用一个类比来说agent 是干活的工人harness 是工地的管理系统。agent 负责实际执行任务——读文件、调工具、生成代码、跑命令。它是有行动力的那部分。而 harness 负责的是给 agent 提供运行环境、管理它的生命周期、记录它每一步干了什么、在它出错时捕获现场。换句话说harness 是那层脚手架和监控系统。这个区分为什么重要因为诊断日志的上传责任在 harness 层不在 agent 层。当 agent 执行到一半崩了就是那个 agent execution terminated due to error是 harness 负责把崩溃现场记录下来用于后续分析。用户看到的上传行为本质上是 harness 的诊断机制在工作而不是 agent 在偷偷搬运你的代码。理解了这一层你就会明白为什么当初那些Zcode 偷代码的说法在技术上站不住脚——它们把 harness 的诊断行为误读成了 agent 的数据窃取行为。这是两个完全不同层面的东西。3. 我自己是怎么验证的3.1 隔离环境下的完整观察流程光讲道理没用我把自己当时的验证过程完整写出来你可以照着复现。第一步准备隔离环境。我不会在主力开发机上直接跑任何新工具做安全观察而是用一个独立的虚拟机或者容器。这样即使真有问题影响范围也可控。这一步是习惯问题跟信不信任某个工具无关。第二步准备一个诱饵项目。我建了一个小项目里面放一些特征明显的字符串比如CANARY_STRING_12345这种散落在几个源码文件里。这样如果真有代码外传我能在流量里一眼认出来。第三步挂上抓包工具。我用的是常规的代理抓包方案把所有出站请求都记录下来重点看非本地地址的请求。第四步正常使用工具触发各种场景正常对话、让它读文件、让它执行任务、故意制造一个错误让它崩。第五步分析抓到的请求。这一步是关键不能只看域名要看 body。我当时的观察结果是正常对话和读文件阶段没有异常外传只有在任务异常终止后才出现指向对象存储的请求body 里是结构化的错误信息我埋的CANARY_STRING_12345没有出现在任何请求里。3.2 怎么判断一个请求到底发了什么这里补充几个实操技巧因为很多人抓包抓到了却不会看。看 Content-Type。如果是application/json说明发的是结构化数据大概率是日志字段如果是multipart/form-data或者application/octet-stream就要警惕了可能是文件内容。看 body 大小。一个诊断日志通常几 KB 到几十 KB。如果你的项目有几百 KB 甚至几 MB 的源码被传走body 大小会明显异常。这是个很粗糙但很有效的初筛手段。看字段名。结构化日志的字段名通常很直白比如error_type、stage、duration、stack_trace。如果字段名里出现file_content、source_code、user_data这种那才需要认真对待。做对照实验。这是最有说服力的方法。用两个不同的项目跑同样的操作如果上传的 body 内容跟项目内容无关两次上传的结构相似、只是错误信息不同基本可以排除代码外传。提示抓包分析时务必确认你看到的是解密后的明文。如果流量是加密的你看到的只是密文任何内容判断都不成立。这一点经常被忽略。3.3 配置项才是你真正该关心的验证到最后我关心的其实不是它传了什么而是我能不能控制它传不传。一个负责任的开源工具应该把这类数据收集行为做成可配置、可关闭、默认透明的。Zcode 在这点上事后看是提供了关闭选项的问题在于早期的文档和提示不够醒目导致很多用户在不知情的情况下就开着。这给了我一个很重要的经验评估任何工具配置项的透明度比功能本身更能反映它的成熟度。一个把数据收集藏在深层配置里、文档里只字不提的工具比一个明确告诉你我们会收集诊断信息开关在这里的工具风险高得多。所以我现在拿到任何新工具第一件事就是翻它的配置文件和数据相关设置而不是先看功能演示。这个习惯帮我避开了不少坑。4. 从这场风波里能学到什么4.1 开源不等于你可以随便看但等于你可以验证热词里开源、开源项目、开源实现出现频率很高说明大家对开源有天然的好感。但这次事件恰恰说明开源的价值不在于它一定安全而在于你有能力去验证它安不安全。闭源工具你只能选择相信或不用。开源工具你可以去看代码、可以去抓包对照、可以自己编译一个版本来跑。Zcode 这次能反转很大程度上就是因为它是开源的有人能去读它的 harness 实现能去确认那些 OSS 请求的真实用途。但这里有个现实问题大部分用户不会去读代码。开源给了验证的可能性但没给验证的行动力。所以社区里那些愿意花时间做分析的人价值就体现出来了。这也是为什么我写这篇东西——把验证方法讲清楚让更多人具备自己判断的能力而不是等着别人给结论。4.2 舆论的传播速度和技术的验证速度不匹配这次风波里最让我感慨的是指控的传播速度远远快于验证的速度。一个Zcode 偷代码的帖子几分钟就能传遍好几个群。而一份严谨的技术分析需要抓包、读代码、做对照实验可能要花好几天。在这几天的窗口期里工具的名声已经被定性了很多人已经卸载了甚至已经去别处骂过了。这不是 Zcode 一家的问题是所有开源项目都可能面临的处境。作为用户我们能做的是在看到指控时先问一句证据是什么而不是先转发。作为项目方能做的则是把数据行为提前讲清楚别等出事了再解释。4.3 一个工具的数据行为该怎么评估我把这次的经验整理成一个评估清单你可以拿去套用任何工具评估项健康的表现需要警惕的表现数据收集告知文档明确说明收集什么文档只字不提开关控制提供关闭选项无法关闭默认状态默认关闭或明确提示默认开启且无提示收集内容匿名化日志、崩溃信息源码、文件内容传输目标明确的服务地址混淆的域名开源程度相关代码可查核心逻辑闭源这张表不是绝对的但能帮你快速筛掉明显有问题的工具。Zcode 对照下来主要问题出在告知和默认状态上而不是收集内容上——这也是为什么它值得一个道歉因为最初的指控方向就错了。5. 实操把 Zcode 用得更放心5.1 安装与初始配置的注意事项热词里zcode安装、zcode使用教程、zcode注册账号这些搜索量不小说明很多人还在入门阶段。我把几个关键点讲一下。安装本身没什么特别的按官方文档走就行。真正需要注意的是首次启动后的配置环节。这时候你要做几件事第一找到数据与隐私相关的设置项确认诊断信息收集的状态。如果你在意直接关掉。关掉之后功能不受影响只是崩溃时项目方拿不到你的诊断数据出问题需要你自己排查。第二确认模型接入方式。Zcode 支持接多种模型包括本地的比如通过 ollama 这类方案。如果你对数据外传极度敏感可以考虑接本地模型这样连对话内容都不出你的机器。第三检查 skill 的加载情况。热词里zcode添加什么skill好是个高频问题。我的建议是按需加载不要一上来全开。skill 越多agent 的行为越复杂出问题的概率也越高。先从核心的几个开始用顺了再加。5.2 skill 机制怎么用才不踩坑skill 是 Zcode 比较有特色的部分但也是最容易出问题的地方。我的经验是skill 本质上是在给 agent 扩展能力边界。每加一个 skillagent 就多了一种能做的事。这带来便利的同时也带来了不确定性——你不知道它在什么情况下会调用哪个 skill也不知道调用失败时会怎么处理。所以我的做法是一次只加一个 skill加完观察一段时间记录每个 skill 的触发场景搞清楚它什么时候会被调用遇到 agent 执行异常先怀疑最近新加的 skill定期清理不用的 skill保持环境干净这套方法听起来笨但能帮你把问题定位范围缩到最小。我见过太多人一次性装一堆 skill然后 agent 行为诡异根本不知道是哪个引起的。5.3 遇到 agent 执行失败怎么排查agent execution terminated due to error 这个报错是热词里出现频率最高的技术问题之一。我讲讲我的排查思路。首先看错误发生的阶段。agent 执行通常分几个阶段理解任务、规划步骤、调用工具、生成结果。错误发生在哪个阶段排查方向完全不同。理解阶段出错多半是模型或提示词问题工具调用阶段出错多半是 skill 或环境问题。其次看是不是可复现。偶发错误和稳定错误处理方式不一样。偶发的可能是网络或资源问题稳定的基本是配置或代码问题。第三缩小输入范围。把任务拆小看在哪一步崩。这一步很关键因为 agent 任务往往很复杂直接看整体很难定位。第四检查环境依赖。很多 agent 失败是因为它要调用的工具在环境里不存在或者权限不够。这类问题日志里通常有线索。注意如果你关掉了诊断上传出问题时就没有项目方的数据辅助了排查全靠自己。这是关闭数据收集的代价要提前想清楚。6. 关于道歉这件事本身6.1 为什么值得道歉以及道歉的边界标题说来给 Zcode 道歉了我觉得这个道歉是有道理的但要说清楚道歉的边界。值得道歉的部分是当初的指控在方向上错了。把 harness 的诊断日志上传说成偷代码这是性质完全不同的两件事。前者是工程上常见的做法虽然告知做得不够好后者是严重的信任背叛。用后者去指控前者对项目方是不公平的。但道歉不等于说 Zcode 完全没问题。它在告知透明度和默认配置上确实有改进空间。一个工具收集任何数据都应该在用户第一次使用时明确告知而不是等出事了再解释。这部分批评是合理的不需要道歉。所以我的态度是为错误的指控道歉但不为合理的批评道歉。这两者要分开不能因为反转了就一股脑说Zcode 全对当初骂的人全错。技术讨论最怕的就是从一个极端跳到另一个极端。6.2 对开源项目的一点个人看法这件事让我对开源项目的处境有了更深的体会。开源项目方往往是一群人在用爱发电功能做得好是应该的一旦有任何数据行为被误解就可能面临铺天盖地的指责。而解释的成本极高因为技术分析的门槛摆在那里大部分人看不懂也不愿意看。我不是说开源项目就该被无条件信任。恰恰相反该验证的还是要验证该质疑的还是要质疑。但质疑的方式很重要——基于证据的质疑能推动项目改进基于情绪的指控只会伤害社区。我自己的做法是遇到类似事件先不下结论等有技术分析出来再说。如果实在等不及就自己动手验证。这个过程可能慢但比跟着舆论跑要靠谱得多。6.3 后续可以关注的方向如果你对这类话题感兴趣有几个方向值得持续关注。一是数据收集的行业规范。目前开发者工具在这块还没有统一标准各家做法差异很大。未来如果有更明确的规范用户判断起来会容易很多。二是harness 工程本身的发展。热词里harness engineering、harness anything这些说明这个方向正在被重视。harness 作为 agent 的运行底座它的设计质量直接决定了 agent 的可靠性和可观测性。这块值得深入。三是本地优先的工具方案。如果你对数据外传极度敏感可以关注那些支持完全本地运行的工具组合比如接本地模型的方案。虽然能力上可能有折扣但数据完全不出机器心理负担小很多。我在实际使用中的体会是工具没有绝对的安全或不安全只有透明不透明和可控不可控。一个把数据行为讲清楚、把控制权交给用户的工具哪怕它收集了一些信息也比一个什么都不说、用户无法干预的工具更值得信任。Zcode 这次的问题本质上是透明度的问题而不是善恶的问题。想清楚这一点很多争论其实就没必要了。