type
status
date
slug
summary
tags
category
icon
password
catalog
sort

为什么“上下文”突然变得比“检索”更性感？

当大语言模型（LLM）从“一次性问答工具”进化为“持续交互智能体”时，技术焦点正在发生迁移——检索（Retrieval）解决了“知识从哪来”的问题，而上下文（Context）则解决了“知识如何用”的问题。
2023年RAG（检索增强生成）的爆发，本质是为LLM补上了“外部知识”的短板；但2024年以来，企业落地中暴露的多轮对话失忆、个性化缺失、成本失控等问题，让行业意识到：仅靠“检索+生成”的线性流程，无法支撑复杂场景（如智能客服、个人管家、B端OA助理）的持续交互需求。
正如LangChain在《Context Engineering for Agents》中指出：“LLM的能力边界，不再由其参数规模决定，而由其对上下文的治理能力决定”。当用户需要“记住上次的偏好”“结合实时工具数据”“衔接历史对话逻辑”时，“上下文工程”（Context Engineering）成为比“检索优化”更核心的技术突破口。

1 从 RAG 到 Context：一次自然演化的历史必然

LLM的交互能力演进，本质是“对外部信息的管理能力”的升级。从Prompt Only到RAG，再到Context Engineering，每一步都是对前一阶段核心痛点的解决，具有明确的历史必然性。
阶段
关键词
核心问题
技术组合
典型缺陷
技术背景与演进动力
1.0 Prompt Only
Zero-shot/Few-shot、Prompt Template
幻觉率高、知识时效性差、无外部信息
LLM + 静态Prompt模板
无法调用外部知识，多轮对话易脱节
2022年LLM（如GPT-3.5）刚落地，仅能依赖内置参数知识，无成熟外部接入生态
2.0 RAG
Retrieve-then-Generate、向量库、重排
知识缺失、幻觉缓解
LLM + 向量库（Pinecone/Weaviate） + 重排模型（Cross-Encoder）
检索噪声多、上下文窗口爆炸、多轮失忆、无状态管理
2023年向量数据库技术成熟，解决了LLM“知识过期”问题，但未考虑“持续交互中的状态延续”
3.0 Context
Context-aware Memory、动态窗口、分层路由
对话一致性、状态延续、个性化适配
LLM + 多层记忆（短期/中期/长期） + 压缩/路由引擎
架构复杂度提升、需精细化工程落地
2024年企业需求从“单次问答”转向“持续服务”（如客服、管家），要求模型“记住上下文、适配用户、衔接工具”
核心演进逻辑：
1.0→2.0 是“补知识”：通过检索将LLM的知识边界从“训练截止日”扩展到“实时数据”；
2.0→3.0 是“补状态”：通过上下文工程将LLM的交互模式从“单次独立请求”升级为“持续连贯服务”。
Context Engineering的核心突破，是将“上下文”从“被动拼接的文本串”升级为“主动管理的结构化状态”——不再是“我检索到什么就用什么”，而是“根据当前需求，动态选择、压缩、组合最相关的状态信息”。
参考资料：

2 RAG 的七宗罪：为什么光靠“检索+生成”还不够

尽管RAG是LLM落地的“基础设施”，但在复杂场景中，其“检索先行、生成跟进”的线性逻辑会暴露诸多根本性问题，这些问题无法通过优化检索算法（如提高召回率、优化向量模型）完全解决。
症状
根因
实际业务案例
行业痛点数据
检索噪声
语义相似≠事实相关：向量检索基于文本 embedding 相似度，但无法判断“语义相似的内容是否与当前问题逻辑相关”
某电商客服场景：用户问“如何退订会员自动续费”，RAG检索到“如何开通会员自动续费”（两者语义高度相似，但操作逻辑完全相反），导致模型给出错误指引
根据Pinecone 2024年《RAG落地报告》，检索噪声导致的回答错误占比达34%
窗口爆炸
Top-K检索结果叠加历史对话，token数量快速超出LLM上下文窗口限制
某金融投研场景：用户与模型多轮讨论“某股票估值”，每轮检索5篇研报（每篇1k token），3轮后总token达1.5万，超出GPT-3.5（4k窗口）上限，导致系统OOM或截断关键历史
OpenAI开发者调查显示，62%的RAG落地项目因“窗口爆炸”被迫限制对话轮次（≤5轮）
多轮失忆
仅拼接历史文本，无结构化记忆：RAG将历史对话作为“纯文本串”拼接到prompt，无法提取关键信息（如用户偏好、之前的结论）
某政务咨询场景：用户第1轮问“居住证如何办理”，模型回答后；第3轮问“那需要准备哪些材料？”，模型因无法关联历史对话，回复“请问您咨询的是哪项业务的材料？”
阿里云智能客服调研显示，多轮失忆导致用户重复提问率提升47%，满意度下降29%
时效漂移
向量库更新周期（通常按天/小时）与实时场景需求（分钟/秒级）不匹配
某股票咨询场景：2024年5月20日某股票突发跌停（10:00发生），但RAG向量库最新数据是5月19日的研报，模型仍基于“目标价100元”回答，与实时行情完全脱节
彭博社《金融LLM应用报告》指出，时效漂移导致金融领域RAG回答的“信息失效率”达58%（实时场景）
工具混乱
无统一的工具结果处理机制：RAG仅处理“文档检索结果”，但工具（API）返回格式多样（JSON/CSV/文本），无法标准化为可用上下文
某生活服务场景：用户问“北京明天天气+我的快递进度”，天气API返回JSON（{"temp":25,"rain":false}），快递API返回文本（“快递已签收”），RAG无法整合两者，导致模型只回答天气问题
LangChain开发者社区调查显示，73%的RAG+工具项目需额外开发“工具结果格式化”模块，开发成本增加30%
个性化缺失
检索结果对所有用户统一，未结合用户属性（如身份、偏好、历史行为）
某视频平台客服场景：VIP用户问“如何取消广告”，RAG检索到“普通用户需开通会员取消广告”，但未调用“VIP用户免广告”的个性化规则，导致给出冗余指引
腾讯云《C端LLM应用报告》显示，个性化缺失导致用户转化率下降22%（对比个性化 Context 方案）
成本失控
每次请求均触发“检索+重排+生成”全流程，无缓存或按需调用机制
某企业OA助理场景：早高峰（9:00-10:00）有1000用户查询“年假规则”，RAG每次均检索OA文档库（5000+文档），导致向量库调用成本达平峰期的10倍，token消耗达平峰期的8倍
AWS Bedrock成本分析显示，未优化的RAG项目token成本比Context方案高40%-60%
参考资料：
notion image
 

