AI Agent 的长期记忆:别再把上下文窗口当大脑

让 Agent 读仓库、改代码、跑测试，聊上几十轮后，它忽然又问起已经确认过的约束。很多人把这叫“模型忘了”，但更准确的说法是：它的短期记忆——当前上下文——装不下了；而真正该沉淀的项目事实，还没有进入可复用的长期记忆。

这两个概念很容易混在一起。上下文压缩可以让一次长任务不断线，却不等于跨会话记忆；一份 AGENTS.md 或 CLAUDE.md 能持续影响行为，却也不等于模型会自动从经验中学习。把这些层次分开，才能选对工具，也才能避免把“记住”误当成“可靠”。

先把记忆拆成两层

短期记忆，是本次任务正在使用的工作台：最近的对话、读过的文件片段、工具输出、当前计划和尚未完成的步骤。它的优点是信息新、细节多、无需检索；缺点是容量有限、成本会累积，且任务结束后通常不会自然留下来。

长期记忆，是可以跨会话、跨任务重新取回的外部状态：项目规则、用户偏好、架构决策、已验证的故障结论、知识库和可检索的历史记录。它的优点是可复用、可审查、能在新会话中生效；缺点是需要写入策略、检索策略和更新机制，错记的信息还会被反复放大。

可以用一个很朴素的分工来判断：

• • 短期记忆回答“我现在做到哪一步”；
• • 长期记忆回答“下次遇到类似问题，哪些事实仍然成立”；
• • 代码、测试、文档和版本记录是两者共同依赖的外部锚点。

长期记忆不是一个文件，而是一条闭环

一套能落地的长期记忆至少要经过五步。

1. 1. 捕获：只记录高价值结论，例如“支付模块必须先验签再落库”，而不是把整段聊天逐字保存。
2. 2. 提炼：把结论写成可执行的规则、决策记录或结构化状态卡，并保留它来自哪里、何时验证。
3. 3. 检索：新任务开始时，按仓库、模块、用户或任务类型取回最相关的少量信息。
4. 4. 校验：读取后仍要用代码、测试或当前文档验证；记忆是线索，不是事实的替代品。
5. 5. 更新与遗忘：过期的规则要标记、替换或删除。没有失效机制的记忆库，最后会变成“更自信地犯旧错”。

这也解释了它的适用边界。项目规范、个人偏好、稳定架构决策和可复现的排障结论，适合长期保存；临时日志、未经验证的猜测、一次性需求和敏感凭据，则不适合。后两类要么污染检索，要么带来安全风险。

选择记忆方案时，真正要权衡什么

长期记忆不是越多越好，至少有四组取舍。

准确性与召回率。 多存一些信息，漏掉关键事实的概率会下降，但无关旧规则也更容易挤进提示词。对 coding agent 来说，宁可按目录、任务和时间做检索，也不要把“全部历史”塞回上下文。

自动写入与人工可控。 自动总结省事，却可能把推测写成结论；人工维护更可靠，却有成本。一个实用折中是：Agent 自动提出候选记忆，人只确认高影响规则。

个性化与可共享。 用户偏好应隔离；项目规则应进入团队可审查的文件；架构决策还应有版本与责任人。把三者混在一个私有记忆库里，协作时最容易出问题。

便利与隐私。 记忆往往包含源码、任务历史和行为偏好。要明确存储位置、保留期限、访问范围与删除通道，尤其不能把密钥、生产数据或未脱敏日志当作“有用上下文”。

五款产品如何处理“记忆”

下面的对比刻意区分三件事：会话压缩、持久规则/项目知识和自动跨会话记忆。它们都能让 Agent 看起来“记得更多”，但工程含义并不相同。

Codex：自动压缩会话，长期规则交给仓库

OpenAI 对 Codex agent loop 的公开说明显示：当输入超过阈值时，运行时会以更小的压缩项替换此前输入，以维持长任务继续执行。[来源1]

这是短期记忆的续航机制：它服务于当前 agent loop，而不是把会话原文无限保存成用户可管理的知识库。对项目级长期记忆，更稳妥的做法是把不可丢的约束放在仓库内的 AGENTS.md、技能说明、设计文档和测试中；这些内容可被审查、版本化，也能被新会话重新读取。

适合什么： 工具调用密集、任务链很长的开发工作；团队已经把关键规则落在文件里。

要留意什么： 自动压缩后的状态并不是完整、可编辑的历史档案。任何不能丢的结论，都不应只存在于聊天记录里。

Claude Code：把长期规则显式放进 CLAUDE.md

