上下文工程。
决定一个智能体能否工作的最大杠杆，不是你选了哪个模型，也不是你把提示词措辞得多巧妙——而是你在每一步决定往上下文窗口里放什么、又刻意不放什么。本条目定义上下文工程，把它与提示词工程区分开，点明它要防的那种失败，并给你真正会去拉动的具体杠杆。
提示词工程打磨一条消息；上下文工程编排整个窗口。
提示词工程是把一条指令措辞好的手艺——任务清晰、示例得当、输出形式正确。它依然重要。但智能体不是跑一条提示，而是跑一个循环；每一轮，模型看到的是一整份拼装好的载荷：系统提示、运行中的指令、检索到的文档、从外部存储拉回的记忆、之前工具调用的结果、对话历史、少样本示例，以及当前任务。上下文工程就是决定这份载荷里放什么、以什么形式、在哪一步放的工程。
上下文窗口是一份有限的共享预算。上下文工程就是把这份预算花好的编辑工作：你不是在写一条消息，而是在编排模型行动前读到的一切。作为 2025 年间对智能体开发者取代了"提示词工程"的框架，它反映了一个朴素的观察——一旦系统有了记忆、工具与检索，任何单条指令的措辞都只是决定输出的一小部分。
一个有用的画面：窗口是一张书桌。提示词工程写一张清楚的便条放到桌上。上下文工程决定桌上到底摆哪些参考书、工具打印件与便利贴——并把不再需要的清走，好让模型能找到那张便条。
它要防的失败：上下文更多，不等于更好。
幼稚的本能是把一切可能相关的东西"以防万一"塞进窗口。这会适得其反。长上下文会以一种可度量的方式退化，常被称为上下文腐烂（context rot）或迷失在中间（lost in the middle）：窗口越满，模型对任一给定 token 的注意越不可靠，埋在长载荷正中间的材料实际上会被忽略。无关、过期或自相矛盾的上下文并不会无害地待在那里——它会分散模型注意、稀释信号、诱使它据过时事实行动，并在每一轮都消耗你的 token 与延迟。
- 分散注意。十份松散相关的文档，会让那一句真正相关的话比单独一段精选片段更难被用上。
- 过期。十二步之前的一个工具结果如今可能已经错了；把它留在窗口里，就是在诱使模型信任它。
- 成本与延迟。窗口里的每个 token 在循环的每一轮都被重新处理一遍——臃肿的上下文是一笔反复缴纳的税，而非一次性的。
因此目标不是最多的上下文，而是正确的上下文：那一小组高信号的 token，恰好足以让模型采取下一个正确动作。
你真正拉动的杠杆。
上下文工程是一小把具体技术，用来把正确的 token 放进去、把错误的 token 拿出来：
- 按需检索，而非预加载。不要把整个知识库贴进提示，而是用检索（RAG）只取这一步需要的东西。窗口装的是查询结果，不是整个语料。
- 压缩历史。当对话或工具调用日志变长时，把旧的轮次总结成一段紧凑的笔记，并丢掉原始记录。智能体保留要点，而非每个字节。
- 卸载到记忆。把持久状态——决定、用户事实、任务进度——推入外部记忆存储，按需读回，而不是整场会话都把它扛在窗口里。
- 隔离子任务。把一个自成一体的子问题交给拥有自己干净窗口的子智能体，只把答案返回主循环——这样一个嘈杂的子任务永远不会污染父级的上下文。
- 裁剪工具输出。一份原始 API 响应可能有数千 token，而其中只有三个要紧。在工具结果进入窗口之前，先把它后处理到模型需要的字段。
这并非五个各自独立的话题——它们是同一场游戏里的五步棋。RAG、记忆与历史压缩，全都服务于同一个目标：让窗口保持小、当前且相关。
这在智能体设计中如何落地。
把上下文的拼装当作头等的、逐步的决策，而非事后补救。每一轮都问：为了正确地选出下一个动作，这个模型最少需要看到什么？然后就把窗口精确地搭建到那个程度——拉进相关记忆、检索相关文档、压掉已过时的部分，其余一律不放。
令人不安的一点是：模型无法告诉你它缺了什么、或什么正在淹没它。你递给它什么窗口，它就自信地据此行动。这让窗口成为你的责任，其度量方式和本节里的一切一样可靠——用一组在像你的任务上的评测集，在你改变放进去的内容时比较结果。当你准备深入时，本站的上下文预算、上下文压缩与有效上下文 vs 宣称上下文等深入解析，会把这些杠杆带入生产级的细节。