2 篇博文 含有标签「ai-agent」

你的 Agent 处理了一笔退款，但响应超时了。框架进行了重试。结果客户收到了两次退款。你的 Agent 发送了一封跟进邮件，触碰了速率限制，在退避（backoff）后重试，结果客户收到了两条完全相同的消息。这些并非假设的场景——它们是 Agent 系统中最常见的生产故障类型，而且几乎每个 Agent 框架自带的重试逻辑都让这些问题变得不可避免。

根本原因看似简单：Agent 框架对所有工具调用的处理方式都一样，无论它是读取数据还是改变现实世界。get_user_profile() 调用重试一百次也是安全的。但 send_payment() 调用则不然。然而，大多数框架都将两者封装在相同的指数退避重试逻辑中，并美其名曰“可靠性”。

你的智能体调用一个工具，获取响应，并立即将其视为真理进行推理。没有 Schema 检查。没有新鲜度验证。没有针对响应预期形式的健全性测试。这是每个主流智能体框架的默认行为，它悄无声息地导致了一整类传统监控永远无法捕获的生产环境故障。

工具结果验证缺口是指“工具返回了某些内容”与“工具返回了正确内容”之间的地带。大多数团队痴迷于确保工具调用正确——选择正确的工具、生成有效的参数、处理超时。几乎没有人验证返回的内容。