高质量「上下文工程」资源整理（含速览和精读）

上下文工程（Context Engineering）现在有多火，就不用多说了吧。

Karpathy 说「Software is changing (again)」，“again” 的下一个注脚，大概率就是 Context Engineering。

今天，给大家整理了上下文工程几个优质资源，通过这波“投喂”，希望能帮助大家在 Agent 构建的实践中，对模型上下文工程有更深层次、更体系化的理解。

速览版

1.《The New Skill in Al is Not Prompting, lt's Context Engineering》

来自谷歌 DeepMind 高级人工智能关系工程师 Philipp Schmid ，偏概念介绍，提出“六层上下文”模型（指令、历史、长记忆、RAG、工具、输出格式），业内首次系统定义 CE（Context Engineering），属于入门级资料，适合开发者快速建立术语与框架。

2. 《Context Engineering for Agents》

来自 LangChain 的联合创始人兼 CEO Harrison Chase ，偏实践，主要 Agent 构建的方法论，结合 LangChain 生态，给出可落地的流程与代码，和 langchain 工具链深度绑定。

3. 《How Contexts Fail—and How to Fix Them》

来自独立研究者 Drew Breunig ，是一篇典型的反面教材 + 对策清单，帮你避免“长上下文 ≠ 高质量”误区。总结 agent 的四大死法：Poisoning / Distraction / Confusion / Clash ，并给出解决思路。

4.《A Survey of Context Engineering》

这篇 160 多页的长综述是当下最全面、最新、并且极具指导价值的参考文献之一，帮助你建立一个宏观的知识框架，适合研究者快速梳理全景与定位未来方向。

5.《Context Engineering: The Outer Loop》

来自 Chroma CTO Hammad Bashir ，是一个 YouTube 视频，30 min 演示如何用向量数据库做外循环动态上下文。

6.《AI 代理的上下文工程：构建 Manus 的经验教训》

来自 Manus 联合创始人季逸超，偏企业实战经验，介绍构建 Manus 的经验教训，包括 KV-cache 命中率、工具遮蔽等工程坑点。

7.《Practical tips on building LLM agents》

来自 Lossfunk 创始人 Paras Chopra，经验分享贴，CE 贯穿始终，附真实指标与成本考量，适合产品经理 / 创业者 12 条一线 Agent 落地心得。

8. GitHub Repo ：Context-Engineering

来自独立开发者 davidkimai ，该仓库已获得 4.1 k stars ，被广泛社区认可，内部组织逻辑清晰，内容包括基础学习路径、可操作模板、进阶示例、上下文协议和代理系统等模块。

详细版

一、The New Skill in Al is Not Prompting, lt's Context Engineering

这篇博客由 DeepMind 高级人工智能关系工程师 Philipp Schmid 撰写，内容偏重概念解析，主要阐述了上下文、上下文工程与提示词工程之间的区别。

原文链接：https://www.philschmid.de/context-engineering

1. 到底什么是“上下文”？首先，我们需要扩展对“上下文”的理解。它远不止是发送给 LLM 的单次提示，而是模型在生成响应前所能感知到的一切信息总和。

一个丰富的上下文通常包括：

• 指令 / 系统提示 (Instructions / System Prompts): 定义模型行为的基础规则、角色设定和示例。
• 用户提示 (User Prompt): 用户当前直接提出的问题或任务。
• 状态 / 历史记录 (State / History): 当前对话的完整记录，即短期记忆。
• 长期记忆 (Long-term Memory): 跨越多次对话沉淀下来的持久化知识，如用户偏好、过往项目摘要等。
• 检索的信息 (Retrieved Information / RAG): 从外部文档、数据库或 API 中动态获取的、与当前任务相关的最新知识。
• 可用的工具 (Available Tools): 模型可以调用的所有函数或 API 的定义，如查询日历、发送邮件。
• 结构化输出 (Structured Output): 对模型响应格式的强制要求，例如必须返回一个特定的 JSON 对象。

2. 为何它如此重要？

