企业官网建设流程全解析

1. 编码代理突然“失忆”的那一刻：问题的本质是什么

先说一个我自己的真实场景。有一次我用 AI 编码代理处理一个跨模块的重构任务，前期和代理在对话里敲定了接口规范、字段命名、错误码区间，甚至约好了 mock 数据的文件路径。前十分钟一切正常，代理生成的代码完全遵循我们的约定。

然后我让它顺手把另一个老模块也改一下，问题出现了：它开始用一个全新的字段命名风格，错误码也不按约定的区间走了，甚至重新“设计”了一套和之前完全冲突的目录结构。我翻回对话记录，发现之前的约定还在，但代理已经看不到了——或者说，它在生成最新回复时，根本没有把那段历史纳入计算。

这就是 AI 编码代理在长会话中典型的下滑曲线：开头很聪明，中间开始犯迷糊，后面干脆“重新做人”。多数人第一反应是“模型不够强”，但我换用更大参数的模型之后，问题依旧存在。真正的问题出在上下文工程上——你给代理喂了什么、喂了多少、以什么顺序喂，直接决定了它的实际智商。

编码代理和工作流自动化工具跑起来之后，消耗上下文的因素远不止“你和它聊了多少句话”。代码库检索结果、工具调用返回、终端输出、文件内容，全都在抢占同一个有限的窗口。窗口一满，最先被丢弃的往往不是低价值内容，而是早期敲定的核心约束——因为队列是先进先出，早期的约定注定最早被挤掉。

所以做上下文工程，核心不是把窗口调大，而是在有限的预算里，保证最有约束力的信息永远在场。这篇文章我会顺着一条完整的链路走下来：先拆解上下文膨胀的成因，再讲 ChatMemory 滑动窗口这套记忆管理机制怎么设计、怎么落地，然后讲 Context-mode MCP 如何从工具调用侧做降噪，最后把两者组合成一套可复用的上下文策略。整篇内容偏实战，适合正在用编码代理做真实项目、或者准备自建代理工作流的开发者。

2. 上下文膨胀的三个隐蔽来源：对话历史只是个开始

很多人在给代理“省上下文”的时候，只盯着对话轮数。实际上，对话历史在大多数编码代理的上下文消耗里占比往往不到一半。真正吃窗口的大户，是你调用工具时产生的返回内容，以及默认携带的系统信息和代码库检索结果。

2.1 工具返回的“信息洪流”远比对话本身更耗预算

每次让代理读取文件、搜代码、跑测试，工具返回来的内容都是完整的一块。比如一个read_file调用，文件 500 行，返回就是 500 行；一个grep调用，搜出 40 处匹配，每处带上下文 3 行，就是 120 行文本。这些内容进入上下文之后，如果后续对话没有再次引用，它们并不会自动释放，而是堆在那里占用预算。

更麻烦的是循环调用。代理经常会有这样的操作路径：读目录结构，读文件 A，读文件 B，发现文件 B 里引用了一个配置项，再去读配置，读完配置发现需要改文件 C……一次简单的改动，工具调用链路可能产生上万 token 的返回内容。这些内容本身不是垃圾，但有效性是瞬时的——代理读完配置之后，那份完整的配置文件就没有继续留在上下文里的必要了。

这就是编码代理上下文工程和普通聊天应用最不一样的地方：普通聊天里历史消息还有“翻回去看”的价值，编码代理的工具调用结果多数是一次性消耗品，用完之后最好的归宿是被清理掉。

2.2 代码库检索结果把无关信息带进了视野

代码语义检索（比如 embeddings 检索）返回的是“最相关”的文件片段，但“最相关”不代表“都有用”。做跨模块改动时，检索结果经常会带上我不想动的那部分代码——它因为关键词重合度高被捞了上来，但实际对当前任务没有任何参考价值。

这类内容占的 token 相当可观，尤其是框架生成的样板代码、配置里的冗余注释、相似度很高的重复封装。代理无法自动判断哪些是“参考”哪些是“约束”，它只会一视同仁地当作上下文处理。于是窗口里塞满了“看似相关”的信息，真正关键的那一行约束反而被稀释了。

2.3 系统提示词与工具描述的隐性成本

每个工具调用都要附带工具本身的 schema 描述，每个 MCP server 连接之后，server 的说明文档也可能被注入上下文。这些内容写的时候感觉没多少，但积少成多——挂三四个 MCP server，工具定义可能就有几千 token；系统提示词写得详细一点，又是几千 token。

这几千 token 平时引不起注意，但在窗口紧张的场景下，它就是压垮骆驼的最后一根稻草。更隐蔽的是，这些静态内容属于永远不会被滑动窗口淘汰的部分，它们的成本是固定摊销的，只能在配置层面做减法。

三个来源加在一起，你就明白了：上下文膨胀不是一个单点问题，对话历史管理、工具返回处理、静态信息瘦身三者必须一起做。只优化其中一个，窗口该爆还是爆。

3. ChatMemory 滑动窗口的设计逻辑：不只是“删旧留新”

ChatMemory 是 Claude Code 里我目前用下来最顺手的上下文管理方案之一。它不是一个单独的模型，也不是某个复杂框架，而是一套把上下文当成有生命周期的数据来管理的机制。核心思路可以拆成四个层面来讲。

3.1 三层记忆结构：短期工作区、中期引用区、长期抽取区

ChatMemory 的记忆管理不是“一个队列从头用到尾”，而是把上下文按角色分成了三层。

第一层是短期工作区，也就是当前正在执行的任务上下文。正在编辑的文件内容、当前函数的定义、最近几条操作指令，都放在这一层。这一层相当于你的工作台，什么东西正在手上处理，一目了然。

第二层是中期引用区，存放的是可能被再次访问的项目参考资料。比如你提到的某个接口定义、某个配置文件的路径、某个模块的结构说明。这些内容不是当前操作的核心，但后续大概率会被引用。

第三层是长期抽取区，负责从整个会话中提取“不可丢失的承诺”。代理和用户达成的命名约定、架构决策、禁止事项，都会被抽取出来，和原始对话分离存储。

这三层的核心价值在于：它不是简单地把旧内容删掉，而是先判断内容的价值，再决定它是该保留、该压缩还是该丢弃。

3.2 滑动窗口的淘汰算法：优先级不是按时间，是按约束力

纯时间维度的滑动窗口（最早的内容最先被淘汰）对编码场景不适用——正如我开头讲的，早期敲定的约定恰恰是最后悔被丢掉的。ChatMemory 在实际实现中给每个记忆单元加了一个优先级权重，淘汰时按权重从低到高清理：

• 工具调用返回的纯内容数据：权重最低，用完之后随时可以清理
• 历史对话中的解释性描述：权重中等，如果长期区已有等价抽取结果，可以直接丢弃
• 用户明确表达的要求和偏好：权重较高，尽量保留原文
• 跨模块的架构决策和约定：权重最高，几乎永不淘汰

所以 ChatMemory 的滑动窗口在“窗口太小，放不下所有高权重内容”时，才会对最高权重做压缩（摘要化），其他时候优先挤掉的都是低权重的瞬时数据。

你可以把这三层理解为生产车间的物料管理：工作台放当前正在拧的螺丝，物料架放手边随时要用的扳手，仓库放这批订单必须遵守的规格书。整理的时候，最先扔掉的是台面上用过的包装纸，而不是规格书。

3.3 高权重内容的摘要化压缩策略

当最高权重的内容也面临窗口压力时，ChatMemory 做的是摘要化而不是删除。它会调用模型把长对话、长文件的核心约束抽取成一段短文本，放进记忆序列。比如你和一个代理讨论了三十分钟的错误码方案，最终可能被压缩成一句话：“错误码命名规则：模块前缀+两位数字，101-199 为参数校验类，200-299 为依赖服务类。”

这种压缩损失的只是中间讨论过程，保留的是最终约束。对于后续任务来说，缺失过程完全不影响执行，保留的约束才是最重要的。

3.4 配置建议：根据你的任务类型调窗口参数

ChatMemory 在实际使用中，有几个参数值得你调一调。

第一个是窗口大小。默认配置适合轻量对话型任务，但做大型编码任务时，建议把短期工作区调大、长期抽取区保持紧凑。因为编码代理最怕的是“手头文件被挤出窗口”，而不是“旧约定没记住”——旧约定有抽取区兜底，当前文件被挤掉就要重新读。

第二个是摘要触发阈值。默认阈值可能在上下文用到 80% 时触发压缩，但对复杂重构任务，我会手动调低到 60%，提前压缩低价值数据，给后续工具调用留出余量。

第三个是长期抽取的频率。太频繁会增加额外开销，太稀疏会漏掉关键决策。我的实践是每完成一个子任务手动触发一次抽取，或者在代理执行一个较长任务链之前主动做一次记忆沉淀，确保后面新开的子任务能看到前置决策。

4. Context-mode MCP 的上下文优化：从源头上减少无谓注入

