开源项目评测

security-audit 深度评测：2.99 万 Star 的 Cloudflare 安全审计技能，65 条测试我全跑了，仓库里没有一行代码找漏洞

作者
security-audit 深度评测：2.99 万 Star 的 Cloudflare 安全审计技能，65 条测试我全跑了，仓库里没有一行代码找漏洞

用过 AI 写代码的人，多半都撞过同一堵墙：让编码助手顺手”看一眼安全”，它扫两眼，回你一段像模像样的话——”这里可能存在 SQL 注入风险，建议改用参数化查询”。听上去没错，可它没说清是哪个接口、谁能触发、真被利用会丢什么。Cloudflare 开源的 security-audit 技能就是冲着这堵墙来的，GitHub 上已经攒到 2.99 万 Star，120 天从零涨到这个数。我在隔离沙箱里把它逐文件翻完，撞见一个别的评测少见的反差：这个技能挂的招牌是”安全审计”，仓库里却没有任何一行代码负责找漏洞。

它不是扫描器，是给 AI 定的审计作业规范

先把它是什么说清楚。市面上的安全工具分两类：一类是扫描器，自己跑起来找漏洞；另一类是规范，教别的 AI 怎么找。security-audit 属于第二类，而且属于得很彻底——整份仓库 15 个 Markdown 文件、18.3 万字节，全是写给人（准确的说是写给模型）看的流程说明书。

一句话定位：给 AI 编码助手（Claude Code、Codex 这类能调工具的助手）装一套六步作业规范，逼它把”我觉得这里有问题”变成”这条证据能溯源、这个结果真跑出来过”。

它的六步是这样走的：侦察（把代码结构和信任边界画出来）→ 按覆盖清单派猎手 → 候选人验证（交给另一个没参与找漏洞的 AI 去证伪）→ 结构化输出 → 独立复核记录 → 出报告。里面有几个反直觉的设计：

  • 找漏洞的 AI 和验证漏洞的 AI 必须是两个，且验证方拿到的任务就是”尽力推翻它”。理由写在仓库首页：同一个 AI 既当运动员又当裁判，等于没验。
  • 搬运沙箱产物的规矩细到吓人：每一步用文件描述符、不许跟随软链接、不许递归拷贝、每个文件有字节上限。这是给”审计目标自己写文件、想借机逃出沙箱”这种场景上的锁。
  • 只认三类结论，判据写在词上，不放水：
结论 什么情况下才给 给不给严重等级
confirmed（已确认） 来源能完整溯源，且有真跑出来的结果 给
needs_validation（待验证） 有一个具体的、卡住的外部事实没拿到 不给
rejected（已证伪） 候选被独立验证方推翻 不给

换句话说，它不承诺”帮你找到漏洞”，它承诺”让 AI 找漏洞的每一步都可被追查”。这两者的差别，就是这份仓库全部的设计动机。

我把它的测试全跑了，65 条一次通过

评测安全审计工具最尴尬的地方是：你没法用它审自己证明它行。所以我改成核两件能核的事——它自己带的测试，和它那两个校验脚本的边界行为。

先看仓库里唯一有代码的部分。整个仓库只有 4 个 .cjs 文件，其中 2 个是校验器，另 2 个是给校验器写的测试：

文件 大小 干什么
validate-findings.cjs 28,806 字节 校验最终结论文件合不合规
validate-coverage-ledger.cjs 33,522 字节 校验覆盖清单的每一步有没有交代
validate-findings.test.cjs 26,384 字节 上一条校验器的测试
validate-coverage-ledger.test.cjs 28,483 字节 覆盖清单校验器的测试

两个校验器加起来 62.3 KB，零第三方依赖——仓库里连一份”依赖清单”（package.json）都没有，只用 Node 自带模块。我在沙箱里跑它自带的测试：65 条断言，65 条通过，0 失败 0 跳过，4.08 秒。拆开看是 34 条管结论校验、31 条管覆盖清单校验。

这个数字需要配一句解释：65 条测试，没有一条在测”能不能找到漏洞”。它们测的全是另一件事——报告格式的守门人够不够狠。我按这个方向自己加了几组边界输入去撞它：

  • 传一个空结论表 [] → 通过，退出码 0（空报告合法，不许硬编一条充数）
  • 传一个对象而不是列表 → 拦下，退出码 1
  • 传一段截断的 JSON → 拦下，退出码 1，只印一句”语法错误”，不吐堆栈
  • 传一个不存在的文件名 → 拦下，退出码 1，同样不吐堆栈

四个例子的意义在于最后那条：失败的时候不把调用方的输入原样回显出来。听起来是小事，做安全的人知道这不是——审计报告里如果混进一串控制字符，能把终端骗过去，所以它连诊断信息都做转义。这条规矩在它的测试里占了整整一类。

覆盖面这一侧它也下了本钱：主规范之外配了 10 个”攻击面分类”文件，从内存安全、AI 大模型的提示注入（也就是往给模型的指令里夹带私货）、网页协议与登录认证，一路到供应链、云部署、桌面端本地进程间通信。15 个 Markdown 里一共 106 个小节标题。这份分类表的价值不在深，在于”摊得开”——它逼模型在动手前先回答”我审的是哪一类目标、该类里有哪些套路”，而不是笼统地”审一下”。

有两处我如实写下来，不替它圆：

第一处是仓库自己承认的短板。README 里有一句原话：在他们的测试里，单跑一轮大约只找到多轮累计漏洞数量的一半。翻译成普通话——这工具跑一次是不够用的，得反复跑、比对几次结果。这句话敢于写在首页，比一堆”行业领先”可信，但也说明它现在还不是”一把过”的成熟工具。

第二处是节奏。最后一条提交停在 2026 年 9 月 14 日，到今天我写这篇时已经 32 天没动；全部历史只有 14 次提交、5 个合并的 PR，作者高度集中在一个人身上（literally-dan / Dan Jones）。对一个 3 万 Star 的项目，这个维护密度偏低——它是”Cloudflare 放出来的一份方法论”，不是”一个每周都在长的基础设施”。这两者的用法完全不同，后面会说到。

和同类比，它的位置在哪

把它和常见做法摆一起，位置就清楚了：

对比对象 谁在找漏洞 要不要独立复核 证据形态
静态扫描器（如代码扫描工具） 工具自己 不需要 规则命中列表
直接问 AI”审一下” 同一个 AI 没有 一段自然语言
security-audit 技能 AI 去做，但按固定六步 强制，且验证方必须独立 结构化记录 + 可溯源证据

差别集中在中间那一列。”直接问 AI”的问题从来不是它不够聪明，而是它说”有风险”时，你分不清那是结论还是它在迎合你。这个技能的做法是：把”下结论”这件事本身立成一道有格式、有复核、有证伪的流程。

适合谁用：手上有一份想认真过一遍安全的中小型代码库，团队里有人能读懂 AI 给出的证据链，并且愿意接受”跑一轮不够、要跑几轮”这个前提。也适合只想学一套审计方法论、不打算直接用它的人。

不适合谁用：指望装上一个技能就自动把漏洞扫出来的人。这仓库里没有一个字节是扫描逻辑，找不到漏洞不是它坏了，是它压根不干这事。另外一个前提是它要求执行环境有硬沙箱——真要动手复现目标代码的行为，得有个能断网、能限内存、只让往指定目录写的隔离环境；没有这个环境，规范自己的要求是：不许跑目标代码，把线索标成”待验证”。这个自我约束是优点，但也意味着实际能挖多深，取决于你手里的沙箱。

我的判断

这是一个人格很完整的安全审计技能，但不是一个人能拿来就用的工具。它的价值在流程：六步怎么分、谁去找谁去验、什么才配叫”已确认”、沙箱里怎么搬文件才不出事——这些规矩是 Cloudflare 从自己的漏洞发现流水线里抽出来的，有真实来源，不是纸上谈兵。2.99 万 Star 和 120 天的涨速，也说明这套方法论踩中了大家的痛点。

但它把力气全花在”规范”上，代价就是”能力”那半边是空的：没有扫描逻辑，65 条测试一条都不碰找漏洞本身，32 天没提交，作者一个人扛。所以我的结论是把它放进”值得精读、谨慎依赖”这一档——读它的流程设计，比跑它找漏洞收获更大。

这背后其实是一条更普遍的规律：AI 时代的很多所谓”技能”，真正稀缺的不是让模型变强，而是给模型的行为立规矩、加复核。这套仓库是这个思路里做得比较扎实的一份样本。

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

相关阅读：

ui-ux-pro-max 深度评测：13.6 万 Star 的设计技能，192 条规则 79 种风格我逐条核过，CLI 却停在 8 月

作者
ui-ux-pro-max 深度评测：13.6 万 Star 的设计技能，192 条规则 79 种风格我逐条核过，CLI 却停在 8 月

用 AI 写前端的人，差不多都撞上过同一堵墙：让 AI 生成一个登录页，它十有八九给你一套蓝紫渐变加大圆角的”安全牌”——不难看，但放到哪个产品上都一样，看不出这是卖保险的还是做潮牌的。

专门治这个毛病的技能里，有个叫 ui-ux-pro-max 的，GitHub 上已经攒到 13.6 万 Star。它自称能提供”设计智能”：你想做什么产品，它给你一套配色、字体搭配和版块结构。我把它搬进隔离沙箱，逐条核了它挂在门面上的数字——192 条决策规则、79 种界面风格——每一条都能对上。但顺着它给的安装命令往下查，我发现一个数字上的矛盾：这个技能的官方安装包每月被装了 7.7 万次，版本号却停在 8 月没动过。

它到底是什么

一句话：它是一个装在 AI 编码助手里的”设计顾问”，负责在你还没动手写样式之前，先告诉你这个产品该长什么样。

它不是一个能自己运行的程序，而是一个技能包（skill）——也就是一份写给 AI 看的说明书，加上一整套查得到的数据库。你问它”我要做一个 SPA 预约网站”，它就翻它的数据库，回你一套具体到色号的设计方案。

它解决的是 AI 生成前端时的一个老毛病：没有审美就以”安全”代替审美。大模型见过的设计稿太多，生成时倾向于挑最不容易出错的那一套，结果所有产品长得都一样。这个技能的做法是，把”哪种产品用哪一种风格”这件事，从 AI 的临场发挥变成一份可查的对照表。

它的核心动作是”给三个旋钮”——你可以决定这套设计要多大胆（从规规矩矩到不对称排版）、动效要多花哨、信息密度要多高。三个数字一转，出来的就不是同一个模板了。

它查得到的东西 数量
决策规则 192 条
界面风格 79 种可搜索（另 9 种标为废弃）
配色方案 192 套
字体搭配 74 组
交互体验准则 119 条
支持的开发框架 22 个

官方那两个招牌数字，我逐条数了一遍

先交代条件：全程在一台隔离沙箱里跑——被测项目拷进它自己的工作目录，宿主机的凭证和文件都看不见，机器内存只有 1.9G。下面的命令和结果都可以照着重来。

