我最近接了一个挺糟心的编码代理任务让AI把一个老项目里三处相似逻辑统一重构成一个公共函数。刚开始跑得很顺代理甚至自己总结出了一套改动规范。但改到第二处时它忽然问我“这个项目的异常处理约定是什么”——这个约定是它40分钟前自己定的还写进了当时的改动记录里。我翻了一下调用日志发现元凶不是模型而是上下文中途有一次它读入了一个600多行的配置文件把之前的决策细节挤出了有效窗口。从那以后我对“上下文工程”这四个字的理解完全不一样了。所谓上下文工程不是单纯地给模型塞更多token而是用一套机制——比如ChatMemory的滑动窗口、MCP工具的上下文模式——让有限的上下文窗口里始终装着当前任务最重要的信息。这篇文章想聊的就是我在这类AI编码代理项目里从ChatMemory滑动窗口到Context-mode MCP优化上下文的一点实战经验。1. 为什么编码代理的上下文会“爆”先算一笔账1.1 编码代理的上下文账单比你想的更复杂普通聊天场景里上下文基本就是“系统提示用户消息历史往返”。但编码代理的上下文账单要复杂得多系统提示里往往塞了角色设定、工具声明、代码规范、工作流约束对话历史里是自然语言的讨论除此之外还有代理读入的源码文件、生成的diff补丁、编译器/linter的错误输出以及MCP工具返回的结构化数据。我按印象大致估算过一个小型重构任务的token消耗10个文件平均每个300行光代码内容就占12000到15000个token加上30轮对话历史每轮按500到800个token算又是15000到24000个token再算上系统提示和工具声明随便一个会话就能摸到40000到50000个token。这还只是“进行到一半”的状态。很多人以为编码代理翻车是因为模型智商不够但实际排查下来大量失败是“该看到的信息被淹没了”。代理不是不会改代码而是它在决定“怎么改”的那一刻上下文里没有足够的决策依据。1.2 上下文“稀释”效应是任务翻车的隐藏原因上下文窗口有上限这是硬约束。但还有一个更隐蔽的问题即便远没到窗口上限塞进去的无关内容也会稀释模型对关键信息的注意力。实证研究里有个被反复验证的现象——模型对长上下文中位于中间位置的内容记忆和理解效果明显偏差太早的内容被遗忘太靠后的内容又会被近因效应盖过。落到编码代理场景里就是用户在一个多小时前明确说“不要改动公共接口的签名”中间代理读了一堆无关文件、跑了三次测试等到真正要动手改公共接口调用方时它已经完全想不起来这条约束了。上下文工程要解决的核心问题不是“怎么塞得更多”而是“在有限的context budget里让当前最重要的信息占据最优位置”。这也是ChatMemory和MCP上下文优化真正要干的活。2. ChatMemory滑动窗口不是简单丢历史而是“留重点”2.1 滑动窗口的基本结构与关键参数ChatMemory这类记忆模块最常见的实现是给对话历史套一个滑动窗口。它的本质是一个有固定容量的FIFO队列新消息进来旧消息出队。窗口内部保留的是最近N轮对话的原始文本窗口之外的历史会进入“摘要层”而不是被直接扔掉。这里有两个关键参数窗口长度N和摘要粒度。窗口长度决定“代理能够直接看到多近的历史”摘要粒度决定“更早的历史被压缩到什么程度”。窗口长度怎么定我的经验是不要盯着模型的context window硬算而要按任务的“决策跨度”来定。所谓决策跨度是指当前这一步操作需要往前追溯多少步的约定。比如让代理改一个函数签名它至少需要记得你之前定的新签名是什么、调用方有哪些、有没有排除某些调用方。这种任务有效跨度通常是20到30轮对话。反过来如果一个任务需要跨多个文件做一致性修改代理每读一个文件就会产生大量新的上下文20轮窗口根本不够。这时候我倾向于把窗口上限放开到50轮以上同时把摘要层的压缩密度调高。2.2 摘要策略什么时候压缩、保留什么一个常见误区是等窗口满了才做摘要。这会在两种情况下翻车一是窗口满之前的一瞬间早期关键历史还占着原始token没有任何收益二是窗口一满早期历史突然从“原始文本”变成“摘要”代理在某一轮之后忽然丢失了大量细节表现为“失忆”。我建议留出窗口容量的10%到20%作为余量。当已占用空间达到窗口上限的80%时就提前把最老的30%历史做一次摘要把摘要追加到摘要层里再从滑动窗口里弹出对应的原始轮次。摘要里到底要保留什么这在编码代理场景里比对话场景更讲究。我的清单是用户明确给出的硬性约束比如“不要动数据库schema”“保持向后兼容”已经做过的关键设计决策比如“采用工厂模式重构”“缓存放在服务端而不是客户端”尚未完成的任务路径比如“还剩两个调用方没改”已经命名并形成共识的接口、变量、文件路径不要做什么复述代码细节的摘要。代码细节应该靠文件系统去按需读取摘要里只留“决策轨迹”。我在实际项目里吃过亏摘要器把一段重构决策压缩成“讨论了重构方案”但方案本身、参与的文件名全丢了代理后续只能猜。2.3 一个简单的窗口队列实现下面是一个很简化的ChatMemory滑动窗口示意能帮你把机制看得更明白。生产环境里通常不会这么简陋但核心逻辑差不多。from collections import deque class ChatMemoryWindow: def __init__(self, max_tokens30000, summary_batch10000): self.raw_history deque() # 滑动窗口原始历史 self.summary_layer [] # 摘要层 self.max_tokens max_tokens self.summary_batch summary_batch self.current_tokens 0 def add_message(self, message, token_count): self.raw_history.append((message, token_count)) self.current_tokens token_count if self.current_tokens self.max_tokens * 0.8: self._compact() def _compact(self): # 弹出最老的30%原始历史 old_messages [] freed 0 target self.current_tokens * 0.3 while freed target and self.raw_history: msg, cnt self.raw_history.popleft() old_messages.append(msg) freed cnt self.current_tokens - cnt # 生成摘要并追加到摘要层 summary self._generate_summary(old_messages) self.summary_layer.append(summary) # 防止摘要层无限膨胀可再对summary_layer做一级压缩注意这里的关键思想滑动窗口不是从队列里“扔掉”旧消息而是把它们送入另一个更紧凑的表示。整个系统永远保留“原始窗口摘要层”两部分代理看到的是这两部分的拼接。源码里如果对摘要层不设上限那本质上只是把token压力从窗口转移到了摘要链上随着会话拉长还是会崩。真正常态化运行的ChatMemory会把摘要层本身也做成一个可压缩的更新结构或者引入第三方mem0、Zep这类系统做记忆检索——那是后话但机制是同一个。3. 滑动窗口的工程化取舍大小、摘要与层级记忆3.1 窗口大小不是拍脑袋定的窗口越大代理能直接看到的历史越多token成本也越高窗口越小历史压缩得越狠单次请求越快但信息损失越严重。这里有个权衡表是我在选型时反复对照的窗口策略直接历史跨度单次token开销记忆精度适用任务类型短窗口10-15轮约10分钟低低容易“失忆”单文件小修改、简单问答中窗口20-30轮约30-40分钟中中配合摘要可用常规重构、多文件局部改动长窗口50轮以上1小时以上高高但摘要压力大跨模块大重构、长链路排错以200K上下文的模型为例如果代理需要在上下文里同时放下代码文件、工具返回和系统提示那留给对话历史的预算其实也就40K到60K token。按每轮700 token算这个量对应50到80轮原始历史。这也是我认为“无脑调大窗口”不现实的原因——窗口对会话历史的让步必然挤压代码和工具信息的空间。3.2 三层记忆架构在编码代理里的落地真正在长任务里扛得住的是三层记忆架构而不是单靠一层滑动窗口L1原始窗口保存最近N轮对话、最近的diff、最近的工具调用结果。这部分要求原汁原味不压缩代理可以直接引用。L2会话摘要保存从会话开始到窗口边缘之间的决策、约束、关键路径。由摘要器周期性生成是“保质期较长的高浓缩信息”。L3项目记忆跨会话持久化落在代码仓库里的CLAUDE.md、AGENTS.md这类文件里。这部分记录的是团队规范和项目级架构决策不是某个会话的临时状态。我在一个三周周期的项目里测试过这个结构L1窗口的session-token消耗保持在25K到30KL2摘要层压在10K以内L3只读一次并常驻系统提示附近。整体上下文占用五成左右剩下的预算给代码文件和MCP工具返回任务跑下来稳定很多。3.3 “窗口永远不够”的现实与对策有一说一无论怎么调窗口编码代理的上下文就是不够用。因为代码文件的总量是固定的一个大型项目动辄几十万行任何窗口都装不下。滑动窗口只能解决“历史对话”的膨胀解决不了“代码仓库太大”的问题。所以真正的工程组合拳通常是滑动窗口负责管理对话记忆文件系统工具负责按需取代码检索工具负责在项目里找相关片段。不要让代理一口气读完整文件而是让它先用grep/ripgrep定位到函数定义再只读那个函数所在的范围。大文件切片读、按符号读、按diff读——这些“代码读取”的习惯反而比调窗口参数更重要。4. Context-mode MCP让工具端学会“少说话说重点”4.1 MCP为什么会在上下文优化里卡住MCPModel Context Protocol解决的是AI代理和外部工具之间的标准化连接问题。它的基础交互方式是JSON-RPC客户端调用tools/list拿到工具清单再通过tools/call发起具体调用server返回结果。问题在于很多MCP server返回结果的时候“太实诚”。客户端问“列一下src目录下的文件”server可能把所有嵌套路径全量返回客户端问“查一下用户表结构”server把整张表的DDL甚至示例数据都倒出来。这些返回全部会进入上下文一次调用烧掉几千甚至上万token都算常见。我见过一个项目代理只调了一次某个数据库工具的list接口返回了全库200多张表名和字段定义直接让上下文从40K跳到70K。从那一刻起这个会话的有效上下文就被永久削弱了——那些早期的重要对话、已读过的代码全都被这些“工具废话”挤了出去。4.2 Context-mode的设计思路在协议之上做“返回粒度协商”社区里逐渐形成的一种做法我称之为Context-mode MCP它不是MCP协议本身的新标准而是在MCP基础上增加一层“返回粒度协商”。核心思想很简单客户端在发起调用时把自己当前的上下文压力或想要的返回粒度告诉serverserver据此裁剪自己的响应。压力轻、且确实需要全量数据时用full模式上下文已经比较紧张时用compact模式再紧张一点就用summary模式只返回最关键的条目和数字。这样设计背后有两点考虑。第一客户端比server更清楚自己还剩多少context budget所以方向必须是“客户端声明需求服务端适配”而不是反过来的。第二server端的裁剪逻辑是确定性代码比让大模型事后总结更省且更稳——避免每次工具调用之后又产生一遍“对工具结果的摘要”烧二次token。4.3 服务端怎么实现分页、裁剪与摘要先看一个最常规的server端实现方向。假设我们有一个文件列表工具原本返回所有匹配文件{ jsonrpc: 2.0, method: tools/call, params: { name: find_files, arguments: { pattern: *.py, path: ./src, context_mode: compact, limit: 20, offset: 0 } } }client在arguments里多传了context_mode、limit、offset三个字段。server在compact模式下就不返回全量list而是返回“前20条 totalCount truncated提示”。如果客户端需要更多再按offset翻页取。这一套做下来单次工具调用的返回量就能从几千token压到几百token。再进一步某些工具可以做“字段级裁剪”。比如一个GitHub类MCP工具拉取issue列表时默认全字段返回在compact模式下只返回issue编号、标题、状态、标签把body、comments这些耗token的大字段裁掉。直到代理明确调用“读取issue正文”时才去拉完整数据。summary模式更激进适合那些“只需要一个概览”的工具。比如check一下CI构建状态返回“共12个job3个失败失败集中在test-stage”就够了没必要把每个job的日志都塞进来。4.4 客户端侧的信号注入客户端侧需要做的是在合适的时机调整context_mode。我目前的做法是维护一个上下文压力计数器每轮调用结束后从provider返回的usage字段里读取input_tokens对照当前模型的context window计算占用率。占用率低于50%时工具调用全部走full模式50%到70%之间切compact超过70%就强制summary同时把ChatMemory的窗口压缩阈值调得更激进。这些规则可以写进代理的运行时配置里而不是靠人肉盯着。这里有一个我自己琢磨出来的细节千万别只给单个工具加context_mode参数要做一个统一的“上下文压力上下文”传递给所有MCP调用。否则就会出现文件工具被裁剪了、数据库工具还是全量返回的“木桶效应”。我给每个MCP工具都预留了同样的参数组由调度层在发起调用前统一注入保证整条工具链的返回粒度是协同的。5. 一套可落地的上下文配置从模型到MCP的完整链路5.1 上下文预算的分配原则我在一个新的编码代理项目里第一件事不是写功能而是先把上下文预算表列出来让整个团队都认同一件事上下文是一个会消耗的资源每个模块都要在预算内运行。以下是一套我实测过比较稳的预算分配基于200K窗口模型组成部分占比建议说明系统提示与工具声明5%-8%只留角色、约束、关键工作流删掉废话对话历史ChatMemory L1L220%-30%由滑动窗口压缩后加入代码文件内容30%-40%按需读取禁止无脑全文件加载MCP工具声明与返回20%-30%工具声明精简返回走context_mode协商预留buffer10%应对突发的中间推理或工具结果这套预算不是死的。长会话任务我会把对话历史占压到20%以内多给代码文件一些空间单步问答型任务则反过来。核心思想是“谁对当前任务最关键谁拿最多的预算”。5.2 我实测过的一套参数在最近的编码代理项目里我用的是这样一套配置模型200K上下文档位带cache read特性。ChatMemory窗口上限50轮token上限45K当占用36K时触发压缩每次压缩最老30%。摘要层上限10K摘要模板固定包含“用户硬约束/已定决策/未完成任务/关键约定”四个字段。MCP所有工具统一支持context_mode参数默认full上下文占用超50%自动切compact超70%切summary。系统提示压到3K以内只保留角色、通用规范、MCP工具的使用边界。跑了一个两周的真实迭代之后单会话有效完成率比之前明显提升翻车点从前半段的“历史丢失”变成了后半段的“代码文件读取策略”——后者是另一套功夫。5.3 上下文监控你必须要有的仪表盘如果不做上下文监控上面的所有配置都是盲调。我现在每个编码代理会话都会在日志里记录这几个指标provider usage字段里的input_tokens、output_tokens、cache_read_tokensChatMemory压缩触发的次数和压缩比例每次MCP调用的返回token数以及context_mode的实际取值系统提示和工具声明的固定开销每次任务结束后回看这几个指标基本一眼就能看出问题出在哪一环。比如某个工具单次返回经常超过3K token就值得对它单独做裁剪比如压缩触发过于频繁说明窗口上限对该任务类型确实太小。5.4 给代理配一个“自省”工具这个做法是我自己的偏方但效果出奇的好给代理配一个“上下文自省”工具让它在关键决策前主动汇报自己对当前任务的理解。工具逻辑很简单调用后返回一份结构化内容清单里包含“当前窗口内有哪些用户硬约束已经确定的接口命名是什么还剩哪些文件要修改”代理需要先回答完这份清单再继续动手改代码。这相当于在关键任务路径上强制做了一个“上下文健康检查”。如果代理的答案里有一条和实际不符合说明上下文里该信息已经丢失我会先让它去读L1原始窗口或L3项目记忆补齐而不是硬着头皮往下写。我在测试中遇到过至少两次代理正要按错误约定改代码时被这个自检工具拦住。6. 调试上下文时的三个典型翻车现场6.1 翻车现场一代理“失忆”忘记自己定过的规范症状任务进行到一半代理开始重复提问或者提出和先前决策相反的方案。排查链路我会按这个顺序走先查ChatMemory的压缩日志看压缩触发时的摘要内容里有没有包含当前的硬性约束和规范再查摘要生成的完整内容确认是“没有提取”还是“提取了但格式不对”。我遇到过的情况是摘要模板里没有“用户硬约束”这个字段导致代理自己总结的规范在压缩时被归并成一句“讨论了重构方案”。修复很简单统一摘要模板把“用户硬约束”和“已定方案”设为必填字段压缩后的摘要永远保留这两类信息。6.2 翻车现场二一次MCP调用“吃掉”2万token症状某轮对话之后代理突然变得迟钝上下文占用陡增响应变慢且更早的上下文被大量截断。排查时先看MCP调用日志里的返回token数。如果发现某次tools/call返回超过5K token就把它列为重点对象。这类情况九成是server默认返回了全量数据——要么是文件工具返回了整块文件内容要么是列表工具返回了全量路径要么是数据库工具返回了全表结构。对策就是在server端加上分页与字段裁剪逻辑并让客户端在调用时明确传context_mode和limit。改完以后再回看日志单次返回从2万token压到800token上下文占用立刻恢复正常。6.3 翻车现场三加了摘要层反而更不靠谱症状代理对历史决策表现得“过度自信”但实际依据的摘要内容已经失真。这是最常见也最难查的。摘要丢失、压缩出错、或者摘要生成时的截断都会让摘要与真实历史产生偏差。代理拿到一份“看起来合理但细节错误”的摘要时通常会自信地按错误前提行事——错误反倒比“不知道”更隐蔽。我的排查思路是把出问题的决策点反查回L1原始窗口看摘要和原文是否一致。如果摘要确实有误就对摘要器做两个改进一是摘要生成时禁用截断宁可让摘要器多花一轮调用或使用更长的输出token也要让关键字段完整二是在摘要结尾固定附加“不确定信息/待验证项”字段让代理知道哪些结论需要回到原始窗口核对。一旦发现某个会话里代理的决策依据来源是“可疑摘要”我的第一反应不是修摘要器而是让代理通过工具主动读回L1原始历史或L3项目记忆优先保证当前步骤基于可靠信息。踩过这几轮坑之后我现在接到新任务第一件事不是配置大窗口或者堆工具而是先问三个问题这个任务的决策跨度有多大有哪些约束跨过了单轮对话需要长期保留哪些代码和工具信息其实可以按需获取想清楚这三件事之后再去调ChatMemory的窗口大小、给MCP工具选context_mode就基本不会偏。上下文工程说到底不是把窗口调满、把工具结果全塞进去就完事而是让每一分token都花在“帮助模型做出正确决策”这件事上。这一点在我用过的所有编码代理上始终是绕不过去的第一原则。