可靠 Agent 如何处理未知信息

Agent 遇到指令含糊、资料缺失时，应该继续做、自己查，还是停下来问用户？作者的结论是：处理不确定性就是 Agent 的核心工作。可靠性取决于它能否发现缺口，并根据出错的代价选择下一步。

这篇短文没有给出模型评测或实现代码，但提出了一组有用的判断标准：别把自信当证据，别把追问当谨慎，也别把「不知道」当失败。对做 AI 编程助手或业务 Agent 的团队，值得借来检查交互与执行流程。

模型说得笃定，为什么仍然不能信

真实任务很少像演示那样顺畅。用户没有交代清楚需求，数据已经过期，某个字段查不到，都可能成为后续错误的起点。执行链越长，早期误判越容易被后面的步骤继续放大。

作者首先质疑的是「置信度」。模型复述事实和编造内容时，可能表现得同样肯定。Token 概率描述的是下一个词出现得是否合理，不能直接证明整句话符合事实。

这里需要区分两个问题：模型觉得自己有多确定，以及它过去在这种确定程度下究竟答对了多少。

后一个问题涉及校准（calibration）：系统声称的可靠程度，要与实际正确率相匹配。没有这层验证，展示一个置信度分数，只是给流畅的表达加了一个看似精确的数字。

判断可靠性，要看分数对应的历史表现。

什么时候自己查，什么时候必须问

作者给出的边界很实用：缺失的信息会不会改变接下来的动作？

「能再多说一点吗」没有说明缺什么，也没解释为什么需要。相比之下，「报告覆盖本月，还是最近 30 天」直接指出了会影响统计结果的选择，用户也容易回答。

但不能把所有信息缺口都交还给用户。Agent 自己能查到的事实，应当先查；选择影响很小、操作又容易撤销时，可以先推进，同时公开采用的假设，让用户有机会纠正。

原文用退款说明这条边界：客户没有提供订单号，却提到了两种产品。差的 Agent 猜一个更可能的产品，直接退款；好的 Agent 先检查近期订单，如果两个订单仍然都符合描述，再提出一个有针对性的问题。

这里重要的是动作顺序：先收集可获得的证据，再确认剩余歧义，最后执行退款。查订单可以帮助缩小范围，转钱则不能靠猜。

「不知道」怎样成为可用的结果

作者把拒绝作答或升级处理，与选择性预测（selective prediction）联系起来：系统在确定程度低于阈值时，可以不回答，或者交给其他流程处理。

大白话讲，就是允许系统只回答自己有把握的部分。

但作者也加了两个条件。首先，不确定性信号必须经过校准，否则系统可能恰好对错误答案最有把握。其次，阈值应当反映答错的代价。医疗、法律、金融中的错误，与一个容易撤销的普通选择，不能只用同一套直觉处理。

拒答也需要成为产品里清晰可见的结果。如果界面和流程只接受「成功输出」，系统就缺少诚实表达疑问的空间。

我的判断

我认同作者把重点放在证据和动作边界上。相比要求 Agent「永远先问清楚」，这种做法能减少无效追问；相比要求它「尽量自主完成」，又为退款这样的操作保留了必要确认。

但这仍是一套设计原则，不能当作经过验证的效果报告。原文没有给出校准方法、测试集、阈值设置，也没有提供退款成功率或用户打断次数的对照数据。

尤其要警惕把「低置信度就拒答」直接写进流程。如果置信度来自模型自报，而没有历史表现支撑，这条规则的基础仍然不稳。一般团队更容易先落地的，是把可查询事实、待确认歧义和执行条件明确写出来，再逐步验证不确定性信号是否有用。

能拿来做什么

• 给 AI 编程助手设置追问标准：先检查仓库里已有的配置和说明；确实存在会改变实现方向的歧义时，再提出具体问题，并解释不同答案会影响什么。
• 在报表类任务中明确时间口径。遇到「本月」和「最近 30 天」这类差异，应确认或公开假设，避免生成了一份格式正确、统计范围却不符合需求的报告。
• 给退款等业务 Agent 拆开查询与执行步骤。先查近期订单，仍有多个候选时要求确认，不能把「最可能」直接作为付款依据。
• 如果产品展示置信度，就记录它与实际结果的对应关系；同时允许「信息不足」和升级处理作为正式结果，避免界面逼着 Agent 给出答案。