上下文工程
上下文工程（Context Engineering）是一种刻意设计 LLM 在生成响应时看到什么信息、以什么顺序、以什么格式呈现 的实践。它涵盖了 提示工程（打磨单条提示），并延伸到进入 上下文窗口 的一切内容：系统提示、检索到的文档、对话历史、用户元数据、工具 schema 等等。Simon Willison、Tobi Lütke 和 Andrej Karpathy 在 2025 年开始公开使用这一术语，到 2026 年它已成为 LLM 产品工程中的标准词汇。
上下文工程（Context Engineering）是一种刻意设计 LLM 在生成响应时看到什么信息、以什么顺序、以什么格式呈现 的实践。它涵盖了 提示工程（打磨单条提示），并延伸到进入 上下文窗口 的一切内容：系统提示、检索到的文档、对话历史、用户元数据、工具 schema 等等。Simon Willison、Tobi Lütke 和 Andrej Karpathy 在 2025 年开始公开使用这一术语，到 2026 年它已成为 LLM 产品工程中的标准词汇。
为什么重要
生产环境中大多数 LLM 产品的失败，源于"我们给了模型错误的上下文"，而不是"模型不行"。即便有 100 万 token 的上下文窗口，把信息随意堆进去也会损害性能，这就是有充分记录的"迷失在中间"效应。上下文工程把复合输入（RAG、记忆、工具、历史）当作一个设计变量来对待，同一个模型在更好的上下文构建下，表现可以好上 2 至 10 倍。
上下文由什么构成
系统提示：固定指令，包括角色、约束、语气、目标。
用户提示：用户在本轮的输入。
对话历史：之前的轮次。
RAG 结果：来自向量数据库的相关文档和片段。
工具定义：可调用函数的名称、描述和 schema。
工具调用结果：先前工具调用返回的数据。
用户元数据：语言、时区、订阅套餐、行为历史。
章程 / 护栏：安全规则、禁止主题、输出过滤器。
所有这些都会合并进一个单一的上下文窗口，再交给 LLM。
上下文工程与提示工程
| 方面 | 提示工程 | 上下文工程 |
|---|---|---|
| 单位 | 一条提示语句 | 整个上下文窗口 |
| 关注点 | "我该怎么问？" | "我该展示什么？" |
| 层级 | 战术性（句子层面） | 系统性（流水线层面） |
| 示例 | 加上"一步一步思考" | 决定 RAG 片段数量、顺序、摘要方式 |
提示工程是写好句子的手艺；上下文工程则是设计这些句子所处的整个输入结构的手艺。
核心原则
只放需要的内容：上下文越长，"迷失在中间"越严重，成本也越高。要无情地砍掉无关信息。
刻意安排顺序：LLM 对开头和结尾的权重更高。把最重要的指令和数据放在两端。
结构化标记：把外部文档包进 <source>…</source>，把示例包进 <example>…</example>，让模型知道每一部分扮演什么角色。
动态选择：不同类型的请求理应配以不同的工具列表、RAG 结果和系统提示。一刀切只会浪费 token。
摘要与压缩：把长历史做成摘要以节省 token。Claude artifacts 这类功能就是一个典型例子。
管理智能体循环：对于多步推理，要在各步之间清理并重建上下文。
实际挑战
Token 预算：上下文窗口并非免费。把 100 万 token 填满会让成本和延迟爆炸。
相关性排序：决定拉取多少个 RAG 片段以及重排多少。
记忆策略：长期记忆放在向量数据库，短期记忆通过摘要实现。
调试：当输出质量下降时，要找出是上下文的哪一部分出了问题。日志记录和可复现性必不可少。
对 GEO 的影响
AI 搜索 引擎本身就是上下文工程的流水线。被构建得"很好地契合上下文"的内容会被引用得更多。具体而言：① 每个小节都应能被独立地概括，② 第一句应承载核心答案，③ 元数据和来源应当明确。这就是面向博主的"对上下文工程友好的写作"。
Sources: