上下文工程实战：用滑动窗口与Context-mode MCP给编码代理瘦身

这两年我把大量时间花在调教 AI 编码代理上最直观的感受是模型本身的能力固然重要但真正决定一个代理好不好用的往往是上下文。所谓上下文工程本质就是让有限的 token 预算去装“当前任务真正需要的东西”而不是把整个仓库、整段历史、所有 MCP 工具定义都塞进去。项目搞到后面你会发现 ChatMemory 的滑动窗口、MCP 工具的按需挂载、Context-mode 这类上下文优化模式其实是在解决同一个问题把最贵的信息放在离模型最近的地方把没用的信息尽快请出去。这篇文章不是讲某个具体产品的说明书而是我在实际调代理过程中沉淀下来的一套上下文工程打法。适合刚接触 AI 编码代理、被“越写越笨”或者“工具列表太长导致跑偏”困扰的人也适合想系统理解 ChatMemory、滑动窗口、MCP 上下文优化关系的朋友。如果你也有一个长期在维护的项目照着这套方法做一轮瘦身大概率会看到明显变化。1. 上下文工程的定位为什么编码代理会“越写越笨”1.1 编码代理的上下文到底由什么组成很多人以为上下文就是聊天记录其实不是。我拆过几次编码代理的请求体一份典型的上下文至少包含五个部分系统提示词角色的行为规则、编码规范、安全约束通常常驻且不参与滑动淘汰。对话历史用户指令与代理回复的逐轮记录这是滑动窗口主要管的部分。工具定义系统提示词里的 function calling schema或者 MCP 暴露出来的工具描述、参数结构。工具返回结果读文件、搜代码、跑命令后回传的内容经常非常长。检索/文件片段代理主动读取的源码块、文档段落、git diff 等。我习惯把上下文想象成一张工作台。桌面就那么大你放了大半个仓库的扫描结果上去真正要改的那个函数反而找不到地方放了。全量历史、全量文件、全量 MCP 工具这三样东西恰恰是吃桌面最大的三个“贪吃鬼”。1.2 上下文超限后会有哪些典型表现代理并不会在某一个瞬间突然“崩掉”它会先进入一种半醒半糊涂的状态。最常见的几个信号早期需求被遗忘你第一轮说“不要动 package-lock.json”二十轮后它开始乱改依赖文件。重复调用工具同一个git log或者grep连续执行好几遍因为它已经忘了自己查过什么。修改文件时选错目标尤其在多模块工程里明明要改 A 服务它却动了 B 服务的同名文件。单轮 token 越来越贵上下文里堆了大量历史内容每一轮都要重新处理延迟和费用一起上升。这些现象不是模型变笨了而是有效上下文被挤占了。上下文工程要做的就是保证“重要信息”永远留在桌面“过期信息”及时进仓库“工具清单”只展开当前任务需要的那几样。2. ChatMemory 机制拆解从全量保留到滑动窗口2.1 全量上下文的代价最早我做编码代理的时候为了“让它记得所有东西”配置里直接不压缩历史对话来多少就留多少。表面上看很稳实际用起来问题很大。一个 50 轮的长任务光历史内容就可能到 8 万到 12 万 token系统提示词和工具定义还要再叠加大几千。模型每生成一个字都要把这些内容整体过一遍推理速度下降不说注意力还容易被无关话题分散。更要命的是早期对话里真正有用的“决策性信息”可能只有几百 token其余全是过程性废话尝试失败的命令、无关的报错、来回试探的思考片段。全量保留等于用 12 万 token 的仓库去掩护那 500 token 的黄金记忆。成本高收益低。ChatMemory 这类机制就是为了解决这个问题出现的。它不一定叫 ChatMemory不同产品里可能叫 Conversation Memory、History Compression、上下文压缩但核心思路一致用滑动窗口保留最近内容用摘要压缩早期内容用固定记忆保护关键约束。2.2 滑动窗口的核心思想滑动窗口这个名字从网络协议里的滑动窗口重传到信号处理里的滑动窗口滤波再到上下文管理其实是一脉相承的。它回答的问题非常简单在一段连续的数据流里我到底应该把注意力集中在哪一段放到编码代理里滑动窗口就是“只保留最近 N 轮对话超过 N 轮的旧内容先压缩成摘要再放进窗口开头”。窗口不是简单地掐断更像搬家和归档最重要的东西放桌上次重要的放文件夹并贴上摘要标签不重要的直接扔。我结合几个编码代理的实现整理过一张通用策略表记忆类型典型策略预算建议系统提示词常驻不参与淘汰尽可能精简到 1500 token 以内用户关键约束固定记忆置顶不超过 10 条每条一句话最近对话滑动窗口保留20 到 30 轮按任务复杂度调整早期对话压缩成结构化摘要每次摘要控制在 500 到 1200 token工具返回结果只保留结果摘要能放路径或 key 就不要放全文文件片段按当前任务加载涉及完就移出不长期挂着2.3 窗口参数的参考计算很多人拿到“滑动窗口”功能后不知道设多大。我一般不会拍脑袋填一个数字而是先做一道简单的预算公式可用的窗口预算 模型输入上限 - 系统提示词 - 固定记忆 - MCP工具定义 - 输出预留假设某模型输入上限是 128k token系统提示词 1k固定记忆 0.5kMCP 工具定义 2k输出预留 4k那么留给对话历史和工具结果的空间大约有 120k。这时候窗口可以宽一点比如 40 轮。但如果模型只有 32k 输入工具定义又膨胀到 10k那对话窗口可能只能给到 20 轮左右。实操中我还会动态观察如果每轮平均 token 消耗涨得很快说明窗口内塞了太多长工具结果不是纯粹靠调轮数能解决的得先压缩工具返回内容。窗口轮数只是一个表面参数底层真正约束是 token 预算。2.4 ChatMemory 落地时容易忽略的细节一开始我简单以为“窗口最近 20 轮”后来才发现只这么做会踩不少坑。第一摘要不能写成“流水账”。我见过很多自动摘要最后变成“用户要求实现 X代理尝试了 Y最后还没完成”这种摘要对后续决策几乎没用。更好用的摘要模板是结构化的【任务快照】 - 当前目标在 payment 服务中新增退款回调 - 已完成数据库表设计、回调接口骨架 - 关键决策用事件消息而不是同步 RPC - 关键约束不动 package-lock.json兼容 Java 8 - 遗留问题需要确认第三方签名算法这个模板的重点是“决策”“约束”“遗留”这三项因为后面代理真正需要的就是这些而不是历史里某一句具体的话。第二固定记忆要“置顶”而不是“塞在历史里”。像“不要修改 public 目录”“测试用例必须同步更新”这种规则如果只出现在第 3 轮对话里到了第 30 轮大概率被窗口挤出去。应该把它抽出来放到系统提示词或者专门的 pinned memory 区域。我习惯叫它“约束白名单”每次新会话开始都重新加载。第三压缩频率不能太激进。每两轮就压缩一次会让代理处于一种“永远在看摘要”的状态细节丢失得很厉害。我一般是在窗口超过预算的 70% 时才触发一次压缩给代理留出更多“完整细节期”。我的体感是窗口大小不是越大越好也不是越小越好。窗口太小人会“失忆”窗口太大注意力会被平均稀释。真正舒服的状态是“摘要给方向窗口给细节”。3. 从 ChatMemory 到 MCP上下文外置与工具边界3.1 MCP 到底是什么MCP 的全称是 Model Context Protocol翻译过来是“模型上下文协议”。它跟 TCP/IP、USB 这类传输层或硬件协议不是一个概念它是软件层面的协议用来统一“模型怎么调用外部工具”和“模型怎么读取外部资源”。你可以把 MCP 理解成编码代理的标准化外设接口。以前每个模型要接自己的插件体系GitHub、数据库、浏览器、设计稿、蓝湖一家一个 SDK接起来很痛苦。MCP 出现以后工具端实现一次 MCP Server客户端实现一次 MCP Client理论上所有支持 MCP 的编码代理都能共用同一套工具生态。这个概念在项目里很香但它也带来了一个典型的副作用工具数量膨胀。以前你可能只挂四五个内置工具现在一个 MCP Server 就能暴露十几个工具项目里再挂五六个 Server工具定义轻轻松松超过几十个。每个工具的名字、描述、参数 JSON Schema 都是 token而且大部分工具定义每一轮都会跟着请求一起发送。3.2 工具定义如何污染上下文我大概估算过一次一个中规中矩的 MCP 工具描述加参数定义大约在 200 到 800 token 之间。如果你挂了十个工具就是 2k 到 8k token如果挂了三十个轻轻松松超过 12k。这些 token 虽然不像长文件那样显眼但每一轮都在消耗输入预算。更麻烦的是工具太多会让模型“选择困难”。比如它需要读文件但候选工具里既有read_file又有search_files还有list_directory模型可能先用一个再用另一个来回折腾。上下文污染不只看数量还看“可选性污染”工具越多模型越容易在工具选择上犯糊涂。这也是为什么我把 MCP 的上下文优化和 ChatMemory 滑动窗口放在同一个工程体系里。前者管的是“历史该留多少”后者管的是“工具该暴露哪些”本质都是在做同一件事控制每一轮被送进模型的信息总量。3.3 MCP 的三种上下文暴露方式我把平时接触到的 MCP 用法分成三层全量模式客户端启动时就加载所有 MCP Server把所有工具定义塞进每一轮请求。适合工具少、任务单一的时候。按需模式按项目或任务挂载指定 Server减少同时暴露的工具数量。比如这个目录只挂 Git 和文件类 Server不挂数据库 Server。上下文模式Context-mode在按需模式的基础上进一步细化到“只暴露当前任务需要的工具子集其余工具通过资源或动态加载机制按需拉取”。Context-mode 我理解不是某个产品独有的开关而是一套优化约定。它的核心原则是默认最小化需要时才展开。这和 ChatMemory 滑动窗口的理念完全一致——不要把所有东西常驻在上下文里而是用一套规则去决定“什么时间放什么进来”。4. Context-mode MCP 实践给上下文做“瘦身”4.1 按任务领域拆分 MCP 配置我第一次做 MCP 上下文优化时把项目里的所有 Server 全挂在全局配置里后来发现每次请求的 token 高得离谱。后来改成按目录和任务拆分前端相关任务只加载前端构建、浏览器调试类 Server后端任务只加载数据库、接口调试类 Server通用任务只保留文件系统、Git、Shell 三个基础能力。这种拆分在编码代理里非常实用。你可以每个项目准备一份mcp.json而不是共用一个巨大的全局配置。大体结构类似下面这样{ mcpServers: { github: { command: npx, args: [-y, modelcontextprotocol/server-github], mode: context, contextRules: { include: [search_code, get_issue], exclude: [create_issue, merge_pr] } } } }不同客户端的字段名可能不一样有的叫mode有的叫scope还有的靠独立配置文件管理但思路是一样的把“这个任务不需要的工具”从默认上下文里拿掉。4.2 精简工具描述与参数 Schema光靠按需挂载还不够因为有些 Server 即使只暴露几个工具描述依然很长。我做过一次手工精简把一批工具描述从 400 token 压到 150 token 左右效果立竿见影。精简的原则有三个删掉“客套话”比如 “This tool allows you to...” 这种开头直接换成动词短语。合并同类项把 read 和 list 类描述统一成“读取目录/文件”不用分别写大段能力介绍。参数 Schema 只保留必填项和最关键的可选项把不常用的参数挪到文档资源里需要时再让代理去查。这个操作看起来不起眼但如果你有二三十个工具每个省 200 token一轮就能省下四五千 token。长时间跑下来费用和延迟都差很多。4.3 用 Resource 替代高频工具调用MCP 除了 Tools 之外还有 Resources 和 Prompts。很多人在做上下文优化时只盯工具列表忽略了 Resources 的作用。Resources 可以理解成“按需读取的上下文片段”。比如项目结构文档、编码规范、接口变更记录都可以暴露成 Resource。代理遇到相关任务时会先读这个资源而不是由工具把全量内容返回。这样既减少了工具结果对上下文的冲击也让关键知识保持最新。我常做的一个配置是把docs/architecture.md和docs/error-handling.md注册成项目级 Resource并在系统提示词里告诉代理“涉及架构决策前先读取 architecture 资源遇到错误处理问题时先读取 error-handling 资源。”这比把所有文档全文塞进上下文靠谱多了。4.4 一个容易被忽视的坑工具命名冲突挂多个 MCP Server 以后你还会遇到工具撞名的问题。比如一个 Server 里有search另一个 Server 也有search如果客户端没有做命名空间隔离代理很容易调用到错误的工具。相比之下Browser 类 MCP 和 Playwright MCP 这类同为浏览器自动化方向的工具功能重合度更高同时挂载时容易出现“两套搜索和点击工具混在一起”的混乱。我的建议是同一领域只保留一个主力 MCP。如果你要做浏览器自动化测试选一个更贴近你日常操作习惯的就行没必要把同类工具全挂上。上下文优化的目标不是“能用全用”而是“够用且不乱”。我个人的一条硬规则每个 MCP Server 在加入项目之前先数一遍它暴露了多少工具、最常用的三个是什么、预期会占用多少 token。凡是工具数超过 15 个的 Server必须开 context 模式过滤否则宁可不挂。5. 实战场一套可复用的上下文优化流程5.1 第一步先给上下文做一次“体检”不要一上来就各种调参。我一般会让编码代理执行一个中等复杂度的任务跑上十几轮然后打开客户端的上下文统计或者用 Token 计数脚本看一眼。重点记录三项数据单轮请求的 token 总量历史消息占多少、工具定义占多少、工具结果占多少最近 10 轮中是否有重复读取同一文件或重复执行同一命令的情况。体检结果通常能直接指出“大胃王”是谁。我自己遇到过的情况是历史消息只占 15%MCP 工具定义反而占了 35%工具结果又占了 30%。这时候单纯调滑动窗口没用重点得放在 MCP 上下文优化和工具结果压缩上。5.2 第二步按顺序调整三个开关我的调优顺序固定是先压工具再压结果最后压历史。工具层面用 Context-mode MCP 过滤掉不相关工具保留当前任务高频使用的三到五个。结果层面要求代理返回工具结果时尽量输出摘要比如git log只保留前几条 commit 和统计而不是完整输出几百行。历史层面再调滑动窗口轮数和摘要触发阈值。这个顺序背后的逻辑是工具定义每轮都送优化它收益最稳定工具结果单次体积大压缩它见效最快历史内容则要在“够用”和“省 token”之间慢慢找平衡优先级放最后。5.3 第三步建立前后对比清单每次调整完我建议在同一类型的任务上做一次前后对比。我通常用下面这份简表评估项优化前优化后单轮平均 token36k15k对话历史保留轮数6024MCP 工具定义 token8k2k误改无关文件次数41重复执行命令次数72任务完成满意度勉强稳定注意token 降下来不算成功任务完成质量才是关键。有时候你把窗口压得太狠代理确实省 token 了但开始丢需求这种优化就是负优化。我的判断标准是在至少连续三个类似任务里代理都能保持一致的决策和输出风格才算优化到位。5.4 第四步把常用方案沉淀成项目模板上下文配置最怕“每次重新发明轮子”。我现在会在项目根目录维护一套模板里面包含三样东西mcp.json的按需配置、ChatMemory 的推荐参数、一份“约束白名单”提示词片段。新项目直接复制过去再按项目特性增删。这套模板不用很复杂关键是把“哪些工具必须开 context 模式”“哪些历史信息必须 pin”“哪些文档作为 Resource 暴露”这类决策固化下来。下次再遇到类似项目你就不需要从 zero 开始试了。6. 常见问题与排查技巧实录6.1 窗口调小后早期需求被模型“忘掉”了怎么办这是最常遇到的问题。早期需求被忘通常不是因为窗口太小而是因为关键约束没有被提取到固定记忆区。你应该在对话开始阶段就把“本次任务不可违背的约束”用一句话写清楚然后设置成 pinned。如果任务过程中出现新的关键约束也要第一时间手动更新这个固定区。如果代理还是忘那就检查一下摘要里是否包含了决策记录。我的习惯是在每次窗口压缩后查看一下生成的摘要确认“任务目标”“决定性决策”“关键约束”三项是完整的。缺哪项就补哪项。6.2 摘要把关键细节压没了怎么办摘要不可能保留所有细节所以我的原则是“摘要保存决策窗口保存细节”。如果某个细节很重要但它不在最近窗口里就把它单独抽出来作为固定记忆。比如客户要求“错误码统一用 BIZ_ 前缀”这种全局规则就不该指望摘要自动带出来。另外我建议把每个阶段的摘要追加到一个项目级的memory.md文件里而不是只在对话里不断覆盖。这样即使代理在某个会话里丢了上下文下一个新会话也可以重新加载这个文件。6.3 MCP 工具列表太长导致每轮 token 爆炸先别急着怀疑滑动窗口重点看 MCP 工具定义占了多少。用上下文统计看一眼如果工具定义超过每轮总 token 的 25%基本就是工具列表太多了。处理办法有三步按项目拆分配置、开启 context 模式过滤、精简描述与参数 Schema。如果工具列表已经精简到底但 token 还是很大再考虑工具结果压缩。很多编码代理允许你设置“tool result truncation”遇到特别长的返回结果就自动截断成摘要这个功能值得优先开。6.4 按需挂载后代理总是找不到工具这个问题我也踩过。按需挂载之后工具定义不再常驻代理有时不知道某个能力已经被过滤掉了。解决办法有两类一是确保当前任务的提示词里明确列出“本任务可以使用的工具白名单”二是把被过滤但偶尔需要的能力暴露成 Resource 或文档代理在需要时可以主动读取获取工具用法。另外如果代理偶尔需要临时接入一个没在配置里的 MCP 工具不要手工强行塞给它先加白名单再发起新会话。我遇到过几次“越权调用”就是因为工具没被正确过滤结果代理反而乱调用比找不到工具更麻烦。6.5 多项目共用一套配置导致上下文互相污染全局配置适合个人日常小工具不适合长期项目。我会为不同项目单独维护mcp.json和 ChatMemory 参数。尤其注意那些跨项目使用的 Server一定要在配置里限定工作目录和项目范围避免代理在 A 项目里突然去读 B 项目的文件。7. 个人体会上下文工程是配置出来的更是观察出来的做完这一整轮优化后我最深的感触是上下文工程不是一个“设一次就完事”的静态配置而是一个持续观察、持续压缩、持续纠偏的动态过程。你每加一个新 MCP Server、每让代理跑一种新任务上下文的构成都会变化。今天调好的窗口参数明天可能就成了拖累。我现在养成的习惯是每隔一段时间就翻一次上下文统计看两个核心数字工具定义 token 是否反弹重复工具调用是否增多。只要这两项没有明显恶化历史窗口和摘要参数就基本不用动。如果恶化了我会先检查新增工具是不是“好看但不常用”再检查代理是不是在处理不熟悉的目录结构时反复搜索。有一次我为了省 token 把窗口压得很小结果代理连续三次重复读取同一个配置文件反而多花了几轮时间。后来我才明白省 token 不是目的降低无效信息、提高决策一致性才是。真正好的上下文优化应该让代理花更少的轮次做成同一件事而不是让它每一轮都更省但做不对。最后分享一个小技巧我会把每次优化前后的上下文统计截图和任务结果记录到一个context-tuning-log.md文件里。踩过几次坑之后回看这份日志你会很快找到适合自己项目节奏的那组参数。上下文工程说到底就是一门“用最少的信息做最准的决策”的手艺值得慢慢磨。