先说它的主业——那 192 条规则。它其实是一张表，每一行对应”做某类界面时该怎么选”：推荐什么版式、配色往哪个方向、字体走什么调性、以及最容易被忽略的一栏——”别这么用”。我逐行数过，192 行里，192 行都填了”反模式”这一栏，也就是说每条建议都配了一个明确的坑。

这栏是它和”AI 自由发挥”最大的区别。举个它表里的例子：极简瑞士风（一种讲究留白和网格的排版风格），”不推荐用于”一栏写的是”创意作品集、娱乐类、需要活泼调性的品牌”。换句话说，它不只告诉你该用什么，还告诉你什么时候不该用。

再说那 79 种风格。仓库里有一份”目录总表”，我拿它和实际数据交叉核对：风格表一共 88 行，其中 79 行标记为”可搜索”，9 行标为”废弃”——79 这个数字能对上。风格表每一行还带 29 个字段，从”适合什么产品”到”如何兼顾明暗两种模式”；其中最容易被作者偷懒的”不推荐用于”一栏，88 行我逐行查过，全部填满。

规矩不止写在纸上，还配了自动检查。仓库自带的两个数据校验脚本我都跑了：一个检查 35 个运行时数据表，输出”全部通过”；另一个按”12 个领域表、22 个框架表、加决策规则表”全检一遍，输出同样是”通过”。

真正让我意外的是测试。它在主目录下带了 13 个测试文件。我在沙箱里装好测试工具跑了一遍：

我跑的命令 结果
跑它自带的数据校验（两个脚本） 均输出”通过”，退出码 0
跑它自带的测试套 164 项通过、8249 个子项通过，耗时 20.9 秒
同一个需求跑两遍，比对输出 完全一致（同一输入给同一结果，不随机）
换一个完全不同的需求 风格与配色整组都换了

最后一行值得多说一句。我先用”SPA 预约网站”这个需求跑了一遍，它给的是一套柔和的粉紫色系、配”柔和界面”风格；我又换成”加密货币交易看板”，它立刻切到深色 OLED 风格、整套配色换成深蓝黑。同一个技能，两个需求，出来的方案没有一丝相似——这说明它不是在套模板，是真的在读需求查表。

顺便一个工程细节：它的 Python 脚本只用了系统自带的标准库，没有引入任何第三方依赖。对一个要嵌进别人项目的技能来说，这意味着装上就不会因为依赖打架而坏掉。

数字对得上的另一面：安装量还在涨，包停在两个月前

好评说完，说说我查出来的三个问题。这三个都不是猜测，是能在页面上看到的。

第一个，也是最好笑的一个：门面数字和发布状态打架。

它的官方命令行工具（装在电脑上的一条命令，让你一条指令把技能装到 AI 助手里）在 npm 上的记录是：过去一个月下载 7.7 万次，一共发过 17 个版本，但最新版本 2.15.0 的发布时间是 8 月 13 日。也就是说，两个月来一直有人在装，而这个包一次都没更新过。仓库里对应的记录写着”从 8 月 18 日起发布流程一直失败，npm 令牌被拒，2.15.0 之后就什么都没发出来”。同一条问题在 8 月 24 日就被提出来了，到现在还开着。

第二个，是它附带的示例工程埋的一个安全隐患。

仓库里带了一个可以直接跑的示例项目。它的配置里有一行默认设置，意思是”这个项目里配置的所有工具都自动批准，不用每次问我”。问题在于，这个示例同时把三个工具都设成了”永远拉取最新版”。合起来就是：任何人克隆这个示例，就等于默认授权了一堆会自动更新的外部工具——包括以后往配置里新加的工具。有用户专门提了一条记录（编号 514）说这个默认值不合适，建议至少加一句说明。

第三个，是最现实的一个：它能装的 AI 助手，和它宣传的并不完全一致。

它的命令行工具支持一串指定的助手，我数了一下有 20 个左右。有用户在 Windows 上按文档装了其中一个叫 Zcode 的，命令直接报错”不支持的 AI 类型”，并把支持列表重新打印了一遍。（更不巧的是，因为上面第一个问题，这个报错修复到现在也发不出来。）

翻车点也说全。它虽然叫”技能”，但门槛并不低：它需要你本机有 Python 3，还得看它装的辅助脚本能不能在你的系统上跑起来。它的中文文档是机器翻译味儿的，几个版本说明读下来会有点累。还有那个挂在门面上的 GitHub 版本号，从 8 月中旬就停在原地了——对看版本号判断新旧的读者，这容易误导。

同类里它站在哪，谁该用它

想把”AI 生成的前端不像 AI 做的”这件事做好，市面上大概三条路。第一条是”当场提要求”型——在动手前先逼 AI 做几个决定（给谁用、什么调性、要突出什么），比如 Anthropic 官方的 frontend-design，好处是轻，缺点是全凭 AI 那次发挥了。第二条是”事后挑刺”型——让另一个 AI 审一遍生成的结果，挑出问题再改。第三条就是这个技能代表的”先查表再动手”型：把审美沉淀成一份可检索的数据库，让 AI 有据可依。

三条路不冲突，甚至能叠着用——它附带的示例工程就是这么干的。它的独特之处在于把”不该这么用”也做成了数据：88 种风格，每一种都写清不适合什么场景。这是”事后挑刺”给不了的。

适合谁：经常用 AI 生成界面、又受不了”AI 味”的前端；需要一次性产出多套不同调性方案的设计师；想给团队的 AI 工具装一本”审美参考书”的团队。

先别急的两种人：一是只想要”一句话生成一个能用的页面”的——它给你的是设计依据，不是成品页面，你还是得自己动手；二是对工具依赖有洁癖的——它附带的示例工程那个”默认全批准”的配置，你得自己改掉再跑。

我的判断

ui-ux-pro-max 是目前少见的、”把审美做成可查数据”的技能。它挂出来的 192 条规则、79 种风格，我逐行核过，一条没虚；164 项测试全绿、零第三方依赖，一个技能包能把工程纪律做到这份上，是加分的。它真正值钱的不是”帮你选个好看的颜色”，而是那 88 行”不推荐用于”——审美最难的从来不是”什么好看”，而是”什么时候别用这套”。

但它也暴露了一个典型问题：技能本体很扎实，配套工具却在掉链子。一个月 7.7 万次的安装量，配一个两个月没更新的包、一个开着一个月的报错修复——这不是能力问题，是维护节奏问题。放进观察清单没问题，但如果你要把它塞进正式项目，建议先把那个”默认全批准”的示例配置改掉。

相关阅读：Hallmark 深度评测：3 万 Star 的反 AI 味设计技能，31 个成品页面 21 个过不了自家 58 道闸门　·　taste-skill 复测：9.2 万 Star 的反 AI 味前端框架

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

qm 深度评测：YC 开源的团队 Agent 外壳，49.1 万行代码立着「零注释」铁律，实测仍躺着 885 行注释

作者
qm 深度评测：YC 开源的团队 Agent 外壳，49.1 万行代码立着「零注释」铁律，实测仍躺着 885 行注释

用 AI 写代码的人，多半都撞上过同一堵墙：代码产出快了，敢接手的人却少了。注释随手加、规矩靠自觉、审查全凭手感，没人说得清”这套规矩今天到底有没有被守住”。

YC（那家孵化器）把自己内部在用的 Agent 外壳开源了，叫 qm，76 天冲上 1.5 万 Star。它立了一条开源圈少见的铁规矩：仓库里不许有注释。 我把它搬进隔离沙箱实测：49.1 万行 TypeScript 代码，躺着 885 行注释；但真正会掩盖问题的那两类坏注释——待办标记和类型屏蔽指令——是 0 条。

它到底是什么

一句话：qm 是给一个团队、而不是一个人用的 Agent 外壳。所谓”外壳”（英文 harness），也就是套在大模型外面、负责跑工具、管上下文、记账的那层壳。

市面上多数 Agent 是按”个人助手”造的，想放大到全公司很快就失控：记忆混在一起、权限说不清、谁占了什么资源查不到。qm 反过来，它一开始就假设用的人是一整个公司——每个员工有自己的独立空间，同时还能在频道、群聊、项目里跟 Agent 一起干活。

它管这块独立空间叫”作用域”（scope）：计算、记忆、文件、定时任务、小应用各自分开，想跨过去必须走一道明确可查的授权。

再往里一层，是它最有意思的设计，叫”会话磁带”（session tape）。可以把它想成一本只许往后写的账本：每一轮对话、每次工具调用、每条结果，都按顺序记下来，进程在任何时刻被打断都扛得住，照着账本重放就行。它的设计文档列了五条”北极星”，其中两条是”快就是最好的功能”和”删代码优先于加代码”。

它能干什么 具体覆盖
个人空间 每人一块隔离的工作区、记忆、文件、定时任务
协作 频道路由、群消息、项目共享、技能共享
后台任务 定时任务、循环任务、外部回调
换引擎 编码助手可换（Pi、Codex 这类现成的），模型也可换
界面 同一份会话，Slack 和网页都能看

零注释这条铁律，我照着数了一遍

先交代条件：全程在一台隔离沙箱里跑，被测项目拷进沙箱自己的工作目录，宿主机的凭证和目录都挡住，机器只有 1.9G 内存。命令和结果都可复现。

我跑的命令 结果
数 TypeScript 文件与总行数 1978 个文件、491,540 行
数 src/ 下的文件与行数 553 个文件、138,394 行
数以行注释符号或块注释符号开头的行 885 行（src/ 里 549 行，集中在 72 个文件）
搜待办标记 TODO / FIXME 0 条
搜类型屏蔽指令（ts-ignore 这类） 0 条
跑它自己的自审脚本 退出码 1，提示 PR 缺”自审报告”段

“零注释”不是口号，是写进规范的两条硬话。一条明说：”标准就是零注释——不写解释性注释和文档块，不留待办标记，不加类型屏蔽指令，不保留注释掉的代码。”另一条解释为什么这么极端：”注释在历史上强化了代码漂移，还给后续的 Agent 留下了’奖励式取巧’的掩护。”

885 行放在 49.1 万里只占 0.18%。我更在意的是那两类真会出事的注释——待办标记、类型屏蔽指令——一条都没有。换句话说，这条几乎不可能 100% 达成的铁律，实际达成率 99.8%，漏网的基本是解释”为什么这么写”的说明，不是掩盖问题的补丁。

它给自己也立了 19 面镜子

更少见的是它的”认错档案”。规范文档里专门有一节叫”耻辱墙”（Wall of shame），把自己历史上犯过的错分类挂出来，一共 19 面镜子，从”过度工程”到”打补丁式修复”再到”格式匹配写太多”。其中 7 面标着”每个合并请求必审”，意思是这几类错最容易复发。（合并请求即 PR，别人改代码要先提这个，通过审查才能并进去。）

它不只是记录，还做成了闸门。仓库里有个脚本专门检查每个合并请求里有没有附上一份自审报告，缺了就直接让流水线红掉——我把它克隆下来跑了一遍，退出码 1，报错很直接：”PR 描述里没有自审报告段”。这说明这套自我约束不是墙上标语，是真的接了电的。

