Context Engineering正在取代Prompt Engineering

过去几年，用大语言模型做开发往往从一个问题开始：

"我应该给模型什么样的 prompt？"

开发者们不断尝试 system prompt、角色指令、few-shot 示例、XML 标签、Markdown 格式，以及越来越复杂的指令组合。

一个更好的 prompt 可以把不可靠的输出变成意外有用的结果。

但现代 AI 应用正在变得越来越复杂。

我们不再只是让 LLM 总结一段文字或生成一封邮件。我们在构建 AI Agent——它们搜索数据库、调用 API、记住之前的对话、读取文档、使用工具、执行代码，并在多个步骤中协同工作。

在这些系统中，写好一个 prompt 只是问题的一部分。

更大的问题变成了：

在这个精确的时刻，模型应该访问哪些信息？

这正是 context engineering（上下文工程）试图解决的问题。

Anthropic 将上下文工程描述为 prompt 工程的自然演进：开发者不再只关注 prompt 内部的指令，而是管理模型在推理过程中可用的整套信息。

这一转变改变了我們构建 AI 应用的方式。

首先，什么是 Prompt Engineering？

Prompt engineering 是设计指令的实践，帮助 LLM 产生我们想要的行为或输出。

You are a senior Python developer.

Review the following code for:
- security issues
- performance problems
- readability

Return your answer as:
1. Issue
2. Why it matters
3. Suggested fix

Code:
{code}

这没有任何问题。

事实上，好的 prompt 仍然极其重要。

开发者已经明确定义了：

……以及期望的输出格式。

对于相对孤立的任务，这可能就足够了。

但想象一下把它变成一个 AI 编程助手。

现在模型可能还需要知道：

多个项目文件的内容，

项目使用的框架，

开发者之前做出的决定，

可用的开发工具，

上一次终端命令的错误，

团队使用的编码规范，

以及哪些文件已经被修改过。

从技术上讲，你可以把所有东西都塞进一个巨大的 prompt。

但这会产生另一个问题。

更多的上下文并不自动意味着更好的上下文。

那么，什么是 Context Engineering？

Context engineering 是决定 AI 模型接收什么信息、在什么时候接收、以及这些信息如何组织的流程。

LangChain 将这个概念描述为：以正确的格式提供正确的信息和工具，让 LLM 能够成功完成任务。

这样理解两者的区别：

Prompt engineering 问的是：

我应该如何措辞这个指令？

Context engineering 问的是：

模型需要在什么基础上才能正确执行这个指令？

那个上下文可能比用户的 prompt 包含多得多。

Context
│
├── System instructions
├── User message
├── Conversation history
├── Retrieved documents
├── Long-term memory
├── Few-shot examples
├── Available tools
├── Tool descriptions
├── Tool results
├── Application state
├── User preferences
└── Output requirements

Prompt 仍然在。

它只是一个更庞大的上下文架构中的一个组件。

一个例子：电商客服助手

想象我们正在为一家电商构建一个 AI 客服助手。

一个 prompt engineering 方式可能长这样：

prompt = f"""
You are a helpful customer support agent.

Answer the customer's question politely.

Customer:
{message}
"""

response = llm.generate(prompt)

假设客户问：

Where is my order?

这个 prompt 完全合理。

但模型给不出有用的回答。

因为它不知道：

客户指的是哪个订单，

订单是否已发货，

由哪家快递公司处理，

或者是否存在配送问题。

再多的改写：

Be extremely helpful.

Think carefully before answering.

都不能凭空给模型它没有的信息。

相反，应用需要组装相关的上下文。

概念上，系统可能做类似这样的事情：

customer = get_customer(user_id)
order = get_latest_order(customer.id)
shipment = get_shipment_status(order.id)

context = {
    "customer": customer,
    "order": order,
    "shipment": shipment
}

response = llm.generate(
    instructions=SUPPORT_INSTRUCTIONS,
    user_message=message,
    context=context
)

现在模型可能收到：

Customer:
Alex

Order:
#81452

Status:
Shipped

Courier:
FedEx

Estimated delivery:
August 12

Latest tracking event:
Package arrived at regional facility

突然，回答"Where is my order?"变得轻而易举了。

重要的改进不是 prompt 里某个更聪明的句子。

而是更好的上下文。

