MCP 协议与 Context Engineering：大模型 Agent 的记忆管理从 RAG 走向工程化

Wed, 08 Jul 2026 18:00:00 +0800

上下文不是塞进去就行的

大模型 Agent 的能力上限，不取决于模型本身有多强，而取决于你喂给它的上下文有多好。这句话听起来像废话，但真正把它想透并做成工程的人，少之又少。

过去两年，行业里最流行的上下文管理方案就是 RAG——往 Prompt 里塞检索到的文本片段，祈祷模型能自己拼出答案。这条路走到今天，瓶颈已经非常明显：检索回来的东西越来越多，Prompt 越来越长，模型反而越来越"迷糊"。

MCP（Model Context Protocol）协议的出现，标志着行业开始认真对待一个被长期忽视的问题：上下文不是越多越好，它需要被工程化管理。

从 Prompt Engineering 到 Context Engineering

一个被低估的转变

2023 年，几乎所有人都在聊 Prompt Engineering。怎么写指令、怎么设计 Few-shot 示例、怎么用 Chain-of-Thought 引导模型推理。这些技巧当然有用，但它们解决的是"怎么跟模型说话"的问题。

到了 2025 年，一个更根本的问题浮出水面：你给模型的"背景信息"本身，该怎么设计？

这不是文字游戏。Prompt 是你对模型说的话，Context 是模型在回答之前"看到"的全部信息。一个典型的 Agent 对话中，Prompt 可能只占 token 总量的 5%，剩下 95% 全是上下文——系统提示、历史对话、工具返回结果、检索片段、用户画像……

如果说 Prompt Engineering 是"写一封好邮件"，那 Context Engineering 就是"设计整个邮件系统的信息架构"。前者是手艺，后者是工程。

为什么 RAG 不够用

RAG 本质上是一种"暴力填充上下文"的策略。用户问了问题，去向量库搜几段文本，拼进去。这个方案在 2023 年很好用，因为当时模型上下文窗口短（4K-8K），检索回来的 3-5 段文本刚好能填满。

但到了 2026 年，主流模型的上下文窗口已经到了 128K 甚至 1M token。窗口变大带来的不是便利，而是新问题：

问题	表现	后果
信息过载	塞了 50 段检索结果	模型注意力分散，关键信息被淹没
来源混乱	文档、API、数据库混在一起	模型无法区分信息可信度
时序错乱	新旧信息混排	模型用过期数据回答当前问题
缺乏结构	全是平铺的文本块	模型无法理解信息之间的关系

一个具体的例子：让 Agent 回答"这个客户上周提的工单解决了吗"。RAG 可能检索到 10 段工单记录，但哪些是上周的、哪些是已解决的、哪些跟这个客户有关——这些判断全部丢给模型去做。模型有时候能做对，有时候不能。

这就是 Context Engineering 要解决的核心问题：不是"检索什么"，而是"怎么把检索到的东西组织成模型能高效理解的格式"。

MCP 协议：给上下文一个标准化的"容器"

MCP 到底做了什么

Model Context Protocol 最早由头部 AI 公司在 2024 年底开源，迅速成为 Agent 生态中事实上的标准协议。它解决的核心问题很简单：让 Agent 能以标准化的方式访问外部数据源和工具，而不需要为每个数据源写一套适配代码。

MCP 的架构分三层：

Host：Agent 运行时本身，负责发起上下文请求
Client：与 Server 保持 1:1 连接的协议层
Server：对外暴露 Resources、Tools、Prompts 三类能力

1
2
3
4
5


Agent (Host)
 ├── MCP Client ──── MCP Server (文件系统)
 ├── MCP Client ──── MCP Server (数据库)
 ├── MCP Client ──── MCP Server (CRM 系统)
 └── MCP Client ──── MCP Server (代码仓库)

这个设计看起来平平无奇，但它隐含了一个非常重要的理念：上下文是有来源的，每个来源有自己的结构和语义，不应该被拍扁成一段纯文本塞进 Prompt。

