记忆别挂在循环外:Agent 每一步都该查什么Chapters1×0:08开场1:00事件播报2:00技术拆解4:01工程意义5:13落地建议6:24收尾0:006:570:08主持过去二十四小时里,我没有看到足够扎实、又能支撑单主题深挖的一手 Agent Loop 动态,所以今天把窗口扩大到近一周。七月六日,一篇题为《循环中的记忆》的预印本提交到 arXiv。它问了一个很工程的问题:Agent 的记忆,到底应该是每一轮开始前查一次的外部资料库,还是应该进入 observe、reason、act 的每一步循环?0:34主持论文的结论很直接。作者认为,关键不只是记不记得,而是记忆访问够不够快。一个一百毫秒级的网络向量库,会被 Agent 当成工具来咨询;一个进程内、约一百微秒级的存储,才可能像工作记忆一样,随时参与每一步推理。这个差别听起来像性能优化,但落到循环设计上,它会改变你能不能在每一步做去重、校验和动作守卫。1:00主持先说论文事实。根据 arXiv 页面,这篇论文在二零二六年七月六日提交,作者是 Yusuf Khan 和 Carlo Lipizzi。摘要里给出的核心实验是:语言 Agent 通常运行一个观察、推理、行动的循环,但它使用的记忆常常在循环外面,每个 turn 最多查询一次。作者把记忆移进循环,让 Agent 在每个推理步骤都能读写,并把变量集中到一个地方:存储的回答速度。1:30主持论文报告了几组数字。进程内存储的操作延迟大约在八十到一百六十五微秒;网络式嵌入和向量库则会落到几十到几百毫秒。作者还做了一个动作去重实验:在固定的一百毫秒记忆预算下,进程内守卫可以覆盖检查,重复动作是零;当每次查库增加到一百一十毫秒的云端往返延迟时,检查直接放不进预算,两个模型平均会重复执行七点二个本来应该跳过的动作。2:00主持这件事为什么和 Loop Engineering 有关?因为很多团队把 Agent 记忆理解成「多接一个向量库」。用户来了,先检索一把,把结果塞进上下文,然后模型往下跑。这个模式对问答和资料补充很自然,但它默认一件事:记忆是 turn 级别的。它在一轮开始时出现,之后就不再跟随 Agent 的内部步骤变化。2:23主持而长循环 Agent 的麻烦,往往就发生在 turn 内。它可能在一个任务里连续打开网页、写文件、调用接口、检查日志。如果每一步都可能产生新事实,或者每一步都可能重复刚才做过的动作,那么只在开头查一次记忆就不够了。论文把这个问题叫作 memory in the loop,也就是把记忆读写放进推理步骤,而不是挂在循环外面。2:51主持真正的门槛是延迟预算。假设一次模型推理大约一秒,你愿意给记忆访问加多少时间?如果一次查库要一百毫秒,每一步查一次,二十步就是两秒的额外阻塞。工程师自然会减少查询次数,把它退回「每轮查一次」。如果查库只有几十微秒,二十次也只是毫秒级,设计空间就变了:你可以在执行动作前查一遍有没有做过,在生成结论时查一遍有没有证据,在写入新事实前查一遍是不是重复。3:24主持论文还有一个重要提醒:快存储不等于好记忆。它们在五个事实的窗口受限任务里发现,记忆版本的召回从零提高到三点六到四点八,但一个「每次回复都重述事实」的提示基线能拿满分。作者没有回避这个结果。他们说,重述在小任务里很强,只是每一轮都要把事实重新读写进上下文,工作集一大,成本会线性增长。记忆方案的问题则落在读策略:事实写进去了,但一次只读八条,重复表述会挤掉真正需要的事实。4:01主持所以这篇论文给工程团队的启发,不是「把所有向量库搬进进程」这么粗暴。更准确地说,它把 Agent 记忆拆成两层问题。第一层是存储位置和嵌入位置:如果你希望记忆参与每一步循环,就不能让每次读取都跨网络等待。第二层是循环布线:即使存储足够快,Agent 也必须被明确要求在关键步骤前后使用它,而不是把读写交给模型自由发挥。4:30主持这个区分很实用。对普通检索问答,turn 开头查一次也许足够;对代码修改、告警处置、浏览器操作、长事务编排这类任务,记忆应该更像状态守卫。它要回答的是:这个动作是不是已经做过?这个证据是不是已经被验证?这个中间结论是不是和先前观察冲突?这些问题只在循环内有意义,放到下一轮再查,已经晚了。4:55主持它也解释了为什么很多 Agent 系统明明接了记忆,还是会重复执行、遗忘约束、或者把上下文越堆越长。问题未必是模型不够聪明,而是记忆被设计成了慢工具。慢工具只能偶尔用;偶尔用的记忆,就很难承担工作记忆的角色。5:13主持如果你正在做生产级 Agent,我建议先检查三个点。第一,把记忆访问按 turn 级和 step 级分开,不要用一个「memory」概念包住所有东西。用户资料、项目知识、历史工单,可以是 turn 级检索;去重、动作守卫、短期事实、临时证据,应该考虑 step 级读写。5:36主持第二,量你的延迟,不要只看检索命中率。论文里真正拖慢每一步的,很多时候不是本地存储,而是网络嵌入调用。你可以先把短期工作记忆做成进程内结构,配一个小型本地嵌入器,或者在同一进程里做更简单的键值和语义匹配。不是所有记忆都需要上云,也不是所有相似度都值得付一百毫秒。5:59主持第三,给循环写明确的记忆触发点。比如执行工具前查重复,写入观察后做去重,生成最终答案前查证据,失败重试前查已经尝试过的路径。不要只给模型一个「你可以使用记忆」的工具描述,然后期待它在压力下稳定调用。真正可靠的 loop,关键检查应该在编排层被硬接进去。6:24主持今天这篇论文还只是预印本,实验任务也偏合成,不能直接证明所有生产场景都该换架构。但它提出的判断标准很清楚:如果一个 Agent 的正确性依赖 turn 内状态变化,记忆就不该只是开场检索。你要问的不是「我们有没有记忆模块」,而是「在每个会出错的步骤前,Agent 付得起这次记忆访问吗?」