# Context Engineering 深度拆解：Agent 时代真正的胜负手 > 来源：https://juejin.cn/post/7621878684524019775 > 作者：数据智能老司机 | 2026-03-29 | 阅读约 25 分钟 Context Engineering 深度拆解：Agent 时代真正的胜负手 [ 数据智能老司机 ](https://juejin.cn/user/430664289626439/posts) 2026-03-29 303 阅读25分钟 专栏： ChatGPT与大模型研究 Prompt Engineering 教你怎么问问题。Context Engineering 教你怎么给 AI 搭建整个"认知脚手架"。2025 年中期这个词突然火了，但它背后的工程挑战其实比大多数人想象的深得多——涉及注意力经济学、记忆架构设计、信息压缩理论、工具编排，以及一个至今没人完全解决的根本矛盾：上下文窗口是有限的，但 Agent 需要处理的信息是无限的。 ## 一、先讲清楚：Context Engineering 到底是个啥 2025 年 6 月，Shopify CEO Tobi Lütke 发了一条推："我真的很喜欢 'context engineering' 这个词，它比 prompt engineering 更好地描述了核心技能：为任务提供所有必要上下文的艺术，使其对 LLM 而言是可解的。" 几天后，Andrej Karpathy 跟了一条更有技术含量的推文，直接把这个概念推上了风口浪尖："在每一个工业级 LLM 应用中，context engineering 是一门精密的艺术和科学——往上下文窗口里填入恰好正确的信息，服务于下一步操作。" Karpathy 的定义揭示了一个关键洞察：**Context 不是一个字符串，而是一个系统的输出** 。 让我把这个概念拆得再细一点。当我们说"context"的时候，实际上在说什么？ - **System Prompt / Instructions** ：定义 Agent 行为的基础规则 - **User Prompt** ：用户当前的任务或问题 - **State / History（短期记忆）** ：当前对话的历史记录 - **Long-term Memory** ：跨会话的持久化记忆 - **Retrieved Knowledge（RAG）** ：从外部知识库实时检索的信息 - **Tool Definitions** ：可用工具的描述和调用规范 - **Tool Outputs** ：工具执行的返回结果 - **Environment Info** ：运行环境的元数据 - **Examples（Few-shot）** ：示例输入输出对 **Context Engineering 就是设计和构建一个动态系统，在正确的时间、以正确的格式、提供正确的信息和工具，让 LLM 拥有完成任务所需的一切。** 注意这里的关键词：**动态系统** 。它不是在写一个静态的 prompt 模板，而是在构建一个运行时的信息编排引擎。对于不同的请求，这个系统可能需要拉取日历数据、搜索邮件、查询数据库、检索文档——然后把这些异构信息整合成一个对 LLM 来说"刚好够用"的上下文包。 ## 二、为什么 Prompt Engineering 不够用了 很多人觉得 Context Engineering 就是"Prompt Engineering 的高级版"。这个理解不算错，但低估了两者之间的断层。 Prompt Engineering 关注的是**怎么问** ——措辞、格式、思维链、角色设定。它默认你已经有了所有需要的信息，问题只是怎么组织语言让 LLM 理解你的意图。 Context Engineering 关注的是**喂什么** ——在 LLM 推理之前，你的系统需要做大量工作来决定哪些信息应该出现在上下文里、以什么顺序、什么格式、什么粒度。 Karpathy 给了一个很好的类比：**把 LLM 想象成 CPU，上下文窗口就是 RAM** 。Prompt Engineering 是在写汇编指令，Context Engineering 是在设计整个内存管理系统——包括什么数据从磁盘加载到内存、什么时候换出、怎么压缩、怎么索引。 这个断层在 Agent 场景下尤其明显。一个简单的聊天机器人可能只需要好的 prompt。但一个能自主运行数小时、调用几十个工具、处理多文件编辑的编程 Agent，它的成败 **70% 取决于上下文质量，而不是模型能力** 。 Gao 等人在 2024 年的 RAG 综述中指出了一个反直觉的事实：现代 LLM 应用中超过 70% 的错误不是因为模型能力不足，而是因为上下文不完整、不相关或结构不良。换句话说，在 2026 年模型已经足够强的今天，**决定 AI 应用成败的瓶颈已经从"模型侧"转移到了"上下文侧"** 。 Hugging Face 的 Phil Schmid 说得更直白："大多数 Agent 的失败不是模型失败，而是上下文失败。" ## 三、上下文窗口的根本矛盾：注意力是稀缺资源 这是整个 Context Engineering 领域最核心的底层挑战，很多人知道它存在，但很少有人真正理解它有多棘手。 ### 3.1 上下文窗口越大 ≠ 越好用 2025-2026 年，上下文窗口经历了爆发式增长：Claude 支持 200K tokens，Gemini 3 Pro 达到 2M tokens，GPT-5.4 在 Codex 模式下支持 1M tokens，Llama 4 甚至声称支持 10M tokens。 直觉告诉我们：窗口越大，能塞进去的信息越多，效果应该越好。 但研究给出了残酷的现实： **Lost-in-the-Middle 效应** ：LLM 对上下文的注意力分布是不均匀的——对开头和结尾的信息关注度最高，中间的信息容易被"遗忘"。这不是某一个模型的 bug，而是 Transformer 注意力机制的结构性缺陷。 **注意力稀缺** ：每个 token 都在争夺有限的注意力资源。上下文越长，每个 token 平均分到的注意力越少。到了一定长度后，增加更多上下文实际上会**降低** 性能——信噪比下降了。 **延迟成本** ：输出 token 的生成延迟随输入 token 数量显著增加。超过 100K tokens 后，一些模型的延迟会大幅飙升，直接影响用户体验。 **经济成本** ：更长的上下文意味着更高的推理费用。对于大规模部署的应用，这不是可以忽略的开销。 Anthropic 在他们最新的 Context Engineering 文章中把这个问题提炼为一句话：**Context engineering 的本质是找到最小的、高信号的 token 集合，最大化期望结果的可能性。** 这是一个优化问题。而且是一个非常难的优化问题——因为你需要在"信息充分性"和"注意力效率"之间找到动态平衡，而这个平衡点会随着任务类型、对话长度、工具调用次数的变化而变化。 ### 3.2 不只是"中间丢失"——更深层的失败模式 Weaviate 的技术博客总结了长上下文场景下的几种致命失败模式： **Context Poisoning（上下文中毒）** ：错误或幻觉信息进入上下文后，Agent 会在此基础上继续推理，错误像滚雪球一样积累和放大。 **Context Distraction（上下文分心）** ：过多的历史信息让 Agent 过度依赖过去的行为模式，而不是针对当前问题进行新鲜推理。就像一个人背负了太多过往经验，反而无法看清眼前的新问题。 **Context Confusion（上下文混淆）** ：多个来源的信息在上下文中产生矛盾——比如 RAG 检索到的文档和系统 prompt 的指令冲突——导致 Agent 行为不可预测。 **Context Staleness（上下文过时）** ：对话越长，早期的信息越可能已经过时。但这些过时信息仍然占据着宝贵的上下文空间，而且模型没有内置的"过期检测"机制。 这些失败模式不是理论上的。任何做过生产级 Agent 的人都会在第一周内遇到其中的至少两种。 ## 四、六大核心工程策略：生产级 Agent 怎么管理上下文 面对这些挑战，社区和工业界已经发展出了一套成熟的策略。我把它们分成六个层次，从最基础到最高级。 ### 4.1 渐进式披露（Progressive Disclosure） 核心思想：不要一次性把所有信息塞进上下文，而是按需加载。 **静态渐进式披露** ：通过配置文件预定义什么信息在什么阶段加载。比如 Codex 的 Skills 系统——Agent 启动时只加载每个 Skill 的元数据（名称和描述），只有当它判断需要使用某个 Skill 时才读取完整内容。Claude Code 的 `@` 引用也是类似思路。 **动态渐进式披露** ：让 LLM 自己决定什么时候加载更多上下文。比如给 Agent 提供"搜索代码库"和"读取文件"的工具，让它根据当前任务自行决定需要查看哪些文件。这是让 Agent 自主运行的前提。 一个重要的权衡：让 LLM 决定何时加载上下文提高了自动化程度，但引入了不确定性——你无法保证它会在你期望的时机去加载关键信息。Martin Fowler 网站上 Thoughtworks 的一篇文章把这称为 Context Engineering 的一个基本张力：**控制 vs 自主** 。 ### 4.2 上下文压缩（Context Compression） 当对话变长、工具调用积累，上下文最终会逼近窗口极限。这时候需要压缩。 **滑动窗口 + 摘要** ：保持最近 N 轮对话完整不动，对更早的历史用 LLM 做摘要压缩。这是目前社区公认最实用的基线方案。 来自生产实践的两个关键细节（源自 Manus 平台的分享）： 1. **保留最近的工具调用原始格式** 。压缩掉工具调用的细节后，模型会丧失"节奏感"——它不知道之前的工具调用是什么格式、什么模式，导致后续的工具调用出现微妙的退化。 2. **永远不要压缩掉错误 trace** 。当工具调用失败时，保留完整的错误信息和堆栈跟踪，帮助模型避免重蹈覆辙。这个技巧在 Instructor 等库中已经是标准做法。 压缩的根本困难是：**任何压缩都是有损的** 。你在节省 token 的同时必然丢失了一些细节。什么信息可以丢、什么必须保留？这个判断本身就需要"理解"——而做判断的又是一个 LLM。这是一个递归的难题。 ### 4.3 路由（Routing） 一个多领域 Agent 可能连接了多个知识库、多个工具集、多组指令。如果每次查询都加载所有这些，上下文会迅速膨胀。 路由的思路是：先判断当前查询属于哪个领域，只加载相关的上下文。 最简单的做法是基于关键词的规则匹配——成本几乎为零，但能显著减少上下文膨胀。更复杂的做法是用一个轻量级 LLM 做意图分类，然后路由到对应的专家 Agent 或知识库。 ### 4.4 检索增强（Evolved Retrieval） RAG 是 Context Engineering 中最成熟的技术之一，但 2025-2026 年的 RAG 已经远超"embedding + 向量搜索"的基础形态。 **Agentic RAG** ：Agent 自己决定什么时候需要检索、检索什么、对检索结果做什么。它可能先搜索一轮，评估结果，发现信息不足，然后换个关键词再搜一轮。这种"带反思的检索"在复杂任务上比一次性检索效果好得多。 **Graph RAG** ：结合知识图谱和向量搜索，不只是找到相关文档，还能沿着实体关系进行推理。比如"这个 API 的调用者有哪些？那些调用者又被谁依赖？"——这种多跳推理纯向量搜索做不到。 **Reranking** ：检索出候选文档后，用专门的排序模型（而不是原始的 embedding 相似度）重新排列，把真正相关的推到前面。结合"Position Engineering"——把最关键的信息放在上下文的开头或结尾——可以显著改善 Lost-in-the-Middle 问题。 ### 4.5 工具管理（Tool Management） 工具定义本身就消耗大量 token。一个连接了 20 个 MCP Server 的 Agent，光是工具 schema 就可能吃掉几千甚至上万 token——在用户说第一句话之前。 Anthropic 的文章专门提到了这个被忽视的问题：**工具集膨胀是最常见的失败模式之一** 。太多功能重叠的工具会导致模型在选择工具时犹豫不决；工具描述如果写得不清晰，模型会传入错误的参数。 最佳实践：工具应该像设计良好的代码库中的函数一样——**自包含、对错误鲁棒、用途明确** 。输入参数应该描述清晰、无歧义。如果一个人类工程师看了工具描述后都不确定该用哪个工具，那模型更不行。 ### 4.6 记忆架构（Memory Architecture） 这是 Context Engineering 中最前沿、也最没有定论的领域。 参考认知科学，社区正在收敛到一个三层记忆模型： **Working Memory（工作记忆）** ：就是当前的上下文窗口。包含当前对话的所有消息、检索到的知识片段、工具调用结果。Token 预算最贵，但精度最高。核心挑战：在有限预算内决定保留什么、压缩什么、丢弃什么。 **Episodic Memory（情景记忆）** ：存储过去交互的"经验"——之前对话的摘要、用户问过的问题、系统犯过的错误和纠正。跨会话持久化，用于避免重复错误和个性化响应。 **Semantic Memory（语义记忆）** ：结构化的知识库——事实、关系、规则。通常由向量数据库或知识图谱承载。这是最"传统"的外部知识存储。 2025 年底 Stanford 的 Generative Agents 研究展示了这个方向的可行性。2026 年，层次化记忆架构成为一个主要研究焦点——通过分层的短期、工作、长期记忆系统，使模型能在扩展交互中处理和记住大量信息。 ## 五、前沿研究：四个让人兴奋的方向 ### 5.1 Agentic Context Engineering（ACE）——让上下文自我进化 这是 2025 年 10 月一篇来自 arXiv 的重要论文提出的框架。核心思想很有意思：**把上下文视为一个不断进化的"剧本"（playbook），通过生成、反思、策展的模块化流程来积累、精炼和组织策略。** 传统做法是人类手写 system prompt，然后祈祷它对所有场景都好用。ACE 的做法是让 Agent 自己根据任务表现来更新自己的 prompt。表现好的策略被保留和强化，表现差的被淘汰。 ACE 解决了两个老大难问题： - **Brevity Bias（简洁偏差）** ：传统的上下文优化倾向于生成越来越简短的摘要，丢失了领域特定的关键细节 - **Context Collapse（上下文坍缩）** ：迭代式的上下文重写会逐渐侵蚀细节，最终变成一堆没有营养的泛化语句 北京大学智能信息科学国家重点实验室 2026 年的后续工作（Meta Context Engineering via Agentic Skill Evolution）进一步推进了这个方向，探索如何让 Agent 的 Skill 也能动态进化。 ### 5.2 GAM：对抗"上下文腐烂"的双 Agent 记忆架构 VentureBeat 在 2025 年底报道了一个叫 GAM（Generative Agent Memory）的架构，它的核心洞察很深刻：**不要试图在存储时就决定什么重要，而是在检索时按需"编译"上下文。** GAM 用了一个类比：**Just-in-Time（JIT）编译** 。它维护一个完整的、无损的原始历史存档，加上一层轻量级的索引线索。当需要回忆时，一个"研究员" Agent 会执行分层搜索——混合向量检索、关键词匹配和直接查找——直到收集到足够的证据才停止。 传统的压缩方法（摘要、滑动窗口）本质上是**预编译** ——提前决定了什么重要什么不重要。但任务是动态的，今天不重要的信息明天可能变得关键。GAM 的 JIT 方法避免了这种"过早优化"的陷阱。 ### 5.3 上下文压缩的新范式：从有损到"选择性无损" 2026 年最新的研究（比如 OpenReview 上的 SAC 论文）正在探索一种新思路：不再用随机初始化的"压缩 token"来表示上下文，而是从原始文本中**选择代表性 token** 作为"锚点"，然后用双向注意力（而非传统的因果注意力）来让这些锚点聚合整个上下文的信息。 这种方法的优势是锚点本身携带了语义先验——它们不是无中生有的向量，而是原文中的真实 token——这减少了压缩导致的语义失真。在实验中，这种方法实现了超过 3000 倍的压缩比，同时保持了约 92% 的事实准确率。 不过必须诚实说，这类研究距离生产落地还有距离。但它代表了一个重要的研究方向：**能不能找到一种压缩方式，在极端压缩比下仍然保持关键信息的无损性？** ### 5.4 MCP 的标准化：上下文的"USB 接口" Model Context Protocol（MCP）正在成为 AI Agent 连接外部工具和数据源的通用标准。Anthropic 在 2025 年底将 MCP 捐赠给了 Linux Foundation 旗下的 Agentic AI Foundation，联合发起方包括 OpenAI、Google、Microsoft、AWS、Block 等。 截至 2026 年，MCP SDK 的月下载量超过 9700 万次，有 75+ 个官方连接器。2025 年 11 月的规范更新引入了异步操作、无状态模式和服务器身份验证。 从 Context Engineering 的角度，MCP 解决的是**工具上下文的标准化** 问题。没有 MCP 之前，每个工具都有自己的 API 格式，Agent 需要为每种工具编写定制的集成代码。有了 MCP，工具的描述、调用方式、返回格式都被标准化了，大大降低了工具上下文的工程复杂度。 但 MCP 也带来了新的 Context Engineering 挑战：当一个 Agent 连接了几十个 MCP Server 时，光是工具 schema 就可能消耗大量 token。如何做到"按需发现"而不是"全量加载"，是正在被积极解决的问题。 ## 六、编程 Agent 中的 Context Engineering 实战 编程 Agent 是 Context Engineering 最密集的应用场景之一——代码库巨大、文件间关系复杂、需要理解项目规范和历史变更。 ### 6.1 Anthropic 的实践：指令 vs 指导 vs 上下文接口 Thoughtworks 的 Birgitta 在 Martin Fowler 网站上发了一篇很有启发的文章，把编程 Agent 的上下文分成了三类： **Instructions（指令）** ：告诉 Agent 做什么。比如"按以下方式编写 E2E 测试：..." **Guidance（指导/规则）** ：Agent 应遵循的通用约定。比如"测试之间必须相互独立。" **Context Interfaces（上下文接口）** ：描述 Agent 如何获取更多上下文的方式。最基础的是文件读取和代码搜索——让 Agent 能自主探索代码库。 她还指出了一个被低估的问题：**你的代码库本身就是上下文** 。代码的可读性、注释质量、目录结构的清晰度——这些"人类可读性"的传统关切，在 AI 时代有了新的含义。一个 AI-friendly 的代码库设计，本身就是一种 Context Engineering。 ### 6.2 AGENTS.md 的局限性 Faros AI 的经验值得深思。他们在大量仓库中投入了精力编写详尽的 AGENTS.md 文件——架构模式、编码规范、常见陷阱、最佳实践——本质上就是一份"面向 AI 的开发者入职手册"。 结果呢？**效果一般** 。他们发现： 1. **Agent 的变异性比 rules 文件的优化更重要** 。同一个 Agent，用完全相同的上下文，运行两次产生的结果可能截然不同。 2. **通用规则的效果很弱** 。"遵循 DRY 原则"在理论上有帮助，但无法阻止每个代码库特有的反模式。 3. **上下文质量 > 上下文数量** 。一份 500 行的 AGENTS.md 不一定比一份精炼的 50 行版本更有效。 这再次印证了 Anthropic 的核心观点：**保持上下文信息充分但紧凑** 。不是写得越多越好。 ### 6.3 编程 Agent 的"三层上下文加载"策略 综合各家实践，编程 Agent 的上下文加载通常分三层： 1. **Always-on（始终加载）** ：系统 prompt + AGENTS.md/CLAUDE.md 核心规则 + 项目结构概览。这些信息每次推理都在，不需要触发条件。 2. **Triggered（触发式加载）** ：按路径匹配的规则（比如只在编辑 .ts 文件时加载 TypeScript 规范）、按任务类型加载的 Skill、按文件引用加载的上下文。 3. **On-demand（按需加载）** ：Agent 通过工具调用自主检索——grep 搜索、文件读取、git log 查询、文档搜索。这是最灵活但也最不确定的层次。 关键洞察：**第一层要足够小，第三层要足够强** 。always-on 的内容越精简，留给按需检索的 token 预算越多，Agent 的灵活性越强。 ## 七、尚未解决的难题：老实说，我们还差得远 Context Engineering 领域有很多令人兴奋的进展，但更多的是尚未解决的根本性难题。作为一个在这个领域摸爬滚打过的人，我觉得有必要把这些挑战摊开来说。 ### 7.1 可评估性问题 怎么衡量一个上下文设计的好坏？这比听起来要难得多。 传统的 Needle-in-a-Haystack 测试太简单了——它只测试简单的词汇检索，不代表生产场景需要的复杂推理和语义理解。 SwirlAI 的 newsletter 提到了一种"probe-based evaluation"方法：在上下文中嵌入探针问题，检查 Agent 是否能回忆出被压缩或被检索的信息。但这也只是测量了"信息保留"，没有测量"信息利用"——模型可能记住了信息但在推理时没有用到。 目前这个领域缺乏一个公认的、端到端的评测标准。这严重制约了 Context Engineering 从"art"走向"science"。 ### 7.2 上下文 Debug 的可观测性 当 Agent 产生了错误输出，你怎么判断是模型的问题还是上下文的问题？ 目前大多数 Agent 框架的可观测性工具都很原始。你能看到完整的 prompt 和 response，但很难追踪"为什么检索到了这段文档而不是那段"、"为什么工具 A 被选中而不是工具 B"、"压缩过程丢失了哪些关键信息"。 社区里有人提出了一个雄心勃勃的构想：`codex proxy start --record .codex/logs`——一个透明的中间人代理，记录结构化的 JSONL 日志，包含时间戳、session、agent、prompt、工具调用、延迟、token 消耗等。这个方向很正确，但离标准化还很远。 ### 7.3 多 Agent 的上下文隔离与共享 当多个 Agent 协作时，它们之间如何共享上下文？太少的共享导致信息孤岛，太多的共享导致上下文膨胀和隐私风险。 目前大多数多 Agent 系统（包括 OpenAI 的 Agents SDK 和 Anthropic 的 Agent Teams）采用的是"文件交接"模式——Agent A 把产出写入文件，Agent B 从文件读取。这简单但粗暴。 理想的方案应该是一种**分层的上下文权限模型** ——类似操作系统的进程间通信和内存保护。某些上下文信息是"全局可见"的（项目规范），某些是"组内可见"的（当前任务的状态），某些是"私有"的（单个 Agent 的推理中间状态）。 ### 7.4 上下文的因果性问题 当 Agent 基于检索到的信息做出决策，如果检索结果是错误的或过时的怎么办？ 更深层的问题是：**Agent 能不能区分"我知道的"和"我被告知的"？** 目前的 LLM 不擅长这个。它们倾向于把上下文中的所有信息当作事实来处理，即使那些信息是 RAG 从一份三年前的文档中检索出来的。 这不是一个小问题。在生产环境中，上下文中毒（context poisoning）是最难调试的故障之一——错误信息进入上下文后，会被后续的推理步骤反复引用和放大，而你看到的错误表象可能已经距离根因十几步之远。 ### 7.5 个性化 vs 泛化的张力 如果一个 Agent 记住了用户 A 的偏好并据此做出推理，当用户 B 使用同一个 Agent 时，那些个性化记忆可能变成噪声。 更微妙的情况是：同一个用户在不同项目、不同角色下可能有不同的偏好。一个在 Python 项目中"永远用 type hints"的规则，在一个快速原型项目中可能是过度约束。 **上下文的个性化粒度应该是什么？用户级？项目级？任务级？会话级？** 目前没有标准答案。 ## 八、未来的方向：Context Engineering 会走向哪里 ### 8.1 从"被动填充"到"主动探索" 当前大多数 Context Engineering 系统是"被动"的——基于预定义的规则和触发条件来组装上下文。未来的方向是让 Agent **主动** 管理自己的上下文——它知道自己不知道什么，知道应该去找什么，知道什么时候需要压缩、什么时候需要扩展。 Anthropic 的文章暗示了这个方向："随着底层模型变得更强，Agent 的自主程度可以提升——更聪明的模型允许 Agent 独立导航复杂的问题空间并从错误中恢复。" ### 8.2 "认知工作区"模型 受认知科学启发的"Cognitive Workspace"概念正在被严肃对待。这个模型建议未来的 LLM 系统可能有离散的"记忆模块"，类似于人类的短期记忆、工作记忆和长期记忆。 不是简单地在外面加一层 RAG 或 vector store，而是**在模型架构内部** 实现多层记忆。这需要模型训练范式的根本性变化——从"固定上下文窗口 + 外部检索"到"内建层次化记忆 + 自主记忆管理"。 ### 8.3 上下文的可组合性 未来的 Context Engineering 系统可能会像 Unix 管道一样可组合——不同的上下文处理器（压缩器、过滤器、排序器、格式化器）可以自由组合，形成针对特定任务优化的上下文管道。 LangChain/LangGraph 已经在朝这个方向走——将上下文流视为代码，prompt、工具、记忆通过编程式的链组合。但目前的抽象层次还不够高，组合性还不够好。 ### 8.4 多模态上下文 当 Agent 需要同时处理文本、图像、音频、视频时，上下文管理的复杂度又上了一个台阶。一张截图可能包含了相当于 1000 个文本 token 的信息，但在上下文窗口中的"注意力权重"如何分配？多模态信息之间的"相关性"如何计算？ 这些问题目前基本上是 open problems。 ### 8.5 形式化理论 最令人兴奋的研究方向之一是尝试为 Context Engineering 建立形式化的数学框架。比如用"Directed Information γ-covering"来描述最优上下文选择——给定一个任务和一个上下文空间，什么是数学上最优的上下文子集？ 这类理论工作目前还很早期，但如果成功，它可以把 Context Engineering 从"经验驱动的调优"推向"理论指导的设计"——就像编译器优化从启发式发展为形式化验证一样。 ## 九、写在最后：真正的 10x 不在模型，在上下文 回顾这篇文章讨论的所有内容，我想用一个最核心的判断作为结尾： **在 2026 年，模型能力已经不再是瓶颈。上下文质量才是。** 这不是我一个人的观点。Anthropic 说"most agent failures are context failures"。Karpathy 说 context engineering 是"一门精密的艺术和科学"。Faros 的实战数据显示 agent 变异性比 rules 优化更重要。所有这些观察都指向同一个结论：**我们已经进入了一个"模型很强但应用很脆"的时代，而 Context Engineering 是弥合这个鸿沟的关键学科。** 对于正在做 Agent 开发的同学，我的建议是： 1. **停止执着于 prompt 的措辞** 。把精力放在设计上下文的"供给系统"上——什么信息、什么时候、什么格式、什么优先级。 2. **投资可观测性** 。你无法优化你不能观测的东西。记录每次推理的完整上下文、token 消耗、决策路径。 3. **从 Lost-in-the-Middle 开始优化** 。最简单的改进往往是最有效的：把关键信息放在上下文的开头和结尾。 4. **拥抱 MCP** 。工具上下文的标准化是大势所趋。 5. **建立三层记忆架构** 。即使是最简陋的版本——working memory（上下文窗口）+ episodic memory（对话摘要存储）+ semantic memory（文档向量库）——都比"把所有东西塞进 prompt"好一个量级。 Context Engineering 还是一个年轻的学科，很多基础问题还没有定论。但正因如此，这是一个充满机会的领域——理论和实践之间的鸿沟，正等着有能力的工程师来填补。 **参考资源** ：Anthropic "Effective context engineering for AI agents"、Andrej Karpathy 的 X 帖文和 2025 Year in Review、Martin Fowler 网站 "Context Engineering for Coding Agents"、Weaviate "Context Engineering - LLM Memory and Retrieval"、ACE 论文 (arXiv:2510.04618)、SwirlAI "State of Context Engineering in 2026"、Phil Schmid "The New Skill in AI"、Faros AI "Context Engineering for Developers"、VentureBeat GAM 报道等。 本文写于 2026 年 3 月。Context Engineering 是一个快速演进的领域，具体技术细节请以最新资料为准。 标签： [Agent](https://juejin.cn/tag/Agent) 话题： [日新计划](https://juejin.cn/theme/detail/7148258259923959846?contentType=1) 本文收录于以下专栏 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c8ab8ca8bb794e828cf991d272bafb2a~tplv-k3u1fbpfcp-jj:80:60:0:0:q75.avis) ChatGPT与大模型研究 专栏目录 生成式AI探索和研究，场景落地。 152 订阅 · 910 篇文章 上一篇 我用了半年 OpenAI Codex，来聊聊这玩意到底行不行 下一篇 AI 营销，究竟改变了什么？——一篇讲透 AI Marketing 的深度研究 评论 0 暂无评论数据 ![](https://p26-passport.byteacctimg.com/img/user-avatar/be4a61ff451931bd1940ef22138c7010~100x100.awebp) [ 数据智能老司机 ![9bc2c24c7f0e89a6-06379888b89b6ddd](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8584543d8535435a9d74c1fbf7901ac7~tplv-k3u1fbpfcp-jj:0:0:0:0:q75.avis) ](https://juejin.cn/user/430664289626439/posts) [ 架构师 ](https://juejin.cn/user/430664289626439/posts) [榜上有名](https://juejin.cn/user/430664289626439/posts) [优秀作者](https://juejin.cn/user/430664289626439/posts) [ 1.8k ](https://juejin.cn/user/430664289626439/posts) [文章](https://juejin.cn/user/430664289626439/posts) [ 1.0m ](https://juejin.cn/user/430664289626439/posts) [阅读](https://juejin.cn/user/430664289626439/posts) [ 1.2k ](https://juejin.cn/user/430664289626439/followers) [粉丝](https://juejin.cn/user/430664289626439/followers) 目录 - [ 一、先讲清楚：Context Engineering 到底是个啥 ](https://juejin.cn/post/7621878684524019775#heading-0) - [ 二、为什么 Prompt Engineering 不够用了 ](https://juejin.cn/post/7621878684524019775#heading-1) - [ 三、上下文窗口的根本矛盾：注意力是稀缺资源 ](https://juejin.cn/post/7621878684524019775#heading-2) - [ 3.1 上下文窗口越大 ≠ 越好用 ](https://juejin.cn/post/7621878684524019775#heading-3) - [ 3.2 不只是"中间丢失"——更深层的失败模式 ](https://juejin.cn/post/7621878684524019775#heading-4) - [ 四、六大核心工程策略：生产级 Agent 怎么管理上下文 ](https://juejin.cn/post/7621878684524019775#heading-5) - [ 4.1 渐进式披露（Progressive Disclosure） ](https://juejin.cn/post/7621878684524019775#heading-6) - [ 4.2 上下文压缩（Context Compression） ](https://juejin.cn/post/7621878684524019775#heading-7) - [ 4.3 路由（Routing） ](https://juejin.cn/post/7621878684524019775#heading-8) - [ 4.4 检索增强（Evolved Retrieval） ](https://juejin.cn/post/7621878684524019775#heading-9) - [ 4.5 工具管理（Tool Management） ](https://juejin.cn/post/7621878684524019775#heading-10) - [ 4.6 记忆架构（Memory Architecture） ](https://juejin.cn/post/7621878684524019775#heading-11) - [ 五、前沿研究：四个让人兴奋的方向 ](https://juejin.cn/post/7621878684524019775#heading-12) - [ 5.1 Agentic Context Engineering（ACE）——让上下文自我进化 ](https://juejin.cn/post/7621878684524019775#heading-13) - [ 5.2 GAM：对抗"上下文腐烂"的双 Agent 记忆架构 ](https://juejin.cn/post/7621878684524019775#heading-14) - [ 5.3 上下文压缩的新范式：从有损到"选择性无损" ](https://juejin.cn/post/7621878684524019775#heading-15) - [ 5.4 MCP 的标准化：上下文的"USB 接口" ](https://juejin.cn/post/7621878684524019775#heading-16) - [ 六、编程 Agent 中的 Context Engineering 实战 ](https://juejin.cn/post/7621878684524019775#heading-17) - [ 6.1 Anthropic 的实践：指令 vs 指导 vs 上下文接口 ](https://juejin.cn/post/7621878684524019775#heading-18) - [ 6.2 AGENTS.md 的局限性 ](https://juejin.cn/post/7621878684524019775#heading-19) - [ 6.3 编程 Agent 的"三层上下文加载"策略 ](https://juejin.cn/post/7621878684524019775#heading-20) - [ 七、尚未解决的难题：老实说，我们还差得远 ](https://juejin.cn/post/7621878684524019775#heading-21) - [ 7.1 可评估性问题 ](https://juejin.cn/post/7621878684524019775#heading-22) - [ 7.2 上下文 Debug 的可观测性 ](https://juejin.cn/post/7621878684524019775#heading-23) - [ 7.3 多 Agent 的上下文隔离与共享 ](https://juejin.cn/post/7621878684524019775#heading-24) - [ 7.4 上下文的因果性问题 ](https://juejin.cn/post/7621878684524019775#heading-25) - [ 7.5 个性化 vs 泛化的张力 ](https://juejin.cn/post/7621878684524019775#heading-26) - [ 八、未来的方向：Context Engineering 会走向哪里 ](https://juejin.cn/post/7621878684524019775#heading-27) - [ 8.1 从"被动填充"到"主动探索" ](https://juejin.cn/post/7621878684524019775#heading-28) - [ 8.2 "认知工作区"模型 ](https://juejin.cn/post/7621878684524019775#heading-29) - [ 8.3 上下文的可组合性 ](https://juejin.cn/post/7621878684524019775#heading-30) - [ 8.4 多模态上下文 ](https://juejin.cn/post/7621878684524019775#heading-31) - [ 8.5 形式化理论 ](https://juejin.cn/post/7621878684524019775#heading-32) - [ 九、写在最后：真正的 10x 不在模型，在上下文 ](https://juejin.cn/post/7621878684524019775#heading-33) [94阅读](https://juejin.cn/post/7598503855597240339) [ · ](https://juejin.cn/post/7598503855597240339) [0点赞](https://juejin.cn/post/7598503855597240339) [235阅读](https://juejin.cn/post/7625823536133718016) [ · ](https://juejin.cn/post/7625823536133718016) [0点赞](https://juejin.cn/post/7625823536133718016) [3.4k阅读](https://juejin.cn/post/7617781226363256866) [ · ](https://juejin.cn/post/7617781226363256866) [8点赞](https://juejin.cn/post/7617781226363256866) [3.7k阅读](https://juejin.cn/post/7617728986828177435) [ · ](https://juejin.cn/post/7617728986828177435) [14点赞](https://juejin.cn/post/7617728986828177435) ----------------