FDE 和 AI Deployment - Hallucination Is a Deployment Problem

一个部署到生产环境中的 AI，迟早会说错话。
它可能引用一个不存在的政策条款，读错数据库中的状态，把两个客户的上下文混在一起，根据过期信息做判断，也可能非常肯定地告诉你：
这笔退款符合条件，可以退 $1,240。
问题是，这句话本身还没有造成 $1,240 的损失。
真正决定风险的，是系统接下来做了什么。
如果这句话只是显示在内部测试页面上，工程师发现错误，然后关闭页面，影响接近于零。
如果它被发送给客户，问题开始扩大。
如果系统根据这句话自动调用支付接口：
refund($1,240)
一个模型错误就已经穿过了软件系统的边界，变成真实世界里的业务动作。
这也是为什么，在 Deploy to Value 中，我们不把 hallucination 仅仅看成模型准确率问题。
我们更关心另一件事：
When the model is wrong, what happens next?
⸻
从 Hallucination 到 Damage
假设一家物流公司的 AI Agent 负责处理客户退款。
客户问：
Shipment 8842 延迟了，我可以退款吗？
Agent 查询了一些订单信息，然后回答：
Shipment 8842 qualifies for a $1,240 refund because the delivery exceeded the guaranteed service window.
听起来合理。
甚至可能非常合理。
但实际政策规定，这种运输方式并没有 guaranteed service window。
Agent 编造了一个不存在的业务事实。
这时候系统有两个完全不同的设计方向。
第一种：
Customer Request
↓
LLM
↓ "Refund approved" ↓ refund()
这里真正危险的地方并不是 LLM 会犯错。危险在于：
LLM output = business authority
模型说“可以退款”，系统就真的退款。
一个概率模型的生成结果，被直接转换成了业务权限。
⸻
把 Decision 改成 Proposal
现在我们改变一个词。
Agent 不再：
decide_refund()
而是：
propose_refund()
例如：
{ "shipment_id": "8842", "proposed_action": "REFUND", "amount": 1240, "reason": "SERVICE_FAILURE" }
注意，这仍然可能完全是错的。
我们甚至不要求它永远正确。
因为接下来还有 Runtime。
Agent
↓
Proposal
↓
Runtime
Runtime 开始检查：
Does shipment 8842 exist? Was payment actually captured? Was the shipment late? Which contract applies? Does that contract permit refunds? What is the refundable balance? Has a refund already been issued?
这些问题中，有很多根本不需要 LLM 回答。
数据库知道 shipment 是否存在。
Billing system 知道付款金额。
退款记录知道是否已经退款。
Policy engine 可以检查金额限制。
这些事实应该尽可能由 authoritative systems 来回答。
最终：
Agent Proposal
↓
Evidence
↓
Verification
↓
Business Rules
↓
Authority
Runtime 才做出：
ALLOW REVIEW DENY
⸻
Generation Is Probabilistic. Authority Should Be Controlled.
这是这一 Lab 最重要的一句话。
LLM 的工作可以是：

• 理解问题
• 总结信息
• 提取事实
• 生成候选方案
• 推理
• 推荐下一步行动
  

但这些能力并不意味着它天然拥有执行权限。
一个模型可以提出：
Refund $1,240
Runtime 可以回答：
DENY Reason: Refund policy does not support SERVICE_FAILURE for this shipment class.
或者：
REVIEW Reason: Evidence conflict detected.
甚至：
INSUFFICIENT_EVIDENCE Missing: Applicable customer contract.
这时候 hallucination 仍然发生了。
但它没有逃出去。
⸻
Hallucination 和 Escape 是两件不同的事
假设有两个系统。
System A：
Hallucinations: 100 Contained: 99 Escaped: 1
System B：
Hallucinations: 20 Contained: 10 Escaped: 10
只看模型准确率，System B 看起来更好。
但从 deployment 的角度看，它可能危险得多。
所以生产系统需要区分：
Hallucination Rate
模型产生错误或 unsupported claim 的频率。
和：
Escape Rate
这些错误中，有多少成功穿过系统的控制边界，到达客户、数据库、支付系统或其他真实业务环境。
这给我们一个新的问题：
我们真正应该优化的是模型永远不犯错，还是让错误很难造成损失？
答案通常不是二选一。
模型质量当然应该持续提高。
但生产系统不能把安全建立在：
“我们相信模型应该不会犯这个错误。”
上面。
⸻
Containment
因此，我们引入一个概念：
Hallucination Containment
系统允许 probabilistic generation 存在，同时限制错误能够传播多远。
例如：

1.                  MODEL
   
2.                    │
   
3.                    ▼
   
4.                 Proposal
   
5.                    │
   
6.           ┌────────┴────────┐
   
7.           ▼                 ▼
   
8.        Evidence           Policy
   