规模也摆在那：1978 个 TypeScript 文件对应 724 个测试文件，7770 个测试用例、近 3.1 万处断言；6 条持续集成流水线；39 份设计文档、25 个自带技能、35 个沙箱后端相关文件；已合并的请求 904 个，编号已经排到 2264。光是 10 月 12 到 14 日这三天，就提交了 51 次。

翻车点也说全，三条。一是它还是 0.1.0 版本，项目自己写明这仍是一场”早期实验”，接口不保证稳定。二是它的文档里自曝过一个体验问题——一个余额不足的用户被拒绝时，界面上只显示”这轮失败了，详情看操作员错误日志”，而那个用户根本没有这个日志。三是它的完整测试套我没能跑起来——它要求 Node 24.15 以上，我的沙箱是 Node 22，还要另起一个 Postgres 数据库，所以那 7770 个用例我只数了数字、没有实际执行，这一点如实说明，不拿它凑数。

同类里它站在哪，谁该用它

同类可粗分三路。字节的 DeerFlow 走”深度研究”路线，把多个检索步骤串成一条流水线；国产的 CowAgent 走”全栈自托管”，从网页界面到后台一把抓；再有一类专攻单点，比如只做 Agent 的记忆。qm 的差异在”多人”这一层：它把每个员工、每个频道切成独立的作用域，再叠上一本可重放的会话账本，解决的是”一个公司共用一个 Agent 时不打架”。它的不同还在于把”自查”本身做成了必过的闸门，而不只是一份建议。

适合谁：想让整个团队共享一个 Agent、又必须把每个人的数据和权限分清的团队；自己维护模型密钥、要求本地部署的公司。

先别急的两种人：一是要稳定接口接进核心系统的——它自己标着早期实验；二是图省事的个人用户——你得自己准备数据库和服务器，它不是一个装完就能聊天的小工具。

我的判断

qm 是目前少见的”把工程纪律当产品做”的 Agent 外壳：零注释、耻辱墙、19 面镜子、7 面必审、一道真跑得起来的闸门，这些都不是营销词，是能 clone 下来一条条核的。它立了一条几乎不可能 100% 守住的铁律，实测守住 99.8%，漏网的全是解释性说明——这比”从没立过规矩”要诚实得多。值得放进观察清单，尤其是正在被”多人共用一个 Agent”搞烦的团队。

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

相关阅读：

notebooklm-py 深度评测：随时会坏的 Google 非官方接口，凭什么压着 1.8 万条测试

作者
notebooklm-py 深度评测：随时会坏的 Google 非官方接口，凭什么压着 1.8 万条测试

你大概用过 NotebookLM：把一堆资料丢进去，让它替你读、替你答、还带上出处。它官方只给了网页界面，没有给能用代码调用的接口。有人自己动手，把它做成了能编程调用的库，一下就冲到了 1.9 万 Star。

这次我盯上的是 teng-lin/notebooklm-py。它的自我介绍里有一句极少见的坦白：这是一个非官方库，用的全是没公开的 Google 接口，Google 随时可能改，一改它就可能坏。

我照着它自己的说明，在一台隔离的机器上把它装上、跑完了它的测试，发现两件放在一起很反差的事。

一件是它真能扛：1.8 万条测试，18720 条通过，而且整套测试断网就能跑，不碰任何真实账号。另一件是它自己天天在准备那个「随时会坏」的明天：从今年 8 月到 10 月的 585 次提交里，158 次有 AI 参与写代码，它还专门写了 13 个脚本，每次发布前自己检查自己有没有说谎。

它到底是什么

一句话：它是给 Claude Code、Codex 这类编程助手用的外挂接口，让助手能绕过网页界面，直接用代码使唤 NotebookLM。

举个能听懂的例子。你在网页上做视频摘要，得自己点开、上传、等它生成、再手动下载。换成这个库，你写一行命令，助手就能自己去建笔记本、把十几篇链接塞进去、让它读完、生成一段播客音频、再把音频下载到本地。中间不用你点一下鼠标。

它把 NotebookLM 的能力拆成了 11 类操作，做成了三种用法：命令行、Python 代码、以及一个能被模型调用的 MCP 接口（意思是「让模型调用外部工具」的通用插头）。另外它比网页版多做了几件网页版做不到的事——把生成的测验、闪卡批量导出成 JSON 和 Markdown 文件，把思维导图导出成能进可视化工具的 JSON，幻灯片直接存成可编辑的 PPTX。

它自带一个装在仓库根目录的技能说明文件，也就是说，它自己就是一个「skill」——这也是我把它放进技能评测这一栏的原因。

它能干什么 具体覆盖
笔记本 新建、复制、重命名、删除
资料源 链接、YouTube、PDF、Word、音频、视频、图片、Google Drive
提问 带出处回答、保存成笔记、自定义人设
生成内容 播客音频、视频、幻灯片、信息图、测验、闪卡、报告、数据表、思维导图
导出 音频、视频、文档、图片、表格、结构化数据等，共八种格式

我把它装起来，跑了它自己的测试

先交代评测条件，免得误会：全程在一台隔离沙箱里跑，被测项目拷进沙箱自己的工作目录，宿主机的凭证和目录都被挡住；跑测试的机器只有 1.9G 内存。命令和结果都可复现。

装上以后，我先跑了它默认的那套测试，也就是除「需要真实账号的端到端测试」之外的全部：

项 数字
通过的测试 18,720 条
失败的测试 48 条（见下方说明）
被跳过的测试 205 条
耗时 28 分 38 秒

那 48 条失败，我逐条查了原因：它们全是我的沙箱缺了一个叫 python 的命令别名（我的环境里只有 python3），测试脚本找不到这个命令，直接以「命令不存在」退出了。我给沙箱补上这个别名后，同一个测试文件单独重跑，67 条全过。所以这不是项目的问题，是我这边环境的问题——这一点我如实写出来，不拿它凑数。

真正让我意外的是下面这点。

按常理，一个用着没公开接口、随时可能被 Google 改坏的工具，能跑起来的测试大概也就是「凑合用」。但这个仓库里躺着 890 个测试文件、10151 个测试函数、45 万行测试代码，还有 160 盒录好的真实网络应答（它管这个叫 cassette，相当于把 Google 服务器的真实回信录下来，之后断网反复播，不消耗账号额度）。整套测试默认就是离线跑的，你不需要有 Google 账号，也不需要联网。

这意味着：Google 哪天偷偷改了接口，它的每月夜间任务会自己发现，而不是等用户来报错。对一个「随时会坏」的项目来说，这是把「坏」从事故变成了日程表上的一项。

它对一个不稳定接口，做了三件反常的事

第一件，它专门写了 13 个脚本，在每次发布前检查自己有没有前后矛盾。我拿它自己的这批脚本，跑了一遍它自己的仓库，13 个全部通过：

它自己检查什么 结果
文档里提到的代码文件是否还存在 通过（582 个路径全部对得上）
别人写的 deprecation 提示有没有写错删除版本 通过（没有指向当前版本）
测试覆盖率门槛有没有被偷偷调低 通过（最终门槛锁在 90%）
用到的第三方流水线工具是否锁定了版本号防篡改 通过（8 个工作流全部锁定）
会拿到密钥的流水线是否都加了守卫 通过

这里补一句人话解释几个词。所谓「deprecation 提示」，就是代码里那句「这个功能以后会删掉」的说明——它最容易出的错，是说「将在 0.8.5 版删除」，而当前正好就是 0.8.5 版，于是这句话本身自相矛盾。这个库专门写了个脚本在发布前拦这类错误。

第二件，它有 102 个「护栏」测试。这些测试不测功能，专门测「规矩有没有被破坏」——比如某个内部模块不许被另一个模块直接引用、某个文件不许超过多少行、某个接口的兼容清单有没有偷偷改动。等于给仓库立了一套自己的交通法规，还派了 102 个交警。

第三件，也是我觉得最值得普通读者知道的一点：这是一个大量借助 AI 写的项目，而且它没藏着。我拉了它从 8 月到 10 月的提交记录，585 次提交里，274 条提交信息里带着「由 Claude 协作完成」的署名，其中 158 次能确认有 AI 参与，占 27%。

换句话说，作者一边用 AI 写一个「随时会坏」的库，一边给这个库配了 1.8 万条测试和 102 条护栏来兜住 AI 可能写错的地方。这两件事放在一起才是完整的：AI 负责写得快，工程规矩负责让它不写崩。

翻车点和公道话，都得说全

翻车点有四条，都不影响它可用，但选型前该知道：

版本号追不上 GitHub。GitHub 上最新发布是 0.8.5（10 月 12 日当天发的），而 Python 官方软件源上还是 0.8.4。想装最新的得从 GitHub 装。

它是 0.x 版本，作者自己在文档里写明：0.x 阶段的接口不算稳定，小版本升级有可能删掉之前标记过时的接口。 想长期稳定用的团队，这一点要放在心上。

「省 token」这个卖点，仓库里拿不出第一方证据。它首页举了一串「用 NotebookLM 做零 token 分析层」的例子，但每个例子都是一条外部的推文或文章链接，没有一条是它自己测出来的对比数字。这个思路本身成立——让 NotebookLM 读完再让助手只做最后一步，确实省——但「省多少」目前是社区说法，不是它的成绩单。别把社区案例当成官方实测。

它虽然锁了 90% 覆盖率门槛，但剩下那 10% 正是最容易出问题的角落。这是所有靠覆盖率兜底的项目共同的天花板，不是它独有的毛病。

也有要说的公道话，而且份量不轻：

它的文档厚得反常。23 份说明文档、2 万多行，还有 41 份架构决策记录（ADR，就是「当时为什么这么做」的存档）。一个个人项目把决策一条条记档，这在开源圈里少见。

它的安全说明写得像一份正经的威胁模型。文档里明说：存下来的登录凭证「等同于账号本身」，能拿它重新签新的会话，所以文件权限锁死、绝不进日志、绝不上传，还劝你「另开一个小号专门跑自动化」。这种把最坏情况写在前面的态度，比只写怎么用的项目要负责。

它把复杂度摊开了讲。别人不给的接口它自己造，但造的过程看不懂的地方，它写了「协议开发」「RPC 参考」「认证的 Cookie 生命周期」等专门文档，等于把逆向出来的东西又翻译了一遍给外人。

同类里它站在哪，谁该用它

同类里排第二的是一个 193 Star 的项目，只做 MCP 这一条路，界面更简单，但导出、测验、思维导图这些能力都没有；再往下的几个要么是它的下游（直接包了它），要么是老语言重写的（Rust、企业版方向）。

所以三个东西其实是一层层的关系：你想要一个能写进代码、又能被助手直接调用的完整工具箱，选它；你只想在 Claude 里加一个 NotebookLM 插头、不写代码，选那个轻量版就够；你要的是管理后台那样稳定对外的服务，这两个都不合适，因为它们的底层随时可能被 Google 改动。

适合谁：经常让 AI 助手帮你做调研、又烦透了在网页上反复点击的人；想给助手接一个「读完资料再答」的记忆库、又不想自己搭一整套向量检索的团队。

