上下文工程：为什么你喂给 LLM 的内容比你提问的方式更重要

大多数 LLM 质量问题并非提示词（Prompt）问题。它们是上下文（Context）问题。

你花了数小时打磨完美的系统提示词。你添加了 XML 标签、思维链指令和精细的人设定义。你在一些输入上进行了测试，效果看起来很棒。然后你上线了产品。两周后，你盯着一个工单发呆：智能体一本正经地告诉用户错误的账户余额 —— 因为它检索到了前一个用户的交易记录。模型完美理解了指令，它只是拿到了错误的输入。

这就是提示词工程（Prompt Engineering）与上下文工程（Context Engineering）之间的核心区别。提示词工程问的是：“我该如何措辞？”上下文工程问的是：“模型现在需要知道什么，以及我如何确保它准确获得这些信息？”前者是文案写作，后者是系统架构。

Andrej Karpathy 说得很好：上下文工程是“将正确的信息填充进上下文窗口，为下一步操作做准备的微妙艺术与科学”。这种说法暗示了一个大多数团队通过惨痛教训才发现的事实 —— 如果你不断优化提示词但结果依然不稳定，模型很可能从一开始就没拿到正确的上下文。

上下文出错的四种方式

在寻找解决方案之前，准确命名这些故障模式会有所帮助。大多数生产环境中的 LLM 事故可以分为四类：

上下文污染（Context poisoning）：错误或幻觉信息进入上下文并被重复使用。智能体在草稿垫（scratchpad）中写下一个事实错误，随后在后面的步骤中检索到该笔记并将其视为事实真相。错误不断累积。当人类看到它时，智能体已经在一个谎言之上构建了数个推理步骤。

上下文干扰（Context distraction）：上下文中包含过多的历史记录或检索文档。模型的注意力在无关内容中被稀释。它开始模仿旧的模式，而不是针对当前状态进行全新推理。这在缺乏压缩策略的长对话或多步智能体任务中很常见。

上下文混淆（Context confusion）：上下文中包含过多的工具、过多的检索片段，或内容相似的重叠文档。模型无法确定该信任哪个来源或使用哪个工具。它会有些随意地选择一个。你会发现相同输入的多次运行结果差异巨大。

上下文冲突（Context clash）：同一上下文中的两个来源表述矛盾。智能体检索到了一份 2023 年关于某项产品功能的文档（该功能在 2024 年已被废弃），同时还有一份未提及旧行为的最新文档。模型试图调和它们，通常会导致错误的结果。

了解你遇到了哪种故障模式，就能立即知道该修复什么。污染需要写入记忆前的验证。干扰需要压缩或修剪。混淆需要缩小范围 —— 更少的工具、更精准的检索。冲突需要按时间过滤和来源优先级排序。

四个原语：写入、选择、压缩、隔离

对于上下文管理，有一个清晰的框架可以映射到大多数实际生产模式。每一个上下文工程决策都是以下四种操作之一：

写入（Write） —— 将信息持久化在上下文窗口之外，以便稍后检索。这包括智能体在执行任务时编写的草稿垫、跨会话持久化的长期记忆库，以及结构化知识库。核心限制是：并非所有内容都值得写入。存储前需进行过滤。有选择地写入，并在适当时明确有效期。

选择（Select） —— 在需要时将相关信息拉回上下文窗口。这就是检索：基于嵌入的语义搜索、BM25 关键词匹配、知识图谱遍历或组合方式。目标不是检索所有可能相关的内容，而是精确检索当前步骤所需的内容，仅此而已。研究一致表明，对于大多数任务，专注的 300 Token 上下文表现优于分散的 100k Token 上下文。

压缩（Compress） —— 减少上下文中已有的内容，保留核心信号。总结工具输出，丢弃旧的对话轮次。在将智能体的推理轨迹传递给下一步之前，对其进行蒸馏处理。Claude Code 在上下文窗口使用率达到 95% 时会执行自动精简 —— 这是一个有用的工程参考点，可以作为你自己在系统中触发压缩的依据。实现良好的压缩可以在保留任务相关信息的同时，减少高达 80% 的 Token 使用量。

