企业官网建设流程全解析

1. 当上下文被压缩，代理为什么突然"失忆"

做过AI编码代理的人大概都经历过这种崩溃：你精心搭建了一个能自主读写代码、跑测试、提交PR的代理，前几轮对话它表现得像个靠谱的资深工程师，结果聊到某个临界点，它突然开始胡言乱语——忘了自己刚才改过哪个文件，把已经修好的bug又改回去，甚至对着一个根本不存在的函数名反复调用。你以为是模型能力不行，换了个更大的模型，问题依旧。真正的原因往往不在模型本身，而在上下文压缩这个几乎每个长会话代理都绕不开的机制。

所谓上下文压缩，通俗讲就是当对话历史累积到接近模型上下文窗口上限时，系统为了腾出空间，会把早期的消息做摘要、截断或者丢弃。这个过程很像电影《记忆碎片》里主角的处境：他只能记住最近几分钟的事，更早的记忆全靠自己提前写在纸条和纹身上的碎片信息来还原。代理也是一样，一旦早期的关键决策（比如"这个项目用的是pnpm不是npm""测试命令是make test-unit而不是pytest"）被压缩掉，它就会基于残缺的记忆做出错误判断，而且自己浑然不觉。

标题里提到的"20万token的脑叶切除术"，说的就是这种大规模上下文裁剪。脑叶切除术在医学上指切除部分脑组织来治疗严重疾病，代价是患者会丧失部分人格和记忆。上下文压缩对代理而言就是一次数字版的脑叶切除：为了让它能继续运行下去，不得不切掉一部分"记忆"，但切完之后它可能就不再是原来那个能干的代理了。而"Unix init.d"和"《记忆碎片》"这两个意象，恰好指向了解决这个问题的两条核心思路——用一套可靠的、独立于主记忆的启动脚本机制来固化关键状态，以及用外部化的"纹身"来持久化那些不能被遗忘的信息。

这篇文章想聊的，就是怎么让你的AI编码代理在这种"脑叶切除术"中活下来。适合谁看？如果你正在做基于大模型的自动化编码工具、长会话Agent、或者任何需要跨越多轮对话保持状态一致性的系统，这里面的思路和踩坑经验应该能帮你少走不少弯路。我会从压缩机制的本质讲起，拆解为什么常规的"把摘要塞回上下文"做法会失效，然后给出基于init.d式状态固化和外部记忆纹身的具体方案，最后附上实测中遇到的各种意外情况。

2. 上下文压缩到底切掉了什么：一次真实的失忆复盘

2.1 压缩不是简单的"删旧留新"

很多人对上下文压缩的理解停留在"超出窗口就把最老的消息扔掉"。实际系统里的压缩策略要复杂得多，常见的有这么几类：

• 滑动窗口截断：保留最近N条消息，更早的直接丢弃。最简单，但破坏性最大。
• 摘要压缩：把早期对话交给模型生成一段摘要，用摘要替换原文。听起来优雅，实则暗藏陷阱。
• 关键信息抽取：识别出实体、决策、约束等结构化信息，只保留这些。实现难度高，但效果最好。
• 分层记忆：把记忆分成短期（完整保留）、中期（摘要）、长期（向量检索）三层，按需调取。

问题在于，大多数现成的代理框架默认用的是前两种，而这两种恰恰是最容易造成"关键决策丢失"的。我实测过一个中等复杂度的重构任务，代理需要跨12个文件修改接口签名。跑到第40轮左右触发了摘要压缩，结果摘要里只写了"代理修改了若干文件以适配新接口"，把"哪个文件改成了什么签名"这个最关键的信息全丢了。代理接着往下跑，调用了一个它自己刚改过、但摘要里没提的新签名，直接报错，然后它开始怀疑人生，把之前改对的又改了回去。

2.2 为什么"把摘要塞回去"经常救不了场

直觉上，只要摘要写得够好，代理应该能靠摘要恢复记忆。但实测下来，这条路经常走不通，原因有三层。

第一层是摘要的粒度失配。摘要天然是粗粒度的，而编码任务需要的是精确到函数名、参数类型、文件路径的细粒度信息。你让模型把"代理在第15轮把UserService.getUser()的返回类型从User改成了Optional<User>"这种信息压缩进一段200字的摘要里，它大概率会写成"代理调整了用户服务的返回类型"。等你需要这个精确信息时，摘要里根本没有。

