智能体上下文管理：记忆与成本的架构设计指南

从提示工程到上下文架构

随着大语言模型（LLM）驱动的智能体（Agent）应用逐渐从演示走向生产环境，一个曾被忽视的问题正浮出水面：上下文管理已经成为一个真正的架构问题，而非简单的提示词技巧。

在早期的 LLM 应用中，开发者关注的核心是「提示工程」（Prompt Engineering）——如何写出更好的指令让模型输出更优质的结果。但当我们进入智能体时代，Agent 需要在多轮交互中持续推理、调用工具、维护状态，上下文（Context）的规模呈爆炸式增长。此时，如何管理这些上下文，直接决定了系统的记忆能力、响应质量和运行成本。

社区关于「Agentic Context Management」的讨论，正是切中了这一痛点：记忆（Memory）和成本（Cost）本质上都是架构层面需要解决的工程难题。

为什么上下文会成为智能体的核心瓶颈

上下文窗口的物理限制

尽管 GPT-4、Claude 等模型的上下文窗口不断扩大（从 4K 到 128K 甚至上百万 token），但这并不意味着「无限记忆」。上下文窗口越大，单次推理的计算开销和 API 调用成本就越高。一个持续运行的智能体，如果每一步都携带完整的历史对话和工具调用记录，token 消耗将呈线性甚至指数级增长。

从底层机制来看，这源于 Transformer 架构中自注意力机制（Self-Attention）的计算特性。标准的自注意力计算复杂度为 O(n²)，其中 n 是序列长度——这意味着上下文每翻一倍，计算量将增长四倍。虽然后续出现了 FlashAttention、Ring Attention 等工程优化手段，以及线性注意力等架构创新，但计算成本随上下文增长的基本趋势并未改变。这也是为什么各大模型服务商对长上下文调用收取显著更高费用的根本原因。

更关键的是，研究已经反复证明「上下文中间迷失」（Lost in the Middle）现象：即便模型能接收超长上下文，它对上下文中部信息的关注度会显著下降。这一现象最早由斯坦福大学的研究团队在 2023 年系统性验证——他们发现，当关键信息放置在长文档的中间位置时，模型的检索准确率可能下降超过 20 个百分点。这与注意力机制的位置编码方式有关：模型对序列起始和末尾的信息存在天然的「位置偏好」。因此，简单地把所有历史信息塞进上下文窗口，既不经济，也不高效。

记忆不等于全量存储

真正的挑战在于：智能体需要「记住」有用的信息，同时「遗忘」无关的噪声。这与人类的记忆机制类似——我们不会记住每一次对话的每一个字，而是提取关键信息、抽象成经验并按需检索。

从认知科学的角度看，人类记忆系统由多个子系统协同工作：感觉记忆仅保持数秒，短期（工作）记忆容量约为 7±2 个信息块，而长期记忆则通过「编码-存储-检索」的三阶段过程实现近乎无限的持久化。更重要的是，人类大脑具备强大的「遗忘」能力——这不是缺陷，而是过滤噪声、保留本质的自适应机制。智能体系统的记忆架构设计，本质上是在计算系统中模拟这种认知层次结构。

将这种能力工程化，就意味着我们需要设计一套完整的记忆架构，而不是依赖模型自身的上下文窗口来「暴力记忆」。在实践中，这通常结合了检索增强生成（RAG，Retrieval-Augmented Generation）的思想——将信息存储在外部系统中，在需要时通过语义检索召回最相关的片段注入上下文。RAG 的核心优势在于将「存储」与「推理」解耦：模型不再需要在参数中记住所有知识，也不需要将所有信息塞进上下文窗口，而是通过一个高效的检索层按需获取。

分层记忆架构：智能体记忆的核心设计模式

三层记忆模型

成熟的智能体系统通常采用分层记忆架构，将记忆按生命周期和用途划分：

工作记忆（Working Memory）：当前任务的即时上下文，直接进入模型的推理窗口。它对应着模型单次调用时实际「看到」的所有 token，包括系统提示、当前用户输入、最近几轮对话以及工具调用结果。工作记忆的容量就是模型的上下文窗口大小，是整个系统中最昂贵的「不动产」。
短期记忆（Short-term Memory）：近期几轮对话的摘要，需要时可召回。短期记忆通常以结构化摘要或关键事实列表的形式存在，驻留在应用层的内存或轻量数据库中，生命周期与单次会话或任务绑定。
长期记忆（Long-term Memory）：通过向量数据库存储的知识与经验，按语义相似度检索。

向量数据库（如 Pinecone、Weaviate、Milvus、Chroma 等）是长期记忆层的核心基础设施。其工作原理是：将文本通过嵌入模型（Embedding Model）转化为高维向量表示，存储在专门优化的索引结构中（如 HNSW、IVF 等近似最近邻算法）。检索时，将查询同样转化为向量，通过余弦相似度或内积等度量找到语义最接近的历史片段。这种语义检索能力使得即使用户使用不同的措辞表达相同的意图，系统也能准确召回相关记忆——这远超传统关键词检索的能力边界。

这种分层设计的核心思想是：只把当前推理真正需要的信息放进昂贵的上下文窗口，其余信息则存放在成本更低的外部存储中，按需检索。

上下文压缩与摘要技术