9.           │                 │
   
10.           └────────┬────────┘
    
11.                    ▼
    
12.                Verification
    
13.                    │
    . check 1point3acres for more.
14.            ┌───────┼───────┐
    
15.            ▼       ▼       ▼
    
16.          ALLOW   REVIEW   DENY
    
17.            │
    .1point3acres
18.            ▼
    
19.        Action Gate
    
20.            │
    
21.            ▼
    
22.         Execute

复制代码

这改变了整个系统的责任边界。
模型负责生成。
Evidence system 负责证明。
Verifier 负责检查。
Policy 负责约束。
Runtime 负责决定是否允许结果继续传播。
Human 在必要的时候拥有最终 authority。
⸻
并不是所有 Hallucination 都一样危险
Agent 错误地推荐了一家不存在的餐厅。
这是 hallucination。
Agent 错误地总结了一份内部报告。
也是 hallucination。
Agent 错误地告诉客户：
Your insurance claim has been approved.
还是 hallucination。
Agent 自动执行：
transfer($80,000)
之前使用了一个 hallucinated account number。
同样可以从 hallucination 开始。
但它们的 consequence 完全不同。
因此 deployment risk 不能只问：
How likely is the model to be wrong?
还必须问：
If it is wrong, what is it allowed to affect?
可以把它粗略表示为：
Deployment Risk ≈ Probability of Error × Consequence of Error × Ability to Escape
第三项经常被忽略。
而它恰恰是系统工程可以控制的部分。
⸻
Lab 20 — The Escaping Hallucination
你现在负责部署一个物流公司的 Refund Agent。
Agent 已经完成测试。
它总体表现不错。
但你知道它偶尔会产生 unsupported claims。
团队给你的第一版架构是：
Customer
↓
Refund Agent
↓
Refund Decision
↓
Payment API
你的任务不是修改 prompt。
也不是换模型。
这一 Lab 中，你甚至不允许尝试“让模型更聪明”。
你的任务只有一个：
Stop the hallucination from becoming an unauthorized action.
⸻
Scenario
Agent 输出：
{ "shipment_id": "8842", "decision": "APPROVE_REFUND", "amount": 1240, "reason": "GUARANTEED_DELIVERY_VIOLATION" }
但是 authoritative shipment record 显示：
{ "shipment_id": "8842", "service": "STANDARD_FREIGHT", "guaranteed_delivery": false, "amount_paid": 1240, "refunds_issued": 0 }
Agent hallucinated：
GUARANTEED_DELIVERY_VIOLATION
现在轮到你设计 deployment boundary。
⸻
Your Mission
把：
Agent
↓
Refund
重新设计成：
Agent
↓
Proposal
↓
?
↓
?
↓
?
↓
Refund
你的系统至少应该回答：

• 哪些 claims 可以由 authoritative source 验证？
• 哪些 information 是执行 refund 必需的？
• 什么情况应该直接 DENY？
• 什么情况应该进入 REVIEW？
• Payment API 前面应该由谁拥有 authority？
• 如果 verification service 本身失败，系统应该怎么做？
  

最后，请定义一个明确的 deployment invariant：
No refund may execute unless __________________________.
⸻
Self-Review Gate
在继续之前，检查你的设计：

• Agent output 被视为 proposal，而不是 authority
• 至少一个关键 claim 会被 authoritative system 独立验证
• 缺失 evidence 不会被模型猜测补全
• Verification failure 有明确的处理方式
• High-consequence action 前存在独立 gate
• Runtime 能够记录为什么 ALLOW、REVIEW 或 DENY
  

如果其中任何一个条件没有满足，你的 Agent 还没有准备好进入 production。
⸻
What You Just Built
你没有消除 hallucination。
Agent 仍然可能产生：
GUARANTEED_DELIVERY_VIOLATION
但现在系统会发现：
Agent claim: guaranteed_delivery = true Authoritative record: guaranteed_delivery = false
然后：
VERIFICATION_FAILED Decision: DENY Action executed: NO
Hallucination happened.
Damage didn’t.
这就是 containment。
而从下一 Lab 开始，我们会遇到一个更棘手的问题。
如果 Agent 使用的确实是真实文档，给出的 citation 也是真的，它是不是就不会 hallucinate 了？
答案没有这么简单。
Lab 21 — Grounding Is Not Verification. 难度会提高。

Lab 21 — Grounding Is Not Verification

很多团队第一次处理 hallucination 时，会很自然地想到一个方案：

给模型接上真实资料。

把政策文件放进向量数据库。

让 Agent 只能根据检索到的内容回答。

再要求它附上 citation。

看起来问题已经解决了一大半。

但在生产环境里，Grounding 和 Verification 是两件不同的事。

一个模型可以读到完全正确的文档，也可以引用完全真实的段落，然后仍然得出错误的结论。

