AI_Admin

微软正式发布新版 Copilot「超级应用」：聊天编程智能体三合一，3000 万付费席位下转向按量计费

作者
微软正式发布新版 Copilot「超级应用」：聊天编程智能体三合一，3000 万付费席位下转向按量计费

3000 万付费席位——这是微软 Copilot 今天改版前交出的成绩单。而它做的第一件事，是把账单的算法换掉。

9 月 25 日，微软正式发布新版 Copilot「超级应用」：把聊天、编程、智能体三种能力塞进同一个应用，分 Home、Code、Autopilot 三个页签。软件开发不用再打开 Visual Studio，做数据看板不用等 IT 排期，交代给 AI 的活你不盯着也能继续跑。

但真正影响你钱包的不是三合一，是配套的计费方式：从按月固定收费，改成按实际使用量收费。

一句话：微软不再试图在消费市场赢过 ChatGPT，它要去赚企业的钱——而且按你用了多少来收。

这次改了什么：三合一，外加一个会自己干活的同事

新版 Copilot 拆成三块，对应三种使用场景。

Home 是默认落地页，把原来的 Copilot 聊天和 Cowork 合在一起，再加一个 Today 面板——微软 AI 工作业务首席营销官 Jared Spataro 的说法是「Home 是你找准方位的地方，回顾最近的动作，看 Copilot 还能帮上什么，把没做完的活接着做」。

Code 是这次最出人意料的页签。按理说它不该出现在一个给知识工作者设计的应用里——现在任何人都能建一个小应用、追踪表、仪表盘或自动化流程，做完直接以云端内部应用的形式分享给同事，全程不用写代码（微软说底层由 GitHub Copilot 驱动）。

Autopilot 是原名叫 Scout 的个人 AI 助理，现在改成云端版，定位是「数字同事」：你睡觉的时候它照样在跑。这个能力的关键差别在于它是「企业级」的——有独立身份、独立记忆、独立工作空间，跑在你公司的账号之下，而不是一个外部工具。

页签 干什么 谁能用、什么时候
Home 聊天 + 协作，加今日面板 未来几周进 Frontier 抢先体验计划
Code 用自然语言做内部小应用/看板 同上；年底进 Microsoft 365 Premium / Pro 订阅
Autopilot 能自己持续干活的智能体（原 Scout） 本月底进私有预览

为什么值得关注：账单算法变了，这比三合一更值钱

这是本文想让你记住的一点：三合一是产品新闻，按量计费才是商业新闻。

改版后的 Cowork、Code、Autopilot 全部走「按使用量计费」。据新浪科技报道，持续运行的智能体任务、以及 Astra、Fable 等模型的调用，都按实际用量收费。原来的固定订阅（微软叫 USL，也就是普通用户许可）仍然保留，覆盖聊天，以及 Office 全家桶里的 Copilot 功能——按微软列举，包括 Word、Excel 等常用应用。

也就是说，微软把 Copilot 的收费切成两层：

计费方式 覆盖什么 谁承担波动风险
固定月费（USL） 聊天 + Office 全家桶里的 Copilot 微软
按量计费（UBB） Code、Autopilot、Cowork 里的持续任务 企业

差别在这里：月费模式下，你用得再多，成本由微软扛；按量模式下，用超了是企业自己付。 对微软来说，这是把「AI 烧钱」的风险从自己账本挪到客户账本上——而这正是过去两年 AI 订阅生意的核心难题。

对企业客户来说，这既是好消息也是新功课：好消息是不用为没人用的席位白付钱；新功课是你的 AI 账单第一次变得不可预测，需要用「成本管理」的思路去管，而不是当成一个固定 IT 支出。

据新浪财经 7 月 30 日报道，纳德拉在财报电话会上说过要整合聊天、编程、智能体做「超级应用」；而据 ZAKER 报道，微软还在推最高五折的优惠，条件是承诺大量席位加特定功能的按量付费——折扣最早 10 月生效。先给折扣、再推按量，这是典型的换计费模型手法。

3000 万席位与它真正想赢的战场