文中举了这样的一个例子：

当你的 AI 智能体收到一封邮件：

嘿，想和您确认明天是否有时间讨论一下。

如果你的智能体上下文贫乏，那它的回应可能死板又无用：

感谢您的消息。明天对我来说可以。请问您有什么具体的时间安排吗？”

而上下文丰富的智能体则会先收集和构建一个丰富的上下文，包括：

• 你的日历信息 (显示你明天已排满)。
• 你与此人的过往邮件 (判断出应该使用非正式的语气)。
• 你的联系人列表 (识别出对方是一位重要合作伙伴)。
• 可用的工具，如 发送会议邀请。

将这些详细、全面的上下文打包提供给大模型后，才能能生成一个真正有帮助的回应：

“嘿吉姆！我这边明天日程完全满了。你看周四上午方便吗？我已经发了一个邀请，如果时间可以的话告诉我一声。”

不需要更智能的模型或更巧妙的算法就为任务提供了更合适的上下文。

二、Context Engineering for Agents

这篇博客更偏实践性，自于 LangChain 工程师 Martin Lance，主要讲了上下文工程的的四种落地策略。

原文链接：https://blog.langchain.com/context-engineering-for-agents/

作者将上下文工程定义为是一门关于如何在智能体运行的每一步，精准地向其有限的“内存”（即上下文窗口）中填充恰当信息的艺术与科学。

这个观点和安德烈·卡帕西（Andrej Karpathy）的观点是基本一致的：

如果大语言模型（LLM）是计算机的 CPU，那么上下文窗口就是它的 RAM。RAM 的容量有限，需要操作系统来智能地管理数据。

同样，上下文工程就是智能体的“操作系统”，管理和优化输入给模型的信息。

作者发现低效的上下文管理会导致一系列问题：

• 上下文中毒（Context Poisoning）： 错误的幻觉信息污染了上下文。
• 上下文干扰（Context Distraction）： 无关信息过多，淹没了核心指令。
• 上下文混淆（Context Confusion）： 多余的信息影响了最终输出的准确性。
• 上下文冲突（Context Clash）： 上下文中的不同部分存在矛盾。

为了应对这些挑战，业界目前有四种主流的上下文工程策略：写入、选择、压缩和隔离。

1. 写入：将信息保存到上下文窗口之外，以备后续使用。这就像人类在解决复杂问题时记笔记一样，帮助智能体“记住”关键信息，避免因上下文窗口限制而遗忘。

• 草稿板 (Scratchpads): 用于短期记忆。智能体可以在执行任务时，将中间步骤的思考、计划或关键数据“写入”一个临时的草稿板。例如，先思考并制定一个详细计划，然后将其保存起来，即使后续对话很长导致早期上下文被截断，这个核心计划依然存在。
• 记忆 (Memories): 用于长期记忆，可以跨越多个会话。智能体通过与用户的交互，自动学习并生成长期记忆（如用户偏好、特定指令等）。像 ChatGPT、Cursor 等产品都内置了类似机制，让智能体在未来的交互中能“记起”过去的信息。

2. 选择上下文 ：在需要时，将最相关的信息“拉入”上下文窗口。拥有海量的记忆还不够，关键在于精准地选择。

• 从记忆中选择: 当智能体需要执行任务时，它需要从大量的记忆库中检索出最相关的内容。这可能包括：用于指导行为的指令（程序性记忆），用于模仿的案例（情景记忆），或用于提供背景的事实（语义记忆）。
• 从工具中选择: 不将所有工具的描述都塞给模型，而是利用 RAG 技术，根据当前任务动态地选择最相关的几个工具。研究表明，这能将工具选择的准确率提升高达三倍。
• 从知识中选择 : 在代码生成等复杂场景中，简单的嵌入搜索已不足以应对。先进的系统会结合抽象语法树（AST）分析、知识图谱检索、grep/文件搜索以及重排（Re-ranking）等多种技术，来确保为智能体提供最精准的代码片段作为上下文。