为什么 Context Engineering 变得越来越重要？

这种变化与 AI 应用本身的演进密切相关。

早期的 LLM 应用通常很简单：

Input → LLM → Output

现代 agentic 应用可能长这样：

User
 ↓
Agent
 ↓
Search documentation
 ↓
Read database
 ↓
Call API
 ↓
Evaluate result
 ↓
Call another tool
 ↓
Update state
 ↓
Generate response

Agent 可能反复调用模型并使用工具，直到完成任务。LangChain 当前的 agent 文档将这个基本循环描述为模型调用和工具执行之间的交替。

每一步都会生成更多信息。

工具响应累积。

对话历史增长。

文档被检索回来。

中间推理产生新的状态。

最终，问题不再仅仅是：

"我如何给模型指令？"

而是：

"在所有这些信息中，哪些片段应该出现在下一次模型调用中？"

这是一个上下文工程问题。

上下文窗口并非无限的Working Memory

现代模型可以处理非常大的上下文窗口，但开发者不应该把它们当作数据库，认为只需把所有东西都一股脑塞进去。

Anthropic 指出，模型性能可能随着上下文增长而下降，并将上下文描述为一种有限资源，收益递减。因此，相关信息需要仔细筛选，而不是不加区分地积累。

这为 AI 开发者创建了一条重要规则：

目标不是最大化的上下文。目标是有用的上下文。

想象让一个开发者修复大型代码库中的一个函数。

给他相关的函数、它的测试、相关的接口和当前的错误，可能会有帮助。

把整个公司代码库、每一条曾经发送的 Slack 消息、六年完整的 Git 历史和所有内部文档打印到他桌上，可能不会。

LLM 面临着类似的信息管理问题。

额外的信息可能造成：

冲突的指令，

无关的干扰，

以及难以识别真正重要的信息。

OpenAI 最近的工程指南同样讨论了避免 agent 系统中的上下文膨胀，因为不必要的工具、历史和集成会增加成本并分散模型注意力。

因此，上下文工程既涉及添加信息，也涉及移除信息。

Context Engineer 实际控制什么？

你不一定需要一个叫"Context Engineer"的新职位。

上下文工程更适合被理解为构建 AI 系统的开发者越来越需要的一项技能。

以下是你可能控制的几个主要方面。

1. Prompt 模板

这些是你的传统 prompt：

You are a financial document analyzer.

Prompt engineering 在这里仍然重要。

2. 检索到的知识

你的应用不需要把整个知识库塞进 prompt，而是在需要时检索相关信息。

User question
      ↓
Search knowledge base
      ↓
Retrieve relevant documents
      ↓
Add documents to context
      ↓
LLM generates answer

这就是检索增强生成（retrieval-augmented generation，简称 RAG）成为如此重要的 LLM 架构的原因之一。

3. 对话历史

一个聊天机器人可能有数百条之前的消息。

模型可能不需要它们全部。

你的应用可以保留：

Last 10 messages
+
Summary of older conversation
+
Important saved facts

而不是反复传递整个对话。

4. 工具定义

对于 agent，工具本身就是上下文。

模型需要理解有哪些能力可用。

tools = [
    search_web,
    query_database,
    send_email,
    create_calendar_event
]

这些工具的名称、描述、参数和结果都会影响模型决定下一步做什么。

因此 LangChain 将工具可用性和工具上下文视为更广泛的上下文工程问题的一部分。

5. 长期记忆

一些信息应该超越单次对话而存活。

AI 助手可能记住：

Preferred programming language: TypeScript
Project framework: Next.js
Database: PostgreSQL
Deployment: AWS

应用可以将有用的信息外部存储，在相关时候再检索回来，而不是把之前每次对话都保留在上下文窗口中。

6. 工具输出精简

工具输出可能变得非常大。

想象一个 agent 运行：

npm test

收到了 15,000 行输出。

下一次模型调用真的需要全部 15,000 行吗？

一个更好的系统可能提取：

Tests failed: 3

Failures:
- auth.test.ts: token expiration mismatch
- cart.test.ts: incorrect subtotal
- checkout.test.ts: missing address validation

这就是上下文工程。

模型收到的是信号，而不是噪音。

四种有用的上下文工程策略