Resources 不是文本片段

MCP 协议中"Resources"这个概念值得特别关注。在传统 RAG 中，检索回来的就是一个字符串——一段文本。但在 MCP 中，一个 Resource 可以携带丰富的元数据：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


{
 "uri": "crm://customer/12345/tickets",
 "name": "客户工单记录",
 "mimeType": "application/json",
 "metadata": {
 "source": "CRM系统",
 "lastUpdated": "2026-07-07T14:30:00Z",
 "confidence": "high",
 "accessLevel": "internal"
 }
}

这段元数据告诉模型：这个数据来自 CRM 系统、昨天刚更新过、可信度高、属于内部数据。模型在生成回答时可以参考这些信息来调整自己的回答策略——比如对高可信度数据可以直接引用，对低可信度数据需要加限定词。

RAG 给你一段文字，MCP 给你一段"有身份的文字"。 这就是结构化上下文和纯文本上下文的根本区别。

Tools 让上下文变成动态的

MCP 的另一个关键设计是 Tools。传统 RAG 中，检索是"被动的"——用户问了问题，系统去搜。但 MCP 的 Tools 允许 Agent 主动发起查询：

Agent 发现用户提到了一个客户名，主动调用 CRM 工具拉取客户画像
Agent 判断需要验证一个数据点，调用计算工具做一次交叉验证
Agent 意识到信息不够，调用搜索工具补充更多背景

这意味着上下文不再是"一次性注入"的，而是 Agent 在推理过程中按需获取、动态构建的。

三种记忆架构：从"金鱼记忆"到"长期伙伴"

聊完 MCP 协议，我们把视角拉高一层。Agent 的记忆管理不只是"怎么检索"的问题，它涉及整个记忆架构的设计。目前行业里主要有三种流派，各有取舍。

架构一：无状态 + 外部检索（RAG 模式）

这是最常见的方案。Agent 本身不保留任何记忆，每次对话都是"从零开始"，需要的信息全部从外部系统检索。

优势：实现简单，不依赖特定模型能力，容易做水平扩展。

劣势：每次对话都要重新"认识"用户。对话了 100 次，第 101 次 Agent 还是不认识你。

1
2
3


用户提问 → [Agent 无记忆] → 检索外部知识库 → 拼装上下文 → 生成回答
 ↑
 每次都从头来

这种架构适合"一次性问答"场景——比如客服机器人、知识库搜索。但不适合需要长期交互的场景，比如个人助理、编程助手。

架构二：滑动窗口 + 摘要压缩（对话记忆模式）

这是多数聊天机器人的做法。保留最近 N 轮对话的完整记录，更早的对话压缩成摘要。

优势：能维持短期对话连贯性，实现成本低。

劣势：摘要过程不可避免地丢失信息。而且"最近 N 轮"这个窗口是人为设定的，经常把重要信息截断。

一个典型的问题：用户第一天说了"我对花生过敏"，这个信息在第三天就被摘要压缩成了"用户提到了一些健康相关的偏好"。到第五天，可能连摘要都被丢弃了。

时间	对话内容	保留状态
第1天	“我对花生过敏”	完整保留 → 摘要 → 丢弃
第2天	“帮我订个餐厅”	完整保留 → 摘要 → 丢弃
第3天	“推荐个菜谱”	完整保留 → 摘要
第5天	“做个泰式沙拉”	完整保留

到了第 5 天，Agent 可能给你推荐了一个含花生的菜谱。不是它"忘了"，而是摘要系统把关键细节丢了。

架构三：结构化长期记忆 + MCP（Context Engineering 模式）

这是 2025-2026 年逐渐成熟的新方案。核心思路是把 Agent 的记忆分成多个层级，用结构化的方式存储，通过 MCP 等协议动态加载。

1
2
3
4
5
6
7
8
9