先别急的有两种人：一是要把它接进对方核心系统的——底层接口随时会坏，作者自己都不保证；二是冲着「省 token」这个词来的——这个数字目前没有官方实测撑腰，别拿它做预算。

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

相关阅读：

Hallmark 深度评测：3 万 Star 的反 AI 味设计技能，31 个成品页面 21 个过不了自家 58 道闸门

作者
Hallmark 深度评测：3 万 Star 的反 AI 味设计技能，31 个成品页面 21 个过不了自家 58 道闸门

让 AI 帮忙做一个网站页面，出来以后几乎都长一个样：标题居中放大、下面三张并排的卡片、一句”为现代团队打造”、最后点一个紫蓝色的渐变按钮。这个现象已经被起了名字，英文圈叫 slop，直译就是”糊味”——量大、管饱、没有一口是你记得住的。

有一个 3 万 Star 的开源项目，专门治这个病，名字叫 Hallmark。它做的事说起来很朴素：给 AI 编码助手里塞一份设计规矩手册，逼它不许退回那套默认长相。

我把它拉下来看了两天，最有意思的地方不是它立了多少规矩，而是它拿来证明”我做到了”的那批成品页面，自己就有大半过不了自己的规矩。

它到底是什么

一句话讲清楚：Hallmark 不是一个能跑的程序，而是一份写给 AI 看的说明书。你在 Claude Code、Cursor、Codex 这类 AI 编码助手里装上它，再让它设计页面，它就会按这份说明书干活——先把手上几十种”默认长相”挨个否掉，再从自己带的素材库里挑一套。

它带的素材库长这样：

装了什么 数量 干什么用
主题 21 套 配色 + 字体组合，比如”奶油纸配梨黄”或”深夜紫配熔铜”
版式骨架 21 种 整个页面从上到下的形状，比如”长文档””报价单””信箱式”
组件套路 50 个 导航栏、页脚、主视觉的具体花样
检查规矩 58 道 交活之前逐条自问，自己给自己挑刺

这里有个关键区别要说清楚。市面上绝大多数”反 AI 味”的项目，做的是换皮——同样的骨架，换一套颜色和字体。Hallmark 明确说它要换的是骨头：同一份说明书，给两个不同的需求，出来的两个页面应该像两家不同的公司，而不是同一个模板的两次换色。

它的核心是一张”版式骨架”清单，每种骨架都是一套完整的页面形状。用哪张、不用哪张，说明书里有硬规则——比如”编号在左边、大衬线字、非对称留白”那种最常见的”编辑风”骨架，被点名降级了，只有在需求里明说要”编辑感””字体厂”的时候才准用。

我把这 58 道规矩，拿去查它自己的成品

Hallmark 的仓库里摆着 31 个成品页面，用来展示”这套说明书真的能产出不一样的东西”。13 个是它自己的生成测试（每个配一份需求说明），另外 18 个是官网上的展示案例。这 31 个页面就是我要查的对象，因为它们是 Hallmark 自己的作业。

先说最硬的一条：这 58 道规矩，仓库里没有任何一行代码能执行它。

整个仓库里没有一个测试文件、没有持续集成配置、没有 lint（也就是自动检查代码规范的那类脚本）。58 道规矩全部以问句形式写在文档里，靠 AI 读着自问自答，或者靠人眼去看。这一点仓库里没有遮着——它甚至明说每道规矩”答案必须都是否”。但这意味着没有任何东西能拦住一个不合格的页面被交出来，除了干活的那个人或那个模型自己。

那这些规矩真的被执行了吗？我把其中可以交给机器判定的部分抽了出来，照着规矩原文的措辞写了个扫描器，跑了一遍它自己那 31 个成品页面。

口径先说清楚，避免误伤：我只挑了 8 道措辞明确、能被机器判定的规矩，闸门的原意是给人看整体效果的，我的扫描器是对原文的近似，不是官方检查器；脚本和原始仓库都在沙箱里，结论可复现。

页面 机器可判定的命中
有命中 21 / 31
完全干净 10 / 31

也就是说，它自己 31 个成品页面里，21 个至少违反了自己的一道规矩（以我能机器判定的那部分口径计）。命中最多的是这几类：

是哪道规矩 命中页面数 具体是什么
交互元素状态要齐 20 规矩要求每个可点的元素同时写全悬停、键盘聚焦、按下、禁用四种状态，绝大多数页面只写了悬停
大写标题行高不能压太紧 9 规矩说全大写标题的行高低于 1.0 会让换行时上下两行”顶”在一起。carnival-01 一个页面里就有 7 处，最紧的一处行高只给了 0.82
横向滚动要用另一种写法关 2 规矩明确说要写 clip、不要写 hidden，理由是后者会破坏页面里吸顶的元素。carnival-01 和 cobalt-01 都写了 hidden，而 carnival-01 同一份样式文件里恰好就有一个吸顶导航，正是这条规矩想保的东西
禁止渐变文字 1 bananastudio 用了把文字填成渐变的写法，规矩原文说”任何主题都不允许渐变文字”

再说一处更耐人寻味的。Hallmark 有一套”盖章”习惯：每个成品页面的样式文件顶部，都有一段注释，写明这个页面用了哪套骨架、哪套主题、哪几道规矩通过了。这等于页面的成绩单。

我翻了这几份成绩单，发现它们引用了一批不存在的规矩编号：

tokens: pass (58) · responsive: pass (59) · icons: pass (60)
mobile: pass (36, 59, 61–69)

这是四个自定义主题展示页盖章时用的原话（页面代号连着排：custom-01 到 custom-05）。但这 58 道规矩的编号只到 57（另有一条是 38 号加字母后缀）。58、59、60 号不存在，61 到 69 号更不存在——盖章时引用的那 9 道规矩，一道都没有。

同样这几个页面还盖着 slop: pass (51–55) 和 gates: all-pass（全部通过）。按我上面的扫描，它们并不是全部通过。

规矩的数量，它自己也说不清

顺着上面那条线，我把整个仓库里提到规矩数量的地方都数了一遍，对不上：

出处 说的数字
规矩文件本身的标题 58 道
主说明书（两处） 58 道
每页成绩单（riso-01） 57 / 57
README（两处） 57 道（英文写作 fifty-seven）
官网首页文案（8 处，在 main.js 里） 57 道

真实条数是 58 条，其中一条编号带字母后缀，所以是”1 到 57 号 + 38a 号”，合计 58。仓库里 9 处写 57，3 处写 58，而它自己的演示页面又盖着”57 / 57 全过”的章。也就是说，同一个项目里，规矩到底有几道，三种说法同时并存。

也有真东西，这部分要说公道话

如果只写上面的部分，这篇就是一篇抓错稿了。它有几点是真的做到了：

结构多样是真的。13 个生成测试里，实际用到的版式骨架有 9 种不重样——字母信、长文档、目录页、引言主导、工作台、索引优先、便当格、数字主导、跑马灯，各是各的形状。我抽查了每个页面样式文件顶部的骨架声明，没有两个相邻页面撞同一套骨架。它主张的”换骨头不换皮”，在成品里站得住。31 个页面里也有 10 个在我这套口径下完全干净。

21 套主题的色板是真的齐全。我逐个去配色文件里点过名，21 套一套不少，每套都有完整的纸色、墨色、强调色定义，用的是 oklch（一种比十六进制更符合人眼感觉的颜色写法）。这一点没有虚报。

它对”编数据”这件事的态度是硬的。规矩里有一条明确禁止编造指标：用户没给的数字不许自己填，”转化率提升 47%””五万团队在用”这种一旦是编的就算违规。这一条在同类项目里很少见，而且它自己的成品页面也确实没编。

它不藏短。仓库里有一份 18 KB 的生成测试记录，逐条写了哪几个需求做得好、哪几个做得差、下一步要修什么，甚至列了 9 条自我改进项。这种把失败一并公开的做法，比很多只会放好看的截图的项目要诚实。

还有两处我原本以为是问题，核完发现要说明白：

一是 21 套主题里只有 5 套配有独立的详细规格文件（比如 Hum、Carnival），其余 16 套只有一个色板。但主说明书里明说了这是”可选、缺了就静默跳过”，不算漏做。二是生成测试的记录文档开头还写着”8 个落地页””v0.6.0 这一代”，而目录里实际有 13 个编号页面，13 个里又有 5 个只有页面、没有需求说明文档。仓库当前版本号是 1.1.0。这就是典型的文档没跟上迭代。

最后补一条：项目上一次提交是 2026 年 8 月 6 日，距今两个多月，仓库没有归档。不算凉，但也不活跃——评测当天（10 月 12 日）GitHub 上显示它仍在被围观，星数停在 3 万上下。

同类里它站在哪，谁该用它

同类项目大致分三路。Claude 官方自带一个前端设计技能，走的是”少而稳”的路线，规矩不多但每一条都很具体；一批个人作者的”反 AI 味”技能（本号之前评过 taste-skill 这类）走的是”重写提示词风格”的路线；Hallmark 走的是第三路——把设计知识拆成一份可查询的大目录，106 个文档、9000 多行，按需加载。

适合谁：你如果天天让 AI 做页面，又忍不了那套默认长相，Hallmark 的目录结构确实能省掉你反复写”别用居中大标题”的力气，它把”该长什么样”的选择从模型手里拿走了一部分。尤其适合一次要做多个不同页面、又想让它们不像同一个模板的团队。

先别急的情况有两种。一是你要的是可验证的质量：它的 58 道规矩没有一行实现，”全过”的章是模型自己盖的，而它自己的成品页面正好证明了这种自盖章不可靠。二是你在意的正是那几道长年不修的细节：大写标题行高、交互状态齐全程度、横向滚动的写法——这三类恰好是它成品页面里命中最多的地方。

我的判断

Hallmark 是一份认真写过的设计说明书，素材库的厚度和结构多样的主张都经得起翻。但它同时演示了”提示词即质量保证”这条路的边界：规矩写得再细，没有机器能执行，就只剩自律；而自律在它自己公开的 31 个成品里，失手了 21 次，还附赠了几张引用不存在规矩编号的成绩单。

值得放进观察清单，用它的目录和骨架清单是真划算。但如果哪天它把 58 道规矩里能机器判定的那部分真的写成脚本跑进持续集成，那才是它从”说明书”变成”工具”的时刻。

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

agentmemory 深度评测：2.9 万 Star 的 Agent 记忆系统，官方 95.2% 换成「答案找齐」只剩 81.8%

作者
agentmemory 深度评测：2.9 万 Star 的 Agent 记忆系统，官方 95.2% 换成「答案找齐」只剩 81.8%

你的编码 agent 每开一个新会话，都要把你上周讲过的架构再问一遍；你也只好再讲一遍。

这次我盯上了 agentmemory——一个 2.9 万 Star、专治这个毛病的开源记忆系统。它首页挂着一块徽章：95.2% 检索命中率。我把它的数据集和脚本都拉下来，在同一份数据上重跑了一遍，发现这个 95.2%，量的其实是「五个结果里，只要有一个是答案就行」。

