RAG及上下文工程

海量计划

57人浏览 · 2026-07-25 18:01:04

海量计划 · 2026-07-25 18:01:04 发布

什么是RAG

RAG的重要性

RAG的流程【重要】

向量数据库和embedding模型【重点理解】

结合coze平台RAG实战【重点】

什么是上下文工程

区分「会话上下文」和「外部上下文」

上下文管理手段

4 .1 什么是RAG

4.1.1 大模型的“知识困境”

我们先做一个小测试：分别向ChatGPT提问两个问题，观察回答差异

问题1：“解释一下牛顿三大定律”

问题2：“2027年1月1日发布的《生成式AI服务管理暂行办法补充细则》中，对企业提供生成式AI服务的算力要求是什么？”

结果会发现：第一个问题回答精准，第二个问题往往“含糊其辞”或给出错误信息。这背后是大模型的三大核心痛点：

1. 知识滞后性：大模型的训练数据有“截止日期”，无法获取训练后产生的新信息（如2026年的新规）

2. 事实准确性差：面对专业领域知识或小众信息，容易出现“一本正经地胡说八道”（即“幻觉”）

3. 知识不可追溯：回答缺乏引用来源，无法验证准确性，在学术、法律等场景无法使用

问题3：如果需要定制企业的智能客服，客户假如询问相关企业的私有数据，如企业的会员管理等级等，这些数据是普通大模型不存在的数据，存在于企业的手册等数据。

如何解决类似问题呢？只有将企业相关资料交给大模型！看起来问题就得到了解决，但是这儿也存在几个问题，如果企业数据非常多，存在大量数据，直接交给大模型，可能就会带来如下一些问题：

1. 模型可能无法读取全部数据【数据太多，超过了大模型上下文窗口大小，会出现读了后面，忘记前面】

2. 大模型的推理成本会剧增【数据太多，大模型出来起来算力就会突增】

3. 大模型推理时间长【内容太多，带来了时间上的额外开销】

和前两个问题类似，需要一个新的技术来解决这个问题，这就是RAG技术。

4.1.2 RAG的诞生

RAG是上下文工程非常重要的一种实现方式，所以我们通过学习RAG，来初步的尝试着理解上下文工程的作用。

RAG定义：Retrieval-Augmented Generation（检索增强生成），是一种将“信息检索”与“生成式AI”结合的技术，核心逻辑是：在大模型生成回答前，先从海量外部知识库中检索出与问题相关的精准信息，再基于这些信息生成回答，相当于给大模型装一个“外接知识库”。

通俗理解：大模型本身的知识是“固定的”（训练数据截止到某个时间点，如GPT-4训练数据截止到2023年10月），无法获取最新信息、特定领域的小众知识；而RAG相当于给大模型“配了一个搜索引擎+知识库”，需要时先“查资料”，再“回答问题”，解决大模型“知识滞后”“内容不准确”的痛点。

RAG可以理解分为六步（前置还存在要给数据清洗和处理）：

切片【chunk】

enbedding

存储（向量数据库）

召回（根据用户的问题，将相关数据从向量数据库中匹配回来），多条匹配的数据

排序【不一定必须有】

生成（根据匹配度最高的数据，结合相关其他数据，大模型生成用户的答案）

RAG的本质：不是训练大模型“记住”更多知识，而是让大模型“学会”在需要时“查阅”权威资料，相当于给大模型配了一个“随身图书馆+参考资料”。

4.1.3 RAG的核心价值

案例对比解析：

1. 无RAG的大模型：提问“2025年诺贝尔物理学奖得主是谁”，由于大模型知识滞后，可能会输出错误答案，或表示“无法回答”。

2. 有RAG的大模型：提问同样的问题，RAG会先检索2025年诺贝尔物理学奖的官方信息（外部知识库），再结合大模型的语言组织能力，生成准确回答。