3 Context Engineering 的三重哲学：分层、压缩、路由

Context Engineering 并非“替代RAG”，而是通过一套系统化的“上下文治理逻辑”，解决RAG无法覆盖的状态管理问题。其核心思想可概括为三重哲学，每一层均对应具体的技术落地路径。

3.1 分层（Layered）：让上下文“各归其位”

核心思想：将上下文按“时效性”和“复用性”分为不同层级，避免“所有信息混在一起管理”导致的效率低下或信息丢失。
本质是模仿人类记忆的“短期记忆-中期记忆-长期记忆”逻辑，让不同生命周期的信息对应不同的存储和调用策略。
记忆层级
数据类型
生命周期
存储介质
核心作用
示例
短期记忆（Short-Term）
本轮对话临时信息、工具调用中间结果
会话内（会话结束即清空）
LLM的KV Cache、内存变量
支撑本轮对话的逻辑连贯性，如“用户当前提问中的指代（‘这个产品’）”
用户问“这款手机的电池容量”，短期记忆存储“‘这款手机’指之前讨论的iPhone 15”
中期记忆（Mid-Term）
多轮对话关键信息、临时用户需求
会话间（如24小时内，超时清理）
分布式缓存（Redis）、轻量向量库
支撑跨会话的上下文延续，如“用户上次未完成的咨询”
用户昨天问“居住证办理”，今天继续问“材料准备好了，下一步？”，中期记忆提取“上次已告知办理流程，当前需衔接‘提交材料’步骤”
长期记忆（Long-Term）
用户画像、长期偏好、固定知识（如企业规则）
持久化（无明确过期时间，定期更新）
关系型数据库（MySQL）、图数据库（Neo4j）、全量向量库
支撑个性化适配和长期知识复用，如“用户是VIP，需优先提供专属服务”
用户是银行VIP客户，长期记忆存储“VIP用户免排队、专属客户经理”，每次咨询均调用该信息
技术落地关键点：
  • 层级间的“流转规则”：短期记忆中的关键信息（如用户明确偏好）需自动同步到长期记忆（例：用户说“我只关注新能源股票”，短期记忆→长期记忆）；
  • 层级优先级：生成prompt时，短期记忆优先级最高（确保本轮逻辑连贯），长期记忆优先级次之（确保个性化），中期记忆按需调用（避免冗余）。
参考资料：

3.2 压缩（Compressed）：让上下文“轻量化”

核心思想：在不丢失关键信息的前提下，通过“摘要、剪枝、结构化”等手段，降低上下文的token消耗，避免“窗口爆炸”问题。
压缩的核心不是“简单截断”，而是“保留语义核心，去除冗余信息”——确保压缩后的上下文仍能支撑LLM的逻辑判断。

常见压缩策略对比

压缩策略
原理
适用场景
压缩率
工具/模型推荐
语义摘要（Semantic Summarization）
用LLM（如GPT-4o-mini、Llama 3）对长文本（如多轮对话、检索结果）进行摘要，保留核心逻辑
多轮历史对话、长文档检索结果
30%-50%（如1k token→500 token）
LangChain Summarizer：https://python.langchain.com/docs/modules/data_connection/document_transformers/summarization
关键信息提取（Key-Info Extraction）
基于规则或LLM提取文本中的关键字段（如用户ID、需求类型、时间、地点），结构化存储
用户画像、工具返回结果（如快递信息、订单状态）
60%-80%（如500 token文本→100 token结构化数据）
Llama Index KeyExtractor：https://docs.llamaindex.ai/en/stable/module_guides/indexing/node_parsers/key_extractor/
冗余剪枝（Redundancy Pruning）
识别并删除重复/相似信息（如用户重复提问、检索结果中的重复段落）
多轮对话中的重复内容、Top-K检索结果去重
20%-40%
Pinecone Duplicate Detection：https://www.pinecone.io/docs/duplicate-detection/
层级压缩（Hierarchical Compression）
先对单段文本摘要，再对多段摘要进行二次压缩（形成“摘要的摘要”）
大量检索结果（如Top-10研报）、超长对话（10轮以上）
50%-70%
LangChain HierarchicalSummarizer：https://python.langchain.com/docs/modules/data_connection/document_transformers/hierarchical_summarization/
案例：电商客服场景中，用户5轮对话涉及“订单查询→退货申请→退款进度→重新下单”，原始对话文本达2k token。通过“关键信息提取（提取订单号、退货状态）+ 语义摘要（总结每轮核心需求）”，压缩后仅需600 token，且关键信息无丢失。
参考资料：
notion image

