Agent —— 记忆、知识与上下文
#Agent

一个没有记忆的 Agent 在每次对话开始时都是”失忆”的——它不记得用户是谁、之前聊过什么、曾经查到什么。记忆系统和知识检索是让 Agent 从”有用”升级到”真正有价值”的关键。

一、为什么 Agent 需要外部记忆

LLM 的参数（权重）中包含了训练数据的”泛化知识”，但有三个根本缺陷：

1. 训练数据截止：LLM 不知道训练截止日期之后发生的事情，也不知道你的私有数据。

2. 上下文窗口有限：即使是 1M Token 的上下文，也无法容纳一个组织多年积累的所有知识。

3. 无状态性：每次新的对话，LLM 不记得上次说了什么，除非显式地把历史信息塞入上下文。

外部记忆系统解决了这三个问题：持续更新（解决截止问题）、按需检索（解决容量问题）、跨会话存储（解决无状态问题）。

二、四种记忆类型

认知科学对人类记忆系统的分类，为 Agent 记忆设计提供了很好的参照：

人类记忆类型 对应 Agent 记忆 存储位置 特点
工作记忆（即时处理） Context Window LLM 的上下文 快速访问，容量有限，对话结束即消失
情节记忆（事件历史） Conversation History / Event Log 外部数据库 记录”发生了什么”，按时间组织
语义记忆（知识概念） Knowledge Base / Vector Store 向量数据库 记录”事实是什么”，按语义检索
程序记忆（技能行为） Tool Definitions / Skills 代码/配置 记录”怎么做”，以工具或工作流形式固化

2.1 工作记忆（Context Window）

这是 LLM 的”RAM”，处理当前任务的所有信息都在这里。

Context Engineering 的核心工作就是管理好工作记忆：哪些历史信息值得保留（不能全塞进去，成本太高），哪些信息需要从外部检索后再注入，哪些信息可以压缩摘要后再保留。

2.2 情节记忆（事件历史）

记录 Agent 经历过的事件序列：与用户的对话历史、执行过的工具调用、观察到的结果。

实现方式：数据库（每条记录包含 timestamp、role、content）。挑战：历史越积越长，全部塞入上下文会撑爆 Token 限制。解决方案：

  • 窗口截断：只保留最近 N 轮对话
  • 摘要压缩：定期将旧对话压缩为摘要，保留摘要而不是原文
  • 关键事件标记：只保留被标记为”重要”的事件

2.3 语义记忆（知识库）

存储结构化或非结构化的知识，通过语义相似度检索而非精确匹配。这是 RAG 系统的核心。

2.4 程序记忆（技能/工具）

Agent 能做什么，是以工具定义、工作流模板、技能描述的形式固化的。当 Agent 学会了一种新的处理模式，将其固化为可复用的工具，就是在扩展自己的”程序记忆”。

OpenClaw 的 SOUL.md 和 nanobot 的 Skills 系统都是程序记忆的具体体现：将 Agent 的行为偏好和能力以配置文件的形式持久化。

三、RAG：检索增强生成

RAG（Retrieval-Augmented Generation）是目前解决”LLM 不知道私有数据”问题的主流方案。

3.1 工作原理

RAG 的核心流程分为两个阶段：

离线阶段（建库）：

1
2
3
4
5
6
7
原始文档（PDF/Word/网页...）
    ↓ 分块（Chunking）
若干文本片段（Chunk）
    ↓ Embedding 模型
向量表示（Dense Vector）
    ↓ 存入
向量数据库（Pinecone/Weaviate/Chroma/pgvector...）

在线阶段（检索+生成）：

1
2
3
4
5
6
7
8
9
用户问题
    ↓ Embedding 模型
问题的向量表示
    ↓ 相似度检索（余弦相似度/点积）
Top-K 相关文本片段
    ↓ 注入 Prompt
LLM（上下文 = 问题 + 检索到的知识）
    ↓
基于真实知识的回答

3.2 关键技术细节

Embedding（嵌入）：将文本转化为高维向量，语义相近的文本在向量空间中距离更近。这是 RAG 能做语义检索而非关键词匹配的根本。常用 Embedding 模型：OpenAI text-embedding-3-small、bge-m3（开源）。

Chunking（分块）策略：

  • 固定长度：简单，但可能切断句子
  • 按句子/段落：保留语义完整性
  • 层次化分块：大块用于检索，小块用于精确匹配
  • 语义分块：用 LLM 识别语义边界再切割

分块大小的权衡：块越小，检索越精准，但丢失上下文；块越大，包含完整上下文，但相关性得分可能被噪声稀释。

检索策略：

策略 原理 优点 缺点
稀疏检索（BM25） 关键词频率匹配 精确匹配，快速 无法理解语义，同义词失效
密集检索（Embedding） 向量相似度 语义理解，泛化好 可能遗漏精确关键词
混合检索（Hybrid） BM25 + Embedding 融合 兼顾精确和语义 实现较复杂

生产环境推荐混合检索：先用 BM25 做初排，再用 Embedding 做重排（Reranking）。

3.3 RAG 常见失效模式

检索到的内容不相关：Chunking 策略不当，或 Embedding 模型语义理解不足。解法：优化分块，引入 Reranker 模型过滤。

检索到的内容正确但 LLM 未使用：检索内容和问题的融合方式有问题，或内容位于”迷失在中间”的上下文位置。解法：优化 Prompt 结构，将最相关内容放在开头。

知识库内容本身过时：文档未及时更新。解法：建立文档版本管理和定期重建索引的机制。

四、Agentic RAG：让 Agent 主动检索

标准 RAG 是被动的：每次问答固定执行一次检索。Agentic RAG 让 Agent 自主决定检索的时机、对象和深度。

4.1 与标准 RAG 的差异

维度 标准 RAG Agentic RAG
检索时机 每次问答自动触发 Agent 判断是否需要检索
检索次数 固定一次 可多次，按需触发
检索内容 基于原始问题 可基于中间推理结果再检索
路由决策 无 Agent 判断查哪个知识源

4.2 Agentic RAG 的典型模式

多步检索（Multi-hop Retrieval）：

1
2
3
4
问题：A 公司的 CEO 最近参加了什么峰会？
→ 检索 1：找 A 公司 CEO 是谁（答：张三）
→ 检索 2：查张三最近的活动
→ 综合两次检索结果给出答案

自适应路由：Agent 根据问题类型决定查哪个数据源——技术问题查内部文档，市场问题查外部新闻，财务问题查财报数据库。

检索-验证循环：检索结果返回后，Agent 判断信息是否足够回答问题，不够则继续检索，够了则生成答案。

五、GraphRAG：知识图谱增强检索

问题背景：标准 RAG 擅长找”与问题直接相关的片段”，但对需要全局理解的问题效果差。例如：”这份报告的整体结论是什么？” 无法通过检索单个片段回答。

GraphRAG（微软 2024 年提出）的解决思路：先用 LLM 从文档中抽取实体和关系，构建知识图谱；检索时沿图谱的关系路径检索相关节点，而不是简单的向量相似度匹配。

优点：能够回答需要跨多个文档、跨多个实体进行推理的问题。
缺点：构建图谱的成本高（LLM 密集计算），图谱更新比向量库更复杂。

适用场景：大型语料库的全局分析（如分析一份完整的法律文件、企业全量文档）；需要多跳推理的问题。

六、长上下文 vs RAG：判断框架

随着 LLM 的上下文窗口扩展到 100K-1M Token，一个新问题出现了：是否还需要 RAG？能不能直接把所有文档塞进上下文？

选择长上下文的条件：

  • 文档总量可控（几十万 Token 以内）
  • 需要全局理解和跨文档推理
  • 内容相对静态，不需要频繁更新
  • 对精确性要求高（不能有遗漏）
  • 可以接受更高的成本和延迟

选择 RAG 的条件：

  • 知识库体量大（GB 级别）
  • 内容频繁更新（实时数据）
  • 大多数问题只需要文档的一小部分
  • 对成本和延迟敏感

两者结合（Agentic RAG + 长上下文）的条件：

  • 大型知识库（用 RAG 做初筛）
  • 检索到的相关内容再做长上下文精读
  • 对回答质量要求极高

结论：长上下文不会取代 RAG，而是改变了 RAG 的应用边界。RAG 处理”从大量文档中找到少量相关内容”的问题，长上下文处理”对有限内容做深度理解”的问题。

七、总结

概念 核心要点
四种记忆类型 工作(Context)/情节(历史)/语义(知识库)/程序(工具)
RAG 工作原理 离线建库（分块→Embedding→向量存储）+ 在线检索（语义搜索→注入上下文）
检索策略 BM25（关键词）+ Embedding（语义）+ Hybrid（混合，生产推荐）
Agentic RAG Agent 自主决定何时检索、检索什么、检索几次
GraphRAG 用知识图谱增强全局推理能力，解决传统 RAG 的碎片化问题
长上下文 vs RAG 不是替代，是互补：大量文档用 RAG 筛选，有限内容用长上下文精读

下一篇：如何让 Agent 在生产环境中稳定、安全、可调试——自主性与可控性的权衡、Human-in-the-loop 设计、可观测性工具与安全防护。

Prev
#Agent
Next