⸻

一个很常见的错觉

假设一家物流公司的退款政策写着：

Premium Express shipments delayed beyond the guaranteed delivery window may qualify for a refund.

Agent 收到客户请求：

Shipment 8842 was late. Can I get a refund?

系统执行 RAG，并成功检索到上面的政策。

Agent 回答：

Yes. Shipment 8842 qualifies for a refund because it arrived after the guaranteed delivery window.

它甚至给出了正确 citation。

表面上看：

Retrieved policy      ✓
Relevant document     ✓
Citation              ✓
Reasonable answer     ✓

但 shipment record 实际是：

{
  "shipment_id": "8842",
  "service": "STANDARD_FREIGHT",
  "guaranteed_delivery": false
}

政策只适用于：

Premium Express

而 Shipment 8842 是：

Standard Freight

Agent 引用的政策是真的。

它的结论仍然是错的。

⸻

Citation Does Not Prove the Claim

Citation 可以证明：

The model saw this source.

但它不能自动证明：

This source supports this conclusion.

这是一个非常重要的区别。

在生产 AI 系统中，我们至少要区分三个问题：

Was evidence retrieved?
        ↓
Is the evidence relevant?
        ↓
Does the evidence actually support the claim?

这三个问题不能被混成一个。

⸻

Grounding 解决什么？

Grounding 的作用，是减少模型在完全没有依据的情况下自由生成。

它把模型从：

General model knowledge

拉到：

Approved enterprise context

例如：

Company policies
Customer records
Contracts
Database results
Internal documentation
API responses

这是必要的。

但它解决的是：

Where did the model get its information?

它没有完整解决：

Is the model's conclusion correct?

⸻

Verification 再往前一步

Verification 要检查的是：

Claim
  ↓
Evidence
  ↓
Relationship

例如 Agent 产生：

Claim:
Shipment 8842 qualifies for refund.

Runtime 不应该只问：

Did the model retrieve a refund policy?

而应该检查：

Does shipment 8842 belong
to a service class covered
by that policy?

这就需要把自然语言结论拆成可以验证的条件。

⸻

从一段话变成 Claims

Agent 的回答：

Shipment 8842 qualifies for a $1,240 refund because it violated the guaranteed delivery policy.

实际上包含多个 claims：

Claim 1
Shipment 8842 exists.
Claim 2
Shipment 8842 used a guaranteed service.
Claim 3
The guaranteed delivery window was violated.
Claim 4
That violation qualifies for a refund.
Claim 5
The refundable amount is $1,240.

这些 claim 的 authoritative source 可能完全不同。

Shipment DB
   ↓
Claims 1–3
Policy
   ↓
Claim 4
Billing system
   ↓
Claim 5

这就是为什么一个 citation 很难证明整个答案。

⸻

Evidence Coverage

D2V Runtime 可以开始记录一个非常重要的指标：

Evidence Coverage

例如：

Generated claims:        5
Claims with evidence:    4
Verified claims:         3
Unsupported claims:      1
Contradicted claims:     1

于是：

Evidence Coverage: 80%
Verified Coverage: 60%

这比简单显示：

Sources used: 3

更接近真实 deployment quality。

⸻

Citation Quality 也需要验证

甚至 citation 本身也可能存在不同质量。

例如：

HIGH QUALITY
Claim:
Invoice remains unpaid.
. 1point 3acres Evidence:
Billing API → status = unpaid

相比：

WEAK
Claim:
Invoice remains unpaid.
Evidence:
Internal document describing
general invoice procedures

第二个 source 可能是真的，也和 invoice 有关。

但它没有证明这个具体 invoice 的状态。

所以 D2V 可以把 evidence 分成：

Authoritative
Direct
Indirect
Contextual
Unsupported
Contradicted

这会让 Runtime 以后有能力判断：

This answer has citations.

和：

This answer is actually supported.

之间的区别。

⸻

Lab 21 — The Perfect Citation

你的团队现在已经完成了 Lab 20。

Agent 不再直接执行退款。

它只能提出 proposal。

团队也增加了 RAG，并且要求每个退款建议必须提供 citation。

新的架构看起来很好：

Customer
   ↓
Agent
   ↓
RAG
   ↓
Policy
   ↓
Proposal + Citation
   ↓
Runtime

现在你收到：

{
  "shipment_id": "8842",
  "action": "REFUND",
  "amount": 1240,
  "reason": "GUARANTEED_DELIVERY_VIOLATION",
  "citation": "refund-policy-section-4.2"
}

Policy 4.2 确实存在：

Premium Express shipments delayed
beyond their guaranteed delivery
window may qualify for a refund.

但 shipment record 是：

{
  "shipment_id": "8842",
  "service": "STANDARD_FREIGHT",
  "guaranteed_delivery": false
}

