大多数智能体的配置里，都有一行类似 ESCALATION_THRESHOLD = 0.90 的代码。高于这个值，智能体自主行动；低于它，人类被拉进来处理。

这个设定简单、可调，让人感觉自主权尽在掌控——但这种掌控感，其实是一种错觉。

问题的关键不在于调出一个更精准的数字。关键在于，你从一开始就没意识到，这个“升级阈值”本质上从来不是一个百分比，而是一个价格。

从错误的问题开始

大多数团队问的问题都是关于能力的：智能体能写SQL吗？能处理退款吗？如果能，就让它放手去做。

但“能做”和“独自决定去做”是两回事。后者真正关乎的是决策本身：犯错的代价是什么？把人类拉进来又要付出什么成本？

这才是真正的选择所在。如果智能体行动，你要承担错误的风险；如果升级，你就要为人类的时间买单——无论智能体当时是对是错。

把数字摆上来，对比就显得简单到让人有些不好意思。先假设一个前提：人类处理升级工单时总是正确的。我们稍后再放宽这个假设。现在，当满足以下条件时，让智能体独自行动：

(1 - p) * 错误成本 < 升级成本

其中 p 是智能体正确的概率。重新排列一下，需要升级的条件就是：

p < 1 - (升级成本 / 错误成本)

右侧的那个值，才是真正的阈值。注意它取决于什么——不是模型，不是开会的讨论结果，仅仅是两个成本之间的比值。如果错误成本低，阈值就低，智能体可以行动得更频繁；如果错误成本高，阈值就高，那么即使一个自信满满的智能体，也应该寻求帮助。

一个固定的阈值，隐含地假设了智能体将面对的所有决策，其成本比值都是相同的。但这种情况极为罕见。

这个思路源自1970年的Chow拒绝规则，它也是今天“学习延迟决策”研究的基础。有些老想法，只要是对的，就能经得起时间考验。

两个工单

展示这个逻辑最直观的方式，是用工单分类的例子。智能体读取新工单，要么直接解决，要么转给人工处理。这里的数字是假设的，但逻辑是自洽的。

一个常规的退款请求，金额小，政策清晰。如果智能体搞砸了，善后工作就是发个后续工单和一笔补偿金，算15英镑。而升级一下，大概消耗一个专家三分钟，算4英镑。

算出来的阈值是 1 减去 4/15，大约是0.73。

所以，如果智能体有90%的把握，它显然应该自己行动。升级要花4英镑，却只为了避免1.5英镑的预期错误成本。说出来没人会做这种交易，但一个固定的阈值却会一整天都在自动地做着同样的事。

现在，再来一个潜在的账户盗用事件。客户报告说密码被改了，但不是他本人操作的。如果智能体按常规处理，后果就不是补偿金那么简单了，而是欺诈损失、修复成本、监管风险，甚至可能永远失去这个客户。保守估计，成本是2000英镑。升级成本仍然是4英镑。

新的阈值是 1 减去 4/2000，也就是0.998。在实践中，这意味着你应该永远选择升级。在90%的置信度下，让智能体单独行动，预期成本是200英镑，而升级只需4英镑。升级比让其自主操作便宜了50倍。

同一个智能体，同样的90%置信度，得出的结论却截然相反。90%的规则会让你在两个案例中都选择“自主行动”，但在第二个案例中，它正悄悄地为了节省人类三分钟时间，而烧掉每张工单196英镑。

这个观察通常在交流中能引人深思。

有一个诚实的难点。这个例子假设智能体知道自己手里拿的是什么类型的工单。但在实际分类中，这正是不确定性所在。如果智能体有90%的把握认为某个工单是常规退款，那么剩下的10%中，可能就隐藏着一个盗用事件。所以，错误成本应该根据工单可能的所有类型来加权，而不是只考虑它最可能的那一种。当不确定时，就按最坏情况定价。那些看起来便宜的工单，恰恰是昂贵错误最常潜伏的地方。

陷阱

上面所有的算术都建立在一个假设之上：当智能体说它90%有把握时，它真的有90%的时候是对的。

这就是“校准”，它和“置信度”不是一回事。置信度只是模型输出的一个数字，而校准是指这个数字是否真的有意义。

把这个输入到规则里，你就会看到它崩溃。如果模型声称的0.95置信度，实际上只对应0.70的准确率，那么你的预期错误成本就是算术结果的六倍。你精心计算的阈值就成了一个虚构的数字。你不再是在管理风险，而是在用一个看起来像概率但实际并非如此的数字，给自己一种虚假的安全感。

