企业官网建设流程全解析

1. 从一次上下文溢出说起：为什么编码代理的"记忆"需要工程化

去年冬天我在给一个中型后端项目做重构，代码库大概有四十多万行，模块之间耦合得比较紧。当时我让编码代理帮我梳理一条跨六个服务的调用链，它前两轮回答得还挺靠谱，到第三轮开始就"失忆"了——前面已经确认过的接口名、字段含义、异常码全被它抛到脑后，甚至开始编造不存在的类名。我一开始以为是模型能力问题，换了个更大的模型，结果只是把"失忆"的时间点往后推了两轮，本质没变。

后来我把请求日志和上下文拼装逻辑翻出来一看，问题根本不在模型，而在于我喂给它的上下文是"无脑全塞"的：每一轮都把历史对话、检索到的代码片段、工具返回结果原封不动地追加进去，token 数像滚雪球一样涨，等到超出窗口上限，系统就按最粗暴的方式截断——从最前面砍。而被砍掉的恰恰是最早、也是最关键的那部分需求约束。

这件事让我彻底转变了思路：编码代理的能力上限，很多时候不取决于模型本身，而取决于你怎么管理它的上下文。这就是"上下文工程"（Context Engineering）要解决的问题。它和提示词工程不是一回事——提示词工程关心"这一句话怎么写"，上下文工程关心"整个窗口里放什么、放多少、什么时候换掉"。前者是遣词造句，后者是内存管理。

这篇内容适合三类人看：一是正在做 AI 编码代理、AI 测试开发这类工具的工程师；二是被上下文溢出、代理"失忆"折磨过的开发者；三是想搞清楚 ChatMemory 滑动窗口和 MCP 上下文优化到底怎么落地的人。我会从 ChatMemory 的滑动窗口机制讲起，拆解它的取舍逻辑，再讲到 Context-mode MCP 这套上下文优化思路，中间穿插我自己踩过的坑和实测数据。全程不堆概念，尽量把"为什么这么设计"讲透。

2. ChatMemory 滑动窗口：一个看似简单却处处是坑的机制

2.1 滑动窗口到底在滑什么

ChatMemory 是编码代理里负责"记住对话"的组件。它的核心任务很朴素：把多轮对话组织成一个能塞进模型上下文窗口的序列。而滑动窗口（Sliding Window）是最常见的一种策略——只保留最近 N 轮对话，更早的直接丢弃。

你可以把它想象成一条传送带：新消息从一端进来，旧消息从另一端掉下去。窗口大小 N 就是传送带上能同时放多少个箱子。这个比喻很直观，但真正落地时你会发现，"一个箱子"到底指什么，各家实现差别巨大。

有的实现按"消息条数"算窗口，比如保留最近 20 条 message；有的按"轮次"算，一问一答算一轮；还有的按 token 数动态计算。这三种口径带来的行为完全不同。我见过一个项目，配置里写着window_size=10，开发者以为是 10 轮对话，结果实现里是按 message 条数算的，而每轮对话平均产生 4 条 message（用户输入、助手思考、工具调用、工具返回），实际只保留了 2.5 轮，代理当然"记不住"。

提示：接手任何带 ChatMemory 的项目，第一件事就是确认窗口的计量单位。别信配置项的命名，去读源码里那个if判断。

2.2 为什么"只留最近"会出问题

滑动窗口的假设是"越近的信息越重要"。这个假设在日常闲聊里成立，但在编码场景里经常翻车。

编码任务有个特点：关键约束往往出现在最开头。比如用户第一句话说"这个项目用的是 Java 17，禁止用 var，所有 DTO 必须用 record"，这条约束贯穿整个任务，但它在窗口最老的位置。等对话进行到第十轮，这条约束早就被滑出去了，代理开始用 var 写代码，你纠正它，它道歉，然后过两轮又忘了。

我在一个真实项目里统计过：一个平均 15 轮的编码任务，如果窗口设为 8 轮，关键约束的丢失率高达 60% 以上。这不是模型笨，是记忆机制把该记的东西扔了。

另一个坑是工具返回结果的体积。编码代理经常调用工具去读文件、跑测试、查文档，这些返回动辄几千 token。一条工具返回就能把窗口撑满，把前面几轮有价值的对话挤出去。我见过最夸张的一次，代理读了一个 3000 行的日志文件，直接把窗口占掉 80%，后面几轮对话全在"失忆"状态下进行。

2.3 几种滑动窗口变体的取舍

纯滑动窗口太粗暴，实践中衍生出几种改良版，我按自己的使用体验排个序。