微软对比的参照物不是 ChatGPT，是 Office。

Spataro 的原话是：「就像 Office 定义了 PC 时代的工作方式，新版 Copilot 就是要定义 AI 时代的工作方式。」这个类比暴露了微软的目标客户：不是个人用户，是已经离不开 Office 和账号体系的企业。

数字上，据雪球与网易财经的财报整理，微软单季营收 900 亿美元、增长 18%、运营利润率 45%；Microsoft 365 Copilot 的付费席位突破 3000 万，净增环比翻倍；Azure 增速 43%，全年 Azure 收入首次破 1000 亿美元。

3000 万席位是个不小的盘子。但微软自己也不否认消费端的处境：The Verge 的报道直言，Copilot 在消费市场与 Claude、ChatGPT 相比「算是失败了」。所以这次改版的赌注很明确——不在消费端追赶，而是守住企业端已有的付费盘，靠「企业级安全与管控」把客户留住，并用按量计费把这盘生意的收益天花板抬上去。

值得注意的是时机：据 Yahoo 财经（香港）报道，微软这次明确表示要「放弃消费者 AI 市场、全力聚焦企业应用」。从 Copilot 诞生至今，微软已经重设计过很多次（最早是 Bing 里的聊天机器人），这次三页签方案，是它第一次在消费端和企业端之间做出明确取舍。

谁该关心，谁可以先不动

该关心的三类人：

  • 企业 IT 与财务负责人：按量计费意味着 AI 成本从固定项变成变动项，需要有人盯用量、设预警。微软配套推了「FinOps for AI」来做这件事，值得提前了解。
  • 重度用 AI 编程的团队：Code 页签把「做内部小工具」的门槛降到几乎没有，如果你们一直想给业务部门做小系统却排不上人力，值得在 Frontier 计划里试。
  • Copilot 的付费客户：留意 10 月那轮折扣与计费切换的细则，别在切换窗口期多付一笔。

可以先不动的：个人用户。Code 和 Home 先走 Frontier 抢先体验，Autopilot 本月底才进私有预览——现在还不是普通用户能立刻上手的阶段，不必急着换方案。

一句话判断 + 怎么继续看

判断：这次改版的真正信号不是「三合一」，是微软把 AI 助手从「卖席位」推向「卖用量」。 这一步走通，AI 订阅生意的天花板才真正打开；走不通，按量计费就会变成客户眼里的账单惊吓。接下来两个观察点：10 月折扣落地后企业的实际续费意愿，以及 Autopilot 私有预览后的真实用量数据。

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

相关阅读：

hermes-jev-skills 深度评测：823 Star 的 Jev 决策引擎，1020 个测试全绿、6 个基准我复现 5 个，README 主图却仍取自真实环境

作者
hermes-jev-skills 深度评测：823 Star 的 Jev 决策引擎，1020 个测试全绿、6 个基准我复现 5 个，README 主图却仍取自真实环境

做开源项目评测这些年，我发现一个规律：README 里最响的那个数字，往往是最没人回头核的那个。

所以这回我换了个做法。hermes-jev-skills 这个仓库，我不看它说自己多好，我把它自带的基准脚本全部重新跑了一遍——真金白银买了 Jev 的 API，6 个能复现的实验里 5 个逐格对上了。它是 9 月 18 日建仓、8 天 823 Star 的小项目，MIT，作者一个人维护。

但也是它自己承认了一件事，我先摆在这：README 里那张主图，今天仍然取自一台真实机器。 这一点它自己在 commit message 和脚本注释里写得很清楚，只是图一直没换。

它想做的事：让一个便宜模型替 agent 做小决定

你的 agent 每轮都在烧前沿模型的 token 做那些根本不是「思考」的事：这一轮该哪个模型答、377 个 skill 里该加载哪个、检索回来的哪几段值得读、转录要压缩时哪些轮次该留下、下一步该点哪个按钮。

