过去这几天，AI 辅助编程圈子里接连冒出来三件事。智谱旗下的桌面编程软件在后台悄悄扫描本地代码与完整版本控制历史，打包加密后排着队想往云端存储送；另一边，一项独立评测在固定底层大模型的前提下，单独调换外层执行框架，测出了相差一倍的账单支出；微软技术团队也给出了一个工程案例，把原先依赖多模型循环对话的架构，改造为直接读取操作规范的单模型方案。
这三起事件的性质完全不同，各自代表了一件安全争议、一个评测研究与一个架构工程原型。大家看到的这些量化数字，实际上只度量了系统复杂链条里的某一个局部环节。测试集里的任务成功率再高，也回答不了生产环境下的实际账单高低；模型调用次数省掉一半，不代表总算力消耗就真的更低；软件哪怕声明开源、模型哪怕离线部署，更无法保证私有代码不出设备。审视这些编程辅助工具时，辨清具体指标究竟建立在哪一个处理层级，往往比数字本身的大小更重要。
智谱旗下的桌面编程软件 ZCode
在后台干了两件事：每次你提问之前，先把整个项目连历史记录拍一份快照；这份快照加密后排队等着传到阿里云的存储服务。2026-09-18，独立开发者
ferstar 发表针对 ZCode
的调查报告，披露客户端在后台静默打包并尝试向云端上传用户的工作区内容。9
月 18
日是社区公开发布报告的日子，软件在报告发出来之前早就存在相关行为。翻看深入的数据流追踪就会发现，客户端只要处于登录状态，就会在日常对话交互之外持续运行一条后台上传通道。每当用户准备发送提示词，或者带
repo-wiki-update
标记的任务结束时，程序便会全面扫描当前工作区生成文件清单，整体压缩打包并采用标准加密手法处理。加密用的钥匙在厂商云端手里，你自己和软件本体都解不开自己硬盘上的这份文件。随后生成的加密包进入本地队列排队等待，客户端向
zcode.z.ai/api/v1/snapshot/upload-credential
接口索取临时凭据，绕开日常业务网关将文件直传至阿里云对象存储，最后以回调形式登记至后端系统。整套上传逻辑只要求登录态有效，界面全程没有任何弹窗提示或用户确认环节。读者可以在
ferstar
发布的调查报告 以及对应的 英文版分析
中核对这套网络调用的原始证据。
后来好几个人在自己电脑上也发现了同样的后台动作。在 GitHub 上的反馈
issue #707 中，多位开发者相继贴出抓包与目录排查日志。NodeSeek
论坛上的抓包记录 显示，有 Windows 用户在自己机器上数出 32
个生成了快照的工作区。而在 Elliot
针对 Mac 3.12.3 版本的取证记录 中，快照目录总计吃掉了 894MB
磁盘空间，清单里版本控制目录占比高达 98.9%。社区工具 zcode-tui
的隐私审计报告 则对 Linux
构建完成了静态审计，证实这套机制覆盖了三大主流桌面系统。研究者展示的本地待传加密包体积达到
313,070,842
字节；不过面对这么大的体积，必须严格厘清待传不等于已传出。元数据中记录的
failureCount: 564 存在两种技术解读：ferstar
读作单包尝试上传失败 564 次，Elliot
逆向代码后认为属于跨任务累计失败值。两种读法记录的都是上传失败，均未代表成功上传。
更让工程团队捏一把汗的，在于打包清单的具体内容分布。在 ferstar
展示的单样本明文清单列出的 42,411 个文件中，.git
目录下的内部对象占到了 86.6%，其中包括 196.1MB 的 LFS 缓存（占比
56.8%）、102.2MB 的 Git 对象库（占比 29.6%）以及 0.6MB 的 reflog
提交回溯日志（占比 0.2%），当前工作区的常规源码和文档实际仅占
13.4%。这些版本历史对象可能包含早期提交中遗留的未脱敏密钥配置文件、未推送的内部特性分支名以及企业内部
GitLab 托管地址。客户端程序遇到 .git
路径直接放行而绕过敏感词过滤规则，附加清单甚至还会将 ZCode
全局配置跨工作区搭车外传。许多开发者尝试通过客户端偏好设置阻断这种行为，但设置界面的
optimizeAgentExperienceEnabled
选项仅控制数据是否用于模型训练，repoSnapshotIndexingEnabled
选项仅控制服务端是否针对快照构建代码索引。#707 的提交者与 Elliot
均通过实测记录确认，即使用户在界面中关闭了这两项开关，本地全量快照依然照常生成。
针对那些加密快照是否最终抵达云端，三处独立来源在客户端本地记录中观察到了
lastAcceptedManifestHash
字段。逆向分析证实客户端仅在文件成功传完 OSS
后才会写入这个哈希值。不过这属于客户端单方面的写入标记：客户端记录不等于服务端收据，不能据此确认服务端已收到并保留。面对社区的强烈关切，据
IT
之家转述，官方把这条链路归因于代码库索引功能，表示这是为了支持会话检查点恢复、历史版本回退以及
Repo
Wiki，并宣称知识库页面在云端生成后“相关上传数据会立即销毁，不会保存”。官方解释“该功能在上线初期默认开启，导致部分用户受到影响”，强调“相关问题目前已经修复”，未来承诺向社区开源客户端并邀请第三方审查，且向受影响用户提供一次周额度重置。
官方公布的说法与目前公开的技术证据之间存在显著落差。ZCode 官网更新日志 目前最新的记录停留在 2026-09-17 的 3.12.3 版本，通篇未见任何关于快照打包或隐私逻辑的修复记录。官方材料中唯一与快照传输相关的公开文字，出现在 2026-09-16 构建的 Linux x64 latest.yml 清单 里，其问题修复栏注明“优化仓库快照上传的内存占用”，这只是一项针对内存开销的性能调优，并未声明停用或关闭上传功能。云端数据即刻销毁的表态目前同样缺少任何第三方的独立验证，而 ZCode 官方 Repo Wiki 文档 提到 Wiki 采用专用的阅读视图且与其他功能的文件扫描相互独立，反而印证了系统内部存在多条并行的文件扫描路径。梳理 GitHub 上 zai-org 组织旗下的全部 52 个开源仓库，未见客户端本体代码开源，官方在 GitHub 的 #707/#709/#711/#715 四条反馈中也没有人工介入回复，现行隐私协议更缺少对快照上传行为的明确披露。社区反馈中也存在差异性样本，例如 Hacker News 用户 weiran 的反馈记录 表明其长期使用中本地从未产生相关快照目录，Linux 用户 zax0rz 同样报告未曾触发过打包进程，说明这种行为并未波及全员设备。审查编程工具必须顺着网络请求与文件读写路径逐项核对：不用于训练和不建索引，均推导不出不上传。这起事件留待后续观察的关键点，在于官方修复逻辑何时体现在带版本号的正式发版日志中、云端数据销毁能否拿出独立的第三方验证凭证、客户端开源承诺的兑现进度，以及由外部独立安全机构对 failureCount 具体语义给出的最终裁定。
Claude Code、Codex 这类成熟 harness 相比极简 agent 到底强在哪里，大家花钱用它们买到了什么？复杂设计应当换来更好的任务表现，这是普遍的默认预期。2026-09-16，Arena 博客与项目团队联合发布 HarnessTax 对比评测，同日上线项目主页，在 Hacker News 上获得了 209 分的高关注度讨论。作者公布的数据给出了直接答案：把同一个底层模型 Claude Fable 5 分别装入官方 Claude Code 与极简框架 Pi 跑同样的 30 题代码修复，成绩几乎一样（97.8% 对 96.7%），平均单次尝试成本却相差约 2 倍（$1.33 对 $0.67）。Pi 只提供读、写、编辑和 bash 执行命令四个基础工具，没有预置厚重上下文与附加功能，成绩照样打平。
这项研究并未局限于单一组合。团队将七个主流模型分别装入三种框架（Claude Code、Codex CLI、Pi），在侧重代码修复的 SWE-bench Lite 与侧重终端操作的 Terminal-Bench 2.0 两套标准化基准上各测 30 题且每题重复 3 次，所有框架均为官方原生默认配置与高努力模式、单次上限 100 轮，合计 21 种组合；各框架轮次定义不统一，严格断网也仅明确部署在其中一个基准中。更出人意料的是模型和自家框架的配对关系：作者指出你的 Claude 模型可能并不需要 Claude Code（“your Claude models may not need Claude Code”），跨六个 Anthropic 与 OpenAI 模型、两个基准共十二组对照里九组的最高成功率出现在非自家 harness 上，直接回答了读者到底需不需要官方配官方的疑问。
这 $1.33 是成功解题才花的钱吗？并非如此。这是依据 2026-09-01 价格表平摊失败尝试的每次开销，脱离订阅支出，非成功任务成本，不含企业管理开销。更厚的初始规则说明属于候选解释但未做因果消融，1.1 个百分点同样不能断言显著或等效。
不能从这组数字武断读出复杂框架无用的结论。作者明确给出了研究边界：测试只在两个公开基准上展开，基准可能进过训练集；面对模型能力边界处的难题（作者举例科学发现类工作），可能仍需要结构化引导更强的复杂 harness。此外，管理功能、跨会话协作这些跑分测不到的价值，不因本次研究归零。正如作者指出的结论：“Harness choice has little effect on task success rate, but can significantly affect the cost on the benchmarks we test.” 后续留待观察的落点，在于作者承诺公开的完整运行追踪记录（原文写明 “will publicly release our profiling traces”，截至 2026-09-17 仍为公开承诺）何时正式开放下载供核查细节。
在多模型协作的架构设计中，技术团队常常直觉地以为减少调度层级就必然带来总体资源开销的降低，但实际的工程度量往往呈现出截然相反的结果。2026-09-16，微软云解决方案架构师 Tommaso Stocchi 在微软官方开发者博客发表了题为《From Specialist Agents to Distributed Skills over MCP》的技术长文，结合自己 2026-09-10 提交到 GitHub 的滑雪场咨询系统代码，复盘了一个滑雪度假村咨询智能体的架构演变。原系统基于智能体间协作架构（Agent-to-Agent，简称 A2A）搭建，主顾问模型在收到用户的复合咨询后，将不同领域的任务分派给远端的专家服务。在老方案中，每个远端专家服务都是一个自带模型循环的 sub-agent。以天气查询专家为例，主顾问将任务分派给天气专家后，天气专家内部的模型先分析意图并决定调用哪个气象工具，拿到气象数据后再由专家模型组织语言、生成摘要并送回给主顾问。面对同一个用户的咨询请求，老系统往往需要先后发起 6 次、6 次甚至 7 次独立的大语言模型调用。
新方案则将整套系统重构为分布式技能架构。四个领域服务依然保持在远端独立部署，底层的业务逻辑代码与数据查询接口完全保留，改动在于移除了各个专家内部原先嵌入的模型推理循环。每个分布式服务对外暴露三项标准化资产：一行简明概括自身能力的技能索引、一份名为 SKILL.md 的 Markdown 操作说明书，以及一组遵循模型上下文协议（Model Context Protocol，简称 MCP）并带有严格参数规范（schema）的工具定义。在面对用户咨询时，主顾问模型在第一次调用中阅读各服务的索引摘要，挑出解决当前问题所需的服务模块；宿主程序随后通过协议拉取对应的说明书，并动态注册这个服务暴露的全套工具；主顾问在第二次调用中，依据说明书的指引直接按规范下发指令调用工具并拉取业务数据；到了第三次调用，主顾问直接结合返回的结构化数据整合输出最终建议。同一个咨询任务的模型调用，由原先典型的 6 次压减至 3 次（6→3 次）。重构真正拿掉的，只是每个专家内部原先用来决定查什么和如何措辞的中间模型推理，业务代码、部署位置与数据查询完全未动；对于开放式网络调研智能体，新老方案均予以保留，表明多步探索任务依然适合交由独立模型处理。作者在副题中强调的核心设计准则是：保持领域服务分布式部署，把专家的指令注入编排器，无需额外引入模型（“Keep your domain services distributed. Move the specialist’s instructions, not another model, into the orchestrator.”）。作者在博客中写道：“A distributed skill is not an agent wrapped in Markdown.” 协作形态也跟着变了样：主模型直接获得操作工具与业务规范，无需把整个任务转交外部推理进程（“delegating a task to another reasoner versus giving the current reasoner a competence and access to its operations.”）。
作者用三组相同的提问做配对测试，测出了两组走向截然相反的指标。面对完全一样的咨询提问，老架构在三组实验中分别需要 6 次、6 次与 7 次模型调用，新架构稳定维持在 3 次；端到端的平均等待时间从 15.480 秒下降至 6.348 秒，整体等待时间减少过半。然而在消耗的 token 总量上，老架构三组实验合计消耗 11,134 token，新架构三组累计却达到 13,533 token，整体 token 消耗反而增加了约 22%（+22%）。作者在博客中特别加粗强调：它并没有使用更少的总 token（“It did not use fewer total tokens.”）。一种可能的解释是，将原本分散的领域说明书集中塞入主模型的上下文后，后续每一轮模型交互都要承受这笔膨胀的上下文开销。作者自己也没回避实验的局限性，明确指出这仅仅是三次配对展示，并不构成严格受控的性能或质量研究（“This is a three-pair illustration, not a controlled performance or quality study.”）。
聊到系统安全与协议规范，这套方案同样标明了清晰的边界。将说明书加载进大模型的上下文，绝对不等于获得了系统的执行授权；系统读取说明书属于渐进呈现信息的过程，加载不是授权（“Loading
is progressive disclosure, not
authorization”）。示例代码之所以能在加载后自动注册并免去确认审批，前提在于示例中的工具全部属于只读查询操作；项目文档明确警示，如果系统接入写入或变更操作，团队必须重新设计审批流程（“adding
write operations requires revisiting
approvals”）。在具体协议实现上，示例代码所依赖的技能发现机制基于
skill://index.json 与
skill://<name>/SKILL.md，这套路径源自早期的 SEP-2640
规范草案；而 2026-09-13 合并的终版协议已全面改用
skills/list 与 skills/get
接口，原有的协议路径不再出现在正文定义中，开发者在参考落地时必须仔细核实接口规范的版本演进。决定采用独立模型专家还是说明书形式的技能，取决于具体场景的决策复杂度是属于发散的多步探索还是收敛的单次查询，以及服务之间的信任边界与规则更新频率。这项架构留给工程界的核心观察点，在于随着接入工具数量与规则说明的急剧扩充，把大量外部规范持续塞回单一主模型的做法，未来能否在维持推理精度的同时承受不断膨胀的上下文开销。
一份加密快照打包了完整版本控制历史，在后台尝试送往云存储。一个框架评测调换了外层执行框架，任务成功率几乎一样，账单支出却可能产生约 2 倍差距。一次架构改造拿掉了中间的专家模型，调用次数与等待时间减少过半，总 token 消耗反而增加两成以上。
数字都不假，但每个数字只回答自己那个环节的问题。弄清它到底量的是哪一段，往往比单看数字本身更实在。