3. 压缩上下文 ：提炼信息，只保留执行任务所必需的令牌（Tokens）。当交互轮次过多或工具返回内容过长时，压缩上下文就显得至关重要。

• 上下文摘要: 利用模型自身的能力，对长对话历史或冗长的工具输出进行总结。

例如，Claude Code 在上下文窗口使用率超过 95% 时会自动运行“压缩”功能。摘要也可以应用在特定节点，比如对一个返回大量文本的搜索工具进行后处理，或在多智能体协作的交接点上进行信息提炼。

• 上下文修剪: 一种更直接的过滤方法。通常采用硬编码的规则，例如简单地“移除对话列表中最旧的消息”，或者使用经过训练的专门模型来“修剪”掉不相关的部分。

4. 隔离上下文：将复杂的任务分解，让不同的上下文在隔离的环境中发挥作用。通常有两种隔离方式：

• 多智能体：将一个大任务分解成多个子任务，分配给一个由多个子智能体组成的“团队”。每个子智能体都有自己独立的、更小的上下文窗口，专注于处理特定的任务。Anthropic 的研究表明，这种架构的性能往往优于单个庞大的智能体，因为它允许并行探索和更专注的处理，但是这也带来了更高的令牌消耗和团队协调的挑战。
• 沙盒环境: 智能体（特别是代码智能体）不直接处理复杂的工具调用，而是生成一段代码，这段代码在一个隔离的“沙盒”中运行。只有代码执行后的关键结果（如返回值）才会被传递回模型的上下文。这种方式特别适合处理和隔离那些令牌消耗巨大的对象（如图片、音频文件等）。

三、How Long Contexts Fail

这篇文章主要提出了上下文管理中的一些问题，并且将问题凝练地更加深刻

原文链接：https://www.dbreunig.com/2025/06/22/how-contexts-fail-and-how-to-fix-them.html

很多人在初期使用上下文工程的时候会发现：有的时候信息越多，AI 表现越差。这主要源于“上下文混淆”和“上下文冲突”：

1. 上下文混淆：当无关信息成为“噪声”GeoEngine 基准测试中，一项针对小型模型的研究提供了典型案例。

研究人员发现，当给量化的 Llama 3.1 8B 模型提供 GeoEngine 中所有 46 种工具定义时（即使全部在 16k 上下文窗口内），模型任务失败。然而，仅提供 19 种相关工具时，模型却成功完成任务。

这揭示了一个核心问题：模型会“关注”上下文中所有信息。即使这些信息是无关细节或无用工具定义，模型仍会将其纳入考量。尽管大型模型在忽略冗余信息方面有所进步，但无价值的上下文信息仍会显著干扰 AI 智能体的性能。更大的上下文窗口固然能容纳更多信息，但也增加了模型被无关内容分散注意力的风险。

2. 上下文冲突：当 AI 被早期错误误导上下文冲突是比混淆更严重的现象，指上下文信息不仅无关，甚至相互矛盾。

微软和 Salesforce 团队的一项研究发现。他们模拟用户逐步提供信息的聊天场景，将完整提示“分片”输入模型。结果令人震惊：模型性能平均下降 39%，连 OpenAI 家的模型准确率也从 98.1% 骤降至 64.1%。

这是因为模型在对话早期基于不完整信息做出了错误假设，并过早尝试生成解决方案。这些错误的“中间步骤”残留于上下文中，与后续更完整的信息产生冲突。

“当 LLM 在对话中走错方向时，它们会迷失方向且无法恢复。”

四、A Survey of Context Engineering

一篇长达 160 页的上下文工程综述，作者梳理了超过 1400 篇文献，包含 prompt 技术、记忆体系、RAG、agent 系统等，深度广度兼备。作者按组件与系统两层结构整理领域现状，适合研究者快速梳理全景与定位未来方向。

综述链接：https://arxiv.org/pdf/2507.13334

这篇综述贡献了一种将上下文工程研究的科学分类的框架：

支柱一：基础组件-构建的核心模块和技术：

