我们的大部分“智能体”问题实际上是工作流/状态问题

Reddit r/AI_Agents 新闻
workflow state-management agents observability retries production-lessons

摘要

一位开发者讲述，构建AI智能体时的许多挑战实际上源于工作流和状态管理问题，而非模型智能，强调了稳健的状态处理和可观测性的必要性。

我们构建的一个工作流调用了银行API。银行接受了电汇。编排器在记录完成之前崩溃了。重试再次运行了后续步骤。银行的幂等键起了作用，但客户还是收到了两条通知。这个例子让我们明白了一件事：很多“智能体”的痛点实际上是工作流/状态的痛点。问题不再是“应该用哪个模型？”，而是变成了： * 实际运行了什么 * 什么被取消了 * 哪些可以安全重试 * 当运行超出单个请求的生命周期时，状态存在哪里 * 如何事后检查发生了什么 这也改变了我们对智能体与工作流的看法。很多被称为智能体的东西，实际上用工作流来表达更好。路径大多是已知的，步骤可调试，审批明确，失败处理更清晰。当系统需要在运行中自适应、从工具故障中恢复或决定下一步尝试什么时，智能体部分才真正开始发挥价值。但即便如此，最常困扰我们的不是“智能”，而是状态。如果重试、工具调用、审批和副作用都在发生，局部状态很快就会变得不可靠。你需要能够事后检查的东西，而不必猜测哪个步骤真的提交了，哪个只是看起来提交了。 更大的教训：模型质量很重要，但生产中的痛点通常在工作流控制。好奇这里是否有人遇到过同样的情况。你的“智能体”问题一直是智能体问题，还是当你真正尝试运行时，它们大多变成了工作流/状态/可观测性问题？
查看原文

相似文章

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

Reddit r/AI_Agents

文章认为，AI代理在生产中的大多数故障是由于不稳定的运行状态和内存退化造成的，而非模型能力不足，并强调需要更好的基础设施来支持状态管理、可观测性和自适应可靠性。