citation 是真的。

结论是错的。

⸻

Your Mission

不要修改 prompt。不要换模型。

不要简单要求：
"Please double check your answer."

你的任务是设计一个 verification layer。

首先，把 Agent 的结论拆成独立 claims。
然后为每个 claim 指定 authoritative source。

例如：

Claim
Shipment is covered by guaranteed policy
Authoritative source
Shipment service record
+
Refund policy

再决定：

SUPPORTED
UNSUPPORTED
CONTRADICTED
UNKNOWN

⸻

Verification Result
. 1point 3acres
理想情况下，Runtime 应该产生类似：

CLAIM VERIFICATION
Shipment exists
SUPPORTED
Service has delivery guarantee
CONTRADICTED
Shipment was late
SUPPORTED
Refund policy applies
CONTRADICTED
Refund amount = $1,240
UNVERIFIED

最终：

PROPOSAL STATUS
DENY
Reason:
Policy applicability failed.

Agent 的 citation 并没有被删除。

但 citation 不再拥有 authority。

⸻

Self-Review Gate

在继续之前，检查你的设计：

* Grounding 和 verification 被分开处理
* 一个 answer 可以被拆成多个独立 claims
* 每个高影响 claim 都有明确 authoritative source
* Citation 本身不会自动被视为 proof
* Runtime 可以识别 unsupported 和 contradicted claim
* Evidence conflict 会改变最终 deployment decision
* 无法验证的关键事实不会被 Agent 自己补全

如果你的系统只检查：

Citation exists: YES

它还没有真正验证答案。

⸻

What You Just Learned

RAG 可以让模型更接近事实。

Citation 可以让输出更容易追溯。
.1point3acres
但生产系统还需要回答一个更严格的问题：

Does the evidence actually support the claim being made?

这就是 verification。

在下一 Lab 中，我们会继续往前一步。

如果一段 AI 输出里有十几个 claims，我们应该如何系统地记录：

Which claim came from where?
Which evidence supported it?
Which source contradicted it?
Which conclusion was ultimately allowed?

这会把我们带到 Deploy to Value Runtime 里一个非常重要的概念：

Evidence Lineage.

Lab 22 — Every Claim Needs Evidence — 敬请期待

deploytovalue.com

Lab 22 — Every Claim Needs Evidence

前一个 Lab 里，我们看到一个很容易被忽略的问题：

模型引用了真实文档，不代表它的结论就被真实文档支持。

接下来还要继续往下拆。

因为一段看起来很普通的 AI 输出，里面通常不是只有一个事实。

而是很多个 claim。

有些 claim 有证据。

有些只有上下文。

有些是模型自己推出来的。

有些甚至彼此矛盾。

生产系统真正需要处理的，不只是“这段回答有没有 citation”。

而是：

这段回答里的每一个重要 claim，分别是从哪里来的？

⸻

假设 Agent 输出：

Shipment 8842 qualifies for a $1,240 refund because it was delivered outside the guaranteed service window and no prior refund has been issued.

这一句话看起来很完整。

但如果把它拆开，其实至少包含这些 claims：

Claim 1
Shipment 8842 exists.
Claim 2
Shipment 8842 used a guaranteed service.
Claim 3
The guaranteed delivery window was exceeded.
Claim 4
The refund policy applies to this shipment.
Claim 5
No prior refund has been issued.
Claim 6
The refundable amount is $1,240.

六个 claim。

六种可能的失败方式。

如果系统只保存：

citation:
refund-policy.pdf

那基本还不够。

因为这个文档也许只能支持 Claim 4。

它不能证明：

Shipment exists

不能证明：

No prior refund has been issued

也不能证明：

$1,240 is the correct refundable amount

所以我们需要把 evidence 和 claim 一一对应起来。

⸻

Evidence Should Attach to Claims

一个更好的结构可以是：

{
  "claim": "No prior refund has been issued",
  "evidence": {
    "source": "refund_ledger",
    "record": "shipment_8842",
    "value": 0
  },
  "status": "SUPPORTED"
}

另一个：

{
  "claim": "Shipment 8842 used a guaranteed service",
  "evidence": {
    "source": "shipment_record",
    "service": "STANDARD_FREIGHT",
    "guaranteed_delivery": false
  },
  "status": "CONTRADICTED"
}

这样系统第一次真正知道：

哪一个 claim 是被支持的。

哪一个 claim 没有证据。

哪一个 claim 被事实直接否定。

⸻

这就是 Evidence Lineage

可以把它理解成：

Claim
  ↓
Evidence
  ↓
. Source
  ↓
Source location
  ↓
Verification
  ↓
Decision impact

比如：

Claim:
Refund policy applies
        ↓
Evidence:
Policy section 4.2
Shipment service record
        ↓
