澄清预算：你的智能体何时应该询问而非猜测

智能体最糟糕的两种失败模式看起来截然相反，但它们其实源于同一种失效的策略（Policy）。第一种智能体在执行任何操作前都会先问四个后续问题，这让它的用户因为繁琐而最终放弃使用。第二种智能体从不提问，它自信地生成用户不得不推倒重做的输出，这让它的用户对其产生不信任感。同样的策略，只是一个缺失参数的不同设置：即提问的成本相对于错误答案成本的比例。

大多数智能体根本没有任何策略。模型只是被要求“提供帮助”，然后被留下来独自应对模糊性。因为下一个 Token 预测（next-token prediction）机制奖励对答案的确定性，所以智能体倾向于猜测。又因为 RLHF 奖励礼貌，智能体偶尔会为了安全而过度纠偏并提出问题。其结果就是一种毫无原则的行为，这种行为在不同会话之间波动不定，团队层面也无法直观地判断智能体何时会暂停、何时会盲目推进。

澄清预算（Clarification budget）正是那个缺失的参数。它是针对每个任务制定的、允许智能体施加摩擦力的配额，并配有一套判断何时值得花费预算去提问的决策规则。你可以把它看作是对话领域的“延迟预算（latency budget）”——每个产品都有一个，即使没人把它写下来；而那些把它写下来的团队，就能停止交付那种让人困惑的智能体。

为什么不能把“提问还是猜测”留给模型决定

模型对你的产品经济学一无所知。它不知道你的用户是正在下单管制药品的医生，还是正在挑选电影的青少年。它不知道你的支持智能体给出的错误答案会触发 40 美元的人工介入成本，也不知道一个充满摩擦力的入职引导智能体会因为每一个额外的问题而流失 12% 的注册用户。这些都是关于你产品的事实，它们属于包裹在模型之外的策略层。

这就是为什么“只需让模型在不确定时提问”在生产环境中会产生如此不一致的行为。模型被要求决定一个路由问题——是现在回答，还是暂停等待输入——但它却没有任何应该主导该决策的输入信息。研究编程智能体澄清问题的研究人员将此视为一个根本性的鸿沟：如果不显式地建模哪些问题重要、模型需要达到多高的置信度才能提交、以及提问的成本是多少，智能体就没有原则性的标准来判断何时停止提问以及何时开始行动。关于 LLM 智能体结构化不确定性的研究将此形式化为一个具有贝叶斯信息价值（Value of Information）目标的偏观测决策问题——这是学术界对产品团队直觉认知的一种术语化表达。提问是有成本的动作，回答是具有不同成本的动作，而正确的权衡取决于具体情况。

结论并不是说每个团队都需要实现一个 POMDP（部分可观测马尔可夫决策过程），而是说这种决策是结构性的，而结构化胜过凭感觉。

澄清预算的四个要素

一个切实可行的澄清预算由四部分组成。它们都不神秘，但为了使系统行为保持一致，这四个部分都必须是显式的。

每项任务的预算。 每种任务类型开始时都有一个有限的配额——例如，支持流程允许提问两次，快速查询允许提问零次，复杂的入职配置允许提问四次。预算随着问题的提出而减少。一旦预算耗尽，智能体必须提交结果，即使它仍不确定。这迫使智能体将提问机会用在最有价值的歧义消除上，而不是分散在每一个微小的不确定点上。

信息增益启发式（Information-gain heuristic）。 在提问之前，智能体应该预估如果用户回答了，其预期误差会降低多少。如果一个问题能区分一个请求中两种可能性相等的解释，那么它就是高价值的。如果一个问题是在两种解释中做选择，而其中一种的可能性已经高达 95%，那么这个问题的价值就很低——直接按照可能性高的那个去执行，并提供一个优雅的撤销选项即可。在这里，学术上的“信息价值”框架真正发挥了作用，即使具体的实现只是粗略的启发式算法而非真正的贝叶斯计算。

提交任务的置信度阈值。 低于阈值时，智能体提问；高于阈值时，智能体直接执行并提供“如果我弄错了请告诉我就好”的辅助机制。这个阈值是一个产品层面的决策，而不是模型属性——它应该根据错误答案的成本在不同场景下进行调整。查询手术记录需要高阈值；而“推荐一首歌”的功能阈值则较低。

优雅的纠错机制（Graceful-correction affordance）。 当智能体在不提问的情况下直接执行时，用户必须有一条无障碍的路径来重新引导。“我假设你的意思是 X——如果不对，请说‘不，我的意思是 Y’”比直接提问要少得多地引起反感，因为它让“首答即中”的路径保持了高效。用户容忍偶尔错误猜测的意愿，几乎完全取决于纠正这些错误的成本有多低。

极端情况下的两种失败模式

如果将这四个杠杆中的任何一个拨得太远，智能体就会以一种显而易见的方式失败。

过度提问者（The over-asker） 是指那些将置信度阈值设得太高或信息增益门槛设得太低的智能体。当 99% 的用户只安装了 Web 应用时，它还会问“你是说 iOS 应用还是 Web 应用？”当用户已经说过“明天”时，它还会问“你想安排在本周还是下周？”孤立地看，每一个问题似乎都是合理的，这也是为什么过度提问很难调试——每一个审查单个日志的 PM 都会说“嗯，在那里问一下是有道理的”。这种病态只会在会话层面显现出来，表现为用户在三轮对话后放弃交谈或要求人工介入。

