2026-11-09 19:05:07 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

看懂 AI Agent 的记忆与知识库：对话结束之后，它怎么继续记住你

原创

取证猎人
取证猎人

Hunter取证

2026年11月8日 10:15
四川

去阅读

上一章解决的是一次任务之内的上下文管理：每一轮调用模型时，把哪些信息递到它面前、怎么摆。这一章往前走一步，处理一个更难的问题：对话结束之后，Agent 怎么仍然记住你、记住知识。

要先承认一个朴素的事实：

大模型 API 本身是无状态的，上一轮聊过什么，这一轮默认全部清空。

想让它跨对话提供个性化服务，

就必须在模型之外建一层持久化的记忆体系。这一层体系可以从两个尺度来理解。

用户记忆是针对单个用户的个性化记忆：

在与每位用户的交互中逐渐了解其偏好、习惯和需求，构建专属于这个人的知识模型，让 Agent 成为\"懂你的助手\"。

知识库是面向所有用户共享的集体知识：

一个行业的法规体系、一家公司的内部流程、一个技术领域的专业文档，让 Agent 成为\"领域专家\"。

两者解决的其实是同一个问题，只是尺度不同——

一个关注个体，一个关注群体；也正因为如此，它们共用向量检索、知识压缩等底层技术，也面临同样的麻烦：信息冲突、知识过期、检索不准。

01记忆不是把每句话都存下来：提取、压缩与审查

先想清楚记忆系统到底存什么。如果把每一句对话都原样保存，对话稍长就会堆积成一座信息大山，真正有用的事实反而被埋在里面。因此用户记忆并不保存每句对话，而是用额外的模型调用，从对话里提取、压缩并审查那些对未来有用的事实。

看一个订机票的例子。用户说\"下周五帮我订去东京的航班，我喜欢靠窗座位，我是素食者，需要特殊餐\"；之后又说\"好，就订这班，用我的 United 常旅客号 12345678\"。对话结束后，框架调用一次专门的模型分析这段对话，提取出四条值得长期记住的信息：

用户偏好靠窗座位（偏好）；
用户是素食者，乘机需要特殊餐食（饮食限制）；
用户的 United 常旅客号是 12345678（会员信息）；
用户近期有去东京的出行计划（近期活动）。

提取结果同时遵循三条规则。

选择性：丢弃\"搜索返回了 3 个选项\"这类只对本次流程有用的短期细节；

抽象化：把本次选择靠窗座位，归纳成一条长期偏好，而不是只记下这一次行为；

结构化：用可以检索的字段把事实保存下来，而不是留在一段原始对话里。

一句话复述：记忆系统做的不是\"录音存档\"，而是每次对话结束后，挑出长期有用的事实，提炼成稳定、可查找的条目。

02记忆能力分三层：从记住一条事实，到提前替你想到

动手设计记忆系统之前，先要立一把标尺：什么样的记忆系统算\"好\"。综合各类记忆基准和商业产品的实践，可以把记忆能力划成三个递进层级，后面讨论各种设计方案时都用这把尺子衡量。

第一层：基础回忆。这是最根本的能力——准确存储和检索用户直接提供的、结构化、无歧义的信息。比如\"我的会员号是 12345\"，后续需要时能精确返回。这一层保证记忆系统基本可靠，是更复杂能力的地基。

第二层：多会话检索。面对来自不同对象、不同时期的多段会话，能检索出所有相关信息并做出推理判断。真实交互往往不是一次完成的：用户在不同渠道、不同时间分别说过一些事。拥有两辆车的用户要求\"给我的车预约保养\"时，系统需要找出两辆车的全部信息，并主动询问是哪一辆，而不是随便猜一辆；询问贷款状态时，要分辨正在履行的有效合同，忽略过去咨询过但未生效的报价；取消\"洛杉矶之旅\"时，要理解旅行是复合事件，主动关联机票和酒店所有相关预订。

