一套从人类决策记录出发，保留原始消息、组织多种检索视图、返回可追溯证据的轻量级长期记忆方案。

• GitHub：

  https://github.com/dlxeva/flowgrid-aml-retriever

• 榜单：

  https://huggingface.co/spaces/agent-memory-leaderboard/leaderboard

FlowGrid 最早只有一份 Markdown 决策日志。

日志记录项目做出了什么判断、有哪些备选方案、为什么选择当前方向、哪些内容已经确认、哪些风险仍未解决，以及什么条件出现时需要重新评估。

最早的记录里已经有决策状态、所属阶段、决策背景、核心问题、备选方案、最终选择、放弃理由、风险判断、后续验证和复盘入口。文件直接给人阅读，也可以被 Git 比较和追踪。即使 Agent 停止运行，人仍能打开文件，理解项目走到了哪里。

随着项目数量和 Agent 协作增加，单份日志遇到了新的问题。决策分散在不同会话和文件中，旧状态可能继续出现在上下文里，新证据又未必能及时到达当前任务。FlowGrid 随后加入来源追踪、时间状态、冲突保留和证据检索。AML 支线进一步加入用户隔离。

这段历史决定了 FlowGrid 的治理哲学：系统要帮助人理解判断的来路，也要保留判断发生变化的过程。

FlowGrid AML Retriever 将这套方法压缩进赛事规定的 Add 和 Search 接口。阅读者由项目负责人变成统一回答模型，任务也随之收窄：保存历史消息，在问题出现时返回相关、完整、可追溯的证据。

首期比赛结束后，这条支线继续演化为独立的 FlowGrid Agent Memory。AML Retriever v1.1 成为通用内核的代码底座，Add 和 Search 保留为兼容与赛事适配层。新的产品内核开始处理原始事件、候选记忆、确认状态、替代与删除、当前状态解析和最小上下文编译。

FlowGrid 没有取得单项第一。它的显式事实召回为 55.59，关系与多跳组合推理为 45.19，个性化与关怀为 51.29。时间与事件序列为 21.13，记忆治理为 27.86，这两项是相对短板。

一个默认不依赖外部模型调用、只使用 Python 标准库和 SQLite FTS5 的系统，为什么能进入前八？

FlowGrid 的成绩来自四项相互约束的选择：原始证据不丢，多种视图并存，检索信号互补，所有派生结果都能回到来源。

FlowGrid AML Retriever 不生成最终答案。

Add 接收用户、会话和消息，完成同步持久化后才返回成功。新消息在接口成功返回时已经可以被 Search 找到。重复的 request_id 与 user_id 组合按幂等请求处理，避免网络重试把同一段记忆写入多次。

Search 始终限定在一个 user_id 内，返回按相关性排序的记忆证据。平台负责后续 Answer 和 Eval。

这条边界让存储、检索和回答可以分别检查。检索系统需要证明自己找回了哪些历史信息，也要说明这些信息来自哪里。

长期对话很少按照问题需要的形状出现。

有些问题只需要一句精确事实。有些问题依赖前后两三轮对话。还有一些问题需要同时看到一段会话里的条件、行动和结果。只按单条消息检索，代词、原因和时间条件容易被切断。只保存大块摘要，姓名、数字、日期和原始措辞又容易被稀释。

FlowGrid 保存每一条原始消息，同时建立三种检索视图。

1. 单消息视图，用于定位直接陈述、姓名、数字和日期。

2. 滑动窗口视图，用于恢复相邻话轮里的指代、条件和补充说明。

3. 会话片段视图，用于保留局部事件的连续结构。

这些视图只改变检索粒度。每个视图都保留 source_message_ids，可以回到生成它的原始消息。窗口和会话片段帮助召回，原始记录继续承担证据来源。

FlowGrid v1.0 的默认路径不使用嵌入模型，也不调用大语言模型。它组合多种可解释信号，覆盖长对话检索里常见的失效点。