对比维度	传统大模型直接生成	RAG增强后生成
知识时效性	依赖训练数据，无法更新	实时检索最新资料，随更随用
事实准确性	易产生幻觉，错误率高	基于权威来源，可验证，幻觉率大幅降低
专业领域适配	通用知识强，专业知识弱	可接入行业知识库，精准匹配专业需求
成本与迭代	更新知识需重新训练，成本极高	更新知识库即可，迭代成本低、速度快

4.1.4 RAG场景

请判断以下场景是否适合用RAG，并说明理由：

1. 企业客服：回答客户关于最新产品功能、售后政策的问题

2. 学生写作文：生成“我的童年趣事”这类主观内容

3. 律师起草文书：引用最新的法律法规条文

4. 科研人员总结文献：基于近5年的领域论文提炼观点

5. 大学生的毕业论文：

（答案提示：1、3、4适合，核心原因是需要“精准、权威、实时”的外部信息；2不适合，因依赖主观体验，无需检索外部知识）

RAG通过检索知识库，提高了大模型的准确性、时效性和专业性，能有效的缓解大模型的幻觉和知识老化问题。避免了重新训练大模型，有效的降低了成本。

4 .2 RAG底层原理与技术链路

4.2.1 RAG的核心逻辑

RAG 主要分两个阶段：

建立索引：首先要清洗和提取原始数据，将PDF、DOCX 等不同格式的文件解析为纯文本数据；然后将文本数据分割成更小的片段（chunk）；最后将这些片段通过嵌入模型转换成向量数据（此过程叫做 embedding），并将原始语料块和嵌入向量以键值对形式存储到向量数据库中，以便进行后续快速、高频的检索。这就是建立索引的过程。

检索生成：系统会获取到用户输入，随后计算出用户的问题与向量数据库中的文档块之间的相似度，选择相似度最高的K 个文档块（K 值可以自己设置）作为回答当前问题的知识。检索到的知识和你的问题会按一定格式组合起来，作为提示词（就是你发给大模型的那段文字）提交给大模型，大模型给出回复。

RAG系统的运行分为两大阶段：离线准备阶段和在线交互阶段，“先检索，再生成”的完整闭环整个链路。可拆解为6个核心步骤，我们用“查资料写报告”的场景类比理解：

1. 离线阶段1：知识收集与清洗——相当于“收集报告所需的各类资料”：将企业文档、行业报告、法律法规等原始数据（如PDF、Word、网页）收集起来，剔除重复、无效信息，保留核心内容【这一步其实是RAG的准备阶段】。

2. 离线阶段2：文本分割（Chunking）——相当于“把厚资料拆成便于查阅的小段落”：将长文档按逻辑拆分成短文本块（Chunk），比如按章节、段落拆分，避免因文本过长导致后续检索精度下降。

3. 离线阶段3：嵌入（Embedding）与存储——相当于“给每个资料贴标签并放进文件柜”：通过嵌入模型将每个文本块转化为高维向量（Embedding Vector），向量的相似度可直接反映文本语义的相似度；再将这些向量存入向量数据库，完成知识库的构建。

4. 在线阶段1：用户问题处理——相当于“明确报告题目”：接收用户问题后，同样通过嵌入模型将问题转化为向量。

5. 在线阶段2：相似性检索——相当于“从文件柜里找出相关资料”：向量数据库计算“问题向量”与 “知识库中所有文本块向量”的相似度，检索出Top N个最相关的文本块（即“相关知识”）。

6. 在线阶段3：增强生成——相当于“基于资料写报告”：将用户问题和检索到的相关知识一同输入大模型，大模型基于这些精准信息生成逻辑清晰、来源可追溯的回答。

4.2.2 RAG的“三大核心支柱”

支柱1：文本分割（Chunking）

文本分割是RAG的“第一道门槛”，分割不合理会直接导致检索失效：如果Chunk太大，包含无关信息多，检索精度低；如果Chunk太小，会破坏文本语义完整性（比如把一个完整的公式拆成两半），所以切割时的颗粒度就非常重要。

常见的分割策略：

固定长度分割：最基础的方法，比如将文本按500字符拆分，同时保留一定的“重叠部分”（如重叠50字符），避免拆分到关键信息。