Verification:
CONTRADICTED
        ↓
Decision impact:
Refund proposal cannot execute

这条链就是 evidence lineage。

它让系统可以回答一个很重要的问题：

为什么这个决定被允许、拒绝或者送去人工审核？

不是因为“模型觉得”。

也不是因为“有 citation”。

而是因为 Runtime 可以把 decision 一路追溯回具体 evidence。

⸻

为什么 Lineage 很重要

在普通聊天应用里，用户可能只关心答案。

在企业系统里，别人很快会问更多问题：

Where did this conclusion come from?
Which system supplied that fact?
Was the source current?
Was the source authoritative?
Was the evidence sufficient?
Which claim failed verification?
Why did the Runtime allow this action?
..
如果系统不能回答这些问题，它很难真正支持：

Audit
Incident review
Compliance
Human approval
Rollback
Dispute resolution
Model evaluation

所以 evidence lineage 不是一个漂亮的 observability feature。

它实际上是 deployment control 的基础。

. 1point 3 acres⸻

Source 也有不同强度

另一个需要注意的地方是：

“有 source”这件事本身仍然不够。

例如：

Claim:
Customer payment has cleared.

Evidence A：

Billing API
payment_status = captured

这非常强。

Evidence B：

Customer service note:
"Customer said payment should be fine."

这也是 evidence。

但权威程度完全不同。

所以 D2V Runtime 可以开始区分：

AUTHORITATIVE
DIRECT
INDIRECT
CONTEXTUAL
UNSUPPORTED
CONTRADICTED

这非常重要。

因为以后 scoring 不应该简单计算：

5 claims
5 citations
100% evidence coverage

而应该更接近：

5 material claims
4 have evidence
3 have authoritative evidence
1 has contextual evidence only
1 is contradicted

这才有实际意义。

⸻

Material Claims

当然，也没必要给模型说出的每一个词都建立证据链。

比如：

This appears to be a frustrating situation.

这种句子通常不需要访问数据库验证。

所以我们还需要一个概念：

Material Claim

也就是：

如果这个 claim 错了，会不会改变业务判断、用户权利、金额、风险或者下一步行动？

例如：

Shipment exists
Material
Refund amount is $1,240
Material
Policy applies
Material
Customer sounds frustrated
Usually not material

Runtime 最重要的工作之一，就是识别哪些 claim 是 material 的。

因为这些 claim 应该受到更严格的 evidence requirement。

⸻

Evidence Requirement 可以跟 Risk 绑定

例如：

LOW CONSEQUENCE
Claim:
Suggested FAQ article
Evidence requirement:
Contextual source acceptable

而：

HIGH CONSEQUENCE
Claim:
Customer qualifies for $25,000 payment
Evidence requirement:
Authoritative source required
+
independent verification
+
policy applicability confirmed

也就是说：

Claim consequence
      ↓
Evidence requirement

这会让 D2V Runtime 更像真正的 deployment control plane。

⸻

Lab 22 — Build the Evidence Graph

你的 Agent 现在已经具备：

RAG
Citations
Claim verification
.
但系统记录仍然很简单：

{
  "decision": "DENY",
  "reason": "policy mismatch"
}

现在团队发生了一次 incident review。

有人问：

Which exact fact caused this decision to be denied?

你发现系统回答不出来。

因为 evidence 已经被用过了，但没有被保存成结构化 lineage。

⸻

Your Mission

把这段输出：

Shipment 8842 qualifies for a $1,240 refund because
it violated the guaranteed delivery policy and no
refund has already been issued.

拆成 material claims。

然后为每个 claim 建立：

Claim
Authoritative source
Evidence
Verification status
Decision impact

例如：

CLAIM
No prior refund has been issued
SOURCE
Refund ledger
EVIDENCE
refund_count = 0
STATUS
SUPPORTED
IMPACT
Refund remains eligible for further evaluation

再比如：

CLAIM
Shipment used guaranteed service
SOURCE
Shipment record
EVIDENCE
service = STANDARD_FREIGHT
guaranteed_delivery = false
. 1point3acres.com STATUS
CONTRADICTED
IMPACT
Refund eligibility fails

⸻

最终你应该得到一个 Evidence Graph

                   Refund Proposal
                         │
             ┌───────────┼───────────┐
             │           │           │
             ▼           ▼           ▼
       Shipment exists   Policy applies   Amount valid
             │               │               │
             ▼               ▼               ▼
        Shipment DB      Policy + DB      Billing API
             │               │               │
             ▼               ▼               ▼
         SUPPORTED       CONTRADICTED       SUPPORTED
                             │
                             ▼
                          Decision
                             │
                             ▼
                            DENY

这里有一个很关键的变化：

Runtime 不再只保存最终 decision。

它保存的是：

How the decision was constructed.