1. 上下文检索与生成：获取并组装模型所需的上下文信息。这包括传统提示工程、从外部知识库（如数据库、知识图谱）检索，以及动态整合这些信息以形成连贯上下文。
2. 上下文处理：对获取的信息进行转换和优化。涵盖长序列处理、模型自优化（Self-Refinement）以及多模态/结构化数据（如图表）的整合能力。上
3. 下文管理：高效组织、存储和利用上下文信息，以应对有限上下文窗口的挑战。涉及记忆层次结构、上下文压缩和优化策略。

支柱二：系统实现-整合基础组件，解决现实世界问题的复杂 AI 架构：

1. 检索增强生成：将外部知识动态注入模型，从简单的线性流程演变为模块化、智能体化和图增强的复杂架构。记忆系统：赋予模型跨会话的持久记忆能力，以实现长期学习和适应。
2. 工具集成推理：通过函数调用和与环境交互，使模型能够超越自身知识限制，利用外部工具解决问题。
3. 多智能体系统：上下文工程的顶峰，多个智能体通过复杂的通信与编排机制协作，解决单个智能体无法完成的复杂任务。

论文提出目前上下文工程最关键研究缺口—基本不对称性：

当前模型虽在先进上下文工程技术加持下展现出强大的复杂上下文理解能力，但在生成同等复杂度的长篇输出时却表现出明显局限性。这意味着模型能“读懂”一本复杂的书，却难以“写出”同样复杂的书。弥合这种理解与生成能力之间的差距，是未来研究的重中之重。

五、Context Engineering: The Outer Loop | Hammad Bashir

Chroma 首席技术官 Hammad Bashir 的演讲，发表了他对上下文工程的看法。

原文链接：https://www.youtube.com/watch?v=vsfbplnJyA8

“如果我们无法预测它何时会出故障，那就不能称之为“工程”。

因此，我们如果想要更好地进行上下文工程，那就需要理解大语言模型的心智模型，Hammad 提出了几种理解大语言模型的思维方式：

• 可插值的程序数据库：可以将模型看作是学习了各种“程序”（例如“用莎士比亚的风格重写”）的集合，它能根据上下文来调用和组合这些程序。
• 重现一种心智状态：上下文的作用就像是让模型“进入状态”，从而能够顺利执行某个程序。
• Mesa-Optimization：一些研究者认为，大语言模型前向传播过程中内部就在执行一种优化过程。这些模型虽不完全准确，但有助于我们提出更好的问题（例如，“我想要定义什么样的搜索空间？”）来调试和改进应用。

六、Practical tips on building LLM agents

这篇博客更偏向于实战经验，提供了 6 个上下文工程的实用技巧。

原文链接：https://letters.lossfunk.com/p/practical-tips-on-building-llm-agents

1. 精细任务分块病症： 短任务成功率高，但随复杂度和耗时急剧下降。

治疗方法： 分解任务至人类 10-15 分钟（最长 30 分钟）可完成的原子化子任务，防上下文过长致模型遗忘指令。

2. 充分利用长上下文病症：廉价模型或 RAG 等成本节约方案，常导致性能下降和错误累积。

治疗方法：

（1）避免 RAG 处理代码，易混淆；直接将整个相关文件置于上下文更佳。

（2）不宜用廉价模型做“辅助工作”（如生成代码 diff），易累积错误，主模型直接“搜索替换”生成 diff，错误率已降至 5% 以下。

3. 为长周期任务构建稳固的验证系统病症： 长周期任务步骤多，错误累积风险高，易致智能体失败。

治疗方法：

（1）保持任务隔离：设计无状态、不严重依赖前序结果的流程。

（2）每步验证：任务后设验证，智能体须判断成败，防错误累积。

4. 将模型视为“失忆天才”：持续重复关键信息病症：上下文增长，模型易遗忘早期指令和信息。

治疗方法：

（1）重复待办事项：运行智能体需在上下文中反复提供任务清单，防其遗忘目标。

