Context Engineering 中文一般译成「上下文工程」。它指的是这样一件事：模型每次生成时能看到的信息是有限的，你要决定这有限的额度里放什么——系统指令、工具说明、检索来的资料、历史对话、记事本里的中间结论，还是干脆什么都不放。
Anthropic 在工程博客里给过一个比较克制的定义：上下文工程是一组策略，用来在模型推理时策划和维护那一份最合适的 token 集合。它把上下文当成一种有限资源来管理，而不是能塞就塞。
先用一句话抓住它
Context Engineering 是在有限的上下文窗口里做取舍：每一轮给模型什么信息、怎么组织、什么时候丢掉。
生活里的类比是给出差的同事装行李箱。箱子容量固定，你要挑的不是「所有可能用得上的东西」，而是「这趟行程真正会用到的东西」。塞得太满，找一件衬衫都要翻半天；漏掉充电器，整趟行程就卡住。上下文工程做的就是这个装箱决策，只是装的是信息。
为什么会出现这个词
早期用大模型，主要场景是一问一答的分类和生成，所以大家关心的是提示词怎么写。等到系统变成多轮对话、接上检索、挂上工具、拆成多个 Agent 协作，需要管理的东西就不只是那句指令了：系统提示、工具定义、MCP 连过来的外部数据、消息历史、检索结果，全都要挤进同一个窗口。
于是关注点发生了迁移：从「找到最合适的措辞」，变成「什么样的上下文配置最可能让模型做出想要的行为」。这个迁移就是 Context Engineering 这个词想标记的东西。Anthropic 把它描述为提示词工程的自然延伸——提示词工程管的是指令怎么写，上下文工程管的是整个 token 预算怎么花。
flowchart TB
subgraph Window["上下文窗口（有限）"]
Sys["系统指令"]
Tools["工具定义"]
Hist["消息历史"]
Ret["检索结果"]
Mem["外部记忆摘要"]
end
Store[("外部存储<br/>文件 / 向量库 / 看板")] -->|select 按需取| Ret
Hist -->|compress 压缩| Mem
Mem -->|write 写回| Store
Window --> Model["模型生成"]它通常包含什么
LangChain 把常见策略归成四类，这个分法在业界用得比较多。写（write）是把信息存到窗口之外，比如让模型把中间结论记到草稿文件里，这样它不占当前对话，需要时再取回。选（select）是每一轮只把相关的部分取进来，检索增强生成就是最典型的一种选法。
压（compress）是把长历史换成摘要，只保留决策、结论和还没解决的问题，丢掉冗长的工具输出。隔（isolate）是把上下文拆开，最常见的做法是交给子智能体，每个子任务有自己的窗口、工具和指令，互不污染。
工具设计也算在里面。Anthropic 强调工具本身要为 token 效率而设计：职责清晰不重叠、边界明确、参数含义一目了然。一个常见的失败模式就是工具堆得太多、功能互相重叠，模型选哪个都说得通，反而选错。
和 Prompt Engineering 的区别
Prompt Engineering 关心的是那段指令怎么写：角色怎么设、任务怎么描述、例子给几个、输出格式怎么约束。Context Engineering 关心的是整个窗口里应该有什么，指令只是其中一块。
举个具体差别：同一个代码任务，提示词工程会纠结「让我把要求说得更明确」；上下文工程会问「这次到底该读哪几个文件、要不要把整个测试输出都贴进去、上一轮那三千行日志能不能只留失败那几行」。前者调的是措辞，后者调的是信息量和信噪比。
两者不冲突，但当任务复杂到需要多轮、多工具时，决定成败的通常是后者。
和上下文窗口、RAG、压缩的关系
上下文窗口是硬约束，是这门工程存在的前提；窗口再大也是有限的，而且塞得越满，模型对中间内容的注意力越容易被稀释。RAG 是「选」这一类里最成熟的一套方案，负责在海量资料里挑出这一轮该看的几段。上下文压缩则是「压」这一类的具体机制，在窗口快满时把历史换成摘要，让会话能继续。
Anthropic 在多智能体研究里给过一个佐证：多个各自持有独立上下文的 Agent，在广度优先的研究任务上表现明显好于单个 Agent，原因之一就是每个子智能体的窗口可以完整分配给一个更窄的子任务。
容易误解的地方
第一个误解是「窗口变大了就不用管上下文了」。窗口从几千涨到几十万确实缓解了很多问题，但塞满长窗口既贵又慢，而且相关信息被淹没在无关内容里时，模型的表现会下降。有限资源的假设并没有因为窗口变大而消失。
第二个误解是把它当成纯粹的检索问题。检索只解决「从外面拿什么进来」，但历史怎么裁、工具给几个、系统提示写多长、什么时候开子任务，这些都不是检索能决定的。
第三个误解是追求「一次性给全」。把所有可能相关的资料一次塞进去，往往不如按需分批取回：前者让模型在噪声里找线索，后者让它带着当前问题去拿。
怎么判断它该不该用
单轮的翻译、改写、分类，基本不需要专门做上下文工程，写清楚指令就够了。一旦出现下面任一情况，就该认真对待：对话会持续很多轮、要读的资料超过窗口、挂了三个以上的工具、要跨多个步骤保持中间状态、或者同样的提示词在长会话里效果明显变差。
一个实用的自查是看 token 构成：把某一次请求里的 token 按来源拆开，看看系统提示、工具定义、历史、检索结果各占多少。如果发现七成额度花在了跟当前这一步无关的内容上，那就是上下文工程该介入的地方。