第三层：主动服务。这是衡量 Agent 是否达到\"助理\"水准的最高标准：综合来自多个会话、甚至很久以前的信息，提供有预见性的主动帮助，从看似无关的记忆里发现深层联系。预订国际航班时，主动关联数月前存下的护照信息，发现即将过期并发出预警；手机损坏时，主动整合所有保障方案（手机自带保修、信用卡附加保修、运营商保险），给出完整的选项列表；报税季主动从过去一年的记录里搜寻并整合所有税务文件（股票销售、自由职业收入、房产税），列出完整待办清单。这一层要求系统在没有明确指令的情况下，主动规避潜在问题、整合复杂信息。

三层之间的差距可以这样记：记住一条事实是第一层，把散落各处的相关信息拼起来是第二层，从看似无关的记忆里发现联系、提前替你想到，是第三层。

03记忆放在哪里、怎么存：层次结构与四种格式

记忆系统的设计可以拆成三个独立维度：放哪里、怎么存、存什么。先回答放哪里。

为了既能高效处理当前任务，又能跨会话提供个性化服务，记忆需要分成不同层次，就像人有短期工作记忆和长期记忆之分。

轨迹（Trajectory）

：一次运行过程中的完整历史记录——用户消息、模型回复、工具执行结果，按时间顺序排列，只增不改，新事件不断追加到末尾。它为当前决策提供即时上下文：\"我刚才说了什么\"\"用户怎么回应\"\"工具返回了什么\"。
* 用户长期记忆

：跨会话、跨实例持久化存储，通常以键值对形式绑定到特定用户 ID，存放偏好设置、历史交互摘要和提取出的知识点，会被反复改写、合并、淘汰。
* 业务状态

：开发者定义的高层状态抽象，表示任务当前阶段，比如\"需要澄清\"\"处理请求中\"\"等待付款\"\"请求完成\"。

两者的区别很直白：轨迹是流水账，长期记忆是档案。

流水账按时间记全、不改写；档案经过提炼，可以更新和淘汰。

接着是怎么存。同一条用户信息，可以用不同粒度和结构表示。下面四种格式从简单走向复杂，简单性递减、表达力递增。

Simple Notes（简单笔记）

：每条记忆是一个最小的、不可再分的事实，比如\"用户邮箱：[email protected]\"。开销极低，检索耗时固定、不随数据量增长；代价是信息关联性完全丢失——\"在 TechCorp 担任高级工程师、负责推荐系统开发\"被拆成三个独立事实后，同一份工作的内在联系被割裂，需要综合多条信息回答时得重新拼凑碎片。
* Enhanced Notes（增强笔记）

：把每条记忆保存为带完整上下文的段落，比如\"用户在 TechCorp 担任高级软件工程师，专注机器学习已有三年，目前领导一个推荐系统项目，团队 5 人\"。叙事结构完整、语义丰富；代价是存储冗余、更新复杂（属性变化要重写多个段落），长段落也不好检索。
* JSON Cards（结构化卡片）

：三层嵌套，类别→子类别→键值对，比如 personal.contact.email、work.position.title。支持部分更新，改职位不影响公司字段；但刚性结构假设信息都能清晰分类——\"周末用 Python 开发个人项目\"同时涉及时间偏好、技术偏好和活动类型，硬塞进单一类别会丢失多维性。
* Advanced JSON Cards（进阶卡片）

：不仅记录事实，还加入信息来源的叙事背景（backstory）、主体身份（person）、与用户的关系（relationship）和时间戳。核心想法是：同一条信息在不同场景下含义可能完全不同——\"张医生\"可能是用户自己的牙科医生，也可能是用户父亲的心脏科医生，脱离情境就无法正确理解。它解决了消歧问题：用户说\"帮我安排家人的年度体检\"，系统能通过关系识别所有家庭成员，通过背景了解健康历史；代价是生成和维护成本较高。

实践中的取舍标准是：关键且少量的数据（用户偏好、关键人物关系）用 Advanced JSON Cards 保证可检索性；大量且非关键的对话事实用 Simple Notes 降低成本；多数生产系统采用混合模式，同一 Agent 内不同类别的信息走不同路径。

最后一个维度是存什么。参照认知科学的分类，

长期记忆可分为三种：

情景记忆是具体事件和经历，比如\"用户订了下周五去东京的 ANA 航班\"；

语义记忆是从事件中抽象出的一般知识，比如\"用户是素食者\"\"偏好靠窗座位\"；

