06. 什么是 Context Engineering？它和 Prompt Engineering 有什么区别？

简单回答

Context Engineering（上下文工程）是为 LLM 构建和管理完整上下文信息的系统性工程，包括动态检索相关知识、管理对话历史、组装工具定义、注入系统指令等。Prompt Engineering 关注的是"怎么写好一条 Prompt"，Context Engineering 关注的是"怎么把正确的信息在正确的时机送进上下文"。Prompt Engineering 是 Context Engineering 的一个子集——写好 Prompt 只是上下文工程的一部分，还需要考虑信息的获取、筛选、组装和管理。

详细解释

为什么这个概念变得重要

早期的 LLM 应用很简单——写一个 system prompt 加上用户消息就够了。但随着 Agent、RAG、Tool Calling 等技术的成熟，送进模型的上下文变得越来越复杂——可能同时包含系统指令、用户历史、检索到的文档、工具定义、之前的工具调用结果、用户的偏好配置、当前的任务状态等。这些信息怎么获取、怎么筛选、怎么排列、怎么在有限的 context window 内管理，变成了一个系统性的工程问题——这就是 Context Engineering。

Andrej Karpathy 提出过一个说法："与其叫 Prompt Engineering，不如叫 Context Engineering"，因为真正决定模型表现的不是那几行 Prompt 模板，而是送进去的整个上下文的质量。

Context Engineering 包含什么

系统指令（System Prompt）是上下文的基础层，定义了模型的角色、行为规范、输出格式等。这是 Prompt Engineering 的传统领域。

对话历史管理是上下文工程的一个重要组成部分。多轮对话中，历史消息需要被保留、摘要或裁剪。前面 Agent Memory 部分讨论的短期记忆管理就是这个范畴。

动态知识注入是 RAG 的范畴——根据当前 query 检索相关文档并注入上下文。

工具定义管理在 Agent 场景下尤为重要。如果系统有几十个可用工具，不可能每次都全部带上（token 消耗太大），需要根据当前任务动态选择相关工具的子集注入上下文。

任务状态信息在 Agent 多步任务中，需要把当前进度、中间结果、待执行步骤等结构化状态注入上下文，让模型知道"现在到哪了"。

用户画像和偏好从长期记忆中检索用户的相关信息，注入上下文以实现个性化。

多源信息的优先级排序当上下文空间有限时，需要决定哪些信息优先放入。系统指令 > 当前任务状态 > 最相关的检索结果 > 对话历史 > 用户偏好——这个排序需要根据场景调整。

和 Prompt Engineering 的区别

Prompt Engineering 主要关注的是"怎么措辞才能让模型给出更好的回答"——包括指令设计、few-shot 示例、CoT 引导等。这些技巧作用在一个静态的文本层面。

Context Engineering 关注的是一个更大的系统性问题——"在一个动态的系统中，怎么保证模型在任何时刻收到的上下文都是最优的"。它涉及信息的获取（从哪里拿）、筛选（拿什么）、排序（怎么排）、裁剪（什么时候砍）、以及生命周期管理（信息什么时候过期、什么时候更新）。

打个比方：Prompt Engineering 是"写好一封邮件"，Context Engineering 是"设计一套邮件管理系统——自动收集信息、筛选重要内容、按优先级排列、控制邮件长度、定期归档"。

工程实践

在实际项目中，Context Engineering 体现为一套上下文构建的管道（pipeline）。每次 LLM 调用前，系统会：从 RAG 检索相关文档、从记忆系统检索用户信息、从任务状态中提取当前进度、根据当前场景筛选需要的工具定义、计算当前上下文的 token 数并做裁剪和摘要、按照优先级组装最终的 Prompt——然后才发送给 LLM。

这套管道的质量直接决定了模型的表现。同一个模型，给好的上下文和给差的上下文，输出质量可以天差地别。很多时候看起来是"模型不够聪明"，实际上是上下文没给对。

面试时可以这样答

Context Engineering 是一个比 Prompt Engineering 更广的概念。Prompt Engineering 关注"怎么写好一条 Prompt"，Context Engineering 关注"怎么在一个动态系统中，保证模型每次收到的上下文都是最优的"。

实际的 Agent 或 RAG 系统中，送进模型的上下文不只是一行 Prompt，而是系统指令、对话历史、检索文档、工具定义、任务状态、用户偏好等多种信息的组合。这些信息从哪里获取、怎么筛选、怎么排序、在有限的 context window 内怎么管理——这些都是 Context Engineering 的范畴。

工程上体现为一套上下文构建管道，每次 LLM 调用前自动组装上下文。同一个模型，上下文质量不同，输出天差地别。很多看起来是"模型不行"的问题，实际上是上下文没给对。Andrej Karpathy 说得好——真正重要的不是那几行 Prompt 模板，而是整个上下文的质量。

常见追问

1. 你在实际项目中是怎么组装上下文的？优先级怎么排？
2. 当上下文超出 token 限制时，你的裁剪策略是什么？
3. Context Engineering 和 RAG 的关系是什么？