如果说 ChatMemory 是“上下文进来之后怎么分诊”，那 Context-mode MCP 就是“上下文进来之前怎么做初筛”。它解决的是编码代理和 MCP server 交互时的老毛病：工具返回了一大堆，真正有用的只有一小撮，其余全在窗口里吃灰。

4.1 MCP 工具调用的上下文困境

传统 MCP 模式下，编码代理调用工具就像你去图书馆借书：你想查“某个接口在哪些地方被调用”，图书馆管理员抱来一整箱文件，里面五十份文件只有三份相关。合上箱子之后，那五十份文件还全部堆在你的书桌上，占满了整个桌面。

具体到实现层面，一个 MCP 工具返回的原始数据可能是结构化 JSON、大段文本、甚至 Base64 编码的文件内容。代理拿到之后，为了从里面提取有效信息，还得把这些内容原样放进上下文里“读一遍”。这个过程在上下文预算充足时看不出来问题，一旦工具调用链条拉长，膨胀速度是指数级的。

4.2 按需注入与延后展开：Context-mode 的两板斧

Context-mode MCP 的核心机制可以概括为两个原则：按需注入和延后展开。

按需注入指的是，MCP server 返回的内容不直接全部进入上下文，而是先在代理的“暂存区”里待命。代理输出回复时，只有明确引用了 setTimeout 之前的数据，才会被展开注入到相应位置。没被引用的数据在暂存区里保留，但不占用主窗口。

延后展开更实用：工具返回先以结构化摘要的形式进入上下文（比如说“在 src/ 和 tests/ 下共找到 37 处引用，涉及 12 个文件”），代理需要看具体内容时，再按文件或按位置展开详情。这样多数情况下窗口里只有一份“索引”，只有真正深挖时才会有“正文”。

这两板斧合起来的效果是：一次包含 50 个文件检索结果的任务，传统模式下可能要吃掉 8000 token，Context-mode 下只花 300 token 的摘要空间。对于长会话，这就是几百个工具调用累积下来的巨大差距。

4.3 server 返回结构设计的落地细节

Context-mode 对返回结构有要求，不是任何 server 输出的原始结果都能自动享受这种红利。你在设计或改造自己的 MCP server 时，有几个结构约定值得注意。

首先，任何列表类返回都应该带“摘要层”。摘要层至少包含：命中总数、涉及文件列表、每处命中的一句话概述。落到 JSON 结构上，大概是这个形态：

{ "summary": { "query": "calculate_total", "matches": 37, "files": [ {"path": "src/order.js", "matches": 12, "summary": "包含订单金额计算核心逻辑"}, {"path": "src/cart.js", "matches": 8, "summary": "购物车金额汇总调用处"} ] }, "detail": { "src/order.js": [ {"line": 84, "snippet": "function calculateTotal(items) { ... }"}, {"line": 102, "snippet": "const total = calculateTotal(cart.items);"} ] } }

摘要层永远进入上下文，详情层默认留在暂存区，代理按需引用时才展开。这样设计，返回体无论多大，主窗口里永远只消耗摘要那一小块。

第二个约定是“展开粒度要有跳转能力”。每次详情展开都要带文件路径、行号范围、函数名之类的锚点信息，让代理能精确引用。有锚点，代理才能在做修改时直接定位；没锚点，它还得把整个文件拖进上下文自己找位置。

第三个约定是“返回内容必须带优先级标签”。有的工具返回是强约束（比如编译错误信息），有的是弱参考（比如代码风格建议）。带上标签之后，上层记忆管理系统可以据此决定缓存优先级——强约束内容进长期区，弱参考内容放短期区随时可丢。

4.4 和传统模式的对比效果

我用同一个编码代理跑了一个真实任务：在多文件项目中修改跨模块调用链，全程产生 27 次工具调用。传统模式跑完，上下文使用峰值约 28k token，会话后期代理已经出现遗忘迹象；切到 Context-mode 之后，同样的任务峰值只有 16k token，而且代理在会话后半段依然能准确引用前期的架构决策。

差距不是靠“模型变聪明”实现的，就是靠上下文结构优化省出来的。上下文工程的本质就是信息密度管理——同样的窗口，让代理看到的内容更有价值，它的推理质量自然就上去了。

5. 组合实战：ChatMemory 与 Context-mode MCP 的配合梯度

单独用其中任何一套方案都能改善体验，但真正产生质变的，是两套机制叠加后的组合效果。这两者解决的层面不同——ChatMemory 管“进入窗口后的生命周期”，Context-mode MCP 管“进入窗口前的体积控制”——配合起来正好形成一条完整链路。

