置信度门控的自动化——既高度自动，又不犯昂贵的错

一句话先说结论

要让一条 LLM 流水线安全地自动跑：每个动作都按一个可量的置信度信号门控，过阈值才执行；用一份带标注、接进 CI 的评测集兜住这个阈值，让模型、prompt、检索层的任何改动都触发回归检查；高风险的值，至少两个独立来源一致才自动填；系统不确定、或来源缺失时，自动把缺口补上——回数据源重查、或联系相关方确认——而不是放它过去、也不是一律塞给人工；每个值都留出处；所有自动写入都走和普通用户一样的服务端授权。真正要命的失败模式不是模型错了，是模型又错又自信——因为那一种没人会去抓。

真正要命的不是出错，是”自信地出错”

会出错、但把错标记出来的流水线，没问题。会出错、却把错当成成品交出去的流水线，很危险——因为这时已经没人盯着输出了，毕竟自动化的目的就是不用人盯。一个发票字段填错、一笔退款发错对象、一条合同条款被凭空编出来，代价从来不是模型错了这一次，而是这个错值在有人发现之前，已经流进了下游十个系统。

随着越来越多的采购和交易迁到 agent 上，这件事不再是某个小众的工程顾虑。Gartner 预测，到 2028 年，90% 的 B2B 采购旅程将受到 AI agent 的影响，涉及超过 15 万亿美元的采购。当 agent 在读你的数据、报你的价、发起交易时，一个自信的错误自动决策就不再是内部的小麻烦——它会传进别人的自动决策里。连接越密，爆炸半径越大。

所以目标不是”高准确率”。一个准确率 95%、却对全部 100% 的样本都动手的模型，每一百条就往生产环境里塞五条坏数据。真正要做到的，是知道哪 5% 它本不该碰，并且确实没去碰。下面讲的，都是怎么把这种”知道”做进系统里，而不是寄希望于它。

置信度门控——过阈值才动手

第一条规则：允许系统弃权。每个自动决策都带一个置信度信号，只有高于设定阈值的决策才会被自动执行；低于阈值的，挂起。

难点在于拿到一个诚实的置信度数字。LLM 原始的 softmax 概率没有经过校准，它会对一个错答案心安理得地报 0.98。更可靠的信号来自多次独立尝试之间的一致性、一个独立的校验模型对照原文给输出打分、或者结构化校验（抽出来的合计是不是真的等于各行金额之和）。挑一个你能拿真值去量的信号，再把阈值定在”误动作的代价超过挂起代价”的那个点上。

这个阈值是业务决策，不是默认值。一条退款流水线和一条打标签流水线，误动作的代价天差地别，所以它们用不同的线。把阈值当成一个带理由的数字写下来——“低于 0.9 一致度就挂起，因为退错款比挂起一单贵”——这样以后有人想为了清积压把它放松时，权衡是摆在台面上的，而不是埋在某个配置文件里。

用评测兜底，否则你只是在猜

阈值有意义的前提，是你能量出”在这个阈值下的精确率”。这就需要一份带标注的评测集——真实输入配上已知正确的输出——以及一个能量到你真正在乎的东西的指标：对自动化来说，几乎永远是”被自动处理那一片样本上的精确率”，而不是整体准确率。整体准确率把你弃权的那些样本也平均了进去，反而盖住了唯一重要的那个数：系统自己动手处理的那些里，对了多少。

把评测当成回归门。接进 CI，让模型、prompt、检索层、解析逻辑的任何改动都触发整轮跑一遍，一旦门控切片上的精确率掉到线下，构建就失败。改 prompt 就是改代码，它出问题的方式和改代码一样；团队之所以没察觉，只是因为没在量。系统 prompt 里改一个词，就能让某个你没在看的切片上精确率掉好几个点，没有门，这种回归会悄无声息地上线。

对于驱动真实浏览器或真实 UI 的流水线，可以用 Playwright 把同一套评测纪律端到端跑通——走真实流程、对真实结果下断言——在它上线的地方抓回归，而不是只孤立地测模型。大多数自动化是在接缝处坏掉的：模型没问题，但值落进了错的字段、重试逻辑重复提交了、选择器挪了位置。在真实流程里下的端到端断言，能抓住那一类只测模型永远看不见的失败。

高风险字段，要求至少两个独立来源一致

