记忆和压缩开始变成 Agent 可靠性的基础设施，不做这一层系统迟早会发散

很多人提到 Agent 记忆，第一反应还是“让它记住用户偏好”或者“跨会话别忘事”。这当然有用，但我现在越来越觉得，这个理解已经不够了。真正决定 Agent 能不能长时间稳定工作、能不能跨多步任务继续推进的，不只是有没有记忆，而是你有没有把记忆和压缩当成一层基础设施来设计。

OpenAI 最新的 Cookbook 已经把 memory 和 compaction 明确写进“reliable agents”的范式里，Anthropic 也早就把 context engineering、memory tool、long-running agent harness 当成同一条线的问题来讨论。这个信号很清楚：当 Agent 开始持续执行任务时，记忆不是锦上添花，而是防止系统发散的约束层。

为什么“上下文够大”解决不了这个问题

很多人会直觉地觉得，只要上下文窗口更大，记忆问题自然就缓解了。我不太认同。上下文变大，只是让系统有能力装下更多东西，不代表它知道哪些东西该留、哪些该压缩、哪些该外置、哪些下次还值得拿回来。

真实系统里最常见的情况是：Agent 一边做事，一边制造越来越多中间状态。工具调用日志、网页片段、代码搜索结果、失败重试说明、半成品计划、临时假设，这些东西会迅速膨胀。如果没有记忆与压缩策略，系统通常会越来越像一个没有清理机制的工作目录：什么都没丢，但也越来越难用。

真正要解决的，不是“记住”，而是“记什么、怎么记、何时丢”

我现在更愿意把这件事看成状态管理问题，而不是产品功能问题。一个可靠的 Agent 至少要回答四个问题：

什么信息应该留在当前会话里；
什么信息应该被压缩成摘要；
什么信息应该沉到外部记忆层；
什么信息应该被明确丢弃，否则只会污染后续判断。

这和传统系统里设计缓存、事件日志、数据库索引很像。区别只是现在这些决策直接影响模型是否还能继续推理、是否会重复犯错、以及下一轮成本会不会突然飙升。

session_state:
  keep:
    - current_task_goal
    - accepted_facts
    - pending_subtasks
  compact:
    - tool_call_history
    - failed_attempts_summary
  externalize:
    - project_notes
    - prior_decisions
  discard:
    - verbose_logs
    - duplicate_search_results

这类结构看起来很朴素，但它已经把“上下文管理”从临场发挥拉回到系统设计。

为什么压缩比记忆更容易被低估

很多人会给 Agent 加 memory，却不愿意认真做 compaction。原因也能理解：存下来很容易，压缩得对很难。压缩本质上是在做判断，你要决定哪些细节未来还有用，哪些只会拖慢系统。这个地方做不好，后果通常有两种：

压缩太弱：上下文越来越脏，系统越来越慢、越来越贵；
压缩太猛：关键假设和失败教训被抹掉，Agent 又开始重复踩坑。

所以我现在会把 compaction 看成和 retrieval 一样重要，甚至在长任务里更重要。找回信息的前提，是你先把值得找回的信息留下来了。

这层基础设施最容易在什么地方体现价值

我觉得最能体现价值的不是“聊天聊得更像记得你”，而是以下三类场景：

长时间任务：任务跑了几十分钟甚至更久，系统要持续保持目标一致；
调查型任务：大量中间证据需要归档、压缩、再引用；
重复协作任务：不同会话、不同人、不同 Agent 之间要继承同一套项目状态。

在这些场景里，没有记忆和压缩层，Agent 就很容易表现出一种“局部聪明、全局失忆”的状态。每一步都像会做，但一拉长就开始漂。

个人开发者最容易忽略的坑

如果你是个人开发者，我觉得最常见的错误不是完全没做记忆，而是把所有东西都丢进一个 notes 文件或者数据库里，然后以为以后检索就能解决。现实通常不是这样。没有边界的记忆层，很快就会变成另一个垃圾堆。

你真正需要的不是“更多记忆”，而是“更有边界的状态层”。哪些是项目事实，哪些是临时猜测，哪些是可以复用的结论，哪些只是这一次失败留下的噪音，这些都要分开。否则你的 Agent 会越来越像在旧聊天记录上捞针。

如果半天时间只能验证一次

我会挑一个会产生很多中间状态的真实任务，比如仓库分析、法规梳理或者故障排查。先跑一版“全都留在会话里”，再跑一版“加最小记忆和压缩策略”。然后只比较三件事：

后半程是否更容易偏题；
重新接管任务时，人类是否更容易看懂状态；
总 token / 工具成本是否明显下降。

只要这三项有改善，你就能直观看到这层基础设施为什么不是可有可无。

我的判断

记忆和压缩，接下来会越来越像 Agent 系统的基础设施，而不是体验增强功能。谁先把这层做扎实，谁的 Agent 才更可能在长任务、复杂任务和协作任务里保持稳定。对个人开发者和小团队来说，我不建议一上来就做很重的知识系统，但我会强烈建议尽早把最小的状态边界、压缩规则和外部记忆层做出来。否则系统迟早会发散，只是早晚问题。

参考来源类型：OpenAI Developers Cookbook（Building Reliable Agents with Memory and Compaction、Context Engineering 相关文章），Anthropic 工程博客（Effective context engineering for AI agents、memory tool、long-running agents）。