AZ-104备考全攻略：从题库PDF到实验环境，六周高效通过Azure管理员认证
2026/9/30 6:15:07
最近在折腾 AI 编码代理的时候，我撞上了一个特别典型的问题：项目改到一半，代理“失忆”了。明明刚交代过某个模块的接口约定，让它去改另一个文件时，它直接按自己的理解发挥，产出的代码和之前的约定完全对不上。排了半天，发现问题不在模型能力，而在上下文管理——对话轮次一多，早期塞进去的核心指令早就被后续的报错日志、工具返回结果、无关讨论给冲散了。
这事其实特别普遍。用过 Cursor、Claude Code、Cline 这类编码代理的人应该都有感觉：刚开始对话时它特别“懂你”，越往后越“拉胯”。很多人以为是上下文窗口不够大，我一开始也这样想，后来才发现，单纯加大窗口只能缓解一时，真正要解决的是怎么让代理“始终带着关键上下文干活”。这段时间我一直在折腾 ChatMemory 的滑动窗口机制和基于 MCP 的 Context-mode 上下文优化，攒了不少心得，这篇就把它掰开揉碎了写清楚。
1. 编码代理“失忆”背后的上下文困境
先明确一件事：AI 编码代理不是一个能自己记住一切的“大脑”，它本质上是个“无状态”的调用器。你每给它发一条消息，它会把当前对话窗口里的全部内容重新发给底层模型，模型看完之后生成回复。也就是说，代理的“记忆”完全取决于对话窗口里此刻还留着什么东西。
1.1 上下文窗口再大也有物理极限
现在主流的大模型上下文窗口已经做到 128K、200K，甚至 1M Token 了。听起来很大对吧？但一个中型项目的真实体量远比你想的恐怖。假设一个项目有 50 个源文件，平均每个文件 500 行，每行折算下来约 10 到 15 个 Token，单个文件就要消耗 6000 到 8000 Token，50 个文件就是 30 万到 40 万 Token。这个量级，即便你有 200K 的窗口也塞不下一整个代码库。
所以矛盾很明显：不是窗口不够大，而是“所有上下文全塞进去”本身就是个伪命题。哪怕你硬塞进去了，效果也不会好。
1.2 注意力稀释比窗口溢出更致命
我做过一个对比实验：同样的需求，一次在对话里只保留必要的 8 个文件，另一次塞了 30 个文件进去。结果特别反直觉——塞了更多文件的那次，模型改代码时反而更容易出错。原因在于注意力机制：上下文越长，模型对每一个局部信息的“注意力权重”就越分散。就像你在嘈杂的餐厅里听人说话，背景噪音越多，你越听不清对方在讲什么。
这就是“上下文稀释”问题。大量无关文件、历史消息、中间输出混在里面，模型会把一些本来不该作为强约束的内容当真，把真正关键的指令当背景噪音。尤其是早期对话里你提过的硬性要求——“这个函数必须返回Result类型而不是直接抛异常”——在后面对话轮次中经常被遗忘或者弱化。不是模型变笨了，是它在海量信息里没法区分优先级。
1.3 token 成本是隐形的第三座大山
上下文管理的第三重压力来自成本。调用 API 是要按 token 付费的，而且每一次对话请求都会带上整个窗口的内容。也就是说，同样的一句“把测试补一下”，如果窗口里塞了 5 万 Token 的历史，实际消耗就是 5 万 Token，哪怕这次对话跟前面 80% 的内容毫无关系。
我做过一个简单的统计：不管理上下文，一个中等规模的功能开发来回 20 轮对话，累计消耗的 token 很容易飙到 80 万以上。而如果做好上下文压缩和裁剪，同样的功能可以把消耗压到 20 万左右。差距是 4 倍。这个数字在长周期、多人协作的项目里会被放大得非常夸张。
所以，编码代理的上下文管理，本质上是在同时解决三个问题：放不下、记不住、花不起。明白了这一点，再看 ChatMemory 滑动窗口和 Context-mode MCP 这两个东西，它们的价值就很清楚了。
2. ChatMemory 滑动窗口：把记忆做成滚动式缓存
ChatMemory 是编码代理里用来管理对话历史的一种机制。它解决的问题很直接：对话轮次太多时，不能把历史全部保留，但也不能全部丢掉，得有一套策略决定“留什么、丢什么、压缩什么”。
滑动窗口是它的核心策略之一。简单说，就是只保留最近 N 轮对话的完整内容，超过这个范围的旧消息，要么直接丢弃，要么压缩成摘要后保留。每来一轮新对话，窗口就往前滑动一格，最旧的消息被移出。
2.1 滑动窗口的核心逻辑
我用一个生活化的方式来解释。想象你在跟人聊天，正常人不会把三天前说的每一句话都记住，但会记得一个大意：“上次我们聊到要给接口加缓存”。ChatMemory 的滑动窗口做的是类似的事——最近的对话用“原话”保留，因为细节对当前任务最关键；久远的对话只留“摘要”，因为这时候只需要保住大概方向，细节反正也过时了。
具体到参数上，一般就四个：
| 参数 | 作用 | 我的建议值 |
|---|---|---|
| 窗口大小（Window Size） | 保留多少轮完整对话 | 8-15 轮 |
| 摘要阈值（Summarize Threshold） | 超过多少轮开始触发摘要 | 窗口大小的 1.5 倍 |
| 摘要粒度 | 每轮独立摘要还是合并摘要 | 按主题合并 |
| 保留策略（Retention） | 关键消息是否强制驻留 | 标记重要消息不走窗口 |
窗口大小是最敏感的参数。太小，代理记不住前因后果，改个跨文件的重构时老是前后矛盾；太大，token 消耗上涨，注意力稀释回归。我测试下来，窗口设在 8 到 15 轮之间最均衡——既能保证最近 20 分钟内的对话内容完整，又不至于让上下文账单失控。
2.2 摘要化不是简单地“总结一下”
很多人忽略了一个细节：摘要化的质量直接决定了代理的中期记忆能力。滑动窗口把旧消息丢弃或摘要后，代理对任务早期约定的认知，完全依赖这份摘要写得是否准确。
我踩过一个大坑：让代理自动生成摘要，结果它在摘要里丢了关键约束——“不要动auth模块的既有逻辑”。等到窗口滑过之后，代理再遇到相关问题时，就开始大胆重构auth模块了。排查到最后，问题出在摘要生成时上下文里的老代码太多，约束信息被淹没。
后来我改成了“结构化摘要”，明确要求摘要里必须包含四类信息：
- 当前任务的最终目标是什么
- 已经确定的技术方案和接口约定（原文保留关键信息，不改写）
- 明确禁止做的事（负面约束，单独成段）
- 未完成事项和下一步计划
我会把摘要指令写进系统提示词里，要求每次触发摘要时按这个模板来。效果立竿见影，代理解读历史决策时的偏差明显变小。这也算是一个实操中的定制化技巧，比默认摘要好用得多。
2.3 滑动窗口的边界：短期记忆的天然局限
滑动窗口本质上解决的是“短期记忆”问题，它管得了最近十几轮对话，管不了更长时间跨度的任务状态。假设一个功能开发了三天，期间跨了多个会话，第一天的关键决策早就被滑出去了，摘要也可能被二次压缩，“摘要的摘要”会把信息损耗放大到不可接受。
这种情况下，不能指望 ChatMemory 一个机制扛下所有。需要引入外部的“长期记忆”载体——把跨会话的关键信息写到项目文档、记忆文件或独立的上下文存储里，每次会话启动时再加载进来。这个后文会细聊，但这里先记住一个原则：短期记忆靠滑动窗口，长期记忆靠显式落盘，两者是互补关系，不是替代关系。
3. MCP 的上下文注入逻辑：从“记忆”升级为“按需取用”
如果说 ChatMemory 是从“时间维度”优化上下文——把对话历史的留存策略做聪明，那 MCP（Model Context Protocol）就是从“空间维度”做优化——把外部信息和工具能力按需、精准地注入到当前上下文里。
3.1 MCP 到底是什么
MCP 是一套开放协议，用来统一 AI 应用与外部工具、数据源之间的通信方式。你可以把它理解为 AI 圈的“USB-C 接口”：以前每个 AI 工具接不同外部系统都要写专门的适配代码，有了 MCP 之后，双方只要实现统一协议，就能即插即用。
放到编码代理的场景里，MCP 带来的能力是质变级的。没有 MCP 的代理，只能靠你手动把文件内容粘进对话框，或者依赖代理自身内置的文件读取工具。有了 MCP，代理可以直接通过标准协议调用外部服务——比如读数据库 Schema、查 GitHub Issue、调浏览器调试接口、获取监控系统的实时数据——而且调用结果会直接以结构化的上下文形式进入对话窗口。
这也是为什么最近 MCP 生态这么火。从 Playwright MCP 到 Chrome DevTools MCP，再到 BurpSuite MCP，本质都是在做同一件事：把某个工具的能力封装成 AI 可以主动调用的“上下文来源”。
3.2 Context-mode 的思路：上下文不是越多越好，而是越准越好
MCP 本身只是通信协议，真正决定上下文质量的是使用方式。我最近在重点实践的 Context-mode，核心思想就一句话：按当前任务的需求，动态决定注入哪些上下文，而不是把能拿到的全拿进来。
举例说明。假设代理正在帮你排查一个线上 Bug，数据链路是：前端页面 → 网关 → 用户服务 → 数据库。如果是默认模式，代理可能会把整条链路的代码、日志、配置全都纳入上下文，几十万 Token 瞬间爆炸。而 Context-mode 的做法是分步注入：
- 先只加载错误信息和调用链追踪数据，定位到具体是哪个服务出的问题；
- 再按需加载该服务的相关代码和配置；
- 最后只在需要验证时，才拉取数据库 Schema 或上下游接口定义。
每一步注入的上下文都跟当前任务直接相关。这样既不会遗漏关键信息，又有效控制了上下文体积，帮模型把注意力集中在真正重要的部分。
为了更好理解，我做了一张对比表帮大家快速掌握差异：
| 对比项 | 默认全量注入 | Context-mode 按需注入 |
|---|---|---|
| 上下文体积 | 大，常溢出窗口 | 小，可控 |
| 注意力分布 | 分散，关键信息被稀释 | 聚焦，核心指令权重高 |
| Token 成本 | 高 | 低，通常能省 50% 以上 |
| 信息完整性 | 看似全，实则乱 | 按需精准，每段有用 |
| 适配场景 | 小型项目、短对话 | 中型以上项目、长任务链 |
这个模式尤其适合多工具串联的场景。比如用 MCP 同时接了数据库工具和浏览器调试工具，代理需要决定“现在该查表还是该打开页面”，Context-mode 会让它根据任务阶段只调用其中一个，而不是把两个工具的返回结果同时堆进上下文。
3.3 资源描述：让代理知道你“有什么”比“注入什么”更重要
用过 MCP 之后，我发现一个容易被忽略的细节：代理不会主动“想起”它能调用什么工具，它得知道自己的工具箱里有什么。MCP 协议里每一类工具、数据源都对应一份资源描述——简单理解就是“工具说明书”，告诉代理这个工具是干什么的、返回什么格式、适用场景是什么。
这份描述写得好不好，直接决定代理会不会在你期望的时刻正确调用对应的 MCP 服务。比如你接了一个 Git 操作 MCP，资源描述里如果没写清“支持查看某文件的历史版本”，代理在需要对比历史代码时，可能就绕回去用自己手头的通用能力了，而不是调用这个更精准的 MCP 服务。
所以我自己整理了一套资源描述的“最小要素”：
- 工具的名称和一句话用途
- 输入参数说明（哪些必填、哪些选填、格式示例）
- 返回结果的结构（尤其是关键字段的含义）
- 适用场景举例（让代理知道“什么情况下用它”）
- 已知限制（避免代理在某些场景下误用）
这些描述本身也会占据上下文，所以要用最精炼的语言写。我的习惯是每条描述控制在 200 Token 以内，能一句话说明白的绝不多写半句。
4. 实战：ChatMemory 与 Context-mode MCP 的落地配置
理论部分说完了，下面讲实战。我以 Claude Code 为主线，配合本地 MCP Server 来演示完整配置流程。这个方案不绑定特定模型，思路可以平移到任何支持 ChatMemory 和 MCP 的编码代理上。
4.1 环境准备：基础工具链
先装好基础环境。我用的是 Node.js 20+ 和 Python 3.11，MCP Server 用 TypeScript 写的，跑在本地。为什么选本地跑？因为编码代理场景下，工具调用的延迟和隐私都敏感，本地部署最稳。
# 创建一个简单的 MCP Server 项目 mkdir my-context-mcp cd my-context-mcp npm init -y npm install @modelcontextprotocol/sdk typescriptMCP SDK 装好之后，先写一个最小的 Server，实现一个“读取项目约定文档”的工具。这个工具返回的内容会作为上下文注入点，后续做 Context-mode 的演示都基于它。
4.2 ChatMemory 参数设置实测
ChatMemory 的配置一般藏在编码代理的配置文件里。以我用的工具为例，我需要在配置文件中声明记忆策略的参数。下面是一组我实际在用的配置：
{ "chatMemory": { "enabled": true, "windowSize": 12, "summarizeThreshold": 18, "summaryTemplate": "target|solution|constraints|next-steps", "retention": { "markImportant": true, "keywords": ["auth", "api contract", "don't"] } } }几个关键决策点：
windowSize取 12，不是随便拍的。我测试过 6、8、12、16 这四档。6 和 8 在跨文件重构时明显“失忆”频繁；12 比较均衡，日常开发 90% 以上的场景都稳；16 以上 token 消耗涨得明显，但记忆提升已经不显著了。所以 12 是我认为的甜点值。summarizeThreshold设成 18，意思是窗口滑到 18 轮时开始触发摘要。给了个缓冲带，避免每次新对话都触发摘要，太频繁会影响响应速度。retention里我配置了关键词强制保留，凡是对话里出现auth、api contract、don't这类内容，相关消息不进摘要流程，原样保留。这个功能是保护关键约束不被摘要稀释的关键手段。
配置完记得重启代理进程，有些工具对配置的变化不是热加载的。我第一次改完没重启，调了半天参数没生效，还以为是配置写错了。
4.3 用 Context-mode 组织 MCP 工具
Context-mode 的核心特征是“按需激活工具，而不是全部暴露”。我在 MCP Server 里给每个工具都加了一个active状态，普通的“全量模式”下，代理能看到所有工具；切到 Context-mode 后，默认只激活当前任务阶段需要的工具子集。
举个例子，我的 MCP Server 里有这么几个工具：
read-project-docs：读取项目根目录的约定文档query-database-schema：查询数据库表结构fetch-issue-detail：从 Issue 系统拉取任务详情run-tests：执行指定测试用例
在 Context-mode 下启动编码代理时，我会写一个简短的启动指令，告诉它当前任务的上下文来源：
当前任务：修复用户登录接口在并发场景下的竞态条件 上下文来源： 1. read-project-docs -> docs/auth-contract.md 2. query-database-schema -> users, sessions 3. run-tests -> tests/auth/login.test.ts这几行信息本身也被当作上下文注入，但它起的作用是指引代理“该调用哪些 MCP 工具”。代理拿到这个指令后，会优先通过这几个工具获取信息，而不是什么都往里塞。我在实测中对比过：同样的任务，默认模式下首轮注入上下文约 42K Token，Context-mode 模式下首轮只有 11K，降幅超过 70%，而且修复方案的准确性反而更高——因为它从一开始就只盯着auth相关的代码和数据。
4.4 MCP 工具的命名与上下文标注
这里有一个很实用的优化点：MCP 工具的名字越长、越语义化，代理的调用准确率越高。因为编码代理在决定“该用哪个工具”时，很大程度上依赖工具名称和描述里的关键词匹配。工具名太抽象（比如tool_a），代理不知道什么时候该用；工具名直白（比如query-database-schema），代理一眼就知道查表结构时该调它。
我还建议在工具描述里主动标注数据的“新鲜度”和“粒度”。比如描述里写清“此接口返回的是最近 24 小时的聚合数据”，代理就会知道，如果要排查当前时刻的具体请求，这个工具的信息不够，得找实时数据源。这种细节对上下文的选择策略非常重要，能避免代理误用缓存数据做决策。
5. 调优过程中的几个关键坑与对策
配置都跑通之后，真正磨人的是调优。下面这几个坑是我实际踩过的，每一个都花了不少时间才定位到根因。
5.1 摘要化之后，代理对硬约束的遵守度下降
这是我在 ChatMemory 上踩的最大的坑。原本以为摘要只是“压缩表达”，后来才发现，模型在一段文字从“原文”变成“摘要”的过程中，语义信息是有损耗的。尤其是带否定语义的约束——“不要修改config.js的导出结构”——在摘要里很容易被写成“关注config.js的导出结构”，一字之差，意思完全变了。代理在后续操作时甚至会主动去改那个文件。
对策是把关键约束做成独立字段，而不是混在摘要正文里。我在摘要模板里单独拆了一个constraints段落，并且要求在生成摘要时，凡是涉及禁止性描述的句子必须原样保留，不得改写。这是我目前用过最有效的方案，强烈推荐给所有依赖 ChatMemory 做长任务的人。
5.2 窗口里有重复内容导致的信息冗余
第二个坑来自文件的重复注入。很多编码代理内置的文件读取能力，再加上 MCP 工具也可能返回同一份文件内容，两个来源一叠加，同一份代码在同一轮上下文里出现两三遍。信息冗余带来的不只是 token 浪费，更会让模型在参考代码时产生“哪个版本才是最新的”的困惑。
排查这个问题的思路是看上下文里的重复 Token 占比。我写了个小的统计脚本，统计对话窗口里重复文件出现的次数。结果发现，光靠去重就砍掉了约 18% 的 token 消耗。对策是在 MCP 工具和内置工具之间做职责划分——MCP 工具负责外部数据源的读取，项目内文件的读取交给内置能力，避免重复。
5.3 MCP 返回结果过大，反噬上下文窗口
MCP 工具很方便，但它的返回结果是全量注入的。有一次我用query-database-schema查了一个大库的表结构，返回了一百多张表的定义，瞬间吃掉了 8 万 Token。结果这次对话的后续，代理的响应明显变迟钝，因为上下文窗口已经被挤得差不多了。
这个问题的根子在于“返回结果不等于有效信息”。一百张表的结构，当前任务可能只需要三张表的。对策是我给查询类工具加了pattern参数，支持传表名关键字过滤；同时在工具的 MCP 实现里增加一层“结果裁剪”，超过设定阈值时自动截断并附加说明。这样上下文注入的就是经过筛选的信息，而不是原始的全量返回。
5.4 多 MCP 工具串联时的上下文污染
最后一个坑出现在多工具配合的链路里。比如排查一个 Bug 时，代理先调浏览器 MCP 抓了页面信息，又调数据库 MCP 查了数据，再调日志 MCP 拉了监控数据。每个工具返回结果都会留在对话历史里，而这些中间结果对后续步骤基本没有价值，却实打实地占着窗口。
解决思路是在代理工具描述里显式引导“用完即弃”。我通常会在描述里加一句：“调用完成后，可总结关键结论并忽略原始返回，以节省上下文空间。”这样代理会在拿到结论后主动把原始返回压缩掉。配合滑动窗口的机制，跑几个轮次之后，中间结果自然就滑出窗口了。
6. 组合起来：我的上下文管理标准流程
把 ChatMemory 和 Context-mode MCP 组合在一起之后，我形成了一套相对稳定的上下文管理流程，这里直接分享出来。
每个会话启动时的固定动作是：
- 加载项目级约定文档（通过 MCP 的
read-project-docs） - 把当前 Issue 的描述和验收标准写入对话起始位置
- 声明本次任务的上下文来源范围和工具集
- 设置 ChatMemory 的强制保留关键词（如
auth、api contract） - 开始任务，每完成一个阶段主动总结一次中间结论，然后让代理用一句话压缩历史
这套流程跑下来，我观察到的收益是：长任务的 session 卡死率（指上下文溢出导致的异常）从频繁出现降到了几乎没有；日常开发的 token 消耗比不管理时省了大约 45% 到 60%；最关键的是，代理在跨文件修改时的代码一致性明显提升，早期约定的接口规范不再容易跑偏。
7. 写在最后的个人心得
上下文工程这个方向，我觉得很快会成为 AI 编码代理使用者的必修课。模型能力在趋同，但“怎么把有限的上下文窗口用好”这件事，现在几乎完全取决于使用者自己的工程能力。
我个人最大的体会是：不要迷信大窗口，也不要完全依赖某一个单一机制。ChatMemory 把“时间维度的对话记忆”管好了，MCP 把“空间维度的外部信息注入”管好了，但最终还要靠使用者去设计“何时用哪种机制”的策略。这个策略没有标准答案，会随项目类型、任务周期、模型选择而变化。
如果你刚开始接触这块，我建议先别急着上很复杂的配置。第一步，把 ChatMemory 的窗口大小从默认值调到你任务实际需要的轮次，观察几轮对话的 token 变化和代码一致性；第二步，接一个你最常用的 MCP 服务，比如 Git 操作或数据库查询，用 Context-mode 的方式按需调用；第三步，再逐步叠加更多工具和摘要策略。按照这个节奏来，上下文管理的收益是肉眼可见的。
最后再分享一个小技巧：每次任务结束之后，我会让代理生成一份“会话遗言”——也就是把本次任务的关键决策、遗留问题、待办事项写成一段结构化的文字，存到项目目录下的一个记忆文件里。下次会话开始的时候，再让代理加载这份文件。这个做法弥补了滑动窗口只管短期记忆的短板，配合起来用，编码代理基本能实现跨会话的“稳定记忆”，不会再出现那种“三天后重新认识项目”的尴尬了。