• 上下文工程
  • 资料
  • 背景
    • LLM 失败
    • 提示词 → 上下文
  • 定义
    • 上下文工程
    • 图解
    • 提示工程 vs 上下文工程
  • 策略
    • 写入
    • 选择
    • 压缩
    • 隔离
  • 构成
    • 正确的信息与工具
    • 格式化至关重要
    • 自检
  • 应用
    • Cognition
    • Anthropic
    • LangChain
    • Cursor
• 结束

上下文工程

早期提示工程（Prompt Engineering），即如何巧妙地向模型提问，迅速转向一个更进阶的领域——上下文工程（Context Engineering）。

要点：

• 上下文工程不仅是提示工程的升级，更是将动态系统、工具协作和记忆管理结合在一起的综合工程
• 四大策略（写入、选择、压缩、隔离） 是构建代理时常见的手段，需要根据任务特性灵活组合
• 多代理架构优缺点并存：并行子代理可扩展能力，但会增加成本并带来协调困难，需配合共享上下文和压缩技术
• 长上下文不是灵丹妙药：随着上下文增长，污染、干扰、混乱和冲突现象会加剧，剪枝和隔离同样重要

资料

• LangChain 官方博客文章《The Rise of “context engineering”》
• 【2025-6-24】解读 LangChain官方分享LLM的“上下文工程”技巧
• 【2025-7-16】图解+详解：上下文工程
• 【2025-7-30】Mutil-Agent的终极秘密武器：上下文工程（Context Engineering）
  • 原文 Context-Engineering-for-Agents

上下文负责铺路，而提示工程教你怎么走，提示工程是上下文工程的子集。

综述

• 【2025-7-21】论文 Title: A Survey of Context Engineering for Large Language Models
• 代码 Code Repository

上下文工程（Context Engineering）是一门生成、获取、处理与管理语言模型智能体上下文信息的艺术。

本文对该领域进行了系统梳理与分类，总结了其核心构成要素及典型应用场景。将现有研究划分为三类基础能力组件（Context Retrieval and Generation、Context Processing、Context Management）和四种系统实现（RAG、Memory Systems、Tool-Augmented Reasoning、多智能体系统），并分析其在Prompt Engineering、Memory机制、Agent通信与调度等方面的具体应用。

此外，重点讨论当前大模型在“context scaling”层面的发展瓶颈与挑战，指出真正的上下文扩展不仅涉及长度问题，更包括对信息类型、结构与动态处理机制的扩展。我们进一步总结了LLM在处理复杂关系型和结构化数据方面的最新进展与未来方向。

背景

使用LLM 智能体（Agent）时，常常遇到棘手问题：

• 为什么智能体表现如此不稳定？

习惯性归咎于模型本身不够强大。

然而，问题根源：未能向模型提供恰当上下文。

• 当一个智能体无法可靠地执行任务时，其根本原因通常是未能以正确的格式向模型传递正确的信息、指令和工具。

随着LLM应用从单一提示词演变为复杂的、动态的智能体系统，“上下文工程”（Context Engineering）正迅速成为AI工程师需要掌握的重要技能。

Cognition 团队核心观点

“再聪明的模型，若不知上下文，也无法做出正确判断。”

LLM 失败

智能体系统的失误，本质是 LLM 失误。

从第一性原理分析，LLM 失败主要源于两个方面：

• 底层模型能力不足，无法正确推理或执行。
• 模型缺少正确判断所需的上下文。

随着模型能力的飞速发展，第二点正成为更普遍的瓶颈。

上下文供给不足主要体现在：

• 信息缺失：模型完成任务所依赖的关键信息未被提供。
• 格式混乱：信息虽然存在，但其组织和呈现方式不佳，阻碍了模型的有效理解。

Agent 任务往往是 多轮对话 和 工具调用 的组合，导致上下文越来越长。

两个问题：

