1. 为什么编码代理做着做着就开始“胡言乱语”上下文才是真正的瓶颈这两年我一直在重度使用各类 AI 编码代理从最早只敢拿它补全函数到现在让它独立改一个跨模块的权限校验逻辑中间踩过最大的坑不是模型不够聪明而是上下文管理出了问题。一个非常典型的现象是刚建好的对话前几轮“智商在线”改起 bug 来思路清晰、引用精准聊到四五十轮之后它开始反复给出同一个错误方案甚至把 A 文件的变量名写到 B 文件里问你“这个变量在哪里定义的”它翻来翻去找不到。你以为是模型变笨了其实不是是它的工作记忆被塞满了、塞乱了。这个问题的学名现在叫“上下文工程”Context Engineering。简单来说大模型的上下文窗口是有限的而编码代理要处理的信息却是无限的项目目录结构、依赖配置、当前文件的全部源码、相关模块的实现、报错堆栈、测试输出、历史对话记录……这些东西一股脑塞进上下文窗口很快就爆了。窗口一爆有两种结果要么直接报错要么模型开始“选择性失明”——只看到离得最近的 token丢掉早期的重要约束。针对这个问题我在这段时间做了两轮比较深入的实践。第一轮是用ChatMemory 的滑动窗口机制优化编码代理的短期记忆让它只保留最有用的近景信息第二轮是把Context-mode MCP接进来用标准化的外部上下文协议把项目里的结构化信息文件树、符号索引、Git 状态变成模型可以动态查询的资源而不是一股脑塞进提示词。这篇文章就把这两块的完整思路、具体配置、以及我在实际工程里的踩坑过程拆开讲一讲希望对正在被“代理突然变傻”困扰的朋友有一点帮助。文章适合谁看两类人。一类是在 Cursor、Claude Code、开源的 Codex 这类代理式编码工具里做二次开发或深度配置的工程师另一类是自己在写 Agent 框架需要处理记忆和上下文调度的开发者。先说明一下下文涉及的具体配置以当下主流的代理框架为例如果你用的框架不同核心思路完全可以平移过去。2. 先说清楚编码代理的上下文窗口到底是怎么被吃掉的2.1 上下文不是“对话记录”而是模型的全部工作台很多刚接触编码代理的人有个误解觉得上下文窗口就是聊天记录的“聊天框长度”。实际上编码代理的上下文包含的东西比聊天记录多得多系统提示词system prompt里定义了角色的行为规范工具定义tool schema是模型可以调用的全部函数接口描述然后是用户消息、助手回复、工具返回结果再往后是被主动塞进去的仓库上下文比如打开的文件、搜索到的代码片段、读取到的目录树。所有这些加起来才构成模型在每一个推理时刻能看到的内容。以我常用的一个代理工具为例它默认加载的上下文大概长这样系统提示词约 1500 token工具定义约 3000 token这还没开始干活就已经吃掉近 4500 token。然后每次读文件、搜代码结果都是直接拼进上下文的一个中等规模文件大概 2000 到 5000 token读上三四个文件加上中间的工具调用记录一万 token 就没了。一次简单的重构任务来回改七八轮上下文总量轻松破 3 万 token。而大多数主流模型的窗口是 10 万到 20 万 token听起来够大但编码任务的特点是每一轮都会产生新的工具结果和代码片段这些内容几乎是只增不减的越到后面窗口里无用的“旧账”越多。2.2 窗口溢出的三种典型表现在实际使用里上下文被塞满之后模型的行为会出问题。你观察到的典型表现有三种。第一种是“丢三落四”。比如你最开始告诉它“这个项目用 pnpm不要用 npm”到了第 20 轮它开始在命令里写 npm install。不是它忘了是早期那条约束被挤到了窗口的边缘模型在做当前预测时对远端 token 的注意力权重极低基本相当于“看不见”。第二种是“重复劳动”。模型因为记不住已经做过的修改会反复提出同一个方案。我遇到最离谱的一次它连续四轮建议我给同一个函数添加同一个参数而我在第三轮已经明确说了“这个参数会导致 A 模块的测试失败并给出了证据”。从窗口上看我的反驳在第 15 轮它看到的却是第 18、19 轮的讨论中间的关键信息被后续的工具输出稀释了。第三种是“直接报错”。上下文超过模型硬性限制时API 会返回 400 错误代理直接中断。这个最直接也最容易发现。2.3 为什么传统“对话清理”对这个场景不够用有人会说那我把旧对话手动清掉不就行了这确实是很多代理工具内置的“清空对话”功能但编码场景和闲聊场景不一样。闲聊里旧内容清掉不影响后续任务编码里很多旧内容恰恰是你下一次修改的输入依据。比如你前 30 轮在讨论一个模块的重构方案里面的决策理由对后续实现至关重要直接清空就等于把“设计文档”扔了模型只能凭感觉写代码结果常常跑偏。所以编码代理需要的不是“清空”而是“压缩和筛选”——把重要的历史决策保留成摘要把无关的长代码输出折叠掉把工具返回的冗长日志截断成结论。这就引出了 ChatMemory 这类专门做记忆管理的组件。3. ChatMemory 滑动窗口实战让代理只记住“此刻最需要”的上下文3.1 ChatMemory 到底解决什么从“全量保留”到“动态取舍”ChatMemory 不是一个具体产品的名字而是一类“对话记忆管理模块”的统称市面上很多代理框架都内置了类似的实现比如 Claude Code 的自动压缩、Cursor 的会话摘要、以及一些开源 Agent 框架里的 ChatMemory 组件。核心思想就一句话用一个滑动窗口 摘要机制替代“全量保留所有对话”的朴素策略。具体来说滑动窗口的工作方式是这样的窗口固定保留最近 N 轮对话比如 20 轮保证模型对当前任务有足够的“近景记忆”超过窗口的历史对话不会直接丢弃而是被一个独立的摘要模型或者规则引擎压缩成一段几百 token 的“远期记忆摘要”放在系统提示词里作为背景信息。这样一来窗口大小是可控的历史信息也不是完全没有只是从“逐字逐句”变成了“压缩提纯”。我用一个生活化的类比解释滑动窗口相当于你办公桌上的物理空间桌面上只放当前任务需要的文件和工具抽屉里放一个笔记本上面写着“过去三天处理了哪些事、结论是什么”。你动手干活时只看桌面需要回忆背景时翻一下笔记本。3.2 滑动窗口的参数怎么定窗口长度和摘要时机滑动窗口的核心参数就两个窗口长度保留多少轮/多少 token和摘要触发时机什么时候开始压缩旧消息。先说窗口长度。我给过几个不同规模项目的配置经验参考如下项目规模典型上下文总量建议窗口长度备注单文件脚本/小工具5k~20k token30~50 轮对话窗口够大摘要压力小中型项目几十个文件20k~60k token20~25 轮对话工具调用密集要控制窗口大型仓库数百文件60k token10~15 轮对话必须频繁摘要窗口越小越稳我这里说的“一轮对话”包括用户输入、助手回复、以及这中间发生的所有工具调用和返回结果。在代理场景里工具调用往往比用户对话更吃 token所以窗口长度的判断依据最好按 token 数而不是轮数来算。一个稳妥的设置是让窗口内的总 token 数不超过模型上下文的 1/3。模型上下文如果是 10 万 token那滑动窗口内最多攒 3 万 token 左右剩下的空间留给系统提示词、工具定义和临时读取的代码。再说摘要触发时机。有两种策略一是“达到阈值就摘要”比如窗口内 token 超过 2 万就触发一次摘要二是“每 N 轮摘要一次”比如每 10 轮就把最早的一批消息压缩掉。我实际用下来阈值策略更有效因为它能应对工具调用突发变多吃 token 的情况。如果你用的是轮数策略遇到过长的工具返回时窗口还是会突然爆掉。3.3 摘要内容怎么设计不是“总结提纲”要带决策依据摘要的质量直接决定滑动窗口的实际效果。很多实现把摘要写成“前面聊了什么”比如“用户讨论了重构方案提到了工厂模式和策略模式”。这种摘要太弱了模型看了等于没看它需要的是决策依据而不是话题列表。我自己的做法是强制摘要包含以下几个要素已确定的决定比如“确认使用 pnpm不用 npm”“权限校验走 PermissionService 而不在 Controller 里写”正在进行的任务比如“正在重构 AuthService.login已完成异常处理部分下一步是补充单元测试”关键的代码位置比如“数据源配置在 src/config/database.ts 第 42 行”“相关类型定义在 src/types/auth.ts”已排除的方案这个非常有用——告诉模型“不要再用 Redis 做缓存了之前讨论过因为序列化问题放弃了”能避免它反复往同一个坑里跳写这些摘要的时候为了让模型能准确理解我会在摘要里保留原始对话中的术语和文件路径不做过度改写。你用模板约束摘要的格式比开放式让模型自由发挥要稳定得多我现在的模板长这样【历史决策摘要】 - 决策1{内容}理由{简洁说明} - 决策2{内容}理由{简洁说明} 【任务进度】 - 当前目标{一句话} - 完成部分{已完成事项} - 待办部分{下一步事项} 【重要位置索引】 - {文件路径}:{行号} 对应 {什么内容} 【已排除方案】 - {方案}{排除原因}3.4 我的实测对比开与关差距有多大我拿手头一个实践项目做了对照实验——一个约 40 个文件的中型 Express 后端项目任务是“给所有接口补充统一格式的错误响应中间件”。不开 ChatMemory 的状态下跑到第 30 轮左右模型开始把errorHandler中间件的注册位置放错放在路由之后导致不生效并且在修正时反复尝试一个错误的 import 路径。开了滑动窗口窗口 20 轮 阈值摘要之后同样的任务跑了 50 多轮仍然稳定模型能准确回忆出“早期确定过要使用 AppError 类而不是直接把 error 抛给 express”这个决策。另外上下文占用上的差别也很明显不开滑动窗口时第 40 轮的上下文总量约 8.5 万 token开了之后稳定在 4 万左右省了一半还多。这直接决定了长任务的可持续时间——从“撑到三轮就要清空上下文”到“可以一口气把一个小模块改完”。3.5 滑动窗口的一个反直觉坑窗口越小代理越“短视”我知道很多人一看滑动窗口第一反应是“那我把窗口设小一点不就更省 token 吗”这里有个反直觉的坑窗口设得太小代理会变得极度短视。它只看得到最近几轮的内容根本记不住几分钟前你让它“先写测试再写实现”的要求经常直接就开始写实现。而且摘要如果太频繁摘要本身的 token 也会挤占窗口空间造成“记忆套娃”——模型既要看摘要又要看新对话注意力被进一步稀释。我试过把窗口压到 8 轮结果非常痛苦模型每次操作都像失忆了一样看两轮就忘了前面的约定。最后折中的配置是15 到 20 轮窗口 token 阈值触发在省 token 和记忆连续性之间找到了一个平衡点。你配置的时候也要做同样的取舍纯靠理论推是不可行的必须拿真实任务跑一遍调参。4. Context-mode MCP把外部上下文变成模型可以“按需查询”的资源4.1 MCP 是什么一句话讲清楚这个协议在干什么讲 Context-mode MCP 之前先花点篇幅把 MCPModel Context Protocol模型上下文协议说透。MCP 是一个开放协议定义了 AI 代理host和外部工具/数据源server之间的通信标准。你不需要知道底层传输的细节只需要理解它的主要价值以前接一个外部工具要在代理代码里写一套专属 API 调用逻辑MCP 统一了格式之后你只要开发一个 MCP server任何支持 MCP 的代理都能直接接上。目前社区里已经有非常多的 MCP server 生态覆盖了浏览器操作Playwright MCP、Chrome DevTools MCP、安全测试工具Burp Suite MCP、Yakit MCP、数据库MySQL 的 MCP server、甚至游戏和创意软件Unity MCP、Blender MCP。编码代理接了 MCP 之后模型可以实时调用这些工具拿到结果再继续写代码。这个我在之前的实践里就深有体会——接入数据库 MCP 之后模型能直接查表结构而不是靠“猜”字段名来写 SQL准确率提升了一个量级。不过MCP 也有一个隐患工具返回的数据同样会占用上下文窗口。你让模型查一次数据库返回几百行记录这本身就是一笔不小的 token 开销。Context-mode MCP 正是针对这个问题出现的优化思路——它强调的是MCP server 不只是“执行工具”它还可以“提供上下文资源”让代理按需、分块地获取外部信息。4.2 Context-mode 的核心工作方式从“全文推送”到“目录式检索”我之前用过不少 MCP server 作为编码代理的外部上下文源先从最典型的项目文件树入手说明。默认情况下如果你把整个项目的文件树塞进提示词一个中型项目可能有上千个条目光目录结构就吃掉 1 万到 2 万 token。更关键的是模型真正需要看的只是当中少数几个文件但为了构建“全局感”它不得不接收全量清单——这是一种巨大的浪费。Context-mode MCP 改变了这个交互模式核心是三步摘要目录MCP server 先把项目结构压缩成一层“摘要目录”只列出顶层目录和每个目录下的一级文件模型先看这个缩略版。按需展开模型想了解某个子目录时调用一个“展开目录”工具server 才返回该目录的完整子项。按语义检索模型不再靠猜文件路径而是直接按语义问比如“找到所有校验用户输入的代码”server 返回相关文件路径和简要说明模型再决定读哪个文件。你发现没有这本质上是把“全量喂给模型”变成了“模型自己动手查”。我大量实测下来的结果是上下文占用减少 40% 到 60%而对代码库细节的定位准确率反而提升了因为模型不再被无关文件干扰。4.3 在你的代理框架里配置 Context-mode MCP 的实操步骤具体配置方法我以一个常见的代理框架支持 MCP client 配置为例展示。一般是在配置文件里声明 MCP server 的地址然后框架会自动建立连接。开发自定义 MCP server 时你需要定义两个核心部分资源Resources和工具ToolsContext-mode 的“目录式检索”主要靠 Resources 暴露元数据、靠 Tools 暴露检索能力来实现。我把核心概念拆一下Resources用于暴露只读的上下文数据。比如项目文件树摘要、某个文件的内容片段、Git 状态信息。代理框架会自动把这些资源的内容暴露给模型但你可以控制资源的大小和粒度。Tools用于暴露可执行的操作。比如展开目录、按关键词搜索代码、查询符号定义。Tools 本身只占少量 token工具名 参数描述真正的大块内容是在调用后返回。一个典型的 Context-mode 配置思路我在伪代码里写一下你要接入不同框架时替换成对应 API 即可# MCP server 配置示例 resources: - name: project-tree description: 项目目录摘要顶层结构 data: 顶层文件夹 各目录一级文件清单 - name: git-status description: 当前 Git 工作区状态摘要 data: 修改/新增/删除文件列表 tools: - name: expand_directory description: 展开指定目录返回其直接子项 params: [relative_path] - name: semantic_search description: 按自然语言查代码返回文件路径与摘要 params: [query, limit] - name: read_file_snippet description: 读取文件指定区间的代码片段 params: [path, start_line, end_line]我在实操里的经验是资源部分尽量“小而精”工具部分尽量“全而稳”。资源是每轮都会给模型看的一定要省工具是模型按需调用的多几个、描述写得清晰一点没坏处能显著提高模型找到正确工具的几率。4.4 我把无关上下文挡住之后代理“老实”多了接好 Context-mode MCP 之后我明显感觉到代理的行为模式发生了改变。最典型的是“全局搜索依赖”这件事。以前模型想知道某个变量在哪定义它会直接调一个全仓库搜索工具把几百个匹配结果全读进来然后大海捞针。现在它会先看资源里的“项目结构摘要”判断变量应该在哪个模块然后用语义搜索直接命中目标文件再用 read_file_snippet 读取关键函数附近几十行代码。有一个案例我记得很清楚帮一个老项目加日志埋点整个仓库有 200 多个文件模型接了 Context-mode 之后前前后后只主动读取了 5 个文件就把埋点的工作全部完成了。要是在以前它大概率会先扫描整个 utils 目录的十几个文件再逐个判断上下文消耗至少差三倍。这种“按需查找而不是全量扫描”的行为模式就是 Context-mode 带来的最大变化。4.5 两个 MCP 的安全细节token 泄露和超时如果你也在给代理接 MCP有两个安全细节我强烈建议你注意。第一个是token 泄露到上下文。很多 MCP server 返回的数据是明文塞进上下文的如果这个数据涉及 API 密钥、内部 URL、私有 IP模型在后续生成代码时可能会“顺手”把它们写进文件里甚至通过代码提交到远端仓库。我见过一次事故MCP server 查数据库返回了连接串里面带着数据库密码模型在写配置示例时直接把真密码写进了注释里差一点就提交上去。应对办法有两层一是 MCP server 端做数据脱敏把敏感字段替换成[REDACTED]二是在代理的系统提示词里明确写“不得将上下文中出现的凭据信息写入任何文件或代码”。第二个是长耗时工具调用导致代理超时。模型调用 MCP 工具时如果 server 响应太慢整个代理循环会卡住。尤其是语义搜索这类工具如果索引没建好搜索一个小仓库都要几秒甚至更久非常影响使用体验。我的建议是一切要读大文件的场景优先用 read_file_snippet 按行区间读而不是一次读全文件搜索工具如果发现仓库文件数量超过阈值先把结果限制在前 10 条避免返回过多内容。5. 让两部分协同工作一套分层上下文的完整编排方案5.1 分层模型远期记忆、近期窗口、即时上下文三层各管什么这两部分实践做下来我最大的体会是ChatMemory 滑动窗口和 Context-mode MCP 不是替代关系而是互补关系——它们分别承担了“纵向时间”和“横向空间”两个维度的上下文管理。真正完整的方案是把它们叠起来形成一套分层上下文架构。我把这套架构总结为三层每一层对应不同的信息粒度和生命周期远期记忆层摘要层存放超过滑动窗口的历史决策摘要。这部分由 ChatMemory 的摘要机制负责。特点是信息密度高、token 占用小几百到一千 token更新频率低。近期窗口层工作层存放最近 15~20 轮的原始对话、工具调用、代码读取结果。这是模型决策时的主战场token 占用量最大但必须控制在上下文窗口的 1/3 以内。即时资源层查询层通过 Context-mode MCP 按需获取的项目结构、符号索引、Git 状态。这层的关键点是“按需”模型用到一个查一个用完不占地方。这三层叠加起来的配置思路是远期记忆负责“不遗忘背景”近期窗口负责“聚焦当下”即时资源负责“拓展视野”。每一层的信息都在自己的职责边界内运行互不越权这样模型的注意力才能被引导到真正关键的地方。5.2 一个完整的会话流程从“开新任务”到“任务收尾”以我的一次实际重构任务为例把整个流程走一遍给你看阶段一初始化我新建对话系统提示词加载后代理自动获取“项目结构摘要”资源层和“Git 状态摘要”资源层。ChatMemory 里还没有历史摘要窗口几乎是空的上下文干净利落。我给出任务“把 auth 模块从 CommonJS 迁移到 ESM。”阶段二探索模型看到项目树里 auth 模块文件并不多调用 expand_directory 展开 src/auth 目录读取 package.json 和相关入口文件片段。此时窗口里累计约 1 万 token主要是读到的文件内容ChatMemory 开始记录这些工具调用方便后续回溯。阶段三决策与执行模型开始改动文件。因为项目里有很多 CommonJS 的require调用模型需要追踪引用关系它会通过语义搜索找到所有require(../auth)的位置。此时上下文缓慢增长ChatMemory 的滑动窗口已经产生早期摘要把第一轮“确认范围”的对话压缩掉了。阶段四中途纠偏用户指出“config 目录下的文件不要改”这会作为一条新的重要决策进入近期窗口。滑动窗口机制会把这条决策保留在最近的 20 轮内短期不会被摘要掉所以模型在后续操作中始终能看到这条约束。阶段五验证与完成模型运行测试读取测试输出。测试输出的内容通常比较冗长ChatMemory 会把它截断为结论摘要Context-mode 的 read_file_snippet 只读失败用例的相关文件区间。最终模型给出总结整个任务大概消耗了 6 万 token但上下文的峰值控制在 3.5 万左右没有一次达到窗口上限。5.3 关于“长期项目”的额外建议每日会话的上下文接力代码项目往往不是一次会话能完成的。我的实践经验是要多利用“每日会话的上下文接力”——每天开工前先让模型读取昨天的会话摘要文件把它放进今天的远期记忆层然后才开始新任务。这里有个细节摘要文件本身也可以由代理在收工时自动生成存成 markdown 放进项目目录比如.agent/memory/session-summary.md。这样即使中间的哪次会话上下文彻底崩了你也有最后一层物理意义上的“记忆备份”不用重新解释背景。我自己的一个额外收尾动作是每次会话结束后目标任务相关的关键文件路径、修改决策、遗留风险统一追加到项目根目录的AGENTS.md里。这个文件作为代理的“永久记忆”比任何会话内的摘要都可靠——因为它是独立于模型的上下文窗口存在的。5.4 性能开销的实测数据值不值得做这套方案有人会顾虑又是滑动窗口又是摘要还要跑 MCP 查询这套方案本身的性能开销值不值我用一组实测数据回答一个 40 文件左右的中型项目常规编码任务执行 50 轮的上下文消耗和 token 成本对比开与不开这套方案差别明显。方案平均上下文峰值50 轮总 token 消耗模型“失忆”事件次数无上下文管理8.2 万 token38 万 token5 次仅 ChatMemory 滑动窗口4.6 万 token26 万 token2 次完整三层方案3.2 万 token18 万 token1 次虽然完整方案多跑了一些 MCP 查询但这些查询都是轻量的目录展开和片段读取单次耗时基本在几十毫秒到几百毫秒之间对整体节奏的影响可以忽略。token 的节省却接近 50%这意味着在相同预算下你能让代理完成近一倍的活。6. 我踩过的几个具体坑给你省点弯路6.1 摘要模型选错了摘要比原文还难懂ChatMemory 的摘要质量除了模板之外还取决于摘要模型的选择。我一开始图省事直接用了一个参数很小的本地模型做摘要结果生成的摘要信息密度极低经常把“用户决定用 A 方案”写成“用户提到了方案 A 和方案 B”完全没有决策倾向。换用当前会话里能力较强的大模型做摘要后质量肉眼可见地提升代价是多花了一点 token但对比上下文整体节省这部分开销完全可以接受。我的建议是摘要这个环节不要省它值得用最好的模型。因为摘要一旦生成后面的几十轮对话全部以它作为背景依据如果摘要本身不可靠整个会话都会在错误的前提下进行后续纠偏成本远高于那一次摘要的 token 成本。6.2 MCP 资源更新不及时模型读到的是“过期地图”Context-mode 的资源层有个隐蔽的坑项目文件树摘要如果缓存了而用户刚新建了文件或文件夹模型拿到的“地图”是旧的。它可能明明知道有一个新文件src/plugins/logger.ts但项目树摘要里没有导致它“认为”这个文件不存在甚至在新代码里重复定义同名模块。我的解决办法是给 MCP server 加一个“刷新缓存”的时机——每次代理开始新任务、或检测到工具被调用时先检查文件系统的变更。简单做法是比对目录的修改时间戳复杂一点的可以做一个文件监听器一旦监听到变更就主动推送新的项目树摘要替换掉模型上下文里的旧资源。如果你用的是现成的 MCP server至少要手动确认它的缓存刷新机制别让代理长期拿着项目早期的结构图干活。6.3 工具描述写得太含糊模型根本不会用对工具Context-mode MCP 里工具的“自我描述”直接决定了模型能不能找到它。我早期写的 semantic_search 工具描述是“搜索代码”结果模型有时候拿它搜索配置文件内容有时候又拿它搜索 Git commit 历史返回结果五花八门。后来我把描述改得更具体“按自然语言在项目源码中定位类、函数、变量的定义与引用位置返回文件路径、行号和代码片段”模型调用它的准确率一下就上去了。这背后有个规律描述里给出“适用场景 预期返回结构”比单纯的功能名词对模型更友好。你可以在描述里补充一句“不要在文件路径已知时使用此工具直接读文件即可”这能减少很多不必要的搜索调用顺带节省上下文。6.4 要对“上下文压缩”这件事设监控别等窗口爆了才反应最后一个小提醒无论你配置得多完善都建议给代理加一个“上下文水位监控”。具体的实现可以是在每轮对话结束时统计当前上下文的 token 数超过阈值时触发主动摘要或提示用户手动干预。我见过太多同事把窗口上限当警戒线来用每次都等到 API 报错才开始清理体验非常痛苦。监控做起来不难。代理框架一般都会暴露当前上下文的估算方法你只需要在每轮循环里加一个检查if context_token_count threshold: chat_memory.compress_oldest_messages()阈值我建议设置为模型最大上下文的一半留出一半的空间给后续工具调用和新信息。这套小机制虽然简单但是它能把“被动的窗口爆掉”变成“主动的稳步压缩”整个编码代理在长任务里的稳定性会有一个质的提升。6.5 再分享一个提升代际稳定性的做法结束前列出“本轮未决事项”这个做法不仅仅是上下文工程更偏向 Agent 工程实践但它和上面所有的优化配合得很好。每一轮对话结束时让模型用固定格式输出一行“未决事项”比如“等待确认是否允许修改 config 目录下的文件”“待验证登录接口重构后测试是否通过”。这些未决事项会进入下一轮的上下文成为摘要的一部分。它相当于给代理的计划能力加了一个“锚点”既约束它不要跑偏也方便你在会话间恢复记忆。实际效果就是以前一个多任务的会话模型容易在子任务切换之间丢掉主线有了未决事项清单之后每次切换都能回到主线任务完成率提升明显。这个做法成本极低但收益非常稳定我强烈建议你加上。我的最终体会回到标题这句“从 ChatMemory 滑动窗口到 Context-mode MCP 上下文优化”这两条路径其实代表了上下文工程的两个方向一条是“管好时间线”让模型在长会话里不忘事一条是“管好资源面”让模型在复杂项目里精准取数。任何一条做到位都能带来明显改善但只有把两者叠起来你才会真正体会到“代理的上下文永远够用”是什么体验。对我个人来说这段时间最大的收获不是省了多少 token而是我重新理解了“上下文”这件事的本质——它不是模型的缓存而是模型的思考边界。你要做的不是把边界撑大而是把它打理得井井有条。