语义感知分割：更智能的方法，基于文本的语义结构拆分，比如按段落、句子、页码、章节标题分割，可通过NLP工具（如spaCy、NLTK）识别标点、标题符号实现。

领域适配分割：针对专业文档，比如PDF表格、代码文件，采用专用工具分割（如用PyPDF2提取表格内容后单独作为Chunk）。

实战经验：对于通用文本，推荐“固定长度（300-800字符）+ 语义修正”的混合策略；对于技术文档，优先按“标题层级+代码块+公式块”分割。

支柱2：嵌入模型（Embedding Model）

嵌入模型的核心作用是“将文本语义转化为可计算的向量”，向量的质量直接决定了“问题与知识”的匹配精度。可以把嵌入模型理解为“语义翻译官”，把人类语言翻译成机器能理解的“向量语言”。

向量：数学中的向量，有大小，有方向的量。

因为存在方向，这样在不同纬度中，代表的信息就不同，如一维中，表示距离0坐标轴的有方向的值。

二维的向量：

三维的，则需要立体三维空间中，增加z轴。

当然可以更高维度，可以看出，维度越高，可以携带和表示的信息会更多。

在RAG里面用到的向量维度通常情况下都会比较大，以GPT-3版本为例，嵌入向量维度是12,288维。

通过Embedding将片段文本转换为向量，再将片段文本和片段向量存入向量数据库中，这个就是嵌入模型的功能。

Embedding 排行榜：https://huggingface.co/mteb/spaces

支柱3：向量数据库

向量数据库：向量数据库是专门用来存储和查询向量的数据库，其存储的向量来自于对文本、语音、图像、视频等的向量化。与传统数据库相比，向量数据库可以处理更多非结构化数据（比如图像和音频）。在机器学习和深度学习中，数据通常以向量形式表示。

传统数据库（如MySQL）是基于“关键词匹配”检索，无法计算“语义相似度”；而向量数据库是专门用于存储和检索向量的数据库，能快速从百万、千万级向量中找出与“问题向量”最相似的向量，核心优势是“高效的相似性检索”。

向量数据库的核心技术：近似最近邻算法（ANN），通过牺牲极微小的精度来换取检索速度的指数级提升，常见的ANN算法有FAISS、HNSW、IVF等。

主流向量数据库对比：

Pinecone：闭源托管型，开箱即用，无需运维，适合快速搭建原型

Milvus（米洛沃斯）：开源，支持大规模数据，性能强，适合企业级部署

Chroma：轻量级开源，可嵌入Python应用，适合小规模项目或本地开发

Weaviate：开源，支持混合检索（向量+关键词），灵活性高

4.2.3 持续改进RAG 应用

通过前面的实验，你搭好了自己的RAG 应用。你邀请了许多人试用、收集反馈，吐槽很快就来了：有人说回答是瞎编的，还有一些你觉得不太客观的差评。凭直觉很难分清哪些是系统真正存在的问题，你需要借助评测来分析和判断。

从真实问题中抽样

随机抽取10 条用户真实提问，让刚搭好的知识问答机器人回答，并逐条打分：

好（准确回答）

中（能解答问题，但值得改进）

差（答非所问，亟待改进）

假设10 条里6 条标了「好」，初步满意度60%。

但光看这个数字，你没法改进机器人。剩下4 条不够好的回答，应该由谁来判断好坏，用哪些问题来测？更关键的是，问题到底出在哪里：是机器人没找到相关资料，还是资料给得太多太杂，模型没能从中提炼出准确答案？

要回答这些问题，你需要一套评测体系。

评测体系建立

评测这件事，得由业务专家主导。他们最清楚用户会问什么、什么样的回答算解决了问题。业务专家能站在用户角度，透过真实问答洞察用户实际意图，基于亲自操作判断系统回答是否到位，并据此优化知识库、迭代评测集，持续驱动业务和技术迭代。

1. 制作评测集

评测样本通常从线上用户的真实问答、工单和负反馈中随机抽取。业务专家拿到这些样本后，为每条问题写出标准答案。

