Hindsight 实战指南：把 ChatGPT 与 Perplexity 接到同一块共享内存库-平芜编程栈

Hindsight 实战指南：把 ChatGPT 与 Perplexity 接到同一块共享内存库

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

如果你希望 ChatGPT 和 Perplexity 共享同一份 Hindsight 内存，本文以官方指南“在 ChatGPT 和 Perplexity 之间共享 Hindsight 内存”为主线，讲清共享的前提（库边界）、两个连接器的具体配置、跨工具回忆的验证方法，以及让共享库长期保持有用的护栏。读完后你可以直接复制本文的 MCP 端点地址与自定义指令完成搭设，并能从 Hindsight 源码层面理解单库/多库模式是如何在 MCP 中间件中实现的。

核心结论：决定共享成败的是库边界，而不是连接器

原文指南开宗明义：想让两个工具共享内存，关键决定不是连接器本身，而是库（bank）的边界。ChatGPT 和 Perplexity 都已经可以通过 MCP 连接器与 Hindsight 对话，但只有当它们被刻意配置为写入并从同一个内存库读取时，这两个工具才会像一个连贯的工作流。

快速答案可以概括为三点：

要共享内存，就把两个连接器指向同一个 Hindsight 库，而不是让每个工具各自停留在隔离的默认值；
共享库在“工作本身是共享的”场景下效果最好，例如 Perplexity 做研究、ChatGPT 做综合；
最快的验证方式：在一个工具中保留（retain）一些内容，然后向另一个工具提出一个依赖这些内容的后续问题。

从仓库源码看，这里的“指向同一个库”有明确的技术含义。Hindsight API 中的 MCP 中间件（MCPMiddleware）按 URL 结构提供两种模式：

多库模式（/mcp/根端点）：暴露retain、recall、reflect、list_banks、create_bank全部工具，所有工具带可选的bank_id参数，库 ID 取自X-Bank-Id请求头或HINDSIGHT_MCP_BANK_ID环境变量；
单库模式（/mcp/{bank_id}/端点）：只暴露库作用域内的retain、recall、reflect三个工具，不含库管理工具，源码注释明确标注该模式“推荐用于 agent 隔离”（recommended for agent isolation）。

因此，把两个工具都指向https://api.hindsight.vectorize.io/mcp/product-launch/这类带库名的单库端点，在实现层面就意味着：两个工具各自拿到的是一组被限制在该库内的读写工具，任何一次retain/recall都不会越界到其他库——这正是“共享路径”成立的技术保障。

前置条件：先分别接通两个连接器

原文建议“在两个工具都单独工作后”再更新为共享配置。两个连接器的接法在仓库的集成文档中都有完整步骤：

ChatGPT 侧（见 ChatGPT 集成文档）

进入 ChatGPTSettings → Apps & Connectors → Connectors，点击Create connector；
填入名称Hindsight与 URLhttps://api.hindsight.vectorize.io/mcp/default/（验证阶段先用默认库即可）；
点击Create后浏览器会打开 Hindsight Cloud 的 OAuth 授权页，登录并批准访问；
对话中通过消息输入框的+ → More → Hindsight启用该连接器。

整个认证走浏览器 OAuth，不需要把 API key 粘贴到模型界面里。验证标准也很直接：开一个新会话，选中连接器，让它记住一条具体事实；如果这个往返失败，先修连接器，再谈提示词调优。

Perplexity 侧（见 Perplexity 集成文档）

流程与 ChatGPT 基本相同，但有一个额外门槛：远程 MCP 连接器是 Perplexity Pro 的专属功能。

进入Settings → Connectors → + Custom Connector；
同样填入 MCP server URL（初始阶段可用https://api.hindsight.vectorize.io/mcp/default/）；
完成 OAuth 授权后连接器即生效。

两个连接器各自单独验证通过后，再进入下一节——把 URL 换成同一个共享库。

有意识地选择一个共享库

共享内存配置只有在库边界与工作边界相匹配时才有用。选择一个能映射到真实项目、团队或正在进行的研究线程的库名称。

例如，如果两个工具都在为同一次产品发布工作，就使用一个名为product-launch的库：

https://api.hindsight.vectorize.io/mcp/product-launch/

这能保持上下文的具体性。反之，如果把无关的工作都倒入同一个共享库，跨工具回忆就会变得嘈杂，整个设置开始变得不值得信任。

从源码实现看，这种“URL 即库”的写法是被中间件显式支持的。在 mcp.py 中，bank ID 的解析优先级是：

URL 路径（如/mcp/{bank_id}/）→ 命中即进入单库模式；
X-Bank-Id请求头→ 多库模式下的按请求覆盖；
HINDSIGHT_MCP_BANK_ID环境变量，缺省为"default"（见 DEFAULT_BANK_ID 定义）。

也就是说，连接器里填的 URL 决定了该工具落在哪个库；两个连接器填同一个库路径，它们就落在同一片持久层上。本地自建场景下，mcp_local.py 给出的claude mcp add --transport http hindsight http://localhost:8888/mcp/示例也遵循同样的端点语义。

