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

本文提出“Memory in the Loop”范式：将记忆存储从外部网络服务移到agent主循环内部，在每个推理步骤同步读写，而非每轮仅一次。关键在于使用进程内存储（100us查询延迟，比网络存储快三个数量级），实证表明在固定内存延迟预算下，冗余动作随延迟单调增加（进程内0/12 vs 云端7.2/12）。实验覆盖GPT-5-nano/mini四个模型，在有限窗口下将回忆准确率从0/5提升至3.6-4.8/5且存储操作p50仅80-165us。瓶颈被重新定位到embedding（网络200-400ms），若配合本地小embedder可将完整操作降至40us。

1. 直接可用于导购/agent产品：当前导购agent需要持续跟踪用户意图和对话上下文，现有外部向量库一次一轮的查询模式无法捕获步骤间的状态变化。采用进程内内存（如SQLite、内存KV）按步读写，可以低成本实现类似“技能记忆”的效果，减少重复推理和误解。
2. 技术选型判断：之前我更关注网络化memory（如Pinecone/Redis）的调度优化，但本文指出延迟的本质是存储位置而非模式。我的技术栈应优先考虑进程内选项，配合本地小embedder（如all-MiniLM-L6-v2）实现微秒级全链路。
3. 下一步行动：在我的导购agent原型中引入进程内memory存储（举例：用Python dict + 本地embedding模型），对比相同任务上现有外存方案的准确性、token效率和端到端延迟。同时关注作者后续关于in-process memory与思考链、工具调用的耦合研究。
4. 对LLM选型的启示：文中GPT-5模型显示出对“重复回复”的敏感度——当延迟高时agent会重复无用动作，低延迟则消除了这种行为。在选择模型时，不仅要看推理速度，还要看它是否支持高频率的memory交互。