3.3 路由（Routed）：让上下文“按需调用”

核心思想：根据“用户请求类型”和“当前场景”，动态选择最相关的上下文层级/来源，避免“所有上下文都塞进prompt”导致的冗余和低效。
路由的本质是“上下文的精准筛选”——让LLM只看到“当前需要的信息”，而非“所有可能相关的信息”。

路由决策的核心维度

  1. 请求类型路由：根据用户提问的意图，选择对应上下文来源
      • 示例：用户问“我的年假还剩多少天”（OA查询类）→ 路由到“长期记忆（用户身份）+ 工具上下文（OA API返回结果）”；
      • 示例：用户问“上次说的那个会议纪要在哪”（历史对话类）→ 路由到“中期记忆（最近3轮对话摘要）”。
  1. 信息优先级路由：根据上下文的“重要性评分”，选择Top-N信息
      • 评分维度：与当前请求的相关性（余弦相似度）、时效性（距离当前时间越近分数越高）、用户关注度（用户标记为“重要”的信息分数更高）；
      • 示例：用户问“北京明天的天气”→ 路由到“工具上下文（实时天气API，时效性评分0.9）”，而非“上周天气检索结果（时效性评分0.2）”。
  1. 场景化路由：根据当前业务场景，过滤无关上下文
      • 示例：用户在“电商购物车场景”问“这个能退吗”→ 路由到“短期记忆（当前购物车商品）+ 长期记忆（用户会员等级，VIP免运费退货）”，过滤“OA相关上下文”；
      • 示例：用户在“企业财务场景”问“报销进度”→ 路由到“工具上下文（财务系统API）+ 长期记忆（用户部门、报销权限）”，过滤“电商订单上下文”。
技术实现：通常通过“规则引擎+LLM意图识别”结合的方式实现路由——简单场景（如“天气查询”）用规则路由，复杂场景（如“模糊需求咨询”）用LLM识别意图后路由。
参考资料：
notion image

4 机制深潜：窗口、压缩、分层、路由、评分、记忆

Context Engineering 的落地依赖六大核心机制的协同工作，这些机制共同构成了“上下文从生成到使用”的全生命周期管理流程。

4.1 窗口预算算法：控制上下文的“总量上限”

核心目标：在LLM上下文窗口限制内，合理分配各层级上下文的token配额，避免“某一层级占用过多token导致其他层级信息丢失”。

窗口预算分配逻辑

  1. 基础预算计算：
      2. 先确定“安全冗余token”（预留1k-2k token给LLM生成回答），再计算可分配给上下文的总预算：
      总上下文预算 = LLM最大窗口token数 - 安全冗余token数
      示例：GPT-4o（32k窗口）→ 总上下文预算 = 32k - 2k = 30k token。
  1. 层级配额分配：
      2. 根据业务场景动态调整各层级的token占比，以下为通用分配方案（可按需优化）：
上下文层级
通用配额占比
最大token限制
压缩策略
调整规则（场景化）
System（系统提示、工具Schema）
10%-15%
固定512-1k token
不压缩（核心规则不能丢失）
工具多的场景（如OA助理）可提升至20%
User（用户画像、历史对话）
25%-30%
动态≤5k token
关键信息提取+语义摘要
个性化场景（如个人管家）可提升至35%
World（RAG检索结果、公共知识）
30%-40%
动态≤8k token
冗余剪枝+分层摘要
知识密集场景（如投研）可提升至45%
Tool（工具API返回结果）
15%-20%
动态≤3k token
结构化提取（JSON→文本）
工具调用频繁场景（如物流查询）可提升至25%
  1. 动态调整逻辑：
      • 当某一层级无信息（如用户未调用工具），其配额自动分配给其他层级（如World层）；
      • 当某一层级信息过多（如历史对话达10k token），触发“深度压缩”（如二次摘要），确保不超过配额上限。
参考资料：
notion image

4.2 评分函数：给上下文“排优先级”

核心目标：通过量化评分，筛选出“对当前请求最有价值”的上下文切片，避免“无关信息占用token”。

评分模型设计（加权求和法）