┌─────────────────────────────────────┐
│ 工作记忆 (Working Memory) │ ← 当前对话上下文
├─────────────────────────────────────┤
│ 短期记忆 (Session Memory) │ ← 本次会话累积的信息
├─────────────────────────────────────┤
│ 长期记忆 (Persistent Memory) │ ← 跨会话的用户画像/偏好/事实
├─────────────────────────────────────┤
│ 知识记忆 (Knowledge Memory) │ ← 外部知识库、文档、数据
└─────────────────────────────────────┘

每一层记忆有不同的生命周期和更新策略：

工作记忆：当前对话窗口，对话结束即清空
短期记忆：一次会话内有效，用于跟踪对话中的临时状态
长期记忆：持久化存储，记录用户偏好、历史决策、关键事实
知识记忆：通过 MCP 连接外部数据源，按需检索

这种架构的关键创新在于记忆不是被动存储的，而是主动管理的。Agent 会在对话过程中判断哪些信息值得"升级"到长期记忆，哪些可以丢弃。

举个例子，用户说"我以后都用 TypeScript 写代码"。在传统对话记忆模式下，这句话就是一段聊天记录。在结构化长期记忆模式下，Agent 会：

识别出这是一个"偏好声明"
提取结构化信息：{type: "preference", domain: "coding", key: "language", value: "TypeScript"}
写入长期记忆存储
后续所有涉及编程的对话，自动加载这个偏好

Context Engineering 的工程化落地

理念聊完了，说说怎么落地。Context Engineering 不是写几篇文档就能搞定的事情，它需要一整套工程体系来支撑。

第一步：上下文的分层与路由

不是所有上下文都该进 Prompt。一个成熟的 Context Engineering 系统，会先对上下文做分层：

必须层：系统指令、安全约束、当前任务描述——每次都带
高优层：用户画像、当前会话状态——大部分时候带
按需层：通过 MCP 获取的外部数据——Agent 判断需要时才加载
背景层：历史对话、相关知识——空间够的时候才带

分层之后，需要一个"上下文路由器"来决定每次调用模型时，到底装哪些信息进去。这个路由器的决策逻辑可以是规则驱动的，也可以是小模型驱动的。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


上下文路由器伪逻辑：
 available_tokens = max_tokens - prompt_tokens - reserved_output_tokens

 必须层 → 无条件装入 （约 500 tokens）
 高优层 → 无条件装入 （约 1500 tokens）

 remaining = available_tokens - 已用

 按需层 → Agent 通过 MCP Tools 请求的数据，按相关性排序装入
 背景层 → 剩余空间按时间衰减 + 相关性加权装入

第二步：MCP Server 的设计原则

搭 MCP Server 不是写个 API 适配器就完事了。有几个工程原则直接影响 Agent 的上下文质量：

原则一：返回结构化数据，不要返回渲染好的文本。

很多团队图省事，MCP Server 直接返回拼好的字符串。这是大忌。结构化数据让 Agent 有选择地提取信息，拼好的文本只能全盘接收。

1
2


❌ 错误做法：返回 "客户张三，手机号138xxxx，上月消费5000元，VIP等级金卡"
✅ 正确做法：返回 {name: "张三", phone: "138xxxx", lastMonthSpend: 5000, vipLevel: "gold"}

原则二：提供分页和过滤能力。

一个 MCP Server 可能连接了百万级数据。如果 Agent 请求"所有客户工单"，不能真的把全量数据返回。Server 端必须支持过滤条件、分页、排序，让 Agent 能精确获取需要的子集。

原则三：暴露数据的"新鲜度"。

每条数据都应该带上最后更新时间。Agent 在构建上下文时，可以优先使用新鲜数据，对过期数据做标注或直接忽略。

第三步：记忆的写入与遗忘机制

Context Engineering 不只是"怎么读"的问题，还包括"怎么写"和"怎么忘"。

写入策略：不是所有对话内容都值得进入长期记忆。一个好的做法是让 Agent 在每轮对话结束时，自主判断是否有需要持久化的信息。判断标准可以包括：

用户明确表达的偏好或要求
对话中确认的事实性信息
重要的决策和结论
反复出现的模式

