被 20 万 token 的上下文窗口骗惨了。我在一个跨平台小工具的编码会话里跑到了接近 20 万 token，原以为这么大的窗口足够把项目全貌“背下来”。结果上下文压缩机制一启动，编码代理就像刚被做了一场“脑叶切除术”，上一轮刚确认过的文件路径、变量命名、设计取舍全部消失。它甚至开始一本正经地建议我新建一个已经存在的函数，那一刻我意识到：大模型的所谓“记忆”，很多时候只是临时贴在对话里的便利贴，压缩一来，便利贴就被撕掉了。后来我用 Unix init.d 的启动脚本机制，加上电影《记忆碎片》里主角那套“外部线索”策略，给编码代理搭了一套对上下文压缩近乎免疫的工作流。效果出乎意料地好，最近几个长会话项目再也没出现过“代理论证一半突然失忆”的崩溃场面。这篇就完整记录一下我的思路、落地步骤，以及踩过的坑。1. 失忆现场：20 万 token 看起来很大，压缩一启动照样“脑叶切除”1.1 上下文压缩是怎么发生的很多人的错觉是：上下文窗口有 20 万 token，那我只要把所有资料都塞进去，模型就能一直记住。实际上窗口大小只代表“最多能放多少 token”，并不代表“模型能稳定利用这么多 token”。我的实际体验里，上下文压缩至少来自三个层面。第一是显式的摘要压缩：当会话长度超过某个阈值，系统会把早期对话浓缩成一段摘要，原始细节直接消失。第二是隐式的注意力稀释：模型在处理长上下文时，对中间位置的信息注意力权重天然偏低，放在第 3 万 token 处的一条关键约定，很可能根本没进入模型的“决策视野”。第三是工具侧的截断：很多编码代理会在请求超过预算时静默丢弃前面的内容，只保留最近几轮。这三类情况有个共同点：它们都发生在你看不见的地方。你以为模型还记得，其实它已经只剩一段模糊的“大概意思”。1.2 失忆的三种典型症状我总结了编码代理在压缩后最典型的三种“临床反应”：路径失忆：它上一秒还在修改src/lib/queue.py，压缩后却声称“项目里似乎没有这个文件”，继而建议新建一个同名文件，差点造成重复实现。约定失忆：说好接口参数用驼峰命名，压缩后它又按默认的下划线命名写出一堆新代码，风格瞬间撕裂。决策反复：前面几轮刚拍板“不用数据库，用 JSON 文件持久化”，压缩后它又一本正经地分析引入数据库的好处，把已经消耗过的讨论重新来一遍。这种症状最伤效率的地方不是单个错误，而是它会破坏你和代理之间的连续工作状态。你不得不在每次压缩后花大量时间“重新哄它想起之前的一切”，长久下来，长上下文反而变成了短上下文。2. 记忆外化的两个师傅：init.d 的系统重启逻辑与《记忆碎片》的便签策略2.1 从 init.d 学到的第一课：重启后靠脚本重建服务Unix 系统的 init.d 机制给了我第一个启发。早期 Linux 在系统启动时，会扫描/etc/init.d目录，按文件名顺序执行里面的脚本，每个脚本负责拉起一个服务。开机那一刻，系统没有“上一分钟的记忆”，它只是老老实实运行脚本，从配置文件和二进制程序里恢复出整个运行时环境。这个思路放在编码代理身上就是：每次新开会话，或者上下文被压缩后，代理都应该像开机一样，按固定顺序读取一系列外部文件，从零重建自己的“项目认知”。它不需要在上下文里保存几十万字的历史会话，只需要知道从哪里读取“启动脚本”。我把这个机制称为“代理重启仪式”。核心原则很简单：一切重要信息都放在磁盘上，而不是放在对话里。会话上下文是易失性存储器，断电就丢；文件系统才是持久化存储。2.2 从《记忆碎片》学到的第二课：给“失忆者”留纹身和便签《记忆碎片》里主角的情况更极端，他只有几分钟的短期记忆，但依然能完成复杂任务，靠的不是努力记住，而是一套极端的外部记忆系统：把关键事实纹在身体上，用拍立得照片记录当前进展，在纸条上写给未来的自己。这套策略映射到 AI 编码代理上非常精准：纹身：项目里不可变的硬规则，比如架构选型、命名规范、强制约定。要纹在皮肤上，让代理每次都能看到。拍立得照片：关键决策的快照，每个重要岔路口选了什么方案，记录下来。纸条：当前状态和下一步计划，每次会话结束时写给下一个会话看。实物线索：文件系统里真实存在的代码、测试、配置文件。代理通过读取这些“实物”来判断当前状态，而不是靠对话里的描述。电影里的主角从来不会试图“提高自己的记忆力”，他做的是“让环境替自己记住”。这个思维的转变对 AI 协作极其关键。2.3 两者的结合：init.d 提供结构，《记忆碎片》提供精神init.d 给了一套清晰的文件组织和加载顺序，让你知道“启动时先读哪个，后读哪个”；《记忆碎片》则提供了一个心理模型：编码代理永远处于“刚刚失忆”的状态，你要做的不是抱怨它记性差，而是像主角一样，把信息变成它视线范围内的线索。我把这套组合方案落成了一个具体的项目目录结构，下一节详细展开。3. 实操：用 .agent/init.d 给代理搭一套“失忆后的重启仪式”3.1 目录结构与文件命名我在每个项目根目录下创建了一个.agent目录，内部结构如下：.agent/ ├── init.d/ │ ├── 00-project.md │ ├── 10-conventions.md │ ├── 20-status.md │ └── 30-glossary.md ├── notes/ │ ├── last-session.md │ └── next-actions.md └── memory/ ├── decisions.md └── debug-log.md用编号前缀是刻意模仿 init.d 的执行顺序。两位数字的排序保证了代理总是先读项目目标，再读规则，然后读当前状态，最后读术语表：00-project.md：项目一句话目标、当前技术栈、核心目录说明。10-conventions.md：代码风格、命名规则、架构约束。这些是“纹身”，通常不允许代理擅自修改。20-status.md：当前正在做什么、做到哪个阶段、最近一次决策。这是“拍立得快照”，需要频繁更新。30-glossary.md：项目里的领域术语和特殊缩写的解释。notes/next-actions.md是给下一次会话的便签，明确写出“接下来应该做什么”。memory/目录则用来沉淀更长的决策记录和排障记录，避免它们污染短小精悍的启动文件。3.2 每次会话启动的“重启仪式”无论新开会话还是上下文被压缩，我都会先让代理执行一段固定的恢复指令。这里有一段我一直在用的提示词模板：你是这个项目的资深工程师。请先执行以下恢复步骤： 1. 依次读取 .agent/init.d/00-project.md、10-conventions.md、20-status.md、30-glossary.md 2. 运行 git log --oneline -10 查看最近的提交历史 3. 运行 git diff HEAD~3 查看最近三笔提交的改动内容 4. 读取 .agent/notes/next-actions.md 完成后，用不超过 10 条列表向我总结你掌握的当前状态， 包括：当前阶段、上一步完成点、下一步行动、应遵守的关键规则。 不要闲聊，不要重复文件内容。这段指令的核心不是让代理“记住”这些文件，而是强制它“重新读取”。哪怕它上一轮的上下文已经被压缩成一团摘要，只要这一轮它真的读过磁盘文件，状态就恢复了。我还会要求代理把读取结果浓缩成 10 条以内的状态摘要。这是为了验证它真的读进去了，而不是象征性打开文件后直接忽略。如果摘要里出现了明显错误，我会先纠正，再让它继续任务。3.3 迭代收尾的“记忆固化”光有启动时的恢复还不够，必须每次迭代结束时把新知识写回外部文件。我在提示词里要求代理在完成一个子任务后，额外执行一次“记忆固化”：本轮任务完成后，请执行以下操作： 1. 更新 .agent/init.d/20-status.md，把“当前阶段”改成最新进度 2. 更新 .agent/notes/next-actions.md，写下下一步要处理的事项 3. 如果出现新的架构决策，追加到 .agent/memory/decisions.md 4. 如果发现关键 bug，追加到 .agent/memory/debug-log.md 更新时保持每个文件不超过 30 行，用简洁的列表描述。有了这个步骤，每次会话结束时，磁盘上的文件都会比开始时多一段“记忆”。下次无论上下文窗口怎么被压缩，代理都能通过读取文件找回全部关键状态。3.4 用 git 提交作为“记忆锚点”除了.agent目录，我还会频繁使用 git 提交作为记忆锚点。每完成一个功能片段，就提交一次，并且把提交信息写得尽量具体，比如“修复导出时文件名冲突，采用前缀参数方案”而不是“fix bug”。原因很简单：git 历史本身就是一份高质量的外部记忆。代理可以通过git log和git diff快速回顾“这个文件为什么长这样”。当上下文压缩发生后，git 历史是少数不会被篡改的真相来源。我把这三件事合起来称为“重启铁三角”：init.d 文件负责项目认知，git 历史负责演化脉络，notes 文件负责下一步动作。三者都放在代理可以直接访问的地方，而不是藏在对话历史里。4. 实测对照：压缩后的代理行为差异，从反复失忆到快速恢复4.1 实验场景设计为了验证这套方案不是心理安慰，我在一个内部练习项目“模拟项目X”上做了对照测试。项目规模不大，约 120 个文件、1.8 万行代码，但会话会持续拉长到接近 20 万 token，中途必然触发上下文压缩。对照组使用传统工作流：把项目说明写在系统提示词里，靠上下文窗口承载历史记忆，没有外部记忆文件。实验组使用.agent/init.d重启仪式，并按前面提到的迭代收尾更新文件。整个测试在一个单独的本地环境里完成，不涉及真实业务数据，结果只是个人观察，但趋势非常明显。4.2 压缩前后的行为差异上下文压缩后，我在同一时间点继续发布任务，要求代理完成一个与当前进度关联的后续功能。对照组的表现如下：把已经存在的src/utils/result.py误判为不存在，想要新建。重新提出数据库选型问题，而这个问题在压缩前已经定性。三次重复修改同一个校验函数，每次改动方向还不一致。需要我把项目背景从头复述一遍才能继续。实验组的表现则稳定得多。压缩发生后，代理先执行重启仪式，读取了00-project.md和20-status.md，明确告诉我“当前正在处理导入失败问题，已确认使用接口熔断方案，下一步是补充重试逻辑”。随后它直接跳出恢复模式，开始处理真正的后续代码，没有一句“我失忆了”。4.3 几个值得记录的数据点观察指标对照组实验组压缩后第一次会话需要我重复背景次数4 次1 次误判文件不存在的次数5 次0 次重复修改同一段逻辑的次数3 次0 次恢复到可继续任务的时间约 12 分钟约 2 分钟这里的“1 次”出现在实验组刚开始接手的首个会话。当时我还没把20-status.md写得足够准确，代理根据旧状态推断方向，走了一小段弯路。修正后，后续所有压缩场景都能在 2 分钟内恢复到工作状态。最让我意外的不是实验组不出错，而是恢复后的“状态质量”反而更高。因为20-status.md是由上一次会话结尾精心总结的，它比杂乱的对话历史更结构化，相当于代理获得了一份比自己记忆更干净的“简报”。5. 避坑：外部记忆系统在真实项目里最容易翻车的五个细节5.1 笔记越长，越容易变成第二个上下文刚开始搭这套系统时，我把所有想记的都往20-status.md里塞，两三轮下来文件超过两百行。结果代理每次读取这个文件几乎占据了整个有效窗口，反而挤占了真正该用的代码分析空间，而且信息越冗长，关键内容越不容易被模型注意到。后来我硬性规定：每个启动文件控制在 30 行以内。具体状态写进notes/next-actions.md，更长的讨论沉淀到memory/，启动文件只保留“当前阶段、上一步、下一步、当前主要决策”四类信息。5.2 把“临时状态”和“永久规则”混在一个文件里这是我觉得最危险的一个错误。代理要分得清“这个世界目前处于什么状态”和“这个世界永远应该怎样”，否则就容易出现：它读了上一轮遗留的阶段性结论，却当成长期约定，之后所有工作都被带偏。解决方法是严格区分文件职能：10-conventions.md是永久规则，作者只能是我，代理无权改动；20-status.md是临时状态，代理每次收尾都可以更新。在提示词里我明确写了“禁止修改 00、10、30 号文件”，相当于把这些文件设为只读纹身。5.3 只让代理读，不让代理写记忆系统只有闭环才有效。如果代理每次启动都能读到状态，但任务结束没有写入最新状态，那么下次启动读到的就是一条过期的旧线索，比没有线索更容易误导。我在每个任务结尾必做一步“强制交还”，先更新状态文件，再让我检查。如果代理直接说“任务完成”但没碰状态文件，我会让它补上更新步骤再去验证代码。宁可慢一分钟，也要保证下一次会话的起点是干净的。5.4 提示词里的“请记住”是弱指令很多同事会习惯性地说“请记住我们用的是单例模式”。对于有即时上下文的短会话，这句话还有效；一旦压缩发生，这句指令就烟消云散。我的改变是：把“请记住”全部替换成“请读取”。“请读取10-conventions.md并确认架构模式” 比 “请记住” 可靠得多。前者是外部存储，后者是内部易失记忆。记住，AI 模型的“内部记忆”本质上是一次性的，跨会话的稳定记忆只存在于外部世界。5.5 状态文件不写“基于哪一笔提交”，过几天就失效.agent/init.d/20-status.md写的是当前状态，但项目代码每天都在变。如果状态文件顶部没有标注“当前基线 commit”，代理读取时可能把旧状态套在新代码上，产生错位。我在 20 号文件的固定模板里加入了更新基线段落：更新于：YYYY-MM-DD 基线版本：commit abc1234每次更新状态文件时，同步更新这两个字段。这样代理既能知道“这些描述基于什么时间点的代码”，也能自行判断当前代码是否已经偏离状态描述。6. 迁移：同一套“外部记忆”策略还能救哪些 AI 长任务场景6.1 长文档写作用 outline 保持主线我在写一个多章节技术手册时也遇到过同样的失忆问题：AI 协作者写着写着就忘了前面的章节约定，人物称呼、术语翻译、排版风格逐渐漂移。我为文档项目搭了一套outline.md和style-guide.md，每次开场先读取，每次写完一节更新大纲，效果和编码场景一样明显。6.2 数据分析用“步骤日志”避免重复清洗做数据分析时，数据清洗往往需要几十个环节。上下文一压缩，AI 可能会忘掉已经做过的过滤条件，重新清洗一遍或者产生不一致的结果。我在工作目录放一个pipeline-log.md，每一步处理的时间、方法、涉及列都写进去，代理每次开始下一阶段前读一遍，完美绕开上下文压缩。6.3 项目会议纪要管理如果 AI 帮你整理会议事项，也可以在项目目录放一个action-items.md，每次会后追加决议和负责人。即使上下文压缩，AI 也能基于最新文件给出准确的跟进建议，而不是凭一段模糊的记忆瞎猜。这个策略本质上是一种通用的人机协作模式：不要试图扩大人工智能的“内部内存”，而是把信息放到它每次都能看到的外部环境里。这套思路放到任何需要多轮协作的 AI 场景都成立。我在实际使用中最大的感受是：上下文窗口越大，越容易让人产生“它肯定记住了”的错觉。但只要经历一次压缩，你就会明白窗口只是缓存，不是记忆。把编码代理想象成一个每隔几分钟就会失忆的老朋友，你自然会养成在它看得见的地方留线索的习惯。现在，我的每个项目在启动时都会经历那套“重启仪式”，而我也很少再被 20 万 token 的“脑叶切除术”打回原形了。
被 20 万 token 的上下文窗口骗惨了。我在一个跨平台小工具的编码会话里跑到了接近 20 万 token，原以为这么大的窗口足够把项目全貌“背下来”。结果上下文压缩机制一启动，编码代理就像刚被做了一场“脑叶切除术”，上一轮刚确认过的文件路径、变量命名、设计取舍全部消失。它甚至开始一本正经地建议我新建一个已经存在的函数，那一刻我意识到：大模型的所谓“记忆”，很多时候只是临时贴在对话里的便利贴，压缩一来，便利贴就被撕掉了。后来我用 Unix init.d 的启动脚本机制，加上电影《记忆碎片》里主角那套“外部线索”策略，给编码代理搭了一套对上下文压缩近乎免疫的工作流。效果出乎意料地好，最近几个长会话项目再也没出现过“代理论证一半突然失忆”的崩溃场面。这篇就完整记录一下我的思路、落地步骤，以及踩过的坑。1. 失忆现场：20 万 token 看起来很大，压缩一启动照样“脑叶切除”1.1 上下文压缩是怎么发生的很多人的错觉是：上下文窗口有 20 万 token，那我只要把所有资料都塞进去，模型就能一直记住。实际上窗口大小只代表“最多能放多少 token”，并不代表“模型能稳定利用这么多 token”。我的实际体验里，上下文压缩至少来自三个层面。第一是显式的摘要压缩：当会话长度超过某个阈值，系统会把早期对话浓缩成一段摘要，原始细节直接消失。第二是隐式的注意力稀释：模型在处理长上下文时，对中间位置的信息注意力权重天然偏低，放在第 3 万 token 处的一条关键约定，很可能根本没进入模型的“决策视野”。第三是工具侧的截断：很多编码代理会在请求超过预算时静默丢弃前面的内容，只保留最近几轮。这三类情况有个共同点：它们都发生在你看不见的地方。你以为模型还记得，其实它已经只剩一段模糊的“大概意思”。1.2 失忆的三种典型症状我总结了编码代理在压缩后最典型的三种“临床反应”：路径失忆：它上一秒还在修改src/lib/queue.py，压缩后却声称“项目里似乎没有这个文件”，继而建议新建一个同名文件，差点造成重复实现。约定失忆：说好接口参数用驼峰命名，压缩后它又按默认的下划线命名写出一堆新代码，风格瞬间撕裂。决策反复：前面几轮刚拍板“不用数据库，用 JSON 文件持久化”，压缩后它又一本正经地分析引入数据库的好处，把已经消耗过的讨论重新来一遍。这种症状最伤效率的地方不是单个错误，而是它会破坏你和代理之间的连续工作状态。你不得不在每次压缩后花大量时间“重新哄它想起之前的一切”，长久下来，长上下文反而变成了短上下文。2. 记忆外化的两个师傅：init.d 的系统重启逻辑与《记忆碎片》的便签策略2.1 从 init.d 学到的第一课：重启后靠脚本重建服务Unix 系统的 init.d 机制给了我第一个启发。早期 Linux 在系统启动时，会扫描/etc/init.d目录，按文件名顺序执行里面的脚本，每个脚本负责拉起一个服务。开机那一刻，系统没有“上一分钟的记忆”，它只是老老实实运行脚本，从配置文件和二进制程序里恢复出整个运行时环境。这个思路放在编码代理身上就是：每次新开会话，或者上下文被压缩后，代理都应该像开机一样，按固定顺序读取一系列外部文件，从零重建自己的“项目认知”。它不需要在上下文里保存几十万字的历史会话，只需要知道从哪里读取“启动脚本”。我把这个机制称为“代理重启仪式”。核心原则很简单：一切重要信息都放在磁盘上，而不是放在对话里。会话上下文是易失性存储器，断电就丢；文件系统才是持久化存储。2.2 从《记忆碎片》学到的第二课：给“失忆者”留纹身和便签《记忆碎片》里主角的情况更极端，他只有几分钟的短期记忆，但依然能完成复杂任务，靠的不是努力记住，而是一套极端的外部记忆系统：把关键事实纹在身体上，用拍立得照片记录当前进展，在纸条上写给未来的自己。这套策略映射到 AI 编码代理上非常精准：纹身：项目里不可变的硬规则，比如架构选型、命名规范、强制约定。要纹在皮肤上，让代理每次都能看到。拍立得照片：关键决策的快照，每个重要岔路口选了什么方案，记录下来。纸条：当前状态和下一步计划，每次会话结束时写给下一个会话看。实物线索：文件系统里真实存在的代码、测试、配置文件。代理通过读取这些“实物”来判断当前状态，而不是靠对话里的描述。电影里的主角从来不会试图“提高自己的记忆力”，他做的是“让环境替自己记住”。这个思维的转变对 AI 协作极其关键。2.3 两者的结合：init.d 提供结构，《记忆碎片》提供精神init.d 给了一套清晰的文件组织和加载顺序，让你知道“启动时先读哪个，后读哪个”；《记忆碎片》则提供了一个心理模型：编码代理永远处于“刚刚失忆”的状态，你要做的不是抱怨它记性差，而是像主角一样，把信息变成它视线范围内的线索。我把这套组合方案落成了一个具体的项目目录结构，下一节详细展开。3. 实操：用 .agent/init.d 给代理搭一套“失忆后的重启仪式”3.1 目录结构与文件命名我在每个项目根目录下创建了一个.agent目录，内部结构如下：.agent/ ├── init.d/ │ ├── 00-project.md │ ├── 10-conventions.md │ ├── 20-status.md │ └── 30-glossary.md ├── notes/ │ ├── last-session.md │ └── next-actions.md └── memory/ ├── decisions.md └── debug-log.md用编号前缀是刻意模仿 init.d 的执行顺序。两位数字的排序保证了代理总是先读项目目标，再读规则，然后读当前状态，最后读术语表：00-project.md：项目一句话目标、当前技术栈、核心目录说明。10-conventions.md：代码风格、命名规则、架构约束。这些是“纹身”，通常不允许代理擅自修改。20-status.md：当前正在做什么、做到哪个阶段、最近一次决策。这是“拍立得快照”，需要频繁更新。30-glossary.md：项目里的领域术语和特殊缩写的解释。notes/next-actions.md是给下一次会话的便签，明确写出“接下来应该做什么”。memory/目录则用来沉淀更长的决策记录和排障记录，避免它们污染短小精悍的启动文件。3.2 每次会话启动的“重启仪式”无论新开会话还是上下文被压缩，我都会先让代理执行一段固定的恢复指令。这里有一段我一直在用的提示词模板：你是这个项目的资深工程师。请先执行以下恢复步骤： 1. 依次读取 .agent/init.d/00-project.md、10-conventions.md、20-status.md、30-glossary.md 2. 运行 git log --oneline -10 查看最近的提交历史 3. 运行 git diff HEAD~3 查看最近三笔提交的改动内容 4. 读取 .agent/notes/next-actions.md 完成后，用不超过 10 条列表向我总结你掌握的当前状态， 包括：当前阶段、上一步完成点、下一步行动、应遵守的关键规则。 不要闲聊，不要重复文件内容。这段指令的核心不是让代理“记住”这些文件，而是强制它“重新读取”。哪怕它上一轮的上下文已经被压缩成一团摘要，只要这一轮它真的读过磁盘文件，状态就恢复了。我还会要求代理把读取结果浓缩成 10 条以内的状态摘要。这是为了验证它真的读进去了，而不是象征性打开文件后直接忽略。如果摘要里出现了明显错误，我会先纠正，再让它继续任务。3.3 迭代收尾的“记忆固化”光有启动时的恢复还不够，必须每次迭代结束时把新知识写回外部文件。我在提示词里要求代理在完成一个子任务后，额外执行一次“记忆固化”：本轮任务完成后，请执行以下操作： 1. 更新 .agent/init.d/20-status.md，把“当前阶段”改成最新进度 2. 更新 .agent/notes/next-actions.md，写下下一步要处理的事项 3. 如果出现新的架构决策，追加到 .agent/memory/decisions.md 4. 如果发现关键 bug，追加到 .agent/memory/debug-log.md 更新时保持每个文件不超过 30 行，用简洁的列表描述。有了这个步骤，每次会话结束时，磁盘上的文件都会比开始时多一段“记忆”。下次无论上下文窗口怎么被压缩，代理都能通过读取文件找回全部关键状态。3.4 用 git 提交作为“记忆锚点”除了.agent目录，我还会频繁使用 git 提交作为记忆锚点。每完成一个功能片段，就提交一次，并且把提交信息写得尽量具体，比如“修复导出时文件名冲突，采用前缀参数方案”而不是“fix bug”。原因很简单：git 历史本身就是一份高质量的外部记忆。代理可以通过git log和git diff快速回顾“这个文件为什么长这样”。当上下文压缩发生后，git 历史是少数不会被篡改的真相来源。我把这三件事合起来称为“重启铁三角”：init.d 文件负责项目认知，git 历史负责演化脉络，notes 文件负责下一步动作。三者都放在代理可以直接访问的地方，而不是藏在对话历史里。4. 实测对照：压缩后的代理行为差异，从反复失忆到快速恢复4.1 实验场景设计为了验证这套方案不是心理安慰，我在一个内部练习项目“模拟项目X”上做了对照测试。项目规模不大，约 120 个文件、1.8 万行代码，但会话会持续拉长到接近 20 万 token，中途必然触发上下文压缩。对照组使用传统工作流：把项目说明写在系统提示词里，靠上下文窗口承载历史记忆，没有外部记忆文件。实验组使用.agent/init.d重启仪式，并按前面提到的迭代收尾更新文件。整个测试在一个单独的本地环境里完成，不涉及真实业务数据，结果只是个人观察，但趋势非常明显。4.2 压缩前后的行为差异上下文压缩后，我在同一时间点继续发布任务，要求代理完成一个与当前进度关联的后续功能。对照组的表现如下：把已经存在的src/utils/result.py误判为不存在，想要新建。重新提出数据库选型问题，而这个问题在压缩前已经定性。三次重复修改同一个校验函数，每次改动方向还不一致。需要我把项目背景从头复述一遍才能继续。实验组的表现则稳定得多。压缩发生后，代理先执行重启仪式，读取了00-project.md和20-status.md，明确告诉我“当前正在处理导入失败问题，已确认使用接口熔断方案，下一步是补充重试逻辑”。随后它直接跳出恢复模式，开始处理真正的后续代码，没有一句“我失忆了”。4.3 几个值得记录的数据点观察指标对照组实验组压缩后第一次会话需要我重复背景次数4 次1 次误判文件不存在的次数5 次0 次重复修改同一段逻辑的次数3 次0 次恢复到可继续任务的时间约 12 分钟约 2 分钟这里的“1 次”出现在实验组刚开始接手的首个会话。当时我还没把20-status.md写得足够准确，代理根据旧状态推断方向，走了一小段弯路。修正后，后续所有压缩场景都能在 2 分钟内恢复到工作状态。最让我意外的不是实验组不出错，而是恢复后的“状态质量”反而更高。因为20-status.md是由上一次会话结尾精心总结的，它比杂乱的对话历史更结构化，相当于代理获得了一份比自己记忆更干净的“简报”。5. 避坑：外部记忆系统在真实项目里最容易翻车的五个细节5.1 笔记越长，越容易变成第二个上下文刚开始搭这套系统时，我把所有想记的都往20-status.md里塞，两三轮下来文件超过两百行。结果代理每次读取这个文件几乎占据了整个有效窗口，反而挤占了真正该用的代码分析空间，而且信息越冗长，关键内容越不容易被模型注意到。后来我硬性规定：每个启动文件控制在 30 行以内。具体状态写进notes/next-actions.md，更长的讨论沉淀到memory/，启动文件只保留“当前阶段、上一步、下一步、当前主要决策”四类信息。5.2 把“临时状态”和“永久规则”混在一个文件里这是我觉得最危险的一个错误。代理要分得清“这个世界目前处于什么状态”和“这个世界永远应该怎样”，否则就容易出现：它读了上一轮遗留的阶段性结论，却当成长期约定，之后所有工作都被带偏。解决方法是严格区分文件职能：10-conventions.md是永久规则，作者只能是我，代理无权改动；20-status.md是临时状态，代理每次收尾都可以更新。在提示词里我明确写了“禁止修改 00、10、30 号文件”，相当于把这些文件设为只读纹身。5.3 只让代理读，不让代理写记忆系统只有闭环才有效。如果代理每次启动都能读到状态，但任务结束没有写入最新状态，那么下次启动读到的就是一条过期的旧线索，比没有线索更容易误导。我在每个任务结尾必做一步“强制交还”，先更新状态文件，再让我检查。如果代理直接说“任务完成”但没碰状态文件，我会让它补上更新步骤再去验证代码。宁可慢一分钟，也要保证下一次会话的起点是干净的。5.4 提示词里的“请记住”是弱指令很多同事会习惯性地说“请记住我们用的是单例模式”。对于有即时上下文的短会话，这句话还有效；一旦压缩发生，这句指令就烟消云散。我的改变是：把“请记住”全部替换成“请读取”。“请读取10-conventions.md并确认架构模式” 比 “请记住” 可靠得多。前者是外部存储，后者是内部易失记忆。记住，AI 模型的“内部记忆”本质上是一次性的，跨会话的稳定记忆只存在于外部世界。5.5 状态文件不写“基于哪一笔提交”，过几天就失效.agent/init.d/20-status.md写的是当前状态，但项目代码每天都在变。如果状态文件顶部没有标注“当前基线 commit”，代理读取时可能把旧状态套在新代码上，产生错位。我在 20 号文件的固定模板里加入了更新基线段落：更新于：YYYY-MM-DD 基线版本：commit abc1234每次更新状态文件时，同步更新这两个字段。这样代理既能知道“这些描述基于什么时间点的代码”，也能自行判断当前代码是否已经偏离状态描述。6. 迁移：同一套“外部记忆”策略还能救哪些 AI 长任务场景6.1 长文档写作用 outline 保持主线我在写一个多章节技术手册时也遇到过同样的失忆问题：AI 协作者写着写着就忘了前面的章节约定，人物称呼、术语翻译、排版风格逐渐漂移。我为文档项目搭了一套outline.md和style-guide.md，每次开场先读取，每次写完一节更新大纲，效果和编码场景一样明显。6.2 数据分析用“步骤日志”避免重复清洗做数据分析时，数据清洗往往需要几十个环节。上下文一压缩，AI 可能会忘掉已经做过的过滤条件，重新清洗一遍或者产生不一致的结果。我在工作目录放一个pipeline-log.md，每一步处理的时间、方法、涉及列都写进去，代理每次开始下一阶段前读一遍，完美绕开上下文压缩。6.3 项目会议纪要管理如果 AI 帮你整理会议事项，也可以在项目目录放一个action-items.md，每次会后追加决议和负责人。即使上下文压缩，AI 也能基于最新文件给出准确的跟进建议，而不是凭一段模糊的记忆瞎猜。这个策略本质上是一种通用的人机协作模式：不要试图扩大人工智能的“内部内存”，而是把信息放到它每次都能看到的外部环境里。这套思路放到任何需要多轮协作的 AI 场景都成立。我在实际使用中最大的感受是：上下文窗口越大，越容易让人产生“它肯定记住了”的错觉。但只要经历一次压缩，你就会明白窗口只是缓存，不是记忆。把编码代理想象成一个每隔几分钟就会失忆的老朋友，你自然会养成在它看得见的地方留线索的习惯。现在，我的每个项目在启动时都会经历那套“重启仪式”，而我也很少再被 20 万 token 的“脑叶切除术”打回原形了。