MemOS 与本机 memory-tencentdb 对比研究

研究时间：2026-06-04 ｜对象：MemTensor/MemOS main 分支、本机 Hermes default profile 的 memory_tencentdb

一句话结论：当前不建议把 Master 的主记忆立刻从 memory-tencentdb 切到 MemOS；MemOS 更像“下一代可观测、自进化、技能化记忆层”，适合并行灰度和评估，但本机当前 TencentDB 已经稳定承载用户画像、场景块、原始对话和 Telegram 工作流，短期应保留为主系统。

1. 快速结论

当前主系统继续用 TencentDB稳定、已接入 Hermes、数据新鲜、符合现有工作流。

新系统定位MemOS 并行灰度适合做实验副本、可观测面与技能结晶评估。

迁移策略不要硬切先镜像写入/导入历史，再做召回 A/B。

最大风险双记忆污染同时自动注入会互相覆盖、重复、放大错误。

2. 本机 TencentDB 现状证据

项目	证据	判断
Hermes 配置	`/root/.hermes/config.yaml`：`memory_enabled: true`、`user_profile_enabled: true`、`provider: memory_tencentdb`、`flush_min_turns: 6`	已作为主记忆启用
插件接入	`/root/.hermes/hermes-agent/plugins/memory/memory_tencentdb` 指向 `/opt/TencentDB-Agent-Memory/hermes-plugin/memory/memory_tencentdb`	Hermes 原生 Provider 已接入
Sidecar 健康	`127.0.0.1:8424/health` 返回 `{"status":"ok","version":"0.1.0","stores":{"vectorStore":true,"embeddingService":false}}`	服务健康；embeddingService=false 是当前灰度召回模式，不等于故障。
数据新鲜度	`conversations/2026-06-04.jsonl`、`records/2026-06-04.jsonl`、`scene_blocks/内置记忆迁移承接.md` 均在当天更新	持续写入
数据规模	13 个 conversation 日文件、13 个 records 日文件、5 个 scene blocks	轻量但有效，更像“高价值工作记忆”而非大规模知识库。
当前注入效果	本轮已注入 persona、scene navigation、memory tool guide，并准确带出用户偏好与代理治理背景	实际召回已在工作

3. MemOS 研究摘要

维度	MemOS 事实	含义
项目成熟度	GitHub：约 9533 stars、864 forks、229 open issues；最新 release `v2.0.17`，仓库当天仍有 push	活跃度高，但 issue 也多，仍处快速迭代期。
核心定位	README 称其为 Memory Operating System，统一 store / retrieve / manage，支持 KB、多模态、工具记忆、企业优化	定位比 memory-tencentdb 更大：不只是个人长期记忆，而是 agent memory 平台。
核心抽象	MOS、MemCube、Plaintext / Activation / Parametric memory；MemCube 可按用户、agent、session 隔离和组合	适合多用户、多 agent、多知识库组合。
开源服务部署	Python 包 `MemoryOS 2.0.17`；依赖 FastAPI、SQLAlchemy、PyMySQL；完整模式还涉及 Neo4j、Qdrant、Redis、RabbitMQ、Milvus、torch、sentence-transformers 等可选组件	能力强但重。若全量部署，运维复杂度显著高于当前 TencentDB sidecar。
Hermes 本地插件	`@memtensor/memos-local-plugin 2.0.5`，宣称支持 Hermes；默认数据目录 `~/.hermes/memos-plugin/`，Viewer `127.0.0.1:18800`	这是与本机最相关的路线，不必一开始部署全量 Python MemOS 服务。
本地插件架构	Node/TypeScript core + Python Hermes Provider，经 stdio JSON-RPC 调 `bridge.cts`；SQLite 存 L1/L2/L3/Skill/Episode/Feedback	与当前 TencentDB 的 Node sidecar 模式类似，但算法层更复杂。
记忆层	L1 Trace、L2 Policy、L3 World Model、Skill；三层检索 Skill → Trace/Episode → World Model；融合 vector、FTS5、keyword、error-signature、RRF/MMR	比 TencentDB 更偏“行动经验学习”。
可观测性	本地 Viewer 包含 Overview、Memories、Tasks、Policies、World Models、Skills、Analytics、Logs、Import、Settings	对用户“写入≠生效”的验证偏好很有价值。

4. 能力对比

