agent 是智能体的意思，什么是智能体呢，为啥不叫AI了啊，也不叫大模型了，其实这并不是孤立的概念，AI中文就是人工智能，英文全称：Artificial Intelligence，其实就是计算机科学的一个分支，用来研究开发模拟，延伸人的理论方法技术和应用研究。大模型是ai具象化的技术产品，大模型还分了LLM语言大模型、VLM视觉大模型、MLLM多模态、技术上又出现了很多细节，比如混合专家模型-MOE。 MCP 是定的ai识别的上下文协议，用来，调用外部的服务器，返回固定内容信息的一个规则，大家都用这个规则，不就方便了ai调用外部工具获取信息了。方便打通不同企业数据库和ai的交互。 tools 就是工具的意思，这里和mcp紧密相连，tools泛指一类工具，遵循的上下文协议也未必是mcp。方便ai通过这个工具进行获取信息。 plugin是插件的意思，就是个扩展包，这不是ai独有的概念，浏览器有插件，任何应用都可能有插件，一个插件里面东西就多了，可以包含skill，agents，hooks，mcp severs等内容。 prompt是提示词的意思，大模型学的东西多了，大模型要在知识汪洋中预测你想要的下一个词，简直不要太难，那么就帮她缩小范围降低幻觉，那就是定人物，定任务范围，定目标，这样将结合以上的信息，进行数据处理，就大大降低了，大模型胡说八道的可能性。大模型本身就是个统计学问题，根本不具备任何智慧，和反思能力，并非动态进化的，而是提前通过人类社会无数的现有文档，向量化，然后通过多维向量的训练出来的，一个具备无数维度的数学矩阵，通过通过上下文的切割成token又称词元，一个词元就是一个数字，多个词元就组成了一个数学矩阵，将这个数学矩阵扔到transform架构的数学矩阵中。我也不知道是不是百亿参数是不是也决定了词元的数量呢，会影响回应呢？ workflow就是工作流，针对一项工作设计的工作流程，使其完成特定的任务，取代繁重的工作。 hook钩子的意思，什么是钩子啊就是，当执行到特定情况或者涉及特殊判断的时候就会触发的程序，相当于一个钩子，勾住了你的工作流，在特定情况下触发，进而保证进程的稳定和顺利。 skill技能的意思，技能可以是一个md说明的工作文档，也可以是md说明文档加一些小程序、或者一些模板的综合体，目标就是让大模型能按你的md说明文档进行工作。 harness就是一个工作台，工作台上啥也有，自由搭配，想用啥就用啥，比如有plugin、tools、prompt、workflow、hook、skill、和设定好的agent。 AI / 人工智能 └── 大模型 / LLM / VLM / MLLM └── Agentic System / 智能体系统 ├── Prompt：给模型的指令 ├── Context：当前任务上下文 ├── Memory：可长期保存或检索的历史信息 ├── Tools：模型可调用的外部能力 │ └── MCP：连接 tools / resources / prompts 的标准协议之一 ├── Workflow：预设流程 ├── Hook：生命周期触发器 ├── Skill：可复用能力包 ├── Plugin：可安装扩展包 └── Harness：运行框架 / 执行外壳 agent 是配置了 instructions、tools，以及可选运行行为的 LLM MCP Server 可以向 AI 应用暴露 resources、prompts 和 tools。这样不同 AI 应用和不同外部系统之间就不用每次都重新写一套私有接口。 Tool：一个具体能力 MCP Tool：通过 MCP 协议暴露出来的 tool MCP Server：把一组 tools / resources / prompts 提供给 AI 应用 Agent：根据任务需要决定是否调用这些工具 plugin 可能包含 tools、skills、agents、hooks、MCP servers 等内容。简单说，plugin 是“打包和分发能力”的方式。 prompt 帮模型缩小范围，降低幻觉。这个是对的。OpenAI 文档也把 prompt engineering 描述为编写有效指令，让模型更稳定地产生符合要求的内容。 大模型本质上是通过大量数据训练出来的神经网络，它没有人类意义上的主观意识，也不会在普通对话中自动修改自己的模型参数。它的回答来自当前输入、上下文、训练得到的参数，以及推理时的生成过程。我们看到的“推理”“反思”“自我检查”，更多是模型在特定提示、上下文或工具流程下表现出来的能力，而不是人类式的自我意识。 Token：文本被切分后的处理单位。 Token ID：token 被映射成的数字编号。 Embedding：token ID 进入模型后对应的向量表示。 Parameter：模型训练出来的权重和偏置。 Context window：一次输入/输出能处理的 token 上限。 Training tokens：训练时看过的数据 token 数量。 Vocabulary size：分词器支持的 token 种类数量。 文本会先被 tokenizer 切成 token，再映射成 token ID。模型会把 token ID 转成向量表示，也就是 embedding，然后送入 Transformer 网络中计算。Transformer 通过注意力机制和多层神经网络，结合上下文预测后续 token。参数量指的是模型内部训练出来的权重数量，和输入 token 数不是同一个概念。 Workflow 是预先设计好的流程。它强调“步骤固定、路径清楚、可控性强”。比如先读订单，再判断退款规则，再调用退款接口，再发送通知。workflow 里可以用大模型，也可以不用大模型。它和 agent 的区别是：workflow 的路径主要由人或程序提前写好；agent 的路径更多由模型根据目标和中间结果动态决定。 Anthropic 对这个区别说得很清楚：workflows 是 LLM 和工具通过预定义代码路径编排；agents 则是 LLM 动态决定自己的流程和工具使用。 这个方向对。Anthropic 的 Agent Skills 文档也把 skill 描述为模块化能力包，包含 instructions、metadata 和可选资源，比如 scripts、templates，Claude 会在相关任务中自动使用。 另一个官方指南也说 Skills 可以是由 instructions、scripts、resources 组成的文件夹 Context：这次对话/这次任务临时放进来的信息。 Memory：跨会话保存、以后还能拿出来用的信息。 Context 是模型当前这次任务能看到的信息，比如用户问题、系统指令、聊天历史、检索到的文档、工具返回结果等。Memory 是被长期保存、之后还能被取出来的信息，比如用户偏好、项目背景、历史决策、常用规则等。Memory 不是模型参数本身发生了变化，而是系统把相关历史信息保存下来，在需要时重新塞回 context。 5 个帖子 - 4 位参与者 阅读完整话题
Blazing fast inference: By shifting the decode bottleneck from memory-bandwidth to compute, DiffusionGemma generates up to 4x faster token output on dedicated GPUs. (1000+ tokens per second on a single NVIDIA H100, 700+ tokens per second on NVIDIA GeForce RTX 5090). 一些补充 Diffusion是一种不同于主流文本大模型Next Token Predict的模型架构，常用于图片生成领域中。NTP是从左向右逐个token生成的，而Diffusion则是给定一块空白区域，模型预测这片区域的每个位置可能的内容，并一次次进行纠错，最终生成完整内容。 14 个帖子 - 9 位参与者 阅读完整话题
先说结论 搞了两年 agent memory ，最痛的体会是：现在的记忆系统从根上就是歪的。不是缺功能，是方向错了。 痛点一：记忆脆弱 —— 存了一堆，但啥都不懂 把几十万封邮件扔进向量数据库，得到的是一个很大但完全没用的上下文堆。存和理解是两码事。 痛点二：时间推理残缺 问一句"我上周在搞啥"，大多数系统直接宕机。数据有，但时间感没有。 痛点三：遗忘困境 这条反直觉——记住一切反而更糟。上下文会腐烂。但要写一个好的遗忘算法，比堆存储难多了。 痛点四：评估缺失 你的记忆系统到底有没有在干活？大多数团队根本没法量化。benchmark 散乱且没有标准。 我们的解法：抄作业——Coding Agents 早就搞定了 看 GitHub 的工作流： Issue → PR → Code Review → Git History → Test → Status Update 每一步都被追踪、版本化、可查询。上下文不消失，它是演进的。 我们把这个模式搬到了个人 AI： 原始消息（邮件/Slack/Notion ） → 结构化记忆洞察 Agent 执行前读记忆，执行后更新记忆 两个维度：空间维度（关联记忆）+ 时间维度（时间旅行查询） 空间维度：一起放电的神经元就连线 当你访问洞察 A ，与它关联的洞察自动加强。长期不访问的连接会衰减。 问"为什么这个客户卡住了？"，系统不只找到当前项目——还会联想到 3 个月前的类似情况。 时间维度：给你的记忆装一台时光机 时间旅行 API 支持查询任意时间点的记忆状态： "Q3 2024 我的优先级是啥？" "1 月到 3 月我们做了哪些决定？" "展示 2 月底那个项目的样子" 不是摘要，是那个时刻的真实快照。 遗忘引擎：学会放手 三级系统（短 → 中 → 长记忆），评分公式综合考虑： 最近访问时间 访问频率 重要性 是否被收藏 6 个月前的普通客户问候？可能就丢了。3 个月前的关键决策？保留并强化。 目标不是存更久，是存得更聪明。 跑分结果 ┌──────────────────┬───────┐ │ Benchmark │ 成绩 │ ├──────────────────┼───────┤ │ LoCoMo │ 96.3% │ ├──────────────────┼───────┤ │ LongMemEval-S500 │ 97.6% │ └──────────────────┴───────┘ 基本达到 SOTA 。但真正的数字是 35%——CL-bench （ Context Learning Benchmark ）。 上下文学习能力（把存储的上下文应用到新情况）才是真正难的问题。 开源 GitHub: https://github.com/melandlabs/openloomi 欢迎来踩，——我们认为这是整个系统里最有趣、也最没被解决好的问题。 有问题尽管问。
先说结论 搞了两年 agent memory ，最痛的体会是：现在的记忆系统从根上就是歪的。不是缺功能，是方向错了。 痛点一：记忆脆弱 —— 存了一堆，但啥都不懂 把几十万封邮件扔进向量数据库，得到的是一个很大但完全没用的上下文堆。存和理解是两码事。 痛点二：时间推理残缺 问一句"我上周在搞啥"，大多数系统直接宕机。数据有，但时间感没有。 痛点三：遗忘困境 这条反直觉——记住一切反而更糟。上下文会腐烂。但要写一个好的遗忘算法，比堆存储难多了。 痛点四：评估缺失 你的记忆系统到底有没有在干活？大多数团队根本没法量化。benchmark 散乱且没有标准。 我们的解法：抄作业——Coding Agents 早就搞定了 看 GitHub 的工作流： Issue → PR → Code Review → Git History → Test → Status Update 每一步都被追踪、版本化、可查询。上下文不消失，它是演进的。 我们把这个模式搬到了个人 AI： 原始消息（邮件/Slack/Notion ） → 结构化记忆洞察 Agent 执行前读记忆，执行后更新记忆 两个维度：空间维度（关联记忆）+ 时间维度（时间旅行查询） 空间维度：一起放电的神经元就连线 当你访问洞察 A ，与它关联的洞察自动加强。长期不访问的连接会衰减。 问"为什么这个客户卡住了？"，系统不只找到当前项目——还会联想到 3 个月前的类似情况。 时间维度：给你的记忆装一台时光机 时间旅行 API 支持查询任意时间点的记忆状态： "Q3 2024 我的优先级是啥？" "1 月到 3 月我们做了哪些决定？" "展示 2 月底那个项目的样子" 不是摘要，是那个时刻的真实快照。 遗忘引擎：学会放手 三级系统（短 → 中 → 长记忆），评分公式综合考虑： 最近访问时间 访问频率 重要性 是否被收藏 6 个月前的普通客户问候？可能就丢了。3 个月前的关键决策？保留并强化。 目标不是存更久，是存得更聪明。 跑分结果 ┌──────────────────┬───────┐ │ Benchmark │ 成绩 │ ├──────────────────┼───────┤ │ LoCoMo │ 96.3% │ ├──────────────────┼───────┤ │ LongMemEval-S500 │ 97.6% │ └──────────────────┴───────┘ 基本达到 SOTA 。但真正的数字是 35%——CL-bench （ Context Learning Benchmark ）。 上下文学习能力（把存储的上下文应用到新情况）才是真正难的问题。 开源 GitHub: https://github.com/melandlabs/openloomi 欢迎来踩，——我们认为这是整个系统里最有趣、也最没被解决好的问题。 有问题尽管问。
先说结论 搞了两年 agent memory ，最痛的体会是：现在的记忆系统从根上就是歪的。不是缺功能，是方向错了。 痛点一：记忆脆弱 —— 存了一堆，但啥都不懂 把几十万封邮件扔进向量数据库，得到的是一个很大但完全没用的上下文堆。存和理解是两码事。 痛点二：时间推理残缺 问一句"我上周在搞啥"，大多数系统直接宕机。数据有，但时间感没有。 痛点三：遗忘困境 这条反直觉——记住一切反而更糟。上下文会腐烂。但要写一个好的遗忘算法，比堆存储难多了。 痛点四：评估缺失 你的记忆系统到底有没有在干活？大多数团队根本没法量化。benchmark 散乱且没有标准。 我们的解法：抄作业——Coding Agents 早就搞定了 看 GitHub 的工作流： Issue → PR → Code Review → Git History → Test → Status Update 每一步都被追踪、版本化、可查询。上下文不消失，它是演进的。 我们把这个模式搬到了个人 AI： 原始消息（邮件/Slack/Notion ） → 结构化记忆洞察 Agent 执行前读记忆，执行后更新记忆 两个维度：空间维度（关联记忆）+ 时间维度（时间旅行查询） 空间维度：一起放电的神经元就连线 当你访问洞察 A ，与它关联的洞察自动加强。长期不访问的连接会衰减。 问"为什么这个客户卡住了？"，系统不只找到当前项目——还会联想到 3 个月前的类似情况。 时间维度：给你的记忆装一台时光机 时间旅行 API 支持查询任意时间点的记忆状态： "Q3 2024 我的优先级是啥？" "1 月到 3 月我们做了哪些决定？" "展示 2 月底那个项目的样子" 不是摘要，是那个时刻的真实快照。 遗忘引擎：学会放手 三级系统（短 → 中 → 长记忆），评分公式综合考虑： 最近访问时间 访问频率 重要性 是否被收藏 6 个月前的普通客户问候？可能就丢了。3 个月前的关键决策？保留并强化。 目标不是存更久，是存得更聪明。 跑分结果 ┌──────────────────┬───────┐ │ Benchmark │ 成绩 │ ├──────────────────┼───────┤ │ LoCoMo │ 96.3% │ ├──────────────────┼───────┤ │ LongMemEval-S500 │ 97.6% │ └──────────────────┴───────┘ 基本达到 SOTA 。但真正的数字是 35%——CL-bench （ Context Learning Benchmark ）。 上下文学习能力（把存储的上下文应用到新情况）才是真正难的问题。 开源 GitHub: https://github.com/melandlabs/openloomi 欢迎来踩，——我们认为这是整个系统里最有趣、也最没被解决好的问题。 有问题尽管问。
先说结论 搞了两年 agent memory ，最痛的体会是：现在的记忆系统从根上就是歪的。不是缺功能，是方向错了。 痛点一：记忆脆弱 —— 存了一堆，但啥都不懂 把几十万封邮件扔进向量数据库，得到的是一个很大但完全没用的上下文堆。存和理解是两码事。 痛点二：时间推理残缺 问一句"我上周在搞啥"，大多数系统直接宕机。数据有，但时间感没有。 痛点三：遗忘困境 这条反直觉——记住一切反而更糟。上下文会腐烂。但要写一个好的遗忘算法，比堆存储难多了。 痛点四：评估缺失 你的记忆系统到底有没有在干活？大多数团队根本没法量化。benchmark 散乱且没有标准。 我们的解法：抄作业——Coding Agents 早就搞定了 看 GitHub 的工作流： Issue → PR → Code Review → Git History → Test → Status Update 每一步都被追踪、版本化、可查询。上下文不消失，它是演进的。 我们把这个模式搬到了个人 AI： 原始消息（邮件/Slack/Notion ） → 结构化记忆洞察 Agent 执行前读记忆，执行后更新记忆 两个维度：空间维度（关联记忆）+ 时间维度（时间旅行查询） 空间维度：一起放电的神经元就连线 当你访问洞察 A ，与它关联的洞察自动加强。长期不访问的连接会衰减。 问"为什么这个客户卡住了？"，系统不只找到当前项目——还会联想到 3 个月前的类似情况。 时间维度：给你的记忆装一台时光机 时间旅行 API 支持查询任意时间点的记忆状态： "Q3 2024 我的优先级是啥？" "1 月到 3 月我们做了哪些决定？" "展示 2 月底那个项目的样子" 不是摘要，是那个时刻的真实快照。 遗忘引擎：学会放手 三级系统（短 → 中 → 长记忆），评分公式综合考虑： 最近访问时间 访问频率 重要性 是否被收藏 6 个月前的普通客户问候？可能就丢了。3 个月前的关键决策？保留并强化。 目标不是存更久，是存得更聪明。 跑分结果 ┌──────────────────┬───────┐ │ Benchmark │ 成绩 │ ├──────────────────┼───────┤ │ LoCoMo │ 96.3% │ ├──────────────────┼───────┤ │ LongMemEval-S500 │ 97.6% │ └──────────────────┴───────┘ 基本达到 SOTA 。但真正的数字是 35%——CL-bench （ Context Learning Benchmark ）。 上下文学习能力（把存储的上下文应用到新情况）才是真正难的问题。 开源 GitHub: https://github.com/melandlabs/openloomi 欢迎来踩，——我们认为这是整个系统里最有趣、也最没被解决好的问题。 有问题尽管问。
先说结论 搞了两年 agent memory ，最痛的体会是：现在的记忆系统从根上就是歪的。不是缺功能，是方向错了。 痛点一：记忆脆弱 —— 存了一堆，但啥都不懂 把几十万封邮件扔进向量数据库，得到的是一个很大但完全没用的上下文堆。存和理解是两码事。 痛点二：时间推理残缺 问一句"我上周在搞啥"，大多数系统直接宕机。数据有，但时间感没有。 痛点三：遗忘困境 这条反直觉——记住一切反而更糟。上下文会腐烂。但要写一个好的遗忘算法，比堆存储难多了。 痛点四：评估缺失 你的记忆系统到底有没有在干活？大多数团队根本没法量化。benchmark 散乱且没有标准。 我们的解法：抄作业——Coding Agents 早就搞定了 看 GitHub 的工作流： Issue → PR → Code Review → Git History → Test → Status Update 每一步都被追踪、版本化、可查询。上下文不消失，它是演进的。 我们把这个模式搬到了个人 AI： 原始消息（邮件/Slack/Notion ） → 结构化记忆洞察 Agent 执行前读记忆，执行后更新记忆 两个维度：空间维度（关联记忆）+ 时间维度（时间旅行查询） 空间维度：一起放电的神经元就连线 当你访问洞察 A ，与它关联的洞察自动加强。长期不访问的连接会衰减。 问"为什么这个客户卡住了？"，系统不只找到当前项目——还会联想到 3 个月前的类似情况。 时间维度：给你的记忆装一台时光机 时间旅行 API 支持查询任意时间点的记忆状态： "Q3 2024 我的优先级是啥？" "1 月到 3 月我们做了哪些决定？" "展示 2 月底那个项目的样子" 不是摘要，是那个时刻的真实快照。 遗忘引擎：学会放手 三级系统（短 → 中 → 长记忆），评分公式综合考虑： 最近访问时间 访问频率 重要性 是否被收藏 6 个月前的普通客户问候？可能就丢了。3 个月前的关键决策？保留并强化。 目标不是存更久，是存得更聪明。 跑分结果 ┌──────────────────┬───────┐ │ Benchmark │ 成绩 │ ├──────────────────┼───────┤ │ LoCoMo │ 96.3% │ ├──────────────────┼───────┤ │ LongMemEval-S500 │ 97.6% │ └──────────────────┴───────┘ 基本达到 SOTA 。但真正的数字是 35%——CL-bench （ Context Learning Benchmark ）。 上下文学习能力（把存储的上下文应用到新情况）才是真正难的问题。 开源 GitHub: https://github.com/melandlabs/openloomi 欢迎来踩，——我们认为这是整个系统里最有趣、也最没被解决好的问题。 有问题尽管问。
Memory Agent — 使用 本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 / 否 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 说明书 版本：0.1.0 · 数据格式：JSON · 依赖：Python 3.8+ · 零外部包依赖（CLI 模式） 目录 概述 快速开始 集成方式 数据格式详解 商业模型场景 CLI 命令大全 MCP 工具大全 维护与故障排除 思维导图记忆（0.2.0 新增） 1. 概述 Memory Agent 是一个本地运行的 AI 记忆系统。它替 LLM 记住跨会话的信息，实现"上次说过的事，下次还记得"。 核心概念 ┌─────────────────────────────────────────────────┐ │ 记忆系统 │ │ │ │ 工作记忆 (Working Memory) │ │ └─ LLM 上下文窗口，每次会话自动携带 │ │ │ │ 情景记忆 (Episodic Memory) │ │ └─ 每次对话的摘要，存为 .json 文件 │ │ 路径: .memory/episodic/sess-时间戳.json │ │ │ │ 语义记忆 (Semantic Memory) │ │ └─ 跨会话提炼的规律/知识，带置信度打分 │ │ 路径: .memory/semantic/km-随机id.json │ └─────────────────────────────────────────────────┘ 三种使用方式 方式 调用方式 适合场景 Skill Claude Code 自动触发 当前会话内，AI 自己管理记忆 CLI python3 memory.py <命令> 终端直接操作，脚本集成 MCP 任何 MCP 客户端调用 Claude Desktop / Cursor 等外部工具 所有方式共享同一个 .memory/ 数据目录。 2. 快速开始 2.1 安装 项目在 .claude/skills/memory-agent/ ，已就绪。 2.2 测试存储与检索 # 进入工作目录 cd /storage/emulated/0/Download/ces # 存储一条会话摘要 python3 .claude/skills/memory-agent/scripts/memory.py store session '{ "summary": "讨论了 SaaS 产品的定价策略", "tags": ["商业模型", "定价策略", "SaaS"], "key_points": [ "建议采用 usage-based + tiered 混合定价", "用户对封顶价格敏感" ], "decisions": ["最终选择 usage-based 方案"] }' # 存储一条知识条目 python3 .claude/skills/memory-agent/scripts/memory.py store knowledge '{ "content": "该用户群体偏好 usage-based 定价，对封顶价格敏感", "tags": ["定价策略", "客户画像"], "confidence": 0.7 }' # 查询 python3 .claude/skills/memory-agent/scripts/memory.py query --tag 定价策略 --limit 5 # 查看统计 python3 .claude/skills/memory-agent/scripts/memory.py stats 2.3 在 Claude Code 中触发 在当前会话中，对 AI 说以下话就可以触发记忆操作： "帮我把刚才的讨论记住" "之前聊过什么关于定价的话题" "看看记住了什么" "这个方案用户采纳了，记一笔" AI 会自动执行对应的存储/查询/统计操作。 2.4 启动 MCP 服务 本 MCP 服务通过 .mcp.json 注册，由支持 MCP 协议的工具自动拉起。 配置已在 .mcp.json 中： "memory-agent": { "command": "python3", "args": [".claude/skills/memory-agent/scripts/memory_mcp.py"] } 不需要手动启动。当 MCP 客户端（如 Claude Desktop）启动时，会自动拉起这个进程。 3. 集成方式 3.1 方式一：Claude Code Skill（自动模式） 已注册在 .claude/skills/memory-agent/SKILL.md 。 触发条件： 你说 AI 会 “帮我记住…” 工作流 A → 生成摘要 → 存情景记忆 “之前说过…” 工作流 B → 查询记忆 → 注入上下文 “总结一下/学习这些” 工作流 C → 批量提炼 → 存语义记忆 “这个建议对不对” 工作流 D → 更新置信度 “看看记住了什么” 工作流 E → 显示统计和条目 “回顾一下历史” 工作流 B → 查询 → 列出相关记忆 深层用法： "刚才关于定价的讨论，存一下。标签用：商业模型、定价策略" "之前我问过关于获客的问题，答案是啥？" "从这些对话里提炼一下用户的行为模式" 3.2 方式二：CLI 命令行（手动/脚本模式） # 完整路径调用 python3 .claude/skills/memory-agent/scripts/memory.py stats # 别名（建议） alias mem="python3 $PWD/.claude/skills/memory-agent/scripts/memory.py" mem stats mem list --limit 10 mem query --tag 定价策略 在 shell 脚本中集成： #!/bin/bash # 每日自动总结 SUMMARY=$(cat <<'JSON' {"summary":"每日工作日志","tags":["日报"]} JSON ) python3 .claude/skills/memory-agent/scripts/memory.py store session "$SUMMARY" 从文件读取数据： python3 .claude/skills/memory-agent/scripts/memory.py store session ./my_summary.json 管道模式： echo '{"summary":"来自管道的测试","tags":["测试"]}' | python3 .claude/skills/memory-agent/scripts/memory.py store session 3.3 方式三：MCP 协议（外部 AI 工具模式） 任何支持 MCP 的客户端可使用以下工具： 在 Claude Desktop 等工具中： # 存储 调用 memory_store_session，参数： data: {"summary": "讨论了XX", "tags": ["商业模型"]} # 查询 调用 memory_query，参数： tag: ["定价策略"] limit: 5 # 统计 调用 memory_stats，参数：{} 工具清单（共 7 个）： 工具名 功能 memory_store_session 存会话摘要 memory_store_knowledge 存知识条目 memory_query 查询记忆 memory_list 列出条目 memory_get 获取详情 memory_stats 统计 memory_update_confidence 更新置信度 3.4 方式四：直接读文件（数据消费模式） 所有数据是纯 JSON，任何工具都能直接读： import json, os mem_dir = "/storage/emulated/0/Download/ces/.memory" # 读所有情景记忆 for fname in os.listdir(f"{mem_dir}/episodic"): with open(f"{mem_dir}/episodic/{fname}") as f: data = json.load(f) print(data["summary"]) # 直接用 jq 查询 cat .memory/episodic/*.json | jq '[.summary, .tags]' 4. 数据格式详解 4.1 情景记忆（Episodic Memory） 每条对应一次会话。文件名为 sess-YYYYMMDD-HHMMSS.json 。 字段说明： 字段 类型 必填 说明 summary string 会话一句话概括 session_id string 自动 格式 sess-20260528-143022 timestamp ISO 8601 自动 时间戳 tags string 推荐 标签，用于检索 user_intent string 用户的核心诉求 solution string 给出的方案 key_points string 关键信息点 decisions string 达成的决策 open_items string 待跟进事项 user_context object 用户画像（行业、规模、痛点等） feedback_score number 用户反馈评分（null=未评） 完整示例： { "session_id": "sess-20260528-143022", "timestamp": "2026-05-28T14:30:22+08:00", "summary": "帮助用户设计 SaaS 分层定价方案", "user_intent": "寻找适合中小企业的定价模型", "solution": "推荐 usage-based + tiered 混合模型，设 soft cap", "key_points": [ "用户团队 10-50 人", "竞争对手用 per-seat 定价", "用户对封顶价格敏感" ], "decisions": ["采用 usage-based 为主，年付可打折"], "open_items": ["需跟进 3 个月后的实施效果"], "tags": ["商业模型", "定价策略", "SaaS"], "user_context": { "industry": "SaaS/企业软件", "scale": "10-50人", "pain_points": ["获客成本高", "客户留存低"] }, "feedback_score": null } 4.2 语义记忆（Semantic Memory） 跨会话提炼的知识条目。文件名为 km-xxxxxxxx.json 。 字段说明： 字段 类型 必填 说明 content string 知识条目内容 knowledge_id string 自动 格式 km-a1b2c3d4 confidence number 自动 0.0~1.0，初始 0.5 created ISO 8601 自动 创建时间 updated ISO 8601 自动 最后更新时间 tags string 推荐 标签 source_sessions string 来源情景记忆的 ID applicable_scenarios string 适用场景 完整示例： { "knowledge_id": "km-a1b2c3d4", "content": "该用户群体对 per-seat 定价接受度低，偏好 usage-based + soft cap 模式", "source_sessions": ["sess-20260527-xxx", "sess-20260520-xxx"], "confidence": 0.85, "created": "2026-05-20T08:00:00+08:00", "updated": "2026-05-28T14:30:00+08:00", "tags": ["定价策略", "客户画像"], "applicable_scenarios": ["SaaS 定价咨询", "新客户报价策略"] } 5. 商业模型场景 5.1 客户画像管理 每次与某个客户交互后，存储包含 user_context 的会话摘要： python3 memory.py store session '{ "summary": "客户 A 的公司介绍与需求分析", "tags": ["商业模型", "客户画像", "客户A"], "user_context": { "company": "某 SaaS 公司", "industry": "企业软件", "scale": "10-50人", "pain_points": ["获客成本高", "客户留存低"], "budget_range": "中等", "decision_role": "创始人兼CTO" }, "key_points": [ "关注产品集成能力", "对 vendor lock-in 有顾虑", "预算需经过技术评估" ] }' 之后查询： # 找所有客户 A 的会话 python3 memory.py query --tag 客户A --limit 10 # 找所有 SaaS 客户的画像信息 python3 memory.py query --tag 客户画像 --tag SaaS --limit 20 5.2 定价策略追踪 记录每次定价讨论和结果： python3 memory.py store session '{ "summary": "定价方案讨论 - tiered vs usage-based", "tags": ["商业模型", "定价策略"], "key_points": [ "讨论三种方案：纯 tiered、usage-based、混合", "用户倾向混合模式", "竞品 A 用 per-seat $29/月" ], "decisions": ["混合模式：基础 $99/月 + 用量计费"] }' 当定价知识积累到 3+ 条后，提炼为语义记忆： python3 memory.py store knowledge '{ "content": "中小企业 SaaS 客户对 per-seat 定价接受度低，偏好 usage-based + tiered 混合", "tags": ["定价策略", "商业模型"], "confidence": 0.7, "source_sessions": ["sess-xxx", "sess-yyy"], "applicable_scenarios": ["新客户报价", "产品定价设计"] }' 5.3 竞品情报积累 python3 memory.py store knowledge '{ "content": "竞品 X：per-seat $29/月，集成能力弱，客户抱怨多", "tags": ["竞品情报", "竞品X"], "confidence": 0.6, "source_sessions": ["sess-xxx"] }' 5.4 决策历史回溯 # 查用户做过的所有定价相关决策 python3 memory.py query --tag 定价策略 --tag 决策 --limit 20 # 查某个竞品的所有情报 python3 memory.py query --tag 竞品X --limit 10 5.5 推荐标签体系 标签 用途 客户画像 行业、规模、痛点、预算、角色 定价策略 定价模型、价格敏感度 竞品情报 竞品对比分析 决策历史 做出的决策与结果 增长策略 获客、增长模型 商业模式 收入模型、成本结构 技术评估 技术栈、集成需求 自定义标签 按需添加，用户/项目名等 6. CLI 命令大全 6.1 存储 # 存储会话摘要 python3 memory.py store session '<json字符串>' python3 memory.py store session ./文件路径.json echo '<json>' | python3 memory.py store session # 存储知识条目 python3 memory.py store knowledge '<json字符串>' python3 memory.py store knowledge ./文件路径.json 6.2 查询 # 按标签过滤（可多个） python3 memory.py query --tag 定价策略 --tag SaaS python3 memory.py query -t 定价策略 -t SaaS # 按关键词搜索 python3 memory.py query --text "usage based 定价" # 标签 + 关键词组合 python3 memory.py query --tag 商业模型 --text "SaaS" --limit 10 # 按时间范围 python3 memory.py query --since 2026-05-01 # 限制返回条数 python3 memory.py query --limit 5 6.3 列表 # 列出最近 20 条 python3 memory.py list # 只列情景记忆 python3 memory.py list --type episodic # 只列语义记忆 python3 memory.py list --type semantic # 自定义条数 python3 memory.py list --limit 50 6.4 获取单条 python3 memory.py get sess-20260528-143022 python3 memory.py get km-a1b2c3d4 6.5 更新置信度 # 用户采纳了建议，加分 python3 memory.py update confidence km-a1b2c3d4 0.15 # 用户否定了，减分 python3 memory.py update confidence km-a1b2c3d4 -0.1 6.6 统计与维护 # 查看统计 python3 memory.py stats # 重建索引 python3 memory.py reindex # 查看帮助 python3 memory.py --help 7. MCP 工具大全 MCP 工具 参数 说明 memory_store_session data: string (JSON) 存会话摘要 memory_store_knowledge data: string (JSON) 存知识条目 memory_query tag: string , text: string, limit: number 查询记忆 memory_list type: “episodic” “semantic”, limit: number memory_get id: string (必填) 获取详情 memory_stats (无参数) 统计概览 memory_update_confidence id: string, delta: number (必填) 调整置信度 在 Claude Desktop 中使用 在 Claude Desktop 的 MCP 配置中添加： { "mcpServers": { "memory-agent": { "command": "python3", "args": [".claude/skills/memory-agent/scripts/memory_mcp.py"] } } } 之后在对话中可以直接说： “帮我记住刚才的讨论” “查一下关于定价策略的历史记录” “看看记忆库有什么” 在 Cursor 中使用 在 Cursor 的 MCP 配置中添加同样内容，然后在 Composer 中叫： “从 memory-agent 查一下相关记录” “把这个讨论存到 memory” 8. 维护与故障排除 8.1 目录结构 .memory/ # 记忆存储根目录 ├── _index.json # 轻量索引（自动维护） ├── episodic/ # 情景记忆 │ ├── sess-20260528-143022.json │ └── sess-20260528-150100.json └── semantic/ # 语义记忆 ├── km-a1b2c3d4.json └── km-e5f6g7h8.json 8.2 数据安全 数据是本地纯文本 JSON 文件。没有网络请求，没有外部依赖。 备份： 直接复制 .memory/ 目录 迁移： 设置 $MEMORY_DIR 环境变量指向新路径 清理： 直接删除文件或目录 # 设置自定义存储路径 export MEMORY_DIR=/sdcard/my-memory-data # 备份 cp -r .memory .memory.backup-$(date +%Y%m%d) # 查看存储位置 python3 .claude/skills/memory-agent/scripts/memory.py stats 8.3 常见问题 Q: memory.py 报 python3: command not found A: 确认 Python 3 已安装： which python3 Q: 存储的 JSON 数据出现乱码 A: 确保 JSON 是 UTF-8 编码。单引号包裹的 JSON 字符串内部不要用未转义的单引号。 Q: MCP 服务连不上 A: 检查 .mcp.json 路径是否正确。 python3 路径在 Termux 中为 /data/data/com.termux/files/usr/bin/python3 。 Q: 如何清空所有记忆 A: rm -rf .memory/ 然后 python3 .claude/skills/memory-agent/scripts/memory.py reindex Q: 如何跨设备使用 A: 把 .memory/ 目录传到另一台设备，设置同一 $MEMORY_DIR 路径即可。 Q: 数据量大了会慢吗 A: 每个记忆是一个独立文件。1000 条以内无性能问题。超过后可考虑定期归档旧数据。 8.4 最佳实践 标签要规范 — 相同的概念用相同的标签名（不要同时用"定价"和"定价策略"） 定期提炼 — 情景记忆积累到 5~10 条后，用工作流 C 提炼为语义记忆 置信度反馈 — 用户给出反馈后及时更新，让系统越用越准 合理使用"总结" — 不需要每次对话都存，重要决策/客户信息/关键知识才存 定期备份 — .memory/ 是整个系统的核心资产 9. 思维导图记忆（0.2.0 新增） 速查见项目根目录 README.md 。 把"项目开发到哪了"存成 思维导图式进度快照 ，开新窗口一眼看懂。三位一体表示：JSON（可检索）/ Unicode 树（终端看）/ Mermaid（渲染成真图）。 M=.claude/skills/memory-agent/scripts # 存 / 更新项目快照（同名覆盖，不重复） python3 $M/mindmap.py save '{ "project":"X","progress":"60%","summary":"现状", "nodes":[{"label":"模块A","status":"done"}, {"label":"模块B","status":"doing","note":"卡在Y", "children":[{"label":"子任务","status":"todo"}]}], "pitfalls":["坑"],"next":"下一步" }' python3 $M/mindmap.py show # 渲染进度树（Unicode + emoji） python3 $M/mindmap.py list # 所有项目概览 python3 $M/mindmap.py mermaid # 输出 Mermaid 源码 → 出思维导图图片 python3 $M/mindmap.py hook # 输出 SessionStart hook JSON（供开窗自动召回） status ： done / doing / todo / bug / blocked save 会自动同步一条语义记忆， memory.py query --tag 项目快照 可召回 快照文件落在 ~/.memory/mindmap/<项目名>.{json,md,mmd} 开窗怎么用 最省心:开新窗口敲一句 /memory-agent ，skill 按工作流 D’ 自动 show 进度图（只靠 skill 加载，环境必支持）。 （可选）开窗零操作 :在 ~/.claude/settings.json 配 SessionStart hook 运行 mindmap.py hook ，新窗口启动自动注入进度图；环境不支持时回到 /memory-agent 即可。详见 README.md 与 SKILL.md 工作流 D’。 附录：文件路径参考 文件 路径 CLI 脚本 .claude/skills/memory-agent/scripts/memory.py MCP 脚本 .claude/skills/memory-agent/scripts/memory_mcp.py Skill 指令 .claude/skills/memory-agent/SKILL.md 参考文档 .claude/skills/memory-agent/REFERENCE.md MCP 配置 .mcp.json 数据目录 .memory/ memory-agent.zip (28.9 KB) 3 个帖子 - 2 位参与者 阅读完整话题
https://openai.com/index/chatgpt-memory-dreaming/ [!quote]+ 如今，我们开始推出一套更强大、更具可扩展性的内存合成系统，旨在应对ChatGPT中数亿用户和多年时间视野中内存应用时所遇到的陈旧性、正确性和可扩展性挑战。 记忆帮助 ChatGPT 学习你的偏好、项目和限制，使未来的对话能够从共享的上下文开始，而非从零开始。 与保存的记忆不同，梦境利用了背景过程，使ChatGPT能够从多次对话中学习并综合ChatGPT的记忆状态，从而始终为你的对话提供最新鲜、最相关的上下文。做梦还让记忆更容易包含对话中自然出现的上下文，而不必依赖明确的请求去记忆某事。 在过去一年里，梦境补充了保存的记忆，使ChatGPT在个性化回应和消除记忆陈旧方面的能力有了阶梯函数式的提升。然而，历史上它从未作为独立的内存系统足够。 今天，我们推出了一种基于梦想构建的更强大且计算效率更高的内存架构。 通过梦境合成的记忆可以通过在记忆摘要页面中展示的摘要进行回顾。通过内存摘要，你可以快速了解ChatGPT对你的了解，添加或更新关于你的信息，并提供ChatGPT应提及哪些话题以及何时提出的指示。如果你想深入某个领域了解更多，只需与模特聊天即可。 5 个帖子 - 4 位参与者 阅读完整话题
配置如下： Memory:7777 MB CPU:4 Core(s) Storage:47 GB Traffic:2447 GB 适当溢价，有出的佬请留言
AI 智能体有个硬伤：记不住你。每次新对话都是白纸一张。你上周讨论过的项目背景、写过的代码逻辑、提过的个人偏好，它全忘了。这不是你的问题，是所有对话式 AI 的天生缺陷。 Memory Sidecar v3.1.0 就是为了解决这个。它是一个外挂记忆系统，跑在你的智能体（ Hermes 、Claude Code 、Cursor 、Codex ，什么都行）旁边，不碰核心代码，独立进程、共享目录。装完你的智能体就有了三层记忆：热层（当前会话 context ）→ 温层（ PostgreSQL 事实图谱，50ms 级召回）→ 冷层（知识图谱 + 十万条消息的全文搜索）。 说人话就是：它帮你智能体记住了所有聊过的东西，并且知道在什么时候把什么拿出来。 架构很薄。去掉了之前那个笨重的 Docker 中间层，现在三层的故障点更少，部署一条命令搞定。支持重点档案（ Focused Dossier ）——比如某个重要的人、长期项目、反复出现的故障，可以单独追踪、优先召回。 生产数据来自一台连续跑了 2 个月的 Hermes 服务器：10,885 个知识图谱页面、42,481 个提取的事实节点、105,601 条可搜索的会话消息。不是原型，是每天在用的东西。 安装很简单：设一下 AGENT_HOME ，跑 install.sh ，选个 embedding 模型（ 6 种可选，默认推荐中英混合的 multilingual-e5-small ），其他自动完成。开源 MIT 协议。 https://github.com/mage0535/hermes-memory-installer
AI 智能体有个硬伤：记不住你。每次新对话都是白纸一张。你上周讨论过的项目背景、写过的代码逻辑、提过的个人偏好，它全忘了。这不是你的问题，是所有对话式 AI 的天生缺陷。 Memory Sidecar v3.1.0 就是为了解决这个。它是一个外挂记忆系统，跑在你的智能体（ Hermes 、Claude Code 、Cursor 、Codex ，什么都行）旁边，不碰核心代码，独立进程、共享目录。装完你的智能体就有了三层记忆：热层（当前会话 context ）→ 温层（ PostgreSQL 事实图谱，50ms 级召回）→ 冷层（知识图谱 + 十万条消息的全文搜索）。 说人话就是：它帮你智能体记住了所有聊过的东西，并且知道在什么时候把什么拿出来。 架构很薄。去掉了之前那个笨重的 Docker 中间层，现在三层的故障点更少，部署一条命令搞定。支持重点档案（ Focused Dossier ）——比如某个重要的人、长期项目、反复出现的故障，可以单独追踪、优先召回。 生产数据来自一台连续跑了 2 个月的 Hermes 服务器：10,885 个知识图谱页面、42,481 个提取的事实节点、105,601 条可搜索的会话消息。不是原型，是每天在用的东西。 安装很简单：设一下 AGENT_HOME ，跑 install.sh ，选个 embedding 模型（ 6 种可选，默认推荐中英混合的 multilingual-e5-small ），其他自动完成。开源 MIT 协议。 https://github.com/mage0535/hermes-memory-installer
AI 智能体有个硬伤：记不住你。每次新对话都是白纸一张。你上周讨论过的项目背景、写过的代码逻辑、提过的个人偏好，它全忘了。这不是你的问题，是所有对话式 AI 的天生缺陷。 Memory Sidecar v3.1.0 就是为了解决这个。它是一个外挂记忆系统，跑在你的智能体（ Hermes 、Claude Code 、Cursor 、Codex ，什么都行）旁边，不碰核心代码，独立进程、共享目录。装完你的智能体就有了三层记忆：热层（当前会话 context ）→ 温层（ PostgreSQL 事实图谱，50ms 级召回）→ 冷层（知识图谱 + 十万条消息的全文搜索）。 说人话就是：它帮你智能体记住了所有聊过的东西，并且知道在什么时候把什么拿出来。 架构很薄。去掉了之前那个笨重的 Docker 中间层，现在三层的故障点更少，部署一条命令搞定。支持重点档案（ Focused Dossier ）——比如某个重要的人、长期项目、反复出现的故障，可以单独追踪、优先召回。 生产数据来自一台连续跑了 2 个月的 Hermes 服务器：10,885 个知识图谱页面、42,481 个提取的事实节点、105,601 条可搜索的会话消息。不是原型，是每天在用的东西。 安装很简单：设一下 AGENT_HOME ，跑 install.sh ，选个 embedding 模型（ 6 种可选，默认推荐中英混合的 multilingual-e5-small ），其他自动完成。开源 MIT 协议。 https://github.com/mage0535/hermes-memory-installer
AI 智能体有个硬伤：记不住你。每次新对话都是白纸一张。你上周讨论过的项目背景、写过的代码逻辑、提过的个人偏好，它全忘了。这不是你的问题，是所有对话式 AI 的天生缺陷。 Memory Sidecar v3.1.0 就是为了解决这个。它是一个外挂记忆系统，跑在你的智能体（ Hermes 、Claude Code 、Cursor 、Codex ，什么都行）旁边，不碰核心代码，独立进程、共享目录。装完你的智能体就有了三层记忆：热层（当前会话 context ）→ 温层（ PostgreSQL 事实图谱，50ms 级召回）→ 冷层（知识图谱 + 十万条消息的全文搜索）。 说人话就是：它帮你智能体记住了所有聊过的东西，并且知道在什么时候把什么拿出来。 架构很薄。去掉了之前那个笨重的 Docker 中间层，现在三层的故障点更少，部署一条命令搞定。支持重点档案（ Focused Dossier ）——比如某个重要的人、长期项目、反复出现的故障，可以单独追踪、优先召回。 生产数据来自一台连续跑了 2 个月的 Hermes 服务器：10,885 个知识图谱页面、42,481 个提取的事实节点、105,601 条可搜索的会话消息。不是原型，是每天在用的东西。 安装很简单：设一下 AGENT_HOME ，跑 install.sh ，选个 embedding 模型（ 6 种可选，默认推荐中英混合的 multilingual-e5-small ），其他自动完成。开源 MIT 协议。 https://github.com/mage0535/hermes-memory-installer
AI Memory Hub 企业 AI 知识资产平台。自动采集、智能关联、随时复用。 员工和 AI 的每一次对话，都是企业的知识资产。 人走，知识留下。 [Github]( https://github.com/Vincent-chao-lang/AIHub ) https://aihub.dabuside.top/ 一、产品定位 AI Memory Hub 是一个企业级 AI 知识资产管理平台。它自动采集、整理、关联员工与 AI （ ChatGPT 、Claude 、DeepSeek 等）的所有高质量对话，将其转化为可检索、可关联、可复用的结构化知识资产，实现 **"人走，知识留下，价值继续"**。 二、企业为什么需要它 2.1 一个新问题的出现 2023 年开始，你的员工每天都在和 AI 对话： 研发 → ChatGPT 讨论架构方案 运维 → Claude 解决部署故障 产品 → DeepSeek 做竞品分析 设计 → Gemini 找设计灵感 运营 → Kimi 写内容策略 这些对话里藏着： · 技术决策的推演过程 · 故障排查的完整思路链 · 对业务的深度思考 · 反复验证过的最佳实践 2.2 一个老问题的新形式 传统离职交接： 员工写一份交接文档（如果有的话） → 只记录了"结论"，丢失了"思考过程" → AI 对话中的试错、推演、对比全部消失 → 新人面对同样问题，从零开始和 AI 聊 结果： 张三用 AI 花 3 天解决了部署问题，离职了。 李四入职遇到同样的故障，再花 3 天从零开始。 知识在，但不可见。 经验在，但无法复用。 2.3 量化损失 假设一个 50 人的技术团队，每人每天和 AI 进行 5 次有价值的对话： 日均知识产出： 50 × 5 = 250 条 AI 决策/推演记录 月均知识产出： 250 × 22 = 5,500 条 年均知识产出： 5,500 × 12 = 66,000 条 如果 80% 随员工流动而不可检索，每年损失： → 约 52,800 条有价值的知识碎片 → 无数可复用的决策链、故障排查路径、方案对比 每一片碎片背后，都是员工花时间与 AI 碰撞出的认知成果。 三、解决方案 3.1 一句话说清楚 员工用 AI 的同时，系统自动记录、理解、关联每一次对话，构建企业自有 AI 知识图谱。 人来，知识自动汇聚；人走，知识结构化管理，随时被新人检索和复用。 3.2 核心能力 ┌──────────────────────────────────────────────────────┐ │ 自动采集（零门槛） │ │ 浏览器扩展静默运行，员工正常使用 AI ，对话自动入库。 │ │ 不需要手动粘贴，不需要额外操作，不改变工作习惯。 │ └──────────────────────────┬───────────────────────────┘ │ ┌──────────────────────────┴───────────────────────────┐ │ 智能理解（结构化） │ │ 每条对话 → 自动生成标题、标签、摘要 │ │ 跨平台语义搜索 → 用自然语言找到任何历史对话 │ │ 知识图谱 → 自动发现对话之间的深层关联 │ └──────────────────────────┬───────────────────────────┘ │ ┌──────────────────────────┴───────────────────────────┐ │ 知识复用（价值闭环） │ │ 新人遇到问题 → 搜索关键词 → 看到前辈的完整 AI 决策链 │ │ AI 回答时 → 注入历史上下文 → 基于团队知识积累来回答 │ │ 团队知识 → 按人/按项目/按主题 → 随时检索和复用 │ └──────────────────────────────────────────────────────┘ 四、关键场景 场景 1：新人入职 传统方式： 新人花 2-4 周熟悉项目，遇到问题问同事或自己摸索和 AI 对话 → 其实前辈早就和 AI 深入讨论过同样的问题 AI Memory Hub： 新人搜索"微服务部署" → 看到： · 张三 3 个月前与 ChatGPT 的完整架构讨论 · 李四 1 个月前与 Claude 的故障排查全过程 · 系统自动生成的关联对话：CI/CD 配置、容器化方案 → 新人在 AI 提问时，注入前辈的上下文 → AI 基于团队已有认知来回答，而非从零开始 效果：新人上手速度 2x 提升，避免重复踩坑 场景 2：员工离职 传统方式： 张三离职 → 写交接文档 → 文档里的结论，丢失了 90% 的思考过程 → 那场"和 AI 反复讨论了 3 个小时才搞定的故障排查"彻底消失 AI Memory Hub： 张三的所有 AI 对话早已自动归档，按主题分类，图谱关联完整 → 李四搜索同一问题 → 直接看到张三当时的完整认知链 → 不只是结论，还有： · 张三问了什么 · AI 给了哪些方案 · 张三做了什么取舍 · 最终为什么选了方案 A 而不是 B 效果：知识保留率从 10% → 95%，真正的"人走知识留" 场景 3：跨部门经验复用 传统方式： 研发团队用 AI 解决了性能问题 运维团队可能永远不知道这个方案 → 遇到类似问题各自重新摸索 AI Memory Hub： 搜索"数据库性能" → 跨部门、跨平台、跨时间维度的所有相关对话汇聚一处 → 研发的架构思路 + 运维的实战经验 + 产品的业务视角 → 知识自动缝合，打破信息孤岛 效果：团队越用越聪明，知识自适应组织 场景 4：企业 AI 审计与合规 传统方式： 员工和 AI 聊了什么 → 无从知晓 是不是把内部代码贴给了 ChatGPT → 无法审查 大模型使用有没有合规风险 → 没法管理 AI Memory Hub： 所有 AI 对话完整记录，按人、平台、时间可检索 → 管理员可以看到：谁、在什么平台、讨论了什么话题 → 敏感信息自动标记（可配置关键词告警） → 满足企业对 AI 使用的审计和合规需求 效果：AI 使用透明化，安全与效率兼得 五、5 分钟跑起来 git clone https://github.com/Vincent-chao-lang/AIHub.git cd AIHub ./start.sh # 加载浏览器扩展 Chrome → chrome://extensions → 开发者模式 → 加载已解压 → 选择 extension/ 目录 # 打开任意 AI 平台 → 正常聊天 → 点击 🧠 图标 → 检索记忆 # 或访问 http://localhost:5173 → Web 面板 数据完全在本地。 不注册、不联网、不上传。你拥有全部数据。 六、 部署模式 模式 适合 配置 个人本地 个人使用 零配置， ./ start.sh 局域网共享 团队 5-50 人 改 host 为 0.0.0.0 Docker 标准化部署 docker-compose up HTTPS + 反向代理 远程团队 Nginx + Let's Encrypt 详细部署指南 → USAGE.md 七、 存储与扩展 默认 SQLite + ChromaDB + 本地 BGE 模型，零配置开箱即用。 随着团队规模增长，可平滑升级： SQLite + ChromaDB → PostgreSQL + pgvector → Milvus 零配置 改一行 .env 独立集群 < 10 万条 10-100 万条 > 100 万条 Embedding 模型同样支持一行配置切换： 本地 BGE-small （ 512 维） → BGE-large / 其他本地模型 → OpenAI / 智谱 API 默认 改模型名 改 EMBEDDING_PROVIDER 切换 embedding 后运行 python backend/ rebuild_index.py 即可全量重建向量索引。 详细升级路径 → docs/STORAGE.md 八、 项目结构 AIHub/ ├── start.sh # 一键启动 ├── backend/ # FastAPI + SQLite + ChromaDB │ ├── api/routes.py # 10 个 API 端点 │ ├── db/ # 数据库 + 向量存储（ ChromaDB/pgvector ） │ ├── models/ # 数据模型 │ └── services/ # embedding · 摘要 · 搜索 · 上下文生成 ├── extension/ # Chrome 扩展 (Manifest V3) │ ├── content/ # 5 平台 DOM 监听 │ ├── sidepanel/ # 侧边栏 UI + 逻辑 │ └── options/ # 设置页 ├── frontend/ # React + Vite + TypeScript + D3.js │ └── src/pages/ # 时间线 · 项目 · 上下文 · 图谱 └── landing/ # 营销页面（中英双语） 九、API 方法 路径 说明 POST /messages 上传消息（自动 embedding + 摘要） GET /timeline 时间线（按对话聚合，支持 ?user_id= 筛选） GET /conversations/{id} 对话详情 GET /conversations/{id}/related 相关对话推荐 POST /search 语义搜索（向量 + 关键词回退） POST /context 图谱驱动上下文生成（含 max_tokens 智能截断） GET /projects 项目聚合 GET /graph 知识图谱数据 GET /stats 统计（总数/平台分布/用户统计/向量索引数/embedding 信息） 十、 设计原则 自动采集 — 知识管理成本从"人"转移到"系统"，员工无需额外操作 本地优先 — 数据 100% 归你，也支持服务器部署 企业级扩展 — SQLite → PostgreSQL ，ChromaDB → pgvector ，随规模平滑升级 零摩擦接入 — 不改现有系统，不要求切换 AI 平台，不改变工作习惯 图谱驱动 — 关联发现用本地算法，不依赖外部 LLM ，零成本零延迟 团队即知识 — 同一套系统，一人用是外脑，团队用是知识库
AI Memory Hub 企业 AI 知识资产平台。自动采集、智能关联、随时复用。 员工和 AI 的每一次对话，都是企业的知识资产。 人走，知识留下。 [Github]( https://github.com/Vincent-chao-lang/AIHub ) https://aihub.dabuside.top/ 一、产品定位 AI Memory Hub 是一个企业级 AI 知识资产管理平台。它自动采集、整理、关联员工与 AI （ ChatGPT 、Claude 、DeepSeek 等）的所有高质量对话，将其转化为可检索、可关联、可复用的结构化知识资产，实现 **"人走，知识留下，价值继续"**。 二、企业为什么需要它 2.1 一个新问题的出现 2023 年开始，你的员工每天都在和 AI 对话： 研发 → ChatGPT 讨论架构方案 运维 → Claude 解决部署故障 产品 → DeepSeek 做竞品分析 设计 → Gemini 找设计灵感 运营 → Kimi 写内容策略 这些对话里藏着： · 技术决策的推演过程 · 故障排查的完整思路链 · 对业务的深度思考 · 反复验证过的最佳实践 2.2 一个老问题的新形式 传统离职交接： 员工写一份交接文档（如果有的话） → 只记录了"结论"，丢失了"思考过程" → AI 对话中的试错、推演、对比全部消失 → 新人面对同样问题，从零开始和 AI 聊 结果： 张三用 AI 花 3 天解决了部署问题，离职了。 李四入职遇到同样的故障，再花 3 天从零开始。 知识在，但不可见。 经验在，但无法复用。 2.3 量化损失 假设一个 50 人的技术团队，每人每天和 AI 进行 5 次有价值的对话： 日均知识产出： 50 × 5 = 250 条 AI 决策/推演记录 月均知识产出： 250 × 22 = 5,500 条 年均知识产出： 5,500 × 12 = 66,000 条 如果 80% 随员工流动而不可检索，每年损失： → 约 52,800 条有价值的知识碎片 → 无数可复用的决策链、故障排查路径、方案对比 每一片碎片背后，都是员工花时间与 AI 碰撞出的认知成果。 三、解决方案 3.1 一句话说清楚 员工用 AI 的同时，系统自动记录、理解、关联每一次对话，构建企业自有 AI 知识图谱。 人来，知识自动汇聚；人走，知识结构化管理，随时被新人检索和复用。 3.2 核心能力 ┌──────────────────────────────────────────────────────┐ │ 自动采集（零门槛） │ │ 浏览器扩展静默运行，员工正常使用 AI ，对话自动入库。 │ │ 不需要手动粘贴，不需要额外操作，不改变工作习惯。 │ └──────────────────────────┬───────────────────────────┘ │ ┌──────────────────────────┴───────────────────────────┐ │ 智能理解（结构化） │ │ 每条对话 → 自动生成标题、标签、摘要 │ │ 跨平台语义搜索 → 用自然语言找到任何历史对话 │ │ 知识图谱 → 自动发现对话之间的深层关联 │ └──────────────────────────┬───────────────────────────┘ │ ┌──────────────────────────┴───────────────────────────┐ │ 知识复用（价值闭环） │ │ 新人遇到问题 → 搜索关键词 → 看到前辈的完整 AI 决策链 │ │ AI 回答时 → 注入历史上下文 → 基于团队知识积累来回答 │ │ 团队知识 → 按人/按项目/按主题 → 随时检索和复用 │ └──────────────────────────────────────────────────────┘ 四、关键场景 场景 1：新人入职 传统方式： 新人花 2-4 周熟悉项目，遇到问题问同事或自己摸索和 AI 对话 → 其实前辈早就和 AI 深入讨论过同样的问题 AI Memory Hub： 新人搜索"微服务部署" → 看到： · 张三 3 个月前与 ChatGPT 的完整架构讨论 · 李四 1 个月前与 Claude 的故障排查全过程 · 系统自动生成的关联对话：CI/CD 配置、容器化方案 → 新人在 AI 提问时，注入前辈的上下文 → AI 基于团队已有认知来回答，而非从零开始 效果：新人上手速度 2x 提升，避免重复踩坑 场景 2：员工离职 传统方式： 张三离职 → 写交接文档 → 文档里的结论，丢失了 90% 的思考过程 → 那场"和 AI 反复讨论了 3 个小时才搞定的故障排查"彻底消失 AI Memory Hub： 张三的所有 AI 对话早已自动归档，按主题分类，图谱关联完整 → 李四搜索同一问题 → 直接看到张三当时的完整认知链 → 不只是结论，还有： · 张三问了什么 · AI 给了哪些方案 · 张三做了什么取舍 · 最终为什么选了方案 A 而不是 B 效果：知识保留率从 10% → 95%，真正的"人走知识留" 场景 3：跨部门经验复用 传统方式： 研发团队用 AI 解决了性能问题 运维团队可能永远不知道这个方案 → 遇到类似问题各自重新摸索 AI Memory Hub： 搜索"数据库性能" → 跨部门、跨平台、跨时间维度的所有相关对话汇聚一处 → 研发的架构思路 + 运维的实战经验 + 产品的业务视角 → 知识自动缝合，打破信息孤岛 效果：团队越用越聪明，知识自适应组织 场景 4：企业 AI 审计与合规 传统方式： 员工和 AI 聊了什么 → 无从知晓 是不是把内部代码贴给了 ChatGPT → 无法审查 大模型使用有没有合规风险 → 没法管理 AI Memory Hub： 所有 AI 对话完整记录，按人、平台、时间可检索 → 管理员可以看到：谁、在什么平台、讨论了什么话题 → 敏感信息自动标记（可配置关键词告警） → 满足企业对 AI 使用的审计和合规需求 效果：AI 使用透明化，安全与效率兼得 五、5 分钟跑起来 git clone https://github.com/Vincent-chao-lang/AIHub.git cd AIHub ./start.sh # 加载浏览器扩展 Chrome → chrome://extensions → 开发者模式 → 加载已解压 → 选择 extension/ 目录 # 打开任意 AI 平台 → 正常聊天 → 点击 🧠 图标 → 检索记忆 # 或访问 http://localhost:5173 → Web 面板 数据完全在本地。 不注册、不联网、不上传。你拥有全部数据。 六、 部署模式 模式 适合 配置 个人本地 个人使用 零配置， ./ start.sh 局域网共享 团队 5-50 人 改 host 为 0.0.0.0 Docker 标准化部署 docker-compose up HTTPS + 反向代理 远程团队 Nginx + Let's Encrypt 详细部署指南 → USAGE.md 七、 存储与扩展 默认 SQLite + ChromaDB + 本地 BGE 模型，零配置开箱即用。 随着团队规模增长，可平滑升级： SQLite + ChromaDB → PostgreSQL + pgvector → Milvus 零配置 改一行 .env 独立集群 < 10 万条 10-100 万条 > 100 万条 Embedding 模型同样支持一行配置切换： 本地 BGE-small （ 512 维） → BGE-large / 其他本地模型 → OpenAI / 智谱 API 默认 改模型名 改 EMBEDDING_PROVIDER 切换 embedding 后运行 python backend/ rebuild_index.py 即可全量重建向量索引。 详细升级路径 → docs/STORAGE.md 八、 项目结构 AIHub/ ├── start.sh # 一键启动 ├── backend/ # FastAPI + SQLite + ChromaDB │ ├── api/routes.py # 10 个 API 端点 │ ├── db/ # 数据库 + 向量存储（ ChromaDB/pgvector ） │ ├── models/ # 数据模型 │ └── services/ # embedding · 摘要 · 搜索 · 上下文生成 ├── extension/ # Chrome 扩展 (Manifest V3) │ ├── content/ # 5 平台 DOM 监听 │ ├── sidepanel/ # 侧边栏 UI + 逻辑 │ └── options/ # 设置页 ├── frontend/ # React + Vite + TypeScript + D3.js │ └── src/pages/ # 时间线 · 项目 · 上下文 · 图谱 └── landing/ # 营销页面（中英双语） 九、API 方法 路径 说明 POST /messages 上传消息（自动 embedding + 摘要） GET /timeline 时间线（按对话聚合，支持 ?user_id= 筛选） GET /conversations/{id} 对话详情 GET /conversations/{id}/related 相关对话推荐 POST /search 语义搜索（向量 + 关键词回退） POST /context 图谱驱动上下文生成（含 max_tokens 智能截断） GET /projects 项目聚合 GET /graph 知识图谱数据 GET /stats 统计（总数/平台分布/用户统计/向量索引数/embedding 信息） 十、 设计原则 自动采集 — 知识管理成本从"人"转移到"系统"，员工无需额外操作 本地优先 — 数据 100% 归你，也支持服务器部署 企业级扩展 — SQLite → PostgreSQL ，ChromaDB → pgvector ，随规模平滑升级 零摩擦接入 — 不改现有系统，不要求切换 AI 平台，不改变工作习惯 图谱驱动 — 关联发现用本地算法，不依赖外部 LLM ，零成本零延迟 团队即知识 — 同一套系统，一人用是外脑，团队用是知识库
AI Memory Hub 企业 AI 知识资产平台。自动采集、智能关联、随时复用。 员工和 AI 的每一次对话，都是企业的知识资产。 人走，知识留下。 [Github]( https://github.com/Vincent-chao-lang/AIHub ) https://aihub.dabuside.top/ 一、产品定位 AI Memory Hub 是一个企业级 AI 知识资产管理平台。它自动采集、整理、关联员工与 AI （ ChatGPT 、Claude 、DeepSeek 等）的所有高质量对话，将其转化为可检索、可关联、可复用的结构化知识资产，实现 **"人走，知识留下，价值继续"**。 二、企业为什么需要它 2.1 一个新问题的出现 2023 年开始，你的员工每天都在和 AI 对话： 研发 → ChatGPT 讨论架构方案 运维 → Claude 解决部署故障 产品 → DeepSeek 做竞品分析 设计 → Gemini 找设计灵感 运营 → Kimi 写内容策略 这些对话里藏着： · 技术决策的推演过程 · 故障排查的完整思路链 · 对业务的深度思考 · 反复验证过的最佳实践 2.2 一个老问题的新形式 传统离职交接： 员工写一份交接文档（如果有的话） → 只记录了"结论"，丢失了"思考过程" → AI 对话中的试错、推演、对比全部消失 → 新人面对同样问题，从零开始和 AI 聊 结果： 张三用 AI 花 3 天解决了部署问题，离职了。 李四入职遇到同样的故障，再花 3 天从零开始。 知识在，但不可见。 经验在，但无法复用。 2.3 量化损失 假设一个 50 人的技术团队，每人每天和 AI 进行 5 次有价值的对话： 日均知识产出： 50 × 5 = 250 条 AI 决策/推演记录 月均知识产出： 250 × 22 = 5,500 条 年均知识产出： 5,500 × 12 = 66,000 条 如果 80% 随员工流动而不可检索，每年损失： → 约 52,800 条有价值的知识碎片 → 无数可复用的决策链、故障排查路径、方案对比 每一片碎片背后，都是员工花时间与 AI 碰撞出的认知成果。 三、解决方案 3.1 一句话说清楚 员工用 AI 的同时，系统自动记录、理解、关联每一次对话，构建企业自有 AI 知识图谱。 人来，知识自动汇聚；人走，知识结构化管理，随时被新人检索和复用。 3.2 核心能力 ┌──────────────────────────────────────────────────────┐ │ 自动采集（零门槛） │ │ 浏览器扩展静默运行，员工正常使用 AI ，对话自动入库。 │ │ 不需要手动粘贴，不需要额外操作，不改变工作习惯。 │ └──────────────────────────┬───────────────────────────┘ │ ┌──────────────────────────┴───────────────────────────┐ │ 智能理解（结构化） │ │ 每条对话 → 自动生成标题、标签、摘要 │ │ 跨平台语义搜索 → 用自然语言找到任何历史对话 │ │ 知识图谱 → 自动发现对话之间的深层关联 │ └──────────────────────────┬───────────────────────────┘ │ ┌──────────────────────────┴───────────────────────────┐ │ 知识复用（价值闭环） │ │ 新人遇到问题 → 搜索关键词 → 看到前辈的完整 AI 决策链 │ │ AI 回答时 → 注入历史上下文 → 基于团队知识积累来回答 │ │ 团队知识 → 按人/按项目/按主题 → 随时检索和复用 │ └──────────────────────────────────────────────────────┘ 四、关键场景 场景 1：新人入职 传统方式： 新人花 2-4 周熟悉项目，遇到问题问同事或自己摸索和 AI 对话 → 其实前辈早就和 AI 深入讨论过同样的问题 AI Memory Hub： 新人搜索"微服务部署" → 看到： · 张三 3 个月前与 ChatGPT 的完整架构讨论 · 李四 1 个月前与 Claude 的故障排查全过程 · 系统自动生成的关联对话：CI/CD 配置、容器化方案 → 新人在 AI 提问时，注入前辈的上下文 → AI 基于团队已有认知来回答，而非从零开始 效果：新人上手速度 2x 提升，避免重复踩坑 场景 2：员工离职 传统方式： 张三离职 → 写交接文档 → 文档里的结论，丢失了 90% 的思考过程 → 那场"和 AI 反复讨论了 3 个小时才搞定的故障排查"彻底消失 AI Memory Hub： 张三的所有 AI 对话早已自动归档，按主题分类，图谱关联完整 → 李四搜索同一问题 → 直接看到张三当时的完整认知链 → 不只是结论，还有： · 张三问了什么 · AI 给了哪些方案 · 张三做了什么取舍 · 最终为什么选了方案 A 而不是 B 效果：知识保留率从 10% → 95%，真正的"人走知识留" 场景 3：跨部门经验复用 传统方式： 研发团队用 AI 解决了性能问题 运维团队可能永远不知道这个方案 → 遇到类似问题各自重新摸索 AI Memory Hub： 搜索"数据库性能" → 跨部门、跨平台、跨时间维度的所有相关对话汇聚一处 → 研发的架构思路 + 运维的实战经验 + 产品的业务视角 → 知识自动缝合，打破信息孤岛 效果：团队越用越聪明，知识自适应组织 场景 4：企业 AI 审计与合规 传统方式： 员工和 AI 聊了什么 → 无从知晓 是不是把内部代码贴给了 ChatGPT → 无法审查 大模型使用有没有合规风险 → 没法管理 AI Memory Hub： 所有 AI 对话完整记录，按人、平台、时间可检索 → 管理员可以看到：谁、在什么平台、讨论了什么话题 → 敏感信息自动标记（可配置关键词告警） → 满足企业对 AI 使用的审计和合规需求 效果：AI 使用透明化，安全与效率兼得 五、5 分钟跑起来 git clone https://github.com/Vincent-chao-lang/AIHub.git cd AIHub ./start.sh # 加载浏览器扩展 Chrome → chrome://extensions → 开发者模式 → 加载已解压 → 选择 extension/ 目录 # 打开任意 AI 平台 → 正常聊天 → 点击 🧠 图标 → 检索记忆 # 或访问 http://localhost:5173 → Web 面板 数据完全在本地。 不注册、不联网、不上传。你拥有全部数据。 六、 部署模式 模式 适合 配置 个人本地 个人使用 零配置， ./ start.sh 局域网共享 团队 5-50 人 改 host 为 0.0.0.0 Docker 标准化部署 docker-compose up HTTPS + 反向代理 远程团队 Nginx + Let's Encrypt 详细部署指南 → USAGE.md 七、 存储与扩展 默认 SQLite + ChromaDB + 本地 BGE 模型，零配置开箱即用。 随着团队规模增长，可平滑升级： SQLite + ChromaDB → PostgreSQL + pgvector → Milvus 零配置 改一行 .env 独立集群 < 10 万条 10-100 万条 > 100 万条 Embedding 模型同样支持一行配置切换： 本地 BGE-small （ 512 维） → BGE-large / 其他本地模型 → OpenAI / 智谱 API 默认 改模型名 改 EMBEDDING_PROVIDER 切换 embedding 后运行 python backend/ rebuild_index.py 即可全量重建向量索引。 详细升级路径 → docs/STORAGE.md 八、 项目结构 AIHub/ ├── start.sh # 一键启动 ├── backend/ # FastAPI + SQLite + ChromaDB │ ├── api/routes.py # 10 个 API 端点 │ ├── db/ # 数据库 + 向量存储（ ChromaDB/pgvector ） │ ├── models/ # 数据模型 │ └── services/ # embedding · 摘要 · 搜索 · 上下文生成 ├── extension/ # Chrome 扩展 (Manifest V3) │ ├── content/ # 5 平台 DOM 监听 │ ├── sidepanel/ # 侧边栏 UI + 逻辑 │ └── options/ # 设置页 ├── frontend/ # React + Vite + TypeScript + D3.js │ └── src/pages/ # 时间线 · 项目 · 上下文 · 图谱 └── landing/ # 营销页面（中英双语） 九、API 方法 路径 说明 POST /messages 上传消息（自动 embedding + 摘要） GET /timeline 时间线（按对话聚合，支持 ?user_id= 筛选） GET /conversations/{id} 对话详情 GET /conversations/{id}/related 相关对话推荐 POST /search 语义搜索（向量 + 关键词回退） POST /context 图谱驱动上下文生成（含 max_tokens 智能截断） GET /projects 项目聚合 GET /graph 知识图谱数据 GET /stats 统计（总数/平台分布/用户统计/向量索引数/embedding 信息） 十、 设计原则 自动采集 — 知识管理成本从"人"转移到"系统"，员工无需额外操作 本地优先 — 数据 100% 归你，也支持服务器部署 企业级扩展 — SQLite → PostgreSQL ，ChromaDB → pgvector ，随规模平滑升级 零摩擦接入 — 不改现有系统，不要求切换 AI 平台，不改变工作习惯 图谱驱动 — 关联发现用本地算法，不依赖外部 LLM ，零成本零延迟 团队即知识 — 同一套系统，一人用是外脑，团队用是知识库
随着自己使用各家 ai 高强度 coding 以来， 我发现一直在做一件事情就是， 认识 AI 。 我发现我大量的时间在研究它们擅长什么、不擅长什么；我们学习提示词，我们把一个个 AI 工具接进工作流，然后慢慢知道：这个适合写代码，那个适合写文章，另一个适合查资料。 但反过来想，一个问题一直没有被很好解决： AI 什么时候开始认识我们？ 我希望在一次次交流里，逐渐知道你的偏好、你的项目、你的表达方式、你的技术取舍、你反复强调过的原则，以及你不希望它再犯的错误。我觉得这件事会是个人 AI 助手真正成立的前提。因为真正长期陪你工作的 AI ，不应该每次都像第一次见面。 所以我最近在做一个小项目：Personal Ai Memory OS ( PAM-OS) 。 一句话介绍：PAM-OS 是一个 local-first 的 AI 记忆运行时 。它想做的不是新的聊天客户端，而是把“记忆”从具体模型和具体 App 里拆出来，变成任何 Agent 都可以调用的一层个人记忆基础设施。 在我的设想里，memory 不只是“存档”，而是 AI 认识一个人的证据 ： 你做过哪些项目，它能逐渐知道。 你偏好什么回答风格，它能慢慢稳定下来。 你在技术上做过哪些取舍，它不会每次重新争论。 你明确纠正过什么，它应该真的记住。 什么时候该用记忆，什么时候不该打扰，它也应该能学习。 整个架构图如下： 目前 PAM-OS 已经具备这些基础能力： 本地优先 ：默认使用 SQLite ，数据放在自己机器上， 其实它也支持远端 rest api 的调用方式。 Agent 友好 ：支持 CLI 、REST API 、MCP ，也打包了 Codex 插件和 Skill ， 目前着重测试了 codex, 如果其他的存在问题，欢迎反馈。 按需读取记忆 ：先判断任务是否需要历史信息，而不是无脑塞上下文。 选择性沉淀 ：只捕捉稳定偏好、长期目标、项目决策、写作风格和纠正反馈。 用户画像归纳 ：把多次行为证据合并成更稳定的 profile trait 。 策略记忆 ：不只记“你说过什么”，还学习“什么时候该使用记忆”。 扩展支持 ：策略、检索、重排、抽取、归纳都留了接口，未来可以接 LLM 、embedding 或混合检索。 我希望 PAM-OS 最终不是某个客户端的附属功能，而是一个可以被 Codex 、Claude Code 、OpenCode 、Hermes ，甚至更多工具共同使用的 个人记忆层 。 项目地址： https://github.com/danzhewuju/PAM-OS 一键安装脚本： curl -fsSL https://raw.githubusercontent.com/danzhewuju/PAM-OS/refs/heads/master/scripts/install-plugin.sh | bash
项目地址： https://github.com/mage0535/hermes-memory-installer 背景 用过 AI 智能体（ Claude Code / Cursor / Hermes ）的人应该都体会过：每次新对话就是一张白纸。上个会话讨论过的架构决策、当事人、项目背景，下个会话全不记得。重新描述一次两次忍了，十次二十次就麻了。 这个项目的思路是：在智能体旁边跑一个记忆 sidecar ，不碰智能体核心代码。智能体正常写会话，sidecar 负责归档、索引、治理、召回。 v3.0 做了什么 v3.0 实现了完整的外挂记忆管线： 会话采集 → session_to_gbrain.py （增量归档到 gbrain ） 治理重建 → memory_governance_rebuild.py （ FTS5 索引、memory object 多版本状态、向量嵌入） 分层召回 → tiered_context_injector.py （ L1 最近会话 / L2 关键词搜索 / L3 治理对象 + 语义向量，RRF 融合 + 意图重排序） 健康监控 → memory_guardian.py （容量、重复率、stuck 操作检测、安全排空） 编排 + 验收 → memory_maintenance_cycle.py + sidecar_acceptance_check.py 几个值得说的设计 多智能体兼容 统一用 AGENT_HOME 环境变量定位智能体数据目录，向后兼容 HERMES_HOME 。设个变量就能挂到不同智能体上。 多版本记忆对象 同一个事实的多版陈述自动分 conflict group ，最新最好的标记 active ，其余 superseded （设 valid_to ）。查询只返回 active ，但历史不丢。 可选向量索引 配置 EMBEDDING_API_URL （ OpenAI 兼容格式）即可自动为 memory object 生成嵌入存到 canonical_semantic_index 表。不配的话，全文本检索（ FTS5 / LIKE / hindsight / gbrain ）完全正常。 Focused Dossier 重要人物 / 关系 / 项目可以提升为一级记忆对象。生产版已验证了 relationship dossier 。 生产情况 生产服务器跑了半年多，12600+ 会话、2GB state.db 、75MB governance.db 。每周跑一次完整维护周期（归档→重建→排空→召回验证），持续稳定。 欢迎 PR / Issue / Star ⭐ 使用方式 git clone https://github.com/mage0535/hermes-memory-installer.git cd hermes-memory-installer python3 installer/install.py --noninteractive AGENT_HOME=/root/.hermes python3 /root/.hermes/scripts/memory_maintenance_cycle.py
IT之家 5 月 28 日消息，腾讯混元宣布正式推出 Hy-Memory。据介绍，这是一个专门为 Openclaw 这类长期协作型 Agent 设计的记忆插件，能真正成为 Agent 的“第二大脑”。 官方称，Hy-Memory 用 6 层记忆框架 × System1/System2 双系统 × 演化链三层底牌，让 Agent 在长期使用中真正 " 记得住、记得对、记得轻、更懂你 "。 在权威公开测试集上，Hy-Memory 效果超过现有主流 memory 框架，可以解决记忆碎片化问题，记忆数量低 70%+，每条记忆信息密度高 45%+。在处理超长上下文方面，Hy-Memory 消耗的 token 量降低 35%，记忆更新速度快 20%。 IT之家附官方详细介绍如下： Agent 任务对长期记忆的要求远超 Chat 使用 Agent 和 Openclaw 深度用户，常常描述过一种常见的“三周轨迹”。 第一周: 蜜月期，把自己当下正在忙的事情，比如一个项目的来龙去脉、最近的决定和取舍、未来想做的方向一股脑都告诉 Openclaw。，能回答问题、能查资料、能帮你规划、能写代码、能起草文档。“这玩意儿真好用”—— 这是大多数人第一周的真实感受。 第二周: 开始不安。人们注意到每天打开 Openclaw 都得先花 3 到 5 分钟提醒它我们在做什么。它好像不太记得几天前讨论过的判断。当你对它说“按之前那个方案”，它会反问“哪个方案”，说“那个我们排除掉的选项”，它却想不起来排除的是什么、为什么排除。不是完全不记得。Openclaw 默认的记忆机制能记住一些最近的对话原文，但跨天、跨 Session、那些更深的判断，它就漂移了。 第三周: 主动降级使用，开始下意识地缩短跟它讨论的深度。不再问“这个方向我该不该走”，因为知道明天它就忘了。变成只问最具体、最即时的小问题: 搜个资料、查个语法、改一段文字。 最常见的结局是，Openclaw 在使用者眼里，慢慢从“能陪你思考的伙伴”，降级成了“一个查询工具”。这不是 Openclaw 的问题 —— 它的内核能力一直很强。问题在于：长期协作类任务对长期记忆的要求，远超过普通 Chat。 Hy-Memory 这个 Openclaw 记忆插件的初衷，就是为了把这三周轨迹的后两周抹掉 —— 让用户第一周怎么用 Openclaw，第三个月还能怎么用，而且越用越懂。 1、长期任务对记忆的挑战比想象中难 长期任务跟普通 Chat 完全是两种工作。不管你拿 Openclaw 调研一个复杂决策、写一本书、规划一次大旅行、跟进一个跨季度的项目，一次对话可能 30 轮 50 轮 100 轮，中间不停地查资料、调工具、读文档、出方案、回退、再改、再走，一个 Session 可能持续几个小时，任务可能跨越数周。 记忆系统至少要扛住 4 件事： 任何一个环节崩了，体验就崩了。 2、一个合格的 Openclaw 记忆插件要满足的 3 条标准 我们在设计 Hy-Memory 的时候围绕“什么样的记忆插件才配得上 Openclaw 这种长期协作场景”，定了 3 条硬标准。 标准一：不能丢历史。 用户跟 Agent 聊过的所有“为什么选这个、为什么否那个”—— 这些判断和因果不能丢。否则下次它推荐方案，可能直接推荐回用户已经否过的那个，白费时间。 标准二：要能演化。 人不是一个静态的存在。技术偏好、生活习惯、长期目标都会随时间变，对某件事的看法也会反复调整，这些都得被记住。不是覆盖式的“只记最新”, 也不是堆积式的“全都留下”，而是要有一个清晰的演化轨迹。 标准三：要在主链路里不仅足够快，还要有认知迭代，进化。 记忆插件不能拖慢用户当下打字、调用工具、等结果的速度。每次搜索要在毫秒级, 召回也不能成为响应瓶颈。同时还要有深层次的语义和事实理解。 接下来，我们把 Hy-Memory 满足这 3 条标准的三层底牌分别讲清楚。 Hy-Memory 的三层核心 第一层：6 层记忆框架 —— 给每种记忆找到正确位置 Hy-Memory 做的第一件事, 是没有把所有记忆塞进同一张表。 想一下 —— 用户跟 Openclaw 聊到最近在准备出国留学, 这段话里其实混着好几种东西： · “我在准备出国留学”—— 这是事实 · “我偏好北欧那种慢节奏的项目”—— 这是画像 · “我做大决策前会先列利弊清单”—— 这是心智模型 · “我下周大概率会问推荐信怎么找教授”—— 这是前瞻意图 这些东西信息形态完全不一样, 但传统记忆系统会把它们全揉成一堆向量，搜索时一锅捞。Hy-Memory 把记忆分成 6 层，每层一种职责。下面用一组多领域混合的例子，让你感受 Agent “记的是什么”： 用户问 Openclaw “我做大决策有什么习惯”, 它应该优先看 L5 心智模型, 而不是把过去 100 轮对话原文一锅塞过来。用户问 " 我现在住在哪 ",L2 一条事实就够了。问什么、走哪层、用什么样的检索权重 —— 分层让这些都变得可能。 整个 prompt 会变干净。模型的注意力不再被无关原文稀释。 第二层：双系统设计，既保障速度又具备认知迭代 Hy-Memory 把来自人脑认知科学的 System1 / System2 机制直接复刻到了 Agent 的记忆加工上 —— 就像给 Openclaw 装了一颗符合认知科学的 " 大脑 "。 Hy-Memory 把记忆加工拆成两套。 System1 (白班)：用户回车那一秒，实时地处理写入的记忆。负责写原始痕迹、抽事实、更新画像、压会话摘要 —— 也就是 L1–L4 System2 (夜班)：秒到分钟级，在后台跑。负责抽心智模型、构建知识网络、预测意图 —— 也就是 L5–L6 为什么要拆？因为深度认知很慢。抽你的“决策心智模型”、构建你的“知识网络”—— 做完一遍 LLM 可能要 5 到 20 秒。如果让你每次调用 Openclaw 都等 20 秒才能收到回复，谁都用不下去。 但你要的也不仅是“快”—— 你要的是 Agent 越用越懂你。Hy-Memory 的拆分把这两件互相打架的事变成两条独立通道： 1、发送消息后 System1 已经把“立即可用的记忆”写好了 —— 下一句对话能立刻用上 2、 System2 在后台慢慢做更深的认知 —— 把你两周的对话沉淀成“你的决策心智” 结果在对话最直接的影响：你每次说完的信息它能立马记住；而它对你的理解还在后台不断变深。 第三层：演化链 —— 记忆能改写但不丢因果 第三层是 Hy-Memory 真正的杀手锏，也是我们觉得用户长期跟 Agent 协作时最容易踩坑、也最值得做对的一件事。 一个典型的长期场景：假设一位用户跟 Openclaw 聊了大半年自己的健身计划。过去半年里他的训练方式发生过 4 次明显的态度转折： · 去年春 — 开始跑步训练有氧，效果不错，体重和精神状态都改善了，对跑步充满信心 · 去年夏 — 跟练 HIIT，强度太大，膝盖出了问题，被迫停训两周 · 去年秋 — 转向纯力量训练，只练大重量、放弃了心肺，结果跑两公里都喘, 挫败 · 上月 — 形成「力量 + 慢跑 + 瑜伽」混合方案，身体状态终于稳定下来 今天他打开 Openclaw 问它：“我下个月想再加一种新的训练方式，你建议什么？” 三种记忆系统会给出三种答案。 答案 1：覆盖派 (只记最新) 很多默认记忆系统是“用新覆盖旧”。库里只剩“用户当前用混合训练效果好”。 Agent 的回答：“你现在的力量 + 慢跑 + 瑜伽组合挺好, 可以再加一个 CrossFit 试试, 效率高。” 不算错，但很浅。它不知道用户为什么走到混合训练 —— 错过了“HIIT 伤过膝盖”、“纯力量丢了心肺”这条完整的踩坑路径。直接推荐 CrossFit 很可能让用户再伤一次膝盖。 答案 2：堆积派 (全部保留) 另一些系统是“什么都留下，搜索时按向量相似度召回”。库里 4 条事实都在, 但搜索“新训练方式”时，最近的、最相似的先被召回 —— 大概率是“跑步起步效果不错”和“混合训练稳定”。 中间的“HIIT 膝盖受伤”、“纯力量丢心肺”在语义空间里距离稍远，可能根本召不回。 Agent 的回答：“你跑步效果不错、混合训练也稳定, 可以加一个 HIIT 试试, 提升心肺效率高。” 踩雷了。它没意识到用户已经在 HIIT 上受过伤 —— 重新推荐 HIIT 等于让用户再走一次老路、再伤一次膝盖。 答案 3：Hy-Memory 演化链 Hy-Memory 在写入第 2 条记忆时，会用 supersedes 指针指向第 1 条；第 3 条指向第 2 条；第 4 条指向第 3 条。4 条记忆通过指针串成一条链。D (混合训练，链头) ↓ supersedes C (纯力量，丢心肺) ↓ supersedes B (HIIT, 膝盖受伤) ↓ supersedes A (跑步起步) 用户问“新训练方式选什么”时，搜索命中链头 D, 整条链自动展开 ——A、B、C、D 一起返回给 Agent。 Agent 拿到的不再是孤立结论而是完整的态度演变： ● 跑步起步 → ● HIIT 伤膝盖 → ● 纯力量丢心肺 → ● 混合方案稳定下来 它的回答会是这样： “你之前在训练方式上走过完整的路: 跑步起步、HIIT 伤过一次膝盖、纯力量又丢了心肺，上月才走到力量 + 慢跑 + 瑜伽这个稳定组合。 所以新方式我会建议你避开高冲击的爆发类训练（比如 CrossFit、HIIT 这类)—— 你的膝盖已经踩过一次坑。如果想再加新内容, 可以考虑游泳或骑行这种低冲击有氧, 或者爬山 / 长距离慢跑 —— 都比再回 HIIT 安全。” 这个回答的质量，不是来自模型本身，是来自记忆结构。 演化链的本质 技术上演化链做的就是两件事： 1、新记忆写入时，通过 supersedes 指针指向旧记忆, 形成一条链 2、搜索命中链上任意一节点，自动展开整条链 最新的判断在最前面（链头），但被否过的、被替代的、被废弃的旧版本不会丢 —— 只是退到链身后面，需要时随时展开。这是我们能想到的、最适合 Agent 长期陪伴用户的“长期记忆”形态。 Hy-Memory：超过同类框架 Hy-Memory 在 LongMemEval 和 PersonaMem 这两个权威的长期记忆评测上跑过。 1、LongMemEval：得分达 85.2，远超其他框架。LongMemEval 是公认很难的长期记忆评测，500 道题覆盖 6 个能力维度。 Hy-Memory 不仅打赢所有同类系统，在 6 个维度中的 4 个维度取得最高分 —— 尤其在最考验 " 演化能力 " 的偏好 (+21.11pp)、时序推理 (+9.63pp)、知识更新 (+21.37pp) 三项上领先同类产品。 2、 PersonaMem：打赢所有同类产品，PersonaMem 是 6000+ 条消息 / 589 道题的真实长期对话评测, 更贴近 " 用户用了好几个月 " 的真实场景。 3、性能：有更高的记忆密度同时，更有 8 倍写入速度 Openclaw 用户能感受到的是： · 写入快：跟 mem0 同档，是 Graphiti 的 8 倍快，不会卡 Openclaw 的对话主链路 · 存得少：记忆条数只有 mem0 的 1/3、Graphiti 的 1/4–1/5，本地嵌入式存储，不需要外部服务，内存占用低 · 密度高：单条记忆是 mem0 的 3–4 倍信息密度，每次召回的记忆更管用，prompt 不被噪声污染 最后这条对长期任务特别重要：当一次 Session 跑到 80 轮对话, 召回的每一条记忆都得是高密度的, 否则 prompt 一下就被噪声塞爆, 模型注意力被稀释。 Hy-Memory 的高密度意味着同样的 Token 预算下 Openclaw 能看到比别的记忆系统多 3-4 倍的有效信息。