• 成本与效率： 长上下文会增加模型的计算成本和延迟，并可能导致模型性能下降
• 新的失败模式： Drew Breunig 总结了长上下文的四大失败模式：
  • 上下文污染（Context Poisoning）： 幻觉或错误信息进入上下文后被反复引用，代理会围绕错误目标做出决
  • 上下文干扰（Context Distraction）： 上下文过长导致模型过度关注历史而忽略训练知识，反复重复已有行
  • 上下文混乱（Context Confusion）： 上下文中无关的内容（如过多的工具说明）干扰模型，使其调用不必要的工
  • 上下文冲突（Context Clash）： 上下文中出现相互矛盾的信息时，模型难以判断取舍

因此，仅依靠扩大上下文窗口并不能解决问题，反而会引入新的风险。

上下文工程旨在通过合理整理、压缩和隔离信息，避免上述失败模式。

提示词 → 上下文

大模型应用技术从“提示词艺术”迈向“上下文科学”。

最近爆品，如Cursor，Manus等产品都表明

• 一个卓越的大模型产品，背后必然是精心设计的上下文工程系统。

未来的核心竞争力，不再是精妙的提示词，更是高质量、高效率的上下文。

通过精心组织，为模型提供事实依据、注入持久记忆、并扩展其行动能力，有可能释放大模型的潜力，构建出新的有价值AI产品。

定义

上下文工程

• 构建动态系统，以正确格式提供合适的信息和工具，使 LLM 能够合理地完成任务。

LangChain 在博客中将 上下文工程（context engineering） 定义为构建动态系统，为大语言模型提供恰当的信息和工具，使其“有可能完成任务”。

• 《The Rise of Context Engineering》

与早期只靠提示词的“prompt engineering”不同，上下文工程强调的是：

• 系统性： 代理的上下文来自开发者、用户、历史交互、工具调用或其他外部数据，必须通过系统化的逻辑组合在一起
• 动态性： 这些上下文通常是实时生成的，因此构建最终提示必须具有动态拼接能力
• 正确的信息与工具： 代理出错往往不是模型能力不足，而是缺乏恰当的信息或工具,因此必须保证提供的信息充分且格式合适

安德烈·卡帕西（Andrej Karpathy）用操作系统类比：

• LLM 就像 CPU，上下文窗口是 RAM（工作内存），而上下文工程就是决定哪些信息可以放入 RAM 的“调度器”。
• 由于 RAM 容量有限，上下文工程需要精心挑选和组织信息以避免溢出。

上下文工程

上下文工程（Context Engineering）核心定义：

• 构建一个动态系统，以正确格式提供正确的信息和工具，从而使大语言模型（LLM）能够可靠地完成指定任务。

深入理解：

• 系统工程：复杂智能体从多个来源获取上下文，包括开发者预设、用户输入、历史交互、工具调用结果以及外部数据。将这些信息源有机地整合起来，本身就是一个复杂的系统工程。
• 动态变化：上下文组成部分很多是实时生成。最终输入给模型的提示（Prompt）也必须是动态构建的，而非静态的模板。
• 信息精准：智能体系统失败的原因之一是上下文信息缺失。LLM 无法“读心”，必须为其提供完成任务所需的全部信息。所谓“垃圾进，垃圾出”，信息质量直接决定输出质量。
• 工具适用：很多任务无法仅靠初始信息完成。为 LLM 配备合适的工具就变得至关重要，用于信息检索、执行动作或与其他系统交互。提供正确的工具与提供正确的信息同等重要。
• 强调格式规范：与 LLM 的“沟通方式”跟人一样关键。简洁明了的错误信息远胜于一个庞杂 JSON 数据块。工具的参数设计、数据的呈现格式，都会显著影响 LLM 的理解和使用效率。
• 任务可行性：设计系统时，应反复自问：“在当前提供的上下文和工具下，LLM 是否真的有可能完成任务？” 便于归因分析，上下文不足，还是模型本身的执行失误，从而采取不同的优化策略。

图解

提示工程 vs 上下文工程

为什么从“提示工程”（Prompt Engineering）转向“上下文工程”？

LLM应用早期，开发者专注于通过巧妙措辞诱导模型给出更好的答案。

