上下文工程：ChatMemory滑动窗口与Context-mode MCP实践

先说个我最近遇到的真实场景。我在给团队搭一个AI编码代理，用来处理日常的代码审查、bug定位和模块重构。刚上线那两天效果确实惊艳，但用久了一点就发现不对劲：它在连续对话里越来越“失忆”。上午刚说过的接口约束，下午它就给你改回去；你让它回顾一下当前任务进展，它输出一段跟关键信息完全无关的废话。问题并不在模型本身，而在上下文这一层——我喂给它的信息太多、太杂，而且没有做任何记忆管理。这篇文章梳理的就是我在这个实战项目里的两条主线：一是用ChatMemory滑动窗口管好聊天记忆，二是用Context-mode MCP把数据获取从“全量灌入”改成“按需取用”。两条线配合下来，整个编码代理的工作质量才真正稳定下来。

1. 为什么要做上下文工程：AI编码代理的“记忆困境”

1.1 上下文窗口不是无限大

大多数人最早接触AI编程是从网页聊天开始的，那种模式下模型收到的只是你粘贴的一段问题，顶多几千字，上下文压力根本不存在。一旦把AI变成“编码代理”——它能自己去读仓库、改文件、跑测试、查日志——上下文的使用方式就完全变了。

这里要区分一个概念：编码代理和普通聊天的本质区别，在于它需要在一个任务周期内连续感知多类信息。比如要修复一个线上bug，它需要知道bug现象、相关代码片段、最近提交记录、测试结果、配置文件内容，以及你之前跟它交流中提到的约束条件。这每一类信息都要占大模型的上下文窗口（Context Window）。

现在的旗舰模型多数给到128K甚至200K token的窗口，听起来很大，但放到真实项目里根本不够看。一个中大型代码库动辄几万到几十万个文件，单次CI构建日志轻松超几千行，某次报错输出可能就有几万token。128K窗口在一整套工作流压力下，几分钟就能被塞满。塞满之后怎么办？很多Agent框架采取最原始的策略：清空旧内容，保留新内容。于是它开始失忆，开始前后矛盾。

1.2 上下文多不等于效果好：Lost in the Middle

“不是塞得越多越好”这件事，是有正经研究支撑的。学术界有一个知名现象叫Lost in the Middle（中部迷失）：当模型需要从长上下文中检索信息时，它对开头和结尾的内容记忆更牢，而对中间位置的信息往往容易遗漏、混淆甚至直接忽略。

这个现象对编码代理的影响非常直接。如果你在Agent的上下文里堆了一堆历史记录、无关代码、多轮废话，真正关键的信息很可能就落在“中间区域”，模型的注意力机制根本捞不到它们。表现出来就是它“看过”了你给的资料，但回答时完全没用上，反而基于一些片面的信息自作主张。

我自己常用一个生活类比去理解这件事：你让实习生去了解一个项目，桌上堆了十几本资料，既有旧需求文档又有新设计稿，还有几十次聊天记录。你问他最终的设计规范结论是什么，他可能翻很久，还可能搞错。AI也是一样的。上下文不是仓库库存，塞得越多，噪声越重，准确率反而下降。

1.3 成本与效率的账

上下文工程还有一个绕不开的现实理由：钱。Token数直接决定API调用成本。一个中等复杂度的bug修复，如果无脑把所有信息塞进一次调用，峰值可能消耗2万到5万token。单次看起来就几美分到几毛钱，但当一个开发团队每天要跑几十上百个这样的任务时，月度账单会非常可观。

而且除了金钱成本，还有时间成本。处理超长上下文的延迟会显著增加，一次完整调用可能从几秒拉到几十秒。对于需要高频交互的Agent来说，这种延迟非常影响使用体验，也直接降低了它作为“团队协作者”的实际可用性。

1.4 上下文工程到底在解决什么

基于这些困境，业内把这套管理上下文的实践统称为上下文工程（Context Engineering）。如果提示词工程（Prompt Engineering）是“如何把话说清楚”，那上下文工程就是“如何选择和组织材料给模型看”。

上下文工程不是一个单一技巧，而是一套系统工程，大致包含几个部分：

• 记忆管理：决定哪些信息保留在短期对话里，哪些进入长期存储，哪些直接丢弃。
• 信息检索：在需要时从外部知识库、代码仓库按需获取与当前任务相关的片段。
• 内容压缩：用摘要、结构化提纲等方式压缩低信息密度的内容。
• 工具编排：让模型通过工具去“查”，而不是把所有数据都加载进来。

