速评：10 月 14 日 dev.to 那篇讲 agent 记忆与学习的文章，正文不值钱，评论区值钱。
署名 Sparsh Jain，开头引了对冲基金总监的一个观察——换人接手，代理之前攒的状态清零。开场选得聪明，痛点抓得准。但整篇真正有杀伤力的是中间那句差点被略过去的话：他们团队往 agent 里塞历史案例、执行记录、检索文档、累积知识，独立评估下来，更多上下文并没有稳定提升表现，某些配置反而更差，删掉一部分信息决策还变好了。
这句该单独拎出来裱起来。
这剧本，眼熟。前两年卷 context window，说塞得下就行；后来卷向量库，说检索得准就行；今年开始卷“经验”。三轮换了皮，撞的是同一堵墙——信息量和判断力不是一回事。多少人还在把“我的 agent 记得上一次”当卖点，人作者团队自己测出来的结论是记得多不一定干得好。
事实和学习那个区分是对的，而且扎人。合同哪天到期、API 怎么认证、服务在哪个仓——查得到的，叫事实。排查生产事故先看近期部署变更、来源打架时信近期验证过的那个——摔出来的，叫判断。执行日志只说明代理做过什么，说明不了它下次该不该这么干。这句话该刻在很多 agent 产品官网首页上，而不是藏在 dev.to 一篇技术随笔的第九段。
但真正卡脖子的不在捕获，在合并。
The Agent Loop 在评论区扔了一个数字，整页最硬的一块料：同一句话的四种“忠实阅读”，给出 26.2%、8.7%、19.5%、8.7% 四个比例。同一句话，四种都算忠实，结果差三倍。整合这一步的分类口径本身就能把结论捏成任何形状。你要把十次相似失败压成一条教训，第一步得先定义什么叫“同一失败”；这个定义只用自然语言写着，后面捕获、检索、更新全在给这个含混定义擦屁股，谁也纠不回来。Kartik 说得更直接，他遇到过日志看着一模一样、修法却完全相反的事故——两条教训该合并还是该打架，光看日志判不出来。
评论区那几个实操的比正文诚实得多。Statewave 自己承认，新陈述取代旧陈述时关了旧记录的有效期窗口，但没写清替代关系，取代链断了，事后追不回来，还自己给它定性成“未修复的缺陷”。Glen Allen 说验证这一步决定整个学习循环可不可信，因为代理完全可能把成功归给某个策略，真实原因是运气或者环境变了。Mahdi 担心的更具体——“先查部署变更”这种好教训，用久了会退化成“总是归咎部署”，适用条件丢了，教训就变成偏见。这几条没有一条是推演出来的，都是踩过之后写下来的。
正文那五个环节——捕获、评估、整合、检索、更新——列出来像条流水线，工整。五步里至少四步的真正难点都在评论区的追问里，正文只负责给它们编号。这不是黑作者。他能把“记忆不等于学习”讲清楚，还敢把自己团队的负结果放出来，这圈子里已经算稀缺。我只是觉得，框架摆得越整齐，越容易让人以为问题已经被分解完了。
渐进披露那条我认，是全文最实用的一句：只给当前决策所需的最小相关信息，需要了再展开。The Agent Loop 补的那组测量也撑得住这个方向——重读笔记消耗的上下文是描述写作的 5.2 倍，加了本地检查涨到 6.9 倍。要减少每个决策单位所需的记忆量，这话比所有“记忆层”产品的宣传页都清醒。目标是正确时机给恰当信息，不是把召回率拉满。召回拉满的系统，最后往往是拿一大堆过期经验糊住当下这个决策。
这里立个 flag：半年之内会冒出一批号称“有长期记忆”的 agent 产品，拆开看是把执行日志换了个名字叫经验，检索预算全花在召回三个月前某次侥幸成功上，而“这条教训什么时候该失效”答不上来。能答上来的，一只手数得过来。
记忆是资产还是负债，分界线就在这句上——答不上来的，存得越多，坑越深。