Harness 工程中的上下文腐化类型

If you've ever worked with an LLM-powered agent long enough for a session to grow, you've probably felt it. Instructions that worked perfectly in a fresh conversation get quietly ignored 15 turns in. The agent starts referencing things it shouldn't. Retrieved snippets that were relevant three queries ago somehow bleed into an answer to a completely different question. Everything looks fine — no errors, no crashes — but the quality of reasoning has visibly degraded. That set of degradations has a name: context rot. And it's not one problem. It's five distinct failure modes that combine, compound, and get worse the more you naively pile things into a bigger and bigger context window. By the end of this article, you'll be able to name all five failure modes, spot which one is affecting your agent when things start feeling "off," and understand why the "bigger context window" pitch doesn't rescue you from any of them. Related reading: I've covered the broader mechanics of how a harness assembles context in Part 5 of my Harness Engineering series. Not required for this article — just there if you want it. Let's get into it. 📚 Want to go deeper on Harness Engineering? If you find this article useful, I've put together two hands-on resources that go further than any single article can: Build a Harness from Scratch — Udemy Course — A self-paced course where I walk you through building a production-grade agentic harness from the ground up, in code. Harness Engineering for AI Agents — Live Maven Workshop — A live, cohort-based workshop for builders who want direct feedback, Q&A, and to work through the material with peers. Both are optional — this article stands on its own. But if you want the full studio-quality version of the material, that's where it lives. What "Context Rot" Actually Means A common mental model treats context like RAM. Fill it up to the limit, and everything fits equally well. Go past the limit, and things break. Simple, digital, binary. That model is wrong. The reality is more like a whiteboard being written on. The more you write, the harder it becomes to see any one thing clearly. Some regions get erased and re-written. Some parts stay legible. Some get covered over by newer content. And the model — reasoning about what's on the whiteboard — makes worse decisions as the board fills up, even before it runs out of space. Context rot is the collective name for the specific ways this degradation happens. It's not one failure — it's five distinct failure modes that combine. Each is worth naming because each has different impact and different remediations. Let's walk through them. The Five Failure Modes 1. Lost in the Middle Models pay more attention to content at the beginning and end of their context than to content in the middle. This is documented in the literature as the "lost in the middle" pattern, and it holds across model families and sizes. Practically: if you inject 20 documents into the context and the relevant one is document #10, the model is more likely to miss it than if the same document were #1 or #20. This isn't about token count — it's about position within the context window. For a real harness, this means: The system prompt (position 0) always gets strong attention. The latest user message (last position) always gets strong attention. Everything in between — tool results from five turns ago, retrieved chunks, session history — gets progressively less attention as it drifts toward the middle. As sessions grow, the "middle" grows. And important content increasingly lands there. A widely-cited prompting response — advocated publicly by Greg Brockman and echoed by many others — is to deliberately duplicate critical instructions at both ends of the context: at the top, and again at the very bottom before the user's latest message. It works because it leverages the two positions the model is guaranteed to attend to. 2. Attention Dilution Attention is a fixed resource. There's only so much of it to go around. When context has 5,000 tokens, each token gets more attention than when context has 50,000 tokens. This is a mechanical property of transformer attention — the softmax over more inputs spreads the weight more thinly. Practically: a specific instruction that shaped behavior perfectly in a short context may be effectively ignored in a long one. Not because the model can't see the instruction — it can — but because it's now competing with more tokens for the same fixed attention budget. For a real harness, this shows up like this: a system prompt that works beautifully in a fresh session may feel like it "loses its grip" 15 turns in, after several tool calls and retrieved-chunk dumps have crowded into the context. The instruction is still there. It just has less relative pull. 3. Distractor Amplification Irrelevant content in context doesn't just fail to help. It actively hurts. The model reasons about what's in context. If there's content that looks like it might relate to the query — but doesn't — the model may incorporate it into its answer anyway. It doesn't reliably filter irrelevance. It reasons over everything present. Practically: a web_search result that returned five snippets, four of which are relevant and one of which is off-topic, may produce reasoning that references the off-topic snippet. And that reference will look confident, coherent, and completely wrong. For a real harness, this compounds fast. Every search returns multiple sources. Every retrieve returns multiple chunks. Unless the harness actively evicts old tool results, all of those distractors accumulate over the course of a session. Chunks that were relevant to the query five turns ago — but aren't relevant now — still sit in context, still get read, still shape reasoning. 4. Repetition Bias Content that appears multiple times in context — even unintentionally — gets weighted more heavily. Repetition signals to the model that something is important. This shows up all over the place: overlapping search snippets across multiple queries, retrieved chunks that overlap because of the chunker's overlap setting, tool results that quote each other. All of these compound. Practically: if the same fact appears in three different snippets returned across two web searches, the model treats it as more certain than a fact that appears once. That may or may not track reality — a widely-repeated fact might be widely wrong. For a real harness, this is especially real for retrieval and web search. Related queries return overlapping content. The same architectural decision or code snippet referenced across three different chunks starts to dominate the model's reasoning — not because it's more true, but because it's more present. 5. Cost and Latency Compounding This one isn't "rot" in the same sense — the model isn't reasoning worse because of this — but it's a real cost. Long context means: Higher per-token API cost. Most model providers charge per input token. A 50,000-token context costs 10× a 5,000-token context, on every call. Higher latency. Attention computation is roughly quadratic in context length. Long contexts take noticeably longer to process. Higher failure rate on limits. Even under the hard token limit, providers sometimes rate-limit or throttle on token throughput. For a real harness, this stacks up brutally. A 30-turn session with heavy retrieval and web-search use can easily hit tens of thousands of tokens per API call. And each turn compounds — the previous turn's cost becomes a floor for the next one. Why "Bigger Context Windows" Doesn't Fix This Model providers keep releasing bigger context windows — 128K, 200K, 1M tokens. Shouldn't that make the problem go away? No. All five failure modes above are properties of how attention works over long context, not properties of hitting the limit. Doubling the context window only doubles the space for attention dilution, doubles the middle, doubles the surface area for distractors. Here's an analogy that makes this concrete. Imagine a diner with three servers. Business is booming, so you expand the floorspace to seat more customers — but you don't hire any more servers. What happens? The three servers are still doing the same amount of work. They're just spread across a bigger room. Every customer waits longer. Every order gets less attention. Some customers get missed entirely because the servers can't physically see them in time. That's exactly what a bigger context window does. The floorspace grows. The attention budget doesn't. Every token — every instruction, every retrieved chunk, every prior message — is one of your customers, and each of them is now competing for the same fixed pool of attention across a much larger space. There's an empirical relationship that's been observed in practice: models with 1M-token context windows routinely perform worse on 500K-token inputs than the same task performs at 50K tokens. The token budget grew. The effective attention span didn't. "Fit within the limit" and "use context well" are different problems. And a harness that treats the latter as if it were the former will keep quietly degrading no matter how much room you give it. So, What Do You Do About It? Context engineering isn't just an assembly problem — it's a management problem. And context rot is the reason. Every failure mode above is a design decision waiting to be made about your harness. What to include. What to compress. What to summarize. What to evict, and when. What to place at the start, what to place at the end, and what to be very careful about placing anywhere in the middle. What to deduplicate before it inflates. What to keep out entirely. If you designed your harness's context assembly logic before knowing the five failure modes existed, it's probably fine at short sessions and quietly rotting on longer ones. If you designed it after, you have a fighting chance. Naming the failure modes is the first step. Actually doing something about them is the ongoing work of context engineering. Happy coding :)