这些是决定，不是文章。hermes-jev-skills 的做法是把它们交给 Jev——TypeSafe 的决策模型，它从不写文本，你给它一个状态和几道类型化问题，它回你一个带校准置信度的答案。十项技能分别是：模型路由、搜索、记忆过滤、handoff 压缩、轮次取舍、skill 选择、消息分诊、邮箱分拣、computer use、browser use。

这十项都以 SKILL.md 形式发布，所以不止能在 Hermes 上跑——Claude Code、Codex，或任何读 skill 文件的宿主都行。

架构上最值得记的一点：它把请求数当成一等成本。路由的三个问题和 skill 选择的 stage 1 问题被合并进同一次请求——Jev 按请求计费而不是按问题计费。这一点后面有实测数字。

实测一：6 个基准实验，5 个逐格复现

先说方法，因为这是这篇的核心。仓库里每个 scorecard 都附了能「reproduce every number here」的脚本，我就照着跑。做法是：在沙箱里 clone、装一个只有 PyYAML 的 venv，然后用真实的 Jev API key 跑它自带的标定脚本。不是读文档，是重算。

先说不动用网络就能验的：

项 结果
主测试套件 tests/ 1020 个测试通过（skipped=1），28.6 秒，全离线
dashboard 测试 71 个测试通过，2.25 秒
jevkit 第三方依赖 零（AST 扫描：纯标准库）

那 1020 个测试用的是内置 fake transport——这一点它自己在测试文件里点明了：如果 fake 发出的分布形状是 API 根本产生不了的，那套件就会变成「绿着测校验器的拒绝路径」。这句话说明作者知道「测试全绿」本身可以骗人。

然后是花钱的那部分。下面每个数字都是我这次实跑的输出，和仓库 scorecard 对照：

实验 我测到的 仓库 scorecard 判定
calibrate_choose.py 31 cases · 0 wrong actions 同 逐格命中
calibrate_choose_match.py --runs 3 floor 0.65：right 23 / stalled 1 / wrong 0 right 22-23 / stalled 1 / wrong 0 逐格命中
calibrate_choose_stakes.py --runs 3 18 个 gate family 全为 69/1-1/21/0 同表 全表命中
calibrate_choose_permutations.py solo Brier 0.032 对照值 0.032 命中
calibrate_skill_stage2.py --runs 2 单轮折算：stage1 only right 10 / spurious 4；stage1+2 right 14 / spurious 0 同口径 命中
calibrate_skillpick_permutations.py 结构一致（10/0/4/0） 11/0/3/0 一行不同 部分

几条值得单独讲的。

那个 trap case 每次都出现在同一位置。31 个用例里有一个是 Cancel this dialog without losing my work，而错误答案是 Save。原文写它的置信度在五轮里是 0.45-0.60，每一轮都落在 0.65 地板之下，所以从没被放过。我这次测到 0.40 和 0.44——机制完全一致。这种「错答案稳定地出现在地板以下」不是运气，是校准。

分离性数字也对上了。「这个屏幕上没有正确答案」这一类，我用第二个问题测出的上界是 0.45（原文 0.43-0.45）；而正常可答类的下界是 0.78（原文 0.75-0.80）。

permutation averaging 那条结论被复现了，而且是以它失败的方式。有一种做法是把选项顺序打乱多次、把概率向量平均。我实跑的结果是：在 0.65 地板上，averaging 把那个本该被拒的 trap case 变成了 1 个 wrong action——而单次调用是 0 个。仓库据此没有采纳这个做法。它甚至补了一句更狠的：那个错答案在三次重复里有两次是全体一致答错的，所以「一致性检查」这种安全阀根本拦不住。

唯一没逐格对上的是第 6 个，因为口径不同：那个脚本优先读机器上的 fleet catalog（原文是 459 个 skill 的目录），沙箱里没有，于是回落到仓库自带的 10 个 skill。结构对上了，数字不能逐格比。我把这条明确标出来，不混进「5 个命中」。

实测二：数字能验，但有一处它自己承认的缺口

既然数字这么硬，那篇宣传的缺口在哪？