本文后面要讲的ChatMemory滑动窗口属于第一类，Context-mode MCP的实践则覆盖第二类和第四类。

2. ChatMemory滑动窗口：最朴实的记忆管理方案

2.1 先搞清楚ChatMemory到底管什么

很多文章一讲ChatMemory就直接贴代码，但我建议先想清楚它解决的问题边界。ChatMemory，聊天记忆，管的是“对话历史”这一层，也就是在Agent与用户多轮交互中，哪些历史消息需要继续喂给模型。

最朴素的做法是把所有历史消息全量保留，每一轮对话都带上全部内容。数据量小的时候确实能跑，但几十轮之后，光历史对话本身就足以把上下文窗口耗尽。于是就有了滑动窗口（Sliding Window）机制，这也目前各类Agent框架里最稳定、最常见的短时记忆方案。核心逻辑一句话就能说清：只保留最近N轮对话，更早的内容要么被丢弃，要么被压缩成一个摘要。

2.2 滑动窗口的工作原理

为了让你直观理解它的工作方式，我先写一段简化伪代码。实际框架里的实现会更复杂，但骨架大体如此：

class SlidingWindowMemory: def __init__(self, max_rounds=10, summarizer=None): self.messages = [] # 完整消息队列 self.max_rounds = max_rounds # 保留最近多少轮 self.summarizer = summarizer # 摘要器，可选 def append(self, role, content): self.messages.append({"role": role, "content": content}) def build_context(self): # 一轮对话包含 user 和 assistant 两条消息 if len(self.messages) > self.max_rounds * 2: overflow = self.messages[:-self.max_rounds * 2] if self.summarizer: summary_text = self.summarizer(overflow) self.messages = [ {"role": "system", "content": f"历史对话摘要：{summary_text}"} ] + self.messages[-self.max_rounds * 2:] else: self.messages = self.messages[-self.max_rounds * 2:] return self.messages

每次要构造发给模型的消息列表时，先检查当前总消息数是否超过预设窗口规模。如果超出，就把窗口之外的老消息取出来，交给摘要器生成一段概括性系统消息，放在窗口最前面，然后保留最近若干轮原始消息。我在实际项目里用的是带摘要的版本，因为如果只是简单丢掉，Agent会彻底忘掉早期聊过的重要约束，比如“不要修改对外接口”“必须兼容旧版本数据”。这些东西丢了会直接导致行为失控。而通过摘要保留骨架，模型至少记得存在这么个约定，具体细节需要时再从代码或文档里查。

2.3 三层落地策略：从简单到进阶

根据项目复杂度，滑动窗口可以有不同的配置方式。我把它归纳成三层。

第一层是纯截断窗口，只保留最近N轮，多余的直接删掉。适合简单问答型助手，历史消息没有跨轮次依赖。优点是实现最简单、内存开销最小；缺点是早期信息完全丢失。

第二层是摘要加滑动窗口。把超窗内容全部交给模型做摘要压缩，压缩后以系统消息形式放在顶层，再配合最近轮次原文。这个方案我推荐大部分编码代理使用，它能以很少的token开销换回一部分“长期记忆”。实现时要注意摘要的稳定性，最好让摘要器保持同样的角色设定，否则每轮摘要风格会漂移。

第三层是分层记忆架构。短期层保留最近N轮原文，中期层存放摘要，长期层放到向量数据库或普通文档库，供Agent在需要时按需查询。这其实已经不是单纯的滑动窗口，而是滑动窗口加外部存储的混合体，后面聊MCP时你会看到这种架构的优势。

2.4 窗口大小设多少合适：我的经验值

窗口大小没有绝对标准，它取决于模型上下文上限、任务复杂度、预算，以及你希望Agent保持多少轮连续性。我结合自己项目给出的经验参考：

• 简单任务（单点问答、一次性改动）：5到8轮足够，太多反而引入无关噪音。
• 中等任务（小模块开发、bug修复）：10到20轮，能覆盖从问题描述到修复验证的完整闭环。
• 大型重构任务：不建议用无限大的滑动窗口，而是在20轮之后启用“任务状态记录页”，把当前目标、已完成步骤、待办事项写成结构化摘要，替代长对话。这个状态记录后面我们用的是MCP Resource来管理，效果远好于硬塞聊天记录。

