技术摘要：环内记忆 (Memory in the Loop)

问题陈述

语言智能体运行在标准的循环之上：观察、推理、行动、重复。然而，它们进行推理的记忆通常被视为一种外部资源，在每轮（per-turn）中最多仅被查询一次（每轮检索）。这种设计是由假设检索延迟极高而驱动的。网络化的向量数据库通常响应时间为 50–200 毫秒；如果智能体在每个推理步骤都咨询此类存储库，端到端延迟可能会增加高达 83 倍。因此，目前的行业指导方针（“记忆优先”）和系统设计通过调度在服务层隐藏成本，将检索限制在每轮一次。

本文认为，这种延迟约束并非智能体设计的根本法则，而是存储库所处位置的一种产物。网络延迟（数十至数百毫秒）使得环内检索成本高昂，而进程内存储（in-process store）的响应时间约为 100 微秒。核心问题在于，当移除延迟障碍后，将记忆移入推理循环内部——即在每一步进行读写——是否可行且有益。

研究方法

核心架构

作者使用一个临时的、进程内语义存储（vxdb）作为 WorkingMemory 原语来实现“环内记忆”。该存储支持 add、recall 和 match 操作。至关重要的是，该存储是为每个智能体/任务分配的，并且不连接到网络服务，旨在实现微秒级的响应时间。

实验设置

研究采用了两种主要的实验方案：

1. 窗口化召回任务（端到端性能）：

   • 场景： 一个六轮次的旅行规划对话，用户在对话早期提出了五个持久性约束。智能体必须在对话结束时列出所有五个约束。
   • 约束： 上下文窗口被限制在 $w=4$ 条消息，导致早期的约束在可见上下文中被滚动移出。
   • 条件：
     • 基准/感知型 (Baseline/Aware)： 无记忆工具（Aware 被告知其历史记录很短）。
     • 笔记型 (Notes)： 被指示在每次回复中重新陈述所有约束（一个“无工具”的上界）。
     • 记忆型 (Memory)： 配备了由进程内存储支持的 remember/recall 工具。
   • 模型： 在“GPT-5 阶梯”（gpt-5-nano, gpt-5-mini, gpt-5, gpt-5.5）上进行了测试。

2. 因果循环卫士任务 (Causal Loop-Guard Task)（延迟 vs. 结果）：

   • 场景： 智能体处理一系列安全警报，决定是 INVESTIGATE（调查）还是 SKIP（跳过）重复项。
   • 机制： 代码卫士在执行每个动作前检查存储库，以防止冗余调查。
   • 变量： 通过注入往返延迟（0 µs 到 200 ms）来操纵存储延迟，同时保持每轮记忆预算固定（100 ms）。
   • 实验组：
     • 进程内 (In-process)： 实时速度（~17.5–85 µs）。
     • 延迟阶梯 (Delayed Ladder)： 具有相同逻辑但注入了延迟（+5, +15, +30, +50, +110 ms）。
     • 每轮 RAG (Per-turn RAG)： 行业标准（每轮检索一次）。
   • 指标： 执行的冗余动作次数（共 12 个重复项）。

成本建模

作者定义了一个可行性边界：如果检索成本 ($f \cdot c$) 相对于推理步骤时间 ($r$) 可以忽略不计，则环内记忆是可行的。他们测量了完整的操作成本（嵌入 + 存储）以确定每步访问相对于 LLM 步骤是否是“免费”的。

关键结果

1. 可行性与延迟税

• 进程内速度： 进程内存储的中位延迟为 80–165 µs。
• 延迟税： 若每轮进行 20 次环内检索，进程内存储的总阻塞时间为 ~1.7 ms。相比之下，云端向量数据库（110 ms RTT）每轮会产生 2.2 秒 的税收。
• 可行性： 在进程内速度下，智能体可以承担每步约 953 次检索（假设延迟预算为 10%），而网络化存储每步甚至不到 1 次查找，从而被迫进行配额限制。

2. 任务性能（窗口化召回）