缺口不在基准，在主图。README 介绍 dashboard 那张截图，caption 写着「profiles, paths and decisions here are a demo home」。但图本身来自一台真实机器。

这是我这次用 git 历史而不是看图确认的：

证据 内容
图的引入 commit 0a15c12（2026-09-19 23:32），此后从未被替换
自陈的那次 commit c5875aa（2026-09-20），标题是 Make the README screenshot reproducible from invented data
该 commit 改了什么 只新增 scripts/demo_home.py、改 caption、改 CHANGELOG——没有动那张图

c5875aa 的 commit message 原话是：「The image was taken from a real machine under a caption calling it demo data, which is how a working fleet’s model strategy got published.」它同期新增的 demo_home.py 注释里写着「that is how the current image ended up showing a real working pool set」。

也就是说：作者发现了这个问题、写了工具来生成假数据、在文档里解释了这件事——然后忘了换图。caption 里那句「the pools are a real working set」直到今天还在。

顺带说，demo_home.py 本身有个小 bug 我顺手复现了：它把 --help 当成输出目录路径（main() 直接取 argv[0]，不解析参数），所以 python3 scripts/demo_home.py --help 会在当前目录建出一个名叫 --help/ 的目录树。这不是安全问题，但是这类「脚本没走参数解析」的痕迹。

还有个细节：README 那张表，一半数字买得到一半买不到

这是我觉得最值得记的一条，因为它解释了这个仓库的诚实边界在哪。

README 顶部有一张十项能力的表，每项配一个「Measured」数字。我按「外部人能怎么验」把它们分了三类：

类别 能力 情况
能重跑出数字 choose（两问门、stakes/margin、permutation）、skill 选择 stage 2 evals/choose-match/、evals/skill-pick/、evals/permutation-averaging/ 有 scorecard，我这轮全跑了并对照
有脚本、但要你自己的数据 记忆过滤（evals/context-filter/regret.py）、computer use 的质量（evals/plan-quality/、evals/representative/） 脚本要求「locally held labelled observations」——人类裁决过的真实任务标注，仓库不含语料，也不许用 mock 推断
有 scorecard、但数据明确不公开 handoff 头条那个「58.7% recall alone, 75.0% with one search」 出自 evals/compaction/results/SCORECARD-2026-09-20.md

也就是说：十项能力里，外部人能独立重算出数字的只有三类模型侧决策；涉及真实会话和人工标注的那几项，谁都验不了。这和我上一篇评 laya 是同一件事，只是程度不同——laya 的头条数字连产物文件都没有，这里的第二类至少把脚本和验收口径都写清了（representative/compare.py 甚至会「reject missing arms、duplicates、unknown completion」而不是替你猜测成功），只是语料在你手上。

第三类最值得单说。那个 handoff 数字出自一套实验，输入是 7 个真实工作会话（243 到 614 行、含大量工具调用）加每份 15 道题的考卷。仓库的 README 里写着「Transcripts, exams and capsules stay off this repo」——数据不公开，所以任何人都复现不了，包括买了 key 的我。而这恰好是它全站最响的那个数字。

我特意核对了这段的表意，因为它容易被误读。这张表里 Jev 的表现是分裂的：

对照 结果 说明
Jev 的取舍标记 vs 按 recency 标记 11 胜 4 负 Jev 的判断确实更好
但 Jev 摘出来的 capsule vs plain tail 37.5% vs 48.1% 靠 Jev 写出来的胶囊反而更差

作者自己解释了原因：一个被标为「summarize」的轮次只保留前 400 字符，而七个会话里有五个平均每轮 1,400 到 7,400 字符，任何取舍策略都救不回被裁掉的部分。所以它没有采用 Jev 版 handoff，而是改成整段对话（上限 300,000 字符）+ 1,200 词预算。

这是整个仓库最诚实的一处：它测出自家核心功能没有更好的方案，就没上。表里那些「looked obviously right、measured、not shipped」的两行实验也一样。

还有一处：它把「不省事」也写进文档了

三条我觉得值得抄的工程习惯。