上下文切片评分 = 0.4×相关性得分 + 0.3×时效性得分 + 0.2×重要性得分 + 0.1×个性化得分
各维度得分计算方式：
  1. 相关性得分（0-1）：
      • 计算“上下文切片文本”与“用户当前请求文本”的embedding余弦相似度；
      • 工具：Sentence-BERT（轻量）、GPT-4o Embedding（高精度）；
      • 示例：用户问“退货流程”，“退货规则”切片相关性得0.9，“下单流程”切片得0.3。
  1. 时效性得分（0-1）：
      • 基于“上下文切片生成时间”与“当前时间”的差值计算，公式：时效性得分 = 1 / (1 + (当前时间 - 切片生成时间)/3600)（单位：小时）
      • 示例：1小时前生成的切片得0.9，24小时前生成的切片得0.3，7天前生成的切片得0.1。
  1. 重要性得分（0-1）：
      • 手动标注或LLM自动判断：关键信息（如用户身份、订单号）得1.0，冗余信息（如礼貌用语）得0.2；
      • 示例：“用户是VIP会员”切片得1.0，“用户说‘谢谢’”切片得0.2。
  1. 个性化得分（0-1）：
      • 衡量切片与“用户长期画像”的匹配度：匹配度越高得分越高；
      • 示例：用户画像为“新能源汽车爱好者”，“新能源汽车优惠”切片得0.9，“燃油车优惠”切片得0.2。

评分应用：

  • 筛选：仅保留评分≥0.5的切片（可按需调整阈值）；
  • 排序：按评分降序排列，优先将高评分切片加入prompt。
参考资料：

4.3 记忆更新策略：让上下文“动态迭代”

核心目标：确保各层级记忆的“时效性”和“准确性”，避免“过时信息”或“错误信息”影响LLM判断。

各层级记忆更新逻辑

记忆层级
更新触发条件
更新频率
数据清理规则
存储介质操作
短期记忆
每轮对话结束后
实时（每轮1次）
会话结束后立即清空
内存变量重置
中期记忆
1. 每3轮对话后；2. 用户明确要求“记住”；3. 检测到关键信息（如订单号）
会话内每3-5轮1次
超时清理（默认24小时，可配置）
Redis缓存更新/删除
长期记忆
1. 用户画像变更（如会员等级升级）；2. 固定知识更新（如企业规则调整）；3. 每月定期全量更新
按需更新（如会员升级时）+ 定期更新（每月1次）
永久存储，仅在信息失效时更新（如规则废除）
MySQL/Neo4j 插入/更新

关键更新机制：

  1. 增量更新：仅更新变化的字段，避免全量覆盖（如用户手机号变更，仅更新“手机号”字段，保留其他画像信息）；
  1. 冲突解决：当新信息与旧信息冲突时，按“可信度优先级”处理：
      • 优先级：工具API返回数据（高可信度）> 用户明确输入（中）> LLM生成结论（低）；
      • 示例：LLM认为“用户是VIP”，但工具API返回“用户会员已过期”，以API数据为准更新记忆。
参考资料：

4.4 上下文处理流程

  1. 请求接入：用户发送“我的订单12345为什么还没发货？”，携带session_id（标识当前会话）；
  1. 记忆拉取：ContextManager根据session_id，从短期记忆拉取“本次会话已讨论‘订单12345’”，从长期记忆拉取“用户是VIP会员（发货优先级高）”；
  1. 路由筛选：Router识别“订单查询”意图，调用RAG检索“订单发货规则”，调用电商API获取“订单12345的物流状态（已出库，运输中）”，筛选出3个高评分切片（订单信息、物流状态、VIP发货规则）；
  1. 压缩适配：Compressor根据“GPT-4o 32k窗口预算”，将3个切片压缩（如物流状态JSON→“订单12345已出库，当前在运输中”），总token控制在2k以内；
  1. LLM调用：ContextManager组装prompt（System：“电商客服，优先使用VIP规则；User：VIP用户；World：发货规则；Tool：物流状态”），调用LLM生成回答；
  1. 记忆更新：将“本次对话（用户问订单发货，回答物流状态）”更新到中期记忆，以便后续用户追问“那什么时候能到”时复用。

5 与 RAG 的协同：不是取代，而是“升维”

Context Engineering 并非“淘汰RAG”，而是将RAG从“核心驱动”降级为“上下文来源之一”，通过“协同架构”解决RAG的固有缺陷。两者的关系可概括为：RAG是“知识供应商”，Context是“知识管理者”。

5.1 协同架构设计（核心是“RAG插件化”）

Context引擎将RAG作为“World层上下文的插件”，而非直接依赖RAG的检索结果生成回答。具体架构如下：
  • RAG的角色：仅负责“外部知识检索”，返回“检索结果切片”（含来源、内容、相关性评分）；
  • Context的角色：对RAG返回的切片进行“二次处理”——包括评分筛选（去除低相关性切片）、压缩（适配窗口）、路由（按需加入prompt）、记忆更新（将关键检索结果存入长期记忆）。

5.2 协同解决RAG痛点的案例

RAG痛点
协同解决方案
效果提升
检索噪声
Context的路由评分机制：对RAG返回的切片，按“与当前请求的相关性”重新评分，仅保留≥0.6的切片
检索噪声导致的错误率下降40%（Pinecone测试数据）
窗口爆炸
Context的压缩机制：对RAG返回的Top-10结果，先剪枝（保留Top-5），再摘要（每篇1k→300 token）
RAG相关token消耗下降60%
多轮失忆
Context的中期记忆：将RAG检索到的关键信息（如“订单发货规则”）存入中期记忆，后续对话无需重复检索
重复检索率下降75%，响应延迟降低30%
个性化缺失
Context的长期记忆：结合用户画像（如VIP），对RAG检索结果进行个性化过滤（如仅保留VIP相关规则）
个性化回答准确率提升35%（腾讯云测试数据）

