企业官网建设流程全解析

1. 当上下文被压缩到只剩骨架，代理为什么还会失忆

做过长会话 AI 编码代理的人，大概都经历过这种诡异场景：明明前面几十轮对话里已经把项目结构、接口约定、命名规范讲得清清楚楚，代理也照着做了，可一旦上下文窗口逼近上限、系统触发压缩，它就像被人做了一次脑叶切除——之前那些"约定"全没了，开始重新发明轮子，甚至把已经改好的文件又改回去。

我最初以为是模型能力问题，换更大的模型、调更高的温度、加更长的系统提示，折腾了一圈才发现，根子不在模型，而在上下文压缩机制本身。压缩的本质是"丢信息换空间"，它会把早期对话摘要化、把工具调用结果截断、把文件内容折叠成一句"用户曾查看过某文件"。对聊天机器人来说这没什么，但对一个需要持续维护代码状态的编码代理来说，这等于把它的长期记忆直接切掉了。

标题里提到的"20 万 token 脑叶切除术"，说的就是这个临界点：当会话累积到 20 万 token 量级，压缩策略开始激进介入，代理的行为一致性断崖式下跌。而"Unix init.d"和"《记忆碎片》"这两个看似不搭界的东西，恰恰是我用来对抗这种失忆的两把钥匙——一个负责把关键状态固化成可重新加载的服务，一个负责用倒叙碎片重建代理的自我认知。下面我把整套思路拆开讲，包括为什么这么设计、具体怎么落地、以及实测中踩过的坑。

这套方案适合谁？如果你正在做长周期 AI 编码代理、多轮工具调用编排，或者任何需要跨压缩边界保持状态一致性的 Agent 系统，那这篇内容基本可以直接抄作业。如果你只是偶尔用用对话式编程，可能感受没那么深，但里面关于"状态外置"的思路同样值得借鉴。

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

2.1 压缩不是均匀裁剪，而是有偏丢弃

很多人以为上下文压缩就是"把老的对话删掉"，其实远不止。主流压缩策略大致分三类：滑动窗口、摘要折叠、重要性打分。滑动窗口最粗暴，直接砍掉最早的 N 轮；摘要折叠会把一段对话用模型重新总结成几句话；重要性打分则试图保留"关键信息"。

问题在于，这三种策略对编码代理都不友好。滑动窗口会砍掉项目初始化时定的规范；摘要折叠会把"函数签名必须用 snake_case"这种硬约束总结成"用户提到了一些命名偏好"，约束强度直接归零；重要性打分更玄学，它判断重要性的依据往往是语义显著性，而不是工程约束性——一段啰嗦但包含关键路径的调试记录，很可能被打成低分丢掉。

我做过一个可复现的实验：让代理连续完成 30 个文件的重构任务，每个任务都依赖前面定义的接口约定。跑到第 18 个任务左右，上下文逼近压缩阈值，代理开始出现三类典型症状：

• 约定漂移：原本统一的错误码格式从ERR_XXX变成ErrorXXX，再变成error_xxx。
• 重复劳动：把第 5 个任务已经重构过的模块又改了一遍，理由是"发现命名不一致"。
• 幻觉引用：引用一个根本不存在的工具函数，因为它"记得"前面定义过，其实那段记忆已经被压缩掉了。

这三类症状的共同点是：代理丢失的不是知识，而是状态。它知道怎么写代码，但不知道"当前项目处于什么状态、已经约定了什么"。

2.2 为什么加大窗口治标不治本

第一反应肯定是"那就别压缩，把窗口开到最大"。我试过，把窗口从 20 万拉到 100 万，失忆点确实往后推了，但只是推迟，没有消除。原因有两个：一是成本，长上下文每次推理的 token 消耗是线性甚至超线性增长的，跑几十轮下来账单很难看；二是注意力稀释，即使窗口够大，模型对早期内容的注意力权重也会衰减，20 万 token 之前定的规范，到 80 万 token 时模型基本"看得到但用不上"。

所以正确的思路不是"避免压缩"，而是"让压缩变得无害"。既然压缩一定会丢信息，那就把不能丢的信息放到压缩够不着的地方——这就是 init.d 思路的起点。

3. 把代理状态做成 init.d 服务：状态外置的核心设计

3.1 为什么是 init.d，而不是简单的配置文件

Unix 的 init.d 机制有个精髓：服务是幂等的、可重新加载的、有明确生命周期的。系统启动时按顺序拉起服务，服务崩溃了可以重启，配置改了可以 reload，而不需要重启整个系统。