一、fail-open 不是口号，是实测。我在沙箱里故意不给 key 跑：jev doctor 仍然退出码 0；jev mail 把消息标成 unsorted、not_sent_to_jev: 1，而不是崩掉。README 的说法是「No key, timeout, rate limit, malformed reply, low confidence: routing keeps your current model, memory returns the original list, compaction drops nothing」——每一条都有对应的测试。

二、有安全护栏不依赖 Jev 答对。比如「风险词（production / delete / migration / security / payment / legal）永不被路由到最便宜的档」、「大上下文不在会话中途切更便宜的模型」、「转录轮次只在有把握时才丢」。这类护栏的意义是：决策模型错了，损失有上界。

三、隐私边界写得很具体，包括它做不到的部分。README 里有一整节「What leaves your machine」，逐项列出每个功能发出去什么：路由发的是被脱敏的用户这一轮（邮箱、手机、token 遮蔽，上限 2,500 字符），绝不含历史、工具结果、文件、记忆；而且它明说了一个不完美处——默认模式下路由发的是这一轮本身，「the agent has no say in that, because routing happens before it acts」，要彻底不出机器得配 private_profiles。邮箱那条更细：邮件是先解码再筛查（quoted-printable、percent-encoding、HTML entity、base64），因为「a newsletter footer carries your own address percent-encoded in the unsubscribe link」——纯文本脱敏器两个都看不见。

放到同类里看

这一篇要横着比，最自然的坐标是我昨天刚评完的 laya——同样是「决策不用生成」这条路线，同样有 Jev 作为对比对象，同样把「自家模型接近随机」这种难看的数字写在主文档里。

但两者的证据链是镜像的。laya 的 6 张基准表我离线复算逐格命中，而它全站主打的 0.766 准确率在仓库 14 个结果 JSON 里找不到任何支撑文件——那个数字出自一个保存输出数为 0 的 notebook。hermes-jev-skills 反过来：它最响的那批数字（路由、skill 选择、choose 校准）我买了 key 就重跑出来了；它的缺口在一张图，而那张图是它自己公开承认过的。

第二个坐标是评测方法论本身，和我写过的 addyosmani/agent-skills 复测 是同一个问题：自带评测的项目，它的分数该不该信。那次是 25 个技能自评 100% 全绿、我只对上 24%；这次是 6 个基准我复现 5 个，缺口在配图。一个稳定的规律正在形成——看它的评测脚本能不能被你重跑，比看它的分数高低有用得多。

如果你要一句话判断这个项目值不值得看：它的方法论比它的代码更值钱。 把「looked obviously right、measured、not shipped」写进 CHANGELOG、把自己输掉的对照表留在文档里、把「测试全绿可以骗人」写在测试文件顶部——这些习惯，比它那 823 个星更能说明这东西靠不靠得住。

适合谁：跑多 profile agent fleet、模型账单肉疼的团队（路由 + 合并请求直接省钱）；要自托管、不想把工具结果发给第三方做决策的场景（它的隐私边界写得很细）；任何想学「怎么诚实地做自评基准」的开发者。

不适合谁：只想开箱即用的人——它要 Jev 的 key，而 TypeSafe 目前不接受新注册（README 明写），得走 OpenCode Zen 免费层或 OpenRouter 才能起步。不用 Hermes 的人也能用那十个 SKILL.md，但 dashboard 和插件接缝是给 Hermes 做的。以及：它的 README 主图目前还不可信于「demo」二字——这事作者知道，只是还没换。

结论

工程纪律一流，数字经得起重算，缺口是它自己认下的那张图。

我买的 Jev key 花的钱不到一毛（几个 scorecard 自陈总额 under $0.05），换回来的是 5 个基准的逐格复现。在这个「自评数字满天飞」的赛道里，能做到这一点的项目是少数。

但它提醒了我一件更重要的事：连一个连自己输掉的实验都写进文档的作者，也会忘了换掉一张图。所以我的做法还是那句——别信 README 里最响的数字，去把它的脚本跑一遍。跑得出来，那个数字就是你的；跑不出来，它只是个声明。

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

