从提示词到上下文
早期与模型打交道，功夫花在打磨一句提示词上——同一个指令换十种措辞，看哪种产出更好。这个「咒语雕花」时代正在过去。真实的 Agent（智能体）应用里，模型每一步看到的不是一句话，而是整个上下文窗口：系统提示、工具定义、检索内容、对话历史挤在同一段文本里，互相争夺有限的空间。窗口是预算不是仓库——塞得越多不等于知道得越多，注意力反而被稀释。本站在上下文窗口一文里讲过窗口的机制，这篇讲怎么管理这份预算：这门手艺现在叫上下文工程。
成分清单与预算分配
一次典型的 Agent 请求，上下文大致由六类成分构成：
- 系统提示（角色、规则、边界）：行为的锚，值得稳定投入，但控制在一屏之内——规则越少，越被遵守。
- 工具定义：每个工具的名字、描述、参数模式都占预算，挂几十个工具会明显稀释注意力，按任务裁剪。
- 记忆与用户信息：长期偏好、关键事实，常驻但精炼。
- 检索内容：单次任务里最占空间的成分，预算波动最大。
- 对话历史：随轮次增长，是清理的重点对象。
- 任务指令：本次要做什么、判定标准，放在末尾，紧贴生成位置。
分配原则：稳定的成分（系统提示、工具）精而固定，动态的成分（检索、历史）按需进出。
加法三问
往上下文里加任何一段内容前，问三个问题：它会改变模型行为吗？模型没有它就做不对吗？有没有更短的等价表述？三问全过才加。最常见的浪费是第三问失守：大段原文能压缩成几行摘要，任务描述能从五段缩成三句。上下文里每个词都在花注意力预算，「可能有帮助」不是放行的理由。
减法四刀
删过期信息。 上一个任务的目标、已经废弃的计划、改过三轮的旧方案，留在上下文里只会干扰当前决策，直接删。
压缩历史。 多轮对话用滚动摘要替代全文：旧轮次压成关键结论，近几轮保留原文。
外置状态。 长状态不放上下文，放文件或数据库，按需读取。Coding Agent 的 todo 外置就是范例——任务清单写进文件，用到哪条读哪条，本站 Coding Agent 一文分析过这个设计。
隔离子任务。 大任务拆给子上下文各自干净地跑，只把结果摘要带回主上下文，避免中间过程污染主线。
结构化排版
同样是那点信息，排得清楚模型就看得清楚。用标题和分隔符把不同来源的内容分区，别让检索文档与对话历史混作一团。重要约束放头尾：模型对上下文首尾的注意力明显高于中段，「lost in the middle」描述的正是这个现象，本站长上下文一文讨论过它的机理与应对——最关键的指令要避开中段。分区标记用 Markdown 标题或 XML 式标签都可以，后者在嵌套与转义上更严格，两类实践都有大量生产验证。一个分区模板大致长这样：
## 系统规则
角色与全局约束
## 检索资料
本次检索到的内容，按来源分小节
## 任务
本次要完成的事与判定标准
组装代码化
上下文不该是手工拼接的字符串，而应该是代码：模板加条件分支，按任务类型、模型、预算动态组装。组件化之后才有版本管理——上下文模板改一版，用同一组评测用例对比新旧版本的表现，A/B 出结论再发布。把上下文当代码管理，改动才有据可查，效果才可复现；当作玄学调参，就永远在「感觉变好了」里打转。
反模式清单
- 一次塞全部背景：把整个项目的文档倒进上下文，用「全」换「稳」，实际换来稀释与成本。
- 依赖模型自己挑重点：不加引导地把材料堆进去，指望模型领会意图——它只会按位置和标记分配注意力。
- 永不清理的滚动历史：历史只增不减，长会话后半段被旧信息淹没，质量缓慢下滑而无从察觉。
小结
上下文工程是 Agent 时代的核心工程技能：窗口是预算，加法要过三问，减法有四刀，排版要分区、约束放头尾，组装要代码化、可版本化。把每一次上下文变更都当作一次代码变更来管理，Agent 的稳定性才谈得上持续改进。
读者留言
COMMENTS 暂无还没有留言，来说第一句？