AI领域正在经历一场静悄悄的变革：从“提示词工程”（Prompt Engineering）转向“上下文工程”（Context Engineering）。这不仅仅是术语的更迭，它背后，是我们对如何与AI系统协同工作这一根本问题的认知升级。

这个观点可不是空xue来风。Shopify的CEO，Tobi Lutke，就曾直言不讳地表示：“我更喜欢‘上下文工程’这个叫法。它更精准地描述了核心技能：为任务提供所有必要的上下文，让LLM能据此解决艺术性问题的艺术。” 这话说得在理。

为什么我们需要这样一个转变？

Prompt Engineering的“天花板”

传统的“提示词工程”，很容易让人联想到在聊天框里输入几句指令，然后等着看结果。这种理解太过简化了。虽然我们内心希望这个词能承载构建可靠提示词的内在复杂性，但现实是，大多数人对此的理解确实停留在很浅的层面。

Context Engineering的“全景图”

“上下文工程”则完全不同，它是一个更全面、更系统的概念。Andrej Karpathy对此有过精辟的总结：“上下文工程是一门精妙的艺术与科学，核心是在上下文窗口中填充恰到好处的信息，用以完成下一步任务。” 他把“艺术”和“科学”放在一起，点明了这件事的复杂性。

到底什么是“Context”？

要理解上下文工程，我们首先得把“上下文”的定义拓宽。它绝不仅仅是发给LLM的一个提示词，而是模型在生成答案前所能看到的一切信息。这包括：

1. 指令/系统提示词

• 定义模型在对话中行为准则的初始指令集。
• 里面应该包含示例、规则这些“规矩”。

2. 用户提示词

• 用户直接抛过来的任务或问题。

3. 状态/历史（短期记忆）

• 当前这场对话，包含导致当前时刻的用户和模型的所有响应。

4. 长期记忆

• 跨多次对话积累下来的持久知识库。
• 比如学到的用户偏好、过去项目的摘要，或者一些需要记住的事实。

5. 检索信息（RAG）

• 从文档、数据库或API那里拉取的外部最新知识。
• 用来回答那些需要特定信息的问题。

6. 可用工具

• 所有可调用的函数或内置工具的定义。
• 比如check_inventory、send_email这些。

7. 结构化输出

• 对模型响应格式的定义。
• 比如指定输出JSON对象的结构。

从“便宜演示”到“神奇产品”

上下文工程的威力，在于它能将一个简单的“玩具演示”变成一个真正“有用”的产品。来看一个具体场景：

场景：AI助手收到一封邮件

内容很简单：“嗨，看看你明天有空简单聊聊吗？”

“便宜演示”版Agent的回应：

• 上下文极度贫乏，只看到了用户这一个请求。
• 回应很机械：“感谢您的消息。明天我有空。请问您想要什么时间？”

“神奇”版Agent的回应：

• 它拥有丰富的上下文，包括：
  • 日历信息（显示明天已经排满了）
  • 与此人的历史邮件（能判断出合适的非正式语气）
  • 联系人列表（识别出这是位重要合作伙伴）
  • 发送邀请或邮件的工具
• 然后它生成了这样的回应：“嗨Jim！明天我这边排得很满，一整天都是会议。周四上午有空，可以吗？我发了个邀请，看看是否合适。”

关键点就在这里：魔法不在于更聪明的模型或更巧妙的算法，而在于为正确的任务，提供了正确的上下文。

什么是Context Engineering？

简单来说，可以这样定义：

上下文工程，是设计和构建动态系统的学科。这些系统能在正确的时间，以正确的格式，为LLM提供正确的信息和工具，使其拥有完成任务所需的一切。

它具备以下几个特征：

1. 系统性，而非字符串

• 上下文不是一个静态的提示词模板。
• 它是在主LLM调用之前，运行一系列系统后产出的结果。

2. 动态性

• 上下文是实时创建的，针对具体任务进行定制。
• 一个请求可能需要日历数据，另一个请求可能需要邮件或网络搜索。

3. 正确的信息和工具，在正确的时间

• 核心工作是确保模型不会错过关键细节。
• 这既包括提供知识（信息），也包括提供能力（工具）。

4. 格式很重要

• 简洁的摘要，远好于原始的、未经处理的数据转储。
• 清晰的工具说明，也比模糊的指令要管用得多。

Agent的Context Engineering策略

对于需要长期运行的AI Agent，上下文工程显得尤为重要。Lance Martin将其总结为四大策略：