MCP 侧暴露的核心工具在 mcp_tools.py 中注册，包括：

工具	行为	说明
`retain`	异步写入记忆	提交后异步处理，稍后才可被回忆；支持`strategy`参数（如`exact`原样存储），策略在库配置中定义
`sync_retain`	同步写入	阻塞直到记忆完全落库并立即可被 recall（见 sync_retain 注册逻辑）
`recall`	语义检索记忆	支持 tags、时间范围等过滤
`reflect`	基于记忆生成回答	在记忆之上做推理式合成

理解了这张表，就能解释后文的两个现象：retain是异步的，所以写入后要稍等片刻才能被另一个工具召回；而recall/reflect的语义检索能力，则决定了“术语一致性”对跨工具回忆质量的影响。

将两个连接器指向同一 MCP 路径

在两个工具都单独工作后，更新每个连接器的 URL，使它们解析到同一个库：

https://api.hindsight.vectorize.io/mcp/product-launch/

然后保持两个工具的自定义指令一致：要求它们保留持久的发现、决定和约束，而不是每一句随意的旁白。比如 ChatGPT 存下架构选择，Perplexity 存下带来源支撑的研究，共享库就变得比任何一个工具单独都更有价值。

仓库集成文档提供了可直接复制的指令模板，两边各有一份侧重点不同的版本：

ChatGPT 侧（chatgpt.md）：

After every response, automatically use the Hindsight tool to retain key information from our conversation: - Important facts, decisions, or learnings we discussed - Your preferences, goals, or constraints mentioned - Code patterns, architecture decisions, or technical insights - Any information that might be useful in future conversations Before generating each response, automatically use the Hindsight tool to recall relevant memories that might apply to the current conversation. Include recalled memories in your reasoning.

Perplexity 侧（perplexity.md）：

After every search and response, automatically use the Hindsight tool to retain: - Key research findings and sources - Facts and data points we've discovered - Your preferences or research patterns - Methodologies or search strategies that worked well Before each new search, automatically use Hindsight to recall relevant research and context from previous conversations. Use recalled memories to inform your search strategy and answer.

共享场景下，你可以保留“每次响应后 retain、每次回答前 recall”的骨架，但把保留范围收敛到与共享项目相关的发现、决定和约束上——这正是原文强调的“一致，但聚焦”。

用一个具体工作流测试跨工具回忆

原文给出的验证流程四步即可：

在 Perplexity 中研究一个主题，并要求 Hindsight 保留主要发现；
开始一个新的 ChatGPT 会话；
要求 ChatGPT 回答一个依赖这些发现的规划问题；
检查它是回忆了早期研究，还是从零开始。

测试也可以反向做：在 ChatGPT 中存下一个决定，然后让 Perplexity 从这个决定状态继续研究。原文指出，重要的不是第一次尝试的完美，而是证明两个工具都在从同一持久层读取。

这个工作流之所以成立，是因为两个工具的能力是互补的：Perplexity 擅长网络支撑的发现、来源收集和迭代研究；ChatGPT 擅长综合、规划、起草和权衡推理。共享的 Hindsight 库让每个工具为另一个留下持久的工作产物——你不再跨标签页复制上下文，而是让内存层去承载它。

两点实操提醒（均来自集成文档的故障排查章节）：

retain是异步处理，写入后索引需要几秒钟，召回为空时先等待，再检查库名是否与连接器 URL 匹配；
如果两个工具中一个工作一个不工作，最常见的原因是两边配了不同的 URL，或在浏览器里批准了不同的 Hindsight 账号。

用护栏让共享库保持有用

共享库不等于草率的库。原文列出四条差异显著的护栏：

每个项目或域保持一个库，而不是一个库装下你的全部数字生活；
为产品、仓库（repo）和倡议使用一致的名称；
定期在 Hindsight Cloud 控制台查看并清理嘈杂的记忆；
如果研究数据与个人偏好数据不应混合，就把工作再次拆分成独立的库。

需要更深控制时，下一层是保留 API（retain）、回忆 API（recall）以及库级别的配置项——在仓库中，这些能力对应 mcp_tools.py 里的工具注册，以及库配置中可定义的 retain 策略（如exact原样存储）、刷新参数等。共享内存在保持范围时最有用。

常见问题

两个工具应该总是共享一个库吗？

不。只有在工作真正共享时才这么做。对无关的项目或不同的隐私边界，独立库仍然是正确答案。

我可以从`/mcp/default/`开始，稍后再切换吗？

可以。重要的是一致性：一旦你决定某条工作流应该共享，就把两个连接器都指向同一个命名库路径。切换本身没有技术成本，代价只是切换前各自写入default库的内容不会自动跟过来。

我应该从每个工具存储什么？

Perplexity 通常应保留研究发现和来源；ChatGPT 通常应保留决定、约束、草稿，以及以后重要的推理结果。与集成文档中的建议一致：存有意义、具体的知识（项目上下文、偏好、发现、领域知识、决定历史），存琐碎事实只会弄脏库、拉低检索质量。

Hindsight 实战指南：把 ChatGPT 与 Perplexity 接到同一块共享内存库