wantsong
/
knowledge-vault
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
knowledge-vault/discussions/agents/GitHub助手GPT/2026-06-15-mempalace.md

21 KiB
Raw Blame History

1

https://github.com/MemPalace/mempalace，这个是AI记忆系统。

我现在使用的Codex、Cluade Code都具有长期记忆能力，OpenClaw/Hermes等自动化工具也具有长期记忆。但是这些都不能作为我们自己开发的Agentic框架底座。这里应该不是它的工作场景。

那么mempalace的工作场景，是否与代码框架比如 LangGraph、CrewAI、PydanticAI来配合？ 现有的代码框架是否已经有了自己的记忆系统？ 与此类似的，还有哪些记忆系统框架，主流的是什么？

判断：MemPalace 更适合做“外置记忆层”，不是 Agentic 框架底座

你的判断基本对。MemPalace 不太像 LangGraph、CrewAI、PydanticAI 这种“编排/执行框架”，它更像一个本地优先的长期记忆仓库 + MCP 工具服务器 + 会话/项目记忆检索器。它的核心机制是保存原始会话或项目文本，再做语义检索；README 明确说它不做摘要、抽取或改写，而是按 people/projects、topics、drawers 这类结构组织原文，并且默认用 ChromaDB，可替换后端。(GitHub)

对你来说，它最合理的位置不是“取代 LangGraph/CrewAI/PydanticAI”，而是作为这些框架旁边的一个共享记忆服务：在 Agent 执行前检索历史决策、执行后写入 diary / drawer / KG fact，让不同工具共享同一份长期上下文。这个方向符合你长期关注的 Skill、Agent、自动化、知识管理和低成本本地运行目标。

1. MemPalace 是否适合和 LangGraph / CrewAI / PydanticAI 配合？

适合，但要放在工具层 / MCP 层 / 外部 Memory Adapter 层，不要放在框架核心层。

最清晰的分工是：

层级 负责什么 典型工具
Agent 编排层 状态机、任务路由、多 Agent 协作、工具调用、Human-in-the-loop、重试、观察性 LangGraph、CrewAI、PydanticAI、Mastra
记忆管理层 决定存什么、何时检索、如何压缩、如何更新事实、如何避免过期记忆 LangMem、CrewAI Memory、Mem0、Zep、Hindsight
外置记忆仓库层 保存历史会话、项目文件、代码决策、事实图谱、可查询原文 MemPalace、Zep/Graphiti、Cognee、Supermemory
存储层 向量库、数据库、图数据库、对象存储 Chroma、Postgres/pgvector、Qdrant、LanceDB、Neo4j、SQLite

MemPalace 适合第三层：外置记忆仓库层。

它通过 MCP 暴露 29 个工具，包括搜索、读写 drawer、知识图谱操作、跨 wing 导航和 agent diary；官方文档还说明 Claude Code、Codex CLI、OpenClaw、Cursor、Gemini CLI 等 MCP 兼容工具可以接入。(MemPalace)

2. 和 LangGraph 配合：可以，但通常不是首选核心记忆方案

LangGraph 自己已经有比较完整的记忆机制：短期记忆用 checkpointer 保存 thread-scoped graph state，长期记忆用 store 保存跨 thread 的用户偏好、事实和共享知识。官方文档把 checkpointer 和 store 明确区分为短期线程记忆与长期跨线程记忆。(LangChain Docs)

所以，如果你在写一个 LangGraph 应用，默认更建议：

  1. 短期会话状态：LangGraph checkpoint。
  2. 应用内长期用户记忆：LangGraph Store / PostgresStore / MongoDBStore。
  3. 智能抽取、更新、管理记忆：LangMem。
  4. 跨工具、跨代码助手、跨项目原文记忆：MemPalace。

LangMem 是 LangChain 生态内更“原生”的长期记忆工具，它提供记忆管理工具、后台 memory manager，并原生集成 LangGraph 的 Store。(GitHub)

我的判断： MemPalace 和 LangGraph 配合的最佳方式不是替换 LangGraph Store，而是作为一个 LangGraph tool / MCP tool：

LangGraph 节点开始前：
  调用 mempalace_search / mempalace_kg_query 找历史决策

LangGraph 执行中：
  根据任务需要检索项目、用户、代码上下文

LangGraph 结束后：
  调用 mempalace_diary_write / mempalace_add_drawer / mempalace_kg_add 写入新记忆

