Hindsight 跨工具共享记忆实战：让 Cursor、OpenClaw 与 Vapi 共用同一个记忆库

Hindsight 跨工具共享记忆实战：让 Cursor、OpenClaw 与 Vapi 共用同一个记忆库

【免费下载链接】hindsightHindsight: Agent Memory That Learns项目地址: https://gitcode.com/GitHub_Trending/hindsight2/hindsight

导读：本文基于 Hindsight 官方博客《One Memory, Three Surfaces》展开，讲解如何让代码编辑器（Cursor）、聊天/Slack 智能体（OpenClaw）与语音智能体（Vapi）三者共用同一个 Hindsightbank（记忆库），实现"一个工具记住的事实，所有工具都能回忆"的跨界面工作流。读完本文，你将掌握 bank 的隔离模型、三个集成各自的关键配置项、共享记忆的搭建步骤，以及多写者场景下 consolidation 如何让共享记忆保持干净与准确。

问题背景：每个 AI 工具都是一座孤岛

在典型的多人协作项目里，开发者往往同时运行多个 AI 工具：用 Cursor 写代码、让 OpenClaw（Slack/Discord 智能体）回答频道问题、再用 Vapi 语音智能体在通勤路上核对方案。没有共享记忆时，每个工具各自为政：你在 Cursor 里作出的技术决策，Slack 机器人不知道；你在聊天里确认的约定，语音智能体也一无所知。结果是同一件事被反复解释——向编辑器解释一遍、向聊天机器人单独培训一遍、再向语音智能体重新简述一遍。

Hindsight 的解法非常直接：所有集成都把记忆写入同一个 bank。任何工具保留（retain）的事实，其他工具在回答前都能回忆（recall）到。三个工具读写的都是同一个存储，无需任何总线、同步任务或各工具独立的"真相副本"。

核心概念：bank 就是共享记忆的边界

在 Hindsight 中，每个集成都把记忆限定在一个bank内——它是唯一的隔离存储单元。从数据模型看，bank 是记忆数据的第一级主键：documents、memory_units、entities等表都以bank_id作为主键或索引前缀，而banks表本身则携带 disposition traits 等档案配置（参见 hindsight-api-slim/hindsight_api/models.py）。因此，"把哪个工具指向哪个 bank"就是决定"谁与谁共享记忆"的开关。

各集成的默认 bank 行为不同：

• 代码编辑器（Cursor）：默认以仓库名为 bank，多个编辑器集成天然对齐；
• 聊天智能体（OpenClaw）：默认按会话动态派生 bank（dynamicBankId: true），需要显式切到静态共享 bank；
• 语音智能体（Vapi）：在构建 webhook 时显式传入bank_id。

三个工具的配置语法各异，但动作完全一致——把每个界面对准同一个 bank id。以原博客中的示例，共享配置如下：

# Cursor: 在仓库内默认使用项目 bank # （也可以在集成配置里显式设置 bank id） # OpenClaw: 默认按会话建 bank，切换到静态共享存储 # dynamicBankId: false, bankId: "acme-web" # Vapi: 构建 webhook 时传入同一个 bank # HindsightVapiWebhook(bank_id="acme-web")

当多个工具的记忆在同一个 bank 里出现重叠时，Hindsight 的 **consolidation（整合）**机制会把重叠事实合并为持久的 observation（观察），而不是堆积三条近乎相同的笔记，从而保证共享存储保持整洁。

一天中的三种界面：共享记忆的实际体验

原博客用一个真实的"一天"来描述共享记忆如何改变工作流：

• 上午，在 Cursor 里做决策。开发者在编辑器里当场拍板："放弃 ORM，数据访问统一走 repository 层。"Cursor 的智能体在完成任务时自动 retain 了这条事实及其推理过程——不需要执行任何"记忆命令"，决策与理由就已落库。
• 下午，在 Slack 里被问到。三个时区之外的同事打开 PR，看到一段手写 SQL 查询，于是在频道里向 OpenClaw 智能体提问。OpenClaw 针对问题做 recall，命中上午的决策，并给出带上下文的回答：我们迁移到了 repository 层、原因是什么、代码在哪个位置。这位同事既不在编辑器会话里、也没参加站会，却通过 Cursor 写入的同一个记忆继承了决策。
• 傍晚，在电话里核对。另一位工程师离开电脑，用 Vapi 语音智能体确认明天的方案："数据访问我们到底定了什么？"语音智能体从同一个 bank recall 并口头复述。无需屏幕、无需搜索、无需翻聊天记录。

**同一个事实，三种界面在同一天内触达，而它只被写入了一次。**这是共享记忆最直观的收益。

