OpenHuman 与 OpenViking 深度拆解：Agent 的长期记忆究竟该怎么建？
**本文欲回答的核心问题：**面对日益复杂的 AI 应用，Agent 到底怎样才能获得长期、稳定、可维护的上下文，从而摆脱“失忆”的宿命？
如果把当前的 AI 应用比作电影《盗梦空间》里的造梦过程，那么我们过去半年都在做同一件事：拼命训练造梦师（大模型）的逻辑，却忽略了梦境的物理架构。当对话结束，梦境崩塌，所有的上下文瞬间归零。
最近被频繁放在一起讨论的 OpenHuman 和 OpenViking，正是在尝试回答这个终极问题——如何为 AI 构建真实的、持久的物理记忆。但如果你把它们当成竞品去分析，就会完全错过其中的技术演进的脉络。
OpenHuman 并非在做一个新的聊天框，它本质上是在把 Karpathy 提过的 LLM Knowledge Base / Obsidian Wiki 思路进行产品化落地，偏向个人 AI 助手体验。而 OpenViking 则是在更底层的维度，致力于打造 Agent 的上下文基础设施，是一个纯粹的 Agent context database。
这两者，一个在搭建普通人看得见摸得着的“梦境宫殿”，另一个在编写维持梦境不崩塌的“物理法则”。
图片来源：Unsplash
为什么我们需要重新审视 Agent 的“记忆”？
**本段欲回答的核心问题：**现有的普通 RAG 路径和短期对话机制，为什么无法支撑 Agent 的长期运作？
在接触这两个项目之前，我们必须先直面当前 AI 记忆机制的痛点。普通 RAG 的路径大家已经非常熟悉：把文档切分成碎片，做向量化，然后在向量库里进行 top-k 检索，最后塞回提示词中。
这种路径在处理“单一文档问答”时堪称完美，但在面对一个具有持续生命周期的 Agent 时，它会暴露出致命的缺陷：扁平化与断裂感。
想象一下你正在处理一个跨越三个月的复杂项目。你的邮件里有客户的诉求变更，Notion 里有项目的架构文档，GitHub 里有代码的提交记录，Slack 里有团队的争吵与妥协，Calendar 里密密麻麻排满了会议。
如果按照传统的 chunking 逻辑，这些极具时间跨度和逻辑关联的数据，会被切分成无数个平等的、没有血缘关系的文本块。当 Agent 试图回答“这个需求最初是怎么来的”时，它只能盲人摸象般地捡起几个相似度高的碎片，根本无法还原事情的全貌。
这就是第一重冲突：人类记忆是网状的、立体的、带有时间戳的，而机器的记忆是扁平的、孤立的。
“
反思 / 独特见解：
过去我们总在抱怨大模型“笨”，其实很多时候不是模型的理解能力不行，而是我们喂给它的上下文本身就是一团乱麻。没有结构的记忆，不叫记忆，叫信息垃圾场。在垃圾场里找线索，再聪明的脑子也会被逼疯。
OpenHuman：把你的数字生活压缩成一个“外脑”
**本段欲回答的核心问题：**OpenHuman 是如何将散落在各处的个人数据，转化为 AI 可以直接调用的结构化上下文的？
OpenHuman 给出的解法是：产品化。它不跟你谈底层索引的复杂算法，它直接伸手把你的数字生活捞过来。
数据的物理聚合与 OAuth 抓取
OpenHuman 的第一步，是打通你的各个 SaaS 壁垒。通过标准的 OAuth 授权，它会自动抓取你 Gmail、Notion、GitHub、Slack、Calendar、Drive 等服务中的数据。
这个操作的意义在于“强制收拢”。过去，这些数据是各自为政的信息孤岛。现在，OpenHuman 充当了一个超级管道，把散落的水流引入同一个水库。
Memory Tree 与 LLM Wiki 的生成逻辑
数据抓取下来后，OpenHuman 并没有把它们扔进黑盒，而是进行了一整套压缩、整理动作，最终写入一个被称为 Memory Tree 的结构中，并落成本地的 LLM Wiki，也就是一个 Obsidian Vault 格式的知识库。
应用场景推演：
假设你下周要和一个重要的客户开复盘会。在 OpenHuman 的体系中，系统不会只给你一堆邮件原文。它会自动在 Memory Tree 中梳理出这样一条线：上个月 Calendar 里的初次会面记录 -> 随后 Slack 里你和内部团队讨论方案的上下文 -> GitHub 里根据方案提交的代码库 -> 最后是 Gmail 里发给客户的交付物。
这个 LLM Wiki 的核心特征在于它的“双栖性”：人可以打开看，Agent 也可以读取。 对于人来说，它是一个极其强大的、自动更新的个人 Wiki；对于 Agent 来说，它就是最完美的上下文来源。
从 Wiki 到工作台的闭环
拥有了 LLM Wiki 后，OpenHuman 并没有止步于此。它在这个知识库之上，叠加了桌面 UI、语音交互、Meet agent（会议助手）、通知系统以及工具调用能力。
这样一来，它就彻底脱离了“聊天机器人”的范畴，变成了一个真正的个人 AI 工作台。它知道你最近在做什么项目，知道你和谁沟通过，知道哪些任务还没完成，知道哪些资料以后会被反复用到。
“
反思 / 学到的教训：
OpenHuman 给我最大的启发是：有时候最好的技术迭代，不是把模型参数做大，而是把用户的冷数据做热。Karpathy 之前的设想被很多人当成了极客玩具，但 OpenHuman 证明了，把个人知识库与 AI 助手直接绑定，才是个人 AI 真正的落地形态。它不是在替代你搜索，它是在替代你“回忆”。
OpenViking：为 Agent 打造的“虚拟文件系统”底座
**本段欲回答的核心问题：**当 Agent 需要处理极其复杂的逻辑和海量的并发调用时，为什么必须引入结构化的上下文数据库而不是简单的知识库？
如果说 OpenHuman 是为“人机协同”打造的，那么 OpenViking 的视角则完全倒向了“机器与机器的协同”或“极度纯粹的 Agent 运行”。OpenViking 做的事情更底层，它直指 Agent context database 的核心痛点。
告别扁平 Chunk：viking:// 虚拟文件系统
OpenViking 同样做 chunking 和 embedding，但在这一步之后，它走上了一条完全不同的路。它没有把向量结果扔进传统的索引池，而是把所有的资源、记忆、技能、会话，统一组织成了一套 viking:// 虚拟文件系统。
这个设计极其精妙，它赋予了 Agent 一种类似操作系统的文件浏览能力。
viking://
├── resources/ # 管理外部资料库（如文档、网页）
├── user/memories/ # 管理用户的长期偏好与历史记忆
├── agent/skills/ # 管理 Agent 自身掌握的工具与技能代码
└── session/ # 管理当前会话的实时上下文历史
应用场景推演：
假设你部署了一个基于 Claude Code 的编程 Agent。当它接到一个“重构支付模块”的指令时，它不会去海量的向量库里盲目检索。它会像程序员打开 IDE 一样，先去 viking://resources/ 里找支付相关的架构文档，然后去 viking://agent/skills/ 里确认自己有没有调用数据库的权限脚本，最后去 viking://session/ 里核对刚才用户是不是说过“不要改动订单表的结构”。
这种目录式的划分，让 Agent 的检索从“海底捞针”变成了“按图索骥”。
L0、L1、L2：上下文预算的极致控制
在 viking:// 文件系统内部，每一个节点并不是一坨庞大的文本，而是被精细地拆分成了三个层级：
-
L0 是摘要：用来快速判断相关性。 -
L1 是概览：用来判断结构和是否值得深入。 -
L2 是原文细节：需要时再读取。
操作示例与场景说明：
为什么需要这三层？因为大模型的上下文窗口无论多大，都有成本和注意力的极限。这就是所谓的“上下文预算”。
当 Agent 需要查找信息时，OpenViking 的检索机制会首先在所有节点的 L0（摘要）层进行 embedding 向量定位。这就好比你在图书馆找书，先看每本书的封面和内容提要。
如果 L0 判断某条数据无关，检索直接终止，极大地节省了算力。如果相关，Agent 才会向下深入到 L1（概览）层，查看具体的章节结构和逻辑脉络。只有在真正需要引用具体的数据表名或原始对话原话时，最耗费资源的 L2（原文细节）层才会被按需唤醒。
结合目录递归检索、rerank（重排序）、过滤机制，OpenViking 把最合适、最精炼的内容交给了 Agent。
“
反思 / 独特见解：
OpenViking 的 L0/L1/L2 设计，实际上是在教 Agent “如何读书”。我们人类在处理信息时天然会略读、精读、跳读，但过去的 RAG 架构强迫 AI 每次都必须把完整的 chunk 原文读一遍。OpenViking 把“记忆”从一堆扁平碎片，变成了 Agent 可以主动浏览、检索、压缩、更新的一套文件系统。这才是 Agent 记忆该有的样子。
图片来源：Unsplash
产品化体验 vs 基础设施化底座，到底该选谁？
**本段欲回答的核心问题：**面对同样的“上下文”痛点，这两种路线各自适用于什么业务场景？
理解了两者底层的逻辑，我们就不会再把它们混为一谈。它们都在解决“Agent 怎么获得长期、稳定、可维护的上下文”这个问题，但出牌的风格截然不同。
如何选择？
如果你是一个产品经理或独立开发者，想要立刻解决自己日常被各种 SaaS 工具割裂的痛苦，想要一个能记住你所有工作背景的桌面 AI 助手，OpenHuman 的产品化路径是直接的解法。它更靠近用户体验，所见即所得。
但如果你正在构建一个复杂的自动化工作流，比如一个能够自主排查线上报警、自动阅读源码、自主执行修复脚本的超级 Agent（例如基于 Claude Code 或 Codex 的进阶形态），那么 OpenViking 是你必须关注的底座。它更靠近 Agent 底座，它不提供好看的 UI，但它保证了你的 Agent 在运行 100 次循环后，依然不会因为上下文溢出而崩溃。
“
反思 / 独特见解：
很多时候我们在做技术选型，容易陷入“谁的功能多”的误区。OpenHuman 和 OpenViking 给我们上了一课：同一个痛点，往前走一步是产品，往底层走一步是基建。没有谁比谁高级，只有谁更契合你当前的系统架构。
实用摘要 / 操作清单
-
明确你的核心诉求：如果你需要的是“帮我记住工作琐事的 AI 助手”，关注 OpenHuman 类的产品化 Wiki 方案；如果你需要的是“让 Agent 在长期任务中不丢失上下文的后端”，研究 OpenViking 类的 context database。 -
重塑数据组织观念：停止将所有数据无脑切 chunk。对于个人知识，尝试构建 Memory Tree 并落地为本地可读的 Markdown 库；对于 Agent 记忆，尝试引入虚拟文件系统的目录隔离概念。 -
实施上下文预算管理：在开发 Agent 时，不要再一次性将全文塞入 Prompt。参考 OpenViking 的 L0/L1/L2 逻辑，先让模型看摘要，按需加载原文，有效控制 Token 消耗和注意力涣散。
一页速览
Agent 的长期记忆不能依赖单纯的“聊天历史追加”或“扁平的向量检索”。OpenHuman 通过 OAuth 接入个人全量 SaaS 数据，将其压缩整理为本地 LLM Wiki，打造了人机共用的记忆外脑，偏重产品体验。OpenViking 则将资源、记忆、技能、会话组织为 viking:// 虚拟文件系统，通过 L0(摘要)、L1(概览)、L2(原文)的三层架构实现精准的上下文预算控制，作为纯粹的 Context Database 服务于底层 Agent 架构。两者一个向上触达用户，一个向下扎根基建，共同指明了 AI 记忆演进的方向。
常见问答（FAQ）
Q1：OpenHuman 生成的 LLM Wiki 和我手动在 Obsidian 里写笔记有什么区别？
OpenHuman 的 LLM Wiki 是通过 OAuth 自动抓取你的 Gmail、Notion 等多源数据，经过 AI 压缩和整理后自动生成的。它不需要你手动维护，且其结构是为了让 Agent 能够更好地读取和引用而专门优化的。
Q2：OpenViking 的 viking:// 虚拟文件系统是真实存在于硬盘上的文件夹吗？
不是。它是一种逻辑上的组织形式，用于将原本扁平、混乱的向量数据块，按照资源、用户记忆、Agent 技能和会话历史进行目录级别的隔离和管理，方便 Agent 像浏览文件系统一样进行检索。
Q3：在 OpenViking 的检索中，如果 L0 摘要判断错了怎么办？
OpenViking 的检索并非只依赖 L0。L0 用于快速过滤大量无关数据以节省算力，在 L0 判断相关后，系统还会结合目录递归检索、rerank（重排序）和过滤机制，在 L1 和 L2 层面进行二次校验，确保最终交付给 Agent 的上下文是准确的。
Q4：我可以在自己的项目中同时使用这两种思路吗？
可以，而且它们并不冲突。你可以借鉴 OpenHuman 的思路，在前端为用户展示一个可视化的 LLM Wiki 增强体验；同时在后端借鉴 OpenViking 的思路，构建你的 Agent 专用的 Context Database，实现体验与底座的双重升级。
Q5：OpenViking 支持接入哪些 Agent 框架？
由于 OpenViking 定位为底层上下文基础设施，它适合作为各类具备长期运行能力的 Agent 后端，例如 OpenClaw、Hermes、Codex、Claude Code 或者是你自己研发的定制化 Agent 系统。
Q6：普通 RAG 和 OpenViking 的核心区别到底在哪里？
普通 RAG 是“切分-向量化-Top-k检索”，数据是扁平且孤立的；OpenViking 在向量化之前，先通过虚拟文件系统和 L0/L1/L2 分层对数据进行了结构化组织和预算控制，使检索过程从“盲目匹配”变成了“按目录层层递进的精准定位”。
Q7：OpenHuman 里的 Meet agent 是什么功能？
它是 OpenHuman 个人 AI 工作台的一个组成部分。结合其底层的 Memory Tree，Meet agent 能够在会议等场景中，基于你过往的文档、邮件和日程上下文，提供更具针对性的辅助，并将会议产生的新数据再次写回你的 LLM Wiki 中。
Q8：为什么说 OpenViking 更适合处理 Agent 的技能？
因为在 viking://agent/skills 目录下，Agent 的工具调用代码、API 文档等可以被结构化管理。当 Agent 遇到复杂任务时，它可以精准地在 L1 层查阅技能的使用逻辑，在 L2 层提取具体的代码细节，而不会与普通的聊天记录或外部资料混淆。