遗忘策略：记忆不能无限增长。需要设计衰减机制：

时间衰减：长期未被引用的记忆降低优先级
冲突覆盖：新信息覆盖与之矛盾的旧信息（用户说"我现在改用 Python 了"，应该覆盖之前"偏好 TypeScript"的记录）
容量上限：每个记忆类别设置存储上限，满了按重要性淘汰

人类大脑有一套精密的遗忘机制——不是所有事情都值得记住。Agent 的记忆系统也需要类似的"遗忘工程"。一个记住所有事情的系统，和一个什么都记不住的系统，同样无用。

第四步：上下文的评估与迭代

这一步最容易被忽略，但也是区分"Demo 级"和"生产级"Context Engineering 的关键。

你需要回答这些问题：

当前上下文中，哪些信息对模型回答质量有正向贡献？
哪些信息是"噪声"，反而干扰了模型判断？
上下文长度和回答质量之间，拐点在哪里？
不同任务类型，需要的上下文组合有什么不同？

实操中，可以通过 A/B 测试来优化：同一个问题，给模型不同的上下文组合，对比回答质量。长期积累下来，就能形成一套针对特定业务场景的"上下文配方"。

一个真实的场景拆解

说个接地气的例子。假设你在做一个面向开发者的 AI 编程助手，它需要：

记住用户的编码偏好（语言、框架、风格）
理解当前项目的代码库结构
追踪正在进行的开发任务
参考团队的技术文档和规范

在纯 RAG 模式下，每次用户提问"这个函数怎么优化"，系统会去代码库里搜索相似代码片段，拼到 Prompt 里。问题是：它不知道用户偏好函数式风格、不知道这个项目用的是 strict TypeScript、不知道团队规范要求所有 API 调用必须有错误处理。

在 Context Engineering 模式下，整个流程变成了：

长期记忆自动注入：用户偏好 TypeScript + 函数式风格 + strict 模式
**MCP Server（代码仓库）**返回当前文件及其依赖关系（结构化 AST，不是纯文本）
**MCP Server（项目规范）**返回相关的编码规范条目
工作记忆携带当前对话的前几轮（用户刚说了"这个函数太长了"）
上下文路由器根据剩余 token 预算，决定要不要再拉一些相关函数的代码

模型拿到的不是一堆散乱的代码片段，而是一份精心组织的信息包：它知道你是谁、你在做什么、你的项目长什么样、你的团队有什么规矩。

回答质量能差多少？根据一些团队公开的对比数据，结构化上下文方案在"代码建议采纳率"这个指标上，通常比纯 RAG 方案高出 30%-50%。

MCP 生态的现状与挑战

MCP 协议从 2024 年底发布到现在，生态发展速度相当快。主流的 IDE、AI 编程工具、企业应用平台都已支持 MCP。但落地过程中也暴露了一些问题。

安全问题首当其冲

MCP 让 Agent 能直接访问外部系统，这带来了明显的安全风险。一个配置不当的 MCP Server 可能让 Agent 读取到不该看的数据，甚至执行危险操作。

目前社区的最佳实践包括：

每个 MCP Server 强制要求认证和授权
对 Agent 的工具调用做沙箱隔离
敏感操作需要用户确认（Human-in-the-loop）
审计日志记录每一次 MCP 调用

标准化程度仍需提高

虽然 MCP 协议本身有规范，但"怎么设计一个好的 MCP Server"这件事，还没有公认的最佳实践。不同团队实现的 Server，返回数据的格式、粒度、质量参差不齐。Agent 在不同 Server 之间切换时，经常需要重新适应。

这个问题类似于早期 REST API 的混乱时期——大家都知道要用 REST，但每个公司的 API 设计风格完全不同。后来 OpenAPI/Swagger 规范的出现缓解了这个问题。MCP 生态也需要类似的"Server 设计指南"。

性能开销不可忽视

