2026大模型上下文工程（Context Engineering）指南

大模型上下文工程指南

主编单位：中科算网科技有限公司算泥AI

开发者社区（）

大模型上下文工程指南

目

录前言

1第

1

章上下文的重新定义

21.1狭义上下文：TokenWindow作为“

技术参数

”的时代

21.2广义上下文：迈向系统状态的整体视角

31.2.1

文本上下文（TextualContext）

41.2.2环境上下文（EnvironmentalContext）

...41.2.3

用户上下文（UserContext）

41.2.4

系统上下文（SystemContext）

51.2.5组织上下文（OrganizationalContext）

51.3

范式跃迁：从被动输入到主动经营

5第2

章历史脉络：上下文技术的三次飞跃

62.1静态输入窗口

时代（2017–2022）：PromptEngineering

的黄金年代

62.1.1一切的起点：Transformer

与有限的注意力

62.1.2GPT-3

的惊鸿一瞥：In-ContextLearning

的魔力

72.1.3黄金期的局限：PromptEngineering

的根本困境

72.2

长上下文窗口

竞赛（2022–2024）：从“

寸土寸金

”到“

军备竞赛

”

..82.2.1解除封印：

突破二

次方诅咒的关键技术

92.2.2从

1k

到

1M：Token

窗口

的“

通货膨胀

”

102.2.3“

长

”的代价：上下文腐烂与注意力稀释

102.3外部记忆与RAG

的兴起（2023–2025）：解耦计算与存储

112.3.1RAG

的核心思想：解耦“

计算

”与“存储

”

112.3.2MemGPT：像操作系统一样管理上下文

122.3.3持久化上下文的黎明

122.4智能体与协议化上下文（2025–2026）：

上下文成为主动的

、

分布式的系统状态网络

132.4.1智能体：上下文的终极载体

132.4.2MCP

：标准化“

单智能体如何接入世界”

132.4.3A2A

：标准化“

多智能体如何互联

”

142.4.4去中心化的上下文网络

15第3

章Prompt：从静态指令到结构化思维

15

大模型上下文工程指南

3.1Prompt

的本质：

一次性

、静态的人机指令

153.2

高级Prompt

技法：

引导模型“

思考

”

163.2.1

思维链（Chain-of-Thought,CoT）

163.2.2ReAct

：协同推理与行动

173.3Prompt

的根本痛点

：脆弱

、难管

、

与世隔绝

173.4必然的演进：从PromptEngineering

到ContextEngineering

18第4

章Skills：

可复用

、

可组合的能力单元

..

184.1Skill

的定义：从临时工具到能力资产

194.2Skill在上下文中的角色：

能力的显式化

204.3Skill

的生命周期：从定义到演进

214.4演进之路：从自定义JSON

到标准化协议

214.5标准化

Skill

定义与实现

22第5

章MCP：单智能体的上下文扩展坞

245.1MCP要解决的核心问题：

能力集成的“巴别塔”

245.2MCP

的核心

架构：解耦智能体与能力

255.3MCP

的三大原语：

不止于工具

255.4MCP

工作流实例：

一次订票查询

265.5

最佳实践：基于官方文档的MCPServer

和Client

实现

275.6MCP

的历史定位与争议

31第6

章A2A：

多智能体的协作总线

326.1A2A

的核心使命：从“

单兵作战

”到“

联合作战

”

326.2A2A

vs.MCP：

两个层面的“

标准化

”

336.3A2A

的核心概念

：任务、上下文与能力切片

336.4A2A

工作流实例：

一次复杂的研究任务

346.5愿景：

一个“

智能体社会”

356.6

最佳实践：基于A2A

官方文档的实现示例

..356.6.1

定义Agent

Skill

356.6.2

定义AgentCard

366.6.3

实现AgentExecutor

366.6.4启动A2AServer

376.6.5

A2AClient

交互

37

大模型上下文工程指南

6.6.6

A2A

与MCP

的关系

38第7

章L

1

记忆：

瞬时工作记忆（Scratchpad）

387.1L

1

记忆的本质：模型上下文窗口

的动态应用

397.2ReAct循环：L

1

记忆的核心读写机制

407.3L

1

记忆的最佳实践

407.3.1使用结构化分隔符

407.3.2

坚持“仅追加

”原则

417.3.3L

1

记忆的“

垃圾回收

”：

向L2/L3

的沉淀

41第

8

章L2记忆：

情景记忆（EpisodicMemory）

428.1L2

记忆的本质：

结构化的交互历史

428.2L2

记忆的实现机制

428.2.1

滑动窗口（SlidingWindow）

428.2.2令牌长度限制（TokenLengthLimit）

438.2.3摘要化（Summarization）

...438.3L2

记忆的作用：从经验中学习

438.4

最佳实践：基于

LangChain

官方文档的消息摘要实现

448.4.1使用

SummarizationMiddleware

448.4.2使用LangGraph

Store

实现长期记忆存储

448.4.3在工具中读取情景记忆

458.4.4从工具写入情景记忆

46第9

章L3

记忆

：语义记忆（SemanticMemory）

479.1L3

记忆的本质：

外部化的

、

可检索的知识库

479.2L3

记忆的核心技术栈

489.2.1

向量数据库

：语义检索的核心

.489.2.2RAGvs.微调

：正确的知识更新姿势