隔离（Isolate） —— 将上下文拆分到不同的智能体或进程中。在多智能体系统中，每个子智能体处理一个专注的子任务，并拥有干净的上下文窗口。子智能体返回的是精简后的摘要（通常为 1,000–2,000 Token），而不是完整的运行上下文。这可以防止一个任务的上下文污染另一个任务。这种权衡是真实存在的 —— 多智能体架构消耗的 Token 可能是单智能体方案的 15 倍 —— 因此，隔离应该是你最后才动用的工具，而非首选。

为什么长上下文窗口无法取代检索

随着模型宣传 1M+ token 的上下文窗口，一些团队认为 RAG 已经过时了。他们的想法是：如果你可以直接将整个知识库放入上下文，为什么还要费力构建检索基础设施？

基准测试结果并不支持这种观点。在结构化对比中，RAG 相比直接的长上下文提示词（prompting）拥有 82% 的胜率。有两个现象可以解释原因。

首先是有效上下文窗口问题。随着输入规模的增长，宣传的上下文限制与模型实际关注的上下文之间存在显著差异。关于最小有效上下文窗口 (MECW) 的研究发现，由于 KV 缓存限制和大规模下的注意力退化，在处理复杂任务时，性能可能会退化到仅为宣传限制的 1%。即使是 Gemini 最好的模型，在 1M token 的满载负荷下也仅能维持 77% 的准确率。

其次是**“迷失在中间” (lost-in-the-middle) 问题**。LLM 具有 U 型注意力曲线：它们最关注上下文开头和结尾的内容，而对于位于中间的信息，性能会下降 30% 以上。这并不是一个可以被修复的 bug，而是位置嵌入 (positional embeddings) 工作方式的结构性特征。这意味着，将大量检索到的内容堆在提示词中间，效果肯定不如检索更少、质量更高的文档。

长上下文在需要全局文档理解或预先不知道相关边界的任务中确实胜出。但对于大多数智能体 (agent) 任务——即寻找特定事实、最新数据或用户特定信息——定向检索在质量、成本和延迟方面仍然更具优势。

分块 (Chunking) 的杠杆作用远超大多数团队的想象

如果你在做 RAG，你的分块策略对检索质量的影响超过了几乎所有其他参数。核心权衡点在于：较小的块提供更好的检索精度，但会剥离周围的上下文；较大的块保留了上下文，但会产生更多噪声嵌入，并消耗更多上下文预算。

来自 2025-2026 年基准测试的一些具体数据：

• 在一项包含 50 篇学术论文的基准测试中，使用 512 token 的递归分块 (Recursive chunking) 实现了 69% 的准确率，成为测试中最准确的策略——而且它的计算成本很低，因为它在分块时不需要嵌入。
• 语义分块 (Semantic chunking) 尽管听起来很有吸引力，但在同一基准测试中准确率仅为 54%，产生的片段平均为 43 token——太小而无法发挥作用。其计算成本也很高：对一个 10,000 字的文档进行语义分块，仅在分割步骤就需要生成 200–300 个嵌入。
• 在一项临床决策支持研究中，与逻辑主题边界对齐的自适应分块 (Adaptive chunking) 达到了 87% 的准确率，而固定大小的基线仅为 13%。但自适应分块需要特定领域的分割逻辑，因此增益伴随着实现成本。

实用的经验法则：从递归 512 token 分块开始。这是大多数用例的正确默认选择。添加重叠（通常为块大小的 10-20%）以避免将推理过程从中间切断。只有当你拥有明确证据表明文档结构至关重要（如技术文档、法律文件、临床记录）时，再转向自适应或语义方法。

一个经常被忽视的选择：对于像常见问题解答 (FAQ) 或产品描述这类短小、用途单一的文档，通常完全不分块是最好的。对小文档进行检索的开销并不值得增加其复杂性。

内存架构：哪些需要持久化，哪些不需要

在不同会话中表现良好的智能体将内存视为一种有意识管理的资源，而不是一个只增不减的日志。存在三种截然不同的内存类型，每种类型具有不同的持久化和检索特征：

情节记忆 (Episodic memory) 记录过去的交互和用户偏好。对于个性化、避免重复和维持对话连贯性很有用。它的衰减最快——三个月前的用户偏好可能会对今天的质量产生负面影响。

语义记忆 (Semantic memory) 存储领域知识、关于世界的事实和结构化信息。适合长期持久化，但需要版本控制：关于产品定价的语义记忆条目如果未更新，就会变成一种负担。

