丢得静悄悄,谈一谈 Agent 的记忆是怎么没的

Agent 记东西,像往黑板上写。只能往上加,擦不掉。------今天所有主流 Agent 框架都是这么干的。

它没报错,也没有任何提示。它就是少了一样东西,而它自己不知道。

这期讲的是这件事怎么发生的,以及 Meta Superintelligence Labs 带着华盛顿大学、MIT 和 Trillium Labs 在9 月 29 号挂上 arXiv 的一种新做法(论文叫 Context Language Models ,代码在 facebookresearch/context-language-models)。

先从第 80 轮那次重跑看起。


第 80 轮那次重跑

你让Agent 改一个老项目。跑到第 40 轮,它读了配置文件,拿到一个端口号。你接着让它干别的,改了七八个文件。第 80 轮,你让它把配置改回去重跑。

它没报错。它很自信地给了一个端口号。

那个号是它自己编的。

它就编一个,还不报错。压缩策略最难防的就是这里。

它不是算错了。它手里那份东西里根本没有那个端口号了------那份东西长得挺完整,读起来也顺,就是没有那一行。关键在于,它也不知道自己已经没有它了。

丢东西这件事之所以难防,不是 Agent 笨。是它丢得静悄悄。


原来那块黑板

写满了会怎样?得重抄一遍,前面全擦掉。

主流 Agent 框架(Claude Code、Codex、Pi)给的记忆,本质是一面黑板。

每轮对话、每次工具返回、每步推理,都往上面加一行。加东西可以,擦东西不行。写到窗口的 75% 左右就触发一次摘要,把前面绝大部分擦掉重抄成一段浓缩版,只留最近几轮原文。你也可以手动敲 /compact 提前触发。

回到刚才那个端口号。摘要发生在某两个回合之间,它不问你"第 80 轮要干什么",它只按规则抄。抄完那一行就没了。

擦的时候谁说了算?外面那个管家,照老规矩来。

重抄这件事由外面的人决定。框架按写死的规则判断哪些该留、哪些该擦,模型没有发言权。

它擦的时候知道啥?不知道。它只看眼前,料不到以后。

这是要命的一条。

摘要是在某个具体时刻写的,写的那一刻,没人有办法知道第 60 轮会用上第 12 轮读到的哪个值。写摘要的人不知道,看摘要的 Agent 也不知道------所以它不会停下来问,只会拿一个编的数接着往下走。

还有个更绕的:摘要的摘要。你手动多压几次,或者长任务自己触发多次压缩,就变成摘要的摘要,每一轮都在丢一点,最后剩下一份读起来很顺、其实已经空了的东西。

论文把这件事说得很直:agent harness 那些"总结 / 截断 / 检索"的固定策略,才是长任务的绑定约束,不是模型本身。


CLM:一本它自己揣着的笔记本

改动就一句话:

把上下文变成一个文件,模型拿着文件路径,用普通命令行工具去改它。

CLM 的做法不一样在哪?不是黑板了,是一本笔记本。

原来(黑板) CLM(笔记本)
谁能擦 只有外面的框架 模型自己
什么时候擦 到阈值了统一擦 它自己决定,随时
擦的时候知道什么 不知道,按固定规则 它知道,因为做判断的是它自己
上下文变了会怎样 只有追加 文件被改写,下一轮直接生效

笔记本这个比方,关键在第三条。前两条是权限问题------从"别人擦"变成"自己擦"。第三条才是那只靴子:做判断的人换成了当事人。 模型在动手的那一刻,手上有完整的目标和完整的现场,它自己知道第 80 轮要拿那个端口号,所以那行不会丢。

这跟"帮我总结一下"不是一回事。这是"你自己看着办,要留的留,要删的删,要改写的改写"。

这本子能干什么?划掉不要的,写小字记账,随手翻页。

改完立刻生效?下一轮它看到的就是改过的。

模型下一轮看到什么,取决于它刚才对自己的上下文做了什么。上下文不再是一份只能追加的记录,是一个它能动手改的工作区。

这套玩法不用训练。不训一个参数,现有模型直接套上就有效果。论文顺手还试了在线 RL,Qwen3.5-9B 在BrowseComp-Plus 上提升 47.6%,FLOPs 还省 12%。

这些玩法没人教它

这套本事谁教的?没人教,它自己学会记账了。

论文里记了三条它自己干出来的事:给自己造了个叫 notes 的角色声明,纯用来做内部记账;写了个辅助函数专门压缩旧的搜索结果,来回调了几十次;一次多 Agent 实验里维护了一张 21 个子Agent 的实时记分板,原地更新了一百多次。

没人写进提示词,没人规定格式。作者管这叫零样本------不是夸它聪明,是给了一个能动手的空间,它自己找出了怎么用。

