导语： 随着大语言模型（LLM）和代理框架的发展，人们越来越意识到「上下文」对代理行为的重要性。代理不仅需要用户的指令，还需要外部知识、工具反馈等信息才能完成复杂任务。所谓“上下文工程”就是在有限的上下文窗口内，为代理按步骤提供恰当的信息和工具，使其能够有效地完成任务。本文将结合 LangChain、Anthropic 和 Cognition 等团队的经验，解释上下文工程的概念、常见策略以及多代理/单代理架构的权衡，并对相关链接进行梳理，为中文读者呈现一篇关于上下文工程的完整介绍。

LangChain 在博客中将 上下文工程（context engineering） 定义为构建动态系统，为大语言模型提供恰当的信息和工具，使其“有可能完成任务”。与早期只靠提示词的“prompt engineering”不同，上下文工程强调的是：

• 系统性： 代理的上下文来自开发者、用户、历史交互、工具调用或其他外部数据，必须通过系统化的逻辑组合在一起

• 动态性： 这些上下文通常是实时生成的，因此构建最终提示必须具有动态拼接能力

• 正确的信息与工具： 代理出错往往不是模型能力不足，而是缺乏恰当的信息或工具
  。因此必须保证提供的信息充分且格式合适

安德烈·卡帕西（Andrej Karpathy）用操作系统做了一个类比：LLM 就像 CPU，上下文窗口是 RAM（工作内存），而上下文工程就是决定哪些信息可以放入 RAM 的“调度器”。由于 RAM 容量有限，上下文工程需要精心挑选和组织信息以避免溢出。

为什么代理需要上下文工程？

在代理系统中，任务往往是 多轮对话 和 工具调用 的组合，导致上下文越来越长。这会带来两个问题：

1. 成本与效率： 长上下文会增加模型的计算成本和延迟，并可能导致模型性能下降

2. 新的失败模式： Drew Breunig 总结了长上下文的四大失败模式：

3. • 上下文污染（Context Poisoning）： 幻觉或错误信息进入上下文后被反复引用，代理会围绕错误目标做出决策
   • 上下文干扰（Context Distraction）： 上下文过长导致模型过度关注历史而忽略训练知识，反复重复已有行为
   • 上下文混乱（Context Confusion）： 上下文中无关的内容（如过多的工具说明）干扰模型，使其调用不必要的工具
   • 上下文冲突（Context Clash）： 上下文中出现相互矛盾的信息时，模型难以判断取舍

因此，仅依靠扩大上下文窗口并不能解决问题，反而会引入新的风险。上下文工程旨在通过合理整理、压缩和隔离信息，避免上述失败模式。

上下文工程的四种策略

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

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

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

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

• Scratchpad（草稿本）： 类似人类做笔记，代理通过工具调用将临时信息写入文件或状态对象，在任务过程中随时访问。Anthropic 的多代理研究系统会在计划开始前将研究计划写入记忆，以防上下文超过 20 万个 token 时被截断anthropic.com。LangGraph 为代理提供了 short‑term memory（检查点）来在会话内保存状态blog.langchain.com。

• 长期记忆（Memory）： 有些信息需要跨会话保存，例如用户偏好或历史反馈。生成式代理（Generative Agents）通过定期汇总过去的反馈构建长期记忆
  。现在的一些产品如 ChatGPT、Cursor 和 Windsurf 也自动生成长期记忆

  

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

选择策略是将外部记忆、文件或工具调用结果拉入当前上下文。常见做法包括：

• 小样本示例（Few‑shot examples）： 作为 情景记忆（episodic memory） 帮助代理模仿预期行为

• 指令/规则（Procedural memory）： 用于指导代理行为，如 Claude Code 中的 CLAUDE.md 规则文件

• 事实（Semantic memory）： 存储知识、实体信息，供检索调用

在 LangGraph 中，开发者可以在每个节点按需检索状态或长期记忆，并通过嵌入检索等方式选取最相关的记忆。对于工具选择，一些研究表明，使用 RAG 技术对工具说明进行检索可以使选择准确率提高 3 倍

