随着行业从聊天机器人向自主智能体演进，架构层面的瓶颈正在发生转移。难点不再仅仅是数据检索，而是决定智能体应该知道什么、何时应该知道、应该记住多久，以及应该遗忘什么。和人类一样，“知道”是一回事，“记住”是另一回事。由此有了记忆与知识的概念。根据任务上下文判断何时动用现有的各种“知道”并将其调入记忆才是关键。例如，如果我只是想煎个蛋饼，那么此刻并不需要记住如何揉面。

我们来拆解一下。

智能体必须跨工具、会话、用户和实时系统进行推理。在工程化系统中，我们可以将上下文描述为一种控制平面。“上下文即控制平面”是一种架构范式：组织、行为和情境数据（即谁、什么、为什么）作为系统运营的集中治理层，而不是直接硬编码到各个应用、AI 模型或微服务中。在我们的世界里，这将决定智能体能否像可靠的软件系统一样运行。提供错误的上下文会极大增加模型产生幻觉的可能性。

系统知识就是指我们的策略、治理规则和硬性事实。它相当于系统的官方教科书，保存着核心业务逻辑、严格的策略和数据库。回到煎蛋饼的例子，其中一部分知识就是需要鸡蛋和平底锅。

记忆是连接历史数据与实时信号、并将其转化为可供推理状态的关键层。当前任务需要记住什么？这通常来自知识、历史数据和当前实时事件所提供的信息。

总结我们的三个组件：

上下文（Context） —— 智能体在任一时刻正在使用的即时、活跃且临时性的信息。它直接位于模型的活跃上下文窗口内（类似于计算机的内存 RAM）。记忆（Memory） —— 提供持久化能力。它让智能体能够将信息保留到单次交互之外，从而从过去的经验中学习，并随时间推移不断适应用户。知识（Knowledge） —— 智能体在与用户交互之前就具备的事实、概念和规则基础。它是用于训练或微调系统的领域特定数据，或者是系统被授予访问权的参考资料库，属于经过高度精选的数据。

对于智能体系统，我们的目标是：在给定任务上下文、系统知识和记忆的情况下，在正确的时刻将数据转化为正确的记忆状态。

除此之外，这种动态架构范式本身存在局限性，因此我们需要系统性应对大语言模型本身带来的成本问题，以及幻觉产生在技术、架构层面的根源。作为开发者和架构师，学会避开智能体系统管理中常见的“坑点”至关重要。接下来我们将深入探讨，如何为下一代可靠的智能体 AI 设计一个完善的多层级架构。

向上下文引擎转变

大语言模型能发挥多大价值取决于我们如何使用它。模型负责生成内容，而我们的系统决定它能看到什么。想要避免幻觉，我们需要在模型外围构建一个可信的系统，充分利用上下文、知识和记忆。为了构建这个系统架构，我们将模型与周边机制分离开来。后文中，我们将这套外围支撑机制称为上下文引擎。它是上下文控制平面的一部分，是负责在信息抵达大模型推理端点之前对其进行选择、过滤、排序、结构化、压缩、安全保护和交付的编排器。它从知识中拉取信息，将其归类到记忆中，并决定在任意给定的毫秒内智能体的上下文应该是什么。这是从简单的提示词工程向系统工程的一次意义深远的转变。

从提示词到状态/上下文系统

提示词工程假定任务就是打磨出更好的指令，而上下文工程假定任务是构建一个动态基底，持续为推理组装出正确的状态。提示词不再是思考“我该向模型提什么问题？”，而是思考“模型当下要做好推理，最小化、价值最高的上下文是什么？”

在生产级智能体架构中，我们需要动态系统来控制在任意给定的毫秒内智能体“知道”什么。我们的系统目标是获取相关内容，并编译出一个包含所需信息的新提示词，提高模型的成功概率。

上下文即编译器

要理解上下文引擎的工作方式，我们可以将其与现代软件编译器类比。编译器将高级源代码翻译成机器可执行的指令，上下文引擎则将浩瀚无边的非结构化、彼此孤立的原始实时数据和历史数据翻译成结构化的、可供推理的状态。它构建出一个确定性的状态机，让概率性的智能体能够安全执行。它确保输入经过了身份认证、对照业务逻辑进行了校验、剥离了个人可识别信息（PII），并在大模型生成行动计划之前被安全地沙箱化。

架构思考

为自主 AI 智能体设计有效的软件架构，需要调和几种在数据管理与数据流方面存在冲突的范式。

历史记忆流与实时记忆流

健壮的智能体架构必须能够优雅地平衡长期“情景记忆”与即时“感知输入”。这意味着，要构建一个有用的上下文引擎，我们的架构必须调和两类截然不同的状态：历史记忆和实时输入。