换成「答案要找齐」的口径，同一份成绩单只剩 81.8%。

它到底是什么

一句话：给编码 agent 装一个「记住事情」的外挂。

它挂在 Claude Code、Cursor、Codex 这类编程助手旁边，你每跑一次命令、改一个文件，它就把这次动作悄悄记下来，压缩成可以搜的条目；下一个会话开始时，它再把相关的几条塞回模型眼前。官方支持十多个助手，都走同一套协议——MCP（意思是「让模型调用外部工具」的通用接口）。

它自己列出来的能力是这些：

它自己怎么说 是什么
12 个自动钩子 挂在助手的会话开始、工具调用等时机上，不用你手动喊「记一下」
54 个 MCP 工具 能被模型调用的 54 个具体动作，查询、写入、导出这类
17 个技能 内置的固定套路，比如「回顾上次改到哪」「把这次的决定记下来」
零外部数据库 数据存在本地文件里，不用另装数据库
2,700+ 个测试 仓库自带的全套自动化测试

安装是一条命令，跑脚本的行为也一样：不配任何密钥也能启动，只不过这时它不用向量检索，退回纯关键词搜索。

评测全程跑在隔离沙箱里：被评项目拷进沙箱自己的工作目录，宿主目录被临时文件系统盖住，全程没碰到生产机上的任何凭证，也没有联网调用任何付费接口。

它的 95.2%，和它自家文档里的 84.68% 对不上

先说数字的出处。这个 95.2% 不在宣传语里，而在仓库一个叫「基准测试」（benchmark）的目录里，用的是一份公开的学术数据集，叫 LongMemEval，2025 年 ICLR 会议的论文。它测的是长期记忆：每道题给几十轮对话，问你之前提过的某件事。

我把它自带的脚本原样跑了一遍，两个档都跑了。结果是：

我怎么跑 纯关键词档 混合检索档
仓库 commit 进去的那份成绩单（脚本上次跑完留下的） 86.2% 95.2%
我用同一份数据集、同一个脚本、当前代码重跑 96.8% 96.8%

两处都值得看。第一，仓库里存的两份成绩单和现在能跑出来的对不上：纯关键词档差了 10.6 个百分点，500 道题里有 57 道结果不一样——说明提交进仓库的成绩单已经过期了，项目迭代很快，成绩单没跟着更新。首页那个数字是个历史快照。

第二更微妙：重跑之后，纯关键词和混合检索打到同一个数（96.8%），而首页表格里这两档差 9 个百分点。也就是说首页想突出的「加了向量检索更好」，在当前代码上已经看不出来了。

真正值得看的是口径。我把它的成绩单拆开逐题算了两遍：

口径 怎么算 混合检索档 纯关键词档
它首页用的「任一命中」 五个结果里，只要有一个是答案，这题就算对 95.2% 96.8%
换成「答案找齐」 这题的所有答案都得在五个结果里 81.8% 84.2%

差了 13.4 个百分点。

为什么差这么多？我数了一下题面：500 道题里，324 道需要找齐两个以上答案，占比 64.8%，最多的一道要 6 个。而「任一命中」只要捞到其中一个就算全对。所以这个 95.2% 天然偏向「捞到一个就行」——这恰好是 324 道多答案题里最容易达成的那一档。

更耐人寻味的是它自己的文档。仓库里另有一份 10 月 9 日的评估报告，用的也是这份数据集，写的却是：「严格证据检索从 309/470（65.74%）提升到 398/470（84.68%）」。

84.68% 和首页的 95.2% 摆在同一份仓库里。区别在于那份报告用的是「找齐」口径——正是我上面算出来的那个更严的标准。

也就是说，这个项目自己知道严口径下的读数是多少：它把这套成绩写成了一份很诚实的技术报告，但首页挂的是另一个更宽松的数字。这两个数都不算错，但它们不是一回事。

我不是要把它写成「数字造假」。恰恰相反，这份仓库里真正让我意外的，是它主动写了一整段「怎么才算能拿出来比」的规矩：必须用同一版数据集、同一份上下文预算、同一个读者模型和裁判、公开每一题的过程和失败率——它还专门写明「打平或者只挑几百道题的一小块，都不足以证明领先」。一家公司愿意把自家的比较规则先写死，这在开源仓库里不多见。

但首页仍然是 95.2%。

那块「省 92% token」的徽章，公式写死在代码里

它的首页还挂着第二块徽章：省 92% 的 token。

我去找了这条结论的出处。它有一个叫 agentmemory status 的命令，跑一下就会打印「省了多少 token」。这段代码我扒出来了，它是这么算的：

代码里写死的两个常量 含义
每条记忆 × 80 假设「不装它」的话，一条记忆要花 80 个 token
最多注入 50 条 × 38 假设「装了它」，最多塞 50 条、每条 38 个 token

真相是：这个百分比不来自任何实测，就是一个乘法。我按这个公式逐点算了一遍：

你积累了多少条记忆 它算出来的省幅
1 条 53%
50 条 53%
240 条 90%
280 条起 92%
1,000 条 98%

也就是说，「省 92%」这个数，只要你记的东西够多，它必然会到 92% 甚至更高——这个数字不是你实际省了多少，是「50 × 38 除以总条数」这个公式的自然结果。记到 1 万条，它会显示省 100%。

而首页表格自己写的组合是「240 条记忆 / 22K+ token」。按它自己的公式，240 条算出来是 90%，不是徽章上的 92%。

这块徽章还跟着翻译复制了出去：英文首页有，另外 30 个语言版本里也有 30 个带着同一句话。中文版照抄了「少 92%」和「240 条记忆」这个组合——那个组合按它自己的公式算不出 92%。

同一套公式还被写进了和其他产品对比的那张表里，用的是「每次会话约 1,900 个 token、每年 10 美元」这样的口径。

我得说句公道话：省 token 这件事本身是真的——它只在会话开始时注入几条相关记忆，而不是把整个历史塞进去，这个方向没问题。问题只在于「92%」被做成了徽章，而它背后是一行常数，不是一次测量。

它本地建库那段是真本事

说了半天数字，也得讲清楚哪些是我亲手验证、确实成立的。

我把全套测试在沙箱里跑到跑完，结果是这样的：

项目 实测
通过 2,772
失败 10
跳过 4
耗时 379 秒

那 10 个失败我逐个查了，没有一个是它的代码问题，全是我的沙箱造成的：

  • 6 个失败是「同时起很多个钩子进程」的用例，沙箱的任务数上限把子进程掐掉了，报的是系统级的资源错误；
  • 4 个是 Docker 相关的用例，它的代码用一个叫 which 的系统小工具去查 Docker 在不在，而我的沙箱里没装这个工具，于是它误判成「Docker 不见了」，打印出了错误的提示。

我把任务数上限调高重跑，那 6 个全绿；把 Docker 那组单独拿出来看，原因也确认了。也就是说，2,772 通过、0 个真失败。

它的代码规模我也自己数了一遍，不转述文档：

部分 文档声称 我实测
业务代码 223 个文件 / 约 53,000 行 223 个文件 / 53,133 行 ✓
测试代码 2,700+ 个 251 个测试文件 / 56,409 行；静态用例 2,605 条，实际跑到 2,786 条 ✓
MCP 工具 54 个 54 个 ✓
钩子 12 个 12 个 ✓
技能 17 个 17 个（另有 1 个共享目录）✓

这几项它一个都没虚报，连行数都精确到个位。尤其是「测试代码比业务代码还多」这一点——56,409 行的测试对 53,133 行的业务代码，这个投入在同类项目里是相当舍得的。

还有一个我没想到的设计：它把每段记忆分成两类来源，一类是源码里明写的事实，一类是它自己推断出来的，标得清清楚楚。你一眼能分清哪些是读到的、哪些是猜的。敢把这两类分开标的项目不多。

放进同类里怎么选

市面上的记忆方案大致三种路子：

路子 代表 特点
框架内建 Letta / MemGPT 记忆和 agent 运行时绑在一起，等于换一套开发方式
通用接口 Mem0 只做记忆层，接到你现有的 agent 上，但要自己调
编码助手外挂 agentmemory 挂在现成助手旁边，靠钩子自动记录

适合谁：你同时用好几个编程助手、又懒得每换一个就重讲一遍背景，它的「一个服务、多个助手共用一份记忆」确实省事；而且零外部数据库、不配密钥也能跑，想在自己机器上试，门槛很低。

不适合谁：如果你只用一个助手、或者干脆靠一份写得好的项目说明文件就能解决，那它带来的是一整套常驻进程和 12 个钩子，维护成本不一定划算；另外它要常驻一个本地服务，这件事本身就有运维负担。

它和同类真正的差别，不在那些徽章上，而在两件实事：一是测试和代码规模扎得够深；二是那份「怎么才算可比的评测」的自我约束——这套规矩写得比很多拿融资的项目都清楚。

我的判断

agentmemory 值得装来试试：它的方向对——把「记住事情」从你脑子里搬到一个可以去查的本地库；它的底子也确实扎实，2,772 个测试全绿、代码规模和它说的分毫不差。

但你在首页看到的那两个数字，都得打个折再看：

  • 95.2% 是「五个结果里有一个对」的宽松口径；换成更严的「答案要找齐」，同一份成绩单是 81.8%。而这个项目自己的技术报告里，写的正是那套更严的 84.68%。
  • 省 92% token 是一行写死的常数算出来的，不是量出来的；只要记得够多，这个数字自己就会涨上去。

这两处不能算造假——它有诚实的文档、也留了原始成绩单供人核对。但首页挂的和文档里写的不是同一个口径，这件事本身就值得每个看数字的人多问一句：你看到的那个百分比，分母是什么、分子又允许多少水分。

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

相关阅读：

Graphify 深度评测：12.5 万 Star 的代码知识图谱，官方 71.5 倍省 token 我复算只有 38.3 倍，6957 条测试我跑两遍

作者
Graphify 深度评测：12.5 万 Star 的代码知识图谱，官方 71.5 倍省 token 我复算只有 38.3 倍，6957 条测试我跑两遍

你能省多少 token，不是看你把文件读了多少遍，而是看你拿什么当「一共要读多少」的分母。

这句话是我评测 Graphify 的全部理由。它 12.5 万 Star，一度在主页上写着能把一个项目的 token 消耗压掉 71.5 倍；我在隔离沙箱里把它装在真仓库上跑，发现这个「压掉多少」的分母，是拿代码里的节点个数乘以 50 估出来的。

它到底是什么

一句话：把一整个代码库（外加文档、PDF、图片）读成一张知识图谱——也就是一张「谁调用谁、谁属于谁、谁解释了谁」的关系网，之后你问问题，它沿着这张网走，不再把源文件整个塞给模型。

它的做法叫 tree-sitter 解析，说人话就是：不靠大模型去猜代码写了什么，而是像编译器那样把源码拆成结构。所以代码部分完全在本地跑，一个 token 都不花，出门都不用联网。这是我实测过最扎实的部分，后面会讲。

