Coding Agents Don’t Need Longer History — They Need Intent Continuity

编程智能体不需要更长的历史记录——它们需要意图连续性

TL;DR: I built a complete, working implementation in pure Python and shared actual benchmark numbers from real runs (no simulated data). The core lesson: just pulling up past history isn’t the same as knowing what’s actually still accurate. A basic search setup only grabbed 57% of the requirements a coding agent needed. Adding a verification layer pushed that to 100%. Out of 8 tasks, the baseline got zero right, basic search got 4, and intent-aware search nailed all 8. I did all of this with zero embeddings, zero vector databases, and absolutely no LLM calls in the pipeline. I also own up to a bug in my original experiment design that almost made my results look way better than they actually were.

简而言之：我用纯 Python 构建了一个完整、可运行的实现，并分享了来自实际运行的基准测试数据（非模拟数据）。核心教训是：仅仅调取历史记录并不等同于知道哪些信息仍然准确。基础搜索设置仅抓取了编程智能体所需需求的 57%，而增加验证层后，这一比例达到了 100%。在 8 项任务中，基准模型全部失败，基础搜索完成了 4 项，而意图感知搜索则全部成功。我完成这一切没有使用任何嵌入（embeddings）、向量数据库，且流程中完全没有调用大语言模型（LLM）。此外，我也承认了我在最初实验设计中的一个漏洞，它差点让我的结果看起来比实际情况好得多。

Why More History Isn’t Enough

为什么更长的历史记录是不够的

I set up a coding agent workflow that worked perfectly at first. But once a project got long enough, it started causing problems. When a project passed a few dozen steps, core rules began vanishing. No one deleted them. The context window was not full. Those rules were still technically sitting in the chat logs. They just dropped off the radar because new requests did not trigger the agent to check if an older decision still mattered.

我建立了一个编程智能体工作流，起初运行得非常完美。但当项目变得足够长时，问题就开始出现了。当项目超过几十个步骤后，核心规则开始“消失”。没有人删除它们，上下文窗口也没有满。从技术上讲，这些规则仍然存在于聊天记录中。它们只是被忽略了，因为新的请求没有触发智能体去检查旧的决策是否仍然重要。

For instance, you might tell the agent on day one to never expose internal database IDs in API responses. Sixty messages later, you ask it to build a new authentication flow. That new request says nothing about IDs. Since the agent lacks a clear reason to look back, it skips that step and ships an endpoint leaking the exact data you tried to protect. This is not a made up scenario. It is the actual test case I used for this article. Below, I will show you how three different methods handle this exact problem.

例如，你可能在第一天告诉智能体：永远不要在 API 响应中暴露内部数据库 ID。六十条消息后，你要求它构建一个新的身份验证流程。这个新请求没有提到 ID。由于智能体缺乏明确的回溯理由，它跳过了这一步，并发布了一个泄露了你试图保护的数据的端点。这不是虚构的场景，而是我为本文使用的实际测试案例。下面，我将展示三种不同的方法如何处理这个问题。

Every result shown here comes from actual test runs using Python 3.12 with no outside dependencies. You can clone the repo and run run_experiment.py to reproduce the numbers yourself, unless I specifically call out an isolated test.

此处展示的所有结果均来自使用 Python 3.12 且无外部依赖的实际测试运行。你可以克隆仓库并运行 run_experiment.py 来亲自复现这些数据，除非我特别说明了某个孤立测试。

Complete Code: https://github.com/Emmimal/intent-continuity/ 完整代码： https://github.com/Emmimal/intent-continuity/

What Intent Continuity Actually Means

什么是真正的“意图连续性”

Terms get mixed up here pretty fast, so let us clear up the definitions. Standard RAG, introduced by Lewis et al. (2020) [1], connects a language model to a retrieval system that finds relevant information from an external knowledge source. The basic question is simple: what information is relevant to this query?

这里的术语很容易混淆，所以让我们理清定义。由 Lewis 等人 (2020) [1] 引入的标准 RAG（检索增强生成），将语言模型连接到一个从外部知识源查找相关信息的检索系统。其基本问题很简单：什么信息与此查询相关？

Bigger context windows let models hold more text at once. But that size does not make the model check an old rule buried sixty turns back. Liu et al. (2023) [2] pointed out that models miss details stuck in the middle of long prompts, even within their stated limits. Yet that misses the real point. Even with total recall, a model still has to connect an old rule about database IDs to a new login task. Memory failure is not the problem. Deciding what matters is.

更大的上下文窗口让模型能一次容纳更多文本。但这种容量并不会让模型去检查埋藏在六十轮对话之前的旧规则。Liu 等人 (2023) [2] 指出，即使在规定的限制内，模型也会遗漏长提示词中间的细节。但这忽略了重点。即使拥有完全的回忆能力，模型仍然需要将关于数据库 ID 的旧规则与新的登录任务联系起来。问题不在于记忆失败，而在于如何决定什么才是重要的。

Intent continuity is different. It means carrying an old requirement into a new task without the user repeating it, while dropping that rule if something newer overrides it.

