上下文工程2026：取代提示工程成为Agent核心的学科
上下文工程2026：比提示工程更重要的六件事
📜 目录
上下文工程2026：比提示工程更重要的六件事
提示工程优化你写的那段话。上下文工程优化模型看到的全部内容：系统指令、检索文档、工具定义、对话历史、记忆，以及它们在有限窗口里怎么抢位置。
区别在哪？把提示词打磨到完美，但塞进二十个用不上的工具定义和一堆无关检索块，输出照样崩。2026年质量差距主要产生在后一件事上。
一、先把窗口当预算，不当容器
窗口不是"能装多少装多少"的盒子，是一笔要分配的预算。每一段内容都在花token，也都在稀释注意力。
一个实用的分配比例：
| 内容 | 建议占比 | 超了怎么办 |
|---|---|---|
| 系统指令 | 5%-10% | 拆分，把低频规则移到工具说明里 |
| 工具定义 | 10%-15% | 按当前步骤裁剪 |
| 检索内容 | 30%-40% | 减top-k、加rerank、去重 |
| 对话历史 | 20%-30% | 滚动摘要 |
| 输出预留 | 15%-20% | 绝不能挤占 |
最后一行最常被忽略。上下文塞满，模型没有空间输出完整答案，表现是回答被截断或突然变简短。
二、六件事，按收益排序
1. 结构化system prompt
把指令分成明确小节，用分隔符隔开：角色、任务、约束、输出格式、示例。
<role>你是客服分诊助手</role>
<task>判断工单类型并给出优先级</task>
<constraints>
- 不确定时输出 unknown，不要猜
- 不得承诺赔付金额
</constraints>
<output_format>{"type": "...", "priority": "..."}</output_format>
改法：把现在的一大段说明按这五节重排。同样的字数，模型遵守率会明显不同，因为结构化标记给了模型明确的边界。
2. 动态检索，只注入真正相关的块
不是检索到就全塞。先做相似度过滤，再rerank，最后只留top 3-5块。
改法：给检索加一个相似度阈值，低于阈值宁可不注入并明确告诉模型"没有找到相关资料"。让模型在空上下文上说"不知道"，比让它在一堆噪声里编答案好。
3. 记忆分层
工作记忆（当前任务上下文）、会话记忆（本次对话摘要）、长期记忆（跨会话的用户偏好和历史结论）分开存。只有工作记忆直接进上下文，长期记忆按需检索后注入。
改法：检查现在的实现是不是把所有历史都拼进prompt。是的话先拆成两层，规模上去之后这套一定会崩。
4. 滚动摘要
每N轮把旧对话压成摘要，保留事实和决定，丢弃原始措辞。
改法：摘要指令里明确要求保留"用户提出的约束"和"已经确认的决定"，这两类信息丢失的代价最大。
5. 工具定义裁剪
只发当前步骤需要的工具。二十个工具的定义既费token又干扰选择，模型在太多选项里挑错概率会上升。
改法：按子任务给工具分组，每步只挂当前组。如果工具必须全量暴露，就把描述压到一句话，参数说明放进按需加载的文档。
6. 优先级排序
模型对上下文的开头和结尾关注最强，中间部分容易漏。关键约束放末尾，背景资料放中间。
改法：把最重要的三条规则从开头挪到最末，或者在末尾重复一次。这个改动几乎没有成本，效果常被低估。
三、两个指标，每周看一次
| 指标 | 算法 | 期望方向 |
|---|---|---|
| 上下文利用率 | 已用token / 窗口上限 | 稳定在60%-75% |
| 检索精确度 | 相关token / 注入token | 上升 |
两个指标的健康方向是"同样的质量，更少的上下文"。如果上下文利用率一路涨而质量没涨，说明在往窗口里堆无效内容。
四、一周落地计划
| 天 | 做什么 |
|---|---|
| 第1天 | 加滚动摘要，处理长对话 |
| 第2天 | 裁剪工具定义，按任务分组 |
| 第3天 | 关键约束移到末尾，提高遵守率 |
| 第4-5天 | 接两个指标到监控，跑一周基线 |
| 第6-7天 | 在评估集上A/B，确认质量没掉 |
别一次全改。六项一起上，质量掉了不知道是哪项的问题。
五、三个常见误解
误解一：窗口越大越省事。 窗口大只意味着单次能塞更多，不意味着模型会用。长上下文中间段落的注意力衰减是普遍现象，塞进去和用上是两件事。
误解二：上下文工程就是写更好的提示词。 提示词只是其中一节。工具定义、检索策略、记忆结构、注入顺序，每一项对结果的影响都不小于措辞。
误解三：这是临时技巧。 它是系统设计的一部分。RAG、Agent记忆、长对话、模型路由，全都要处理"什么进上下文"这个问题。
常见问题
Q：小项目也要做这些吗？ A：做两件就够：结构化system prompt 和 检索阈值。这两项成本最低，收益最直接。
Q：怎么判断是上下文问题还是模型能力问题？ A：把同一份精简过的上下文喂给同一个模型。质量明显提升，就是上下文问题；没变化，才是模型能力问题。
Q：摘要会不会丢关键细节？ A：会。解决办法是双轨：摘要进上下文，原文留在数据库，模型说"需要细节"时再按需取回原文片段。
Q：有没有工具能自动做这些？ A：编排框架提供了部分能力（检查点、状态管理、消息裁剪），但注入什么、留什么、怎么排序，仍然要按你的业务自己定。
注：不同模型的上下文上限和注意力特性有差异，具体参数以各厂商官方文档为准。
相关文章
本站文章由编辑人工撰写，收录的工具均经过实测或公开资料核验。文中链接指向工具官网或 GitHub 仓库，仅作信息参考，不构成付费推广。