每次 MCP 调用都是一次网络请求。如果 Agent 在一次推理过程中需要调用 5-10 个 MCP Server，光网络延迟就可能达到几秒。对于实时交互场景，这个延迟体验并不好。

一些团队开始探索的优化方向：

预加载：预测 Agent 可能需要哪些数据，提前加载到缓存
批量化：将多个 MCP 请求合并为一次调用
流式返回：Server 端边处理边返回，不等全部查完
本地代理：高频访问的数据在本地做镜像

Context Engineering 的组织影响

技术选型的背后，是组织结构的变化。Context Engineering 的兴起正在改变 AI 团队的人员配置和工作方式。

新角色的出现

一些前沿团队已经开始设立"Context Engineer"这个角色（虽然头衔可能不叫这个）。这个角色的核心职责是：

设计和维护上下文分层策略
管理 MCP Server 生态
优化记忆系统的写入/遗忘规则
通过实验持续提升上下文质量

这个角色跟传统的 Prompt Engineer 有本质区别。Prompt Engineer 关注的是"怎么写好一段指令"，Context Engineer 关注的是"怎么设计整个信息供给系统"。前者更像文案，后者更像架构师。

对 Prompt Engineering 的替代效应

一个有趣的现象：Context Engineering 做得好的团队，花在 Prompt 优化上的时间反而大幅减少。

道理很简单——如果上下文足够好，模型不需要你"哄"着它去理解信息。那些精心设计的 Few-shot 示例、反复调优的指令措辞、各种"请你一步一步思考"的引导语，很多时候都是在弥补上下文质量不足的缺陷。

上下文给对了，模型自然就聪明了。与其花 80% 的时间打磨 Prompt，不如花 80% 的时间打磨 Context。

这并不意味着 Prompt Engineering 会消失，但它会从"核心技能"降级为"基础技能"——就像今天没有人把"会写 SQL"当成核心竞争力一样，未来"会写 Prompt"也会变成人人都会的基本功。

几个值得关注的方向

Context Engineering 还在快速演化中。有几个方向值得持续跟踪。

多模态上下文。目前的上下文主要还是文本。但随着多模态模型成熟，上下文会扩展到图片、音频、视频。MCP 协议已经在支持二进制 Resource 的传输。想象一下，Agent 不只是"读"你的设计稿文本描述，而是直接"看"你的 Figma 文件。

协作记忆。多个 Agent 共享同一套记忆系统。比如客服 Agent 记住了用户偏好，销售 Agent 也能用。这涉及记忆的权限管理、冲突解决、一致性保障等复杂问题。

隐私优先的记忆架构。用户的长期记忆存在本地，只有用户授权时才上传给 Agent。这种"记忆主权"的理念正在得到越来越多的关注，尤其在欧洲和日本的合规环境下。

自适应上下文。模型自己学会判断需要什么上下文。不再需要人工设计路由规则，而是通过强化学习让 Agent 自主掌握"什么时候该查什么、查多少"。这有点像从手动挡升级到自动挡。

回到那个根本问题

大模型 Agent 到底需要什么样的"记忆"？

这个问题没有标准答案，但方向已经很清楚：不是更多，而是更好。 不是把所有信息塞进去让模型自己挑，而是精心设计信息的结构、层次、优先级和时效性，让模型在最少的认知负担下做出最好的判断。

MCP 协议提供了标准化的数据接入层，Context Engineering 提供了上层的设计方法论。两者结合，构成了当下 Agent 记忆管理最务实的技术栈。

RAG 没有过时，它只是从"整个方案"变成了"方案的一部分"。检索仍然是获取上下文的重要手段，但检索回来的东西怎么组织、怎么分层、怎么跟其他来源的信息融合——这些才是决定 Agent 实际表现的关键变量。

做 AI 应用的人，迟早要跨过这道坎：从"模型能做什么"转向"我能给模型什么"。这个转变看似微小，实际上决定了产品是 Demo 级别还是生产级别。

上下文工程化这条路很长，但方向对了，走多远都不怕。

记忆管理 on 文艺技术笔记