过度猜测者（The over-guesser） 则恰恰相反。它的置信度阈值太低，预算太慷慨，而纠错机制薄弱或隐藏太深。智能体会自信地处理错误订单的退货请求、预订错误的会议室、或者用猜错的产品名称草拟客户邮件。同样，孤立地看，每一个猜测似乎也是合理的——模型选择了最可能的解释。但用户的体验却是一个不听指挥的智能体，因为每一次错误的猜测感觉都像是系统忽略了用户认为自己已经提供的信息。

区分这两者的诊断性问题是：用户是否知道智能体已经承诺执行了什么？一个会提示“我假设是 X——需要更改吗？”的过度猜测者，比一个悄悄执行并在之后给用户带来“惊喜”的智能体，更接近一个调校良好的智能体。执行行为的可修正性与准确性同样重要。

为什么评估规范必须追踪两个维度

最常见的评估错误是只追踪准确率就认为大功告成了。仅仅追求准确率，会导致产生“过度提问者”，这种 Agent 在通过审问逼迫用户就范之前，永远不会执行任何操作。奇怪的是，追求准确率也会催生“过度猜测者”，因为用户已经学会了手动修正每一个输出——由于修正后的输出是正确的，评估得分看起来依然很好。

一个真正的澄清评估体系必须同时追踪至少四个指标：按任务类型细分的澄清率，这样过度提问者就会在特定流程中表现为异常值；澄清后准确率，这样提问更多的团队可以证明提问是有价值的；猜测后准确率，这样提问较少的团队可以证明他们并不仅仅是在交付更多错误的答案；以及用户反馈修正率，这是一个综合信号，表明无论你在做什么，在会话级别都在让用户感到厌烦，即使单次对话看起来没问题。

如果没有这四个指标，团队在优化一个数字时，另一个数字会悄无声息地下降。最痛苦的情况是，一个团队通过提高澄清率来提升准确率，发布变更后却眼睁睁看着用户留存率下降，因为 Agent 变得让人沟通起来精疲力竭。准确率仪表盘显示为绿色，但产品正在走向消亡。这正是 Nielsen Norman 在其关于 AI 聊天 UX 的广泛研究中所指出的动态——在那些看起来最具权威性的指标面前，这种摩擦是不可见的。

策略层是架构上的解决方案

团队犯的最大错误是将“我该不该问？”视为一个提示词工程问题。它不是。这是一个模型在结构上没资格单独做出的路由决策，因为模型无法接触到应该主导该决策的产品经济学因素。

架构上的修复是在模型和用户之间建立一个策略层，由其负责询问与猜测的决策。模型仍然负责提议——它生成候选动作、自报置信度，以及在预算无限的情况下会提出的消除歧义的问题列表。策略层负责处置——它参考每个界面的预算、错误答案的成本参数、用户的会话历史（他们是否已经被问过两次了？），并决定是转发问题、带修正机制地提交，还是静默提交。

这种分离使得系统变得可调优。当支持团队发现 Agent 在退货流程中过度提问时，他们可以专门针对退货调整阈值。当法律团队要求对任何数据删除进行确认时，他们可以将删除的阈值设为“总是询问”。当一个新的高价值企业客户要求更快、更少干扰的体验时，可以提高该账户的预算，而无需重新训练任何模型。如果询问与猜测的决策被埋藏在一个无差别的模型系统提示词中，这一切都不可能实现。

策略层也是评估信号闭环的地方。上述四个指标会反馈到每个界面的阈值调整中，理想情况下是自动完成的。大多数团队会从手动调优和季度审查开始。成熟的终点是一个闭环系统，其中用户修正率上升的界面会收紧阈值，而相对于信息增益而言澄清率上升的界面会放宽阈值。

优先构建什么

阅读本文的大多数团队都没有澄清预算。他们只有一个系统提示词，写着类似“在需要时提出澄清问题”之类的话，并且在两个方向上都收到用户投诉——既太啰唆又太唐突，有时甚至来自同一周内的同一个用户。

最小且有效的起步点是为每种主要任务类型写下两个数字：Agent 允许提问的最大次数，以及该流程中错误答案的成本，并用具体的事物（美元、人工审核时间、流失风险）来衡量。然后挑选一个产品经理、工程师和支持团队之间分歧最大的界面，在该界面上对四个评估信号进行为期两周的监测。

你会发现两件事。首先，团队在正确行为上的共识比讨论中表现出来的要多——一旦预算和错误成本被明确记录下来，“我们在这里该问吗？”就变成了可以回答的问题，而不再是审美偏好。其次，模型的现有行为实际上与你写下的预算相去甚远，这为你提供了一个具体的调优目标。

随着模型变得更聪明，询问与猜测的问题并不会消失。更聪明的模型会更自信地猜测，这使得未经检查的错误猜测成本变得更高，而非更低。现在就开始构建策略层的团队，在未来十年里只需为每个界面调整两个数字。而那些不这样做的团队，在未来十年里将不得不向用户解释，为什么 Agent 不听话——或者为什么它问得太多。