先说一个让我印象深刻的翻车现场。当时我在给一个编码代理接入中等规模的Java后端项目任务是从零迁移一个订单模块。刚开始非常顺利代理能准确给出模块依赖图、识别出REST Controller和Service的调用链前5轮修改基本靠谱。但到第8轮它突然开始重复生成早就被淘汰的旧Controller还坚持认为某个已经被删除的DTO仍然在用。最让我心态崩掉的是我一开始就写进系统提示里的约束Service层禁止直接访问仓储实现从第10轮起完全失效它生成的代码几乎次次踩雷。我花了两天时间反复排查最终把根因锁在上下文工程上发送给模型的实际prompt里早前那些关键约束、模块关系、具体文件路径早就被滑动窗口挤出上下文了。留在窗口里的全是一堆中间态噪声——工具调用的报错堆栈、临时调试输出、无关文件的搜索片段。AI编码代理不是能力不够是记忆被垃圾填满了。这篇文章我会结合自己在这类系统上的实战把两条主线讲透一条是ChatMemory滑动窗口这种经典的对话记忆机制它的原理、实现方式、以及为什么单纯记最近远远不够另一条是基于Context-mode MCP的上下文优化如何把上下文管理从应用层堆料下沉到协议层按需供给。对正在做AI编码代理、智能体或多工具工作流的工程师来说这两块都是绕不开的硬功夫。1. 上下文工程为什么是编码代理的隐形天花板1.1 模型不行还是上下文不行一个快速判断方法先说一个快速判断方法。当时我怀疑是模型能力问题换了更强的模型重跑同样的任务结果前半程表现确实变好但到第10轮左右又开始犯同样的失忆错误。这就很能说明问题如果换不同模型后错误形态一致那大概率是输入端出了问题而不是模型输出能力出了问题。我后来做了一个对照实验同一任务一组用完整上下文跑另一组用被驱逐后的上下文跑两者差异极其明显。完整上下文下代理能准确遵守约束被驱逐后的代理则频繁猜测。这个实验非常简单但在排查AI编码代理问题时极其好用——先区分是上下文坏了还是模型不行再决定优化路径。1.2 编码场景比聊天场景更难的三个矛盾AI编码代理和普通聊天助手的最大区别在于它的记忆不止包含对话还包含文件、依赖关系、工具输出、用户反复确认过的接口契约。要把这么多信息塞进有限的上下文窗口同时保证关键信息不被冲走本质上是在解决三个矛盾有限窗口与无限项目信息一个中大型项目有几百个文件、几十万行代码但上下文窗口只有几万到十几万token。全量注入不现实只能靠取舍。时间近邻与逻辑相关对话记忆天然按时间排列但编码任务的关联性往往是空间/拓扑的。比如30分钟前确认过的接口签名和当前正在修改的调用方在时间上隔了很多轮在逻辑上却是一体的。按时间窗口保留记忆很容易丢掉真正相关的东西。信息完整性与token成本注入越多上下文token消耗越大注意力越分散注入太少代理又缺乏决策依据。这个平衡点非常微妙。理解这三个矛盾后你会发现上下文工程不是简单的调窗口大小而是一整套围绕什么信息值得留下、什么信息可以丢弃、什么信息应该按需获取的设计。这也是后面所有方案的原点。2. 从断尾求生到筛选淘汰ChatMemory滑动窗口的演进2.1 最朴素的滑动窗口实现与其失效模式滑动窗口Sliding Window是ChatMemory体系中最基础的机制。它的朴素思路很简单维护一个先进先出的消息队列总量超过上限时从最旧的消息开始丢。import tiktoken from collections import deque class ChatMemoryWindow: def __init__(self, max_tokens: int): self.max_tokens max_tokens self.records: deque deque() self.total_tokens 0 self.enc tiktoken.encoding_for_model(gpt-4) def add(self, role: str, content: str, meta: dict | None None): record { role: role, content: content, meta: meta or {}, tokens: len(self.enc.encode(content)), } self.records.append(record) self.total_tokens record[tokens] # 粗暴策略超过上限就从头丢 while self.total_tokens self.max_tokens: dropped self.records.popleft() self.total_tokens - dropped[tokens]这段代码逻辑没错但用一段时间就会发现问题被丢掉的往往恰恰是最不该丢的。比如用户在第2轮明确说过缓存不要用Redis用进程内Caffeine这条信息在第3轮被某次大型工具输出挤出窗口后代理从第4轮开始就频繁生成Redis相关代码。时间最久的信息被无条件优先丢弃跟信息最重要根本不搭边。2.2 双因子驱逐策略时间衰减乘以重要性评分朴素窗口只认时间不认价值。我开始改造它的第一步是引入驱逐评分不再机械地从头砍掉旧消息而是对窗口内所有消息打分然后砍掉综合得分最低的一批。# 重要性因子编码场景下的关键信息信号 KEY_TERMS [ 必须, 禁止, 注意, 契约, 不要用, 接口签名, 依赖方向, 架构约束, 用户偏好, ] def time_decay(record, current_time) - float: # 时间衰减越旧的分越低但衰减不是线性的 age_minutes (current_time - record[timestamp]).total_seconds() / 60 return max(0.2, 1.0 / (1.0 age_minutes / 30.0)) def importance_score(record) - float: text record[content].lower() score 0.0 score 2.0 if record[role] in (user, system) else 1.0 score 3.0 if any(k in text for k in KEY_TERMS) else 0.0 score 4.0 if record[meta].get(is_anchor) else 0.0 return score def eviction_candidates(records, budget_ratio0.2): scored [] for r in records: # 总分 时间衰减 * 重要性 total time_decay(r, r[timestamp]) * importance_score(r) scored.append((total, r)) scored.sort(keylambda x: x[0]) keep int(len(scored) * (1 - budget_ratio)) return [r for _, r in scored[keep:]]这个改动立竿见影用户明确表达过的约束被降级驱逐的概率大幅下降。但很快又暴露出新的问题——评分只是个启发式它无法理解语义。比如不要在事务里调用远程接口这类句子如果措辞不包含强标记词权重就会偏低。我后来补了一个硬规则所有记录在写入时可以通过meta标记is_anchorTrue来锚定锚点记录无论多旧都不参与驱逐。2.3 摘要编译层窗口之外的第二级记忆即使有锚点和双因子评分窗口空间依然有限。我引入的第二层是摘要编译当一个高价值记录即将被驱逐、或者窗口占用即将超过阈值时把一批旧记录交给模型压缩成结构化摘要然后存到独立摘要存储中。def compress_records(records: list) - str: raw \n.join(f{r[role]}: {r[content][:500]} for r in records) summary llm.complete( 请压缩以下对话记录为结构化要点保留接口签名、 架构约束、用户明确偏好忽略调试噪声\n raw ) return summary注意摘要层的设计目标不是全面而是信息密度高。我一般把摘要分成三个层级任务级摘要当前任务的目标、已完成步骤、剩余步骤。会话级摘要本次会话中用户反复强调的偏好和约束。项目级摘要跨会话通用的架构决策、目录规则、技术栈约定。摘要层每次注入模型时也要算token成本所以它不是用来全量塞进窗口的而是作为候选上下文存在当新任务需要时从摘要层检索相关片段注入。简单说窗口管的是过程记忆摘要层管的是长期记忆。2.4 一个容易搞错的点全局窗口与会话窗口的切分在编码代理场景里有一类问题特别容易踩把对话轮次和工具输出放进同一个滑动窗口导致一次大型搜索的输出直接挤掉好几轮关键对话。我的做法是把窗口按职责切分全局窗口系统提示、用户核心目标、锚点约束。这部分用最大隔离度保护驱逐优先级最低。会话窗口近几轮的对话与决策记录。走双因子驱逐。工具输出区文件读取、搜索结果、命令输出。这个区域通常单独限制在2k-4k token内超出后立刻转摘要不进入主窗口。切分之后至少搜索输出挤掉用户指令这类惨案不再发生。这算是我在ChatMemory设计上最收益最大的一个改动。3. 滑动窗口解决不了的错位问题最近的不等于关键的3.1 长链路重构中的上下文断裂滑动窗口本质上是时间近邻优先的机制但编码任务中真正要命的信息往往不是最近的。拿那次订单模块迁移来说第3轮确认了新模块的命名规范第15轮代理开始写代码时它已经完全不记得这个规范了。中间隔的十几轮里塞满了各种探索性的grep、报错、临时思路真正重要的那个决策反而被淹没。这就是上下文工程里最经典的错位时间上的距离不等于逻辑上的距离。滑动窗口用时间轴组织记忆但编码任务需要的是按依赖关系组织记忆。当一个30轮前的架构决策和当前正在改的文件在逻辑上高度相关时滑动窗口帮不上忙——它只会给你最近的东西。3.2 摘要漂移压缩带来的信息失真摘要层也不是万能的。模型在压缩信息时会有损耗尤其在经过多轮摘要的摘要之后约束会逐渐失真。我见过一个案例原始约束是核心模块禁止依赖基础模块经过三层压缩后变成注意核心模块依赖问题再后来直接变成模块依赖需要注意。约束的刚性完全消失了代理在代码里该违反还是违反。应对办法是关键约束必须用锚点而不是摘要来保存。锚点可以是原始文本原样保留不允许压缩只允许新增或替换。在我在ChatMemory中的实现里锚点记录有几个硬性规则——不驱逐、不压缩、不参与token预算淘汰每次请求时按需加载。代价是如果锚点太多token占用会激增所以我一般把锚点上限控制在20-30个超出后需要人工或模型合并。3.3 编码场景中最容易被误驱逐的三类高价值上下文结合我自己的经验以下三类信息在滑动窗口里最容易意外消失必须特殊对待架构约束分层规则、依赖方向、禁止反向调用等。这类信息通常只在任务早期出现但影响贯穿整个任务。接口契约已经确认过的函数签名、参数顺序、返回结构、数据模型。模型一旦记错生成的代码会引发连锁编译错误。用户偏好命名风格、测试框架选择、注释语言。这类偏好往往藏在某轮不起眼的对话里别人不提它就想不起来。对于这三类信息光靠评分权重不够应该直接走锚点机制。我甚至会为它们单独建一个契约区放在系统提示之后最显眼的位置。毕竟在编码代理里用户怎么说的往往比模型觉得怎么合理更重要。4. 下沉到协议层Context-mode MCP如何改变上下文供给方式4.1 MCP是来干什么的为什么它对上下文工程有意义先简单说下MCPModel Context Protocol。它是用来统一AI应用与外部工具、数据源之间通信的协议核心结构是HostAI应用比如编码代理本身、Client协议客户端、Server工具/数据提供方。Server把能力暴露为资源和工具Host通过标准接口调用它们。在MCP出现之前编码代理获取项目信息最粗暴的方式是全量注入把相关源文件全部读出来拼进prompt。这种方式对上下文窗口的压力极大而且文件一大很多内容模型根本没用到白白浪费token。MCP不一样的地方在于它把信息从跟着prompt走变成摆在远端按需拉取。Host可以在具体任务需要时通过资源URI请求某个特定的数据集而不是把整个仓库都塞进来。4.2 Context-mode让服务器成为上下文提供方而不是工具堆严格来说Context-mode不是MCP协议里某个强制标准而是我在实际项目中把MCP能力组织成上下文服务时采用的一种设计模式。它的核心思路是MCP Server除了暴露工具还要暴露了一批可以按需查询的上下文域context domain。打个比方传统方式是找个实习生把图书馆所有书都搬到你桌上Context-mode则是图书馆配一个专业检索员你问我要查接口调用链她给你一张A4纸的结构化摘要而不是把整本书丢过来。在我落地过的系统里Context-mode Server会声明自己的上下文域比如dependencies模块依赖图、反向依赖、循环依赖检测。api-contract指定符号的签名、调用方列表、相关测试。architecture-rules项目级分层约束与模板。error-trace最近一次失败的堆栈、相关日志摘要。Host编码代理在任务运行中根据当前需求动态订阅或查询这些上下文域。返回的内容不再是文件源码而是已经加工过的结构化信息信息密度远高于原生文本。4.3 一个最小Context-mode服务端的骨架下面是一个示意性的Server骨架用来说明Context-mode的代码形态。生产上你可以用官方MCP SDK来实现我这里的重点是看它的资源路由方式# context_mode_server.py import json from mcp.server import Server app Server(repo-context) app.resource(context://dependencies/{module}) def dependency_context(module: str): 返回模块的依赖关系摘要而不是完整源码 graph build_dependency_graph(module) return json.dumps({ direct_deps: graph.direct_dependencies(module, depth2), reverse_deps: graph.reverse_dependencies(module), risk_nodes: graph.find_cycle_nodes(), }) app.resource(context://api-contract/{symbol}) def api_contract(symbol: str): 返回接口签名、调用方、相关测试而不是整个文件 decl symbol_index.lookup(symbol) return json.dumps({ signature: decl.signature, callers: decl.callers[:20], related_symbols: decl.related[:10], tests: decl.test_refs[:10], }) app.resource(context://recent-errors) def recent_errors(): 返回最近失败的编译/测试错误摘要 return json.dumps(build_error_summary(limit5))注意这些接口的返回值都是摘要级别的内容。例如查接口契约返回的是签名、调用方、相关测试如果模型真需要看函数体它会再通过普通工具去读取源码。两步配合下来既保证了信息足够又不会让上下文窗口被大段源码塞满。4.4 为什么要用协议层管理而不是继续在应用层拼字符串我把Context-mode MCP和传统滑动窗口放在一起对比核心差异是上下文供给的时机和信息形态维度应用层堆料传统方式Context-mode MCP获取时机任务开始时一次性注入大量内容执行中按具体需求动态拉取信息形态原始文件、完整文本结构化摘要、语义化数据信息损耗大量无用token占据窗口信息密度高按需取用失效更新注入后就固定过期内容难感知可以按订阅/失效机制动态刷新与窗口的关系挤压ChatMemory空间主动向窗口按需投喂在实际项目中Context-mode MCP对编码代理带来的最大改变是把猜测需要什么信息变成了查询需要什么信息。传统方式下Host只能一次性把所有可能要用到的文件塞进prompt然后祈祷模型在这堆文件里抓取重点而Context-mode下Host在任务执行到特定阶段时可以主动发起查询并且拿到的还是高度加工后的答案。窗口占用率降下来后ChatMemory滑动窗口的驱逐压力大幅减小锚点保护的力度也能更集中。5. 三层上下文架构在生产项目的落地与参数调优5.1 三层架构总览把前文的讨论整合起来我在生产项目里搭的是三层上下文架构每一层管不同节奏的记忆层级载体更新频率典型内容过程层ChatMemory滑动窗口每轮对话近期对话、工具输出、临时决策长期层锚点摘要库事件触发用户约束、架构决策、偏好、接口契约项目层Context-mode MCP按需查询依赖图、接口契约快照、错误摘要这三层的配合逻辑很直接过程层负责最近发生了什么长期层负责用户到底要什么项目层负责这个项目长什么样。任何一层缺位代理都会出现各种奇怪的失忆症状。5.2 上下文路由器的实现思路三层架构不是简单地把信息全塞给模型而是需要一个路由器来动态组装每一次请求的上下文。我这里的核心逻辑是先查锚点再按需拉项目上下文最后补过程记忆class ContextRouter: def __init__(self, window, anchors, mcp_client): self.window window self.anchors anchors self.mcp mcp_client def resolve(self, task: str): parts [] # 1. 锚点用户反复强调的约束永远排在最前 for anchor in self.anchors.match(task_keywords(task)): parts.append(anchor.render()) # 2. 项目层根据任务语义订阅需要的上下文域 for domain in self.mcp.domains_for(task): parts.append(self.mcp.query(domain)) # 3. 过程层最近的对话决策与工具输出摘要 parts.append(self.window.render_recent(limit_ratio0.6)) return \n\n.join(parts)锚点匹配使用的是关键字加语义向量的双重检索确保任务进入某个阶段时能激活对应的约束MCP查询也不是每个任务都把全部上下文域拉一遍而是根据任务分类重构、修bug、新增功能选择不同的订阅集。这套路由器跑下来token消耗比最初的全量注入方案减少了大概40%同时约束违反率明显下降。5.3 几个值得记录的调优参数以下参数来自我在不同项目里的实测经验不一定普适但可以作为起点参数建议初始值调整依据ChatMemory主窗口6k-12k token超过12k后模型对中段信息的敏感度明显下降工具输出独立窗口2k-4k token只保留提取后的关键行超限必须摘要化摘要触发阈值主窗口用满80%时提前压缩避免被动驱逐造成关键信息丢失锚点数量上限20-30个超过后锚点本身会占用过多token需合并或替换上下文域订阅超时按工具调用粒度长时间任务中定期刷新依赖图等易变化数据其中摘要触发阈值是我最推荐的低成本高收益调优点。很多实现是在窗口满了之后才被迫压缩这时候驱逐已经开始发生信息已经丢了。提前在80%时主动压缩可以让摘要层从容地挑重点进行整理。5.4 上下文交付给模型时的格式约定同样的信息以不同格式呈现给模型效果差异很大。我在实践中总结了三条约定强约束用独立区块系统提示中设置契约区所有锚点约束放在这个区块里用分隔线隔开。模型对这里的内容遵循度高得多。结构化优于叙述式依赖图、接口清单等数据尽量用表格或JSON块输出而不是写成长段文字。结构化信息更容易被模型看见。排序策略要考虑首尾效应模型通常对开头和结尾的内容记忆更强因此最重要的锚点放在开头最新的过程信息放在结尾附近。中间区域放辅助性上下文即使被忽略也不致命。6. 高频坑位复盘与可观测性设计6.1 上下文重复注入会让模型选择困难三层架构引入后我一度很兴奋觉得信息越全越好。结果发现同一个约束在锚点区、摘要区和MCP返回中出现了三遍模型反而开始犹豫甚至在代码里出现自相矛盾的处理。重复注入不等于加强约束它只是在稀释注意力。我的修正方式是单源性原则每条约束只在一处保存其他位置用唯一的引用ID代替。比如锚点区出现约束后摘要区只保留该约束详见锚点#7不再复制原文。6.2 长工具输出是窗口的最大杀手编码代理特别依赖grep、find这类命令但一次搜索返回上千行结果是常事。如果不做任何加工直接丢进窗口无论你的滑动窗口设计得多好都会被瞬间打爆。我的处理方案是在工具调用和窗口之间插入一层信息提取器先让一个轻量模型把原始输出压缩成关键行列表再进入窗口。比如搜索谁调用了Utils.getId输出直接提取为调用方OrderService.java:42, PaymentService.java:117。这一层有个额外好处原始输出留在日志里需要查细节时仍然可以追溯。6.3 驱逐日志是排查所有上下文问题的黑匣子如果你在给代理添加日志时只记录最终prompt那当代理表现异常时你根本不知道哪个信息是被谁挤掉的。我强烈建议在ChatMemory里记录结构化的驱逐事件{ ts: 2025-06-12T10:23:41Z, event: eviction, trigger: window_full, dropped_record_id: msg_8821, dropped_type: tool_output, drop_reason: importance_low oldest, summary_ref: sum_452_created }有了这些日志回放代理为什么忘掉某条约束就变成了一条清晰的因果链某时刻某条记录因为什么原因被驱逐是否生成了摘要。我自己在搭建初期靠这个黑匣子发现了至少三类隐藏问题工具输出意外占用主窗口、锚点没有正确激活、摘要ID引用断裂。6.4 一点个人体会上下文管理做到最后我认为核心逻辑并不复杂编码代理最需要的不是记住一切而是在正确的时间把正确的信息以正确的形态送到模型面前。滑动窗口管的是过程的连续性锚点管的是约束的刚性MCP按需拉取管的是项目知识的可得性。这三层协同好了哪怕模型不变编码代理的整体表现都会上一个台阶。最后分享一个经验如果你正在改造自己的编码代理第一优先级永远是加可观测性——先搞清楚上下文里到底有什么再谈优化策略。我见过太多人一上来就调窗口、调摘要、调路由结果因为缺少日志连问题在哪一层都定位不到。先把驱逐日志和上下文构成统计做了你会发现自己对上下文工程的理解会清晰非常多。