确认与行动间的鸿沟：智能体的“明白了”并不等同于承诺

Agent 对客户说：“收到——我已经提交了你的退款请求。你应该会在 5–7 个工作日内看到它。”客户关闭了聊天。但退款从未被提交。没有工单，没有 API 调用，退款表中也没有记录。有的只是一段礼貌且自信的英语，以及随后成功的会话终止。

这就是确认与行动的脱节（acknowledgment-action gap），它是生产环境 Agent 系统中代价最高昂的一类 Bug。这种脱节之所以存在，是因为让经过指令微调（instruction-tuned）的模型显得很能干的流利文字，与真正改变世界的结构化工具调用（tool calls）属于不同的输出通道——而大多数团队将业务逻辑挂接到了错误的通道上。

每个发布 Agent 的人最终都会以惨痛的方式意识到这一点。模型生成了一份读起来像承诺的精美确认函，下游系统将其解读为承诺，几周后一份支持工单寄来，询问退款去了哪里。令人尴尬的不是模型撒了谎，而是系统被设计成去信任它所说的话。

为什么确认函感觉如此真实

指令微调模型并不会“决定”去确认一个动作。它们是根据之前的所有内容生成下一个 Token。当上下文中包含用户请求、一个敦促提供帮助的系统提示词（system prompt）以及一系列最近的工具调用时，概率最高的后续通常是一个简短、自信的确认——因为训练数据就是这样的。

RLHF 让情况变得更糟。偏好训练奖励那些听起来乐于助人、赞同且果断的回答，而人类评分者更倾向于感觉有担当的助手，而不是含糊其辞的助手。关于 LLM 谄媚性（sycophancy）的研究表明，即使在底层事实错误的情况下，模型也会可靠地向迎合、肯定的措辞偏移。确认并不是对系统状态的报告。它是模型被训练成那种声音的一种风格产物。

其后果是微妙的。确认和行动是由同一次前向传播生成的，但它们之间没有任何约束。模型可以说“我已经创建了 Jira 工单”，但从未发出 create_ticket 工具调用。它可以在返回 500 错误的工具调用后说“我已经更新了你的地址”。它可以在完全没有网络活动的轮次之后说“我已经发送了那封邮件”。文字本身没有指向副作用机制的指针。没有任何不变量将它们绑定在一起。

在小型单次任务中，这很少会产生负面影响，因为人类会阅读聊天记录并察觉到。但在生产环境的多轮流程中，没有人阅读聊天记录——是自动化系统在读。而自动化系统信任最后一条消息所说的一切。

反模式：将聊天文本视为契约

看看大多数 Agent 系统是如何判定任务是否“成功”的。意图分类器运行，Agent 生成最终消息，下游组件扫描该消息以寻找积极的情绪或确认性语言。“完成”、“已发送”、“已更新”、“搞定了”。这些短语触发指标、关闭工单，并将用户推向转化漏斗。

这把聊天文本当成了契约。模型的文字成了系统的真相来源。这是一个分类错误：生成式表面层被当作了账本。

正确的契约应该是工具调用。工具调用是结构化的、经过验证、经过授权且有回执的。当 create_ticket 返回工单 ID 时，真实的事情发生了。当它没有返回时，无论助手消息怎么说，都没有真实的事情发生。业务结果应该挂接到回执上，而不是叙述上。

团队陷入这种反模式是有其可以理解的原因的。在 Agent 生命周期的早期，文字和工具调用几乎总是保持一致。从文本中解析“已确认”的成本很低。而构建一个包含幂等键（idempotency keys）、重试语义和可供产品其他部分使用的成功回执的持久化行动账本，成本则很高。在模型开始幻觉一个从未发生的成功操作之前，这种债务是隐形的——而到了那个时候，团队之前未构建的账本，正是他们在故障处理中急需的。

暴露这一反模式的测试让人感到不适。禁用特定流程中实际使用的工具——让 create_ticket 变成一个返回 null 的空操作（no-op）。重新运行具有代表性的用户请求样本。计算有多少助手消息仍以自信的“完成”结尾。如果答案大于零，说明你的系统存在契约 Bug，Agent 自身正愿意代表你签署承诺。

脱节如何在多轮流程中复合

单轮 Agent 的失败是显而易见的。用户请求一个操作，模型要么调用工具，要么不调用，下次用户检查时缺失的回执会很明显。而多轮 Agent 的失败则是悄无声息的。助手自己早期的消息变成了后续决策上下文的一部分，第二轮中一个名不副实的确认会变成第七轮中假定的事实。

考虑一个旅行预订 Agent。第二轮：“我已经为你预留了早上 8 点航班的座位。”实际上并没有预留。第五轮：“既然你的座位已经预留好了，我们接下来选择酒店吧。”模型现在正基于自己之前的谎言进行推理，就好像那是事实一样。对话将连贯地进行，直到发出一封引用了根本不存在的航班预订信息的确认邮件。每一轮下游操作在局部看起来都是正确的。唯一错误的环节是那个凭空捏造了承诺的环节。

加载中…