标准答案不用写成完整文章，列出关键要点就够了，这也方便后续做自动评测（后面会讲到）。

举个例子：问题「全聚德怎么走？」的标准答案只需列出关键要点，如（1）出景区东门左转（2）

步行约500 米（3）到十字路口右拐即到。不用写成一段完整的导航讲解词。

用户的真实提问配上业务专家写的标准答案，就构成了评测集。评测集不是一次做完就不管了，因为用户需求会不断变化。上个月的热点（比如景区内一场已经结束的临时展览），这个月可能就没人问了。过期的问题要淘汰，新出现的问题类型要补充，不准确的标准答案要修正。建议每周从线上问答中随机抽样，只保留最近几个月（比如3 个月）内的真实问答对，滚动维持1000～3000 条评测样本。

2. 建立评测指标

有了评测集，还需要一套评测指标来衡量RAG 系统的效果。

但问题是：业务关心的指标往往不能直接用来优化系统。比如景区主管关心「游客满意度有没有提升」「问题解决率有没有提升」，但这些指标只能告诉你「出问题了」，不能告诉你「问题出在哪」。技术指标才能定位系统的问题，把这些问题逐一优化后，RAG 系统的效果通常会随之改善。

因此，你要把业务指标拆解为具体的、可量化和可优化的技术指标。

怎么拆？可以像考核一名导游的讲解服务一样，先把「游客满意度」下钻到回答过程中的关键环节，比如是否听懂了游客的问题、有没有从手册中准确找到相关的资料等。对应到RAG 系统中，这些环节可以映射为意图理解、知识检索、答案生成等模块。只有先定位到某个具体的模块，技术指标才有明确的评估对象。

定位到模块后，就可以用技术指标量化问题了。RAG 系统可以采用Ragas 评测体系（这是一套开源的RAG 评测框架，详细指标定义可查阅其官方文档）：

检索模块：

准确率（Context Precision）：检索到的文档有多少是真正相关的

召回率（Context Recall）：相关文档有多少被检索到了

生成模块：

回答相关性（Answer Relevance）：回答是否切题

忠实度（faithfulness）：是否基于资料回答，没有编造

完整性：信息是否充分

流畅性：表达是否自然

答案正确性（Correctness）：答案内容是否正确

这些技术指标怎么影响RAG 系统的效果？举个例子：如果检索的召回率从30% 提升到70%，意味着系统多找回了40 个百分点的相关信息。用户不用反复追问，一次就能拿到完整答案，满意度自然上升，工单量也会下降。

执行评测

每周，景区主管会从上周游客提出的问题中抽查一批，逐个看导游是怎么回答的。不只是看「答得好不好」，更重要的是看「哪里出了问题」。这就是专家评测。但专家评测很消耗人力，容易成为版本频繁迭代的瓶颈。对于需要日常批量评测的场景，可尝试用自动评测快速回归验证，判断新版本是否稳定变好。

1. 专家评测

业务专家定期从线上用户的真实问答中抽样审查，让团队持续掌握用户满意度的变化。发现异常时，业务专家要及时分析原因（归因方法在第6 节展开）。归因清楚后，按问题类型分派改进：

技术团队：负责优化意图理解、检索、生成等问题

业务专家：负责补充知识库内容、更新知识、修复错误

产品团队：负责处理业务规则类问题

同时，专家每次审查还会产出新的评测样本，从而覆盖更多场景，持续扩展下面将讲到的自动评测能力。

2. 自动评测

专家评测发现问题后，团队会做相应修复，比如调整检索算法、优化系统提示词等。但修完之后，新问题来了：这次改动到底是改好了还是改坏了？核心技术指标有没有退化？如果每次改动后所有场景都要依赖业务专家重新人工做评测，专家就会成为系统迭代速度的瓶颈。

这时，前期沉淀的高质量评测集就派上用场了。对于评测集已覆盖的场景，直接交给机器快速批量对比验证。

图6：Ragas 工作原理

