I got a really interesting question last week from Mike Loukides, my editor at Radar, after he read the third part of this trilogy on context management. “Another issue I’ve read about,” Mike asked, “is the tendency for a model to ignore the middle of the context. I’ve seen that particularly for the models with very large context windows. Is there anything to be said about that?”上周，我的 Radar 编辑 Mike Loukides 在阅读了这部上下文管理三部曲的第三部分后，向我提出了一个非常有趣的问题：“我读到的另一个问题是，模型倾向于忽视上下文的中间部分。我在拥有非常大上下文窗口的模型中尤其看到这种情况。对此有什么可说的？”
Excellent question, Mike, and yes, there is. In that same email he pointed out that clearing the context and reloading it with just what’s important does a pretty good job dealing with this “ignore the middle” problem when it happens, but that’s clearly a stopgap.好问题，Mike，答案是肯定的。在同一封邮件中，他指出，清除上下文并仅重新加载重要内容，在处理这种“忽视中间”问题时效果相当不错，但这显然只是权宜之计。
It’s worth a deeper dive into what’s actually happening when an AI starts forgetting what’s in the middle of its context, because the problem is deeper (and more interesting!) than it might seem at first. It turns out that there’s a basic problem that’s fundamental to how LLMs manage context, and we’re still learning about it as an industry. That problem is called a U-shape. There’s been a lot of really interesting research into the U-shape problem recently, and several useful techniques have emerged that can help you manage it. And it’s probably not a coincidence that I’ve had to use all of them in my ongoing experiments with AI-driven development and agentic engineering (even if I didn’t always realize that’s what I was doing at the time).值得深入探讨一下，当 AI 开始忘记上下文中间的内容时到底发生了什么，因为这个问题比表面看起来更深（也更有趣！）。事实证明，LLM 管理上下文的基本问题是根本性的，我们作为行业仍在学习。这个问题被称为 U 形。最近关于 U 形问题的研究非常有趣，已经出现了几种有用的技术可以帮助你管理它。并且我在 AI 驱动的开发和代理工程实验中不断使用这些技术，这并非巧合（即使当时我并未意识到自己在做这些）。
A few weeks ago, in fact, I ran into the exact failure mode that Mike described. I was running the Quality Playbook, my open source code quality engineering skill, and ran into trouble with one of its phases—the one that writes up the bugs the earlier phases find. There’s a part of the bug writeup process where it had just created a file called BUGS.md that had an overview of each of the bugs, and had to create individual writeups for each bug it found. But instead of filling in the details correctly, it produced skeletal-looking stub files, with a generic template that had blank values instead of populated ones.事实上，几周前我正好遇到了 Mike 所描述的那种失败模式。我在运行 Quality Playbook（我的开源代码质量工程技能）时，遇到了一个阶段的麻烦——即写出前面阶段发现的 bug。bug 写作过程的一个环节是，它刚创建了一个名为 BUGS.md 的文件，概述了每个 bug，然后需要为每个发现的 bug 创建单独的写作。但它没有正确填充细节，而是生成了骨架式的存根文件，使用了一个通用模板，里面的值是空白的而不是已填充的。
The thing is, the instructions for how to write a populated writeup were in the prompt. The actual bug data was in BUGS.md. I was absolutely certain that everything the agent needed was sitting in its context window, because I could see that it hadn’t compacted yet, and the skill’s intermediate artifacts let me see that earlier phases had read and reasoned about both files (which I talked about in my last article in this series). But the agent was producing stubs anyway. It really looked like the agent had everything it needed sitting in plain sight, and just wasn’t using the information it had. Frustrating!问题在于，如何编写完整写作的指令在提示中，而实际的 bug 数据在 BUGS.md 中。我确信代理所需的一切都在它的上下文窗口中，因为我看到它还没有进行压缩，技能的中间产物也表明早期阶段已经读取并推理了这两个文件（我在本系列的上一篇文章中谈到过）。但代理仍然生成了存根。看起来代理拥有所有需要的信息，却没有使用这些信息。真让人沮丧！
I thought at the time that the model was just an idiot (which, arguably, was true but beside the point). It turns out that I had run directly into the U-shaped context problem.当时我以为模型只是个笨蛋（这在某种程度上也许是对的，但不是重点）。事实证明，我直接碰到了 U 形上下文问题。
In the previous three articles I covered what context is and why it disappears, how to keep important information in files instead of leaving it in the agent’s context window, and how to detect and recover when context has been compacted out from under you. All three were about losing context, through fragmentation, through compaction, through long sessions that overrun the window. This article is about this entirely different U-shaped failure mode, where the context is still sitting in the window and the model just isn’t using it.在之前的三篇文章中，我介绍了上下文是什么以及为何会消失，如何将重要信息保存在文件中而不是留在代理的上下文窗口，以及如何在上下文被压缩时检测并恢复。三篇文章都围绕上下文丢失——通过碎片化、压缩、以及超出窗口的长会话。本篇文章则讨论一种完全不同的 U 形失效模式，即上下文仍在窗口中，但模型却没有使用它。
The U-shape failure, and why bigger windows don’t fix itU 形失效，以及为何更大的窗口并不能解决它
The U-shape is an active area of academic investigation, so I’m going to start by going into a little bit of that research, because I think it will actually help us pin down what’s going on. I’ll start with an experiment run by Nelson Liu, an AI researcher at Stanford, who tested how language models actually use the contents of long inputs by giving them documents with the relevant answer placed at different positions and measuring whether the model could still find it. An interesting thing his findings show is that the U-shape didn’t appear to be a quirk of a single model. The U-shape showed up across model families, and even models with larger context windows still exhibited it.U 形是学术界活跃的研究领域，所以我先介绍一些相关研究，因为我认为这有助于我们弄清楚到底发生了什么。我将从斯坦福 AI 研究员 Nelson Liu 的实验说起，他通过在不同位置放置相关答案的文档来测试语言模型如何使用长输入，并测量模型是否仍能找到答案。他的发现显示，U 形并非单一模型的怪癖，而是在多个模型家族中出现，即使是拥有更大上下文窗口的模型也会表现出这种现象。
If you have time, it’s actually worth taking a look at the paper that Liu and his team wrote, called “Lost in the Middle: How Language Models Use Long Contexts.” (It’s surprisingly readable for an academic paper.) The result they reported was a robust U-shape: The model performed best when the relevant information was at the beginning of its context window or at the recent end and worst when it was in the middle. Performance on questions where the answer was buried mid-context fell off sharply, even when the answer was sitting right there in plain sight. The field now uses the terms primacy bias and recency bias for those two preferences, and the U-shape is what you get when you plot them together against position.如果有时间，值得一读 Liu 及其团队撰写的论文《Lost in the Middle: How Language Models Use Long Contexts》（《迷失于中部：语言模型如何使用长上下文》）。（这篇学术论文出奇地易读。）他们报告的结果是一个稳健的 U 形：模型在上下文窗口的开头或最近的结尾时表现最佳，而在中部时表现最差。即使答案就在眼前，位于中部的问答性能也会急剧下降。该领域现在将这两种偏好称为首位偏差（primacy bias）和近期偏差（recency bias），而 U 形则是将它们相对于位置绘制在一起的结果。
I’m going to lean a little into academia here, because a lot of researchers are still learning about how LLM context actually works and what behavior has emerged in it.我将在这里稍微倾向学术，因为许多研究者仍在学习 LLM 上下文的实际工作方式以及其中出现的行为。
One reason the U-shape matters more than “just another LLM quirk” is that recent research has started showing it’s a structural property of how transformers work, not a learned artifact. A 2025 ICML paper called “On the Emergence of Position Bias in Transformers” explained it as the equilibrium between two opposing forces inside the model: The causal mask amplifies the influence of the first few tokens (the primacy bias), while position encodings like RoPE heavily weight the tokens closest to where the model is generating (the recency bias). The middle is where those two forces cancel out. A 2026 paper by Borun Chowdhury, a researcher at Meta, called “Lost in the Middle at Birth: An Exact Theory of Transformer Position Bias,” took the argument even further by proving mathematically that the U-shape exists at the moment of initialization, before any training has happened, with random weights.U 形之所以比“又一个 LLM 怪癖”更重要，是因为最近的研究表明它是 transformer 工作的结构性属性，而非学习得到的副产物。2025 年的 ICML 论文《On the Emergence of Position Bias in Transformers》将其解释为模型内部两股相反力量的平衡：因果掩码放大了前 few token 的影响（首位偏差），而 RoPE 等位置编码则强烈加权模型生成位置最近的 token（近期偏差）。中部正是这两股力量相互抵消的地方。2026 年 Meta 研究员 Borun Chowdhury 的论文《Lost in the Middle at Birth: An Exact Theory of Transformer Position Bias》进一步证明，U 形在模型初始化时就已存在，权重仍是随机的。
That matters because the natural assumption about large context windows is that more room means fewer problems. Most of today’s frontier models give you a million tokens or more, with some pushing well past two million, and some have made real progress on the simplest version of the lost-in-the-middle test, the needle-in-a-haystack benchmark, where the model has to retrieve a single sentence buried in a long document. Google’s Gemini 1.5 Pro reported near-perfect single-needle recall at 1M tokens, and current Gemini 3 models are similar.这很重要，因为人们普遍认为更大的上下文窗口意味着更少的问题。如今的前沿模型通常提供一百万 token 甚至更多的窗口，有的甚至超过两百万，并且在最简单的“迷失于中部”测试——针刺干草堆基准（需要检索长文档中埋藏的单句）上取得了实质性进展。Google 的 Gemini 1.5 Pro 在 1M token 时报告了几乎完美的单针召回率，当前的 Gemini 3 系列模型表现相似。
So the accurate version of “bigger windows don’t fix it” is this: Bigger windows have made simple single-fact retrieval much better. They have not made long-context agent work reliable by default. A two-million-token window means a bigger middle to fall into.因此，所谓“更大的窗口并不能解决它”的准确说法是：更大的窗口显著提升了单事实检索的效果，但并未让长上下文代理默认可靠。两百万 token 的窗口意味着更大的中部可供掉入。
The important idea that’s emerging here is that it’s increasingly looking like the U-shape isn’t just a bug in today’s models that will eventually be worked out or trained away by more data or better fine-tuning. Instead, it seems like the U-shape may actually be a geometric property of the LLM architecture itself.这里出现的关键观点是，U 形似乎并非当今模型的一个可以通过更多数据或更好微调逐步消除的 bug，而更像是 LLM 架构本身的几何属性。
In other words, we’re all going to have to deal with the U-shape. And that means we need techniques for managing it, and any effective technique we use isn’t likely to become obsolete any time soon. And that’s my goal in this article: to show you the techniques that have emerged for managing U-shaped context memory loss that you can use today in your own work.换句话说，我们都必须面对 U 形。这意味着我们需要管理它的技术，而任何有效的技术都不太可能很快过时。这也是本文的目标：展示已经出现的、可用于今天工作的 U 形上下文记忆丢失管理技术。
Five techniques to help with U-shaped context problems帮助解决 U 形上下文问题的五种技术
The previous article in this series laid out a pattern for detecting and recovering from context loss, which I called externalize-recognize-rehydrate. The techniques below extend the same discipline to the lost-in-the-middle problem. The principle I keep coming back to is that working memory is untrustworthy, and the discipline that follows from it is to externalize what matters, curate what stays in context, and verify what the agent claims to know against what’s on disk. The five techniques are how I do that in practice, and each one is drawn from a real moment in the Quality Playbook’s development.本系列前一篇文章提出了检测和恢复上下文丢失的模式，我称之为外部化‑识别‑再水化。下面的技术将同样的纪律扩展到“迷失于中部”问题。我的核心原则是工作记忆不可靠，随之而来的纪律是：外部化重要信息、策划保留在上下文中的内容、并在关键时刻将代理的声明与磁盘上的真实数据核对。以下五种技术是我在实践中使用的，每一种都来源于 Quality Playbook 开发过程中的真实场景。
Curate, don’t accumulate策划，而不是累积
This is the technique which, in its most brute-force form, is exactly what Mike talked about in his email to me: just clear the context and reload it with just what matters, periodically and deliberately. In other words, don’t trust an accumulated session to stay coherent; build the artifact, then start fresh against it. And if you have the AI write down the important parts of the context (like we’ve talked about throughout this series), then you can start a new session with refreshed AI that has a more targeted, curated context as a starting point.这是一种最直接的技术，正是 Mike 在给我的邮件中提到的：定期且有意识地清除上下文并仅重新加载重要内容。换句话说，不要指望累积的会话保持连贯；先生成产物，然后基于它重新开始。如果让 AI 记录上下文中的重要部分（正如本系列一直在讨论的），你就可以用更有针对性、策划好的上下文作为起点，开启新会话。
I ran into this during the v1.5.2 release prep for the Quality Playbook. I was using a long Claude Code session that had been working through a series of fixes. But I noticed that it was just starting to show its age: It had forgotten a couple of things it should know, and its thinking times were starting to grow.我在 Quality Playbook 的 v1.5.2 发行准备期间遇到了这种情况。当时我使用的是一个运行了很久的 Claude Code 会话，已经处理了一系列修复。但我注意到它开始显露老态：忘记了一些本该记住的细节，思考时间也在增长。
When it came time to land the final four fixes for the release, I worked with the AI to write a context brief, or a separate document with everything the implementing session needed. The question was whether to keep using the existing session, which already “knew” the codebase from the earlier work, or open a fresh CLI session and point it at the brief. I asked another session what to do:在为发行敲定最后四个修复时，我与 AI 合作编写了一个上下文简报，或说是一个包含实现会话所需全部信息的独立文档。问题是是继续使用已有的会话（它已经“了解”了代码库），还是打开一个全新的 CLI 会话并指向该简报。我向另一个会话询问该怎么做：
Should we run that in a new cli session rather than continue my currentclaude code session that has the existing context?我们应该在新的 CLI 会话中运行，而不是继续使用当前已有上下文的 Claude Code 会话吗？
The AI gave me a good answer—start a fresh session, using a starting prompt to read the brief—and it gave three reasons that have stuck with me. First, the brief was self-contained, including file paths, line numbers, exact diffs, regression test bodies, and preflight greps. Anything the new session needed to know was already there, and continuing context bought nothing. Second, fresh context is stricter about adherence. A session that already “knows” the codebase tends to skim the new instructions and improvise from prior assumptions. Surgical fixes are exactly the case where you want the agent to read the brief carefully rather than rely on memory of what felt right last round. And third, the audit trail: The brief is the artifact, and the implementing session is reproducible from just the brief. If the same work has to be redone in six months by a different model, you point at the brief and say, “This is the input.”AI 给了我一个很好的答案——启动一个新会话，使用起始提示读取简报，并给出了三个让我印象深刻的理由。第一，简报是自包含的，包含文件路径、行号、精确 diff、回归测试体以及预检 grep。新会话需要了解的一切都已经在简报里，继续使用旧上下文毫无收益。第二，新的上下文对遵循指令更严格。已经“了解”代码库的会话往往会略读新指令并依据先前假设即兴发挥。手术式的修复正是需要代理仔细阅读简报而不是凭记忆凭感觉操作的场景。第三，审计轨迹：简报是产物，实现会话可以仅凭简报复现。如果同样的工作六个月后要由另一模型完成，只需指向简报并说：“这就是输入”。
The approach worked really well. I was able to pick up development seamlessly, and the model’s memory problems disappeared.这种做法效果极佳。我能够无缝继续开发，模型的记忆问题也随之消失。
Position critical information at the edges将关键信息放在边缘位置
The U-shape says the model attends best to the beginning and end of its context. The natural move is to put your most load-bearing information in those positions and keep the middle for things you don’t need the model to focus on. Anything important that lives only in the middle of an accumulated context tends to slide out of attention.U 形表明模型对上下文的开头和结尾关注度最高。自然的做法是把最关键的信息放在这些位置，而把中部留给不需要模型重点关注的内容。任何仅位于累积上下文中部的重要信息往往会被忽视。
The other side of this technique is what not to put in the middle. If something matters, don’t bury it in a long preamble of context you’ve been accumulating; move it to the edges, restate it where the model will act on it, and let the middle absorb the less important material. Luckily, there’s a useful technique that can help with this problem.这项技术的另一面是：不要把重要内容埋在长前置上下文里；如果它重要，就把它移到边缘，在模型将要采取行动的地方重新陈述，并让中部承载次要信息。幸运的是，有一种实用技术可以帮助解决这个问题。
In Claude Code, for example, one really clean way to put information at the beginning of context is to use the system prompt. The CLI gives you --append-system-prompt for exactly this. (Most of the other providers’ CLI tools have similar options.) If you put your brief (or selected parts of it) there, the agent will attend to it strongly throughout the session, and that in turn will help keep the per-turn user prompt focused on the action you want the agent to take right now.以 Claude Code 为例，将信息放在上下文开头的一个干净方式是使用系统提示。CLI 提供了 --append-system-prompt 参数正是为此设计的。（大多数其他提供商的 CLI 工具也有类似选项。）如果把简报（或其中选定的部分）放在那里，代理将在整个会话期间强烈关注它，这也有助于让每轮用户提示聚焦于当前需要代理执行的操作。
Short sessions over long ones短会话胜于长会话
Don’t run one long session. Run many short ones, each reading fresh from disk. This will help you iterate on your brief and your external development context, so instead of relying on an opaque context window, you have a visible and constantly changing set of documents that give you a lot more visibility into—and control over—your AI’s context.不要运行一次长会话。运行多个短会话，每次都从磁盘读取新内容。这有助于你迭代简报和外部开发上下文，从而不依赖不透明的上下文窗口，而是拥有一套可见且不断变化的文档，提供对 AI 上下文的更多可视性和控制。
Something useful I started doing was taking all my chat history from Gemini, ChatGPT, Claude, and Cowork and putting it into a single folder I could keep updated and indexed for fast search. I built out an entire system to manage this, which turns out to be a great tool when I’m writing articles like this, because I can search through my development history for specific examples and techniques that I’ve used. The system uses Haiku 4.5 to read through chat history, summarize what happened, and create an index. Haiku turned out to be a smart enough model to read each individual interaction in a chat and write a useful index entry for it. But the model being smart enough to do one summary didn’t mean its context management could keep up across all 18,000 records. I ran smack into the U-shape problem.我做的一件有用的事是把 Gemini、ChatGPT、Claude 和 Cowork 的所有聊天记录收集到一个文件夹，保持更新并建立索引以便快速搜索。我构建了一个完整的系统来管理这些记录，这在写本文时非常有帮助，因为我可以在开发历史中搜索特定的示例和技术。系统使用 Haiku 4.5 读取聊天记录，概括发生的事情并创建索引。Haiku 足够聪明，能够读取每一次交互并为其写出有用的索引条目。但模型能够进行一次概括并不意味着它的上下文管理能够在 18,000 条记录中保持同步。我撞上了 U 形问题。
The first attempt tried to keep dedupe state and progress counts in the model’s head, and it failed spectacularly. The model really didn’t want to keep track of specific deterministic things like accurate numbers or the current state. Haiku 4.5, in particular, seems especially bad at this. What worked was reframing the architecture entirely. Here’s the actual prompt that I gave it to fix the problem:第一次尝试试图在模型内部保存去重状态和进度计数，结果惨败。模型真的不想跟踪具体的确定性信息，比如准确的数字或当前状态。尤其是 Haiku 4.5 在这方面表现尤为糟糕。有效的做法是彻底重新构建架构。以下是我给它的实际提示，用来解决问题：
ok, so we need context management. it doesn't need to remember things,it just needs to write them down as they go. we had this same contextmanagement problem with Quality Playbook, when it was running out ofcontext. Just write down after each message.ok, so we need context management. it doesn't need to remember things, it just needs to write them down as they go. we had this same context management problem with Quality Playbook, when it was running out of context. Just write down after each message.
The protocol I greenlit for the full run made the short-session discipline explicit:我为完整运行批准的协议明确了短会话的纪律：
- Resume processing from the cursor recorded in progress.json, working through each input file in order.从 progress.json 中记录的光标位置恢复处理，按顺序遍历每个输入文件。
- Update progress.json after every line.每处理一行后更新 progress.json。
- Expect to run out of context well before finishing—that’s fine. Just stop cleanly after each step (or a group of steps), then spin up a fresh session that reads progress.json and continues.预计在完成之前会耗尽上下文——这没关系。每一步（或一组步骤）结束后干净地停止，然后启动一个读取 progress.json 并继续的全新会话。
- When all files are complete, set status: “complete” in progress.json and report back.当所有文件完成后，在 progress.json 中将状态设为 “complete”，并报告回去。
Item 3 is the technique in one line: expect context loss, so make sure you’ve written your state down, and build fresh restarts into the process. The technical details, like spinning up subagents, orchestrating with script, etc., will change, but the core idea stays the same. In a lot of ways, you can think of treating the agent like a pipe, not a database. The state lives on disk, and the session is something you throw away and replace.第 3 条是一行概括的技术：预期会出现上下文丢失，所以确保已将状态写下来，并在流程中构建全新重启。技术细节如启动子代理、脚本编排等会变化，但核心思想保持不变。很多情况下，你可以把代理当作管道，而不是数据库。状态保存在磁盘，会话则是可以丢弃并替换的临时体。
Restate key info close to the point of use在使用点附近重新陈述关键信息
When the model needs a constraint to apply right now, repeat it right now. Don’t trust an instruction from earlier in the session to carry forward through the middle of the context.当模型需要立即应用约束时，立刻重复该约束。不要指望会话早期的指令能够在上下文中部持续有效。
This is the technique that fixed the problem I opened the article with, where the Quality Playbook seemed to forget everything it had just written into a file called BUGS.md and produced stubs when it needed to write the same information into more detailed files, and instead writing generic blank templates with the bug-specific fields left blank.这正是解决本文开头提到的问题的技术：Quality Playbook 似乎忘记了刚写入 BUGS.md 的所有信息，导致在为更详细的文件写入时只生成了空白模板，而不是填充了 bug‑specific 字段的内容。
The fix was to restate the read-the-source rule right before the action that needed it, using this prompt:修复方法是在需要执行动作之前重新陈述读取源文件的规则，使用以下提示：
Before writing BUG-NNN.md, re-read the BUG-NNN entry in BUGS.md.Copy the Spec basis, Minimal reproduction, Location, Expected behavior,Actual behavior, Regression test name, and Patches fieldsfrom that entry into the writeup. Do not paraphrase from memory.在编写 BUG‑NNN.md 之前，重新阅读 BUG‑NNN 在 BUGS.md 中的条目。将该条目的 Spec basis、Minimal reproduction、Location、Expected behavior、Actual behavior、Regression test name 和 Patches 字段复制到写作中。不要凭记忆改写。
“Do not paraphrase from memory” is the line that did the actual work. The instruction couldn’t trust the agent’s memory of what BUGS.md said, even though BUGS.md was sitting right there in the context window. So the instruction forced a fresh read of the file at the moment of writing. The restatement and the fresh-read together fixed the bug.“不要凭记忆改写”这句话起到了关键作用。指令不再信任代理对 BUGS.md 内容的记忆，即使 BUGS.md 正在上下文窗口中。于是指令强制在写入时重新读取文件。重新陈述加上即时读取共同解决了 bug。
The same pattern applies any time a rule was stated earlier in the session and the model needs to act on it now. Restate the rule next to the action, and force the model back to the source rather than letting it work from memory.同样的模式适用于任何在会话早期声明的规则，需要模型现在执行的情况。把规则放在动作旁边，并强制模型回到源文件，而不是依赖记忆。
Test the middle测试中部
The previous four techniques are about avoiding lost-in-the-middle failures. This one is about catching them. If you don’t know whether the agent is actually using the information you think it’s using, find out, with a deterministic check rather than a judgment call.前四种技术旨在避免“迷失于中部”失效，这一技术则用于捕捉它们。如果你不确定代理是否真的在使用你认为它在使用的信息，就用确定性的检查而不是主观判断来验证。
The pattern is the one I used in the Haiku summarizer that I described earlier: compare what the agent claims to know against what’s on disk. You have something the agent claims to know (its progress, its current state, the latest version of a rule), and you have something on disk that’s the ground truth (a file, a log, a database record). At the moment the agent’s claim has to be trusted, you check it.模式与我之前描述的 Haiku 摘要器相同：将代理声称知道的内容与磁盘上的真实数据进行比对。你有代理声称知道的东西（进度、当前状态、最新规则），也有磁盘上的真相（文件、日志、数据库记录）。在需要信任代理声明的时刻，进行比对。
In the summarizer’s resume protocol, every new session started by cross-checking progress.json against the actual last line written to the summary file, and the agent printed a checkpoint report when it did—at session start, and periodically through the run. A representative one looked like this:在摘要器的恢复协议中，每个新会话都会交叉检查 progress.json 与实际写入摘要文件的最后一行，并在会话开始以及运行期间定期打印检查点报告。一个代表性的报告如下：
Checkpoint Report:
✓ progress.json confirmed: cursor for cowork_04_06 is at 238, status is"running"
✓ Disk state verified: Last line in summaries/cowork_04_06.md is [237]assistant: Tool invocation repeating chat file read.Discrepancy noted: The prior session left a bulk note claiming records
238–296 are duplicates but didn't write individual lines for them. Peryour instructions, I must write one line per record, even for duplicates,in the format [idx] <sender>: Duplicate of record [X] (<note>).Checkpoint Report:✓ progress.json confirmed: cursor for cowork_04_06 is at 238, status is "running"✓ Disk state verified: Last line in summaries/cowork_04_06.md is [237] assistant: Tool invocation repeating chat file read. Discrepancy noted: The prior session left a bulk note claiming records 238–296 are duplicates but didn't write individual lines for them. Per your instructions, I must write one line per record, even for duplicates, in the format [idx] <sender>: Duplicate of record [X] (<note>).Status: Cursor matches disk state. Ready to resume from record 238.
Status: Cursor matches disk state. Ready to resume from record 238.
The agent doesn’t need to introspect whether it lost context, only to compare two files. When they agree, the agent proceeds; when they disagree, the agent flags the discrepancy and stops before adding any new work on top of a broken state. Disagreement is the signal.代理不需要自我检查是否丢失上下文，只需比较两个文件。当它们一致时继续；不一致时标记差异并在基于错误状态继续之前停止。差异即为信号。
You can build this kind of check into any agent that does multistep work. Pick something the agent has to track, pick the file that’s the source of truth for it, and have the agent compare the two at every session start. When the agent’s view of the world drifts from the file, you find out before the drift becomes a buried bug.你可以在任何执行多步骤工作的代理中构建这种检查。选取代理必须跟踪的事项，选取对应的真相文件，在每次会话开始时让代理比较两者。若代理的世界观与文件不符，你将在漂移成为潜在 bug 之前发现问题。
The discipline behind these techniques这些技术背后的纪律
When I built the Quality Playbook’s multi-phase architecture, I was solving the compaction problem. Long pipeline runs were filling the context window and triggering silent compaction in the middle of work. Breaking the pipeline into separate phases that read fresh from disk and stopped after each phase fixed it.当我构建 Quality Playbook 的多阶段架构时，我在解决压缩问题。长流水线运行会填满上下文窗口并在工作进行中触发静默压缩。将流水线拆分为读取磁盘并在每个阶段结束后停止的独立阶段解决了该问题。
What I didn’t realize until later was that the same architecture also helps with the lost-in-the-middle problem. Each phase has its own short, focused context, with the phase brief at the beginning and the latest progress update at the end, so there’s almost no middle for information to fall into. The architectural move that helped with working memory disappearing turns out to also help with working memory being there and unused.我后来才意识到，同样的架构也有助于解决“迷失于中部”问题。每个阶段都有自己的短小、聚焦的上下文，阶段简报位于开头，最新进度更新位于结尾，几乎没有中部可供信息掉入。帮助工作记忆不消失的架构同样帮助了工作记忆虽在却未被使用的情况。
That’s the lesson I want to land. Both failure modes, context loss and lost-in-the-middle, are problems of working-memory unreliability, and the discipline that addresses them is the same: keep the working set small, put the load-bearing information at the edges of the window, and check the agent’s claims against ground truth on disk when it matters.这就是我想传达的教训。上下文丢失和迷失于中部这两种失效模式本质上都是工作记忆不可靠的问题，解决它们的纪律是相同的：保持工作集小，将关键信息放在窗口边缘，并在关键时刻将代理的声明与磁盘上的真相核对。
Context windows will keep getting bigger, and compaction will get smarter. Some of the techniques in these four articles may eventually be unnecessary. But the underlying constraint won’t disappear. After all, we’ve added a lot more RAM to our computers since the 1MB 286 I wrote about in the last article, and memory management has gotten much more complex since then. And many of these problems are structural; for example, it’s increasingly looking like the U-shape itself is a geometric property of the transformer architecture, not a training artifact that more compute will smooth out.上下文窗口会越来越大，压缩也会更智能。这四篇文章中的一些技术未来可能不再必要。但底层约束不会消失。毕竟，自从我在上一篇文章中提到的 1 MB 286 以来，计算机的 RAM 已大幅增加，内存管理也变得更复杂。而且这些问题很多是结构性的；例如，U 形本身越来越像是 transformer 架构的几何属性，而不是可以通过更多算力平滑的训练副产物。
The bottom line is that 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 32 kilobytes of core memory at Princeton in the 1970s, it was true for my 640 kilobytes of conventional RAM on my 286 in the 1980s, it was true for the 200K-token windows in last year’s models, and it will be true for whatever comes next.底线是，如果你的代理的工作依赖于信息，那么这些信息必须存放在比工作记忆更持久的地方。这一点在我父亲 1970 年代在普林斯顿使用的 32 KB 核心存储、我 1980 年代 286 上的 640 KB 常规 RAM、去年模型的 200 K‑token 窗口以及未来的任何模型中都成立。