LangChain 提出的一个有用心智模型将常见的上下文工程技术分为四类：写入（Write）、选择（Select）、压缩（Compress）、隔离（Isolate）。

写入（Write）

将信息存储在直接上下文之外，以便稍后使用。

选择（Select）

只检索与当前任务相关的信息。

documents = search(
    query=user_question,
    limit=5
)

而不是加载 5,000 份文档。

压缩（Compress）

在保留关键信息的同时，减少大量信息。

120-message conversation
        ↓
Structured summary
        ↓
Current context

Anthropic 和 OpenAI 都描述了用于长期运行 agent 的压缩技术——将累积的历史减少为保留重要状态的小型表示。

隔离（Isolate）

将不相关的工作保持在独立的上下文中。

不要让一个 agent 携带所有东西，专用的 agent 可以处理不同的任务：

Main Agent
   │
   ├── Research Agent
   ├── Coding Agent
   └── Testing Agent

每个 agent 获得其特定工作所需的上下文，然后向协调者返回一个简明的结果。

Anthropic 在复杂 agent 工作流的讨论中提到了这种方法，作为防止详细子任务信息消耗主 agent 上下文的一种方式。

Prompt Engineering vs. Context Engineering

理解这一转变的最简单方法是将它们直接对比。

所以，说上下文工程正在取代 prompt 工程需要一点 nuance。

Prompt engineering 不会消失。

它在系统其余部分面前角色正在变小。

Anthropic 明确将上下文工程描述为 prompt engineering 的自然演进，而不是完全替代。

更大的转变：从 Prompt 到系统

这可能是最重要的收获。

构建可靠的 AI 应用越来越看起来不像发现神奇的 prompt 短语，而更像传统软件工程。

开发者需要考虑：

Data
↓
Retrieval
↓
State
↓
Memory
↓
Permissions
↓
Tools
↓
Context
↓
Model
↓
Validation

LLM 位于一个系统内部。

它的输出严重依赖于系统向它呈现的内容。

考虑两个相同的模型。

Help the user debug their application.

Relevant source files
Current stack trace
Dependency versions
Project architecture
Recent code changes
Available terminal tools
Team coding standards
User's actual question

即使两个模型同样智能，系统 B 拥有巨大的实际优势。

不是因为它的 prompt 包含了更好的形容词。

是因为它的信息环境工程化得更好。

这意味着开发者可以停止学习 Prompt Engineering 吗？

一个写得差的指令仍然可能产生差的结果。

开发者仍然需要理解：

……

但这些技能现在属于一个更大的学科。

演进过程大致是这样的：

Prompt Engineering
        ↓
Prompt + Retrieval
        ↓
Prompt + Retrieval + Memory
        ↓
Prompt + Tools + State + Memory
        ↓
Context Engineering

随着 AI 应用从单轮生成器转向能够在多个工具和更长时间运行任务中工作的 agent，管理那个上下文变得越来越成为系统可靠性的核心。

开发者的一条好规则

当你的 AI 系统产生了一个糟糕的回答时，不要立刻去改 prompt。

先问：

模型是否收到了
做出正确决策所需的信息？

相关信息是否缺失？

不相关信息是否被包含了？

重要信息是否淹没在太多文本中？

两个上下文片段是否相互矛盾？

模型是否有正确的工具可用？

之前的状态是否正确保留了？

某些信息是否应该只在需要时才检索？

有时解决方案仍然是更好的 prompt。

但越来越多的时候，解决方案是更好的上下文架构。

---

Prompt engineering 教会了开发者如何与语言模型沟通。

Context engineering 要求我们更深入一层——设计这些模型运作的环境。

对于简单的 LLM 应用，一个精心设计的 prompt 可能仍然是你需要的大部分。

但对于现代 AI agent，模型可能依赖检索到的文档、工具、记忆、应用状态、对话历史、中间结果和运行时信息。

需要有人决定什么被包含。

需要有人决定什么被移除。

需要有人决定模型在每一步应该知道什么。

这就是上下文工程。

随着 AI 开发从：

Prompt → Response

转向：

Context → Model → Tool → State → Context → Model → Action

理解如何工程化那个上下文的开发者，将拥有一个构建可靠 AI 系统的好得多的心智模型。

AI 开发的未来不在于找到完美的 prompt。

而在于在正确的时刻、以正确的形式、向模型提供正确的信息。