5.3 协同流程示例（金融投研场景）

  1. 用户问：“贵州茅台2024年一季度营收增长多少？是否符合预期？”；
  1. Context引擎识别“需要最新财务数据+分析师预期”，调用RAG插件检索“贵州茅台2024Q1财报”和“分析师研报”；
  1. RAG返回10篇文档（5篇财报、5篇研报），相关性评分0.3-0.9；
  1. Context的Router筛选出评分≥0.7的3篇文档（2篇财报、1篇研报），Compressor将其摘要为“2024Q1营收增长15%，分析师预期12%-14%，超预期”；
  1. Context结合长期记忆中“用户是机构投资者（需详细数据）”，补充财报关键数据（如“营收1200亿元，同比+15%”）；
  1. 组装prompt调用LLM，生成回答；
  1. 将“贵州茅台2024Q1营收15%”存入长期记忆，后续用户问“茅台增速是否持续”时可直接复用。
参考资料：

6 Prompt 范式迁移：从“一次性问答”到“持续对话”

Context Engineering 的普及，推动了Prompt设计范式的根本性转变——从“面向单次请求的独立Prompt”，转向“面向持续交互的状态化Prompt”。

6.1 两种范式的核心差异

维度
一次性问答范式（RAG时代）
持续对话范式（Context时代）
Prompt结构
固定模板：System + 用户当前提问 + RAG检索结果
动态结构：System + 压缩后的历史上下文 + 当前提问 + 按需加载的World/Tool切片
信息来源
仅依赖“当前请求+RAG”，无历史状态
依赖“多层记忆+实时工具+RAG”，含完整状态
设计目标
确保单次回答的准确性
确保多轮对话的连贯性、个性化、时效性
典型示例
System：“回答用户问题，基于提供的文档。”<br>用户：“介绍GPT-4o。”<br>RAG：“GPT-4o是OpenAI 2024年发布的模型...”
System：“电商客服，优先使用用户会员权益。”<br>历史上下文：“用户是VIP，咨询订单12345。”<br>当前提问：“为什么还没发货？”<br>Tool切片：“订单12345已出库，运输中。”

6.2 持续对话范式的设计原则

  1. 状态显性化：将关键状态（如用户身份、订单号、历史结论）以“结构化字段”嵌入Prompt，而非隐藏在文本中。
      • 示例：[用户属性：VIP会员，订单号：12345] [历史结论：订单已出库]
  1. 冗余最小化：仅保留“影响当前判断”的历史信息，避免重复拼接无关对话。
      • 反例：拼接10轮前的“问候语”；
      • 正例：仅保留“与当前订单相关的2轮对话摘要”。
  1. 工具结果结构化：将工具返回的JSON/CSV转换为“自然语言+关键字段”，降低LLM理解成本。
      • 示例：工具返回{"order_id":12345,"status":"shipped","time":"2024-05-20"}→ 转换为“订单12345（状态：已发货，发货时间：2024-05-20）”。

6.3 范式迁移的技术支撑

  • ContextManager的动态组装能力：自动根据当前请求调整Prompt结构，无需人工编写固定模板；
  • 压缩引擎的语义保留能力：确保历史上下文压缩后，关键状态不丢失；
  • 记忆层的状态延续能力：跨轮次保留用户属性、历史结论等核心信息。
参考资料：

7 场景化落地设计方案

Context Engineering 的价值需通过具体业务场景落地体现，以下为三大核心场景的详细设计方案，涵盖“需求痛点、架构设计、流程步骤、关键配置”。

7.1 场景一：智能客服（电商领域）

7.1.1 核心需求与痛点

  • 需求：用户咨询订单、退货、售后等问题，需结合历史对话、订单数据、会员权益，提供连贯、个性化的回答；
  • 痛点：多轮失忆（用户重复提问）、个性化缺失（VIP用户未享专属服务）、时效差（订单状态未实时更新）。

7.1.2 架构设计

上下文层级
数据来源
核心字段/内容
生命周期
压缩策略
短期记忆
本次会话对话
当前咨询的订单号、用户临时需求（如“加急处理”）
会话内
关键信息提取（仅保留订单号、需求类型）
中期记忆
近7天会话摘要
未解决的问题（如“上次咨询退货未完成”）、用户偏好（如“喜欢线下退货”）
7天
语义摘要（每轮对话→100字以内摘要）
长期记忆
用户画像系统
会员等级（VIP/普通）、历史售后记录（如“近3个月无退货”）、收货地址
永久
结构化存储（字段级更新，不压缩）
World层
电商FAQ库、帮助中心
退货规则、发货时效、会员权益说明
按需更新（规则变更时）
冗余剪枝（仅保留与当前问题相关的规则片段）
Tool层
订单API、物流API、售后API
订单状态、物流进度、售后申请进度
实时（每次请求调用）
结构化转换（JSON→自然语言+关键字段）

