为什么 Agent 记得越多,反而越不稳定 ⭐ S|Situation 一开始我对 Memory 的理解其实也比较简单,觉得无非就是把历史信息存下来,让 Agent 能“记住以前发生过什么”。但在一个 Agent 项目真正跑到线上之后,我的感受发生了很大的变化。当时我们做得比较激进,把用户历史行为、一些中间结论频繁写入 Memory,结果跑了一段时间发现,Agent 反而更容易被早期判断带偏,在相似场景下重复做出并不合适的决策。 ⭐ T|Task 这次踩坑之后,我重新思考了一个问题:Memory 到底是为了解决什么问题的?我后来意识到,它并不是对话记录的延续,也不是简单的“长期上下文”,而更像是一个可被检索、但必须被严格控制的外部状态系统。Context window 解决的是“这一轮还能记住什么”,Memory 解决的是“未来某个时刻,要不要、以及该不该用过去的经验”。 ⭐ A|Action 在真正落到系统设计时,我不再按概念拆,而是从时间尺度来分: 短期层:尽量依赖 context window 保证当前任务能顺着走,状态是即时、可见的,不做长期沉淀。 长期层:只写高度抽象的信息 我们只保留那些被反复验证、具备长期价值的内容,比如: 用户稳定偏好 多次出现的失败模式 而不是原始对话文本,或者一次性的中间推断结果。 真正最关键、也最容易出问题的,是Memory 的写入和检索控制策略。 我们后来专门加了一层规则: 限制什么情况下允许写 Memory 控制一次能写多少 明确哪些结论只能是“当下假设”,不能升级为长期事实 否则 Agent 很容易把当时的猜测,当成未来决策的前提。 ⭐ R|Result 在真实业务中跑下来,我的一个很强烈的感受是:Memory 不一定是加分项,用不好反而是放大器。记得越多,Agent 在相似场景下反而越容易复用错误路径,而且排查成本非常高。所以后来我们的整体策略变得非常保守:宁愿少记,但每一条都要求能在未来的关键决策中反复复用。 对我来说,Memory 的价值不是让 Agent 看起来更聪明,而是保证它在跑半年、一年之后,判断依然是稳定、可控、可预期的。 #llm #大模型 #算法 #互联网大厂 #面试题
00:00 / 01:48
连播
清屏
智能
倍速
点赞166
00:00 / 07:38
连播
清屏
智能
倍速
点赞1675
为什么Agent一上线,Memory反而容易出问题 面试被问到Agent的Memory时,我一开始理解得也挺简单的,觉得不就是把历史信息存下来嘛。但后来在一个Agent项目真跑到线上之后,这个想法完全变了。 上线后的第一个反直觉问题 当时我们一开始做得比较激进,把用户历史行为、一些中间结论都往Memory里写。结果跑了一段时间发现,Agent反而更容易被早期判断带偏,在相似场景下重复做出并不合适的决策。这之后我对Memory的定位就变了现在我更倾向于把Memory 看成一个可被检索、也必须被严格控制的外部状态系统,而不是对话记录的自然延续。上下文窗口解决的是当前这一轮还能记住什么;Memory解决的是在未来某个时刻,要不要、以及怎么用过去的经验。真正在系统里跑,不能按概念拆 在那个项目里,我们后来这样调整: 短期层:基本完全依赖context window,只保证这一次任务能顺着走 长期层:只保留被抽象过的内容,比如用户偏好、反复出现的失败模式,而不是原始对话或一次性的中间结论 最容易出问题的,其实是“怎么用 Memory” 后来发现,真正的难点不在记什么,而在记忆的检索和控制策略。我们专门加了一层规则:限制什么时候允许写Memory、一次最多写多少,明确禁止把“当时的猜测”当成长期事实。一旦放到真实业务里跑,Memory并不一定是加分项。记得越多,如果没有治理,反而越容易出问题、也越难排查。所以后来我们的策略变得很保守:宁愿少记,但每一条都要求能在未来关键决策中反复复用。 对我来说,Memory的价值不是让Agent看起来更聪明,而是保证它在跑半年、一年之后,依然是稳定、可控、可预期的。 #llm #大模型 #ai #互联网大厂 #面试题
00:00 / 01:48
连播
清屏
智能
倍速
点赞38
00:00 / 01:00
连播
清屏
智能
倍速
点赞8851
00:00 / 05:22
连播
清屏
智能
倍速
点赞32