程序记忆是行为模式和流程，比如\"先搜直飞航班→确认座位偏好→使用常旅客号码→订餐\"。三套分类体系是正交的维度，可以自由组合：一条语义记忆可以用简单笔记存在长期记忆里，一段程序记忆也可以用进阶卡片保存。

还有一种更进一步的形态叫可执行代码：

把用户状态改成带类型的可执行对象，把规则写成普通函数，表示和推理使用同一种可验证介质。聚合统计、冲突发现、约束执行这类原本要模型\"读一遍再心算\"的操作，交给确定性函数完成；事实先追加到只增日志，再定期从完整日志重建带类型的状态，既保留原始证据，也得到可查询、可执行的派生状态。

04记忆怎么整理、怎么守住隐私：压缩、冲突与脱敏

随着交互持续进行，简单累积式存储会导致\"记忆爆炸\"：既消耗存储空间，又降低检索准确性。实践中可以用多层次压缩策略。

第一层是重要性评分筛选。综合四个因素打分：访问频率（经常被检索的记忆更重要）、时间衰减（越久远越容易被遗忘）、情感强度（带强烈情感标记的更易保留）、信息独特性（重复信息重要性降低）；低于阈值的标记为可压缩或可删除。一条被访问 5 次、创建于 3 天前、带强情感标记、无重复记录的记忆得分较高；一条仅被访问 1 次、创建于 90 天前、无情感标记、与其他 3 条高度重复的记忆，就可能低于压缩阈值。

第二层是聚类。相似记忆分成一组，每组生成代表性摘要，比如多次天气对话压缩为\"用户经常询问天气，特别关心降雨\"；原始详细记忆归档到二级存储。第三层是抽象和泛化：从具体情景记忆中提取一般性规律，转化为语义或程序记忆，比如从多次购物对话中学到\"偏好性价比高的产品，重视用户评价\"。

记忆之间出现矛盾时怎么处理？开源框架 Mem0 的演进提供了两种不同思路。早期版本把冲突处理放在写入阶段：对话结束后模型先抽取候选事实，再用检索找到相近的已有记忆，由模型在新增、更新、删除、保持原样之间做决定。用户先说\"我住在北京\"，后来又说\"搬到了上海\"，系统会把前一条更新为\"住在上海\"，在写入时消除冲突。

好处是记忆库始终简洁一致；风险是一次错误的更新或删除会不可逆地丢失历史信息，每条候选事实也要经历检索和第二次模型判断。新版本则改为仅追加写入、检索时再推理：一次模型调用抽取事实，只做新增；\"住在北京\"和\"搬到上海\"作为带时间信息的两条事实并存，查询时融合语义相似度、关键词、实体匹配和时间排序，找出当前有效的事实。这样既避免错误删除丢失历史，又减少了模型调用。

隐私是另一道必须守住的关口。记忆系统要利用用户信息提供个性化服务，又不能让敏感数据暴露在模型上下文和系统日志里。常见做法是用本地部署的小模型做日志脱敏：识别结构化信息（身份证号、银行卡号）、半结构化信息（地址）和自然语言表达的敏感内容（比如\"我的密码是 abc123\"），输出敏感类型、位置和置信度。选择本地部署而非云端 API 的原因很明确：日志本身可能包含敏感信息，发送到云端脱敏就违背了隐私保护的初衷。超高吞吐场景可以采用混合策略：正则先快速过滤明显模式，模型再深度分析剩余文本。

05知识库怎么建：RAG 管道与文档分块

前面关注的是记忆的表示和管理。当记忆量增长到成千上万条，怎么快速找到相关的那几条？这正是检索增强生成（Retrieval-Augmented Generation，RAG）要解决的核心问题，它既服务共享知识库，也会反过来增强用户记忆的检索能力。

RAG 的基本想法来自一个朴素的事实：模型训练数据有截止日期，而知识库可以随时更新。典型 RAG 系统由两部分构成：检索器从知识库里找出相关片段，生成器（通常是大模型）拿到这些片段作为上下文来生成答案。流程是固定的三步：检索相关片段→注入上下文→模型基于上下文生成答案。用户问\"我买的东西想退款，流程是什么\"，检索器召回退款政策和操作步骤两条片段，模型结合这些片段组织出回答。

