Why Does Your AI Coding Agent Start Forgetting What It Was Doing?

为什么你的 AI 编程助手会开始“健忘”？

I’ve been working with AI coding agents for quite a while, and there’s one behavior that keeps bothering me. At first, everything looks fine. The agent understands the task, reads the error, finds the relevant file, makes a change, runs the test, and moves forward. Then, after several iterations, something strange can happen. The agent starts going back to things that have already been fixed. It reads old errors again. It investigates files that are no longer relevant. Sometimes, it even starts working on something that was already completed instead of focusing on the part that is still broken. And the first thing we usually think is: “The model is getting stupid.” But I’m not convinced that’s always the real problem.

我使用 AI 编程助手已经有一段时间了，有一个行为一直困扰着我。起初，一切看起来都很正常：助手理解任务、读取错误、找到相关文件、进行修改、运行测试并继续推进。然而，经过几次迭代后，奇怪的事情发生了：助手开始回头处理那些已经修复的问题，重新读取旧的错误，调查不再相关的文件。有时，它甚至会开始处理已经完成的任务，而不是专注于仍然损坏的部分。我们通常的第一反应是：“模型变笨了。”但我并不认为这总是问题的根源。

The context gets messy

上下文变得混乱

When an AI coding agent works on a real software project, it doesn’t only see the code. It also sees a lot of other information: framework logs, stack traces, dependency output, tool responses, terminal output, previous errors, repeated information, files from previous investigations, and debugging attempts that are already finished. And this happens over and over again. A long debugging session can look something like this: Task ↓ Error ↓ Tool call ↓ Framework logs ↓ Stack trace ↓ Relevant code ↓ Patch ↓ Test ↓ New error ↓ More logs ↓ More tool output ↓ Another patch ↓ Another test ↓ … The agent keeps accumulating information. Eventually, the problem may not be that the context window is too small. It may simply be that the context has become too noisy.

当 AI 编程助手处理真实的软件项目时，它看到的不仅仅是代码，还有大量其他信息：框架日志、堆栈跟踪、依赖项输出、工具响应、终端输出、之前的错误、重复的信息、之前调查过的文件以及已经结束的调试尝试。这种情况会反复发生。一次漫长的调试过程可能看起来像这样：任务 ↓ 错误 ↓ 工具调用 ↓ 框架日志 ↓ 堆栈跟踪 ↓ 相关代码 ↓ 补丁 ↓ 测试 ↓ 新错误 ↓ 更多日志 ↓ 更多工具输出 ↓ 另一个补丁 ↓ 另一个测试 ↓ …… 助手不断积累信息。最终，问题可能不在于上下文窗口太小，而仅仅是因为上下文变得太嘈杂了。

A bigger context window doesn’t automatically solve this

更大的上下文窗口并不能自动解决这个问题

This is something I’ve been thinking about for a while. Even if an LLM has a very large context window, an agent can still fill that context with information that is no longer useful. So the question isn’t only: “How much information can the model handle?” It is also: “How much of that information is actually useful right now?” Imagine an agent is debugging a large application. Early in the process, it discovers a problem in the authentication middleware. It fixes the issue. The tests pass. The agent moves on. Ten iterations later, that entire investigation is still sitting somewhere in the conversation alongside old logs, tool outputs, stack traces, and previous debugging attempts. The agent can still see it. But the useful state is much simpler: Authentication middleware → DONE; Database transaction → STILL BROKEN. That distinction matters. If everything remains in the context without a clear representation of what has already been resolved, the agent has to continuously work through information that may no longer be relevant to the current problem. And that’s where things get interesting.

这是我思考了一段时间的问题。即使大语言模型（LLM）拥有非常大的上下文窗口，助手仍然会用不再有用的信息填满它。因此，问题不仅在于“模型能处理多少信息？”，还在于“其中有多少信息在当前是有用的？”想象一下，一个助手正在调试一个大型应用程序。在过程早期，它发现了身份验证中间件中的一个问题并修复了它，测试通过了，助手继续前进。十次迭代后，整个调查过程仍然存在于对话的某个地方，伴随着旧的日志、工具输出、堆栈跟踪和之前的调试尝试。助手仍然能看到它。但有用的状态其实很简单：身份验证中间件 → 已完成；数据库事务 → 仍然损坏。这种区别很重要。如果所有内容都保留在上下文中，而没有明确表示哪些已经解决，助手就必须不断地处理那些可能与当前问题不再相关的信息。这就是事情变得有趣的地方。