相关阅读：

laya 深度评测：7 天 2.35 万 Star 的决策引擎，6 张基准表我逐格复现，头条 0.766 却查无实据

作者
laya 深度评测：7 天 2.35 万 Star 的决策引擎，6 张基准表我逐格复现，头条 0.766 却查无实据

评测一个 AI 项目时，最省事的做法是信它的 README。最费事、也最值钱的做法，是把它的数字逐个拿回来重算一遍。

laya 这个仓库值得后者。它 9 月 18 日建仓，7 天冲到 2.35 万 Star，Apache 2.0，主打一个很硬的技术判断：决策不需要生成。你不用让大模型吐出一段话再解析，而是给它一个状态和几道题，它在一个前向传播里直接给出带概率的答案。仓库自带 325 行 BENCHMARKS.md，里面既有一张张成绩表，也有一节标题叫「Limits, stated plainly」——把自家模型「接近随机」写进去了。

我把仓库 clone 进沙箱，用纯离线的方式复算了它 6 张核心表的数字。结论分两半：表格部分它经受住了核对，逐格命中；但全站最响的那个数字 0.766 查无实据——仓库里找不到任何支撑它的产物文件。

它想做的事：把「生成」从决策链路里拿掉

先讲清楚技术主张，否则后面没法判断数字的意义。

现在让模型做个判断（这封邮件是垃圾邮件吗、这条客服消息属于哪个队列），标准做法是让它生成文本再解析。慢、贵，而且会幻觉出一个不存在的选项。laya 换了个路子：非自回归。它把「状态 + 类型化问题 + 选项」拼成一个序列，跑一次编码器，决策头直接输出每个选项的概率。没有 token 生成，所以没有东西可解析，也没有东西可幻觉。

一次调用可以同时问好几道题——这点设计上比较讲究。它把用户的问题切成三种原语：

原语 回答什么 输出
choice 从 N 个标签里选一个 N 路概率分布
score 在有序档位上打分 各档位概率
noul 是/否 P(是)