我在一个基于Claude Code二次封装的内部Agent上做过对照：窗口从10轮提到14轮，修复bug的平均上下文消耗增加约12.7%，正确率提升约6%；继续往上加，收益急剧下降。所以我的建议是先用10至15轮打底，再配合摘要和MCP优化，而不是一味调大窗口。

2.5 滑动窗口方案常见的坑

这里记录几个我踩过的坑。

第一个坑是“把窗口设大就能缓解失忆”。很多人一看到模型记性差，就盲目调大窗口，结果很快撞上成本和中部迷失问题。信息越多，模型越容易在关键节点走偏。窗口本质是“有限注意力预算”的分配策略，不是越大越好。

第二个坑是摘要频率太高。有些实现会在每一轮对话结束都对全量历史做摘要，这会产生大量额外token消耗，而且摘要信息会逐级失真。别小看这个“逐级失真”，类似于传话游戏，消息传来传去就变形了。我的处理方式是不在每轮触发摘要，只在触发窗口溢出时做一次。

第三个坑是忽视系统提示和固定指令在窗口中的占比。很多人只数用户消息和助手消息的轮次，忘了系统消息也可能很庞大。你的Agent如果加载了项目规范、风格指南、工具说明，这部分内容可能已经占掉几千token，必须提前从窗口预算里预留出来。

3. Context-mode MCP：把上下文从“堆”变成“取”

3.1 先说清楚MCP是什么

MCP全称是Model Context Protocol（模型上下文协议），由Anthropic在2024年底提出的开放协议，目标是把AI应用和数据源、工具之间打通成一套标准接口。

我更喜欢把MCP理解为AI界的USB接口。在MCP出现之前，每个AI应用要接一个数据源，几乎都要定制开发一套接口。你想让Agent读数据库、连浏览器、操作设计软件、查日志，每个都得单独写插件。有了MCP，数据源提供方只需要实现一个标准协议的服务端（MCP Server），AI客户端（MCP Client）就能统一调用。这种标准化带来的生态效应非常明显，现在GitHub上已经有大量现成的MCP Server，覆盖MySQL、PostgreSQL、Redis、Playwright、浏览器DevTools、各类CI系统，甚至Blender、Unity这类专业软件都有人在做。

3.2 Context-mode从何而来

题目里提到的“Context-mode MCP上下文优化”，严格来说不是MCP协议中一个叫“Context-mode”的官方模式，而是实践社区对“如何用MCP把上下文做精”的一套总结。我理解它的本质是：通过MCP把数据访问从“全量加载”改成“按需获取、用完即走”。

为什么这套思路在上下文优化上特别有优势？关键在MCP的资源模型支持三类操作：

• Resources（资源）：以声明方式暴露可读数据，比如一个文件、一张表结构、一份文档。Agent可以知道有这个资源存在，但不必读取全文，而是可以按标识符、路径或过滤条件只取需要的部分。
• Tools（工具）：暴露可调用的函数，Agent根据需要请求执行，调用结果作为一条新消息进入后续上下文，用完就不再占用永久空间。
• Prompts（提示模板）：暴露预定义的提示词，让Agent在特定场景下格式化请求。

对照传统的“把整个知识库全塞进上下文”，Context-mode MCP的思路是：环境里有一整个图书馆，但不要求模型把图书馆背下来，需要哪本书时去书架取哪本就行。

3.3 实操：给编码代理配一个MySQL MCP服务

我拿一个典型场景演示怎么落地。假设我要让AI编码代理分析本地MySQL数据库，排查业务数据异常。

不用MCP的老做法，是把表结构和样本数据整个塞进Prompt。几张大表的schema列出来就要上千token，想全量导入数据更是直接撑爆窗口。

用MCP的方式清爽很多。以@benborla29/mcp-server-mysql这类现成服务为例，配置文件大致如下：

{ "mcpServers": { "mysql": { "command": "npx", "args": ["-y", "@benborla29/mcp-server-mysql"], "env": { "MYSQL_HOST": "127.0.0.1", "MYSQL_PORT": "3306", "MYSQL_USER": "readonly_user", "MYSQL_PASSWORD": "your_password", "MYSQL_DATABASE": "business_db" } } } }