489.2.3知识图谱：超越向量的结构化记忆

499.3L3

记忆的构建与维护

509.4

最佳实践：基于LlamaIndex

官方文档的RAG

实现

509.4.1安装依赖

509.4.2准备知识源

509.4.3构建带RAG

能力的Agent

50

大模型上下文工程指南

9.4.4持久化RAG

索引

519.4.5添加对话历史

529.4.6代码与L3

记忆分析

52第

10

章上下文工程六大支柱：

结构化（Structuring）

5210.1

为什么要结构化？对抗“

熵增

”

5310.2结构化的核心技术

5410.2.1XML/JSON：

最通用的结构化语言

..

5410.2.2Markdown：

兼顾可读性与结构化

5410.2.3Pydantic：代码世界的结构化

5510.3结构化的实施层级

5510.4

最佳实践：基于LangChain

官方文档的结构化输出实现

5510.4.1使用ProviderStrategy（原生结构化输出）

...5610.4.2使用ToolStrategy（工具调用策略）

5610.4.3自

定义工具消息内容

..5710.4.4代码分析

58第

11

章上下文工程六大支柱

：检索（Retrieval）

5811.1超越基础向量搜索

5811.2混合搜索：

两全其美的艺术

5911.3重排：从“

粗筛

”到“

精选

”

5911.4查询转换：从“

用户问题

”到“

机器问题

”

6011.5构建一个智能的检索流水线

6011.6

最佳实践：基于LlamaIndex

官方文档的重排实现

6111.6.1使用

SentenceTransformerRerank

6111.6.2使用CohereRerank

6111.6.3使用LLMRerank

6211.6.4使用ColbertRerank

6211.6.5完整的两阶段检索示例

6211.6.6其他有用的后处理器

63第

12

章上下文工程六大支柱

：压缩（Compression）

..6412.1“信息密度”

的挑战

6412.2压缩的两种哲学

：抽取式与抽象式

64

大模型上下文工程指南

12.3抽取式压缩：从“

选择性上下文”

到LLMLingua6412.3.1SelectiveContext：基于信息熵的剪枝

6512.3.2LLMLingua：

用小模型为大模型“

减负

”

6512.4压缩在上下文工程中的位置

6612.5

最佳实践：基于LLMLingua

官方文档的Prompt压缩

6612.5.1安装LLMLingua6612.5.2基础使用

6612.5.3使用不同模型

6712.5.4LongLLMLingua：

长上下文压缩

..6712.5.5LLMLingua-2：

更快更准的压缩

6712.5.6结构化Prompt压缩

6812.5.7SecurityLingua

：安全防护压缩

6812.5.8

完整RAG压缩流程示例

69第

13

章上下文工程六大支柱：编排（Orchestration）

7013.1从“静态管道

”到“

动态决策

”

7013.2编排的核心机制

7013.2.1上下文路由器：智能的“

交通警察

”

.7013.2.2代理式编排

：会思考的“研究员

”

7113.3

LangGraph：

实现代理式编排的利器

7213.4从“

工人”

到“

工头

”

7213.5

最佳实践：基于LangGraph

官方文档的Agent

编排

7313.5.1安装依赖

7313.5.2

完整Agent

示例（基于官方Quickstart）

7313.5.3代码解析

7513.5.4自适应RAG

Agent

示例

75第

14

章上下文工程六大支柱

：评估（Evaluation）

..

7714.1从“

感觉不错

”到“

数据说话

”

7814.2

RAG评估的“

三位一体

”：RAG

三元组

7814.3

RAGAS：自动化评估的利器

7914.4构建你的评估数据集

7914.5评估驱动的开发（EDD）

80

大模型上下文工程指南

14.6从“

艺术

”到“科学

”

8014.7

最佳实践：

用RAGAS

评估一个RAG

流程（基于官方文档）

8114.7.1安装依赖

8114.7.2创建测试数据集

8114.7.3

定义评估指标

8114.7.4运行评估实验

8214.7.5运行评估

8214.7.6结果分析

82第

15

章上下文工程六大支柱

：安全（Security）

...8315.1上下文即“

攻击面

”

8315.2

两大核心威胁：

注入与泄露

8315.2.1提示注入：

系统指令的“

篡位

”

8315.2.2数据泄露：RAG系统的“

阿喀琉斯之踵

”

8415.3工具使用的安全

8415.4安全是底线

8515.5

最佳实践：基于OWASP

官方指南的安全管道实现

8515.5.1输入验证和净化（OWASP官方示例）

8515.5.2结构化Prompt

与清晰分离（OWASP官方示例）

..8615.5.3输出监控和验证（OWASP官方示例）

8715.5.4人工确认控制（OWASP官方示例）

8715.5.5完整安全管道（OWASP官方示例）

8815.5.6使用示例

88第

16

章上下文工程的工具和框架

8916.1数据与存储层

8916.2编排与代理层

9116.3评估与观测层

9316.4操作与部署层

95第

17

章上下文工程未来展望

9717.1从“

无限

”上下文到世界模型：当上下文成为一种“

流

”

9817.1.1“

大海捞针

”的终结与“

上下文学习

”的真正潜力

9817.1.2上下文的“

流

”化：从静态快照到动态世界感知

98

大模型上下文工程指南

17.1.3“

世界模型

”：上下文工程的终极形态

9917.1.4

当前的挑战与未来的路径

