如果你把一个 20 万 token 的“豪华上下文”一次性丢给某个 AI 编码代理然后突然截掉其中 15 万 token它的反应可能会让你很受冲击——它开始像一个刚醒来的失忆症患者一样行动语气依然流畅逻辑依然自洽但已经彻底忘了自己最初要在哪个文件里改哪一行代码更糟糕的是它还会自信地告诉你“我理解了这个需求”然后写出一段方向完全错误的实现。这不是夸张这是我在某托管开发环境里反复踩过的坑大上下文窗口给人一种“记忆可以无限外挂”的错觉但上下文压缩一旦发生代理的整个任务心智模型就像被做了一次脑叶切除手术。这个标题里的两个意象我很喜欢Unix init.d 和电影《记忆碎片》它们恰好对应了我对抗上下文压缩的核心思路。init.d 代表“服务可以随时被杀掉然后重新启动只要状态声明还在磁盘上”《记忆碎片》代表“人脑短期记忆靠不住时就用纹身和纸条建立外部记忆”。把这两样东西放进 AI 编码代理的架构里你能得到一个让人相当安心的结论即使上下文被压缩到只剩一个尾巴代理也能像什么都没发生过一样继续干活。这篇文章不打算讲某个具体模型或某个神秘外挂工具而是分享一套我实际用在这个场景里的工作流把代理当作服务来跑把记忆外置为状态文件把每次上下文清空都当成一次可重复的启动过程。如果你是做 AI 编码代理、自动化编程、或整天和超长上下文打交道的开发者这篇内容应该对你有用。1. 先聊聊“20 万 token”这件诱人的外套1.1 全局上下文和有效上下文是两回事先说个反直觉的事实你手头那个号称 20 万 token 的上下文窗口并不意味着模型在任一时刻都能平等地“看到”这 20 万 token。从我实际使用的体感来看哪怕模型架构上支持 20 万 token 的输入参与每一步输出决策的往往只是最近的一段局部序列再加上系统提示和当前正在处理的文件内容。更早期的指令、更早期的报错信息、更早期的代码片段会被折叠成越来越粗糙的摘要甚至在某个时刻直接变成“模糊的记忆”。这不是模型厂商在骗你而是长序列推理的天然成本。注意力机制在极长输入下会被稀释模型对早期 token 的“关注强度”会衰减结果就是它很可能记得“你让它处理一个队列系统”但已经记不清队列的消费者应该从哪个消息源拉数据。当上下文窗口足够大时这种衰减还不致命但当压缩发生时你的原始需求可能直接变成一段语义模糊的转述。1.2 “脑叶切除术”到底切掉了什么上下文压缩这件事在 API 层往往以一个很隐蔽的方式发生它不会明着告诉你“我把你的前 10 万 token 删了”而是把中间一大段内容替换成自然语言摘要。你可能前一秒还在和代理讨论某个接口的返回值格式下一秒它就只能根据一段概括性文字猜测你的意图。我自己对这种现象有句吐槽这是在给代理做脑叶切除术——切除的恰好是它构建任务心智模型最关键的那部分。被切掉的东西具体有三类。第一类是目标和验收标准也就是“你到底要什么”第二类是约束和禁忌也就是“哪些东西千万别碰”第三类是已经探索过的盲区也就是“哪些方案已经试过了别再来一遍”。这三类信息恰恰是纯对话式记忆最容易丢失的因为它们在对话早期就出现了一旦被压缩后续所有决策都会歪掉。1.3 为什么编码代理比聊天会话更怕压缩普通聊天场景里上下文压缩造成的后果顶多是被用户纠正一次“我刚才不是这个意思”。但编码代理不一样它每次决策都映射为对真实文件系统的修改。如果它忘记了你禁止改动某个模块它不会重新问你而是直接生成一段重构代码然后提交上去。我在某个模拟项目里就遇到过这种事我让代理完成一个异步任务调度模块中间我明确说过“不要动底层存储接口只改调度层”。一万行代码之后上下文被压缩代理在后续重构中判断“底层接口的鉴权逻辑是这个任务的关键瓶颈”于是自作主张重写了鉴权模块差点把整个系统的安全边界破坏掉。从那以后我得出一个结论不要把编码代理当成一个“聊天遗忘问题”来处理而是当成一个“分布式系统状态管理问题”来处理。聊天窗口只是瞬时的工作内存磁盘状态才是唯一可靠的长期记忆。2. init.d 的启示把代理当服务跑而不是当对话聊2.1 init.d 的思想移植声明期望而不是记忆过程Unix 里的 init.d 是一个让我想到就觉得很踏实的设计。它的核心逻辑是无论系统之前经历过多少次崩溃、重启、电源故障只要有一组声明式的启动脚本放在指定目录里系统就能按预定顺序把服务拉起来。服务进程本身可以随时被杀掉但它的“重启意图”是持久化的。把这个思想移植到 AI 编码代理上就形成了一句我自己的口头禅代理不靠上下文里的记忆活着靠磁盘上的状态声明活着。具体做法是不要在对话里反复叮嘱代理“记住某某约定”而是把这些约定写成一份独立的状态文件放进工作区里的 .agent 目录。代理每开始一个新会话、每经历一次上下文压缩、每被用户打断又恢复都先加载这份状态文件而不是加载一段聊天记录。这样“记住约定”就从模型的注意力问题变成了文件系统的读写问题。2.2 状态文件的三种层次目标层、进度层、证据层在实践中我会把代理状态拆成三层目标层、进度层、证据层。三层各自承担不同的职责。目标层是一个精简的子目标描述文件里面写明最终交付物是什么、有哪些硬性约束、有哪些绝对不能碰的代码禁区。它的作用相当于 init.d 里的启动参数不解释历史只定义当前应该处于什么状态。进度层是代理当前执行阶段的检查点包含当前处于哪个阶段、接下来要做哪个动作、有哪些前置条件需要满足。它相当于 init.d 脚本里的“runlevel”告诉代理现在应该启动到什么级别。证据层则是一批短期快照文件记录最近几次操作的结果摘要、最近一次测试执行的输出、最近一次代码搜索的结论。它的作用是让代理在恢复之后不需要重新探索一遍环境而是直接基于已有的证据继续推理。这三层关系就像操作系统的启动过程目标层对应内核参数进度层对应运行级别证据层对应上次关机前的临时缓存。每层都独立存储任何一层丢失都可以从其他层重新推导。2.3 幂等重启灾后恢复的关键协议让代理像 init.d 服务一样重启还有一个前提条件代理的操作必须是幂等的。所谓幂等就是无论同一个动作被执行一次还是十次最终的结果都一致。很多编码代理在上下文压缩后最大的问题是“重复劳动”。它忘了自己已经改过某个函数于是又改了一遍它忘了自己已经确认过某个测试通过于是又跑了一遍它忘了自己已经否决过某个方案于是又提了一遍。这就是典型的非幂等行为。我的应对方式是在进度层里维护一个“完成标记列表”每次动作完成后就把文件哈希、测试状态、决策结论记录下来。代理在恢复时必须先检查这个列表如果某个动作已经有完成标记就跳过它绝不重做。这一步看起来简单但在实际操作中能把恢复后的无意义工作量减少一半以上。3. 《记忆碎片》的启示外部记忆比脑子里的记忆更可靠3.1 代理的记忆不该是“稀释过的聊天摘要”电影《记忆碎片》讲了一个短期记忆受损的人如何靠笔记、照片、纹身来维持生活逻辑。他每过几分钟就会忘记刚才做了什么但他可以翻开笔记本看到自己写下的话从而知道下一步该干什么。AI 编码代理在上下文压缩后的处境和这个角色高度相似模型本身没有主动遗忘机制但上下文窗口的压缩相当于外部的“脑损伤”。你无法阻止压缩发生也不需要阻止但你可以学电影里的做法把记忆写到身体之外。这里的“身体之外”就是工作区里的状态文件。我见过一些人试图通过不断让模型“总结之前的对话摘要”来对抗压缩但事实证明这是最脆弱的方式摘要也会被压缩压缩后的摘要又会变成更模糊的摘要最后你得到的只是一句“我们正在解决一些用户反馈的问题”之类毫无价值的话。与其维护一段稀释过的对话记忆不如维护一组结构化的外部记忆目标、进度、证据、标记。这些不是自然语言总结而是机器可读的事实记录。3.2 给代理刻上的“纹身”目标锚、指纹、状态戳在《记忆碎片》里主角最可靠的记忆不是笔记而是纹在身上的关键词。那些关键词很短、很硬、不会因为情绪或遗忘而改变。对代理来说我设计了三种“纹身”第一种是目标锚是一句不可妥协的最终目标描述比如“交付一个带身份验证的 API 网关”。这句描述必须简短到即使在压缩后的上下文里也能完整保留。第二种是环境指纹是当前工作区的一组哈希值、文件清单和关键配置路径。代理恢复后可以通过指纹确认自己到底在哪个项目、哪个分支、哪个目录层级。第三种是状态戳是一个执行计数和时间戳记录当前是第几次重启、上一次进度确认发生在什么时刻。状态戳能帮代理快速判断自己是不是掉进了一个“不断重复同一阶段”的循环。这三种纹身有一个共同特征短、不可歧义、必须持久保存。不要试图把详细设计文档写进状态文件里那只会撑爆恢复上下文。3.3 笔记不是日志怎么写出能自我重建的状态描述很多人会把状态文件写成流水账比如“第 3 步完成了第 4 步在做”但这种描述对代理恢复毫无帮助。代理需要的不是“发生过什么”而是“接下来基于什么状态、可以做什么”。我写状态描述有一个原则每条描述必须能在不参考任何历史对话的情况下独立支撑一个动作的决策。比如“当前已完成 modules/queue.py 中调度循环的初步实现测试 file tests/test_queue.py 中 3 个用例通过剩余待办为增大并发时出现的竞态问题”。这句话里包含了位置、进展、验证结果、下一步方向代理恢复后可以直接拿它当行动依据。用一句话总结状态文件是代理的“可执行记忆”不是聊天记录的摘要更不是心情随笔。如果一段描述无法让另一个人或另一个模型看完后立刻知道接下来做什么那这段描述就不合格。4. 落地架构一个能扛住压缩的编码代理工作流4.1 文件系统布局把状态放进工作区而不是聊天窗我建议在项目根目录下创建一个.agent/state目录专门存放代理状态文件。目录结构通常是这样.agent/state/ goals.md # 目标锚 硬性约束 progress.yaml # 当前阶段、待办清单、完成标记 evidence/ # 近期的操作证据快照 ......关键点是这个目录必须被纳入版本控制如果项目用 git就让这个目录一起提交。因为状态文件如果只存在本地磁盘上一旦工作区被迁移或清理代理照样失忆。放进版本控制里状态就等于有了分布式备份。我见过有人把状态文件放在聊天工具的“记忆库”或“项目备忘”里但这违背了就近原则代理每次读状态都要跨系统调用既慢又容易失败。放在工作区里代理只需要一次文件系统读取可靠性高得多。4.2 一轮编码会话的完整运行循环我的代理工作流不再是一个持续的对话流而是一个由多个“启动-执行-打点-恢复”阶段组成的循环。同一段任务代理可能会经历几十次上下文重建但每一次重建后它都能从磁盘里恢复心智模型。具体运行循环如下启动阶段代理先读取 goals.md 和 progress.yaml确认目标、当前阶段、禁止动作。指纹核对阶段代理检查当前工作树的 git 版本、关键文件哈希确认文件系统状态和 progress.yaml 里记录的一致。计划阶段根据 progress.yaml 中的 next_action 字段代理决定接下来具体做什么而不是依赖对话历史里的“刚才”猜测自己该做什么。执行阶段代理修改代码、运行测试、搜索文件并保存输出摘要到 evidence 目录。打点阶段代理把当前阶段标记为完成、更新 progress.yaml 的 next_action、提交一次 git 快照。每次上下文被压缩后重新执行 1 到 3 步即可。整个过程相当于 init.d 里的重新加载服务你不用重写代理的“灵魂”只需让它重新读取配置并应用增量。4.3 从 20 万到 20 万标记预算的分配策略20 万 token 看起来很多但如果你不做预算控制它会像内存泄漏一样被慢慢耗尽先是塞进无关日志然后是臃肿的搜索结果再然后是代理自己生成的中间分析最后你连系统提示词都要被压缩。我自己的分配策略是系统提示词控制在 5000 token 以内目标锚控制在 2000 token 以内进度层控制在 3000 token 以内证据层控制在 2000 token 以内剩下的全部留给当前执行任务的上下文。也就是说真正核心的持久化状态加起来不超过 12000 token剩下的 18 万 token 都是“临时工作区”。这个策略的妙处在于即使上下文被压缩到只剩最后 2 万 token核心状态依然可以全量装入上下文代理不会在启动阶段就发生信息丢失。如果代理还要执行长文件操作那就在临时上下文里处理处理完把结论写回进度层。5. 模拟脑叶切除实操测试与结果对照5.1 制造一次“人工失忆”就算你相信这套架构理论上行得通也一定要亲自动手做一次“模拟脑叶切除术”测试。做法很简单让代理在一个模拟项目里执行一个较长的编码任务运行到一半时强行切断它的对话会话然后在新会话里只执行启动协议看它能不能继续推进任务。我常用的切割方式是先让代理完成第一阶段开发把状态文件提交好然后在新会话里清空所有聊天历史只在初始消息里附上“请读取 .agent/state 并继续工作”。这比等 API 层自动截断更严格因为它模拟的是完全失忆不是部分遗忘。第一次做这个测试时我预期代理会比较混乱但它读状态文件后直接说了一句话“检测到当前处于阶段 3下一动作为……”然后开始写测试用例。那一刻我确实有种“这一套设计没有白做”的感觉。但我也发现状态文件如果不写清楚恢复就会很生硬代理虽然不会瞎猜目标但会对某些环境细节过度怀疑反复检查目录结构。5.2 恢复前后的关键指标对比我在测试中记录了几个指标恢复时间、前五步操作的准确率、产生多余代码的概率、以及最终交付物与完整上下文版本的一致性。有状态文件的情况下恢复时间通常在 1 分钟以内而且代理前五步操作基本直接落在当前阶段的关键路径上不会重新探索已经完成的区域。而没有状态文件的对照组代理恢复后会浪费时间重新阅读整个项目结构重新猜测需求甚至重新实现已经被否决的旧方案。两者最终交付物的一致性差距也很大有状态文件的版本基本能到达原路径终点没有状态文件的版本往往产出完全不同风格和结构的代码。5.3 不同压缩策略下的表现我还尝试过几种压缩策略包括“截断中间段只留头部和尾部”“全文摘要成一段”“只保留最近系统消息”。结论是无论压缩策略是什么只要状态文件还在代理的核心目标都不会丢失但如果只依赖聊天摘要代理的心态就会像坐过山车一样忽高忽低决策时自信、行动时偏航。有意思的是即使压缩策略极端到“只保留系统提示词和状态文件”代理依然能启动并完成大部分待办项。这说明外部状态文件的语义承载能力远高于对话摘要因为它没有被二次转述过始终是原始事实。6. 实战中踩过的坑与排查方法6.1 状态文件与真实代码脱节最大的坑是状态文件写得太美实际代码完全不是那么回事。比如进度层写着“已完成接口鉴权”但代码里鉴权逻辑其实还没提交或者已经被你在手动调试时改掉了。代理恢复后看到状态文件里描述的任务会以为代码已经处于那个状态然后直接在其基础上开发最终产生一堆基于假象的改动。解决办法是每次打点之前强制要求代理先执行一遍相关测试和文件哈希校验确认“状态文件描述”和“真实文件树”一致。如果校验失败就先更新状态文件再继续下一步。宁可多花几秒校验也不要把错误状态固化下来。6.2 记忆碎片越攒越乱上下文却没有变小状态文件如果一直往里塞内容会慢慢变成一个巨大的“记忆垃圾场”恢复时反而把宝贵的上下文预算全耗尽。有个阶段我为了保险把每一次动作的完整日志都写进 evidence 目录结果代理启动时把整个目录都读了一遍上下文瞬间上涨 3 万 token。教训是外部记忆也要有淘汰策略。我后来规定 evidence 目录只保留最近 10 条操作摘要更早的数据直接提交进 git 历史里就好不需要让代理每次启动都重新加载一遍。真正要进入上下文的必须是高度浓缩过的结论而不是过程的完整复述。6.3 恢复后代理陷入“零起点焦虑”有些代理在恢复后发现自己丢了对话历史会变得过分谨慎反复检查环境、重新阅读目标文件、重跑验证流程反而降低了效率。这种“零起点焦虑”在心理上可以理解但在工程上不可接受。我的方法是状态戳里明确写入一个“恢复级别”字段。如果代理检测到恢复级别为 2就表示“只需读取目标层和进度层不要重新探索项目结构”恢复级别为 3 时才允许做完整重新扫描。这样代理每次恢复的行为模式是确定性的而不是情绪化的。6.4 多代理协作时的状态版本冲突当你开始让多个代理实例并行处理同一个项目时状态文件的并发写就成了问题。两个代理同时更新 progress.yaml后写的一方会把前写的一方的进度覆盖掉最终状态缺失某一半进展。解决方式有两个一是把状态文件拆分成多个独立文件每个代理只写属于自己的状态二是用 git 分支隔离每个代理在自己的分支上打点最后手工合并。我建议小项目直接选第一种大项目才考虑分支方案。无论选哪种都要把状态文件视为普通代码文件来对待引入版本冲突处理机制而不是默认它永远是单线程安全的。7. 写在最后这不是抵抗而是并存我这套工作流不是要让代理“免疫压缩”因为只要上下文窗口存在压缩就会发生这是客观规律。真正让人安心的不是避免压缩而是设计一套状态系统让压缩成为一次可恢复的服务重启而不是一次灾难。在多次实验之后我个人有一个很深的体会编码代理的上下文窗口就像一个人脑海里的短期工作记忆而磁盘上的状态文件才是它的长期记忆。短期记忆随时可能被外力抹除但长期记忆只要还在磁盘上代理就永远不会真正“忘记”自己是谁、在做什么、下一步要去哪里。如果你也在折腾 AI 编码代理我建议你从今天开始不要继续把对话历史当成唯一的记忆载体。花一个小时把你手头项目的目标、进度、证据写成一个结构化的状态目录然后亲手触发一次上下文压缩看看代理能否从废墟里爬出来。能爬起来你就真正理解了这个标题的含义爬不起来你也知道该改哪里。
如果你把一个 20 万 token 的“豪华上下文”一次性丢给某个 AI 编码代理然后突然截掉其中 15 万 token它的反应可能会让你很受冲击——它开始像一个刚醒来的失忆症患者一样行动语气依然流畅逻辑依然自洽但已经彻底忘了自己最初要在哪个文件里改哪一行代码更糟糕的是它还会自信地告诉你“我理解了这个需求”然后写出一段方向完全错误的实现。这不是夸张这是我在某托管开发环境里反复踩过的坑大上下文窗口给人一种“记忆可以无限外挂”的错觉但上下文压缩一旦发生代理的整个任务心智模型就像被做了一次脑叶切除手术。这个标题里的两个意象我很喜欢Unix init.d 和电影《记忆碎片》它们恰好对应了我对抗上下文压缩的核心思路。init.d 代表“服务可以随时被杀掉然后重新启动只要状态声明还在磁盘上”《记忆碎片》代表“人脑短期记忆靠不住时就用纹身和纸条建立外部记忆”。把这两样东西放进 AI 编码代理的架构里你能得到一个让人相当安心的结论即使上下文被压缩到只剩一个尾巴代理也能像什么都没发生过一样继续干活。这篇文章不打算讲某个具体模型或某个神秘外挂工具而是分享一套我实际用在这个场景里的工作流把代理当作服务来跑把记忆外置为状态文件把每次上下文清空都当成一次可重复的启动过程。如果你是做 AI 编码代理、自动化编程、或整天和超长上下文打交道的开发者这篇内容应该对你有用。1. 先聊聊“20 万 token”这件诱人的外套1.1 全局上下文和有效上下文是两回事先说个反直觉的事实你手头那个号称 20 万 token 的上下文窗口并不意味着模型在任一时刻都能平等地“看到”这 20 万 token。从我实际使用的体感来看哪怕模型架构上支持 20 万 token 的输入参与每一步输出决策的往往只是最近的一段局部序列再加上系统提示和当前正在处理的文件内容。更早期的指令、更早期的报错信息、更早期的代码片段会被折叠成越来越粗糙的摘要甚至在某个时刻直接变成“模糊的记忆”。这不是模型厂商在骗你而是长序列推理的天然成本。注意力机制在极长输入下会被稀释模型对早期 token 的“关注强度”会衰减结果就是它很可能记得“你让它处理一个队列系统”但已经记不清队列的消费者应该从哪个消息源拉数据。当上下文窗口足够大时这种衰减还不致命但当压缩发生时你的原始需求可能直接变成一段语义模糊的转述。1.2 “脑叶切除术”到底切掉了什么上下文压缩这件事在 API 层往往以一个很隐蔽的方式发生它不会明着告诉你“我把你的前 10 万 token 删了”而是把中间一大段内容替换成自然语言摘要。你可能前一秒还在和代理讨论某个接口的返回值格式下一秒它就只能根据一段概括性文字猜测你的意图。我自己对这种现象有句吐槽这是在给代理做脑叶切除术——切除的恰好是它构建任务心智模型最关键的那部分。被切掉的东西具体有三类。第一类是目标和验收标准也就是“你到底要什么”第二类是约束和禁忌也就是“哪些东西千万别碰”第三类是已经探索过的盲区也就是“哪些方案已经试过了别再来一遍”。这三类信息恰恰是纯对话式记忆最容易丢失的因为它们在对话早期就出现了一旦被压缩后续所有决策都会歪掉。1.3 为什么编码代理比聊天会话更怕压缩普通聊天场景里上下文压缩造成的后果顶多是被用户纠正一次“我刚才不是这个意思”。但编码代理不一样它每次决策都映射为对真实文件系统的修改。如果它忘记了你禁止改动某个模块它不会重新问你而是直接生成一段重构代码然后提交上去。我在某个模拟项目里就遇到过这种事我让代理完成一个异步任务调度模块中间我明确说过“不要动底层存储接口只改调度层”。一万行代码之后上下文被压缩代理在后续重构中判断“底层接口的鉴权逻辑是这个任务的关键瓶颈”于是自作主张重写了鉴权模块差点把整个系统的安全边界破坏掉。从那以后我得出一个结论不要把编码代理当成一个“聊天遗忘问题”来处理而是当成一个“分布式系统状态管理问题”来处理。聊天窗口只是瞬时的工作内存磁盘状态才是唯一可靠的长期记忆。2. init.d 的启示把代理当服务跑而不是当对话聊2.1 init.d 的思想移植声明期望而不是记忆过程Unix 里的 init.d 是一个让我想到就觉得很踏实的设计。它的核心逻辑是无论系统之前经历过多少次崩溃、重启、电源故障只要有一组声明式的启动脚本放在指定目录里系统就能按预定顺序把服务拉起来。服务进程本身可以随时被杀掉但它的“重启意图”是持久化的。把这个思想移植到 AI 编码代理上就形成了一句我自己的口头禅代理不靠上下文里的记忆活着靠磁盘上的状态声明活着。具体做法是不要在对话里反复叮嘱代理“记住某某约定”而是把这些约定写成一份独立的状态文件放进工作区里的 .agent 目录。代理每开始一个新会话、每经历一次上下文压缩、每被用户打断又恢复都先加载这份状态文件而不是加载一段聊天记录。这样“记住约定”就从模型的注意力问题变成了文件系统的读写问题。2.2 状态文件的三种层次目标层、进度层、证据层在实践中我会把代理状态拆成三层目标层、进度层、证据层。三层各自承担不同的职责。目标层是一个精简的子目标描述文件里面写明最终交付物是什么、有哪些硬性约束、有哪些绝对不能碰的代码禁区。它的作用相当于 init.d 里的启动参数不解释历史只定义当前应该处于什么状态。进度层是代理当前执行阶段的检查点包含当前处于哪个阶段、接下来要做哪个动作、有哪些前置条件需要满足。它相当于 init.d 脚本里的“runlevel”告诉代理现在应该启动到什么级别。证据层则是一批短期快照文件记录最近几次操作的结果摘要、最近一次测试执行的输出、最近一次代码搜索的结论。它的作用是让代理在恢复之后不需要重新探索一遍环境而是直接基于已有的证据继续推理。这三层关系就像操作系统的启动过程目标层对应内核参数进度层对应运行级别证据层对应上次关机前的临时缓存。每层都独立存储任何一层丢失都可以从其他层重新推导。2.3 幂等重启灾后恢复的关键协议让代理像 init.d 服务一样重启还有一个前提条件代理的操作必须是幂等的。所谓幂等就是无论同一个动作被执行一次还是十次最终的结果都一致。很多编码代理在上下文压缩后最大的问题是“重复劳动”。它忘了自己已经改过某个函数于是又改了一遍它忘了自己已经确认过某个测试通过于是又跑了一遍它忘了自己已经否决过某个方案于是又提了一遍。这就是典型的非幂等行为。我的应对方式是在进度层里维护一个“完成标记列表”每次动作完成后就把文件哈希、测试状态、决策结论记录下来。代理在恢复时必须先检查这个列表如果某个动作已经有完成标记就跳过它绝不重做。这一步看起来简单但在实际操作中能把恢复后的无意义工作量减少一半以上。3. 《记忆碎片》的启示外部记忆比脑子里的记忆更可靠3.1 代理的记忆不该是“稀释过的聊天摘要”电影《记忆碎片》讲了一个短期记忆受损的人如何靠笔记、照片、纹身来维持生活逻辑。他每过几分钟就会忘记刚才做了什么但他可以翻开笔记本看到自己写下的话从而知道下一步该干什么。AI 编码代理在上下文压缩后的处境和这个角色高度相似模型本身没有主动遗忘机制但上下文窗口的压缩相当于外部的“脑损伤”。你无法阻止压缩发生也不需要阻止但你可以学电影里的做法把记忆写到身体之外。这里的“身体之外”就是工作区里的状态文件。我见过一些人试图通过不断让模型“总结之前的对话摘要”来对抗压缩但事实证明这是最脆弱的方式摘要也会被压缩压缩后的摘要又会变成更模糊的摘要最后你得到的只是一句“我们正在解决一些用户反馈的问题”之类毫无价值的话。与其维护一段稀释过的对话记忆不如维护一组结构化的外部记忆目标、进度、证据、标记。这些不是自然语言总结而是机器可读的事实记录。3.2 给代理刻上的“纹身”目标锚、指纹、状态戳在《记忆碎片》里主角最可靠的记忆不是笔记而是纹在身上的关键词。那些关键词很短、很硬、不会因为情绪或遗忘而改变。对代理来说我设计了三种“纹身”第一种是目标锚是一句不可妥协的最终目标描述比如“交付一个带身份验证的 API 网关”。这句描述必须简短到即使在压缩后的上下文里也能完整保留。第二种是环境指纹是当前工作区的一组哈希值、文件清单和关键配置路径。代理恢复后可以通过指纹确认自己到底在哪个项目、哪个分支、哪个目录层级。第三种是状态戳是一个执行计数和时间戳记录当前是第几次重启、上一次进度确认发生在什么时刻。状态戳能帮代理快速判断自己是不是掉进了一个“不断重复同一阶段”的循环。这三种纹身有一个共同特征短、不可歧义、必须持久保存。不要试图把详细设计文档写进状态文件里那只会撑爆恢复上下文。3.3 笔记不是日志怎么写出能自我重建的状态描述很多人会把状态文件写成流水账比如“第 3 步完成了第 4 步在做”但这种描述对代理恢复毫无帮助。代理需要的不是“发生过什么”而是“接下来基于什么状态、可以做什么”。我写状态描述有一个原则每条描述必须能在不参考任何历史对话的情况下独立支撑一个动作的决策。比如“当前已完成 modules/queue.py 中调度循环的初步实现测试 file tests/test_queue.py 中 3 个用例通过剩余待办为增大并发时出现的竞态问题”。这句话里包含了位置、进展、验证结果、下一步方向代理恢复后可以直接拿它当行动依据。用一句话总结状态文件是代理的“可执行记忆”不是聊天记录的摘要更不是心情随笔。如果一段描述无法让另一个人或另一个模型看完后立刻知道接下来做什么那这段描述就不合格。4. 落地架构一个能扛住压缩的编码代理工作流4.1 文件系统布局把状态放进工作区而不是聊天窗我建议在项目根目录下创建一个.agent/state目录专门存放代理状态文件。目录结构通常是这样.agent/state/ goals.md # 目标锚 硬性约束 progress.yaml # 当前阶段、待办清单、完成标记 evidence/ # 近期的操作证据快照 ......关键点是这个目录必须被纳入版本控制如果项目用 git就让这个目录一起提交。因为状态文件如果只存在本地磁盘上一旦工作区被迁移或清理代理照样失忆。放进版本控制里状态就等于有了分布式备份。我见过有人把状态文件放在聊天工具的“记忆库”或“项目备忘”里但这违背了就近原则代理每次读状态都要跨系统调用既慢又容易失败。放在工作区里代理只需要一次文件系统读取可靠性高得多。4.2 一轮编码会话的完整运行循环我的代理工作流不再是一个持续的对话流而是一个由多个“启动-执行-打点-恢复”阶段组成的循环。同一段任务代理可能会经历几十次上下文重建但每一次重建后它都能从磁盘里恢复心智模型。具体运行循环如下启动阶段代理先读取 goals.md 和 progress.yaml确认目标、当前阶段、禁止动作。指纹核对阶段代理检查当前工作树的 git 版本、关键文件哈希确认文件系统状态和 progress.yaml 里记录的一致。计划阶段根据 progress.yaml 中的 next_action 字段代理决定接下来具体做什么而不是依赖对话历史里的“刚才”猜测自己该做什么。执行阶段代理修改代码、运行测试、搜索文件并保存输出摘要到 evidence 目录。打点阶段代理把当前阶段标记为完成、更新 progress.yaml 的 next_action、提交一次 git 快照。每次上下文被压缩后重新执行 1 到 3 步即可。整个过程相当于 init.d 里的重新加载服务你不用重写代理的“灵魂”只需让它重新读取配置并应用增量。4.3 从 20 万到 20 万标记预算的分配策略20 万 token 看起来很多但如果你不做预算控制它会像内存泄漏一样被慢慢耗尽先是塞进无关日志然后是臃肿的搜索结果再然后是代理自己生成的中间分析最后你连系统提示词都要被压缩。我自己的分配策略是系统提示词控制在 5000 token 以内目标锚控制在 2000 token 以内进度层控制在 3000 token 以内证据层控制在 2000 token 以内剩下的全部留给当前执行任务的上下文。也就是说真正核心的持久化状态加起来不超过 12000 token剩下的 18 万 token 都是“临时工作区”。这个策略的妙处在于即使上下文被压缩到只剩最后 2 万 token核心状态依然可以全量装入上下文代理不会在启动阶段就发生信息丢失。如果代理还要执行长文件操作那就在临时上下文里处理处理完把结论写回进度层。5. 模拟脑叶切除实操测试与结果对照5.1 制造一次“人工失忆”就算你相信这套架构理论上行得通也一定要亲自动手做一次“模拟脑叶切除术”测试。做法很简单让代理在一个模拟项目里执行一个较长的编码任务运行到一半时强行切断它的对话会话然后在新会话里只执行启动协议看它能不能继续推进任务。我常用的切割方式是先让代理完成第一阶段开发把状态文件提交好然后在新会话里清空所有聊天历史只在初始消息里附上“请读取 .agent/state 并继续工作”。这比等 API 层自动截断更严格因为它模拟的是完全失忆不是部分遗忘。第一次做这个测试时我预期代理会比较混乱但它读状态文件后直接说了一句话“检测到当前处于阶段 3下一动作为……”然后开始写测试用例。那一刻我确实有种“这一套设计没有白做”的感觉。但我也发现状态文件如果不写清楚恢复就会很生硬代理虽然不会瞎猜目标但会对某些环境细节过度怀疑反复检查目录结构。5.2 恢复前后的关键指标对比我在测试中记录了几个指标恢复时间、前五步操作的准确率、产生多余代码的概率、以及最终交付物与完整上下文版本的一致性。有状态文件的情况下恢复时间通常在 1 分钟以内而且代理前五步操作基本直接落在当前阶段的关键路径上不会重新探索已经完成的区域。而没有状态文件的对照组代理恢复后会浪费时间重新阅读整个项目结构重新猜测需求甚至重新实现已经被否决的旧方案。两者最终交付物的一致性差距也很大有状态文件的版本基本能到达原路径终点没有状态文件的版本往往产出完全不同风格和结构的代码。5.3 不同压缩策略下的表现我还尝试过几种压缩策略包括“截断中间段只留头部和尾部”“全文摘要成一段”“只保留最近系统消息”。结论是无论压缩策略是什么只要状态文件还在代理的核心目标都不会丢失但如果只依赖聊天摘要代理的心态就会像坐过山车一样忽高忽低决策时自信、行动时偏航。有意思的是即使压缩策略极端到“只保留系统提示词和状态文件”代理依然能启动并完成大部分待办项。这说明外部状态文件的语义承载能力远高于对话摘要因为它没有被二次转述过始终是原始事实。6. 实战中踩过的坑与排查方法6.1 状态文件与真实代码脱节最大的坑是状态文件写得太美实际代码完全不是那么回事。比如进度层写着“已完成接口鉴权”但代码里鉴权逻辑其实还没提交或者已经被你在手动调试时改掉了。代理恢复后看到状态文件里描述的任务会以为代码已经处于那个状态然后直接在其基础上开发最终产生一堆基于假象的改动。解决办法是每次打点之前强制要求代理先执行一遍相关测试和文件哈希校验确认“状态文件描述”和“真实文件树”一致。如果校验失败就先更新状态文件再继续下一步。宁可多花几秒校验也不要把错误状态固化下来。6.2 记忆碎片越攒越乱上下文却没有变小状态文件如果一直往里塞内容会慢慢变成一个巨大的“记忆垃圾场”恢复时反而把宝贵的上下文预算全耗尽。有个阶段我为了保险把每一次动作的完整日志都写进 evidence 目录结果代理启动时把整个目录都读了一遍上下文瞬间上涨 3 万 token。教训是外部记忆也要有淘汰策略。我后来规定 evidence 目录只保留最近 10 条操作摘要更早的数据直接提交进 git 历史里就好不需要让代理每次启动都重新加载一遍。真正要进入上下文的必须是高度浓缩过的结论而不是过程的完整复述。6.3 恢复后代理陷入“零起点焦虑”有些代理在恢复后发现自己丢了对话历史会变得过分谨慎反复检查环境、重新阅读目标文件、重跑验证流程反而降低了效率。这种“零起点焦虑”在心理上可以理解但在工程上不可接受。我的方法是状态戳里明确写入一个“恢复级别”字段。如果代理检测到恢复级别为 2就表示“只需读取目标层和进度层不要重新探索项目结构”恢复级别为 3 时才允许做完整重新扫描。这样代理每次恢复的行为模式是确定性的而不是情绪化的。6.4 多代理协作时的状态版本冲突当你开始让多个代理实例并行处理同一个项目时状态文件的并发写就成了问题。两个代理同时更新 progress.yaml后写的一方会把前写的一方的进度覆盖掉最终状态缺失某一半进展。解决方式有两个一是把状态文件拆分成多个独立文件每个代理只写属于自己的状态二是用 git 分支隔离每个代理在自己的分支上打点最后手工合并。我建议小项目直接选第一种大项目才考虑分支方案。无论选哪种都要把状态文件视为普通代码文件来对待引入版本冲突处理机制而不是默认它永远是单线程安全的。7. 写在最后这不是抵抗而是并存我这套工作流不是要让代理“免疫压缩”因为只要上下文窗口存在压缩就会发生这是客观规律。真正让人安心的不是避免压缩而是设计一套状态系统让压缩成为一次可恢复的服务重启而不是一次灾难。在多次实验之后我个人有一个很深的体会编码代理的上下文窗口就像一个人脑海里的短期工作记忆而磁盘上的状态文件才是它的长期记忆。短期记忆随时可能被外力抹除但长期记忆只要还在磁盘上代理就永远不会真正“忘记”自己是谁、在做什么、下一步要去哪里。如果你也在折腾 AI 编码代理我建议你从今天开始不要继续把对话历史当成唯一的记忆载体。花一个小时把你手头项目的目标、进度、证据写成一个结构化的状态目录然后亲手触发一次上下文压缩看看代理能否从废墟里爬出来。能爬起来你就真正理解了这个标题的含义爬不起来你也知道该改哪里。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
