# 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 集合的一整套策略”，并指出提示词工程是上下文工程的一个子集。文章引入了 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 应用开发走向成熟的必由之路。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://yeasy.gitbook.io/context_engineering_guide/di-yi-bu-fen-ren-shi-shang-xia-wen-gong-cheng/01_overview/1.2_evolution.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.