7.1.3 关键流程（以“VIP用户咨询订单退货”为例）

  1. 请求接入：用户发送“我的订单67890能退货吗？我是VIP”，携带session_id；
  1. 记忆拉取：
      • 短期记忆：拉取“本次会话已提及‘订单67890’”；
      • 长期记忆：拉取“用户是VIP会员（免运费退货，7天无理由）”；
  1. 路由筛选：
      • 识别“退货咨询”意图，调用订单API获取“订单67890（已签收，购买时间3天前）”；
      • 调用RAG检索“VIP退货规则”，返回“VIP用户签收后7天内可无理由退货，免运费”；
      • 筛选出评分≥0.8的切片：订单状态、VIP退货规则；
  1. 压缩适配：
      • 将订单API返回的JSON（200 token）压缩为“订单67890（已签收，购买3天）”（50 token）；
      • 将RAG规则（500 token）压缩为“VIP用户7天无理由退货，免运费”（80 token）；
  1. LLM调用：
      • 组装Prompt：System（电商客服，优先VIP规则）+ User（VIP用户，订单67890）+ Tool（订单状态）+ World（VIP退货规则）；
      • LLM生成回答：“您的订单67890（已签收3天）符合VIP退货条件，支持7天无理由退货，退货运费由平台承担，点击【退货申请】即可操作。”；
  1. 记忆更新：将“用户咨询订单67890退货，符合条件”更新到中期记忆，后续用户问“怎么申请”时直接复用。

7.1.4 关键配置

  • 窗口预算：GPT-4o（32k窗口）→ 总预算28k，System层512 token，User层8k，World层12k，Tool层5k；
  • 评分阈值：0.5（仅保留评分≥0.5的切片）；
  • TTL配置：中期记忆7天，短期记忆会话结束清空。
参考资料：

7.2 场景二：B端 OA 助理（企业领域）

7.2.1 核心需求与痛点

  • 需求：员工查询年假、工资单、审批进度，提交请假/报销申请，需结合企业OA数据、员工身份权限，提供合规、精准的服务；
  • 痛点：工具混乱（OA系统多，API格式不一）、权限管控严（不同部门员工权限不同）、信息保密（工资等敏感数据需加密）。

7.2.2 架构设计

上下文层级
数据来源
核心字段/内容
生命周期
压缩策略
安全措施
短期记忆
本次会话对话
当前申请的审批单号、员工临时需求（如“加急审批”）
会话内
关键信息提取
内存加密存储
中期记忆
近30天审批记录
未完成的审批（如“报销审批中”）、历史申请结果
30天
语义摘要+结构化字段
Redis加密存储
长期记忆
企业HR系统、权限系统
员工部门、职位、年假额度、薪资等级、审批权限
永久
结构化存储（字段级）
数据库加密+权限控制
World层
企业OA规则库、制度文档
年假规则、报销标准、审批流程
按需更新（制度变更时）
规则片段提取
文档权限管控
Tool层
年假API、工资API、审批API
年假剩余天数、工资单详情、审批进度
实时调用
JSON→结构化文本
API调用加密

7.2.3 关键流程（以“员工查询年假剩余天数”为例）

  1. 请求接入：员工发送“我还剩多少天年假？”，携带员工ID（关联权限）；
  1. 记忆拉取：
      • 长期记忆：拉取“员工A（产品部，2020年入职，年假额度15天，已用5天）”；
      • 中期记忆：拉取“员工A去年未休年假3天，可结转至今年”；
  1. 路由筛选：
      • 识别“年假查询”意图，调用年假API获取“2024年已用年假5天，结转3天”；
      • 调用RAG检索“企业年假规则”，返回“结转年假需在次年3月前使用”；
      • 筛选出评分≥0.8的切片：年假API数据、结转规则；
  1. 压缩适配：
      • 将API返回的JSON（300 token）压缩为“2024年已用5天，结转3天”（60 token）；
      • 将RAG规则（400 token）压缩为“结转年假需在2025年3月前使用”（70 token）；
  1. LLM调用：
      • 组装Prompt：System（OA助理，严格按权限返回数据，敏感信息脱敏）+ User（员工A，产品部，2020入职）+ Tool（年假数据）+ World（结转规则）；
      • LLM生成回答：“您好！您2024年年假额度15天，已使用5天，剩余10天（含去年结转3天）。请注意：结转的3天需在2025年3月前使用，逾期失效。”；
  1. 记忆更新：将“员工A查询2024年假剩余10天”更新到中期记忆，后续用户问“如何申请年假”时复用。

7.2.4 关键配置

  • 窗口预算： Claude 3 Opus（100k窗口）→ 总预算95k，System层1k（含权限规则），User层15k，World层20k，Tool层10k；
  • 评分阈值：0.6（OA场景对准确性要求高，提高阈值）；
  • 安全配置：所有敏感数据（工资、身份证）脱敏显示，API调用需员工ID鉴权。
参考资料：

7.3 场景三：C端 个人管家（生活服务领域）

