上下文工程是构建高效AI代理的关键技术,它通过系统化地管理信息流,帮助大语言模型在有限的上下文窗口内完成任务。本文介绍了上下文工程的概念、四大策略(写入、选择、压缩、隔离)以及多代理与单代理架构的权衡。文章强调,上下文工程能避免长上下文带来的污染、干扰、混乱和冲突等问题,是代理工程师的核心技能。通过学习本文,你将掌握如何为AI代理提供恰当的信息和工具,从而提升代理系统的性能和可靠性。

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

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

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

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

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

  1. 成本与效率: 长上下文会增加模型的计算成本和延迟,并可能导致模型性能下降
  2. 新的失败模式: Drew Breunig 总结了长上下文的四大失败模式:
  • 上下文污染(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 倍

不同记忆类型一览(重点词条,避免冗长描述):

记忆类型 存储内容 代理示例
语义记忆 Facts(事实) 关于用户的事实
情景记忆 Experiences(经历) 过去的代理动作
程序记忆 Instructions(指令) 系统提示或规则

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的人,将会比较晚掌握AI的人有竞争优势”。

这句话,放在计算机、互联网、移动互联网的开局时期,都是一样的道理。

我在一线互联网企业工作十余年里,指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家,也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑,所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限,很多互联网行业朋友无法获得正确的资料得到学习提升,故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

这份完整版的大模型 AI 学习资料已经上传CSDN,朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费

https://img-blog.csdnimg.cn/img_convert/05840567e2912bcdcdda7b15cba33d93.jpeg

在这里插入图片描述

为什么要学习大模型?

我国在A大模型领域面临人才短缺,数量与质量均落后于发达国家。2023年,人才缺口已超百万,凸显培养不足。随着AI技术飞速发展,预计到2025年,这一缺口将急剧扩大至400万,严重制约我国AI产业的创新步伐。加强人才培养,优化教育体系,国际合作并进是破解困局、推动AI发展的关键。

在这里插入图片描述

在这里插入图片描述

大模型入门到实战全套学习大礼包

1、大模型系统化学习路线

作为学习AI大模型技术的新手,方向至关重要。 正确的学习路线可以为你节省时间,少走弯路;方向不对,努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划,带你从零基础入门到精通!

img


2、大模型学习书籍&文档

学习AI大模型离不开书籍文档,我精选了一系列大模型技术的书籍和学习文档(电子版),它们由领域内的顶尖专家撰写,内容全面、深入、详尽,为你学习大模型提供坚实的理论基础。

在这里插入图片描述

3、AI大模型最新行业报告

2025最新行业报告,针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估,以了解哪些行业更适合引入大模型的技术和应用,以及在哪些方面可以发挥大模型的优势。

img

4、大模型项目实战&配套源码

学以致用,在项目实战中检验和巩固你所学到的知识,同时为你找工作就业和职业发展打下坚实的基础。

img

5、大模型大厂面试真题

面试不仅是技术的较量,更需要充分的准备。在你已经掌握了大模型技术之后,就需要开始准备面试,我精心整理了一份大模型面试题库,涵盖当前面试中可能遇到的各种技术问题,让你在面试中游刃有余

img

适用人群

在这里插入图片描述

第一阶段(10天):初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识,对大模型 AI 的理解超过 95% 的人,可以在相关讨论时发表高级、不跟风、又接地气的见解,别人只会和 AI 聊天,而你能调教 AI,并能用代码将大模型和业务衔接。

  • 大模型 AI 能干什么?
  • 大模型是怎样获得「智能」的?
  • 用好 AI 的核心心法
  • 大模型应用业务架构
  • 大模型应用技术架构
  • 代码示例:向 GPT-3.5 灌入新知识
  • 提示工程的意义和核心思想
  • Prompt 典型构成
  • 指令调优方法论
  • 思维链和思维树
  • Prompt 攻击和防范
第二阶段(30天):高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习,学会构造私有知识库,扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架,抓住最新的技术进展,适合 Python 和 JavaScript 程序员。

  • 为什么要做 RAG
  • 搭建一个简单的 ChatPDF
  • 检索的基础概念
  • 什么是向量表示(Embeddings)
  • 向量数据库与向量检索
  • 基于向量检索的 RAG
  • 搭建 RAG 系统的扩展知识
  • 混合检索与 RAG-Fusion 简介
  • 向量模型本地部署
第三阶段(30天):模型训练

恭喜你,如果学到这里,你基本可以找到一份大模型 AI相关的工作,自己也能训练 GPT 了!通过微调,训练自己的垂直大模型,能独立训练开源多模态大模型,掌握更多技术方案。

到此为止,大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗?

  • 为什么要做 RAG
  • 什么是模型
  • 什么是模型训练
  • 求解器 & 损失函数简介
  • 小实验2:手写一个简单的神经网络并训练它
  • 什么是训练/预训练/微调/轻量化微调
  • Transformer结构简介
  • 轻量化微调
  • 实验数据集的构建
第四阶段(20天):商业闭环

对全球大模型从性能、吞吐量、成本等方面有一定的认知,可以在云端和本地等多种环境下部署大模型,找到适合自己的项目/创业方向,做一名被 AI 武装的产品经理。

  • 硬件选型
  • 带你了解全球大模型
  • 使用国产大模型服务
  • 搭建 OpenAI 代理
  • 热身:基于阿里云 PAI 部署 Stable Diffusion
  • 在本地计算机运行大模型
  • 大模型的私有化部署
  • 基于 vLLM 部署大模型
  • 案例:如何优雅地在阿里云私有部署开源大模型
  • 部署一套开源 LLM 项目
  • 内容安全
  • 互联网信息服务算法备案

学习是一个过程,只要学习就会有挑战。天道酬勤,你越努力,就会成为越优秀的自己。

如果你能在15天内完成所有的任务,那你堪称天才。然而,如果你能完成 60-70% 的内容,你就已经开始具备成为一名大模型 AI 的正确特征了。

这份完整版的大模型 AI 学习资料已经上传CSDN,朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费

https://img-blog.csdnimg.cn/img_convert/05840567e2912bcdcdda7b15cba33d93.jpeg

Logo

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。

更多推荐