9917.2

多模态的融合：当世界不再只是文本

10017.2.1从文本RAG

到多模态RAG（MM-RAG）

..10017.2.2

Agent

架构的演进：从“语言

”到“

感知

”

10117.2.3新的挑战与机遇

10217.3

Agent

的社会化与经济学：从单体智能到协作生态

10217.3.1A2A

协议：Agent

社会的“

法律

”与“语言

”

10317.3.2上下文的“

所有权

”与“

隐私

”

.

10317.3.3Agent

经济学：看不见的手

10417.3.4上下文工程师的新角色

：协议设计师与经济系统分析师

10417.4新时代的“

上下文工程师

”

10517.4.1

变与不变：贯穿始终的核心原则

10517.4.2新时代的“

上下文工程师

”：

一份技能图谱

10517.4.3终点，也是起点

106附录

107参考文献与资源

107术语表

110欢迎来到大模型应用开发的新纪元。曾几何时，我们与大型语言模型（LLM）的互动

，更像是一门“

炼丹术

”。我们小心翼翼地调整着提示词（Prompt）

的每一个字眼，试图通过精妙的语言“咒语

”来“调教

”出一个行为符合预期的模型。这便是“提示工程

”（PromptEngineering）的黄金时代——一个充满了奇技淫巧与个人英雄主义的探索阶段。然而，正如内燃机的发明最终让位于交通系统的构建，我们正处在一个相似的转折点：单纯的“

点火”技巧已不足以支撑未来，构建一个高效、

可靠

、

智能的“

交通网络

”——即上下文系统（Context

System）

——正成为新的核心议题。为什么是“

上下文系统

”？进入2026

年，

一个日益清晰的共识正在形成

：在基础模型能力逐渐趋同的背景下，决定一个AI应用成败的关键，不再仅仅是其背后模型的规模或参数量，而在于它如何工程化地构建

、

管理和经营其上下文

。正如Anthropic

公司的研究所指出的

，构建AI应用的焦点正在从“

寻找正确的词语

”转向一个更宏大的问题：“

什么样的上下文配置最有可能引导模型产生我们期望的行为？

”这标志着一次深刻的范式跃迁。我们不再将模型视为一个被动的、等待指令的黑箱，

而是将其看作一个复杂信息系统中的核心推理引擎

。

这个引擎的燃料

，就是“

上下文”。上下文不仅仅是用户输入的那几句话

，它是模型在做出每一次决策前所能“

看到

”的整个世界

。

这个世界可以包括：即时指令：当前的Prompt

和系统指令。历史记忆：过往的对话

、

用户的偏好与身份。外部知识：通过检索增强生成（RAG）

从数据库

、

文档库中获取的实时信息。可用能力：模型被授权使用的工具（Tools/Skills）及其当前状态。环境状态：

时间

、地点

、任务进度、

乃至整个系统的运行参数。当我们将这些元素作为一个整体来设计、优化和治理时，我们便从“提示工程师

”的角色

，演进为了“

上下文工程师

”（ContextEngineer）或“

上下文架构师

”（Context

Architect）。我们的工作不再是一次性的“

调教

”，而是持续性的“

经营

”——经营一个能让模型持续做出高质量决策的、动态演进的信息生态系统。

1

大模型上下文工程指南前言

大模型上下文工程指南

本指南的核心关切这份《大模型上下文工程（ContextEngineering）指南》

正是为这场正在发生的深刻变革而生

。

它旨在为所有致力于构建高级AI应用的开发者

、

架构师和

产品经理，提供一个全面

、系统且可实践的知识框架。我们将尝试回答以下三个

核

心问题：上下文究竟是什么？

我们将跳出“Token

窗口

”这一狭隘的技术参数，从系统工程的视角重新定义上下文，并梳理其从静态输入到分布式系统状态的演进

脉络。如何工程化地构建

、

管理和治理上下文？我们将深入探讨上下文工程的四大核心组件（Prompt,Skills,MCP,

A2A）和六大方法论支柱，

为您提供一套从建

模

、获取、编排到安全治理的完整操作手册。如何落地一个可演进的上下文工程系统？我们将剖析当前主流的工具与框架生态。作为国内领先的

AI模型开发服务平台，算泥社区秉持“

技术专业

、态

开放

、开发者友好

”的理念，联合社区众多资深分析师与技术专家

、学者，共同撰写并发布《大模型上下文工程（ContextEngineering）指南》。我们深信，未来属于那些能够驾驭上下文的团队。他们将不再仅仅是模型的

使用者，而是上下文系统的创造者和经营者。对于有开发需求的团队或个人，算

泥社区平台通过整合国产异构算资源，

为开发者提供了经济效的算选择。现在

，就让我们一同开启这段探索之旅，从“

调教模型

”的艺术，迈向“

经

营上下文系统

”的科学与工程。第

1

章

上下文的重新定义在大型语言模型（LLM）

的世界里，“

上下文

”（Context）

是一个无处不在却又极易被误解的核心概念。长期以来，它被简单地等同于模型的“

上下文窗

口

”（ContextWindow）

，一个衡量模型一次性可以处理多少文本（

以Token

计

算）

的技术参数

。

然而，

随着LLM

从实验室走向千行百业的复杂应用，这种狭

隘的定义已然成为我们构建更强大

、

更智能系统的思想枷锁

。要真正释放AI

