上下文与记忆：智能体信息机制对比解析

一、为什么需要区分上下文与记忆

在智能体开发中，一个常见的误区是把“喂给模型的内容”和“模型真正记住的内容”混为一谈。实际上，两者在生命周期、存储位置、成本结构和访问机制上存在本质差异。理解这种差异，是设计稳定、可维护且成本可控的智能体系统的前提。

智能体每处理一次请求，都会经历一个信息组装过程。模型在这个过程里看到的不是某个单一数据源，而是由多个层次拼接起来的完整视图。与此同时，模型还可以通过专门的工具去检索长期存储的信息。前者是上下文，后者是记忆。二者协同工作，但职责边界清晰。

如果不加区分地把所有内容都塞进上下文，会导致 token 消耗快速上升、响应变慢，甚至超出上下文窗口限制；反之，如果所有信息都只写入记忆而不进入上下文，模型可能无法在关键推理时刻获取必要信息。因此，开发者需要在两者之间做出合理分配。

二、上下文是怎么拼出来的

每次请求发出之前，智能体框架会按照一定顺序组装模型可见的内容。一个典型的结构如下：

[0] 系统提示词
    - 静态规则
    - 条件指令
    - 能力边界与工具声明
[1] 项目上下文
    - 启动文件与项目级配置
    - 用户可编辑的 Markdown 文件
    - 与当前工作目录绑定的指导信息
[2] 对话历史
    - 消息记录
    - 工具调用记录
    - 压缩摘要
[3] 当前消息
    - 用户本次输入
    - 附件或引用内容

其中，系统提示词决定了智能体的能力边界和可调用工具范围。它通常是静态的，但也可以根据条件动态插入指令。

项目上下文是与记忆关系最密切的一层。它会把一组用户可编辑的文件注入到每一次请求中。常见文件及其作用如下：

文件	作用
AGENTS.md	智能体指令，包括与记忆相关的规则
SOUL.md	性格与语气风格
USER.md	关于用户的信息
TOOLS.md	外部工具使用指南

这些文件与记忆文件一起存放在智能体的工作目录中，因此整个智能体的配置是透明、可见、可编辑的。开发者可以直接查看和修改这些文件，而不需要依赖黑盒配置界面。

三、上下文与记忆的边界

上下文是模型在单次请求里能够看到的一切。它的组成可以概括为：

上下文 = 系统提示词 + 对话历史 + 工具结果 + 附件

上下文具有三个显著特征：

短暂性。 上下文只为当前这一次请求存在。请求结束后，这些内容不会自动保留为长期状态。下一轮请求需要重新组装上下文。

有限性。 上下文受模型上下文窗口的硬限制，例如常见的 200K tokens 上限。当拼接内容接近或超过这个限制时，框架通常需要截断、压缩或丢弃部分内容。

成本敏感性。 上下文中的每个 token 都会影响 API 调用成本与响应速度。长上下文不仅增加费用，还可能导致首字延迟上升。

记忆则是写入磁盘的内容。它的组成可以概括为：

记忆 = 结构化记忆文件 + 分类记忆目录 + 会话转录

记忆的特征与上下文形成鲜明对比：

持久性。 记忆写入磁盘后，即使智能体重启也不会丢失，可以跨天、跨月持续积累。

可扩展性。 记忆总量不受单次上下文窗口限制，理论上可以持续增长。

低成本。 记忆存储在本地，不增加 API 调用成本。即使记忆量很大，也不会直接推高模型调用费用。

可检索性。 记忆文件会被索引，支持语义检索。模型可以在需要时按相关性查找，而不是完整加载全部记忆。

简单来说：上下文是模型“此刻正在看的内容”，记忆是模型“可以查的内容”。 前者受限于窗口大小，后者受限于检索质量。

四、记忆工具的工作方式

智能体通常通过专门的工具来访问记忆，而不是直接读取所有记忆文件。一个典型的记忆检索工具定义如下：

{
  "name": "memory_search",
  "description": "强制回忆步骤：在回答有关过去工作、用户偏好或项目细节的问题前，先检索相关记忆内容"
}

这个工具的工作逻辑是：模型根据当前问题生成查询，工具在所有记忆文件中执行语义检索，返回最相关的片段，模型再基于这些片段组织回答。

