生产环境代理评估应测试事故重放，而不仅仅是任务成功
摘要
讨论生产环境代理评估应包括故障重放和恢复能力，而不仅仅是顺利路径的任务成功，强调需要可观测性以实现恢复。
我见到的大多数代理评估仍然只衡量代理是否完成了顺利路径的任务。这很有用，但对于生产环境，我认为更重要的评估是：当运行出错时，操作员能否重建发生了什么？对于每个失败或部分完成的运行，我想回答：- 失败前的持久状态是什么？- 哪个工具调用改变了外部世界？- 发送的确切载荷或差异是什么？- 是否有幂等键或外部回执？- 模型使用了哪些证据？- 下一个操作员能否安全地恢复、重试、补偿或放弃？如果答案是否定的，那么代理可能通过了演示，但未能通过生产评估。这改变了我对可观测性的看法。如果追踪只是一堆跨度，它们是不够的。追踪必须成为恢复工件：状态、决策、外部回执、策略结果和负责人。很好奇这里的团队是如何评估生产代理的。你们只衡量任务成功，还是有故障重放和恢复评估？
相似文章
智能体失败应成为评估标准，而不仅仅是追踪记录
主张将智能体失败视为评估基准，而不仅仅是追踪日志，强调需要对AI智能体行为进行系统性测试。
当你的智能体在生产环境中出错时，如何定位哪一步出了问题？
一位开发者分享了在多步骤智能体生产调试中遇到的挑战——由于复杂的工具使用和自信的错误回答，失败难以追踪，并向社区寻求更好的监控和回归检测方法。
大多数智能体可观测性感觉像是崩溃录像
作者认为，当前的智能体可观测性提供了行动轨迹，但缺乏运行时对行动为何被允许的合理性说明，这对于涉及金钱、数据或通信的生产部署至关重要。
你们是如何处理AI代理在生产中中途任务失败的？以及这种情况对你们来说有多频繁？
一个讨论提问，询问开发者如何处理AI代理在生产中中途崩溃的情况，探讨重启、持久化状态、使用检查点或手动检查等方法。
智能体检查点远未达到生产级弹性
一篇博客文章指出，当前的智能体检查点不足以实现生产级弹性，指出了故障检测、自动重试和高可用性等缺口，并建议将智能体构建在高可用编排层之上。