addyosmani/agent-skills 深度评测:9.9 万 Star 的 25 个工程技能,自带评测 100% 全绿,我实测只对 24%

addyosmani/agent-skills 深度评测:9.9 万 Star 的 25 个工程技能,自带评测 100% 全绿,我实测只对 24%

如果你给 AI 编码助手装过技能包,大概遇到过同一个尴尬:装是装上了,可它该触发的时候不触发,不该管的事又抢着管。一个 25 个技能的包里,你想用的那个到底会不会被选中?

addyosmani/agent-skills 这个仓库给出了一个罕见的答案:它自带评测套件、把通过率写进 CI 当门禁。我把它 clone 下来跑了一遍——官方跑分 100%,我按真实用户的口吻出题,只剩 24%。差别不在项目好坏,在于它的评测用的是书面语,而你说话不是。

它是什么,凭什么 9.9 万 Star

一句话定位:把资深工程师的工作流、质量闸门和验收标准写成 25 个可自动触发的技能,让 AI 编码助手在每个开发阶段都照着做。作者 Addy Osmani 是 Google 的工程负责人,仓库 MIT 许可,JavaScript 为主,创建 220 天冲到 98,752 星、10,372 个 fork,一天前还有提交。

它的设计思路不是「教模型更聪明」,而是「给流程装栏杆」。开发被切成六段——定义、计划、构建、验证、审查、上线——对应 9 个斜杠命令,每个命令自动激活相关技能:

阶段 命令 核心原则
定义 /spec 先写规格再写代码
计划 /plan 任务切到原子级
构建 /build 一次只推进一薄片
验证 /test 测试就是证据
审查 /review 先提升代码健康度
上线 /ship 更慢反而更安全

技能本身不是空话。25 份 SKILL.md 合计 7,519 行,平均 301 行,最长的是 performance-optimization(496 行)。随手翻一份 doubt-driven-development,它先把「什么算非平凡决策」定义清楚——引入分支逻辑、跨模块边界、断言编译器验不了的属性、爆炸半径不可逆——再明确列出不该用的场景:重命名、格式化、用户已明确要求提速。「怀疑每一次按键就什么都发不了」写在正文里。这种自我设限,比多数「万能提示词」克制得多。

真正让它区别开的是 evals/ 目录:82 个文件、25 份用例、25 套 fixture,外加 13 个校验脚本。分三层——结构层查 frontmatter 和命名,路由层查触发准确率,行为层用真实 agent 跑用例打分。前两层免费且在 CI 里强制执行。

实测:100% 与 24% 之间差了什么

官方路由层评测的门槛写在 CI 里:node scripts/run-evals.js --min-rank1 95。我在这台机器上原样跑了一遍,结果是 88 条正向提示全部命中自己的技能,rank-1 准确率 100%,140 项检查零错误零警告。

这个数字很漂亮,但它是怎么来的?我读了 runner 的实现:它把所有技能描述做成词袋,用带词干还原的 TF-IDF 向量算余弦相似度,取最相近的那个。也就是说,它比的不是语义,是用词重叠。

于是我做了一件事:不看它的测试集,自己写题。同一批技能,换三种问法。

第一组是啰嗦口语,就是人真会说的话——「应用点保存就崩了,我也搞不清为啥」这种带噪声的长句。21 条里只对了 5 条,rank-1 准确率 24%。第二组换成中等长度的书面请求,12/15 命中,80%。第三组压到 3-6 个词的短语,9/10,90%。

为了排除「我写得太怪」的可能,我又做了一组严格对照:同一个意图,写成短语、标准句、啰嗦口语三种版本各 10 条。

问法 rank-1 准确率 top-3 命中
短语(3-6 词) 90% 90%
标准书面句 100% 100%
啰嗦口语(带噪声) 40% 80%

变量很清楚:提示越长、噪声越多,词法路由器越容易被无关词稀释掉关键信号。它认的是关键词密度,不是你想干什么。

还有一组更直接的证据。我把作者 88 条测试提示与对应技能描述的词汇重叠率算了出来:平均 56.2%,其中 57% 的条目重叠率超过一半——「write a failing test」对上描述里的 test,「pull request」对上描述里的 code review,几乎是原词照抄。我自己写的那 21 条,平均重叠率只有 12.6%。

最后是消融实验:把每条提示里与技能描述重叠的实词删掉,保留其余部分,重新路由。结果 rank-1 从 100% 掉到 2%,top-3 也只剩 7%。词一拿掉,路由器就不认识自己的技能了。

需要说清楚的是,这不等于项目在造假。它的评测文档把话讲得很明白:路由层是「词汇近似」,判不了语义,抓的是两种真实故障——描述缺了用户会说的词,或描述太宽泛挤掉了正确的技能。这套检查确实管用,而且它有个真本事:25 个技能描述两两比余弦,300 对里最高只有 0.260,离 0.5 的告警线还很远。也就是说,这套技能的边界互不打架,这在同类技能包里相当少见。

翻车点在别处。它的分词正则只保留 a-z0-9,中文字符会被整体清空——我用纯中文提问,分词结果直接是空数组,所有技能得分都是 0.0000,排序退化成按目录顺序。中文用户拿到的是一个完全失效的路由器。另外 25 个技能里有 5 个叫 *-driven-development(constraint / doubt / source / spec / test),命名高度雷同,靠名字区分基本不可能。行为层(Tier 3)要调真实模型、花 token,我在这个克隆里没找到任何历史结果文件,evals/skill-impact.md 是一张只有表头的空账本——「哪些改动被评测否掉了」,目前无从查证。

放到同类里看

技能路由这个题目,最近一个月已经有三篇值得对照。

reverse-skill(36.9k 星)同样是路由包,我实测它自己的 178 条路由全绿,而我出的 56 条错了 7 条——和这里的结论几乎一致:自测集通过率高,不等于你的问法能过。mattpocock/skills(254k 星,37 个小工具)走的是反面路线,明确拒绝流程绑架,不做统一编排。Spec Kit(13.7 万星)长成了插件市场,169 个社区扩展实测八成已休眠——规模上去之后,维护是另一回事。

适合谁:团队里用 Claude Code、Cursor、Codex、Copilot、Cline、Gemini 等 8 种以上助手,且希望把「先写规格、测试先行、上线前审查」变成默认动作的人。25 个技能可以整体装,也可以单装——npx skills add addyosmani/agent-skills --skill code-review-and-quality 这样点名取用。

不适合谁:技能内容全是英文,中文团队要用得自己重写描述;如果你只想要一两个技能,整包 7,519 行的体量反而增加上下文负担;如果你的诉求是「让 AI 更聪明」,这套东西治的是纪律,不是智力。

结论

9.9 万 Star、25 个技能、7,519 行内容、CI 里跑着 100% 的评测——这个仓库的工程质量在同类里是第一梯队。但它的路由评测是一把词法尺子,量的是「用户的用词和描述的用词有多像」,而不是「用户想干什么」。所以看到任何技能包宣称「触发准确率 100%」,值得多问一句:你的测试提示,是谁写的、照着什么措辞写的。

我的建议是放进观察清单并试用,但装完之后用自己的话测一遍你最常用的三个场景——如果它没触发,你要改的是技能描述,不是自己的说话方式。

关注 AI商业快讯,每天一篇 AI 热点深度解读。

相关阅读:

OpenAI 法庭文件自曝:苹果 ChatGPT 整合远未达标,反垄断案 2027 年 1 月开庭

OpenAI 法庭文件自曝:苹果 ChatGPT 整合远未达标,反垄断案 2027 年 1 月开庭

苹果和 OpenAI 那场被吹了两年的合作,是 OpenAI 自己说它失败的。

本周三,The Financial Times 披露了一批新的法庭文件:在跟马斯克旗下 SpaceXAI 的反垄断案里,OpenAI 承认苹果把 ChatGPT 接进 iPhone 这件事「远未达标」(dramatically underperforming)。原话出现在它请求法院提前判决的材料里——不是被对手挖出来的黑料,是它主动写进去的。

这个细节决定了这条新闻的价值。一家公司公开说自己的明星合作失败了,通常意味着这个「失败」对它现在的处境有用。

发生了什么

时间线要从 2024 年算起。那一年苹果宣布 Apple Intelligence,ChatGPT 成为 Siri 的默认外部模型,OpenAI 拿到的是全世界最大的分发入口——每一台 iPhone。

OpenAI 在文件里说,它当时的预期是一个「光环效应」:借苹果的品牌和推广,换来订阅增长。但接入一个月后,这个整合就「看起来起步迟缓」,OpenAI 开始下调每周活跃用户的预期。到 2025 年夏天,「已经很清楚,苹果对 ChatGPT 的整合远未达标」。

它对原因也给了判断:ChatGPT 在这套整合里默认是关闭的。用户要自己去系统里打开,才能让 Siri 把请求转给 ChatGPT。这个设计是苹果做的,不是 OpenAI 做的。

文件里有大量涂黑段落,但未被遮蔽的部分显示,OpenAI 高管当时担心苹果会「想走得更快」——去找另一个 AI 合作伙伴。这个担心后来变成了现实:苹果的新 Siri 转身用上了 Google 的 Gemini 模型,Xcode 也已经接入 Anthropic、Google、OpenAI 三家的编码 agent。

为什么现在说,才是重点

要理解 OpenAI 为什么在这个时间点承认「我们的合作很失败」,得看它说这句话的场合——在被告席上。

案子是马斯克的公司 SpaceXAI 在 2025 年 8 月提起的,指控苹果和 OpenAI 串通,把竞争对手挡在 AI 入口之外,顺带压制「超级应用」(包括马斯克想做的「万能应用 X」)。案子审理地被定在德州 Fort Worth,法官 Mark Pittman。按最新排期,庭审定在 2027 年 1 月 11 日。

被告要赢这种反垄断案,最有力的辩护之一是:这桩被指控「排他」的合作,根本没排他性、也没带来垄断收益。

「苹果的整合远未达标」这句话,正好落在这个论证上。苹果没有帮 OpenAI 拉来用户,ChatGPT 也不是 iPhone 上唯一的选择,用户还能用 Gemini——这叫没有伤害竞争。OpenAI 甚至在文件里说,SpaceX 自己 IPO 招股书里的披露「充斥着与本案指控截然相反的内容」。

同一件事,对 OpenAI 是「我们被苹果坑了」的委屈,对反垄断法庭是「我们没有垄断能力」的证明。 两句话不矛盾,只是场合不同。

还有一层背景值得交代:OpenAI 和苹果的关系早就不只是「合作不顺」。2026 年 5 月起就有报道说 OpenAI 在考虑起诉苹果,7 月苹果反过来在加州北区联邦法院起诉 OpenAI、io Products 和两名前员工,指控窃取商业机密。两家从合作方变成对手,这段「合作失败」的自述,同时也在为后续的法律战铺垫叙事。

这件事对三类人意味着什么

对 iPhone 用户:没什么可慌的。默认关闭是个可改的设定,Siri 什么时候调 ChatGPT、什么时候自己答,苹果在隐私文档里写得很清楚。真正变化的是,苹果已经在把新 Siri 的底座换成自家模型和 Gemini,ChatGPT 在这个生态里的位置只会更边缘。

对开发者:这是一个「平台方掌握分发权」的教科书案例。OpenAI 拿到的是全球最大的终端入口,但它拿不到默认开关的控制权——苹果只要把功能设为默认关闭,两年的分发红利就蒸发大半。任何依赖大平台带量的产品,都该把这个案例当成风险模型来看:入口是别人的,「光环效应」就不是你能定价的资产。

对普通观察者:注意「失败」这个词的来源。这不是第三方评测给出的结论,是 OpenAI 在法庭语境下自己提供的事实陈述。它说的是真的,但选择说、选择现在说,是有动机的。

放到坐标系里

把这件事和苹果今年另一条新闻放在一起,反差会更清楚。苹果在 AI 上付出的和解成本正在累积:今年早些时候它同意支付 2.5 亿美元,就 Apple Intelligence 宣传失实(承诺的 Siri 功能没按时兑现)的集体诉讼达成和解,单台设备最高折算约 95 美元。

一边是为「AI 功能没做到」赔钱,一边是被合作方在法庭上举证「AI 功能没带量」。苹果在 AI 上的账,目前两头都是负数——这恰好解释了它为什么急着把 Siri 的底座换成自家模型加 Gemini:继续绑在一家外部模型上,风险只会越积越多。

而 OpenAI 这边,最扎眼的对比是它同期在硬件入口上的另一场官司——和苹果的商业机密诉讼还在打,进 iPhone 的路已经被 Gemini 切走一段。它在软件入口上没守住的,正在用别的方式补。

判断

这条新闻真正值得记住的不是「OpenAI 承认失败」,而是它的使用场景:在反垄断案里,承认自己的合作没带来垄断地位,是一种防守动作。

可以预期两件事。第一,庭审前 OpenAI 会继续用「合作无效」这条线做文章,它有强动机把这句话反复写进文件。第二,苹果不会回应——对它最省事的做法就是让这件事停在联邦法院的卷宗里,然后继续推进自己的模型路线。

对读者的实操结论只有一条:别把大平台分发的「预期收益」当成既定资产。OpenAI 是全球最强的模型公司之一,在 iPhone 这个入口上依然是被动的一方。你不是。

关注 AI 商业快讯,每天一篇 AI 热点深度解读。

相关阅读:

OpenOPC 深度评测:港大开源的「AI 原生公司」,50 张表撑起组织,186 个 AI 员工是借来的

OpenOPC 深度评测:港大开源的「AI 原生公司」,50 张表撑起组织,186 个 AI 员工是借来的

