1. 从“记不住”到“用不完”我为什么开始折腾上下文工程先聊个真实的场景。我最近在用 AI 编码代理Coding Agent做一个小型微服务项目代码量不大但横跨了前端、后端、部署脚本和一堆配置文件。结果不到半天就发现一个让人抓狂的问题这个 AI 助手在同一个会话里前面还在分析 API 路由后面就开始“失忆”——要么忘了之前确认过的表结构要么把已经废弃的旧函数名当成新代码引用进来。一开始我以为是模型本身不行后来看着上下文面板里的 token 上限琢磨了一会儿才意识到一个更本质的问题我喂给它的上下文根本没经过管理。上下文工程Context Engineering这个概念这两年其实已经被反复提但真正上手做的人不多。所谓上下文工程通俗点讲就是把“喂给模型的上下文”当作一种需要设计、维护、优化的资源而不是随手往里塞东西。它跟提示词工程不一样提示词工程关心的是“怎么把一句话写清楚”上下文工程关心的是“整个会话里模型能看到的全部信息——包括历史消息、工具返回、外部文档、代码片段——如何编排才能让模型始终保持最佳状态”。我这次的实战目标是给一个基于大模型 API 构建的编码代理加上一套可维护的上下文管理系统核心手段是两条线一是ChatMemory 的滑动窗口二是Context-mode MCPModel Context Protocol。这两样东西配合在一起解决了三个长期困扰我的问题上下文无限膨胀导致费用飙升、关键信息被远端历史冲淡、工具调用返回的数据格式把上下文塞满噪声。这整套折腾下来水比较深踩的坑也不少。这篇文章不打算写成文档翻译而是把我从设计思路到落地实现再到排查问题的完整过程梳理出来。适合正被“AI 编码代理记性差、上下文贵、工具结果乱”这三件事反复折磨的人参考。看完你至少能回答这三个问题上下文到底是怎么被消耗掉的滑动窗口到底怎么滑才合理MCP 的 context mode 到底能优化什么东西2. 为什么编码代理是“上下文吞噬怪”先理解钱和注意力是怎么没的2.1 一个会话到底会产生多少上下文要理解上下文工程先得知道 AI 编码代理和普通聊天机器人的区别。普通聊天机器人对话短、语义边界清晰而编码代理在背后做了大量循环操作读文件、跑测试、看报错、改代码、再验证。每一次循环都会把新的内容压入上下文。我举个自己实测的例子。用某个主流编码代理框架跑一个小任务任务是“给现有 Python 服务加一个 GET /health 接口”。整个过程中模型大概经历了这些动作1. 用户输入任务描述一条消息约 1000 token 2. 读取项目结构、相关文件内容约 30000 token 3. 生成代码修改第一次输出约 2000 token 4. 工具返回 lint 结果约 3000 token 5. 根据报错修改代码第二次输出约 3000 token 6. 再次读取被修改的文件约 8000 token 7. 最终输出验证结论约 2000 token这些累积下来单次小任务就消耗了近 5 万 token而且这里的每一步都是必需的没有哪个环节是浪费的。更可怕的是如果代理在同一个会话中连续做多个任务之前的文件内容、中间输出、工具返回会一直堆在上下文里。到后面你想让它专注处理“当前这个 bug”它眼里全是前面 10 个 bug 的相关信息——不是它不想专注是它“眼里”看见的就是所有东西。这就像一个员工被塞进一个塞满杂物的房间你要他找桌上的图纸他得先翻过三摞无关文件。不是他笨是房间没有整理。2.2 长上下文不等于好上下文很多模型厂商现在都在宣传“200K 上下文窗口”听起来很强。但实际经验告诉我长窗口解决的是“放得下”的问题不是“看得清”的问题。模型对上下文中部位置的注意力天然不如开头和结尾这在 Transformer 架构里叫“lost in the middle”。你把一个关键配置项埋在 150K token 的中间位置它“看过”和它“记住并引用”完全是两码事。另外200K 窗口的推理成本也不是线性的很多 API 是按输入 token 计费的长上下文每次调用都肉疼。更要命的是延迟输入越长首 token 返回越慢。你在编码代理场景中一轮循环往往要发起多次模型调用如果每次都要吃下 100K 的上下文整个任务的执行时间会成倍拉长。所以结论很直接上下文 optimization 的目标不是“塞满窗口”而是“让窗口里始终保持高频价值密度的信息”。这就像一个讲究的冰箱不是塞满就叫好把不常用的冷冻起来、常用的放在手边才是真正的经营之道。2.3 我定义的三个核心优化方向基于上面的问题我把编码代理的上下文管理拆成了三个方向后面的方案选择也都绕不开这三个方向容量控制把上下文总量控制在预设预算内避免无限膨胀。核心手段是滑动窗口和历史消息截断。新鲜度保护让模型永远亲近最近的事实当前代码状态、最近报错而不被几天前的旧结论干扰。核心手段是消息过期机制。结构降噪工具返回的结构化数据经过压缩/筛选后再注入上下文避免一堆 JSON 模板噪声浪费 token。核心手段是 MCP 的 context mode。这三个方向不是互相独立的往往要组合使用。这也决定了后面的架构滑动窗口管容量过期机制管新鲜度MCP 管结构。3. 核心工具拆解ChatMemory 滑动窗口与 Context-mode MCP 各解决什么问题3.1 ChatMemory 滑动窗口一种“有遗忘机制”的上下文管理器滑动窗口本身不是新鲜概念网络协议里的滑动窗口、信号处理里的滑动窗口滤波核心思想都是维护一个固定长度的动态区间新数据进入旧数据淘汰。落到 AI 编码代理的上下文管理上ChatMemory 做的就是同一件事把消息队列维护成一个固定大小的窗口超过容量后自动移出最旧消息。但我必须说真正实现好后有几个容易被忽视的细节第一窗口大小不能只看消息条数要看 token 数。有些消息很短比如“好的”有些消息很长比如某个文件的完整内容。如果按条数切一条长消息可能占掉半壁江山如果按 token 切就需要在切割时小心处理别把一条消息拦腰截断否则模型读到的是一堆不完整的内容比没有更糟。我实践中的做法是给每条消息设定一个 token 估算值然后维护一个累积和新消息插入后将尾部消息出队直到总 token 落在目标窗口的 90% 左右留出一些余量给模型输出。这个估算可以简单用len(text) / 4中文场景大致换算也可以用 tiktoken 精确计算。在编码代理里我建议做精确计算因为代码内容里特殊符号、空格多粗略估算偏差太大。第二滑动窗口不能无差别滑。有些“旧消息”是不能被滑走的比如用户在任务开始前给出的硬性约束“不要修改数据库迁移文件”“只允许使用已有依赖”“这个项目必须兼容 Python 3.9”。这些约束一旦被滑出上下文模型后续就可能犯错。ChatMemory 在这一点上的设计我是认可的它支持对消息做“固定”标记带有该标记的消息在窗口滑动时不会被淘汰而是被挤入一个永久保留区。这个功能简直是编码代理的救星。第三滑动窗口淘汰旧消息时如何保持“语义连贯”。模型突然发现上下文里少了前面一大段内容有可能会出现困惑。缓解方式是在窗口边界注入一段摘要或者“之前讨论过的结论汇总”让模型知道身边发生了什么。这种“摘要 窗口”的混合模式比纯硬切割要稳健得多。3.2 Context-mode MCP给外部数据加“闸门”MCPModel Context Protocol是一个让 AI 应用与外部工具、数据源进行标准化通信的开放协议。可以把它理解为“AI 世界的 USB 接口”——你不需要为每个数据源单独写适配器只要它们实现了 MCP serverAI 就能以统一的方式调用它们。MCP 里不同资源请求有不同用途Context-mode 是其中最贴合上下文工程的一种设计。它和普通 mode 的区别核心在于回答方式不同普通模式工具完整返回请求的所有数据原样塞入上下文。比如让你读一个 3000 行的配置文件它就真的把 3000 行全部给你。Context-mode MCP由 MCP server 侧对请求意图做出来判断返回“当前模型智能体任务最需要的那部分上下文”而不是“整个资源内容”。同时会给模型提供有关资源结构与用途的元信息方便模型按需再请求。我一开始用 MCP 的时候完全没意识到这个模式的价值默认就是普通模式。结果写了一个读取数据库 schema 的 MCP server项目里有 120 张表每张表的 DDL 都往上下文里塞两次调用下来上下文就爆了。换成 context mode 之后同样是“读取数据库 schema”的请求MCP server 返回的是数据库共有 120 张表与当前任务相关的核心表users、orders、order_items。 users: 主键 id关键字段 email、status。 orders: 主键 id外键 user_id关键字段 amount、status、created_at。 如需查看某张表的完整 DDL可使用 schema.detail(tablexxx) 方法。这下模型既能知道全局面貌又不会陷入所有表的细节里。需要某张表细节时它再发起一次精准请求。这就是 context-mode 的本质上下文按需供给而非全量供给。3.3 两者结合一个“窗口控制 内容筛选”的双层流水线在真实编码代理里ChatMemory 滑动窗口和 Context-mode MCP 不是替代关系而是叠加关系。我最后搭的架构可以概括成这样一个双层流水线外部工具/数据源 - MCP context mode第一层筛选压缩噪声 | v 模型消息历史 - ChatMemory 滑动窗口第二层控制总量裁剪 | v 组装 Final Prompt - 送入 LLM第一层负责“什么内容值得进上下文”第二层负责“上下文装得下多少内容”。两层各管一件事叠加之后的效果比我之前任何单层优化都要明显。我会在第 5 节详细展示配置和代码这里先不做展开。4. 设计一个编码代理的上下文管理系统参数、策略与代价权衡4.1 定窗口大小之前先算清 Token 预算很多人的第一反应是“窗口越大越好”但经验告诉我滑动窗口大小不是拍脑袋定的而是跟着预算和任务模型走的。我给自己定了一个流程第一步明确模型上下文上限。比如用的是 128K 上下文的模型。第二步预留输出空间。一般保留 20% 给当前轮次的模型输出生成代码、生成解释等。这样可用输入空间就是大概 100K。第三步根据任务类型确定窗口目标。编码代理场景里我认为 30K 到 60K 是一个比较合理的“高质量工作集”。太少了装不下代码和工具结果太多了会引发前述 attention 衰减问题。我做过的测试里将窗口设为 40K token 的效果比较均衡既能容纳一轮完整迭代所需的文件内容、工具输出又不至于让陈旧信息长期堆积。这只是我的经验值不同框架和模型可能不同建议你从 30K 起步逐步观察模型行为变化。4.2 滑窗淘汰策略不只是 FIFO简单 FIFO先进先出策略虽然能用但在编码场景里很容易把关键信息误杀。我最终采用的策略包含两层一层是按优先级区分消息。我给消息定义三档优先级优先级适用范围窗口滑动时的处理高用户硬性约束、当前任务的最终目标永不剔除即使超出窗口预算中当前文件内容、最近的工具返回正常参与滑窗淘汰但保底保留最近 N 条低早期阶段的分析、过时尝试优先被淘汰必要时直接忽略另一层是保底保留条数。即使窗口已经超出预算我也会保留中优先级里最近若干条消息因为编码代理的循环迭代非常依赖最近的报错信息一旦丢掉最新报错模型就可能在盲改。实际测试下来高优先级消息占比一般控制在 5% 以内如果超过这个数说明用户任务里塞了过多“不可丢弃”的内容这时候我会提示用户将硬性约束精简而不是放任它挤占窗口。4.3 ChatMemory 核心参数配置参考由于 ChatMemory 的具体实现可能因框架而异我这里给出一份基于常见实践的配置参考带有完整的“为什么”解释方便你迁移到自己的框架中chat_memory_config { max_tokens: 40_000, # 窗口总 token 预算 reserve_ratio: 0.15, # 保留给模型输出的比例约 15% hard_fixed_ids: [goal], # 永不淘汰的消息分组 summary_every: 10_000, # 每累积 10K token 就生成一次小结 summarizer_model: fast, # 使用轻量模型生成摘要省成本 recent_keep: 6, # 无论窗口如何保留最近 6 条消息 }这里的summary_every是我自己加的机制当一个低优先级消息即将被淘汰前把它的核心结论抽取成一句话合并到全局摘要中。这样虽然具体的文件内容被滑走了但“这个文件里有什么结论”的大意还在。模型后面需要细节时可以再通过 MCP 去请求原数据。4.4 Context-mode MCP server 设计如何决定返回什么内容设计一个 context-mode MCP server核心是要回答清楚一个问题“模型当前真正需要什么粒度的信息”这个判断做不好context-mode 就会变成一个语义模糊的裁剪器。我的经验是把 MCP server 的每个资源请求都拆成三个层级server 根据请求参数自动选择返回粒度概要层资源存在哪些模块、关键文件清单、表结构总览。适合模型做规划。结构层目标文件的关键类/函数定义、类型签名、核心逻辑的注释。适合模型做局部修改。全量层完整内容。只有模型明确请求时才返回并压缩成高密度形式。以文件读取为例普通的 MCP server 收到read_file请求后返回整个文件内容。context-mode server 则可以根据参数自动返回{ mode: structure, target: src/services/order_service.py, summary: 订单服务的核心模块负责订单创建与状态流转, structure: [ class OrderService:, create_order(user_id, items) - Order, cancel_order(order_id) - bool, get_order_detail(order_id) - dict ], size: 共 640 行如需读取完整实现请调用 read_file_full }看到没有模型拿到的是一个“地图”而不是一篇长文。它能知道文件里有什么、去哪里找什么但不会被 640 行代码淹没。需要细节时再按图索骥。4.5 成本与收益优化前后我实测的对比数据为了验证这套方案的价值我在一个约有 2 万行代码的中型项目中跑了一组对比测速。任务内容是“修改订单模块增加优惠券字段并覆盖测试”。每组任务各跑 5 次取平均结果如下指标未使用上下文工程原配置使用 ChatMemory Context-mode MCP单任务总 token 消耗约 420K约 180K有效工作耗时约 8 分钟约 5 分钟首次修改正确率60%85%最大上下文尖峰约 110K约 46K上下文超限中断次数2 次0 次最直观的感受是 token 消耗降了接近 60%而且模型的修改正确率提升非常明显。原因也简单语境中“噪音”少了模型注意力更集中。上下文工程不是省了钱就亏了质量恰恰相反它是省钱、提速、涨质量的三赢。5. 实操从 0 到 1 搭建一个带上下文优化的编码代理5.1 整体架构与代码落地我采用的方案是基于 Python 实现的依赖一个假设的coding_agent_core库配合 MCP SDK。整体流程如下用户输入 - CodingAgentSession - ChatMemory滑动窗口管理历史消息 - MCPClient连接 Context-mode MCP Server - PromptAssembler组装最终请求 - LLM API下面展示一个简化版但可以跑通的核心代码方便理解整个框架的关系。5.2 ChatMemory 滑动窗口骨架代码与配置class ChatMemory: def __init__(self, max_tokens40_000, reserve_ratio0.15): self.max_tokens max_tokens self.reserve_tokens int(max_tokens * reserve_ratio) self.hard_fixed_ids set() self.messages [] # 每条消息: {id, priority, content, tokens} self.summary # 全局摘要 self.recent_keep 6 def add_message(self, msg): token_count estimate_tokens(msg[content]) msg[tokens] token_count self.messages.append(msg) self._slide_window() def _slide_window(self): # 一直压缩到“总 token - 保留区”以内 while self._total_tokens() self.max_tokens - self.reserve_tokens: # 找到第一个可以被滑走的低/中优先级消息 evict_idx None for i, m in enumerate(self.messages): if m[id] in self.hard_fixed_ids: continue # 高优先级永不淘汰 if m[priority] low: evict_idx i break if evict_idx is None: # 全部都是不可淘汰那就先压缩摘要保留最近几条 self.summary self._update_summary() break evicted self.messages.pop(evict_idx) self._absorb_into_summary(evicted) # 将大意并入摘要这段代码里最关键的是_absorb_into_summary需要在踢出消息之前把它的“有价值结论”捕捉进摘要里。我在实际实现中是把原始消息发给一个轻量模型让它用 50 字总结出“关键事实”再追加到全局摘要后。成本很低效果却非常好。5.3 Context-mode MCP Server从一个“读数据库 schema”的实例说起我用 FastMCP 框架实现了一个 schema 查询 server核心是资源注册和 context mode 判断。代码逻辑大致如下ctx_server.resource(schema://overview) def get_schema_overview(params): # context mode 核心根据 params 决定返回哪个层级的粒度 request_mode params.get(context_mode, overview) if request_mode overview: tables db.list_tables() return { mode: overview, table_count: len(tables), tables: tables[:80], # 只给清单不全量 DDL } elif request_mode structure: table params[table] cols db.get_columns(table) return { mode: structure, table: table, columns: cols, # 只给字段名与类型 } elif request_mode full_ddl: return db.get_ddl(params[table]) # 只有明确请求才完整返回这个 server 的元信息设计很重要。每个返回值都带mode字段模型看到这个字段就知道当前拿到的信息层级需要更多细节时它可以按资源地址发第二次请求。实际测试中模型会自己学会这套交互模式很少出 bug。5.4 组装最终 Prompt把滑动窗口和 MCP 输出拼进一个请求最后把前面两个模块的输出合并到最终 prompt 中。我的组装逻辑是def assemble_prompt(user_query, memory: ChatMemory, mcp_client: MCPClient): # 1. 从 MCP 获取与当前任务最相关的外部上下文 external_ctx mcp_client.fetch_context( queryuser_query, context_modeauto, # auto 由 server 自动判断层级 ) # 2. 从 ChatMemory 取出当前窗口内的消息列表 history_messages memory.get_visible_messages() # 3. 拼接系统提示 - 外部摘要 - 历史 - 用户新指令 system_prompt ( 你是一个编码代理助手。请使用以下外部上下文与历史消息 完成用户的编码任务。若需要更多详细信息可以主动调用工具获取。 f\n\n[全局摘要] {memory.get_summary()} f\n\n[外部上下文] {external_ctx} ) return [{role: system, content: system_prompt}] history_messages [ {role: user, content: user_query} ]注意外部上下文被放在历史消息之前、系统提示之后这样模型在阅读后续消息时已经有了地图感不会迷失。5.5 执行一个真实任务从“读代码”到“改代码”的全程记录为了展示这套系统如何生效我跑了一个具体的任务“在这个仓库中定位订单金额计算的位置并修复负数金额被接受的问题。”实际操作流程如下第一步模型先向 MCP server 请求仓库结构概览。MCP 返回概要层仓库拥有 12 个模块订单相关的核心文件是src/order.py、src/payment.py、src/price.py。此时上下文消耗极少。第二步模型读取src/price.py的结构层快速获得了类层次与关键函数签名。它发现金额计算入口是PriceCalculator.calculate(price, quantity)。第三步模型请求完整读取calculate方法的具体实现。此时 MCP 返回全量层模型看到了负数校验缺失的问题所在。整轮下来上下文消耗大约 8K token而如果直接让模型每步都读全量文件很容易突破 30K。模型在输出修改意见时引用的代码行都是真实存在的说明它“看到的”信息足够精确。6. 实战中我踩过的坑ChatMemory 与 MCP 的黄金避坑手册6.1 滑窗乱滑导致“人格分裂”最开始我的滑动窗口只是单纯的 FIFO 按条数切。结果有一次任务里用户在前面给出“不要使用 ORM请直接编写 SQL”的硬性约束跑了几轮后这条约束被滑出窗口模型后面竟然给出一段 ORM 代码还浑然不觉。从那以后我把“硬性约束”全部标记为高优先级永不淘汰。这个踩坑经历也验证了我在 4.2 中说过的优先级分层。6.2 滑窗的“消息污染”链还有一个问题是滚动窗口会把工具返回的中间消息当成历史消息导致上下文里累积了一堆“文件读取结果”。我发现 ChatMemory 有一个隐藏问题每次模型调用工具读取文件后工具返回内容都会作为用户消息加入历史滑动窗口需要区分这些“工具消息”和正常用户消息。如果它只看消息角色就会乱套必须为消息打上类型标签比如user_query、tool_call、tool_result、assistant_code。不同类型在窗口滑动时的保留策略也不一样tool_result是最需要被快速淘汰的因为它体积通常巨大而且往往只在下一轮有用。6.3 MCP 返回 JSON 被当成代码误报Context-mode MCP 返回的 JSON 结构本身有时会被模型误认为“JSON 配置文件”并尝试修复。解决方案是在返回的元信息里加上显式的类型声明比如data_type: context_summary让模型不对其做语法修复也不用它去做代码补全。6.4 摘要模型不可靠时的兜底方案实际使用中我发现summary_every机制依赖轻量模型的摘要能力但如果摘要模型质量不够摘要可能丢关键信息。兜底做法是对于被淘汰的低优先级消息不直接依赖摘要而是保留一个“消息指纹”——比如文件名、行号、任务的最近状态。这些结构化信息比自然语言摘要更可靠丢失概率更低。6.5 回调循环问题最后一个坑是代理本身带来的模型在调用 MCP 工具时上下文管理同样会触发新的消息传递。如果 ChatMemory 的滑窗是在模型请求结束时触发而不是在每次工具返回时触发就可能在下一次工具调用时发现上下文已经超限进而报错。建议把滑窗压缩放在“任何消息进入之前”这样可以保证每一次模型调用前上下文都是正常状态。7. 我的一些额外心得上下文工程是一门“经营”手艺做完这套系统之后我最大的感悟是上下文工程不是某个具体算法而是一套价值观——你希望模型把注意力花在哪里你就应该在管理上下文中体现这种偏好。ChatMemory 的滑动窗口本质上是在回答一个问题“历史记忆中哪些记忆值得留着”。Context-mode MCP 则是回答另一个问题“外部信息中哪些信息该被拿出来”。两者凑在一起才是完整的上下文生命周期管理信息的进入、驻留、淘汰全部有章法。根据我个人的使用经验我通常在以下几个场景中最感受到这套系统的价值第一个是大型仓库下的跨模块重构。没有上下文优化时模型经常在修改 A 模块时引用已过时的 B 模块信息。有了滑窗 MCP 概要层之后模型的视野被精确控制在一个“因果范围”内不会东看西看。第二个是长时间后台自动执行。编码代理经常要跑很长时间如果任务执行到第 20 步上下文已经变成一团乱麻模型基本就开始原地打转了。而滑窗机制保证每步的上下文状态都是干净的每一步都能扎实往前走。第三个是成本敏感型应用。个人开发者做起 AI 编码代理实验来token 费用是实打实的开销。66% 的 token 下降对我来说意味着每个月能省下不少预算可以用在更值得的地方。最后再分享一个细节上的小技巧我习惯在窗口里放一个“可导航的文件索引”消息里面存着当前仓库的文件树和每个文件的摘要每条摘要不超过 30 个中文字符。这个索引消息体积小、信息密度高却能让模型在不需要频繁调用工具的情况下快速决定下一步操作。这个小设计让整个代理的行为变得更“聪明”推荐你试试。