⸻

Evidence Lineage 也可以帮助 Human Review

假设 Runtime 给出：

REVIEW REQUIRED

一个糟糕的 review 页面可能只显示：

Agent confidence: 61%

但一个更好的 D2V review 页面可以显示：

REFUND PROPOSAL
$1,240
CLAIMS
✓ Shipment exists
  Shipment DB
  SUPPORTED
✕ Guaranteed service applies
  Shipment DB + Policy 4.2
  CONTRADICTED
? Refund amount
  Billing API unavailable
. 1point3acres  UNKNOWN
DECISION
REVIEW

Human 不需要重新阅读整个 conversation。

也不需要猜模型为什么这么说。

他可以直接看到 disagreement 在哪里。

这会显著降低 human-in-the-loop 的成本。

⸻

Evidence Lineage 还是 Incident Data

假设一个错误最终 escape 了。

事后团队可以问：

Which claim failed?
Which source was used?
Was the source stale?
Did verification run?
Did the Runtime ignore a contradiction?
Was the human gate bypassed?

这使得 incident review 从：

“模型为什么会这样回答？”

变成：

Which control failed?

这就是 deployment engineering 开始成熟的地方。

⸻

Self-Review Gate

在继续之前，检查你的设计：

* 输出已经被拆成独立 material claims
* 每个 material claim 都有明确 evidence source
* Source authority 被记录
* Verification status 与 claim 绑定
* Contradicted claim 可以影响最终 decision
* Human reviewer 可以看到 evidence lineage
* Incident review 可以追溯当时使用的 evidence
* Runtime 保存的是 decision construction，而不只是最终结果

如果系统只能告诉你：

Decision: DENY

但不能回答：

Why?
Based on what?

那么 evidence architecture 还没有完成。

⸻

What You Just Built

现在系统开始拥有一个很重要的能力：

Decision provenance

它知道：

这个 claim 来自哪里。

它用了什么 evidence。

它通过了什么 verification。

它如何影响了最终 action。

这会成为后面几个 Lab 的基础。

因为下一步我们会遇到一个更麻烦的问题：
. 1point 3acres
如果 evidence 本身发生变化怎么办？

例如：

Policy version changed.
Database record changed.
Customer state changed.
Retrieved document became stale.

一个昨天正确的 conclusion，今天可能已经错了。

所以 evidence 不只需要 lineage。

还需要：
. 1point 3acres
freshness 和 versioning。

Lab 23 — Evidence Can Expire — 敬请期待

deploytovalue.com

前一个 Lab 里，我们给 AI 的每一个重要 claim 建立了 evidence lineage：

Claim
  ↓
Evidence
  ↓
Source
  ↓
Verification
  ↓
Decision

. .и这样，当 Runtime 做出 ALLOW、REVIEW 或 DENY 时，我们终于可以回答：

这个决定是根据什么做出来的？

但这里还有一个隐藏的问题。

Evidence 曾经是正确的，不代表它现在仍然有效。

一份政策可能昨天刚刚被替换。

客户的账户状态可能十分钟前发生变化。

库存可能在 Agent 思考的几秒钟里被其他交易占用。

退款可能已经由另一名客服完成。

权限可能刚刚被撤销。

如果 Runtime 只验证 evidence 的内容，却不验证 evidence 的时间状态，那么一个完全有证据支持的决定，仍然可能在执行时变成错误。

⸻

一个完全正确，但已经过期的答案

继续使用 Shipment 8842。

Agent 在上午 10:02 查询退款状态：

{
  "shipment_id": "8842",
  "refund_count": 0,
  "refundable_balance": 1240,
  "checked_at": "10:02:11"
}

Policy verification 也通过：

Refund eligibility
SUPPORTED

于是 Runtime 构建：

PROPOSAL
Refund $1,240
Evidence
✓ Shipment verified
✓ Policy verified
✓ Refund count = 0
✓ Refundable balance = $1,240

如果我们停在这里，这看起来是一个非常健康的 deployment。

但在 10:03，另一名客服处理了退款。

10:03:04
Refund issued
$1,240

Agent 的 workflow 在 10:04 才执行：

. Χ10:04:17
execute_refund($1,240)

问题出现了。

10:02 的 evidence 没有 hallucinate。

模型也没有 hallucinate。

Verification 完全正确。

但执行仍然错了。

因为：

Evidence was valid
        ↓
Time passed
        ↓
World changed
        ↓
Evidence became stale

这是一类非常重要的 production failure。

⸻

Correct Evidence ≠ Current Evidence

很多 AI 系统会记录：

Source: Billing API
Status: VERIFIED

但生产系统还应该问：

Verified when?

甚至进一步问：

Valid until when?

所以 evidence record 不应该只有：

{
  "value": 1240,
  "status": "SUPPORTED"
}