历史记忆是长寿命层，包括过往交互、历史决策、用户偏好、领域规则、内部文档和累积的观察记录。它赋予智能体连续性，让系统表现得如同拥有过往经验。

实时输入是短寿命层，包括当前任务、最新事件、实时遥测数据、新鲜的工具输出和环境变化。它让智能体立足于当下。

向量数据库擅长检索历史性的语义事实，但智能体工作流常常依赖于亚秒级的实时上下文。举个例子，一个 AI DevOps 智能体正在排查服务器故障，从向量库中检索架构运行手册（情景记忆）只完成了一半工作，它还需要最近五秒的实时错误日志流（感知记忆）。架构必须异步地融合这些批量与流式数据源，确保智能体基于统一、最新的事实展开行动。

这种架构必须保持平衡。如果过度偏向历史/情景记忆，智能体会变得滞后，持续用过去的假设判断当下情况。如果过度偏向实时数据，智能体会变得被动且健忘——它可能对最新信号做出响应，却忽略了赋予该信号意义的上下文。

好在这种矛盾并不是新问题。分布式系统一直都要处理持久状态和瞬时事件的冲突。智能体系统继承了同样的问题，但多了一个挑战：推理层是概率性的、成本高昂，且受限于有限的上下文窗口。这给上下文架构设计增加了约束优化目标——决定哪些信息要保留、哪些可以压缩、哪些必须重新验证、哪些应被完全排除。目标不只是保证信息新鲜或者完整，而是在约束条件下保证信息有用。

知识与原始数据（SELECT * 与累积洞见）

AI 系统中最常见的架构错误之一，就是把检索当作充分条件，这在语义层面相当于 SQL 的 SELECT *，想当然地认为信息越多越好。试图持续检索大量数据的架构在大规模场景下必然失败。我们可以把检索看作数据进入系统的方式，但它并不能保证数据对当前决策是有用的、及时的、连贯的或经过恰当排序的。这正是标准 RAG 管道的症结所在——它们往往只负责检索原始的、碎片化的、相互重叠的数据块。实际上，这种做法很可能导致系统把 10 页未经编辑的 Wiki 页面内容全部塞进提示词，大模型耗费算力在噪声里寻找有效信号——却因为关键信号淹没在大量无关噪声之下而失败。因此，正确的信息和数据的形态，也就是我们所说的知识，比原始数据重要得多。

真正的知识提炼聚焦于累积洞见。架构不再注入原始数据，而是采用后台工作进程/机器学习管道，利用最新的系统状态对检索到的数据进行提炼、聚合和相关性排序。为此，我们需要构建专门的管道，将原始数据转化为结构化知识图谱或精简的摘要。例如，针对一个大型数据库，创建一个管道，每 12 小时将一百万条数据条目汇总成一条。这样可以确保模型接收到的是一小段经过合成的知识体（数据库中的 1 个条目），而不是一股混乱的意识流（有时是整个数据库）。

定制上下文：告别“一刀切”

GPT-4、Claude 等基础模型，以及 Pinecone、Milvus 等向量数据库，已经成为容易获取的通用基础设施，任何人都可以通过服务接入。但上下文并非如此，上下文相关的架构原则高度依赖领域。每一家公司都应基于自身业务领域和产品来设计自己的上下文。例如，金融科技公司为自主风控分析智能体整理上下文时，会优先关注交易时间戳、地理位置异常、以及严格的合规规则；而法律科技公司的做法会完全不同——它们可能会基于州法律来策划上下文，供合同生成智能体使用。我们逐渐意识到，上下文不可能是通用的，它必须反映特定产品独有的领域逻辑、安全边界和专业术语。

上下文生命周期：规模化管理知识与幻觉

将上下文视为一个连续的生命周期，工程团队就可以系统化管理知识，直接定位模型失败和推理成本高昂的根因。

生命周期阶段

一般来说，生命周期分为四个阶段：选择（Selection）、注入（Injection）、压缩（Compression）、过期与刷新（Expiration & Refresh）。图 2 描述了每个阶段如何成为架构中的专用模块或独立服务。

选择（检索与过滤）

这是第一步，也是最重要的一步。系统在这个阶段识别哪些数据点可能与当前任务相关。系统的目标是在多个数据存储中识别出价值最高的数据点。先进的架构已经不再只用向量空间的简单余弦相似度，而是采用混合搜索算法——将稠密语义搜索与稀疏关键词搜索（如 BM25）以及知识图谱遍历相结合，确保检索精准度。在这个过程中，我们要理解意图、任务类型、风险、用户角色和时间相关性。要记住，同一个底层语料库可能会为故障排查智能体、研究智能体和支持摘要智能体生成不同的上下文。架构与产品的差异正由此开始。作为设计要求的一部分，我们需要识别并定义哪些是高风险的、哪些是可操作的。