7.3.1 核心需求与痛点

  • 需求：用户管理电商订单、物流、账单、购物车，获取个性化推荐（如“常买的牛奶补货了”），需结合多平台数据（淘宝、京东、美团），提供一站式服务；
  • 痛点：数据分散（多平台账号独立）、个性化弱（推荐与用户偏好不符）、实时性差（物流状态未实时同步）。

7.3.2 架构设计

上下文层级
数据来源
核心字段/内容
生命周期
压缩策略
短期记忆
本次会话对话
当前关注的订单/物流单号、临时需求（如“提醒收货”）
会话内
关键信息提取
中期记忆
近14天订单/物流记录
待收货订单、待付款账单、近期购物偏好（如“常买牛奶”）
14天
语义摘要+关键词提取
长期记忆
多平台用户画像（淘宝/京东）
购物偏好（如“喜欢低脂牛奶”）、收货地址、支付习惯（如“优先微信支付”）
永久
结构化存储+偏好标签
World层
电商平台商品库、促销信息
商品详情、促销活动（如“618满减”）、物流规则
实时更新（促销变更时）
商品关键信息提取（名称、价格、促销）
Tool层
电商API、物流API、账单API
订单状态、物流进度、账单金额、购物车商品
实时调用
JSON→自然语言（含关键字段）

7.3.3 关键流程（以“用户查询淘宝订单物流”为例）

  1. 请求接入：用户发送“我淘宝买的牛奶到哪了？”，携带个人管家账号（关联淘宝账号）；
  1. 记忆拉取：
      • 长期记忆：拉取“用户偏好‘低脂牛奶’，常用收货地址‘北京市朝阳区XX小区’”；
      • 中期记忆：拉取“用户3天前在淘宝购买‘某品牌低脂牛奶’，订单号78901”；
  1. 路由筛选：
      • 识别“物流查询”意图，调用淘宝物流API获取“订单78901（物流单号YT12345，当前在朝阳区派送中，预计1小时内送达）”；
      • 调用RAG检索“物流派送规则”，返回“朝阳区派送时间9:00-18:00”；
      • 筛选出评分≥0.8的切片：物流API数据、派送规则；
  1. 压缩适配：
      • 将API返回的JSON（400 token）压缩为“订单78901（牛奶），物流YT12345，朝阳区派送中，预计1小时内到”（80 token）；
      • 将RAG规则（300 token）压缩为“朝阳区派送时间9:00-18:00”（50 token）；
  1. LLM调用：
      • 组装Prompt：System（个人管家，结合用户偏好推荐）+ User（偏好低脂牛奶，地址朝阳）+ Tool（物流数据）+ World（派送规则）；
      • LLM生成回答：“您3天前购买的‘某品牌低脂牛奶’（订单78901），当前物流单号YT12345，已在朝阳区派送中，预计1小时内送达（朝阳区派送时间9:00-18:00）。您常买的这款牛奶目前有补货，需要提醒您下单吗？”；
  1. 记忆更新：将“订单78901物流状态（派送中）”更新到中期记忆，同时将“用户可能需要补货”的偏好标签更新到长期记忆。

7.3.4 关键配置

  • 窗口预算：GPT-4o（32k窗口）→ 总预算28k，System层512 token，User层10k，World层8k，Tool层8k；
  • 评分阈值：0.5；
  • TTL配置：中期记忆14天，短期记忆会话结束清空；
  • 个性化配置：长期记忆每7天更新一次用户偏好标签。
参考资料：

8 常见误区与最佳实践

Context Engineering 落地过程中，容易因对“上下文治理逻辑”理解不深导致效果不佳。以下总结六大常见误区及对应的最佳实践。

8.1 常见误区

  1. 误区1：过度依赖LLM进行上下文压缩
      • 问题：所有上下文切片均用大模型（如GPT-4）压缩，导致成本过高（压缩阶段token消耗占比达40%）；
      • 案例：某项目用GPT-4压缩所有历史对话，月成本超10万元，远超预期。
  1. 误区2：记忆层级混淆
      • 问题：将“短期临时信息”（如本轮对话的临时需求）存入长期记忆，导致长期记忆冗余；或将“长期用户属性”（如会员等级）存入短期记忆，会话结束后丢失；
      • 案例：某客服项目将用户“本次需要加急处理”的临时需求存入长期记忆，后续所有对话均优先“加急”，导致资源浪费。
  1. 误区3：路由规则过于简单
      • 问题：仅用“关键词匹配”路由，无法处理模糊需求（如用户问“这个东西怎么弄”）；
      • 案例：用户问“我的报销怎么还没好”，关键词“报销”路由到“OA报销API”，但未识别“‘我的’需要关联用户身份”，导致返回“请提供报销单号”。
  1. 误区4：忽略上下文的时效性
      • 问题：未设置TTL（存活时间），过时信息（如过期的促销活动）仍被调用；
      • 案例：某电商项目未清理“618促销”的上下文切片，7月仍推荐“618满减”，导致用户投诉。
  1. 误区5：安全管控缺失
      • 问题：敏感上下文（如工资、身份证）未加密，或未按权限过滤；
      • 案例：某企业OA项目未做权限控制，普通员工可查询其他部门的工资数据，引发数据泄露。
  1. 误区6：未做上下文质量监控
      • 问题：未监控上下文的“评分分布”“压缩率”“冗余度”，导致低质量上下文（评分<0.3）进入prompt，影响LLM回答；
      • 案例：某项目因未监控评分，大量低相关性RAG结果进入prompt，LLM回答错误率上升25%。

