最近用ChatGPT、Codex处理长期项目时，我越来越明显地感觉到一个变化：

Agent正在从“每次重新认识项目”，变成“开始记住项目”。

以前一个Agent任务结束以后，很多上下文也跟着结束。

下一次再让它处理同一个项目，往往还要重新告诉它：

项目结构是什么。

哪些目录不能改。

测试怎么跑。

团队有什么约定。

上次为什么采用这个方案。

如果Agent能够保留长期记忆，这些重复解释当然会大幅减少。

它可以记住：

项目架构。

代码规范。

历史决策。

常见故障。

工具使用方式。

开发者偏好。

看起来这是一个非常自然的能力升级。

但问题也随之出现：

Agent记住的东西，不一定永远是对的。

一个三个月前完全正确的结论，今天可能已经过期。

一个过去适用的架构约束，项目重构以后可能已经失效。

一个曾经踩过的坑，依赖升级以后可能已经不存在。

于是以前我们担心的是：

Agent忘记。

以后可能越来越需要担心：

Agent记错，而且自己不知道已经记错。

这会让“旧记忆”逐渐变成一种新的工程风险。

---

一、为什么长期记忆一开始看起来特别有价值？

因为真实项目最大的成本之一，就是重复建立上下文。

比如你第一次让Codex处理项目，需要解释：

后端使用什么框架。

测试命令是什么。

哪些模块不能修改。

数据库Migration有什么规则。

团队为什么不用某种方案。

如果这些信息能够长期保留，下一次Agent进入项目时，就不需要重新学习一遍。

它可以直接知道：

测试使用 pytest
核心目录不能直接改
数据库变更必须走 migration
支付模块修改后必须跑 integration test

这会让Agent启动任务的速度明显变快。

所以长期记忆真正解决的是：

Context Rebuild Cost——上下文重建成本

但一个信息只要被保存下来，就会出现第二个问题：

它什么时候应该失效？

---

二、最危险的不是错误记忆，而是“曾经正确”的记忆

如果一条记忆从一开始就是错的，通常比较容易发现。

真正麻烦的是：

它过去完全正确。

例如半年前项目规定：

所有用户缓存TTL固定30分钟

Agent把这条规则记住了。

后来因为一致性问题，团队已经把核心用户状态改成：

TTL = 5分钟
关键变更主动失效

但Agent的长期记忆没有更新。

几个月以后你让它修一个缓存Bug，它仍然按照：

“TTL应该是30分钟”

进行判断。

这时候Agent不是能力不足。

它只是：

在一个已经过期的前提上进行正确推理。

而这种问题最难发现。

因为从Agent自己的视角看：

它没有任何理由怀疑这条记忆。

---

三、Agent记忆为什么会越来越容易过期？

因为软件项目本身就在持续变化。

例如：

依赖版本会升级。

API会调整。

数据库Schema会变化。

架构会重构。

CI流程会修改。

团队规范会更新。

权限边界会重新设计。

过去很多项目知识都有一个特点：

它们并不是永久事实，而是某个时间点的事实。

所以如果Agent记忆只有：

规则：不能直接修改 services/core

却没有：

什么时候记录的。

来自哪里。

适用于哪个版本。

那么随着时间推移，这条记忆的可信度一定会下降。

这也是长期记忆真正困难的地方：

保存并不难，知道什么时候不该再相信才难。

---

四、长期记忆最少需要两个属性：来源和时间

以后Agent记忆不能只是：

“我记得有这么回事。”

更理想的形式应该是：

内容：
支付模块修改必须跑 integration test

来源：
AGENTS.md

记录时间：
2026-09-01

适用版本：
main@abc123

这样当Agent再次调用这条记忆时，就可以判断：

当前项目版本是否已经变化。

原始文件是否还存在。

规则是否被更新。

这就是两个非常重要的概念：

Provenance——来源

和：

Freshness——新鲜度

没有来源：

Agent不知道这条记忆当初为什么成立。

没有时间：

Agent不知道它现在还值不值得相信。

---

五、旧记忆还会和新信息发生冲突

假设Agent记得：

项目统一使用 Redis Cache

但当前代码里已经出现：

Local Cache + Redis

这时候到底应该相信谁？

如果Agent简单地把长期记忆当成最高优先级，就可能认为：

当前代码“不符合项目规范”。

然后试图把新设计改回旧设计。

所以长期记忆系统必须面对一个现实：

记忆不是事实源，只是历史证据。

真正执行任务时，当前代码、当前文档、当前配置，通常应该拥有更高优先级。

也就是说：

Agent不能因为“我记得以前是这样”，就覆盖：

现在真实发生的事情。

---

六、为什么Agent能力越强，旧记忆风险反而越大？

如果Agent只是回答问题，旧记忆最多导致：

回答不够准确。

但如果Agent已经能够：

改代码。

修改配置。

调用工具。

运行Migration。

触发CI。

那么一个错误前提就可能继续影响后续多个动作。

例如Agent记得：

某个API已经废弃。

实际上这个API后来重新启用了。

Agent因此：

修改调用方式。

重构相关代码。

更新测试。

删除兼容逻辑。

最后可能改动十几个文件。

所以Agent执行能力越强：

错误记忆的放大效应也越强。

以前一条旧信息可能只是一次错误回答。

以后可能变成：

一串自动化错误决策。

---

七、长期记忆不能只会“增加”，还必须会“淘汰”

