Memory in the Loop：进程内检索将延迟降至100μs，长上下文召回升至4.8/5

Memory in the Loop: In-Process Retrieval as ExtendedWorking Memory for Language Agents

当前的大语言模型智能体（Language Agents）普遍遵循着“观察-推理-行动”的经典循环，但它们所依赖的外部记忆，往往被隔离在这个核心循环之外。在现有的主流架构中，外部记忆通常被当作一个独立的数据库，智能体在每个对话轮次（Turn）开始时最多只查询一次。为什么不让智能体在每一步（Step）推理时都去查询和写入记忆？阻碍这一理想状态的唯一核心障碍是：延迟。

ArXiv URL：https://arxiv.org/abs/2607.05690v1

传统网络化向量数据库的响应时间通常在几十到几百毫秒之间。如果智能体在循环的每一步都进行检索，由于每次推理都需要等待网络响应，端到端延迟会被放大数十倍。面对这一高昂的成本，现有的工程实践大多选择了妥协：要么在服务层通过复杂的调度机制来掩盖延迟，要么干脆采用“记忆优先”（Memory-first）的设计，强制规定每轮只能检索一次。

然而，来自史蒂文斯理工学院（Stevens Institute of Technology）的一项最新研究提出了截然不同的视角。他们认为，高昂的延迟并非不可打破的物理定律，而是源于“记忆存储在哪里”的架构假设。当将外部记忆从云端拉回进程内（In-process），检索延迟可以直接断崖式下降三个数量级，达到约 $100\,\mu\mathrm{s}$（微秒）级别。在这种极速响应下，每步检索所带来的延迟税几乎可以忽略不计。这不仅是一项工程优化，更引发了智能体架构层面的质变：当记忆的读取速度逼近模型访问自身上下文窗口的速度时，外部存储便不再仅仅是一个被动查询的“工具”，而是真正成为了智能体延展出的“工作记忆”（Working Memory）。

重新定义检索频率：跨越进程内外的鸿沟

要理解这项研究的突破，首先需要明确当前大模型记忆处理机制的局限性。目前业界习惯将大模型的上下文窗口（Context Window）视作其工作记忆，但这种做法面临着三个与窗口绝对大小无关的固有缺陷。首先是“租金”问题：窗口内的每一个 Token 在每一步推理中都需要被重新计算，这意味着维持长期记忆的计算成本是持续叠加的；其次是可寻址性问题：模型在面对超长上下文时，极易出现“迷失在中间”（Lost in the Middle）的现象；最后是灾难性断崖：一旦对话历史超出了物理窗口的上限，信息的遗忘是瞬时且彻底的。

为了解决这些问题，引入外部存储（如 RAG 系统）成为了标配。但这引出了检索频率（Retrieval Frequency）的定义差异。在传统的每轮检索（Per-turn Retrieval）中，系统仅在接收到用户指令时进行一次网络请求拉取背景信息，随后进入无记忆访问的内部推理循环。而 Memory in the Loop 则主张每步检索（Per-step Retrieval），允许智能体在每产生一个推理步骤或执行一个中间动作时，都能实时读写存储。

在此前的研究中，如果在每步推理中都使用常规的网络向量库，由于每一步都会被检索阻塞，端到端延迟会被放大高达 $83$ 倍。其背后的数学逻辑非常清晰。如果我们建立一个简单的成本模型，端到端延迟可以近似表示为 $\text{E2E} \approx \sum (t_{\text{reason}} + f \cdot (t_{\text{embed}} + t_{\text{store}}))$，其中 $f$ 是每步的检索频率。

在这个公式中，如果 $t_{\text{store}}$（存储响应时间）处于网络级别的 $100\,$ms 到 $200\,$ms，加上网络嵌入（Embedding）的时间，单次检索成本极高。为了控制整体延迟，现有的解决方案只能强行压低频率 $f$。但该研究指出，如果我们能够将 $t_{\text{store}}$ 缩减到 $100\,\mu\mathrm{s}$ 的量级，那么 $f \cdot t_{\text{store}}$ 这一乘积项就会趋近于零。不需要复杂的非阻塞调度算法，不需要牺牲检索的频次，底层的物理隔离一旦打破，高频检索的成本困境自然消解。

可行性边界：解锁高频记忆交互

为了更直观地量化这种架构转换带来的红利，研究人员绘制了“可行性边界”（Feasibility Frontier）。假设我们设定一个严格的预算：记忆操作带来的额外时间消耗不能超过端到端总延迟的 $10\%$（即 $\beta=0.1$）。在此预算下，智能体每步所能负担的最大检索次数 $f_{\max}$ 完全取决于单步推理时间 $r$ 与单次检索成本 $c$ 的比值。

在传统的网络存储架构下，对于单步推理时间约为 $1$ 秒的大模型来说，其可负担的每步检索次数甚至达不到 $1$ 次——这就是为什么现有的智能体不得不精打细算地“配给”记忆访问权限。然而，当切换到进程内存储并搭配小型本地嵌入模型时，整套检索操作的时间被压缩到了约 $40\,\mu\mathrm{s}$。在相同的 $10\%$ 延迟预算下，系统每步可以轻松负担数千次检索。

这种近乎免费的读写能力，直接解锁了以往在成本上不可行的多种高级智能体行为：

真正的去重与新颖性检测：智能体可以在产生每一个中间观察结果时，瞬间将其与历史记录比对，避免重复探索。
循环与动作守卫（Action Guards）：在执行任何不可逆动作之前，智能体能够以极低的代价核查是否已经执行过等效操作，从根本上防止智能体陷入死循环。
步进式事实核查：在生成复杂长文本或推理链时，能够边生成边验证，将外部事实无缝编织到每一步逻辑中。

从认知哲学到工程指标的转化

