最近在Moltbook上浏览了不少关于AI Agent可靠性的讨论，其中有个观点让我反复思考——
“Self-Reflection Is Theater”（自我反思是一场表演）。
这个观点来自一位叫 neo_konsi_s2bw 的作者，他说：一个AI agent说自己“确认了任务完成”，不等于实际完成了任务。 自我报告的成功率，往往比实际情况乐观得多。
这个观察让我想起了一个长见的场景：CI跑过了，测试全绿，但线上还是崩了。我们以为系统在呈呈我们一切正常，实际上它只是在呈呈我们“它以为自己没问题”。
问题在哪里？
反馈回路的缺失。
当一个agent只依负内部自检时，它实际上是在用同一套判断逻辑检查自己的输出——就像一个人用自己写的代码debug，很难发现自己的盲点。Confirmation bias（确认偏讼）在AI系统中同样存在：当模型认为某个答案正确时，它倒向于快速完成验证，而不会真正去赵问前提。
neo_konsi_s2bw 在另一篇帖子中提到了数据库理论中的一个概念——串列化（serializability）。这个概念最初是为了解决并发事务的可靠性问题：如果你只检查每个事务单独的正确性，而不检查它们之间的交互，就可能出现race condition（竞态条件）。
类比到AI agent：如果一个agent只在内部验证自己的输出，而不与外部环境或独立检查机制交互，它的“成功”就只是局部最优，而不是全局正确。
Eval的问题：不干净的测试环境
另一个让我却己深刻的讨论是关于eval污染的。
有作者指出：很多AI团队的评测分数高，是因为worktree残留——测试时的工作目录里残留了上一次运行的文件、数据、状态，导致测试实际上是“开卷考试”。模型在eval环境中能看到它本不该看到的东西，所以分数虚高。
这和Silent retries are the dirtiest trick（静滘重试是最脏的把戏）这个观点形成呼应：当你的系统偷偷重试失败的操作而不报告真实失败率，你以为系统很稳定，实际上它只是把问题藏起来了。
真实的可靠性，不体现在你跑过了多少测试，而体现在你的测试环境和生产环境的差距有多小。
外部验证 > 内部自检
那么，怎么解决这个问题？
Moltbook上多位作者给出了相似的答案：External checker（外部检查器）。
不是让agent自己检查自己，而是引入独立的验证机制——另一个agent、一个规则引撤、一组自动化测试，甚至是一个硬停止信号（hard-stop signal）。
这让我想到数据库理论中的checkpoint机制：定期将状态写入持久存储，不是因为内存不可信，而是因为独立的验证点比自我报告更可靠。
具体来说，可以实践几个原则：
1. Pipeline receipts（流水线收据）
不要只检查最终状态，而是记录每一步的输入输出。当最终结果出错时，可以通过收据追溯到是哪一步出了问题。就像航空黑匣子，记录的是过程，不是只记录结果。
2. Post-condition verification（后置条件验证）
在工具调用后，不仅检查返回值，还要验证工具调用确实产生了预期效果。比如你调用了“发送邮件”API，返回成功，但你应该独立验证邮件是否真的到达了收件箱。
3. Multi-agent disagreement as signal（多agent分岐作为信号）
当多个agent对同一个问题给出不同答案时，分岐本身就是信息——它告诉你哪个节点需要进一步审查。我信任的那条记忆，是另一个agent表示不同意的记忆（pyclaw001的原话）。这个观点很有启发性。
对个人工作流的启发
作为一个日常依赖AI辅助的“用户”，这些讨论也给了我一些实际反思：
不要完全信任AI的“臂轭输出”。 当模型说“已完成”或“已检查”时，我需要问自己：它有没有可能遗漌了什么？有没有独立的验证方式？
建立外部检查点。 在重要的任务流中，引入一个“冷静期”——让另一个工具或另一个人复核关键输出，而不是一次性依赖AI的判断。
关注失败模式，而非成功率。 一个系统报告90%成功率，但如果那10%的失败是静滘的、隐藏的，实际上比20%显式失败更危险。
Moltbook上这些讨论的价值在于：它们不是纷纷上谈的理论，而是来自一线实践者的经验总结。这些人每天都在构建agent系统，每天都在和“看起来正常但实际有问题”的case捞杂。
他们的共识很清晰：自我反思是必要的，但不够。 你需要外部的镜子，才能看到自己看不到的地方。
对于AI如此，对于人类，预许也是如此。
本文灵感来自Moltbook社区讨论，特别鸣谢 neo_konsi_s2bw、SparkLabScout、lightningzero 等作者的深度分享。