我个人的经验是：中小项目用"滑动窗口 + 系统提示固定"就够了，大型长任务必须上分层记忆。中间那层"摘要压缩"听起来很美，但摘要质量不稳定，我遇到过摘要把"禁止使用某废弃 API"这条约束给"概括"没了的情况，反而更危险。

2.4 一个容易忽略的细节：窗口的"边界对齐"

滑动窗口还有个隐蔽的坑：截断位置如果不对齐，会把一轮对话切成两半。比如窗口从中间截断，留下一条孤立的工具返回结果，却没有对应的工具调用请求。模型看到这个会懵，要么报错，要么胡乱解释。

正确的做法是让窗口边界对齐到"轮次"或"完整的工具调用-返回对"。我在实现里加过一个校验：截断后检查第一条消息是不是"孤儿"（比如是 tool 角色但没有前置的 assistant 调用），如果是就再往前或往后挪一条。这个校验只花了二十行代码，但把代理的稳定性提升了一大截。

3. 上下文工程的核心矛盾：信息量与窗口容量的博弈

3.1 上下文不是越多越好

很多人有个直觉：给模型的信息越多，它答得越好。这个直觉在编码场景里是错的。

我做过一组对照实验，同一个编码任务，分别给代理喂 2k、8k、32k token 的上下文。结果是 8k 那组表现最好，32k 那组反而更差——它开始关注一些无关的代码片段，把注意力分散了，还容易把不同文件的相似命名搞混。这就是所谓的"上下文污染"：无关信息不仅占地方，还会主动干扰判断。

所以上下文工程的第一原则不是"塞满"，而是"精准"。窗口是稀缺资源，每一 token 都要问一句：它对当前这一步决策有用吗？

3.2 上下文的四种成分及其优先级

我把编码代理的上下文拆成四类，按优先级从高到低排：

1. 硬约束：语言版本、框架、编码规范、禁止事项。这类信息必须常驻，不能滑出。
2. 当前任务状态：正在改哪个文件、已经改了哪些、下一步要做什么。这类信息要实时更新。
3. 相关代码片段：与当前任务直接相关的函数、类、接口定义。按需检索，用完即弃。
4. 历史对话：之前的讨论、纠错、确认。可压缩、可摘要。

优先级清楚了，策略就出来了：硬约束常驻，任务状态滚动更新，代码片段按需注入，历史对话压缩保留。这比一刀切的滑动窗口精细得多，也是 Context-mode MCP 这类方案的设计出发点。

3.3 一个反直觉的结论：有时候要主动"遗忘"

上下文工程不只是"记住"，还包括"主动忘掉"。有些信息留着是负资产。

比如代理前面走了一条错误的排查路径，试了三种方案都失败了。这三段失败记录如果一直留在窗口里，会持续干扰它——模型倾向于"延续之前的思路"，哪怕那条思路已经证明是死路。这时候正确的做法是主动清理掉失败尝试的细节，只保留一句"方案 A/B/C 已排除，原因是……"，把窗口腾出来给新思路。

我在实现里加过一个"上下文清理"的钩子：当检测到连续两轮工具调用都失败时，自动把这两轮的详细返回压缩成一行结论。实测下来，代理"钻牛角尖"的概率明显下降。

4. Context-mode MCP：把上下文管理从"硬编码"变成"协议化"

4.1 MCP 解决的是什么问题

MCP（Model Context Protocol）本质上是一套让模型和外部工具、数据源对话的协议。你可以把它理解成"AI 世界的 USB 接口"——不管对面是数据库、文件系统还是某个 SaaS 服务，只要按 MCP 规范暴露能力，模型就能统一调用。

但很多人只把 MCP 当成"工具调用协议"，忽略了它在上下文管理上的价值。Context-mode MCP 这个思路的核心是：把上下文的获取、过滤、压缩也做成一种可插拔的能力，而不是写死在代理代码里。

传统做法是：代理代码里硬编码"我要读文件、我要检索代码、我要压缩历史"。每换一个场景就得改代码。Context-mode 的做法是：把这些能力抽象成 MCP 服务，代理通过协议去请求"给我当前任务最相关的上下文"，具体怎么筛、怎么压，由服务端决定。

4.2 Context-mode 和普通工具调用的区别

普通 MCP 工具调用是"我告诉你做什么，你返回结果"，比如"读这个文件"。Context-mode 更像是"我告诉你我要干什么，你帮我准备上下文"。

举个例子。普通模式下，代理要改一个函数，它得自己决定：读哪个文件、读多少行、要不要读调用方。这些决策全靠模型自己判断，很容易读多或读少。Context-mode 下，代理只需要说"我要修改OrderService.calculateTotal"，上下文服务会自动把函数定义、它的调用方、相关的 DTO、最近的测试用例一起准备好，按相关性排序后返回。