This is why I started building Tokenectomy

这就是我开始构建 Tokenectomy 的原因

Tokenectomy started from a simple idea: What if we process the information before giving it to the agent? Instead of blindly passing everything produced by the environment back into the model, we can try to: remove unnecessary noise, keep the relevant information, extract useful context, preserve important state, redact sensitive information, and reduce irrelevant output.

Tokenectomy 源于一个简单的想法：如果我们先处理信息再交给助手会怎样？与其盲目地将环境产生的所有内容传回模型，我们不如尝试：去除不必要的噪音、保留相关信息、提取有用的上下文、保存重要状态、屏蔽敏感信息并减少无关输出。

The goal isn’t to make the underlying model magically smarter. The goal is to make the information surrounding the model more useful. Tokenectomy isn’t just about saving tokens. This is an important distinction. At first glance, something that removes unnecessary context sounds like a token optimization tool. But I’m more interested in what happens after the cleanup. If an agent receives less irrelevant information, does it make fewer unnecessary tool calls? Does it repeat fewer investigations? Does it stay focused on the remaining problem for longer? Does its performance degrade less as the debugging session becomes longer? Those are much more interesting questions to me than simply: “How many tokens did we save?”

目标不是让底层模型变得神奇地聪明，而是让模型周围的信息变得更有用。Tokenectomy 不仅仅是为了节省 Token，这一点很重要。乍一看，去除不必要上下文的东西听起来像是一个 Token 优化工具，但我更关心清理之后会发生什么。如果助手接收到的无关信息更少，它是否会减少不必要的工具调用？是否会减少重复调查？是否能更长时间地专注于剩余的问题？随着调试时间的延长，其性能下降是否会减缓？对我来说，这些问题比单纯的“我们节省了多少 Token？”要有趣得多。

I’m not saying context noise is always the problem

我并不是说上下文噪音总是问题的根源

This is important. I’m not claiming that every AI agent failure is caused by messy context. Agents can fail for many different reasons. The model can misunderstand the task. A tool can return bad information. The generated patch can be incorrect. The test environment can be broken. The agent can simply make a bad reasoning decision. Context noise is only one possible factor. But I’ve repeatedly seen situations where an agent starts revisiting old work during long debugging sessions. So instead of saying: “AI agents forget because their context gets messy.” I’d rather ask: “What happens if we deliberately remove irrelevant context during a long debugging trajectory?” That’s something we can actually test.

这一点很重要。我并不是说每一个 AI 助手的失败都是由混乱的上下文引起的。助手可能会因为许多不同的原因而失败：模型可能误解了任务、工具可能返回了错误信息、生成的补丁可能不正确、测试环境可能损坏，或者助手可能仅仅是做出了错误的推理决策。上下文噪音只是一个可能的因素。但我反复观察到，在漫长的调试过程中，助手会开始重温旧的工作。因此，与其说“AI 助手因为上下文混乱而健忘”，我更愿意问：“如果我们在一长串调试轨迹中刻意移除无关的上下文，会发生什么？”这是我们可以实际测试的东西。

Let’s measure it

让我们来衡量一下

If this idea is real, it should show up in the data. For example: How many tokens are sent to the model? How many iterations are required? How often does the agent repeat completed work? How often does it call irrelevant tools? How often does it revisit previously resolved errors? Does the final patch pass the tests? How does performance change as the debugging session gets longer? Does context cleaning reduce that degradation? The goal isn’t to make a nice-looking demo. The goal is to find out whether this actually changes the behavior of an agent. That’s where Kronumos comes in. I’m also building Kronumos, a specialized software-repair agent, to experiment with this idea in a more…

如果这个想法是成立的，它应该会体现在数据中。例如：发送给模型的 Token 数量是多少？需要多少次迭代？助手重复已完成工作的频率如何？它调用无关工具的频率如何？它重温之前已解决错误的频率如何？最终的补丁是否通过了测试？随着调试时间的延长，性能如何变化？上下文清理是否减少了这种性能下降？目标不是做一个漂亮的演示，而是找出这是否真的改变了助手的行为。这就是 Kronumos 的用武之地。我还在构建 Kronumos，这是一个专门的软件修复助手，旨在以更……的方式试验这个想法。