产品工具

AI 产品发布、工具评测、使用技巧与最佳实践

OpenCode Go 与 Command Code GOAT 订阅横评：$10 档对 $40 档、6 倍对 7 倍额度，一方 5 周里改了 5 次规则

作者
OpenCode Go 与 Command Code GOAT 订阅横评：$10 档对 $40 档、6 倍对 7 倍额度，一方 5 周里改了 5 次规则

如果你每个月在 AI 编程订阅上花钱，这篇文章省的是你的时间：两款最便宜的多模型订阅，过去五周里走的方向完全相反——一款在改规则，一款没动。

OpenCode Go 就是我一直在用的那一档，每月 10 美元。9 月 28 日它多了一个 40 美元的档位；同一天，它的模型列表里少了三个模型。另一家 Command Code 的 GOAT 计划，还是每月 10 美元给 70 美元额度，五周里一次没改。

两边卖的基本是同一批开源模型，连单价都一样。区别在规则怎么写，以及写完改不改。

两个卖家，先认清楚

OpenCode 由 Anomaly 公司维护，就是做 Serverless Stack 那家，2021 年进 Y Combinator。项目现在是这个赛道星数最高的一个，主仓库 21.1 万 Star，MIT 许可，官方说 Go 主要面向「国际用户」。要留意的是：OpenCode 的免费命令行工具本身可以接任何模型，Go 只是官方顺带卖的一档托管服务，买不买都能用工具。

Command Code 是家小公司，12 个人，创始人 Ahmad Awais，今年 8 月拿了 500 万美元种子轮，自己公布三个月做到 600 万美元年化收入。它的命令行工具也放在 GitHub 上——我按官网说法去看了那个仓库：4,060 Star，但里面只有一份说明书，没有代码、没有许可证，最后一次提交停在 8 月 15 日。官网至今写着「本月开源」。

这份资料只说明一件事：两家的体量差着几十倍，风险的性质也不一样。下面全部按官方文档和可复现的实验说话。

三档订阅，摆在一起看

价格与额度截至 2026 年 9 月 29 日，下单前请以官网为准。

OpenCode Go OpenCode Go Plus Command Code GOAT
月费 10 美元 40 美元 10 美元
月度额度 60 美元 240 美元 70 美元
倍数 6 倍 6 倍 7 倍
每 5 小时 12 美元 48 美元 14 美元
每周 30 美元 120 美元 35 美元
单模型上限 15 / 30 / 60 美元 60 到 240 美元 10 到 70 美元
额度用完之后 硬停，或从余额扣（需手动开） 硬停，或从余额扣（需手动开） 转用充值额度，可结转、不过期
模型数 30 款左右 同上 61 款（含 6 款免费）
接口 有，但需订阅且在客户端白名单内 同左 有，订阅即含

表格里最该盯住的是「倍数」那一行：40 美元的档位没有让单价变便宜，只是把天花板抬高了四倍。这一点很多横评都漏了——大家看到 240 美元就以为赚了，其实每花 1 美元买到的额度，$10 档和 $40 档是一样的。

对照着看 GOAT：同样的 10 美元，它给到 70 美元额度，7 倍。而它在 40 美元价位上没有档位，你不需要为了用满额度去升级。

「额度」在这里指的是按各模型公开单价折算的美元用量。你可以理解成两家的额度表都是一张充值卡，卡里的钱只能按官方标价消费，便宜的模型能烧很久，贵的模型几下就没了。

实测一：同一段上下文，两家接口的差别

我准备了一段三千多个词元（token，模型读写文字的最小计量单位，也是计费单位）的假代码库说明，分别发给两家的接口，各发两遍，第二遍专门看缓存。原样复现的结果：

接口 第一遍 第二遍
OpenCode Go 拒绝，提示「需要有效的 OpenCode Go 订阅」 同样拒绝
Command Code GOAT 正常返回，3,494 个输入词元全部按新输入计价 正常返回，其中 3,456 个词元命中缓存

先说清楚边界：我没有订阅 OpenCode Go，所以这一组只跑通了 GOAT 一侧。但被拒这件事本身也是信息——Go 的接口有订阅墙，而且官方还维护着两份客户端名单：一份「已验证客户端」，一份「已知有问题客户端」，文档里明确写着要监控流量、识别「影响其他用户体验的滥用」。换句话说，你想用自己的工具接 Go，得先确认自己在名单上。GOAT 的接口则是订阅即含的一项功能，官方文档里面向接口用户的说明是独立成篇的。

第二遍的结果说明了另一件事：GOAT 宣传的「缓存命中」不是话术。缓存命中，也就是这段内容之前算过、这次直接取用，不用重算一遍。同一个上下文重发，九成九的输入走了缓存价——按官方标价，缓存读是每百万词元 0.003 美元，只有新输入价的五十分之一。这就是它敢喊 7 倍的底子：聊天式编程里，请求的大头是重复的上下文，缓存把这块成本压到几乎为零，省下来的才变成你的额度。

实测二：把两个月的真实账单算一遍

我把自己机器上 8 月 17 日到 9 月 29 日每一次请求的词元记录导出，按两家官方标价折算成美元：

模型 请求数 输入词元 输出词元 缓存命中率 折算金额
DeepSeek V4.1 Flash 2,736 3.13 亿 238 万 98.5% 3.07 美元
MiMo-V2.5 1,274 3,670 万 65 万 93.2% 0.62 美元
DeepSeek V4 Flash 123 1,217 万 10 万 89.2% 0.29 美元
Hy3 37 137 万 8 万 82.7% 0.12 美元

按月合计：8 月 0.88 美元，9 月 3.23 美元。两个月加起来刚过 4 美元。

这意味着我一个月实际产生的用量，只占 GOAT 70 美元额度的 4.6%，占 Go 60 美元额度的 5.4%。

这个数字改变了整篇文章的结论方向。对用量和我一个量级的人——每天几十次调用，跑真实项目——「6 倍还是 7 倍」「30 款还是 61 款模型」根本不构成选择依据，因为两家都给得太多、多到用不完。真正决定你这笔钱值不值的，是另外三件事：

第一，额度规则会不会被改。你付的是订阅，不是合同，额度表随时能重写。

第二，你的调用方式在不在允许范围内。额度再高，接口不让你接也是零。

第三，用不完的部分能不能顺延。每月清零还是可以攒，差别很大。

过去五周，两家各做了什么

下面每一条都能在官方更新日志、官方文档或公开提交记录里核到。

OpenCode Go 一侧：

日期 发生了什么
8 月 24 日 更新日志写「移除过时的 OpenCode Go 首月折扣信息与定价」，5 美元首月优惠取消，变成实打实的每月 10 美元
9 月 9 日 限额口径从「每 5 小时 12 美元、每周 30 美元、每月 60 美元」改成按模型分别算，15 到 60 美元不等；文档里那句「多数模型给到 6 倍」的措辞被删掉
9 月 10 日 唯一一款 100 美元额度的模型从文档消失，单模型上限落到 60 美元
9 月 13 日 DeepSeek V4.1 Flash 被标成「4 倍促销，9 月 20 日结束」，额度从 15 美元临时提到 60 美元
9 月 28 日 40 美元的 Go Plus 上线。同一天提交的文档改动里，GLM-5.1、Qwen3.7 Max、Qwen3.6 Plus 三个模型从列表移除；官方文档站点当日还没更新