2026-09-24 补测:文章发布后,我用真实模型把这套框架的完整公司流程跑了一遍——招募、编制、执行、终交付卡全程,以及四个卡点,见第五节。

多 Agent 框架的通病是演示能跑、长跑就散:聊到第三轮丢上下文,进程一停就恢复不了,最后一个「全自动团队」退化成几个必须有人盯着的对话框。港大数据智能实验室(HKUDS)7 月 1 日开源的 OpenOPC 换了个问法——不是「怎么让 Agent 互相发消息」,而是「怎么把 Agent 当员工管起来」:先招人建组织(Self-Built),再派活跑流程(Self-Run),最后复盘沉淀(Self-Grown)。84 天拿到 1,714 星、319 个 fork,中文圈已经有几篇通稿在转,但都停在 README 的翻译层面。

我把它整包拉下来,跑通了初始化、34 个 CLI 子命令和那个像素办公室 UI,量了它的数据库、测试和人才池,复现了一条 9 月 22 日刚上报的恢复崩溃;后来又借到一个真实模型的 key,把它整套公司流程完整跑了一遍。结论先给:它的组织学是真材实料,员工学是借来的,而它现在最要命的地方是「跑完之后的恢复」。

一、它把「公司」做成了什么东西

README 讲的是三个词(自建、自跑、自长),但打开代码,真正被反复推敲的是另一个东西:一条工作项(WorkItem)的状态机。它把「谁在什么时候能干什么」全部压进一个 Phase 枚举——14 个状态、4 个看板列、50 条合法转移,而且看板列、当前负责人、能不能跑、裁决结果全部由 phase 用纯函数推出来,不再各处各写一套判断。

源码注释把动机交代得很直白:这个 Phase 替换掉了旧版「status 加 5 个 metadata 子状态」(activation_state、lifecycle_state、review_state、manager_release_state、review_execution_state)互相打架的写法,改成「一个枚举值对应一种具体处境,转移表在每次写入时强制校验」。跨层同步(task 状态、角色会话状态、调度器唤醒)则交给 phase 转移钩子,注释里还写清了它的边界:钩子只做「尽力收敛」,不做事务一致,工作项写入才是唯一真源。

这套东西落到磁盘上就是那张数据库:我建了个空库跑起来,50 张表、70 个索引、590 个字段(空库 736 KiB)。表名基本是组织学的词汇:delegation_runs、delegation_work_items、role_runtime_sessions、seat_states、work_item_decisions、approval_records、execution_checkpoints、reorg_proposals、runtime_permission_grants。它还有自己的通信层:角色之间不是直接调函数,而是往文件式工作区 .opc-comms/ 里写收件箱、会议记录和共享记忆,好处是可审计、可重放、阻塞时能被唤醒。

另外两个细节值得记一笔。一是「员工从哪来」:5 个外部 agent 适配器(Claude Code、Cursor、Codex、OpenCode、JiuwenSwarm),但你跑 opc agents list 会发现表格里分了两栏——只有 JiuwenSwarm 的两种形态既支持 Task 又支持 Company,其余四个在 Company 栏是 no。也就是说所谓「公司」目前基本跑在它自己的原生运行时上。二是自演化:每个员工跑完活会往 employee_evolution.json 里落经验和评审偏好,同一个模式被记到第 2 次就蒸馏成可复用的 skill(LEARNED_SKILL_THRESHOLD = 2)。

它自己的路线图也把债摊开写了:7 条优先级里,第一条是「角色级技能还不能在界面上选」,最后一条是「运行时打磨:恢复、检查点、执行进度可视化」,另外还自认「CLI 不如 Office UI 完整,终端侧的编辑与检查是后续工作」。一个愿意在 README 里承认「CLI parity 还没做到」的项目,通常比通稿里的它更可信。

它还把「公司治理」直接做成了命令行:AI 自己觉得组织架构该调整,得走 opc propose-reorg 提交一个带理由和变更集的提案,等人 approve-reorg 才生效;自主度是分档的(我这边看到的是 bounded 模式,风险不超过 medium 才自动放行,置信度阈值 0.7);整个组织可以打包成 .opcpkg 导出、安装、卸载。这套「AI 提案、人批」的写法,比大多数 Agent 框架里那句「human-in-the-loop」要具体。

二、我实测到的东西

下面这张表是这次动手的产出,方法和数字都可以复现。

我测的 方法 结果
装起来 opc init 一次通过:载入 11 个角色、预检 6 个外部 agent(本机 0 命中)、生成 config/memory/skills/agent_homes 目录树
界面 opc ui 起得来,200,「OpenOPC Pixel Office」;Phaser 3.90 跑 1.2 MB + 主包 1.37 MB + 6 套角色精灵 + 7 套配色 + 中英双语
安全闸门 在未信任仓库里跑 CLI 先 fail closed 提示 opc trust add;信任后放行;再往 .opc/config 里多放一个文件,立刻又被拦(提示「信任后配置权威已变更」)
代码形状 逐文件统计 243 个文件 204,663 行;store.py 单文件 32,354 行(1.41 MB)、engine.py 21,295 行、company_mode.py 20,376 行,三个文件占全仓 Python 的 21%
测试体量 pytest 全量跑 156 个测试文件 130,761 行,是库代码的 64%;3,059 个用例跑完用了 45 分 04 秒:3,033 通过 / 8 失败 / 18 跳过
失败归因 逐条复跑 4 条是本机环境(缺 websockets、沙盒文件系统不支持硬链接)、1 条重跑就过、2 条是仓库自己的不变量 lint 红了、1 条我没能归因到环境
CI 覆盖率 读 workflow 官方 CI 只跑 6 个文件、30 个用例,占全部 3,059 个的 1.0%
一条崩溃 直接调它的函数 复现 9/22 上报的恢复失败:12 个合法 turn type 里没有 verify,canonical_work_item_turn_type_for_kind("verify") 返回的是 execute
数据库膨胀 用它的引擎量 每个任务都存一份完整组织拓扑:3 角色 20.3 KB、11 角色 74.5 KB、21 角色 157.8 KB
一条上游报告 按声明版本复跑 复现不出来:报告说远程 MCP 必挂,我用它在 pyproject 里声明的 mcp 1.30.0 直连公共 DeepWiki MCP,握手成功
端到端公司运行 真实模型跑满全流程 3 角色组织跑通「招募 → 编制 → 执行 → 终交付卡」,产物落盘 929 字节简报 + 25 个协作 md,花费见第五节

那 8 条失败里最值得看的是两条「仓库自己的 lint 红了」。第一条叫「状态单一真源」的不变量测试:它扫源码,禁止有人绕过 phase 通道直接改任务状态(原话是「会造成跨层状态不同步」),我跑的时候它报出 company_mode.py:10886 直接写 .status = TaskStatus.CANCELLED、10905 直接写 .status = TaskStatus.FAILED——而它自己的白名单注释里写着「company_mode.py 已不再直接写这两个状态,9 处写入全部改走 transition_work_item」。更巧的是,这两行代码正好落在 9 月 11 日那笔「评审反馈完整性」修复新增的路径上(评审员没给理由就驳回 → 自动重试两次 → 重试耗尽把评审卡置为失败)。也就是说:它三周前为了修「驳回理由丢失导致 worker 空转」而新写的分支,恰好踩回了它自己用 lint 看守的那条老病根,而这条 lint 不在 CI 的 30 个用例里,所以没人拦得住。另一条红的 lint 是测试夹具命名的守卫,它在自己的一个测试文件里抓到一处违规。这两条都不是沙盒问题,任何人在任何机器上 clone 下来跑都会看到。

那张安全闸门的表值得单独说,因为它是这个仓库里最容易被人忽略、却最说明工程成熟度的一处。上游 8 月 11 日收到过一个安全报告:OpenOPC 默认加载项目目录里的 .opc/config,而这份配置可以指定 MCP 启动命令、远程 MCP 地址、LLM 的 api_base 和 api_key_env——也就是说,你 clone 一个别人的仓库、在里面敲一条 opc chat,就等于让对方仓库里的文件决定「跑什么进程」和「把你的 key 发到哪个地址」。报告给复现、给受影响 commit、指出仓库当时连 SECURITY 政策都没有。8 月 26 日修复落地,并且我这次实测到的行为是这样的:先拦住、要求你 review 后手动 opc trust add,信任记录绑的是配置指纹,我只要再改一次配置就立刻重新拦截。这条链路是我这次评测里质量最高的部分。

三、186 个「AI 员工」是怎么来的

README 里最抓人的是人才池:186 个岗位模板,涵盖工程、设计、营销、金融、游戏。我数了一遍,并且和它的上游做了逐路径比对。

人才池构成 数量
仓库里的岗位 md 文件 197
带 YAML 头的真模板 186
与 msitarzewski/agency-agents 路径一一对应 165
上游嵌套目录被拍平或改名 20
仓库真正自建 1(general-default-employee.md)
上游现有模板 / 本地缺失 321 / 缺 156
抽样 7 个做内容比对 4 个逐字节相同,3 个只差 1–10 字节

agency-agents 是一个 154,385 星的人才模板库,OpenOPC 的致谢里也如实写了「本仓库包含的所有人才模板均导入自 agency-agents」。我抽样的差异长这样:把上游的 ## Identity & Role Definition 改成 ## Role Definition,或者补一个文件末尾的换行——几乎没有实质改写。剩下 11 个不带模板头的文件里,10 个是上游 examples/、strategy/ 目录的说明文档被一起拍平放了进来,还有一个是 Pull Request 模板。

这不是「抄」,MIT 协议下导入并且署名,合规。但读者需要知道的是:它卖给你的员工,和你在别的项目里随手能拿到的员工是同一批;而因为导入时间停在 7 月,上游的模板如今已经涨到 321 个,本地缺了 156 个。真正属于它自己的,是上面第一章那套状态机——那是别人没有、也没法直接拿的。这一点在我第五节的实跑里被验证得更清楚:自动招募挑出来的两个「员工」,正是那两个模板。

四、现在的它,卡在哪

9 月 22 日,两位用户在同一个项目上提了三条崩溃报告,全部开放、全部零回复,而仓库最后一条提交停在 9 月 11 日:

  • 原生工作项在 LLM 流式调用卡住时会永久挂起,调度器每 5 秒打印一次「claim skip」,可以空转 23 分钟直到有人手动杀进程;
  • 一旦你为此杀了进程,delegation_runs 里会留下一个没释放的租约,之后每一条恢复路径(opc exec --resume、UI 的会话恢复)都会撞上「live company runtime Task requires an explicit run or attempt fence」这道为「保护活任务」而设的闸门——报告作者的原话是「这道闸门在进程死掉之后保护的是尸体」;
  • 自定义组织里「经理把活派给下属」这种最常见的结构,恢复时直接抛「WorkItem identity changed before commit」。

我复现的是第 3 条的近亲:verify 是这套系统里的一等公民(company_mode.py 里出现 11 次,qa_ready 门、依赖检查、投影 id 都在用),但它不在规范 turn type 集合里,于是所有「按 kind 映射 turn type」的通用助手都会把它悄悄降级成 execute,下游 guard 拿一个错的默认值去比对真实业务类型,于是「本来没问题的恢复」每次都失败。这不是玄学,是集合里少了一个字符串。

还有一处容易被忽略的不对称:整个 docs/ 里唯一的中文文档是那份 JiuwenSwarm 接入说明(10.7 KB),其余文档全是英文。JiuwenSwarm 是国产的自组织蜂群框架,也就是说「把外部 Agent 接进公司模式」这条路径,目前是为中文用户准备的——而它也确实是唯一能进 Company 模式的外部执行体。

把 issue 和 PR 一起算,有 28 个外部账号在这个项目里留过东西,其中 15 人提过 PR——社区是活的。但另一边,30 条 issue 里有 11 条至今零评论,8 条还开着的报告一条回复都没有。对一个 84 天的新项目来说,这是「用户比维护者跑得快」的典型形状。

生态那边的信号也一致:33 个 PR 里合并了 13 个,其余长期挂着——包括 8 月 27 日就提出来、直接修「最终交付后会话永久卡死」的 #53;一位贡献者的 Shadow Mode(把真人承包商当员工接进流水线)PR 被关掉后,他干脆自己开源成独立包 OpenOPC-Shadow-Adapter,20 天不到 120 星,卖点是「一台机器同时打多份工」。

五、真跑一遍:招募、编制、执行都成了,卡点在后半段

光看代码不够,我借了一个真实模型(xiaomi/mimo-v2.6-flash,走 CommandCode 的 OpenAI 兼容端点),在仓库自带的 3 角色组织 research-report-studio 上把它跑了一遍:首席分析师 → 研究员 → 报告产出。

前半段跑通了,而且是真跑通:staffing 检查点 → 自动招募 → 确认编制 → 执行 → 交付。首席分析师读了任务、写了产物,brief.md 落在工作区(929 字节,含三条可执行建议,内容是能看的);.opc-comms/ 下生成了 25 个协作文件(给 owner 的 4 封信、团队记忆、草稿板)。自动招募挑出来的两个员工,就是第三章里那两个借来的模板:研究员用了 Codebase Onboarding Engineer,报告产出用了 Technical Writer。整场 20 次模型调用,输入 239,882 token、输出 12,838 token,主执行回合 7 分 48 秒;按这个模型费率折算大约 0.04 美元。顺带一句:cost_records 里记的成本全是 0.0,因为 litellm 不认识这个端点的定价。