（2）建立“读写”学习循环：指示模型读写关键文件，将新知或中间结论写回，形成积累巩固的良性循环。

5. 赋予 LLM 读写工具：使其主动构建上下文病症： 模型工具调用能力增强，最佳实践从被动“上下文填充”转向智能体主动获取信息。

治疗方法：

（1）提供读写文件工具：让智能体像人般按需读写，而非被动接收信息。

（2）设计工具反馈机制：提供简洁有效反馈，避免撑爆上下文（如数据库查询只返回摘要，非万行数据）。

6. 关注多轮对话成本：善用 KV 缓存病症： 多轮交互智能体 token 成本呈二次方增长（如 50 轮对话成本为 2.5 单位/次，100 轮飙升至 100 单位/次）。

治疗方法：

（1）只追加，不修改上下文：多轮对话始终在末尾追加新内容，不修改历史。

（2）利用 KV 缓存：命中缓存可降成本至 1/10。长对话成本仍高，设计须考量效益

七、Manus 团队的实战总结：构建 AI 智能体的 6 个核心经验

这篇文章是 Manus AI 团队对其 AI 智能体“Manus”构建过程中的经验总结

原文链接：https://manus.im/zh-cn/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus

Manus AI 团队提出了构建生产级 AI 智能体的六大实用策略：

1. 围绕 KV 缓存进行设计在生产环境中，KV 缓存命中率是决定 AI 智能体延迟和成本的最关键指标。

由于智能体任务的输入（上下文）通常远大于输出（工具调用），高效的缓存策略能带来超过 90% 的成本节约：

• 稳定化提示词前缀：移除系统提示（System Prompt）中的时间戳、用户 ID 等动态内容。任何微小变动都会导致后续所有缓存失效。
• 坚持上下文“只追加”原则：不要修改或删除历史记录。同时，确保 JSON 等数据结构在序列化时是确定性的（如固定键的顺序），防止缓存被意外破坏。
• 显式标记缓存边界：如果推理框架支持，应在上下文中手动插入缓存断点，确保关键部分（如完整的系统提示）被有效缓存。

2. 动态管理工具：用“遮蔽”代替“增删”在任务执行中动态增删工具列表是非常不利模型生成正确答案的，工具定义通常位于上下文前部，任何改动都会使后续缓存全部失效，并可能因引用了不再存在的工具而干扰模型：

3. 将文件系统作为“无限”上下文即使是 128K 甚至更长的上下文窗口，在处理网页、PDF 等大型非结构化数据时也捉襟见肘。此外，超长上下文还会显著增加成本并引发“迷失在中间”等性能问题：

• 赋予读写权限：让智能体能够读写文件，将本地文件系统当作一个容量无限、可持久化的外部结构化记忆体。
• 采用“指针”压缩策略：不要直接丢弃信息，而是用指针替代。例如，将网页内容从上下文中移除，但保留其 URL；省略文档细节，但保留其文件路径。这样，智能体可以在需要时通过工具重新加载信息，有效缩短上下文长度。

4. 利用动态任务列表维持焦点在执行包含数十个步骤的复杂任务时，智能体很容易偏离最初设定的目标，即“目标漂移”：

• 维护动态待办事项：让智能体在工作区（如 todo.md 文件）维护一个任务清单。每完成一步，就重写整个文件，勾选已完成项。
• 强化“近期记忆”：通过不断重写，最新的任务计划始终位于上下文的末尾。这利用了模型的“近因效应”（Recency Bias），将核心目标始终置于其注意力焦点，从而有效对抗目标漂移。

5. 保留失败记录，让智能体从错误中学习开发者常倾向于隐藏或清理智能体的错误尝试（如失败的工具调用、错误日志）。但这恰恰剥夺了模型从失败中学习和适应的宝贵机会：

• 完整记录失败过程：当操作失败时，应将失败的指令连同其返回的错误信息（如堆栈跟踪）一并追加到上下文中。
• 驱动隐式信念更新：当模型观察到一次失败记录后，它会自然地更新其内部判断，从而在后续步骤中降低重复犯同一错误的可能性。

