“多数 Al Agent 的失败，并非模型能力的失败而是上下文工程的失败。”
上下文工程：AI应用构建的隐形框架
概念溯源与争议
当Context Engineering（上下文工程）这一术语在技术社区引发热议时，许多开发者最初的反应与笔者一致——这究竟是Prompt Engineering的变体包装，还是对RAG（检索增强生成）的过度解读？
事实上，正如Andrej Karpathy所言，其本质是“为LLM任务提供恰到好处的上下文信息”的系统化方法论。
这种认知差异恰恰揭示了技术演进中的典型现象：当某个领域从实践探索升华为理论总结时，术语的边界往往最先引发争论。
技术哲学的三重维度
\1. 动态上下文管理
不同于静态的Prompt模板，上下文工程强调根据任务进展实时调整信息供给。例如在多轮对话Agent中，系统需动态维护：
• 短期上下文（当前对话轮次）
• 长期上下文（用户历史偏好）
• 隐性上下文（环境参数如时间、位置）
\2. 信息熵的精确控制
Tobi Lütke提出的“微妙艺术”实则指向信息密度与相关性的平衡。工业级应用要求开发者像电影剪辑师般精准：
• 剔除冗余噪声（如无关历史记录）
• 保留关键线索（如未完成的订单编号）
• 预埋推理锚点（如结构化数据标签）
\3. 系统级的上下文协议
与MCP（模型上下文协议）的互补性体现在：
• MCP定义上下文传输的标准化接口
• 上下文工程决定接口内流动的“信息血液”
工业实践中的准则沉淀
在智能客服系统的故障诊断案例中，上下文工程的准则体现为：
\1. 可追溯性：保留完整的错误链上下文
\2. 模块化：区分用户输入、系统日志、知识库片段
\3. 可解释性：为每个上下文片段添加元数据注释
这种准则体系与Prompt Engineering的“技巧集”存在本质差异——后者关注单次交互的最优解，而前者追求复杂系统的稳定涌现。
正如量子物理中的观测者效应，上下文工程揭示的正是：在Agentic系统中，我们提供的上下文质量，直接决定了AI可能性的边界。
本篇博客旨在回答以下三个问题:
What?什么是 Context Engineering?它和我们熟知的 Prompt Engineering、RAG 有什么本质区别?
Why?我们为什么需要这样一个新的概念?它的作用是什么?具有什么价值?
How?如何系统性地进行 Context Engineering?Context Engineering 包含哪几个部分?以及这几个部分对应的最佳实践。
由于上下文工程的内涵仍在快速演进，其概念边界较为开放，在一篇文章中全面覆盖所有细节颇具挑战。
因此，本文的核心目标并非求全，而是聚焦于其最有价值的核心，力求为读者构建一个清晰、稳固的认知(这样看来叫一篇就够了略微标题党了)。
1. What is Context Engineering?
1.1如何定义 Context?
在理解什么是 Context Engineering(上下文工程)之前，我们首先需要明确什么是 Context(上下文)?相当一部分人会认为用户的历史聊天记录就是上下文。
这个理解是部分正确的，上下文所涵盖的范围要远大于简单的历史对话记录。从本质上讲，上下文(Context)是提供给LLM 的、用于完成下一步推理或生成任务的全部信息集合。引用一张图来进行概括:
虽然上图提供了全面的视角，但其并没有进一步分类。为了更清晰地分析，我倾向于将上下文划分为三个核心类别:
引导型上下文(Guiding Context)，这类上下文的主要作用是明确指示模型的行为规范和操作指南，为模型执行任务提供方向性指引。
Prompt Engineering的核心优化对象通常就是引导型上下文。
其构成要素包括：系统指令(SystemPrompt)；任务说明(Task Description)；示例演示(Few-shot Examples)；输出规范(Output Schema)（前三项较为基础，OutputSchema通常是限定模型输出格式如JSON/XML的结构化定义）
知识型上下文(Informational Context)，这类上下文的核心价值在于向模型传递必要的认知基础，为问题解决提供事实依据和信息支撑。
其涵盖：检索增强生成(RAG)；记忆系统（短期记忆：当前会话记录，长期记忆：跨会话保留的关键数据和用户偏好）；状态记录/临时笔记（如ClaudeCode的任务规划TODO列表和Thinking模式的思考过程记录）
操作型上下文(Actionable Context)，这类上下文的本质功能是赋予模型外部交互能力并反馈执行结果，使模型具备现实世界行动力。其包含：工具定义(Tool Definition)；工具调用记录（工具使用历史及返回结果/Tool Traces）。
所以，上下文是一个多维，动态，服务于特定任务的系统性概念。
1.2 如何理解 Context Engineering?
明确了“上下文"的定义之后，我们可以回归核心问题: 究竟什么是上下文工程?
回顾 Tobi Lütke 和 Andrej Karpathy 的观点:(提供所有上下文的艺术，以使任务能够被LLM合理地解决)&&(上下文工程是一门微妙的艺术与科学，旨在在上下文窗口中填入恰到好处的信息，为下一步推理做准备)
由此，本文为上下文工程提出如下定义: ContextEngineering 是一门系统性学科，专注于设计、构建并维护一个动态系统，该系统负责在 Agent 执行任务的每一步，为其智能地组装出最优的上下文组合，以确保任务能够被可靠、高效地完成。
由于上下文工程更接近一种开发哲学，它可以从多个角度被解释。其中一个极具启发性的类比源自 YouTube:Andrej Karpathy: Software ls Changing (Again)。
若将LLMs（或更广义的Agentic System）类比为新一代操作系统，那么LLM相当于中央处理器（CPU），而上下文窗口（Context Window）则如同随机存取存储器（RAM）——同样受限于容量，负责为CPU提供所需的内存空间。
上下文工程在此系统中扮演着内存管理器的角色。其核心使命并非粗暴地填满RAM（上下文窗口），而是借助精密的调度策略，在每一个"时钟周期"动态决策：哪些数据需要即时载入、哪些可以暂存置换、哪些必须优先处理，以此确保系统高效稳定运行并输出精准结果。
这也印证了"上下文工程是融合艺术性与科学性的精细技艺，其目标是在有限窗口内精准配置信息，为后续推理铺路"的核心理念。
整体而言，上下文工程代表着LLM交互范式的演进——从早期Prompt Engineering阶段对指导性上下文（Guiding Context）的优化，跃迁至"打造最优信息供给体系"的新纪元。
1.3 Context Engineering vs PromptEngineering vs RAG
在深入1.1/1.2节的理论阐述前，多数从业者（包括笔者）对Context Engineering的认知往往存在光谱式的理解偏差。
部分观点将其视为Prompt Engineering的扩展形态，另一些则简单等同于RAG技术的上下文堆砌方案。
经过前文的范式定义，三者间的拓扑关系得以显性化——它们构成非互斥的协作体系，而非替代关系。
用架构语言表述：提示词工程本质是上下文工程的子模块，专注精炼指导性上下文(Guiding Context)的构建；而RAG技术则承担动态生成信息性上下文(Informational Context)的基础设施角色。
已掌握差异点的读者可跳过后续说明性段落。
层级化技术分工
Prompt Engineering
其作用域聚焦于单次对话的指令优化，包括系统提示词的角色定义、Few-shot示例植入及输出格式约束等微观调控。这属于高度场景化的单轮交互优化技术。
RAG技术
核心功能是从外部知识源检索相关信息，将其转化为信息性上下文注入对话窗口。但上下文工程的覆盖维度显著超越RAG——不仅需要解决检索什么的问题，更需实现信息性上下文与另外两类上下文的动态融合。
成熟的Context Engineering系统可能完全规避RAG，或在检索失败时启动备用工具链。
2. Why Context Engineering?
在上一章节，我们解构了“Context Engineering"的定义及其与相关概念的区别。一个自然而然的问题是: 我们为什么需要这样一个新的概念?
2.1模型之过，还是上下文之失?
LLM Accuracy Optimization 系列博客中，提到过一个“优化 LLM 的二维思维模型”(那时候还未出现 Context Engineering 的概念)。当 agenticsystem 或单次 LLM 调用的输出不及预期时，问题的根源往往可以归结为两个方面:
1.模型能力局限: 基座模型自身的能力不足，需要对模型本身进行优化。
2.上下文信息缺失: 模型没有接收到生成高质量回复所需的恰当上下文。
通常情况下(尤其是现在基础模型的智能已经超过一个阈值)，输出不及预期的原因更多指向后者。即我们没有实现有效的上下文工程，导致模型缺失了一些解决问题的关键信息。
模型不会读心术，因此只能进行不确定的假设，甚至陷入不必要的幻觉。(这也引出了一个值得思考的方向: 一个能主动识别并请求补全缺失上下文的LLM，或许能从根本上解决相当一部分问题?)
2.2 两个简单的示例
这两个例子将清晰地展示 Context Engineering 的必要性。
示例一: 缺失上下文的代价
这个例子源自 Philipp Schmid 的观察，它展示最基础的上下文缺失是如何造成巨大的结果差异。
想象你的 Al助手收到一封简单的邮件:
“Hi, 明天有空聚一下吗?"
一个上下文贫乏(Poor Context)的 Agent，它只能看到这句请求，别无其它上下文。其回应是机械的:
“感谢您的消息。我明天有空。请问您希望约在什么时间?"
分析: 此 Agent 未能推进任务，因为它缺乏做出下一步决策所需的信息性上下文
现在，考虑一个上下文充足(Rich Context)的 Agent。它的系统在调用 LLM 之前，其首要任务是动态地组装一个包含多维信息的上下文:
信息性上下文(Informational):
[Calendar Data] 检索你的日历，发现明天日程已满。
[Contact Data]: 识别发件人 Jim 是重要合作伙伴。
[Email History] 分析过往邮件，确定沟通应采用非正式语气。
行动性上下文(Actionable):
[Tool Definition] 提供
send_calendar_invite 工具的描述
基于这个完整的上下文，它能生成一个真正高效的回应
“Hi Jim! 我明天日程完全满了。周四上午有空，你看方便吗?我发了一个暂定邀请，如果时间合适请确认。”
分析: 这里的“魔力"，并非源于更智能的模型，而是一个能够为特定任务动态组装恰当上下文的系统。
这个例子展示了 Context Engineering 必要性的第一个层面: 缺乏上下文，将造成显著的性能鸿沟。
示例二: 上下文退化的挑战
第一个例子似乎暗示了一个简单的解决方案: 把所有可能的上下文都提供给模型。暂且不考虑模型能力(大部分LLM并没有较长的上下文容量)和经济成本。
当任务变得复杂和长程时，这种“简单的累加"策略不仅会失效，甚至会降低模型的表现。例如，你与 Jim 的往来邮件有上千封，其中不乏长篇内容，将这一切全部输入给LLM 并非明智之举。
这里我通过另一个例子来进一步的介绍 ContextEngineering的重要性(受 Cognition Al 博客的启发)想象一个 Agent 被赋予一项长期任务: 在一个大型代码库中，为期数天，实现一个涉及多个文件和依赖项的新功能。
为了方便阐明，我们假设采用的是线性 AgenticSystem(因为并行架构存在决策不一致等内在复杂性，在某些场景例如 Coding 下并非最优选择)。
一种朴素的策略: 为了保证模型“无所不知"，系统将每一次交互都记录下来——每一条用户指令、文件读取、编译错误、成功的工具调用--并将这整段历史作为上下文，在每次调用 Agent 时都完整地传递给LLM.
必然出现的失败级联
1.性能下降: 首先，性能会悄然下降。早期任务中1无关紧要的细节(例如一次已解决的语法错误)会不断稀释当前步骤所需的核心信息，造成上下文干扰(Context Distraction)
2.成本与延迟激增: 随着上下文线性增长，每次API调用的 Token 数量急剧膨胀，导致成本失控和更高的延迟。
3.最终崩溃: 最终，系统将撞上架构限制--上下文溢出(Context Overflow)。当累积的信息总量超过模型的上下文窗口上限(无论是 200K还是1M tokens)，API调用将直接失败，可能导致任务中断，或因信息截断而引向错误的结果。
Context Engineering 便是旨在解决这类问题的。例如，它可以通过对上下文进行智能管理与压缩，仅将高价值的结论与信息注入上下文(相当一部分 token 是没有价值的分析)，从而规避上述风险。下图是一个简单的示例。
这个例子表明了: 上下文是一种需要被主动管理的、有限的资源。简单的累加策略在规模化应用中是不可持续的。
2.3 小结
随着基础模型的能力普遍越过一个关键阈值，上下文工程不仅成为提升系统表现的更高优先级选项，在许多场景下，它甚至是唯一可行的路径。
上下文的缺失固然会导致Agentic System性能下降、幻觉频发，但无差别地堆砌所有历史信息注入上下文，同样会引发各类上下文退化问题。
因此，上下文的重要性及其管理复杂性逐步被所有 AI工程师所熟知。这就要求我们必须建立一套系统性的方法论来对上下文进行智能的、动态的写入(Write)、选取(Select)、压缩(Compress)和隔离(Isolate)。这四个操作构成了上下文工程的实现细节，也正是我们将在下一章探讨的核心内容。
3.How? The Best Practice of Context Engineering
“提示工程"一词被创造，指代为大型语言模型聊天机器人编写理想格式任务所需付出的努力。“上下文工程"是其更高层次。
它指的是在动态系统中自动完成这项工作。这需要更精妙的考量，并且实际上是构建 Al Agent 的工程师们的首要任务。——Cognition Al
上下文工程的实践可从两个维度展开: 首先识别常见的失效模式，进而构建对应的工程方法。本章将从问题诊断与解决方案两个层面进行分析。鉴于技术快速演进，以下方法代表当前阶段的通用实现，而非永恒结论。
3.1 什么是上下文退化?
在介绍上下文工程的最佳实践前，我们有必要想想工业级Agentic System 一般会遇到何种上下文相关的问题。了解了问题所在，才能更好地理解对应的解决方案。
最常见的问题是 Informational Context 的缺失，此时需要优化的应该是 RAG 即检索部分。仅仅缺少相关信息的这类问题的解决方案比较成熟。接下来是一些不那么常见或者不那么直觉的 Context 问题。
在探讨解决方案之前，我们必须首先清晰地定义问题。虽然“信息性上下文缺失"(如 RAG 检索失败)是最直观的挑战，但在工业级的长程、复杂 Agentic System中，一个更根本且更隐蔽的威胁是上下文退化。
以 Coding Agent 为例，单次任务的 token 消耗通常是普通 chatbot 的数倍。Anthropic的 Multi-AgentResearch System 的 token 消耗量达到普通应用的 15倍。
这种消耗模式使得上下文窗口管理和跨 agent 的上下文传递成为核心技术挑战。关于 Long Context 可能引起的问题，参考我基于博客 How Long Contexts Fail 进行的总结。
长上下文带来成本与协同压力，更易暴露四类上下文失效: 污染、干扰、混淆、冲突。它们常彼此耦合，并直接损害推理稳定性与跨代理传递。
上下文污染(Context Poisoning)，主要是幻觉进入 Context 导致异常结果。
上下文干扰(Context Distraction)，当 Context 接近溢出时，模型训练中获得的知识会被“覆盖"导致模型降智。
上下文混淆(Context Confusion)，冗余且不相关的 Context 让输出结果偏离期望。
上下文冲突(Context Clash)，当上下文中的信息互相矛盾时，比如上下文存在过去错误的答案。
3.2 上下文工程的最佳实践
为应对上述挑战，业界已逐步收敛出一套系统性的应对框架。参考 Lance's Blog，如下图所示将上下文工程分为四个部分:写入(Write)、选取(Select)、压缩(Compress)和隔离(Isolate)。
每个部分的具体实现策略和细节有太多可以深挖的，这里仅作大致的介绍。
写入(Write)
写入主要是将上下文持续久化，超越上下文窗口的限制在未来按需取用。通常情况下分为:
会话内写入(Session-levelWrite): Agent 将中间思考、计划或临时数据写入一个会话内的草稿纸(Scratchpads)。这是一种轻量级的、非持久化的写入，用于管理当前任务的复杂性。
持久化写入(Persistent Write): 系统将具有长期价值的信息(如用户偏好总结、关键事实)写入外部的记忆(Memory)系统，如向量数据库或知识图谱。
这实现了跨会话的知识积累。例如，ChatGPT和Cursor等应用通过这种方式，让 Agent在与用户的持续交互中“学习"和“成长"，用户在解决某些问题时无需手动引入上下文。
Anthropic也曾在博客中建议，Subagent output to a filesystem to minimize the 'game of telephone. 通过把 subagent 的输出写到文件以避免无意义的上下文传递，上下文窗口占用等。
选取(Select)
选取的目的，是在每次 LLM 调用前，从所有可用的信息源中，动态地拉取与当前子任务最相关的信息。这是保证上下文信噪比的关键。
上下文工程中的选取包括三类:
确定性选取(Deterministic Select) : 指根据预设规则加载上下文。例如，编码 Agent (Claude Code)在启动时，固定加载项目根目录下的CLAUDE.md文件，这是一种简单高效的先验知识注入。
模型驱动选取(Model-driven Select) : 当可用信息源过多时(如海量工具或文档)，可以利用模型自身的能力进行筛选。
检索式选取(Retrieval-based Select) : 这是最主流的方式，其核心范式是通过相似度检索，从记忆、草稿纸或外部知识库中选取信息。因此，选取操作的成败，在很大程度上依赖于底层检索系统的质量。
压缩（Compress)
压缩的目的，是在信息进入上下文窗口之前，对其进行有损或无损的压缩，用更少的 Token 承载最核心的信号。这是在上下文窗口容量有限的情况下，容纳更多有效信息的直接手段。
如前文所述，Claude Code 等智能代理系统往往需要消耗大量 token 资源。当上下文窗口即将达到容量上限时，这些系统通常会启动"auto-compact"机制（如图左侧所示），自动对上下文内容进行摘要处理，仅保留"系统判定为最关键的信息"。
由此可见，自动压缩策略的效果将直接影响后续任务的处理质量。实际应用表明，Claude Code 的自动压缩功能尚不成熟，相比之下，采用最小化上下文重启的方式更为可靠。
参考 Section 2.2 中的图示说明。Cognition AI 采用经过专门调优的"上下文压缩大语言模型"来实现信息压缩，这种设计旨在优化智能体之间的信息传递效率。
另有修剪策略: 如硬截断超限历史，代价是失去部分语境。
隔离(lsolate)
与前三个聚焦于"信息流"内部优化的准则不同，隔离属于系统架构维度的、更具基础性的上下文管控方案。
隔离的核心价值，在于为多重信息流构筑防火墙，通过前置处理环节完成信息提纯，最终仅向上层传递精要内容。这种机制本质上实现了跨信息流的"压缩"效应。
Anthropic曾提出一个颇具启发性的论断："The essenceof search is compression: distilling insights from avast corpus"，中文可表述为："搜索的本质在于压缩，即从海量数据中淬炼真知"。这自然令人联想到Ilya提出的"智能即压缩"理论。
在分布式智能系统架构中，次级智能单元实际承担着"认知筛"的职能。它们通过领域隔离与并行计算，对原始数据进行深度处理，最终向主控单元传递经过高度提炼的核心认知要素（the mostimportant tokens）。
这种设计显著降低了主智能体(Lead Agent)的认知负荷。主智能体不必直接处理原始文档的庞杂内容，转而专注于接收各领域专家团队预处理后的精华信息——即结构化的"摘要报告"。
在上下文工程领域，这种隔离机制最典型的实现就是多智能体系统架构。
通过仅向Lead Agent传递经过筛选的关键上下文片段，不仅能有效规避长上下文可能引发的干扰和冲突问题，还提升了单位上下文的信息价值密度。Tool call技术以及沙盒机制的设计理念，同样遵循着这种隔离原则。
压缩 vs 隔离 的思考
压缩作用于单一信息流的内容，旨在提升其内在的信息密度。
隔离则作用在多条信息流上，旨在管理系统的复杂性，同时也能起到广义的压缩作用。
它们的目的，在我看来殊途同归，最终都是为了提升 Context 中的信息密度。一个成熟的系统，往往会同时运用这两种策略。
一个值得思考的问题: Prompt Engineering 在这个框架中的位置?
敏锐的观察者或许会注意到，虽然我们持续指出提示工程属于上下文工程的范畴，但前文提出的写、选、压、隔四项核心准则，确实没有直接涉及设计 System Prompt 这类提示工程的关键操作。
这种差异本质上源于分析维度的不同。我们所强调的四大实践方法论，其焦点在于处理持续变化的信息流（例如RAG检索结果、对话轮次记录）。
而由提示工程生成的引导性上下文（典型如System Prompt），在这个体系架构中，更多是被视作相对稳定的基础性参数——它会在信息筛选环节被纳入上下文框架，而非作为动态内容进行处理。
4. Conclusion
行文至此，我们已系统性地剖析了上下文工程的三大核心维度——"定义本质"、"价值所在"与"实施路径"。这绝非昙花一现的技术噱头，而是AI应用从实验性原型迈向工业化落地的过程中淬炼出的方法论体系。
我们的技术演进轨迹，正不可阻挡地从"寻找万能prompt的玄学探索"，转向"构建能动态生成最优上下文的鲁棒系统架构"。
从早期的"炼丹式调参"回归到严谨的工程实践，掌握写入策略、上下文筛选、信息压缩、边界隔离这四大核心能力，将成为区分"炫技型demo"与"可量产级应用"的分水岭。
特别值得关注的是MCP(Model Context Protocol)的价值。当我们深入理解上下文工程后，这个命名背后的深意便呼之欲出。
MCP本质上是工具与数据交互的标准化协议，致力于实现"行动性上下文"与"信息性上下文"的规范化交互，为Agent与外部资源的安全高效通信奠定基础。
从这个维度看，MCP堪称上下文工程的基础设施层，其标准化接口设计(不得不承认Anthropic在技术标准制定上的前瞻性)为整个系统工程提供了关键支撑。
绝大多数AI Agent的折戟沉沙，根源往往不在模型本身，而在于上下文工程的缺失。
无论是精妙的prompt设计，RAG技术，还是MCP协议，本质上都在解决同一个命题：在模型决策前为其构建最适配的上下文环境。期待通过本文，您能对Context Engineering获得更立体的认知。
这或许可视为Agent系统开发的"心法要诀"，受限于表达能力，本文仅能呈现这个复杂体系的冰山一角，更多实践细节有待各位同行指正探讨。