后半段每一步都撞墙,而且四个卡点全部可复现、全部不是我的环境问题:

  1. 无头模式会卡死在工具审批提示上。默认自主度是「medium 以下自动放行」,但「读取工作区之外的路径」被单独判为需要人点,提示打到标准输出等人输入;后台跑没有交互终端,于是永久阻塞——数据库里三条 tool_permission 检查点至今还是 pending 状态。加 --approval-level full-access 可以绕过。
  1. 为解卡杀掉进程,留下僵尸租约:delegation_runs 那行保持 status=running、lifecycle_status=active、controller_lease_generation=5,对应工作项永远停在 running。这正是第四章里那三条报告描述的现场。
  1. 带审批级别的恢复直接崩,报错与上游报告逐字一致:CompanyRunControllerLeaseLost: live company runtime Task requires an explicit run or attempt fence,位置在「给运行中的公司任务持久化原生权限配置」那一步;把 --approval-level 去掉,同一条恢复命令就正常返回。也就是说这道为防误写而设的闸门,卡住的恰好是恢复路径自己。
  1. 终交付确认这张卡,命令行答不了。我用自然语言回复「我完全同意这次交付」、又试了「approve」,都不消费这张卡:每回一次就新生成一个交付工作项,旧卡变成 superseded,运行再次停回 awaiting_owner。CLI 里唯一的检查点提交命令只服务组织改组(approve-reorg),通用卡片没有入口——也就是说,完整闭环目前只能在那个像素办公室界面里点出来。

对照组在这里最有意思:维护者自己 9 月 11 日的实跑记录里写着,「尚未实跑所有 company profile 的规划、编制、并行派工、owner 审批、返工、崩溃接管与最终交付完整生命周期」,并且注明那一轮的三次实跑没有启动正式的公司调度器。我这次启动了;结果是前半段(规划、编制、执行)确实能用,后半段(审批、返工、崩溃接管)三段各撞一个真实缺陷。

还有两条附带观察。一是 3 角色组织里,被录用的研究员和报告产出一个工作项都没拿到——首席分析师在自己的首个回合里把活干完了,和上游报告里那个「CEO 自己干、不派给下属」的 corporate 形状一模一样,也就是说多角色的编制在真实运行里未必真的分出去。二是一次公司运行会改写 .opc/config,从而让工作区信任指纹失效,下一条命令行必须先重新 opc trust add 才能执行——这是第二章那条安全加固的副作用,安全上没错,但对无头自动化是个持续的绊脚石。

六、判断和边界

值得学的:状态机单一真源、跨层钩子写清一致性边界、fail-closed 的工作区信任、把内部审计文档(docs/ 里 6 份带日期的审计与迁移记录,最长 37 KB,逐条对比姊妹项目 Talen 的正确性修复并注明血缘)直接放在公开仓库里。测试写了 13 万行,这个比例在同类项目里少见。

要打折的:它是「AI 公司」的骨架,不是劳动力。员工模板是借的且已经落后上游两个多月;外部 agent 里只有 Jiuwen 能进 Company 模式(而 JiuwenSwarm 的 0.2.4b4 根本不在 PyPI 上,安装要靠一个 GitHub 固定 commit 加一份 --overrides 把依赖顶到 gitcode 上的另一个仓库);3,059 个测试只有 30 个进了 CI;README 里那张「七层架构」的表被 HTML 注释包住了,浏览器里根本看不到,中文版连这段注释都没有。

谁该用:想研究「多智能体怎么管起来」的人,这个仓库值得逐文件读,它的债务和设计都写在明处。想在生产里跑「全自动公司」的人先别——我这次跑下来,前半段能用、后半段全是恢复问题,而恢复恰恰是自动化最不能缺的能力。当「带审批和完整审计轨迹的单 Agent 工作台」用(Task 模式),风险小得多。

局限说明:端到端这次是用真实模型跑的(组织是 3 角色的自定义预设,模型是 MiMo V2.6 Flash),但「返工、审批、崩溃接管」三段各撞一个缺陷,完整闭环没能收口;那 8 条测试失败逐条复跑归因如上,没归因清楚的 1 条我照实写出来,不作为项目缺陷计入。Playwright 浏览器工具与 chromadb 在 aarch64 musl 上没有预编译包,我按缺失处理。

同类项目此前评测过的:把多个 AI 组队成开发团队的 oh-my-openagent 走的是「角色技能包 + 命令行编排」,GreatCTO 押的是「69 个岗位一次买齐」,ECC 卷的是「工程纪律」。OpenOPC 是这四家里唯一把「恢复」当第一性问题做的,也是目前唯一还没把恢复做成的。

Archify 复测:70.2k Star 的 AI 架构图生成器,23 天翻倍、一个稳定版没发,我复现出一条栽赃环境的假报错

Archify 复测:70.2k Star 的 AI 架构图生成器,23 天翻倍、一个稳定版没发,我复现出一条栽赃环境的假报错

让 AI 画系统架构图,最常见的结局是拿到一张漂亮的废纸:框没错、线乱飞,和仓库里的代码对不上。Archify 的解法是让 Agent 先写结构化 JSON,再用渲染器和三道闸门把图逼成真的。上次我在它 34k Star 时写过一篇实测,23 天后它涨到 70,210 Star、翻了一倍,却连一个稳定版都没发。这次我把仓库整个 clone 下来重跑:1,397 个测试、14 个内置样例、5 类图形各交付一张,还亲手造了一张 40 节点 90 连线的密集图,把一个「报错信息栽赃环境」的假报错完整复现出来。

一、星数翻倍,版本号停在原地

同一篇文的两次观测之间,只隔 23 天:

指标 2026-08-31(前作) 2026-09-23(本次) 变化
Star 34,400 70,210 +104%,日均约 1,556
Fork 2,185 4,718 +116%
open issue+PR 72 153 翻倍
稳定版 v2.16.0(08-30 发布) 仍是 v2.16.0 23 天零发版
合并 PR(累计) — 206 贡献者 34 人

同期仓库并不冷清:23 天 63 个提交、252 个文件被改动,网站整体迁到 Astro 6.4,多了一个 star-history 工作流,中文 README_ZH 单独维护 benchmark 说明。真正停着的是发布节奏——最新预发布版本 v2.17.0-dev.1 停在 09-17,CHANGELOG 里压着 compare 回滚修复、diff 箭头修复、UTF-8 SVG 声明(中文导出用)、CLI 失败结果机器可读化、DSH 插件刷新等 7 项没上正式版;README 的营销点清单写着「截至 08-30」再没动过。

我的判断:增长已经跑在发布流程前面。星数来自口碑扩散(教程站、Trendshift 徽章、社区 showcase 截图),工程侧在攒一次大版本。

二、它怎么做到的:五段流水线,三道闸门

把它当架构看,是一条严格的单向流水线,AI 和渲染器各管一半:

  1. Agent 写 JSON:12 种中间表示(architecture / sequence / workflow / dataflow / lifecycle 等),schema 严格到连多余字段都拒(additionalProperties 报错会精确指到路径)。guide 命令自带 11 个场景脚本(绿场/加密审计/并行任务/单服务追因…),中文写成可执行的写作契约。
  1. validate 三道闸:schema 校验 → 布局校验(按字符宽度估算像素,超宽必拦)→ 工程 profile 校验。deployment-ownership profile 要求每个部署组件在 tag 里写明 owner,validation profile 要求 low/medium/high 必须有端口对象、组件必须挂 service/risk 数据。
  1. 渲染子进程:按类型分发到独立渲染器,输出单文件自包含 HTML(SVG + 内联 CSS/JS,不依赖任何 CDN)。
  1. check 五项几何自检:single_svg、finite_svg、orthogonal_arrows、label_route_clearance、relationship_crossings,产出带 builder/checker 标识的机器可读回执。
  1. 交付后的证据链:visual-check 在四个视口截图比对(1440×900 / 1440×1100 / 1920×1080 / 390×844,每档取 120–480 行);compare 把两个版本的架构 IR 对齐成 delta(组件/边界/连接三类增删改 + 节点与连接的语义 sha),四档身份分(excluded / partially represented / represented / changed);连排错都用它自己——「debug by archify」要求把系统状态也画成图。

三条工程决策值得抄:零运行时依赖(devDependency 只有 ajv、parse5、saxes、simple-icons 四个包);SKILL.md 只有 137 行、16,396 字节,只管编排,绝不把 schema、渲染器或成片样式内嵌进技能文档;渲染与检查都走子进程 + 管道,拿到纯净 JSON 才做判断。

三、一手实测:跑真不跑真

装机零摩擦:clone 后 npm install 装 4 个 dev 包(node_modules 30.3 MB),doctor 0.219 秒五项全绿。

命令 结果 耗时
validate 14 个内置样例 12 个直接 OK(另 2 个是 compare 专用 base/head) —
deliver 五类 showcase architecture / sequence / workflow / dataflow / lifecycle 各一张,check 全 ok:true 单张 1.05–1.13 s
单张产物 810–821 KB 自包含 HTML,回执仅 710 B —
compare architecture 双版本 delta HTML 2.2 MB,回执带 builder/checker 语义哈希 2.19 s
全量测试套件 1,397 tests / 1,330 pass / 49 skip / 17 fail 758 s

17 个失败我逐条对了归因:12 个是更新检查器(1 秒窗口内拉不到清单就按设计静默)、3 个是打包测试调 unzip -Z 而 BusyBox 没这个子命令、1 个是沙盒 git pack 校验、1 个要真实 HTTPS 证据仓库——没有一个是渲染或校验逻辑的缺陷,但它们证明这套套件对网络和系统工具敏感,换台干净机器复跑先备好依赖。对照前作引用的 README 口径(1,026 测试 / 988 通过 / 38 跳过),测试规模已经涨到 1,397。

布局闸门是真的拦人。我故意造了一张 40 节点、90 连线的密集架构图,一次性吃下 1,352 条问题:标签按字符宽度估像素(100px 组件里塞 26 个字必超)、连线短于 24px、边界跑出 viewBox、连线穿过节点、50 处交叉——每条都带 Fix: 提示,指到具体坐标。渲染器端的 deployment-ownership profile 连每个组件的 owner tag 都逐个点名。这不是形式主义,它逼着 Agent 一直迭代到图能交付为止。

然后撞上一个栽赃环境的假报错。同一张密集图跑 validate,CLI 只给我一句 Renderer process could not start.——听起来像我沙盒的问题。翻代码找到根因:子进程输出走管道、spawnSync 全文没有一处 maxBuffer(Node 默认 1 MiB),诊断 JSON 刚到 1,057,920 字节就被 ENOBUFS 截断,那 1,352 条真实问题一条都看不见。我直接复刻子进程确认:errno: ENOBUFS、status: 1、stderr 正好 1,057,920 字节,连中文都被截在半个字符上。同一根因的另一面是 issue #525(deliver 的 check 输出超 1 MiB 就报 artifact/check-failed,v2.16.0 和 main 都能复现):维护者 tt-a1i 在 09-23 确认并公开邀请修 PR,gold-beyond 已认领。它和 #448 的「grep -c 0 被判 false」属于同一类病——退出码是 1,但原因读不出来。

四、坐标系:同类工具里它站在哪

这个赛道我验过三件事,结果摆在一起才看得清位置。前作那篇实测 记录的是 34k Star 时的它,当时结论偏向文档复述;这次的证据全在手上:装机、跑测试、画图、复现 bug,可信度换了一层。Skill Seekers 那篇 走的是反方向——把文档转成技能,卡在模式识别(@property 被当成装饰器模式);Archify 恰恰相反,不让模型自由发挥,用 schema、像素估宽、工程 profile 三道闸门把发挥空间掐死,代价是写 JSON 的约束感,收益是图能对上代码。第三件是 i-have-adhd 那篇:一个项目的文档自带评测,结果被自己的质量闸门拦下——「自证」是这个赛道的通病,Archify 用机器可读回执(builder/checker、视口行数、语义 sha)给出了目前我见过最像证据链的解法。

五、结论:谁该用,以及别信什么

该用:有真实系统要画、并且要求「图和代码对得上」的人——工程文档、安全审计、服务拆分评审、交接。它的五段流水线天然适合塞进 Agent 工作流:Agent 只负责写 JSON,画得对不对交给闸门,人只看回执。中文支持是真的(README_ZH、guide --lang zh 的 11 个场景、CHANGELOG 里还有中文提交),零依赖意味着离线也能跑。

别信:星数。70,210 Star 对应的是 23 天零稳定版发布、153 个 open issue/PR、61 个 PR 排队合并(累计已合并 206)。口碑扩散和工程发布是两条速差曲线,v2.17.0-dev.1 停在 09-17 之后没有新预发布。另外别信「报错说环境坏就是环境坏」——本次那句 Renderer process could not start. 就是缓冲区截断伪装的,同样一个 1 MiB 的默认值,还在 deliver 上伪装成 artifact/check-failed。

本次的局限:visual-check 在我这台沙盒里起不来 Chrome(DevTools 管道 ECONNRESET,PRoot 环境限制),四个视口的截图证据我拿不到,只能依赖它自己的几何自检回执;10 个子命令没有一个支持 --help(传了就回 Unknown X option),只能裸跑看 usage;--json 只在 validate / deliver / brands / guide 上有,render 和 check 吃不下——对一个把「机器可读回执」当卖点的工具,这个不统一有点讽刺。本次实测数据取自 2026-09-23 的仓库快照,截图、回执与 17 个失败的完整归因见文末证据包;相关断言已登记到断言守望,字段一变会复核。

reverse-skill 实测:36.9k 星的技能路由包,它自己 178 条路由全绿,我出的 56 条错了 7 条

reverse-skill 实测:36.9k 星的技能路由包,它自己 178 条路由全绿,我出的 56 条错了 7 条