5.1 一套推荐的三级上下文流水线

我把自己的代理工作流拆成三级流水线之后，整个上下文管理才真正从“救火”变成“常态”。

流水线第一级是MCP 数据瘦身。所有工具返回先过 Context-mode 的摘要/展开机制，粗加工之后，能进上下文的只有摘要层和锚点信息。这一步把最大头的消耗直接压掉。

第二级是内存分诊与会话管理。ChatMemory 的滑动窗口处理所有进入主窗口的数据——对话记录、摘要层数据、代码检索片段——按权重分诊到三层记忆区。短期区放当前任务数据，中期区放项目参考，长期区抽取约束性信息。

第三级是定期记忆沉淀。这是 ChatMemory 的主动动作，不依赖窗口满自动触发。每完成一个子任务或者每条消息处理结束时，对已有记忆做一轮压缩抽取。沉淀后的长期记忆反过来又能指导 Context-mode 的摘要策略——比如哪些文件是项目核心，哪些文件可以只在摘要层出现。

5.2 参数协同调优的经验值

两套系统联动之后，参数不能各自为政。我调了几次，目前这组参数在多数项目上表现稳定：

• ChatMemory 短期窗口：8k token。再大确实能多存点临时数据，但会挤压长期抽取区的空间，导致最终约束信息被压缩得太多
• ChatMemory 摘要触发阈值：60%。低于这个值压缩太频繁，多余开销影响响应速度；高于这个值则窗口总是太满，碰到大型工具返回容易爆
• Context-mode 摘要层大小：500 token 上限。不管命中多少文件，摘要必须控制在这个范围内，超出说明查询条件设计不合理
• 详情展开单次上限：单次调用里代理允许展开的文件数限制在 3 个以内，强制它聚焦，而不是一次性把结果全打开

这套参数在重构类、跨模块任务上表现很好。如果你主要做单文件小修补，可以把短期窗口调小到 4k，因为单文件任务需要的临时上下文本来就少；如果你在跑跨仓库的任务，建议把摘要层上限上调到 800 token，因为仓库之间的引用信息比单仓复杂。

5.3 一套可复用的提示词模板

组合配置跑起来之后，还需要一个和代理约定工作方式的提示词模板。这个模板本身不产生魔法，但它能让代理主动配合上下文管理系统，而不是被动等系统兜底。我在项目里用的模板结构如下：

工作方式约定： 1. 执行任何任务前，先检查已沉淀的记忆区，确认是否存在相关决策，不要重复询问。 2. 调用工具时，先消费摘要层数据，按需展开详情，禁止一次性展开全部返回内容。 3. 每条消息结束后，主动把新产生的架构决策、命名约定、禁止事项写入记忆抽取区。 4. 窗口紧张时，优先保留当前任务文件和长期约束，允许主动要求用户确认删除瞬时数据。 5. 发现之前记忆区中的决策与当前需求冲突时，先提出冲突说明，再执行新操作。

第 5 条特别有用。默认情况下，代理遇到新指令与旧决策冲突时，往往会直接按最新指令执行，导致早期约定被悄悄推翻。加上这条之后，代理会先提示冲突，由你来判断是旧约定失效还是新指令有误。这避免了大量“代理自己重新发明轮子”的隐性成本。

5.4 实际效果：一个跨模块重构任务的复盘

拿最近做的一个跨模块改造来复盘。任务是把订单模块原来的金额计算逻辑抽取到独立的费用中心服务，涉及 6 个文件、2 个公共工具库，全程大概 40 轮对话。

用组合方案的完整链路是这样的：代理先调用检索工具，Context-mode 返回的摘要层告诉它“费用计算逻辑集中在 order.js 和 cart.js，另有 5 处服务内调用”。代理展开 order.js 的详情锚点，确认核心函数结构，开始改造；改造过程中产生的接口定义、命名约定，ChatMemory 的三层记忆机制自动把关键决策沉淀到长期区。

40 轮跑完，上下文总量始终没有超过 20k token，而且最后 10 轮代理依然能准确说出“费用中心接口使用 calculateFee 命名”这种早期约定。对比没有组合方案时同类型任务 30 轮就开始混乱的表现，差距非常明显。

6. 边界条件与坑位记录：有些问题不是工程能解决的

上下文工程不是银弹。用了这套组合方案之后，我仍然遇到了几个绕不开的边界问题，值得说清楚，免得你踩了坑再回头骂方案不行。

6.1 语义焦点漂移：统计信息带宽的极限