适合你的场景：代码项目长期决策、研究项目历史、Agent 调试日志、跨 Codex/Claude Code/OpenClaw 的共享上下文。 不适合的场景：生产级多租户用户画像、低延迟 SaaS 记忆 API、强治理企业记忆，这些更适合 Zep、Mem0、Supermemory 或自建 Postgres/pgvector。

3. 和 CrewAI 配合：可以，但重复度更高

CrewAI 现在已经有自己的统一 Memory 系统。官方文档说它用一个 Memory 类替代短期、长期、实体和外部记忆类型，保存时会用 LLM 分析 scope、category、importance，检索时结合语义相似度、时间衰减和重要性评分。(CrewAI Documentation)

CrewAI Memory 默认存储后端是 LanceDB，路径在 ./.crewai/memory 或指定目录；它支持自定义后端、不同 embedding provider、LLM 分析、深度召回、隐私 flag 和 source tracking。(CrewAI Documentation)

所以在 CrewAI 里，MemPalace 不是必需品。它的价值主要在三种情况：

场景 是否适合 MemPalace
只想让 CrewAI 记住任务上下文 不太需要，CrewAI Memory 自己能做
想把 CrewAI 的记忆和 Claude Code / Codex / OpenClaw 共用 适合
想保留所有原始会话与项目文件，避免 LLM 摘要丢信息 适合
想做多用户 SaaS agent memory 不首选，CrewAI Memory 或 Mem0/Zep 更合适

CrewAI 也支持 MCP，把 MCP server 接成 Agent 工具；因此 MemPalace 可以作为 CrewAI 的外部 MCP memory server 使用。(CrewAI Documentation)

但要注意：CrewAI 官方 MCP 安全文档提醒，MCP server 可能执行代码、访问数据、影响 Agent 行为，甚至通过 tool metadata 做 prompt injection。因此 MemPalace 这类记忆 MCP 最好只接可信本地服务，不要随便接未知远程 MCP。(CrewAI Documentation)

4. 和 PydanticAI 配合：反而更有价值

PydanticAI 当前官方文档强调的是 message history：可以把已有消息通过 message_history 参数传给后续 agent run，用于跨 run 保持上下文；也提供 ProcessHistory 来在发给模型前处理历史消息。(Pydantic)

我没有在当前官方文档中看到它有类似 LangGraph Store、CrewAI Memory、Mastra Memory 那种内置完整长期记忆系统。它更像一个类型安全、依赖注入、结构化输出、工具调用优先的 agent 框架。

这使得 MemPalace 对 PydanticAI 更有意义：你可以把 MemPalace 封装成几个强类型工具：

search_memory(query, project_id, person_id?)
write_memory(content, wing, room, hall?)
query_kg(entity, time_range?)
write_diary(agent_id, summary)

PydanticAI 也有原生 MCP client 能力，支持 Streamable HTTP、SSE、stdio 三种连接方式，并且 MCP server 可作为 toolset 注册到 Agent。(Pydantic)

我的判断： 如果你要在 PydanticAI 上搭自己的轻量 Agent 框架，MemPalace 是三者中最值得接的，因为 PydanticAI 本身没有强记忆层，MemPalace 可以补“长期项目记忆 + 原文检索 + diary”。

5. 现有代码框架是否已经有自己的记忆系统？

有，但成熟度差异很大。

框架 自带记忆能力 判断
LangGraph 有。短期 checkpointer，长期 store，配合 LangMem 可做抽取、更新、检索 目前 Python Agent 框架里最适合做生产级可控记忆底座
CrewAI 有。统一 Memory 类，LLM 分析、LanceDB、深度召回、source/private 对 Crew/多 Agent 协作友好，但更框架内闭环
PydanticAI 有 message history 和 history processing；未见完整内置长期记忆层 适合外接 MemPalace/Mem0/Zep/Cognee
Mastra 有。message history、observational memory、working memory、semantic recall、多用户 threads TypeScript 生态里值得重视
Letta / MemGPT 本身就是 stateful agent 平台，内核围绕记忆设计 更像“带记忆的 Agent 平台”，不是单纯 memory lib

Mastra 的 Memory 文档显示，它支持 message history、observational memory、working memory、semantic recall、多用户 threads，并要求配置 storage provider 来持久化消息历史。(Mastra)

6. MemPalace 和这些框架的关键差别

MemPalace 的核心哲学是：先不要让 LLM 决定什么重要，先把原文保存下来。