后三条来自第三方价格追踪站，前两条可在官方更新日志与文档历史中核到。9 月 28 日的改动我是从合并进主干的文档提交里挖出来的，方式是打开仓库的改动记录比对模型列表。

把这张表横过来看，五个动作指向同一件事：先把新用户的优惠收掉，再把限额口径改得更难比较、有效上限更低，然后下架高额度模型，用限时促销补一下，最后开一个四倍价格的新档接住撞墙的人。 每一步单独看都解释得通，连起来看方向很清楚。

Command Code GOAT 一侧，同期只有一次收紧：9 月 19 日把免费的 LongCat 2.0 转成付费。其余全是加码，而且都带着日期和期限：MiMo V2.5 降价 98%、MiMo V2.5 Pro 降价 99%、MiniMax M3 加倍、DeepSeek V4.1 Flash 提到 60 美元并写明「无结束日期」，另有四到六款限时免费模型。

这里必须说一句公道话：Command Code 也在变化，它一样会把模型塞进「新模型先按 20 美元额度」的池子，等谈到更好的算力合同再往上调。差别不在「改没改」，而在改的时候说不说、以及改完后你还能不能算清楚自己买到多少。

接下去会怎么样

下面的判断部分是我的推测，不是事实。

最可能的情形（我估六成）：开源模型的价格战还在打，两边都不必大砍，但都会继续做小改动。OpenCode 的 40 美元档大概率会变成事实上的主力档，那个 15 美元额度的层级会吞掉更多模型；GOAT 会守住 70 美元的名义额度，同时让更多新模型落进 20 美元那一档，再慢慢退掉一两项老优惠。你无论选谁，都不会在今天这个价位上被立刻背刺。

乐观情形（两成）：推理成本降得比补贴烧得快，两边都维持甚至加码，你躺着受益。

不利情形（两成）：其中一家做断崖式调整。这里风险更高的是 Command Code——12 个人、500 万美元融资，每月掏出相当于 70 美元的量卖 10 美元，这是典型的增长期补贴，停掉融资就得纠正，而且会是急刹车。OpenCode 的风险反过来是慢刀子：它不太可能一夜之间变脸，但会像上表那样每两周挪一格，你很难找到一个明确的离开信号。

一句话：你是在选「低厂商风险 + 中高政策风险」还是「中高厂商风险 + 低政策风险（只要它还在增长）」。

谁该买哪一档

按用量画像给三条规则：

如果你的用量和我差不多，一个月连 5 美元的额度都烧不到，那这两家你都不缺，选你顺手的那家命令行工具就行。这种情况下我推荐 GOAT，理由不是额度：它的接口是订阅自带的功能，你不用去查自己有没有被列进白名单。

如果你一个月真的能烧掉 30 到 60 美元额度，那 Go Plus 和 GOAT 的对比才有意义：同样想拿到更大的池子，Go Plus 要你付四倍价钱，GOAT 只付一份，多出来的容量靠充值额度补，而且充值部分可以攒着不过期。这种情况下 GOAT 明显更划算。

如果你的活必须依赖 Claude、Gemini 或最顶级的闭源旗舰模型，两家都不适合你。Go 的名单里没有它们，GOAT 的 10 美元档也没有（要到 20 美元的 Pro 才有）。这不是省钱能解决的问题。

反过来说，不适合的人还有一类：需要企业采购流程、发票、SLA 的团队。Command Code 的企业档要单独谈，OpenCode 的团队空间目前免费但官方说定价待公布——当成临时免费看，别当承诺。

判断

长期主用 GOAT，OpenCode Go 留着当备份。理由排序是：接口是订阅含的、额度用不完也没有清零焦虑、主用模型身上挂着「无结束日期」的明文承诺。

但这次评测真正的结论不是选谁，而是：在 10 美元这个价位上，两家给的额度都已经远超普通开发者的实际消耗。上面那两个月不到 5 美元的账单就是证据。所以别被 6 倍 7 倍的宣传词牵着走，把注意力放到那些会真的影响你的地方去——额度清零还是结转、接口让不让你接、规则改了之后你多长时间才能发现。

三条具体做法：别一次性囤额度，两家的「不过期」承诺都撑不过厂商本身出问题；每月重看一次额度表，那几行小字是最早的预警；如果你和我一样用量很轻，把官方接口直连也配好，多一条退路比多一档订阅便宜。

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

相关阅读：

—

本文为独立评测，与文中厂商无利益关系，未接受任何形式的赞助或免费额度。定价与额度信息引自各厂商官方文档与更新日志，截至 2026 年 9 月 29 日；真实用量数据来自作者本机 2026 年 8 月 17 日至 9 月 29 日的请求记录。

Today 深度解析：齐俊元的个人 AI 助理，注册送 1 亿 token、传估值 25 亿美元，应用商店却只有 8 条评分

作者
Today 深度解析：齐俊元的个人 AI 助理，注册送 1 亿 token、传估值 25 亿美元，应用商店却只有 8 条评分

换一个 AI 助理最烦的不是学新界面，是它对你一无所知：你是谁、你在忙什么、上周交代到一半的事，全得重新讲一遍。9 月 24 日上线中国大陆的 Today，想解决的正是这件事——注册就送 1 亿 token（大模型处理文字用掉的计量单位，像手机流量）加一个月 Pro 权益，基础版永久免费；而它背后的公司成立两天就拿到 1000 万美元天使轮，如今被传估值 25 亿美元。

先说清边界：我没有下载安装 Today，也没有注册账号。下文所有数字与说法都来自公开可查的一手材料——官网与官网公布的版本条款、两个地区的隐私政策与服务协议、苹果应用商店的公开数据、公司团队自己上播客的口述，以及国内媒体的报道。凡是它没公开的，我不替它补。

它是什么：一个想「先认识你」的助理

Today 的官方自我介绍有两句，中英文各一版：英文站写「懂你的助理，在你开口前就行动」，中国站写「懂你所想，为你先行」。36 氪的报道里还引了更硬的一句定位：「拥有自主思考能力的操作系统，一切以你为中心」。

打开后它会给你四个主区域：今天（当天要关注的事）、任务（你说的事和它自己排的活）、记忆（它对你形成的了解，可看可改可删）、能力（连接的应用与服务），另有一个可以给助理起名字、换性格的「AI 伙伴」。

这套结构跟主流的编码助手完全不是一回事。那些助手以任务为单位组织工作，你派活、它交付；Today 想以人为单位组织一条持续变化的时间线，任务可以从你的状态变化里自己长出来。品玩在一篇记录了深度体验的文章里打过一个比方：前一种保存的是「这项任务进行到哪」，后一种保存的是「这个人现在处于什么状态」。

它把「记忆」拆成了三种寿命：用完即弃的（搜邮件时敲的临时关键词）、有明确时效但任务结束前必须留着的（对方说周四前给材料）、真正值得长期留下的（稳定习惯、重要关系、长期目标）。

品玩写到，Today 会从一组分散行为里推导更稳的判断——比如发现你装过几个 AI 创作工具，就归纳出「长期关注 AI 产品」，再据此把这类产品的变化推给你。