• 基准失败： 所有基准和“感知型”运行的约束召回率均为 0/5。上下文窗口的限制导致了无论模型规模如何都会发生的完全失败。
• 重述基准： 被指示在每次回复中重述约束的基准实现了 5/5 召回，这证明了如果智能体积极管理上下文，该任务是可解的，尽管这会产生随工作集规模增长的 Token “租金”。
• 环内记忆： 环内记忆条件在不同模型下的召回率为 3.6–4.8/5。
  • 失败分析： 存储从未丢失事实（244/244 次写入均得到保留）。失误完全是 读取策略失败：智能体过度写入约束（产生了重复项），然后通过一个固定的 $k=8$ 窗口进行单次运行读取，而该窗口被冗余条目挤满了。失败在于智能体的工具使用，而非记忆基质。

3. 延迟的因果影响（循环卫士）

• 单调剂量反应： 在固定预算下，冗余动作随存储延迟增加而单调上升。
  • 进程内 (0 ms)： 0.0 次冗余动作。
  • +15 ms： 1.4–1.6 次冗余动作。
  • +110 ms (云端)： 12 次中的 7.2 次为冗余动作。
• 统计显著性： 对于测试的两种模型，进程内与 110 ms 延迟之间的差异具有统计学显著性（$p=0.0079$）。
• 机制： 在 110 ms 时，预算（100 ms）无法负担单次查找，因此卫士实际上被禁用了。“错误”并非检索错误，而是缺乏检查。
• 每轮 RAG： 行业标准的每轮检索表现良好（0.4–0.6 次冗余动作），但在结构上无法捕捉在单轮内产生的重复项，而进程内卫士捕捉到了所有重复项。

4. 嵌入瓶颈

• 环内堆栈中的主要成本不是存储，而是 嵌入 (Embedding)。网络嵌入 API 的耗时为 200–400 ms。
• 通过将进程内存储与小型本地嵌入器（32M 参数，32 µs）配对，完整的操作（嵌入 + 存储）降至 **40 µs**。这消除了环内记忆的最后一道障碍。

意义与主张

理论贡献：扩展工作记忆

论文将工程发现建立在 扩展心灵论 (Extended-Mind Thesis, Clark & Chalmers, 1998) 之上。它认为，只有当一个外部资源满足以下条件时，它才成为认知（即智能体工作记忆）的“构成部分”：

1. 始终可用。
2. 可以直接访问且无困难。
3. 被自动认可。

作者将前两个条件解释为 延迟预算。一个 100 ms 的网络调用是智能体 咨询 的工具；一个 100 µs 的进程内存储是智能体 拥有 的资源。当延迟低到对推理步骤透明时，存储就从外部数据库转变为 扩展工作记忆。

工程贡献

• 延迟作为设计变量： 论文将检索频率从服务层约束转变为智能体层面的设计轴。它证明了决定因素是存储延迟，而非环内模式本身。
• 因果联系： 它提供了因果证据，表明在固定预算下，存储延迟本身决定了任务结果（冗余动作），且独立于模型能力。
• 架构转变： 它提出记忆应被视为一个按任务分配的循环原语（类似于草稿本/scratchpad），而不是一个连接的服务。

谦逊态度与局限性

作者明确了研究范围：

• 他们并未声称存储使模型变得更“聪明”；模型在没有卫士的情况下仍然无法识别重复项。系统的成功在于 脚手架 能够承担检查记忆的代价。
• “笔记”基准（重述）在处理 5 个事实的小型任务时优于记忆工具，这凸显了重述会产生随工作集增长而增长的每轮成本，而存储则避免了这一点。
• 研究侧重于记忆的 时间性 方面（即记忆何时参与推理）。关于如何保留信息、如何组织信息以及生命周期管理（遗忘/优先级排序）的问题被确定为未来的工作。

总之，论文断言，“环内”模式不仅可行，而且对于需要单轮内状态一致性的任务而言，在提供进程内存储并配对本地嵌入器以消除网络延迟的前提下，具有因果上的优越性。