它的 benchmark 文档也强调：Raw 模式保存原始 session 文本，用 ChromaDB 默认 embedding 检索，不用摘要、不用抽取、不用 LLM；项目方认为很多记忆系统过度依赖 LLM 抽取，可能丢掉原始上下文。(GitHub)

这点很适合你这类长期系统：代码决策、论文想法、研究路线、调试记录，很多价值不在“事实句子”本身，而在当时的权衡、反驳、上下文和失败路径。

但它也有明显边界：

MemPalace 强项 MemPalace 弱项
原文保存，不丢上下文 不一定适合生产多租户 SaaS
本地优先，核心路径无需 API key 不是 Agent 编排框架
MCP 接入方便 依赖 Agent 自觉调用记忆工具
适合代码会话、项目决策、长期笔记 对 memory consolidation、用户画像、治理、权限不如专门平台
可作为 Skill / MCP 工具 hype 和 benchmark 需要谨慎看

尤其要注意：MemPalace 官方自己有一份 corrections/history，承认早期 README 和公开页面曾混用 retrieval recall 与端到端 QA accuracy、删除了部分夸张表述，并警告有仿冒域名传播潜在恶意内容。(GitHub)

所以我不会因为 star 数或“best benchmarked”宣传直接把它列为主力底座。它更适合本地试跑 + 架构观察 + 小范围接入。

7. 类似的记忆系统框架：哪些是主流？

我会按用途分，而不是按 star 数分。

A. LangGraph + LangMem：Python Agent 工程主流路线

适合：你自己写 Agentic 框架、需要可控状态机、长期用户记忆、生产可维护性。 不适合：只想给 Codex/Claude Code 加一个外部记忆仓库。

LangGraph 提供短期 checkpointer 和长期 store；LangMem 在此之上提供 memory tools、后台抽取、合并、更新、优化 agent 行为。(LangChain Docs)

对你的价值：最高。 如果你未来自己写 Agentic 框架，LangGraph + LangMem 比 MemPalace 更像底座。

B. Mem0：通用 AI Agent memory layer 主流候选

Mem0 定位是 universal memory layer，面向 AI assistants、customer support、autonomous systems，支持 user/session/agent 多层记忆。(GitHub)

它的论文把 Mem0 描述为可扩展长期记忆架构，通过动态抽取、整合、检索对话信息来解决多 session 一致性问题，并强调相比 full-context 降低延迟和 token 成本。(arXiv)

适合： 产品化 Agent、用户偏好、客户支持、多用户记忆。 不适合： 完全本地、完全原文归档、你想自己掌控全部数据结构。

C. Zep / Graphiti：生产级 temporal knowledge graph memory

Graphiti 是 Zep 的开源 temporal context graph engine，强调事实随时间变化、来源追踪、语义 + 关键词 + 图遍历混合检索。(GitHub)

适合： 企业知识、关系复杂、事实会变、需要“现在为真 / 过去为真”区分的 Agent。 不适合： 只想本地快速记住几百段代码会话。

对你的价值：很高。 如果你关心“长期系统沉淀”和“架构借鉴”，Graphiti/Zep 比 MemPalace 更值得深读架构。

D. Letta / MemGPT：有记忆的 stateful agent 平台

Letta 定位是 stateful agents 平台，强调 advanced memory、learn、self-improve；它有 CLI 和 API，支持 Python/TypeScript SDK。(GitHub)

适合： 研究“Agent 自我管理记忆”的平台型架构。 不适合： 只想给现有 LangGraph/PydanticAI 补一个 memory tool。

对你的价值：架构学习高，直接落地中等。

E. Supermemory：托管/本地 context stack API

Supermemory 的 README 说它给 AI agents/apps 提供 memory、RAG、user profiles、connectors、file processing 的一体化 API，并自动抽取 memories、构建用户 profile、返回相关上下文。(GitHub)

适合： 想快速给应用接 memory/profile/RAG，不想自己管 chunking、embedding、vector DB。 不适合： 强本地隐私、想完全自建、想深度改造底层。

F. Cognee：知识图谱式 agent memory / company brain

Cognee 定位是开源 AI memory platform，面向 agents 的跨 session 长期记忆，支持自托管知识图谱、向量检索、图推理、ontology generation，并且 README 提到 Claude Code、OpenClaw 相关插件。(GitHub)