还有一条结论挺有意思:RL 在 CLM 上比在普通 LM 上更好做信用分配。因为模型对上下文的每一次编辑都是显式的、可读的判断------哪条重要、哪条没用,它写出来了,不用猜。


省了多少

这么干能省多少?答得更准,还能更省算力。

基准 准确率/得分 算力
BrowseComp-Plus(深度检索) +11.4% FLOPs −21.5%
EdgeBench(12 小时自主任务) +5% FLOPs −59%
六仓库 24 小时 Agent 群 同算力下改进 +65% ---

三个都不需要训练。EdgeBench 那行最狠------跑 12 小时的任务,算力少用近六成,准确率还上去了。

还有一个数字容易被忽略:用自然语言指令(走 skill 优化循环)能教上下文管理策略,在留出数据上最多提升 35.9 个百分点。也就是说"怎么管上下文"这件事本身也能变成可优化的目标,不用写死在代码里。


两个坑

那没有代价吗?有,改狠了会变慢,坏指令会赖着。

改中间会破掉前缀缓存。 模型上下文是个 KV 缓存,前面的算好了后面接着用。在中间动一刀,后面全部作废。论文自己做了配套优化叫 Suffix Cache Reuse------把还活着的部分挪一挪,只重算真变了的那段,在 BrowseComp-Plus 上做到性能持平、服务端算力比标准 SGLang 少 35%。第三方视频解读里提到"最差可能慢 70 倍",这个数字我没在论文正文核实到,只当参考。

Prompt injection 会长期驻留。 普通摘要有个副作用是"冲淡"------恶意指令混在摘要里,多轮之后可能被稀释掉。CLM 的上下文是模型自己写的文件,它还打算写长期笔记。注入的指令会一直在那儿。这是 CLM 自己论文里承认的安全问题。

还有一个论文自己说的观察,值得单独拎出来:harness 的配置方式会直接影响效果。开了并行工具调用之后,模型几乎不怎么自己编辑上下文了,退化成兜底逻辑在压缩。

这条最有意思,因为它反着证明了前面的道理。模型会去用你给它的空间------你把空间收走,它就退回老路。所以不是"CLM 一套上去就一定灵",得真的留出动手的空间。


怎么用,我的判断

如果你手上已经有一个跑长任务的 Agent,先试一处:让它重写自己的压缩决策,不用整套换掉。仓库里有 clm-minimal 实现和 clm-harbor CLI,能接 OpenAI 兼容端点,跑起来看行为就行。

CLM 动的是"谁决定压缩",不是"怎么压缩"。过去这层是 harness 的,框架写死规则,模型被动接受;现在收回来了,理由很朴素------压缩之前要做判断的是模型,因为它知道第 60 轮要用什么,第 40 轮的人不知道。

代价也实在:延迟不确定性变大,安全面变宽。所以短期内更可能是混合------harness 管硬边界(上下文总长、超时、权限),模型管软决策(什么值得留)。并行工具调用那条观察就是在说这条边界画在哪儿:硬边界给多了,模型就不动手了。

最后一件我会继续盯的事:论文把上下文管理从框架挪进模型,而同期 turbopuffer 那家做 serverless 向量数据库的公司在往反方向走,宣布要把向量检索降级成"只是一个二级索引"。两个独立团队,一个从上面收,一个从下面收,中间的中间件层正在被两头挤。这个结构比 CLM 本身更值得盯。


出处:arXiv 2026-09-29,Meta Superintelligence Labs / University of Washington / MIT / Trillium Labs。

漫画由 AI 辅助生成,人工逐字终审。

相关推荐
姜鱼问生6 小时前
Nginx gzip 压缩:一个配置让页面加载快 3 倍
后端·算法·架构
颜酱6 小时前
一栋商业大厦,讲清 InnoDB 的表空间、段、区和页
后端·mysql
码事漫谈6 小时前
1956 亿行数据该怎么存:金仓时序数据库的三个实测
后端
Wx-bishekaifayuan6 小时前
springboot桂味美食分享系统40540-计算机课程设计、毕业设计
spring boot·后端·python·django·课程设计·express·旅游
彭亚川Allen6 小时前
从零手搓 RAG 之检索全流程,给大模型接上自己的知识库
前端·后端·ai编程
IT_陈寒6 小时前
别让Java字符串拼接偷偷吃掉你的内存
前端·人工智能·后端
_Evan_Yao6 小时前
前后端联调怎么排查问题?从 Network 到后端日志,一步步定位错误
开发语言·后端·团队开发·需求分析
程序员梅雨7 小时前
ZooKeeper面经总结
java·大数据·linux·分布式·后端·zookeeper·中间件
蜗牛互联网7 小时前
Java 17 调用视觉 Responses API:JSON 约束与人工复核路由
java·人工智能·后端
高频因子挖掘机8 小时前
股票分红送转后价格“断层”:前复权、后复权和不复权该怎么选?
后端·github·api