深度拆解：三个集成如何读写同一个 bank

Cursor：编辑器 + CLI 的持久记忆

Cursor 有两个实际使用的界面——编辑器（hindsight-cursor，官方维护）和 Cursor CLI（hindsight-cursor-cli，社区构建）。两者都用 Cursor 的生命周期钩子接入 recall/retain：编辑器在每次新聊天的sessionStart做项目级 recall，在stop事件后 retain 会话；CLI 则拥有sessionStart、beforeSubmitPrompt、stop、sessionEnd四个钩子，实现"每次 prompt 前 recall + 会话结束强制 retain"（详见 hindsight-docs/blog/2026-06-12-cursor-persistent-memory.md）。

两个界面默认的 bank id 分别为cursor与cursor-cli。只要在~/.hindsight/cursor.json和~/.hindsight/cursor-cli.json里设置相同的bankId，编辑器与 CLI 之间就共享记忆——例如 CLI 会话里确认的决策，会出现在编辑器下一个新会话的首次 prompt 中。

// ~/.hindsight/cursor.json 与 ~/.hindsight/cursor-cli.json { "hindsightApiUrl": "https://api.hindsight.vectorize.io", "hindsightApiToken": "hsk_your_key", "bankId": "my-cursor-memory" }

OpenClaw：从按会话隔离切换到共享静态 bank

OpenClaw 插件（@vectorize-io/hindsight-openclaw）默认dynamicBankId: true，按agent/channel/user/provider粒度派生独立 bank（dynamicBankGranularity）。在共享记忆场景下，需要把它切到静态共享 bank：

# 安装插件 openclaw plugins install @vectorize-io/hindsight-openclaw # 切换到共享静态 bank openclaw config set plugins.entries.hindsight-openclaw.config.dynamicBankId false openclaw config set plugins.entries.hindsight-openclaw.config.bankId "acme-web"

关键配置项（来自 hindsight-integrations/openclaw/README.md）：

另外，插件在首次使用某个 bank 时会把配置的默认值"盖章"到该 bank 上（applyConfiguredBankDefaults，见 hindsight-integrations/openclaw/src/bank-defaults.ts）：包括retainExtractionMode（事实抽取模式）、enableObservations（保留后是否合成 observation）、enableAutoConsolidation（是否开启自动整合调度）、disposition traits（怀疑度/字面度/共情度，取值 1–5）、entityLabels受控实体标签词表等。这些字段只在首次使用时写入，未配置的字段保持服务端默认，因此共享 bank 的初始行为是可以由配置预先塑形的。

Vapi：一次 recall + 一次 retain 的 Webhook

Vapi 的架构没有逐轮（per-turn）钩子，所以hindsight-vapi采用"每次通话开始时注入一次记忆、通话结束时异步保留整份通话记录"的策略。核心处理器HindsightVapiWebhook（hindsight-integrations/vapi/hindsight_vapi/webhook.py）只处理两类事件：

• assistant-request（来电开始）：以主叫电话号码为查询条件调用 recall，把结果包装成<hindsight_memories>系统消息，通过assistantOverrides.model.messages返回给 Vapi，在 LLM 生成任何 token 之前合入助手配置；
• end-of-call-report（通话结束）：立即返回 200，用asyncio.create_task以 fire-and-forget 方式异步 retain 完整通话记录，不阻塞 webhook 响应。

构建共享记忆的 webhook 与普通用法完全相同，只要求传入与另两个工具一致的 bank id：