意图连续性则不同。它意味着在用户无需重复的情况下，将旧需求带入新任务，同时如果有了更新的规则覆盖了旧规则，则将其丢弃。

Here is the exact split this article focuses on: 以下是本文重点关注的区分：

• Retrieval asks: “What historical information might be relevant?”
• 检索问的是：“哪些历史信息可能是相关的？”
• Verification asks: “Is that information still valid?”
• 验证问的是：“这些信息仍然有效吗？”
• Intent continuity asks: “What historical intent should influence this task, right now?”
• 意图连续性问的是：“此时此刻，哪些历史意图应该影响这项任务？”

Right now, most talk about agent memory focuses purely on that first question. 目前，关于智能体记忆的大多数讨论都纯粹集中在第一个问题上。

Who This Is For

适用人群

Build this if you run coding agents on long-running projects where rules get stated once and forgotten. Think of multi-week refactors, codebases packed with old design choices, or teams where whoever set a constraint three weeks ago is not the person prompting the agent today.

如果你在长期项目中运行编程智能体，且规则往往只被提及一次就被遗忘，那么请构建这个系统。比如持续数周的重构、充满旧设计选择的代码库，或者团队中三周前设定约束的人与今天向智能体发出指令的人不是同一个人的情况。

Skip it for quick, single-session tasks that carry no history. Skip it if your project is small enough that you can just paste your full requirements doc into every prompt. Skip it if you are already manually repeating every rule to the agent on every turn. If a human is constantly reminding the agent what to do, the system never needs to look up past decisions.

如果是没有历史记录的快速单次任务，请跳过它。如果你的项目足够小，可以直接将完整需求文档粘贴到每个提示词中，请跳过它。如果你已经在每一轮中手动向智能体重复每一条规则，也请跳过它。如果人类一直在提醒智能体该做什么，系统就永远不需要去查找过去的决策。

If your agent sessions stay short and your rules never shift, standard search or zero memory works great. Long projects just do not work that way.

如果你的智能体对话很短且规则从不改变，标准搜索或零记忆模式效果很好。但长期项目并非如此。

Full Pipeline Architecture

完整流水线架构

The intent-continuity pipeline, horizontal flow. Nine steps carry a coding agent’s historical requirements from raw interaction history, through verification and supersession checks, to a graded implementation. No embeddings, no vector database, no LLM call in the pipeline.

意图连续性流水线（水平流程）。九个步骤将编程智能体的历史需求从原始交互记录中提取出来，经过验证和覆盖检查，最终实现分级执行。流水线中没有嵌入、没有向量数据库、没有 LLM 调用。

This diagram maps how an AI coding agent recovers and verifies project requirements from earlier conversations instead of relying on a longer context window or plain vector search. Interaction history moves left to right through rule-based intent extraction, then drops down and continues right to left through candidate retrieval and verification, where superseded or out-of-scope decisions get dropped before anything reaches the agent. The pipeline ends with a deterministic agent and a requirement checker, so every recovered requirement is graded the same way it was verified. The whole system runs in pure Python, with no embedding model or vector database anywhere in the chain.

该图展示了 AI 编程智能体如何从早期对话中恢复和验证项目需求，而不是依赖更长的上下文窗口或简单的向量搜索。交互历史从左到右通过基于规则的意图提取，然后向下转折，从右到左通过候选检索和验证，在到达智能体之前，被覆盖或超出范围的决策会被剔除。流水线以确定性智能体和需求检查器结束，因此每个恢复的需求都以与验证时相同的方式进行评分。整个系统运行在纯 Python 中，链条中没有任何地方使用嵌入模型或向量数据库。

I set one strict rule before writing a single line of code: 100% pure Python. No API keys, no external LLM, no embedding models, and no vector databases.

在写下一行代码之前，我设定了一条严格的规则：100% 纯 Python。没有 API 密钥，没有外部 LLM，没有嵌入模型，也没有向量数据库。

Part of the reason was convenience. I wanted anyone to clone the repo and run it in under a second with zero setup friction. But the bigger reason was control. If I relied on an embedding model, the benchmark results would just get tangled up in how good or bad that specific model happened to be.

部分原因是方便。我希望任何人都能克隆仓库并在不到一秒钟的时间内运行它，且无需任何配置。但更重要的原因是可控性。如果我依赖嵌入模型，基准测试结果就会纠缠于该特定模型的好坏。

The verification logic is what actually does the heavy lifting here, and I wanted to prove it can stand entirely on its own two feet.

验证逻辑才是这里真正承担繁重工作的部分，我想证明它完全可以独立运作。

Component 1: The Extractor

组件 1：提取器

The pipeline starts by turning raw chat logs into structured requirement records. The extractor is just simple. It scans each message for sentences that look like requirements, identifies the part of the system the requirement appears to target, and extracts specific values when they are present.

流水线从将原始聊天记录转换为结构化需求记录开始。提取器非常简单。它扫描每条消息中看起来像需求的句子，识别该需求似乎针对的系统部分，并在存在时提取特定值。

# extractor.py