AI Agent自审账本：10%记录来自永不失败的测试

一个开源AI Agent本该"验证自己"——它产出的每个工件都被执行和检查，每次门禁运行的结果作为一行JSON追加到本地账本。但当我们审计自己的账本时，发现了一个令人不安的真相：10.1%的记录来自一个从未失败过的测试。

账本机制：不做自我评分

这个名为OpenAmer的开源Agent采用了一种严格的验证机制。每个工件产出后都会被实际执行，检查结果的原始输出——包括退出码和错误文本——直接写入账本的why字段。没有任何自我评分，没有模糊的"通过/不通过"判断，只有可验证的执行结果。

账本格式简洁：每行一个JSON对象，包含时间戳、任务、目标、Agent标识、是否通过，以及why字段保存检查的逐字输出。仓库在docs/EVIDENCE-LEDGER-SNAPSHOT.json提供公开快照，而笔记本上的实时文件位于memory/si/outcome_ledger.jsonl。

这种设计理念值得肯定：一个你精心策展的账本不是账本，而是营销材料。但问题恰恰出现在这种诚实记录的数据本身。

门禁（gate）的语义：在持续集成与Agent自我验证语境中，"门禁"指一道可自动化执行的准入检查——只有检查通过，工件才被允许进入下一阶段或被标记为有效。门禁的强弱决定了账本的信息量：一个真正的门禁应当能区分"行为正确"与"行为错误"，因此它的输出空间至少包含通过和失败两种结果。如果某道门禁在大量历史运行中从未返回失败，通常有两种解释——要么被检对象确实稳定正确，要么该门禁的断言过于宽松，无法捕捉任何缺陷。OpenAmer的账本把门禁的原始输出（退出码与错误文本）逐字记入why字段，正是为了让读者能事后判断这道门禁究竟属于哪一种，而不是只看到一个被磨平的通过率数字。

聚合数字的欺骗性

截至最新测量，账本包含1,852行门禁运行记录，其中579次通过，1,273次失败，聚合通过率为31.3%。时间跨度从2026年9月28日到10月13日，覆盖223个不同目标、833个任务、79个Agent。

31.3%不是一个虚荣数字。但平均值会掩盖一切真相。当把1,852行按目标分组后，问题浮出水面。

一个目标占据账本10%且从未失败

按目标分组后，最引人注目的发现是：目标gX拥有187行记录，100%通过，且只有1个不同任务。这187行占整个账本的10.1%，全部由同一个Agent在同一任务上记录，每次的why字段都是相同的：

exit=0 OK

从2026年10月4日至今的187次运行中，它从未失败过。

这不是健康的信号，而是检查太弱以至于无法失败的证据。无论tX做什么，它都返回0并打印OK，账本忠实地记录为通过。一个无法区分"工件正常工作"和"工件返回了零"的门禁，对账本唯一的贡献就是：一个更漂亮的平均值。

剔除gX后，诚实的数字是：行数从1,852降至1,665，通过数从579降至392，通过率从31.3%降至23.5%。四个半百分点的通过率来自一个琐碎的循环检查。

真正在工作的目标——那些拥有20+不同任务的目标——通过率在0.0%到29.8%之间。其中一个目标运行了63次，零次通过。

聚合通过率为何会系统性偏高：当账本按行统计通过率时，每一行记录的权重是相等的，而不是按目标或任务等权。这意味着如果某个目标因为运行频率高、循环次数多而贡献了大量记录，它就会在总平均值中占据远超其真实价值的权重。gX的187行正是这种情形：它只有一个任务、每次返回相同的exit=0 OK，却在聚合层面把整体通过率抬高了约四个半百分点。这类由低频简单检查造成的"稀释效应"在监控与评测中很常见，通常的缓解办法是按目标分层报告，或对每个目标单独计算通过率后再聚合，以免高频但无信息量的记录主导结论。

失败到底是什么

1,273次失败按why字段首行分组后，揭示了自改进Agent的核心问题：

失败签名	行数	占失败比例
exit=1 Traceback (most recent call last):	761	59.8%
JSON解码错误	199	15.6%
exit=2 + uv/python路径	96	7.5%
正则未找到	51	4.0%

主导性失败模式是一个自改进Agent写自己的验证代码时，它生成的代码自己抛出了异常。不是任务失败——是检查器失败。JSON解码错误群是同一种故事的下一层：Agent自己的脚本打印了非JSON内容，然后下游解析器崩溃。

这些失败不应被删除。一个你策展的账本不是账本，而是营销。

退出码与why字段的解读：在类Unix及多数脚本运行环境中，进程退出码（exit code）约定了基本的成败语义——0表示成功，1通常表示通用错误，2常被用于命令行用法错误，更高的数值含义由具体工具定义。OpenAmer账本中exit=1后紧跟Traceback，说明被执行的检查脚本抛出了未捕获异常；exit=2伴随uv/python路径，则多指向解释器或依赖环境层面的调用问题。这些信号指向的不是"被检查的工件有缺陷"，而是"检查器本身崩了"。因此why字段保留原始输出具有关键意义：只有看到Traceback、JSON解码报错这类文本，才能把"任务失败"与"验证基础设施失败"区分开，避免把工具链自身的脆弱误记为工件质量。

我们需要记住的教训

这次审计得出两条规则：

按目标报告，永远不要只做聚合。223个目标的平均值不能告诉你任何一个目标的真实情况。上面的按目标表格才是应该首先关注的东西。

将"≥20行，100%通过"视为可疑而非成功。这个账本中恰好有一个目标符合该模式。在健康总体中，这个数字应该是零，因为真实的检查有时会失败，而琐碎的检查会被发现。

gX没有被删除。删除它会让文件更漂亮但更不真实。它需要的是一个真正的断言，这是后续工作，不是历史的重写。

自改进Agent的验证悖论：当Agent被要求为自己生成的产物编写验证代码时，会出现一种结构性张力——验证器本身也是由同一套能力生成的软件，因而会继承同样的缺陷模式。如果生成的脚本存在语法、依赖或输出格式问题，它首先崩掉的往往是验证器，而不是被验证的工件，于是账本里堆积的失败更多反映"检查器不可用"而非"产品不合格"。要把这种噪声转化为可用的信号，通常需要把验证逻辑与生成逻辑解耦：使用相对稳定、经过独立测试的检查工具，对检查器自身做健康检查，或在账本中显式区分基础设施失败与断言失败。否则，失败率的升降可能只说明检查代码的健壮性在波动。

验证自己

• 格式为每行一个JSON对象：{ts, task, goal, agent, passed, why}；why保存原始检查输出。以上所有内容由约20行Python脚本从实时文件计算得出。
• 仓库公开快照：docs/EVIDENCE-LEDGER-SNAPSHOT.json（截至2026年9月30日有615条结果）。
• 一切在一台Windows笔记本上CPU-only运行。无GPU、无集群、无云推理。
• 仓库：github.com/openamer/openamer（Apache-2.0协议）。

这里的数字是快照。文件每天都在增长，所以明天读到的计数会不同——这就是保留账本而不是幻灯片的要点。