Context Engineering 是什么——Prompt Engineering 已经过时了吗

适读人群：AI应用开发者、对大模型工程化感兴趣的工程师 | 阅读时长：约12分钟 | 核心价值：搞清楚Context Engineering和Prompt Engineering的本质区别，以及实际工程中该怎么做

上个月我在给一个电商团队做AI代码审查方案的时候，技术负责人突然问我："老张，你觉得我们现在还有必要学Prompt Engineering吗？听说Context Engineering才是2025年的方向。"

我当时没有立刻回答。因为我知道如果我说"Prompt Engineering过时了"，他们可能真的会把好不容易积累的Prompt优化经验全扔掉；如果我说"没过时，继续学"，那也不够诚实——这两个概念确实有本质的差异，值得认真说清楚。

所以今天这篇文章，我想把我两年多做AI应用开发的真实理解写出来。

---

先说一个让我改变认知的失败经历

2023年底，我刚开始做AI应用开发，那时候满脑子都是"Prompt优化"。我花了大量时间在一个客服机器人项目上调Prompt，用了角色扮演、思维链、few-shot示例，把一个Prompt从200字调到了800字，效果确实提升了不少。

当时我觉得自己掌握了门道。

但有一天，这个客服机器人突然开始给用户提供过时的退款政策——说的还是半年前的老规则。我去查原因，发现是业务方把政策文档更新了，但没有人去更新Prompt里嵌入的那段硬编码的政策说明。

这件事让我意识到一个根本问题：我在用Prompt Engineering的思维做一个需要Context Engineering思维的系统。

---

两个概念到底是什么

Prompt Engineering，核心关注的是：如何构造一段文字，让模型理解你的意图、按你期望的方式输出。它的操作对象是"那一段给模型看的文字"，优化目标是让指令表达得更清晰、更精准。

这件事本身是有价值的，但它的边界很清晰——你在优化的是人与模型之间的沟通方式。

Context Engineering，关注的是一个更大的问题：在模型推理的时候，它的上下文窗口里应该放什么、怎么放、放多少。它不只是关心那个System Prompt怎么写，而是关心整个信息架构：

• 哪些信息应该以什么形式进入上下文
• 信息之间的优先级和结构关系是什么
• 如何动态地根据用户意图检索和组装上下文
• 长对话中如何管理和压缩记忆
• 工具调用结果怎么格式化才能让模型最好地利用

你可以这样理解：Prompt Engineering是在优化一封信怎么写，Context Engineering是在设计一个完整的信息传递系统。

---

为什么2025年Context Engineering变得重要

有几个现实原因：

模型上下文窗口大幅扩展了。 Claude 3.5支持200K token，Gemini 1.5 Pro支持100万token。当你有这么大的窗口可以用，怎么填充它就变成了一个重要的工程问题——不是随便填就行，填得不对会让模型注意力分散，效果反而更差。

RAG（检索增强生成）成为标配了。 几乎所有稍微复杂一点的AI应用都需要RAG。RAG的核心就是Context Engineering：检索什么、怎么排序、怎么拼接到上下文里，这些决定了RAG系统80%的效果上限。

Multi-agent系统开始大量出现。 当你有多个Agent相互协作，每个Agent的上下文怎么设计、Agent之间怎么传递信息，这已经完全超出了传统Prompt Engineering的范畴。

模型能力天花板在提升。 以前很多任务是模型能力本身不够，Prompt怎么优化都有限。现在模型能力足够强，很多时候卡脖子的是上下文的质量。

---

工程实践上的具体差异

光说概念没用，我说几个具体的例子。

例子1：信息结构化

Prompt Engineering思维：

你是一个客服助手，我们公司的退款政策是：7天无理由退款，15天内质量问题可退，超过15天不退。用户问退款问题时，友好地告知相关政策。

Context Engineering思维：

# 把政策从Prompt里抽出来，做成结构化数据
POLICY_STORE = {
    "refund": {
        "no_reason": {"days": 7, "condition": "未拆封"},
        "quality_issue": {"days": 15, "condition": "提供凭证"},
        "special_cases": ["定制商品不适用", "数字内容不适用"]
    }
}

# 运行时动态检索相关政策
def build_context(user_query: str) -> str:
    relevant_policies = retrieve_relevant_policies(user_query, POLICY_STORE)
    return format_policies_for_context(relevant_policies)

差别在于：前者政策硬编码在Prompt里，改起来要改所有相关Prompt；后者政策和逻辑分离，业务变更只需要更新数据。

例子2：上下文窗口管理

一个技术客服场景，用户和AI已经聊了50轮。

Prompt Engineering思维： 把所有对话历史都塞进去。

Context Engineering思维：

def build_conversation_context(history: list, current_query: str) -> list:
    # 策略1：保留最近N轮完整对话
    recent_turns = history[-8:]
    
    # 策略2：对早期对话做摘要压缩
    if len(history) > 8:
        early_summary = summarize_early_conversation(history[:-8])
        compressed_context = [{"role": "system", "content": f"早期对话摘要：{early_summary}"}]
        return compressed_context + recent_turns
    
    return recent_turns

