意圖連續性：編碼代理的長歷史困局新解

核心背景与技术痛点

长周期编码代理项目中，一个常见且令人沮丧的现象是：早期设定的核心规则会“凭空消失”。并非有人删除了它们，上下文窗口也未满，它们仍躺在聊天日志里，但新请求来临时，代理不再检查这些旧决策是否仍然相关。例如，项目第一天开发者明确要求“永远不要在API响应中暴露内部数据库ID”，六十轮对话后，当代理被要求构建一个新的认证流程时，由于新请求未提及ID，它直接跳过该规则，返回了泄漏内部ID的端点。这不是虚构场景，而是作者用于验证的真实测试用例。

现有技术方案并未真正解决这个问题。更大的上下文窗口（如GPT-4-32k、Claude 100k）只是让模型能容纳更多文本，但Liu et al.（2023）的研究已指出，模型会忽略长提示中间位置的细节。RAG（检索增强生成）尝试从历史中找出相关信息，但它的提问方式仅是“什么信息可能与当前查询相关？”，而不追问“这些信息是否仍然有效？”更不追问“哪个历史意图应该影响当前任务？”最终，代理可以回忆起所有规则，却无法判断哪些规则此刻仍然适用。记忆失败不是问题——决定什么重要才是。

架构设计与实现机制

作者将这一能力明确命名为“意图连续性”（Intent Continuity），并区分了三个层次：Retrieval（检索）、Verification（验证）、Intent Continuity（意图连续性）。Retrieval问“什么历史信息可能相关”，Verification问“该信息是否仍有效”，而Intent Continuity更进一步，问“什么历史意图应当影响当前任务，且在新规则覆盖它之前持续生效”。这三层形成了一个金字塔，当前大多数Agent记忆方案只停留在最底层。

实现上，作者用纯Python（Python 3.12）构建了一个完整的可运行系统，全程零向量数据库、零嵌入模型、零LLM调用。核心思路是：不依赖语义相似度，而是构建一个轻量级的“需求注册与验证”管道。系统维护一个需求清单，每次新任务时先执行基本搜索（仅匹配关键词或直接相关语句），得到一个初步的需求候选集（覆盖率约57%）。然后增加一个独立的验证层，检查每条候选需求在当前上下文是否仍然有效（例如是否有更新的规则覆盖它），最终筛选出真正应遵守的需求列表。正是这个验证层将覆盖率从57%提升至100%。

作者还坦诚了原始实验设计中的一个bug：初始版本中，由于验证层与搜索层耦合不当，使得某些本应失效的规则被错误保留，导致结果看起来比实际更好。修正后的数据更为真实，但反而验证了验证层的关键作用——没有它，系统会“过度遵守”规则，引入不必要的约束。

实测性能与工程价值

作者在8个代表性任务上进行了对比实验：基线（无任何历史检索，仅靠当前请求）的正确数为0；加入基本搜索后正确4个；而完整的意图感知方案（搜索+验证）全部8个正确。所有数据均来自真实运行，使用Python 3.12，无外部依赖，代码已在GitHub（Emmimal/intent-continuity）开源，可通过run_experiment.py复现。

这一结果的工程价值在于其极低的基础设施成本。不需要搭建向量数据库、不需要调用昂贵的LLM进行嵌入计算、不需要维护索引服务。一个纯Python的轻量级库即可为长周期编码代理提供规则连续性保障。对于多周重构、大型代码库历史约束追溯、团队多人交替提示等场景，该方案可以以极小的代价大幅提升代理行为的稳定性和安全性。

行业启示与未来演进

当前业界对Agent记忆的讨论几乎全部集中在“如何存储更多历史”和“如何更快检索”。这篇工作指出了一条不同的路径：与其无限扩大记忆容量，不如教会Agent判断“哪些记忆此刻仍然重要”。意图连续性本质上是将一种元认知能力引入Agent架构——不是被动地“记住一切”，而是主动地“决定忘记或继承”。

未来，该思路可进一步演进：结合显式的规则依赖图，实现规则的版本化与自动过期；也可与轻量级验证模型集成，在规则冲突时自动协商优先级。对于需要长期维护的编码Agent，意图连续性可能比任何更大的上下文窗口都更实用。它让我们重新思考：Agent需要的不是更长的历史，而是更智能的意图继承。