OpenViking Working Memory v2 评测报告LoCoMo 长对话召回 79.61%、Token 成本下降 5 倍的结构化工作记忆实践【免费下载链接】OpenVikingSelf-evolving Context Database for AI Agents. Unify Agent Memory, Knowledge RAG and Skills.项目地址: https://gitcode.com/GitHub_Trending/op/OpenViking本报告基于 OpenViking 仓库 examples/openclaw-plugin/docs/workmemory-v2-test-report.md 整理并结合 workmemory-v2-design.md 设计文档与 session.py 源码对结果成因做了解读。文中所有数据均为该测试报告原始记录未做任何推算或外推。导读本文是 OpenViking Working Memory v2以下简称 WM v2的完整测试报告解读覆盖 LoCoMo 长对话事实召回与 MemoryArena 跨会话规划两个基准场景给出旧版基线Main、纯工作记忆WM2-NOREC、WM v2 全功能WM2与 OpenClaw 原生记忆MC四组的准确率、QA tokens 与单题成本tok/correct实测对比。读完本文你将掌握WM v2 相对旧版 structured_summary 到底提升了多少、结构化 7 段模板与增量更新的收益边界在哪里、以及这类「工作记忆 长期记忆向量召回」分层方案的评测方法论。一、测试目标验证 WM v2 四个核心改造的实际收益WM v2 的核心改造点包括结构化 7 段模板、tool_call 增量更新、服务端 Guards与keep_recent_count详见 workmemory-v2-design.md。测试要回答三个问题WM v2 在小样本35Q和大样本152Q下相对旧版 Main 的准确率提升WM v2 结构化 overview 的独立贡献关闭向量召回WM v2 autoRecall 联合方案的最佳效果。测试环境如下项值LLMdoubao-seed-2-0-code-previewEmbeddingdoubao-embedding-vision-251215GatewayOpenClaw 2026.4.27Main 分支OpenViking origin/maincommit4d6f5b65WM2 分支工作记忆代码Judgedoubao-seed-2-0-code-preview-260215二、LoCoMo 长对话事实召回测试2.1 测试组设计测试组说明autoRecall设计目的WM2工作记忆 长期记忆 工具回溯onWM v2 全功能端到端测试WM2-NOREC工作记忆 工具回溯关闭长期记忆off隔离工作记忆 工具回溯的独立贡献看不靠向量召回时还能拿多少分MAIN原 overview 长期记忆 老版工具回溯仓库主分支代码on旧版基线MCOpenClaw 原生记忆关闭 OpenViking—横向对比 OpenClaw 原生记忆方案这个分组是理解全部结论的钥匙WM2 vs MAIN回答「新方案值不值得换」WM2-NOREC vs MAIN回答「结构化工作记忆本身贡献了多少」WM2 vs WM2-NOREC回答「向量召回还有没有增量」。2.2 数据集数据集session 数QA 数说明locomo-small1935LoCoMo sample 0 前 35 题小样本快速对照locomo10 case019152LoCoMo sample 0 完整注意Ingest 和 QA 同会话QA 会话连续复用前题上下文——目的是测试工作记忆而不是长期记忆的跨会话检索。2.3 locomo-small35Q纯工作记忆即 60.0pp测试组准确率QA tokenstok/correctMAIN28.57% (10/35)144,79714,480WM294.29% (33/35)184,4975,591WM2-NOREC88.57% (31/35)124,2464,008MC42.86% (15/35)2,352,395156,826三组关键对比纯工作记忆 vs 旧版 MAIN准确率从 28.57% 提升到 88.57%60.0ppQA tokens 反而下降 14.2%144,797 → 124,246单题成本从 14,480 降到4,0083.6× 效率。仅靠结构化 7 段 overview 工具回溯、无需任何向量召回就已拿到大部分提升且同步节省 token。叠加长期记忆 vs 纯工作记忆准确率再升5.7pp88.57% → 94.29%代价是 QA tokens 增加 48.5%124,246 → 184,497单题成本升到 5,591。长期记忆在此表现为「以 token 换最后一段准确率的细节召回」边际收益递减但仍正向。OpenClaw 原生记忆 MC 横向对照仅 42.86%单题成本 156,826是 WM2 的28 倍准确率比 WM2 低51.4pp无竞争力。2.4 locomo10 case0152Q长样本上纯工作记忆已占整体提升的约 88%测试组准确率QA tokenstok/correctMAIN23.68% (36/152)2,280,09863,336WM279.61% (121/152)1,510,19012,481WM2-NOREC73.03% (111/152)1,622,31914,615纯工作记忆 vs MAIN准确率从 23.68% 提升到 73.03%49.35ppQA tokens 同步下降 28.8%2,280,098 → 1,622,319单题成本从 63,336 降到14,6154.3× 效率。纯结构化工作记忆贡献了整体提升的约 88%49.35 / 55.93且 token 大幅节省。叠加长期记忆 vs 纯工作记忆准确率再升6.58pp73.03% → 79.61%QA tokens再节省 6.9%1,622,319 → 1,510,190单题成本降到 12,481。与 35Q 的「以 token 换准确率」不同长样本上长期记忆是双向收益——既提升准确率又因更高效答题而节省 token。2.5 核心结论汇总LoCoMo 长对话事实召回WM v2 在 152Q 上达79.61%旧版 23.68%55.93pp35Q 上达94.29%旧版 28.57%65.7pp。Token 效率35QWM v2 总 QA tokens 184,497旧版 144,797多 27.4%但准确率涨 65.7pp单题成本从 14,480 降到5,591约 1/2.6。152QWM v2 总 QA tokens 1,510,190旧版 2,280,098节省 33.8%准确率涨 55.93pp单题成本从 63,336 降到12,481约 1/5.1。整体趋势35Q 是「以 token 换准确率」总量略增 单题大幅降本152Q 是双向收益总量降 单题降。纯工作记忆是主体收益关闭长期记忆向量召回仍能达73.03%152QautoRecall 在此基础上再补6.58pp。三、MemoryArena Group Travel 跨会话规划对比MemoryArenagroup_travel_planner是跨会话旅行规划任务slot-filling 后续 QA不直接验证工作记忆能力——每个 task 是独立 session没有跨题上下文累积。它被用来回答另外两个问题与 OpenClaw 原生记忆的差距以及与 OV 主分支无 WM 的严格 A/B 副作用检验。3.1 数据集与方法维度说明数据集MemoryArenagroup_travel_planner270 task / 1869 subtask 的多日多人旅行规划子样本sample0 / sample1 / sample2 共294 道 slot-level QA任务结构slot-filling 旅行规划 后续 QA跨 task 独立 session指标定义Actionslot-filling 规划阶段的执行准确率——agent 在多步规划过程中正确填充 expected slot如 flight number / departure time / arrival time的比例衡量规划执行阶段的动作准确性。QA问答阶段答题准确率——agent 基于 task 上下文回答 slot-level 问题的正确率衡量记忆/检索阶段能力。Combined Tokens规划阶段run 问答阶段QA两阶段总 token。3.2 WM v2 vs MC 原生Action 42.52pp / QA 35.03pp / Token −21.76%方案sample0 Actionsample1 Actionsample2 ActionAgg ActionAgg QACombined TokensMC memorySearch8/10424/7026/12058/294 (19.73%)74/294 (25.17%)7,158,830WM v266/10438/7079/120183/294 (62.24%)177/294 (60.20%)5,601,097WM v2 相比 MC 原生Action 42.52ppQA 35.03ppCombined Tokens−21.76%。在 slot-filling 任务上OpenViking 工作记忆的整体表现远胜 MC 自检索方案LLM 主动调用memorySearch。3.3 严格 A/BWM v2 vs OV-noWM无副作用、大体持平SampleOV-noWM ActionOV-noWM QAWM v2 ActionWM v2 QAsample071/104 (68.27%)65/104 (62.50%)66/104 (63.46%)60/104 (57.69%)sample152/70 (74.29%)45/70 (64.29%)38/70 (54.29%)38/70 (54.29%)sample266/120 (55.00%)58/120 (48.33%)79/120 (65.83%)79/120 (65.83%)Aggregate189/294 (64.29%)168/294 (57.14%)183/294 (62.24%)177/294 (60.20%)WM v2 vs OV-noWMAction −2.04ppOV-noWM 略胜QA 3.06ppWM 略胜token 2.75%。per-sample 异质性较高sample1 OV-noWM 大幅领先、sample2 WM v2 大幅领先aggregate 大体持平——没有显著退化也没有显著提升符合预期slot-filling 不直接受工作记忆改造影响说明 WM 改造在此类任务上没有副作用。四、为什么纯工作记忆能拿到主体收益从源码看结果成因测试结论「关闭向量召回仍能达 73.03%」并非偶然而是 WM v2 三个设计原则在源码层面的直接体现见 workmemory-v2-design.md 与 session.py4.1 固定 7 段结构化模板让「记住什么」变得可维护archive 的.overview.md是固定 7 段结构Session Title / Current State / Task Goals / Key Facts Decisions / Files Context / Errors Corrections / Open Issues每段职责明确LLM 不能随意增删段落。代码中WM_SEVEN_SECTIONS常量见 session.py顺序固定段上限约 2000 tokens、总 WM 上限约 12000 tokens单段 ≥ 25 bullets 或 ≥ 1500 tokens 时触发 consolidation 提醒。有结构才能做增量更新LLM 对每个段独立发KEEP/UPDATE/APPEND未变化的段发KEEP由服务端原样复制——零 token 消耗、零信息丢失。这正是 35Q 上「QA tokens 反降 14.2%」的结构性原因。4.2 信息保留是系统责任5 个段级 Guards设计原则「信息保留是系统责任不是 LLM 责任」落地为服务端 guard 函数session.py段数据特点Guard规则Session Title锚定型_wm_enforce_title_stabilityUPDATE 与旧 title 有效词重叠 1 → 回退 KEEPCurrent State易变型无LLM 可自由 UPDATETask Goals易变型无LLM 可自由 UPDATEKey Facts Decisions累积型_wm_enforce_key_facts_consolidationbullet 数 ≥ 旧 15% 且 lexical anchor 覆盖率 ≥ 70% 双阈值被拒时提取新 items 做 APPENDFiles Context引用型_wm_enforce_files_no_regressionUPDATE 丢失旧路径 → KEEP APPEND 新路径Errors Corrections只增型_wm_enforce_append_onlyUPDATE 降级为 APPEND去重后只追加新条目Open Issues跟踪型_wm_enforce_open_issues_resolved被静默丢弃的 item → 加[restored]标签恢复即使 LLM 说 UPDATE服务端也按段特性决定是否接受Errors 纯 append-onlyUPDATE 总被降级为 APPENDKey Facts 允许「受控合并」通过双阈值验证后才接受 LLM 的合并。这 5 个 guard growth 通用 schema 共有 107 个单元测试覆盖tests/unit/session/test_wm_v2_guards.py、tests/unit/session/test_working_memory_growth.py是「长对话丢信息」这一根因的直接防御。4.3 增量更新协议JSON schema 强约束 完整回退链更新通过update_working_memory工具的 tool_call 提交schema 要求 7 段全部必填、additionalProperties: false漏段/多段/格式错误在 schema 层直接拦截。每段操作被oneOf约束为三种形状{op: KEEP}、{op: UPDATE, content: ...}、{op: APPEND, items: [...]}。服务端_merge_wm_sections(old_wm, ops)按常量遍历 7 段合并并带完整回退链session.pytool_call 缺失 → 重跑创建 prompt传入旧 WM 作为上下文JSON parse 失败 → 正则 recovery → 段级 guard 兜底 KEEPlegacy 格式自动检测检查 overview 是否含 7 段 header旧格式会话走创建路径全量生成、下次 commit 自动升级无需手动迁移。这就是「平滑升级、向后兼容」的保证——不配置新字段时行为完全不变keep_recent_count0等价于全量归档。4.4 滑动窗口与 keep_recent_count归档后的上下文连贯SessionMeta维护pending_tokens与keep_recent_count并持久化到.meta.jsonsession.pyadd_message时新消息进入保留窗口尾部、被挤出窗口的消息 token 累加到pending_tokenscommit时归零GET /sessions/{id}直接读 metaO(1) 判断是否触发归档。服务端有防御性 clamp两者均max(0, ...)CommitRequest.keep_recent_count在 router 层约束ge0, le10_000。插件侧对应配置commitKeepRecentCount默认 10见 config.tsafterTurn 归档时保留最近 N 条消息维持下一轮上下文commitTokenThresholdRatio默认 0.5控制何时触发异步 commitcompact 路径则固定传keep_recent_count0全量压缩。OV 存储模型保证tool_use/tool_result配对完整性归档后工具调用链仍可完整回溯。4.5 assemble 三分区WM overview 成为会话摘要的单一来源上下文组装按 instruction / archive / session 三分区Layer 1 是 ≤8K tokens 的 Archive Memory即 WM 7 段 overviewLayer 2 是未压缩的 live messagesLayer 3 保留 ≥20K tokens 给 LLM 回复空间。pre_archive_abstracts字段保留在 API 中但服务端固定返回空数组插件侧只消费latest_archive_overview。需要细节时模型走两条回查路径ov_archive_expand按archive_id展开单个 archive 原文ov_archive_search按关键词跨 archive grep默认最多 12 条命中、每条 1500 字符、不返回完整原文、正则元字符自动转义为字面量。这套「摘要兜底 按需回查」机制正是测试中「靠结构化摘要本身就能拿到大部分分数」的工程基础。五、结论与适用边界结论在 LoCoMo 长对话事实召回上WM v2 相比旧版 structured_summary 实现了准确率55.93pp / 152Q与单题成本约 1/5.1的双重改善其中纯工作记忆结构化 7 段模板 工具回溯贡献了约 88% 的提升在 MemoryArena 跨会话规划上WM v2 与 OV 主分支无 WM 严格 A/B 大体持平QA 3.06pp / Action −2.04pp相对 MC 原生显著领先QA 35.03pp / Token −21.76%。适用边界务必注意MemoryArena 每个 task 是独立 session、无跨题上下文累积不直接验证工作记忆该任务结论不外推到 LoCoMo35Q 上长期记忆是「以 token 换准确率」152Q 上才是双向收益——长对话场景收益更显著测试基于 doubao-seed-2-0-code-preview 与 OpenClaw 2026.4.27 特定环境换模型/换 Gateway 后数值需重新验证。相关实现与测试的进一步阅读入口session.py7 段常量、guards、滑动窗口、ov_wm_v2 提示词模板、插件配置、设计文档、Guards 单元测试。【免费下载链接】OpenVikingSelf-evolving Context Database for AI Agents. Unify Agent Memory, Knowledge RAG and Skills.项目地址: https://gitcode.com/GitHub_Trending/op/OpenViking创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考