7. 打破重复模式，避免“少样本”陷阱虽然少样本（Few-shot）示例有助于引导模型，但如果上下文中充斥着大量高度相似的“操作-观察”范例，模型会倾向于盲目模仿，导致行为僵化，在面对新情况时表现脆弱：

• 引入受控的多样性：在“操作-观察”的表示方式上引入微小的结构性变化，如使用不同的序列化模板、同义词替换或在格式上加入微量“噪音”。
• 提升模型适应性：这种受控的随机性有助于打破固化模式，迫使模型更深入地理解任务而非简单模仿，从而使其行为更灵活、更鲁棒。

八、Context Engineering

来自大卫·金梅，一个全面的开源项目，属于从从原理到模板的一站式仓库，复制即用；常年更新，社区最佳实践浓缩。

最有意思的是，他创建了一个有趣的框架-上下文工程遵循生物进化的过程，非常有助于理解如何系统性地构建强大的 AI 能力。

GitHub链接：https://github.com/davidkimai/Context-Engineering

大卫·金梅从一个独特的视角来审视 AI 的构建，将上下文工程理解为五个进化层级：从原子到神经网络的逐级进化的系统。就像生命体的演化过程：从原子到分子，再到细胞、器官，最终形成复杂的神经系统。每一级都以前一级为基础，层层递进。

遗憾的是，大多数人止步于“原子”层面——即最基本的提示词。而真正的力量，在于构建一个完整的“神经网络系统”。这可以通过以下五个层次逐步实现：

第一级：原子（单个提示）

这是最基础的层面，但其精髓常被忽略。

那种“给我写一份商业计划书”式的模糊指令已经过时，它只会产出泛泛而谈的无用信息。

真正的威力在于情境化设计，即将实例、约束条件和认知工具融入上下文。

例如：

“请为一家针对 Z 世代市场的可持续时尚品牌撰写一份商业计划书。目标是获得 A 轮融资，请参考我们过去成功的营销案例（附链接），并考虑当前供应链挑战与机遇。”

提示本身并未改变，改变的是我们提供的“上下文”。上下文的丰富与精确，才是释放原子层力量的关键。

第二级：分子（少样本学习）

在丰富的上下文之上，少样本学习是真正的变革者，从“告知”AI 做什么，转变为通过“展示”教会它如何思考。

具体的示例远比冗长的解释更有效。

第三级：细胞（记忆系统）

进化过程始于此。

记忆系统赋予 AI 在对话中维持持久状态的能力，使其能够记住过往决策，并基于先前的知识进行累积和构建，从一个无状态的工具变为一个有记忆的学习者。

第四级：器官（多智能体系统）

到这个步骤，已超越简单的提示链，开始构建多智能体系统。

这如同组建一支高效的内部专家团队，其中每个智能体都拥有独立的上下文和专业知识:

第五级：神经系统（认知操作系统）——终极智能形态

这是所有前述层级的最终融合与演化，不再是简单地使用代理，而是构建一个具有以下特征的思维系统：

• 跨所有代理的持久记忆动态工具选择自我改进的上下文自主决策流程

结语

这些研究团队的思考和实践，其实都在告诉我们同一个道理：构建强大的智能体，早已不是“提示词炼金术”的游戏，而是一门真正的系统科学—上下文工程。

它要求我们完成一次认知上的转变：从“提问者”，进化成一个“AI 思维系统”的设计师。

不再是满足于打磨单个的“原子”（提示词），而是要像生物进化一样，将它们构造成拥有记忆的“细胞”、能够协同的“器官”，最终搭建起一个可以自我优化的“神经系统”。

所以，家人们，下一次当你准备构建自己的 Agent 时，请务必跳出那个小小的提示框。开始像一位真正的工程师那样去思考，去设计你的信息流，去搭建你的“神经系统”吧 ～

文章来自公众号“夕小瑶科技说”，作者“小鹿 ”