agent 输出里加一个 confidence 字段

让 agent 自动处理有后果的账，你就得一直回头盯它有没有认错人。一天几十个 webhook，"万一错了"这种念头就跳出来几十次。解法不是把提示词再写狠一点，是让模型把"它敢不敢确定"一起交出来。

有个开源项目叫 Recona，用 Qwen 对账，匹配上的发票自动关账。它的分工很朴素：模型只提建议，关不关账由确定性代码决定。精确金额、匹配货币、置信度阈值，全是代码拿数字比，不靠提示词让模型"自觉"。

关键在它给模型输出里塞了个字段：

type MatchResult = {
  invoice_id: string | null
  confidence: number
}

这种字段最容易放着吃灰——反正模型填个 0.9，你也懒得较真。但 Recona 真拿它当闸门。match_transaction_to_invoice 必须把这两样都交出来，然后护栏写成这样：

const result = await match_transaction_to_invoice(payment)
if (result.confidence < 0.8 || !result.invoice_id) {
  await send_to_telegram(`人工看一下: ${payment.reference}`)
  return
}
await close_invoice(result.invoice_id)

阈值你按自己的胆子设。⚡这一下，把"不确定"从模型的内心戏变成了正式输出，单独占一个字段！不是等它说错话再去补救。

头一回看到这种分工，我心想这不就是个 if 吗。直到看见那次真实测试：一笔付款，邮箱和发票对上了，金额不多不少正好是发票的一半，参考号也对不上。模型推理文本里其实已经写出了正确的发票，但交出来的结构化输出只有 30% 置信度，发票 ID 空着没敢填。要是当初图省事去解析它推理文本里"看起来对"的那句话，这笔账就关错了！

原作者本来想演示的是"模型识别对了、然后被确定性规则拦下"这个正面案例，结果被模型的实际表现逼着重写了演示。这反而说明问题：该拦的不是模型说错的那一次，是它不敢确定的那些次。

这套改动抄到自己 agent 上，就是那个类型定义加一段 if，十分钟的事。回本不用算——盯 agent 的活，出一次错就是整个下午翻账。

只适用于自动操作有后果的场景。要是让模型帮你起个标题，它不确定就不确定，随它去。