能力	memory-tencentdb 当前表现	MemOS / memos-local-plugin 表现	谁更适合当前 Master
Hermes 接入稳定性	已运行，Provider 已启用，sidecar 健康，当前对话真实注入	有官方 Hermes adapter，但本机尚未安装；需要改 provider、装 Node 插件、重启 Hermes	TencentDB
用户画像/场景块	L0 对话、L1 records、L2 scene_blocks、L3 persona 已符合当前使用习惯	World Model / Policy 更抽象，但需要累计和调参	TencentDB 短期更可靠
工具失败经验学习	主要靠 records/scene/skills 手工治理；工具级失败学习有限	明确记录 tool call、tool result、error signature、decision repair	MemOS 潜力更大
技能自动结晶	Hermes 已有手工 skill 管理；TencentDB 不负责自动写技能	MemOS 有 Skill crystallization、η、生命周期状态	MemOS 值得灰度
可观测面	文件和 health endpoint 可查，但缺统一 UI	本地 Viewer + SSE + Logs + Retrieval preview	MemOS
资源/复杂度	当前仅 8424 sidecar + 本地文件，轻	local plugin 需 Node 20+、better-sqlite3、viewer；全量 MemOS 更重	TencentDB
多 agent 共享	本机已通过 CCTB mirror 将 Codex/Antigravity completed turns 写入 Master TDAI	支持 hub/team sharing，但需显式配置；OpenClaw/Hermes 默认隔离	当前 TencentDB 已满足；MemOS 可后续评估
隐私/本地性	本地，未依赖云	local plugin 本地；cloud plugin 则外部云	都可；若用 MemOS 应优先 local plugin
迁移风险	现有主系统，无迁移风险	切换 Provider 可能改变 prompt 注入、工具名、召回语义；需要重启 Hermes	TencentDB 保主

5. 关键判断：两者不是完全同类

memory-tencentdb 当前更像“为 Hermes 定制的长期上下文系统”：它把原始对话、结构化记忆、场景块、persona 合成和搜索工具做成低成本持续注入，优势是稳定、轻量、贴合现有 profile。

MemOS 更像“agent 经验操作系统”：它不只记事实，还试图从工具调用、失败、反馈、轨迹中诱导 policy/world model/skill，用于后续决策修复。它的目标更大，长期上限更高，但在本机生产 Master 上直接替换会带来不确定性。

6. 适合本机的路线

阶段	动作	验证口径	是否影响当前 Master
Phase 0：保持现状	TencentDB 继续作为 Master 主记忆；不切 provider	8424 health、当天 conversations/records、scene 注入正常	无影响
Phase 1：离线研究	在不改 Hermes provider 的情况下，安装/构建 MemOS local plugin 到测试目录或新 profile	Viewer 能打开，SQLite schema 可见，导入样例 JSON 成功	不影响
Phase 2：镜像写入	把现有 TencentDB 的 conversation/records/scene 导出为 MemOS 可导入 JSON，做只读/副本评估	同一查询对比召回：命中率、噪音、延迟、上下文长度	低风险
Phase 3：灰度 profile	建独立 Hermes profile 运行 MemOS provider，不接管 default Master	连续 3-7 天检查注入质量、工具失败学习、skill 结晶质量	可控影响
Phase 4：再决策	若 MemOS 在失败避免、召回精度、token 成本上明显优于 TencentDB，再考虑主从切换或混合架构	必须有 A/B 数据，而不是只看 README 指标	需 restart context

7. 不建议立刻替换的原因

当前系统正在工作：本轮注入已经准确提供 persona、scene index、memory tools guide；这不是“记忆没跑起来”。
用户偏好已被 TencentDB 适配：内置记忆短路由、TencentDB 承载长背景、skills 承载 runbook 的分层已经成型。
MemOS 仍需实机校准：官方文档能力很强，但本机还没有安装，也没有对用户这类运维任务做过 A/B。
切换会改变工具与注入语义：TencentDB 工具是 memory_tencentdb_memory_search / conversation_search；MemOS 工具会变为 memos_search、memos_timeline、memos_skill_get 等。
双系统自动注入有污染风险：如果两个 provider 同时把长上下文注入，可能引发重复、陈旧事实竞争、token 浪费和策略冲突。

8. 最终建议

生产判断：Master default profile 继续使用 memory-tencentdb。

研究判断：MemOS 值得作为下一代候选，尤其适合验证三件事：工具失败模式是否能自动沉淀、是否能生成高质量可复用 skills、Viewer 是否能显著提高“记忆是否生效”的可观测性。

迁移判断：不要做直接替换；做 side-by-side 灰度。只有当 MemOS 在同一批真实历史问题上召回更准、噪音更低、token 更省、并且不会覆盖现有 Hermes skills 流程时，才考虑把它提升为主记忆。

9. 如果下一步要试，我建议的最小安全实验

新建独立 profile，例如 memos-lab，不动 default Master。
写 restart context 后，仅重启测试 profile 的 Hermes，不重启主 gateway。
安装 @memtensor/memos-local-plugin 到测试 profile 对应目录。
导入一小段 TencentDB conversations/records，不导入全部。
用 10 个固定查询做对比：用户偏好、VPS inventory、Shadowrocket 节点拆分、iOS Health、OpenRouter 用量口径等。
记录每条：是否命中、是否带错、上下文长度、延迟、是否产生有用 skill。

本报告未包含任何密钥、订阅 URL 私密内容或完整原始记忆正文。