但随着应用变得越来越复杂，共识逐渐形成：

• 向AI提供完整和结构化的上下文，远比任何“魔法般”的措辞都重要。

提示工程是上下文工程的子集。

• 

即使有全部上下文信息，提示词组织、编排方式，仍然至关重要——提示工程范畴。

核心区别：

• 上下文工程：设计架构，动态地收集、筛选和整合来自多源的数据，构建出完整的上下文。
• 提示工程：已有上下文的基础上，设计格式化和指令，以最优方式与LLM沟通。
• 

不同于传统 Prompt Engineering，Context Engineering 更关注系统级的动态上下文构建。

• 强调：在复杂交互和多智能体协作中，如何为每个 Agent 构建精准、独立、可持续的任务背景，是系统能否稳定运行的关键。

维度	提示词工程(Prompting engineering)	上下文工程(Context engineering)
目标	写出清晰、明确的指令	准备好一切AI该知道的信息
本质	提示词本质是布置任务的指令，让AI按预期方式回答问题、执行任务	告诉AI当前的「需要什么」、「能做什么」，就像游戏的任务设定一样，提供所需要的信息、工具和历史记忆，然后交给AI来思考和执行
比喻	怎么走路	铺路
图解

总结：

• 提示词工程依赖精细指令，不仅难以复用，还容易因措辞差异导致结果波动，对写Prompts的人要求也更高
• 上下文工程让AI具备持续理解和应变能力，不仅能适应新任务，还能保持输出稳定、不易“翻车”
• 

漫画来自: 小红书博主“机器坏人（AI版）”

更多对比

• 

策略

上下文工程的四种策略

LangChain 将常见的上下文工程策略分为： 写入（Write）、选择（Select）、压缩（Compress）和隔离（Isolate）

这些策略并不是孤立的，而是在复杂代理中相互配合使用

写入

写入（Write）——在上下文之外持久化信息

写入策略指将信息存储在上下文窗口之外，供未来检索。例如：

• Scratchpad（草稿本）： 类似人类做笔记，代理通过工具调用将临时信息写入文件或状态对象，在任务过程中随时访问。Anthropic 的多代理研究系统会在计划开始前将研究计划写入记忆，以防上下文超过 20 万个 token 时被截断anthropic.com。LangGraph 为代理提供了 short‑term memory（检查点）来在会话内保存状态blog.langchain.com。
• 长期记忆（Memory）： 有些信息需要跨会话保存，例如用户偏好或历史反馈。生成式代理（Generative Agents）通过定期汇总过去的反馈构建长期记忆。现在的一些产品如 ChatGPT、Cursor 和 Windsurf 也自动生成长期记忆

选择

选择（Select）——从记忆中提取相关信息

选择策略是将外部记忆、文件或工具调用结果拉入当前上下文。

常见做法包括：

• 小样本示例（Few‑shot examples）： 作为 情景记忆（episodic memory） 帮助代理模仿预期行为
• 指令/规则（Procedural memory）： 用于指导代理行为，如 Claude Code 中的 CLAUDE.md 规则文件
• 事实（Semantic memory）： 存储知识、实体信息，供检索调用

LangGraph 中，开发者可以在每个节点按需检索状态或长期记忆，并通过嵌入检索等方式选取最相关的记忆。

对于工具选择，一些研究表明，使用 RAG 技术对工具说明进行检索可以使选择准确率提高 3 倍

压缩

压缩（Compress）——保留必要的信息

压缩策略通过 摘要（summarization） 或 修剪（trimming） 减少上下文长度：

摘要：

• 通过 LLM 压缩对话历史，只保留关键决策。
• Claude Code 会在上下文超过 95% 时运行 “auto‑compact” 自动摘要。
• 在 Cognition 的代理中，还使用专门微调的小模型来压缩代理间的交互，以减少知识传递时的 token 数

修剪：

• 通过启发式方法删掉旧消息，例如只保留最近的几轮对话；也可以用训练出的 Provence 模型对检索内容进行句子级别的剪枝，它将上下文剪枝任务视为序列标注问题，在多领域问答中几乎不损失性能

