Codex 多仓库记忆隔离实战：用 Hindsight 一仓库一库，告别召回串味

Codex 多仓库记忆隔离实战用 Hindsight 一仓库一库告别召回串味【免费下载链接】hindsightHindsight: Agent Memory That Learns项目地址: https://gitcode.com/GitHub_Trending/hindsight2/hindsight你在 API 仓库里排查一个查询问题Codex 却冒出一句前端仓库的 lint 约定——因为两个仓库共用了同一个记忆银行bank存进去越多召回时无关上下文抢得越凶。用 Hindsight 的多仓库记忆隔离方案两行配置就能把每个仓库的 Codex 记忆分开存放团队规范还能跨仓库共享。下面带你一步步搭起来。先定布局多仓库记忆银行怎么拆 结论先说日常开发用一仓库一库再加一个固定的共享库存团队规范整个布局就齐了。为什么必须拆把 N 个仓库写进同一个银行后每次提问都要从一锅粥里筛相关信息。前端仓库刚 retain存入过的 lint 规则相似度足够高就会抢走本该属于 API 仓库的召回名额。银行级隔离是召回精准的根本一个仓库的记忆只存在于它自己的库里对该仓库的召回就只会看这一处。开启按仓库分库把下面这段写进~/.hindsight/codex.json{ dynamicBankId: true, dynamicBankGranularity: [agent, project] }dynamicBankId是总开关默认关闭dynamicBankGranularity决定银行 ID 用哪几个字段拼接默认代理名 项目目录名。改完立即生效不用重启 Codex。共享库何时用有些知识天然跨仓库组织的 commit 约定、共享 CI 流水线、安全评审要求、人人依赖的内部库。这类内容放进固定的共享银行关掉动态开关、指定一个稳定的库名即可{ dynamicBankId: false, bankId: team-standards }指向同一bankId的银行在各自客户端之间是共享的所以一位队友用 Codex 写进共享库的规范其他队友的会话同样能召回。实用组合就是个人仓库各用各的动态库团队标准走一个具名共享库。银行 ID 是怎么命名的三个粒度词与四层配置 先说命名规则。动态模式下银行 ID 就是把dynamicBankGranularity里列出的字段值用::连起来。Codex 可用的字段有四个agent代理名取agentName配置默认codexproject当前工作目录的基名拿不到就是unknownsession本次会话 IDuser环境变量HINDSIGHT_USER_ID缺省anonymous所以在~/projects/api目录下跑默认配置得到的库名就是codex::api换成frontend目录就是codex::frontend。目录名里的空格、中文等特殊字符会原样保留不做 URL 编码——这对你来说是好事不用去猜编码后的名字。静态模式dynamicBankId: false则直接返回bankId配置值默认就是codex如果还设了bankIdPrefix结果会变成前缀-库名的形式。再说配置从哪来。插件按后写覆盖前写的顺序读四层内置默认值 → 安装时落盘的~/.hindsight/codex/settings.json→ 用户配置~/.hindsight/codex.json→ 环境变量。第三层是推荐改的位置升级不会丢第四层适合临时切换场景比如HINDSIGHT_DYNAMIC_BANK_IDtrue就地开启分库或HINDSIGHT_BANK_ID、HINDSIGHT_AGENT_NAME、HINDSIGHT_RECALL_TIMEOUT、HINDSIGHT_DEBUG这类变量单独覆盖某个键。排查配置不生效时先确认它没被更靠后的层盖掉。什么该写进银行什么时候写什么时候读 内容分类决定回报。按仓库分库之后放什么进去最值类型为什么值得记不值得记的反例工程决策从 diff 里反推为什么这么选很贵从记忆库里召回很便宜中途反复摇摆、尚未定案的讨论历史排障根因故事如某 401 是时钟偏移能让重复事故变成一次快速召回一次性的环境抖动、临时网络故障已知脆弱区记下内有恶龙的模块阻止 AI 用踩坑方式重新学已修复且加了防护的老 bug项目约定技术栈、lint 命令、测试运行器新会话不用重复解释一次性的安装步骤、临时命令写入时机由钩子决定分三段看。会话开始时SessionStart钩子在后台预热 Hindsight 服务让后面的召回不用冷启动。每次你提问前UserPromptSubmit钩子把最近几轮对话拼成查询调召回 API 把命中的记忆包进hindsight_memories注入上下文——整条链路永远以退出码 0 收尾任何错误都只降级、不打断对话。每轮结束后Stop钩子读取会话 transcript 按retainMode入库默认的full-session模式在会话结束时存整份对话由 Hindsight 从中抽事实你正常干活就行chunked模式则按retainEveryNTurns默认 10轮取带重叠的窗口滚动保存。文档 ID 默认用会话 ID同一会话反复 upsert 不会产生重复记录。怎么确认隔离真的生效三问自检✅ 别靠感觉没问题用三个问题逐项验证。一、能召回吗在一个仓库里让 Codex 明确说出一个约定或决策比如重试为什么这么改结束会话后在同一仓库开新会话直接问它。答不出来时确认两次运行派生的是同一个库名代理名、目录名是否一致确认autoRetain没被关掉full-session模式下会话没结束前记忆还没落库先把retainEveryNTurns调到 1 再测。二、会串库吗换到另一个仓库问同样的问题。按仓库分库后第一个仓库的答案不该出现。若冒出来了检查dynamicBankId是否真的为true——环境变量或旧的settings.json可能把它压回了false打开HINDSIGHT_DEBUGtrue看 stderr 里钩子实际派生的库名最直观。三、两边 bankId 一致吗手动对一遍命名规则动态模式按代理名::目录名静态模式按配置值可能带前缀。两次会话的库名不一致召回必然落空。容易踩的坑所有仓库都堆进默认codex库写进去的仓库越多召回和无关上下文的竞争越激烈这是噪声召回的根源。团队规范放进某个仓库的库一换仓库就失效跨切标准必须走固定bankId的共享库。期待 A 仓库能召回 B 仓库的记忆银行间数据严格不流动这是特性不是缺陷。会话还没结束就去测召回full-session模式整份 transcript 是会话结束时才存的早了测就是没记住。改完配置不验证生效层codex.json写得对但环境变量或旧安装配置把它覆盖了白改。FAQ这套策略必须用 Hindsight Cloud 吗不用。自托管的 Hindsight 服务器或本地hindsight-embeddaemon 效果一样银行布局和后端选型是两回事连接方式见 Codex 安装指南。目录名带空格或中文会有问题吗不会库名原样保留目录基名。但注意别事后改名——目录名一变派生出的库名就变了等于换了个空库。召回和保留走的是同一个库吗是。两边用同一套派生规则保证写进哪就从哪读这也是验证时两边 bankId 一致必须成立的原因。想临时不注入记忆怎么办把autoRecall关掉即可想控制注入量就调小recallMaxTokens或recallMaxQueryChars。动手清单还没装钩子先按 Codex 安装指南 完成安装并连上后端Hindsight Cloud 或本地 daemon。对照 Codex 集成 README 的完整配置表把dynamicBankId和共享库的bankId落到~/.hindsight/codex.json。不确定默认值时直接翻 settings.json 里的出厂配置。想彻底搞懂命名规则读 bank.py 的派生实现和 test_bank.py 里的边界用例再跑一遍三问自检。【免费下载链接】hindsightHindsight: Agent Memory That Learns项目地址: https://gitcode.com/GitHub_Trending/hindsight2/hindsight创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考