适合： 文档、知识库、公司脑、研究材料、论文知识管理。 对你的价值：很高。 如果你的目标是论文/知识管理/写作工作流，Cognee 可能比 MemPalace 更值得进入候选池。

G. Hindsight：更研究型的“学习型 Agent Memory”

Hindsight 强调不是只回忆对话，而是让 Agent learn over time；它提供 retain/recall/reflect 思路，论文中提出 world、experience、opinion、observation 四类 memory networks。(GitHub)

适合： 研究 agent 如何从经验中学习、形成稳定偏好和观点。 不适合： 低成本简单本地试跑；它的推荐部署路径是 Docker/API，且需要 LLM provider key。(GitHub)

8. 主流选择排序：按你的场景

结合你的本地 Windows、远程 CentOS、偏好 API 模型、关注 Skill/Agent/自动化/知识管理的情况，我会这样排序。

你的目标 首选 备选 MemPalace 位置
自研 Agentic 框架底座 LangGraph + LangMem PydanticAI + 外部 memory 作为外部记忆工具
Crew/多 Agent 自动化 CrewAI Memory Mastra Memory 作为共享历史仓库
PydanticAI 轻量 Agent PydanticAI + MemPalace/Mem0/Zep PydanticAI + Cognee 很适合补位
代码助手长期记忆 MemPalace Cognee、Supermemory 很适合
论文/知识管理/写作 Cognee Zep/Graphiti、MemPalace 适合做原文记忆，不适合独占
企业级用户记忆 Zep / Mem0 Supermemory 不首选
本地低成本试验 MemPalace Cognee local、LangGraph local store 值得小试
架构借鉴 Graphiti/Zep、LangMem、Hindsight MemPalace 可借鉴“原文优先”思想

9. 我对 MemPalace 的最终动作建议

结论：值得收藏 + 本地小试，但暂不建议作为你自研 Agentic 框架的默认记忆底座。

主动作

把它作为一个外部记忆 Skill / MCP 记忆工具候选，而不是框架底座。

最小试跑方向：

1. 本地 uv tool install mempalace
2. mine 一个代码项目 + 一份 Claude/Codex 会话导出
3. 测试 search / wake-up / diary
4. 再接一个 PydanticAI 或 LangGraph agent，封装 3 个工具：
   - search_memory
   - write_memory
   - query_project_decision

MemPalace 官方推荐 uv tool install mempalace，核心本地流程不需要 API key，需要 Python 3.9+、ChromaDB、PyYAML，并会使用本地 embedding 模型。(MemPalace)

次动作

和以下方案做对照评估：

LangGraph Store + LangMem
Mem0
Zep / Graphiti
Cognee

看三个指标：

  1. 是否容易被你自己的 Agent 框架调用；
  2. 是否能跨 Codex / Claude Code / OpenClaw / 自研 Agent 共享；
  3. 是否能支撑论文、知识库、写作和长期项目上下文。

不建议做的事

不要把 MemPalace 直接当成“未来 Agent OS 的核心记忆内核”。它目前更像一个有用的本地记忆工具，而不是成熟的多租户、强治理、强一致性的 memory infrastructure。

也不要从非官方域名安装。官方文档明确警告 mempalace.tech 等仿冒域名可能有恶意风险，只应使用 GitHub、PyPI 和官方 docs。(MemPalace)

10. 一句话项目卡片

  • 一句话定位： 本地优先的 AI 长期记忆仓库，通过原文保存 + 语义检索 + MCP 工具，让 AI 记住项目、会话和决策。
  • 最适合： Codex / Claude Code / OpenClaw / 自研 Agent 之间共享代码项目记忆。
  • 不适合： 作为 LangGraph/CrewAI/PydanticAI 的替代框架，或生产级多租户 memory backend。
  • 与 LangGraph： 可作为外部 memory tool，但 LangGraph Store + LangMem 更原生。
  • 与 CrewAI： 可作为共享外部记忆，但 CrewAI 自己已有 Memory。
  • 与 PydanticAI： 匹配度最高，因为 PydanticAI 更需要外接长期记忆层。
  • 主流替代： LangMem、Mem0、Zep/Graphiti、Letta、Supermemory、Cognee、Hindsight。
  • 推荐动作： 收藏 + 本地小试 + 做一个 PydanticAI/LangGraph memory adapter。
  • 是否进 Codex 深挖： 暂时不需要全面体检；等你决定要做 memory adapter 时，再让 Codex 按依赖、API、MCP、安全和 Windows 兼容性深挖。