的

潜力，我们必须首先打破这个枷锁，

重新认识上下文的广阔内涵。1.1狭义上下文：TokenWindow作为“

技术参数

”的时代2

大模型上下文工程指南

在LLM

发展的早期

，特别是以GPT-3

为代表的时代，模型的上下文窗口是

其能力最显著的瓶颈之一。一个2k

或4k

的窗口，意味着模型在生成下一个词时

，

只能“

看到

”紧邻的几千个Token

。这就像一个记忆力只有几分钟的对话者，

虽然能在短时间内展现出惊人的语言天赋，但稍微复杂的任务、稍长一些的对话

，

就会让他“

忘掉

”

了开头

，迷失了目标。在这个阶段，所谓的“

上下文工程

”几乎等同于“

窗口

管理术

”。开发者们绞尽脑汁，

试图在有限的窗口

空间内，

塞进最有价值的信息

。

这催生了PromptEngineering

的繁荣，

其核心任务之一就是在给定的Token

预算下，设计出最高

效的指令和示例。上下文是一个被动的

、需要被精打细算的技术约束，而非一个可以主动设计和利用的战略资源。1.2广义上下文：迈向系统状态的整体视角真正的变革，源于我们将视角从“模型能看到什么

”转向“

系统能感知和利用什么

”。一个先进的AI应用，

其智能不仅仅来自模型本身，

更来自它所嵌入的整个信息系统。在这个系统中，上下文是驱动模型决策的全部信息流的总和

。它是

一个动态的

、多层次的

、结构化的系统状态。我们可以将广义上下文解构为以下五个核心

类别：上下文类别核

心定义关键要素作用与价值文本上下文模型直接处理的文本信息流Prompt

、系统指令

、

历史对话

、Few-shot

示例

、RAG

检索结果构成模型推理的直接输入和工作记忆，是所有上下文的基础。环境上下文AI

智

能

体任务状态

、会话

Session

、

时赋予模型“

此时此地

”的感知31.2.1

文本上下文（TextualContext）这是最基础

、最直接的上下文

。它构成了模型“

工作记忆

”的全部内容，是所有推理和生成任务的起点

。

它不仅包括用户当前的提问（Prompt），还包括：系统指令（SystemPrompt）：

定义了AI

的基本角色

、性格、

能力边界和行为准则。历史对话（ConversationHistory）：确保多轮交互的连贯性。Few-shot

示例：通过具体的例子向模型演示任务要求。RAG

检索内容：从外部知识库动态获取的

、与当前问题最相关的信息片段。1.2.2环境上下文（EnvironmentalContext）如果说文本上下文是AI

的“

内在思想

”

，那么环境上下文就是它对“

外部世界”

的感知

。

它让AI

的行为不再是孤立的文本生成，

而是与真实世界状态绑定的行动

。例如，

一个智能客服Agent

需要知道：任务状态：

当前是在“

识别问题

”、“

查询订单

”还是“

处理退款

”阶段？会话

Session：当前会话的ID，

关联的技术日

志，

用户的等待时长。时间与地点：现在是工作时间还是非工作时间？

用户位于哪个时区？工具状态：

支付API

是否可用？

物流查询接口

的响应延迟是多少？1.2.3

用户上下文（UserContext）用户上下文是个性化体验的核心。它将AI

从一个对所有人都说一样话的“通用模型

”，转变为一个懂你的“

专属顾问

”。这需要系统能够持续地学习和更新关于用户的一切：身份与角色：他是普通用户

、VIP

客户，还是内部管理员？偏好与习惯：他喜欢简洁的回答还是详尽的解释？

他常用的功能是什么？所处的动态环境状态间/地点、工具/API

的实时状态能力，使其行为与外部世界同步。用户上下文关于交互对象的个性化信息身份、偏好

、角色

、

权限

、历史行为

、

情绪状态实现从“

通用助手

”到“

私人助理

”的跃迁，提供高度个性化的体验。系统上下文AI系

统

自身的技术与能力配置模型版本

、

可用工具列表

、协议规范（如MCP/A2A）

、运行参数让模型了解“自己是谁

、能做什么

”，是实现自主规划和可靠执行的前提。组织上下文特定领域或机构的专有知识与规则内部知识库

、

业务流程

、

合规策略

、

行业术语

、

组织架构使模型能够融入企业环境，成为理解并遵守特定规则的“领域专家

”。

大模型上下文工程指南

4

大模型上下文工程指南

历史行为：他过去购买过什么？

浏览过哪些页面？提过哪些问题？情绪状态：从他的用词和语气中，能判断出他当前是满意

、焦虑还是愤怒？1.2.4

系统上下文（SystemContext）系统上下文是AI

的“自我认知”

。

它需要清楚地知道自己作为一个软件实体的配置和能力

。

这对于构建能够自主规划和执行复杂任务的Agent

至关重要。模型版本：

我是基于GPT-4.1-Turbo

还是

Sonnet-4.5？

我的知识截止日期是

什么？可用工具（Skills/Plugins）：我能调用哪些API？每个API

的参数和功能是

什么？协议规范（Protocols）

：我应该如何通过模型上下文协议（MCP）与其他服

务交互？

我应该如何通过智能体间协议（A2A）

与其他Agent

协作？运行参数：我的Token

生成速率限制是多少？当前的安全过滤级别是什么？1.2.5组织上下文（OrganizationalContext）当AI