Anthropic 的 Claude Code 文档说明，当上下文接近限制时，会先清理较旧的工具输出，再在需要时总结会话；用户可用 /context 查看上下文、用 /compact 主动压缩，也可在 CLAUDE.md 提供 Compact Instructions。[来源2]

这里的设计很清楚：压缩负责短期上下文，CLAUDE.md 负责可重复读取的项目指令。它不要求你相信一段自动摘要能永久正确，而是鼓励把“测试命令、模块边界、提交要求、禁区”写成显式资产。

适合什么： 需要让同一套约束跨多人、跨会话稳定生效的仓库。

要留意什么： 指令文件也会过期。把它当作长期记忆时，应像维护代码一样评审和更新，而不是无限追加。

Qoder：把项目知识、记忆与上下文预算放进工程工作流

Qoder 公开介绍的 Engineering Knowledge Engine 会整合代码、提交历史、Repo Wiki 与记忆等信息，以改善 Agent 对项目的理解；其 CLI 文档还列出项目记忆、会话恢复与 /compact 等能力。[来源3][来源4]

这更接近“知识层 + 会话层”并行：Repo Wiki、规则和项目记忆承担长期可检索的项目背景；压缩与恢复处理当前任务的上下文预算。价值在于不必每次从零解释仓库，风险则是旧知识可能和当前分支不一致。

适合什么： 中大型代码库，且团队希望把代码、历史与说明组织为 Agent 可按需获取的知识层。

要留意什么： 把项目记忆视为待验证索引，而不是权威源。变更架构后，应同步更新 Wiki/规则，并让测试兜底。

Trae：近期原文 + 早期任务语义摘要

TRAE 对 Agent 2.0 的公开介绍称，接近上下文限制时会保留近期轮次原文，并将较早历史总结为紧凑记忆；摘要会尽量保留工具调用目的和任务依赖。[来源5]

它的重点不是“存下更多聊天”，而是尽可能保住行动链的因果：读了什么、为什么读、得到了什么结论、接下来依赖什么。对多步骤编程任务，这种任务语义比一串文件名更有恢复价值。

适合什么： 需要连续规划、读写与验证的长链路任务。

要留意什么： 这仍首先是会话内的压缩/摘要机制。架构决策、规范和共享知识仍应有会话外的、可审查的载体。

WorkBuddy：先确认产品与记忆边界，再谈“方案”

“WorkBuddy”存在同名或近似名称的产品与服务，而本次可用的一手资料不足以确认你指向的具体版本、是否提供跨会话自动记忆、存储位置和删除机制。因而本文不把任何未核验能力写成产品事实。

这不是回避比较，恰好是评估记忆产品时最该问的四个问题：它保存的是会话摘要、用户偏好还是项目知识？谁能查看和编辑？何时写入、如何检索？如何过期与删除？如果这些问题没有明确答案，就应把它视为“上下文能力待核验”，而不是默认拥有长期记忆。

适合什么： 在采购、试用或接入前做尽调；拿到明确产品链接后，再将它放入同一张对照表。

一张图看懂：别把三种能力混为一谈

给开发者的最小实践

不必先搭一个向量数据库。先从一张可审查的“记忆卡”开始：

适用范围：支付模块
稳定结论：回调验签必须先于任何落库操作
依据：安全设计文档与回归测试
最后验证：2026-08-05
失效条件：支付网关或验签库升级

把它放到离代码最近、最容易被新 Agent 读取的位置；每次任务只检索与当前模块相关的几张卡；当测试推翻结论时，连同记忆一起更新。这样做的好处是，记忆不会神秘地藏在某个模型里，而会成为团队能复用、能质疑、能回滚的工程资产。

最后用一句话收束：短期记忆让 Agent 做完眼前的事；长期记忆让它下次从正确的地方开始。 两者之间，永远需要可验证的外部事实。

参考来源

• • [来源1] OpenAI，《Unrolling the Codex agent loop》：https://openai.com/index/unrolling-the-codex-agent-loop/
• • [来源2] Anthropic，Claude Code Docs，《How Claude Code works》：https://code.claude.com/docs/en/how-claude-code-works
• • [来源3] Qoder，《Engineering Knowledge Engine: The Knowledge Layer Behind Harness Engineering》：https://qoder.com/blog/engineering-knowledge-engine
• • [来源4] Qoder CN Documentation，《Using the CLI》：https://docs.qoder.cn/en/cli/using-the-cli
• • [来源5] TRAE，《Inside TRAE Agent 2.0: Smarter Architecture, Tools, and Memory》：https://www.trae.ai/blog/product\_thought\_0617

💬 如果你也在探索 AI Agent 的长期记忆，欢迎在评论区留言或私信交流，一起进步！