你的 Agent Demo 运行良好，但这正是陷阱所在。

我为公司构建 AI Agent。我经常看到同样的模式：模型在 Demo 中表现出色，你发布了产品，然后在生产环境中，每三次就有一次失败。没人知道为什么。

Demo 与生产环境之间的差距在于数学。一旦你理解了其中的数学逻辑，你的构建方式就会有所不同。

如果你的 Agent 中每一步的可靠性都是 95%，听起来很不错。但 Agent 使用的是步骤链。如果你将十个步骤串联起来，成功率会降至 60%。如果你使用二十个步骤，成功率会降至 36%。

在实际工作中，步骤的错误率通常在 10% 到 20% 之间。如果一个 Agent 有八个步骤，且每步可靠性为 85%，那么它有 75% 的时间会失败。

模型不是问题所在。复合概率才是问题所在。

Demo 展示的是单一的“快乐路径”（happy path）。它使用干净的输入和短链。而生产环境使用的是来自数百名用户的杂乱数据，并使用包含隐藏步骤的长链。

Agent 的失败看起来不像崩溃，而更像是一个“静默错误”。

第 3 步读错了字段。输出看起来仍然是有效的 JSON。第 4 步利用这些错误数据进行推理。第 5 到第 8 步基于这个错误继续构建。最终答案是错误的，但看起来很合理。没有任何错误日志能告诉你哪里出了问题。

不要再说模型在“幻觉”了。模型只是传递了它接收到的错误数据。你的系统缺乏一个检查点（checkpoint）来在第 3 步捕获错误。

不要再把 Agent 当作一个 Prompt，要开始把它当作一个系统。

遵循以下规则来构建可靠的 Agent：

  • 在 Agent 外部保存状态。将状态保存在数据库中，而不是对话中。如果流程在第 6 步失败，你可以从第 6 步恢复，而无需重启整个链条。

  • 在边界处进行验证。根据 Schema 检查每一个输入和输出。在错误发生的步骤立即捕获它。这能将一个“谜团”变成一个“可恢复的错误”。

  • 使副作用具有幂等性。当步骤失败时，你必须进行重试。如果某个步骤发送了电子邮件或扣款，请使用幂等键（idempotency key）。这可以防止重试期间产生重复操作。

  • 在 CI 中使用评估（evals）。Agent 的行为会随着每一次微调而改变。一次 Prompt 的修改可能会修复一个案例，但却会导致其他五个案例出错。使用测试集来自动捕获这些回归（regressions）。

从 Demo 转向真正的产品是工程问题。它关乎错误处理、状态管理和可观测性，而不是关乎更好的 Prompt。

如果你的 Agent 在生产环境中表现不稳定，不要试图寻找更大的模型。去寻找链条出错的具体步骤。问问自己，为什么你的系统没有在那里捕获错误。

Source: https://dev.to/sagar_jain4010/your-agent-demo-works-thats-the-trap-4joc

Optional learning community: https://t.me/GyaanSetuAi