1. 为什么我们开始认真对待上下文工程
做过大模型应用开发的同学应该都有过这种体验：明明同一个模型，别人调的Agent能稳定执行复杂任务，自己写的却经常答非所问、丢三落四。模型本身没变，变的只是喂给它的上下文。我前几个月跟进一个多步骤工具调用项目时，被这个问题折磨得不轻——不是模型能力不够，而是我根本没有把上下文当回事。
后来复盘某Agent研发团队公开分享的实战经验，才慢慢摸到门道。他们最核心的思路其实特别朴素：把模型当作一个需要“精心准备资料”的协作者，而不是一个什么都知道的百科全书。你给它什么材料、按什么顺序给、怎么组织格式，直接决定了它能不能把事情做对。这就是Context Engineering，中文常叫上下文工程。它不研究怎么训练模型，也不研究怎么微调，而是研究如何在推理阶段把上下文构建到最优状态，让模型在有限的计算资源里发挥出最大能力。
这个方向适合谁？如果你是做大模型应用落地、Agent开发、RAG系统、自动化工作流的工程师，或者你正在被“模型不听话”“输出不稳定”“多步任务总断链”这些问题困扰，这篇文章应该能帮到你。整篇内容围绕我在实际项目里踩过的坑和沉淀下来的方法展开，核心会落到6个可以立刻上手的关键技巧上，每个技巧都会说清楚“是什么、为什么、怎么用”。
2. 系统提示词：整个上下文架构的地基
2.1 为什么System Prompt往往决定了Agent的“性格”
先说一个很容易被忽略的事实：在目前主流对话模型里，System Prompt（系统提示词）对模型行为的影响权重远大于普通用户消息。模型对每一轮内容的注意力不是均匀分配的，系统提示词在序列最前面，天然承担了“全局行为约束”的角色。你在System Prompt里写的内容，等于提前给模型划定了行为边界和价值排序。
我在早期项目里犯过一个低级错误：把系统提示词写成了“你是一个智能助手，请帮助用户完成任务”。这句话等于没说。模型不知道任务的最终目标是什么、不知道可用的工具边界、不知道输出格式的约束，结果就是每一次调用都在赌模型的心情。后来我把系统性提示词拆成了五个模块，情况立刻好转：
- 角色边界：明确模型在本次任务中是谁，比如“你是订单处理助手”，这个角色描述要具体，但不要过度拟人化。
- 任务目标：用一句话说明模型的核心目标，越具体越好，避免“帮助用户”这类空泛表述。
- 约束条件：比如不能编造信息、必须基于提供的资料回答、遇到不确定时明确说不知道。
- 输出格式：需要JSON就写明JSON结构，需要Markdown就约定层级，模型对格式的遵循能力很大程度上取决于你把格式定义得多清楚。
- 可用资源：列出本次任务中可以访问的工具、可以检索的数据范围，以及哪些数据是可信的。
这条经验来自对某Agent团队分享的拆解——他们花了很多时间把系统提示词变成一份“产品需求文档”，而不是一两句口号。也就是说，系统提示词不是用来“提示”模型的，而是用来“约束”模型的。
2.2 配置规则时最容易踩的三个坑
第一个坑是提示词过于抽象。比如你写“请谨慎处理用户请求”，模型并不知道什么样算谨慎。换成“在未确认用户身份前，不要执行涉及账号信息的操作”，模型才能真正执行。
第二个坑是规则之间互相冲突。我在一个项目里同时写了“尽可能提供详细解释”和“回复必须简短”，结果模型在两难中随机发挥，输出质量极不可控。后来做了一次规则冲突检查，把所有约束列成一张表，逐条验证是否存在逻辑矛盾，花的时间不多，但效果立竿见影。
第三个坑是把范例放在错误的位置。Few-shot示例不能随便堆在提示词末尾，应该紧挨着相关指令。模型对序列中“临近位置”的内容更加敏感，示例放得太远就起不到约束作用。更简单的做法是给示例加上明确标注，比如“以下为正确输出示例：”，让模型知道该模仿什么。
3. 上下文预算管理：让每一段Token都花在刀刃上
3.1 Token预算分配策略
做过线上大模型服务的人都知道，上下文窗口再大也是有限的。就算买到了几十万Token的窗口权限，直接把所有资料全部塞进去，效果也不会好，因为模型处理超长上下文时注意力会衰减，中间位置的内容尤其容易被忽略。
我习惯在每次调用前先做一次预算分配。默认情况下，我会把系统提示词控制在总上下文的20%以内，核心用户请求或工具结果占50%左右，检索到的参考资料占30%左右。这个比例不是绝对的，但它是一个很好用的起跑线。你可以把它理解成一个漏斗：最上面是稳定的总目标，中间是当前这一步的具体输入，最底下才是可选的参考资料。
有次我在做多轮数据分析Agent的时候，连续几轮回答质量下降。排查下来发现，每一轮我都把上一轮的完整记录重新塞进上下文，导致可用窗口越来越小。后来改成“滑动窗口策略”：只保留最近的3轮关键交互，更早的内容压缩成摘要。这样既保留了必要的对话历史，又不浪费宝贵的上下文空间。
3.2 动态截断与关键信息保留
动态截断听起来复杂，其实核心思路就是按优先级丢弃信息。信息优先级从高到低大致是：系统提示词 > 当前用户指令 > 最近的交互记录 > 工具执行结果 > 历史摘要 > 原始长文档。真正需要动态处理的是后面几类。
一个我在实践中验证有效的做法：把长文档按段落切分后，先逐段执行一次“信息密度评分”，评分依据是关键词命中数、与当前问题的语义相似度、本身的信息完整度。拿不准的时候可以用模型快速跑一遍摘要，但没必要对每一段都这么做，成本太高。只对长文档中排名靠前的段落做“保真保留”，其余段落统一压缩成一句话摘要，既减少了Token消耗，又保证了核心信息不丢。
从某Agent团队的分享里学到的另一个细节是：截断不要直接从尾部砍。模型对开头的注意力最强、对结尾次之、对中间最弱。如果必须牺牲一部分内容，优先压缩中间段落，而不是删掉靠后的信息。你可以把关键结论或最终答案放在上下文末尾，让模型在生成时更容易“看到”。
4. 结构化上下文：从文本堆砌到信息分层
4.1 排序、标注与分节：让模型快速定位重点
我之前一直以为，只要把相关材料拼在一起丢给模型就行，直到被现实教育了一轮。有一回让模型从三份PDF里提取特定字段，它居然把一份合同里描述附件的信息当成主合同内容提取出来。不是因为模型笨，而是因为我把三份文档无序地堆在一起，模型根本分不清哪个是主文档、哪个是附件。
从那以后，我所有上下文构建都强制分节。最基本的分节方式是用明确的标记区分信息块，比如：
[合同主文档] （正文内容） [附件A：设备清单] （正文内容） [附件B：维修记录] （正文内容） [关键字段定义] 甲方名称: 指合同签署主体这个做法在多个任务上都会带来提升，原因是模型在预训练阶段就常见到结构化文本，看到明确的“章节标签”时，它能更好地调用相应的理解方式。更重要的是，分节之后我可以进一步做“重点前置”：把模型需要优先关注的内容放在信息块的前面，并在分节标记里直接写明优先级，比如[高优先级文档]。
4.2 统一工具调用与结果回注格式
多步工具调用是上下文工程里最容易崩的环节。我跑过一个日程安排Agent，它需要先查用户日历、再查参会人空闲时间、最后创建会议邀请。最初我把工具定义写得很随意，有的返回纯文本、有的返回JSON、有的返回表格，模型在“理解上一步结果”和“规划下一步操作”之间反复横跳，链条动不动就断。
这事的解法不复杂，但需要严格执行：所有工具调用结果必须统一成同一种结构。我在项目里定的标准格式是：
{ "tool_name": "calendar_query", "status": "success", "summary": "用户3月2日上午空闲，下午有周会", "data": [...] }关键在于summary字段——我会要求工具层在返回原始数据的同时，生成一句人话摘要。为什么这个字段这么重要？因为模型直接读结构化数据经常漏掉隐含信息，但读摘要就很容易抓到要义。你可以把summary理解为给模型准备的“导读”，data才是原始证据。模型只需要基于摘要判断下一步，必要时再深入看data字段。
把工具调用结果回注到上下文时，还要注意覆盖“历史操作”。如果模型已经完成了第1步查日历，这一步的结果要单独存放，在下一次调用系统提示词时带上，但不能把它和“用户原始指令”混在一起。我的做法是单独开一个“操作历史”区域，每一轮追加一行步骤序号 + 操作内容 + 结果摘要，模型看到这些记录，就能清楚地知道自己做到哪一步了。
5. 长会话记忆与动态检索压缩
5.1 多级记忆架构：工作记忆、情景记忆与长期知识
做Agent项目做得越久，越会发现上下文工程和“记忆系统”其实是一对双胞胎。单个请求的上下文构建再漂亮，如果跨多轮任务没有记忆管理，整个对话依然会变得碎片化。
我在设计会话式Agent时参考了心理学里的记忆分类，做了三层架构。第一层是“工作记忆”，也就是当前这一轮需要用的所有信息，存在于这一次请求的上下文中。第二层是“情景记忆”，指用户在整个会话过程中提过的关键需求、偏好和决策，我用一个独立的记忆库保存，不是每一轮都全部注入，而是根据当前话题动态拉取。第三层是“长期知识”，比如企业知识库、产品文档、政策法规这类不随对话变化的静态信息，放在检索库里，需要时才查询。
三层之间的调度规则是：工作记忆永远完整保留；情景记忆按相关度排序，只取前若干条；长期知识靠向量检索返回Top K段落。这个架构的好处是，模型每一轮面对的上下文长度基本恒定，不会随着轮数增多而无限膨胀，同时该用的背景信息一项都不少。
5.2 摘要压缩与检索增强的实战取舍
摘要压缩和RAG是两种经常被放在一起比较的技术，但它们的适用场景其实完全不同。我个人的判断标准是：如果想要“全局记忆”，摘要压缩更合适；如果想要“精确事实”，RAG检索更可靠。
举个例子，用户在前几轮讨论过“喜欢简洁风格、重视数据准确性、对隐私敏感”，这些偏好型信息适合写成摘要，每轮都带上一段。但用户问“上次那个项目里协议条款原文是什么”，这种就必须走检索，直接从原始文档里查，不能靠摘要——因为摘要是对信息的再加工，保不齐会丢细节甚至带偏。
某Agent团队的实战分享里提到一个观点我特别认同：不要用RAG代替一切上下文，也不要盲目相信“把整个知识库塞进提示词”的粗暴路线。好的做法是分级：80%的场景靠结构化系统提示词和紧凑的摘要记忆就能解决，只有真正涉及事实核查、原文引用时才需要动用检索。这样既能控制成本，又能提高稳定性。
实操中还有一个细节：RAG检索回来的段落如果过多，反而会稀释模型对重点的注意力。我一般把检索结果控制在5到8段以内，每段不超过200字。超过这个量的时候，我会先跑一轮粗排，只把“和当前问题最相关”的那部分传进上下文，而不是把所有召回结果一股脑儿全部塞进去。
6. 可观测、可评测、可迭代
6.1 上下文日志与追踪：看得见才能调得动
上下文工程最让人头疼的地方就是它不透明。你很难直接看出“为什么模型在这个任务上失败了”——是因为指令写得不好，还是检索到的内容不对，还是上下文被截断了，还是示例的指导性太弱。
所以我在项目里养成了一个习惯：每次模型调用都完整记录当时的上下文快照。快照里至少包含系统提示词全文、工具定义、检索命中片段列表、截断策略参数、模型输出原文、Token使用量。这个日志的直观好处是，出问题之后不需要猜，直接回放当时的上下文就能定位是哪一个环节拖了后腿。
为了做更细粒度的观测，我还会在提示词里埋一些“标记字段”。比如在参考资料区之前加一行[参考资料开始]，在用户指令之前加[当前用户请求]，这样日志搜索时就能快速定位每一段内容在上下文中的位置和角色。久而久之，这些标记还能反映出一个趋势：当模型输出质量下降时，究竟是哪一节占用了过多的Token比例。
6.2 建立评测集：回归测试是上下文工程的安全网
上下文工程的调整经常是“这次改好了A场景，结果B场景崩了”。没有评测集，你根本发现不了这种回归。我后来给项目建立了一个小而精的评测集：大概60到100条典型输入，覆盖正常请求、边界情况、容易混淆的相似任务、恶意或模糊输入这几类。每次改动系统提示词或上下文构建逻辑后，先跑一遍全部用例，对比输出是否达标。
评测集里的每条用例我都预先定义好“判定标准”，不追求模糊的主观评分，而是拆成可验证的硬指标。比如字段提取任务要求“必填字段不能为空、格式必须符合JSON Schema”，工具调用任务要求“工具名正确、参数合法、调用顺序符合逻辑”。硬指标的好处是回归测试可以自动化，至少能做第一道筛子；主观体验类指标留给人工抽检，两者结合足够撑起稳定迭代的底座。
最后补一个建议：评测集本身的用例要和真实场景保持同步。每周把线上用户反馈里出现的新问题转化成新的评测用例，上下文工程才能真正越调越稳。最怕的是评测集做完了就再也没人维护，测来测去都是那几条旧的，时间长了就是自我欺骗。
7. 六个核心技巧一个都不能少
通篇下来，其实可以把核心经验收敛成六个直接可用的技巧，方便你对照自己的项目去落地：
- 系统提示词分层设计：把角色、目标、约束、格式、资源分开写，别糊成一团。
- 上下文化预算管理：给系统提示词、用户输入、参考资料设定比例，动态截断要有优先级。
- 结构化信息分节与标注：用明确标记区分不同信息块，重点内容往前放。
- 统一工具调用与结果回注格式：所有工具输出都转成“摘要+原始数据”的结构，保持多步骤链路不散架。
- 多级记忆与检索压缩结合：工作记忆完整放，情景记忆摘要带，长期知识按需检索，各司其职。
- 全链路日志与评测集驱动迭代：记录每次调用的上下文快照，用回归测试守住每一个改动。
这六个技巧看起来都很基础，但真正难的是把它们组合在一个系统里持续运转。从我个人的经验看，上下文工程不是一次性写完提示词就结束的工作，它更像是一个需要不断维护的在线系统——调整一个环节，就要观察其他环节有没有连锁反应。某Agent团队的分享里有一句话我印象很深，大意是说，上下文工程的核心能力不是“写提示词”，而是“持续观测和调整提示词系统的能力”。这和我踩过这么多坑之后的理解完全一致。
如果你现在正被大模型应用的稳定性问题困扰，别急着怀疑模型能力，先打开自己的上下文构建代码，看看是不是某些环节偷了懒。把基础打牢之后，你会发现很多“模型不听话”的灵异事件，其实都是上下文工程没做到位。
