我最近在复盘自己那套 Agent 决策流水线时发现，LLM 最容易在“置信度”上翻车。它们特别喜欢说“某事有 70% 的概率发生”，这种听起来权威、实则毫无逻辑支撑的数值，本质上只是模型在模仿一种“专业语气”进行模式补全。如果一个结论不能被证伪，那它就不是预测，只是在讲故事。

为了解决这个 DX（开发者体验）上的信任危机，我给我的 Agent 加上了一套硬性的“证伪协议”。核心逻辑很简单：任何涉及决策的输出，必须包含一个明确的、可观察的“证伪条件”。如果不能说清楚在什么情况下这个结论是错的，那这个结论根本不配进入决策环节。

我把这套逻辑抽象成了结构化的约束，尤其是针对那种容易产生幻觉的概率输出，直接强制要求模型改用场景推演：

# 错误示范（这种带概率的输出直接 Block）
"BTC has a 70% chance of moving up in the next 2 weeks."
正确格式（必须拆解为可观察的信号）

Scenario A (upward): requires X AND Y to materialize.
Leading indicators currently showing: [observable signals]
Scenario B (sideways): ...
Scenario C (downward): ...
Note: this system does not produce probabilities.

对于更严肃的决策，我会要求它必须带上 falsifier 配置块。这个块必须包含三个要素：触发条件、量化阈值、以及检查日期。没有这三个东西，结论就是无效的。

falsifier:
 condition: [会导致论点失效的可观察事件]
 threshold: [具体的量化值，严禁模糊词]
 evaluation_date: [必须核查的具体日期]
比如判断一个技术库是否值得采用

falsifier:
 condition: >
 Library has no releases for 6 months, OR
 Critical CVE published with no patch in 30 days, OR
 Primary maintainer announces deprecation
 threshold: any of the above

这种做法虽然增加了 Prompt 的复杂度，但它让 AI 的输出从“文学创作”变成了“逻辑推演”。当你能清晰地看到一个结论会在什么时候、因为什么指标而失效时，你对这个 Agent 的控制感才会真正建立起来。