上下文工程：比提示词工程更重要的学科

大多数构建 LLM 系统的人最初几周都会沉迷于优化提示词。他们进行 A/B 测试，争论该使用 XML 标签还是 JSON，并不断迭代系统提示词，直到模型输出看起来正确的内容。然而，一旦进入生产环境，加入真实数据、记忆和工具调用——模型就会开始出现各种提示词调优无法解决的异常行为。问题从来都不在提示词上。

生产级 LLM 系统的真实瓶颈在于上下文——即模型输入中包含什么信息、以何种顺序排列、信息量有多少，以及这些信息是否与模型即将做出的决策相关。上下文工程是将该输入空间作为系统首要关注点进行设计和管理的学科。它包含了提示工程，就像软件架构包含了变量命名一样：较小的技能依然重要，但它并不能大规模地决定最终成果。

为什么提示词只是子集，而非策略

提示工程问的是：“我该如何描述这个指令？”而上下文工程问的是：“为了做出正确的决策，模型现在需要知道什么？”

这种区别并非语义上的文字游戏。语言模型只能处理其上下文窗口中的 token。它无法访问外部状态，无法记住之前的交互，也无法凭直觉感知你忘了告诉它的事情。当模型失败时，第一个问题不应该是“我该如何改写指令？”，而应该是“模型是否拥有成功所需的必要信息？”

这种思维框架的转变将责任从提示词转移到了系统。可靠的 AI 源于架构，而非巧妙的措辞。如果你在得到不一致结果的同时反复调整提示词，那么几乎可以肯定，模型从一开始就没有获得充分的上下文。

思维模型的转变很简单：

• 提示工程：“我该说什么？”
• 上下文工程：“模型应该知道什么？”

两者都很重要，但它们作用于不同的杠杆点。设计良好的上下文能让平庸的提示词发挥作用；而设计糟糕的上下文即便配上最好的提示词也会变得不可靠。

上下文窗口的物理学

要理解为什么上下文工程很难，你需要理解 Transformer 架构产生的几种具体的失败模式。

上下文腐烂 (Context rot) 是指模型性能随着输入长度增加而下降的现象。2025 年的一项研究测试了包括 GPT-4.1、Claude 和 Gemini 在内的 18 个前沿模型，发现随着上下文的增长，所有模型的表现都会变差。这种退化不是线性的，而是加速的。模型主要在较短的序列上进行训练，针对长程上下文依赖的专用参数较少。

“迷失在中间”问题 (The lost-in-the-middle problem) 加剧了这一现象。LLM 对输入开头和末尾的 token 关注度最高。埋藏在长上下文中间的信息，其准确率与放在边界处的相同信息相比，可能会下降 30% 以上。在 100,000 个 token 的上下文中，你不能假设模型会均匀地处理所有内容——事实并非如此。

注意力稀释 (Attention dilution) 是架构层面的根本原因。Transformer 的注意力机制是平方级的：每个 token 都会关注其他所有 token，产生数十亿个成对关系。随着上下文的增长，注意力预算被分摊得越来越薄。添加无关内容不仅浪费 token，还会竞争模型有限的注意力能力。

干扰项干预 (Distractor interference) 是具体的表现形式。语义相似但无关的内容会误导模型，且这种误导难以检测。如果你的上下文中包含四个讨论数据库架构的文档，而其中只有一个与当前查询相关，模型可能会对全部四个文档进行综合，从而产生一个听起来合情合理、但引用文档错误的答案。

这些不是可以打补丁的 Bug。它们是架构的基本属性，上下文工程必须绕过这些障碍进行工作。

生产级上下文的剖析

生产级上下文不是一个附加了一些数据的提示词。它是一个动态组装的流水线，具有不同的层级，每一层都有不同的更新频率和相关性标准。

系统指令 (System instructions) 构成了基础。它们应该达到适当的高度——既要具体到足以引导行为，又要灵活到足以让模型独立推理。系统提示词中脆弱的 if-else 逻辑会导致 Agent 变得脆弱；模糊的系统提示词则会导致不可预测性。目标是建立一套简明的原则，在不规定每种情况的前提下约束行为。

检索到的知识 (Retrieved knowledge) 为模型提供了训练数据之外的事实依据。这就是检索增强生成 (RAG) 的用武之地。检索的质量——而非检索提示词的质量——决定了模型是否拥有所需的信息。对检索到的片段进行重新排序 (Reranking) 并将最相关的放在最顶部并非可选操作，而是直接缓解“迷失在中间”问题的必要手段。

持久化记忆 (Persistent memory) 将当前的推理与先前的状态连接起来。这包括用户偏好、之前的决策和任务历史。如果没有显式的记忆管理，Agent 要么重复错误，要么要求用户在每次交互时重新解释背景。