在能够检索之前，还有一步不可或缺的离线预处理：文档分块（Chunking），把长文档切成适合独立检索的片段。分块必不可少，原因有二。其一，嵌入模型对输入长度有限制；一整篇文档只压缩成一个向量时，多个主题混在一起，向量无法精确表达任何一个主题——段落越长，嵌入越难抓住重点。其二，检索的目标是只把相关那部分注入上下文，片段太大会连带引入大量无关内容，浪费窗口、稀释注意力。

常见分块策略有三类。固定大小切分按固定 token 数切分，相邻块之间保留一定重叠，避免关键句子恰好在边界处被切断；实现简单、结果可预测，但完全无视文档结构，段落、代码、表格都可能被拦腰截断。递归/结构感知切分按文档自然边界（章节标题、段落、句子）递归切分，先尝试大边界，仍超长再降级到更小边界，是目前生产系统最常用的默认选择。语义切分计算相邻句子的嵌入相似度，在语义\"断崖\"处下刀，使每个块内部主题尽量单一；质量更高，代价是需要额外的嵌入计算。

块大小和重叠量是一对典型权衡：块太小，单块信息不完整，脱离上下文后语义变得模糊——\"该公司收入增长了 3%\"，哪家公司？哪个季度？块太大，一个块混杂多个主题，向量被稀释，检索精度下降，命中后还会带入更多无关内容。实践中的常见起点是每块 256–1024 token、相邻块重叠 10%–20%，再根据检索质量实测调优。

这里埋下一个伏笔：无论采用哪种策略，分块都会切断片段与原始上下文的联系——\"该公司\"指代谁、这段话出自哪份报告，这些信息留在了块外。这是分块的固有缺陷，后面会专门讲怎么修补。

06检索两条路线：稠密语义、稀疏关键词，再混合起来

分好块之后，检索器怎么判断一块内容和查询相关？有两条技术路线。

稠密嵌入：计算机只能处理数字，不能直接理解\"苹果\"和\"橙子\"的含义。嵌入的思路是把每个词或句子转化成一串数字（向量），并让语义相近的内容转化出来的数字串也相近。这些向量所在的数学空间可以想象成一张高维地图，每个词或句子都是其中一个点，语义越接近的内容彼此距离越近，如同北京和上海在地图上的位置反映地理相关性。

衡量两个向量有多近，常用余弦相似度：看两个向量的夹角，值越接近 1 表示方向越一致、语义越相似。之所以比方向而不比长度，是因为关心语义是否相近，而不是文本的长度或频率——两篇内容相同但长度不同的文档，向量长度不同但方向一致，余弦相似度仍能正确判断语义相同。

早期静态词向量只能捕捉词汇共现关系，且一词一向量，无法处理一词多义；现代上下文感知模型在生成一个词的向量时，会参考所在句子的全部其他词，同一个词在不同语境下得到不同向量：\"苹果公司发布新产品\"和\"买了两斤苹果\"里的苹果，向量表示并不相同。

稀疏嵌入：根植于传统信息检索，核心是精确的关键词匹配。文档被表示为极高维度的向量，绝大多数维度为零，只有出现词汇对应的维度有非零值。其理论基石是词袋模型：把一段文本看作装满词的袋子，只关心哪些词出现了、出现几次，忽略词序。

从 TF-IDF 到 BM25，直觉没有变：一个词在当前文档出现得越多、在整个语料库中越少见，它对检索越重要。假设 100 篇文章里有 60 篇包含\"模型\"，只有 3 篇包含\"蒸馏\"，那么\"蒸馏\"更能区分哪些文章真正与\"模型蒸馏\"相关。BM25 在这个直觉上做了两处经典修正：词频饱和——一个词出现 10 次通常不会比出现 5 次贡献整整两倍；长度归一化——相同词频在较长文档中的权重更低，避免长文档仅仅因为字数多而得分高。底层是倒排索引：从词直接找到所有包含它的文档，好比书后的术语索引页，查\"TCP\"就知道第 45、112、203 页提到过这个词。稀疏检索的短板也很明显：读不懂同义表达，查一个词只能匹配到字面相同的文档，搜\"kitty\"找不到只写了\"cat\"的文档。

