用于 Agent 编队的共享内存：hermes-memory-pgvector
当你运行不止一个 AI agent —— 比如营销小助手、交易小助手、事件响应小助手 —— 它们都需要内存。内置的内存工具会给每个 agent 各自一份内存。这没问题，直到你想让它们共享，或者直到你想回忆 agent 六周前学到了什么，而不必为了查一下它就支付一次 LLM 往返调用的成本。
hermes-memory-pgvector 是一个小型的 Postgres + pgvector 插件，它会把 agent 的内存写入镜像到一个共享的、可嵌入、可查询的存储中。已在 PyPI 发布，版本为 v0.4.0。
v0.4.0 新内容
最新版本延续了“不要让 LLM 处于关键路径中”的原则，并新增了四项存储层能力：
- 身份治理。 直接消息会话键会合并为一个兼顾隐私的单一桶 — 不会按联系人无限膨胀主题，也不会包含 PII — 基准测试流量会被隔离，并且可选的允许列表会把拼错的主题名称路由到安全默认值，而不是悄悄创建一个新的。
- Agent 归属与委派。 一个新的注册表和溯源边记录哪个 agent 把什么委派给了谁，可通过数据库视图查询。纯粹记录“谁/何时”的溯源信息 — 绝不是事实存储。
- Embedding 回填。 在 embedding 端点故障期间以纯文本写入的行不再被困住：一个幂等命令会重新生成它们的 embedding，使其再次可搜索。
- 会话 TTL 与成本控制。 由操作员运行的清理会裁剪旧的聊天轮次（持久记忆绝不会被触碰），而 embedding 策略可以上调或下调 embedding 成本。
所有功能都通过一个维护 CLI（hermes-pgvector）提供，其破坏性命令默认使用 dry-run。v0.4.0 可从 v0.3.x 直接升级 — 只需应用一条增量迁移，新钩子就会启用；如果跳过它，其余一切都会保持不变地运行。
它实际做什么
一句话：“一个存储层，为内置记忆模型提供持久的、多租户的、可语义搜索的后端支持，并且不让 LLM 处于关键路径中。”
两张表，都带有 HNSW 向量索引。memory_entries 会把写入镜像到 agent 的 MEMORY.md/USER.md 文件中。conversations 存储实质性的聊天轮次（≥40 个字符，过滤掉模板化内容）。Embedding 维度为 768，由外部端点计算 —— Ollama、兼容 OpenAI 的服务，任选其一。agent 永远不会在这里被阻塞：写入只需微秒级返回，而 embedding 工作器会在后台队列中处理其余部分。
默认按每个 agent 分主题
每个请求都会携带一个 X-Hermes-Session-Key 标头，用 agent_identity 对数据进行范围限定。营销笔记不会污染交易回忆。当你确实想进行跨主题搜索时，请显式传入 scope='all'。默认值是更安全的那个。
为什么是独立项目，而不是 fork
hermes-agent 按政策关闭了其内置记忆提供者列表，因此这里是作为一个独立的 /plugins 目录扫描项存在，而不是上游 fork。把它放到 agent 旁边，设置几个配置键，然后重启。回滚也是对称的：禁用提供者，必要时删除这些表。无需迁移长期存在的状态，也不需要维护内核补丁。
它 不是 什么
不是 Honcho 的替代品。不是知识图谱。不是 RAG 框架。它有意设计成一个很薄的层，只做一件事——把内置记忆工具变成一个共享、持久、可向量搜索的存储——然后让开。没有 LLM 派生器，没有辩证循环，也不对你应该如何分块或重排序发表意见。只是向量数学。
获取它
pip install hermes-memory-pgvector
源码、迁移和配置在 GitHub 上：