上下文工程实战从 ChatMemory 滑动窗口到 Context-mode MCP 上下文优化前阵子我接手了一个 AI 编码代理AI coding agent的维护工作遇到一个非常典型的头疼问题单文件改动、单函数重构时它表现很好但只要进入跨文件的大型重构它就像金鱼一样只有七秒记忆——前面刚确认过的接口定义后面就凭记忆脑补一个错误的版本导致连续报错、反复返工。排查之后发现问题根本不出在模型能力而在于上下文工程我们给代理喂的上下文既不完整、又充满噪声模型再好也白搭。这篇文章想把我在这个方向上从ChatMemory 滑动窗口一路演进到Context-mode MCP 上下文优化的实战过程完整拆给你包括原理、参数调优、踩坑记录和可复现的配置方案。如果你也在做 AI 编码代理、RAG 聊天机器人、或者任何依赖长对话历史的 LLM 应用这篇文章应该能帮你少走不少弯路。我会尽量用大白话把关键机制讲透不会只甩一堆名词。1. 先搞清楚我们的 AI 编码代理为什么总在失忆在动手改方案之前我花了不少时间做了一件事把上下文这两个字拆开看清楚它在 AI 编码代理里到底扮演什么角色。很多团队的误区是把上下文当成聊天记录来看待——模型记得刚才说过的话就算有上下文。但在编码代理这个场景里上下文远不止对话历史这么简单。1.1 编码代理的上下文不是聊天记录而是工作台想象一下你带了一个新实习生你给他派活之前会把项目背景、相关代码路径、要改的接口文档、之前讨论过的约束条件全部摊在他面前的桌子上。他干活的时候并不是背下你所有话而是随时能在桌上找到对应的资料。AI 编码代理需要的也是这个桌子——它得同时保持以下几类信息会话历史用户和代理之间的实时对话包括需求描述、修改意见、确认过的方案。项目快照当前工作目录的文件树、关键源码片段、配置文件内容。工具调用轨迹代理执行过哪些 shell 命令、读取过哪些文件、修改过哪些内容。长期规范项目风格指南、测试约定、依赖版本约束等。这里最容易被忽略的是工具调用轨迹。我见过不少团队的上下文系统把对话记录记得清清楚楚但代理中间执行过什么命令、看到了什么报错、怎么确认问题根因的全被丢掉了。结果模型只知道用户说要修登录接口却不知道代理已经跑过一遍测试发现是 Redis 连接池配置错了。这就像给实习生一份任务清单却收走了他的工作日志等于让他重复劳动。1.2 上下文预算模型有一个物理上限但实际问题远超上限第二个要认清的现实是当前主流大模型的上下文窗口虽然标注得很唬人——128K、200K、甚至有 1M 的——但真的塞满之后模型的注意力质量会显著下降。这不是玄学Transformer 架构的自注意力机制是平方级复杂度窗口越长模型对远端信息的回忆越模糊。我在实际压测里观察到当上下文占用率超过 70% 之后代理对早期指令的遵循度开始下降到 90% 以上它甚至会遗漏关键约束这时候你只能看到它一本正经地做错事。所以上下文工程面临一个非常现实的矛盾真实项目的上下文体积代码库全文 历史记录 工具轨迹往往远超模型的物理窗口。你不能把所有东西都塞进去必须做选择。怎么选这就是上下文工程的核心命题。1.3 上下文工程的基本策略全部保留、滑动窗口、还是按需取用理论上存在三种策略正好对应了三代方案全量保留把整个项目历史、所有会话都塞进窗口。只对小项目可行稍微大一点就爆窗。滑动窗口ChatMemory只保留最近 N 条消息或最近 M 个 token旧的直接丢弃。实现简单是绝大多数 AI 编码工具的默认方案。按需取用Context-mode MCP不按时间远近决定保留什么而是按当前任务需要什么来决定。需要历史摘要就调摘要需要某个文件内容就临时检索全部通过标准化的上下文服务动态注入。我们团队最初用的是第 2 种也就是 ChatMemory 式滑动窗口。这一代方案本身不算错但它有明显的天花板。搞清楚它的原理和边界你才能真正理解为什么最终要走向 MCP 那一套。2. ChatMemory 滑动窗口第一代上下文管理的原理与调参关于滑动窗口最经典的解释来自信号处理和网络协议——你在热词里看到的滑动窗口重传协议滑动窗口滤波都是同一个思想的不同应用用一个固定大小的窗口随时间推移不断丢弃旧数据、纳入新数据让系统始终只关注最近一段区间内的信息。LLM 上下文管理里的 ChatMemory 滑动窗口本质是把这个思想移植到 token 序列管理上。2.1 滑动窗口的两种实现口径按条数截断与按 token 截断我在实现第一版时踩过一个大坑以为窗口就是最近的 N 条消息后来才发现编码代理的消息并不都是同一量级的。用户可能只发一句改一下登录接口但代理回复里夹着整段 diff 和报错日志一条消息可能顶用户一百条。按条数截断会导致 token 使用量剧烈波动窗口看起来没爆实际早已超限。更稳妥的做法是双阈值控制同时设置最大消息条数和最大 token 数无论哪个先达到都触发淘汰策略。用 Python 实现一个简易版本的话大概是这样的逻辑from collections import deque from typing import List class ChatMemoryWindow: def __init__(self, max_messages: int 50, max_tokens: int 12000): self.messages deque(maxlenmax_messages) self.max_messages max_messages self.max_tokens max_tokens def add(self, message: dict, estimate_tokens_func): # message: {role: ..., content: ...} self.messages.append(message) # 如果超出 token 阈值从头丢弃直到满足 self._trim_by_tokens(estimate_tokens_func) def _trim_by_tokens(self, estimate_tokens_func): total sum(estimate_tokens_func(m[content]) for m in self.messages) while total self.max_tokens and self.messages: dropped self.messages.popleft() total - estimate_tokens_func(dropped[content])deque(maxlen...)负责保证消息条数不超过阈值_trim_by_tokens负责保证 token 总量不超限。两条规则叠加窗口才能真正稳定。这里有个细节我后来反复提醒同事estimate_tokens_func必须和模型实际分词器一致用len(content.split())估算英文问题不大但代码场景里大量符号挤在一起空格分词会严重低估 token 数。我当时踩的坑就是没接真实 tokenizer导致窗口实际塞了 1.3 倍的 token 才触发截断模型直接报上下文超限。2.2 窗口大小的取值策略没有最优只有最不坏窗口设多大合适是团队里争论最多的问题。设大了上下文足但噪声多、成本高设小了省 token 但代理容易丢关键信息。我后来总结出一个经验公式思路窗口大小 ≈ 单轮工具调用循环的平均 token 数 × 代理需要保持的工作记忆轮数。举个例子我们的代理每完成一次读文件 → 改代码 → 跑测试循环大约消耗 1200 token。如果希望它至少记住最近 5 轮循环的决策上下文那就是 6000 token。再留一些缓冲给新消息我实际把窗口初始值定在 8000 token。这个数字不是拍脑袋而是先观察代理任务的 token 分布再倒推出来的。下面是我压测时记录的一组不同窗口大小下代理完成购物车模块重构的表现任务包含 4 个文件的联动修改窗口 token 上限任务完成率平均返工轮数单任务 token 开销400041%3.218.6K800067%1.822.1K1200072%1.624.8K1600069%2.129.4K数据很有意思的是窗口不是越大越好12000 到 16000 之间出现回落因为窗口大了以后早期被保留的过时信息——比如某个文件的老版本内容——反而干扰了代理对新版本的判断。这说明滑动窗口有一个内在悖论窗口太小丢东西窗口太大塞旧东西而旧东西和过时的东西在时间维度上是绑定的。2.3 滑动窗口在不同场景下的表现差异滑动窗口还有一个不容易发现的特性它对连续性任务和离散查询任务的表现差异非常大。连续调试类任务改 A 看 B、再改 B 看 C时间局部性强最近的上下文就是最有用的滑动窗口效果尚可但一旦调试链路过长超过 10 轮早期结论丢失后代理开始发明根因。多文件重构类任务跨 5 个文件的接口调整每轮循环要参考不同文件时间顺序不等于依赖顺序滑动窗口几乎必然丢失前置信息。它的表现比连续调试差得多。需求澄清类任务用户一段长需求 多次补充描述用户说过的约束如果恰好落在窗口外代理会用默认假设去做事产生隐蔽但严重的偏差。到这一步我基本确认了滑动窗口的边界它适合作为短期记忆存在但不适合承载工作记忆的全部职责。真正要做上下文优化得换一种思路——不是尽量保留最近的而是动态提供当前最需要的。3. 滑动窗口不够用了Context-mode MCP 如何按需供给上下文从滑动窗口走向 MCP不是推翻前面的设计而是把上下文管理的重心从缓存转移到调度。3.1 MCP 到底是什么为什么选它做上下文工程如果你还不太熟悉 MCPModel Context Protocol可以把它理解成模型和外部工具/数据源之间的一个标准 USB 接口。过去接入一个文件检索工具、一个数据库查询服务、一个文档摘要器每个都要写一套专用协议有了 MCP所有工具都以统一的工具/资源/能力形式暴露给模型模型按标准格式发起请求服务端按标准格式返回结果。在上下文工程这个场景里MCP 的意义是它把上下文获取从模型内部的隐式记忆变成了模型可以主动调用的显式服务。代理不依赖模型记住了什么而是知道自己可以去哪里查。这就是 Context-mode 的核心思路——平时不把所有东西塞进窗口而是在需要的时候通过 MCP 工具临时加载最相关的那一部分上下文。3.2 Context-mode 的三种上下文供给手段我落地 Context-mode MCP 时主要实现了三种上下文供给能力对应三种不同的取用需求。第一种语义检索式注入。当代理接手一个任务先通过 MCP 的search_codebase(query, top_k)工具把与任务关键词相关的代码片段检索回来。这一步相当于给代理一个项目地图告诉它去哪个文件、看哪个函数。实现上我起初用纯关键词匹配召回质量很差后来换成了 embedding 相似度检索效果有明显提升代价是多了向量化服务的依赖。对代码场景我更推荐关键词候选 embedding 重排的混合策略兼顾速度和准确。第二种结构化摘要兜底。滑动窗口的问题在于时间近的必然保留而有些需求是长线依赖——比如用户在第 3 轮提过一个全局约束第 30 轮才要求落地它。Context-mode 的做法是当窗口发现某段早期上下文即将被淘汰时不直接丢弃而是调用 MCP 的summarize_topic(topic)工具把相关内容压缩成结构化摘要存进一个长期备忘录。代理需要时通过recall_summary(topic)拉取。这相当于给代理配了一个自动记笔记的助手而不是只靠短时记忆。第三种工具痕迹回放。编码代理干活必定会产生 shell 命令、diff 补丁、测试输出。这些内容体量大、且多半是一次性的不需要长期保存但排查问题时又必不可少。我的做法是把完整工具轨迹写入持久化存储只在代理进入报错排查状态时才通过 MCP 回放最近 N 条工具调用轨迹。这样既不长期占用窗口又能按需恢复调查线索。3.3 Context-mode MCP 的架构要点谁来决定要什么上下文围绕 MCP 做上下文供给有一个设计问题非常关键决定当前需要什么上下文的是模型自己还是外部调度器我一开始把决定权完全交给模型让它自己按需调用 MCP 工具。结果模型经常忘调或者调太多。焦点跑偏的时候它会疯狂调一堆和当前任务无关的检索把窗口迅速撑爆。后来我调整为**规则预判 模型补调双通道**规则预判层在请求进入模型之前外部调度器根据当前任务类型code_edit / debug / test / grep预置一批最可能需要的上下文。比如任务类型是 debug就自动附带最近的测试输出和报错堆栈摘要任务类型是 code_edit就附带目标文件的函数签名和调用方列表。模型补调层模型在推理过程中如果发现自己还缺某个具体信息通过 MCP 工具自行补调。这一步保留了模型的主动性但不把全部信任押在模型的自觉上。我这里直接用 Agent SDK 的方式描述这个双通道流程方便理解整个调用链# 伪代码Context-mode MCP 调用的调度逻辑 async def build_context(request: TaskRequest) - List[ContextBlock]: blocks [] # 通道1规则预判 for rule in RULE_MAP.get(request.task_type, []): content await mcp_call(rule.tool, rule.args(request)) blocks.append(content) # 通道2模型补调 if request.model_need_context: extra await mcp_call(resolve_context, {prompt: request.prompt}) blocks.append(extra) # 最后做一次总控保证不超窗口 return trim_to_budget(blocks)这套架构跑起来之后最直接的感受是代理不再背着一整个项目在跑而是随时知道去哪里拿自己需要的东西。窗口占用从经常逼到 90% 以上稳定回落到 50% 左右。4. 实战落地从滑动窗口逐步迁移到混合上下文方案的完整记录理论讲得再好迁移过程中该踩的坑一个都不会少。这一节我完整记录一次从纯 ChatMemory 滑动窗口迁移到滑动窗口 Context-mode MCP 混合方案的真实过程包括配置对比和三个典型坑。4.1 基线环境与迁移步骤先说基线环境方便你做横向比较模型选用了一支支持 128K 上下文窗口、工具调用能力较好的通用大模型接口按 OpenAI 格式适配。代理框架自研轻量编码代理任务类型包含代码生成、单测调试、跨文件重构。原有上下文模块ChatMemory 滑动窗口窗口上限 12000 token消息条数上限 200 条。观察指标任务完成率、平均返工轮数、上下文占用率、单任务 token 开销。迁移不是一步到位的我踩到前面说的16K 窗口反而效果回落的坑之后意识到问题的关键不在窗口大小而在于保留策略太粗糙。之后我按以下步骤推进迁移保留滑动窗口作为短期记忆层窗口继续存在但缩小到 8000 token专职保留最近几轮的工具轨迹和未结对话。新增 MCP 上下文服务先接入search_codebase和summarize_topic两个工具跑通外部取上下文链路。把淘汰内容路由到摘要服务修改滑动窗口的淘汰逻辑——被挤出窗口的内容不再直接删除而是交给摘要工具压缩存储。加入规则预判层根据任务类型预注入基础上下文降低模型对窗口的依赖。压测对比与回滚验证每一小步都跑基准任务集确保没有劣化再进入下一步。4.2 迁移前后的关键对比数据迁移完成并稳定运行两周后我重新跑了一遍和 2.2 节同一组购物车模块重构任务数据对比如下指标纯滑动窗口12000 token混合方案窗口 MCP任务完成率72%86%平均返工轮数1.60.9上下文平均占用率63%47%单任务 token 开销24.8K19.3K跨文件联动修改的回归率68%82%最意外的是** token 开销反而下降了**。迁移前我以为引入 MCP 会增加额外请求成本数据却显示单任务总 token 开销降了约 22%。原因很容易理解过去窗口里塞着大量过时或无关的旧上下文白白消耗 token 还干扰判断现在按需注入之后去掉了这部分浪费模型出错少了返工 token 也相应减少。上下文工程的收益不只是让模型更准还是让模型更省。4.3 迁移路上的三个典型坑讲完成功数据必须把失败经验也摆上来。第一个坑摘要丢失了关键数字和约束。我最初设计的摘要策略是把窗口淘汰内容合并压缩成一段自然语言摘要。结果代理在后期执行细节时经常丢失具体数字比如超时时间 30 秒被写成超时时间要长一点。后来我强制规定摘要里必须保留三类信息数值型参数、精确标识符文件名、函数名、变量名、用户明确说过的否定式约束不要做 X。摘要模板改为结构化字段不是自由文本。第二个坑规则预判层注入过量上下文。预判逻辑写得太慷慨的话会在每个任务开头灌入一大包代码片段虽然没有超过窗口上限但模型在前期明显注意力发散经常跑偏到预判提供的但和当前子任务无关的文件上。修复方式预判注入的不是完整代码片段而是文件路径 关键符号 一句话说明真正需要细节时让模型再通过 MCP 工具拉取。代理学会查资料而不是背资料之后表现稳定了很多。第三个坑MCP 检索的召回噪声污染上下文。search_codebase返回的 top_k 代码片段存在大量近似匹配但不相关的噪音。举个例子搜update_stock会返回所有带 update 字样的函数距离真正目标十万八千里。应对办法有两个层面一个是检索侧加上重排序过滤器按调用关系而不是单纯 embedding 相似度排序另一个是 prompt 侧明确要求模型把检索结果当作候选线索而不是既定事实调用前先用可靠方式验证。这两个手段叠加后噪声影响基本可控。5. 上下文工程的进一步优化监控、调试与后续演进方向混合方案稳定跑起来之后我并没有就此停手。上下文体系和业务代码一样需要持续维护否则会悄悄劣化。最后一个部分分享我在这个过程中总结的监控手段和演进方向以及一些个人的建议。5.1 给上下文系统装上仪表盘很多团队对模型的应用指标只盯着响应延迟和成功率却不看上下文本身的质量。我做了一套非常轻量的上下文监控方案核心是给每次请求记录几组关键字段跑批分析按类型统计上下文占比对话历史、工具轨迹、代码片段、摘要文本各自在总 token 中占多少。如果代码片段占比长期偏低说明检索链路没有发挥价值。被截断淘汰的信息是否被重新请求如果某条信息被窗口淘汰后代理又通过 MCP 或用户重复请求了同样的内容说明保留策略存在漏洞。任务类型的上下文使用画像debug 任务和 code review 任务的上下文构成应当不同通过画像可以反推预判规则是否合理。拿到这些数据之后调参就不再靠感觉了。比如我发现重构类任务的代码片段检索量明显偏低就加强了规则预判层在重构场景下的文件预注入而不是笼统地加大窗口。5.2 更深一层的上下文优化思路分层记忆与任务画像沿着混合方案往前走我规划了三个进一步优化的方向。第一个方向是分层记忆架构短期窗口秒级、工作记忆任务级MCP 强相关、长期记忆项目级结构化摘要与知识库。每一层有独立的读写机制和淘汰策略层与层之间通过上下文化回调关联。这个架构对大型项目万级以上文件几乎是必须的。第二个方向是任务画像驱动的动态预算分配在请求进入模型之前用一个小模型对任务打标签生成、调试、重构、审查然后根据标签给出上下文预算配比——比如 debug 任务的工具轨迹预算占 40%重构任务的代码片段预算占 50%。这比统一模板更精准也是我正在重点推进的方向。第三个方向是上下文溯源与回放记录每次注入上下文块的来源标识来自哪个文件、哪个摘要条目、哪轮会话当模型输出出现偏差时能快速定位是哪块上下文误导了它。这本质上是给上下文做版本管理对调试复杂问题非常有用。5.3 一些个人建议做了这么多实战探索如果让我用一句话总结上下文工程的核心心法那就是模型的记忆不可靠别让它背让它查。滑动窗口适合做短期记忆的缓冲但真正支撑长任务、复杂项目的一定是一套显式的、按需驱动的上下文服务体系。MCP 的价值恰恰在于给这套体系提供了一个标准化的交互界面让查这件事变得非常自然。如果你正在从零搭建类似的系统我的建议是先别急着上复杂架构。第一步梳理清楚你的代理任务里上下文依赖的图景是什么——是强时序依赖还是强检索依赖根据任务特点选择主策略第二步在现有架构上叠加可观测性把上下文构成和模型行为关联起来第三步再逐步引入 MCP 服务用数据验证每一步的收益。如果你已经跑在纯滑动窗口方案上不妨试试把淘汰策略改成全量丢弃变摘要按需重取这一小步改动通常能在不大改架构的情况下带来可感知的提升。 上下文工程实战：从ChatMemory滑动窗口到Context-mode MCP上下文优化
上下文工程实战从 ChatMemory 滑动窗口到 Context-mode MCP 上下文优化前阵子我接手了一个 AI 编码代理AI coding agent的维护工作遇到一个非常典型的头疼问题单文件改动、单函数重构时它表现很好但只要进入跨文件的大型重构它就像金鱼一样只有七秒记忆——前面刚确认过的接口定义后面就凭记忆脑补一个错误的版本导致连续报错、反复返工。排查之后发现问题根本不出在模型能力而在于上下文工程我们给代理喂的上下文既不完整、又充满噪声模型再好也白搭。这篇文章想把我在这个方向上从ChatMemory 滑动窗口一路演进到Context-mode MCP 上下文优化的实战过程完整拆给你包括原理、参数调优、踩坑记录和可复现的配置方案。如果你也在做 AI 编码代理、RAG 聊天机器人、或者任何依赖长对话历史的 LLM 应用这篇文章应该能帮你少走不少弯路。我会尽量用大白话把关键机制讲透不会只甩一堆名词。1. 先搞清楚我们的 AI 编码代理为什么总在失忆在动手改方案之前我花了不少时间做了一件事把上下文这两个字拆开看清楚它在 AI 编码代理里到底扮演什么角色。很多团队的误区是把上下文当成聊天记录来看待——模型记得刚才说过的话就算有上下文。但在编码代理这个场景里上下文远不止对话历史这么简单。1.1 编码代理的上下文不是聊天记录而是工作台想象一下你带了一个新实习生你给他派活之前会把项目背景、相关代码路径、要改的接口文档、之前讨论过的约束条件全部摊在他面前的桌子上。他干活的时候并不是背下你所有话而是随时能在桌上找到对应的资料。AI 编码代理需要的也是这个桌子——它得同时保持以下几类信息会话历史用户和代理之间的实时对话包括需求描述、修改意见、确认过的方案。项目快照当前工作目录的文件树、关键源码片段、配置文件内容。工具调用轨迹代理执行过哪些 shell 命令、读取过哪些文件、修改过哪些内容。长期规范项目风格指南、测试约定、依赖版本约束等。这里最容易被忽略的是工具调用轨迹。我见过不少团队的上下文系统把对话记录记得清清楚楚但代理中间执行过什么命令、看到了什么报错、怎么确认问题根因的全被丢掉了。结果模型只知道用户说要修登录接口却不知道代理已经跑过一遍测试发现是 Redis 连接池配置错了。这就像给实习生一份任务清单却收走了他的工作日志等于让他重复劳动。1.2 上下文预算模型有一个物理上限但实际问题远超上限第二个要认清的现实是当前主流大模型的上下文窗口虽然标注得很唬人——128K、200K、甚至有 1M 的——但真的塞满之后模型的注意力质量会显著下降。这不是玄学Transformer 架构的自注意力机制是平方级复杂度窗口越长模型对远端信息的回忆越模糊。我在实际压测里观察到当上下文占用率超过 70% 之后代理对早期指令的遵循度开始下降到 90% 以上它甚至会遗漏关键约束这时候你只能看到它一本正经地做错事。所以上下文工程面临一个非常现实的矛盾真实项目的上下文体积代码库全文 历史记录 工具轨迹往往远超模型的物理窗口。你不能把所有东西都塞进去必须做选择。怎么选这就是上下文工程的核心命题。1.3 上下文工程的基本策略全部保留、滑动窗口、还是按需取用理论上存在三种策略正好对应了三代方案全量保留把整个项目历史、所有会话都塞进窗口。只对小项目可行稍微大一点就爆窗。滑动窗口ChatMemory只保留最近 N 条消息或最近 M 个 token旧的直接丢弃。实现简单是绝大多数 AI 编码工具的默认方案。按需取用Context-mode MCP不按时间远近决定保留什么而是按当前任务需要什么来决定。需要历史摘要就调摘要需要某个文件内容就临时检索全部通过标准化的上下文服务动态注入。我们团队最初用的是第 2 种也就是 ChatMemory 式滑动窗口。这一代方案本身不算错但它有明显的天花板。搞清楚它的原理和边界你才能真正理解为什么最终要走向 MCP 那一套。2. ChatMemory 滑动窗口第一代上下文管理的原理与调参关于滑动窗口最经典的解释来自信号处理和网络协议——你在热词里看到的滑动窗口重传协议滑动窗口滤波都是同一个思想的不同应用用一个固定大小的窗口随时间推移不断丢弃旧数据、纳入新数据让系统始终只关注最近一段区间内的信息。LLM 上下文管理里的 ChatMemory 滑动窗口本质是把这个思想移植到 token 序列管理上。2.1 滑动窗口的两种实现口径按条数截断与按 token 截断我在实现第一版时踩过一个大坑以为窗口就是最近的 N 条消息后来才发现编码代理的消息并不都是同一量级的。用户可能只发一句改一下登录接口但代理回复里夹着整段 diff 和报错日志一条消息可能顶用户一百条。按条数截断会导致 token 使用量剧烈波动窗口看起来没爆实际早已超限。更稳妥的做法是双阈值控制同时设置最大消息条数和最大 token 数无论哪个先达到都触发淘汰策略。用 Python 实现一个简易版本的话大概是这样的逻辑from collections import deque from typing import List class ChatMemoryWindow: def __init__(self, max_messages: int 50, max_tokens: int 12000): self.messages deque(maxlenmax_messages) self.max_messages max_messages self.max_tokens max_tokens def add(self, message: dict, estimate_tokens_func): # message: {role: ..., content: ...} self.messages.append(message) # 如果超出 token 阈值从头丢弃直到满足 self._trim_by_tokens(estimate_tokens_func) def _trim_by_tokens(self, estimate_tokens_func): total sum(estimate_tokens_func(m[content]) for m in self.messages) while total self.max_tokens and self.messages: dropped self.messages.popleft() total - estimate_tokens_func(dropped[content])deque(maxlen...)负责保证消息条数不超过阈值_trim_by_tokens负责保证 token 总量不超限。两条规则叠加窗口才能真正稳定。这里有个细节我后来反复提醒同事estimate_tokens_func必须和模型实际分词器一致用len(content.split())估算英文问题不大但代码场景里大量符号挤在一起空格分词会严重低估 token 数。我当时踩的坑就是没接真实 tokenizer导致窗口实际塞了 1.3 倍的 token 才触发截断模型直接报上下文超限。2.2 窗口大小的取值策略没有最优只有最不坏窗口设多大合适是团队里争论最多的问题。设大了上下文足但噪声多、成本高设小了省 token 但代理容易丢关键信息。我后来总结出一个经验公式思路窗口大小 ≈ 单轮工具调用循环的平均 token 数 × 代理需要保持的工作记忆轮数。举个例子我们的代理每完成一次读文件 → 改代码 → 跑测试循环大约消耗 1200 token。如果希望它至少记住最近 5 轮循环的决策上下文那就是 6000 token。再留一些缓冲给新消息我实际把窗口初始值定在 8000 token。这个数字不是拍脑袋而是先观察代理任务的 token 分布再倒推出来的。下面是我压测时记录的一组不同窗口大小下代理完成购物车模块重构的表现任务包含 4 个文件的联动修改窗口 token 上限任务完成率平均返工轮数单任务 token 开销400041%3.218.6K800067%1.822.1K1200072%1.624.8K1600069%2.129.4K数据很有意思的是窗口不是越大越好12000 到 16000 之间出现回落因为窗口大了以后早期被保留的过时信息——比如某个文件的老版本内容——反而干扰了代理对新版本的判断。这说明滑动窗口有一个内在悖论窗口太小丢东西窗口太大塞旧东西而旧东西和过时的东西在时间维度上是绑定的。2.3 滑动窗口在不同场景下的表现差异滑动窗口还有一个不容易发现的特性它对连续性任务和离散查询任务的表现差异非常大。连续调试类任务改 A 看 B、再改 B 看 C时间局部性强最近的上下文就是最有用的滑动窗口效果尚可但一旦调试链路过长超过 10 轮早期结论丢失后代理开始发明根因。多文件重构类任务跨 5 个文件的接口调整每轮循环要参考不同文件时间顺序不等于依赖顺序滑动窗口几乎必然丢失前置信息。它的表现比连续调试差得多。需求澄清类任务用户一段长需求 多次补充描述用户说过的约束如果恰好落在窗口外代理会用默认假设去做事产生隐蔽但严重的偏差。到这一步我基本确认了滑动窗口的边界它适合作为短期记忆存在但不适合承载工作记忆的全部职责。真正要做上下文优化得换一种思路——不是尽量保留最近的而是动态提供当前最需要的。3. 滑动窗口不够用了Context-mode MCP 如何按需供给上下文从滑动窗口走向 MCP不是推翻前面的设计而是把上下文管理的重心从缓存转移到调度。3.1 MCP 到底是什么为什么选它做上下文工程如果你还不太熟悉 MCPModel Context Protocol可以把它理解成模型和外部工具/数据源之间的一个标准 USB 接口。过去接入一个文件检索工具、一个数据库查询服务、一个文档摘要器每个都要写一套专用协议有了 MCP所有工具都以统一的工具/资源/能力形式暴露给模型模型按标准格式发起请求服务端按标准格式返回结果。在上下文工程这个场景里MCP 的意义是它把上下文获取从模型内部的隐式记忆变成了模型可以主动调用的显式服务。代理不依赖模型记住了什么而是知道自己可以去哪里查。这就是 Context-mode 的核心思路——平时不把所有东西塞进窗口而是在需要的时候通过 MCP 工具临时加载最相关的那一部分上下文。3.2 Context-mode 的三种上下文供给手段我落地 Context-mode MCP 时主要实现了三种上下文供给能力对应三种不同的取用需求。第一种语义检索式注入。当代理接手一个任务先通过 MCP 的search_codebase(query, top_k)工具把与任务关键词相关的代码片段检索回来。这一步相当于给代理一个项目地图告诉它去哪个文件、看哪个函数。实现上我起初用纯关键词匹配召回质量很差后来换成了 embedding 相似度检索效果有明显提升代价是多了向量化服务的依赖。对代码场景我更推荐关键词候选 embedding 重排的混合策略兼顾速度和准确。第二种结构化摘要兜底。滑动窗口的问题在于时间近的必然保留而有些需求是长线依赖——比如用户在第 3 轮提过一个全局约束第 30 轮才要求落地它。Context-mode 的做法是当窗口发现某段早期上下文即将被淘汰时不直接丢弃而是调用 MCP 的summarize_topic(topic)工具把相关内容压缩成结构化摘要存进一个长期备忘录。代理需要时通过recall_summary(topic)拉取。这相当于给代理配了一个自动记笔记的助手而不是只靠短时记忆。第三种工具痕迹回放。编码代理干活必定会产生 shell 命令、diff 补丁、测试输出。这些内容体量大、且多半是一次性的不需要长期保存但排查问题时又必不可少。我的做法是把完整工具轨迹写入持久化存储只在代理进入报错排查状态时才通过 MCP 回放最近 N 条工具调用轨迹。这样既不长期占用窗口又能按需恢复调查线索。3.3 Context-mode MCP 的架构要点谁来决定要什么上下文围绕 MCP 做上下文供给有一个设计问题非常关键决定当前需要什么上下文的是模型自己还是外部调度器我一开始把决定权完全交给模型让它自己按需调用 MCP 工具。结果模型经常忘调或者调太多。焦点跑偏的时候它会疯狂调一堆和当前任务无关的检索把窗口迅速撑爆。后来我调整为**规则预判 模型补调双通道**规则预判层在请求进入模型之前外部调度器根据当前任务类型code_edit / debug / test / grep预置一批最可能需要的上下文。比如任务类型是 debug就自动附带最近的测试输出和报错堆栈摘要任务类型是 code_edit就附带目标文件的函数签名和调用方列表。模型补调层模型在推理过程中如果发现自己还缺某个具体信息通过 MCP 工具自行补调。这一步保留了模型的主动性但不把全部信任押在模型的自觉上。我这里直接用 Agent SDK 的方式描述这个双通道流程方便理解整个调用链# 伪代码Context-mode MCP 调用的调度逻辑 async def build_context(request: TaskRequest) - List[ContextBlock]: blocks [] # 通道1规则预判 for rule in RULE_MAP.get(request.task_type, []): content await mcp_call(rule.tool, rule.args(request)) blocks.append(content) # 通道2模型补调 if request.model_need_context: extra await mcp_call(resolve_context, {prompt: request.prompt}) blocks.append(extra) # 最后做一次总控保证不超窗口 return trim_to_budget(blocks)这套架构跑起来之后最直接的感受是代理不再背着一整个项目在跑而是随时知道去哪里拿自己需要的东西。窗口占用从经常逼到 90% 以上稳定回落到 50% 左右。4. 实战落地从滑动窗口逐步迁移到混合上下文方案的完整记录理论讲得再好迁移过程中该踩的坑一个都不会少。这一节我完整记录一次从纯 ChatMemory 滑动窗口迁移到滑动窗口 Context-mode MCP 混合方案的真实过程包括配置对比和三个典型坑。4.1 基线环境与迁移步骤先说基线环境方便你做横向比较模型选用了一支支持 128K 上下文窗口、工具调用能力较好的通用大模型接口按 OpenAI 格式适配。代理框架自研轻量编码代理任务类型包含代码生成、单测调试、跨文件重构。原有上下文模块ChatMemory 滑动窗口窗口上限 12000 token消息条数上限 200 条。观察指标任务完成率、平均返工轮数、上下文占用率、单任务 token 开销。迁移不是一步到位的我踩到前面说的16K 窗口反而效果回落的坑之后意识到问题的关键不在窗口大小而在于保留策略太粗糙。之后我按以下步骤推进迁移保留滑动窗口作为短期记忆层窗口继续存在但缩小到 8000 token专职保留最近几轮的工具轨迹和未结对话。新增 MCP 上下文服务先接入search_codebase和summarize_topic两个工具跑通外部取上下文链路。把淘汰内容路由到摘要服务修改滑动窗口的淘汰逻辑——被挤出窗口的内容不再直接删除而是交给摘要工具压缩存储。加入规则预判层根据任务类型预注入基础上下文降低模型对窗口的依赖。压测对比与回滚验证每一小步都跑基准任务集确保没有劣化再进入下一步。4.2 迁移前后的关键对比数据迁移完成并稳定运行两周后我重新跑了一遍和 2.2 节同一组购物车模块重构任务数据对比如下指标纯滑动窗口12000 token混合方案窗口 MCP任务完成率72%86%平均返工轮数1.60.9上下文平均占用率63%47%单任务 token 开销24.8K19.3K跨文件联动修改的回归率68%82%最意外的是** token 开销反而下降了**。迁移前我以为引入 MCP 会增加额外请求成本数据却显示单任务总 token 开销降了约 22%。原因很容易理解过去窗口里塞着大量过时或无关的旧上下文白白消耗 token 还干扰判断现在按需注入之后去掉了这部分浪费模型出错少了返工 token 也相应减少。上下文工程的收益不只是让模型更准还是让模型更省。4.3 迁移路上的三个典型坑讲完成功数据必须把失败经验也摆上来。第一个坑摘要丢失了关键数字和约束。我最初设计的摘要策略是把窗口淘汰内容合并压缩成一段自然语言摘要。结果代理在后期执行细节时经常丢失具体数字比如超时时间 30 秒被写成超时时间要长一点。后来我强制规定摘要里必须保留三类信息数值型参数、精确标识符文件名、函数名、变量名、用户明确说过的否定式约束不要做 X。摘要模板改为结构化字段不是自由文本。第二个坑规则预判层注入过量上下文。预判逻辑写得太慷慨的话会在每个任务开头灌入一大包代码片段虽然没有超过窗口上限但模型在前期明显注意力发散经常跑偏到预判提供的但和当前子任务无关的文件上。修复方式预判注入的不是完整代码片段而是文件路径 关键符号 一句话说明真正需要细节时让模型再通过 MCP 工具拉取。代理学会查资料而不是背资料之后表现稳定了很多。第三个坑MCP 检索的召回噪声污染上下文。search_codebase返回的 top_k 代码片段存在大量近似匹配但不相关的噪音。举个例子搜update_stock会返回所有带 update 字样的函数距离真正目标十万八千里。应对办法有两个层面一个是检索侧加上重排序过滤器按调用关系而不是单纯 embedding 相似度排序另一个是 prompt 侧明确要求模型把检索结果当作候选线索而不是既定事实调用前先用可靠方式验证。这两个手段叠加后噪声影响基本可控。5. 上下文工程的进一步优化监控、调试与后续演进方向混合方案稳定跑起来之后我并没有就此停手。上下文体系和业务代码一样需要持续维护否则会悄悄劣化。最后一个部分分享我在这个过程中总结的监控手段和演进方向以及一些个人的建议。5.1 给上下文系统装上仪表盘很多团队对模型的应用指标只盯着响应延迟和成功率却不看上下文本身的质量。我做了一套非常轻量的上下文监控方案核心是给每次请求记录几组关键字段跑批分析按类型统计上下文占比对话历史、工具轨迹、代码片段、摘要文本各自在总 token 中占多少。如果代码片段占比长期偏低说明检索链路没有发挥价值。被截断淘汰的信息是否被重新请求如果某条信息被窗口淘汰后代理又通过 MCP 或用户重复请求了同样的内容说明保留策略存在漏洞。任务类型的上下文使用画像debug 任务和 code review 任务的上下文构成应当不同通过画像可以反推预判规则是否合理。拿到这些数据之后调参就不再靠感觉了。比如我发现重构类任务的代码片段检索量明显偏低就加强了规则预判层在重构场景下的文件预注入而不是笼统地加大窗口。5.2 更深一层的上下文优化思路分层记忆与任务画像沿着混合方案往前走我规划了三个进一步优化的方向。第一个方向是分层记忆架构短期窗口秒级、工作记忆任务级MCP 强相关、长期记忆项目级结构化摘要与知识库。每一层有独立的读写机制和淘汰策略层与层之间通过上下文化回调关联。这个架构对大型项目万级以上文件几乎是必须的。第二个方向是任务画像驱动的动态预算分配在请求进入模型之前用一个小模型对任务打标签生成、调试、重构、审查然后根据标签给出上下文预算配比——比如 debug 任务的工具轨迹预算占 40%重构任务的代码片段预算占 50%。这比统一模板更精准也是我正在重点推进的方向。第三个方向是上下文溯源与回放记录每次注入上下文块的来源标识来自哪个文件、哪个摘要条目、哪轮会话当模型输出出现偏差时能快速定位是哪块上下文误导了它。这本质上是给上下文做版本管理对调试复杂问题非常有用。5.3 一些个人建议做了这么多实战探索如果让我用一句话总结上下文工程的核心心法那就是模型的记忆不可靠别让它背让它查。滑动窗口适合做短期记忆的缓冲但真正支撑长任务、复杂项目的一定是一套显式的、按需驱动的上下文服务体系。MCP 的价值恰恰在于给这套体系提供了一个标准化的交互界面让查这件事变得非常自然。如果你正在从零搭建类似的系统我的建议是先别急着上复杂架构。第一步梳理清楚你的代理任务里上下文依赖的图景是什么——是强时序依赖还是强检索依赖根据任务特点选择主策略第二步在现有架构上叠加可观测性把上下文构成和模型行为关联起来第三步再逐步引入 MCP 服务用数据验证每一步的收益。如果你已经跑在纯滑动窗口方案上不妨试试把淘汰策略改成全量丢弃变摘要按需重取这一小步改动通常能在不大改架构的情况下带来可感知的提升。