Agent 为什么"学不会":自进化记忆卡在哪
我给自己跑的 Agent 做了一套"经验沉淀"机制:每次任务跑通,就把用过的工具路径和步骤抽象成一条可复用的"做法",攒够证据后升级为正式经验,以后遇到同类任务直接召回。
机制上线之后,我做了一次盘点,结果是:候选池里堆了 50 条,其中 49 条只有 1 个样例;真正生效的条数,是 0。
更难受的是,它不报错、不打日志、界面上一切正常 —— 看起来就像"这段时间确实没遇到同类任务"。后来我把这条链路拆开看,发现这不是一个 bug,而是三件不同的事被混成了一件。
一、分桶口径:同一个任务,每跑一次就换一个桶
"做法"要先归类才能积累。归类靠的是工具调用序列的抽象:把 fs_write → shell_exec → fs_read 映射成 file → exec → file。
问题出在"怎么合并"这一步。如果只合并连续的同类动作,那么同一个任务跑两次,只要中间多夹了一次 shell,序列就变了:
第一次: shell_exec, fs_read, shell_exec → exec→file→exec
第二次: shell_exec, fs_read, shell_exec, fs_read → exec→file→exec→file
同一个任务,两个签名,两个桶。 每个桶里孤零零躺着 1 个样例,而升级需要 3 个。于是"攒够证据"这件事永远不会发生。
修法很直接:把合并规则从"只合并连续同类"改成"按首次出现顺序去重",签名就与调用次数无关了:
第一次: exec→file
第二次: exec→file ← 同一个桶了
这一步是有效的,实测签名确实收敛了。但问题没解决。
二、门槛:改粗签名之后,病换了个名字
签名变粗,碰撞率必然上升 —— 更多不相关的任务会落进同一个桶。为此系统里有一道判词,专门判断"这两条任务算不算同一类",判否就分裂成两个桶。
实测的判词结果是:15 条里 14 条判"不同类"。
而这些"不同类"判得没错。比如 exec→file→exec 这种通用序列,会把"提交并推送代码"和"检视系统磁盘占用"凑到一起 —— 它们本来就毫无关系,判否是正确行为。
于是因果链变成了这样:
签名修粗 → 碰撞变多,但多为假碰撞
↓
判词正确判否 → 分裂 → 每条仍是 1 个样例
↓
唯一能增加样例的路径被堵死 → 永远到不了门槛 3
门槛值 3 是对着"以前的分桶粒度"定的,却要拿"现在的判词精度"来过。 两个数字从来没有对齐过:判词诚实地说"这些不是同一类",门槛却说"你得凑够 3 个同类"。结果就是系统在正确地拒绝升级,同时永远升不了级。
这就是最容易被忽略的一点:指标不工作时,不要先怀疑算法,先看两个阈值是不是在互相打架。
三、撤销入口:能写进去、拿不出来的东西,迟早变成垃圾
还有一条更隐蔽的代价。早期按旧标准写入的一条"做法",内容是"写一个测试文件然后读回"—— 明显是自测残留,不是真经验。
它在那儿待了 10 天,没人发现,因为它会随每回合的上下文快照一起被注入 —— 占用预算,还可能被当成"可信做法"。
为什么没人清掉?因为这条链路只有写入,没有撤销入口:写入路径齐全,命令行里却没有"撤下某条经验"的开关。数据进得去、出不来,就成了孤儿。
顺带说一个反直觉的观察:这三件事里,观测缺失是最贵的那个。分桶口径和门槛的问题,只要有一次埋点,当天就能看出来;而没有埋点,它们可以安静地待上十天 —— 因为"没有升级"这个结果,和"确实还没有同类任务"在外部表现上完全一样。分不清"没发生"和"判定为否",是这类系统最典型的盲区。
所以正确的修复顺序是什么
回头看,这次踩的坑归根到底是顺序错了。合理的做法应该是:
- 先补观测。当时这条链路一个埋点都没有,升级为什么没发生,运行时完全看不见 —— 只能直连数据库翻文件才查得出。没有观测,任何"优化"都是盲调。
- 再补真值。判词判得对不对,需要人工标注来校准。如果标签一条都没有,"该不该调门槛"就永远没有依据。
- 最后才调参数,并且连着改分桶口径与门槛 —— 它们是一对,单改一个只会把问题推给另一个。
- 顺手把撤销入口补上。可写不可撤的系统,错误经验的半衰期等于你的耐心。
Agent 的"经验"这件事,难的不是提炼算法有多聪明,而是口径、门槛、退出口径这三样工程细节有没有对齐。对齐了,朴素的方法也能跑;没对齐,再聪明的模型也只是在一条堵死的管道里打转。
本文基于一次真实的 Agent 记忆系统盘点写成:50 条候选、0 条生效、14/15 判否 —— 数字都来自实测。