上下文工程现状：从提示词到上下文管理的范式演进

当“提示词工程”逐渐被视作基础技能，一个更宏观的概念正在社区中成形：上下文工程。它不关心单次提问的措辞技巧，而是把模型可见的全部信息——系统提示、检索片段、工具输出、历史对话、用户画像——当作一个需要主动设计、动态治理的资源系统。

本文基于技术写作者 dbreunig 的文章《The State of Context Engineering》以及在 Hacker News 上引发的讨论，尝试梳理这一概念的现状、边界与仍待解决的问题。

从提示词工程到上下文工程，究竟变了什么

提示词工程的核心假设是：模型能力固定，优化输入的表达方式即可获得更好输出。上下文工程则把视角拉远——模型在每次调用时能“看到”的空间是有限的，如何填满这个空间，比某句话怎么措辞更能决定结果。

这一转向背后有现实动因。随着 Agent 形态普及，模型不再只回答单轮问题，而是在多步骤任务中持续接收工具返回结果、检索文档和中间状态。上下文从一次性输入变成了持续流动的状态，谁负责筛选、压缩、丢弃，成为工程问题。

原文所讨论的“状态”，可以理解为对这个新兴领域的阶段性盘点：实践已经跑在概念前面，但方法论尚未收敛。

上下文窗口指模型单次推理时能够处理的最大 token 数量（输入与输出之和）。主流大模型的上下文窗口已从早期的 4K、8K 扩展到 128K 乃至百万级，但窗口扩大并不等于有效利用能力同步提升。研究普遍观察到“中间信息丢失”现象：位于长上下文中段的内容被模型引用或推理的概率显著低于开头和结尾部分，这被称为位置偏置。此外，注意力机制的计算开销随序列长度呈平方级增长，长上下文直接推高推理延迟与成本。因此上下文工程的核心矛盾并非窗口容量不足，而是如何在有限的高效区间内放置最关键的信息。

上下文工程真正要解决的问题

HN 讨论区（45 条评论、196 点）中，不少讨论集中在几个具体矛盾上：

上下文窗口不是越大越好。 更长的窗口意味着更多噪声和更高的推理成本，模型对长上下文中段信息的利用效率也常被质疑。工程上的取舍因此从“能不能塞进去”变成“值不值得塞进去”。

检索质量决定上限。 无论是 RAG 还是工具调用结果，注入上下文的片段如果相关性不足，反而会干扰模型判断。上下文工程把检索、重排、截断视为同一个设计链条上的环节。

状态管理需要显式设计。 多轮 Agent 任务中，哪些历史需要保留、哪些需要摘要、哪些应当丢弃，目前多依赖经验规则，缺乏统一抽象。

评估难以标准化。 单轮提示词可以靠对比输出打分，而上下文策略的效果往往要在完整任务链路中才能体现，评估成本显著更高。

这些讨论共同指向一点：上下文工程不是提示词工程换个名字，而是把问题从“怎么写”扩展到“给什么、给多少、什么时候给”。

RAG（检索增强生成） 是一种在模型生成前从外部知识库检索相关片段并注入上下文的架构，通常包含文档切分、向量化索引、相似度检索、重排四个环节。检索质量由召回率（相关片段是否被检索到）和精确率（检索到的片段是否真正相关）共同决定。在上下文工程视角下，RAG 的每个环节都直接影响最终注入上下文的内容质量：切分粒度过粗会引入无关噪声，重排缺失会让低相关片段挤占预算，截断策略不当则会丢失关键事实。这也是原文将检索、重排、截断视为同一设计链条的原因。

当前实践中的几种典型模式

从社区讨论和公开实践看，上下文工程目前大致形成了几类做法：

• 分层上下文：把系统指令、任务说明、检索内容、对话历史分层组织，并对不同层设置不同的裁剪策略。
• 动态摘要：长对话中定期压缩历史，只保留决策相关的事实，而非逐字保留。
• 工具输出过滤：对工具返回的原始内容先做结构化抽取，再决定是否进入上下文，避免一次性灌入大段文本。
• 上下文预算：为不同来源分配 token 配额，把窗口当作需要规划的资源。

这些模式尚未形成标准库或统一框架，更多是各团队在工程中自行沉淀的经验。这也解释了为什么“状态”一词更贴切——领域仍在流动中。

上下文预算借用了经济学中的资源分配思路：把上下文窗口视为固定容量的稀缺资源，为系统提示、检索片段、工具输出、对话历史等不同来源预设 token 配额上限，超出配额时触发压缩或丢弃。实践中常见做法包括为每类来源设置硬上限、按优先级动态调整配额、以及在预算紧张时优先保留决策相关事实而非原始文本。这一模式的价值在于把“塞什么”从直觉判断变成可度量、可调参的工程决策，但也带来新问题：配额比例如何设定、超限时丢弃哪部分内容，目前仍缺乏通用准则。

仍待回答的问题

原文与讨论并未给出确定答案，反而暴露了几个开放议题。

其一是责任归属：上下文策略应该由应用层实现，还是下沉到模型或框架层？目前两种路线都有尝试，但边界模糊。

其二是可观测性：当模型输出变差时，很难判断是检索错了、摘要丢了信息，还是上下文顺序有问题。缺乏调试工具是这个领域落地的现实阻力。

其三是与微调的关系：部分知识究竟应该放进上下文，还是通过训练固化进模型，这是成本与灵活性的权衡，目前仍以经验判断为主。

上下文工程的热度，本质上反映了一个事实：模型能力的提升并没有消除工程问题，只是把问题从“如何表达”迁移到了“如何组织信息”。这个迁移过程，可能比任何单一技巧都更值得关注。

微调指在预训练模型基础上，用特定领域数据继续训练以将知识或行为模式固化进模型参数。与上下文注入相比，微调的知识不占用推理时的上下文窗口，响应更稳定，但更新成本高、灵活性差，且难以针对快速变化的信息及时调整。上下文注入则相反：无需训练即可随时更新知识，但每次调用都要消耗窗口预算，且受检索质量制约。二者的取舍通常取决于知识更新频率、任务对延迟的敏感度以及可用的训练资源，目前尚无通用的决策框架，多以经验判断和小规模对比实验为主。