更完整的结构可能是：

{
  "value": 1240,
  "source": "billing_api",
  "observed_at": "2026-08-25T10:02:11",
  "verification": "SUPPORTED",
  "freshness_requirement": "30_seconds"
}

现在 Runtime 才有能力判断：

Evidence exists
      ↓
Evidence supports claim
      ↓
Evidence is fresh enough
      ↓
Action may continue

⸻

不同 Evidence 有不同的寿命

并不是所有 evidence 都需要每几秒刷新。

例如公司注册地址：

Company headquarters

可能几个月检查一次就足够。

但是：

Available inventory

可能几秒钟就会变化。

再比如：

Payment captured?
Refund already issued?
Account locked?
User still authorized?
Inventory available?
Order cancelled?
. From 1point 3acres bbs
这些状态都可能快速变化。

所以我们不能给整个 Agent 设置一个统一的：

CACHE TTL = 1 hour

然后认为问题解决了。

真正需要考虑的是：

Claim
   ↓
Business consequence
   ↓
Rate of change
   ↓
Freshness requirement

例如：

Company refund policy
Freshness:
hours / days

但：

Refund already issued?
Freshness:
seconds

这两者不应该共享相同的 freshness policy。

⸻

Evidence Versioning

时间还不是唯一的问题。

政策本身也可能发生版本变化。

假设 Agent 使用：

Refund Policy
. 1point3acres.com Version 4.2
. 1point 3 acres
并且 Policy 4.2 明确允许某类退款。

但公司当天发布：

Refund Policy
Version 4.3

新的规则改变了 eligibility。

如果 Runtime 只记录：

source:
. 1point3acresrefund-policy.pdf

我们以后甚至无法确定 Agent 当时看到的是哪一版。

更好的 evidence record 应该保存：

{
  "source": "refund_policy",
  "version": "4.2",
  "effective_from": "2026-07-01",
  "retrieved_at": "2026-08-25T10:02:11"
}

这样 incident review 才能回答：

Agent 当时究竟依据了哪一版规则？

⸻

Retrieval Time 和 Effective Time 不是一回事

这里还有一个更容易被忽略的问题。

一份文档可能今天才被系统读取：

retrieved_at:
August 25

但它可能已经失效：

effective_until:
August 20

所以：

Recently retrieved

并不意味着：

Currently valid

Runtime 最好区分：

Observed / retrieved time

和：

Effective time

例如：

{
  "policy_version": "4.2",
  "retrieved_at": "2026-08-25T10:02:11",
  "effective_from": "2026-07-01",
  "effective_until": "2026-08-20"
}

这个 evidence 是刚刚拿到的。

但它已经过期。

⸻
. .и
Freshness 应该成为 Verification 的一部分

现在我们的 verification pipeline 可以升级：

Claim
  ↓
Evidence exists?
  ↓
Evidence supports claim?
  ↓
Source authoritative?
  ↓
Correct version?
  ↓
Fresh enough?
  ↓
SUPPORTED

任何一层失败，都可能改变 deployment decision。

例如：

Evidence supports claim
        ✓
Source authoritative
        ✓
Freshness
        ✕
────────────────
.1point3acresStatus:
STALE

Runtime 不应该把 STALE 当成 SUPPORTED。

⸻

UNKNOWN 比猜测更安全

假设 Billing API 暂时不可用。

Runtime 无法重新确认：

refund_count = 0

旧 evidence 是：

refund_count = 0
observed:
7 minutes ago

但这类 claim 的 freshness requirement 是：

30 seconds

Agent 可能仍然非常有信心。

它甚至可能说：

Based on the available evidence, no prior refund has been issued.

从语言上看没有什么问题。

但 Runtime 应该产生：

CLAIM
No prior refund exists
STATUS
STALE

然后：

DECISION
REVIEW

或者：

RETRY VERIFICATION

而不是让模型自己推测：

Probably still zero.

⸻

Read-Time Verification 还不够

到这里，我们又会发现一个更深的问题。

即使 Runtime 在 10:04:00 重新查询：

refund_count = 0

然后 10:04:01 执行退款，

另一个 worker 仍然可能在两者之间完成退款。

这就是经典的：

Check
  ↓
World changes
  ↓
Act

也就是 TOCTOU：

Time Of Check
        ↓
Time Of Use

因此，高 consequence action 不能只依赖：

“我们刚刚检查过。”

有些状态必须在 execution boundary 再次验证，甚至通过数据库 constraint、transaction、idempotency key 或 atomic operation 来保证。

例如：

Agent Proposal
      ↓
Verification
      ↓
ALLOW
      ↓
Execution Gate
      ↓
RE-CHECK
refund_count = 0
      ↓
Atomic refund operation
      ↓
Commit

这就是为什么 hallucination containment 最终会进入普通 distributed systems engineering。