它的「主动」也是这么来的。同样是品玩的体验记录：第二天收到对方回信时，Today 在没有人重新下指令的情况下自己把新邮件和前一天的任务接了起来，判断下一步该怎么推进，再回来提醒人。

同一个记录里还有个更细的例子——它注意到用户装了某个 AI 音乐工具，于是主动提醒该工具的下载政策要收紧，让用户提前处理要留的作品。

一句话：通用助手等你带着任务来，Today 想先把你的邮件、日历、关系和没做完的事组织成一个围绕你转的世界，再从这个世界里产生任务。

我把官网、条款和商店数据逐项核了一遍

这一节是全文的骨头。因为没装，我把能公开核实的部分全查了一遍，查的地方和查到的结果都放在表格里，正文只留结论：

我查的 去哪查（都是公开一手） 查到什么
支持哪些设备 两个官网的下载页 桌面端六种安装包（Mac 苹果芯片 / Mac 英特尔芯片 / Windows 64 位 / Windows ARM / Linux 64 位 / Linux ARM），移动端 iOS 加安卓，国际站与中国站各一套下载地址
装一个有多大 安装包的实际字节数 Mac 苹果芯片版 164,458,641 字节、Windows 64 位版 151,645,672 字节、Linux 版 136,362,218 字节、安卓安装包 19,370,341 字节
客户端多新 安装包的构建时间 全部构建于 2026 年 9 月 27 日，也就是本文写作前两天
手机版什么状态 苹果应用商店公开数据 iOS 版 1.19.1，2026 年 8 月 27 日上架、9 月 19 日更新，安装包 84,436,992 字节，免费；当前评分 5.0 分，评分条数 8 条
有哪些档位 官网服务协议 免费、Pro、Ultra 三档；符合条件的账号可领 7 天 Pro 试用，Ultra 目前没有试用；Pro 与 Ultra 按月订阅
卖多少钱 品玩体验记录里看到的订阅页 Pro 每月 20 美元，Ultra 每月 200 美元（协议本身只写「购买前页面会展示价格」，没把数字写进条款）
模型是谁家的 国际版隐私政策 写明可能调用亚马逊云服务、Anthropic、OpenAI 等第三方模型与云推理供应商（名单以官网公示为准，可能变动）
中国版谁在运营 中国官网备案与中文协议 汇翮（上海）智能科技，备案号沪ICP备2026015004号-3；仅向年满十八周岁的用户提供
公司什么来头 工商与媒体报道 此间无限（上海）智能科技 2026 年 3 月 4 日成立，两天后官宣 1000 万美元天使轮（IDG 资本、阶跃星辰），距离公司注册到产品在国内上线不到七个月
域名什么时候来的 品玩的采访记录 创始人齐俊元在 2014 年就买下了这个域名，当时想做个人助手，技术条件不够，隔了十二年重启

两个细节值得单独说。

一，中国站和国际站是两个主体、两套域名、两套法律文本。国际版服务条款约定适用新加坡法律、由新加坡法院管辖，并把数据出境写成常规安排。中国站协议签订地是上海、适用中国大陆法律，隐私政策把中国大陆用户的个人信息「原则上存储在中国大陆境内」，确需出境要单独取得同意，还要做安全评估或标准合同备案。

同一个产品在两地的合规姿态完全不同——如果你是冲着国际版去的，别拿中文站的隐私政策当准。

二，它的数据清单长得让人停一下。中文隐私政策里，它要处理的信息包括账号信息、你提交和它生成的内容、设备与日志、订单与支付、健康与健身数据（睡眠、心率、血压、血糖、经期、心理状态量表……）、语音、剪切板。健康数据在大陆法下属于敏感个人信息，需要单独同意，且明确不用于广告、营销、征信、保险核保和招聘。

这句话写得比同类产品清楚，但反过来也说明它要的权限范围有多大。

三处硬约束，它自己写在条款里

一、付费：免费是真免费，但取消要自己动手。 中国站服务协议写得很直白：卸载应用、退出登录、注销账号都不等于取消自动续费，你得回原购买渠道取消；自动续费前至少提前 5 天会再提醒你一次；费用除非法律要求否则不退。换句话说，「基础版永久免费」是成立的，但试用结束后的扣费路径要你自己走一遍。

二、记忆越准，越依赖它推导得对。 它记的不是你的原话，而是从你的行为里推出的判断。推对的时候体验非常好——品玩记的那个例子（从你装了哪些 AI 创作工具推出你长期关注 AI 产品，再把该领域的变化推到你眼前）就是这么来的。

推错的代价也被这篇体验记录点出来了：记忆累积久了，旧状态和新决定会混在一起，已经结束的事可能继续影响判断。团队给的解法是主动遗忘、压缩和更新，按信息的类型、时效、未来价值来决定去留——这是产品设计上的选择，目前还没有第三方验证。

三、它记住的东西，边界在协议里。 国际版隐私政策承诺不拿可识别的聊天内容、附件和健康数据去训练面向公众的基础模型，也承诺不成批出售个人信息；中国站协议则要求你在医疗、法律、金融、人身安全这类事项上不能把它的输出当唯一依据。

这两句话合起来才是完整的阅读方式：它不会被拿去喂模型，但它的判断仍然是要你自己复核的。

25 亿美元估值，要跟什么比

关于钱，需要先分清哪部分是官方信息：媒体报道里出现过两个数字——今年 3 月官宣的天使轮是 1000 万美元，投资方是 IDG 资本和阶跃星辰（阶跃星辰同时提供底层模型支持，这一点多家媒体一致）；而 25 亿美元估值目前是传闻，未见公司确认。

把这个传闻放进同类坐标系里，反差就出来了：

产品 融资情况 报道中的估值 成立时间
Today（此间无限） 1000 万美元天使轮（多家媒体一致） 25 亿美元（传闻） 2026 年 3 月
Instinct 累计 3.5 亿美元（4 月种子轮、7500 万美元 A 轮、8 月 26 日 2.5 亿美元 B 轮） 25 亿美元 2025 年
River AI 11 亿美元种子轮加 A 轮（英伟达、AMD 参投） 未披露 2026 年 6 月

同一张 25 亿美元的牌，一家是拿了 3.5 亿美元换来的，另一家用 1000 万美元就传出来了——这就是当下「个人助理」这个方向的热度与泡沫同时存在的证据。

评论这个赛道的报道都提到同一处风险：把邮箱、短信、日历、支付的权限交给一个助理，等于交出数字生活的钥匙；而一个会自作主张的助理在关键事务上出错，代价可能远高于省下的时间。

回到产品本身，适合谁：手上已经有编码助手、但经常要重复交代个人背景的人，以及愿意先花几天让它读邮件和日历、再等它把记忆养起来的人。

不适合谁：需要稳定服务和售后保障的企业场景（它自己写明只对个人、且服务可能随时调整）、不愿把健康和日程数据交给第三方的用户，以及期待「装上就变聪明」的人——记忆型产品的价值曲线是往后走的，前几天大概率不如你惯用的助手。

判断

一句话结论：它值得放进观察清单，但现在还不值得你交出全部权限。

