上下文工程实战：从概念到落地的完整指南

上下文工程这个词这两年被聊得越来越多但真正动手做过的团队其实没那么多。我最早接触这个概念是在一个对话类产品的迭代里当时模型换了一版回答质量反而掉了排查了整整两天才发现问题不在模型本身而在我们喂进去的上下文结构变了——历史消息截断策略改了系统提示词的位置挪了几个工具描述的顺序也调了。那次之后我才真正意识到上下文工程不是玄学它是一套可以拆解、可以复现、可以量化的工程方法。这篇文章我想把这两年踩过的坑、试过的方案、验证过的参数尽量完整地摊开讲一遍从概念到落地从设计到排查适合刚入门想搞明白这套东西的读者也适合已经在做但总觉得效果不稳的同行对照着看。1. 上下文工程到底在解决什么问题1.1 从提示词工程到上下文工程的认知升级很多人把上下文工程当成提示词工程的新马甲这个理解偏差挺大的。提示词工程关注的是这一句话怎么写上下文工程关注的是这一整块信息怎么组织。打个比方提示词工程像是你在跟人说话时斟酌措辞上下文工程则是你在安排一场会议——谁先发言、谁坐哪、材料什么时候发、哪些信息该提前铺垫、哪些该留到最后揭晓这些都属于上下文工程的范畴。具体到技术层面一次模型调用的输入其实由好几块拼起来系统指令、历史对话、检索到的外部知识、工具定义、当前用户输入、格式约束。这些内容不是简单堆在一起就完事它们的顺序、篇幅、粒度、冗余度都会直接影响输出质量。我见过太多案例模型本身没问题就是上下文塞得太满或者太乱导致关键信息被淹没。从提示词工程到上下文工程的转变本质是从单点优化走向系统设计。前者是局部技巧后者是全局架构。你在做上下文工程时要考虑的不只是这句话怎么说还要考虑整个信息流的生命周期——什么进、什么出、什么留、什么丢。1.2 上下文窗口变大为什么反而更难用现在主流模型的上下文窗口动辄几十万 token理论上能塞进去的东西越来越多但实际用下来你会发现窗口大不等于效果好。这里有个很反直觉的现象把一堆相关资料全塞进去模型的表现有时候还不如只给两三段精准内容。原因在于注意力机制的特性。模型在处理长上下文时对中间位置的信息关注度会下降业内常说的中间遗忘就是这个现象。你辛辛苦苦检索了二十篇文档全塞进去结果模型只记住了开头和结尾的几段中间的关键论据反而被忽略了。所以上下文工程的一个核心任务不是能塞多少塞多少而是该塞什么、塞多少、怎么排。我实测下来的经验是对于大多数问答和生成任务有效上下文控制在窗口容量的三到五成是比较稳的区间。留出余量不仅能让模型注意力更集中也给输出留了空间。当然这不是绝对数字具体要看任务复杂度和信息密度但宁精勿滥这个原则基本通用。1.3 哪些场景最需要上下文工程不是所有场景都值得投入精力做上下文工程。简单的一问一答、单轮翻译、格式转换这类任务提示词写清楚就够了。真正需要上下文工程发力的是这几类场景多轮对话系统历史消息怎么压缩、怎么摘要、哪些轮次要保留原文直接决定对话连贯性。检索增强生成检索回来的片段怎么排序、怎么去重、怎么标注来源影响答案的准确性和可追溯性。工具调用型应用多个工具的定义怎么描述、按什么顺序排列、参数说明写多细关系到模型选工具的准确率。长文档处理合同审阅、报告分析这类任务文档怎么分块、块之间怎么建立关联是成败关键。角色扮演与人格化应用人设信息怎么稳定注入、怎么防止多轮之后人设漂移是这类产品的核心难题。你可以对照一下自己手上的项目如果命中上面任意两条以上那上下文工程就值得认真做一轮。2. 上下文的组成结构与设计原则2.1 一次调用的上下文分层模型我把一次模型调用的上下文拆成五层从外到内依次是系统层、知识层、历史层、任务层、约束层。这个分层不是官方标准是我自己在项目里总结出来的组织方式好处是每一层职责清晰改动时不容易互相干扰。系统层放的是角色设定、能力边界、总体行为准则这部分内容相对稳定一次会话内基本不变。知识层放检索到的外部信息或者预置的领域知识这部分是动态的每次请求可能不同。历史层是对话记录需要做压缩和摘要处理。任务层是当前这一轮的具体指令要写得明确具体。约束层是输出格式、长度、语气这些硬性要求。分层的价值在于可维护性。当输出出问题时你可以逐层排查是系统层的人设被稀释了还是知识层塞了无关内容还是历史层压缩过度丢了关键信息。不分层的话所有内容糊成一团排查起来就是大海捞针。2.2 信息密度与冗余度的平衡上下文里最忌讳两种极端一种是信息太稀说了半天没说到点子上另一种是信息太密每句话都是干货但堆在一起反而让人抓不住重点。模型处理信息的方式和人有点像需要一定的结构信号来引导注意力。我的做法是给关键信息加锚点。比如在知识层里每段检索内容前面加一句简短的主题标注告诉模型这段讲的是什么在历史层里对重要的用户偏好做显式标记而不是指望模型自己从对话里总结。这些锚点会增加一些 token 开销但换来的是模型定位信息的准确率提升这笔账算下来是划算的。冗余度控制上我一般遵循同一信息不重复超过两次的原则。系统层说过的人设任务层就不用再强调知识层已经给出的数据约束层就不用再复述。重复不仅浪费窗口还会让模型误以为这是重点而过度关注反而干扰判断。2.3 顺序编排对输出质量的隐性影响上下文里内容的排列顺序影响比大多数人想象的大。有几个我验证过的规律重要指令放两端。开头和结尾是模型注意力最集中的位置核心要求尽量放在系统层开头或者任务层结尾别埋在中间。知识在前问题在后。检索内容应该放在用户问题之前让模型先读完材料再回答问题顺序反了容易导致模型先形成判断再找证据产生确认偏误。示例紧跟指令。如果你给了输出示例示例要紧挨着对应的指令中间别插其他内容否则模型可能对不上号。工具定义按使用频率排。工具多的时候常用的放前面冷门的放后面实测能提升工具选择的准确率。这些规律不是拍脑袋想出来的是我在不同项目里做 A/B 对比测出来的。当然不同模型可能有细微差异建议你在自己的场景里也做一轮小规模验证。3. 核心实操上下文组装的完整流程3.1 系统提示词的编写与稳定注入系统提示词是上下文的地基写得好不好直接决定后续所有环节的上限。我总结了一个四段式结构实测下来比较稳第一段定角色和能力边界说清楚你是谁、你能做什么、你不能做什么。第二段定行为准则比如遇到不确定的信息要怎么处理、遇到超出范围的问题要怎么回应。第三段定输出风格语气、详略、格式偏好。第四段放少量高质量示例给模型一个具体的参照。这里有个细节很多人忽略系统提示词要防稀释。多轮对话之后系统提示词在上下文里的占比会越来越小模型对它的记忆会减弱。解决办法是在历史层压缩时始终保留系统提示词的核心要点摘要或者在每若干轮之后重新注入一次精简版人设。我一般设置每八到十轮做一次轻量重注入效果比较明显。还有一个坑是系统提示词写太长。我见过有人写了三千字的系统提示结果模型反而抓不住重点。系统层控制在五百到八百字是比较舒服的区间超过一千字就要考虑拆分把部分内容挪到知识层按需注入。3.2 历史对话的压缩与摘要策略多轮对话的上下文管理是重灾区。全量保留会撑爆窗口粗暴截断会丢关键信息怎么取舍是门手艺。我目前用的是分层压缩方案最近三轮对话保留原文一个字不改保证即时连贯性。第四到第十轮做轻度摘要保留用户的核心诉求和模型的关键结论删掉寒暄和试错过程。十轮以前的对话做深度摘要只保留事实性信息比如用户透露的偏好、已经确认的结论、明确排除的方案。摘要不是让模型随便总结而是要用固定的模板。我用的模板大概是用户在此轮提出了X需求确认了Y信息排除了Z方案。这种结构化摘要比自由发挥的摘要稳定得多信息丢失率也低。注意摘要环节本身也要消耗一次模型调用如果对话轮次不多直接截断可能更划算。我一般设置在对话超过十五轮之后才启用摘要机制短对话用滑动窗口截断就够了。另外有个实操技巧在历史层的最前面放一句以下是历史对话摘要按时间顺序排列给模型一个明确的结构信号。别小看这句话实测能减少模型把摘要内容当成当前指令的误判。3.3 检索内容的筛选、排序与标注检索增强场景下检索回来的内容怎么处理是上下文工程的重头戏。我的处理流程分四步第一步去重。不同来源的文档经常有重复段落用简单的文本相似度做一轮过滤能砍掉两三成的冗余。第二步相关性重排。检索系统给的排序不一定适合直接喂给模型我会用一个轻量模型或者规则做二次排序把和当前问题最相关的片段提到前面。第三步分块粒度调整。块太大信息杂块太小上下文断裂。我的经验是每块控制在三百到五百字块与块之间保留一句重叠内容做衔接。第四步加标注。每块前面加一行来源和主题标注格式大概是[来源某文档 | 主题XX]这种。标注的作用是让模型知道这段内容的出处和主旨回答时能引用来源也方便它判断内容可信度。排序上我遵循倒金字塔原则最相关的放最前次相关的放最后中间放补充材料。这样即使模型只关注了两端也能拿到最关键的信息。3.4 工具定义的描述技巧与排列顺序工具调用型应用里工具定义的写法直接影响选择准确率。我踩过的坑是工具描述写得太技术化模型理解不了工具的适用场景。后来改成功能描述适用场景不适用场景三段式准确率明显提升。举个例子一个查询订单状态的工具光写根据订单号查询订单状态是不够的要补上适用于用户询问物流进度、订单是否发货等场景不适用于修改订单、退款等操作。把边界说清楚模型就不会乱用工具。工具数量多的时候排列顺序也有讲究。我一般按高频通用工具在前低频专用工具在后排同时把功能相近的工具放在相邻位置方便模型对比选择。工具超过十个之后建议在系统层加一句工具使用总则告诉模型优先考虑哪几类工具。参数描述同样重要。每个参数要写清楚类型、是否必填、取值范围、示例值。我见过参数描述只写订单号三个字的模型经常传错格式。补上字符串类型必填格式为纯数字例如12345678之后传参错误率降了一大截。4. 参数调优与效果验证方法4.1 关键参数的取值逻辑与计算上下文工程涉及几个关键参数取值不能拍脑袋要有计算依据。我列一下自己常用的几个上下文预算分配。假设模型窗口是 128K token我不会全用满。我的分配比例大概是系统层占 5%知识层占 40%历史层占 25%任务层和约束层占 10%剩下 20% 留给输出。这个比例是根据任务类型调的检索密集型任务知识层可以提到 50%对话密集型任务历史层可以提到 35%。分块大小计算。分块大小 目标知识层预算 ÷ 预期块数。比如知识层预算 50K token预期放 100 块那每块就是 500 token 左右换算成中文大概三百多字。这个计算能保证块数和预算匹配不会出现块太大放不下或者块太小信息碎的问题。摘要压缩比。轻度摘要保留原文 40% 到 50% 的信息量深度摘要保留 15% 到 20%。这个比例是通过对比摘要前后关键信息召回率测出来的低于这个比例信息丢失明显高于这个比例压缩效果不够。这些数字不是金科玉律但提供了一个起点。你在自己场景里可以先按这个比例跑一轮再根据实际效果微调。4.2 用对照实验验证上下文改动上下文工程的改动最怕感觉变好了。感觉这东西不靠谱必须用对照实验说话。我的做法是建一个小型评测集覆盖典型场景每次改动上下文结构就跑一轮对比。评测集不用很大三五十条就够但要覆盖不同难度和不同类型。每条样本记录改动前后的输出人工或者用规则打分。打分维度我一般看四个准确性信息对不对、完整性该说的说了没、相关性有没有跑题、格式合规输出格式对不对。跑对照实验时有个原则一次只改一个变量。同时改顺序又改分块大小出了问题根本不知道是哪个引起的。我吃过这个亏后来老老实实单变量测试虽然慢一点但结论可靠。4.3 上下文长度与响应质量的实测曲线我在一个问答项目里做过一组实测把上下文长度从 2K token 逐步加到 64K token观察响应质量的变化。结果挺有意思上下文长度准确性完整性响应延迟2K中等偏低快8K较高中等较快16K高较高中等32K高高偏慢64K略降高慢可以看到质量在 16K 到 32K 之间达到峰值再往上加反而准确性略降延迟还明显上升。这个曲线的拐点因任务而异但存在最优区间这个结论是通用的。盲目堆上下文长度是性价比很低的做法。5. 常见问题排查与避坑实录5.1 输出跑偏的逐层排查法输出跑偏是最常见的问题排查时我按分层模型从外往内查先看系统层人设有没有被稀释行为准则有没有被后续内容覆盖。再看知识层检索内容里有没有和问题冲突的信息有没有无关内容干扰。然后看历史层摘要有没有丢关键信息有没有把旧指令当成新指令。最后看任务层当前指令写得够不够明确有没有歧义。这个排查顺序的逻辑是从稳定层往动态层查因为稳定层出问题的概率低但影响大动态层出问题的概率高但影响局部。大部分跑偏问题最后都定位在知识层和历史层。5.2 上下文超限的应急处理上下文超限报错是家常便饭应急处理有几个手段按优先级排第一优先是压缩历史层这是最不影响效果的。第二是精简知识层去掉相关性低的块。第三是缩短系统层把非核心内容挪走。最后才是截断任务层这个要慎用容易丢关键指令。我一般会在组装上下文之前先做一次预算检查预估 token 数超了就按上面的优先级自动降级。这个预检查机制能避免大部分超限报错。5.3 多轮对话中的人设漂移修复人设漂移是多轮对话的顽疾聊到十几轮之后模型就开始出戏。修复手段我试过几种效果最好的是周期性重注入每八到十轮在历史层末尾插入一段精简人设摘要格式是提醒你的角色是X核心行为准则是Y。这段内容不占太多 token但能有效把人设拉回来。另一个辅助手段是在摘要模板里固定保留人设相关字段每次摘要都带上防止人设信息在压缩过程中被丢掉。两个手段配合使用人设稳定性提升很明显。5.4 常见问题速查表问题现象可能原因排查方向解决手段输出跑偏知识层有冲突信息检查检索内容相关性去重重排过滤人设漂移系统层被稀释检查轮次和人设占比周期性重注入上下文超限预算分配失衡检查各层 token 占比按优先级降级压缩工具选错工具描述不清检查描述三段式完整性补适用/不适用场景信息遗漏摘要压缩过度检查摘要保留比例提高压缩比或改模板响应变慢上下文过长检查总 token 数压缩到最优区间这张表是我从实际项目里攒出来的遇到问题先对照着查一遍大部分情况能快速定位。6. 工程化落地与持续优化6.1 上下文模板的版本管理上下文结构一旦确定就要当成代码一样管理。我的做法是把上下文模板抽成配置文件每个版本打标签改动走评审流程。这样做的原因是上下文改动的影响很隐蔽今天改个顺序明天可能才暴露问题有版本记录才能回溯。模板配置里我一般包含这几块各层的模板文本、参数默认值、压缩策略配置、工具定义列表。改任何一项都要记录改动原因和预期效果跑完对照实验再合并。这套流程听起来重但比出了问题抓瞎强得多。6.2 监控指标与迭代节奏上线之后要有监控。我关注的指标分两类质量指标和成本指标。质量指标看输出准确率、用户反馈、重试率成本指标看平均 token 消耗、响应延迟、调用次数。迭代节奏上我不建议频繁大改。上下文结构稳定下来之后小步快跑地调参数就行大结构调整一个季度做一次顶天了。频繁大改会让效果波动用户感知很差排查起来也困难。6.3 不同模型间的上下文适配差异换模型是上下文工程最容易翻车的时候。不同模型对上下文顺序的敏感度、对指令的遵循程度、对长上下文的处理能力都不一样。我的经验是换模型之后必须重跑一遍对照实验重点看三个地方系统提示词的遵循度、知识层的利用效率、工具选择的准确率。有些模型对结构化标注更敏感有些模型对自然语言描述更买账。适配的时候不要照搬要根据模型特性调整。比如某个模型对列表式指令遵循得好那就把关键要求改成列表另一个模型对示例学习效果好那就多放几个示例。这些调整都要靠实测确定没有通用答案。7. 我个人的几条实操心得做上下文工程这两年有几个体会比较深分享出来供参考。第一别迷信窗口大小。窗口大是好事但用不好反而是负担。我见过太多项目把窗口当垃圾桶什么都往里塞结果效果还不如精简版。上下文工程的核心是取舍不是堆砌。第二结构化比自然语言更稳。同样的信息用固定模板和标注组织起来比一段流畅的自然语言描述效果稳定得多。模型对结构的敏感度比我们想象的高给它清晰的骨架它填内容的质量就高。第三对照实验是唯一真理。所有我觉得这样更好的判断都要用数据验证。上下文改动的影响很微妙直觉经常骗人。建个小评测集养成改完就跑的习惯长期下来能省很多返工。第四留余量是门艺术。上下文预算、压缩比例、摘要保留度这些参数都要留缓冲。卡着极限用遇到边界情况就崩。我一般所有预算都留两成余量稳字当头。第五人设和指令要防衰减。多轮对话里越靠前的内容越容易被遗忘。重要的东西要么周期性重注入要么放在靠后的位置。这个规律在几乎所有模型上都成立值得当成常识记住。上下文工程这个方向还在快速演进新的模型、新的能力会不断改变最佳实践。但底层的那套思路——分层组织、预算分配、对照验证、持续迭代——短期内不会过时。把这几条吃透换什么模型都能快速适配。后续如果要做更细的展开工具调用的上下文优化和长文档的分块策略是两个值得深挖的方向我后面有机会再单独聊。