滑动窗口和摘要机制再优化，本质上都是在解决“信息带宽”问题——单位窗口内塞进更多有效信息。但有一类问题它解决不了：任务的语义焦点一旦漂移，旧信息再怎么错峰存储，也难以及时被重新精准唤起。

比如你正在改前端支付流程，中途用户说“顺便把后端那个订单导出也一起改了吧”。这个“顺便”会让代理陷入焦点分裂。前端支付流程已经占用了大量认知资源，后端订单导出是全新的语义域。即便记忆区里有后端的相关存储，切换成本依然很高——代理需要重新展开后端相关文件、重新建立新上下文，而旧的支付流程数据又不会自动退场。

这类问题的解法不在工程侧，而在任务管理侧：要么明确告诉代理“切换到新任务，旧任务暂时搁置，不需要继续关注”；要么更干脆，开一个新的会话。上下文工程能帮你延后切会话的时间点，但跨大语义域的任务切换，该开新会话还是开新会话。

6.2 摘要压缩不可逆：细节损失是实打实的

记忆摘要化最大的代价是不可逆。一段 5000 token 的讨论被压缩成 200 token 的约束摘要之后，过程细节就再也找不回来了。

写代码这件事，有时候恰恰需要过程细节。比如之前为什么决定用 A 方案而不是 B 方案——摘要可能只留下“最终采用 A 方案”，B 方案被否定的原因是什么，如果项目条件变化，你可能需要复盘那个决策过程，但摘要里已经没有这些内容了。

我的应对方式是双轨制：对于高风险决策（比如数据库选型、接口协议变更、核心架构重构），在长期抽取区之外，单独保留一份完整的决策日志。这份日志不进代理上下文，而是作为外部文件存储，需要的时候手动让代理读取。摘要机制管的是“日常记忆”的压缩，外部决策日志管的是“重大共识”的完整归档。

6.3 会话恢复：记忆存储的独立性问题

这套方案的另一个坑是：ChatMemory 的抽取结果如果在代理进程重启后无法自动恢复，那所有沉淀都白做了。我遇到过几次：代理进程崩溃重启，记忆区清空，它又变成了一个完全失忆的状态，不得不重新对话建立约束。

现在的对话工具对记忆持久化的支持参差不齐。有的支持跨维度释放历史，有的需要手动告警机制。如果你在做关键项目，建议不要依赖工具的默认记忆恢复，而是建立自己的外部记忆锚点——把项目核心约束写在一个CONTEXT.md文件里，每次会话开始时让代理强制读取。文件级别的记忆比任何内存级记忆都可靠。

6.4 多代理协作时的记忆协商问题

最后一个坑来自多代理分工场景。我试过让一个“规划代理”负责拆任务，另一个“执行代理”负责写代码。理想状态下，规划代理的决策应该通过共享记忆传递到执行代理，但实际用下来，两个代理的记忆区是各自独立的，摘要文本无法完整传递决策的上下文。

这个问题的可行解法是建立一份结构化的任务交接单，而不是依赖自然语言摘要。交接单必须包含：目标说明、约束列表、文件清单、完成标准。执行代理拿到交接单后，将其注入自己的记忆长期区，再开始干活。我试过几次之后，这个流程比直接在系统提示词里写“参考上一个代理的输出”稳定得多。

7. 最后说点实在的使用体会

这套组合方案用下来，最大的感受是：上下文工程不能解决所有问题，但它能把代理被“逼疯”的时间点从第 20 轮推后到第 60 轮。对于大多数编码任务来说，40 轮内保持稳定的记忆和推理质量，就足够覆盖一次像样的重构作业了。

如果你现在刚开始接触这块，我建议的进阶路径是：先用单层方案感受差异。打开 ChatMemory 的滑动窗口默认配置，跑一个长会话任务，观察代理在第几轮开始出现遗忘；接着接入 Context-mode MCP 的摘要/展开机制，再看同样的任务能多撑多少轮。

对比数据一旦出来，你自然会对“上下文是怎么变胖的、又是怎么变瘦的”有直观感受。之后再按我上面给的参数和建议逐步调优，就不容易把问题归错因。

还有一个小技巧忍不住多说一句：善用会话内的“主动总结”指令。每完成一个阶段性目标，直接命令代理“用三句话总结当前项目的关键状态和强制约束”，然后把那段总结粘进一个持久化的上下文文件里。这个动作比任何自动机制都更简单有效——毕竟，让代理自己把最重要的东西写出来再喂回去，本质上就是一种概率最高的记忆强化方式。