压缩并不是万能的：过度摘要可能遗漏关键细节，修剪也有风险，因此需要结合任务特点谨慎使用。

隔离

隔离（Isolate）——拆分上下文以并行处理

隔离策略通过 分工合作 减少单个上下文窗口的压力。例如：

• 多代理架构： Anthropic 的 Research 系统采用 主代理 + 子代理 模式，主代理制定研究计划并将任务分配给多个子代理并行搜索，子代理拥有自己的上下文窗口，并在完成后将结果返回，由主代理汇总。该系统在广度优先查询中比单代理效果提升 90% 以上，但使用的 token 约是对话模式的 15 倍，因此只适用于价值高且可并行的任务
• 分离环境与沙盒： Hugging Face 的代码代理通过将代码执行放在沙盒环境中，图像或大型对象留在沙盒内，返回值再传回 LLM，这样可以隔离大量 token
• 状态对象： 在 LangGraph 中，开发者可以设计包含多个字段的状态 schema，只将 messages 字段暴露给模型，而将其他字段留作环境使用

Cognition 指出，多代理架构容易出现上下文缺乏共享、决策冲突等问题，并总结出两个关键原则：

• 原则 1：共享上下文和完整的代理轨迹；
• 原则 2：决策隐含偏好，冲突会产生坏结果

因此在实际应用中，应谨慎使用多代理，必要时更倾向于线性单代理配合压缩技术。

构成

上下文系统由多个关键部分组成

• 

上下文工程 = 提示词 + 用户画像 + 记忆 + 检索信息 + RAG信息 + MCP信息

• 

上下文工程是一个动态系统

复杂的智能体系统从多个来源获取上下文：

• 应用开发者：预设的系统指令和行为准则。
• 用户：当前任务的直接输入和要求。
• 历史交互：先前对话的记忆或摘要。
• 工具调用：通过API或函数调用获取的外部信息。
• 外部数据：从数据库或知识库中检索的文档。

将所有这些信息整合在一起，需要一个复杂的系统。

1. 提供正确的信息与工具
2. 格式化至关重要
3. 自检：反复确认信息是否充分

而且必须动态，因为许多上下文信息是实时变化的。

因此，最终交付给LLM的提示词（Prompt）不是静态模板，而是由动态逻辑实时构建的。

好的上下文工程应该包括：

• 工具使用：当一个智能体访问外部信息时，需要拥有能够访问这些信息的工具。当工具返回信息时，需要以 LLM 最容易理解的方式对其进行格式化。
• 短期记忆：如果对话持续一段时间，可以创建对话摘要，并在未来使用该摘要。
• 长期记忆：如果用户在之前的对话中表达了偏好，需要获取这些信息。
• 提示工程：在提示中清楚地列举智能体应该如何操作的说明。
• 检索：动态地获取信息，并在调用 LLM 之前将其插入到提示中。

正确的信息与工具

LLM 应用失败常见原因：上下文缺失。

LLM无法读取用户思想，如果不提供完成任务所需的关键信息，不可能知道这些信息的存在。

• “垃圾进，垃圾出”（Garbage in, garbage out）原则。

同样，仅有信息可能还不够。

在很多场景下，LLM需要借助工具来查询更多信息或执行某些动作。为LLM提供正确的工具，与提供正确的信息同等重要。

格式化至关重要

与人类沟通类似，如何向LLM传递信息，其格式会极大地影响结果。

一个简短但描述清晰的错误信息，远比一个庞大而杂乱的JSON数据块更容易让LLM理解和处理。这一点同样适用于工具的设计，工具的输入参数是否清晰、易于理解，直接决定了LLM能否有效使用。

自检

进行上下文工程时，反复确认：

• “以当前提供的上下文，LLM真的能合理地完成任务吗？”

这个问题能保持清醒，认识到LLM不是万能的，要为创造条件。同时，有助于区分两种主要的失败模式：

• 失败模式一：没有提供足够或正确的信息/工具，导致LLM失败。
• 失败模式二：提供了所有必要的信息和工具，但LLM自身出现了推理错误。