赌注高的时候，单一来源不够。只有当至少两个独立来源对同一个值达成一致时，才自动填——一个 OCR 读数配一个结构化字段、一个抓取来的数字配一个 API 返回、两个不共享失败模式的抽取器。一致，这个值大概率是对的，系统就填；不一致，这个分歧本身就是你能拿到的最有用的信号：它精确地标出了需要人工或第二轮复核去看的那些样本。

这里起作用的词是”独立”。对同一个模型、同一份输入问两次 prompt，不是两个来源——它们会一起错。真正的交叉验证，来自通往同一个事实的、确实不同的路径。“独立”也是为什么这一招能和置信度门控很好地叠加、而不是重复它——独立路径之间的一致性，本身就是你能构造出来的比较诚实的置信度信号之一，远胜过让模型给自己的答案打分。

留出处、留审计痕迹

每个自动填上的值，都该带上它的来历——哪个来源、哪个模型版本、哪个置信度、哪个时间戳。这不是文书工作。真出了问题，出处是你在几分钟内（而不是几天内）定位爆炸半径的依据，也是你判断”这是一次孤立的坏抽取，还是一类需要回滚的失败”的依据。它还让你能在模型改动之后，拿历史数据重跑一遍门控，看看哪些结果会变。

出处正是让上面那道评测门能够回溯的东西。带标注的评测集告诉你”在基准上会发生什么”；出处告诉你”在生产里实际发生了什么”，于是你能拿上个季度的真实流量去重放一次模型升级，在真正信任它之前先量出实际的差值。没有这条痕迹，每一次模型改动都是一次新的下注，而你没法核对赔率。

系统不确定时，自动把缺口闭环补上

这一招大多数团队会漏掉。置信度低、或来源缺失时，本能反应是二选一：要么放它过去（那自动化就白做了），要么扔给人工（那自动也白自动了）。其实还有第三条路，而且通常是对的——自动把缺口补上。

某个值缺失或有争议，系统可以自己回到源头：重新查库、重新抓页面、换一个抽取器跑，或者主动联系相关方去确认、补全那条缺的信息。一个挂起的样本，于是变成流水线自己去做的一个任务，而不是一张干等着的工单。人工复核仍然留在设计里作最后兜底，但它不再是每一个不确定的默认归宿。大多数缺口不用人就能补上；把人留给那些真正需要判断的。

这正是”能扩起来的自动化”和”只是把瓶颈挪了个位置的自动化”之间的差别。把每一个不确定都升级进队列的流水线，吞吐被那个队列的大小卡死。一条自己解掉大部分不确定、只把残渣升级上去的流水线，吞吐能随着量增长继续撑住——因为人力成本是随着真正的难案上升，而不是随着总量上升。

自动执行者，照样要走服务端授权

有一条警告，在流水线开始自主动手时最容易被丢掉。一个会执行写入、退款、改账户的自动 agent，是一个有权限的客户端，它必须和任何用户一样，走同一套服务端授权校验。置信度门控决定系统”该不该”动手；它不决定系统”被不被允许”动手。失效的访问控制是 OWASP Top 10 的头号条目，而一个相信自己置信度、就跳过授权的自主循环，正是一个低危 bug 变成一次入侵的典型路径。

陷阱在于”因为这流水线是你写的就把它当成可信的”。活在客户端里的授权——“这个 agent 只会对自己拥有的账户调这个接口”——不是强制，而是一条约定，离一次 prompt 注入、一个逻辑 bug 去对它不拥有的账户动手只有一步之遥。在服务端强制权限，每一个动作都查，哪怕调用方是你自己的流水线。置信度门和授权检查回答的是两个不同的问题，两个你都需要：一个让系统在不该动手时不动手，另一个让它在不被允许的地方动不了手。

整体长这样

拼起来看，这些都不玄。一个让系统能弃权的阈值，一份证明这个阈值买到多少精确率的评测集，高风险自动填之前的两个独立来源，样样都留出处，一个先自己补缺口再升级的闭环，以及一套不管置信度多高都成立的授权。它们彼此加强——一致性喂给置信度信号，出处让评测门能回溯，自动补缺把人工队列压得够小、整条流水线才一直是自动的。那个会大声报错、把不确定样本挂起来的版本，远比那个自信地犯错、一周后才被发现的版本值钱。