Nori的创始人theahura以前常说一句话:session transcript——也就是agent和工程师之间的完整对话记录——是新石油,比代码本身还值钱。他就是照着这句话把公司开起来的。几个月后,他自己团队做的对照测试给出了相反答案:给coding agent配上搜索历史session记录的能力,在SWE任务上带来的性能提升是零;要是没人盯着,靠agent自己翻旧账去改进上下文,效果也谈不上好,长期看甚至可能让模型变差。这不是场面话,是自家产品跑出来的结论,还顺手把自己当初创业的理由推翻了。
一整条赛道的默认做法,被自己的产品验证成了噪音
把整个组织的session全部塞进数据库,前面挂上向量搜索、Elastic或SQL,野心大一点的再加图数据库,最后通过MCP或CLI+skills暴露给agent——这是目前agent memory这条赛道最常见的打法,连Claude Code自己也内置了类似的session记忆能力。直觉很顺:一段对话里藏着代码之外的东西,为什么这么改、用户否掉了哪些方案、这行代码背后到底是谁的临时决定。
Nori测出来的是相反结果。多加一层transcript搜索,SWE任务成绩没有提升;要是这条链路上没有人工把关,自动检索甚至可能拖累模型。
问题不在数据量,在agent不会“忘”
原因不复杂。Nori团队本来就要求写好的commit message、PR描述和文档,agent做事之前会先去看这些——这些材料早就把transcript里真正有价值的东西蒸馏出来了。再去读一遍原始对话,等于花token炒冷饭,还顺带捡回一堆当初被人特意没写进文档的杂念。
更深的问题是,agent没有状态,只能把输入窗口里的每一行都当真,哪怕这行东西只是某次会话里一个从未被人审阅过的随手决定。这种“意图漂移”会随着自动记忆越攒越多而复合放大,而目前没有一个编码benchmark假设输入数据本身可能是脏的——模型甚至会因为怀疑输入而被扣分。这也是一个对齐难题:既不想让agent乱删代码库,又希望它能清理自己的记忆,这条线目前谁都没划清楚。
赫伯特·西蒙那句老话放在这儿正合适:“信息的丰富,造成的是注意力的贫乏。”agent不是读得不够多,是读得太多、又不会挑。
agent能记住一切,却学不会忘。
- 结论.agent真正缺的不是更多记忆,而是更好的蒸馏——一条写清楚的commit message,比给它一整座数据库都管用。
人类审核都只有不到两成的通过率
Nori自己也没有完全放弃“让agent学历史”这件事,只是换了做法:内部的nori bots每周复盘公司全量PR、Slack、Drive里发生的事,向内置的skillset提出修改建议,团队再逐条看diff决定要不要接受。这些建议默认全部拒绝,最终采纳率不到两成。
换句话说,就算有人每周复盘、逐条看diff,八成以上的“自动”建议本来就会让模型变差。如果这一步也交给机器自己判断,后果可想而知。
- 风险.几百人规模的组织如果把这类自动记忆更新全部默认接受,积累的漂移只会比现在更难收拾。
这盆冷水泼向了整条memory赛道,但泼得还不够满
这个结论如果站得住,受影响的不只是Nori自己。所有靠“给agent配长期记忆”讲故事的向量数据库厂商、图记忆创业公司,连Claude Code内置的session记忆功能,都要面对同一个问题:存进去的到底是有用信息,还是噪音。
但这盆水目前只有Nori一家倒出来的,没有第三方复现,也没有公开benchmark验证,更像一份诚实的内部经验分享,而不是行业定论。评论区已经有人提醒:结论能成立多大程度,取决于一家公司commit和PR文档写得有多规范——如果一个团队的工程习惯本身就潦草,transcript或许还真是唯一能找回上下文的地方。这有点像切斯特顿栅栏:栅栏立在那儿,你得先搞清楚是谁立的、为什么立,才敢拆。Nori的工程文化足够扎实,所以不缺这堵栅栏背后的记录;换一家习惯松散的团队,答案未必一样。
石油这个比喻本身没错,只是矿脉选错了地方。真正值钱的不是原始记录,而是被人手动提炼过的那部分,剩下的大多只是废土。