被部署在企业环境中时，

它必须成为组织的一员，理解并遵守其独特的知识

、

流程和规则

。

组织上下文就是AI

的“

入职培训材料

”。知识库

：公司内部的Wiki、产品文档

、

最佳实践案例。流程与制度：如何创建一个工单？

一个退款请求需要经过哪些审批？合规策略：哪些客户数据是敏感信息，绝对不能在日志中记录？

与客户沟通

时

，有哪些必须声明的法律条款？行业术语：在本行业，“SLA”

、“ARR”分别指什么？1.3

范式跃迁：从被动输入到主动经营将上下文从狭义的“Token

窗口

”扩展到广义的“

系统状态

”，带来的绝不仅仅是概念上的丰富，

而是一场深刻的开发范式革命。这场跃迁意味着，我们的核心工作不再是“

写出完美的Prompt”，而是“

设计一个能为模型持续提供完美上下文的系统

”。这个系统能够动态地从不同来源拉取信息，根据任务进展更新其状态，依据用户身份调整其行为，并严格遵守安5回顾这段历史，我们可以清晰地看到三次关键的范式飞跃，每一次都极大地扩展了我们对“

上下文”

的认知边界和应用深度。2.1静态输入窗

口

时代（2017–2022）：PromptEngineering

的黄金年代2.1.1一切的起点：Transformer

与有限的注意力2017

年，

一篇名为《Attention

IsAllYouNeed》的论文横空出世，

宣告了

Transformer

架构的诞生

。

它彻底摒弃了之前在自然语言处理领域占主导地位的循环（Recurrence）

和卷积（Convolution）

结构，

完全基于“自

注意力机制

”

（Self-Attention）

来构建模型

。这一设计的核心思想是，在处理一个序列（如

一个句子）

时

，模型中的每个元素都可以直接“

关注

”到序列中的任何其他元素

，并根据相关性权重来计算其表示。这种架构带来了无与伦比的并行计算能力，使得训练更大、更深的模型成为可能，

为后来GPT系列等巨型模型的出现铺平了道路

。

然而，

它也带来了一个

大模型上下文工程指南

全与合规的边界。这，就是上下文工程的真正要义，也是通往更高级别人工智能的必由之路。第

2

章

历史脉络：

上下文技术的三次飞跃上下文工程并非一日建成，

它的演进与大型语言模型自身的发展紧密相连，是一部从“

螺蛳壳里做道场

”的精巧技艺，走向构建宏大

、复杂信息系统的工程

科学史。6

大模型上下文工程指南

与生俱来的“原罪

”

：有限的上下文窗口。自注意力机制的计算复杂度与序列长度（即上下文窗口大小）的平方成正比

(O(n²))

。

这意味着，上下文窗口每扩大一倍，计算量和内存占用就会增长四倍

。

这个二

次方的“

诅咒

”使得早期的Transformer模型

，如BERT

和GPT-2，

其上

下文窗口通常被限制在

512

或

1024

个Token

。

这便是“静态输入窗口

时代

”的技术底色——上下文是一个宝贵但极其有限的资源。2.1.2GPT-3

的惊鸿一瞥：In-ContextLearning

的魔力2020

年，OpenAI

发布了拥有

1750亿参数的GPT-3，并在一篇题为《LanguageModelsareFew-ShotLearners》

的论文中，揭示了一种名为“

上下文学习

”的惊

人能力。在此之前

，让模型学会一个新任务

，通常需要“微调

”（Fine-tuning）——

用成千上万个标注好的新数据来更新模型的权重

。

而GPT-3展示了，无需任何

权重更新，仅仅通过在Prompt

中提供几个任务示例（shots），模型就能“

凭空

”学会执行这个新任务

。例如

，要让它做法语到英语的翻译，

你只需要在Prompt

里这样写：模型就会在“cheese=>

”后面

，神奇地补完“fromage

”。

它仿佛从这几个例子中“领悟

”到了翻译任务的模式

。

这种能力，

就是In-ContextLearning

。

它极大地改变了人们与模型互动的方式，使得“

调教

”模型变得前所未有的简单和即时。ICL

的发现，直接催生了“提示工程

”（PromptEngineering）

的黄金时代。开发者和研究者们的热情被瞬间点燃，

大家开始疯狂探索如何通过设计不同的Prompt

来激发模型的潜能

。

从简单的角色扮演（

“

你现在是一个莎士比亚风格的诗人

…

”）

到后来的思维链（Chain-of-Thought,CoT）

，提示工程变成了一门显学。2.1.3黄金期的局限：PromptEngineering

的根本困境7

大模型上下文工程指南

然而，在繁荣之下，PromptEngineering

的根本局限也日益凸显

。这些局限，本质上都源于其所依赖的“静态输入窗口

”。脆弱性与不稳定性：Prompt

的效果对措辞

、格式甚至标点符号都极为敏感。同一个意思的细微表述差异，可能导致模型输出质量的天壤之别。这使得Prompt的开发过程充满了

大量的试错

，缺乏工程上的确定性和可复现性。知识的静态性：Prompt

中的知识是“

一次性

”的

。

它无法连接到实时变化的世界

。如果你的知识库更新了，你必须手动去修改所有相关的Prompt

。

它也

无法处理需要外部数据库或API

