有一段时间，\"提示工程\"是我们用来描述从大型语言模型中获得好结果的技艺的名称。在早期，这说得通。大多数人使用的是一次性交互，而主要的杠杆确实感觉像是措辞：问得更清楚、加一个例子、限制格式，模型的表现就会更好。
\n但这种框架对于真正的问题来说，现在已经太小了。
\n当一个AI系统在生产环境中失败时，问题通常不是模型需要在系统提示中再多一句巧妙的话。问题在于模型没有看到正确的信息、看到了太多无关信息、以错误的格式看到了正确信息，或者无法将正确的状态从一个步骤传递到下一个步骤。换句话说，问题不仅仅是提示。问题是整个上下文管道。
\n这就是为什么上下文工程这个术语开始流行起来。这个短语在2025年中期进入主流AI讨论，当时Tobi Lütke和Andrej Karpathy认为\"提示工程\"低估了构建可靠LLM系统所涉及的真正工作量。[1] 但背后的学科比这个名字更古老。如果你构建过RAG、工具调用、记忆系统、摘要或评估循环，你已经做过上下文工程的各个部分。变化的是我们终于有了一个描述整个工作的名字。
\n如果你想要最简单的图景，上下文工程就是外部世界与模型工作记忆之间的那一层。
\nflowchart TD\n U[\"User request\"] --> CE[\"Context engine\"]\n\n I[\"Instructions and policies\"] --> CE\n R[\"Retrieved knowledge\"] --> CE\n M[\"Memory and saved state\"] --> CE\n T[\"Tool definitions and results\"] --> CE\n H[\"Recent conversation history\"] --> CE\n\n CE --> W[\"Model context window\"]\n W --> L[\"LLM reasons and acts\"]\n L --> O[\"Answer or tool call\"]\n O --> S[\"New memory, logs, and state\"]\n S --> CE\n这就是整个游戏。
\n模型是推理引擎。上下文引擎决定模型可以对什么进行推理。
\n这个术语引起共鸣的一个原因是，它将几条一直在独立发展的线索联系在了一起。
\n检索增强生成（RAG）教会我们，模型在推理时需要访问外部知识。[2] ReAct教会我们，当模型能够调用工具、观察结果并继续推理时，推理和行动的效果会更好。[3] 记忆研究教会我们，长期运行的助手需要索引、检索和阅读策略，而不是无休止地累积对话记录。[4] 长上下文评估表明，简单地将更多token塞入模型并不等同于给它更好的工作记忆。[5][6][7]
\n这样看来，上下文工程并不是要取代这些想法。它是它们之上的那把伞。
\n这把伞很重要，因为现代AI系统不再是孤立的提示。它们是动态系统，将指令、文档、结构化数据、工具输出和先前状态组装到下一步的临时上下文窗口中。LangChain很好地描述了这一点，它将上下文工程定义为提供正确信息和工具以正确格式呈现的工作，以便LLM能够合理地完成任务。[8]
\n\"合理地完成任务\"这个短语在这里做了很多工作。它是正确的测试标准。
\n如果一个智能体失败了，第一个问题不应该是\"如何让提示更聪明？\"
\n第一个问题应该是，\"我是否真的给了模型成功所需的东西？\"
\n提示工程仍然重要。它只是变成了一个更大学科的一个子集。
\n旧的思维模型是：
\n| 提示工程 | \n上下文工程 | \n
|---|---|
| 写出更好的指令 | \n构建完整的信息环境 | \n
| 专注于单个请求 | \n专注于多步骤系统 | \n
| 大多是静态的 | \n动态且有状态的 | \n
| 优化措辞 | \n优化选择、结构、记忆和工具 | \n
| 改进单次模型调用 | \n改进整个循环 | \n
这种区别在你构建一个智能体的那一刻就变得显而易见了。
\n假设你正在为企业软件构建一个支持智能体。用户问：\"为什么我们的API请求超时了？\"
\n如果你只从提示的角度思考，你可能会改进措辞：
\n这些都是不错的改进。但还不够。
\n真正的系统问题更难：
\n这就是上下文工程。
\n提示只是其中的一行项目。
\n在实践中，上下文包括模型在推理时看到的所有内容，不仅仅是可见的提示。[8][9]
\n这通常意味着：
\n这就是为什么\"填充上下文窗口\"这个短语变得如此核心。上下文窗口不仅仅是放置文本的地方。它是模型的临时工作记忆。进入其中的所有内容都在争夺注意力。
\n而竞争就是关键词。
\n每一个额外的token不仅仅是额外的信息。它也是额外的干扰。
\n当前AI市场中最常见的误解之一是，更大的上下文窗口让上下文工程变得不那么重要了。
\n研究指向的是相反的方向。
\nLost in the Middle表明，模型对长上下文的使用往往是不均衡的，当相关信息出现在开头或结尾时表现更好，而当重要信息位于中间时表现更差。[5] Databricks的长上下文RAG研究发现，虽然添加更多检索到的文档可能有帮助，但只有少数最先进的模型在64k token以上保持强劲性能。[6] Chroma的Context Rot报告更进一步：即使是简单的任务，随着输入长度增加也会变得更不可靠，特别是在引入模糊性和干扰项时。[7]
\n这是许多团队通过惨痛教训学到的部分。
\n更大的窗口并没有消除选择的需要。它们起初让错误选择的代价不那么明显，但之后会更加痛苦。
\n一个长提示至少可能以四种不同的方式失败：
\n这就是为什么上下文工程不是关于最大化token。它是关于最大化上下文窗口内的信号密度。
\n这就是最近最好的想法之一进入画面的地方。
\nJason Liu认为，经典基于分块的RAG之后的下一步，是停止只思考\"最相似的段落\"，而开始思考搜索空间的形状。[10] 他的框架特别有用，因为它描绘了许多团队已经在经历的演进路径：
\n前三项是对检索内容的改进。
\n第四项更有趣。它改进了智能体关于语料库本身所学到的内容。
\n分面给模型提供了类似周边视觉的东西。系统不仅可以返回最前面的几个分块，还可以返回聚合的元数据：
\n这很重要，因为相似性搜索偏向于最容易匹配的内容，而不一定是最需要检查的内容。[10] 检索系统可能过度呈现记录完善的已解决事件，而低估稀疏的、仍然开放的事件。法律搜索可能过度呈现已签署的合同，而隐藏实际上需要关注的未签署合同。分面帮助智能体不仅看到\"什么匹配了\"，还看到\"附近还有什么存在\"。
\n这是一个重大的概念转变。
\nRAG主要是关于检索。
\n上下文工程越来越是关于导航。
\n让上下文工程具体化的最简单方法，是将其分解为实际执行的工作。
\n第一项工作是决定什么值得进入窗口。
\n这包括检索、排序、过滤、来源选择和时效性检查。这听起来很明显，但这仍然是大量质量得失的地方。像BRIGHT这样的基准测试表明，现实的检索比表面层次的语义匹配要困难得多。[11] 如果你的检索质量很弱，再多的下游提示润色也无法完全挽救结果。
\n选择不仅仅是\"找到相关的分块\"。它是：
\n好的系统通常比朴素的系统检索得更少，但检索得更有意图。
\n第二项工作是决定所选上下文如何呈现。
\n相同的信息根据格式不同可能有用也可能无用。Anthropic的工具使用指南明确指出了这一点：工具描述和接口强烈影响模型行为。[9] 长上下文提示指南对XML标签、来源标签和清晰分隔的文档部分也提出了类似的建议。[12]
\n在实践中，结构意味着：
\n一个简短、标注良好的结果往往胜过一个巨大的JSON blob。
\n第三项工作是在不破坏重要内容的前提下减少上下文。
\n这是许多智能体系统要么变得更好、要么变得更差的地方。
\n压缩可以意味着：
\nOpenAI的提示缓存文档表明，提示顺序在经济上和认知上都很重要：静态共享前缀放在前面时更便宜更快，因为缓存命中依赖于精确的前缀复用。[13] OpenAI较新的Responses API在压缩方面进一步推进了同样的想法，将长期运行的智能体历史视为应该在窗口填满之前被压缩成更token高效的表示的东西。[14]
\n压缩不是可选的。唯一的问题是你有意地做，还是让上下文窗口自行退化。
\n第四项工作是决定什么应该超越当前回合而持久存在。
\n这是许多团队犯同样错误的地方：他们将记忆与对话记录保留混淆了。
\n但好的记忆不是\"永远保留一切\"。LongMemEval将长期记忆框定为一个三阶段问题：索引、检索和阅读。[4] 这是正确的思考方式。记忆系统应该帮助模型在正确的时刻恢复正确的事实，而不是用完整的过去淹没它。
\n这引出了一个有用的区分：
\n如果一切都留在工作记忆中，模型会分心。\n如果一切都被推出去，模型会失去连续性。
\n上下文工程决定什么属于每一层。
\n第五项工作是使工具对模型可读。
\n这是该学科中一个被低估的部分。工具表面不仅仅是软件API设计。它也是上下文设计。
\n模型需要理解：
\n这就是为什么工具描述如此重要。[9] 这也是为什么Jason Liu对工具结果的强调很重要。[10] 工具的输出不仅仅回答当前查询。它教会智能体如何思考下一个查询。
\n当工具表面通过像MCP这样的协议标准化时，这变得更加重要。MCP使连接工具、资源和提示到LLM应用变得更容易，但它不决定应该呈现什么信息、如何过滤，或者多少信息应该注入到下一次模型调用中。[15] 协议是管道。上下文工程仍然是手艺。
\n第六项工作是决定何时不共享上下文。
\n这是玩具演示和生产智能体之间最大的区别之一。
\n有时正确的答案不是更大的共享提示。而是多个具有隔离范围的较小提示。
\nAnthropic的多智能体研究系统就是一个有力的例子。[16] 他们的子智能体在独立的上下文窗口中并行运行，这有助于它们探索问题的不同分支，而不会因为每一个中间细节而相互污染。LangChain在\"隔离\"下描述了类似的模式：有时提高智能体可靠性的最佳方式是分割上下文，而不是累积它们。[17]
\n这很重要，因为共享上下文有一个隐藏的成本。它创造了路径依赖。一个坏的分支可以影响下一步，再下一步，再下一步。
\n隔离是一种限制爆炸半径的方式。
\n2025年，上下文工程主要是一个对人们已经感受到的问题有用的名字。2026年，它开始硬化为一种架构。
\n第一个重大转变是构建者将持久状态移出原始上下文窗口。Anthropic的上下文编辑和记忆工具明确区分了留在工作窗口中的内容和应该跨会话持久存在的内容。[18] OpenAI 2026年1月关于个性化的cookbook以不同的形式做出了同样的转变：结构化状态对象跨运行持久存在，并在每次运行开始时被有意地注入回工作记忆。[19] OpenAI的Responses API然后通过原生压缩进一步推进了这一点，因此长期运行的智能体循环不需要每个团队都从头构建自定义摘要子系统。[14]
\nAnthropic的Managed Agents使底层模式异常明确：会话不是模型的上下文窗口。[20] 这是2026年的一个关键思想。窗口是临时工作记忆。会话日志是持久对象。框架决定如何切片、压缩和重新水合那个持久上下文回到下一次模型调用中。
\n第二个转变是检索变得更加即时和更加原生接口化。团队不再预先加载每一个可能相关的token，而是给智能体提供它们已经知道如何操作的检索表面。Mintlify的ChromaFs就是一个很好的例子：不是为文档检索启动完整的沙盒，而是将文档呈现为可通过ls、cat和grep导航的虚拟文件系统，将p90会话创建时间从约46秒缩短到约100毫秒。[21] Turso的AgentFS将同样的直觉推向通用智能体执行：一个具有可移植单文件存储和内置审计的写时复制文件系统抽象。[22]
第三个转变是上下文图正在成为一个实现方向，而不仅仅是一个隐喻。Foundation Capital的论文使这个术语可见，但更强的主张是架构性的：当智能体位于执行路径中时，它们可以将决策痕迹捕获为持久工件，而不仅仅是发出最终输出。[26][27] 像Graphiti这样的开源系统和像Zep这样的商业平台将其操作化为具有有效性窗口、来源片段和跨语义、关键词与图结构的混合检索的时间上下文图。[23] TrustGraph采取相关方法，将上下文视为版本化工件：图、嵌入、证据和策略被打包成可移植的\"上下文核心\"，可以像构建输出一样被提升或回滚。[24][25]
\n第四个转变是上下文工程现在可见于真实的软件实践中，而不仅仅是平台博客。2026年关于开源软件中上下文工程的MSR论文研究了466个仓库，发现AI上下文文件如AGENTS.md正在传播，但还没有稳定的内容结构。[28] 这很重要，因为它标志着从理论到运维工件的转变。上下文不再只是运行时推断的东西。它正在成为软件生命周期中被编写、版本化、审查和挖掘的一部分。
如果你想要2026年的思维模型用一张图表示，它看起来像这样：
\nflowchart LR\n E[\"Session log / events\"] --> A[\"Context assembler\"]\n F[\"Files, docs, and tools\"] --> A\n G[\"Context graph / memory\"] --> A\n P[\"Policies and AGENTS.md\"] --> A\n\n A --> W[\"Working context window\"]\n W --> X[\"Agent action\"]\n\n X --> E\n X --> G\n这与\"提示 + 向量搜索\"是非常不同的架构。
\n这个对话变得模糊的一个原因是，人们使用上下文工程和上下文图，好像它们意思相同。它们不是。
\n上下文工程是更广泛的学科。它是决定什么进入下一个上下文窗口、什么留在外面、什么被压缩、什么按需检索的工作。
\n上下文图是更大系统中的一种可能的长期记忆基底。
\n这种区分很重要，因为不是每个有用的智能体都需要上下文图。一个主要覆盖静态内容的文档助手可能需要良好的检索、工具设计和压缩，但不需要图。一个编码智能体可能通过仓库指令、持久会话日志和文件系统抽象就能走得很远。[20][21][22][28]
\n当问题具有四个特征时，上下文图变得引人注目：
\n这就是为什么在我看来，上下文图最好的定义不是\"AI的图数据库\"。它是先例的持久表示。
\n这也是为什么决策痕迹如此重要。Foundation Capital的框架在这里很有用：规则告诉智能体一般情况下应该发生什么；决策痕迹告诉它在特定情况下发生了什么，在真实约束下，有真实的例外。[26] 一旦这些痕迹跨实体和时间链接起来，你得到的东西比通用记忆更有价值。你得到的是可搜索的判断。
\n如果我今天正在构建一个严肃的上下文工程栈，我不会从图开始。我会从接口和提升规则开始。
\n每一个动作、工具结果、观察和重要的中间工件都应该落在一个仅追加的会话日志或事件存储中。这是你的可恢复上下文对象。[14][20]
\n不要将活动上下文窗口与真相来源混淆。
\n窗口用于推理。\n会话用于恢复、重放、调试和选择性重新水合。
\n组装器应该明确管理：
\n这是决定模型现在看到什么的层。它应该是可观察的、可测试的，并且易于更改。[18][19][14]
\n首先给模型轻量级的句柄：文件路径、对象ID、URL、查询模板、工单ID、事件ID。然后让它只在需要时拉取细节。[9][18][21]
\n这就是文件系统、MCP工具、搜索API和结构化查询变得比巨大的top-K转储更有价值的地方。
\n不是一切都应该成为记忆。
\n我会提升四类工件：
\n其他一切都应该留在会话日志中，直到它证明自己值得被提升。
\n这是许多团队颠倒的部分。
\n图不应该是你的原始对话记录的图形式。它应该是位于会话之上、实时组装之下的策划层：
\n如果你跳过提升步骤，图会变成垃圾场。\n如果你做对了提升，图会变成组织实际如何推理的记忆。[23][26]
\n到2026年，最有前途的想法之一是将上下文视为版本化工件。在软件项目中，这表现为AGENTS.md和其他仓库特定的上下文文件。[28] 在图原生系统中，这表现为上下文核心：可移植的本体、图结构、嵌入、来源和检索策略的捆绑包。[24][25]
这很重要，因为上下文变更需要与代码变更相同的运维纪律：
\n一旦上下文成为工件，它就变得可治理。
\n你需要两者：
\n这两者不是一回事。
\n我想知道：
\n如果你无法回答这些问题，你仍然在黑暗中调试提示。
\n如果你试图评估自己的系统处于什么位置，这个成熟度模型比抽象定义更有用。
\n你有一个系统提示、一条用户消息，也许还有几个例子。
\n对于狭窄的任务，这可以出奇地有效。当任务需要新鲜知识、持久性或工具时，它很快就会崩溃。
\n你在运行时添加文档。
\n这是许多团队停止的地方。这也是许多团队开始看到朴素分块、排序和上下文膨胀局限性的地方。
\n你现在有意地管理历史、工具结果、记忆和格式。
\n这是\"上下文工程\"首次成为有用术语的级别，因为系统不再只是提示加检索。它是动态地组装多种形式的上下文。
\n系统根据任务改变构建上下文的方式。
\n它可能：
\n在这一点上，上下文构建是应用核心逻辑的一部分。
\n系统将上下文视为一流的工程表面。
\n它具有：
\n这是最强的生产系统正在走向的方向。
\n如果我要将整个学科简化为一个检查清单，它看起来会是这样：
\n这些都不 glamorous。这正是它重要的原因。
\n提示工程变得流行，因为它听起来像捷径。
\n上下文工程重要，因为它描述了实际的工作。
\nAI的重心正在转移。
\n前沿问题曾经是：模型有多聪明？
\n应用问题越来越变成：模型在必须行动之前能看到什么？
\n这是一个不同的工程问题。它更少关于单个提示，更多关于系统设计。更少关于措辞，更多关于信息流。更少关于一次性输出质量，更多关于智能体是否能随时间保持可靠。
\n这就是为什么上下文工程将继续作为一个学科成长。模型越好，剩下的失败就越像上下文失败。缺失的状态。错误的工具。糟糕的检索。膨胀的历史。糟糕的格式。矛盾的证据。薄弱的记忆。无限制的循环。
\n讽刺的是，这让AI系统感觉更像经典软件，而不是更少。我们回到了构建管道、接口、状态机、内存层次结构、缓存和可观察性层。新颖之处在于，所有这些部分现在都为概率推理引擎服务。
\n名字可能是新的。方向不是。
\n可靠的AI系统将由将上下文视为一流产品表面的团队构建。
\n其他人会继续说模型不稳定。
\n参考文献：
\n[1] Simon Willison. (2025, June 27). Context engineering.
\n[2] Lewis, P. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.
\n[3] Yao, S. et al. (2023). ReAct: Synergizing Reasoning and Acting in Language Models.
\n[4] Wu, D. et al. (2025). LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory.
\n[5] Liu, N. F. et al. (2023). Lost in the Middle: How Language Models Use Long Contexts.
\n[6] Leng, Q. et al. (2024). Long Context RAG Performance of Large Language Models.
\n\n[8] LangChain. (2025, June 23). The rise of \"context engineering\".
\n[9] Anthropic. How to implement tool use.
\n[10] Jason Liu. (2025, August 27). Beyond Chunks: Why Context Engineering is the Future of RAG.
\n\n[12] Anthropic. Long context prompting tips.
\n\n\n[15] Model Context Protocol. What is the Model Context Protocol (MCP)?
\n[16] Anthropic. (2025, June 13). How we built our multi-agent research system.
\n[17] LangChain. (2025, July 2). Context Engineering.
\n[18] Anthropic. (2025, September 29). Managing context on the Claude Developer Platform.
\n\n[20] Anthropic. Scaling Managed Agents: Decoupling the brain from the hands.
\n[21] Mintlify. (2026, March 24). How we built a virtual filesystem for our Assistant.
\n[22] Turso. AgentFS.
\n[23] Zep. Graphiti: Build Real-Time Knowledge Graphs for AI Agents.
\n[24] TrustGraph. The context development platform.
\n[25] TrustGraph. Working with Context Cores.
\n[26] Gupta, J., and Garg, A. (2025, December 22). AI's trillion-dollar opportunity: Context graphs.
\n[27] Garg, A. (2026, January 16). Why context graphs are the missing layer for AI.
\n", "source_hash": "sha256:43286410ec2f1b23129ef8d7330ac9e09e780a8159635d34658ade10aac0581a", "model": "moonshotai/kimi-k2.6", "generated_at": "2026-05-31T02:55:04.713367+00:00" }