8.2 最佳实践

  1. 分层压缩策略
      • 轻量信息（如工具返回的简短数据）用规则压缩（如JSON→文本）；
      • 中量信息（如3轮对话）用小模型压缩（如GPT-4o-mini、Llama 3）；
      • 大量信息（如10轮对话、长文档）用大模型压缩（如GPT-4o）；
      • 效果：压缩成本降低50%-70%。
  1. 明确记忆层级划分标准
      • 制定“记忆层级归属表”，明确各类型信息的存储层级：
          • 信息类型
          存储层级
          TTL
          用户会员等级
          长期记忆
          永久
          本次会话临时需求
          短期记忆
          会话内
          近30天审批记录
          中期记忆
          30天
      • 技术保障：在ContextManager中添加“层级校验逻辑”，防止错存。
  1. 规则+LLM混合路由
      • 简单场景（如“天气查询”“订单查询+明确单号”）用规则路由（关键词+字段匹配）；
      • 复杂场景（如“模糊需求”“多意图混合”）用LLM意图识别后路由（如调用GPT-4o-mini识别“用户问‘这个怎么弄’指‘报销申请’”）；
      • 效果：路由准确率提升至95%以上。
  1. 动态TTL与定期清理
      • 按信息类型设置动态TTL：
        • 实时数据（物流、股价）：TTL=10分钟；
        • 促销信息：TTL=活动结束时间；
        • 用户临时需求：TTL=会话结束；
      • 定期清理：每天凌晨清理过期的中期/短期记忆切片，避免冗余。
  1. 全链路安全管控
      • 传输安全：API调用用HTTPS，敏感数据加密传输；
      • 存储安全：长期记忆（数据库）加密，短期记忆（内存）脱敏；
      • 权限控制：基于用户角色过滤上下文（如普通员工仅能查看自己的工资数据）；
      • 审计日志：记录所有上下文的“拉取/更新/使用”操作，便于追溯。
  1. 上下文质量监控指标
      • 核心监控指标：
          • 指标
          含义
          阈值
          切片平均评分
          进入prompt的切片评分均值
          ≥0.6
          压缩率
          压缩后token数/压缩前token数
          ≤50%
          冗余率
          重复切片数/总切片数
          ≤5%
      • 告警机制：当指标超出阈值时（如平均评分<0.5），触发告警并自动降级（如增加人工审核）。
参考资料：

9 参考文献

9.1 官方文档与技术白皮书

  1. Context-Engineering 官方Wiki
      2. https://github.com/davidkimai/Context-Engineering/wiki
      • 核心内容：分层记忆设计、记忆更新策略、最佳实践案例；
  1. LangChain 官方文档（Context相关）
      • 核心内容：LangChain的上下文管理组件、RAG与Context协同方案；
  1. OpenAI 上下文窗口管理指南
      2. https://platform.openai.com/docs/guides/context-window
      • 核心内容：上下文窗口分配、压缩策略、多轮对话设计；
  1. Pinecone 2024 RAG落地报告
      2. https://www.pinecone.io/resources/state-of-rag-2024/
      • 核心内容：RAG的痛点分析、Context-Aware系统的演进方向；

9.2 优质技术博客与专栏

  1. Anthropic 技术博客：《Memory Systems for Long-Term Agent Interaction》
      2. https://www.anthropic.com/index/memory-systems-for-long-term-agent-interaction
      • 核心内容：长期记忆系统设计、上下文路由算法；
      • 特点：结合Anthropic Claude的实践经验，理论与实战结合。
  1. 美团技术团队：《个人管家的上下文治理实践》
      2. https://tech.meituan.com/2024/03/15/personal-butler-design.html
      • 核心内容：C端场景的上下文分层、个性化适配方案；
      • 特点：国内大厂实战案例，贴近业务落地。
  1. 钉钉开放平台：《OA助理的上下文安全设计》
      2. https://open.dingtalk.com/document/orgapp/oa-assistant-design
      • 核心内容：B端场景的上下文权限控制、敏感数据保护；

9.3 学术论文与研究报告

  1. 《Context-Aware Language Models for Conversational Agents》（2024）
      2. https://arxiv.org/abs/2402.10618
      • 作者：Anthropic团队；
      • 核心内容：上下文感知模型的架构设计、路由算法的数学原理。
  1. 《Memory-Efficient Context Compression for Large Language Models》（2024）
      2. https://arxiv.org/abs/2401.08500
      • 作者：Stanford AI Lab；
      • 核心内容：高效上下文压缩算法、token节省与语义保留的平衡。
  1. 《The State of Context Engineering in 2024》（Gartner报告）
      2. https://www.gartner.com/en/documents/4025387
      • 核心内容：Context Engineering的行业应用现状、未来趋势预测；
Keycloak 客户端授权服务从RAG到Context Engineering：重新定义AI系统的认知能力边界
Loading...
目录
0%
Honesty
Honesty
花有重开日,人无再少年.
统计
文章数:
115
目录
0%