这两种失败模式的修复方案截然不同，准确定位问题是优化的第一步。

应用

优秀的上下文工程实践：

• 工具使用（Tool Use）：确保必要时能访问外部信息，并为工具设计易于LLM理解的输入参数和输出格式。
• 短期记忆（Short-term Memory）：持续多轮对话中，动态创建对话摘要，并将其作为后续交互的上下文，防止信息丢失。
• 长期记忆（Long-term Memory）：当历史对话中包含用户特定偏好时，系统能够自动获取这些信息，并在新对话中加以利用。
• 提示工程（Prompt Engineering）：提示词清晰地列出智能体应遵循的行为准则和详细指令。
• 检索（Retrieval）：调用LLM之前，根据用户查询动态地从知识库（如向量数据库）中获取相关信息，并将其注入到提示词中。

两者却不约而同指出：要让多智能体系统稳定运行，有两个关键前提：

• Context Engineering（上下文工程）是基础设施级能力
• 多智能体更适合“读”任务而非“写”任务

结语：别被“智能体数量”迷惑，关键是上下文控制力

• Cognition 的告诫并非“多智能体无用”，而是警示其复杂性；
• Anthropic 的成功并非“多智能体万能”，而是源于良好的任务拆解与上下文管理； 构建多智能体系统不仅是技术挑战，更是“系统工程挑战”。

Cognition

Cognition 团队总结

• 多 Agent 写作风险: “行为背后是决策，冲突的决策会带来灾难。”
• 再聪明的模型，若不知上下文，也无法做出正确判断。

读 vs 写，本质区别在哪？

• 读（Research）型任务：如搜索信息、理解材料等，天然适合并行执行，多个 Agent 各自探索、协同处理即可。
• 写（Synthesis）型任务：如代码生成、内容撰写，需保持结构统一、语言风格一致，难以拆分并行，否则会产生冲突或碎片化。

Anthropic

Anthropic 实践：

• 长对话管理：对话可能长达数百轮，需要引入外部记忆与压缩机制，如在每阶段总结信息存储进记忆库、跨阶段切换时唤回关键信息。
• 任务描述精准化：子智能体需要被明确告知目标、输出格式、所用工具、边界约束，否则容易重复劳动或遗漏重要内容。

底层能力支持

• ✅ 完整控制 LLM 接收的上下文输入
• ✅ 无隐藏提示、无强加的“认知架构”
• ✅ 明确每一步执行顺序，实现灵活编排

Claude Research 系统中：

• 读取任务：由多智能体并行完成，每个 Agent 负责不同方向
• 写作任务：由主智能体统一汇总并输出，避免冲突与割裂

模糊指令导致多个 Agent 重复搜索 2025 年半导体供应链，有效的任务拆解机制是防止资源浪费的关键。

Agent 框架核心不是功能丰富，而是给开发者“上下文的完全控制权”。

多智能体系统适合任务：

• ✅ 高价值任务：计算成本可控，但任务本身价值高（如战略研究）
• ✅ 广度优先探索：适合多个 Agent 并行发散，如舆情分析、多角度政策解读
• ✅ 超长上下文任务：任务 token 超过单模型窗口上限时，可用 Agent 分工处理各部分

而在以下场景中，多智能体反而不如单体结构高效：

• ❌ 强依赖上下文同步、实时响应（如代码协作、系统集成）
• ❌ 子任务之间依赖复杂、无法并行（如多步骤推理题）

没有通用最佳结构，只有最合适的架构决策。

作者：AI小智

LangChain

LangChain 生态两个核心工具——LangGraph和LangSmith——为实践上下文工程提供了强大的支持。

• LangGraph 用于构建可控智能体框架的库。设计理念与上下文工程完美契合，因为赋予了开发者完全的控制权。
• LangSmith 是 LangChain 的 LLM应用可观测性（Observability）和评估解决方案。核心功能——调用链路追踪——是调试上下文工程问题的利器。

Cursor

待定

结束