别再把你AI助手的记忆放在LLM上下文窗口里了

大家好，最近我将一些智能体工作流投入生产，想吐槽/分享一个我看到很多人犯的重大架构错误。别再把你LLM的上下文窗口或大规模向量嵌入当作智能体的长期记忆。如果你的智能体需要保留状态、记住过去的误报、处理人机协同工作流或维护审计轨迹，那么将会话历史整成一个巨大的JSON blob来回传递到提示词中，简直就是无声失败和高昂token账单的配方。对我们而言，唯一能在生产环境中存活的架构依赖于严格的关注点分离。首先，持久化状态和记忆必须完全存在于智能体之外，放在像Postgres或Lakebase这样平淡且高度结构化的事务性数据库中。智能体只需在启动时读取，在工具执行时写入——它本身不应是数据库。其次，使用确定性控制流。如果你有明确的业务约束，比如“在写入数据前必须征求人类意见”，那就用Python或Langgraph这样的状态图框架来编码这个逻辑，不要依赖系统提示来强制执行安全边界。最后，把LLM当作判断层。严格将模型用于处理非结构化输入、生成工具参数或总结证据。将状态层迁移到专用数据库意味着我们实际上可以暂停、重放和单元测试智能体的执行，而不用担心上下文漂移或幻觉抹掉智能体的历史。很想知道其他人是如何处理多日工作流的持久状态的？你们是把所有逻辑都封装在自定义的SQL表中，还是依赖框架的记忆功能？