这周好几篇东西同时在说一件事：agent 的上下文管理已经成了瓶颈。但看下来，多数团队的问题不是没做记忆，是做了个什么都往里塞的记忆。真正的答案很朴素——你需要的记忆根本不多，只有三类：用户偏好、已确认的事实、失败的尝试。剩下的大概率在 24 小时内不会被读到，那就不该被写。
向量库不是记忆，是仓库
随便抓一个搭过 agent 的团队（不能确信这就是原文链接，但既然是在 HN 上，那它至少值得看一眼），大概率能看到这么一套：一个 pgvector，一个把对话记录原样 upsert 进去的 worker，和一个没有 retention 策略的库。听起来很完整，用起来很糟糕。
问题在于“存了”不等于“记得”。向量检索本质上是相关性匹配，相关性最高的往往是最新的对话片段——但最新不等于是对的。“用户上周让我把报价改成美元”，和“用户当前在做一个欧洲客户的方案”是不是相关？相关。但这条旧指令不该被当成当前任务的要求。
我不是不信向量检索——我自己也用它。问题在于很多人把“记忆”当成容量问题：存得越多，记得越多。事实恰恰相反，存得越杂，检索到的有效信号越稀。多数 agent 的记忆里，一大部分是被动倒进去的冗余对话。存的时候没过滤，取的时候自然只能按相关性碰运气。
真正该存的只有三类
按我现在的工程经验，真正配得上“记忆”两个字的只有三类。
用户偏好。“用中文回复”“别喊我老板”“代码里别用双引号”。跨会话、跨任务稳定存在，值得存。
已确认的事实。“这个项目必须 PostgreSQL，别碰 MySQL”“生产环境禁止自动迁移”。这些是硬约束，每次决策省一轮确认。
失败的尝试。“上次直接 psql 导 schema 挂了，后来用 COPY 才搞定”。不是黑历史，是路线图。
这周 HN 上那篇 agent.md 我挺喜欢。不 fancy——就是仓库根目录放一个 markdown，agent 一进来先读规则。本质上这就是用户偏好和已确认事实，只是把记忆放在最容易被读到的地方，而不是推进向量库之后碰运气。
短任务根本不用记忆——这我认
反对的那一半我也认。短任务真的不需要记忆层。写封邮件、翻译一段、解释一句报错——上下文塞进 prompt，又快又可控。为这种任务加记忆层，等于给自己加一段不确定的链路。
Agent Is Not the Model 也点了这个：agent 的价值不在复杂编排，在正确地调用模型。大部分调用就是“给上下文，拿结果”。这没错，也不丢人。
但有个反转：很多任务开头是短的，做着做着就长了。“帮我整理这个仓库”，开头像短任务。跑起来之后，你需要知道用户偏好（注释语言、分支策略、提交习惯），需要知道之前为什么重构中断了。短任务的边界不是由任务定义的，是由你不知道什么定义的。
所以说到底不是要不要记忆的问题，是任务到底有多短。一眼能看穿的，别引入记忆；看不穿的，那三类早晚有用。
判断标准：写进去没被读过，就不该写
我有个土办法，每次写进记忆库的东西都带一个 last_read 时间戳。定期扫一遍。24 小时没被命中的，降级或者直接删。
写下来没被读过，只有两种解释：要么它没用，要么你检索不到。多数情况下是前者。记忆库的信噪比掉得比你想的快，每一条加进去的旧记录都在稀释真正有用的那几条。
24 小时这个数不用照抄。测法很简单：给记忆块加心跳，跑一两周看命中分布。多数团队的命中曲线是少数块承担了几乎所有读取——找到那条基线，把低于基线的删掉。一周才被读一次又舍不得扔的，放冷存，别占主检索空间。
记忆是架构问题，不是功能开关
这周 Agentic Context Management 那篇论文 标题说到根上了：Memory and Cost as Architecture Problems。记忆不是一个模块，它决定 token 成本、检索质量、决策正确度。
Headlong 也走同一条线。给持久化 agent 用的微框架，不搞“长期记忆系统”，就把上下文怎么持久化、怎么恢复当成第一公民。看起来小，方向对。
为什么强调架构？因为当成架构，你会考虑预算和淘汰策略。当成功能，最后就是“先存着，以后再说”——以后不会说的，只会越存越堵。
agent 不需要记住一切才能干活。它需要记住少量、关键、可复用的东西。至于哪些可复用——看它被读了几次就明白了。也许过半年，这套“少存”的判断会被更好的路由策略打脸，但按现在看，少存比多存靠谱。