所以，在做任何事之前，先检查一下这个数字。记录每一次决策及其声称的置信度。按置信度区间和决策类别进行分组。比较每个区间内声称的置信度与实际的准确率。如果智能体说90%但实际只达到78%，那你就找到了修正方向：在达到阈值之前，先做一个映射转换。等渗回归或Platt缩放都能完成这个拟合工作。

有两个细节需要留意。智能体在校准上表现最差的，往往正是那些稀有但风险极高的类别，恰恰因为它们很稀有。而这类别正是承载着你极端阈值的地方，所以一个全局平均值会掩盖掉那个真正重要的失败点。另外，随着工单组合的变化，这个映射关系也会发生漂移，所以需要定期重新测量。技术本身没那么重要，养成习惯才是关键。在你真正测量出这个差距之前，任何阈值都不值得信任。

代码中的规则

下面是一个教学玩具式的实现。短短几行代码，让结构变得清晰可见，并非我实际构建或部署过的方案。

def should_act_autonomously(
stated_confidence: float,
cost_of_error: float,
cost_of_escalation: float,
calibrate
) -> bool:
"""教学玩具：根据预期成本，决定是独自行动还是升级策略。
`calibrate` 将声称的置信度映射为
基于已记录决策和实际结果的
正确概率。
"""
p_correct = calibrate(stated_confidence)
expected_cost_of_acting = (1 - p_correct) * cost_of_error
expected_cost_of_asking = cost_of_escalation
return expected_cost_of_acting < expected_cost_of_asking

函数内部没什么花哨的东西。真正重要的是你如何选择那三个输入参数。这才是你该投入精力的地方，而不是去争论那个神奇数字应该是0.85还是0.92。

数字变得棘手的地方

有两个因素让输入参数变得复杂。

升级成本不仅仅是分钟数乘以工资。升级的工单会堆积成队列，而队列会拥堵。更糟糕的是，过度升级会训练审核者变得“盖章式”处理。如果一小时内给他们塞四十个常规退款，一周之内，他们就不再仔细阅读了。一个只会批准一切的人类，并不是一个控制机制，而是一种仪式。所以，边际升级成本比表面看起来要高得多，而且这个差距会随着数量增加而扩大。

另外，还记得我们之前搁置的假设吗？人类总是能正确处理。但现实是，他们往往不能。假设专家一个错误率 h，那么规则就变成了：当 (1 - p) × 错误成本 小于 (升级成本 + h × 错误成本) 时才行动。通常 h 小到可以忽略不计。但在那些真正模糊的工单上，它就不容小觑了，并且它会将阈值向智能体一侧倾斜。这常常让很多人感到意外。

这两个问题都不会改变整体方法，它们只是影响了数字本身。而这，正是使用数值方法的好处所在。

为你的智能体实现这个规则

操作步骤非常简短。

首先，将智能体的决策按错误成本大致相同的类别进行分组。例如，把退款归为一类，安全事件归为另一类。如果你无法估算某个类别的错误成本，那它还没准备好实现自主决策。实际上，理清这一点本身就是这个过程中很有价值的一部分。

然后，为每个类别定价。去和那些负责收拾残局的人聊聊，而不是只和构建智能体的人聊。财务和运营支持部门的人比工程师更清楚这些数字，而且他们通常很高兴终于有人来问他们了。

同时，估算升级成本，包括拥堵和“盖章式”处理的影响。

在你的规则中使用校正后的概率，而不是原始得分。

最后一步：根据成本比值，推导出每个类别的阈值，并让它在成本变动时随之变动。一个新型欺诈模式的出现，会提高安全类错误的成本，那么该阈值也随之提高。不需要开会讨论，因为它是推导出来的，而不是人为规定的。

最终，你的智能体将拥有多个阈值，而不是一个。它会在错误成本低的地方拥有更多自主权，在错误成本高的地方则少得多。模型和比较方法保持不变。

这就是对每个人一开始都会问的那个问题的诚实回答。“我的智能体在独自行动前，应该有多大的把握？”这个问题无法回答，因为它本身就被定义得不够具体。“一个错误的决策在这里的代价是什么？而寻求帮助的成本又是什么？”这个问题才能回答。把阈值设定为一个价格，百分比自然会各就各位。