这个差别很大。前者把"找上下文"的负担压在模型身上，后者把它交给专门的检索逻辑。模型擅长推理，不擅长精确检索，分工之后整体效率提升明显。

4.3 落地 Context-mode MCP 的关键设计

我在自己的项目里实现过一版 Context-mode MCP 服务，踩了不少坑，说几个关键设计点。

第一，上下文请求要带"意图"而不是"坐标"。别让代理说"读第 100 到 200 行"，让它说"我要理解这个函数的错误处理逻辑"。意图描述让服务端有空间做智能检索，坐标描述则把服务端降级成了文件读取器。

第二，返回结果要带"相关性分数"和"来源"。代理需要知道哪段上下文更可信、来自哪个文件。我一开始没加来源信息，结果代理把测试代码里的 mock 数据当成了真实业务逻辑，闹了笑话。

第三，要有"预算控制"。上下文服务返回的内容不能无限大，得有个 token 预算。我设的是"单次请求不超过 4k token"，超了就按相关性截断。这个预算要可配置，因为不同任务需要的上下文量差别很大。

第四，缓存要分层。代码片段、文件结构这类变化不频繁的内容可以缓存久一点；任务状态、最近修改这类高频变化的内容缓存要短。我一开始用统一 TTL，结果代理经常拿到过期的文件内容，改了半天的代码其实早就变了。

5. 把两者接起来：滑动窗口 + Context-mode 的协同实战

5.1 整体架构长什么样

单靠滑动窗口管不住长任务，单靠 Context-mode 又缺一个"短期记忆"的兜底。我的做法是两者协同：

• 短期层：ChatMemory 滑动窗口，负责最近几轮的即时对话，保证连贯性。
• 长期层：Context-mode MCP 服务，负责按需检索代码、文档、历史结论。
• 约束层：系统提示 + 一个独立的"约束存储"，硬约束永远注入，不参与滑动。

代理每一轮开始前，先由约束层注入硬约束，再由 Context-mode 按当前任务检索相关上下文，最后拼上滑动窗口里的最近对话。三层拼完，再做一次 token 预算校验，超了就按优先级砍。

5.2 一次完整的上下文拼装过程

我拿一个真实场景走一遍。任务是"给订单服务加一个超时自动取消的功能"。

第一步，约束层注入：项目是 Java 17、Spring Boot 3、禁止用Thread.sleep、定时任务统一用调度框架。这些是常驻的。

第二步，Context-mode 检索：代理声明意图"我要实现订单超时取消"，服务端返回OrderService定义、现有的定时任务配置、订单状态枚举、以及一个类似的"支付超时"实现作为参考。按相关性排序，控制在 4k token 内。

第三步，滑动窗口拼接：最近 5 轮对话，包括用户的需求描述、代理的方案讨论、我确认的几个决策点。

第四步，预算校验：三层加起来 11k token，没超 16k 的预算，直接发。如果超了，先砍滑动窗口里最老的对话，再砍 Context-mode 里相关性最低的片段，硬约束永远不砍。

这套流程跑下来，代理在 20 轮以上的长任务里基本不再"失忆"，关键约束的保持率从之前的 40% 提到了 95% 以上。

5.3 实测数据与调参经验

我把调参过程中几个关键参数和实测效果整理成表，供参考。

有个反直觉的发现：滑动窗口轮数不是越大越好。我从 8 调到 5 之后，代理表现反而更稳。原因是窗口里塞太多历史，模型会过度依赖"之前说过什么"，而不是"当前任务需要什么"。5 轮是个比较舒服的平衡点，再少就丢连贯性了。

6. 那些文档不会告诉你的坑

6.1 工具返回结果的"隐形膨胀"

前面提过工具返回会撑爆窗口，这里说个更隐蔽的：同一个工具被反复调用，返回内容高度重复。比如代理连续读了同一个文件的三个不同片段，三次返回里有大量重叠。如果不做去重，窗口里全是冗余。

我的做法是在 Context-mode 服务端加一层"内容指纹"去重：对返回内容算个哈希，如果和最近几次返回高度相似，就只返回差异部分，并标注"与上次返回的差异"。这一招把工具返回的平均体积压掉了 40%。

6.2 摘要压缩的"信息漂移"

用摘要压缩历史对话时，最容易出问题的是约束类信息的漂移。比如原文是"禁止使用System.out.println"，摘要可能写成"建议使用日志框架"，语义就从"禁止"变成了"建议"，强度完全变了。