部分编码工具可以直接读取这份配置。Agent启动后，会在工具体系里看到一组MySQL相关操作，比如query、get_schema、list_tables。当它需要分析数据时，会主动调用这些工具，而不是提前加载全部数据。

单次查询结果通常只有几百到几千token，而且只影响当前这一步。下一个任务开启后，这个查询结果就可以从窗口里移除了。这就是Context-mode的核心：数据按需进入上下文，用完即走，不污染后续任务。

3.4 上下文占用对比：从全量灌到按需取

我在同一个任务上粗略统计过不同方案的上下文消耗，给大家一个量级感受。假设业务库有20张表，平均每张表3个核心字段，而实际排查只需要其中2张表和3次数据查询：

MCP方式比全量方式节省了超过90%的上下文占用。这里还有个细节，工具描述虽然要占一部分上下文，但它是稳定元数据，可以做成精简版本反复使用，总量很低。

这个做法还有一个额外好处：让Agent养成“查数据库”的习惯。如果直接把schema全给它，它往往会偷懒不查，直接用已有信息猜；但给的是查询工具，它反而会在不确定时主动拉取最新数据。这个差异对生产环境的准确性非常有价值。

3.5 MCP上下文优化在代码场景的高级玩法

除了数据库，MCP在代码仓库层面的上下文优化更常用。我推荐两个配置供参考。

第一个是“代码检索MCP”，接收Agent的语义查询或关键词查询，返回相关代码片段、定义位置、调用关系。Agent不需要把整个仓库塞进上下文，只在需要了解某个函数实现时去获取。

第二个是“项目规范MCP”，把项目规范、代码风格、架构约束、团队约定放到MCP Resource里。Agent启动时只读取一份索引，当进入到特定任务，比如新增REST API时，才去加载对应的API设计规范文档。这样系统提示词可以做得非常精简。

开篇提到的“失忆”问题，很大程度上可以通过MCP方案解决——它让Agent不必依赖历史对话去记规范，因为随时可以重新查回来。这比依赖摘要可靠得多。

4. 组合实战：ChatMemory+MCP的混合上下文架构

4.1 两者不是替代关系，是分工关系

很多人拿到这两个方案之后，第一反应是既然MCP这么厉害，滑动窗口是不是可以废掉？我实测下来的结论是：不要废。两者管的是完全不同层面的上下文。

ChatMemory滑动窗口管的是时间维度的对话历史：你跟Agent聊了什么，它之前做过什么决策，哪些约束在任务过程中不能忘。这些信息属于“过程记忆”。

Context-mode MCP管的是空间维度的信息获取：需要哪些外部数据，从哪儿读，什么时候读。这些信息属于“知识记忆”。

一个编码代理要稳定干活，两方面都得有。过程记忆负责让协作连贯，知识记忆负责让内容准确，缺一个都会出问题。

4.2 一个混合架构实例

我把自己在内部给代码助手搭的上下文架构整理成一个简版，你可以当模板用。整体分三层：

第一层是系统指令层，包含角色定义、通用工作流、安全约束。这一层只保留精简核心内容，详细规则统一放MCP的项目规范Resource里。

第二层是短期记忆层，使用带摘要的ChatMemory滑动窗口，窗口默认14轮。保留当前任务的用户描述、Agent中间结论、工具调用结果摘要。超窗内容压缩成“任务进展摘要”置顶。

第三层是按需知识层，接入多个MCP Server：代码检索、项目规范、构建与测试。Agent根据所处阶段动态调用。

4.3 完整工作流演示

用“修复慢查询”这个任务完整走一遍。

第一步，用户告诉Agent：本地报表接口慢，排查一下。描述进入滑动窗口，Agent开始接手。

第二步，Agent通过代码检索MCP找到报表接口相关Service函数和SQL语句，只把这一段代码加载进上下文。随后调用数据库MCP查询执行计划，把EXPLAIN结果拉进来。

第三步，Agent结合窗口里的任务描述和执行计划给出结论：缺少user_id索引，查询包含了不必要的全字段扫描。分析结果写入滑动窗口。

第四步，Agent准备修改代码。通过代码检索MCP查看表结构定义和ORM模型，确认索引变更位置，给出修改建议。

整个过程中，上下文里始终只有任务描述、分析结论、必要代码片段和查询结果，从来没有把整个项目或全库数据塞进去过。老方案里，光加载几个大页面类可能就要上万token，还不一定定位到关键信息。

