Context-Engineering-技术博客

Context Engineering不是 Prompt 写得不够好是你给 AI 的上下文没整对从调 Prompt到工程化上下文这才是大模型应用开发的正确打开方式。一、先讲个扎心的场景假设你正在做一个智能客服系统用户问了一句“这个订单怎么还没发货”你把这句话直接丢给 GPT-4它大概率会回你一段请您耐心等待一般 3-5 个工作日发货这种正确的废话。为啥因为你没告诉它这个用户是谁订单号是多少当前订单状态是啥你们公司的发货规则是什么之前客服有没有跟进过说白了AI 不是不会答是你没给它足够的上下文让它做出精准判断。这就是今天咱们要聊的 ——Context Engineering上下文工程。二、Context Engineering 到底是什么2.1 一句话定义Context Engineering 系统化地构建、组织、检索和注入上下文信息让大模型在足够的信息基础上做出高质量决策。注意关键词是**“系统化和工程化”**。不是写 Prompt 时随手加几句背景说明而是一套可复用、可扩展、可维护的架构实践。2.2 跟 Prompt Engineering 啥区别维度Prompt EngineeringContext Engineering关注点怎么写提示词怎么准备和组织信息核心动作调措辞、加示例、设角色检索数据、构建上下文、管理 Token复杂度单点优化系统工程可复用性低换场景重写高框架化复用打个比方Prompt Engineering像是你教一个聪明人怎么说话更得体Context Engineering像是你给这个聪明人配了一个情报团队确保他做任何决策前都有充足的情报支持。再聪明的脑子没有好情报也是白搭。三、Context Engineering 的核心挑战在动手之前咱们得搞清楚问题到底出在哪。我总结了三个核心痛点3.1 信息太多Token 天花板压死人GPT-4 的上下文窗口是 128K听起来挺大对吧但一个中等规模的代码库、一套完整的产品文档、一个用户的全量历史记录 —— 随便哪个都能轻松撑爆。问题来了怎么在有限的 Token 里塞最有价值的信息3.2 信息太杂噪声淹没信号你塞给 AI 的上下文里可能 80% 是无关信息。比如用户问怎么退款你把整本用户手册都丢进去AI 反而会在无关章节里迷路。问题来了怎么做到精准检索只给 AI 它需要的那部分3.3 信息太旧世界在变上下文没变大模型的知识有截止日期你的业务数据更是实时变化的。昨天刚更新的价格策略、刚刚下单的订单状态 —— 这些新鲜情报怎么及时注入问题来了怎么让上下文活起来而不是一潭死水四、怎么做 Context Engineering四步走好了痛点清楚了咱们上方案。我把 Context Engineering 拆成四个核心环节┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ 1. 上下文 │ - │ 2. 上下文 │ - │ 3. 上下文 │ - │ 4. 上下文 │ │ 识别 │ │ 检索 │ │ 组装 │ │ 注入 │ │ (Context │ │ (Context │ │ (Context │ │ (Context │ │ Identification)│ │ Retrieval) │ │ Assembly) │ │ Injection) │ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘咱们逐个击破。Step 1上下文识别 —— 先搞清楚需要啥这一步的核心是根据用户输入判断解决当前问题需要哪些类型的信息。举个栗子 # 伪代码上下文识别逻辑defidentify_context_requirements(user_query,user_id): 分析用户问题识别需要哪些上下文 # 先用一个小模型/规则引擎做意图识别intentclassify_intent(user_query)# 比如查询订单状态# 根据意图确定需要哪些上下文required_contexts[]ifintentorder_status_query:required_contexts[ContextType.USER_PROFILE,# 用户基本信息ContextType.ORDER_DETAILS,# 订单详情ContextType.SHIPPING_POLICY,# 发货政策ContextType.RECENT_TICKETS# 近期工单记录]elifintentrefund_request:required_contexts[ContextType.USER_PROFILE,ContextType.ORDER_DETAILS,ContextType.REFUND_POLICY,# 退款政策ContextType.PAYMENT_INFO# 支付信息]returnrequired_contexts关键点不要一股脑把所有信息都塞进去。先判断这个问题需要啥按需索取。Step 2上下文检索 —— 精准找到要啥给啥识别完需要什么下一步就是去各个数据源里捞信息。这里 RAGRetrieval-Augmented Generation是主力方案。# 伪代码多路上下文检索defretrieve_contexts(requirements,user_id): 根据需求从多个数据源检索上下文 contexts{}forreqinrequirements:ifreqContextType.USER_PROFILE:# 从用户服务查contexts[user]user_service.get_profile(user_id)elifreqContextType.ORDER_DETAILS:# 从订单服务查可能需要先提取订单号order_idextract_order_id(user_query)# NER 提取contexts[order]order_service.get_details(order_id)elifreqContextType.REFUND_POLICY:# 从向量数据库检索相关策略文档contexts[policy]vector_db.search(queryuser_query,collectionrefund_policies,top_k3# 只取最相关的 3 条)elifreqContextType.RECENT_TICKETS:# 从客服系统查近期工单contexts[tickets]ticket_service.get_recent(user_id,limit5)returncontexts这里有几个实用技巧多路召回不要只依赖向量检索结构化查询SQL/API 向量检索 关键词匹配可以互补。重排序Rerank召回 20 条用更精细的模型排个序只保留 Top 5。摘要压缩如果检索到的文档太长先用小模型做摘要再塞进上下文。Step 3上下文组装 —— 把零散信息拼成一盘菜检索回来的信息是零散的需要按一定结构组装让大模型能读得懂、用得上。我推荐一个实用的结构模板【系统角色】 你是 XX 公司的智能客服助手负责处理用户咨询。 【当前时间】 2026-04-30 20:30:00 【用户信息】 - 用户 IDU12345 - 会员等级VIP3 - 注册时长2 年 【用户问题】 这个订单怎么还没发货 【相关订单信息】 订单号O98765 下单时间2026-04-28 14:20:00 商品XXX 手机壳 x2 当前状态待发货仓库拣货中 预计发货2026-04-30 18:00 前 【发货政策】 - 普通商品24 小时内发货 - 预售商品按页面标注时间发货 - VIP 用户优先发货 【历史工单】 - 2026-04-29用户咨询发货时间已告知预计 4/30 发货 【回答要求】 - 语气友好直接回答用户问题 - 如果有延迟说明原因并给出补偿方案 - 不要编造不存在的信息组装时的几个原则结构化优于平铺用标题、列表、表格组织别堆成一大段文字。重要性排序把最关键的信息放前面大模型对上下文开头更敏感。Token 预算管理给每个模块设 Token 上限超长的自动截断或摘要。# 伪代码上下文组装 Token 预算控制defassemble_context(contexts,max_tokens4000): 按优先级组装上下文严格控制 Token 数 # 定义各模块的 Token 预算按优先级排序budget{system_role:200,user_info:300,user_query:200,order_info:800,# 订单信息最关键给最多预算policy:600,tickets:500,instructions:300}assembled[]total_tokens0forsection,limitinbudget.items():contentformat_section(section,contexts.get(section))# 截断到预算范围内truncatedtruncate_to_tokens(content,limit)assembled.append(truncated)total_tokenscount_tokens(truncated)iftotal_tokensmax_tokens:breakreturn\n\n.join(assembled)Step 4上下文注入 —— 优雅地喂给大模型组装好的上下文最终要通过 API 调用喂给大模型。这里有几个工程实践4.1 多轮对话中的上下文管理# 伪代码对话历史的上下文管理classConversationManager:def__init__(self,max_history10):self.max_historymax_history# 保留最近 N 轮self.history[]defbuild_messages(self,current_query,retrieved_contexts): 构建完整的 messages 数组 messages[]# 1. System Prompt 检索到的上下文system_contentassemble_context(retrieved_contexts)messages.append({role:system,content:system_content})# 2. 精简后的对话历史避免 Token 爆炸forturninself.get_compressed_history():messages.append({role:user,content:turn[user]})messages.append({role:assistant,content:turn[assistant]})# 3. 当前用户输入messages.append({role:user,content:current_query})returnmessagesdefget_compressed_history(self): 对话历史压缩太久远的用摘要替代原文 recentself.history[-3:]# 最近 3 轮保留原文olderself.history[:-3]# 更早的做摘要ifolder:summarysummarize_turns(older)# 用小模型摘要return[{user:[历史对话摘要],assistant:summary}]recentreturnrecent4.2 动态上下文更新有些场景下上下文不是一次性的而是需要根据 AI 的回复动态补充# 伪代码动态上下文补充工具调用场景defhandle_with_tools(user_query,initial_context):# 第一轮给基础上下文让 AI 决定要不要调工具responsellm.chat(messagesbuild_messages(user_query,initial_context),tools[search_order,check_inventory,contact_human]# 可用工具)# AI 决定调用 check_inventory 查库存ifresponse.tool_calls:tool_resultexecute_tool(response.tool_calls[0])# 把工具返回的结果补充进上下文再调一次updated_contextinitial_contextf\n\n【工具查询结果】\n{tool_result}final_responsellm.chat(messagesbuild_messages(user_query,updated_context))returnfinal_response五、进阶Context Engineering 的架构模式当你把 Context Engineering 做到一定规模可以考虑这些架构模式5.1 分层上下文架构┌─────────────────────────────────────┐ │ Layer 3: 动态上下文每次请求生成 │ │ - 检索结果、实时数据、工具返回 │ ├─────────────────────────────────────┤ │ Layer 2: 会话上下文跨轮次保持 │ │ - 对话历史、用户状态、临时变量 │ ├─────────────────────────────────────┤ │ Layer 1: 静态上下文预加载/缓存 │ │ - 系统 Prompt、产品文档、知识库 │ └─────────────────────────────────────┘静态层启动时加载变化少可缓存会话层存在 Redis 里跟着 session 走动态层每次请求实时检索最灵活也最耗资源。5.2 上下文版本管理业务规则变了上下文模板也得跟着变。建议给上下文模板加版本号CONTEXT_TEMPLATE_V1...# 旧版本CONTEXT_TEMPLATE_V2...# 新版本加了售后政策模块# 按用户/AB 实验切换版本versionget_context_version(user_id)templateCONTEXT_TEMPLATES[version]5.3 上下文效果评估怎么知道你的上下文工程有没有效果建议跟踪这几个指标指标说明回答准确率人工标注或自动化测试集评估Token 利用率有效信息 / 总 Token 数越高越好检索命中率检索到的内容被 AI 引用的比例响应延迟上下文检索和组装耗时六、实用范例与模板直接抄作业好了理论讲完了咱们来点能直接复制粘贴的干货。下面是我实际项目中沉淀的几个模板覆盖了最常见的场景。模板 1智能客服系统上下文模板适用场景电商/服务平台的智能客服【系统角色】 你是 {company_name} 的智能客服助手负责解答用户咨询、处理售后问题。 回答要求语气友好、信息准确、不编造事实。如果无法解决主动引导转人工。 【当前时间】 {current_time} 【用户信息】 - 用户 ID{user_id} - 昵称{user_nickname} - 会员等级{vip_level} - 注册时间{register_date} - 近期订单数{recent_order_count} 【用户当前问题】 {user_query} 【相关订单信息】如用户提到订单 订单号{order_id} 商品{product_name} x{quantity} 下单时间{order_time} 订单状态{order_status} 物流单号{tracking_number} 预计送达{estimated_delivery} 【适用政策】 {retrieved_policies} 【历史服务记录】最近 3 条 {recent_tickets} 【可用操作】 - 查询订单状态 - 申请退款/退货 - 修改收货地址 - 转接人工客服工作时段9:00-22:00使用说明大括号{}是占位符实际使用时替换为真实数据如果某模块无数据如用户没提到订单直接省略该模块别留空retrieved_policies通过向量检索动态获取只放最相关的 2-3 条模板 2代码审查助手上下文模板适用场景AI 辅助 Code Review【系统角色】 你是一名资深 {language} 开发工程师擅长代码审查。请对以下代码变更进行审查重点关注 1. 潜在的 Bug 和逻辑错误 2. 性能隐患 3. 安全漏洞SQL 注入、XSS 等 4. 代码规范和可读性 5. 是否有更优雅的实现方式 输出格式按优先级列出问题每条包含问题描述、风险等级高/中/低、修改建议。 【项目背景】 - 项目{project_name} - 技术栈{tech_stack} - 相关模块{module_name} 【代码变更上下文】 变更文件{changed_files} 相关依赖文件供参考 {related_files} 【本次 Diff】 diff {diff_content}【审查历史】同一 PR 的前几轮审查{review_history}**使用说明** - related_files 通过代码依赖分析或向量检索获取帮助 AI 理解调用关系 - diff_content 如果太长先按文件拆分分别审查 - review_history 避免重复提出已解决的问题 --- ### 模板 3数据分析助手上下文模板 适用场景自然语言查询数据库/BI 系统【系统角色】你是数据分析师擅长将用户问题转化为 SQL 查询并解读结果。数据库类型{db_type}MySQL/PostgreSQL/ClickHouse 等【数据库 Schema】仅包含相关表{relevant_tables}【表关系说明】{table_relationships}【常用查询范例】{query_examples}【用户问题】{user_question}【当前查询的上下文】时间范围{time_range}用户权限只能访问 {accessible_tables}数据更新频率{refresh_frequency}【输出要求】先生成 SQL注释说明每一步意图假设查询结果如下{mock_result}请用中文解读如果问题模糊先列出可能的理解方式供用户选择**使用说明** - relevant_tables 通过 Schema Embedding 检索只放跟用户问题相关的表 - query_examples 是 Few-shot 示例放 2-3 条同类问题的 SQL - 必须做权限校验防止越权查询敏感表 --- ### 模板 4多轮对话状态追踪模板 适用场景需要跨轮次保持业务状态的复杂对话 python # 伪代码对话状态管理 class DialogueState: 维护多轮对话中的业务状态 def __init__(self): self.slots {} # 已收集的槽位 self.intent None # 当前意图 self.history [] # 对话历史 self.pending_action None # 待执行的操作 def to_context(self) - str: 将状态转换为上下文字符串 parts [] # 意图 if self.intent: parts.append(f【当前意图】{self.intent}) # 已收集的信息 if self.slots: parts.append(【已确认信息】) for key, value in self.slots.items(): parts.append(f- {key}{value}) # 还缺什么 missing self.get_missing_slots() if missing: parts.append(f【待收集信息】{, .join(missing)}) # 对话摘要太久远的轮次 if len(self.history) 6: parts.append(f【 earlier 对话摘要】{self.summarize_old_turns()}) # 最近 3 轮原文 recent self.history[-3:] if recent: parts.append(【最近对话】) for turn in recent: parts.append(f用户{turn[user]}) parts.append(f助手{turn[assistant]}) return \n.join(parts) def get_missing_slots(self) - List[str]: 根据意图返回还缺哪些必填槽位 required { book_flight: [出发地, 目的地, 出发日期], refund: [订单号, 退款原因], # ... } return [s for s in required.get(self.intent, []) if s not in self.slots]使用说明每轮对话开始时把DialogueState.to_context()拼进 System Prompt槽位收集齐后执行pending_action然后清空状态意图切换时用户突然改需求要有状态重置机制模板 5RAG 检索结果组装模板适用场景知识库问答把检索到的文档片段组装进上下文defformat_retrieved_chunks(chunks:List[Chunk],query:str)-str: 将检索到的文档片段格式化为上下文 ifnotchunks:return【相关知识库】未检索到相关内容parts[【相关知识库】以下是从知识库检索到的内容请基于这些信息回答]fori,chunkinenumerate(chunks,1):# 标注来源方便溯源和可信度判断source_infof[来源{chunk.source}| 相关度{chunk.score:.2f}]parts.append(f\n--- 片段{i}{source_info}---)parts.append(chunk.content)# 如果片段有元数据如发布时间也加上ifchunk.metadata:parts.append(f[元数据{chunk.metadata}])parts.append(\n---)parts.append(注意如果以上信息不足以回答问题请明确说明不要编造。)return\n.join(parts)使用说明一定要标注来源和相关度分数帮助 AI 判断信息可信度检索结果按相关度排序最相关的放前面最后加一句不要编造的提醒降低幻觉风险模板 6Token 预算分配速查表实际项目中不同场景的 Token 分配策略场景总 Token 预算System Prompt检索上下文对话历史用户输入预留输出客服问答8K5003K2K5002K代码审查16K8008K1K2K4K数据分析8K6002K1K5004K长文档摘要32K40020K050011K多 Agent 协作16K1K6K4K1K4K原则输出预留要充足别为了塞上下文把回答空间挤没了对话历史超过预算时优先摘要旧轮次保留最近 2-3 轮原文检索上下文超过预算时用 Rerank 精排后截断别均匀截断七、总结从写 Prompt到做工程咱们来回顾一下 Context Engineering 的核心要点识别先搞清楚解决当前问题需要哪些信息检索从多个数据源精准召回相关内容组装结构化拼接做好 Token 预算管理注入通过 API 优雅地喂给大模型支持多轮和动态更新。上面给的 6 个模板覆盖了客服、代码审查、数据分析、多轮对话、RAG 组装、Token 预算这几个高频场景。建议收藏需要时直接改改占位符就能用。最后想说几句心里话早期玩大模型的时候我也沉迷过Prompt 调参——换个说法、加个示例、调整温度参数试图让 AI 更听话。但后来发现真正决定输出质量的往往不是 Prompt 怎么写而是你给 AI 准备了什么样的情报。Context Engineering 就是把准备情报这件事从随手写写升级为系统化工程。当你的应用从 Demo 走向生产从单一场景扩展到复杂业务这一步是绕不开的。你在做大模型应用开发的时候是怎么处理上下文管理的有没有遇到过 Token 不够、信息噪声大之类的坑上面这些模板对你有帮助吗欢迎在评论区交流参考资料Anthropic: Contextual Retrieval (2024)—— Anthropic 提出的上下文检索优化方案通过上下文感知分块显著提升 RAG 效果OpenAI: RAG Best Practices—— OpenAI 官方 RAG 最佳实践指南涵盖检索策略、提示工程与评估方法LangChain: Context Management Patterns—— LangChain 检索与上下文管理的核心概念与实现模式Google: Long Context vs. RAG—— 长上下文窗口与 RAG 的对比研究帮你判断什么场景该用哪种方案LLM Context Window Management—— Pinecone 的 RAG 系列教程从向量检索到上下文组装讲得很系统