This is the eighth article in a series on agentic engineering and AI-driven development. Read part one here, part two here, part three here, part four here, part five here, part six here, and part seven here.这是关于智能体工程和AI驱动开发系列文章的第八篇。阅读第一部分请点击此处，第二部分请点击此处，第三部分请点击此处，第四部分请点击此处，第五部分请点击此处，第六部分请点击此处，第七部分请点击此处。
“640K ought to be enough for anybody.”—Bill Gates (allegedly)“640K对任何人来说都应该足够了。”——比尔·盖茨（据称）
If you’re building AI agents that do complex, multistep work, you’re going to run into context loss. The agent’s working memory fills up, older information gets silently dropped or compressed, and the agent keeps going without realizing it’s forgotten something. This article, the third in my Radar article trilogy about context management, walks through a pattern I’ve been refining for detecting and recovering from that problem, which I call the externalize-recognize-rehydrate pattern (or ERR, which I think is actually a pretty good acronym for an error recovery pattern): save your agent’s state to files on disk, detect when context has degraded, and reload from those files to recover. The individual techniques are standard practice in agent and skill engineering—checkpointing, progress files, state verification—but the real power comes from combining them into a coherent workflow that you can use live or build into your agents. I’ll walk through each step with specific prompts you can adapt for your own agents and coding sessions.如果你正在构建执行复杂多步骤工作的AI智能体，你将会遇到上下文丢失的问题。智能体的工作记忆被填满，旧信息被静默丢弃或压缩，而智能体继续运行却未意识到自己遗忘了某些内容。本文是我关于上下文管理的雷达文章三部曲中的第三篇，介绍了我一直在完善的一种检测和恢复该问题的模式，我称之为“外部化-识别-再水化”模式（或ERR，我认为对于错误恢复模式来说，这是一个相当不错的缩写）：将智能体的状态保存到磁盘上的文件中，检测上下文何时退化，并从这些文件中重新加载以恢复。这些单独的技术在智能体和技能工程中是标准实践——检查点、进度文件、状态验证——但真正的力量来自于将它们组合成一个连贯的工作流程，你可以实时使用或将其构建到你的智能体中。我将逐步介绍每个步骤，并提供具体的提示，你可以根据自己的智能体和编码会话进行调整。
Which brings me to memory. Gates has said on multiple occasions that he never actually said that quote at the top of this article, but it endures because it captures one of the core limitations of that era, one that people struggled with constantly, in a way that we can laugh about now. Around that time I was using a 286 with 1 MB of RAM. That’s megabytes, not gigabytes. MS-DOS 3.3 gave me 640K of conventional memory plus 384K of upper memory, and I spent a lot of time figuring out how to use every bit of it. I configured memory managers, loaded device drivers high, used (and wrote!) terminate-and-stay-resident programs that moved themselves out of conventional memory to free up space, and generally treated memory as a resource that required active, deliberate engineering. There was a lot I wanted to do that didn’t fit into 640K, and like most people at the time, I went to some lengths to compensate for the memory limitations.这让我想到了内存。盖茨曾多次表示，他从未说过本文开头的那句话，但这句话之所以流传至今，是因为它捕捉到了那个时代的一个核心限制，一个人们不断与之斗争的限制，以至于我们现在可以对此一笑置之。大约在那个时候，我使用一台拥有1MB内存的286电脑。是兆字节，而不是千兆字节。MS-DOS 3.3给了我640K的常规内存加上384K的上层内存，我花了很多时间想办法利用每一比特。我配置内存管理器，将设备驱动程序加载到高端内存，使用（并编写！）终止并驻留程序，这些程序将自己移出常规内存以释放空间，总的来说，我将内存视为一种需要主动、精心设计的资源。我想做很多事情，但640K装不下，和当时大多数人一样，我费了不少力气来弥补内存限制。
We’re at the 640K stage of AI development. The context window is the new RAM ceiling. Most of today’s models give you somewhere between 200K and 2M tokens of working memory (and, like memory in the late 1980s and early 1990s, those numbers are growing all the time), and if you’re building agents that do complex multistep work, you will hit that ceiling. When you do, the AI starts compacting: compressing or dropping older parts of the conversation to make room. And just like running out of conventional memory on a 286, things stop working right and you’re not sure why.我们正处于AI发展的640K阶段。上下文窗口是新的RAM上限。当今大多数模型提供大约20万到200万个令牌的工作记忆（并且，就像20世纪80年代末和90年代初的内存一样，这些数字一直在增长），如果你正在构建执行复杂多步骤工作的智能体，你将触及这个上限。当这种情况发生时，AI开始压缩：压缩或丢弃对话的较旧部分以腾出空间。就像在286上耗尽常规内存一样，事情开始出错，而你不确定原因。
In 20 years we’ll be looking back at today’s puny context windows and wondering how developers in the 2020s managed to get anything done with just a few million tokens. Because none of this is new. In case you don’t believe me, here’s a photo of my dad at Princeton in the early 1970s working on an Evans and Sutherland LDS-1 graphics computer, the first commercial vector graphics machine, connected to a PDP-10 mainframe:20年后，我们回顾今天微不足道的上下文窗口，会想知道21世纪20年代的开发者是如何仅凭几百万个令牌完成任何工作的。因为这一切都不是新鲜事。如果你不相信我，这里有一张我父亲20世纪70年代初在普林斯顿的照片，他正在使用一台Evans and Sutherland LDS-1图形计算机，这是第一台商用矢量图形机，连接到一个PDP-10大型机：
The actual LDS-1 is in the large cabinet in the background, directly behind the monitor. Sitting next to it, just out of the picture, is an even larger cabinet that holds a memory unit with 16K of magnetic core memory (technically 8K words).实际的LDS-1位于背景中的大机柜里，就在显示器正后方。在它旁边，照片之外，是一个更大的机柜，里面装有一个拥有16K磁芯内存（严格来说是8K字）的内存单元。
So you can imagine that just a decade later, 640K in a tiny PC that fit on your desktop seemed extravagant.所以你可以想象，仅仅十年后，一台放在桌面上的小型PC拥有640K内存似乎就很奢侈了。
In the last two articles in this series (“Why Doesn’t Anyone Teach Developers About Context Management?” and “Your AI Agent Already Forgot Half of What You Told It”), I talked about what context is and why context management matters, and I shared practical techniques and prompts for keeping important information in files instead of leaving it in the AI’s context window. This article gets more technical. I want to build on those strategies and talk about how to build agents that can detect when they’ve lost context and recover from it on their own.在本系列的前两篇文章（“为什么没有人教开发者关于上下文管理？”和“你的AI智能体已经忘记了你告诉它的一半内容”）中，我讨论了什么是上下文以及为什么上下文管理很重要，并分享了将重要信息保存在文件中而不是留在AI上下文窗口中的实用技术和提示。本文更具技术性。我想在这些策略的基础上，讨论如何构建能够检测到上下文丢失并自行恢复的智能体。
Brute-forcing my way through context loss暴力破解上下文丢失
I’ve been doing this kind of context management for a while now, long before the specific tools I’m about to describe existed. But a recent crash gave me a clean example of what the process looks like in its most brute-force form.我进行这种上下文管理已经有一段时间了，远在我即将描述的具体工具出现之前。但最近的一次崩溃给了我一个清晰的例子，展示了这个过程在最暴力形式下的样子。
I was working in Copilot with a seven-step plan, going through it one step at a time, having another AI review each step before moving on. Steps one and two went fine. When it came time to do step three and I gave it the prompt, it jumped straight to step four. This kind of thing can be really frustrating, because it seems like an AI smart enough to implement a complex feature in code should be able to (ahem) count to four.我当时在Copilot中按照一个七步计划工作，一步一步地进行，每一步都由另一个AI审查后再继续。第一步和第二步进行得很顺利。当轮到第三步时，我给出了提示，它直接跳到了第四步。这种事情可能非常令人沮丧，因为一个足够聪明能够在代码中实现复杂功能的AI似乎应该能够（嗯）数到四。
The key to not getting frustrated when the AI loses track of steps or can’t seem to count from prompt to prompt is to remember what it’s good at and how it remembers things. If the AI you’re using does that, check the conversation history. You’ll probably see something like “summarizing conversation history” or “compacting conversation” somewhere above your last message. That’s telling you that the AI lost track of where it was because that count was literally purged from its memory.当AI失去步骤追踪或似乎无法在提示之间计数时，不感到沮丧的关键是记住它擅长什么以及它是如何记忆的。如果你使用的AI出现了这种情况，请检查对话历史。你可能会在最后一条消息上方的某个地方看到类似“正在总结对话历史”或“正在压缩对话”的内容。这告诉你AI失去了对当前位置的追踪，因为那个计数实际上已从其记忆中清除。
AIs are good at carrying out an instruction. They’re bad at keeping track of their own state over a long conversation, and the way they manage their memory is a big part of that. This article is about finding ways to build your AI tools so you’re not relying on them to do the thing they’re worst at.AI擅长执行指令。它们不擅长在长对话中跟踪自己的状态，而它们管理记忆的方式是其中的一个重要部分。本文是关于寻找方法来构建你的AI工具，这样你就不必依赖它们去做它们最不擅长的事情。
But compaction isn’t the only way your AI loses context. A few weeks ago I was deep into a long session with Copilot, working through a multiphase code review. I’d spent a while building up context with the AI about my codebase and the decisions we’d made together. I was about to move on to the next phase, and then I got this:但压缩并不是AI丢失上下文的唯一方式。几周前，我深入参与了一个与Copilot的长时间会话，正在进行一个多阶段的代码审查。我花了一段时间与AI建立关于我的代码库和我们共同做出的决定的上下文。我正准备进入下一阶段，然后我看到了这个：
The entire context was wiped, which could have been a really frustrating problem, since I had a long history with the session, and it had built up a lot of knowledge about what we were doing. This turned out to be a bug in Opus 4.6’s interaction with Copilot’s conversation history, and I’ve seen other people hit the same thing. I was staring at a fresh prompt with nothing in it.整个上下文被清除了，这可能是一个非常令人沮丧的问题，因为我在这个会话中有很长的历史，它已经积累了大量关于我们正在做什么的知识。结果发现这是Opus 4.6与Copilot对话历史交互中的一个错误，我也看到其他人遇到了同样的问题。我面对着一个全新的提示，里面什么都没有。
So I did something that, in retrospect, is a pretty good brute-force version of what this whole article is about. I recognized the context was gone (hard to miss when the whole conversation disappears). I copied the entire conversation out of Copilot and pasted it into a text file. Then I gave the new session a prompt:所以我做了一件事，事后看来，这是本文主题的一个相当不错的暴力版本。我意识到上下文丢失了（当整个对话消失时很难错过）。我将整个对话从Copilot中复制出来，粘贴到一个文本文件中。然后我给新会话一个提示：
We were in the middle of a long conversation, then I got an error and the entire context was wiped. I saved a copy of the conversation in #file:chat_history.txt, read it and bring yourself back up to speed.我们正在进行一个长对话，然后我遇到了一个错误，整个上下文被清除了。我保存了一份对话副本在#file:chat_history.txt中，请阅读它并让自己跟上进度。
And it worked! This brought the new session back to where I needed it to be.而且它奏效了！这使新会话回到了我需要的位置。
That simple error and recovery actually outlines a pretty good pattern for dealing with context loss:这个简单的错误和恢复实际上勾勒出了一个处理上下文丢失的不错模式：
- Externalize the state. Get the important information out of the conversation and into a file on disk, where it won’t disappear when the context window reshuffles.外部化状态。将重要信息从对话中取出，放到磁盘上的文件中，这样当上下文窗口重新调整时，它就不会消失。
- Recognize the loss. Notice that the agent’s working context has been wiped or degraded, whether that’s obvious (like a crash) or subtle (like output that quietly stops making sense).识别丢失。注意到智能体的工作上下文已被清除或退化，无论是明显的（如崩溃）还是微妙的（如输出悄悄变得不合理）。
- Rehydrate from the file. Point a new session at that file and let it rebuild its understanding from what’s written down.从文件中再水化。将新会话指向该文件，让它根据记录的内容重建理解。
The individual mechanics are well-documented across cognitive science (cognitive offloading, task resumption), software engineering (the Memento pattern, React hydration), and knowledge management (the SECI model). I’m not claiming to have invented any of them. But the specific abstraction of these three phases into a unified, named pattern applied to AI context management is, as far as I can tell, new. It’s synthesis and codification, not invention.这些单独的机制在认知科学（认知卸载、任务恢复）、软件工程（备忘录模式、React水合）和知识管理（SECI模型）中都有详细记载。我并非声称发明了其中任何一个。但是，将这三个阶段抽象成一个统一的、命名的模式并应用于AI上下文管理，据我所知，是新的。这是综合和编码，而非发明。
In this case I did it with copy and paste, which isn’t particularly elegant, but it worked for me. But this is a blunt instrument, because a raw conversation dump is both too much and too little: it’s too much because it’s full of noise, like tool calls, dead ends, back-and-forth that doesn’t matter anymore; and it’s too little because the context that got silently compressed away during the session is already gone. When you build these mechanisms into agents and skills, you can do it in a much more subtle and automated way.在这种情况下，我通过复制粘贴来完成，这并不特别优雅，但对我有效。但这是一种粗糙的工具，因为原始的对话转储既太多又太少：太多是因为它充满了噪音，比如工具调用、死胡同、不再重要的来回对话；太少是因为在会话期间被静默压缩掉的上下文已经消失了。当你将这些机制构建到智能体和技能中时，你可以以更加精细和自动化的方式来完成。
Externalize: Add two layers of state to your agent外部化：为你的智能体添加两层状态
The idea behind externalization, or periodically saving your agent’s state, came out of a conversation I was having with an AI assistant while building the Quality Playbook, an open source AI coding skill that runs structured code reviews. The playbook runs a structured code review as a single process, but that process could easily turn into a 15-million-token request if you tried to do it all in one shot. I described in the previous article in this series how I broke it into six phases, and that was only possible because the context for each phase had already been externalized. Each phase reads its inputs from files, does its work, writes its outputs to files, and stops. The next phase picks up from the files, not from whatever the agent remembers. If this sounds like the familiar advice to ask the AI to plan before you ask it to implement, it’s the same principle applied to context management. Separating each step and persisting the output means you can inspect it, and the next step doesn’t depend on the agent’s memory.外部化（即定期保存智能体状态）的想法源于我在构建Quality Playbook（一个开源AI编码技能，用于执行结构化代码审查）时与AI助手的对话。该手册将结构化代码审查作为一个单一过程运行，但如果你试图一次性完成所有工作，这个过程很容易变成一个1500万个令牌的请求。我在本系列的前一篇文章中描述了如何将其分解为六个阶段，而这之所以可能，只是因为每个阶段的上下文已经被外部化。每个阶段从文件中读取输入，执行工作，将输出写入文件，然后停止。下一阶段从文件中获取信息，而不是从智能体记忆的任何内容中获取。如果这听起来像是熟悉的建议——在要求AI实现之前先让它计划——那么这是相同的原则应用于上下文管理。将每个步骤分开并持久化输出意味着你可以检查它，并且下一步不依赖于智能体的记忆。
But what should those files contain? I found that the AI is actually good at figuring that out. At some point I asked the assistant:但这些文件应该包含什么？我发现AI实际上很擅长弄清楚这一点。在某个时候，我问助手：
Would it make sense for the agent to record more context in files as it progresses, to make sure nothing is dropped along the way? It should work even if you break it into separate prompts, because the result from each step is persisted. Plus, we can audit its reasoning for debugging and improvement.智能体在进展过程中将更多上下文记录到文件中是否有意义，以确保沿途不会丢失任何内容？即使你将其分解为单独的提示，它也应该有效，因为每一步的结果都被持久化了。此外，我们可以审计其推理以进行调试和改进。
That prompt was all it took. The assistant designed the file structure itself: a progress tracker that records which phase is active and what’s been completed, a JSONL artifact file (JSONL is just a file with a bundle of JSON objects, with one record per line) where each pass appends its output, and a set of brief documents describing the purpose of each phase. You don’t need to overengineer this. Tell the agent what you’re trying to preserve and let it figure out the file layout.这个提示就足够了。助手自己设计了文件结构：一个进度跟踪器，记录哪个阶段处于活动状态以及已完成的内容；一个JSONL工件文件（JSONL只是一个包含一组JSON对象的文件，每行一条记录），每次遍历都会追加其输出；以及一组描述每个阶段目的的简短文档。你不需要过度设计。告诉智能体你想要保留什么，让它自己弄清楚文件布局。
What emerged falls into two categories that I think of as execution continuity and task continuity:最终出现的内容分为两类，我称之为执行连续性和任务连续性：
- Execution continuity is the state the agent needs to resume work in the middle of a task: what step it’s on, what it’s completed, what decisions it’s made so far. These files change constantly as the agent works.
执行连续性是指智能体在任务中间恢复工作所需的状态：它处于哪一步，完成了什么，到目前为止做出了哪些决定。这些文件随着智能体的工作不断变化。 - Task continuity is the broader context that doesn’t change during execution: what the whole task is about, what success looks like, what the structural constraints are. These files are written once and read at every resumption.任务连续性是指在执行过程中不会改变的更广泛的上下文：整个任务是关于什么的，成功是什么样的，结构约束是什么。这些文件只写入一次，并在每次恢复时读取。
When an agent needs to resume after suspected compaction, it reads back both layers. The task continuity files anchor it back to what the whole endeavor is about. The execution continuity files put it back in the middle of the work. Together, they give the agent enough information to continue without relying on anything that might have been compacted.当智能体在疑似压缩后需要恢复时，它会读取这两层。任务连续性文件将其锚定回整个工作的目标。执行连续性文件将其放回工作的中间。它们共同为智能体提供了足够的信息来继续，而无需依赖任何可能已被压缩的内容。
The key is that externalization isn’t something you do once at the beginning of a task. You want the agent saving its state at frequent checkpoints so that if compaction happens mid-run, the most recent checkpoint is close to where the agent was working. Here’s the kind of instruction I gave the agent for tasks that processed records one at a time:关键在于，外部化不是在任务开始时只做一次的事情。你希望智能体在频繁的检查点保存其状态，这样如果压缩在运行过程中发生，最近的检查点就接近智能体正在工作的位置。以下是我给智能体处理逐条记录任务的指令类型：
Update the progress file after every single record, not in batches. Write the output line first, then update the progress file with the new cursor and a fresh timestamp. If the progress file’s timestamp falls behind the output file’s, you’re batching and that’s wrong.在每条记录之后更新进度文件，而不是批量更新。先写入输出行，然后用新的游标和新的时间戳更新进度文件。如果进度文件的时间戳落后于输出文件的时间戳，说明你在批量处理，这是错误的。
The frequency matters because context can compact at any point. If the agent only saves state at the end of a long run, compaction in the middle means losing everything since the start. If it checkpoints after every unit of work, the worst case is losing one unit.频率很重要，因为上下文可以在任何时候压缩。如果智能体只在长时间运行结束时保存状态，那么中间的压缩意味着丢失自开始以来的所有内容。如果它在每个工作单元之后设置检查点，最坏的情况是丢失一个单元。
Two-layer externalization survives context reshaping, not only outright context loss. Even if the agent’s context window isn’t full, if the context has been reorganized or reprioritized (a compression that reshapes without truncating), the agent can reload the external files and know for certain what the ground truth is.两层外部化能够应对上下文重塑，而不仅仅是直接的上下文丢失。即使智能体的上下文窗口未满，如果上下文已被重新组织或重新排序（一种在不截断的情况下进行重塑的压缩），智能体也可以重新加载外部文件，并确切知道什么是真实情况。
Recognize: Detecting loss from inside the agent识别：从智能体内部检测丢失
The second step in the pattern is to recognize that your agent has lost context, and it turns out to be the hardest part (at least with today’s AI technology). When the context window fills up, the AI compacts silently, and the agent keeps working without realizing it’s lost information. The agent can’t tell you it’s forgotten something, because it doesn’t know it forgot. Detecting that change turns out to be a nontrivial problem; I’ll walk you through an approach that helped me, and keep it general enough so you can do the same thing. The copy-and-paste approach works when the context loss is obvious, like a crash that wipes your whole conversation. But most context loss isn’t that visible.该模式的第二步是识别你的智能体是否丢失了上下文，而这被证明是最困难的部分（至少对于当今的AI技术而言）。当上下文窗口填满时，AI会静默压缩，智能体继续工作，却没有意识到自己丢失了信息。智能体无法告诉你它忘记了什么，因为它不知道自己忘记了。检测这种变化是一个不简单的问题；我将向你介绍一种对我有帮助的方法，并保持足够通用，以便你也可以这样做。当上下文丢失很明显时，比如崩溃清除了整个对话，复制粘贴的方法有效。但大多数上下文丢失并不那么明显。
I described context compaction in the previous article, but it’s worth restating the core problem from the agent’s perspective. Different tools handle context overflow differently: Some truncate older messages; some compress conversations into summaries; some use a sliding window. But they all have the same effect. Information disappears from the agent’s working context, and the agent doesn’t get notified.我在前一篇文章中描述了上下文压缩，但值得从智能体的角度重申核心问题。不同的工具处理上下文溢出的方式不同：有些截断较旧的消息；有些将对话压缩成摘要；有些使用滑动窗口。但它们都有相同的效果。信息从智能体的工作上下文中消失，而智能体没有收到通知。
This was a challenge when I built the Quality Playbook, because it runs multiple passes over a codebase, each one reading source files, extracting requirements, and checking coverage. Each pass can involve enough work that it fills the context window multiple times over. And when context compacts mid-pass, the agent doesn’t know it happened. It keeps working, but the output starts silently degrading. So I started building mechanisms for the agent to detect compaction and recover by reading back the files it had written earlier. The patterns that came out of that work are general enough to apply to anyone building agents that need to survive context pressure.当我构建Quality Playbook时，这是一个挑战，因为它对代码库进行多次遍历，每次遍历都读取源文件、提取需求并检查覆盖率。每次遍历可能涉及足够多的工作，以至于多次填满上下文窗口。当上下文在遍历过程中压缩时，智能体不知道发生了这种情况。它继续工作，但输出开始悄悄退化。所以我开始构建机制，让智能体通过重新读取之前写入的文件来检测压缩并恢复。从这项工作中得出的模式足够通用，可以适用于任何需要应对上下文压力的智能体构建者。
From the agent’s perspective, compaction is seamless. It’s tracking state, referencing decisions made earlier in the conversation, and then at some point the earlier context is gone. But the agent can’t tell the difference between “I never knew that” and “I knew it but lost it.” It tries to reference something and finds nothing, or finds a compressed version that lost the nuance. And because the agent doesn’t know it lost anything, it doesn’t know it needs to recover.从智能体的角度来看，压缩是无缝的。它正在跟踪状态，引用对话早期做出的决定，然后在某个时刻，早期的上下文消失了。但智能体无法区分“我从未知道”和“我知道但丢失了”。它试图引用某些内容，却发现什么都没有，或者发现一个丢失了细微差别的压缩版本。而且因为智能体不知道它丢失了任何东西，它也不知道需要恢复。
This invisibility is the core problem. But it turns out you can work around it, and the next two sections walk through how.这种不可见性是核心问题。但事实证明你可以绕过它，接下来的两节将介绍如何做到。
Building a detection mechanism构建检测机制
Once you have files on disk, the question is what specifically to check and how to know when something has gone wrong. I landed on a mechanism while building the Quality Playbook’s requirement extraction pipeline. The playbook processes source documents in multiple passes, and each pass appends its output to a JSONL artifact file. After each unit of work, the agent also writes a progress record to a separate file: what it just finished, what it found, and where it should pick up next.一旦你在磁盘上有了文件，问题就变成了具体检查什么以及如何知道何时出了问题。我在构建Quality Playbook的需求提取管道时确定了一种机制。该手册分多次遍历处理源文档，每次遍历将其输出追加到一个JSONL工件文件中。在每个工作单元之后，智能体还会将一条进度记录写入一个单独的文件：它刚刚完成了什么，发现了什么，以及下一步应该从哪里继续。
The detection mechanism comes from two rules I gave the agent. The idea is that the progress file tracks a cursor, which is just a position marker that tells the agent which record to process next. If the agent writes a record to the output file but then loses context before updating the progress file, those two files will be out of sync.检测机制来自我给智能体的两条规则。其想法是，进度文件跟踪一个游标，它只是一个位置标记，告诉智能体接下来要处理哪条记录。如果智能体将一条记录写入输出文件，但在更新进度文件之前丢失了上下文，那么这两个文件将不同步。
The agent didn’t need to understand any of that upfront; I just described the rules in plain language and let it figure out the implementation. The first rule establishes an invariant between the output file and the progress file:智能体不需要事先理解所有这些；我只是用简单的语言描述了规则，让它自己找出实现方法。第一条规则在输出文件和进度文件之间建立了一个不变性：
Cursor advances only after the line is on disk. Write the summary line to the output file first, then update the progress file. The cursor must always equal the index of the next record that still needs to be processed.游标仅在行写入磁盘后前进。先将摘要行写入输出文件，然后更新进度文件。游标必须始终等于下一个仍需处理的记录的索引。
The second rule told the agent how to check that invariant on startup:第二条规则告诉智能体如何在启动时检查该不变性：
On startup, read the progress file. Resume from its cursor value. Verify continuity: the last line in the output file should equal cursor minus one. If not, roll the cursor back to match disk state and report the discrepancy.启动时，读取进度文件。从其游标值恢复。验证连续性：输出文件中的最后一行应等于游标减一。如果不是，将游标回滚以匹配磁盘状态，并报告差异。
If the progress file says the cursor is at record 381, but the last line in the output file is record 379, something happened. The context compacted and the agent lost track of where it was. The divergence between the two files is the signal.如果进度文件显示游标位于记录381，但输出文件中的最后一行是记录379，那么发生了某些事情。上下文压缩了，智能体丢失了当前位置。两个文件之间的差异就是信号。
This worked because files on disk don’t change when context compacts. They’re written once and then read repeatedly. If what the agent thinks it knows doesn’t match what’s actually in the files, something shifted in the agent’s memory, not on disk. I ended up folding this check into a preamble that every session started with:这之所以有效，是因为磁盘上的文件在上下文压缩时不会改变。它们只写入一次，然后被反复读取。如果智能体认为它知道的内容与文件中实际内容不匹配，那么是智能体的记忆发生了变化，而不是磁盘。我最终将这个检查纳入每个会话开始的序言中：
If this session has experienced auto-compaction, re-read the pass specification from disk. Do not try to reconstruct it from the compacted summary. Read the progress file. Read the last record of the JSONL artifact and confirm its index equals the cursor minus one. If not, roll the cursor back to match disk state. Disk is the source of truth. The conversation is not.如果此会话经历了自动压缩，请从磁盘重新读取遍历规范。不要试图从压缩的摘要中重建它。读取进度文件。读取JSONL工件的最后一条记录，并确认其索引等于游标减一。如果不是，将游标回滚以匹配磁盘状态。磁盘是真相来源。对话不是。
That preamble ran at the top of every session. During one particularly intensive day of pipeline development, I ran over a hundred Claude Code sessions with that exact instruction. Most of them completed without hitting compaction. But the ones that did hit it recovered cleanly, because the preamble told the agent exactly what to check and exactly what to do when the check failed.该序言在每个会话的顶部运行。在管道开发特别紧张的一天里，我运行了超过一百个Claude Code会话，都带有这个确切的指令。其中大多数完成时没有遇到压缩。但遇到压缩的那些会话干净地恢复了，因为序言准确地告诉智能体要检查什么，以及检查失败时该做什么。
The specific prompts I used are tied to the Quality Playbook’s file structure, but the technique generalizes. If you’re building any agent that does multistep work, you can adapt the same approach. Here’s a version you could drop into a session preamble or an agent’s system prompt:我使用的具体提示与Quality Playbook的文件结构相关，但该技术是通用的。如果你正在构建任何执行多步骤工作的智能体，你可以采用相同的方法。以下是一个你可以放入会话序言或智能体系统提示的版本：
Before continuing any task, read your progress file and your most recent output file. Compare them: does the progress file say you’ve completed work that isn’t reflected in the output? If so, trust the output file, roll back your progress to match, and note the discrepancy. Do not rely on what you remember from the conversation. The files on disk are the source of truth.在继续任何任务之前，请读取你的进度文件和最新的输出文件。比较它们：进度文件是否显示你已完成输出中未反映的工作？如果是，请信任输出文件，将进度回滚以匹配，并记录差异。不要依赖你从对话中记住的内容。磁盘上的文件是真相来源。
The wording doesn’t have to be precise. What matters is the structure: tell the agent where to look, what to compare, and which source to trust when they disagree.措辞不必精确。重要的是结构：告诉智能体在哪里查找，比较什么，以及当它们不一致时信任哪个来源。
But didn’t you just say the AI can’t detect its own compaction?但你刚才不是说AI无法检测自己的压缩吗？
Right, and it can’t. What I described above isn’t the agent detecting compaction. It’s the agent running a deterministic check against files on disk and finding a discrepancy. The agent doesn’t need to know that compaction happened. It just needs to notice that two files disagree. Think of the agent as an amnesiac clerk. You don’t ask the clerk to remember what they did yesterday. You make the clerk check the physical ledger every time they sit down at the desk. If their notes disagree with the ledger, they’re trained to trust the ledger.没错，它不能。我上面描述的不是智能体检测压缩。而是智能体对磁盘上的文件运行确定性检查并发现差异。智能体不需要知道发生了压缩。它只需要注意到两个文件不一致。把智能体想象成一个健忘的职员。你不会要求职员记住他们昨天做了什么。你让职员每次坐在办公桌前检查实物账本。如果他们的笔记与账本不一致，他们被训练成信任账本。
If you saw Christopher Nolan’s breakout movie Memento, you can think of your agent as Leonard Shelby, the character played by Guy Pearce with anterograde amnesia. You couldn’t ask Leonard to remember what he did yesterday. He had to check his tattoos every time he woke up. If his tattoos disagreed with what he’s seeing, he trusts the tattoo (which leads to a major plot point, which I won’t spoil). Again, this isn’t a new idea either. I mentioned the Memento pattern earlier, which is literally named after this movie.如果你看过克里斯托弗·诺兰的突破性电影《记忆碎片》，你可以把你的智能体想象成伦纳德·谢尔比，那个由盖·皮尔斯扮演的患有顺行性遗忘症的角色。你不能要求伦纳德记住他昨天做了什么。他每次醒来都必须检查他的纹身。如果他的纹身与他看到的不一致，他信任纹身（这导致了一个主要情节，我就不剧透了）。同样，这也不是一个新想法。我之前提到过备忘录模式，它实际上就是以这部电影命名的。
This is a classic distributed systems technique. In double-entry bookkeeping, you maintain two independent records of the same transaction and reconcile them regularly. If they disagree, you investigate. You don’t need to know why they diverged; the divergence itself is the signal. A two-phase commit works the same way: write the data first, then update the record that says the data was written. If you find data without a matching record, or a record without matching data, something went wrong between the two phases.这是一种经典的分布式系统技术。在复式记账中，你维护同一笔交易的两个独立记录，并定期对账。如果它们不一致，你就进行调查。你不需要知道它们为什么出现分歧；分歧本身就是信号。两阶段提交的工作原理相同：先写入数据，然后更新记录数据已写入的记录。如果你发现数据没有匹配的记录，或者记录没有匹配的数据，那么两个阶段之间出了问题。
That’s exactly what the cursor invariant does. The agent writes the output line first, then updates the progress file. If those two files are out of sync, something happened between the two writes. The agent doesn’t detect compaction. It detects a broken invariant, and it’s been told that when the invariant breaks, the files on disk win.这正是游标不变性所做的。智能体先写入输出行，然后更新进度文件。如果这两个文件不同步，那么两次写入之间发生了某些事情。智能体没有检测到压缩。它检测到了一个被破坏的不变性，并且它被告知当不变性被破坏时，磁盘上的文件获胜。
Three things make this work. First, the check is purely deterministic: read two files, compare two numbers, act on the result. There’s no reasoning involved, no judgment call about whether the agent “feels” like it lost context. I wrote about this principle in “Keep Deterministic Work Deterministic”; you never want an AI making decisions that a file comparison can make for it. Second, the files on disk don’t change when context compacts. They’re the stable reference point that the agent’s memory gets checked against. Third, the instruction to run the check lives in the system prompt or preamble, which is generally preserved even when conversation context gets compacted. The check survives the thing it’s designed to detect.有三件事使这成为可能。首先，检查完全是确定性的：读取两个文件，比较两个数字，根据结果采取行动。不涉及推理，不需要判断智能体是否“感觉”丢失了上下文。我在“保持确定性工作确定性”中写过这个原则；你永远不希望AI做出文件比较可以为其做出的决定。其次，磁盘上的文件在上下文压缩时不会改变。它们是智能体记忆被检查的稳定参考点。第三，运行检查的指令位于系统提示或序言中，这通常在对话上下文被压缩时得以保留。检查能够在其设计检测的事物中幸存下来。
Rehydrate: Reading back the state再水化：读回状态
Rehydration is the process of reading back externalized state and rebuilding the agent’s working context. Once the agent detects compaction (or, more specifically and accurately, has enough evidence from the filesystem that compaction occurred), the recovery step is to read back the externalized files and rebuild. For the Quality Playbook, rehydration meant:再水化是读回外部化状态并重建智能体工作上下文的过程。一旦智能体检测到压缩（或者更具体和准确地说，从文件系统获得足够的证据表明发生了压缩），恢复步骤就是读回外部化文件并重建。对于Quality Playbook，再水化意味着：
- Read the phase brief to re-anchor the purpose of this pass读取阶段简报以重新锚定本次遍历的目的
- Read the progress file to know which unit is active and what’s been completed读取进度文件以了解哪个单元处于活动状态以及已完成的内容
- Read the tail of the JSONL artifact to confirm the last successfully written record读取JSONL工件的尾部以确认最后成功写入的记录
- Recompute the next unit of work from those files从这些文件中重新计算下一个工作单元
This is different from just continuing without detection. Without detection, the agent tries to pick up where it left off and hopes it still has enough context. With detection, the agent knows something happened and deliberately reloads state before continuing.这与没有检测的继续不同。没有检测，智能体试图从它离开的地方继续，并希望它仍然有足够的上下文。有了检测，智能体知道发生了某些事情，并在继续之前有意识地重新加载状态。
You can make the rehydration process itself auditable. Instead of silently reading the files and resuming, have the agent write down what it learned:你可以使再水化过程本身可审计。不要让智能体静默读取文件并恢复，而是让它写下它学到的东西：
Read the progress file and the JSONL artifact. Write a summary of what you learned: what pass is running, what unit is active, what the cursor position is, and how many requirements have been extracted so far. Then continue from there.读取进度文件和JSONL工件。写下你所学到的摘要：正在运行什么遍历，哪个单元处于活动状态，游标位置是什么，到目前为止提取了多少需求。然后从那里继续。
Writing a rehydration summary serves two purposes. It gives you visibility into what the agent understood and whether it rehydrated correctly. And it forces the agent to process the external files explicitly rather than just loading them into context. Explicit processing is more reliable than silent loading because the agent has to commit to an interpretation, and you can read that interpretation and catch mistakes.编写再水化摘要有两个目的。它让你了解智能体理解了什么以及是否正确地进行了再水化。它迫使智能体显式处理外部文件，而不是仅仅将它们加载到上下文中。显式处理比静默加载更可靠，因为智能体必须承诺一种解释，而你可以阅读该解释并发现错误。
You can adapt this approach to any agent workflow where work happens in steps. The specific files and cursor values are particular to my pipeline, but the underlying technique is general: have the agent write its progress to a file after each step, and check that file against its output at the start of every session. And this advice isn’t just for writing agents or skills. Even in a live session with Claude Code, Cursor, or Copilot, you can tell the agent to periodically write a summary of what it’s done and what it plans to do next to a file on disk. If the session crashes or the context gets long enough to compact, you can point a new session at that file and pick up where you left off. The key is getting the state out of the conversation and onto disk before you need it.你可以将这种方法应用于任何工作分步骤进行的智能体工作流程。具体的文件和游标值特定于我的管道，但底层技术是通用的：让智能体在每一步之后将其进度写入文件，并在每个会话开始时将该文件与其输出进行比较。这个建议不仅适用于编写智能体或技能。即使在Claude Code、Cursor或Copilot的实时会话中，你也可以告诉智能体定期将其已完成的工作和下一步计划写入磁盘上的文件。如果会话崩溃或上下文变得足够长以至于压缩，你可以将新会话指向该文件，并从你离开的地方继续。关键是在你需要之前将状态从对话中取出并放到磁盘上。
Context management is an architectural concern上下文管理是一个架构问题
Every technique I’ve described in these articles comes down to the same principle: Important information shouldn’t live only in the agent’s context window. The previous articles covered how to put that information on disk. This one covers how to make the agent aware of its own limitations so it can recover when context pressure gets too high.我在这些文章中描述的每一种技术都归结为同一个原则：重要信息不应只存在于智能体的上下文窗口中。之前的文章涵盖了如何将该信息放到磁盘上。本文涵盖了如何让智能体意识到自己的局限性，以便在上下文压力过高时能够恢复。
An agent that can detect its own degradation and correct for it is fundamentally more reliable than one that just keeps going. When the agent knows how to stop, check itself against ground truth, and reload what it lost, context pressure becomes a recoverable event instead of a slow, silent failure.一个能够检测自身退化并加以纠正的智能体从根本上比一个只是继续运行的智能体更可靠。当智能体知道如何停止、对照真实情况检查自己并重新加载丢失的内容时，上下文压力就变成了一个可恢复的事件，而不是一个缓慢、静默的失败。
This concludes my mini-series trilogy of articles about context management. The first article in this series was about understanding what context is and why it disappears. The second was about getting important information out of the conversation and onto disk before you need it. This one is about closing the loop: making the agent aware of its own limitations so it can detect degradation and recover from it. Together, they add up to treating context as an engineering problem rather than something you hope works out.这结束了我关于上下文管理的迷你系列三部曲。本系列的第一篇文章是关于理解什么是上下文以及它为什么会消失。第二篇是关于在需要之前将重要信息从对话中取出并放到磁盘上。这一篇是关于闭环：让智能体意识到自己的局限性，以便它能够检测退化并从中恢复。它们共同构成了将上下文视为一个工程问题，而不是你希望它能解决的问题。
These are still early days. Context windows will get larger, compaction will get smarter, and some of the workarounds in this article will eventually be unnecessary. But the underlying principle won’t change: If your agent’s ability to do its job depends on information, that information needs to live somewhere more durable than working memory. That was true for my dad’s 32KB core memory at Princeton, it was true for my 640K of conventional RAM, and it’s true for today’s 200K-token context windows.现在仍然是早期阶段。上下文窗口将变得更大，压缩将变得更智能，本文中的一些变通方法最终将变得不必要。但基本原则不会改变：如果你的智能体完成工作的能力依赖于信息，那么这些信息需要存在于比工作记忆更持久的地方。这对我父亲在普林斯顿的32KB磁芯内存成立，对我640K的常规RAM成立，对今天20万个令牌的上下文窗口也成立。
The Quality Playbook and Octobatch are open source projects where these techniques are used in production. Both are built using AI-driven development and available for exploration if you want to see how this looks in practice.Quality Playbook和Octobatch是开源项目，这些技术在生产中使用。两者都是使用AI驱动开发构建的，如果你想看看这在实践中是什么样子，可以探索它们。
Disclosure: Aspects of the approach described in this article are the subject of US Provisional Patent Application No. 64/044,178, filed April 20, 2026, by the author. The open source Quality Playbook project (Apache 2.0) includes a patent grant to users of that project under the terms of the Apache 2.0 license.披露：本文所述方法的某些方面是美国临时专利申请号64/044,178（2026年4月20日提交）的主题，由作者提交。开源Quality Playbook项目（Apache 2.0）包含对该项目用户根据Apache 2.0许可条款的专利授权。