它的思路是对的——模型能力不再是瓶颈之后，个人助理真正的差异就在「对你的了解」这件事上，而这需要时间积累，积累的前提是信任。它的账也已经很明白：Pro 每月 20 美元、Ultra 每月 200 美元，要靠订阅收入去覆盖模型调用和 24 小时云端电脑的成本。

能不能跑赢这笔账，取决于记忆和主动提醒创造的价值是不是真的多于它带来的打扰与解释成本——这一点只能靠真实用户的留存数据来回答。

我们之前评过几个记忆系统的开源实现，结论都是同一条：记忆的难点不在记得住，而在忘得对、更新得准。Today 把「主动遗忘」写进了产品设计，方向选得对，但这条路要靠公开验证。

你真想试，建议按这个顺序：先用免费档只接日历和笔记，跑两周看它推给你的东西有多少是你真想知道的，再决定要不要放开邮件。

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

相关阅读：

Omarchy 深度评测：DHH 的 Linux 发行版 18 天被下载 20 万次，把 sudo 免密做成 15 分钟开关

作者
Omarchy 深度评测：DHH 的 Linux 发行版 18 天被下载 20 万次，把 sudo 免密做成 15 分钟开关

想给旧笔记本换系统的人，最近很难绕开一个名字：Omarchy。它是 Ruby on Rails 作者 DHH 做的 Linux 桌面发行版，上线 18 天被下载 20 万次，GitHub 上 4.3 万 Star，一个月里连发五个版本。它的主卖点不是快、不是省资源，而是：让 AI 智能体（agent，能自己多步干活的 AI 程序）替你改系统。

宣传页上的说法是「vibe code 你的操作系统」「agent 会排查所有问题」。但把它的官方手册、几份版本说明和仓库结构翻完之后，我看到的是一份它自己写出来的风险清单：管的越深，要收的权就越多，而它把这套动作做得相当自觉。

先说清边界：本文没有在本机装一次 Omarchy（这台机器跑不了图形桌面，也没法复现安装流程），所以下文所有结论都来自公开可查的一手材料——GitHub 仓库接口、官方发行说明原文、51 篇官方手册、官方新闻与赞助页面。凡是它自己没公开的数字，我不替它补。

它是什么：一个把「改系统」外包给 agent 的桌面

Omarchy 不是从零写的操作系统，它建立在三块现成的东西上：发行版底子是 Arch Linux，窗口管理是平铺式的 Hyprland（窗口自动排满屏幕、不用鼠标拖），桌面外壳用的是 Quickshell 这套工具包。它做的事是把这堆零件调成一个开箱能用的整体：装完就有终端、编辑器、浏览器、办公套件、剪辑软件，连主题配色都是配好的。

今年 8 月 14 日发的 4.0 版（代号 Quattro）是一次大改：整个桌面外壳用 Quickshell 重写进了一个常驻进程，还带上了插件机制——第三方可以写小组件，甚至整个替换状态栏，装插件的命令是一条 omarchy plugin add 。老的 Waybar、Walker、Mako、hyprlock 这些独立小工具全被替换掉了。

真正体现它定位的是 AI 那一块。官方手册里列了 13 个编程 agent 命令行默认预置好，装了只是个懒加载的壳，第一次真用的时候才去下载。名单里既有最主流的 Claude Code、OpenAI 的 Codex、开源圈常用的 OpenCode，也有 GitHub Copilot 和 Cursor 这两家的命令行；小众的像 Charm 家的 Crush、Nous Research 的 Hermes，新出的有谷歌的 Antigravity 和 OpenRouter 的 Ori。它还自带一个「Omarchy 技能」，让 agent 能直接改你的窗口配置、状态栏、甚至从零生成一套主题。

实证：我把仓库、版本说明、51 篇手册逐项核了一遍

这一节是全文的骨头。因为没装系统，我把能公开核实的部分全查了一遍，命令和文件名放表格，正文只留结论：

我查的 去哪查（都是官方一手） 查到什么
仓库规模与结构 GitHub 仓库接口的文件树 1,947 个文件、约 77MB；命令脚本 467 个、桌面外壳 15 个插件模块、内置主题 22 套、系统迁移脚本 133 个
用户手册 仓库 manual/ 目录 51 篇，从热键、主题、剪贴板到安全、双系统安装都有
给 agent 看的说明书 仓库 AGENTS.md + agents/skills/ 7 篇任务指南：改命令、写安装脚本、改桌面外壳、写图形验收测试等
测试 仓库 test/ 目录 360 个测试文件，含一类图形界面的验收测试
版本节奏 官方发行说明 66 条 4.0.0 于 8 月 14 日发布；4.0.1 到 4.0.4 分别落在 8 月 25 日、8 月 31 日、9 月 8 日、9 月 15 日
代码活跃度 GitHub 提交接口 累计 6,685 次提交；最近 30 天 404 次、最近 90 天 1,342 次
用户压力 GitHub 搜索接口 未处理的 issue 2,068 个、已关 2,888 个；未合入的 PR 2,635 个、已合 3,807 个
官方口径的热度 官网新闻页 Quattro 上线 18 天 20 万次 ISO 下载，峰值每小时 1,165 次，来自 215 个国家地区
它自己承认的风险 manual/17-ai.md、manual/48-security.md 见下一节，这是本文最值得看的部分

两个细节值得单独说。

一，仓库地址已经从 basecamp/omarchy 永久跳转到 omacom/omarchy，也就是迁到了项目自己的组织名下。个人项目变成机构项目，这一步是分水岭。

二，未处理的 PR 数（2,635）比未处理的 issue 数（2,068）还多，已关 issue 和已合 PR 加起来 6,695 条。一个人做不过来的量，这也是它后面要讲资金和团队的原因。

它自己写下的风险，和补丁日志里最密集的一类问题

这是我翻完手册后最意外的地方。宣传页说「agent 会排查所有问题」，手册里却自己列了三处风险，而且写得比宣传页细：

  • 默认 agent 用 Super + Shift + Ctrl + A 启动，手册原文说明它以「不停下来问」的模式无人值守运行，并且提醒你「ready for them to actually do things」（准备好它们真去动手）；
  • 它自带的那个「改系统」技能，手册直接标注为实验性，还建议你先在计划模式下看它打算改什么，并「准备好回滚，甚至准备好重装全部配置」——因为它可能把事情搞砸；
  • 免密 sudo（也就是让 agent 不用每次输密码就能以管理员身份动手）做成一个 15 分钟的开关，到点自动收回，重启也能清掉。手册自己写了一句大实话：开关打开期间，任何以你身份运行的进程都能不经询问做任何管理员操作，「这正是它的意义，也正是它的全部风险」。

这已经是罕见的坦白了。更说明问题的是补丁日志。

安全团队是今年才成立的，官网团队页上列了 6 个人。接下来的三个版本——8 月 25 日的 4.0.1、8 月 31 日的 4.0.2、9 月 8 日的 4.0.3——发行说明的主线都是「一批经过安全团队验证的修复」。4.0.1 那一版的发行说明里，安全修复列了 11 条，其中有 5 条是同一类毛病——本该只是数据的东西被当成要执行的命令：

  • 视频标题里的内容会被当成命令执行，已堵住；
  • 通知的点击动作能被塞进任意指令，改成按安全参数执行；
  • 装插件时，插件地址能被拿去做非预期的网络操作，已加校验；
  • USB 设备名能被当成脚本执行，已堵住；
  • 装好的主题本来只是样式文件，却能执行代码，已堵住。