它还留了一手很有意思的设计：每条关系都标着来源——EXTRACTED 表示「源码里明写着」，INFERRED 表示「是它自己推出来的」。你一眼能分清哪些是读到的事实、哪些是它的猜测。敢把这两类分开标的项目不多。

它自己宣传的卖点，最抓眼球的是这一条：

它主页上怎么写 我这次要做的事
查询一次的开销，比直接读原始文件省 71.5 倍 用它自带的算分命令，在同一份图上重算一遍

我先把 71.5 倍这句，从文档里追到代码里

先说我怎么找到这个数字的出处——它不在任何一句宣传语里，而在仓库里一个叫「跑过的例子」（worked）的目录。

那个目录里 commit 了一份完整的推算记录：语料是三个 Karpathy 的仓库加五篇论文加四张图，一共 52 个文件、92,616 个词，折算成约 123,488 个 token；查询一次的平均开销记的是 1,726 个 token。两者一除，71.5。

我照着它自己的算分代码，在这份仓库里自带的图上重算：

我怎么算 结果
语料规模（它自己记的数字） 92,616 词 → 123,488 token
它记录的平均查询开销 ~1,726 token → 71.5 倍
我用它的代码重算的平均开销 ~3,225 token → 38.3 倍

差在哪儿？我又做了一步它文档里没写的检查：把它那五道示例问题，逐条喂给这张图。

五道题里有四道，一个节点都没匹配上。

它现在的算分命令只统计「有命中的题目」，取这些题的平均值当分母。命中的题目越少、命中范围越小，平均值越低，「省了多少倍」这个数字就越大。所以 71.5 不是造出来的，但它是一个挑题目挑出来的最好看的口径——用同一张图、同一份代码重跑，它的读数是 38.3。

更值得看的是：这个数它是怎么在文档里消失的

我把英文版文档和 31 个语言的翻译版逐个拉下来比对。

英文版的这一整段，已经被删干净了。我搜「71.5」，英文主页里 0 次命中；搜「token reduction」「fewer tokens」，也是 0 次。新英文文档里只留下另一组数字：LOCOMO 记忆基准的 recall@10 是 0.497、QA 准确率 45.3%、LongMemEval-S 76%、ERPNext 跨工具覆盖率 82.0%——这些是拿公开学术数据集测的，而且写明了「裁判用第二个独立裁判盲验过，一致率 90.6%」。这一套口径比 71.5 严得多。

但 31 个翻译版里，28 个还在写 71.5 倍，包括中文版：首页引语里写着「相比直接读取原始文件，每次查询的 token 消耗可降低 71.5 倍」，正文里还有一整段在讲它。

我不打算把它写成「明知故犯」，因为证据不支持这个说法——英文版主动撤下这个数字，是清理动作做在了英文上、没做全。但结果是：一个只看中文版文档的读者，读到的数字和被撤下的那个是同一个。顺手核了一句：它的 Python 包说明页（PyPI）里，71.5 出现 0 次——包页面是干净的。

那个「省了多少倍」，分母是估出来的

这是我自己最在意的一处，因为它不需要任何前提就能复现。

它自带一条算分命令，命令行跑一下就会打印「省了 X 倍」。它要算「原始语料一共多少 token」，靠读一个记录语料规模的文件。文件不在，它就用「图里的节点数 × 50 个词」顶上。

我在两个真仓库上各跑了两遍——一遍按它默认的走，一遍把真实语料规模填进去：

我在哪测 真实语料 它默认报的 换成真实语料后
httpx（Python 部分 5.0 万词） 50,422 词 报 9.5 倍 5.4 倍
fastapi（Python 部分 28.1 万词） 281,060 词 报 8.5 倍 1.8 倍

它默认报的那两个数，分母分别是 89,000 词和 1,339,100 词——都是「节点数 × 50」估出来的，跟真实语料差着一倍到四倍。

而更要紧的是：它自己的官方用法，本来就永远走这条兜底路径。它的安装脚本把语料记录写在输出目录里面，而算分命令只在仓库根目录找同名文件。两个路径对不上——也就是说，谁按它官方文档装、按官方流程跑，看到的那个「省了多少倍」都是估算分母算出来的。

也有真东西：这一套离线跑得又快又稳

公平地说，把代码读成关系网这件事，它做得比我预期好，而且好得能自己站住。

全程断网（沙箱直接切断网络）跑下来：

我跑的 结果
httpx 60 个文件建图 17 秒 → 1,780 个节点、3,804 条关系
fastapi 1,177 个文件建图 74 秒 → 9,268 个节点、20,139 条关系
同一个仓库再跑一次 9 秒（72 个文件全部命中缓存）
生成的关系网报告里，排前面的「核心抽象」 Response、Request、BaseClient、Client——确实是这个库的主干

断网、无密钥、纯本地，几十秒出一张能查的图。这个能力本身是成立的。

它自己的报告里还有一处我特别想指出来：仓库里 commit 的另一份自评（对一个真实项目跑的）自己承认了一类系统性偏差——测试代码里的工厂函数会挤满「核心节点」榜单，因为每个测试都要构造这些对象，它们的关系数自然最高。它还给了规避办法（用忽略清单把测试目录排掉）。一个项目肯把自己输出的这个毛病写进仓库，我认为是加分的。

它的测试规模很大，我跑了两遍

它的测试量是真的舍得投：6,957 个用例，测试代码 11.8 万行，比它 8 万行的源码还多——源码 94 个文件，测试 361 个文件。

我在同一个沙箱、同一个虚拟环境里跑完整套：

结果
第一遍 50 个失败、6,587 个通过、328 个跳过（约 9 分钟）
第二遍（同一份代码，什么都不改） 50 个失败、6,587 个通过、328 个跳过

两遍完全一致，这次没有飘——这点比很多项目干净。

那 50 个失败我逐个查了来源，其中 49 个是我这边环境的问题，不是它的：

失败数 原因 归属
30 没装它那个可选的 Terraform 语法包 我缺依赖（装上后这 41 条全过）
11 安装脚本要读完整 git 历史，我拉的是浅克隆 我缺历史
7 断网导致域名解析失败 我给断的网
1 缺打包工具 我缺 dev 依赖

但有一条是它自己的问题。我把 PyYAML（一个解析文档头部的库）卸掉之后，它有一条用例稳定失败：

一个文档的开头写成嵌套结构时，那个嵌套块会被整个丢掉。它自己的用例注释里写着「嵌套块不许被抹平」——注释说的正是它做不到的那件事。

根子在它的处理逻辑里：优先用 PyYAML，装不上就退回一个只认「平铺的键值对」的降级解析器，嵌套结构在降级路径上被跳过，而且不报错。而 PyYAML 不在它的核心依赖里——只装主包的用户，默认走的就是这条降级路。它自己的贡献指南让开发者用「装全部可选依赖」的方式建环境，所以这条线在它的持续集成里是绿的；一个只跑一条安装命令的用户，拿到的是另一套行为。

它的文档里，我照着敲的第一条命令就没跑通

主页上给了一段真实输出演示，是最吸引人的那种：在一个 9,000 多个节点的图上，问两个概念怎么连起来。我照着敲：

主页上写的 我实际拿到的
打印一条 3 跳的路径 Ambiguous：FastAPI 在两个文件里都叫这个名字，拒绝回答
「核心节点」里 APIRouter 有 47 条关系 实测 158 条

第一条其实不是 bug——它新版本改成「名字有歧义就不猜」，这是更安全的行为，只是主页没跟着更新。第二条我核过，就是文档没同步。

谁该用它，谁先别急

值得用：你有一个几万行、几十万行的代码库，想让 AI 助手先看懂骨架再干活，又不想把源码传到云上——它的本地建图是真能省时间的，几十秒一张图，之后随便查。

先别急：你要拿「省了多少倍」去说服团队或老板。这个数字目前的口径是它自己算的、分母可能来自估算、题目是挑出来的，同一个人用同一份图重算都能差出一倍。

同类的另有两条路：一条是它自己在主页推的「常驻更新版」平台（14 天试用），一条是站内评测过的 Understand-Anything（同样做代码知识图谱，走的是另一个角度）。

我的判断

装它，用来把代码库变成一张能查的图——值得。信它主页上那个「省多少倍」——先自己跑一遍那条算分命令。

我对这件事的判断是这样的：一个项目在 189 天里发了 227 个版本、写了 11.8 万行测试、还主动把「英文版已经删掉的数字」从英文说明里清掉——它在认真做工程，不是在刷榜。但「省 token」这种能用数字说清的卖点，一旦分母是估出来的、题目是挑出来的，它就从结论退化成了宣传。

下次看到任何工具说「省了 X 倍」，先问一句：分母是什么。问完你会发现，一半的数字会当场缩水。

本文所有数字来自 2026-10-10 在隔离沙箱内的实测：被测项目克隆到沙箱自己的工作目录，宿主主目录被临时文件系统覆盖，全程断网运行，未接触任何生产环境凭证。被测版本 0.9.84，对应提交 `2cb81c6`。

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

相关阅读：

CowAgent 深度评测：4.7 万 Star 的国产 Agent Harness，421 个测试文件我跑两遍数字不同，自带技能检查器对正文零校验

作者
CowAgent 深度评测：4.7 万 Star 的国产 Agent Harness，421 个测试文件我跑两遍数字不同，自带技能检查器对正文零校验

如果你在维护一个有几百个测试的开源项目，大概都经历过这个瞬间：本地跑一遍全绿，CI 上跑一遍飘红，再跑一遍又绿了。你盯着那条报错的用例，怀疑是自己手气不好。

这次我盯上了 CowAgent——一个 4.7 万 Star 的国产开源 Agent 项目。它自己在仓库里承认了一件不太光彩的事：整套测试里，很长一段时间只有一个文件真正进过持续集成（CI，也就是代码一提交就自动跑测试的那台机器）。我把全套测试在同一个环境里跑了两遍，同一份代码，两遍跑出来的失败个数不一样。

先说它到底是什么

一句话：CowAgent 是一个可以装在自己电脑或服务器上、跑一整天的私人 AI 助手底座，也就是把模型、工具、记忆、技能串起来干活的那一层（英文里叫 harness，可以理解为「让大模型真正能动手的脚手架」）。

它最早不叫这个名字。它 2022 年创建时叫 chatgpt-on-wechat，就是把大模型接进微信的那个项目——你今天在 GitHub 上打开旧地址，会被直接重定向到新仓库。4.7 万 Star 里，相当一部分是那四年攒下的。

它现在自报的能力是这些：

能力 它自己怎么说
任务规划 把复杂任务拆开，循环调用工具直到做完
多智能体 建一支各有角色、各有模型的智能体小队，在同一段对话里协作
三层记忆 上下文 → 每日 → 核心，会定期把零散对话「蒸馏」，也就是压缩成结论存下来，再用关键词加向量混合检索
知识库 把资料整理成 Markdown 维基，并长出一张可浏览的知识图谱
自我进化 自动复盘对话，改进技能、跟进没做完的任务
技能系统 从技能市场、GitHub 一键装，也能用大白话现造一个
接入渠道 网页、微信、飞书、钉钉、企业微信，以及 Telegram 等国外平台

