用历史决策约束智能体的审批信心

一张比采购订单贵了 4.52% 的发票，AI 为什么知道该拦下？Precedent 的依据是几周前同一供应商那笔被退回采购部门的 4.26% 差价记录。那条记忆一旦没被检索出来，它就把判断交给人。

作者用这个应付账款代理说明了一条原则：自动处理的权限，应当来自可追溯的历史证据。对正在做业务 Agent 的程序员，这篇最值得读的是置信度怎么计算，以及一次检索遗漏如何改变了系统的决定。

为什么给了订单和政策，模型还是不会处理

应付账款（AP）通常要做三方匹配：采购订单、收货记录、发票相互核对，匹配不上的项目再交给人工。

麻烦在于，异常经常重复，处理依据却散落在历史决定里。供应商附加柴油费，合同第 7.2 条允许的上限是 2.5%；粮商按公担开票，订单却用千克；物流商第一次部分发货就开全额发票；标签供应商给未付款发票加上 /R 再发一遍。还有要求更换收款账户的来信。

这些情况不能只靠字段相等来判断。系统还需要知道：这个供应商以前发生过什么，当时为什么批准或退回。

作者认为，无状态 LLM 缺少这些先例，容易生成一段解释后把问题上交。这个观察来自他们的业务设计，不能据此断言所有无状态方案都会失败；显式维护完整规则，同样可能覆盖其中一部分情况。

Precedent 的分工是：确定性的三方匹配先识别价格、数量、计量单位、GST 类型、额外费用、重复发票和银行信息变更；Hindsight 检索先例；通过 Groq 使用的 gpt-oss-120b 推理并提交函数调用；可审计的推理器再核验证据。

原文将超过 75% 置信度作为自动放行条件，低于它则由人工一键确认，恰好等于 75% 的处理没有说明。银行账户变更始终交给资金部门，不受置信度影响。

记忆既要能读懂，也要能精确查到

Hindsight 是开源 Agent 记忆系统，提供 retain、recall、reflect 操作。作者花心思最多的地方，是决定一条记忆应该长什么样。

每次异常处理完成，都写入自然语言 content，包含供应商、异常、最终动作、处理人和理由；同时附上 vendor:、exception:、action:、mag:、outcome: 和 kind:case 标签。

自然语言供系统提取事实、归纳经验，标签负责限定检索范围。只存一段描述，容易找到语义相近但条件不符的案例；只有结构化字段，又会丢掉当时的解释。

另一个关键字段是 document_id，格式为 case-{invoice_id}。Hindsight 会从一份文档抽出多个事实，如果不按文档去重，同一张发票就可能被当成多条独立证据，虚增支持度。

人工推翻代理的决定也必须回写，并保留审核人的理由。否则系统积累的只是自己的输出，纠错经验进不了下一轮判断。

reflect 还会根据已有记忆生成供应商操作手册，通过 JSON response schema 约束输出，让 UI 渲染成表格。历史案例因此既服务自动决策，也能帮助新人理解供应商的处理惯例。

置信度怎么约束，检索就得怎么设计

没有记忆时，系统的置信度就是 0%。

对于价格偏差和额外费用，作者没有简单地让历史案例多数表决，而是从批准案例里找已接受的上界，从拦截案例里找已拒绝的下界，两者之间的灰区交给人。支持度还受到案例数量影响，计算中使用 min(1.0, len(ok) / 3)，避免少量案例直接给满信心。

模型可以解释邮件等上下文，但置信度受证据约束。下面这段代码负责限制模型建议的确定程度：

if out["action"] == proposal.action and not no_backing:
    d.confidence = round(min(llm_conf, proposal.confidence), 2)
elif no_backing:
    # 记忆中没有覆盖此情况的先例：LLM 可以建议，但不能独自行动。
    d.confidence = round(min(llm_conf, 0.4), 2)

关键是第一处 min()：模型与记忆推导出的动作一致时，仍不能超过证据给出的置信度。没有支持先例时，上限是 40%；模型与记忆结论冲突时，原文另设 50% 上限，交给人工判断。

但证据约束也有软肋：关键证据没查到，推理器就无法使用它。

开头那张 4.52% 的发票，在本地测试中被拦截，到了 Hindsight Cloud 却转成了人工审核。原因是该供应商有 11 条批准记录，只有 1 条拦截记录。检索按相关性排序，又受 token 预算限制，大量相似的批准记录挤掉了那条少见的拦截。

推理器于是只看见 2.43% 的已批准上界，看不见 4.26% 曾被拒绝，只能认定新情况超出了已知范围。

作者补了一组专门查询拒绝边界的请求：

if exc.type in MAGNITUDE_TYPES:
    for action in BOUNDARY_ACTIONS:   # hold_for_procurement, return_to_vendor
        batches.append(self.memory.recall(
            f"{inv['vendor_name']} {exc.label} {ACTIONS[action]}: amount above the accepted limit",
            tags=[v, t, f"action:{action}"], tags_match="all_strict", limit=10))

要看的是 action 标签与 tags_match="all_strict"：查询明确要求返回对应供应商、异常类型和处理动作的案例。这里的 limit=10 配合额外查询使用，重点是主动找边界，而非单纯扩大一次检索的数量。

我的判断

我赞同把自动处理权限交给证据约束。模型擅长解释，权限边界却需要可检查的依据。按文档去重、保留人工纠正、单独检索少见的拒绝记录，这些做法比笼统要求模型「谨慎一点」更具体。

不过，实验结果需要连同条件一起看。作者回放了 11 周历史，共 12 家供应商、96 张发票，场景按 Hyderabad 一家中型食品企业建模。第 1 周建议与人工决定一致率为 0%；最后 4 周达到 100%，88% 的异常自动放行，全程错误自动放行为零。关闭记忆后，先例数和置信度都为零，全部转人工。

这些是作者报告的回放结果。原文没有交代真实生产数据的占比、独立测试集，也没有说明首周的 0% 如何统计弃权行为，不能把它直接当成上线后的准确率承诺。

关闭记忆就全部转人工，首先证明了权限限制按设计生效。它还不足以证明 Hindsight 比规则表、数据库案例库或其他检索方案更好，因为作者没有给这些方案的对照数据。

合同上限若是明确的 2.5%，直接维护为显式规则更容易审计。历史先例适合补足上下文，但一次批准也可能是特批，不能自然升级成长期政策。原文没有充分说明规则变更、案例失效和过期记忆如何处理。

此外还有工程成本：Groq 的函数调用可能出现 tool_use_failed 或畸形 JSON。作者依次重新提示、修复参数、切换备用模型，最终仍失败时，根据记忆证据决策并显示警告。Hindsight Python SDK 使用 aiohttp，同步包装器又会把 HTTP session 绑定到首次使用的事件循环；面对 Flask 每次请求使用不同线程的问题，作者把所有 SDK 调用集中到一个专用事件循环。这些都是实现经验，仍需在自己的运行环境中验证。

能拿来做什么

• 做重复业务审核时，先把明确政策写成可执行规则，再为规则之外的情况保存案例、处理动作和人工理由，让记忆补足判断依据。
• 在前端审核界面同时展示建议、支持案例和转人工原因，并提供纠正入口，把审核人的说明回写到下一轮可检索的数据里。
• 编写检索逻辑时，除了查询相似案例，还要主动查询拒绝、退回和人工推翻记录，并按原始业务单据去重。
• 为日常 Agent 回放加入空记忆、边界案例缺失、模型与证据冲突、函数调用失败等情况，验证证据不足时能否稳定转人工。