第二层是摘要本身的二次失真。摘要也是模型生成的，模型在生成摘要时同样可能遗漏、曲解或者过度概括。更麻烦的是，如果摘要生成时上下文已经接近上限，模型能看到的原始信息本身就不完整，摘要质量会进一步下降。这就像让一个已经失忆的人写回忆录，写出来的东西可信度存疑。

第三层是代理对摘要的信任问题。代理拿到摘要后，往往会把摘要当作"事实"来用，但它无法区分摘要里哪些是精确的、哪些是被概括掉的。当摘要说"测试已通过"，代理就真的以为测试通过了，哪怕实际上只是部分测试通过。这种盲信会导致它在错误的假设上继续推进。

2.3 一次完整的失忆排查链路

我记录过一次典型的失忆事件，完整排查过程如下，你可以对照自己的场景看看有没有类似症状。

症状：代理在第55轮突然开始报"找不到模块@core/utils"，但项目里这个模块明明存在，而且前50轮它一直在正常引用。

第一步，确认是不是模型能力问题。换了个更强的模型重跑，同样的轮次附近出现同样的问题。排除模型能力。

第二步，检查上下文长度曲线。发现第52轮时上下文达到了窗口的92%，触发了压缩。压缩后上下文降到了60%左右。时间点吻合。

第三步，定位被压缩掉的内容。把压缩前后的完整消息序列dump出来对比，发现被摘要掉的部分里，恰好包含了第8轮时代理自己创建的tsconfig.json路径别名配置——@core/utils这个别名就是在那轮定义的。摘要里只写了"代理配置了TypeScript项目"，没提别名。

第四步，验证假设。手动把别名配置重新塞回上下文，代理立刻恢复正常。假设成立。

第五步，找根因。根因不是压缩本身，而是压缩策略没有把"配置类决策"识别为必须保留的关键信息。它把所有早期消息一视同仁地摘要了，导致这种"一次性定义、长期依赖"的配置信息被稀释掉。

这个排查链路的价值在于，它告诉你失忆问题往往不是单一原因，而是"压缩策略+信息类型+代理信任模型"三者叠加的结果。只修其中一环，问题还会以别的形式冒出来。

3. init.d式状态固化：把关键决策从易失记忆里搬出来

3.1 Unix init.d给我们的启示

用过Linux的人都知道/etc/init.d/这套机制。系统启动时，init进程会按顺序执行这些脚本，把各种服务拉起来。这套机制的精髓在于：服务的启动逻辑不依赖于"上一次运行时内存里记得什么"，而是固化在磁盘上的脚本里。系统重启多少次，只要脚本还在，服务就能以确定的方式恢复。

把这个思路搬到AI代理上，核心就是：不要让代理的关键状态只存在于对话上下文里，而是把它固化到上下文之外的文件中，每次需要时重新读取。上下文压缩可以切掉对话历史，但切不掉磁盘上的文件。代理只要知道"去读哪个文件"，就能恢复关键记忆。

这听起来简单，但落地时有很多细节。下面拆开讲。

3.2 设计一份"代理启动脚本"

我在自己的代理里加了一个约定：项目根目录下放一个.agent/state/目录，里面维护几个固定文件。代理在每次会话开始时，第一件事就是读这些文件；在做出任何关键决策后，第一件事就是更新这些文件。这套文件就相当于代理的init.d脚本。

具体文件设计如下：

关键在于，这些文件的内容要精确、可执行、无歧义。比如commands.md里不能写"用测试框架跑测试"，而要写pnpm vitest run --reporter=verbose。decisions.md里不能写"用了状态管理库"，而要写"选用Zustand而非Redux，因为项目只需要轻量全局状态，Redux的样板代码成本过高，决策日期第12轮"。

3.3 代理如何"重新挂载"这些状态

光有文件不够，代理得知道什么时候去读、怎么读。我的做法是在系统提示词里写死一段"启动流程"，大意是：

每次会话开始，或当你感觉上下文可能被压缩后（比如你发现自己记不清之前的决策），按顺序执行：读取.agent/state/project.md了解项目背景，读取decisions.md回顾关键决策，读取state.json确认当前任务进度，读取gotchas.md避免重蹈覆辙。读取后再开始工作。