具体做法是：用前面提到的Ragas框架，基于同一套评测集，分别跑基线版本和新版本，对比关键指标的变化。指标整体提升且核心指标没有退化，说明改动有正向收益；某些指标下降，也能帮助定位问题出在哪。

上线判断

上线判断不应只看技术指标。另一种做法是用GSB（Good / Same / Bad：新版更好、基本持平、新版更差）对新旧版本在评测集上的表现进行逐条样本对比，再统计Good / Same / Bad 三类结果的占比。一个可以参考的经验是：当超过20% 的样本变好，且不超过10% 的样本变差时，可以考虑上线。

总体来看，专家评测和自动评测应长期并行、相互补充。专家评测适合关键场景和新场景的评测、掌握用户满意度和意图空间变化、发现异常、沉淀新的评测样本与指标；自动评测适合日常批量评测，用于版本迭代后的批量回归验证，判断新版本是否稳定变好，发现潜在退化，降低上线风险。

4 .3 coze调用RAG

4 .4 Context 上下文工程

4.4.1 什么是上下文工程

要很好的理解上下文和上下文工程，我们还是得回到之前的提示词和提示词工程。

提示词（Prompt）：提示词是我们与AI 模型沟通的"语言"。写好提示词，本质上是在学会如何清晰地表达需求。一个好的提示词需要包含：明确的目标、必要的背景信息、期望的输出格式。很多人觉得 AI"不好用"，问题往往出在提示词写得太模糊，此时就需要提示词工程来解决了。

提示词工程（Prompt Engineering）：正如我们之前所说，提示词工程不是玄学，而是一套系统化的方法论，如将提示词分为系统提示词和用户提示词，通过系统提示词来影响AI输出内容，这种通过系统提示词组合用户提示词，来引导大模型返回特定风格回复的做法，就是提示词工程。核心技巧包括：

角色设定：给AI 一个身份（"你是一名资深Python 工程师"），能显著提升输出质量

分步引导：复杂任务拆解为多个步骤，引导AI 逐步推理（Chain-of-Thought）

示例驱动：提供输入输出示例（Few-shot），让AI 理解你的期望模式

约束条件：明确告诉AI 什么能做、什么不能做

赋予技能：通过工具，加持AI的更强大的能力

参考文档：提供相关技术的文档地址或者引用

提示词工程的关键在于迭代——写提示词→看结果→调整→再看结果，直到稳定输出。

上下文工程（Context Engineering），这是比提示词工程更深一层的能力。我们都知道，大模型本来是没有记忆的，每一次询问都是一次独立的问答，但是在现实场景中，我们往往需要多轮对话这种业务场景，此时就需要使用手段让AI具备记忆力，如将每一次对话的内容都上传给AI，使得AI每一次回答都会参考前面的对话。

这样看上去，就相当于给了AI大模型记忆，但是我们都知道，大模型有上下文窗口限制（如512K/1M tokens），如何在这个有限的空间里塞进最有价值的信息，是一门学问，因此就有了上下文工程。因此：

上下文（context）：就是一次发给大模型的完整的历史记录就是上下文。

上下文工程（Context Engineering）：如何管理和修改这段历史记录的技巧就被称为上下文工程。

上下文工程关注的是：你给了A I 哪些信息、以什么顺序给、如何管理这些信息。

Context Engineering = 在有限Context Window 内，对信息进行选择、组织、压缩、注入和更新的系统工程。。

这不仅是技术动作，而是一套持续优化的决策系统，包含三个核心维度：

决策维度	核心问题	关键考量
塞什么（What）	哪些信息对当前任务真正有用？	相关性、时效性、冗余度、安全性
怎么塞（How）	以什么格式和结构呈现？	优先级排序、结构化程度、指令/数据分离
什么时候塞（When）	何时注入？每次都塞还是按需塞？	首轮注入、动态检索、按需加载

如何管理上下文

1. 选择上下文

选择上下文，一般有两种手段：固定【静态】的上下文+ 动态的上下文固定上下文：必须要加载给大模型的，不能缺少。系统提示词、用户提示词

不固定的上下文：RAG技术、数据库的知识。。。

