验证Agent不要看输出，要看状态diff

构建一个在执行前会确认的 AI Agent，迫使我们直面一个意想不到的问题：如何验证一个操作确实发生了？

显而易见的答案是：检查 Agent 的输出，让它自述做了什么。

递归信任问题

如果一个 Agent 报告"已完成"，然后你用另一个 Agent 来验证这个报告，你不过是在信任链上又加了一层，什么问题都没解决。第二个 Agent 犯错的理由可以和第一个一模一样。你并没有打破信任链——你只是延伸了它。

Action dispatched
  → Agent reports: "done"
    → Verification agent checks: "looks done"
      → System reports: success ✓

每一步都信任前一步的输出，没有任何一个步骤在观察真实世界。

真正有效的方法：状态差异

不要问"Agent 做了什么"，而要问"系统的状态是否如我们所预期地改变了？"

Action dispatched: "send SMS to Sarah"
  → Check sent folder: message present? ✓
  → Compare timestamp: after dispatch? ✓
  → System reports: confirmed ✓

验证过程与 Agent 无关。你不是在让 Agent 给自己的工作打分——你在读取一个完全存在于 Agent 之外的真实依据。

当状态差异不可行时

有些操作不会留下可观察的状态变化。对于这些操作，诚实的回答不是"成功"或"失败"，而是 UNRESOLVED（未决）。

我们在 StareBrain 中将 DENIED_UNRESOLVED 作为永久的一等公民状态——不是一个会衰减为答案的临时占位符，而是一个明确的信号，表明：操作已发出，但我们无法确认发生了什么。

确认界面会将这一状态呈现给用户：

• "你会知道这是否生效"——状态是可观察的
• "你可能无法知道，下面是原因"——状态不可观察

为什么这对于 AI Agent 尤为关键

一个对无法验证的操作自信满满地报告成功的 AI Agent，还不如一个什么都不报告的 Agent。沉默传达的是不确定性。虚假的自信则完全抹杀了这一信号。

验证层必须位于信任链之外。状态差异让大多数操作达到了这一目标。UNRESOLVED 则诚实处理了其余的情况。

StareBrain 是一个 Android AI Agent：说出你想做什么，准确看到它即将做什么，在任何操作运行前确认。尚未正式发布——waitlist 已开放。