from fastapi import FastAPI, Request from hindsight_vapi import HindsightVapiWebhook app = FastAPI() memory = HindsightVapiWebhook( bank_id="acme-web", # 与 Cursor / OpenClaw 同一个 bank hindsight_api_url="https://api.hindsight.vectorize.io", api_key="hsk_your_token_here", ) @app.post("/webhook") async def vapi_webhook(request: Request): event = await request.json() response = await memory.handle(event) return response or {}

Vapi 集成还有两个值得一提的细节：

1. 外呼没有assistant-request事件，需要在创建外呼时用build_assistant_overrides(query)主动构建记忆覆盖（其内部走与入站相同的 recall 逻辑，见build_assistant_overrides的实现）；
2. recall/retain 内部都吞掉异常并记日志（_recall/_retain的try/except），Hindsight 调用失败不会打断 Vapi 通话——recall 失败只是不带记忆运行，retain 失败只是丢失这一份记录。

构造函数上的可调参数还包括recall_budget（low/mid/high，语音场景因只在通话开始时注入一次而余量更大）、recall_max_tokens、enable_recall/enable_retain（可用于先只读观察、后开启写入的分阶段上线）以及memory_prefix。多个助手实例可以通过configure(...)全局配置连接信息，之后每个 webhook 只需指定bank_id。

共享之后发生了什么变化

原博客从四个方面总结了共享记忆前后的对比：

• 不再逐工具重复解释。此前每个界面都是孤岛：单独教 Cursor、单独培训 Slack 机器人、单独给语音智能体做简报。现在第二、第三个工具"本来就知道"。
• 未到场的同事也能继承决策。在 Slack 提问的人从未看过 Cursor 会话，记忆把决策带给了他们——这正是悄然改变团队协作方式的部分。
• 上下文随界面切换而延续，而不只是随会话延续。离开编辑器曾经意味着丢掉上下文；如今从代码切到聊天再切到语音，线索始终在，因为线索存在 bank 里，而不是存在某个应用里。
• 工具之间更少分歧。三个助手读同一份整合后的记忆，倾向于给出同一个答案，而不是三个略有差异的答案。

值得注意的是，这一切不需要引入任何新工作流，只是删除了一个旧工作流——"重复自己"的工作流。

为什么共享记忆能长期保持准确

共享记忆只有在"填满数月、来自三个嘈杂来源的决策"之后依然快速且准确时才有价值。两个机制支撑了这一点：

1. Consolidation 让存储保持蒸馏状态。Hindsight 合并同一实体的相关事实，把"数据层""repository 改造""ORM 移除"解析为同一条决策而非三条。从源码看，consolidation 以 bank 为粒度调度：服务端有banks_needing_consolidation()例行程序筛选"未在 bank 级显式关闭自动整合、且有待处理记忆"的 bank，并支持POST /banks/{id}/consolidation之类的手动触发接口（参见 hindsight-api-slim/hindsight_api/api/http.py 及 hindsight-api-slim/hindsight_api/alembic/versions/e5f6a7b8c9d0_add_maintenance_routines.py）。
2. 检索在数据量大时必须保持精准。这正是 Hindsight 的 BEAM 基准测试所检验的场景——在 1000 万 token 的规模下无法把全部内容塞进上下文。原博客给出的数据是 Hindsight 在 BEAM 上得分 64.1%，次优公开发表结果为 40.6%；该余量正是"一个 bank 支撑三个工具而不退化为噪音"的底气。需要说明的是，此类数字属于博客中陈述的第三方评测结论，具体分数请以相应评测的最新发布为准。

动手搭建你自己的共享记忆

如果你已经在同一个项目上运行不止一个 AI 工具，这通常是"一个下午就能完成"的改动：

1. 为每个工具安装 Hindsight 集成。每个集成都在回答前 recall、在工作中 retain。参考仓库内的集成清单：hindsight-integrations/（Cursor、OpenClaw、Vapi 对应hindsight-integrations/cursor、hindsight-integrations/openclaw、hindsight-integrations/vapi）。
2. 给它们配置同一个 bank id。在仓库内，编辑器集成按仓库名自动对齐；把聊天与语音智能体指向同一个 bank 即可（对 OpenClaw 这类按会话建 bank 的工具，切换到静态共享 bank）。
3. 连接到 Hindsight Cloud 或自托管服务器。自托管可参考 hindsight-api-slim/README.md 的部署方式，或使用 docker/docker-compose/ 下的编排示例。

完成后，在一个工具里做出决策，再到另一个工具里提问——第二个工具已经知道了。

常见问题

工具之间会互相踩踏记忆吗？不会。它们读写同一个 bank，consolidation 会把重叠事实合并成单条 observation 而不是复制多份。写者越多，记忆越丰富，而不是越混乱。

所有东西都必须放在同一个仓库里吗？不必。仓库名只是编辑器集成的默认 bank。任何工具都可以指向任意 bank id——聊天机器人和语音智能体正是借此加入项目记忆的。

这只适用于编码工具吗？不是，这正是重点。本文的三种界面分别是编辑器、聊天智能体和语音智能体。任何拥有 Hindsight 集成的工具都可以共享同一个 bank。

私有的、按用户区分的上下文怎么办？把需要隔离的内容放进不同的 bank。共享是一种你通过分发同一个 bank id 来主动做出的选择，而不是默认就把一切泄露给所有人的设定。

延伸阅读

• One memory for every AI tool：共享 bank 背后的设计理念。
• Cursor 持久记忆、OpenClaw 代码库记忆、Vapi 语音持久记忆：本文涉及的三个集成各自的详细教程。
• Agent 记忆中的整合问题：重叠事实如何变成一条干净的 observation。

【免费下载链接】hindsightHindsight: Agent Memory That Learns项目地址: https://gitcode.com/GitHub_Trending/hindsight2/hindsight