1. 写入上下文 (Write Context)

在上下文窗口之外，保存一些信息，以帮助Agent完成任务。

草稿本 (Scratchpads)

• 就像人类在解决复杂任务时做笔记一样。
• 把信息保存在上下文窗口之外，供Agent随时调用。
• 可以通过工具调用或运行时状态对象来实现。

记忆 (Memories)

• 跨会话记住信息。
• 包括反思和自生成的记忆。
• ChatGPT、Cursor、Windsurf的记忆机制就是典型例子。

2. 选择上下文 (Select Context)

将相关的上下文拉入上下文窗口。

记忆选择

• 从记忆库中挑选与当前任务最相关的记忆。
• 使用嵌入或知识图谱来建立索引。
• 核心挑战：如何确保选到的记忆是真正相关的。

工具选择

• 使用RAG为任务选择最合适的工具。
• 避免工具过多导致模型混乱。
• 提升工具选择的准确性。

3. 压缩上下文 (Compress Context)

只保留执行任务所必需的token。

上下文摘要

• 当上下文窗口使用率超过95%时，自动进行压缩。
• 采用递归或层次摘要策略。
• 在工具调用边界处添加摘要。

上下文修剪

• 使用启发式方法，过滤掉不重要的上下文。
• 比如从消息列表中删除过旧的消息。
• 也可以训练专门的上下文修剪器。

4. 隔离上下文 (Isolate Context)

将上下文分割，以帮助Agent更高效地执行任务。

多Agent系统

• 将关注点分离到不同的子Agent。
• 每个Agent拥有特定的工具、指令和上下文窗口。
• 可以并行探索问题的不同方面。

环境隔离

• 使用代码沙箱，隔离token密集型的对象。
• 通过状态对象管理上下文。
• 有选择地向LLM公开信息。

实际应用中的挑战

现实远比理论复杂。在具体实践中，上下文工程面临着不少挑战：

1. 上下文污染

• 模型产生的幻觉信息，可能会混入上下文。
• 需要建立验证和过滤机制来防范。

2. 上下文分心

• 过多的上下文，反而会淹没模型在训练数据中学到的模式。
• 需要在相关性和完整性之间找到平衡。

3. 上下文混乱

• 多余的无关上下文，会影响模型响应的质量。
• 需要精确地判断哪些信息是真正相关的。

4. 上下文冲突

• 上下文的不同部分之间，可能存在相互矛盾的信息。
• 需要建立优先级和一致性机制来处理。

工具和实现

代码Agent的Context Engineering

代码Agent面临的挑战尤其复杂。Windsurf团队的经验很有代表性：“索引代码 ≠ 上下文检索……我们做索引和嵌入搜索……通过AST解析代码，并在语义边界上分块……随着代码库规模增长，嵌入搜索作为检索启发式方法越来越不可靠……我们必须依赖grep/文件搜索、基于知识图谱的检索等多种技术组合……以及重排序步骤。” 这充分说明了，在实际场景中，没有银弹，需要组合拳。

产品中的Context Engineering

目前，主流产品都在探索如何实践上下文工程：

• Claude Code: 使用CLAUDE.md文件来存储指令。
• Cursor和Windsurf: 使用规则文件来实现。
• ChatGPT: 存储和选择大量用户特定的记忆。

未来展望

上下文工程正在成为AI应用开发的核心技能。Cognition公司的观点很直接：“上下文工程，实际上是构建AI Agent的工程师的第一要务。” 随着AI Agent变得越来越复杂，需要处理数百轮的对话，上下文工程的重要性只会越来越高。

未来的发展方向包括：

1. 更智能的上下文管理策略
2. 更好的工具和框架
3. 标准化的最佳实践
4. 跨功能的理解和协作

结论

从提示词工程到上下文工程的转变，标志着AI应用开发正在走向成熟。这不只是技术上的进步，更是一种思维方式的根本转变。

要构建强大且可靠的AI Agent，关键不在于找到那个“神奇”的提示词，也不是坐等下一个模型更新，而在于工程化地构建上下文。在正确的时间，以正确的格式，提供正确的信息和工具，让LLM能够真正“完成任务”。

这是一个跨功能的挑战，需要你深入理解业务场景，定义清晰的输出格式，并结构化所有必要的信息。这，才是让LLM发挥出全部实力的关键。

再见，Prompt Engineering；你好，Context Engineering。