才能回答的问题。任务复杂度的天花板：对于需要多步骤

、多工具协作的复杂任务，单靠一个

Prompt很难进行清晰的规划和状态管理

。

随着任务逻辑变长，Prompt

会变得臃

肿不堪

，很快就会撑爆有限的上下文窗口，

并且极难维护。缺乏记忆与个性化

：静态的Prompt

是无状态的

。

它无法记忆用户之前的偏

好，也无法在跨会话的交互中积累知识

。每一次交互都是一次“

冷启动

”，这使

得提供真正个性化的

、持续的服务成为泡影。研究和实践都表明，单纯的提示工程存在明显的性能上限

。当一个任务超出了模型在预训练阶段所“内化

”的能力范畴，无论你如何精心设计Prompt

，模

型都无法完成。就如同一项研究指出的，如果模型没有真正学会某项任务，任何

提示都无法让它执行。正是在这些深刻的痛点驱动下，社区开始意识到，我们不能永远在螺蛳壳里

做道场

。我们需要的不是更精巧的“

咒语

”，而是能够突破静态窗口限制

、连接

外部世界、管理复杂状态的全新方法论。上下文技术的第一次飞跃虽然辉煌，但

它的历史使命已经接近终点

。

一场向着更广阔天地的探索，

即将拉开序幕。2.2

长上下文窗

口

竞赛（2022–2024）：从“

寸土寸金

”到“

军备竞赛

”随着PromptEngineering

的局限性日益暴露，业界和学术界都意识到

，要让

LLM

处理更复杂的任务，必须打破那个该死的O(n²)计算瓶颈，从根本上扩大上

下文窗口

。

于是，

一场围绕“

长上下文”

的技术军备竞赛在2022

年左右拉开帷

幕。这场竞赛的目标非常明确：在保持（甚至提升）模型性能的同时

，用更高效

的算法将上下文窗口从几千个Token

，推向几万

、几十万，

乃至百万级别

。这标8

大模型上下文工程指南

志着上下文技术的一次重大飞跃，

其核心驱动力来自一系列对Transformer

底层架构的精妙改造。2.2.1解除封印：

突破二

次方诅咒的关键技术众多技术创新共同促成了长上下文的实现，其中最具代表性的可以分为三类：高效的注意力算法（Efficient

AttentionAlgorithms）FlashAttention：2022

年

，斯坦福大学的研究者提出了FlashAttention，

这可

以说是长上下文革命的“

引爆点

”。它本身并没有改变注意力的计算逻辑，但通

过一种“IO

感知

”（IO-aware）

的设计

，极大地优化了GPU

显存（HBM）

的读

写方式

。它利用tiling（分块）技术

，将巨大的注意力矩阵拆分成小块进行计算

，

从而显著减少了数据在不同层级内存之间的移动次数。这使得完全相同的注意力

计算，速度提升了数倍，内存占用却大幅降低

。FlashAttention

的出现，

让之前

因为算力限制而不敢尝试的更长上下文长度，

变得触手可及。更聪明的“位置编码

”（SmarterPositionalEmbeddings）传统的Transformer

需要明确地为每个Token

注入其在序列中的绝对或相对位置信息，这被称为位置编码。但当序列变得非常长时

，旧的位置编码方法会失

效

。

为了解决这个问题

，新的方法应运而生。旋转位置编码（RotaryPositionEmbedding,RoPE）

：由Google在2021

年提

出，RoPE

通过一种巧妙的数学变换，将位置信息编码到了Query

和Key

向量的

“相位

”

中

。

它的优点是具有良好的外推性（extrapolation），

即在比训练时更

长的序列上也能保持较好的性能，

因此被Llama

等众多主流模型采用。线性偏置注意力（AttentionwithLinearBiases,ALiBi）：

由MetaAI在2021

年提出，ALiBi

更加简单直接。它完全抛弃了在词嵌入阶段添加位置编码的做法

，

而是在计算注意力分数时，直接给每个分数加上一个与Token

之间距离成正比的

“

惩罚项

”（一个负的偏置）。距离越远的Token

对

，惩罚越大

。这种设计天然

地赋予了模型一种“

关注就近

”的归纳偏置，并且外推能力极强

，即使在比训练长度长得多的序列上也能稳定工作。稀疏注意力（Sparse

Attention）另一条思路是

，既然完全的“

全局注意力

”计算量太大，我们是否可以让每

个Token

只关注一部分“

重要

”的邻居？

这就是稀疏注意力的核心思想

。例如

，

Longformer

结合了局部窗口注意力和全局注意力，让每个Token

关注附近的几

个词，以及少数几个被设定为“全局重要

”的词。BigBird

则引入了随机注意力，

9

大模型上下文工程指南

让每个Token

再额外随机关注几个词。这些方法在特定任务上取得了成功，但因为其“

稀疏

”的假设，通用性不如前两类方法。2.2.2从

1k

到

1M：Token

窗

口

的“

通货膨胀

”在这些技术的加持下，上下文窗口

的长度开始了一场惊人的“

通货膨胀

”。2023

年初，

主流模型的上下文窗口还在4k-8k

的范围。Anthropic

的Claude

率先将窗口扩大到

100k。不久，Google在其Gemini

1.5Pro

中展示了惊人的

100

万Token

上下文窗口

，

并成功通过了“

大海捞针

”（NeedleinaHaystack）