132 天 36,908 星,平均每天约 280 个 star——reverse-skill 是近期安全向 Agent 技能里涨得最快的一个。它的判断很简单:AI 不是不会用工具,是不知道该用哪个工具,于是把 44 条路由规则摆在最前面,让 jadx、IDA、Frida、Burp 先各归各位,再进入 45 个场景模块里的那一个。仓库自带 178 条路由回归用例,我在 Linux 上全量跑完,178 条全绿;随后自己出 56 条对抗用例,它错了 7 条,其中 3 类是真问题——最典型的一个 bug,会让「sandbox escape」这种标准提法被路由去分析恶意软件。

一个「先选剧本再动手」的技能路由包

拆开仓库,它由三层组成:单一事实源 skills/config/routing.json(15,089 字节,44 条规则按优先级排列,每条规则由 must 命中、mustAll 全中、exclude 一票否决三段组成)、45 个场景模块的 SKILL.md,以及一套 bootstrap 脚本负责探测本机工具链。路由产出 PRIMARY/SECONDARY 两档 skill 路径和置信度(high/medium/low),还附带 case-init 流程:授权范围与网络档没就绪之前,不许对真实目标动手。

项 我实测的数字
路由规则 44 条(R0–R45,R0 为兜底),优先级链单独列出
场景模块 45 个 + 根路由 SKILL.md,INDEX.md 由脚本自动生成
CTF 子技能 41 个 competition-* 目录、42 个 SKILL.md
SKILL.md 合计 46 个、324,983 字节,按 1.8 字节/token 约 18 万 token
首屏负担 主路由只读 routing.json + MASTER-ROUTING.md(7,435 字节),模块按需展开
提交与人力 181 次提交、15 位贡献者(前三名 42、36、36 次)

上手路径也是三条:给 Claude Code 装 reverse-skill 插件、复制仓库根的 AGENTS.md 到项目 AGENTS/、或 git clone 后用 master-route.sh 单独跑路由——仓库为 Claude、Codex、OpenCode、Cursor、Copilot、Gemini 各准备了各自的桥接文件(CLAUDE.md、AGENTS.md、opencode.json、GEMINI.md 等),最小加载路径甚至可以为零。我在干净的 Alpine 沙盒里跑了 bootstrap:--list 列出 23 项发现能力、7 个工具组、4 条纪律(只发现不激活、MCP 默认不注册、每个安装给一行理由、端口只读探活),并直接点名缺 java、jadx、frida、radare2;它的工具索引刷新后给出 34 项清单,只有 5 项在沙盒里可用(python3、node、npm、npx、burp-mcp-full),每个缺失项都带 install_hint。路由的判定逻辑可以一句话概括:must 命中、mustAll 全中、exclude 一票否决,同分时按优先级链仲裁——官方基准里就有「ghidra + .so」这种用例:两条规则都命中,预设路由是 ghidra 而不是 IDA,靠的正是优先级而非关键词数量。

我抽开了被路由频次最高的 apk-reverse 模块:11,727 字节、14 个 H2,开头是五步 ACTION REQUIRED——NOW 读 precedent-reverse.md 确认这是已授权的常规操作、NOW 核对适用范围、NEXT 查 tool-index.md 校验工具真实路径、缺工具就调 bootstrap 而不是猜路径、ACT 进工作流第一步别停在确认状态;结尾则是「任务完成自检(声称完成前 MUST 通过)」,中间夹着工具分工、自带脚本、禁止事项、输出要求、路由上下文和按需自举六段。相邻的 mobile-reverse 是 6,234 字节,结构同款。首尾各一道强制协议,比在提示词里写一句「要注意安全」硬得多——agent 想跳过,得先跳过自己刚读过的清单。

授权边界在这套体系里不是口头约定。master-route.sh 的下一步是 case-init:先写 scope 文件,声明 authorization_ready(靶标、测试账号、时间窗)、network_profile(read_only / controlled_active / active 三档)和 response_format(no_write / read_only / active),三者没对齐之前,R45 的强制 scope 检查不让任何 ACT 动作落地。配套的 RULES.md(中英两版)还写了更细的硬约束,比如单个红队阶段不超过 5 分钟、不超过 15 个动作,收尾必须提交 Evidence → Finding → Path 三件套到时间线,报告格式由 REPORTING.md 模板锁死。换句话说,它把「你有没有资格动手」变成了一个可被 agent 循环反复校验的状态,而不是一句提示词里的情绪表达。

这个体量设计值得单独说一句。我们评测过的 a-stock-data 把 7,288 行塞进单个 SKILL.md,一次加载 11 万 token;reverse-skill 的 46 个 SKILL.md 全量也有 18 万 token,但它是路由型结构,首轮只读十 KB 级的路由配置,命中哪个模块才开哪个——同一堆文档,上下文成本差一个量级。对比同赛道的大星仓库:ECC 25.5 万星管的是工程纪律,marketingskills 47k 星管的是营销流程,reverse-skill 管的是危险动作的顺序与授权边界——这是三者里唯一把「不许对没授权的目标动手」写进流程的。

实测一:它自己出的 178 道题全绿,状态表却写错了

克隆仓库后我把六套测试全部跑了一遍:

测试 结果
test-routing(路由回归) 178/178 全绿;其中 quick 冒烟 44 条、中文用例 103 条、英文 75 条,44 条路由全部有覆盖
test-bash-workflow 5/5,1.9 秒;含网络档校验、未授权拒绝两条安全断言
verify-repository-security 599 个文件全部被跟踪、74 个可执行源、无符号链接,OK
verify-doc-links 全部内部 Markdown 链接可达
bootstrap 两套回归(manifest + client-neutral) 全过
refresh-tool-index 34 项工具只探测到 5 项可用(python3/node/npm/npx/burp-mcp-full),java、jadx、frida、r2 全缺,每项附 install_hint

基准本身的质量高得超出预期:每条路由至少 2 条用例、44 条全覆盖、中英双语,还是跨平台 CI(Windows + Ubuntu)跑的。但README 的 Current status 表把回归基准写成 175 cases,实际文件里是 178 条(基准 meta 停在 2026-08-02)——文档和数据第一次对不上,就发生在最该对得上的那个数字上。治理面同样偏紧:15 位贡献者、18 个 open issue、7 个 closed,唯一的 PR 还挂着,0 个被合并,主线实际上仍是作者一人在推(最新提交 9 月 22 日)。文档滞后一两天不致命,但滞后偏偏发生在 README 首屏的状态表里——后来者第一眼看到的就是一个错数。

实测二:我出的 56 条对抗用例,49 过 7 错

官方基准的用例几乎都含规则里的字面关键词,等于命题人和考生共用一张表。我另出 56 条:口语化重述、中英混合、多个技能域竞争,全部走真实入口 master-route.sh。结果 49 过 7 错(中文 45/51、英文 4/5),单次路由延迟 min 304ms / p50 358ms / p90 683ms。7 条失败分三类:

类型 用例 → 实际路由 判定
子串误命中 docker sandbox escape → malware-analysis 真 bug
关键词不对称 redis 未授权访问安全评估 → R11 通用渗透 真洞
优先级平局 iOS APP 证书校验绕过 objection → apk-reverse 真错
平局取工具方 用 nmap 扫完出个报告 → R11;mysql 注入 → R35 可辩护
口语掉置信 抓一下 APP 的请求看看签名怎么算 → R0,confidence=low 标记正确

第一个是实锤 bug:R9 恶意软件规则的 mustAll 里有一项裸词 cape(指 CAPE 沙箱),没有词边界,于是 “escape” 直接命中。我补测了四个变体:「sandbox escape」「k8s sandbox escape」「escape from sandbox」全部被判给 malware-analysis,只有中文「容器逃逸」落到正确的 cloud-k8s——因为规则写的是 docker.?escape|container.?escape,中间插一个词就不匹配,而官方基准里 R23 的逃逸用例措辞恰好全都带字面 container/docker,所以 178 条自测全绿也测不出这个洞。第二个是规则不对称:mysql、postgres、mongodb 是裸词直达 R35 数据库安全,redis 却要求 redis.?secur 相邻出现,一句「redis 未授权访问」(渗透测试里最经典的一句话)就漏到了通用渗透。第三个是优先级设计:iOS 与 APK 两条规则同时命中时,R1 排在 R2 前面,于是带 objection 的 iOS 任务进了 APK 技能。

我又围绕这个洞补了四个探针:「sandbox escape」「k8s sandbox escape」「escape from sandbox」三条英文全部落进 malware-analysis,「sandbox 逃逸」因为没有 escape 字面、R9 的 mustAll 不成立,干脆跌到逆向工程兜底——同一个意思,换种说法就换来三种不同结局,路由表对英文子串的敏感和对中文语义的迟钝同时暴露。

值得肯定的是置信度机制真的在工作:中文口语「抓一下这个 APP 的请求看看签名」匹配不到任何字面关键词,路由退回兜底 R0 并标了 confidence=low——它知道自己没听懂,这比硬给一个 high 强得多。合起来看,官方基准考的是「关键词表内命题」,我的 56 条考的是「把同一件事换种说法再问一遍」——178/178 与 49/56 之间的差距,就是这套路由在真实对话里的安全边际。

生态、赞助与中文圈的数字滞后

项目挂了三家赞助(UCloud AstraFlow、AtlasCloud、Kite AI),自建了教程站与 star-history 图,并上了 Trendshift 榜。文档纪律倒是罕见地完整:REPORTING.md 约束证据格式(Finding 必须带 PoC、Path、Impact 三件套)、CHANGELOG 记录到最近一次提交(v1.0.1 是唯一正式 release)、RULES 有中英两版,甚至 burp-mcp-full/ 里嵌了完整的 MCP 服务端代码。中文圈已有教程向覆盖:知乎两篇、腾讯云一篇、CSDN 与 CodePass 各一篇,但口径明显滞后——8 月 20 日的知乎长文还写着「41 条路由规则 + 163 个回归用例」(现在是 44 + 178),Threads 上 20 小时前的热帖还在转「27.5k 星」,而我实测拿到的是 36,908,两天差了九千多。没有一篇做过实测复核——中文教程基本停在安装向,没人跑过一次 test-routing,也没人指出 README 状态表与实际文件差了 3 条用例。这也是本文只做一件事的原因:把它自己出的题和我出的题都跑一遍,让 36,908 这个星数落在可验证的地面上。

什么时候不适合用

它不是万能插件,四种场景建议绕开:任务不在 44 条规则覆盖域里(Web CRUD、数据分析、写作润色),每次请求都要先付一遍路由上下文再落到 R0 兜底,纯亏;中文口语描述容易掉出关键词覆盖,命中不了就得自己补一句术语(我实测中文场景 88% 通过,剩下基本败在口语重述上);越是关键任务,越不能只信那 178 条全绿——cape 这个洞证明自测基准有盲区,master-route 的输出要人眼过一遍再往下走;另外它的主线是 Windows(PowerShell 一等公民,bash 是对等移植),Linux/Kali 用户建议直接读 kali/ 平台文档。如果你只是想给 Agent 加一个单点能力,装个几百行的小 skill 比引一整套路由与授权流程轻得多——那样的话,先看你更适合哪种,再决定要不要它。

AI 创业方法论:把工具装进六层流程的判断标准(六层蓝图总纲)

AI 创业方法论:把工具装进六层流程的判断标准(六层蓝图总纲)

收藏夹里躺着十几个 AI 工具,测评存了几十篇,新模型发布当天必看热搜——三个月过去,能稳定用进工作流的还是原来那一两个。问题通常不在于没找到好工具,手里缺的是一把尺子:不知道什么值得学、学到哪一步、什么时候该换。装进流程的才值得学,装不进的再热门也不学。这篇是持久方法论轨的总纲:一张六层蓝图、一组判断标准、一张带日期的插槽表。

一、「是什么」的内容活不过一周,「为什么/怎么做」可以放十年

新闻与评测有明确半衰期:一次发布、一轮价格调整、一个版本号,热度在几天内起落,本仓台账里的时效文章皆是如此。商业模式、产品原则、避坑经验、决策框架则不随模型升级失效——变的是插槽里的工具,不变的是每层要回答的问题和判断依据。

写与读各有一个便宜的自检法:主语是事件还是体系?「某模型发布了什么」会过期,「怎么判断一个新工具值不值得投入学习成本」不会。本轨所有选题都要过六道闸(半衰期、挂载、一手、受众、空档、视角),今天先把体系本身交代清楚。

顺带把写作建议落成自检:写完每一段,先问这段是在描述一个事件,还是在交付一个可以照做的动作。事件段落删掉不心疼,动作段落才是文章留得住的部分——这套自检与六道闸同源:事件型内容服务今天,动作型内容服务明天。读者这边同理,看到「新东西很厉害」的说法,先等它长成判断标准再决定投入;等不到标准的,让它留在时间线上即可。

二、六层蓝图:每层回答一个问题,判据说明为什么这么判

层 这层回答什么 判据(为什么是这个)
L1 需求层 谁、痛到什么程度、愿意付什么 已有人在为替代方案付钱
L2 定位层 交付什么形态、和谁竞争 说得出不选竞品的那一个理由
L3 生产层 用什么把交付做出来(模型/Agent/人力) 单位交付成本可算、可复现
L4 分发层 怎么持续触达目标人群 至少一条渠道有可复利资产(订阅/搜索/名单)
L5 变现层 怎么收钱:按量/订阅/按结果 单位毛利为正,账单能对上
L6 复利层 沉淀什么会随时间增值 数据、内容、关系任一在复利
LOOP 验证循环 上面的假设何时被证伪 30 天一个节拍,至少一个读数
X 合规红线 隐私/版权/合同/IP 出事代价 × 概率,一票否决

层与判据是体系,按年级稳定;工具插槽是耗材,月级换。合规(X)不是第七层,是横切的红线:任一层都可能被它一票否决。

