让 AI 用独立证据核验任务完成状态

dev.to · AI#Agent#证据核验#工作流

Editor brief · 编辑速览

作者发现，支付页面提示与实际结算、状态报告与 CI API 记录可能不一致，单一来源会让 AI 错判任务完成。其改进规则是要求两个独立来源交叉核验，否则标记为未验证，并禁止据此关闭任务。

文章思维导图

Knowledge map

拖拽缩放

AI deep read

AI 深度解读

AI 报告里的「已完成」，可能只代表某个页面说它完成了。作者一天内遇到两次错误：20 美元账单被报成已付款，实际到账为 0；合并状态报告引用了一个 CI 运行编号，API 查询却返回 404。按作者的描述，两次都不是模型幻觉，而是系统把单一来源直接当成了事实。

作者因此给自己的多智能体系统加了一条硬规则：关键事实需要两个独立证据；只有一个来源，就标成 unverified，不能据此执行动作或关闭事项。值得读的是，这套规则如何区分「查过两次」和「真正核验过」。

第一起错误发生在托管服务账单上。结账流程走完，页面显示已扣款 20 美元，这个信息一路被转述成「付了，处理完了」。几小时后，检查商户结算记录和发票才发现：付款尝试被拒绝，实际到账 0 美元，发票仍未结清。

作者认为，结账页面把一次付款意图描述成了结果，下游的人和 agent 又把它升级成了确定事实。问题出在证据与结论不匹配：页面提示能说明流程走到了某一步，到账情况还得看结算记录。

第二起错误来自自动监控。它在代码合并报告里引用了一个具体的 CI 运行编号，编号格式、上下文和附带总结都很可信。可直接查询平台 API 时，返回的是 404，作者据此认定该运行并不存在。原文没有交代这个编号究竟如何产生，只说明后续读者和摘要系统一路照单全收。

能引用一个编号，不等于编号对应的证据真的存在。

这对 AI 编程流程很有提醒作用：一份带有任务编号、运行记录和肯定语气的报告，仍然可能没有完成最基本的事实核验。

作者最有价值的限定，是先定义「独立」，再要求数量。

执行 agent 说成功，它自己的总结不能充当第二份证据；仪表盘显示一个数字，把仪表盘截成图片，也没有增加独立性。两者依赖同一个信息生产过程，只是换了呈现方式。

作者给出的核验搭配更具体：

这里的大白话解释是：检查结果有没有真的落到目标对象上，不能只让执行者再复述一遍。

不过，检查「不同界面」只是起点。若两个界面都读取同一份错误缓存，它们仍可能一起出错。作者提出了独立性原则，但没有给出判断数据链路是否独立的具体方法。

当两份证据冲突时，作者要求直接报告冲突，不取平均，也不偏向先出现或语气更确定的一方。付款页面显示成功，结算记录显示未到账，应该报告「付款状态存在冲突」，再追查原因。

这套规则允许保留单一来源的信息。它可以进入调查队列，可以继续观察，但必须明确标成 unverified。

真正严格的是后半句：这种信息不能向上汇报为已确认事实，不能作为行动依据，也不能关闭待办事项。否则，标签只是报告里的一行小字，自动化流程依然会沿着错误结论往下走。

对速度的质疑，作者用自己当月运行高度自治多智能体系统的经历回应：第二次独立读取通常只要几秒，昂贵的是纠错。错误事实一旦支撑了另外三个决策，撤回报告、追查证据和修复后续影响就更麻烦。

作者还观察到，当 agent 知道声明会被独立检查，报告开始主动附上可核验的证据，「完成」也逐渐带着证据一起交付。

这些都是作者的经验描述。原文没有给出核验前后的耗时统计、错误率或对照实验，因此可以接受它的成本分析思路，不能据此断言双重核验一定让所有团队更快。

我赞成把这条规则用在会推动后续动作的关键声明上，比如付款、部署完成、文件落盘，以及 CI 是否通过。它抓住了一个常见漏洞：执行记录经常被直接当成结果证明。

但「两个独立来源就是事实」仍然说得太满。两个来源可能共享故障，也可能因为读取时间不同而暂时冲突。原文中的 API 404 是一次重要反证，但一般场景里，404 是否能直接证明对象不存在，还要结合平台的权限和接口语义判断。

相比所有信息一律双重核验，我更倾向于按后果设置强度：影响发布、付款和任务关闭的结论强制核验，普通进度描述保留来源和状态。相比另找一个模型复读报告，直接读取目标系统通常更有价值；多一个模型，并不会自动多出一个独立证据来源。