2. 压缩上下文

对于上下文的内容进行压缩（compact）。

暴力方式：直接将之前的轮数截取【缺点】

压缩：Agent都存在自动压缩、手动压缩

长期记忆力和短期记忆力

4.4.2 上下文工程的终极目标

在Prompt Engineering 阶段，人们关注：“如何向模型提问？”

而在Context Engineering 阶段，关注的问题变成：“模型在回答问题时，应该看到哪些信息？”因为大模型本身并不是缺少能力，而是受到：

Context Window 限制

知识截止时间限制

私有数据不可见限制

多轮任务状态丢失限制

因此，上下文工程的核心目标不是简单扩大输入规模，而是在有限Token 预算下：

最大化进入模型上下文的信息价值。

即：

有效上下文价值= 相关性× 准确性× 时效性× 可理解性

最终实现：

目标	作用
降低幻觉	提供可靠知识来源
保持连续性	保存任务状态
降低成本	减少无效Token
提升效率	减少模型计算负担

4.4.3 上下文的两大组成

从工程角度看，一个AI Agent 的Context Window 主要由两部分组成：

会话上下文

外部上下文

会话上下文（Session Context）

会话上下文：指单次Session 生命周期内，为保持任务连续性而保存的信息。特点：

生命周期短

服务当前任务

会话结束后释放

主要包含三个部分。

对话历史（Conversation History）

保存：

User 消息

Assistant 回复

System 指令

Tool 调用结果例如：

1 [2 {

3 "role ":"user ",

4 "content ":"我要退款"5 },6 {

7 "role ":"assistant ",8 "content ":"请提供订单号"9 }

10 ]

1 [2 {3 "role ":"user ",4 "content ":"我要退款"5 },6 {7 "role ":"assistant ",8 "content ":"请提供订单号"9 }10 ]

作用就是让模型理解：

“我们刚刚讨论到了哪里？”

但是呢，对话历史并不会无限保存，当超过Context Window，就需要进行：

历史截断

自动摘要

重要信息提取

任务状态（Task State）

这是Agent 系统区别于普通聊天机器人的关键。不要让模型，从几十轮聊天记录中猜测任务进度。而应该独立保存：

1 {

2 "task ":"refund ",

3 "stage ":"verify_order ",4 "completed ":[

5 "user_identity "6 ],

7 "pending ":[

8 "refund_reason "9 ]

10 }

1 {2 "task ":"refund ",3 "stage ":"verify_order ",4 "completed ":[5 "user_identity "6 ],7 "pending ":[8 "refund_reason "9 ]10 }

优势：

更稳定

更省Token

更容易控制

会话级用户偏好（Session Preference）

记录当前对话中的临时偏好，例如：

1 回复语言:

2 中文3

4 输出形式:

5 Markdown6

7 回答长度:

8 简短

1 回复语言:2 中文34 输出形式:5 Markdown67 回答长度:8 简短

特点：

只服务当前Session

不进入长期记忆

会话上下文的核心挑战

Context Overflow

历史消息越来越长，超过Context Window，数据会溢出，导致之前的数据会丢失掉。

解决方案：

方法	作用
截断	删除低价值历史
摘要	压缩历史信息
状态提取	保存关键事实

Lost-in-the-Middle

长上下文中，模型对于中间位置的信息关注度下降。因此，重要信息应该：

根据transform架构，将重要信息放在开头或者结束部分，而不是隐藏在大量历史中。

外部上下文（External Context）

外部上下文：指来自当前会话之外，为模型补充知识、数据和长期信息的外部信息。解决大模型三个天然限制：

限制	解决方案
不知道最新信息	实时知识检索
不知道企业数据	RAG
不知道用户历史	Memory

外部上下文主要来源有如下组成：

企业知识（Knowledge）

例如：

产品文档

技术手册

公司制度 FAQ

通过RAG，本地知识库来实现检索和管理。

业务数据（Business Data）

例如：

用户订单

库存

CRM

数据库记录特点：

实时性强

权限要求高

