AI代理即使能通过所有交接仍然可能出错。我认为状态是我们测试不足的生产失败。

我经常看到生产清单关注幻觉、权限、重试、日志、人工审查和交接完整性。这些都很重要。但我认为有另一种失败被忽略了：代理可以正确携带信息却仍然从错误的状态操作。简单例子：一个工作流以5万美元的预算开始。中途，预算更改为2万美元。代理正确确认了更改。下一个代理正确接收了更新的信息。一切看似正常。然后五步之后，一个较旧的摘要、记忆或检索记录将5万美元的值带回工作流。现在每个单独的响应仍然看起来合理，但系统正在从两个不同版本的现实中操作。这并非真正的普通幻觉。交接可能运作完美。问题在于系统丢失了哪个状态是权威的跟踪。我一直在对这类失败进行压力测试，我认为一个生产代理在运行中的任何时刻都应该能够回答四个问题：现在什么是真实的？什么改变了？什么仍然起约束作用？什么实际算作完成？我认为在生产前值得运行的几个测试： - 在长时间工作流中途更改一个重要事实，看看旧值是否再次出现。 - 引入两个不一致的源，看看哪个胜出，以及为什么。 - 在代理已经使用权限后撤销它。 - 中断一个工作流，然后稍后恢复。 - 强制工具或代理交接在中途失败，然后恢复。 - 让代理在仍缺少一个必要条件时声称已完成。 有趣的情况不是代理明显损坏的时候，而是当每个局部步骤都很好，而整个系统悄悄漂移到错误版本的现实时。更大的上下文窗口不一定能解决这个问题。更好的提示也不一定能做到。在这里，人们如何处理长时间或多代理工作流中的权威状态？数据库状态？事件日志？工作流引擎？自定义控制层？有没有人在生产中看到这种个别交接看起来正确的失败？