即时工程究竟是什么

提示工程是指通过调整提供给模型的指令——包括措辞、示例、角色设定和思路提示——来获得更佳的单一回答。它回答一个问题： 我该如何问这个问题呢？ 诸如少样本示例、明确的输出格式和逐步推理提示等技巧仍然适用。这些技巧依然重要，只是不再是整个系统了。

什么是情境工程？

上下文工程是一门设计模型在响应瞬间所能感知的一切信息的学科——不仅包括指令，还包括系统消息、检索到的文档、内存、工具输出、对话历史以及支配所有这些信息的规则。这个术语在2025年由Andrej Karpathy和Shopify的Tobi Lütke等人推广开来，他们将其定义为在每次调用之前，有意识地决定模型上下文窗口的内容，而不是将上下文窗口视为一个可以通过单个巧妙的提示完全控制的事物。

核心区别，一句话概括

提示工程侧重于你如何与模型沟通。上下文工程侧重于模型在生成响应时可以访问哪些信息。前者关乎措辞，后者关乎架构。

语境的构成要素

目前大多数框架都包含相同的几个组成部分，无论团队称之为五个组件还是六个组件。以下版本与当今生产系统的实际构建方式非常吻合。

为什么这种转变现在会发生

三个因素汇聚在一起。上下文窗口从几千个词元扩展到几十万甚至几百万个词元，技术上使得单次调用可以容纳更多数据。智能体系统变得普遍，这意味着模型不再只回答一个问题，而是跨越多个步骤运行，每个步骤都需要新鲜、准确的上下文。而将这些系统投入生产的企业遇到了可靠性问题，这些问题无法通过改进措辞来解决，因为真正的原因是检索质量、内存设计或工具输出格式，而不是提示语的措辞。到2026年的行业调查始终显示，数据和人工智能领域的领导者优先考虑上下文质量和人工智能就绪的元数据，而不是进一步改进提示语——这表明瓶颈已从结构上转移到了上游。

语境失效的四种方式

更大的上下文窗口并不意味着更安全。研究员德鲁·布鲁尼格（Drew Breunig）提出的长上下文失效分类法——目前已被该领域广泛引用——列出了四种不同的失效模式，值得我们了解，因为每种模式都需要不同的解决方法。

四个杠杆就能解决问题

该框架的补救措施部分提供了四个杠杆，每个杠杆都针对上述一种故障模式。

多智能体架构本质上是在系统层面应用上下文隔离：协调智能体将任务委托给子智能体，每个子智能体在自己的窗口中工作并报告一个精简的摘要，而不是每个子任务的每个步骤都堆积到一个共享的上下文中。

代理和 MCP 中的上下文工程

模型上下文协议 (MCP) 之所以重要，是因为它规范了工具和外部上下文如何暴露给模型，而不是每个团队各自发明临时格式。这种标准化本身就是一个上下文工程问题：编写良好的 MCP 服务器描述可以减少上下文混淆，而编写不佳的描述则容易导致多个 MCP 服务器同时连接时出现上下文冲突。随着代理框架的成熟，预计上下文编辑 API、具有显式写入/遗忘控制的内存工具以及能够显示特定上下文实际驱动输出的可观测性等功能将成为标准基础设施，而不是每个项目单独定制的。

Prompt Engineering 已经消亡了吗？

不，它只是被降级了，而不是被删除了。系统提示仍然是上下文工程系统中的一个组成部分，措辞在其中仍然至关重要。不再存在的是，仅仅依靠措辞就能弥补糟糕的检索流程、臃肿的内存存储或相互矛盾的工具描述这种假设。在一个长时间运行、发出数十次呼叫的代理程序中，手写提示只是众多信息来源之一——其余信息来自检索器、工具或内存存储，而正是这部分信息决定了系统在生产环境中的稳定性。

一个实用的起始框架

从临时提示过渡到真实情境工程的团队通常会经历相同的步骤：

1. 仔细查看橱窗里实际摆放的是什么。 记录一个真实的生产调用，并查看构成该调用的每一个组件——而不是你假设存在的组件。
2. 将持久性规则与情境背景区分开来。 系统级约束属于稳定的系统提示；任何因请求而改变的内容都应该动态地组装。
3. 先添加检索功能，再添加更多提示。 如果模型缺少事实，检索步骤通常比更长的指令更有效。
4. 设计具有可见性的存储器。 避免使用黑箱式存储器，它会默默地决定保留什么或忘记什么，而且没有办法检查或纠正——一个错误的存储事实会像任何其他有害的环境一样不断累积。
5. 用于检测四种失效模式的仪器。 注意反复出现的虚假声明（投毒）、长期步骤质量下降（干扰）、不相关的工具使用（混乱）以及添加新源后出现的矛盾输出（冲突）。

最佳实践

的

• 将系统提示视为一个稳定的层面，而不是整个解决方案。
• 在检索到的文档到达模型之前，对其进行重新排序和修剪——先进行宽泛的召回，再进行窄化召回。
• 对于长时间运行的智能体，应该执行压缩或总结步骤，而不是任由历史记录不受控制地增长。
• 让内存可检查、可纠正，而不是一个沉默的黑盒子。

禁忌

• 不要以为更大的上下文窗口就意味着你应该把它填满——未使用的容量并不是需要解决的问题。
• 不要将所有可用工具连接到每个代理；工具过载会显著降低函数调用准确性。
• 不要将所有子代理的工作上下文合并到一个共享窗口中——隔离不需要共享的内容。

• 系统提示与动态上下文源分开审查
• 检索管道在注入上下文之前会重新排序。
• 内存写入是可见且可纠正的。
• 长时间运行的代理具有压缩或检查点策略。
• 对连接的 MCP 服务器中的工具描述进行审核，以查找冲突。

常问问题

结论

到 2026 年，能够从代理程序中获得可靠结果的团队，并非那些拥有最巧妙的系统提示的团队，而是那些将上下文视为基础设施的团队：他们能够检索真正相关的信息，管理可检查的内存，编写前后一致的工具描述，并制定清晰的计划，以便在任务运行时间过长时压缩或隔离哪些信息。这与其说是一个编写问题，不如说是一个软件架构问题。提示工程仍然至关重要，但它不再是唯一重要的因素。