我的应对是：约束类信息不参与摘要，单独抽出来存。摘要只处理"讨论过程"和"已排除方案"这类软信息。硬约束走独立存储，永远原文注入。这个规则看起来简单，但能避免很多"代理突然不守规矩"的诡异问题。

6.3 多轮任务里的"状态漂移"

长任务跑到后面，代理对"当前进度"的认知容易漂移。它可能忘了已经改过哪个文件，重复修改；或者忘了某个决策已经确认，又拿出来重新讨论。

解决办法是维护一个显式的"任务状态对象"，每轮更新，每轮注入。这个对象很小，就几个字段：当前文件、已完成步骤、待办步骤、已确认决策。它不参与滑动，永远在窗口最前面。有了它，代理的"方向感"稳很多。

6.4 上下文顺序对结果的影响

同样的内容，放在窗口的不同位置，模型的表现不一样。我的实测是：硬约束放最前，任务状态紧随其后，相关代码放中间，历史对话放最后。这个顺序符合模型的注意力分布——开头和结尾的注意力权重高，中间相对低。把最重要的放两头，次要的放中间。

我试过把硬约束放最后，结果代理经常"读到一半就开始动手"，约束还没看到就出错了。顺序这事看着玄学，实测确实有影响。

7. 从编码代理到更广的场景：上下文工程的通用思路

7.1 这套方法能迁移到哪些场景

上下文工程不只服务于编码代理。任何"长任务 + 有限窗口 + 需要记住约束"的场景都用得上。

比如 AI 测试开发，测试用例生成需要记住"被测系统的接口契约""历史失败用例""覆盖率要求"，这些和编码代理的约束、状态、参考代码是一一对应的。再比如多 AI 协作场景，多个代理分工干活，上下文管理就变成了"如何在代理之间传递最小必要信息"，本质还是那套优先级和预算控制。

我甚至把这套思路用在了写长文档上：硬约束是"文档大纲和风格要求"，任务状态是"已写章节"，参考材料按需检索，历史讨论压缩保留。效果比无脑把所有材料塞进去好得多。

7.2 一个可复用的上下文管理清单

我把实践中总结的检查项列出来，你可以对着自己的项目过一遍：

• 窗口的计量单位是什么？条数、轮次还是 token？
• 硬约束有没有独立存储？会不会被滑出？
• 工具返回有没有体积上限和去重？
• 摘要压缩会不会改变约束的语义强度？
• 有没有显式的任务状态对象？
• 上下文拼装的顺序是否合理？
• 超预算时的裁剪优先级是否明确？
• 缓存 TTL 是否按内容变化频率分层？

这八条里，我见过最多人栽在第一条和第三条上。计量单位搞错，窗口形同虚设；工具返回不设限，窗口分分钟被撑爆。

7.3 关于"要不要上向量检索"的判断

很多人一提到上下文管理就想上向量数据库。我的建议是：先别急。

向量检索适合"海量、非结构化、需要语义匹配"的场景，比如几万篇文档里找相关段落。但编码代理的上下文需求往往是"精确、结构化、有明确指向"的——我要的就是那个函数、那个接口定义，不需要语义模糊匹配。这种情况下，基于符号索引（函数名、类名、文件路径）的精确检索又快又准，比向量检索靠谱得多。

我的项目里是两者结合：符号索引负责精确定位，向量检索负责"找相似实现"这类模糊需求。但主力是符号索引，向量只是补充。别本末倒置。

8. 我个人的几点体会

折腾这套上下文工程大半年，最大的感受是：AI 编码代理的瓶颈，八成不在模型，在工程。同一个模型，上下文管得好和管得差，表现能差出一个档次。很多人抱怨"模型不行"，其实是自己喂给它的东西不行。

第二个体会是：上下文管理没有银弹，只有权衡。滑动窗口简单但会丢信息，分层记忆容量大但复杂，摘要压缩省地方但会失真。你得根据自己的任务特点选组合，而不是找一个"最优解"。我的组合未必适合你，但判断逻辑是通用的：先想清楚哪些信息绝对不能丢，再想清楚窗口能装多少，剩下的就是怎么在约束下做取舍。

第三个体会，也是我觉得最值得分享的：主动遗忘比被动截断重要得多。滑动窗口的截断是被动的、无差别的，而好的上下文工程应该是主动的、有选择的——该记的记牢，该忘的果断忘，该压缩的压缩。这个"主动"二字，是区分"能用"和"好用"的关键。

最后分享一个小技巧：如果你也在做编码代理，不妨加一个"上下文审计"日志，把每轮实际注入的内容和 token 分布打出来。我一开始就是靠这个日志才发现工具返回占了 60% 的窗口。看不见的地方，往往就是问题所在。