图1：查询同时走稠密语义与稀疏关键词两路，融合后再由重排序精排出最终 Top-N（示意图）

两种方法各有盲区：稠密检索懂语义，但可能漏掉关键词（搜\"HTTP-403\"可能返回\"服务器错误\"的泛泛讨论）；稀疏检索精确匹配，但读不懂同义词。混合检索的思路很简单——两个引擎都跑，结果合并；难点在于如何把分布迥异的两组得分整合成一个有意义的排序。典型流水线分三阶段。

第一阶段并行检索，同时向稠密和稀疏两个引擎发送查询，各自召回一部分候选。第二阶段结果融合：两路得分不能直接比较，稠密的余弦得分通常在 0 到 1，稀疏的 BM25 得分可能是 0 到几十的任意值。常用的倒数排名融合（RRF）完全抛开原始得分、只看排名，每个文档的综合得分是它在各路结果中排名的平滑倒数之和，简单且稳健。第三阶段是神经重排序：换用一种更强的匹配范式，让跨编码器对查询和文档做深度交互匹配，对融合后排名靠前的若干候选逐一精确打分，产生最终排序。

这个分工可以用招聘类比：双编码器像猎头快速筛简历，依靠预先抽取的特征做大规模初筛，速度快但无法捕捉深层匹配；跨编码器像面试官与每位候选人深谈，把查询和候选文档拼接成一段完整文字送入模型，逐词比对后输出相关性得分，慢得多，但判断更准确。重排序并不替代融合：融合负责从两路结果中产生统一候选池，重排序负责在这个池子里精排。

衡量检索质量，最核心的指标有三个：召回率@k回答\"该找的找到了吗\"——包含正确答案的文档是否出现在前 k 个结果里；MRR（平均倒数排名）回答\"找到得够不够靠前\"——排第 1 得 1 分，排第 10 只得 0.1 分；nDCG综合考虑所有相关文档的排名与相关程度，回答\"整个排序列表的质量如何\"。实践结论很清楚：没有哪种单一检索策略在所有场景下都可靠，稠密、稀疏加重排序组合起来，才是生产级 RAG 的正确做法。

07知识怎么组织得更牢：结构化索引、文件范式与更新机制

前面的基础技术解决的是\"给定一个文本块，怎么快速找到最相关的几个\"。但一个更根本的问题是：这些文本块本身该怎么组织？把文档切成互不关联的扁平文本块，会丢掉知识固有的内在层次和跨文档关联；面对技术手册、法律文书、学术论文这类结构复杂、逻辑严谨的材料，只检索零散片段，就如同靠阅读字典的随机词条去理解一部小说。

两个案例能说明不加处理直接入库的风险。

其一，黑猫白猫计数问题：假设知识库有 100 个独立案例文档（90 只黑猫、10 只白猫），用户问\"比例是多少\"，受限于 top-k（比如 20），大部分案例根本不会被检索到，模型只能基于不完整样本得出错误结论；如果预先生成摘要\"共有 100 只猫：90 只黑猫、10 只白猫\"并索引，一次检索就能获得准确信息。

其二，优惠资格边界问题：几百条客服工单各自记录一个个案结论，没有一条写着资格范围本身。护士来问能不能享受优惠时，首先会遇到最近邻偏置——\"护士\"与\"医生\"语义最近，医生那条排在最前，模型顺势推断护士也可以；

其次是边界语义缺失，\"仅限某些职业、其他一律不适用\"这种带全称与否定的边界，不存在于任何单条工单中，调大 k 也解决不了；最后是完整性信号缺失，模型无从判断自己是否看全，不会追问，只照着手里几条自信作答。解决办法仍然要从索引阶段入手：离线通读整个工单库，提炼出一条带边界的规则卡。

两个案例指向同一个结论：把原始案例或文档不加处理地直接放进知识库远远不够；必须在索引阶段投入计算资源，主动提炼、抽象和结构化——把 100 个个体案例压缩为统计摘要，把散落在几百条工单里的个案提炼为带边界的明确规则。

