北京
八篇帖子前，我们从一堆石头开始。
到那个系列结束时，那些石头已经变成了一个可识别的系统——采集层、摄取管道、结构化记录、索引资产，最后是上层应用。这个架构与后院之外的系统惊人地一致：制造业、档案管理、人工智能。
但这个架构留下了一个未解决的问题。
数据流入，数据被索引，应用查询它。但系统做不到——也无法做到——跨越时间记忆。每次查询都是无状态的，每次会话都重新开始。
这对石头来说没问题。石头不会变。十月编目的花岗岩标本，三月还是那块花岗岩。
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提示到持久智能的工程跃迁。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
