> For the complete documentation index, see [llms.txt](https://yeasy.gitbook.io/context_engineering_guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yeasy.gitbook.io/context_engineering_guide/di-yi-bu-fen-ren-shi-shang-xia-wen-gong-cheng/01_overview/1.2_evolution.md).

# 1.2 从提示词工程到上下文工程

## 1.2.1 提示词工程的起源与局限

**提示词工程**（Prompt Engineering）是指通过精心设计输入给模型的文本指令，来引导模型产生期望输出的技术。自 GPT-3 等大模型问世以来，提示词工程迅速成为 AI 应用开发的核心技能。

提示词工程的典型技巧包括：

* **角色设定**：如“你是一位专业的法律顾问”
* **任务描述**：清晰说明期望模型完成的任务
* **输出格式**：指定 JSON、Markdown 等结构化输出
* **少样本学习**：提供几个示例引导模型行为
* **思维链提示**：要求模型逐步推理

这些技巧在许多场景下效果显著，但随着应用场景的复杂化，提示词工程的局限也逐渐显现：

| 局限性   | 具体表现                      |
| ----- | ------------------------- |
| 静态性   | 提示词通常是预定义的，难以适应动态变化的需求    |
| 孤立性   | 聚焦于单次交互，缺乏对对话历史和外部信息的系统管理 |
| 可扩展性差 | 随着任务复杂度增加，提示词变得冗长且难以维护    |
| 缺乏工程化 | 更多依赖直觉和试错，缺乏系统化的方法论       |

## 1.2.2 上下文工程的演进

上下文工程是提示词工程的自然演进和扩展。如果说提示词工程关注的是“写什么指令”，那么上下文工程关注的是“如何构建完整的信息环境”。

```mermaid
graph LR
    subgraph "提示词工程"
        A["单一提示词设计"]
    end

    subgraph "上下文工程"
        B["系统指令设计"]
        C["知识检索"]
        D["记忆管理"]
        E["工具集成"]
        F["动态组装"]
    end

    A --> B
    A --> C
    A --> D
    A --> E
    A --> F
```

图 1-2：上下文工程的演进

Anthropic 在其工程博客 [《Effective context engineering for AI agents》](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)（2025-09-29 发布）中明确把上下文工程定义为“在推理过程中策划与维护最优 token 集合的一整套策略”，并把上下文工程称为提示词工程的「自然演进」（natural progression）——「子集」是本书为便于理解采用的说法，原文并未使用该措辞。文章引入了 context rot（上下文随窗口增大而衰减）、just-in-time retrieval（按需取回）、compaction / structured note-taking / sub-agent 这三类长任务策略等关键概念，与本章观点一致——提示词工程仍然重要，但它只是上下文工程这个更大画卷中的一部分。

## 1.2.3 核心差异对比

| 维度        | 提示词工程      | 上下文工程          |
| --------- | ---------- | -------------- |
| **关注点**   | 单次指令的措辞和格式 | 完整信息环境的设计      |
| **范围**    | 提示词文本      | 指令、数据、工具、记忆、策略 |
| **时间维度**  | 静态、一次性     | 动态、跨会话         |
| **信息来源**  | 手工编写       | 多源融合、自动检索      |
| **工程化程度** | 技巧驱动、经验依赖  | 系统化、可量化、可测试    |
| **应用场景**  | 简单任务、单轮对话  | 复杂任务、多轮交互、智能体  |

## 1.2.4 为什么需要这种演进

这种从提示词工程到上下文工程的演进，是由几个关键因素驱动的：

**因素一：任务复杂度的提升**

早期的 LLM 应用主要是简单的问答和文本生成，一个精心设计的提示词就足够了。如今的应用场景包括代码编写、数据分析、复杂推理、多步骤任务执行等，这些都需要更丰富的上下文支持。

**因素二：智能体的兴起**

AI 智能体需要在长时间跨度内持续工作，处理多个子任务，协调多个工具，维护工作状态。这种场景下，静态的提示词远远不够，需要系统化的记忆管理和上下文编排。

**因素三：生产环境的要求**

从原型到生产，AI 应用需要面对可靠性、一致性、可观测性、成本控制等一系列工程化要求。上下文工程提供了应对这些挑战的系统方法。

**因素四：模型能力的提升**

随着模型能力增强，上下文窗口扩大，模型能够利用更丰富的信息。如何高效利用这些能力，需要更高层次的工程方法。

**因素五：从“无状态”到“有状态”的飞跃（记忆工程）**

单靠扩大参数或无限制拉长上下文窗口会遇到收益递减、计算成本高昂、首 Token 延迟过长等硬性瓶颈。“记忆”正在成为继 MCP（模型上下文协议）和上下文工程之后的下一个核心。构建具备长期留存与动态调度能力的“有记忆的 AI”，是解决短时遗忘、知识碎片化、跨任务信息无法留存的关键。（关于记忆工程的系统论述，请参考[第四章](/context_engineering_guide/di-er-bu-fen-he-xin-ji-shu-yu-ce-le/04_write.md)的写入策略和[第九章](/context_engineering_guide/di-san-bu-fen-jin-jie-ji-shu-yu-jia-gou/09_agents.md)的智能体记忆管理。）

## 1.2.5 一个类比

可以用建筑来类比这种演进：

* **提示词工程** 如同为一座房子设计入口大门——门的设计很重要，但它只是整个建筑的一部分
* **上下文工程** 如同建筑设计——需要考虑整体结构、空间布局、采光通风、管道电路等所有要素的协调配合

单凭一道漂亮的大门无法成就一座优秀的建筑；同样，单凭精巧的提示词也无法构建可靠的 AI 系统。从提示词工程升级到上下文工程，是 AI 应用开发走向成熟的必由之路。