我翻了 laya/common.py 里的序列构造函数，格式是 [CLS] 类型 指令 [SEP] [MASK] 选项0 [MASK] 选项1 … [SEP] 状态 [SEP]。关键在于多个选项共享一个固定的 token 预算 head_max_len，默认 192（英文 checkpoint），超出就按 max(4, (预算-16)//选项数) 均分。这个设计后面会变成它最大的短板，也是它少数几个「架构性」缺陷的根源。

三个 checkpoint 分工也直白：laya 用 ModernBERT-large（421M，512 上下文）主打英文；laya-multilingual 用 mmBERT-base（322M，1024 上下文）覆盖 100+ 语言；laya-typed-decisions 是在四个具体工作流上微调过的版本。配一个 Router 按脚本检测语言来分派——因为作者的实测数据是：英文 checkpoint 在非英文上不是「退化」，是崩掉。

实测一：6 张表我逐格复算，对上了

先说方法。我没有下载权重、没有跑前向传播——这台机器是生产机，1.9G 内存、磁盘余 4G，装不下 421M 模型加 torch 那一套。我做的是两件更硬的事：把仓库里已提交的逐选项概率原始 JSON 拿回来自己重算指标，以及跑它自带的离线审计脚本。这两件事都不需要模型，也骗不了人。

第一张：快路径的同答案性证明。仓库为了证明 GPU 加速路径（TileLang 融合 kernel）不会改变答案，提交了 benchmarks/results/parity_*.json，里面存了每个问题的 fp32 / 标准 bf16 / 快路径 bf16 三组逐选项概率。我从这三组概率自己重算最大偏差和 argmax 一致数：

checkpoint 类型 n 最大 |快-标准| 最大 |快-fp32| argmax 一致
laya choice 48 0.031 0.022 47/48
laya noul 180 0.076 0.043 180/180
laya score 60 0.015 0.011 59/60
多语言 choice 48 0.049 0.015 47/48
多语言 noul 180 0.037 0.045 180/180
多语言 score 60 0.010 0.009 59/60

6 行、18 个数值、12 个一致计数，全部与我重算的结果一致，没有一格对不上。仓库原文还主动写了一处对自己不利的例外：多语言 noul 这一行，标准 bf16 路径其实比快路径更接近 fp32（0.0446 vs 0.0455）。我复算确认了——它没藏这个。

第二张：51 语言扫描。英文 checkpoint 在 MASSIVE intent（20 选项，随机基线 0.050）上，51 语言宏平均 0.2269，只有 23/51 语言超过 3 倍随机；多语言版 0.3661，45/51。这三个数在 cpu_51_language_sweep.json 里逐字对上。更值得记的是它自曝的一个数字：高棉语 0.000 准确率，同时平均置信度 0.952。也就是说，模型读不懂的时候不是「不确定」，是「非常自信地答错」。这也是为什么它的路由必须在前向之前做——靠置信度门控根本拦不住。

第三张：中文基准，我跑了它自带的审计。仓库里有一份 64 条中文工作场景的第三方提交（走 issue #154），带冻结的提示词、原始的 Laya/Jev 配对响应，和一条零下载、零 API 的离线审计命令。我把它跑了一遍，退出码 0，输出：Laya 多语言版单选 20/64、四问组合 18/64；Jev 1.13.0 是 64/64 和 63/64。与仓库文档逐字一致。仓库自己对这份成绩的表述也很克制——明说是 2026-09-21 的历史快照、输入是 AI 辅助编写的合成场景、Laya 跑本机 MPS 而 Jev 耗时含网络，两者不同硬件，不能当排名看。

第四张：温度校准。它承认两个 checkpoint 出厂都过度自信，重量化温度能把平均 ECE 从 0.4656 降到 0.0812（多语言 0.3135→0.1059）。这四个数我在 t4_colab_benchmark.json 里逐个对上了。

第五、六张：延迟与自我修正。T4 上单题 39.5 ms / 32.8 ms、批量后每题 7.2 ms，对上了。还有一处很罕见的操作：仓库自己开了 issue #208，指出已提交的 51 语言扫描里 ECE 那一列是过期的（早于温度钳制），然后重新跑了一遍，把「原始温度」和「实际服务温度」两列并排放在新文件里。我核对了新旧两版：宏准确率 0.2269 三次完全一致，ECE 从 0.7331 动到 0.5709。

一个工程团队把自己已发布的表格标成「这一列不可复现」、再补一份对照，这件事在开源项目里不多见。

实测二：最响的那个数字，仓库里找不到证据

前面四张表都对上了，那问题在哪？

全站最核心的一个数字是 0.766。README 开头第 85 行就这么写：微调后的 laya-typed-decisions 在 2,000 条决策上拿到 0.766 准确率，而基础版只有 0.362。它被用来支撑三件事——「微调后反超 TypeSafe Jev 的 0.727」、「超过 0.735 的 teacher 自一致性天花板」、「完整能力都来自微调」。Hugging Face 上那个模型卡的第一行也是它。

这个数字没有对应的产物文件。我用脚本把仓库里全部 14 个结果 JSON 的路走了一遍，找任何等于 0.766 的 accuracy 条目：一个都没有。更关键的是，这 14 个文件里没有任何一个评测过 laya-typed-decisions 这个 checkpoint。

那 0.766 从哪来？我查到了它的生成路径。它来自 notebooks/laya_finetune_typed_decisions_2xT4_kaggle.ipynb——一个 Kaggle 上的微调脚本，运行后会评测，把数字用 f-string 填进模型卡模板，再连同权重一起推到 Hub。我检查了这个 notebook：19 个 cell，保存的输出数是 0。它被完整提交进仓库，但从未带着运行结果提交。逐项报告的 benchmark_report.json 在 notebook 里是有的，但写盘那一步排在推送之后，所以即使跑完也不会被上传；Hugging Face 上那个模型仓库的文件树里确实没有这个文件，仓库里也没有。

这里必须把话说准，避免冤枉人：

  • 这不等于造假。notebook 的代码本身是干净的——用 train split 微调 1,200 条，用官方 test split 评测 400 条，没有偷看测试集。
  • 更可能的解释是：数字是作者在本地/Kaggle 侧真实跑出来的，只是没把产物提交进仓库。这是可复现性问题，不是诚信问题。
  • 但后果是实打实的：你无法用这个仓库复现它自己的头条数字。同一份文档里，51 语言扫描、校准、延迟都留了原始 JSON 和可跑脚本，唯独最重要的那个 0.766，留在了一个跑不出东西的 notebook 里。

还有一处更隐蔽的：那个 0.727 的 Jev 基准，来源可疑。仓库 research/scripts/bench_apps.py 和 bench_local.py 里，Jev 0.727 的 source 字段写的是——"figure quoted in the laya repo's own comparison table"，即「引自 laya 仓库自己的对比表」。也就是说，「反超 Jev」这个宣称，其基准数字的最终出处是它自己。仓库另一处又列了两个第三方来源（AbdelStark/jev-benchmarks、nibzard/decision-model-benchmark），但那两个来源里都没有 typed-decisions 这一项——AbdelStark 那份是 AG News / Banking77 / DAIR Emotion，nibzard 那份测的是 ECE、banking77 和选项翻转率。仓库正文对此的免责写得很老实（「Jev 从未在这里运行过，没有 TypeSafe 的 API 凭证」「是用于提供背景的已发表数字，不是受控的同台对比」），只是这层循环引用藏在一个 JSON 字段里，不翻代码看不到。

放到同类里看

这个项目要横着比，最自然的坐标是它自己反复引用的 Jev——同一种「一次决策一个请求」的路子，我早前评过的 Jev Ultrafast 深度评测 那篇里，浏览器 Agent 的路径是每次决策只发一个请求。laya 是同一思路走到极致：连请求都不生成，直接出概率分布，还开源可自托管，对 Jev 是闭源 API 这点构成实质差异。

第二个坐标是评测方法论本身，这和我写过的 Archify 复测 是同一个问题：项目自评的数字，和自己能提供的证据之间，缺一条线。Archify 那次是环境报错栽赃，这次是核心指标缺产物。规律很稳定——越是全站主打的数字，越值得先问一句「它的原始文件在哪」。

适合谁：需要低延迟、可自托管、Apache 2.0 的批量分类/打标场景的人。邮件垃圾识别 0.993、钓鱼识别 0.993 这类有明确训练覆盖的任务，成绩是生产级的。以及手上有领域标注数据、准备微调的团队——它的微调路径完整，模型小，单张 16G 卡就能跑。

不适合谁：想要开箱即用的人。它的基础版在 typed-decisions 上 0.362，低于 0.461 的多数类基线，也就是说零样本用还不如直接猜最常见的那个答案。选项数超过 20 的场景也别用——我看了代码，77 个选项均分 192 token 预算，每个标签只剩约 4 个 token，特征被压没了；它自己在 banking77 上就是这么掉到 0.425 的。中文用户还要额外注意：中文基准那次多语言版是 20/64，作者也说明这测的是未微调的基础版、不代表不支持中文，但你要用就得自己补微调。

结论

工程质量第一梯队，证据链有一处硬缺口。

它做了绝大多数开源项目不做的事：把自家模型「接近随机」「低于多数类」「高棉语 0 分却 95% 自信」这些难看的数字写进主文档，自己的过期表格主动开 issue 重测，还留了零依赖的离线审计脚本让别人能核。我复算的 6 张表逐格命中，这部分经得起看。

但那个撑起整个 README 叙事的 0.766，藏在了一个 0 输出的 notebook 里，而它用来对比的 Jev 基准又绕回自己。所以我的判断是：这是一个值得用、也值得信工程能力的项目，但它的头条数字目前只是一个「声明」，不是一个「可复现结果」。你如果要用，别信 0.766——拿你自己的数据微调一遍，那个数字才是你的。

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

相关阅读：

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 解析、字符串匹配）都可复现，任务集与原始结果已存档。

相关阅读：