同一批里还有一条更直接：启动 Claude 和 Codex 时，从「完全绕过审核」改成了「自动复核」。一个把 agent 当一等公民的系统，补丁最密集的地方就是 agent 能乱来的地方——这不是黑它，反而是它能持续公开发版的理由：问题被写进发行说明、被署名、被关掉。

再往下一层看资金和团队，逻辑就完整了。

钱从哪来：12 位百万美元个人赞助，加三家云厂商

Omarchy 的钱不走公司账，走的是新成立的 Omacom Foundation。官网赞助页列得很清楚：

  • 个人「创始赞助人」12 位，各 100 万美元，名单里有 Shopify 的 Tobi Lütke、Stripe 的 Patrick Collison、戴尔创始人 Michael Dell、Twitter 前 CEO Jack Dorsey、Cloudflare 的 Matthew Prince、Dropbox 的 Drew Houston、Coinbase 的 Brian Armstrong；
  • 企业「创始赞助人」三家：Meta 超级智能实验室、DigitalOcean、阿里云，各承诺 100 万美元/年、连投三年；
  • 还有一批 10 万美元级的赞助方：做密码管理器的 1Password、DHH 自己那家做项目管理软件的 37signals、模型推理服务商 Fireworks
  • 另有六家做模型调用通道的公司也在名单里，其中包括 OpenAI 和 OpenRouter

官方新闻页的时间线也能对上：9 月 3 日宣布募资到 1,300 万美元，9 月 9 日 DigitalOcean 300 万，9 月 22 日阿里云 300 万（并合作做「面向中国本地的 CDN、聚会」，还写明要针对通义千问模型做开箱调优），中间还有一轮 51 万美元。

钱的去处是发工资。基金会目前三位全职：负责内核的 Krzysztof Wilczyński、负责桌面外壳的 outfoxxed（Quickshell 的作者本人）、负责基础设施的 Emir Beganović。9 月 26 日又请到了 ThePrimeagen 进核心团队管「agent 质检」。另外官网还给 Mac、骁龙芯片分别组了团队。

赞助名单和阿里云那条合作的措辞，其实点明了这门生意的逻辑：云厂商和大模型厂商乐意掏钱，因为一个把 agent 装进桌面的操作系统，是模型调用的新入口。

判断：三类人，三种答案

一句话结论：它值得试，但前提是你接受「这是台要自己收拾的机器」。

适合装：手上有一台放着的旧笔记本或旧 Mac、想体验平铺桌面和 agent 干活的人；以及想就地学 Linux 系统管理的人——它的手册写得比多数发行版认真，51 篇按主题排好，出问题有得查。

先别装主力机：靠这台机器赚钱、或者只会用图形界面的人。理由不是它不稳，而是它的默认设定主动把 agent 权限拉满、又靠临时开关收回，这套设计的代价要你自己判断。想稳，等版本节奏慢下来，或者挑一个社区复刻了它配置的成品方案。

别装：需要长期稳定支持（LTS）、需要合规审计、或者公司设备不允许 agent 自主执行命令的场景。

最后一件事，也是我觉得这个项目最值得学的地方：它把「我这样做有什么风险」写进了产品文档里——免密 sudo 的开关页写「这正是它的全部风险」，agent 技能页写「准备好回滚」，补丁日志把每一条被堵住的洞署名列出来。对照我们上周评的那个省 token 技能：它宣传页上的数字从后端撤下了，仓库简介里那句旧话却还挂着。一个项目敢把自我批评写在用户会看到的地方，比它的配色和动画更值得抄。

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

相关阅读：

caveman 深度评测：10.8 万 Star 的省 token 技能，简介还写 65%，自家文档只认 8.5%

作者
caveman 深度评测：10.8 万 Star 的省 token 技能，简介还写 65%，自家文档只认 8.5%

用 Claude Code 的人大多盯着屏幕右下角那个额度条一路往下掉，然后就习惯性地把指令写得更短一点（prompt，也就是你给 AI 的那句要求）。有个开源技能说不用——让 AI 反过来说话短点就行，最多能砍 65% 的计费单位（token，模型读写文字的最小单位，也是账单单位）。它叫 caveman，中文圈一般叫「洞穴人」，从 Hacker News 头条一路火到 10.8 万 Star。

我把它的仓库整个搬进隔离沙箱，逐项复现：它自己提交在仓库里的评测快照、它自带的基准测试（benchmark，也就是一套标准考题）脚本、404 个自动化测试，以及那份写着 65% 的仓库简介。结论先放这：它省的是 AI 的「嘴」，不是「耳朵」，而 65% 这个数字只对聊天式问答成立——真实编码任务上，官方第三方实测是 8.5%。

它是什么，怎么做到的

caveman 不是一个模型，是一层「说话纪律」。装完之后 AI 还是那个 AI，只是回答从求职信变成了电报稿。它规定得很细：

  • 删冠词、删客套、删「当然可以」「这是个好问题」这类开场白，删「just / really / basically」这类纯填充词
  • 代码、命令、文件路径、报错原文一字不改。它专门写了一句话：只有代码周围的散文会被压缩
  • 安全警告和「你确定要删库吗」这类不可逆确认，自动切回完整句子，做完再切回去

最反直觉的一条是它禁止为了「像原始人」而加词。别人模仿原始人会说 when it not，它说这比 when not 多花一个 token，却表达同一件事，属于净亏——压缩是唯一的风格。它的规则文件里甚至把「自己造 cfg / impl / req 这类缩写」列为禁止项，理由是分词器会把它们切成和完整单词一样多的片段，零节省，读者还得多解码一次。这一条是我在这个仓库里读到最有工程味的地方：它不装傻，它算过账。

等级分成日常三档（轻、标准、极简）和文言三档，默认是标准档。文言档在中文上按「汉字数」而非 token 数宣传削减，规则里自己标注了这个区别。

除了「管说」的技能本身，仓库里还有两层「管读」的东西：一个跑在本机的代理程序，把日志、测试输出、结构化数据、网页抓取结果在你发给模型之前先压一遍（原文落在本地数据库，随时可以取回）；以及一个可以塞进你自己代码里的中间件。这两层是商业许可，不是开源（下面第 6 条细说）。

实测：我把它的评测快照跑了一遍，也把它的测试跑了一遍

⚠️ 先说清楚边界：真跑一轮「带技能 vs 不带技能」的模型对比，需要 Claude Code 命令行加商业接口额度，评测机不具备。所以下面凡是模型生成的分数，都是仓库自己提交的数据；我复现的是这些数据的算法、结论口径和一致性。

第一步复现快照。仓库里存着一次完整评测：10 道开发问题、每道题跑三种条件（不加系统提示 / 只加一句「Answer concisely.」/ 那句加上技能全文），模型是 claude-opus-4-6，生成时间 2026-04-08。我按它自带的评测脚本口径重算（它用 tiktoken 这套开源分词器数 token）：

十道题 只加「简短回答」 加上 caveman 削减
解释数据库连接池 339 41 省 87.9%
为什么会 CORS 报错 328 138 省 57.9%
哈希表怎么处理冲突 167 103 省 38.3%
怎么修 Node 内存泄漏 227 226 省 0.4%
十题合计 2,045 1,026 中位省 50%、均值省 46%