SQLite FTS5 提供基础词法召回。英文、数字和日期按词法单元处理，中文使用字符一元组和二元组补足分词能力。它难以处理语义跨度很大的改写，但能稳定保留专有名词、数字、日期和原文词面。

候选进入排序阶段后，系统分别计算原文子串、词项覆盖、实体、数字、日期、可选答案、时间和相邻上下文等信号。选择题中的选项也可以参与检索，为人名、地点和候选事实提供额外线索。

BM25 排名与确定性特征排名随后进入加权倒数排名融合。融合发生在名次层面，避免直接比较不同尺度的原始分数。同内容视图和被其他结果完全覆盖的证据会被去重，为更多独立来源腾出位置。

最终返回结果包含内容、分数、时间、视图类型、原始消息 ID 和证据标记。下游模型获得的是一组可以核验的历史证据。

假设用户先说发布日期定在 8 月 10 日。几天后又补充，发布日期改到 8 月 14 日，因为测试还需要四天。

之后用户询问当前发布日期。

单消息视图可以分别找到两个日期。滑动窗口视图可以把新日期与延期原因放在一起。时间信号知道哪条消息更晚。来源字段保留两条陈述各自来自哪里。

难点在于确认后一句确实更新了前一句。同一项目在更晚时间出现的另一条消息，也可能只是无关提及。

以 v1.0 默认检索器为基线的赛后对照实验，曾尝试更激进的旧值降权。它改善了部分时间问题，却拖累了整体 MRR，因此没有进入默认版本。失败原因很具体：仅凭话题相似和时间更晚，系统会把部分无关的新消息误判成状态更新。

赛后 v1.1 加入受保护的状态更新重排。查询需要具备时间意图，两条证据需要高度相关，较新消息还要包含明确的修改、更正、延期或作废语义。三个条件同时满足时，系统轻微抬高新证据并降低旧证据。旧消息仍然保留，也仍然可检索。

这项机制只处理边界清楚的一小类更新。条件不足时，系统保持原有排序。

AML 检验记忆系统能否为回答模型提供足够证据。FlowGrid 最初面对的任务更宽：当判断需要由人承担责任时，系统还要呈现当前状态、历史变化、冲突来源和采用某条证据的理由。

对统一回答模型来说，同时看到带时间戳的新旧记录，可能已经足以推断当前状态。对项目负责人来说，一百条原始记录仍然是一百条需要重新阅读的材料。人还需要知道当前采用哪条口径、谁在什么时候修改了它、旧口径为何仍被保留、冲突是否已经解决，以及判断出错后如何恢复上下文。

因此，FlowGrid 保留冲突和历史状态，首先服务于人的审计与决策。在 AML 支线中，这套治理哲学还要接受一个更直接的检验：它能否改善最终返回的证据集合和排序。

榜单给出了一个有价值的提醒。有些系统没有显式治理机制，却能获得更高的治理类得分。内部保存了多少状态标签，无法证明回答模型收到了更好的证据。旧值即使下降几个名次，只要仍在 Top K 中，就可能继续影响回答。

FlowGrid 对这一问题的处理是缩小治理规则的作用范围，并用成对实验决定它是否进入默认路径。每项机制都要说明它修复了哪类错误，是否伤害其他查询，是否真正改变了返回结果。缺少这些证据时，机制保持关闭。

43.98 和第 8 名只对应正式参评的 v1.0。

FlowGrid Agent Memory 公开仓库中的 AML Add/Search 适配层版本为 v1.1.0。受保护的状态更新重排尚未获得新的官方榜单成绩。仓库里的数字来自确定性合成评测，用于比较版本，不能换算成新的 AML 综合分。

在 classic、medium、mixed、三个固定 seed、top_k 100 的本地配对实验中，v1.0 基线的 Recall@20 为 0.9948，Recall@100 为 1.0000，MRR 为 0.6728。v1.1 受保护状态更新的 Recall@20 和 Recall@100 保持不变，MRR 达到 0.6948。