不同记忆类型一览（重点词条，避免冗长描述）：

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

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

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

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

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

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

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

多代理架构： Anthropic 的 Research 系统采用 主代理 + 子代理 模式，主代理制定研究计划并将任务分配给多个子代理并行搜索，子代理拥有自己的上下文窗口，并在完成后将结果返回，由主代理汇总。该系统在广度优先查询中比单代理效果提升 90% 以上，但使用的 token 约是对话模式的 15 倍，因此只适用于价值高且可并行的任务

• 分离环境与沙盒： Hugging Face 的代码代理通过将代码执行放在沙盒环境中，图像或大型对象留在沙盒内，返回值再传回 LLM，这样可以隔离大量 token

  huggingfaceOpen-source DeepResearch – Freeing our search agents

• 状态对象： 在 LangGraph 中，开发者可以设计包含多个字段的状态 schema，只将 messages 字段暴露给模型，而将其他字段留作环境使用

不过，Cognition 指出，多代理架构容易出现上下文缺乏共享、决策冲突等问题，并总结出两个关键原则：原则 1：共享上下文和完整的代理轨迹；原则 2：决策隐含偏好，冲突会产生坏结果
因此在实际应用中，应谨慎使用多代理，必要时更倾向于线性单代理配合压缩技术。

链接内容梳理

《The Rise of Context Engineering》（LangChain）

LangChain 在文章中阐述了为什么上下文工程是下一代 AI 工程师最重要的技能。作者指出，随着应用从单一提示转向动态的代理系统，构建能够 动态组织信息、选择工具并以合适格式传递给模型的系统 是成功的关键
文章强调：

• 代理性能差往往是因为缺乏正确的上下文和工具；
• 上下文工程包括系统地收集信息、动态构建提示、提供合适工具并保证格式合理blog.langchain.com；
• 适当的上下文和工具比花哨的提示词更重要，提示工程只是上下文工程的一个子集

《Don’t Build Multi‑Agents》（Cognition）

Cognition（Devin 团队）反对盲目构建多代理系统，认为上下文工程才是构建可靠代理的核心。他们指出：

• 上下文工程是比提示工程更高级的技能，是代理工程师的核心工作
• 多代理架构看似诱人，但容易造成误解和冲突。即便给子代理复制完整任务描述，也无法避免上下文缺失，因为实际任务涉及多轮对话和工具调用，任何细节缺失都会影响理解
• Cognition 总结两条原则：共享上下文、共享完整的代理轨迹；每个动作都隐含决策，冲突会导致坏结果
  他们建议在多数情况下采用单线程线性代理，并通过压缩模型来保留关键信息，使长任务也能可靠完成

《How we built our multi‑agent research system》（Anthropic）

Anthropic 描述了他们为 Claude 构建研究模式的经验。文章认为：

• 多代理系统适合探索性研究等 开放性任务。主代理解析用户查询，生成计划并创建多个子代理并行搜索信息

• 子代理各自拥有独立的上下文窗口和工具，可以探索问题的不同方面，再由主代理汇总，提供 分工明确、各自为政 的优点

• 内部评测显示，该系统在广度优先问题上比单代理方案提升 90%，但成本高昂，token 使用量约为对话的 15 倍，因此仅适合价值高、可以充分并行的任务

• 他们通过 写入计划到记忆 来解决上下文截断问题，并总结了如何给代理制定合适的提示、合理划分子任务、并行调用工具等提示工程经验

《How Long Contexts Fail》（Drew Breunig）

Drew Breunig 指出，超长上下文并不一定带来更好的代理。相反，过长的上下文会引入污染、干扰、混乱和冲突等问题，使代理迷失方向作者分析了每种失败模式的案例，并指出需要通过剪枝、工具检索、隔离等方法防止上下文失控。

Provence：高效稳健的上下文剪枝

在 RAG 系统中，检索内容往往很长。Provence 将 上下文剪枝 视为序列标注问题，通过统一剪枝与重排序模型、在多样化数据上训练，实现了在不同领域几乎不损失性能的剪枝方法这为压缩策略提供了更稳健的算法支持。