这种“检索—注入—回答”的模式，本质上是在不扩大上下文窗口的前提下，让模型获得超出当前对话范围的信息。关键设计点在于：

1. 强制调用。 工具描述中明确要求模型在特定场景下必须先调用检索，避免模型仅凭“记忆中的印象”回答。
2. 语义匹配。 检索不是简单关键词匹配，而是基于语义相似度，能够处理表述不同但含义相近的查询。
3. 按需注入。 只有检索结果会被注入当前上下文，记忆文件本身不会全量进入上下文。

五、核心差异对比

维度	上下文	记忆
生命周期	单次请求	跨请求、跨会话、跨天
存储位置	请求组装时临时存在	磁盘文件
容量限制	受上下文窗口限制	理论上可无限增长
成本	每个 token 都计费	存储与检索不增加 API 成本
访问方式	自动全量可见	按需检索后注入
内容更新	每次请求重新组装	增量写入、持续累积
丢失风险	请求结束即失效	除非手动删除，否则保留
主要用途	当前任务推理	长期知识、用户偏好、历史决策

六、典型场景选择

适合放入上下文的场景：

• 当前任务的直接输入与中间推理结果
• 工具调用的返回数据
• 本轮对话中已经确认的信息
• 短期指令与临时约束
• 需要模型完整通读才能正确理解的任务背景

适合写入记忆的场景：

• 用户长期偏好与习惯
• 跨会话的项目背景与决策记录
• 已经完成的工作与结论
• 需要在未来任务中复用的经验
• 不适合反复拼接到上下文的大块参考内容

一个实用的判断标准是：如果某条信息只在当前任务内有用，放上下文；如果它可能在未来的任务中再次被用到，写入记忆。

七、选型建议

在实际设计中，上下文与记忆不是二选一，而是分层协同。

上下文承担“工作台”的角色。 它保证模型在处理当前请求时拥有足够的即时信息，支持连续推理和工具调用链。

记忆承担“档案库”的角色。 它保证模型能够跨时间积累知识，在需要时通过检索获取历史信息。

合理的设计应当遵循以下原则：

1. 控制上下文规模。 只把当前任务必需的上下文放入窗口，减少无效 token 消耗。
2. 将长期价值内容下沉到记忆。 当对话中产生了对未来有复用价值的信息时，主动触发记忆写入。
3. 用检索替代全量加载。 当记忆量增长后，依靠语义检索按需获取，而不是将全部记忆注入上下文。
4. 保持记忆文件可编辑。 将记忆以 Markdown 等透明格式存放，方便人工审核、修正和清理。

八、迁移与使用注意事项

如果从“全量拼接上下文”的模式切换到“上下文加记忆检索”的模式，需要注意以下几点：

检索质量。 语义检索的效果直接影响模型能否找到正确信息。检索结果不准确时，模型可能基于错误或无关的片段回答。需要持续优化索引策略和文件组织方式。

信息冲突。 记忆文件中可能存在过期或矛盾的内容。当检索到的旧信息与当前上下文冲突时，模型需要有明确的优先级规则来判断以哪个为准。

记忆膨胀。 虽然记忆不受窗口限制，但无节制写入会导致检索精度下降。需要建立记忆清理和汇总机制，定期合并重复内容、删除过时信息。

写入时机。 不是所有对话内容都值得写入记忆。写入策略需要区分“临时信息”和“长期有价值信息”，避免将噪声引入记忆库。

人工可干预性。 记忆文件应保持透明和可编辑。用户和开发者需要能够查看、修改甚至清空记忆，确保对智能体长期行为的控制权。

九、总结

上下文与记忆的差异，本质上是“临时工作状态”与“持久知识存储”的差异。上下文决定模型在当前请求中能利用多少即时信息，记忆决定模型能跨越时间积累多少可复用知识。

上下文短暂、有限、昂贵，但直接参与推理；记忆持久、可扩展、低成本，但需要通过检索才能发挥作用。二者以“上下文负责当前任务，记忆负责长期复用”的方式协同，共同支撑智能体在复杂、长期场景下的稳定表现。

开发者需要根据信息的时效性、复用价值和成本敏感度，在上下文与记忆之间做出合理分配。核心决策思路始终是：当前必须用的进上下文，未来可能用的进记忆，两者都不需要的就不要保留。