更激进的时间权重可以把 MRR 提高到约 0.7040，但会让一个 seed 的 Recall@20 从 0.9870 降到 0.9844。v1.1 没有选择这组参数。该系统以高召回为主要目标，不愿用召回稳定性换取少量前排收益。

这组实验只支持一个有限结论：在当前本地合成协议中，明确更新语义可以减少粗暴时间重排造成的误伤。它不能证明同样的增益会出现在官方隐藏数据中。

FlowGrid 没有依靠一个决定性的模型组件。它减少了多种常见失误。

原始消息完整保存，写入阶段不会因为摘要或事实抽取丢失细节。

消息、窗口和会话片段提供三种召回尺度，问题发生改写时仍有更多可命中的表面。

中文字符片段、实体、数字、日期和选项补充了 FTS5 的基础词法能力。

每个派生视图都绑定原始消息，返回结果可以核验，也可以按用户完整删除。

默认路径没有第三方 Python 依赖和外部模型调用。Add、Search、幂等、用户隔离和同步写后可搜都能确定性复现。

它的代价同样明确。纯词法方案面对语义跨度较大的改写时能力有限，时间表达改写尤其困难。SQLite 适合单节点实现，无法直接承担分布式记忆服务。软重排可以改善证据顺序，不能替代完整的状态判断。

第 8 名说明这条轻量级证据检索路线在第一期榜单中具有竞争力。它没有证明复杂记忆治理已经完成。

首期成绩证明了证据检索底座的竞争力，也暴露了只做 Add 和 Search 的边界。赛后主线已经转向通用 FlowGrid Agent Memory，AML 接口继续保留，用于兼容和后续公开评测。

通用内核将记忆分成三个层次。

第一层是不可变的原始事件。它保存真实发生过的交互和来源。

第二层是由规则或模型提出的候选记忆。候选、推断和未知状态不能自动升级为用户已经确认的事实。

第三层是经过用户、负责人或授权策略确认的当前状态。被替代、否决和删除的内容不会重新进入普通续接，但仍可在获得权限的审计模式中追溯。

Current State Resolver 负责解析当前有效状态。Context Compiler 根据任务、作用域、权限和 token 预算编译最小上下文包。模型可以辅助抽取，治理内核仍然要求来源锚点，并把模型输出限制在 candidate。

下一阶段的主要证据目标是长期真实任务中的续接收益。后续 AML 公开周期仍是外部验证目标，但比赛规则只进入适配器和评测配置。任何赛事改进还要通过 FlowGrid 的治理不变量，避免为了榜单把通用内核写成题型规则。

FlowGrid 从一条给人看的 Markdown 决策日志出发，逐渐获得了结构化状态、来源追踪、冲突保留和证据检索能力。AML Retriever 将这些方法适配成赛事规定的 Add 和 Search。FlowGrid Agent Memory 又把赛事中验证过的检索底座带回通用产品，继续处理当前状态、授权边界和最小上下文。

第 8 名说明它已经能够为回答模型找回一组有竞争力的历史证据。较弱的时间与治理得分指出了下一阶段需要解决的问题。

长期记忆需要回答四件事：这条信息说了什么，它来自哪里，后来发生了什么变化，当前判断为什么采用它。

FlowGrid 希望这些问题始终留有记录，也始终能被人重新检查。

• 项目团队：人工智障研究所

• 项目负责人：杜灵消

• 背景：独立研究员，游戏发行

FlowGrid 是杜灵消发起的本地优先开源项目，关注人和 Agent 如何在长期项目中共享可读、可追溯、可恢复的项目状态。FlowGrid AML Retriever 由项目负责人和 AI 协作者共同完成。项目负责人负责问题定义、系统边界、实验取舍、版本验收和公开口径。

杜灵消目前开发 FlowGrid、Canvas Prompt 等人机协作项目，并运营个人科技内容站人工智障研究所。

• 个人网站：https://aizhiz.com/

• GitHub：https://github.com/dlxeva

• X：https://x.com/dlxeva

• 联系邮箱：[email protected]