AI 编码 Agent 跑几个月之后，真正的瓶颈变成了“记忆的可靠性”

大多数关于 AI 编码的讨论集中在单次任务的表现：给它一个函数、一个 bug、一个 PR，看它写得对不对。但 2026 年出现了一批新的实践报告，关注的不是“一次任务”，而是同一个 Agent 在同一个代码库上连续工作数周甚至数月。当时间尺度拉长，问题的性质就变了。

一篇 2026 年 8 月的论文记录了这样一个案例：一个研究项目从 2026 年 1 月开始，由一条持续的 Claude Code 会话线驱动一个 63.3 万行的代码库，跨越了多次上下文压缩。作者的核心判断是：LLM 编码 Agent 正在从“任务尺度”进入“项目尺度”，而在这个尺度上，持久化记忆变成了基础设施问题，而不是提示词问题。

为什么“项目尺度”不一样？单次任务的上下文可以塞进窗口，模型不需要记住三天前的一个决策。但几个月的项目里，Agent 会反复遇到同一个设计约束、同一个曾经踩过的坑、同一个被否决的方案。如果这些信息只存在于“上一次会话的上下文”里，而上下文已经被压缩或丢弃，Agent 就会重复犯错。更隐蔽的问题是，压缩本身会引入失真：摘要可能丢掉关键的前提条件，合并后的记忆可能把两个不同时期的决策混在一起。

论文报告的操作经验指向一个方向：把 Agent 的记忆当作一个需要可靠性工程的系统来对待。这意味着至少要做三件事。第一，对记忆做分层——短期工作记忆、项目级事实、历史决策记录，分开存放，不同的过期策略和冲突裁决规则。第二，对压缩做可验证的摘要，而不是让模型自由发挥，关键约束和否决理由要显式保留。第三，建立“记忆卫生”机制，定期检查记忆里有没有过时的、互相矛盾的、来自失败尝试的残留信息。

同期的另一条路线是多 Agent 分工。Anthropic 在 2026 年 4 月推出的多代理 Harness 把长时编程任务拆给不同的代理，分别负责前端设计、全栈实现等部分。这解决的是“一个 Agent 上下文被撑爆”的问题，但它没有消除记忆问题，只是把记忆问题转移到了“代理之间如何共享和同步状态”上。

对正在把编码 Agent 从“辅助补全”推进到“长期协作者”的团队来说，一个务实的判断是：不要用单次任务的满意度来衡量 Agent 的可用性，用“跨会话重复错误率”来衡量。如果同一个约束被违反了三次以上，说明记忆层没有起作用，加更多上下文窗口或者换更强的模型都不会解决这个问题。