我把这个模型搬到代理状态管理上：不再指望代理"记住"项目约定，而是把约定写成一个可被代理随时重新加载的状态服务。具体来说，在项目根目录维护一个.agent/state/目录，里面按职责拆成几个文件：

• conventions.state：命名规范、错误码格式、目录结构约定。
• interfaces.state：已定义的接口签名、数据结构。
• progress.state：已完成的任务、当前进行中的任务、待办。
• decisions.state：关键技术选型及其理由。

关键在于，这些文件不是给人类看的文档，而是代理在每次关键操作前必须重新读取的状态源。代理不需要"记住"它们，只需要知道"它们在哪、什么时候读"。

3.2 状态服务的加载协议

光有文件不够，得有加载协议。我设计了一个极简的三段式协议，代理在每轮任务开始和结束时各执行一次：

# 任务开始：加载状态 cat .agent/state/conventions.state cat .agent/state/interfaces.state cat .agent/state/progress.state # 执行任务... # 任务结束：回写状态 # 把本轮新增的约定、接口、进度追加到对应文件

看起来简单到有点傻，但效果立竿见影。因为状态不再依赖上下文记忆，而是依赖文件系统。压缩可以砍掉对话历史，但砍不掉磁盘上的文件。代理每次"醒来"第一件事就是重新读状态，相当于每次失忆后都能靠外部记忆恢复。

这里有个容易忽略的细节：回写必须是追加而非覆盖。我一开始图省事让代理直接重写整个 state 文件，结果它经常"忘记"之前的内容，把文件写成了只有当前任务的状态。改成追加模式后，历史状态被完整保留，代理即使压缩后也能看到完整的演进轨迹。

3.3 幂等性：让重复加载不产生副作用

init.d 服务的另一个特性是幂等——重复执行不会产生额外副作用。这一点在代理场景里至关重要，因为代理可能因为压缩、重试、异常恢复等原因多次加载同一份状态。

我的做法是给每个 state 文件加一个版本号和校验和：

# conventions.state version: 7 checksum: a3f9... --- - 命名: snake_case - 错误码: ERR_<MODULE>_<CODE> ...

代理加载时先比对版本号，如果版本没变就跳过解析，直接复用内存中的状态。这样即使一小时内加载了 50 次，也不会因为重复解析导致状态错乱。校验和则用来检测文件是否被意外篡改——实测中确实出现过代理误写 state 文件的情况，校验和不匹配时直接拒绝加载并告警，比默默用错状态强得多。

4. 《记忆碎片》式倒叙：用碎片重建代理的自我认知

4.1 正序记忆为什么在压缩下必然崩溃

init.d 解决了"硬状态"的问题，但代理还有"软状态"——它对自己"正在做什么、为什么这么做"的认知。这部分很难用结构化文件表达，因为它涉及意图、上下文、权衡。

正序记忆的脆弱性在于：它依赖时间连续性。代理需要记得"我先做了 A，因为 B，所以现在要做 C"。一旦中间某段被压缩掉，因果链就断了，代理会做出看似合理但实际矛盾的决定。

《记忆碎片》这部电影给了我启发：主角只有短期记忆，但他靠倒叙的碎片——纹身、照片、笔记——重建自己的目标。每一块碎片都是独立的、自包含的，不依赖前后顺序。代理的软状态也可以这样组织。

4.2 把每轮任务写成自包含的"记忆碎片"

具体做法是：每完成一轮任务，就让代理生成一条自包含的记忆碎片，格式固定，包含五个字段：