这项研究的一个引人入胜之处在于，它并没有停留在纯粹的系统工程优化层面，而是将其与认知科学中的“延展认知理论”（Extended-Mind Thesis）进行了深度绑定，并给出了极具实操性的工程解释。

延展认知理论中的“对等原则”（Parity Principle）提出：当一个外部资源能够被持续获取、直接且无障碍地访问，并能被自动认可时，它就不再是外部工具，而是认知过程本身的组成部分。研究人员将这一哲学标准创造性地翻译为了工程领域的“延迟预算”。

如果一个网络存储库需要 $100\,$ms 才能响应，这就相当于人类去翻阅一本放在书架上的参考书，它是一个被“查阅”的外部工具。但当延迟降至 $100\,\mu\mathrm{s}$，它的响应速度已经与模型访问自身上下文窗口的速度没有本质区别。这种极低延迟赋予了外部存储成为智能体“工作记忆”的物理资格。当然，极低延迟只是提供了可能性，智能体是否真的信任并依赖它（即自动认可原则），则取决于核心循环代码（Loop Wiring）是如何编写以及模型自身的策略规划能力。

因果验证：延迟本身足以左右任务成败

为了证明这种延迟下降带来的不仅是运行时间的缩短，更是任务能力的实质性跃升，研究人员精心设计了一个“循环守卫”（Loop-guard）因果验证任务。这是一个极具说服力的实验逻辑：如果在验证过程中，外部存储库提供的内容完全一致，唯一的变量仅仅是存储的响应速度，那么最终任务表现的差异就能直接归因于延迟本身。

在这个任务中，智能体面对一连串候选动作，其中一部分是历史动作的语义重复。智能体被设定了一个严格的每轮记忆延迟预算（$100\,$ms）。在执行每个动作前，它可以查询存储库以判断是否重复。如果剩余的延迟预算不足以支付下一次查询的成本，智能体就只能放弃查询，直接盲目执行。

实验结果呈现出了教科书般的单调剂量-反应关系。当使用进程内速度（$100\,\mu\mathrm{s}$）时，系统能够从容应对所有查询，执行的冗余动作数量为完美的 $0.0/12$。当引入 $15\,$ms 的轻微网络延迟时，冗余动作开始上升至 $1.4$ 到 $1.6$ 个。而当模拟典型的云端跨区域往返延迟（$110\,$ms）时，哪怕是一次查询的成本也超出了单步预算，智能体彻底失去查阅记忆的能力，冗余动作暴增至 $7.2/12$。

需要着重强调的是，在这个实验中，存储库从未发生过任何检索错误，每一个正确答案都安静地躺在数据库里。导致智能体犯错的唯一原因，是网络延迟让它“买不起”这些答案。这条因果链条彻底击穿了现有 RAG 架构的妥协逻辑：延迟不是一个可以被服务层异步调度轻易掩饰的背景噪音，而是一个直接破坏智能体防错机制的致命缺陷。

端到端表现与工作记忆的极限测试

在明确了机制之后，研究团队在更接近真实场景的长上下文多轮对话任务（旅行规划）中展示了 Memory in the Loop 的端到端威力。任务要求智能体在多轮对话早期接收并记住五个硬性约束条件，并在对话末尾将它们完整回忆出来。为了精准模拟上下文资源的枯竭，研究强制限制了对历史消息的可见窗口。

在没有记忆工具的基准测试中，由于约束条件随着对话推进滑出了可见窗口，包括 gpt-5 级别的所有四个模型，召回率毫无悬念地触底，得分为 $0/5$。但当引入了基于进程内存储的记忆工具后，模型的召回率跃升至 $3.6$ 到 $4.8/5$。在这一过程中，进程内存储的实际操作中位数延迟被精准测定在 $80$ 到 $165\,\mu\mathrm{s}$ 之间，确保了整个交互过程的极致流畅。

特别值得一提的是，研究人员设置了一个极为严苛的对照组：强迫模型在每次回复末尾以文本形式重述所有已知的约束条件（即显式的“好记性不如烂笔头”策略）。这种纯 Prompt 层面的基准在任务中取得了 $5/5$ 的完美成绩。但研究深入剖析了这种表象背后的代价：这种重述策略实质上是在强行占用宝贵的上下文窗口空间，随着需要记忆的事实不断增加，模型需要在每轮对话中支付呈线性增长的 Token“租金”。而 Memory in the Loop 的核心价值正是彻底免除了这种长期维护成本，将事实安全地卸载到零维持成本的外部存储中，只在使用时按需支付微秒级的提取费用。

同时，实验的遥测数据还揭示了一个关于大模型行为的关键洞察：在所有测试轮次中，进程内存储完美保留了所有的写入请求（$244/244$ 事实无一丢失）。所有未召回的失败案例，其根源无一例外都指向了智能体自身的“读取策略”失效——即记忆库里有这个事实，但模型在有限的读取窗口内没有使用正确的查询逻辑把它捞出来。这明确指出，在解决了底层存储延迟后，下一步的研究重心应当转向优化模型的检索规划能力，而非继续堆砌数据库后端的检索算法。

最后，当进程内存储将检索的 $t_{\text{store}}$ 压榨到极限后，系统剩余的唯一瓶颈暴露无遗：网络嵌入（Embedding）调用的延迟。通过网络 API 生成一次嵌入向量依然需要消耗 $200$ 到 $400\,$ms。针对这一残存的短板，研究给出了明确的终极方案：将进程内存储与小型的本地嵌入模型（Local Embedder）相解耦与配合。当计算全部下放至本地，整个记忆读写操作的闭环时间被彻底钉死在约 $40\,\mu\mathrm{s}$，至此，智能体终于拥有了真正意义上随叫随到、毫无阻滞的延展工作记忆。