过去两年，行业的热词从「提示词工程」慢慢换成了「上下文工程」。这不是换名字玩——当模型窗口从几万 token 扩到上百万，真正决定智能体表现的，不再是那一句话怎么写，而是每一次调用时，模型到底看见了什么。这篇把这门手艺拆开看。
01一、从提示词工程到上下文工程
提示词工程关注的是「这句话怎么说更好」，它的隐含前提是：模型只看到一段固定的输入。这在聊天场景够用，但在智能体场景失灵——智能体的每一步都在重新构造输入：带上哪些历史、检索哪些资料、暴露哪些工具，每次都不一样。
于是问题升级了：不再是「怎么说」，而是「让模型看见什么」。这个决策做对了，平庸的提示也能跑出好结果；做错了，再漂亮的提示词也救不回来。上下文工程，就是研究这个决策的手艺。
02二、窗口里住着谁：四类内容
打开任何一个智能体的上下文窗口，里面基本住着四类住户，脾气各不相同。
▪︎ 系统提示：角色、规则、输出格式——最稳定，也应该最克制，它是契约而不是说明书
▪︎ 检索知识：RAG 拿回来的资料片段——最贵也最杂，质量直接决定任务上限
▪︎ 工具定义：可用工具的说明书——暴露得越多，注意力越稀，很多团队把全量工具硬塞进去
▪︎ 对话与中间结果：历史消息和工具返回——最容易膨胀的部分，几步之后就会挤占窗口
关键认知是：窗口是稀缺资源。哪怕物理上还装得下，每一段内容都在和其他内容竞争模型的注意力。塞进窗口的，不等于模型会用上的。
03三、核心决策：写入还是检索
上下文工程最核心的权衡，是「提前写进去」还是「用时再取回来」。这是两种世界观。
▪︎ 全部塞进去（write-heavy）：把可能用到的资料都预置在窗口里。稳定、少一次检索延迟，但贵、噪声多，无关内容还会把模型带偏
▪︎ 用时再取（retrieve-on-demand）：窗口只放任务本身，资料按需检索。省、准，但检索失败任务就失败——瓶颈从生成转移到了检索
▪︎ 实践中几乎都是混合态：系统提示常驻，知识按需取，历史滚动压缩
判断倾向哪边的经验法则：如果某类知识在大多数任务里都会用到，值得常驻；如果只在特定子任务里用到，就该放进检索库，按需召回。把例外当常态写进窗口，是最常见的浪费。
04四、上下文不是越长越好
「窗口够大就多塞点」是最顺手也最危险的直觉。长上下文有两个被反复验证的问题。
▪︎ 迷失在中间：模型对窗口开头和结尾的内容召回较好，中间部分明显偏弱——关键资料恰好放在中间时，等于白放
▪︎ 注意力稀释：无关内容不只是浪费 token，它会实际拉低准确率。测试显示，往窗口里塞几页不相关文档，模型在原任务上的表现就会下降
所以历史裁剪不是可选项。常见做法有三层：滚动摘要（老对话压成几句话）、只保留决策与事实（丢弃过程性闲聊）、丢弃原始返回（工具返回只留解析后的结果，超长的原文落盘存档，需要时再读）。
05五、一份最小可行的上下文清单
如果团队要给自己的智能体做一次上下文体检，可以对着这张表逐行过。
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
这张表的核心思想只有一句：窗口里的每一段内容，都应该能回答「为什么是它在这里」。答不上来的，就是候选删除项。
06六、手艺在看不见的地方
提示词写得好，用户看得见；上下文工程做得好，用户感知不到——它表现为这个智能体「稳」「省」「准」：不跑偏、不浪费、不漏关键信息。
检验标准也很朴素：同样的模型、同样的工具，只换上下文方案，结果是否明显变好。如果答案是否，说明你的瓶颈不在上下文；如果是，那这门隐形手艺，就是你拉开差距的地方。