这是我觉得未来Agent记忆最重要的一层。

很多人谈Memory时，重点都是：

如何让Agent记住更多东西。

但真正成熟的记忆系统应该同时具备：

记住。

更新。

降权。

冲突检测。

删除。

否则记忆会越来越像一个不断堆积的仓库。

时间越久：

旧规则越多。

历史方案越多。

过期假设越多。

最后Agent反而需要花更多时间判断：

到底哪一条是真的。

所以记忆系统真正重要的不是：

Memory Size

而是：

Memory Quality

---

八、哪些内容适合长期记，哪些内容不应该长期记？

并不是所有上下文都值得长期保存。

比较适合长期记忆的通常是：

稳定的项目约束。

长期架构原则。

团队明确规范。

高频工具使用方式。

经过多次验证的工程经验。

而以下内容则应该谨慎：

临时Bug判断。

一次性的环境状态。

当前分支信息。

某次测试结果。

短期Feature Flag。

某个版本特有的行为。

因为这些信息变化非常快。

如果长期保存，未来就很容易污染Agent判断。

所以真正成熟的Agent Memory，应该有：

不同生命周期。

不是所有记忆都永久保存。

---

九、一个简单办法：记忆在使用前先重新验证

比如Agent准备引用一条长期记忆：

“这个项目不能修改legacy目录。”

不要直接执行。

可以先检查：

当前项目文档还有没有这个规则。

目录结构有没有变化。

最近Commit有没有修改相关约束。

如果记忆和当前Evidence冲突：

优先重新确认。

这其实和之前讲“可恢复执行”很像。

长期记忆也不应该：

Recall → Execute

而更适合：

Recall → Revalidate → Execute

记忆负责：

减少搜索范围。

而不是：

代替当前验证。

---

十、给自己测一个指标：有效记忆率

这篇我建议只看一个核心指标：

Effective Memory Rate——有效记忆率

统计Agent最近100次调用长期记忆的情况。

看这些记忆有多少仍然：

准确。

相关。

没有过期。

没有和当前项目状态冲突。

例如100次记忆调用里：

有82次最终确认仍然有效。

那么：

有效记忆率 = 82%。

这个指标比：

“Agent记住了多少东西”

更有意义。

因为真正重要的不是记忆数量。

而是：

这些记忆今天还能不能安全使用。

---

十一、有效记忆率低，应该先解决什么？

如果有效记忆率低于70%：

说明Agent大量时间都在引用：

过期规则。

无关经验。

旧项目状态。

这时候最值得做的是：

给记忆增加来源。

记录时间和版本。

把临时状态设置过期时间。

让当前代码和文档拥有更高优先级。

定期清理长期不再使用的记忆。

如果有效记忆率在70%—90%：

重点找出最容易失效的记忆类型。

例如：

API规则。

依赖版本。

部署流程。

缓存策略。

这些变化快的信息应该拥有更短生命周期。

如果长期超过90%：

说明记忆体系已经比较成熟。

Agent可以真正依赖历史经验减少重复理解。

---

十二、为什么这个问题会越来越重要？

因为未来Agent很可能不再只是：

一次会话里的助手。

而会长期参与同一个项目。

它会逐渐积累：

项目历史。

错误经验。

设计决策。

团队规则。

甚至过去其他Agent留下的信息。

这时候Memory就像人的经验一样：

经验越多，理论上效率越高。

但经验也有一个天然缺陷：

过去成功，不代表今天仍然正确。

所以Agent真正成熟以后，需要具备的不只是：

“我记得。”

还应该能够问：

“我记得的这件事，现在还成立吗？”

---

十三、Plus和Pro怎么判断？

如果你的有效记忆率还比较低：

Agent经常引用旧规则。

需要人工纠正过期信息。

不同会话里的历史结论互相冲突。

那当前真正限制效率的不是AI容量。

而是：

记忆质量还不够可靠。

这个阶段Plus通常已经足够。

更值得先解决：

Memory来源。

版本。

过期时间。

冲突验证。

清理机制。

否则增加更多AI容量，只会让Agent更快地基于错误历史执行更多任务。

---

如果你的有效记忆率已经很高：

Agent能够稳定复用项目历史。

旧信息会自动降权或失效。

历史经验和当前Evidence之间能够正确处理冲突。

同时又长期存在：

大量成熟、高价值Agent任务排队，

AI执行容量才真正开始成为瓶颈。

这时候Pro才更容易放大效率。

因为更多AI容量建立在：

可靠的长期记忆之上。

---

最后

过去我们一直在解决一个问题：

怎么让Agent不要忘。

但当ChatGPT、Codex真的开始拥有越来越多长期记忆以后，新的问题会变成：

怎么让Agent知道什么应该忘。

因为软件项目不是静态世界。

代码会变。

架构会变。

规范会变。

过去正确的答案，也会过期。

真正成熟的Agent记忆，不应该只是一个不断累积的信息仓库。

它应该知道：

这条记忆从哪里来。

什么时候记录。

适用于哪个版本。

今天是否仍然有效。

和当前Evidence冲突时应该相信谁。

所以长期记忆真正的价值，不是：

记得越来越多。

而是：

留下来的，仍然值得相信。

持续分享 Codex、大模型开发与 AI 编程实战内容。
长期深度使用各类代码大模型，也整理了稳定的Plus/Pro会员订阅渠道，有需要可自取。