我们的AI智能体向客户开具了0.00美元的发票，而我们的日志却未发现异常。以下是我们如何发现的。

快速分享一个实战故事，因为我想知道是否有人遇到过类似情况。我们运行一个内部销售运营智能体，负责处理一部分报价工作。客户填写表格后，智能体会提取相关SKU，对照定价逻辑进行计算，草拟发票，然后在最终发出前交给人工审核。正是这个人工审核步骤让我们发现了问题。上周二，一位AE给我发了一张截图。智能体为14座企业版方案草拟了一张发票，行项目正确，客户信息正确，日期正确，但总计金额为0.00美元。不是空白，不是空值，也不是错误。模型自信地写下了"$0.00"，格式与真实发票行完全一致。如果AE当时动作快点击了批准，这份报价就会发出去。我起初猜测是定价API返回了零，但并非如此——日志显示正确的数字已经返回，只是智能体决定不使用它。我花了大约一天才弄清楚实际发生了什么，而且完全出乎我的意料。我检查了API响应，没问题。检查了提示词，与已经运行了三个月的版本相同。在预发布环境输入同样的数据，得到了正确的发票，无法复现。我以为是模型的一次偶然失误，便没再深究，但当天又发生了两次。当我终于拉取了一次失败运行的完整追踪时，发现其中有一个步骤是我没有故意添加的。在定价工具调用之后，智能体针对一个合同对象运行了自己的“验证”，而这个对象是几周前我们为了一个不相关的功能放入提示上下文中的。该对象有一个discount_applied字段，对这些客户总是null，模型将null解读为100%折扣，然后自信地写下了0.00美元。我任何一个单独的日志都无法捕捉到这一点。printf调试会显示定价工具返回了正确的数字，但输出却神秘地变成了零。我之所以能发现这个验证步骤，唯一的原因是它在追踪中作为独立的span出现，位于工具调用和最终合成之间。事后看来，修复方法很简单：将合同对象从开票路径中移除，并添加了一个评估规则，对低于阈值的任何发票标记为需要明确审核。一旦知道了问题所在，一个下午就部署完成了。我的收获是：对于智能体来说，printf调试基本已死，因为模型可以在你记录的步骤之间做一些你永远想不到要记录的事情。可怕的失败不是那些垃圾输出，而是那些看似合理、格式正确但完全错误，并且通过了所有合理性检查（除了“这个数字真的对吗？”）的情况。而将null暴露给没有明确说明如何解读它的LLM，简直是自找麻烦。我们使用Langfuse作为追踪层，说实话，如果没有记录完整执行路径的工具，我不知道如何调试生产环境中的智能体。很好奇是否有人有类似的故事，特别是那种“模型自信地插入了你并未要求执行的一个步骤”的失败模式，因为这次经历比普通的幻觉更让我感到不安。