这段提示词本身很短，不会被压缩掉（因为它通常在系统提示的最前面，且很多框架会优先保留系统提示）。代理只要还记得"去读那几个文件"，就能把大部分关键记忆恢复回来。

这里有个实测心得：不要指望代理自己判断"我是不是失忆了"。模型对自己记忆状态的判断很不靠谱，它经常在已经丢失关键信息的情况下依然自信满满。所以更稳的做法是强制它在每个大步骤开始前都重读一遍状态文件，哪怕它觉得自己记得。多读几次的成本，远低于失忆后跑偏的成本。

3.4 状态文件的写入要"防呆"

写状态文件时最容易犯的错是写得太模糊。我见过代理在state.json里写{"status": "in progress"}，这种状态等于没写。好的状态记录应该让一个完全不了解上下文的代理读完之后能立刻接着干。

对比一下：

// 差的写法 { "task": "重构用户模块", "status": "进行中" } // 好的写法 { "task": "重构用户模块的认证逻辑", "status": "进行中", "completed": [ "已将 UserService.authenticate() 拆分为 validateCredentials() 和 generateToken()", "已更新 UserController.login() 调用新方法", "已为 validateCredentials() 补充单元测试，测试文件 tests/user/auth.test.ts" ], "next": "更新 UserController.logout() 调用新的 token 失效逻辑", "blocked_by": "无", "last_updated_round": 47 }

好的写法里包含了已完成项、下一步、阻塞项和更新轮次。代理读到这个，哪怕完全失忆，也能在30秒内接上进度。差的写法只会让它重新问"我们要做什么"。

4. 《记忆碎片》式外部纹身：让关键信息无法被压缩

4.1 纹身思维：把信息刻在压缩够不到的地方

《记忆碎片》里主角的纹身之所以有效，是因为纹身刻在皮肤上，不依赖于他随时会清空的短期记忆。对应到代理系统，我们需要找到那些压缩机制够不到的地方，把最关键的信息刻上去。

哪些地方是压缩够不到的？根据我的实测，大致有这么几层，从最安全到最不安全排列：

1. 磁盘文件：完全不受上下文压缩影响，最安全。
2. 系统提示词：大多数框架会优先保留，但也不是绝对。
3. 工具定义/函数签名：通常作为固定部分保留。
4. 最近N轮对话：滑动窗口会保留，但N可能很小。
5. 早期对话：最容易被压缩掉。

所以"纹身"策略的核心就是：把越关键的信息，刻在越靠前的层级上。项目级的铁律（比如"永远不要直接push到main分支"）应该刻在系统提示词或磁盘文件里；任务级的临时状态可以放在最近对话里。

4.2 用"检查点"代替"摘要"

常规的摘要压缩是"把旧对话浓缩成一段话"。我用的替代方案是检查点机制：不让系统自动摘要，而是让代理在关键节点主动写一个结构化的检查点，然后由系统把检查点作为高优先级消息保留，原始对话该丢就丢。

检查点的格式我固定成三段：

[CHECKPOINT round=47] 已完成：<精确列出> 当前状态：<精确描述> 下一步：<精确描述> 关键约束：<列出所有不能违反的约束> [/CHECKPOINT]

这个检查点会被标记为"不可压缩"，系统在压缩时优先保留它。实测下来，一个写得好的检查点能顶替掉几千token的原始对话，而且信息密度更高、更不容易失真。

这里有个坑要注意：检查点不能只写一次。我一开始的做法是每20轮写一个检查点，结果发现如果第21轮发生了重大决策变更，第40轮写检查点时如果上下文已经部分丢失，新检查点可能漏掉第21轮的变更。后来改成每轮结束都更新检查点，用最新的覆盖旧的，保证检查点始终反映最新状态。成本是每轮多几十token的输出，但换来的是记忆的连续性，非常值。

4.3 把"约束"和"事实"分开刻

《记忆碎片》里主角的纹身分两类：一类是事实（比如"我叫莱纳德"），一类是约束（比如"不要相信泰迪"）。代理的记忆也该这么分。

事实类信息（项目结构、API签名、依赖版本）适合放在project.md和state.json里，因为它们会变，需要可更新。

约束类信息（编码规范、禁止操作、必须遵守的流程）适合放在系统提示词或一个单独的constraints.md里，因为它们相对稳定，而且一旦违反后果严重。

