【AI】从 Prompt Engineering 到 Context Engineering：AI 应用的范式转移
1. 为什么要从 Prompt 到 Context
过去两年，”Prompt Engineering” 几乎是每个想用好大模型的人都要学的技能。精心设计角色、任务描述、输出格式，往往就能让模型在单轮对话中达到意想不到的效果。
但当我们从「问答」走向「办事」——也就是构建 AI Agent 时，这种思路开始捉襟见肘。
想象一个能帮你处理客服工单的 Agent，它需要：
- 知道：公司产品文档、历史工单、FAQ
- 记住：当前对话、用户偏好、之前处理过的类似工单
- 能用：CRM、工单系统、知识库等工具
- 遵守：公司流程、权限范围、合规要求
光靠一段精心雕琢的提示词，根本塞不下这些信息。更关键的是：在 Agent 的多轮执行过程中，哪些信息该放进上下文、什么时候该放、什么时候该丢，才是决定成败的核心。
业界近来流行的一个说法概括得很精炼：“Prompt Engineering is about writing the right instructions. Context Engineering is about providing the right information and tools in the right format at the right time.”
2. Prompt Engineering vs Context Engineering
两者并非完全对立，而是从不同视角看待同一个问题。可以用下面的对比来理解：
| 维度 | Prompt Engineering | Context Engineering |
|---|---|---|
| 关注点 | “怎么说”（指令、角色、格式、示例） | “给什么”（信息、历史、工具、状态、约束） |
| 适用场景 | 单轮任务、固定流程的问答 | 多轮任务、长期运行的 Agent、复杂工作流 |
| 思路 | 优化提示词文本本身 | 优化上下文窗口的「信息架构」 |
| 方法论 | 少样本（Few-shot）、思维链（CoT）、角色扮演等 | RAG、记忆系统、工具清单、上下文压缩、动态裁剪、状态管理等 |
| 类比 | 给演员一张剧本 | 给演员整套道具、背景板、前情提要以及必要的联系方式 |
简单来说：Prompt Engineering 关心「说什么」，Context Engineering 关心「该让模型知道什么」。
3. 上下文工程的核心要素
要做好 Context Engineering，需要从多个维度统筹信息：
3.1 系统指令（Instructions）
仍然不可或缺，但不再是全部。好的系统指令应该简洁且聚焦，描述 Agent 的身份、目标、行为边界和安全约束，而不是试图用长篇大论覆盖所有场景。
3.2 用户输入与历史（History）
多轮对话的历史是上下文中最容易膨胀的部分。直接全量塞入往往既贵又会稀释注意力。常用手段包括：
- 摘要（Summarization）：将早期对话压缩成要点摘要
- 滑动窗口（Sliding Window）：只保留最近 N 轮对话
- 关键信息提取：只保留任务相关的事实、决策、约束
3.3 知识注入（Knowledge）
Agent 要处理真实业务，就必须接入外部知识。常见方式：
- RAG（Retrieval-Augmented Generation）：根据当前任务动态检索最相关的文档片段
- 长期记忆（Long-term Memory）：记住用户偏好、常用配置、历史决策等跨会话信息
- 实体记忆：对人、项目、产品等实体建立结构化记忆，避免每次都重新解释
3.4 工具与能力（Tools）
在工具调用日益普及的今天，工具定义本身就是上下文的一部分。一个常见误区是「把所有工具都塞进去」。实际上应该：
- 按需暴露：只向 Agent 暴露当前任务可能用到的工具
- 清晰描述：工具名、参数、用途要足够清晰，避免模型选错或传错参数
- 精简 Schema：过于复杂的 JSON Schema 会占用大量 token，还可能误导模型
3.5 状态与约束（State & Constraints）
对于长任务，模型需要知道「现在做到哪一步了」。这可能是任务清单（Todo List）、已执行的操作记录、待办事项、错误信息等等。将这些结构化状态显式地写入上下文，往往比单纯堆砌历史对话更有效。
4. 实践中的权衡
Context Engineering 本质上是一门「取舍的艺术」。在实践中永远要权衡以下几个因素：
- Token 成本：每多一段信息都要花钱。不是所有信息都值得花费 token
- 注意力稀释：研究表明，上下文越长，模型对中间信息的关注往往会下降。堆砌越多不一定越好
- 延迟：更长的上下文意味着更慢的首字延迟，影响用户体验
- 信息时效：有些信息只在当前步骤有用，过了就该清理
- 可观测性：比起调试一个 10 行的提示词，排查「为什么 Agent 在第 5 步忘记了第 2 步的结论」要困难得多
5. 写在最后
可以预见，未来招聘 AI 工程师时，「擅长写 Prompt」或许还会被提及，但「擅长设计上下文」会越来越常成为硬性要求。
从某种意义上说，Context Engineering 更接近传统软件工程中的「系统设计」。它不是在雕琢句子，而是在设计信息流：数据从哪来、该怎么过滤、以什么形式呈现、何时更新、何时丢弃。
Prompt Engineering 教会了我们「怎么跟模型对话」，Context Engineering 正在教会我们「怎么为模型搭建工作环境」。
对于想从「玩转 Chatbot」走向「落地 Agent」的开发者来说，这个转变值得花时间去思考和实践。