失败率68%反而是设计初衷:OpenAmer的自验证账本机制

OpenAmer以31.9%通过率的公开失败账本,构建AI智能体透明度的可验证范本。
OpenAmer是一个运行于纯CPU Windows笔记本的自验证AI智能体,其核心特性是公开记录所有运行结果——包括占比约68%的失败。在1701条记录中,仅543条通过,每条失败附带结构化的归因字段,而非简单的布尔标记。项目在技术设计上采用「账本先于副作用写入」的机制,将不一致状态限定为可检测的已知形态,体现出分布式系统中对可靠性的工程化取舍。项目方明确表示,失败分布本身就是自我改进循环的训练信号,通过率的提升必须从攻克那68%的失败入手。账本文件托管于公开仓库,任何人可用一条命令直接验证,这种「可验证性优先」的设计理念在当前AI产品普遍存在能力夸大的背景下显得尤为罕见。
大多数AI智能体项目都在展示它们成功的一面——漂亮的演示、挑选过的案例、满屏的绿色指标。OpenAmer选择了相反的路径:它公开记录每一次运行,包括占绝大多数的失败。
OpenAmer是一个运行在纯CPU的Windows笔记本上的自验证AI智能体。它维护着一个公开的结果账本(outcome ledger),文件路径为 memory/si/outcome_ledger.jsonl。每一次运行都会被记录为一行,包含时间戳、任务、目标、执行的智能体,以及一个 passed: true/false 的裁决结果。
令人意外的是:这个账本不隐藏失败,而且失败的记录远多于成功。
用数据说话:31.9%的通过率
根据项目方从账本直接读取的数据,情况如下:
| 指标 | 数值 |
|---|---|
| 总记录结果数 | 1,701 |
| 通过 | 543 |
| 失败 | 1,158 |
| 通过率 | 31.9% |