对话历史 (Conversation history) 是最危险的一层。它会无限制地增长，积累噪声，是生产系统中上下文腐烂的主要诱因。大多数团队没有刻意管理它——他们只是不断追加回合直到上下文溢出，然后从顶部截断。这两种做法都是错误的。

工具定义 (Tool definitions) 占据了原本可以承载其他内容的 token。你添加的每个工具都会减少其他内容的可用空间。工具 schema 应当保持极简、无重叠且无歧义。歧义的工具集会迫使模型浪费上下文去推理该调用哪个工具，而不是去推理实际的任务。

即时上下文 vs. 预加载

一个常见的错误是在 Agent 运行开始时预加载所有可能相关的信息。这种方法为了方便而牺牲了性能。

另一种方案——即时上下文检索（just-in-time context retrieval）——保持初始上下文精简，并根据 Agent 的需要动态加载信息。Agent 维护轻量级标识符（文件路径、数据库键、文档 ID），仅在需要时才获取完整内容。这模仿了人类的工作方式：我们不会记住所有可能相关的事情；我们记住的是去哪里寻找。

对于多步 Agent，这种模式至关重要。在第一步，Agent 需要任务描述和可用工具。到第五步时，它需要的是从第二步到第四步的中间结果，而不是完整的原始文档集。上下文应该追踪任务的当前状态，而不是你到达那里的完整历史。

管理历史：压缩与结构化笔记

在大多数 Agent 系统中，工程化程度最低的组件是对话历史管理。如果不加管理，它会成为上下文腐烂（context rot）的主要诱因。

压缩（Compaction） 是在达到上下文限制之前总结对话历史的做法。压缩过程将累积的轮次还原为保留关键决策、约束和输出的密集表示，同时丢弃工具调用细节、中间推理和冗余的确认。如果处理得当，压缩可以在完全超出上下文限制的会话中保持任务的连贯性。

良好压缩的关键在于知道保留什么。架构决策、用户偏好、确定的事实和阻塞性约束属于摘要内容。而前一轮的准确措辞、中间 API 响应和已被取代的假设则不属于。

结构化笔记（Structured note-taking） 是一种互补的方法，Agent 将持久笔记完全写在上下文窗口之外——写入文件、数据库或草稿纸——并在随后的轮次中选择性地加载它们。这就是 Claude Code 在长会话中的工作方式：模型将待办事项列表和笔记写入文件，在每轮开始时读取它们，从而避免用完整的会话历史填满其上下文。

子 Agent 架构与干净的上下文

在复杂的 Agent 系统中，解决上下文污染最干净的方案是架构层面的：给每个子 Agent 一个专注于特定任务的全新上下文窗口。

一个编排 Agent 分解任务，派遣具有狭窄作用域的子 Agent，并接收它们压缩后的输出（通常为 1,000–2,000 个 token）。子 Agent 在干净、整洁的上下文中完成繁重的工作。编排器从不累积原始的中间输出——它只处理摘要。

这种模式在软件工程中也有直接的类比。你不会用整个应用程序状态作为参数来调用一个函数；你只传递该函数确切需要的内容。多 Agent 系统的上下文工程是应用于 token 空间的同一种原则。

状态对象隔离（State object isolation）是一种相关的技术：Agent 的运行时状态被设计为结构化 Schema，不同的字段暴露给推理过程的不同部分。只有与当前步骤相关的字段才进入上下文窗口。其他字段保存在外部并按需加载。

这对你的构建意味着什么

实际的意义在于，上下文设计应该发生在编写提示词（prompt）之前，而不是之后。在你写下任何一条指令之前，请先问：

• 在该任务的每个步骤中，模型需要什么信息？
• 考虑到延迟和成本限制，我在每一步能负担的最大上下文长度是多少？
• 对话历史将如何累积，我将在何时进行压缩？
• 哪些工具是必不可少的，哪些可以剔除？
• 现在的检索返回什么，最相关的内容是否出现在模型真正关注的地方？

将上下文视为一个拥有自身架构、生命周期和约束的系统——而不是一个你不断追加内容的字符串。用你对待代码的严谨态度来对你的检索流水线进行版本控制。评估你的上下文管理策略如何影响长会话中的任务完成度，而不仅仅是在干净的单轮基准测试上进行评估。

开启生产级可靠性的见解很简单：模型的好坏取决于你展示给它的内容。提示词工程（Prompt engineering）为你提供指令。上下文工程（Context engineering）则为模型提供遵循指令所需的一切。

大多数系统的失败并不是因为提示词错误，而是因为模型被要求在缺乏成功所需信息的情况下进行推理。修复上下文，你通常会发现提示词一直以来都没问题。