八篇帖子前，我们从一堆石头开始。

到那个系列结束时，那些石头已经变成了一个可识别的系统——采集层、摄取管道、结构化记录、索引资产，最后是上层应用。这个架构与后院之外的系统惊人地一致：制造业、档案管理、人工智能。

打开网易新闻 查看精彩图片

但这个架构留下了一个未解决的问题。

数据流入，数据被索引，应用查询它。但系统做不到——也无法做到——跨越时间记忆。每次查询都是无状态的，每次会话都重新开始。

这对石头来说没问题。石头不会变。十月编目的花岗岩标本，三月还是那块花岗岩。

AI智能体不同。

它们现在无处不在。但大多数共享同一个架构限制：它们会遗忘。

这不是因为AI模型能力不足或有缺陷。而是因为包裹它们的应用是无状态的。作为开发者，我们花了多年时间设计通过数据库、缓存、队列、事件日志等有意持久化状态的系统。然而，许多AI系统仍依赖最简单的记忆机制：把之前的消息追加到提示里，希望它能装得下。

在演示、示例应用和展示的语境中，这能奏效。但对生产环境来说，它无法扩展。

有几种技术被用来克服这一架构限制，Oracle的团队有一些有趣的例子。他们的GitHub仓库oracle-ai-developer-hub展示了不同方法。通过memory_context_engineering_agents.ipynb等Jupyter笔记本和RAG示例，智能体记忆不再是一个功能，而成为一门工程学科。

让我们深入探讨为何这种向智能体记忆的转变很重要，以及开发者如何在真实系统中应用这些模式。

核心问题：默认无状态

大多数大语言模型（LLM）API以无状态方式运行，比如这样：

response = llm.generate(
prompt = "User: What did I ask earlier? \n Assistant:"
)

如果应用不明确包含之前交互的上下文，模型对此一无所知。常见的变通方法可能是：

conversation_history.append(user_message)
response = llm.generate(
prompt="\n".join(conversation_history)
)

这看起来合理，但有一些问题需要考虑。当对话超出token限制时怎么办？当检索变得过于昂贵时怎么办？当跨会话持久化变得复杂时怎么办？当无关信息淹没上下文窗口时怎么办？

这些不是边缘情况，而是生产部署中的核心工程挑战。

Oracle的示例展示了更成熟的解决方案：上下文工程、检索增强生成（RAG）、以及将记忆作为可查询资产而非提示填充物来处理。这些方法把智能体记忆从"让它能工作"的演示技巧，转变为可设计、可优化、可监控的系统组件。

对于正在构建真实AI应用的开发者来说，这意味着一个关键转变：不再问"我的提示能装多少历史"，而是问"我的系统需要记住什么、如何记住、记住多久"。

这是从状态less提示到持久智能的工程跃迁。