AI代理没有智能问题，它们有状态管理问题

过去几个月，我一直在研究AI代理、副驾驶系统、编排系统和工作流自动化工具在生产中的故障模式。阅读了多个社区的工程讨论、部署事后分析和运维投诉后，一个模式反复出现：大多数生产AI故障并非由弱模型引起，而是由不稳定的运行状态造成的。 --- 1. 行业仍然过度关注模型能力 大多数讨论仍围绕：更大的上下文窗口、基准测试分数、推理改进、推理速度、工具使用。但一旦系统进入生产工作流，主导问题就彻底改变了。团队开始与以下问题作斗争：内存漂移、过时检索、执行不一致、工作流分歧、重试循环、调试失败、运行不稳定。这时，问题不再像“AI”，而更像分布式系统工程。 --- 2. 当前的代理架构从根本上不完整 目前很大一部分系统仍然这样运行：提示 → 大语言模型 → 工具 → 输出。这对演示有效，但在长期运行的生产环境中变得脆弱。现实世界的系统越来越需要以下层次：状态验证、执行策略、恢复处理、内存生命周期管理、可观测性、回滚能力、不确定性处理。没有这些层次，小的不一致会随着时间累积。 --- 3. 长期运行的内存退化速度惊人 一个反复出现的问题是，随着使用时间延长，内存会退化。典型的故障模式：检索出无关上下文、过时内存覆盖近期状态、矛盾信息积累、摘要逐渐扭曲上下文、代理强化早期错误。困难之处在于，退化通常是缓慢且无声的。团队可能直到工作流变得不一致或用户信任崩溃时才注意到。 --- 4. 传统调试方法不足 这是其中一个更有趣的运行问题。在传统系统中：日志、堆栈跟踪、确定性重放通常足以隔离故障。但对于AI系统，故障往往是概率性的且与状态相关。这导致团队无法可靠地确定：哪个内存导致了故障、哪个检索破坏了推理、为什么执行路径出现分歧、故障是否可重现。这使得可观测性比传统软件系统困难得多。 --- 5. 可靠性层带来了自身的问题 明显的解决方案是添加：验证层、矛盾检测、重放系统、策略执行、审批工作流。但每增加一项保障都会增加：延迟、编排复杂性、存储开销、同步成本、运维摩擦。这产生了一个重要的权衡：高可靠性系统可能变得过慢或运维成本过高。 --- 6. 真正的挑战是自适应可靠性 我越研究这些系统，越觉得静态管道是错误的做法。并非每个工作流都需要最高级别的保障。更好的架构可能是：低风险任务的轻量执行、仅对高风险操作进行深度验证、基于不确定性的动态可观测性、选择性回滚检查点、风险感知编排。换句话说，可靠性机制应根据操作风险来伸缩。 --- 7. 这越来越像一个基础设施问题 当前许多AI工具关注的是：编排、链式调用、代理协作、工具调用。但较少关注：内存完整性、执行重放、状态恢复、运维追踪、矛盾管理、可靠性中间件。这可能会成为未来几年最重要的基础设施缺口之一。 --- 8. 我当前的结论 模型能力仍然重要。但一旦AI系统变得持久、有状态且嵌入运维，可靠性和状态管理质量就开始与原始智能同等重要。能在生产中存活下来的系统，很可能不是那些演示最惊艳的系统，而是那些：安全恢复、随时间保持稳定、正确处理不确定性、维持一致运行状态、以可预测而非灾难性方式失效的系统。 好奇其他从事生产AI系统的人是否看到类似模式，尤其是关于：长期运行的代理稳定性、内存退化、编排复杂性、调试工作流、可靠性vs延迟权衡、恢复和回滚策略。