三、四条判断标准:新工具到底值不值得学

判断标准要能直接拿去用,顺序不能反:

  1. 挂载在哪一层:它替换 L1 到 L6 加 LOOP 加 X 里的哪一层、哪个插槽?挂不上就不要学,那是兴趣不是生产资料。
  1. 30 天窗口:插槽级收益能否在 30 天内被验证?验证不了就降级为「了解」,不进生产流。
  1. 替换成本:有没有替换判据和回退路径?绑死且无回退的,只放非关键位。
  1. 单位成本:按一手账单算(每任务、每百万 token),宣传页的数字不算数。

四问全答得上来,再谈学习投入;任何一问答不上来,它就还只是收藏品。

四、三个一手例证:这套判据在本仓怎么落地

例一(成本,L3):Jev Ultrafast 端到端实测-延迟 p50 382 毫秒、问题加到 60 个延迟只涨 14%、255 个 choices 是硬边界,全部实验花不到一毛钱,单任务成本压在 1 美分以内;同一轮也抓到三种静默假成功。判据对应:算到任务级,才知道便宜在哪、风险在哪。

例二(复现,L3):CUA-S1-FORMS 全量复核-模型卡宣称 99.95%,本仓用手移植的 numpy 前向加自写 ONNX 解释器全量跑 24,370 条,复现到 99.9549%;同时发现域外字段 23 个只填对 2 个。不看宣称,看复现——这是 L3 插槽替换判据的原型。

例三(账单,L5):CommandCode GOAT 档实测-10 美元换 70 美元额度,MiMo-V2.6 每百万 token 实测约 6 美分,缓存读、长上下文、批量半价在账单里一一拆开算单位成本。判据对应:L5 变现层先算单位经济,再谈规模。

五、30 天验证法与更新承诺

怎么做,三段节拍(对应 LOOP 循环):

  • 第 1 到 7 天:给工具定挂载层与插槽位,写下它的判据和预期读数,判据没写下来的工具不准开工。
  • 第 8 到 20 天:进真实任务,只记录插槽级读数——单位成本、成功率、返工率;顺手过一遍 X 红线四查(数据来源、素材版权、合同边界、敏感信息)。
  • 第 21 到 30 天:对照判据决定去留。通过则留在插槽,不通过则回退,记录留下作下一轮基线。

当前插槽填充(2026-09-23 快照,这就是「当前填充 + 日期」两行约定):

层 插槽 当前填充 替换判据
L3 强推理模型 CommandCode GOAT 档 MiMo-V2.6(6 美分/百万,账单实测) 同题单位成本与成功率
L3 端到端 Agent runtime 暂缓(假成功风险,见例一) 假成功率降到可接受
L4 分发渠道 geeyo 与微信双端 长尾阅读占比
L5 定价参照 按量与订阅对照,批量半价 单位毛利为正
LOOP 验证节拍 30 天 每个插槽至少一个读数
X 合规检查 发布前四查 出事代价 × 概率

更新承诺:插槽漂移会原地更新本文并改更新日期,体系层按年修订才另发新文;文中一手数据全部来自本仓可复现评测,上文三例均带链接回原评测。

收束成一句话:先挂层、再定判据、30 天见数——见不了数的工具,不配占用学习预算。

CommandCode 上的 MiMo-V2.6 实测:GOAT 订阅下每百万 token 约 6 美分,但 Flash 并不快

CommandCode 上的 MiMo-V2.6 实测:GOAT 订阅下每百万 token 约 6 美分,但 Flash 并不快

如果你每个月在 AI 编程上要花掉 10 美元以上,今天这条值得看完:CommandCode 把小米今天凌晨发布的 MiMo-V2.6 三个档位全部上架了,而且费率跟小米官网一分不差——Pro 输入每百万 token 0.435 美元、输出 0.87 美元,Flash 是 0.14 与 0.28。放在 GOAT 计划里,$10 换 $70 额度,折扣率 7 倍。

「7 倍额度」是数学还是话术,两周半前写过一次。这次换个问法:同一个活,交给四个模型做,谁把活干完、谁花得更少。我用账号里的 Provider API 跑了六组全自动判定的任务——没有一项靠人打分,对错由 pytest、JSON 解析和字符串匹配决定——把 MiMo V2.6 Pro、MiMo V2.6 Flash,和同平台上的 DeepSeek V4.1 Flash、GLM-5.3 Flash 放在同一张题卷上。

结论先说:MiMo V2.6 两档都能干活,端到端成本比直连小米官网便宜约 7 倍;但「Flash」这名字没带来速度,而最大的坑不在价格表上,在三个平台细节里。

它是什么,档位怎么选

CommandCode 是一套以开源模型为优先的编码 agent(CLI 加网页工作室),同时提供 OpenAI 与 Anthropic 双兼容的 Provider API,端点 https://api.commandcode.ai/provider/v1。MiMo V2.6 的三档今天上架,模型 ID 是 xiaomi/mimo-v2.6-pro、xiaomi/mimo-v2.6-flash、xiaomi/mimo-v2.6-pro-ultraspeed,都标 1M 上下文。

档位地图(价格截至 2026-09-22,另收支付手续费):

套餐 月费 额度 适合谁
Go $1 $10 只想试一下,约 1.5 万次请求
GOAT $10 $70 个人主力,约 7.5 万次请求
Pro $20 $80 需要闭源旗舰模型(Claude、GPT、Gemini)
Max 10× / 20× $100 / $200 $150 / $300 重度用户,额度上限更高
Provider $15 起 按量付费 自建脚本调 API,零加价、不限流

倍率从哪来,官方没有藏着:一是额度按模型独立分配($70 不是一个大池子,而是每个模型一份),二是缓存命中工程的差价,三是厂商 deal 补贴。第三条对 MiMo 用户特别现实——mimo-v2.6-flash 有个上架 deal,GOAT 上这个模型的额度临时提到 $67(平时 $30),9 月 24 日截止;上一代 V2.5 系列则挂着 -98% 与 -99% 的折扣。

对照一下直连:小米官方海外定价与 CommandCode 完全一致(Pro $0.435 / $0.87,缓存读 $0.0036),所以这里的「便宜 7 倍」纯粹来自订阅额度,不是平台压价。

先做纸面数学,再谈体验。官方给的「约 7.5 万次请求」是个容易误读的数字——它指的是轻量 agent 请求。按我下面实测里最便宜的动作(修一个 bug,账单 $0.00013)算,$70 足够跑 50 万次以上;换成最贵的动作(一次 12.9 万 token 的长上下文,账单 $0.0564),$70 只够 1,240 次。同样一笔钱,容量差 400 倍,取决于你每次让它读多少东西。所以「够不够一个月」这个问题,答案不在套餐页上,在你的使用姿势里:把复用前缀固定住、让缓存吃满,比换模型省钱得多。

实测:六组任务,四个模型

方法说明白:走 Provider API 直连,/chat/completions,温度与输出上限按任务固定;六个任务全部可机器判定——T1 是给一个预埋了 3 个 bug 的小仓库(6 个 pytest 用例,初始 3 失败 3 通过),模型交回完整文件,我应用后跑测试;T2 是两轮真实工具循环,看它会不会用 read_file 读完两个文件、再用 run_tests 带 -v 跑测试;T3 是把 23.7 万字符(实测 129,521 token)的合成代码库塞进去找一句藏起来的话;T4 是严格 JSON 指令遵循;T5 是一道可判定的多步概率题;T6 量时延与吞吐。

任务 MiMo V2.6 Pro MiMo V2.6 Flash DeepSeek V4.1 Flash GLM-5.3 Flash
T1 修 3 个 bug(6 用例) 通过 6/6 通过 6/6 通过 6/6 通过 6/6
T2 两轮工具调用 通过 通过 未跑完(网关超时) 未跑完(网关超时)
T3 12.9 万 token 藏针 答对 答对 未答出 未测
T4 严格 JSON + 枚举 通过 通过 通过 通过
T5 多步推理(0.65) 通过 通过 通过 通过
T6 时延中位 / 吞吐 7.60 秒 / 9.1 tok/s 6.29 秒 / 12.9 tok/s 7.84 秒 / 16.3 tok/s 9.51 秒 / 13.5 tok/s

三个可以直接用的观察。第一,能力层面四个模型打平——修 bug、工具调用、JSON、推理这四关谁都没掉队,MiMo V2.6 的「agentic coding」定位不是虚的,Pro 与 Flash 在这几关没有可见差距。第二,长上下文分开了档次:12.9 万 token 的检索,MiMo 两档都一次答对(Pro 20.0 秒、Flash 15.1 秒),DeepSeek V4.1 Flash 在同样的题上没能给出答案(它先把预算烧在思考上,触发长度截断)。第三,「Flash」不等于快:Flash 的 12.9 tok/s 反而低于 DeepSeek V4.1 Flash 的 16.3 tok/s,Pro 更慢(9.1 tok/s)。名字里的 Flash 说的是价格档位,不是速度承诺。

然后是钱。同样一道 T1 修 bug,四个模型的账单差 4.8 倍:

场景 输入 token 输出 token 账单(美元) GOAT 实付(约)
修 bug · MiMo Flash 548 191 $0.00013 $0.00002
修 bug · MiMo Pro 548(缓存 512) 235 $0.00022 $0.00003
修 bug · DeepSeek V4.1 Flash 598 471 $0.00037 $0.00005
修 bug · GLM-5.3 Flash 536 1,079 $0.00062 $0.00009
12.9 万 token 长上下文 · MiMo Pro 129,521 80 $0.0564 $0.0081
12.9 万 token 长上下文 · MiMo Flash 129,521 27 $0.0181 $0.0026

折算成单价,GOAT 订阅下的 MiMo V2.6 Pro 相当于输入每百万 token 约 6 美分、输出约 12 美分;Flash 是 2 美分与 4 美分。这个量级已经比国内大部分 API 直采都低。

缓存是这套算术里最被低估的一项。我拿同一段 23,293 token 的前缀连发两次:第一次全价、7.65 秒;第二次 23,168 token 命中缓存(命中率 99.5%),只按 $0.0036/M 计费——缓存读取价是标准输入价的 1/120,延迟也降到 4.49 秒。也就是说 agent 场景里反复复用的系统提示与代码上下文,几乎不花钱。CommandCode 官方口径是「约 98% 缓存命中率」,我在单个场景复现到的比它更高。

额度不等于能花完。GOAT 的两道滚动窗口是 5 小时 $14、每周 $35。按实测里最贵的动作(一次 12.9 万 token 长上下文,账单 $0.0564)算,5 小时窗口大约能跑 248 次,一周约 620 次,月度 $70 够跑 1,240 次——对日常编码够用,但如果你拿它灌整个仓库做批量分析,卡住的会是 5 小时窗口而不是月度额度。额外买的按量额度不计入限额,超窗时会优先消耗它们。

三个价格表上没有的坑

第一,非浏览器 UA 会被 Cloudflare 拦。我用 Python 的 urllib 直连时一律返回 HTTP 403 error code: 1010,换成 curl 或给请求加一个浏览器 User-Agent 就正常。1010 是 Cloudflare 的浏览器签名判定,不是模型权限问题——自己写脚本接这个 API 的人,第一分钟就会撞上。

第二,推理默认开着,预算给少了会拿到空回答。一个「只回复两个字」的请求,账单是 13 输入、18 输出,其中 15 个 token 花在思考上。我第一版长上下文测试把输出上限设成 64,模型把 64 个 token 全用来思考,最终 finish_reason=length、正文为空——看起来像模型没答出来,实际是预算太紧。给到 1024 之后 DeepSeek 也能正常作答。用这个平台写脚本,输出上限要按「思考加正文」的总量来配,习惯性写 256 的人会误判模型能力。

第三,平台自己还没给 MiMo V2.6 打过分。四个 V2.6 相关条目在 CommandCode 的模型页上,智能指数与吞吐两栏都写着 not yet scored。这不是缺陷,但意味着你在选择档位时没有任何第三方参考,只能像本文这样自己跑题。

超速档 mimo-v2.6-pro-ultraspeed 也是 10 倍价(输入 $4.35、输出 $8.70),GOAT 同样能调用(我实测返回 200)。它存在的意义只有延迟敏感的交互场景,以我测到的 Pro 延迟水平看,不值得默认开启。

判断:谁该用哪一档

主力用 Flash,难任务切 Pro。两者在本次六组任务里能力打平,而 Flash 的输出价只有 Pro 的 32%($0.28 对 $0.87),还更快一点;再加上 9 月 24 日前额度提到 $67 的上架 deal,当下性价比最高的是它。Pro 该出场的地方是长链路 agent 任务与方案设计——12.9 万 token 藏针这一关,它和 Flash 都答对了,但账单是 Flash 的 3.1 倍,所以除非真遇到 Flash 答错的场景,长上下文也建议先用 Flash。

如果你的用法是「一次性把整个仓库喂进去」,要注意 MiMo 的输入侧单价(Pro $0.435/M)在 1M 上下文下并不便宜:单次 12.9 万 token 就是 5.6 美分,一天跑几十次就吃掉 5 小时窗口的大半;这种用法更该配合缓存,把复用前缀固定住。

如果你只是偶尔写点代码,$1 的 Go 档也能用 MiMo——但 Go 档没有 API 权限,只能在 CLI 里用。

如果你的用法是跑脚本而不是敲代码,$15 的 Provider 档更对路:按量付费、零加价、没有滚动限流,只是额度不会像订阅那样被放大 7 倍。反过来,$1 的 Go 档虽然也能用 MiMo,但没有 API 权限,只能待在 CLI 里。