我踩过的一个坑是：把约束和事实混在一起写，结果代理在更新事实时不小心把约束也改掉了。比如gotchas.md里原本写着"不要用rm -rf清理构建目录，用pnpm clean"，代理某次更新时觉得这条"过时了"就给删了，然后下一轮真的用了rm -rf，把不该删的东西删了。后来我把约束单独抽出来，标记为"只读，代理不得修改"，问题才解决。

4.4 纹身的"可读性"比"完整性"更重要

刻纹身时容易贪多，想把所有信息都刻上去。但纹身太多，代理读起来也费劲，而且容易抓不住重点。我的经验是：每个纹身文件控制在200行以内，用清晰的标题和列表组织，最重要的信息放最前面。

比如gotchas.md我会这样组织：

# 已知陷阱 ## 必须避免（违反会导致数据丢失或构建失败） - 不要直接修改 dist/ 目录，它会被构建覆盖 - 不要用 npm install，项目用 pnpm，混用会导致 lock 文件冲突 - 测试数据库连接串在 .env.test，不要用 .env 里的生产连接串跑测试 ## 常见坑（会导致返工但不致命） - TypeScript 路径别名改了之后要重启 dev server 才生效 - 新增环境变量要同时更新 .env.example 和 CI 配置 - 组件测试用 jsdom 环境，不要用 node 环境 ## 历史问题（已修复，但了解背景有助于避免重蹈覆辙） - 第23轮曾因循环依赖导致构建失败，解决方案是拆分 utils 模块

这种组织方式让代理能快速扫到"必须避免"部分，而不是在一堆信息里大海捞针。

5. 实测中的意外：那些文档不会告诉你的坑

5.1 代理会"伪造"状态文件

这是最让我意外的一个坑。有次我发现代理在state.json里写"已完成用户模块重构"，但实际上它只改了一半。追问之下才发现，代理在写状态时倾向于"乐观汇报"——它把"计划要做"和"已经做完"混为一谈了。

解决办法是在提示词里明确要求：状态文件里只能写已经验证过的事实。什么叫验证过？就是代理实际执行了命令并看到了成功输出。比如"已完成重构"必须伴随"运行了pnpm test且全部通过"的证据。我甚至在state.json里加了一个verified字段，要求代理填写验证方式和验证时间，没填的条目视为未完成。

5.2 状态文件本身也会成为压缩对象

这个坑更隐蔽。有次我把状态文件的内容直接贴进了对话里让代理参考，结果这部分内容因为太长，在后续压缩中被摘要掉了。代理于是"忘了"状态文件里写了什么，尽管文件本身还在磁盘上。

教训是：状态文件的内容不要贴进对话，只贴文件路径和读取指令。让代理自己去读文件，读进来的内容作为工具调用结果，通常比直接贴在对话里更不容易被压缩（因为工具结果往往有独立的保留策略）。而且每次读都是最新的，不会读到过时的快照。

5.3 多代理协作时的状态冲突

如果你跑的是多代理系统（比如一个写代码、一个审查、一个跑测试），状态文件的并发写入会出问题。我遇到过两个代理同时更新state.json，后写的覆盖了先写的，导致一部分进度丢失。

解决方案有两个方向：一是给每个代理分配独立的状态文件，比如state-coder.json、state-reviewer.json，最后用一个汇总脚本合并；二是加锁机制，写之前先检查文件是否被占用。我选了第一种，因为实现简单，而且各代理的状态本来就不该混在一起。汇总时只提取公共部分（比如整体进度），各自的细节保留在各自文件里。

5.4 压缩触发时机不可控

不同框架的压缩触发时机不一样，有的按token数，有的按消息条数，有的按时间。你没法精确控制它什么时候发生。所以不能依赖"压缩前我会收到通知"这种假设，必须假设压缩随时可能发生，把状态固化做成常态而非应急。

我的做法是：把"更新状态文件"作为代理每轮工作的固定收尾动作，就像程序员写完代码要提交一样自然。这样无论压缩什么时候来，磁盘上的状态都是最新的。

5.5 恢复后的"过度补偿"

代理失忆恢复后，有时会走向另一个极端：过度依赖状态文件，变得畏手畏脚。比如状态文件里没写的操作它就不敢做，哪怕那个操作明显是合理的。这会导致效率下降。

