上下文工程实战指南：从Prompt优化到RAG与Agent落地-北京尧图网络

前阵子拿到一份70页的技术文档主题是“上下文工程”。第一次翻开的时候说实话有点头皮发麻术语密、图表多、示例代码页页都有读完一遍感觉好像都看过了但真要我在项目里复用又不知道从哪里下手。冷静下来重新过了一遍之后我觉得这70页里有不少东西值得拉出来讲清楚。如果你最近在做大模型相关的工作——不管是客服机器人、知识库问答、代码助手还是Agent流程编排——上下文工程都是绕不过去的一环。文档里最核心的一句话可以概括为模型本身只是计算引擎上下文才是内存系统表现得聪明还是蠢很大程度上取决于你往内存里放了什么、怎么放。这篇文章我会用拆PPT的方式来解读这70页每讲一个主题我会说它解决什么问题、在真实项目里怎么落地以及我自己踩过的一些坑。适合正在做LLM应用开发的工程师也适合想系统理解“提示词之外的东西”的算法同学。1. 全文核心认知上下文工程到底在解决什么问题1.1 从“能对话”到“稳定交付”的跨越先说一个背景。很多人刚接触大模型应用时会觉得“对话能跑通”就等于“任务完成了”。写一个Prompt模型能回答就交给业务方。但真上线后会发现问题根本不在“会不会说”而在“能不能稳定地做好一件事”。上下文工程这个概念之所以出现就是因为它补上了中间那段空白怎么把业务目标、参考资料、对话历史、工具定义这些信息有条理地组织起来让模型在每一次推理时都能拿到“够用且不乱”的信息。文档里给过一个类比让我印象很深如果我们把大模型看成一台高性能发动机上下文就是油路系统。发动机本身马力再大油路设计得乱七八糟燃油供应不稳定车照样跑不快、跑不稳。上下文工程就是设计油路的那套方法论。1.2 三层上下文系统级、任务级、会话级这70页文档里我读过之后受益最大的一个框架是把上下文按作用范围拆成三层。这个问题不拆开后面很容易混成一锅粥。第一层是系统级上下文。它负责定义模型的“人设”和“边界”比如“你是一个电商客服助手”“你只回答和订单相关的问题”“遇到退货问题要引导到售后流程”。这部分内容在整个会话生命周期里相对稳定相当于公司的新员工培训手册。第二层是任务级上下文。它负责支撑“当前这一次请求”所需的信息比如用户查询的商品数据、库存信息、优惠规则、参考文档片段。这部分是动态的每次请求可能都不一样。第三层是会话级上下文。它记录“到目前为止发生了什么”包括用户的提问历史、之前是否已经提供过地址、是否已经确认过某个方案。这部分是状态维护不好就会出现“鱼一样的记忆”。把这三层分开管理最大的好处是避免互相污染。很多工程问题比如模型突然“忘记”指令、回答前后矛盾根源往往不是模型能力不行而是三层信息被混在一起模型分不清哪些是规则、哪些是数据、哪些是历史。1.3 为什么这篇文档值得花时间读说句实话市面上单独讲Prompt技巧的文章很多但大部分都是“碎片化知识点”你要用few-shot、你要给模型思考时间、你要用XML标签。这些都对但不系统。这篇70页的文档价值在于它把“经验”变成了一套“方法论”。我在项目里的感觉是碎片化知识能解决单个问题但解决不了系统性问题。比如你优化了一个Prompt准确率提了5个点但换一批数据又掉回去了。原因就是你只改了一个点但没有理解整个上下文链路是怎么协作的。这份文档适合的人群大致有三类一类是做RAG应用的工程师想搞清楚“检索之后怎么把内容组织好”一类是做Agent开发的工程师需要管理工具定义和多轮状态还有一类是技术负责人想建立团队内部的评估和迭代机制。不同角色读它能提取到的东西会有点差异但整体框架是共通的。2. 上下文构建的底层方法论2.1 把上下文拆成四个基本模块文档在讲上下文构建的时候给了一个非常工程化的做法把上下文内容拆成模块而不是一段长文本直接怼给模型。四个核心模块分别是指令块、数据块、示例块和输出约束块。指令块负责告诉模型“你要做什么、不要做什么”这是整个上下文的地基。数据块负责提供完成任务所需的原始材料比如商品信息、用户订单、政策条款。示例块是最直接的“教学材料”给模型看一两个输入输出对它就知道你期望的格式和语气。输出约束块负责限定“只输出JSON”“控制在50字以内”“必须包含订单号”等硬性要求。我在实践中对模块化最大的体会是它让“调试”变得可操作。以前一个Prompt几百字模型出了格式问题你得从头到尾找可疑点。但拆成模块之后如果格式不对问题大概率在输出约束块如果事实性错误问题大概率在数据块如果风格不对问题大概率在指令块或者示例块。2.2 信息位置决定模型注意力文档里花了不少篇幅讲一个现象我愿称之为“中间遗忘症”模型对上下文开头和结尾的信息处理得更好对中间部分的内容容易“视而不见”。这个现象在长上下文场景里尤其明显。我自己实测下来确实如此。有一次做知识库问答把问题放中间、把参考文档放开头结果模型经常忽略问题答非所问。后来把问题放最后、参考文档放前面效果立竿见影。基于这个现象文档给出的实用建议是核心指令放在上下文的最前面关键任务描述或用户问题放在最后面参考资料、历史记录等辅助内容放在中间。这个顺序安排看着简单但实际影响非常大。你可以把它理解成“给模型划重点”开头是“这是规则”结尾是“现在要处理的事”中间是“可以查阅的资料”。2.3 结构化标签减少解析歧义文档对结构化标签的使用着墨很多。核心思想是模型毕竟是在处理文本你给它一段没有边界的文本它需要自己猜测“哪部分是规则、哪部分是数据”这就会增加出错概率。用XML、Markdown或JSON把区域明确分隔开来相当于给它一份带目录的文档而不是一摞散页纸。比如这样组织system 你是一名订单客服只回答与订单相关的问题。 /system context 用户订单号20250612001 订单状态已发货物流公司某快递运单号SF1234567890 /context user_question 我的订单现在到哪了 /user_question这样模型一眼就能看出哪部分是“规则”、哪部分是“数据”、哪部分是“用户问题”。我自己越来越习惯这种写法尤其是做复杂任务时结构化标签能有效降低模型的误读率。这里有一个小提醒标签体系要前后一致不要今天用XML明天用Markdown更不要嵌套混乱。嵌套不规范时模型反而会产生更多解读错误。文档里的建议是“宁可简单清晰不要复杂花哨”。2.4 上下文长度不是越长越好这可能是整篇文档里最反直觉的一个观点。长上下文能力在近几年突飞猛进很多人因此形成了“能塞多少塞多少”的习惯。但文档非常明确地指出上下文越长注意力分散的风险越大同时成本和延迟也会同步上升。拿我做过的一个案例来说早期做文档问答我一度把用户的历史对话全都带进上下文结果模型经常把“用户上次问过的东西”和“这次问的东西”混淆。后来把历史会话截断到最近三到五轮效果反而更稳定了。这里有一个很实用的判断标准这个信息对“完成当前这一步”是不是必需的如果是就放进上下文如果不是就别放。每次请求前都问一遍这个问题上下文长度自然会被控制住。3. 运行时上下文管理检索、记忆与工具注入3.1 RAG的“检索后处理”才是关键市面上聊RAG大部分精力都花在“怎么召回”上嵌入模型选哪个、向量库用哪个、相似度阈值设多少。但这份文档的观点很有启发性检索只是前半段真正决定效果的是检索结果的“组织方式”。我举个例子。假设用户问“这台空调支持多少平方的房间”检索系统召回了五段文档其中两段讲制冷参数、一段讲安装要求、一段讲遥控器说明、一段讲保修政策。如果你把这五段内容顺序不变全塞进上下文模型很可能被安装要求和保修政策带偏。文档里的建议是检索之后要做“后处理”包括去重、按相关性重排、裁剪冗余、合并同类项。这些步骤看着不起眼但对答案质量的影响经常比换一个嵌入模型还大。我在实际项目里的流程已经固化成检索这批结果之后先按问题中的关键实体过滤一遍再做一次重排最后只保留与问题最相关的前两到三段内容。这套流程跑下来回答的准确率提升非常明显。3.2 短期记忆与长期记忆的分工上下文工程对“记忆”的划分很清晰。短期记忆是当前会话里需要保留的状态比如用户已经报了订单号、已经确认过收货地址长期记忆是跨会话沉淀下来的事实比如用户的常用地址、会员等级、历史偏好。文档特别强调了一点长期记忆不能无脑塞进上下文。模型不是数据库不适合拿来做全量记忆的载体。正确做法是“按需提取”——当用户触发某个场景时记忆系统把相关的少量信息注入到上下文中而不是把用户三年的历史订单全部丢进去。这个思路跟人脑的记忆机制很像你不会记得所有事情但处理具体问题时你会想起那些有关联的信息。上下文工程就是给模型装一个“按需唤醒”的记忆管理器。3.3 工具调用把外部能力装进上下文中Agent类应用是上下文工程的重要场景。文档里对工具的定义讲得很透彻对模型来说工具本身就是上下文的一部分。模型需要知道“有哪些工具可用、每个工具是干什么的、参数长什么样”才能做出正确选择。这里有一个坑。工具描述写得含糊模型就会瞎调用。比如你给一个查天气的工具写了一行描述“查询天气信息”模型可能不知道该传城市还是传经纬度。但如果你把描述写成“根据城市名称获取实时天气输入参数为城市中文名例如北京、上海”模型就很少会传错参。工具描述的关键是“写给人看但机器也能理解”。实际操作中工具说明应该包含功能概述、适用场景、参数格式和示例。每次新工具接入时我都习惯先跑一个最小用例验证模型能不能正确选出这个工具再放进去。4. 让上下文工程可评估指标、方法与节奏4.1 没有度量就没有迭代这是我踩过最多坑的地方。早期调上下文完全靠“感觉”模型答得好就开心答得不好就改Prompt再跑一两遍看看。但这种方式最大的问题是不可持续——你不知道这次改好是偶然还是必然也不知道是哪个改动起了作用。文档给的核心建议是上下文工程必须建立在“可评估”的基础上。每一次改动都要能通过一组固定的测试用例来衡量效果变化。否则你觉得每天都在优化实际上是在原地打转。我现在的做法是为每个项目先建一个评估集大小不用太大三十到五十条即可但必须覆盖正常场景、边界场景和异常场景。每次改动Prompt或上下文结构都在这个评估集上跑一遍记录前后对比。这个习惯救了我很多次。4.2 一组能落地的评估指标文档里列举的指标不少我结合自己项目的经验把最实用的几个列了出来指标含义使用场景任务准确率回答是否正确所有任务的基础指标内容召回率关键信息是否覆盖完整知识库问答、摘要类任务事实忠实度回答是否严格基于给定资料需要引用文档的场景格式合格率是否满足JSON、XML等格式要求结构化输出任务单次成本平均每次请求的Token消耗需要控制成本的项目端到端延迟从请求到返回的耗时在线服务、实时场景这里我特别想强调“事实忠实度”。如果你做的是知识库问答模型回答得再流畅但编造了文档里没有的信息这个回答就是不合格的。我们团队现在会把“是否出现幻觉”作为单独一个维度来打分不跟准确率混在一起。4.3 评估集怎么搭搭评估集的时候很多人会犯一个错误只用好的、正常的问题做测试。结果就是模型在正常场景下表现不错一旦遇到稍微偏一点的输入就开始胡说。文档里建议评估集按照“7:2:1”的比例分配七成是正常问题两成是边界问题比如提问方式不太规范、包含错别字、信息不完整一成是明确异常的问题比如超出范围、恶意输入。这样既能验证模型的主路径是否稳定也能验证它面对干扰时是否还能守住边界。评估的方式我个人建议采用“模型评判加人工抽检”的组合。先用一个评判模型对回答打分再抽其中一部分让人工复核。这样成本可控质量也有保障。5. 实操复盘一个客服问答场景的上下文工程落地5.1 场景定义与上下文蓝图理论讲再多不如跑一个案例。我用一个模拟项目来复盘做一个电商客服问答机器人用户会问订单状态、物流进度、退换货政策机器人需要基于订单数据回答并且只输出JSON格式方便业务系统对接。项目启动时我先画了一张“上下文蓝图”这张图的思路完全来自文档的框架上下文层级内容来源是否动态系统级客服角色定义、回答边界、禁止行为静态任务级订单信息、物流信息、售后政策每次查询动态拉取会话级用户近期提问、是否已提供订单号随对话更新输出约束JSON字段要求、枚举值范围静态画完蓝图之后我对整个上下文结构就心里有数了后面写Prompt就变成了“往四个模块里填内容”而不是写一整篇不可控的大作文。5.2 Prompt结构示例基于上面的蓝图实际构建出的Prompt结构如下system 你是一名在线订单客服助手。 - 只能回答与订单、物流、售后相关的问题。 - 如果用户没有提供订单号先询问订单号。 - 不回答与订单无关的问题。 /system order_info 订单号20250612001 状态已发货物流公司某快递运单号SF1234567890 物流轨迹 - 2025-06-10 18:30 已揽收 - 2025-06-11 09:00 运输中 - 2025-06-12 14:00 到达本市分拨中心 /order_info policy 七天无理由退货签收后7天内可申请商品需保持完好。 /policy user_question 我的快递到哪了我想退掉它。 /user_question output_format 只输出JSON { answer: 回答用户的问题, order_number: 订单号, requires_more_info: 是否需要用户补充信息 } /output_format这个结构里每个模块边界清晰模型很容易理解哪部分是对它行为的约束、哪部分是数据、哪部分是输出要求。5.3 实验对比与迭代记录这个模拟项目我跑了三个版本对比结果非常有意思。V1版本是“把所有信息写在一段长文本里”没有模块标记模型虽然能回答但JSON输出格式经常缺字段。V2版本引入了XML模块划分格式问题明显减少代价是Prompt总长度变长了一些但换来的是稳定性提升。V3版本在V2基础上调整了信息顺序把user_question从中间挪到了靠近末尾的位置同时精简了订单信息中的冗余字段最终的效果是任务准确率提高回答时长也缩短了一截。版本格式合格率任务准确率单次Token消耗V178%82%约1300V295%88%约1500V397%94%约1260这个实验让我彻底相信了一件事上下文工程不是玄学每一步改动都可以量化也值得量化。6. 高频问题排查上下文工程实战避坑6.1 模型“忘记”系统指令这是出现频率最高的问题。你明明在系统指令里写了“只回答与订单相关的问题”用户问了一句“今天天气怎么样”模型就开始聊天气。排查思路很简单系统指令放在哪了如果系统指令埋在一大段参考资料中间模型很可能把它当成次要信息忽略掉。解决方法是把系统指令单独放在上下文最开头并且用结构化标签标出来。我还会在指令里主动加一句“当遇到与订单无关的问题时直接拒绝回答”而不是只写“只回答与订单相关的问题”这样模型的拒绝行为会更明确。6.2 检索片段相互冲突知识库问答的典型问题检索回来的两段文档内容互相矛盾模型不知道听谁的最后编出了一句四不像的话。文档里的建议是在做上下文组织时为检索内容标注来源并让模型优先信任权威来源。比如在各段落前面加上“来源A”“来源B”同时在指令中明确“如果不同来源信息冲突以来源A为准”。我在项目中试过这一招效果非常直接冲突引发的幻觉率明显下降。6.3 输出格式不稳定要求模型输出JSON但它偶尔会在JSON前面加一句“好的这是您要的结果”或者用单引号代替双引号。这种问题在长上下文场景尤其常见因为模型面对大量信息时注意力容易从输出约束上偏移。我的解决方案是双管齐下一是把输出约束块放在用户问题之后、紧邻生成位置二是在评估阶段专门用“格式解析器”检查输出是否为合法JSON解析失败就自动重试一次。有了重试兜底线上服务的稳定性会好很多。6.4 成本失控上下文工程做了一段时间很多人会发现Token消耗越来越夸张。原因往往不是任务变难了而是把太多“可能用得上”的信息塞进上下文。成本控制的核心原则还是那一句只为当前步骤保留必要信息。我在代码里加了一个简单的判断逻辑如果用户查询的是订单状态就只拉取该订单的基础状态和最新轨迹不拉取三个月内的全部历史。这个小改动让单次调用成本下降了大约四成。7. 把70页转成PPT我的提炼与展示思路7.1 直接可用的十页结构如果你也要在公司内部做分享我建议直接把内容按十页PPT来切每页一个主题顺序可以这样排页码PPT主题讲述重点1背景上下文工程为什么现在讨论度这么高2定义上下文工程的边界与目标3三层上下文系统级、任务级、会话级的划分4四大模块指令、数据、示例、输出约束5信息位置开头和结尾的重要性6结构化用标签减少解析歧义7RAG后处理检索之后才是关键8记忆管理短期记忆与长期记忆9评估方法指标、评估集、迭代节奏10案例复盘一个客服场景的实战数据这样切完整个分享的时间大概在四十分钟到一个小时之内既不会太散也不会因为内容过多而讲不透。7.2 演示时的叙事顺序分享这类技术文档最容易犯的错误是“按原文顺序逐页讲”。原文是论证式的它是为了说服读者而演示时你应该按照“听众的痛点”来组织叙事。我自己会先用一个失败案例开场一个客服机器人答非所问、格式乱、成本高。然后反向推导告诉听众这些问题的共性都在于“上下文没管好”。再引出三层框架和四模块方法论最后用自己的实验数据收尾。这样听众的代入感和接受度都会高很多。7.3 个人经验与后续扩展最后说点我自己的体会。接触上下文工程之前我做LLM应用优化基本靠“试”Prompt改一版测一次效果不行再改。做久了你会发现自己像一个盲人摸象的手艺人每次只摸到一条腿永远不会形成完整画面。而上下文工程给我最大的帮助是把优化这件事从“玄学”变成了“工程”。现在每次遇到模型表现不稳定的问题我第一反应不是怀疑模型能力不行而是检查自己的上下文结构三层分清楚了吗模块边界清晰吗信息顺序合理吗输出约束有没有放在正确位置这套自检流程我几乎每次都能定位到真正的问题。这70页文档读起来需要耐心但读完之后的复盘价值是巨大的。后续我还会继续在这条线上深入尤其是评估体系的方向我觉得还有很大的优化空间。如果你也在研究上下文工程欢迎在实际项目中多试试文章里提到的几个方法用数据说话比看一百遍文档都有用。

上下文工程实战指南：从Prompt优化到RAG与Agent落地

相关推荐

知识工作插件化：从信息采集到输出的轻量可组合实践

车管所串口监控程序：72小时稳定运行的COM口黑匣子

PyTorch迁移学习实战：水稻虫害图像分类全流程与踩坑指南

更多资讯

机器人导航地图模块开发：占据栅格地图与坐标系实践

机器人导航栅格地图处理利器：lingbot-map 实战指南

PPT抠图去背景全攻略：删除背景、透明色与边缘处理技巧

项目标题‘rea‘为何无法生成有效技术博文？

Adobe Audition教程PDF使用指南：版本差异与降噪响度实战

dp123电天下API接口实战：列表搜索数据同步与避坑指南

今日更新

微信云开发旅游小程序实战：LBS打卡+UGC社交全栈方案

金融AI代理平台核心拆解：从多代理协作到财报分析实战

基于大数据的智慧旅游推荐与可视化平台架构实践

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？