别指望它替代闭源旗舰。小米自己的报告里,Pro 在 ProgramBench 上得 26.5,而 Claude Opus 5 是 37.0;ExploitBench 47.9 对 78.5。它在开源权重阵营里是第一梯队,但跨到闭源旗舰那一档仍有肉眼可见的差距,这也是 CommandCode 把 Claude、GPT、Gemini 放在 Pro 与 Max 套餐的原因。

最后是利益与口径声明:本文作者是 CommandCode GOAT 的付费订阅用户,自购自用,与 CommandCode、小米均无商业合作;文中全部价格为 2026 年 9 月 22 日抓取的官方页面口径,费率与 deal 随时可能变动;实测数据来自本机 Python 脚本直连 Provider API,每一组的判定逻辑(pytest 退出码、JSON 解析、字符串匹配)都可复现,任务集与原始结果已存档。

相关阅读:

小米 MiMo-V2.6 深度实测:逐张量核对 1.02T 参数,六天 RL 直播日志全量对账

小米 MiMo-V2.6 深度实测:逐张量核对 1.02T 参数,六天 RL 直播日志全量对账

今天凌晨,小米发布并开源了 MiMo-V2.6 系列:Pro(1.02T 总参数 / 42B 激活)、Flash(310B / 15B),外加一个蒸馏到 Qwen3.5-9B 上的 9B 版本,三个仓库都是 MIT 许可。中文圈三个小时内就铺满了,「46 分」「开源第一」「万亿参数」的说法到处转。

参数有多大、榜单第几名,这些转述就够了。我更关心三件能自己动手验证的事:那个 1.02T 是不是真的;把成本、失败、重启都摊在面板上的六天直播,日志里究竟写了什么;以及「开源」这两个字,这次到底覆盖了多少东西。

于是我把三个仓库共 199 个权重分片各取了前几百 KB 的 safetensors 头部(只取头部,没下那 573 GB 权重),把每张张量的 dtype 与 shape 拉下来,逐个数参数;训练面板的接口是公开的,我把两次 RL 每一步的指标全量拉了下来对账;再把 GitHub 上那三个「训练资源」仓库逐一看了一遍。

结论先放前面:参数量没吹,训练日志甚至比技术报告更细,但确实有三处对不上——其中一处是 Pro 这一轮 RL 里没有网络安全数据集。

这次发布的三个模型与它们的骨架

Pro 与 Flash 都是稀疏 MoE 的全模态模型,文本、图像、视频、音频进同一套序列,1M 上下文;第三个 MiMo-V2.6-Distill-Qwen-9B 是把 MiMo 的 agentic 能力蒸馏进 Qwen3.5-9B 的监督微调版,官方定位是「给社区当 agentic RL 的起点」。

骨架上有三个值得记的决策。一是混合注意力:Pro 的 70 层里 60 层是滑动窗口注意力(窗口只有 128),10 层是全局注意力,第 0 层用全局注意力加稠密 FFN 兜住早期表征。二是 MoE 的规模:384 个路由专家、每 token 激活 8 个、没有共享专家,第 0 层之后每层都是 MoE。三是投机解码:随包附了一个 5 层的 DFlash 草稿模型(2.77B 参数,块扩散,一次前向并行猜多个 token),外加 3 层 MTP。

编码器也没含糊:视觉塔 28 层(24 层 SWA 加 4 层全局),音频分词器编码器 308M 参数,音频 patch 编码器把 25Hz 压到 6.25Hz。

RL 侧才是这次真正的新东西。异步 GRPO,每步 1,568 个提示、每个出 16 条轨迹,即每步 25,088 条;训练 30 步。优化器用的是 Muown(Muon 与 Adam 合体),学习率 3e-6,没有 warmup,梯度裁剪 1.0。为了防止专家负载塌陷,RL 期间路由器被整个冻结——报告里给了对照实验:不冻结时第 9 层的专家负载变异系数从 0.78 涨到 2.0、峰值负载从 6 倍涨到 16 倍、冷门专家占比从 0.5% 升到 22%;冻结后三条曲线全部走平。

证据一:把 1.02T 参数一个个数出来

先说方法。HF 上每个分片都是标准 safetensors:文件头 8 个字节是头长度,后面跟一段 JSON,列出该文件里每张张量的 dtype、shape 和数据偏移。所以我只要对每个分片发一个 Range 请求,取前几百 KB 就够了——Pro 130 个分片、Flash 65 个、蒸馏版 4 个,加起来只下了几十 MB,却把三个仓库索引里的 23 万条张量记录全部清点了一遍。

结果是这样的:

项目 官方口径 我从权重里数出来的 差异
Pro 总参数 1.02T 1,024,216,603,392(1.0242T) +0.4%
Pro 每 token 激活 42B 41.89B −0.3%
Flash 总参数 310B(报告)/ 309B(模型卡) 310.76B +0.2%
Flash 每 token 激活 15B 15.45B +3%
视觉塔 681M 681.4M 一致
音频 patch 编码器 127M 126.9M 一致
音频分词器编码器 308M 302.3M(编码器层)加卷积与量化器 一致
蒸馏版 9B 9.41B 一致

每一个数字都能对得上,连「681M 视觉塔」这种边角都对得上——报告的小字写着「编码器参数含输入嵌入、不含投影层」,我按这个口径算,视觉塔的 28 个 block 正好 681.4M,投影层另算 57.7M。

第一个坑:mxfp4 是打包存储的,按字节估算参数会错一半。专家权重在文件里的 dtype 是 U8,一张 down_proj 的 shape 是 [6144, 1024]——但它的逻辑维度是 [6144, 2048],也就是一个字节里塞了两个 4-bit 数。我第一版脚本按元素数直接累加,得到 5240 亿参数,正好是 1.02T 的一半。发现之后按「U8 元素数乘二」重算,才落回 1.0242T。想从下载体积或文件大小反推参数量的人,会被这个坑绊住。

第二个坑:三种精度说法并存。权重索引里的元数据写着 save_format: mxfp4,HF 的标签写着 8-bit 和 fp8,而实际情况是混合的——专家权重是 mxfp4(每 32 个一组带块缩放),多数线性层是 FP8 E4M3,而配置里那份 ignored_layers 名单把全部 70 层的输出投影排除在量化之外、保持 BF16,嵌入与归一化也是 BF16。也就是说,官方文档里的 mxfp4 只描述了专家那一部分(占总参数 97.7%),标签里的 8-bit 说的是另一部分。

顺带得到一个结构上的观察:Pro 每 token 激活的 41.89B 里,专家占 49.7%(20.84B),注意力占 44.7%(18.72B)——两者几乎一样重。原因是 head_dim 192 配上 128 个查询头,qkv 投影一层就是 2.7 万维。MoE 把 97.7% 的参数堆在库里,但每 token 真正动用的计算,有一半还留在注意力上。

证据二:六天直播的日志,对上了什么

训练面板的接口没有鉴权,/api/status、/api/series、/api/benchmarks、/api/notices 都能直接读。我把两次 run 的全部指标拉了下来:

项目 Pro Flash
训练步数 30 30
轨迹总数 752,640 752,640
累计 token 75.0B 81.4B
每步 token(首→末) 1.80B → 3.43B 1.79B → 3.70B
成本 $2,620,671 $854,045
时长 127.5 小时 83.1 小时
重启次数 14 5
基础设施错误率(峰值) 0.98% 3.04%
DeepSWE v1.1(首步→末步) 58.41 → 72.57 48.67 → 65.68

对上的部分很硬:技术报告说 Pro 花了 2.6M 美元、Flash 0.9M,面板上是 2,620,671 与 854,045;报告图 3 说 DeepSWE 从 58.4 涨到 72.6、Flash 从 48.7 涨到 65.7,面板上逐步曲线正好是 58.41 到 72.57、48.67 到 65.68;1,568 乘 16 等于 25,088,乘以 30 步等于 752,640,也都是逐字对得上。合计 347 万美元、每小时 3.08 万美元——媒体算的「约 3.1 万美元每小时」就是这个数。

对不上的地方在「每步 token」。官方发布页写「每次训练步的 token 数达到 3.5~3.7B」,技术报告写 2.7B~3.7B。我把每一步的数值拉出来:Pro 从 1.73B 涨到 3.43B,30 步均值 2.50B,全程没有一步到过 3.5B;Flash 从 1.79B 涨到 3.70B,均值 2.71B。也就是说,发布页那个区间是末期单步的峰值,不是训练的实际水位——报告里的 2.7B 起点同样偏高。

面板上还挂着六条人工通知,我认为这才是「直播」最值钱的部分:

时间 官方在日志里写的话(摘要)
9/17 01:58 更新了 Flash 第 12 步与 Pro 第 8 步的 DeepSWE 离线评测结果
9/17 04:08 一个节点显存出问题,Pro 重启
9/17 10:27 Flash 从第 15 步重跑:某数据集的一类基础设施错误在过去约 3 小时里没被正确检出
9/17 20:20 Pro 集群与评分器之间网络中断,已重启;同时把 cyber 数据集从接下来的 Pro 训练里移除了,因为 rollout 日志里出现了坏 pattern
9/18 11:49 Pro 在第 17 步因专家负载不均导致的 GPU OOM 重启,已调整并行策略
9/19 18:14 我们过滤掉了对当前 Pro 模型来说相对简单的题

技术报告里能对上最后两条:5.5 节写着训练期的失败主要是 GPU 显存双比特错误,以及一次微批次内 MoE 不均衡造成的 OOM——「某一层上,一个专家并行 rank 收到了超过均值 30 倍的 token 负载」。直播里的通知,就是事后复盘时被写进正式报告的那部分;没写进报告的部分,才需要读者自己去对。

把这段通知和面板上的数据集清单对起来看,就出现了第三处对不上。面板给每次 run 列了当前批次里的数据集构成:Pro 是 24 个——11 个 code、4 个 general、3 个 chat、6 个 visual,没有 cyber;Flash 是 25 个,多出 cyber/dataset-9aui。而技术报告第 5.1 节的训练设置写着任务混合包含 4% 的网络安全。

也就是说,从面板能看到的构成里,Pro 这一轮 RL 没有 cyber 数据(再加上 9/17 那条通知,后半程基本可以确认没有),可发布时 Pro 报的是 CyberGym 94.0、内部 Cyber Bench 80.2 这样的网络安全分数。这些分数只能来自 RL 之前的阶段,或者报告那句 4% 描述的是混合计划、不是 Pro 这一轮的实际构成——小米没有解释,公开日志里也查不到补回来的记录。这不是造假,但训练直播最大的价值恰恰是这种能被外部抓出来的口径差:说 30 步、说 1,568 个提示、说 347 万美元都能对上,唯独「训了什么」有一块对不上。

还有一个可以算的账:Pro 这 75.0B token 花了 262 万美元,折合每百万 token 的 RL 成本 34.94 美元。而 MiMo-V2.6-Pro 的 API 输出价是每百万 token 0.87 美元。训练期每 token 的成本,是它自己卖出去的价格的 40 倍——这个比例解释了为什么前沿模型不可能靠 API 收入覆盖训练开支。

证据三:开源开了什么,以及首日的三个可复现问题

三个仓库的权重都能直接下,MIT。Pro 的完整下载量是 573.5 GB:专家分片 563.6 GB、DFlash 草稿 5.5 GB、MTP 2.5 GB、音频分词器 1.9 GB。Flash 178 GB,蒸馏版 19 GB。

训练资源则是另一种形态:GitHub 上那三个仓库——verl(RL 训练框架)、uni-agent(长程 agent 训练)、mimoagent(agentic rollout)——都是别人家仓库的 fork,各自开了一条叫 mimo-oss 的分支,装的是 multi-harness gateway、agentic RL recipes(arvo、code、design、general 四个目录)、rollout 与环境适配器。分支上的提交数是 125(uni-agent)、565(mimoagent)和 2,848(verl,含上游历史),星标 3 到 4 个,issue 0 个。这是研究级的代码投放,不是长期维护的开源项目,别期待有人回你的 issue。

然后是首日就能复现的问题,三个都是我自己跑出来的:

第一,Flash 仓库里的 DFlash 配置不是合法 JSON。dflash/config.json 最后多了一个逗号,json.load 直接抛错,任何按标准流程加载这个草稿模型的脚本都会在这里断掉。Pro 的同名文件没有这个问题。HF 上已经有人提了 PR(第 2 号),截至我写作时仍是 open 状态。

第二,同一份配置里的超参和主配置不一致。Flash 的主 config 里 attention_value_scale 是 0.707,它的 DFlash 配置里却是 0.612——而 Pro 两份都是 0.612。看起来是从 Pro 复制过去之后忘了改。

第三,模型卡把 MTP 和 DFlash 草稿说成了一个东西。Pro 与 Flash 的模型卡都写「MTP:5 层投机解码器」,报告表 1 的「投机解码器」一栏也写 5 层。但权重里那个 MTP 模块只有 3 层(Flash 的 config 也老实写着 num_nextn_predict_layers: 3);5 层的是另一个独立文件,就是前面说的 DFlash 草稿。顺带一提,Pro 的 config 里干脆没有 num_nextn_predict_layers 这个字段,而随包发布的 transformers 建模代码里也一次都没引用它——这两个模块的权重更像是给 SGLang、vLLM 那套推理栈准备的。

另外,技术报告表 1 里 Pro 那一行,「激活参数」印成了 42T(同行的 Flash 是 15B)。这种笔误不影响任何结论,但它提醒你:模型卡和报告是宣传材料,不是规格书。

要自己部署的话,官方给的 SGLang 命令是 16 路张量并行、2 个节点、DeepEP 通信加 EAGLE 投机解码;vLLM 是 8 路。573 GB 是下载量,不是显存需求,但 1M 上下文的 KV cache 和 MoE 通信会把它抬到「要有集群才能聊」的级别。