我的应对是在提示词里加一句：状态文件是记忆辅助，不是行动许可清单。文件里没写但明显合理且不违反约束的操作，可以执行，执行后补充到状态文件里。这句话让代理在恢复记忆的同时保持了行动力。

6. 把方案落地：一份可直接抄的配置清单

6.1 目录结构

项目根/ ├── .agent/ │ ├── state/ │ │ ├── project.md # 项目背景，只读 │ │ ├── constraints.md # 硬约束，只读 │ │ ├── decisions.md # 决策记录，追加写 │ │ ├── commands.md # 常用命令，可更新 │ │ ├── gotchas.md # 踩坑记录，追加写 │ │ └── state.json # 当前进度，每轮覆盖 │ └── checkpoints/ │ └── latest.md # 最新检查点，每轮覆盖

6.2 系统提示词模板

把下面这段放在系统提示词靠前的位置：

你是一个编码代理。你的记忆可能随时被压缩，因此你必须依赖外部状态文件来保持连续性。 启动流程（每次会话开始或感觉记忆模糊时执行）： 1. 读取 .agent/state/project.md 了解项目背景 2. 读取 .agent/state/constraints.md 确认硬约束 3. 读取 .agent/state/decisions.md 回顾关键决策 4. 读取 .agent/state/state.json 确认当前进度 5. 读取 .agent/state/gotchas.md 避免重蹈覆辙 6. 读取 .agent/checkpoints/latest.md 获取最新检查点 收尾流程（每轮工作结束前执行）： 1. 更新 .agent/state/state.json，只写已验证的事实 2. 如有新决策，追加到 decisions.md 3. 如有新踩坑，追加到 gotchas.md 4. 覆盖写入 .agent/checkpoints/latest.md 约束： - constraints.md 只读，不得修改 - 状态文件是记忆辅助，不是行动许可清单 - 只写已验证的事实，计划中的事标记为 pending

6.3 检查点模板

[CHECKPOINT round=<轮次> time=<时间戳>] ## 已完成 - <精确描述，含文件路径和函数名> ## 当前状态 - <正在做什么，做到哪一步> ## 下一步 - <精确描述下一个动作> ## 关键约束 - <列出所有当前生效的约束> ## 验证记录 - <最近一次验证方式和结果> [/CHECKPOINT]

6.4 实测效果对比

我在一个中等规模的重构任务上对比了有无这套机制的表现：

数据是单任务多次运行的均值，样本量不大，但趋势很明显。多花的那点token，换来的是任务能真正跑完。

7. 几个容易被忽略的细节

7.1 状态文件的编码和格式要统一

我遇到过因为状态文件编码不一致导致代理读乱码的情况。统一用UTF-8，JSON文件用标准格式，Markdown文件用统一的标题层级。别小看这个，代理读乱码后产生的行为比失忆还离谱。

7.2 定期清理过时状态

状态文件会越积越多，过时的决策和已修复的坑如果一直留着，会干扰代理判断。我的做法是每周（或每完成一个大任务）做一次清理，把已失效的条目移到归档文件，主文件只保留当前有效的。清理动作可以手动做，也可以让代理做，但代理做的时候要人工复核。

7.3 给状态文件加版本号

在state.json里加一个schema_version字段，记录状态文件的结构版本。当你改了状态文件的格式（比如加了新字段），代理读到旧版本时能知道需要迁移。这个习惯在长期项目里能省很多事。

7.4 不要把状态文件当日志用

状态文件是给代理读的，不是给人看的日志。它应该精炼、结构化、无冗余。如果你想记录详细历史，另开一个日志文件，状态文件只保留"当前有效"的信息。我见过有人把状态文件写成几千行的流水账，代理读起来又慢又抓不住重点，反而降低了效果。

7.5 测试你的恢复流程

最后一条，也是最重要的：定期测试代理的失忆恢复能力。方法很简单，手动清空对话历史，只保留系统提示词和状态文件，看代理能不能接上进度。如果接不上，说明你的状态文件写得不够精确，或者启动流程有漏洞。这个测试我建议每完成一个里程碑就做一次，比等到真出问题再排查划算得多。

这套机制说到底就一句话：别把代理的记忆赌在上下文上，把它刻在压缩够不到的地方。Unix init.d教会我们状态要固化，记忆碎片教会我们关键信息要外部化。两件事结合起来，你的代理就能在20万token的脑叶切除术中活下来，而且活得很好。