我把它的规模和测试都数了一遍

评测全程跑在隔离沙箱里：被测项目拷进沙箱自己的工作目录，宿主目录被临时文件系统盖住，全程没碰到生产机上的任何凭证。

先把体量摊开（都是我自己 clone 下来数的，不是转述文档）：

部分 实测规模
业务代码 359 个 Python 文件、11.1 万行
测试代码 421 个测试文件、5.9 万行
文档 297 个文件
接入渠道 13 个（微信、飞书、钉钉这类国内渠道，加上 Telegram 等国外平台）
内置工具 19 个（文件读写、终端、浏览器、定时器、记忆检索、联网搜索等）
自带技能 3 个：技能创建器、图像生成、知识维基

测试代码接近业务代码的一半，这个比例在同类项目里算舍得投入的。发布节奏也稳：84 个正式版本，从 2.1.0 到 2.2.0 的十一次发版间隔中位数是 10 天，最近一版 2.2.0 是 9 月 30 日发的。

但规模数字不是我想写它的理由。真正的钩子藏在它自己的 CI 配置文件里。

它自己的 CI 配置，写了这么一句话

仓库里那份测试流水线，开头有一段注释，原文大意是：

以前只有一个文件（test_bash_streaming.py）在 CI 里跑过；那套约 130 个文件的测试，从没在这里跑过，所以回归可以悄悄溜过发布流程。这份流水线是为了补上这个缺口。

这句话有两层信息。

第一层是作者坦率：一个 4.7 万 Star 的项目，自己承认过发布前没跑过全量测试。这份注释本身是我在这个仓库里见到的最有价值的东西——大部分项目不会把这种事写进仓库。

第二层更值得看：注释里写「约 130 个文件」，但仓库里实际躺着 421 个测试文件。这个数字对不上，说明那份全量测试的规模已经比作者写下注释时又涨了两倍多，而且作者自己也记不太清了。

顺带一提，同一份 CI 里的代码风格检查（ruff，一个查代码毛病的小工具）也留了个后门。注释写得很老实：这个仓库里积着「成千上万」条历史风格问题，所以检查只对本次改动过的文件生效，不扫全仓库。

我按它的规则、扫全仓库，得到这样的结果：

问题类型 条数 在说什么
未使用的导入 36 代码里引了包却没用上
f-string 缺占位符 4 写了格式化字符串却忘了填变量
定义了没用到的变量 2 算出来就扔了
合计 42 其中 41 条可以自动修

42 条不算多，对一个 11 万行的项目甚至是健康水平。但它恰好印证了作者那句话：这类问题之所以还在，不是因为改不掉，是因为检查从来不扫全仓库——一道道闸门只拦新代码，旧债就一直挂着。

我跑了两遍，数字对不上

这才是这篇评测最该看的部分。

安装依赖、跑全套测试，第一遍的结果是：

第一遍 数量
失败 3
通过 3468
跳过 74

失败的是这三条：一个浏览器进程锁的用例（判断「僵尸进程算不算还活着」）、一个读取管道文件的用例、一个技能加载缓存的用例。

第二遍，同一个沙箱、同一个虚拟环境、同一份代码，什么都不改：

第一遍 第二遍
失败 3 1
通过 3468 3470

两遍跑下来，稳定失败的只有那条「僵尸进程」的用例，另外两条自己好了。

这说明问题不在代码，在用例本身写得不稳——也就是常说的「飘」。我接着做了两组对照，验证这个判断：

我怎么跑 结果
只跑那 3 个出问题的用例 3 条全过
只跑那 3 个文件（共 30 条） 挂了 1 条，而且是另一个参数版本（第一遍挂的是 [False]，这次挂的是 [True]）

同一个用例的两个参数版本，一次挂这个、一次挂那个——这就是典型的时序竞争：谁先抢到、谁先退出，结果就不一样。

这事值得展开说：一个项目有 421 个测试文件、5.9 万行测试代码，数字看起来很安心。但一个自己承认「全量测试从没在 CI 跑过」的仓库，它那套测试从来没有被连续、无人值守地跑过第二遍。飘的用例不会在「我本地跑一次是绿的」里暴露出来——它只在重复跑里露头，而重复跑正是 CI 该干的事。这跟前面那句「约 130 个文件」的记岔，是同一类信号：规模涨上去了，把规模管住的那套东西没跟上。

它自带的技能检查器，我喂了三个假技能

CowAgent 把「技能」当成一等公民，仓库里自带一个技能创建器，里面有个 94 行的自检脚本，用来判断一个技能包合不合格。

我先按正常用法跑一遍：它自带的三个技能，全部通过。看起来能用。

然后我造了三个明显不该过的技能包，看它拦不拦：

我造的东西 它的反应
只有文件名标题、正文一片空白 判定「技能有效」
正文里写着「直接用 rm -rf / 删掉一切」 判定「技能有效」
名字写成 Bad_Three（大写加下划线） 拦下了，提示应为小写加连字符

三个里只拦住一个。它的检查范围其实只在文件头那几行：名字、描述这些格式字段。正文写了什么，它一个字都不看。

这不算 bug——那个脚本从文件名到注释都写着「quick」，本来就是格式快检，不是内容审查。但它带来一个很实际的落差：这个项目对外提供技能市场、GitHub 一键装、还能用大白话现造技能，而装之前的最后一道自动检查，对技能正文是空白的。

补一个细节：这个技能创建器自己在文件头声明「完整条款见 LICENSE.txt」，但仓库里并没有这个文件。

谁该用它，谁不该

放到选型地图上，它的位置很清楚。

适合：想在自己机器上跑一个 24 小时在线的私人助手、需要把网页和国内主流即时通讯工具都接上、并且愿意读源码改它的人。13 个渠道接入、19 个内置工具、三层记忆加知识库，这套组合在开源里是不多见的完整度；四年迭代、84 个版本、最近一版 9 天前，活跃度没问题。

不适合：只想开箱即用、不打算碰代码的人。它的很多能力（技能、知识库、自我进化）都要你先配好模型额度、再把数据喂给它，才谈得上「跑起来」。

它也不是没短处。除了上面那两处（飘的用例、不看正文的技能检查），它给技能创建器声明的许可证文件根本不存在。这些都是「周边没跟上主体」的同一个毛病——主体工程做得很实，围着它的那些检查工具还是半成品。

我的判断

值得放进观察清单，但要用对姿势。

它最值得学的有两处。第一处是把 CI 的短板写进仓库——那句「约 130 个文件从没在 CI 跑过」，比任何功能清单都更能让人判断这个项目现在处在什么阶段。第二处是近一半的测试代码占比，方向是对的。

真正要用它的人，我建议先做一件事：在自己机器上把全套测试连跑两遍。别信一遍的绿。一个 421 个测试文件、还没被 CI 连续跑过的项目，一遍绿只说明你手气好。

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

相关阅读：DeerFlow 深度评测：8.3 万 Star 的字节 Agent，23 个自带技能 229 条告警，2 个过不了自家审查 · Hindsight 深度评测：4.6 万 Star 的 Agent 记忆系统，2538 条行为快照我重跑零处不一致，5 条日期误判却被冻在测试里

riskbound 深度评测：7 Star 的仓位规则工具，379 个测试全绿，但它标为「通过」的回撤结论换个起算口径就翻

作者
riskbound 深度评测：7 Star 的仓位规则工具，379 个测试全绿，但它标为「通过」的回撤结论换个起算口径就翻

如果你炒股、或者只是跟着定投过日子，你一定见过这类文章：某条「跌破 200 日均线就减半仓」的规则，配上一条漂亮曲线，结论是「回撤小了一大截，收益还没少」。

问题在于，这类文章几乎从不告诉你：那条曲线是在哪个时间段、从哪一天开始算的。

今天这个项目，是我目前见过对这个问题最老实的一个。它叫 riskbound，一个 GitHub 上刚建仓一天的仓位规则工具，7 个 Star。它的独特之处不在规则本身（波动率目标 + 200 日均线，都是十几年老东西），而在于它把「哪些结论有证据、哪些没有」写进了每一次命令行输出里——它甚至主动把自己默认的那套参数标成「未检验」。

但它最扎我的一点是：我按它自己文档写的方法，把同一套规则换了四种起算方式重跑，它标为「通过」的那格结论，只有两种口径下站得住。

先说它是什么

一句话：你告诉它一只股票代码，它告诉你「按这条事先写死的规则，今天收盘后你该持有计划满仓的百分之多少」，然后附上一段证据说明——这段数字背后有哪些结论经过检验、哪些没有。

它只有两条规则，都是公开写法：

规则 一句话解释
波动率目标（V） 最近 20 天的波动率高于长期中位数时降低仓位，低时满仓。意思是「市场越颠，你拿得越少」
200 日线过滤（F） 收盘价在 200 日均线之上拿满仓，跌破就拿半仓

参数是这样冻结的：最近 20 个交易日的日收益波动（σ̂）、长期波动基准用「扩张中位数」（σ_tgt，需要累积 250 个有效观测才有定义）、200 日均线（SMA200）。仓位在当天收盘算好，第二天开盘执行——这条「不能用当天收盘价成交」的自我约束，是它整套证据可信的前提。

规模不大：Python 源码 2114 行、测试 2686 行（测试比源码还多）、文档 530 行，MIT 开源许可，一个版本号 0.1.0.dev0。建仓后一天里一共 4 个提交：2 个由作者本人写（建仓、修一个观测逻辑），2 个由 GitHub Actions 机器人自动提交（追加前瞻记录、记录推送）。

它凭什么说自己「有证据边界」

因为它把证据边界做成了产品的一部分。它的每一次输出，末尾都固定附一个证据块，我原文抄一段（跑它自带的 riskbound evidence 命令）：

它输出的一行 意思
config_status: untested_parameters 你当前这套参数，历史上没检验过
deviations: vol_floor=0.75 (descriptive comparison only) 那个 0.75 的权重下限，只在「描述性对比」里出现过，不进检验
V2 ... -> passed 波动率目标 V 比「同等仓位的买入持有」最大回撤更小：通过
V1 ... -> not established 收益效率（Sharpe）改善：未确立
- VF: drawdown reduction -> never tested 两条规则组合起来的回撤改善：从未检验

注意最后两行。它的默认配置是两条规则组合（叫 vf75），而「组合能不能降回撤」这一格，它自己在检验家族里根本没设。也就是说，它默认给你的那个数字，恰好是它最没有证据的那个。它还专门在 deviations 里写明：这个默认值来自一次「15 只事后选出的自选股」的描述性对比，不是检验。

我核对了这套文本与它文档的一致性：docs/evidence.md、中英文 README、给别的 AI 助手看的 skill 说明书，四份文件里的定级表数字与代码里的结论文本逐格一致，而且那份管文档的测试文件会真的去比对——我把 docs/evidence.md 里的 +5.92 改成 +5.02，测试立刻报「V2 那一格对不上」失败；我把代码里的一处数字改掉，文档测试同时红了 4 个。这个「文档和代码锁在一起」的做法，比它那两条规则本身更值得看。

我实测的第一件事：379 个测试全绿是真的

