智能体 AI 架构中记忆、知识与上下文的系统化方案

随着行业从聊天机器人向自主智能体演进，架构层面的瓶颈正在发生转移。难点不再仅仅是数据检索，而是决定智能体应该知道什么、何时应该知道、应该记住多久，以及应该遗忘什么。和人类一样，“知道”是一回事，“记住”是另一回事。由此有了记忆与知识的概念。根据任务上下文判断何时动用现有的各种“知道”并将其调入记忆才是关键。例如，如果我只是想煎个蛋饼，那么此刻并不需要记住如何揉面。 我们来拆解一下。 智能体必须跨工具、会话、用户和实时系统进行推理。在工程化系统中，我们可以将上下文描述为一种控制平面。“上下文即控制平面”是一种架构范式：组织、行为和情境数据（即谁、什么、为什么）作为系统运营的集中治理层，而不是直接硬编码到各个应用、AI 模型或微服务中。在我们的世界里，这将决定智能体能否像可靠的软件系统一样运行。提供错误的上下文会极大增加模型产生幻觉的可能性。 系统知识就是指我们的策略、治理规则和硬性事实。它相当于系统的官方教科书，保存着核心业务逻辑、严格的策略和数据库。回到煎蛋饼的例子，其中一部分知识就是需要鸡蛋和平底锅。 记忆是连接历史数据与实时信号、并将其转化为可供推理状态的关键层。当前任务需要记住什么？这通常来自知识、历史数据和当前实时事件所提供的信息。 总结我们的三个组件： 上下文（Context） —— 智能体在任一时刻正在使用的即时、活跃且临时性的信息。它直接位于模型的活跃上下文窗口内（类似于计算机的内存 RAM）。记忆（Memory） —— 提供持久化能力。它让智能体能够将信息保留到单次交互之外，从而从过去的经验中学习，并随时间推移不断适应用户。知识（Knowledge） —— 智能体在与用户交互之前就具备的事实、概念和规则基础。它是用于训练或微调系统的领域特定数据，或者是系统被授予访问权的参考资料库，属于经过高度精选的数据。 对于智能体系统，我们的目标是：在给定任务上下文、系统知识和记忆的情况下，在正确的时刻将数据转化为正确的记忆状态。 除此之外，这种动态架构范式本身存在局限性，因此我们需要系统性应对大语言模型本身带来的成本问题，以及幻觉产生在技术、架构层面的根源。作为开发者和架构师，学会避开智能体系统管理中常见的“坑点”至关重要。接下来我们将深入探讨，如何为下一代可靠的智能体 AI 设计一个完善的多层级架构。 向上下文引擎转变 大语言模型能发挥多大价值取决于我们如何使用它。模型负责生成内容，而我们的系统决定它能看到什么。想要避免幻觉，我们需要在模型外围构建一个可信的系统，充分利用上下文、知识和记忆。为了构建这个系统架构，我们将模型与周边机制分离开来。后文中，我们将这套外围支撑机制称为上下文引擎。它是上下文控制平面的一部分，是负责在信息抵达大模型推理端点之前对其进行选择、过滤、排序、结构化、压缩、安全保护和交付的编排器。它从知识中拉取信息，将其归类到记忆中，并决定在任意给定的毫秒内智能体的上下文应该是什么。这是从简单的提示词工程向系统工程的一次意义深远的转变。 从提示词到状态/上下文系统 提示词工程假定任务就是打磨出更好的指令，而上下文工程假定任务是构建一个动态基底，持续为推理组装出正确的状态。提示词不再是思考“我该向模型提什么问题？”，而是思考“模型当下要做好推理，最小化、价值最高的上下文是什么？” 在生产级智能体架构中，我们需要动态系统来控制在任意给定的毫秒内智能体“知道”什么。我们的系统目标是获取相关内容，并编译出一个包含所需信息的新提示词，提高模型的成功概率。 上下文即编译器 要理解上下文引擎的工作方式，我们可以将其与现代软件编译器类比。编译器将高级源代码翻译成机器可执行的指令，上下文引擎则将浩瀚无边的非结构化、彼此孤立的原始实时数据和历史数据翻译成结构化的、可供推理的状态。它构建出一个确定性的状态机，让概率性的智能体能够安全执行。它确保输入经过了身份认证、对照业务逻辑进行了校验、剥离了个人可识别信息（PII），并在大模型生成行动计划之前被安全地沙箱化。 架构思考 为自主 AI 智能体设计有效的软件架构，需要调和几种在数据管理与数据流方面存在冲突的范式。 历史记忆流与实时记忆流 健壮的智能体架构必须能够优雅地平衡长期“情景记忆”与即时“感知输入”。这意味着，要构建一个有用的上下文引擎，我们的架构必须调和两类截然不同的状态：历史记忆和实时输入。 历史记忆是长寿命层，包括过往交互、历史决策、用户偏好、领域规则、内部文档和累积的观察记录。它赋予智能体连续性，让系统表现得如同拥有过往经验。 实时输入是短寿命层，包括当前任务、最新事件、实时遥测数据、新鲜的工具输出和环境变化。它让智能体立足于当下。 向量数据库擅长检索历史性的语义事实，但智能体工作流常常依赖于亚秒级的实时上下文。举个例子，一个 AI DevOps 智能体正在排查服务器故障，从向量库中检索架构运行手册（情景记忆）只完成了一半工作，它还需要最近五秒的实时错误日志流（感知记忆）。架构必须异步地融合这些批量与流式数据源，确保智能体基于统一、最新的事实展开行动。 这种架构必须保持平衡。如果过度偏向历史/情景记忆，智能体会变得滞后，持续用过去的假设判断当下情况。如果过度偏向实时数据，智能体会变得被动且健忘——它可能对最新信号做出响应，却忽略了赋予该信号意义的上下文。 好在这种矛盾并不是新问题。分布式系统一直都要处理持久状态和瞬时事件的冲突。智能体系统继承了同样的问题，但多了一个挑战：推理层是概率性的、成本高昂，且受限于有限的上下文窗口。这给上下文架构设计增加了约束优化目标——决定哪些信息要保留、哪些可以压缩、哪些必须重新验证、哪些应被完全排除。目标不只是保证信息新鲜或者完整，而是在约束条件下保证信息有用。 知识与原始数据（SELECT * 与累积洞见） AI 系统中最常见的架构错误之一，就是把检索当作充分条件，这在语义层面相当于 SQL 的 SELECT *，想当然地认为信息越多越好。试图持续检索大量数据的架构在大规模场景下必然失败。我们可以把检索看作数据进入系统的方式，但它并不能保证数据对当前决策是有用的、及时的、连贯的或经过恰当排序的。这正是标准 RAG 管道的症结所在——它们往往只负责检索原始的、碎片化的、相互重叠的数据块。实际上，这种做法很可能导致系统把 10 页未经编辑的 Wiki 页面内容全部塞进提示词，大模型耗费算力在噪声里寻找有效信号——却因为关键信号淹没在大量无关噪声之下而失败。因此，正确的信息和数据的形态，也就是我们所说的知识，比原始数据重要得多。 真正的知识提炼聚焦于累积洞见。架构不再注入原始数据，而是采用后台工作进程/机器学习管道，利用最新的系统状态对检索到的数据进行提炼、聚合和相关性排序。为此，我们需要构建专门的管道，将原始数据转化为结构化知识图谱或精简的摘要。例如，针对一个大型数据库，创建一个管道，每 12 小时将一百万条数据条目汇总成一条。这样可以确保模型接收到的是一小段经过合成的知识体（数据库中的 1 个条目），而不是一股混乱的意识流（有时是整个数据库）。 定制上下文：告别“一刀切” GPT-4、Claude 等基础模型，以及 Pinecone、Milvus 等向量数据库，已经成为容易获取的通用基础设施，任何