注入

在系统确定了重点信息之后，需要把信息以适当的形式放入模型的上下文（即上下文窗口）。表面上看只是简单的字符串拼接，却需要深思熟虑的设计。这涉及语义模板化——确保数据格式与用户的意图相匹配，包含必要的系统指令、少样本示例和输出格式约束（如 JSON 定义）。要理解这一步的重要性，只需看看它对整个系统的影响。在我们的世界里，信息的排布方式会直接改变模型的推理方式。因此，顺序、分组和结构化状态都至关重要。

压缩（摘要与蒸馏）

处理大型上下文成本很高。为了满足 Token 上限约束，历史数据需要进行迭代压缩。利用更小、更快的大模型（甚至确定性算法）来总结对话历史或压缩长文档可以节省大量空间并降低主推理模型的延迟。要仔细校验摘要，避免信息失真。现在有统计模型可用于评估摘要的有效性，例如困惑度（PPL）比率、Token 级 KL 散度、分类输出卡方检验等。

过期与刷新

永不过期的上下文最终会变成隐患。智能体需要相应的机制来淘汰过时的假设、刷新实时事实，并将持久不变的真相与临时的观察结果分离开来。系统偏好可能在数月内保持稳定，也可能一夜之间改变。产品配置可能在几分钟内发生变化。支持工单事件可能当天有效，一周后却会产生误导。如果没有过期与刷新机制，系统会陷入过时数据循环：不断重用曾经正确、如今却只是貌似有说服力的上下文。因此，必须通过反馈回路对系统进行持续测试和验证。这应根据系统的最终目标量身定制。例如，对于汽车共享系统，目标是让用户满意，因此，如果用户满意度突然下降，就要去排查需要刷新的底层信息。

幻觉往往就是上下文故障

大模型的幻觉很少是因为模型本身“坏掉了”，几乎都是上下文窗口管理不当、信息匮乏造成的症状。由于大模型是概率性的，当智能体缺乏回答提示或执行任务所需的事实数据时，其底层机制会迫使它基于潜在的训练权重去“猜测”。

主动的上下文管理是一道严格防护栏。通过用高度相关、高置信度的知识让模型饱和，并明确指示它仅基于所提供的上下文进行推理，能够有效抑制潜在的、不准确的关联。在生产级智能体系统中，精心设计的上下文引擎成为抵御幻觉行为的第一道防线。

Token 经济学：成本与性能的权衡

处理大型上下文向来成本高昂。注入提示词窗口的每个 Token 都会产生计算延迟和费用。Token 经济学是研究如何在大语言模型的约束下优化“注意力资源空间”的工程学科。

如今上下文窗口不断扩大（例如支持 128k 到百万以上 Token），诱使开发人员采用偷懒的架构：直接把整个代码库或者海量文档全部丢进提示词。这会大幅提升首 Token 响应延迟（TTFT），API 费用暴涨，而且讽刺的是，这样反而降低了模型性能。模型会遇到文献中提到的“中间遗忘（Lost in the Middle）”现象，如图 3 所示。这个现象由斯坦福研究人员 Nelson F. Liu 等人在 2023 年提出：模型很难提取藏在超长上下文中间位置的事实，只会重点关注首尾信息。U 型曲线底部越宽（上下文窗口越大），回答准确率越低。这项研究解释了为什么送入模型的上下文应当尽量精简：缩小 U 型底部范围，从而改善输出质量。

架构师必须权衡每一份检索文档带来的边际收益、对应的 Token 开销和相关性。我们能够传入十万 Token，不代表就应该这么做。严格的上下文配额、迭代裁剪、缓存机制是规模化降本的必备手段。

设计分层记忆架构

设计系统性的记忆方法，需要为智能体如何在会话间保留、更新或丢弃知识建立明确的边界。借鉴人类的认知架构，这样的系统应该是分层的：

工作记忆（提示词窗口）：执行工作流当前步骤所需的瞬时状态。容量严格受限，每次推理调用都会重置。短期记忆（会话缓存）：常由 Redis 这类内存数据库维护。记录当前对话状态、任务中间步骤、近几分钟到几小时内的动作。长期记忆（异步持久化）：保存提炼后的洞见、用户偏好和历史事实。它依赖向量数据库和知识图谱，采用异步更新，使智能体的核心“理解”随着时间推移不断增长，又不会拖慢实时检索路径。