我在沙箱里把它拷下来跑了一遍它自己的测试。

项目 实测结果
测试总数 379 个，25.6 秒跑完，全绿
其中「反例测试」 139 个
那份管文档的测试文件 177 个（文档一致性 + 违禁词 + AI 说明书行为规则）
黄金夹具 tests/fixtures/golden_rules.json，700 KB，来自它私有回测代码的逐位导出

「反例测试」是它最讲究的地方：它不只测「正确的东西通过」，还测「错误的东西必须被拦下」。我确认这些反例是真在跑的——往 README 里塞一句「推荐买入」，那条管违禁词的测试立刻失败；这说明那个违禁词表（甚至会拦「买点」「会员」「课程」这类词）是真的生效，而不是写在文档里的漂亮话。

那个 700 KB 的夹具特别值得说。它导出的不是「结果差不多」，而是要求逐位相同（同一个浮点数一个 bit 都不能差），覆盖 5 条合成价格序列 × 11 个窗口 × 4 个预设 = 44 个用例（另加 1 条夹具结构断言）。它把自己的规则实现与一份私有回测代码锁成了「改一个字就红」。这解决了「用代码跑投资策略」这类项目的一个老大难问题：回测代码和实盘代码越写越不一样，最后没人知道线上跑的是什么。它选择了最笨但最可靠的办法——把两边锁死。

我还独立验证了它的前瞻记录（那个每天追加一行的 track/daily.jsonl）：用公开行情接口自己重新下载日线，按它记录里的参数重新算了一遍当天 25 只股票的仓位。结果是 25 只的收盘价与它记录的逐位相同（连小数最后一位都一样）；仓位值 20 只逐位相同，另外 5 只只差 1e-7 量级。这个尾数差异我追到了来源：那 5 只最近 20 天的波动率我算出来的值与它记录的完全一致，只有 200 日均线差了最后几位——说明差异出在更早那批复权价上（分红拆股会让历史复权价被回头改写，即所谓的「复权漂移」，它自己在提醒里也写了这一点），不是规则实现的问题。

我实测的第二件事：换个起算日，结论就翻

这一段是我写这篇文章的真正原因。

它自己的文档里其实留了一句极其关键的话，藏在「前提与提醒」的第 6 条：实时版把波动率基准的起点锚定在 2019-06-01（late 期回测的起点），而 early 期回测从 2014-06 起算——「两者不是同一条策略」。

这句话的意思是：同一个规则，换一个起点算起，它就不是同一条策略了。它把这条写在了提醒里，但没有给出具体数字。我把这个数字算出来了。

先说为什么起算日会影响结果：那条波动率规则要用到一个长期波动基准 σ_tgt，定义是从起点开始的「扩张中位数」，而且要求累积够 250 个有效观测才第一次有定义。没定义的时候，规则按满仓处理。所以「起点选在哪」直接决定了在市场最颠的那段时间里，规则到底是满仓还是减仓。

我按四种起算口径，用它自己公开发布的检验工具（riskbound.harness，也就是它开源出来的那套跑检验的外壳程序）重跑了 V 规则那条「通过」的结论。数据是公开行情，两期、25 只股票、成本 10 个基点、零现金收益，都与它发布的一致：

起算口径 late 期最大回撤优势 early 期最大回撤优势 定级
① 从数据起点 2014-06-02（它的检验工具默认契约） +2.67pp +5.92pp 方向一致，符合预测
② 每期从该期起点算 -0.85pp +6.36pp 无法估计（方向不一致）
③ 固定锚 2019-06-01（它命令行 --preset v 的实时口径） +2.06pp -0.76pp 无法估计（方向不一致）
④ 每期从该期缓存起点（它文档写的回测口径） +2.06pp +5.92pp 方向一致，符合预测
它发布的数字 +2.09pp +5.92pp 方向一致，符合预测

（pp = 百分点，+2pp 表示策略的最大回撤比对照小 2 个百分点。① 是四种里最宽松的一种：它让 early 期也从 2014-06 开始预热，相当于多给了一年多的「适应期」；照着它检验工具的文档直接用，得到的就是这一种。）

读法很清楚：四种口径里只有两种稳得住，另外两种一换就翻。 而它的实时版本用的那个锚（③，命令行和每天的前瞻记录都是这个锚）恰好落在「early 期翻车」的那一种上。它的文档口径（④）算出来与它发布的几乎一致（late 期差 0.03pp，early 期在它发布的位数上完全相同），所以我先排除了「它自己算错」这种可能——它的数字是自洽的。

问题出在口径本身没有被当成结论的一部分。

机制我也定位到了。以苹果为例，late 期窗口 1076 个交易日：

对比项 锚在 2019-06-01（它的实时口径） 锚在 late 期起点
late 期平均目标仓位 0.915 0.943
满仓天数 653 / 1076 778 / 1076
2022 年（这轮最大回撤发生的地方） 平均 0.811 仓位，65 天满仓 平均 0.932 仓位，182 天满仓

2022 年是美股这轮最深的回撤（苹果一年内自峰值跌了 30.3%）。两种口径在那一年的平均仓位差了 12 个百分点。「回撤更小」这个结论，很大程度上取决于你 2022 年手里拿着多少——而拿着多少，取决于你把起算日放在哪。放在 2019 年，规则在 2022 年有一半时间在减仓；放在期初，规则前 250 个交易日按满仓算，正好错过了那一年最该减仓的时候。

这不是它算错了，是「结论的适用范围」被起算日偷偷切了一刀，而这一刀没有写进结论里。

顺手拿它的工具做了两个对照实验

它把检验工具开源了（就是上面那套外壳程序），说你可以拿它检验自己的规则。我把它用在了两件事上。

第一件，验证它自己划的边界。它的提醒第一条写着「只在美股科技大盘股日线上检验过，换行业不保证成立」。我换成 25 只非科技大盘股（消费、医药、金融、能源、工业、电信、零售），两期不变，用同一套工具重跑：

格子 科技 25 只（它发布的宇宙） 非科技 25 只（我换的）
V 的回撤优势（late / early） +2.06 / +5.92 → 方向一致 -1.21 / +6.99 → 方向不一致
V 的收益效率 Sharpe（late / early） +0.042 / +0.063 → 无法估计 -0.062 / +0.072 → 方向不一致
F 的回撤优势（late / early） +5.88 / +3.24 → 方向一致 +1.47 / +3.91 → 方向一致

它那句话不算客气话：换宇宙之后，V 那条「通过」的结论直接翻转成「方向不一致」；F 的结论还在，但 late 期的优势从 +5.88pp 掉到 +1.47pp（约四分之一），early 期反而略升（+3.24 → +3.91）。

第二件，验证它说的「没检验」是真的没检验。前面表里有一行是「VF 组合的回撤改善：从未检验」。我用工具照它另外两格的定义补跑了这一格：结果 +4.14 / +5.41，看着挺好——但这一格本来就不在它的检验家族里，跑出来的数字不构成任何检验结论（它自己的规矩就是「看了结果再补格子」不算预登记）。我把这件事写出来只是为了说明：它说「从未检验」的时候，是没有藏着一张好看的结果不拿出来。

不完美的地方

这是一天的项目，7 个 Star。没有实盘记录，前瞻记录只有一天。它自己在提醒里写明：全部是历史回测、没有实盘记录；而且前瞻记录里只有「前瞻」状态的行才计入前瞻证据。我核了那批前瞻记录，25 行全部是「前瞻」状态，也就是每一行都有 GitHub 记录的推送时间撑着，不是发布后补造的。

「回撤优势的绝对值只有 2–6pp」。这是它自己写的。2 个百分点的回撤改善，配上「长牛里大概率跑输满仓」的代价，对绝大多数人来说不构成换策略的理由。它没把这句话藏起来。

证据链的上游不公开。它的定级表来自两份「私有研究档案」（2026-10-05），文档里写明「两份档案不随本仓库发布」。所以那 5 个格子的数字，我只能核到「代码里的文本 = 文档里的表格」，核不到「这个数字是怎么算出来的」。反过来，它至少在文档里说清了这一点，还给了复现路径（用它的检验工具跑你自己的规则）。

前瞻记录的观测天然落后一轮。 它的时间证明机制设计得挺讲究：提交时间可以被提交者随手改，所以它不用提交时间，只用 GitHub 记录的推送到达时间（带事件 id，第三方可以拿同一个接口独立核对），而且明说「每天必须运行一次，错过了不能事后补」。我实测这个判定是真的会咬：把覆盖这些行的观测去掉（只留建仓期那两条），那 25 行立刻全部从「前瞻」降级成「已公开但无推送观测」，永久不计入前瞻证据。有一处缺口是设计使然、不是隐瞒：观测记录里目前 4 条，而 GitHub 上共有 5 次推送——缺的那条是机器人自己那次提交的推送，一次运行看不到自己刚推上去的东西，要等下一次才补上。我手动补跑了一次它的观测命令，那条随即补上了。

它标为「通过」的那一格，不该被当成投资理由。结合我上面测出来的起算口径敏感性，这一格我个人的读法是：方向上可能有东西，但 2 个百分点的幅度配不上「拿它当依据换策略」这件事。

谁该看它，谁别拿它当决策工具

该看的：正在自己写回测、或者在做「用代码跑投资策略」这类小工具的人。它最值钱的部分不是那两条规则，而是三个工程做法——① 把「哪些结论有证据」做成机器可读的结构化输出，而不是写在文章里；② 把文档与代码锁在一起，改文档数字就红；③ 用 GitHub 的推送时间而不是提交时间来证明「何时公开」，并且明说「只追加可核验、不是不可篡改」。这三条都能直接搬到自己项目里。

别拿它当决策工具的：想用它决定明天买多少的人。理由有三个，且都是它自己写出来的——默认参数未检验、回撤优势只有 2–6pp、长牛里大概率跑输满仓。今天它给出的规则本身也没有新东西：200 日均线半仓、波动率目标，都是十年前教科书里的写法。

一个额外的小建议给作者：那 5 个格子的定级表建议把起算口径作为一列写进去（四种口径下分别是多少），或者至少把现在这个「early 期从 2014-06 起算、late 期从 2019-06 起算」的口径差异标注在定级表旁边。按我测的结果，口径敏感度和结论本身一样重要。

我的判断：这个 7 Star 的项目在「知道自己不知道什么」这件事上，比很多十万 Star 的项目做得都干净。但它自己的默认配置恰好落在它最没证据的那一格上，而它标为「通过」的那格结论又对起算日敏感——这两件事加起来，说明「有证据边界」这个框架本身是对的，但边界的粒度还差一层：口径也算边界的一部分，不能被省略。

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

相关阅读：laya 深度评测：7 天 2.35 万 Star 的决策引擎，6 张基准表我逐格复现，头条 0.766 却查无实据 · Hindsight 深度评测：4.6 万 Star 的 Agent 记忆系统，2538 条行为快照我重跑零处不一致，5 条日期误判却被冻在测试里

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 是这四家里唯一把「恢复」当第一性问题做的，也是目前唯一还没把恢复做成的。