程序记忆 (Procedural memory) 编码如何执行工作流——本质上是学到的智能体行为。这是最危险的存储类型，因为程序记忆中的错误会被反复执行，直到有人发现。

最重要的工程决策：

写入前过滤。如果一个智能体回合的内容只是“好的，知道了”，则不需要内存条目。选择性写入可以防止内存污染——低信号条目的逐渐积累会降低检索质量，并在上下文中填充噪声。

定期清理。大多数团队只构建了内存写入路径，却从未构建内存过期机制。结果就是智能体会对用户、产品和系统产生过时的认知，并持续数月。应根据新鲜度和明确的有效期安排垃圾回收。

跨会话压缩。当长任务期间上下文窗口填满时，总结完整对话并以压缩表示形式重新开始。正确的压缩策略应首先最大化召回率（保留所有可能重要的内容），然后迭代以提高精确率（丢弃肯定不重要的内容）。

系统提示词即架构

系统提示词（System prompts）不仅仅是指令——它们是上下文中固定、始终存在的部分。系统提示词中的每个 token 都会占用检索文档、工具输出和对话历史的配额。这创造了一个大多数团队在优化 token 成本之前都会忽略的设计约束。

常见的失效模式处于两个极端：过于规定性（硬编码逻辑导致脆弱性和维护债务）或过于模糊（只有高层指导而没有具体信号）。合适的高度应该是足够具体以引导已知边缘情况下的行为，又足够灵活以泛化到系统未曾见过的输入。

实践指南：使用 XML 标签或 Markdown 标题将提示词组织成带标签的区块，以便你和模型都能导航。从最简开始。根据生产环境观察到的失效模式添加指令，而不是基于假设的推测。使用 Few-shot 示例而不是详尽的边缘情况描述——对于大语言模型（LLM）来说，示例确实胜过千言万语。

工具方面也是如此。功能重叠且臃肿的工具集会造成上下文混乱。如果人类工程师在特定情况下都无法在两个工具之间做出明确选择，那么智能体（Agent）也无法做到。当工具数量增加时，对工具描述本身应用 RAG——针对给定子任务检索最相关的三个工具，而不是暴露全部 40 个。

将上下文监控视为基础设施

大多数可观测性设置监控的是输出：响应质量、延迟、错误率。很少有人监控上下文的构成。这是一个空白——因为大多数质量故障源于进入上下文的内容，而不是模型处理它的方式。

最简上下文监控技术栈：

跟踪每个组件的 token 消耗。了解系统提示词、对话历史、检索文档和工具输出分别占用了多少上下文配额。当质量下降时，第一个问题应该是上下文配额是否发生了偏移——例如，过多的历史记录挤占了检索文档的空间。

针对检索质量而非仅仅检索延迟进行告警。一个在 50ms 内返回但拉取了错误文档的检索调用，比一个耗时 200ms 但返回正确文档的调用更糟糕。在检索流水线中加入相关性评分，并监控分布变化。

对采样请求记录完整上下文。不必记录每个请求——存储成本很高——但要足以诊断生产故障。当智能体做出意料之外的行为时，调试的第一步就是阅读它到底看到了什么。

复杂性的渐进梯度

上下文工程不是“简单 RAG”和“完整多智能体架构”之间的二选一。它有一个演进过程：

从可能奏效的最简单方法开始：一个最简系统提示词、一个优秀的模型和单次检索步骤。许多问题在这里就能解决。在了解实际失效模式之前，抵制构建基础设施的冲动。

一旦你有证据表明纯基于嵌入（embedding）的检索在特定关键词查询上失败，就增加混合检索（语义 + BM25）。混合检索的效果始终优于单一方法。

一旦上下文窗口的使用成为约束，就增加压缩（compaction）。主动监控这一点——在任务中途耗尽上下文窗口是一个硬性故障。

只有当单智能体的上下文管理变得真正难以处理时，才增加多智能体隔离。Token 成本是实打实的，协调开销也会增加延迟和复杂性。

值得注意的模型改进趋势：更好的模型更擅长处理给定的上下文，这意味着更少需要人工精选输入内容。针对 2023 时代的模型过度设计上下文管理，在升级时可能会变成一种负担。为今天的需求构建，但不要让上下文管理逻辑死板到与更出色的模型产生冲突。

正如一个工程团队所言：“用尽可能小的高信号 token 集，来最大化获得预期结果的可能性。”这听起来比实际做起来更难，但它是正确的目标。