三道题的表现就是这个技能的完整画像：问题越像聊天、越要让 AI 讲道理，省得越多；问题越像「给我代码」，省得越少，甚至一分不省。十道题里最差的那道只省了 0.4%（227 token 变 226），而离散度是 24.7 个百分点——这意味着「省 50%」这个中位数容易让人误以为稳定，其实它是一堆差异极大的结果平均出来的。

第二步，找矛盾。同一个仓库里，它的首页文档引用了两家第三方的测量：Adobe 研究院的论文测出输出侧压缩把实际成本降到 1/1.4 到 1/2.4（最好情况 1/3）；JetBrains 用 86 个真实编码任务做配对 A/B，测出省 8.5% 的输出 token、约 10% 的成本，而且这是「强制开启」的上限值（自动触发只会更少），质量上没有可检测的退化（符号检验 p = 0.82，82 组配对里 8 题更好、10 题更差、64 题打平）。

10 道聊天题省 50%，86 个真实编码任务省 8.5%。差距不是谁在撒谎，而是分母换了：在编码 agent（也就是能自己多步干活的 AI 程序）里，token 大头是代码和工具调用，而 caveman 明确不动这两样。它自己在首页文档里也把两句话并排写出来，这点是诚实的。

第三步，也就是这篇文章真正的发现：65% 这个数字，仓库早就把它从后端撤了，只剩 GitHub 简介还挂着。可复现的证据链有三条：

  1. 它自己的《诚实数字》文档里，输出削减那一栏写的是「未公布（Not published）」，理由是没有提交过经过复核的原始结果。
  1. 首页本该放基准表格的位置，是一段 HTML 注释占位，写着「这里尚无经过复核的接口基准结果」。
  1. 提供「已省多少」的后端统计早就不报数字了，代码注释里写明历史上的固定比例字段已不再使用，状态栏也不再显示节省百分比。
  1. 但 GitHub 仓库简介今天仍然是原话：「cuts 65% of tokens」。而这不是没发现——仓库在 2026-07-02 的提交里自己写了一句：「GitHub 仓库简介还写着『cuts 65%』，应该改成『约省 50-65% 输出 token（实测）』。本地提交改不了它。」

时间线更能说明问题：7 月 2 日先把宣传从「约 75%」改成「约 50-65%」并补上方法；7 月 3 日又发了一个提交，把「所有产品面」统一拉平成一句话 65%；直到 9 月 8 日，后端口径才撤回成「只报告日志里真实显示的内容」。一次改小、一次改回大、一次撤数字——三次里改动最小的那个位置，恰好是唯一改不动的地方。

顺手还挖到两个快照本身的问题，都属于「数字对不上现在的仓库」。

一是这份快照是 2026-04-08 一次跑完的单轮结果（每道题每种条件只跑一次、默认温度、没有显著性检验），而它测的那个技能文件在之后又改过 22 次，最近一次是 9 月 8 日——也就是说这份「50%」代表的不是今天的 caveman。

二是快照里参与竞速的四个技能中，中文版和西语版两个已在加入的次日删除，「压缩」那一路也已改名；而现在技能目录下躺着 20 个技能文件。这段对比数字连参赛者名单都对不上今天。

第四步，跑测试。仓库指定的测试命令是 node --test tests/installer/.test.mjs tests/hooks/.test.mjs。我在沙箱里跑完 404 个：381 通过、17 跳过、6 失败。

其中 3 个我看过失败原因，属于我们沙箱侧的限制：一个是容器里 /tmp 与根目录不同设备、跨设备硬链接被拒，两个是同时跑多个测试用例时 Node 起线程池撞上沙箱的进程数上限。

另外 3 个都跟 OpenClaw 的自动检测有关，我尝试把 OpenClaw 从系统查找路径里隔离后仍然复现——它们的失败信息是「没找到 OpenClaw 工作区」。

不下定论说这是仓库缺陷（真实用户的机器环境千差万别），但可以确定的是：这 6 个红不是「装了 OpenClaw 的机器才有」那么简单。

第五步，量体量。最近 30 天有 100 次提交、分布在 11 天里，持续集成流水线累计跑过 516 次、最近 5 次全绿；140 个待处理 issue，npm 上的命令行工具近 30 天下载 83,484 次。一句话：这不是蹭热度的仓库，维护强度是实打实的。

和同类比，你该装吗

「省 token」这个赛道其实分三层，装之前先分清你要省哪一层。

压读的一层：flowctx 走 OpenClaw 上下文引擎，实测砍 56% 输入 token 且解题率没掉；context-mode（也就是「上下文模式」）用 MCP 沙箱（MCP，也就是模型上下文协议、给 AI 接外部工具的通用接口）把 315KB 的工具输出压成 5.4KB。

压说的一层就是 caveman，以及管输出风格的 i-have-adhd。再往上是 ECC 这类整体工程纪律。这三篇我们之前都单独写过，文末可以顺着看。

caveman 的位置很特别：它是唯一同时做「说」和「读」的，而「说」那一半是 MIT 这种最宽松的开源许可、免费永久，「读」那一半要装本地代理。

第 6 条得单独说，因为它影响「能不能用在公司项目里」：这个仓库是混装许可。

技能目录、命令行工具、开发套件都是 MIT；但真正做压缩的几块——压缩引擎主体、本机代理、改写器、网页驱动、命令行输出压缩——是被称为 BSL-1.1 的商业许可，不是开源促进会认可的那种开源。

它允许你自用、自托管、内部生产使用，但不允许把它作为托管或嵌入式服务提供给第三方，那需要单独商业授权；变更日是 2030-06-21，届时转成 Apache 2.0。GitHub 接口给出的许可字段是「无法识别」，正是因为这个混装。

你想核实的 去哪看（都在仓库里） 我跑出来的
评测快照与算法 自带的评测目录，含结果快照与评测脚本 十题合计 2,045 → 1,026 个计费单位，中位省 50%
「未公布」的原话 文档目录里的《诚实数字》页 输出削减一栏确为「未公布」
测试命令与结果 项目配置里声明的测试命令 404 个用例：381 通过 / 17 跳过 / 6 失败
沙箱侧两个失败的成因 一个是跨设备硬链接被系统拒绝，一个是线程池起不来 均与沙箱限制一致，非项目缺陷
许可混装 根目录的许可文件与逐目录许可说明 逐目录列明，引擎相关目录为商业许可

最后是我实测下来觉得该提醒的三件事。

一，规则文件本身每次调用都要作为输入发一遍，当前那份技能正文约 1,650 token（按同一个分词器算），短问答里它可能比需要的还贵——仓库自己的 issue 里就有用户测出净亏。

二，按请求或按积分计费的工具（比如 GitHub Copilot 那类按「次」算的），回答短了还是同一次请求，一分钱省不下来。

三，首页公开过一条用户自测：某个 Cursor 的 A/B 里带 caveman 反而花了 430 万 token、对不带的 100 万，耗时还翻倍；仓库承认这条无法复现。

所以正确读法是——规则重复注入、以及缓存（也就是把算过的结果存起来、下次直接用）计费这两件事，能盖过输出端的节省，请在自己的任务上量一遍。