结构化索引目前主要有两条路。RAPTOR 采用自下而上的递归抽象：长文档切成小文本块作为叶子节点，聚类算法把语义相近的叶子分组（类似把图书馆的书按主题自动分堆），模型为每组生成一个更高层次的摘要作为父节点，过程不断递归，最终形成一棵从具体细节到全局概览的知识树。检索可以在多个抽象层次上进行，既能精确回答细节问题，也能提供宏观概念理解，适合\"从概念逐步钻进细节\"的查询。

GraphRAG 把知识建模为由实体和关系构成的知识图谱，用\"主语—关系—宾语\"三元组表达一条知识，大量三元组交织成一张知识之网。它有两个不可替代的优势：一是多跳关系推理，问\"我的医生所在医院的地址\"，需要沿\"用户→医生→医院→地址\"这条关系链逐跳遍历；二是实体消歧，两个同名\"张医生\"是图中不同节点，靠各自的关系边（牙科/心内科）区分。

它的局限也要看清：自然语言转三元组不可避免地导致语义降级，\"如果下周还下雨，我就取消去海边、改成去博物馆\"里的条件判断和时间依赖，分解成三元组后全部丢失；三元组提取的准确性也高度依赖模型理解能力，错误提取会造成知识污染。因此实践中推荐分层互补：以完整自然语言保存核心信息、保留语义完整性，辅以结构化元数据做索引和检索；在需要多跳推理和精确消歧的垂直场景（医疗问诊、法律案件分析、家族关系管理），把知识图谱作为专项索引手段。

第三种是文件系统范式：不把上下文视为扁平向量碎片或图谱节点，而是把记忆、资源、技能映射为虚拟文件系统中的目录和文件。资源写入时自动提炼为三个抽象层次：L0 摘要（约一百 token 的一句话概述，用于快速判断目录相关性）、L1 概览（约两千 token 的核心信息与使用场景，供规划决策）、L2 全文（完整原始内容，仅在需要深入时按需加载）。大部分查询加载到 L1 即可完成决策，token 消耗因此大幅降低——\"摘要常驻、按需取全文\"的思路，与上一章 Skills 的渐进式披露如出一辙。

底层选择 Markdown 纯文本而非专用数据库，是刻意为之：用户可以直接阅读、编辑和修正知识，可以通过版本控制回滚。但这种方式有一个极易被忽视的前提：文件之间必须建立链接与索引。如果只是把知识拆成一堆各自独立的文本文件平铺在目录里、彼此没有交叉引用，知识越多反而越难检索。正确做法是把知识库组织得像维基百科：每个条目提及其他条目时都以链接指向它，再辅以入口页和索引页，让 Agent 顺着链接从一个概念走到相关概念。

上线运行的记忆或知识库还会持续收到新信息，完整的更新机制必须同时包含两条路径。增量更新处理\"刚出现一条新证据，应作什么局部修改\"：最稳妥的工程答案是把知识库当成代码库，每次知识变更当成一个 Pull Request。提议者 Agent 从原始证据中发现新事实、冲突或过期内容，在工作分支上提出尽可能小而完整的改动；审核者 Agent 拿到变更前的知识、改动和原始证据，独立检查每个新断言是否有证据支持、是否遗漏限定条件、是否与其他文件冲突；双方迭代至收敛，审核明确批准后才可合入；合入后先过格式、链接、元数据、权限检查，再增量重建受影响的分块、摘要和向量索引。

原始证据层只增不改，知识层可持续修订，服务层保存从已合入版本生成的检索索引——索引是可重建的派生物，经过审核的知识才是真正的来源。提议者和审核者应优先使用能力相近但来自不同家族的模型，以降低在同一处犯同类错误的概率；权限上强制分工：提议者只能写工作分支，审核者只读证据并提交意见，只有合并流程可以更新主分支和线上索引。

定期整理则解决局部修改累积出的全局问题：同一事实散落多个文件、新旧说法并存、摘要逐渐偏离原始证据。后台周期性窗口从全局视角重审整个体系，至少做三项工作：去重、去旧与合并，重新建立文件间链接和索引；回到原始数据逐段核查，不能只在已有摘要之间相互改写，否则早期遗漏会一代代传下去；