另一个关键技术是上下文压缩。当历史对话过长时，系统可以调用一个轻量模型（或同一模型）对早期内容进行摘要，用几百 token 的摘要替代数千 token 的原始记录。这既保留了核心信息，又大幅降低了后续推理的成本。

从技术实现角度看，上下文压缩主要有两种路径：抽取式摘要（从原文中选取关键句子）和生成式摘要（由模型重新组织语言生成简洁表述）。在智能体场景中，生成式摘要更为常见，因为它能够跨多轮对话合并信息、消除冗余并保持语义连贯。更高级的实现采用递归摘要策略：随着对话推进，系统会对已有摘要再次摘要，形成金字塔式的信息压缩层次。例如，最近 5 轮对话保持原文，5-20 轮压缩为一级摘要，20 轮以前压缩为二级摘要——每一层都在信息密度和计算成本之间取得不同的平衡点。

说个细节，摘要本身也存在信息损失的风险，因此需要在「压缩率」和「信息保真度」之间做出权衡——这正是架构设计的艺术所在。实践中的一个有效策略是「选择性保留」：系统在压缩时识别并保留高价值信息（如用户明确表达的偏好、关键决策节点、数字和日期等），即使在高压缩率下也确保这些信息不被丢失。

Token 成本优化：成本感知的架构策略

Token 经济学分析

在生产环境中，LLM 的调用成本与 token 数量直接挂钩。一个设计不良的智能体，可能在完成一个简单任务时消耗数万 token，累积起来的成本相当惊人。以 GPT-4 级别的模型为例，输入 token 的价格通常是输出 token 的数倍之低，但一个携带冗长历史上下文的智能体，其输入 token 消耗可能是输出的 10-50 倍——这意味着上下文管理直接决定了 80% 以上的运行成本。因此，「成本感知」（Cost-aware）的架构设计变得至关重要。

具体策略包括：

模型分级调用：简单的任务（如意图分类、摘要生成）交给便宜的小模型，只有复杂推理才调用旗舰模型。这种「路由」策略在实践中可以将总成本降低 60-80%，同时几乎不影响最终输出质量。常见的分级架构是：用 GPT-4o-mini 或 Claude Haiku 等轻量模型处理分类、提取、格式化等「苦力活」，仅在需要复杂推理、创造性生成或关键决策时才调用 GPT-4o 或 Claude Sonnet 等旗舰模型。
缓存机制：对重复出现的上下文（如系统提示、工具定义）利用 Prompt Caching，避免重复计费。Prompt Caching 是各大 LLM 服务商近期推出的重要成本优化特性。其原理是：当多次 API 调用共享相同的前缀内容（如固定的系统提示和工具定义）时，服务商在首次处理后缓存该前缀的 KV Cache（键值缓存，即注意力计算的中间结果），后续请求命中缓存时只需为新增部分付费。以 Anthropic 的实现为例，缓存命中的 token 费用仅为正常输入的 10%，对于系统提示动辄数千 token 的智能体系统来说，这意味着巨大的成本节约。OpenAI 的类似机制则自动对相同前缀进行缓存，开发者无需额外操作。
上下文裁剪：动态判断哪些历史信息对当前任务无关，主动移除以节省 token。

延迟与成本的平衡

成本不仅体现在金钱上，也体现在延迟上。上下文越长，模型的处理时间越长，用户体验越差。具体而言，LLM 的推理过程分为两个阶段：「预填充」（Prefill）阶段处理所有输入 token，「解码」（Decode）阶段逐个生成输出 token。预填充阶段的延迟与输入长度近似线性相关，这意味着一个携带 50K token 上下文的请求，仅在开始生成第一个字之前就可能等待数秒。因此，优秀的上下文管理架构必须在成本、延迟和质量三者之间找到动态平衡点。

在实践中，这种平衡往往通过设置「上下文预算」来实现：为每次模型调用设定 token 上限，然后在这个预算内通过优先级排序决定哪些信息最值得被包含。这类似于操作系统中的内存管理——有限的资源需要通过智能的调度策略来最大化利用效率。

走向工程化的智能体系统

这场讨论的深层意义在于，它标志着 LLM 应用开发正在从「炼丹」走向「工程」。早期我们更多依赖直觉调整提示词，而现在，我们需要像设计传统软件系统一样，认真对待智能体的记忆管理、状态存储和资源调度。

可以预见，未来将出现更多专门的上下文管理中间件和框架，把分层记忆、上下文压缩、成本控制等能力抽象为可复用的基础设施，就像数据库和缓存系统之于传统 Web 应用一样。事实上，这一趋势已经初现端倪：LangChain 和 LlamaIndex 等框架已经提供了记忆模块的基础抽象；Mem0 等专门的记忆层服务正在兴起；MemGPT（现更名为 Letta）提出了将操作系统的虚拟内存概念应用于 LLM 上下文管理的创新范式——通过在主内存（上下文窗口）和外部存储之间自动「换页」，实现理论上无限的记忆容量。此外，像 Zep 这样的项目专注于提供生产级的对话记忆基础设施，包括自动摘要、实体提取和时序记忆等能力。

对于正在构建智能体产品的团队来说，这意味着一个重要的启示：不要把上下文管理当成事后优化，而应当从架构设计的第一天就将其纳入考量。 记忆和成本，从来都不是模型能力问题，而是实实在在的系统设计问题。