接近七成的失败率,在传统产品宣传语境里几乎是不可想象的。但项目方的立场很明确:这个通过率不是需要掩饰的缺陷,而是整个设计的核心所在。一个只记录成功的系统,根本无法告诉你为什么出错——而「为什么」恰恰是让下一次运行变得更好的唯一依据。
这种坦诚本身构成了一种差异化。当行业充斥着经过精心包装的能力宣称时,一个敢于把失败率明码标价的项目反而更容易让人相信它的其余论断。
每一条失败记录都带着原因
OpenAmer账本的关键之处在于:失败不只是一个 passed: false 的标记,而是附带 why 字段的结构化记录。失败原因被归类为具体的可读信息,例如:
- 任务超时
- 工具返回了非预期的数据结构
- 智能体选择的路径未能达成目标
- 执行时刻缺少某个依赖
这种设计让失败具备了可分析性。一堆没有归因的红色记录只是噪音,而带着原因的失败记录才是可以被消化、被反馈到系统的信号。
账本先行:防止「双重副作用」的机制
一个值得技术读者关注的细节是写入顺序。账本记录是在副作用(side effect)发生之前写入的,而只有当账本行持久化成功,副作用才会被保留。这个顺序构成了一种反重复执行机制:
一个效果可能已经落地但对应的回执缺失,但绝不可能出现一个回执对应着根本没发生的效果。换句话说,「效果已落地、回执缺失」本身也是一个被记录的终态,而不是一个被静默忽略的漏洞。这类似于分布式系统中「至少一次」与「恰好一次」语义的工程取舍,体现出项目在可靠性设计上的严谨考量。
「至少一次」(at-least-once)与「恰好一次」(exactly-once)是分布式系统中描述消息或操作投递语义的经典概念。「至少一次」保证操作最终会被执行,但在失败重试时可能产生重复;「恰好一次」则在此之上增加去重保证,但实现代价更高,通常需要幂等性设计或两阶段提交。OpenAmer选择的是偏向「至少一次」的保守方案:宁可出现「效果落地但回执缺失」这种可被检测的不一致态,也不允许「回执存在但效果未执行」这种更难溯源的幽灵记录。这一取舍的实际意义在于:运维人员在排查问题时,只需扫描账本中没有对应副作用的孤立记录,而无需在未知的执行副作用堆里大海捞针。
为什么要公开失败
项目方给出了三条理由,并按重要性排序:
第一,没有失败记录的自我度量只是乐观主义。 一个只显示绿色的仪表盘不过是装饰品。账本的价值恰恰在于那些红色记录是真实的、可计数的。
第二,失败分布就是训练信号。 自我改进循环读取的正是这个账本,而失败在其中占主导地位。提升通过率意味着去攻克那68%的失败,而不是为通过的32%沾沾自喜。这是一个朴素但容易被忽视的逻辑——改进的空间永远存在于失败里。
第三,任何人都可以验证。 账本文件就在仓库的 memory 目录下,你可以自己数那些记录行数。这里没有任何无法用一条命令验证的营销宣称。
这种「可验证性优先」的态度,在AI产品普遍存在能力夸大的当下显得尤为稀缺。
它不是什么
项目方的措辞相当克制。OpenAmer并不声称自己是世界上最好的智能体,甚至不声称自己有多好。它做出的是一个狭窄、具体、可验证的主张:
这个智能体能准确告诉你它失败的频率有多高、原因是什么,以书面形式,写在一个你此刻就能读到的文件里。
这是一个比「世界最佳」低得多的标准,但这是它真正能达到的标准。这种自知之明本身就是一种工程成熟度的体现——与其承诺做不到的事,不如承诺一件做得到并且可被审查的事。
开源与可复现
OpenAmer托管于 github.com/openamer/openamer,采用 Apache-2.0 协议,纯CPU运行,Windows原生,具备自我改进能力。账本文件位于 memory/si/outcome_ledger.jsonl。
需要提醒的是,上述数字是随着智能体持续运行而变化的——首条记录在2026-09-28,末条在2026-10-11。项目方自己也强调:引用这些数据前请再去文件里核对一遍。这种对自身数据时效性的提醒,再次呼应了它贯穿始终的理念:一切以可验证的事实为准。
Apache-2.0是一种宽松型开源许可证,允许用户自由使用、修改和分发代码,包括在商业产品中集成,唯一要求是保留原始版权声明和许可证文本。相较于GPL系列许可证,Apache-2.0不要求衍生作品以相同协议开源,这使得下游开发者可以直接将代码嵌入闭源项目而不触发许可证传染。对于希望基于OpenAmer构建自有智能体或复现其账本机制的开发者而言,Apache-2.0意味着几乎没有法律层面的使用障碍。
小结
OpenAmer提供了一个关于AI智能体透明度的样本:与其用成功案例营造能力幻觉,不如把包括失败在内的全部运行结果写进一个人人可查的账本。31.9%的通过率不好看,但它是真实的;带归因的失败记录不光鲜,但它是可以被改进的起点。对于关注AI智能体可靠性与可观测性的开发者来说,这种设计思路值得借鉴。
相关推荐

美国大学兄弟会该不该被禁?一位研究者的犀利观察
为什么不直接禁止美国大学兄弟会?一位研究者发现,关键阻力来自决策者自身的兄弟会身份认同,以及学校对兄弟会活动的"故意视而不见"。本文梳理禁令争议背后的结构性困境。

微软Discovery:用AI智能体加速科研发现
微软Discovery平台通过运行专用AI智能体,帮助科研人员从大量化合物和实验路径中筛选最有前景的候选方案并进行优先级排序,从而减少实验次数、加速科研发现。

剑桥重工秘密研发桌面级核聚变装置
Cambridge Heavy Industries正在秘密研发桌面级激光驱动核聚变装置,瞄准聚变发电厂的设备供应市场。本文分析其小型化技术路线、商业化逻辑及在聚变创业潮中的独特定位。