上下文工程正在取代提示词工程?一个新术语的边界

一、这个词从哪来：2025 年 6 月的三周

"上下文工程"不是某个大厂发布会上的新词，它是 2025 年 6 月三周内被几拨人先后叫出来的。Cognition 的 Walden Yan 在《Don't build multi-agents》里最早把它写成文："上下文工程是构建 AI Agent 的工程师的第一工作"。几天后 Shopify CEO Tobi Lütke 发推说更喜欢"上下文工程"而不是"提示词工程"，因为它描述的是"让任务对 LLM 可解的全部上下文的供给艺术"。LangChain 的 Lance Martin 随后给出四策略分类（写、选、压缩、隔离），Andrej Karpathy 转发背书，Drew Breunig 补了六战术版本。一个月内，这个词从博客标题变成了 Agent 框架的默认模块——LangChain 的官方文档里，上下文工程就是"可靠 Agent 的核心"。

值得注意的是，提出它的人没有一个在否定提示词。Yan 的原文恰恰是在讲：多 Agent 系统难，难在每个子 Agent 拿不到合适的上下文。问题从来不在"提示词写得好不好"，而在"该给的信息给没给、给得对不对"。

二、上下文工程到底管什么

LangChain 的四策略是目前最耐用的分法：写（把需要长期记住的东西写下来，比如记忆和状态）、选（每一步只选当下需要的信息进窗口）、压缩（窗口快满时做摘要而不是直接截断）、隔离（把不同任务、不同用户的上下文隔开，防止互相污染）。Drew Breunig 的六战术更偏实操：RAG、工具装配、上下文隔离区、剪枝、摘要、卸载——Agent 跑起来之后窗口变脏了，用这六招打扫。

和提示词工程对比，差异不在技巧，在范围。提示词工程管的是单条指令的措辞：怎么写更清楚、示例怎么给。上下文工程管的是每一步的信息供给系统：记忆、检索结果、工具返回、状态、token 预算，全部算进去。提示词是这个系统里"指令"层的写法问题，是子集，不是对手。

失败模式也完全不同。提示词写坏了，错的是一次输出；上下文烂了，Agent 会系统性跑偏：该记住的忘了（记忆没写）、不该看的看了（隔离没做）、窗口撑爆了（压缩没做）。生产环境里后者才是常态。

三、边界：什么时候提示词就够了

不是所有场景都需要上下文工程。一次性问答、简单 chatbot、流程固定的单步任务——提示词写好就够了，上四策略是杀鸡用牛刀。Anthropic 在《Building Effective Agents》里反复强调的也是这个：从最简单的方案起步，只在被证明需要时才加复杂度。

需要上下文工程的信号很明确：多步任务、长对话、Agent 要调工具、一次会话里信息越积越多。出现这些信号还只调提示词，就像水管漏水只换水龙头——修的不是漏的地方。

所以正确的关系是包含，不是替代。提示词工程是手艺，上下文工程是工程。手艺不会死，它只是住进了更大的房子里。