测试——即在百万级别的文

本中，

准确地找到并利用一个被刻意隐藏的“针

”（一个特定的事实）。随后，

几乎所有主流模型提供商都迅速跟进，

128k

、200k

甚至更长的上下文窗口成为了旗舰模型的标配。上下文似乎在一夜之间从“

稀缺资源

”变成了“

无限供应

”的商品

。这极大

地扩展了LLM

的应用场景

，例如直接处理一整本书

、分析数百页的财报、

或者

消化整个代码库。2.2.3“

长

”的代价：上下文腐烂与注意力稀释然而，看似无限风光的长上下文，很快也暴露出了其固有的问题。窗口

变长，并不意味着模型能同等有效地利用所有信息。一个核心问题浮出水面——上下文腐烂（ContextRot），也常被称为“

注意力稀释

”（AttentionDilution）

或“

迷

失在中间

”（LostintheMiddle）

现象。研究者们通过“

大海捞针

”测试发现，模型能否找到“针

”，很大程度上取决于“针

”在上下文草堆中的位置。当信息位于上下文的开头或结尾时

，模型的召回率非常高。然而，当信息被放置在上下文的中间部分时，模型的性能会急剧下降，仿佛

“忘记

”

了那里的内容。这种现象揭示了长上下文的一个残酷真相：更长的上下文并不等于更强的理

解力。仅仅扩大窗口，而不优化信息的组织和利用方式，就像给一个学生发了

一

堆没有重点的复习材料，他很可能会“

划重点

”式地只记住开头和结尾

。

过量

、

未经处理的上下文信息，反而会“

稀释”掉模型的注意力，使得关键信息被淹没

在噪声之中。长上下文竞赛的实践，让我们深刻地认识到上下文工程的第二个真理：上下10

大模型上下文工程指南

文的质量，远比其数量重要

。简单粗暴地堆砌信息是行不通的。如何在一个巨大的窗口

中

，结构化地组织信息，突出重点，

引导模型的注意力，成为了新的

、更

高级的挑战。这直接催生了上下文技术的第三次飞跃——从依赖“内置

”的短期记忆

，转向构建“

外置

”的

、

可持久化的长期记忆系统。2.3外部记忆与

RAG

的兴起（2023–2025）：解耦计算与存储长上下文竞赛很快让业界达成一个共识：仅仅扩大模型的“

工作记忆

”（即

上下文窗口）是远远不够的

。一个真正智能的系统

，不能只依赖于短暂

、易

失的

在场信息，它还需要一个庞大

、持久

、可检索的“

长期记忆

”。这一需求，催生

了上下文技术的第三次、也是迄今为止影响最为深远的一次飞跃——外部记忆与检索增强生成（Retrieval-AugmentedGeneration,RAG）

的全面兴起。2.3.1RAG

的核心思想：解耦“

计算

”与“存储”RAG

的理念，

最早在2020

年由

Facebook

AI（现MetaAI）

的研究者提出

，

但直到2023

年，

随着LLM

应用的爆发，

它才真正成为主流

。

其核心思想优雅

而强大：将大型语言模型的“

计算

”（推理能力）与“存储

”（知识）彻底解耦。在RAG

出现之前，我们试图将全世界的知识都“

塞

”进模型的参数里，通过不断增大模型规模来提升其“

博学

”程度

。

这种方式的弊端显而易见：知识更新困难：模型一旦训练完成，其内部知识就被固化。要更新知识，就

必须进行成本高昂的重新训练。事实不可靠：模型在回答时，本质上是在进行“有根据的猜测

”，这很容易

导致“

幻觉

”（Hallucination），

即一本正经地编造事实。缺乏透明度：我们无从知晓模型是根据哪个知识来源给出的答案，无法进行事实核查和溯源。RAG彻底改变了这一模式

。

它不再强求模型“

记住

”一切，

而是将模型定位为一个开放式的推理引擎，将知识存储在外部的

、可随时更新的知识库中（通

常是向量数据库）

。当一个问题到来时，RAG

系统的工作流程如下：1.检索（Retrieve）：

首先，

用用户的查询去知识库中检索最相关的信息片段。2.增强（Augment）：

然后，将这些检索到的信息片段，

连同用户的原始问题，

一同“

增强

”到给模型的Prompt

中。3.

生成（Generate）：

最后

，要求模型基于提供的上下文信息来生成答案。11

大模型上下文工程指南

这个简单的流程

，却带来了革命性的变化：知识变得可插拔、

可更新：我们只需更新外部知识库，

就能实时更新AI

的

知识，

而无需触动模型本身。答案变得有据可查：系统可以明确地告诉用户，答案是基于哪些文档或数据

生成的，

大大提升了可靠性和透明度。成本效益更高：我们可以用一个相对较小的模型，通过外挂一个庞大的知识

库，

来达到甚至超过一个巨型模型的知识能力。2.3.2MemGPT：像操作系统一样管理上下文如果说RAG

为模型外挂了“

长期记忆

”的硬盘，那

么MemGPT

则为模型

设计了一套先进的“内存管理系统

”。2023

年

，加州大学伯克利分校的研究者

提出了MemGPT，

其灵感直接来源于计算机的操作系统。操作系统通过“虚拟内存

”机制，让程序感觉自己拥有比物理内存大得多的

内存空间

。

它会自动地在高速但昂贵的物理内存（RAM）