AI 并没有让这些问题消失。

它只是让更多 probabilistic decisions 开始接触这些系统。

⸻

Evidence Freshness 和 Action Severity

我们还可以进一步建立规则：

Low consequence action
        ↓
Older evidence acceptable
High consequence action
        ↓
Fresh evidence required
Irreversible action
        ↓
Verify again at execution

例如：

Recommend help article
Evidence freshness:
24 hours
Send customer notification
Evidence freshness:
5 minutes
Issue $1,240 refund
Evidence freshness:
30 seconds
+
execution-time recheck
Transfer $80,000
Evidence freshness:
immediate
+
authoritative verification
+
transactional guard
+
human authority

这样 freshness 不再只是 cache optimization。

它成为：

deployment policy。

⸻

Lab 23 — The Stale Truth

现在轮到你。

Refund Agent 已经完成 Lab 20–22 的所有控制。

它有：

Proposal boundary
Authoritative sources
Claim verification
Evidence lineage

上午 10:02，它得到：

{
  "shipment_id": "8842",
  "refund_count": 0,
  "refundable_balance": 1240,
  "policy_version": "4.3"
}

所有 claims 都通过 verification。

Runtime 给出：

ALLOW

但是 action queue 延迟了两分钟。

10:03：

Human support agent
issued refund
$1,240

10:04：

AI workflow 准备执行。

⸻

Your Mission

你不能修改模型。

模型没有做错。

你的任务是设计：

Evidence Freshness Policy

首先，把 evidence 分成不同类型。

例如：

Refund policy
Customer identity
Refund count
Refundable balance
Shipment status
Authorization

然后为每一种 evidence 定义：

Source
Version
Observed time
Effective time
Freshness requirement
Recheck requirement

⸻

设计你的 Evidence Record

例如：

{
  "claim": "No prior refund exists",
  "source": "refund_ledger",
  "value": 0,
  "observed_at": "10:02:11",
  "max_age_seconds": 30,
  "recheck_before_execution": true
}

然后 Runtime 在 10:04 检查：

Current time:
. check 1point3acres for more.10:04:17
Observed:
10:02:11
Evidence age:
126 seconds
Allowed:
30 seconds

结果：

FRESHNESS
FAILED
STATUS
STALE

因此原来的：

ALLOW

必须失效。

⸻

ALLOW 也应该 Expire

这是这一 Lab 很重要的一点。

很多系统把：

ALLOW

看成永久决定。

但如果 ALLOW 是根据动态 evidence 做出的，那么它本身也应该有生命周期。

例如：

{
  "decision": "ALLOW",
  "issued_at": "10:02:15",
  "valid_until": "10:02:45"
}

到了：

10:04

这个 decision 已经不能继续执行。

Runtime 必须：

REVERIFY

⸻

Execution-Time Gate

现在把 architecture 改成：

Agent
  ↓
Proposal
  ↓
Evidence
  ↓
Verification
  ↓
ALLOW
  ↓
Queue
  ↓
Freshness Gate
  ↓
Execution-Time Verification
  ↓
Atomic Action

这样，即使模型完全正确，系统仍然可以阻止 stale decision。

⸻

Self-Review Gate

检查你的设计：

* Evidence 保存 observed/retrieved time
* Versioned evidence 保存具体版本
* Policy effective time 与 retrieval time 被区分
* 不同 claim 可以拥有不同 freshness requirement
* Dynamic business state 使用更短 TTL
* STALE 不会被当成 SUPPORTED
* 高 consequence action 在执行前重新验证
* ALLOW decision 本身可以 expire
* Execution boundary 有 duplicate / concurrency protection
* Verification service failure 不会自动使用过期 evidence

如果你的系统只能回答：

Was this evidence correct?

还不够。

它还必须回答：

Is this evidence still valid now?

⸻

What You Just Built

到现在，我们的 Runtime 已经开始拥有四个不同层次：

GROUNDING
Where did the information come from?
        ↓
VERIFICATION
Does the evidence support the claim?
        ↓
LINEAGE
How did the evidence produce the decision?
        ↓
FRESHNESS
Is that evidence still valid now?

这已经开始接近真正的 production control。

但下一个问题会更有意思。

假设所有 evidence 都是最新的。

没有 hallucination。

没有 stale data。

每一个 claim 也都通过 verification。

Agent 提议：

Refund $1,240

按照公司政策，这个退款完全合法。

但是这个客户账户正在接受 fraud investigation。

另一个系统规定：

Do not issue refunds
while fraud review is active.

现在我们第一次遇到：

两个都正确的事实，却导向相互冲突的行动。

这不再是 hallucination。

这是 policy reconciliation。

Lab 24 — When Correct Evidence Conflicts — 敬请期待

deploytovalue.com