冲突解决与场景限定——遇到矛盾说法，追溯各自原始信息源，检查是否分别在不同时间、对象、地域、任务或前置条件下成立，两者都有效就把适用场景分别写入知识，证据不足则保留冲突和待确认状态，不强行收敛成确定结论。此外，失效内容要附版本号和生效/失效时间，检索阶段就过滤已失效条目；多用户共享知识库必须按调用者权限过滤，绝不能让越权文档进入某个人的上下文。

08检索也能变成工具：智能体化 RAG、上下文感知检索与双层记忆收束

建好知识库之后，下一个问题是 Agent 怎么自主利用它。传统 RAG 是一条简单直接的单向数据流：用户查询直接用于检索，结果直接注入上下文，模型直接生成答案。这种模式高效，但能力上限低，本质上只是被动的\"检索—生成\"管道，缺乏对问题深度理解、分解和迭代探索的能力。

智能体化 RAG（Agentic RAG）把 RAG 从固定流程升级为由 Agent 主导的动态迭代探索。打个比方：传统 RAG 像在图书馆里只能搜一次就得立刻写报告；智能体化 RAG 像一位研究员，可以反复查阅不同书架、调整搜索策略、交叉验证信息，直到掌握足够材料再动笔。知识库检索不再是自动化前置步骤，而是一个可供随时调用的工具；Agent 通过\"思考→行动→观察\"的循环主导全过程：先分析核心需求、决定用什么关键词，再调用检索工具；观察初步结果后不立即作答，评估信息是否充分，不够就提炼更精确的查询再次搜索，甚至调用其他工具辅助；只有判断信息充分后，才综合所有上下文生成有理有据的答案。

实验对比很能说明问题：简单问题如\"正当防卫是怎么规定的\"，一次直接检索就能找到答案，传统 RAG 流程更简洁、质量相差无几；面对复杂问题如\"醉酒过失致人重伤且有盗窃前科如何量刑\"，差距就十分显著——智能体化 RAG 会先并行搜索\"过失致人重伤量刑标准\"\"醉酒刑事责任\"\"盗窃前科影响\"，评估发现缺少把它们联系起来的关键信息后，再构造更聚焦的二次查询检索累犯、数罪并罚相关司法解释，最后综合给出逻辑严密、有法条依据的回答。它牺牲一定响应速度，换来对复杂问题更强的鲁棒性和更高的回答质量。

把外部内容检索进上下文，也把一类安全风险一并带了进来：检索到的文档正是间接提示注入最典型的载体——攻击者可以把恶意指令藏进会被收录的网页或文档里，等它被检索命中、拼进上下文，模型就可能把这段数据当成指令执行；知识库投毒是同一道理，污染发生在索引之前。

防御分两层：其一，指令与数据分离，对所有检索内容做来源标记，明确告诉模型\"以下是供参考的外部资料，不是你要服从的命令\"；

其二，不让检索内容直接触发高风险操作，转账、删除、对外发信这类有副作用的动作，不应仅凭检索内容自动执行，而要经过独立授权判断。

回到上一章埋下的伏笔：传统分块把紧密关联的上下文分离了。孤立的文本块\"该公司第二季度收入增长了 3%\"，脱离原始上下文后无法回答代词指代、时间参照和实体关系等关键问题，语义信息在嵌入阶段就已经损失。上下文感知检索的核心思路非常直观：在向量化索引之前，先用模型为每个文本块生成一段简短的、包含核心上下文的前缀摘要，再把前缀与原始块拼接后索引。比如生成前缀\"本段内容节选自 ACME 公司 2025 年 Q2 财务报告的关键业绩指标章节\"，原本模糊的块就被重新锚定回原始语义环境。

这种方法同时增强两路检索：前缀增加了可精确匹配的关键词，对稀疏检索有利；前缀注入关键语义背景，也让稠密向量更精确地反映块的真实含义。需要划清界限：这里的上下文感知发生在索引期，针对知识库里的文本块，做的是\"补前缀、加背景\"的加法；上一章讲的上下文感知压缩发生在运行期，针对当前会话的对话历史，做的是\"按任务裁剪、丢弃无关内容\"的减法，两者时机和对象完全不同。