Agent需要学会说「不知道」
你问一个资深会计：「我们公司上个月的净利润是多少？」她会说：「让我查一下账本。」你问一个老中医：「这个症状是风寒还是风热？」她会说：「我得再看看舌苔。」你问一个建筑结构工程师：「这面墙能不能拆？」他说：「得看原始图纸，我现在没有依据。」
人类的专家在面对不确定的问题时，有一套天然的处理机制：承认边界，诚实告知，然后转向可以做的事。这个机制在心理学上叫「元认知监控」——我知道我知道什么，我也知道我不知道什么。
但现在的 AI agent 系统，大多数没有这个机制。
强迫 agent 说谎的设计
当一个用户问 agent：「帮我分析一下竞品 X 的上季度毛利率」，一个诚实的设计应该让 agent 说：「我没有 X 的内部数据，无法直接计算。」但实际情况是，大多数 agent 会编一个看起来合理的数字出来，附带一句「根据公开信息推测」之类的话——而「推测」的依据可能根本不存在。
这就是 hallucination 的本质：不是模型的 bug，而是系统设计层面的「强迫说谎」。
什么叫强迫说谎？模型在训练时被优化「让回答看起来合理」，加上系统 prompt 里往往隐含着「你必须回答」的指令，两股力量叠加在一起，模型在不确定时会本能地选择编造，而不是说「不知道」。这和人被逼到墙角时胡乱找借口，本质上是一样的行为模式。
为什么 agent 倾向于「瞎猜」
让我们拆解一下 agent 为什么总爱瞎猜，原因有三层。
第一层是训练目标。语言模型的训练目标是「最大化下一个 token 的似然」，换句话说，模型被训练成「在任何情况下都要输出一个看起来合理的序列」。这个目标没有区分「我知道这个答案」和「我不知道这个答案但我要装知道」——因为在 token 层面，两种输出的概率分布都可以被优化得看起来很流畅。模型从根上就没有被教育过「诚实放弃」的价值。
第二层是系统 prompt 里的隐性指令。很多 agent 的系统 prompt 里有「你是一个专业的助手，请尽力回答用户的问题」这样的话。这类指令在语义上等同于告诉 agent：「不能以『不知道』结尾。」用户和开发者的期望被编码成了一种压力——「没回答」等于「回答质量差」，这种压力传导到模型输出层面，就变成了硬撑着也要说点什么。
第三层是评价体系的缺失。开发者通常用回答的流畅度、相关性、有用性来评价 agent，但几乎没有人用「在不确定的情况下是否诚实承认」来评价 agent。评价指标不覆盖的行为，在系统演化过程中自然不会得到改进。
「说不知道」的三道门槛
既然模型本身具备感知不确定性的能力（这已经被大量校准研究证实），为什么在实际 agent 系统中「说不知道」仍然这么难？因为有三重门槛没有跨越。
第一道门槛在 prompt 层。很多 prompt 设计里根本没有给「说不知道」留梯子。什么叫留梯子？就是在 prompt 里明确告诉 agent：「在你确定答案之前，先评估一下自己的置信度。如果低于 70%，请转而执行以下替代方案，而不是输出猜测。」没有这个前置条件，agent 就会默认走「直接回答」这条路径，因为它没有收到任何关于何时应该放弃的指令。
第二道门槛在系统架构层。大多数 agent 系统的质量门（quality gate）只检查「回答是否包含内容」，不检查「回答是否值得被信任」。系统设计者假设只要模型输出了文本，就代表它有这个把握。但这个假设从一开始就错了。
第三道门槛在用户体验层。「这个问题我无法回答」这样的输出，在大多数产品的设计里会被标记为「失败」——要么是 agent 能力不足，要么是产品体验不好。用户的投诉通常是「你答非所问」，而不是「你居然在瞎编」。这种外部压力进一步强化了 agent 回避「说不知道」的倾向。
引入知道-不知道的判断机制
要在 agent 系统里实现「说不知道」，需要从两个方向同时用力：置信度自评和分支决策。
先说置信度自评。模型在生成答案之前，应该先完成一次内部检查：我对这个问题有几分把握？这个检查可以显式地做，比如在 prompt 里要求模型先输出一个置信度评分再输出正文；也可以隐式地做，比如设计一个专门的「判断环节」在主回答之前运行。无论哪种方式，核心是把「判断」从黑箱里拿出来，变成一个可以配置、可以审核的显式步骤。
然后是阈值触发。一旦置信度低于某个设定值——这个值取决于任务的风险等级，金融、医疗、法律相关的任务阈值应该设得更高——系统就应该走「不知道」分支，而不是继续生成主回答。这个阈值不是模型自己猜的，而是由开发者在系统设计阶段配置的，是产品决策而不是模型决策。
举一个具体的阈值配置场景。在一个客服 agent 里，用户问的是「你们的产品什么时候打折」，置信度阈值可以设为 60%——低于这个值就去查促销系统，或者告诉用户「我正在查询最新的优惠信息」。在一个投研 agent 里，用户问的是「竞品的毛利率」，置信度阈值应该设在 80%——低于这个值就直接说「没有内部数据」，而不是输出一个估算值然后假装很确定。
「不知道」是路径节点，不是死胡同
「说不知道」最大的误解是把它当成终点。实际上，触发「不知道」之后，才是 agent 真正开始工作的时刻。
一个设计良好的 agent 系统，在检测到置信度不足时，应该自动进入一个替代路径。这个路径可能包括：调用知识库检索相关文档，在全网搜索最新公开数据，调用内部 API 查询用户未明确授权但有权限访问的信息，或者向用户请求补充信息。每一条路径都比编造一个答案有价值。
用竞品毛利率的例子来说明。用户问：「帮我分析一下竞品 X 的上季度毛利率。」一个好的 agent 反应链是这样的：检测到没有 X 的内部财务数据，触发「不知道」状态，然后立即提供三条替代路径——第一，搜索 X 最近的公开财报，计算公开披露的毛利率数字并标注数据来源和时效；第二，提供行业平均毛利率区间作为参考，并说明这和 X 实际数字之间可能存在的偏差；第三，列出计算毛利率所需的精确数据项（营收、营业成本、毛利），让用户知道「精确分析」需要什么条件。
这三条路径每一条都比随口给一个「约 35%」的数字要有用一万倍。前者帮用户建立了认知框架，后者只是在制造幻觉。
系统设计层面的三个建议
如果你在设计一个 agent 系统，以下三个方向值得认真投入。
第一，在计划质量门里加入「不确定度检查」步骤。在 agent 的 plan 阶段，不仅要检查「任务是否被正确理解」，还要检查「完成这个任务所需的信息是否充足」。如果信息不充足，plan 阶段就应该把「信息获取」列为第一步任务，而不是假设信息会在执行过程中凭空出现。这个检查不需要模型自己判断，开发者在设计质量门时应该穷举「哪些信息是完成任务所必需的」，然后在 plan 里显式检查这些信息是否存在。
第二，在知识密集型任务里强制标注信息来源和置信度。任何涉及事实性陈述的输出，都应该附带「数据来源：XXX，置信度：高/中/低，原因：……」这样的元信息。这个元信息不是给用户看的，而是给系统的下一个环节看的——负责审核 agent 输出的质量门可以基于置信度决定是否放行、是否需要人工确认、以及是否需要调用补充工具。
第三，把「承认不确定」纳入 agent 的评价体系。开发者在迭代 agent 时，需要一个指标来衡量 agent 在不确定情况下的诚实程度。这个指标可以是：「在低置信度场景下，agent 选择调用工具或请求用户确认而非直接生成答案的比例」。这个比例越高，说明 agent 越不倾向于瞎猜，也越不容易产生危害性的 hallucination。
写在最后
说「不知道」不是能力不足。一个在不确定情况下选择闭嘴而不是胡说的 agent，才是真正值得信赖的系统。
人类专家之所以值得信赖，不是因为他们什么都知道，而是因为他们知道自己的边界在哪里，并且愿意诚实地告知。这个边界管理能力，是专业素养的核心组成部分。AI agent 如果要被委托处理真实世界的任务——查账、分析竞品、辅助医疗决策——就必须具备同等水平的自我边界感知。
设计「承认不确定」的机制，不是给 agent 设限，而是给它装上一套刹车系统。没有刹车的车跑得快，但随时可能翻车。
从今天起，在你设计下一个 agent 的 prompt 时，加一行：「如果你不确定答案，请选择调用工具或明确告知用户，而不是输出猜测。」这是最小的一步，也是最重要的一步。