通常处理方案是让大模型调用数据库，之后将相关数据转入到上下文中，如NL2SQL方案。

长期记忆（Long-term Memory）

保存跨Session 信息，例如：

1 用户喜欢中文回答

2 用户职业:

3 程序员

4 历史关注:

5 AI Agent

1 用户喜欢中文回答2 用户职业:3 程序员4 历史关注:5 AI Agent

存储到长期记忆库中，进行检索。

工具执行结果（Tool Context）

Agent 调用工具后，工具返回的信息也是上下文。

4.4.4 上下文管理的核心原则

一个优秀的Context Engineering 系统，需要满足五个原则：

原则	说明
相关性	只提供当前任务需要的信息
准确性	避免错误知识进入模型
时效性	优先使用最新数据
安全性	控制数据访问权限
可追溯	知道信息来源

4.4.5 完整的上下文组装流程

也就是每轮对话：

1【每轮对话开始】

2 ①从会话存储中加载：

3 ├──本轮对话历史（经过压缩/截断后的Message List）

4 ├──当前会话状态（结构化JSON）

5 └──用户临时偏好（KV 键值对）6

7 ②从广义上下文系统检索：

8 ├──用户问题→Embedding →向量检索→Top-K 相关文档片段

9 └──（可选）结构化数据查询→文本化10

11 ③组装最终Context Window：

12 ├──System Prompt（最高优先级，固定不变）

13 ├──会话状态（本轮任务进度）

14 ├──用户临时偏好

15 ├──检索到的外部知识（标注来源）

16 └──对话历史（最近N 轮）17

18 ④调用LLM 生成回复19

20 ⑤更新会话存储：

21 ├──追加本轮对话

22 ├──更新会话状态（如任务推进）

23 └──（可选）提取新的偏好→存入长期记忆

1【每轮对话开始】2 ①从会话存储中加载：3 ├──本轮对话历史（经过压缩/截断后的Message List）4 ├──当前会话状态（结构化JSON）5 └──用户临时偏好（KV 键值对）67 ②从广义上下文系统检索：8 ├──用户问题→Embedding →向量检索→Top-K 相关文档片段9 └──（可选）结构化数据查询→文本化1011 ③组装最终Context Window：12 ├──System Prompt（最高优先级，固定不变）13 ├──会话状态（本轮任务进度）14 ├──用户临时偏好15 ├──检索到的外部知识（标注来源）16 └──对话历史（最近N 轮）1718 ④调用LLM 生成回复1920 ⑤更新会话存储：21 ├──追加本轮对话22 ├──更新会话状态（如任务推进）23 └──（可选）提取新的偏好→存入长期记忆

4.5.6 上下文工程解决什么问题

问题	传统Prompt	Context Engineering
多轮任务	依赖聊天记录	状态管理
知识更新	重新训练	RAG
用户个性化	重复输入	Memory
复杂任务	人工控制	Agent Context
长期运行	无法实现	上下文生命周期管理

最终：

上下文工程的本质，是为大模型构建一个动态的信息操作系统。

模型负责推理，而上下文工程负责决定：

模型什么时候看到什么信息，以及这些

下面做了一个人工客服的实验

DAMO开发者矩阵

DAMO开发者矩阵，由阿里巴巴达摩院和中国互联网协会联合发起，致力于探讨最前沿的技术趋势与应用成果，搭建高质量的交流与分享平台，推动技术创新与产业应用链接，围绕“人工智能与新型计算”构建开放共享的开发者生态。

更多推荐

[具身智能-655]：X5能够同时支持bin和hbm格式的模型文件吗？

机器人端：D-Robotics（地瓜）OpenExplorer OE Toolchain →。ash-e/Nash-m 微指令编码、硬件流水线不兼容，没有任何办法直接转换。解决方案：原始 ONNX 模型，用 X5 OE 工具链重新 PTQ 编译生成。二进制文件头、指令集、元数据全部不一样，修改后缀直接报模型校验错误。多任务方案优化方向：手动把多分支网络合并进单个 ONNX，编译为单。两套独立工具链