4.4 关键配置：怎么让Agent愿意用MCP

很多人在实践MCP时遇到的问题不是配不好，而是Server都起来了，Agent就是不去碰，还喜欢在上下文里堆回忆。问题几乎都出在系统提示词没有把工具使用策略讲明白。

我在系统指令里明确加了一条规则：“当你需要了解数据或代码时，应优先调用MCP工具获取最新信息，不要依赖历史记录做推测。除非工具不可用，否则不要仅凭记忆回答。”这条规则对提升工具使用率帮助非常大。

还有一个重要点：同一时刻不要暴露太多工具。一个MCP Server注册几十个工具时，Agent每轮都要为“调用哪个工具”付出额外决策成本，还容易选错。我建议每次任务只挂载对当前任务必要的那两三个Server，其余保持懒加载。

4.5 效果评估：我实测的一组数据

这套组合方案我跑了大概三周，对比改造前的数据如下：任务成功率（定义为最终结果未返工且满足约束）从61%上升到82%；上下文平均占用从每任务约2.8万token降到约9000token；费用降了约60%；长任务中的“遗忘约束”类失误从平均每3个任务一次降到每9个任务一次。

绝对数值跟项目相关，不用照搬，但趋势很稳定：混合架构在成本、质量、连续协作体验上都是正向收益。

5. 常见问题与排查技巧实录

5.1 上下文越用越“笨”：是不是窗口设计有问题？

项目进行到一半时，Agent开始重复已经说过的结论，或者忽略你刚刚给出的修正。最可能的原因有两个：一是窗口溢出后摘要压缩把关键约束丢了，二是摘要的简要内容被后续内容挤到了中部。

我的排查步骤一般是：先打开调试日志，看每次请求实际收到的消息列表，确认摘要是否还挂在顶部；再检查摘要内容本身，看是否包含了核心约束关键词；最后看窗口轮次是不是设置得过小，导致摘要过频。通常的解法是给摘要器设计专门提示词模板，让它明确提取“用户强约束”“当前进展”“待办事项”，比自由摘要可靠得多。

5.2 MCP配置成功，但Agent就是不调用工具

这个现象在首次配置MCP时特别常见。Server进程起来了，工具列表也能拉取，但Agent就是不用。我总结了三步排查：

• 第一步，确认工具是否真的暴露给了模型。有些配置后客户端默认把工具放在“需手动允许”状态，Agent有权但未必主动用。
• 第二步，确认工具描述是否清晰。MCP Server的默认工具描述如果太宽泛，比如就叫execute_sql，Agent根本判断不出什么时候该调它。解决办法是给工具补描述，写明使用时机、参数含义、示例。
• 第三步，检查系统提示词里有没有工具禁用约束。不少项目为了安全默认关闭工具，只在用户确认后启用。如果启用时机没设计好，Agent只能全程靠猜。

另外有个小细节：MCP调用是有网络延迟的，Agent在多步决策中对高延迟工具有时会回避。如果工具响应太慢，建议在提示里让Agent等待，或者优化查询本身。

5.3 摘要压缩后信息失真，重要事实被抹掉

这是带摘要滑动窗口实现的老大难。我的抢救办法是不要只做一层自由摘要，而是做“标题加关键事实加待办”的结构化摘要，比如：

【任务目标】 （一句话） 【已确认的关键决策】 （列表，保留数字、动词、完整约束） 【当前进度】 （哪些已完成，哪些未开始） 【待办事项】 （下一步动作）

这种结构化摘要的好处有两个：一是模型填充模板时会更严谨，不会随便略过关键信息；二是后续轮次里模型能快速定位到“已确认决策”这一段，规避Lost in the Middle的影响。

5.4 常见问题速查表

最后说一个我踩过最深的坑。有一阵我把上下文优化做好之后，急于给Agent挂上更多MCP Server，觉得工具越多越强大。结果Agent每轮光纠结调用哪个工具就多烧了不少token，还时不时选错。后来我把工具按任务分组，每次只暴露最必要的一组，整个性能立刻上来了。上下文工程说到底是一门“舍得”的艺术，你越是懂得向Agent暴露尽量少的高价值信息，它反而跑得越准。这也是我做完这套架构之后最深的体会：帮模型做减法的能力，才是编码代理能力上限的关键变量。