和低速但廉价的硬盘

（Disk）之间，

来回“

换页

”（Paging），将当前最需要的数据放入内存，将暂

时不用的数据存回硬盘。MemGPT

将这一思想引入了LLM

的上下文管理。它将模型的上下文窗口视

为有限的“物理内存

”，将外部的向量数据库或文件系统视为无限的“虚拟内存

”。MemGPT

赋予了LLM

一种“

元认知

”能力，让模型自己来决定：何时将信息从主上下文（物理内存）中移出，进行摘要或归档，存入外部的

长期记忆（虚拟内存）。何时需要从长期记忆中检索关键信息，调入主上下文，

以辅助当前的任务。如何与用户互动，以确认哪些信息是重要的

，值得被长期记住。通过这种方式，MemGPT

让LLM

的上下文管理变得像操作系统一样智能和

高效

。它不再被动地接收信息

，而是主动地

、分层地管理自己的记忆，从而在理

论上实现了“

无限上下文”

的能力，

即便其物理上下文窗口是有限的。2.3.3持久化上下文的黎明RAG

和MemGPT

的兴起，标志着用户上下文和组织上下文终于进入了“

可持久化

、可检索

”的长期记忆层。这意味着AI应用第一次有可能构建起真正的

、

跨越时空的记忆。对于个人用户：AI

助手可以记住你几周前的工作内容、你的长期目标

、你12

大模型上下文工程指南

的沟通偏好，从而提供真正连贯和个性化的辅助。对于组织：AI

系统可以沉淀每一次客户服务的经验、每一个项目

的决策过

程、每一个团队成员的专业知识，形成一个动态演进

、人人可用的“

组织大脑

”。上下文不再是一次性交互中的匆匆过客，

而是可以被系统性地捕获

、存储

、

检索和利用的宝贵资产

。上下文技术的重心，从“如何塞满窗口

”和“如何扩大

窗口

”，

演进到了“如何构建和运营一个高效的记忆系统

”。

这为即将到来的

、更高级的智能体时代，奠定了至关重要的基础。2.4智能体与协议化上下文（2025–2026）：上下文成为主动的、分布式的系统状态网络随着RAG

和记忆系统的成熟，上下文技术正迎来其第四次

、也是最具颠覆

性的飞跃：

智能体（Agent）

的普及与上下文的协议化

。如果说前三次飞跃的核

心是“如何让一个模型看到更多

、记得更牢

”，那么这一次飞跃的核心

则是“如

何让众多能够看见和记忆的智能体

，安全

、

高效地协同工作

”。

上下文的定义

，

也因此从单个模型的信息输入，

演进为整个分布式智能系统中的主动状态网络。2.4.1智能体：上下文的终极载体一个AI

智能体（Agent）的本质，是一个能够自

主感知环境

、制定计划

、执行动作以达成目标的系统。在这个定义下，上下文构成了智能体存在的全部基础

。

一个智能体的上下文，可以被精确地定义为其在某一时刻的完整状态描述，它至

少包含：目标（Goal）：我被要求完成什么？

最终的成功状态是怎样的？状态（State）：为了达成目标，我已经完成了哪些步骤？当前卡在哪一步？环境（Environment）：

我能感知到的外部世界是怎样的？

时间

、

用户

、

可

用资源有何变化？能力（Capabilities）：我能调用哪些工具（Skills）？每个工具的用途和限制

是什么？这种“

上下文即智能体

”的视角，意味着上下文管理不再仅仅是为模型“

准

备资料

”，而是要动态地

、结构化地维护智能体完成任务所需的全套信息

。这要

求上下文本身是主动的

、

结构化的，

并且是可被机器读写的。2.4.2MCP：标准化“

单智能体如何接入世界”当每个开发者都用自己的方式为智能体提供工具和数据时，整个生态是混乱

13

大模型上下文工程指南

且不可扩展的

。

为了解决这个问题，模型上下文协议（ModelContextProtocol,

MCP）应运而生

。MCP

由Anthropic

等公司在2024

年底倡导，旨在为“模型如何与外部工具/数据源交互

”提供一个开放的标准。MCP

的核心，是定义了一套标准的“语言

”，让任何外部资源（如一个API、一个数据库、一个知识库）都能将自己的能力“自我描述

”清楚。这种描述（Schema）包含了：能力是什么

：工具的功能描述。如何使用：调用该工具所需的参数和格式。能得到什么

：工具返回结果的结构。通过MCP，

一个智能体在需要使用工具时，

不再需要开发者为其硬编码

一

套特定的调用逻辑

。

智能体可以直接“

阅读

”MCP

服务器提供的能力清单，

然

后自主决定调用哪个工具、如何传递参数。这使得外部世界的所有资源，都能以

一种标准化的方式

，动态地成为智能体上下文的一部分

。MCP

的出现

，标志着系统上下文和环境上下文开始被标准化和协议化。2.4.3A2A：标准化“

多智能体如何互联

”如果说MCP

解决了单个智能体“

接入世界

”

的问题，

那么智能体间协议（Agent-to-Agent,

A2A）则致力于解决“

智能体之间如何协作

”的难题。A2A

协

议由Google

等公司在2025

年提出，其目标是创建一个智能体的“

互联网

”，让

不同公司

、

不同平台开发的智能体能够互相发现

、

沟通和协作。A2A