判断

装，但要装着正确的期待。它是一层写作纪律，不是省钱魔法：你的活越像聊天、越按 token 付费、回答里散文越多，它越值；你的活越像「给我代码」、越按次数付费，它就越接近零。8.5% 是真实编码任务上的上限，不是地板；50% 只在十道聊天题里成立。项目真正值得学的地方，反倒是它那份把「我什么时候会亏」写进文档的自觉——以及它到现在还没改掉的那句 65% 简介，提醒所有人：仓库里的数字会随文档更新一起改，产品页面上的那句话不会。

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

相关阅读：

ayghri/i-have-adhd 深度评测：5.1 万 Star 的输出样式技能，14 项评测 10 胜 2 平 2 负、自带发布闸门却判 FAIL，我复现了全部 70 个测试

作者
ayghri/i-have-adhd 深度评测：5.1 万 Star 的输出样式技能，14 项评测 10 胜 2 平 2 负、自带发布闸门却判 FAIL，我复现了全部 70 个测试

如果你用 AI 编程，每天至少要被这样一段话浪费掉一次注意力：「这是个好问题！让我想想。你的认证流程有几个环节，中间件、令牌校验、Cookie 处理……另外你的依赖版本好像也旧了，顺便说一句……希望对你有帮助，有需要随时问我。」 你问的是「怎么修」，它答了三百字，你读完还不知道第一行该敲什么。

有一个开源技能就是专门治这个毛病的。它叫 i-have-adhd，5 个月前出现在 GitHub 上，现在 5.1 万 Star。它的做法和你见过的「请简洁一点」完全不同：它写死了 10 条输出纪律——第一行就给可执行动作、多步任务必须编号、每轮都要复述进度、列表最多 5 条、禁掉「好问题」这类开场白和「希望对你有帮助」这类收尾。

它最有价值的地方不是这 10 条规则，而是它自带一整套评测。项目作者写了一台机器，拿 14 道题让同一个模型分别在「不带技能」和「带技能」两种情况下作答，再让评分模型盲评五个维度。结果是五个维度全线上涨，加权总分从 4.045 涨到 4.473。

但真正有意思的是接下来这件事：它自己的发布闸门，把这份成绩单判成了 FAIL。 项目里白纸黑字写着「发布门：未通过」。原因不在分数，在下文那张表。

它是什么，怎么做到的

先说清它到底是个什么东西。i-have-adhd 是一份给 AI 看的写作规范，一份纯文本文件，把 10 条输出纪律写进去。你把它装进 Claude Code、Codex、Cursor、Gemini CLI 这些编码助手（也就是能自己读文件、跑命令的 AI 编程工具），它就会在每次回答时被读一遍，管住输出的形状。

我把它 clone 下来逐层拆了一遍。整个项目 245 次提交、48 位贡献者，从 5 月 13 日建仓到现在 4 个多月，热度没有掉（最近 30 天还有 59 次提交，一周前刚合过代码）。规则本身只有 142 行、1187 个英文词——按比例换算大约 1700 个 token（也就是模型读写文字的最小计量单位，同时也是计费单位），这就是它每次回答要额外付的开销。

10 条规则里，前 3 条是核心，其余 7 条都在给这 3 条堵漏：

规则 一句话要求 它想治的病
1 动作先行 第一行就是能跑的指令、路径或代码 开场先铺垫背景
2 多步编号 一步一个动作，不许「然后」套「然后」 步骤糊成一段
3 末尾给一个下一步 指明 2 分钟内能做完的那一件事 结尾用「随时问我」收场
7 让完成可见 「登录能用了，去跑这个命令」 把成果埋在复述里
9 列表封顶 5 条 排序后只显示 5 条，其余留在内部 一口气甩 20 条清单
10 无开场白、无复述、无客套 删掉「好问题」「希望对你有帮助」 AI 味最重的两头

有个设计我认为值得单独说：规则 9 特意写了「只在展示层收敛，不许丢信息」——它只压缩你看到的清单，不压缩它搜过的结果。这一条是被用户骂出来的，我在下面「翻车点」里细说。

实测：我复现了全部 70 个测试，也复现了它自己的判据

它自带的评测有三层，我从最便宜的一层往上跑，全部在隔离沙箱里完成（一次性的容器式沙箱，跑完即删，不碰本机环境）。

第一层：70 个自动化测试，我逐个复现。项目里有 7 个测试文件，覆盖会话钩子、评分脚本、评测调度、安装文档路径、多平台打包。我按它官方 CI 用的同一套命令跑：

测试文件 用例数 我的结果
会话钩子（always_on_hooks） 7 全过
盲评脚本（judge） 17 全过
评测调度（run_evals） 25 全过
场景评测（run_scenario_eval） 7 全过
安装文档（install_docs） 2 全过
打包（omp_package） 2 全过
OpenCode 插件 10 全过
合计 70 70 过 0 挂

这里有个插曲值得记：第一次跑，有 2 个用例挂了，报错是「找不到 awk」。我一开始以为是仓库的 bug，追下去发现是我的沙箱问题——那两个用例调用一个文本处理小工具，而它在系统里是通过一条软链接间接指向真身的，我的沙箱只读挂载了主程序目录、没挂那个软链接目录，于是「工具在，但找不到」。我把真身直接接进去再跑，7 个用例全过。

也就是说：这 2 个失败是我的环境造成的假阳性，不是项目缺陷。我把它写出来，是因为「评测翻车往往是评测者自己的问题」这件事，比 70 个全绿更常见。

第二层：评测清单能跑通。项目的评测调度脚本有两个命令：一个校验 14 道题的清单格式，一个打印「要跑哪些组合」。前者输出「用例有效」；后者按 3 次重复 × 14 道题 × 3 种条件（不带技能 / 带技能）算出 126 次作答的排期。这两步我都跑通了，说明评测脚手架本身是好的。

第三层：评分环节我没有跑通，原因必须说清楚。项目的评分流程要用命令行调用 Claude Code 或 Codex（也就是 Anthropic 和 OpenAI 的编码助手命令行），由它们实际生成作答、再盲评打分。

我这台评测机没有装这两个工具、也没有对应的商业 API 额度，所以我无法自己生成那 126 次作答，也就无法亲手复核那五组分数。下面的数字来自项目公开的成绩单，不是我跑出来的——这一点我在文末的口径说明里再强调一次。

它自己那份成绩单是这样的（同一模型、14 道题 × 3 次重复，共 84 份作答，盲评时被打乱成 A / B / C 三组、评委不知道哪份带技能）。五个维度各自满分 5 分，带技能后全部上涨：

  • 正确性（权重 35%）：4.333 → 4.524，涨 0.190
  • 自主性（25%）：3.762 → 4.167，涨 0.405
  • 可执行性（20%）：3.905 → 4.619，涨 0.714
  • 安全性（10%）：4.643 → 4.667，涨 0.024
  • 简洁度（10%）：3.429 → 4.571，涨 1.143
  • 加权总分：4.045 → 4.473，涨 0.427

最值得看的是「正确性」和「安全性」也在涨——这两项权重最高，而且向风格类改动要收益是最难的：一般「让 AI 说短点」的做法，最容易拿简洁度换掉正确性，表现成「答得更短，但也更不准」。它在这里没有掉，说明压缩的是废话，不是内容。