def summarize_early_conversation(early_history: list) -> str:
    # 调用一个小模型或专用Prompt来压缩早期对话
    summary_prompt = "请提取以下对话中的关键信息点（用户问题、已解决的内容、待处理事项）："
    # ... 调用API
    return summary

这是在主动管理上下文窗口，而不是被动地往里堆信息。

例子3：RAG的上下文组装

这是Context Engineering最典型的场景。

from anthropic import Anthropic

client = Anthropic()

def build_rag_context(
    user_query: str,
    retrieved_chunks: list[dict],
    conversation_history: list[dict]
) -> list[dict]:
    """
    构建RAG场景下的完整上下文
    retrieved_chunks: [{"content": str, "source": str, "score": float}]
    """
    # 按相关性分层
    high_relevance = [c for c in retrieved_chunks if c["score"] > 0.85]
    medium_relevance = [c for c in retrieved_chunks if 0.7 <= c["score"] <= 0.85]
    
    # 构建知识上下文块
    knowledge_block = "【参考资料】\n"
    
    # 高相关内容完整引用
    for chunk in high_relevance[:3]:
        knowledge_block += f"来源：{chunk['source']}\n{chunk['content']}\n\n"
    
    # 中等相关内容简略引用
    if medium_relevance:
        knowledge_block += "【补充参考】\n"
        for chunk in medium_relevance[:2]:
            knowledge_block += f"- {chunk['source']}：{chunk['content'][:200]}...\n"
    
    # 组装最终消息列表
    messages = []
    
    # 注入知识上下文（放在对话历史之前）
    messages.append({
        "role": "user",
        "content": knowledge_block
    })
    messages.append({
        "role": "assistant", 
        "content": "我已经了解了相关背景资料，请问您有什么问题？"
    })
    
    # 加入对话历史
    messages.extend(conversation_history[-6:])  # 最近6轮
    
    # 加入当前问题
    messages.append({
        "role": "user",
        "content": user_query
    })
    
    return messages

def answer_with_rag(user_query: str, vector_db_results: list, history: list) -> str:
    messages = build_rag_context(user_query, vector_db_results, history)
    
    response = client.messages.create(
        model="claude-opus-4-5",
        max_tokens=1500,
        system="你是一个专业助手，基于提供的参考资料回答问题。如果资料中没有相关信息，明确说明不知道。",
        messages=messages
    )
    
    return response.content[0].text

注意这里的设计决策：

• 高相关和中等相关内容采用不同的引用深度
• 知识块放在对话历史之前（让模型先看到背景再看问题）
• 对话历史取最近6轮而不是全部
• System Prompt里明确说明"资料中没有就说不知道"（防止模型瞎编）

每一个决策都影响效果，这就是Context Engineering。

---

我的判断：不是替代，是升维

说回那个技术负责人的问题。

我的答案是：Prompt Engineering是Context Engineering的子集，不是替代关系。

你仍然需要写好System Prompt，仍然需要知道few-shot怎么用、思维链怎么触发——这些Prompt Engineering的技能依然有价值。但如果你只会写好一段Prompt，在真实的AI应用开发中会遇到很多用Prompt写得再好也解决不了的问题。

打个比方：Prompt Engineering是厨师学会了调味，Context Engineering是厨师还要学会怎么选食材、怎么控制火候、怎么安排出菜顺序。调味技能不会白学，但光会调味开不好一家餐厅。

---

实际工作中如何建立Context Engineering的思维

我自己总结了几个实操方向：

1. 信息与逻辑分离

把硬编码在Prompt里的业务信息（政策、规则、知识点）抽出来，做成结构化的数据源，运行时动态检索注入。这件事带来的不只是可维护性，还会逼着你去思考"什么信息对这个Query最相关"。

2. 设计上下文的层次结构

不是所有信息都一样重要。一般我会把上下文分成这几层：

System Prompt（角色定义、行为规范）
  └── 知识上下文（检索到的相关信息）
       └── 记忆上下文（历史对话摘要）
            └── 当前会话（最近N轮完整对话）
                 └── 当前请求（用户当前输入）

每层的位置、篇幅、格式都要有意识地去设计。

3. 测量和监控

Prompt Engineering时代，很多人凭感觉调优。Context Engineering需要更系统地去测量：

• 上下文窗口利用率（填了多少、有效的比例是多少）
• 检索准确率（检索到的内容和Query的相关性）
• 模型对上下文的利用率（输出里有多少来自你注入的上下文）

4. 把Context Assembly当作一个独立模块

在系统架构里，把"组装上下文"这件事当作一个独立的服务或模块来设计，而不是散落在各个业务逻辑里。这个模块要能测试、要能迭代、要能监控。

---

最后说一句实话

2025年"Context Engineering"这个词确实有一定的炒作成分，但它背后指向的工程问题是真实存在的。那些做出来真正好用的AI应用的团队，绝大多数都在认真处理上下文管理这个问题——只是以前没有一个好的词来描述这件事。

现在有了这个词，对从业者来说是好事：它让大家可以更清晰地讨论这类问题，知识和方法论也会沉淀得更快。

所以我的建议是：不要纠结这两个词谁更重要，去看你现在的AI系统里上下文管理做得怎么样。大概率，那里有一堆值得优化的东西。