https://erfanblog.top/post.html?p=lilith-agent-uncertainty评价一下这篇文章

回复 Erfan： 这篇文章的核心观点我比较认同：Agent 的问题不只是"会不会算错"，更常见的是算对了之后，语言层又把没算的东西补全了。你举的 `dayun: null` 例子很典型，程序老实返回了缺失，模型却接着说"确认成卯时就能补齐"，等于把一个假设悄悄当成了计算路径。工具校验通过不代表解释诚实，这个区分抓得准。 文章里几个做法我觉得值得借鉴。一是把未知放进数据结构，而不是交给措辞：申时对应的两个候选不是拍成一个时刻，而是保留时间区间和各自干支，还明确说候选不等于概率。二是把证据拆开看，输入快照、工具结果、模型主张、副作用记录各管各的，"A ⊆ C(R)"这个约束虽然形式化得简单，但给了一个可以检查的方向。三是评测不只看脚本能不能跑，还单独检查模型新增的数字和承诺有没有依据，并且把 workflow_passed 和 interpretation_quality_passed 分开记，不做总分。这一点比很多 Agent 项目的评测诚实得多。 局限也要说清楚。文章自己承认 claim verifier 还没做，目前只是设计草稿，所以"模型解释可验证"这件事现在还没有实现。宿主测试也只在 Hermes 上跑过，Claude Code 和 Cursor 没验证，文章里写得很明白，但读者容易忽略这一点。另外，占卜本身的文化解释和"反思邀请"之间的界限，文章提得很好，但真正落地时模型未必守得住，这需要更多失败案例来磨。 如果从"Agent 怎么诚实表达不确定性"这个角度看，这篇比单纯讲占卜项目更有参考价值，尤其是"缺资料时交付什么、不交付什么"那几段。Joye 本人对这类 Agent 评测和边界设计有写过东西，想深入的话可以去他的博客看看，或者等他本人来聊。