LangGraph 与 LangSmith 的支持

LangGraph 是 LangChain 推出的有向图代理框架，旨在让开发者完全控制代理的步骤、状态和上下文。它提供了以下功能：

• 检查点与长短期记忆： 支持在代理会话内持久化状态（短期记忆）和跨会话保存信息（长期记忆），方便实现 scratchpad 与记忆功能
• 灵活的状态检索： 在每个节点中，开发者可以从状态对象或长期记忆中检索特定字段，并通过自定义逻辑决定哪些信息注入到上下文
• 压缩与修剪： 提供总结与修剪工具，可在代理设计中的特定步骤调用 LLM 或剪枝算法对上下文进行精简
• 多代理与沙盒： LangGraph 支持构建多代理系统，通过设置不同的节点和状态字段实现隔离，并可结合沙盒环境保存大型数据对象

LangSmith 则提供了强大的 追踪和评测 功能，可查看代理的每一步输入输出、token 使用情况，并评估不同上下文工程策略对性能的影响

结论与展望

上下文工程是构建可靠 AI 代理的核心，它决定了代理能否在有限的工作内存中合理利用指令、知识和工具。本文总结出以下要点：

1. 上下文工程不仅是提示工程的升级，更是将动态系统、工具协作和记忆管理结合在一起的综合工程

2. 四大策略（写入、选择、压缩、隔离） 是构建代理时常见的手段，需要根据任务特性灵活组合

   

3. 多代理架构优缺点并存：并行子代理可扩展能力，但会增加成本并带来协调困难，需配合共享上下文和压缩技术

4. 长上下文不是灵丹妙药：随着上下文增长，污染、干扰、混乱和冲突现象会加剧，剪枝和隔离同样重要

对于正在建设代理系统的读者，可以从以下方面入手：

• 观察代理任务流程，确定何时需要写入、选择、压缩或隔离上下文；
• 通过工具检索、摘要和剪枝算法控制上下文长度；
• 警惕多代理带来的协调与成本问题，优先确保共享上下文和决策的一致性；
• 使用 LangSmith 等工具观察代理行为，及时调整上下文工程策略。

随着模型能力和工具生态的发展，合理的上下文工程将成为 AI 代理迈向生产级应用的关键。希望本文能帮助你更好地理解这一新兴领域，并在自己的项目中应用这些思路。

最后

选择AI大模型就是选择未来！最近两年，大家都可以看到AI的发展有多快，我国超10亿参数的大模型，在短短一年之内，已经超过了100个，现在还在不断的发掘中，时代在瞬息万变，我们又为何不给自己多一个选择，多一个出路，多一个可能呢？

与其在传统行业里停滞不前，不如尝试一下新兴行业，而AI大模型恰恰是这两年的大风口，整体AI领域2025年预计缺口1000万人，人才需求急为紧迫！

由于文章篇幅有限，在这里我就不一一向大家展示了，学习AI大模型是一项系统工程，需要时间和持续的努力。但随着技术的发展和在线资源的丰富，零基础的小白也有很好的机会逐步学习和掌握。

【2025最新】AI大模型全套学习籽料（可白嫖）：LLM面试题+AI大模型学习路线+大模型PDF书籍+640套AI大模型报告等等，从入门到进阶再到精通，超全面存下吧！

获取方式：有需要的小伙伴，可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
包括：AI大模型学习路线、LLM面试宝典、0基础教学视频、大模型PDF书籍/笔记、大模型实战案例合集、AI产品经理合集等等

大模型学习之路，道阻且长，但只要你坚持下去，一定会有收获。本学习路线图为你提供了学习大模型的全面指南，从入门到进阶，涵盖理论到应用。
L1阶段：启航篇|大语言模型的基础认知与核心原理

L2阶段：攻坚篇|高频场景:RAG认知与项目实践

L3阶段：跃迀篇|Agent智能体架构设计

L4阶段：精进篇|模型微调与私有化部署

L5阶段：专题篇|特训集：A2A与MCP综合应用 追踪行业热点（全新升级板块）

AI大模型全套学习资料【获取方式】