判断:数字层面很扎实,但别把它读成别的东西

先说值得肯定的。这是我今年核过的国产开源发布里,可验证度最高的一次:参数、成本、每天的进步曲线、失败与重启,全都能从公开渠道复算,而且训练日志的颗粒度比论文更细——技术报告只给了三条曲线和一句「2.7~3.7B」,面板上有每一步 20 多条指标、六条人工通知和 14 次重启的完整记录。这种透明度本身就是发布内容的一部分。

但有三件事别读歪。

第一,「6 天」指的是最后一场 RL,不是模型研发周期。面板上 Pro 的 run 从 9 月 15 日 18:32 跑到 9 月 21 日凌晨 2:01,Flash 更早结束。官方发布页自己写了「这六天背后是半年的基础研究积累与工程试错」。347 万美元是这一场 RL 的账单,不是这个模型的开发成本。

第二,开源的是权重加部分训练资源,不是可复现的训练。预训练数据披露到来源类别为止,约七千个 RL 任务能在框架分支里看到 recipe,但没法把每一批实际任务和某个固定 commit 对上。9B 蒸馏版加那套 RL recipe 其实是这次对社区最有用的东西——比 1.02T 的权重更实用,因为大多数人根本跑不动后者。

第三,榜单数字要打两个折。一个是外部评测的口径:Artificial Analysis 的小米页上,MiMo-V2.6-Pro 的智能指数显示 46(上一代 V2.5-Pro 是 26),中文圈普遍引用的 46.32 是同一指数更精确的小数位。另一个是基准自身的质量:Epoch AI 对 DeepSWE v1.1 的审查认定 113 道题里至少 23 道存在假阴性问题(超过 20.3%),并把整个基准标为 flawed——我读了原文,问题出在验证器会覆盖模型改过的测试文件。面板上那条 58.41 到 72.57 的曲线是这个基准上的,看趋势可以,当绝对刻度不行。与闭源旗舰的差距也还在:ProgramBench 26.5 对 Claude Opus 5 的 37.0,ExploitBench 47.9 对 78.5,Terminal Bench 4.0 是 34.9 对 49.0,GDPval-AA 是 1673 对 1708。

那么谁该动手?做 agentic coding、长上下文、成本敏感场景的人,直接走 API 最省事:Pro 每百万 token 输入 3 元、输出 6 元,缓存命中 0.025 元;Flash 是 1 元与 2 元,批量推理半价。要注意两点:这次新增了一个 mimo-v2.6-pro-ultraspeed 档位,价格是 30 元与 60 元,十倍;另外 V2.5 系列将在 10 月 21 日下线,别把线上业务留在旧模型上。

想做研究者,从 9B 蒸馏版和那套 RL recipe 入手;想自建推理,先数清楚自己有没有 16 张卡和两个节点。至于「1M 上下文」,报告自己写的典型 RL 轨迹长度是 11 万到 15 万 token——容量是容量,有效使用是另一回事。

我核过的那三处对不上——每步 token 的区间、Pro 的 cyber 数据、MTP 的层数——都不改变「这是一次扎实的发布」这个判断。但它们说明一个更通用的道理:当一家公司把训练过程直播出来,它其实同时交出了两样东西:一份成绩单,和一份可以被外部逐条核对的账本。第二样比第一样稀罕得多。

相关阅读:

CUA-S1-FORMS 深度评测:2.8MB 填表模型全量复现 99.95%,域外字段集体放弃

CUA-S1-FORMS 深度评测:2.8MB 填表模型全量复现 99.95%,域外字段集体放弃

9 月 19 日,Cua 把自家第一个「System One」模型挂上了 Hugging Face,文件名 cua-s1-forms。参数 706,048,盘上 2.8MB,只干一件事:看一眼表单里的某个字段,再决定要不要从文档里挑一个值填进去。模型卡给的数字是合成测试 99.95%、真实表单 100%。

中英文圈这几天转的就是这几个数字。中文侧的说法基本是「70 万参数正在挑战千亿参数的大模型」,没有人把权重下下来自己跑过。

我跑了。官方的测试集 test.jsonl 一共 24,370 条决策,我全量过了一遍:24,359 条正确,错了 11 条,99.9549%。声明属实。

但同一份权重,换一批它没见过的字段名,就是另一个故事:我自建了 23 个域外字段,它有 21 次直接选择放弃,平均置信度 0.999。不是「拿不准」,是非常确定地不填。

这两件事都值得摊开说。

一个不做推理的模型在做什么

先说定位。Cua 这家公司做的是「让 Agent 操作真实电脑」的基础设施,cua-driver 负责读界面的无障碍树、发点击和按键。表单填写是这条链路上最琐碎的一环:一张表十几个字段,每个字段要判断「该填哪个值、该不该勾、该不该点、还是什么都不做」。用通用大模型逐字段推理当然能做,但一次表单几十次 API 调用,成本和延迟都不划算。

CUA-S1 的思路是把这件事降级成一个分类问题:不看截图,不做自回归,一次前向出分。

它的输入是两段纯文本。第一段叫 context,描述当前这一个界面元素,最多 224 字节:

TASK fill the form from the document, then submit
FORM Test Insurance - Auto Claim Form
ELEMENT Edit "Policy #" value=""

第二段是选项列表,每个选项最多 96 字节:文档里提前抽出来的每个「标签:值」各成一条 fill,再加上三个固定动作。

选项 含义 谁来执行
fill <文档标签>: <值> 把这个文档实体写进当前字段 下游代码排好顺序后逐步下发
check 勾上这个复选框 同上
click 点这个控件(提交类按钮) 同上,默认只放行标签恰好是 Submit 的
skip 什么都不做 ——

模型输出的只是一个概率分布。argmax 选出选项,剩下的「先填、再勾选、最后提交」由普通代码决定。这一点很关键:模型没有多步规划能力,也不需要。

这套「一次前向、只做选择、不做生成」的思路来自 TypeSafe 的 Jev —— 我们此前拆过那个模型背后的浏览 Agent,也在端到端实测里见过它的静默假成功。CUA-S1 是这条路线上的第一批「单任务」变体:不做通用 agent,只做填表。

内部结构比想象的还小:字节级 embedding(257 × 128)加两层 4 头 transformer 编码 context,另用一个单层 transformer 编码每个选项,最后用一个 option-attention 头把两者打成一组分数。128 维的 query、key、value,除以 sqrt(128)。没有分词器,没有词表,输入直接按 UTF-8 字节切,超出上限就截断。

我在一台装不了 torch 的机器上把它跑了起来

先说方法,因为这篇的可信度全在这里。

我的工作沙盒是 aarch64 的 Alpine Linux。torch 在这个平台上没有可用的轮子(PyPI 只有 glibc 的 aarch64 构建),onnxruntime 同样装不上,官方仓库要求 uv sync 拉一整套依赖跑测试,这条路直接走不通。

于是我从 model.py 逐行移植了一个 numpy 版本的前向传播。要小心的地方不少:PyTorch 的 nn.MultiheadAttention 把 q、k、v 打包成一个 in_proj_weight 张量(384 × 128),得按块切;TransformerEncoderLayer 用 norm_first=True,是预归一化的残差写法;padding 位置在注意力和池化两处都要屏蔽。为了让结果可信,我又手写了一个 ONNX 的 protobuf 解析器和一个小型的 ONNX 图解释器(第三方仓库里有一份导出的 model.onnx,242 个节点、68 个初始化器、opset 18),把它当成第二套独立实现。

三组交叉校验全部通过:

  1. 权重位级一致。把 ONNX 里的 45 个初始张量与官方 safetensors 逐个比对,最大差值 0;safetensors 的 sha256 是 05954c1c…356ddc,与 Hugging Face 上的 LFS oid 完全相同,2,828,784 字节。
  1. 我的输出对得上官方参考概率。官方在数据集里留下了每一条决策的参考概率,我的 numpy 实现跑出来最大偏差 2.4e-6,argmax 一次都没翻。
  1. 参数计数对得上。45 个张量求和正好 706,048,与模型卡声称的一致。

过程里有个插曲值得写出来:我第一版跑出来只有 47.7% 的正确率,差得离谱。逐张量对比之后才发现,是我自己把掩码写反了(np.where 的真值分支放错了位置,又把「全掩码行清零」的判断写反),导致注意力被整体清零、模型退化成「永远偏向 skip」。修掉之后,逐层输出与 ONNX 的最大差值降到 1e-6 量级。如果我没有逐张量对齐,这篇文章就会变成一篇「我实测这个模型只有 47.7%,官方数据造假」的错误结论。

24,370 条测试:数字是真的

官方在 Hugging Face 上把数据集也放出来了:test.jsonl 24,370 条、validation.jsonl 16.8MB、train.jsonl 142.6MB、demo.jsonl 196 条。我把测试集和 demo 集都跑了一遍。

模型卡声明 我复现的结果 判定
706,048 参数 / 2.8MB 45 个张量求和 = 706,048;safetensors 2,828,784 字节 属实
合成测试 99.95%(约 15k 条) 官方 test.jsonl 全量 24,370 条 → 99.9549% 属实,样本比模型卡写的更多
真实表单 100%(196 条) demo.jsonl 196 条 → 196/196 属实
与托管 Jev 对比 99.7% vs 83.6% 没有公开的对比决策集 无法复现
打乱 context 对照 37% 无脚本、无产物 无法复现
「完整数字见仓库 docs/RESULTS.md」 仓库里没有这个文件 缺失

分动作看更清楚:fill 9,802/9,802,check 816/816,click 1,040/1,040,skip 12,701/12,712。放弃率 52.2%,选择性准确率 1.000 —— 只要它决定动手,在这个分布上一次都没做错。

那 11 个错误值得单独拆。5 个是把同一个值重新填一遍:字段里已经写着 NE,它选了另一个文档标签 ST: NE;已经写着 Tomas,它选 First name: Tomas。这类错误在语义上是幂等的,实际执行不会写坏数据。剩下 6 个才是真错:4 个是文档里根本没有对应实体,它从别的实体里硬凑(「Current employer」被填了「Company reg: REG3878384」,「Relation to applicant」被填了车牌号);另外 2 个是字段已经填好,它想用另一个值覆盖,而且置信度高达 0.999。

顺带一个工程发现:同一个表单里,所有元素面对的选项列表是完全一样的,而模型对每个选项独立打分。把重复的选项去重、再按字节长度分桶之后,我的 numpy 实现快了约 300 倍(1,048 条从 188 秒降到 0.6 秒,argmax 一次没变)。这也说明这个模型的推理是天然可缓存的:你不需要为同一个文档实体重复算第二遍。

换个字段名,它 21 次里放弃 21 次

验证完声明,我做了第二件事:把它推到词表外面看看。

仓库里 concepts.py 只有 55 个概念(first_name、policy、vin 这类),每个概念配一组表单标签和一组文档标签。我照着它的输入格式,自造了 4 张表、23 个字段,语义上都明确不属于这 55 个概念:船舶登记号、咖啡生豆含水率、图书馆 OCLC 编号、DBS 证明编号……文档里都为它们准备了语义上一一对应的实体,所以「正确答案」应当是把对应实体填进去。每一张表里也混了它的词汇表内的干扰实体,尽量贴近真实分布。

结果:23 个域外字段里只有 2 个填对,21 个选择了放弃,平均置信度 0.999,其中大多数直接给到 1.000。对照组(「我确认以上信息属实」勾选框、Submit 按钮、浏览器边框元素)16/16 全对,说明不是我的输入格式出了问题。

这个现象不是我先发现的。9 月 19 日,用户 0xsline 在仓库里报了 issue #3978:他的域外集合 41 条里只有 12 条正确(29.3%),其中 36 条回答 skip,平均置信度 0.974。他还做了设备对照(CPU 与 MPS)和批处理对照(单条与整批),41/41 预测完全一致,排除了硬件与 padding 因素。我的实验独立复现了同一件事,而且因为字段名更彻底地落在词表外,数字更难看。

结论要说清楚:这是一个标签匹配器,不是语义理解器。它在自家 55 个概念的分布里几乎是完美的,走出分布之后不会退化成「不确定」,而是退化成「自信地不做事」。模型卡确实写了「只在演示集上验证过、未在任意真实表单上验证」,但没有写这个失败的具体形态 —— 而对下游执行器来说,「不确定」和「自信地放弃」是两种完全不同的风险。

一份「源码优先」发布里的三处对不上

再看治理层。这个组件是 9 月 18 日通过 PR #3964 一次性加进 trycua/cua 的(7,550 行新增、35 个文件、0 条评审意见),三天内已经攒下 12 个相关 issue 和 PR,能看出社区很活跃。但发布材料本身有几处对不上:

第一处是权重。组件内的 README.md 写着「不包含也不下载模型权重、数据集、demo 二进制或录制」,MODEL_CARD.md 的状态栏写着「weights not distributed」,还专门强调「本次仅源码发布不构成任何检查点性能声明」。可同一天,Hugging Face 上就有 2.8MB 权重和四个 JSONL 数据集(合计约 178MB)。仓库根目录的 README 后来改成了「权重另行托管在 Hugging Face」,但组件里的两份文档没跟上 —— PR 正文里那句「不含模型权重、数据集、二进制、录制、原始实验日志、托管供应商对比或检查点性能声明」,和一天后模型卡上的 99.95%、100%、37%、99.7% 是直接矛盾的。

