Hindsight 记忆银行按仓库隔离：3 个配置项终结 Codex 跨项目记忆污染-港品优选

Hindsight 记忆银行按仓库隔离：3 个配置项终结 Codex 跨项目记忆污染

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

给 API 仓库修查询 bug，Codex 的召回里却冒出前端仓库的 lint 约定——不是记忆出错，是它们挤在同一个记忆库里。Hindsight 的记忆银行（bank，按主题隔离记忆的容器）支持动态银行 ID，一行配置就能让每个仓库拥有私有记忆库，另加一个固定银行承载团队规范。

30 秒结论
结论：日常开发按仓库分库，跨仓库标准放一个固定共享库，召回互不污染。
何时用：你让 Codex 同时维护两个以上仓库，且希望新会话自动记得老会话的决策。
核心配置：~/.hindsight/codex.json里dynamicBankId: true+dynamicBankGranularity: ["agent", "project"]。
验证：同一仓库新会话能召回旧决策，另一个仓库问同样问题保持干净。

一个`codex`银行装下所有仓库，代价是什么

把~/projects/api和~/projects/frontend都指向默认的codex银行时，每次写入都在扩大下一次召回的候选池。某天你让 Codex 修 API 仓库的分页查询，注入的上下文里却混着上周前端仓库的 lint 规则——它们相似度足够高，又恰好是最近写入的，于是挤掉了真正相关的记忆。

这不是数据损坏，所有记忆都真实存在，但召回预算被无关仓库瓜分。召回精度是银行层面决定的：一个仓库的记忆只落在自己的银行里，对该仓库的 recall 就只在这个空间里检索，噪声在入口被挡掉，而不是靠调参事后补救。

分库落地三步：准备 → 配置 → 派生验证

第 1 步：确认三个钩子已经就位

分库生效的前提是记忆流水线已在跑。装好钩子后，会话生命周期的三个时点由 hooks.json 接管：

SessionStart：会话开始，后台预热 Hindsight 服务器；
UserPromptSubmit：每次提问前，从对应银行召回记忆注入上下文；
Stop：每轮结束，把会话内容写入长期记忆。

第 2 步：核心配置——开启动态银行 ID

在~/.hindsight/codex.json（官方推荐的用户配置位置，升级不会丢）里写两个字段：

{ "dynamicBankId": true, "dynamicBankGranularity": ["agent", "project"] }

project维度取工作目录的基名，agent取代理名（缺省codex）。效果：在~/projects/api和~/projects/frontend里跑 Codex，会分别存入、召回各自的银行，跨仓库零泄漏。不想碰配置也能切分库：config.py支持环境变量直接覆盖，HINDSIGHT_DYNAMIC_BANK_ID=true即可，团队可用环境变量统一推配置，个人则把agentName之类的差异项写在codex.json里，互不干扰。

第 3 步：读一遍派生源码，确认银行名不会漂移

银行 ID 的拼接规则集中在 scripts/lib/bank.py 的derive_bank_id（L24-L65），两条路径：

# 非动态：bankIdPrefix 拼前缀，bankId 缺省 "codex" return f"{prefix}-{base}" if prefix else base # 动态：按 dynamicBankGranularity 取维度值，"::" 连接 segments = [field_map.get(f, "unknown") for f in fields] base_bank_id = "::".join(segments)

每个维度对应一个固定来源：agent→ 配置的agentName；project→ cwd 基名，空则unknown；session→ 钩子输入的session_id；user→ 环境变量HINDSIGHT_USER_ID，缺省anonymous。目录名里的空格、Unicode 原样保留，不做 URL 编码，两次运行只要 cwd 相同，银行 ID 必然一致。

对应的测试 tests/test_bank.py 把派生规则全部钉死：agentName="mybot"且 cwd 为/home/user/hindsight时得到mybot::hindsight（L41-L45）；目录名含空格、UTF-8 时结果不含%（L47-L57）；cwd 为空时 project 维度落unknown（L81-L84）。配置侧的加载顺序见 scripts/lib/config.py：内置默认值 → 安装时写入的~/.hindsight/codex/settings.json→ 用户配置codex.json→ 环境变量，后者压过前者。

读写两端各自做什么

recall.py每次提问前派生银行 ID → 组装查询（recallContextTurns带多轮上下文，recallMaxQueryChars截断）→ 召回结果用<hindsight_memories>标签包裹注入，任何异常都以退出码 0 降级，不打断对话。retain.py读transcript_path指向的会话记录：retainMode默认full-session整段保留；切chunked则按retainEveryNTurns（默认 10）取窗口、retainOverlapTurns（默认 2）留重叠。文档 ID 默认复用session_id，同一会话反复 upsert 同一篇文档。

该沉淀什么、该共享什么：内容放置对照

内容类型	放哪里	为什么
仓库约定：技术栈选择、lint 命令、测试运行器、发布流程	该仓库的按仓库银行	每个新会话都要重新解释一遍的东西
排障根因："auth 401 是时钟偏移"	该仓库的按仓库银行	复发性 bug 会回来，召回一次胜过重查一次
工程决策：为什么加指数退避、为什么选这个库	该仓库的按仓库银行	从 diff 反推很贵，直接召回很便宜
团队 commit 规范、共享 CI、内部 SDK 用法	固定共享银行	必须跨仓库生效才叫团队标准
临时草稿、一次性命令	不存	不值得占用召回预算

团队规范走固定银行，关掉动态即可：

{ "dynamicBankId": false, "bankId": "team-standards" }

指向同一bankId的集成互相可见：队友 Codex 沉淀进team-standards的规范，你的每个仓库会话都能召回。

验证清单：隔离生效与 4 个误配信号

四步验证序列：1. 在仓库 A 让 Codex 记录一个决策（如为什么加指数退避重试）；2. 结束会话，让 transcript 完成 retain；3. 在 A 开新会话问该决策，应被召回；4. 在仓库 B 问同样问题，不应浮出 A 的答案。

执行对照，逐条可直接排查：

若第 3 步召回为空，则确认两次运行派生出相同银行 ID（agentName与 cwd 一致），必要时开debug看派生日志。
若在会话中途就测召回落空，则因full-session模式要等会话完整结束才 retain；验证期可把retainEveryNTurns从 10 临时调到 1，让每轮都触发写入。
若第 4 步浮出了 A 的答案，则dynamicBankId未真正生效，查~/.hindsight/codex.json或被HINDSIGHT_DYNAMIC_BANK_ID反向覆盖。
若团队规范在别的仓库召不回，则误放进了按仓库银行——跨切标准必须进固定bankId。
若你正指望 A 仓库召回 B 仓库的决策，则预期错了：银行隔离是严格的，数据不跨银行流动，隔离本身就是特性。

高频疑问

必须用 Hindsight Cloud 吗？不用。自托管 Hindsight 服务器或本地 embed daemon 行为一致，银行布局与后端无关。

同一个库为什么有的记得、有的不记得？大概率是两次运行派生出了不同银行 ID。project维度取 cwd 基名，只要工作目录或agentName不一致，就会落到不同银行；用HINDSIGHT_DEBUG=1跑一遍，对比两次派生值即可定位。

企业官网建设流程全解析