[碎片 #42] 目标: 重构 user 模块的错误处理 依据: conventions.state v7 的错误码规范 动作: 替换了 12 处 raise 语句 结果: 测试通过，但 auth 模块出现 3 处不兼容 下一步: 检查 auth 模块的错误码引用

关键在于"自包含"——每条碎片单独看都能理解，不需要读前面的碎片。这样即使压缩把碎片 #1 到 #30 全砍了，代理读到 #42 时依然知道"当前在重构错误处理，auth 模块有问题"。

我把这些碎片存在.agent/memory/目录下，按时间倒序排列（最新的在最前）。代理每次恢复时，先读最新的 5 条碎片，就能重建出"最近在干什么"的认知。这比读完整对话历史高效得多，也更抗压缩。

4.3 碎片之间的交叉引用

纯倒叙有个问题：碎片多了之后，代理可能不知道某条碎片和哪条相关。我加了一层轻量交叉引用——每条碎片可以引用之前的碎片编号：

[碎片 #42] ... 关联: #38 (auth 模块接口变更), #40 (错误码规范更新)

这样代理读到 #42 时，如果对 #38 的内容有疑问，可以按编号去读 #38。引用是显式的、可追溯的，不依赖模型的模糊记忆。实测下来，这层引用让代理在处理跨模块任务时的连贯性提升了非常明显——它不再"忘记"某个改动会影响另一个模块。

5. 两套机制如何协同：一次完整的抗压缩任务流

5.1 任务启动阶段的加载顺序

把 init.d 和记忆碎片结合起来，一次完整的任务流是这样的。代理被唤醒后，按固定顺序执行：

1. 读.agent/state/下所有 state 文件，重建硬状态（约定、接口、进度）。
2. 读.agent/memory/下最新 5 条碎片，重建软状态（最近意图、待办）。
3. 比对 state 版本号和碎片时间戳，如果发现不一致（比如 state 更新了但碎片没跟上），先做一次状态对齐。
4. 才开始执行当前任务。

这个顺序不能乱。我试过先读碎片再读 state，结果代理经常被碎片里的旧约定误导——碎片是某个时间点的快照，而 state 是最新的权威源。state 优先于碎片，这是铁律。

5.2 任务执行中的状态检查点

任务执行到一半，如果上下文又逼近压缩阈值怎么办？我的做法是设置状态检查点：每完成一个子步骤，就强制回写一次 state 并生成一条碎片。这样即使下一秒就被压缩，损失也仅限于当前子步骤。

检查点的触发条件我设了两个：一是 token 消耗达到阈值的 70%，二是子步骤完成。前者是预防性触发，后者是常规触发。实测中，70% 这个阈值比较合适——太早触发会频繁打断任务流，太晚则来不及保存。

5.3 任务结束后的状态固化

任务结束后，代理必须做三件事：更新 progress.state、追加新的 conventions/interfaces（如果有）、生成最终碎片。这三件事做完，才算一次完整的任务闭环。

这里有个坑：代理经常偷懒，觉得"这次改动很小，不用记"。结果下次压缩后，这个小改动就成了悬案。我的对策是把状态固化做成硬性检查——如果代理没更新 state，下一次加载时会检测到 progress 和实际文件状态不一致，直接拒绝继续任务并要求先对齐。用机制逼着它记录，比靠自觉靠谱得多。

6. 实测中的意外与踩坑记录

6.1 state 文件膨胀导致加载变慢

跑了大概两周后，progress.state膨胀到了几千行，每次加载要好几秒。代理虽然不抱怨，但任务启动延迟肉眼可见。我的解决办法是分层归档：把 30 天前的进度归档到progress.archive.state，主文件只保留近期内容。归档文件不参与常规加载，只在需要追溯历史时按需读取。

6.2 碎片编号冲突

多代理并行时，碎片编号会冲突——两个代理同时生成 #42。我一开始用时间戳做编号，结果可读性太差。后来改成"代理ID-序号"的格式，比如A-042、B-042，既避免冲突又保留可读性。如果你的场景是单代理，这条可以忽略。

6.3 压缩后代理"过度依赖"外部状态

有个反直觉的坑：状态外置做得好之后，代理变得过度依赖外部状态，连一些本该从当前对话就能推断的信息也要去读文件。这导致每轮任务的文件读取次数暴增。我的调整是给状态加载加一个"最小必要"原则——只加载当前任务直接相关的 state 文件，而不是全量加载。比如做前端任务时，后端接口的 state 可以延迟加载。

6.4 校验和误报

校验和机制偶尔会误报，原因是代理在回写时用了不同的换行符（\nvs\r\n）。这个坑很隐蔽，排查了半天。解决办法是在计算校验和前统一做换行符归一化。如果你也打算上校验和，记得先处理这个。

7. 什么场景值得上这套方案，什么场景别折腾

这套方案不是银弹，它有明确的适用边界。我按自己的经验给个判断标准：

判断的核心就一条：你的任务是否需要在压缩边界之后仍然保持一致性。如果是，那这套 init.d + 记忆碎片的组合基本能解决问题；如果不是，老老实实用简单方案，别为了架构而架构。

我个人在实际操作中的体会是，这套方案最大的价值不在于"让代理记住更多"，而在于把"记忆"从不可控的模型内部，转移到了可控的文件系统。模型会失忆，磁盘不会。只要状态在磁盘上，代理每次醒来都能靠重新加载恢复认知。至于《记忆碎片》那套倒叙碎片，本质上是给"软状态"找了个抗压缩的容器——它不追求完整，只追求每块碎片都能独立成立。

最后分享一个小技巧：如果你刚开始搭这套机制，别一上来就搞全套。先只做conventions.state一个文件，跑一周看看代理的约定漂移有没有改善。有改善再加 interfaces 和碎片。渐进式落地比一次性上全套更容易发现哪部分真正起作用，也更容易在出问题时定位。