Skip to content

情境工程:超越提示工程的演进

Updated: at 12:45 PM

人工智能领域经历了从早期“提示工程”到如今“情境工程”的显著演进。虽然提示工程在GPT-3时代以巧妙的技巧和文字打磨激发了我们的想象,但情境工程代表了构建生产就绪AI系统的一种更系统化、可扩展的方法。

什么是情境工程?

情境工程是为任务提供所有上下文,使LLM能够合理地解决问题——正如Tobi Lutke所描述的那样。更精确地说,情境工程是构建动态系统的学科,这些系统为LLM完成某一任务提供所需的一切。

不同于聚焦于精炼单次指令的提示工程,情境工程采用系统级的方法。它涵盖围绕AI模型的整个信息生态系统——包括记忆、检索系统、工具集成以及跨多次交互的信息动态流动。当在自主代理与控制代理架构之间做决策时,这种系统思维变得尤为关键,其中上下文管理决定了代理行为和可靠性。

根本差异:提示 vs 情境工程

这两种方法的区别比许多人意识到的更深:

范围与目的

提示工程关注在某一时刻对模型说什么。情境工程关注在你说这话时模型知道什么——以及它为什么应该在乎。

提示工程:

  • 在单次输入-输出对内操作
  • 聚焦于编写清晰、具体的指令
  • 大量依赖文字打磨来把事情“做得恰到好处”
  • 适用于一次性任务和创造性应用
  • 仅凭聊天界面即可完成

情境工程:

  • 跨会话管理整个上下文窗口
  • 为规模化的一致性性能设计系统
  • 聚焦于在正确的时间提供正确输入
  • 为长时间运行的工作流和复杂状态管理而构建
  • 需要记忆模块、RAG系统和API协调

关系与层级

提示工程是情境工程的一个子集,而不是相反。可以这样想:提示工程告诉模型怎么思考,但情境工程给予模型训练和工具去完成任务。

情境工程将提示工程作为更大架构框架中的一个组成部分。提示工程聚焦于为单个任务编写指令,而情境工程设计的管理信息流跨越多个交互。当从单代理扩展到多代理系统时,这种层级关系变得明显,其中个体提示设计必须考虑代理协作与协调的更大上下文。

情境工程的核心原则

基于构建生产AI代理的实践经验,已浮现出若干关键原则:

1. 围绕KV缓存设计

KV缓存命中率是生产阶段AI代理最重要的单一指标。它直接影响延迟和成本。该原则驱动若干实际设计决策:

  • 保持提示前缀稳定:即使单个令牌的差异也可能使缓存失效
  • 使上下文仅追加:避免修改之前的行动或观察
  • 使用确定性序列化确保一致的JSON键顺序
  • 明确标记缓存断点:在架构中考虑缓存过期

经济效益是巨大的——以Claude Sonnet为例,缓存令牌每百万令牌0.30美元,而未缓存的为3美元,相差10倍。当构建通过情境工程革新软件开发经济的代理AI系统时,这些效率提升变得至关重要,因为上下文管理成本直接影响项目可行性。

2. 屏蔽而非移除

随着AI代理能力增强,其动作空间自然扩大。屏蔽并非移除工具,而是在解码过程中屏蔽令牌logits以防止(或强制执行)某些操作基于当前上下文。

这种方法解决了两个关键问题:

  • 通过保持工具定义稳定来维护KV缓存有效性
  • 防止模型困惑于之前引用但不在上下文中的工具

3. 将文件系统作为上下文

现代LLM提供大型上下文窗口,但在实际的代理场景中,这通常是不够的,有时甚至是一种负担。解决方案是将文件系统视为终极上下文:

  • 无限大小且持久存储
  • 代理本身可直接操作
  • 启用始终可恢复的压缩策略
  • 允许模型将长期状态外化而非保存在上下文中

这种方法直接与为真正代理AI的模型上下文协议(MCP)基础保持一致,其中通过MCP的结构化上下文交换使代理能够高效管理和共享超出其即时上下文的信息。

4. 通过复述操纵注意力

通过不断地重写待办事项列表,Manus正在将目标复述到上下文的末尾。这将全局计划推入模型的近期注意力范围,避免“中间丢失”问题并减少目标偏离。

这种技术有效地利用自然语言来偏向模型对任务目标的关注,而无需架构变更。

5. 保留错误内容

反直觉地,最有效的技术之一是保留失败轨迹:当模型看到一次失败的行动——以及结果观察或堆栈跟踪——它隐式更新其内部信念。这将其先验移离类似动作,减少重复同样错误的机会。

错误恢复已成为真正代理行为的最清晰指标之一,尽管它在学术基准中仍然不足。

6. 避免少样本提示

虽然少样本提示对提示工程有价值,但它在代理系统中可能适得其反。语言模型是出色的模仿者;它们模仿上下文中的行为模式。如果你的上下文充满类似的历史动作-观察对,模型会倾向于遵循该模式,即使它不再是最佳选择。

解决方案是引入结构化变化——不同的序列化模板、替代措辞和受控随机性来打破模式。

实践实现策略

内存管理

情境工程需要复杂的内存管理策略:

  • 分层内存:系统提示、会话内存和工作内存
  • 选择性压缩 保留关键上下文同时压缩冗长观察
  • 内存索引:对相关过去交互的高效检索

工具集成

不同于简单的基于提示的系统,情境工程代理需要:

  • 动态工具加载:运行时发现和集成能力
  • 工具状态管理:跟踪工具可用性和约束
  • 结果情境化:将工具输出有意义的融入进行中上下文

工作流编排

情境工程超越单个模型调用来编排整个工作流:

  • 状态机:管理不同上下文中的代理行为
  • 上下文转换:不同操作模式之间的无缝交接
  • 错误恢复:在保留上下文中优雅处理失败

这些编排模式与B2A SaaS新兴模型相结合时尤其强大,其中情境工程代理能无缝与多个专用服务交互。

AI系统设计的未来

情境工程仍是一门新兴科学——但对代理系统而言,它已必不可少。模型可能变得更强、更快、更便宜,但任何原始能力都无法替代对记忆、环境和反馈的需求。

随着我们向更复杂AI代理迈进,情境工程将成为AI系统架构师的主要学科。情境工程将AI代理从基础聊天机器人转变为强大的、目标驱动的系统。

其影响超越技术实现,触及AI系统设计的根本问题:

  • 我们如何构建在扩展交互中保持连贯行为的AI系统?
  • 哪些架构模式实现从原型到生产的可靠扩展?
  • 我们如何平衡模型能力与系统约束和要求?

结论

从提示工程到情境工程的演进反映了AI系统从实验工具到生产基础设施的成熟。虽然提示工程对特定应用仍然有价值,但情境工程提供了构建可靠、可扩展AI代理所需的系统化框架。

提示工程让你得到第一个好的输出。情境工程确保第1000个输出仍然是好的。随着组织越来越依赖AI代理进行关键工作流,理解和实施情境工程原则对长期成功至关重要。

未来属于能在复杂、多步交互中保持连贯行为的AI系统。情境工程提供了构建这些系统的概念框架和实用技术。代理的未来将由每一个情境构建。好好地设计它们。


要深入了解生产视角下的情境工程实践,我强烈推荐阅读Manus团队的详细案例研究:Context Engineering for AI Agents: Lessons from Building Manus

相关阅读:


Previous Post
AGI 是一个工程问题
Next Post
软件3.0——AI时代的编程