再细一层，14 道题里它 10 道赢、2 道平、2 道输。涨幅最大的两道是「多步任务报进度」和「报错怎么说」——加权分分别涨了 2.53 和 2.40，这两道题几乎贡献了全部总分增量。而「写代码」和「写长文」两道题是零变化：题目本身就规定了输出格式，技能没有乱插手。这个「该让的时候让了」的结果，比总分上涨更能说明规则设计得克制。

翻车点：它的发布闸门判自己 FAIL，这事不能算小事

现在说开头那个反差。项目里有一份发布门规则，写着 4 条放行条件，其中第一条是「不得存在任何阻断问题」。它自己跑出来的结果是：不带技能 7 处阻断问题，带技能 3 处——砍掉了一半以上，但发布门依然 FAIL。

因为那条规则写的是「零」，而不是「比之前少」。所以一个把缺陷数量砍掉 57% 的版本，和原版一样被拦下。这不是分数问题，是判据的写法问题，项目自己也在文档里点破了这一点：按这条规则的字面意思，只要题目集里还剩下任何一处阻断问题，任何版本都永远不可能通过，无论它改善了多少。

这个设计我认为是本项目最耐看的地方，也是最该被别家抄的地方：它的成绩单和它的发布门是两台独立的机器，而且发布门比成绩单严。 绝大多数开源项目的「评测」是自我介绍，它的评测是准入门槛，并且真的拦住了自己。

那 3 处没消掉的阻断问题里，有 2 处集中在一道题上。项目的解释是那道题没有任何一次运行能通过：题目要求 AI「直接改仓库，别把修改交回给用户」，但评测时所有命令行都被设成了「不加载任何工具」，于是没有一次作答真的能动手。这是题目本身的缺陷，不是技能的问题。

把这道题排除后，计数变成「不带技能 5 处、带技能 1 处」，发布门按同一条规则判，依然 FAIL。

真正值得警惕的是剩下那 1 处，它指向技能本身的一个副作用。题目给的是「三个检查跑完：代码风格检查通过、单元测试通过、集成测试失败」这种证据不全的场景。带技能的作答给出了一份很笃定的判断——「缺认证请求头就是确定原因」——而评分者认为这句话在没有任何诊断证据的情况下把猜测写成了定论。

机制说得通，而且技能作者自己把它挂成了公开 issue：第 8 条规则要求「报错要说清原因和修法，不许用『哎呀』『好像有问题』这种口气」。原文照字面执行，就等于逼模型必须给出一个原因；而证据不足时，它就会去猜一个。作者在 issue 里也承认这个推论样本不够（只有 3 次重复，其中 2 次明显下行、1 次持平），但方向和机制都对得上，所以标为「值得加更多重复次数去验证的那一个」。

从工程角度看，这几乎是一道送分题的陷阱：「说清原因」和「不许无依据断言」在证据不足时会打架。我自己写技术文档时也踩过——把「可能是 X」改写成「就是 X」能让句子更干脆，代价是撒谎。

另外三处来自真实用户的抱怨，也一并列出来：

  1. 规则 9 被理解成了硬性的 5 条上限。一条 15 人讨论的 issue 里，用户反馈它不只是把长清单分成「现在做 / 以后做」，而是直接砍到 5 条，把后面的信息丢了。作者的回应是正在把规则改成不写具体数字的写法。

这解释了为什么现在的规则正文里反复强调「只在展示层收敛、不许丢信息」——那是事后补上的补丁。

  1. 在某个模型上严重退化。有用户报告在 Grok 4.6 上开启后，AI 变得「只会描述步骤、不肯动手」，多步推理也明显变差；同配置在 4.5 上正常，关掉技能立刻恢复。这是模型相关的水土不服，不是普适缺陷，但说明输出规范类技能并非对所有模型都安全。
  1. 加载方式有兼容性坑。有 issue 指出技能文件头部的元数据写法（嵌入了一层嵌套对象）会让严格按规范解析的客户端直接跳过这个技能，报告者贴出的报错显示某个客户端解析失败后就不加载了。

局限也要说清：它的评测只有 3 次重复、且评委模型和作答模型是同一家。项目自己在文档里承认，单题标准差最高到 0.95，单题涨幅低于约 0.5 就不该当作信号，只有汇总分比较可信；同时评委和选手同源会带来偏好偏差，理想的对照组应该换一家模型来评。换句话说：+0.427 这个总变化可以参考，那张逐题表里的小数不要当真。

判断：谁该装，谁别装

装它的理由：如果你的痛点是「AI 答得没错，但读了半天不知道该干嘛」，这就是最对症的一类工具，而且它是纯文本改写、没有任何运行时依赖——没有需要单独安装的程序、也没有常驻后台的进程，最坏情况下它只是不生效。参数上也很清楚：每次回答多花约 1700 个 token（整个规则文件的长度换算而来），换来加权分 +0.427、劣势项「简洁度」+1.143（均为项目自测，非我实测）。

别装的情况：如果你的任务是让它写长文档、做方案评审、要它展开讲原理，它的 10 条规则里至少 3 条会和你打架。

好在技能文件里专门留了「什么时候可以破例」一节，明确写了「用户要求解释时，就完整解释」——这道逃生门是设计的一部分，不是补丁。

判断的分界线是：你更常被「答案埋在废话里」烦，还是更常被「回答太短不够用」烦。前者装它，后者绕道。

还有一点值得单列：它值不值得学，跟你用不用它无关。这套东西真正可复用的不是那 10 条规则（规则本身多数人一看就懂），而是「给自己配一台独立的、会拦住自己的验收机」这个习惯。同一批开源技能里，绝大多数把「我们做了评测」当勋章挂着，成绩单漂亮就够了；这个项目多走了一步——让成绩单和发布门互相独立，并且让发布门判自己 FAIL。它那条「零阻断才能发布」的规则写得过于绝对，项目自己也承认这是个「该在发版前特意拍板、而不是发版时才发现」的性质问题——但肯把这条规则和它判自己失败的结论一起公开，比一个漂亮的百分比更有价值。

项目地址：ayghri/i-have-adhd（MIT 协议）。技能全文 142 行，直接复制 skills/i-have-adhd/SKILL.md 到你的技能目录即可，不必装整个仓库。

口径与利益声明：本文作者与该项目及作者无任何商业关系，非付费用户，未接受任何形式的赞助或评审授权。文中「70 个测试全绿」「沙箱复现」为作者在隔离沙箱中对 ayghri/i-have-adhd 主分支实测结果；五维分数、14 道题的胜负分布、「7 处砍到 3 处」等数字来自项目公开的成绩单（2026-08-02 记录），非作者实测，原因是本项目评测需要商业模型命令行与对应额度，评测机不具备。仓库元数据（5.1 万 Star / 2,965 fork / 245 次提交 / 48 位贡献者 / MIT）抓取于 2026-09-27。该项目无版本号发布（无 tag、无 release），文中所述为 2026-09-19 的主分支状态。

相关阅读：

关注 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 热点深度解读。

相关阅读：

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 个失败的完整归因见文末证据包；相关断言已登记到断言守望，字段一变会复核。