第二处是那份被引用了两次的 docs/RESULTS.md。模型卡说「完整数字见仓库的 docs/RESULTS.md」,仓库里没有这个文件;issue #3977 在 9 月 19 日就报了这个 404,也报了模型卡提供的加载方式根本跑不通 —— 模型卡给的快速开始用的是 pickle 版 .pt,而这个包自己的加载器按设计拒绝 .pt/.pth/.bin/.pkl,理由是「pickle 反序列化对公开检查点等于代码执行风险」。当天 15:30,HF 仓库补传了 safetensors 加 JSON 配置(我下载并校验的就是这一版,格式签名通过),但那份 RESULTS.md 至今没有。

第三处是残留字段。检查点配置里写着 hf_model: "Qwen/Qwen2.5-0.5B",可这个模型是字节级的、根本没有分词器,make_system 的 tinyx 分支不读这个字段,仓库自己的单元测试还断言这种字段配 encoder="hf" 必须被拒 —— 它更像模板里没删干净的东西。检查点元数据里源文件名写的是 jevform-best.pt,第三方声明也说 model.py 里的字节拼装与小注意力原语改编自 MIT 许可的 jevlike 项目。换句话说,这条路线是照着 TypeSafe 的 Jev 那套「System One」思路做的一个独立实现,模型卡自己也承认「不是 Jev 的复现」。

该不该用

我的判断分三句。

它是真的。 你没有理由怀疑 99.95% 这个数字 —— 我把 24,370 条全跑了,一条不差地复现了,还顺手核对出参数、字节数与哈希。在一个到处是营销数字的领域里,这份可复现性值得肯定。

它的适用范围比宣传语窄得多。 55 个概念、英文标签、结构规整的表单,这是它的全部射程。把你自己的业务表单丢进去之前,先用你自己的字段名做一次我上面那种域外探测 —— 如果字段名掉出它的词表,你会得到的不是低置信度,而是一堆 0.999 的 skip。

它的失败方向需要额外闸门。 11 个错误里有 2 个是高置信度的错误覆盖动作;域外探测里 21 个是高置信度的放弃。这两类错误都不会自己举手说「我不确定」,所以下游必须自己加一层校验:把置信度 0.8 以下的决策(正确项平均 0.9993、错误项平均 0.8076,这个差距是可用的信号)挑出来人工复核,并且对「已经填了值的字段」单独做一次幂等判断 —— 那 5 个「重复填同一个值」的错误就属于这一层能拦掉的。

如果你正在做的是「一批结构固定的表单 + 一份抽好实体的文档」这种批处理,而且字段名正好落在它的词表里,这个 2.8MB 的东西确实值得试:CPU 就能跑,不吃 GPU,一次决策的时间成本可以忽略。反之,如果你的表单多变、多语言,或者业务上不允许「悄悄不填」,那它现在还不适合放进无人值守的链路。

权重和数据集都在 Hugging Face 上(cua-ai/cua-s1-forms),测试集是公开的 24,370 条,你完全可以照着上面三步自己验一遍。需要的话,我这套 numpy 实现、ONNX 解释器与全部结果都已留档。

ZCode 开源后我拆了 4 个官方安装包:上传链路确实删了,那个开关却从没管过它

ZCode 开源后我拆了 4 个官方安装包:上传链路确实删了,那个开关却从没管过它

5600 颗星、1600 次 fork、两天——这是智谱把 ZCode 开源之后,GitHub 上给出的数字。而这款工具一周前被开发者抓包:登录状态下,它会把你本地整个代码仓库打包、加密、传到云端。

9 月 21 日,智谱在开源公告里说得很具体:v3.14.0 客户端已移除 Repo Wiki 功能,已切断本地仓库快照的生成与上传链路,并公布了信通院与绿盟的审计结论。

声明可以写得很干净,安装包不会。我把四个版本的 ZCode 从官方 CDN 下下来,解开内部的 app.asar,逐符号比了一遍。

一、三天之内发生了什么

时间 事件
9 月 18 日 开发者抓包:登录后 ZCode 静默打包本地工作区(含完整 .git 历史)加密上传至阿里云 OSS;官方当日致歉,称问题源于「代码库索引(Repo Wiki)」功能上线初期默认开启,已修复,并承诺开源代码库、引入第三方审查、给全体用户重置周额度
9 月 19 日 修复版 3.14.0 客户端发布
9 月 20 日 zai-org/ZCode 仓库建立
9 月 21 日 正式开源(Apache-2.0);公布信通院、绿盟审计结论;创始人唐杰实名投诉小红书网友「偷代码」传闻;社区发现开源版与官网版「不完全一致」

从曝光到开源,三天。速度值得肯定,但三天的信任重建只等于一份声明加一个仓库——能不能自证,要看你愿不愿意把安装包拆开看。

二、我把四个版本的安装包拆开比了一遍

官方说 v3.14.0 切断,我就把这条当假设去验。四个版本全部来自官方 CDN(cdn-zcode.z.ai),Linux arm64 的 AppImage,每个约 200 MB,解开 squashfs 后取出 resources/app.asar,再抽取桌面主进程的打包产物 out/host/index.js 逐符号计数。

符号(主机进程包内出现次数) 3.12.3(9/17 构建) 3.14.0(9/19) 3.14.1(9/20) 3.14.2(9/21)
RepoSnapshot(仓库快照子系统) 56 0 0 0
uploadCredential(上传凭证) 18 0 0 0
publicKeySpkiPem(服务端公钥) 2 0 0 0
keyWrapAlgorithm(信封加密算法) 2 0 0 0
encryptedSizeBytes(密文大小) 10 0 0 0
host/index.js 体积 2,588,119 B 1,496,653 B 1,497,846 B 1,497,917 B

结论与官方口径完全一致:事发前最后一版 3.12.3 里有一整套带 RepoSnapshot 前缀的代码,含 53 个具名函数;从 3.14.0 起,这些名字在客户端里一个都不剩,主进程包一次性瘦了约 42%(1.09 MB)。

同一套代码在命令行运行时里也被删了:3.12.3 的 zcode.cjs 有 3 处 RepoSnapshot,3.14.2 是 0。

服务端一侧也能对上一个便宜的证据。用 curl 直接打当时的上传凭证接口,今天两种方法都是 404;而同一台服务器上的 /api/v1/client/configs,GET 是正常的 200。这不是「全站 404」,是那条路由没了:

curl -s -o /dev/null -w '%{http_code}\n' https://zcode.z.ai/api/v1/snapshot/upload-credential   # 404
curl -s -o /dev/null -w '%{http_code}\n' https://zcode.z.ai/api/v1/client/configs              # 200

三、那段被删掉的代码,到底做了什么

更值得写清楚的是它原来的样子。废掉的 3.12.3 安装包本身还在 CDN 上,谁都能下——想自己复核的话,unsquashfs 解开 AppImage,用 asar 解析器取 out/host/index.js,搜 publicKeySpkiPem 就能看到这段代码。

流程和早先开发者还原的一致,但代码里还有几处此前没被提到的东西:

密钥由服务端掌控。客户端用随机 32 字节密钥 + 16 字节 nonce 走 AES-256-CTR 加密打包好的 tar.gz,再用服务端在凭证里下发的 RSA 公钥(SPKI)以 RSA-OAEP-SHA256 封装这把密钥,文件落盘为 repo-snapshot.tar.gz.enc。私钥从不出现在客户端,本地密文你自己解不开。

上传走 OSS 表单直传。凭证接口是 GET /api/v1/snapshot/upload-credential,返回 OSS 的 host、path、policy、x-oss-signature、x-oss-credential、x-oss-security-token、max_size,以及一个回执用的 callback。客户端组 multipart 表单,把密文以字段名 repo-snapshot.tar.gz.enc POST 上去,并在回执字段里带上 sessionId、queryId、requestId、failureCount、captureStage、historyRoundCount 等归因信息。

.git 被显式豁免了所有过滤规则。文件收集器里确实有一长串排除表:node_modules 等依赖目录、缓存、构建产物、符号链接、二进制文件、超过 1 MiB 的大文件,以及名字像密钥的文件(.env、.npmrc、id_rsa、.pem、.key、.p12、.pfx,以及文件名里含 token 或 secret 的)。但只要路径里出现 .git,函数直接返回「包含」,大小、二进制、密钥名三道检查一道都不跑。所以历史上被删掉的配置文件、早年的测试密钥、内部域名,全都随 .git 目录一起进了压缩包——过滤器拦得住当前目录里的 .env,拦不住提交历史里的 .env。

除了代码,还顺走了你的全局 Agent 配置。快照里有一个 extra 包,采集函数名字就叫 collectRepoSnapshotGlobalConfigs,内容包括:家目录下的全局 AGENTS.md(超过 20 MiB 才截断,截断标记写的是 ...[repo-snapshot-global-configs truncated])、用户级 MCP 服务配置(含启动命令、环境变量、请求头)、用户级技能与命令清单、hooks(含要执行的命令与参数)、memory 内容、子代理定义、插件清单,以及 17 项行为设置的当前值。

那个开关,从来没有管过它。客户端里有个设置项叫 repoSnapshotIndexingEnabled,界面上对应「仓库快照索引」。它在整个主进程包里只出现两次:一次是用户改动它时打个「用户已配置」的标记,一次是作为设置值被塞进上面那个 extra 包。没有一处代码读它来决定要不要采集、要不要上传。早先开发者说「没找到开关控制上传的逻辑」,我这次是从代码层面对上了。

它在你按回车之前就开始干活。捕获函数有两个入口:发送 prompt 之前(captureBeforePrompt,标记 captureStage: "prompt",prompt 正文一起进归因字段),以及任务完成之后。此外本地还有配额管理:单份密文上限默认 2 GiB,最多同时存在 3 份、保留 2 份,磁盘预算 6 GiB——这解释了为什么有人的 ~/.zcode 会悄悄涨到几百兆。

四、开源的那份,和你装的那份

开源当天,社区就发现 GitHub 上的代码和官网下载版不完全一样,「公关式开源」的质疑随之而来。这一条需要拆开说,因为两件事被混在了一起。

第一件,争议代码。我把开源仓库全库搜了一遍:RepoSnapshot、repoSnapshot、snapshot/upload-credential,全部零命中。开源版里唯一带 upload-credential 的地方是反馈附件的上传,那件事写在 NOTICE.md 的对外请求清单里,是用户主动提交工单才触发的。我又抽查了几个只可能来自同一份源码的字符串(例如主进程里那句「任务终态未读裁决」),开源仓库与线上 3.14.x 能对上——修复后的代码,两边是同源的。所以就「你审查的是哪一份 ZCode」这个问题,答案比社区猜测的更清楚:争议中的那段,两份里都没有。

第二件,商业功能。仓库自己的 NOTICE.md 第 70 行写得很直白:「受第三方版权、许可及再分发条件等约束,不承诺提供官方产品的全部功能及活动政策」。开源版少掉的是额度活动一类的商业化能力,官网仍在单独分发完整客户端。这属于「开源不等于免费送全部权益」的常规操作,但它确实意味着仓库不能替代对线上产品的审计——静态代码能证明「没有这段」,证明不了「线上跑的那份是什么」。

顺便说三个开源仓库的硬数据:6,973 个文件、14 个包、84.3 万行 TypeScript;NOTICE.md 27.7 KB,第三方声明 THIRD-PARTY-NOTICES.md 1.98 MB;2 个 commit、0 个 tag、0 个 release。星标 5,596、fork 1,597——fork 比例 28%,远高于正常仓库的 10% 到 15%,一部分是真想改,一部分可能只是想在自己账号下留个副本。

还有一个细节:仓库的 Issues 是关着的(GitHub API 返回 has_issues: false),PR 也是 0 条。官方在公告里说「把代码交给社区监督,欢迎开发者持续检查和反馈」——但反馈入口目前不在这个仓库里。

五、还没被验证的三件事

一、服务端的行为只能靠审计背书。信通院与绿盟的结论都指向同一个点:zcode-prod 的阿里云 OSS 存储桶「云端零数据」、全部对象与桶本身已删除。这对用户是好消息,但两份报告本身没有公开原文,外界看到的是官方转述的结论。国内机构做审计、三天出结论,效率和可信度都摆在那,唯一缺的是可复查的过程。

二、旧安装包还在。事发前的 3.12.3(9 月 17 日构建,199,710,914 字节)今天仍然能从官方 CDN 直接下载。这一点对想自己复核的人是便利,对没开自动更新的用户是风险——修复只在客户端,装了老版本的人不会因为服务端下线而变安全。

三、本地历史删不干净。无论客户端怎么改,已经被打包上传过的内容、以及 .git 里那些「以前删掉的密钥」,都不因为这次整改而变得不存在。涉及生产凭据的仓库,该轮换的密钥还是要轮换。

我的判断

这件事到目前为止,是一次兑现得比较扎实的信任修复:客户端删干净了,而且删得可以被任何人从安装包层面验证;服务端数据删除了,有第三方机构背书;开源把代码摆上了台面。

但信任重建有三条腿,现在只稳了一条。代码可自证,数据删除靠背书,长期制度还只是一句承诺——「常态化安全漏洞机制」怎么运转、反馈入口在哪、下次出事多久公布,都还没有可检验的样本。开源第一天就把 Issues 关掉,恰恰是这种落差最直观的注脚。

给正在用或者准备用的人三句话:

  1. 确认客户端版本不低于 3.14.0,这是官方口径里切断上传链路的分界,我的比对结果与之一致。
  1. 想自己复核,检查 ~/.zcode/v2/checkpoints 目录里有没有几百兆的密文文件;顺手看一眼 ~/.zcode 的总占用。
  1. 在用过老版本的机器上,把 .git 历史里出现过的密钥当作已泄露处理——文件名过滤挡不住提交历史。

—

相关阅读:

关注 AI 商业快讯,每天一篇 AI 热点深度解读。