给 AI Agent 装一个「会进化的大脑」：OpenViking 深度拆解

前两天分享 Hermes Agent，聊到 AI Coding 中的自进化话题时，有同学提到了 OpenViking。回来一查，这个项目已经在 GitHub 上攒了 36k+ Star，由字节跳动火山引擎 Viking 团队开源。它到底解决了什么问题？和 Hermes Agent 又是什么关系？这篇文章我们一次讲透。

一、从一场分享会说起：Agent 自进化的「最后一块拼图」

上周的技术分享会上，我们聊了 Hermes Agent------Nous Research 推出的那个号称「与你共同成长」的开源智能体框架。它最吸引人的地方在于内建了一套闭环学习机制：完成复杂任务后自动把解决步骤抽象成可复用的 Skill（技能），跨会话记住你的偏好和工作习惯，还能通过 GEPA 算法定期对已有技能做复盘优化。

讨论到 AI Coding 场景时，一个问题被抛了出来：Hermes 的技能和记忆，到底存在哪里？

这是个好问题。大多数 Agent 框架的做法是：记忆塞进一个向量数据库，技能写成 Markdown 文件丢在某个目录，项目知识又走另一套 RAG 管道。三套系统、三种格式、三份维护成本。当 Agent 需要同时调用「用户偏好 + 项目文档 + 历史经验」时，上下文窗口里塞满了从不同渠道拼凑来的碎片，Token 烧得飞快，效果还不一定好。

就在这时，有同学提到了 OpenViking。

它的定位一句话就能说清：专为 AI Agent 设计的自进化上下文数据库（Self-evolving Context Database） 。记忆、资源、技能，全部统一到一个 viking:// 虚拟文件系统里，Agent 用 ls、tree、find 就能浏览自己的「大脑」。

更有意思的是，OpenViking 的官方 Benchmark 里，Hermes Agent 接入它之后，长对话记忆准确率从 33.38% 飙升到 82.86% ，输入 Token 消耗最多下降 91%。

这就值得好好拆一拆了。

二、Agent 的上下文之痛：为什么我们需要一个「上下文数据库」

在深入 OpenViking 之前，先花点时间理解问题本身。因为只有真正痛过，才会明白这个项目为什么能在半年内拿到近 3 万 Star。

2.1 上下文碎片化：记忆、知识、技能各管各的

做过 Agent 开发的人都有体会：一个稍微复杂点的 Agent，上下文来源至少有三路------

用户记忆：用户的偏好、习惯、历史对话摘要，通常存在向量库里；
知识资源：项目文档、代码仓库、网页资料，走 RAG 管道，又是一套切片+索引；
技能经验：Agent 自己总结的操作流程、工具用法，可能写成 YAML 或 Markdown 丢在文件系统里。

三路上下文用三种方式存储、三种方式检索、三种方式更新。当 Agent 执行一个任务需要同时用到这三类信息时，开发者得自己写胶水代码把它们拼进 Prompt。拼少了信息不全，拼多了 Token 爆炸。

2.2 朴素 RAG 的天花板：切片是平的，世界是有结构的

传统 RAG 的做法是把文档切成固定大小的文本块，向量化后平铺存储。检索时按语义相似度取 Top-K。

这套方案在单文档问答场景下够用，但面对有结构的信息组织 （比如一个代码仓库、一套产品文档体系）就力不从心了。原因很简单：切片丢失了目录结构和上下文关系。你问「这个项目的认证流程是怎样的」，向量检索可能返回 auth.py 里的一个函数片段，但你真正需要的是从 README → docs/architecture.md → src/auth/ 这条完整的理解路径。

更致命的是，朴素 RAG 过于关注语义相关性，在需要兴趣泛化和探索的开放式场景中表现不佳。Agent 不是搜索引擎，它需要的不只是「最相关的 5 个片段」，而是「理解这个问题所需的完整上下文环境」。

2.3 长程任务的 Token 压力：截断就是丢信息

Agent 从单轮对话走向长周期任务后，每一轮执行都会给上下文窗口带来压力。一个涉及多工具调用、多步骤推理的 Coding 任务，上下文里可能同时包含：用户需求、项目结构、相关代码、工具输出、历史决策......

简单的做法是截断或压缩，但本质上是「丢卒保帅」------被截掉的信息可能恰恰是后续步骤需要的。而把所有东西都塞进去，不仅成本高昂，还会引入噪声，让模型在海量无关信息中迷失。

2.4 黑箱检索：出错了不知道为什么

从 DeepSeek 到 Manus 的爆火能看出一个趋势：AI 越强，用户越渴望白盒化体验------能看到它的思考与决策轨迹。

但传统 RAG 的检索链路是个黑箱。你问一个问题，它返回几个片段，你不知道它是怎么找到的、为什么选了这几个而不是那几个、检索过程中走过了哪些路径。结果不对时，你无法归因，无法调试，改进全靠猜。

2.5 记忆才是核心资产，但它需要一个「家」

最后一点，也是最根本的一点：模型本身是通用的，沉淀的记忆才是 Agent 的核心资产。

这不止包括用户的记忆，还包括 Agent 自身的经验------它在执行任务过程中积累的操作技巧、工具使用经验、踩过的坑、总结的方法论。这些东西如果能在开发初期就建设起来，就能形成「使用时间越长，体验越好」的复利效果。

但问题是：这些记忆存在哪里？怎么组织？怎么检索？怎么更新？怎么让多个 Agent 共享？

OpenViking 给出的答案是：给 Agent 造一个专门的上下文数据库。

三、OpenViking 是什么：一个「会进化的虚拟文件系统」

3.1 项目档案

先看基本信息：

维度	详情
全称	OpenViking: Self-evolving Context Database for AI Agents
出品方	字节跳动火山引擎 Viking 团队
开源时间	2026 年 1 月
开源协议	AGPLv3（主项目），ov_cli 和 examples 为 Apache 2.0
GitHub Star	29k+
技术栈	Rust（核心引擎）+ Python 3.10+（SDK/CLI）+ TypeScript（Web Studio）
学术基础	VLDB 2026 论文 VikingMem
支持部署	pip 安装、Docker、docker-compose、Helm

Viking 团队不是凭空做这个项目的。他们从 2019 年就开始做向量数据库 VikingDB，支撑字节内部全业务大规模使用；2024 年推出 Viking 知识库、Viking 记忆库；2025 年做了 AI 搜索和 vaka 知识助手；2025 年 10 月开源了 MineContext（主动式 AI 应用探索）；2026 年 1 月，把多年在上下文工程领域的积累浓缩成 OpenViking 开源出来。

所以这不是一个「蹭 Agent 热度」的玩具项目，而是一支在向量检索和上下文管理领域深耕了 7 年的团队的集大成之作。

3.2 一句话定位

OpenViking 把 Agent 的记忆、资源和技能统一组织成一个 viking:// 虚拟文件系统，让 Agent 像开发者翻文件一样用 ls、tree、find 浏览自己的上下文，同时通过分层加载、目录递归检索和会话自迭代实现「越用越聪明」。

这里有三个关键词需要展开：文件系统范式 、分层加载 、自迭代。它们构成了 OpenViking 的设计灵魂，我们一个一个拆。

四、核心设计一：文件系统范式------「记忆、资源、技能，皆为文件」

4.1 为什么是文件系统？

OpenViking 的设计深受业界前沿实践的启发：

Manus 提出「文件系统是上下文的终极形态」；
Claude Code 的成功验证了「文件系统 + Bash」的简洁方案在特定场景下超越复杂向量索引的潜力；
Anthropic 的 Skills 系统巧妙地以文件夹来组织能力模块。

这些实践共同指向一个结论：文件系统是组织上下文的一种极好方式。它有层级、有路径、有确定性的定位方式，开发者对它的心智模型已经刻在骨子里了。

但问题是，之前没有一个类似数据库的东西，能有效管理 Agent 所需的所有上下文并解决前述痛点。OpenViking 做的就是这件事：把文件系统的组织能力和数据库的管理能力结合起来。

4.2 viking:// 目录结构

在 OpenViking 中，所有上下文都映射到 viking:// 协议下的虚拟目录，拥有唯一的 URI。整体结构长这样：

csharp 复制代码

viking://
├── resources/                          # 全局资源：项目文档、仓库、网页等
│   └── my_project/
│       ├── docs/
│       │   ├── api/
│       │   └── tutorials/
│       └── src/
│
└── user/
    └── {user_id}/                     # 每个用户独立的空间
        ├── memories/                   # 记忆：偏好、习惯、经验
        │   └── preferences/
        │       ├── writing_style
        │       └── coding_habits
        ├── resources/                  # 私有资源
        │   └── private_project/
        ├── skills/                     # 技能：可复用的操作流程
        │   ├── search_code
        │   └── analyze_data
        └── peers/                      # 同伴：其他 Agent 或用户的共享上下文
            └── web-visitor-alice/

这个设计有几个精妙之处：

第一，统一了三类上下文的存储范式。 记忆、资源、技能不再是三套系统，而是同一个文件系统里的不同目录。Agent 需要什么，就去对应路径下找，逻辑清晰，维护简单。

第二，天然支持多租户和多用户隔离。 user/{user_id}/ 的目录结构让每个用户的记忆、资源、技能完全隔离。同时 resources/ 全局目录又可以存放共享资源，公私分离。

第三，确定性可达。 每个上下文条目都有唯一的 viking:// URI，Agent 可以精确地定位、引用、操作某条上下文，而不是依赖模糊的语义匹配。这对调试和可追溯性至关重要。

第四，技能即文件。 这一点和 Hermes Agent 的理念完美契合------Hermes 把技能抽象成 Skill 文件，OpenViking 把这些文件统一管理在 skills/ 目录下，Agent 可以像浏览代码库一样浏览自己的技能集合。

4.3 用文件操作管理上下文

有了文件系统，Agent 操作上下文的方式就变得极其直观：

bash 复制代码

ov ls viking://resources/                    # 列出所有资源
ov tree viking://resources/my_project -L 2  # 查看项目目录树
ov find "如何实现用户认证"                     # 语义搜索
ov grep "openviking" --uri viking://resources/.../docs  # 关键词搜索

ls 看结构，tree 看层级，find 做语义检索，grep 做关键词匹配。对开发者来说，这组命令的学习成本几乎为零。

但这里有个关键问题：文件系统是结构化的，语义检索是模糊的，两者怎么结合？答案就在 OpenViking 的第二个核心设计------目录递归检索。我们稍后展开。

五、核心设计二：L0/L1/L2 分层加载------「按需取深度，Token 省着花」

5.1 问题：一次性全量加载太贵

传统 RAG 的另一个问题是：检索到一个文档片段，就把完整内容塞进上下文。但很多时候，Agent 并不需要完整内容------它可能只需要知道「这个文档大概讲了什么」来判断要不要深入，或者只需要「核心要点」来做规划，只有在真正执行时才需要「完整细节」。

如果不管什么阶段都把完整原文塞进去，就是典型的「杀鸡用牛刀」，Token 浪费严重。

5.2 OpenViking 的解法：写入时自动分层

OpenViking 借鉴了业界前沿实践，在上下文写入时就自动将其处理为三个层级：

层级	名称	内容	典型 Token 量	用途
L0	摘要（Abstract）	一句话概括	~100 tokens	快速判断相关性
L1	概述（Overview）	核心信息 + 使用场景	~2k tokens	规划阶段决策
L2	详情（Details）	完整原始数据	原文长度	确有必要时深入读取

这个分层不是只对文件做的，每个目录也有自己的 L0/L1 层。结构长这样：

csharp 复制代码

viking://resources/my_project/
├── .abstract        # L0: ~100 tokens --- 这个项目是做什么的
├── .overview        # L1: ~2k tokens  --- 项目结构、核心模块、关键入口
└── docs/
    ├── .abstract    # L0: 文档目录的一句话摘要
    ├── .overview    # L1: 文档体系的结构和要点
    └── api/
        ├── auth.md       # L2: 完整内容，按需加载
        └── endpoints.md  # L2: 完整内容，按需加载

这个设计的精妙之处在于：Agent 在读取任何完整文件之前，就能通过目录的 L0/L1 判断这个方向对不对。

举个例子：Agent 接到一个任务「帮我给这个项目加一个微信登录功能」。它不需要把整个代码仓库读一遍，只需要：

读项目根目录的 .abstract（~100 tokens），确认这是个 Web 项目；
读根目录的 .overview（~2k tokens），了解项目结构，发现有 src/auth/ 目录；
读 src/auth/ 目录的 .abstract 和 .overview，了解现有认证机制；
只有在需要具体实现时，才去读 src/auth/login.py 的 L2 完整内容。

整个过程中，Token 消耗被控制在最小必要范围，而信息完整性丝毫没有损失------因为 L2 原文一直在那里，只是按需加载。

5.3 分层加载的实际效果

OpenViking 官方 Benchmark 给出了量化数据：接入 OpenViking 后，三个 Agent 的输入 Token 消耗分别下降了 34.3% 到 91.0% ，查询延迟下降了 58.45% 到 66.10%。

这个降幅是惊人的。91% 的 Token 节省意味着什么？意味着原来花 100 块钱才能完成的上下文供给，现在 9 块钱就够了。对于长期运行的 Agent 来说，这是实打实的成本下降。

六、核心设计三：目录递归检索------「先锁定方向，再精细探索」

6.1 传统向量检索的问题

传统向量检索的流程是：把查询向量化 → 在所有切片中计算相似度 → 返回 Top-K。这个流程有两个问题：

第一，缺乏全局视野。它不知道一个切片属于哪个目录、和哪些其他切片有关联。返回的结果可能是语义相关但语境断裂的碎片。

第二，在开放式场景中表现不佳。当查询意图模糊、需要探索时，纯语义相似度可能把 Agent 引向一个「局部最优但全局错误」的方向。

6.2 OpenViking 的目录递归检索策略

OpenViking 设计了一套创新的目录递归检索策略，深度融合了多种检索方式的优点。整个流程可以分为五步：

第一步：意图分析，生成多个检索条件。 不是简单地把用户查询直接向量化，而是先做意图分析，拆解出多个检索维度。比如用户问「这个项目的支付流程安全吗」，系统可能生成「支付流程」「安全机制」「代码实现」等多个检索条件。

第二步：向量检索，定位初始高分目录。 用生成的检索条件做向量搜索，但不是直接返回文件切片，而是先定位得分最高的目录。这一步的目标是「锁定大方向」------这个问题的答案大概率在哪个目录下面。

第三步：目录内二次检索，更新候选集合。 在定位到的高分目录下，做更精细的二次检索，把高相关的文件和子目录加入候选集合。

第四步：逐层递归，持续下钻。 如果候选目录下还有子目录，就递归重复上述二次检索步骤，逐层深入，直到找到最相关的具体文件。

第五步：返回携带完整上下文的结果。 最终返回的不是孤立的文本片段，而是带着目录路径、层级关系和周边上下文的完整结果。

这套策略的核心思想是：「先锁定高分目录，再精细探索内容」。它不仅能找到语义最匹配的片段，更能理解信息所在的完整语境，从而提升检索的全局性与准确性。

6.3 一个直观的对比

假设你有一个电商项目的代码仓库，Agent 问「订单退款流程是怎样的」。

传统 RAG ：可能返回 refund_service.py 里的一个函数片段，你看到的是几行代码，不知道它在整个退款流程中的位置，不知道上游是谁、下游是谁，也不知道有没有相关的文档说明。

OpenViking 目录递归检索：

先定位到 src/order/ 目录（高分目录）；
在 src/order/ 下二次检索，发现 refund/ 子目录和 docs/order-refund.md；
递归进入 refund/ 目录，找到 refund_service.py、refund_controller.py、refund_validator.py；
返回结果时，不仅包含这些文件的相关内容，还带着完整的目录路径和层级关系。

Agent 拿到的是一个结构化的理解路径，而不是一堆碎片。这对复杂任务的推理质量提升是显著的。

七、核心设计四：可观测检索轨迹------「黑箱变白盒，出错可追溯」

7.1 为什么可观测性很重要

前面提到，传统 RAG 的检索链路是个黑箱。结果不对时，你不知道是切片有问题、检索策略有问题、还是排序有问题。调试全靠猜，改进全靠试。

OpenViking 的组织方式是层次化虚拟文件系统，所有上下文都有唯一 URI，检索过程采用目录递归策略------这天然为可观测性提供了基础。

7.2 检索轨迹可视化

OpenViking 的每一次检索，都会完整保留目录浏览轨迹：从哪个根目录开始、经过了哪些子目录、在每个目录做了什么检索决策、最终选择了哪些文件。

这意味着：当一个检索结果看起来不对时，你可以清晰地看到 Agent 是沿着哪条路径找到这个结果的，是在哪个目录做了错误的转向，还是在某个环节漏掉了关键信息。

这种「白盒化」的检索体验，对开发者来说价值巨大。你不再需要猜测「为什么 Agent 会引用这个文件」，而是可以直接看到它的「思考路径」，然后针对性地优化目录结构、检索策略或内容质量。

OpenViking 还提供了 Web Studio 可视化控制台，可以在浏览器中直观地查看目录结构、检索轨迹和分层内容。不需要安装，打开就能用。

八、核心设计五：会话自迭代------「Agent 越用越聪明」

这是 OpenViking 最「性感」的特性，也是它和 Hermes Agent 理念最契合的地方。

8.1 自迭代的闭环机制

OpenViking 内置了一套记忆自迭代闭环 。在每次会话结束时，通过 session.commit() 主动触发，系统会异步做两件事：

第一，提取用户偏好记忆。 分析本次会话中的用户行为、反馈和表达习惯，提取出用户的偏好信息，更新到 viking://user/{user_id}/memories/preferences/ 目录下。

比如用户在多次对话中都要求「代码注释用中文」「函数命名用小驼峰」「回复简洁一点」，系统就会把这些偏好沉淀成长期记忆。下次对话时，Agent 不需要用户再重复说明，就能自动按照这些偏好来执行。

第二，提取 Agent 经验记忆。 分析本次任务的执行过程和结果，提取操作技巧、工具使用经验、踩过的坑、有效的解决路径等，更新到 Agent 的记忆目录下。

比如 Agent 在本次任务中发现「用 grep -r 搜索代码比语义检索更快定位到具体函数」「这个项目的测试需要先启动 Docker 容器」，这些经验就会被沉淀下来。下次遇到类似任务时，Agent 可以直接复用这些经验，而不是重新探索。

8.2 自迭代 = 复利效应

这套机制的核心价值在于复利效应：

使用第 1 天：Agent 从零开始，什么都要探索；
使用第 7 天：已经沉淀了一批用户偏好和基础经验，常见任务的执行效率明显提升；
使用第 30 天：记忆库已经相当丰富，Agent 对用户的工作习惯、项目的结构特点、常见问题的解决方案都了如指掌，很多任务可以「直接上手」而不需要反复确认；
使用第 90 天：这个 Agent 已经成为「最懂你」的工作伙伴，它的记忆和经验本身就是一种不可替代的资产。

这就是「自进化」的真正含义------不是模型本身在变，而是 Agent 的上下文在持续积累和优化，让它在同样的模型能力下，表现得越来越聪明。

8.3 和 Hermes Agent 的协同

说到这里，OpenViking 和 Hermes Agent 的关系就很清楚了：

Hermes Agent 负责「学习和进化」的策略层------它决定从任务中提取什么技能、怎么优化技能、什么时候调用技能；
OpenViking 负责「学习和进化」的存储和检索层------它把 Hermes 生成的技能、积累的记忆、引用的资源统一管理起来，提供高效的检索和按需加载。

两者是天然的互补关系。Hermes 的技能文件可以直接存入 OpenViking 的 skills/ 目录，Hermes 的记忆可以存入 memories/ 目录，项目资源可以存入 resources/ 目录。当 Hermes 需要调用这些上下文时，通过 OpenViking 的目录递归检索和分层加载，以最低的 Token 成本获取最相关的信息。

官方 Benchmark 数据也印证了这一点：Hermes Agent 原生记忆的 LoCoMo 准确率只有 33.38%，接入 OpenViking 后飙升到 82.86%。这不是模型变聪明了，而是上下文管理变高效了。

九、技术架构解析：Rust + Python 的混合引擎

9.1 整体架构

OpenViking 是一个 Python + Rust 的多组件项目，整体可以分为四层：

arduino 复制代码

┌─────────────────────────────────────────────────────────┐
│                    应用层（Application）                    │
│  VikingBot 对话框架 · Web Studio 可视化 · Agent 集成插件    │
├─────────────────────────────────────────────────────────┤
│                    接口层（Interface）                      │
│  Python SDK · ov CLI · MCP Server · LangChain 集成        │
├─────────────────────────────────────────────────────────┤
│                    引擎层（Engine）                         │
│  解析引擎 · 检索引擎（目录递归检索）· 记忆引擎（自迭代）      │
├─────────────────────────────────────────────────────────┤
│                    存储层（Storage）                        │
│  AGFS 虚拟文件系统（L0/L1/L2 + 多媒体 + 关联）              │
│  + 向量索引 + 文档存储 + 目录元数据                          │
└─────────────────────────────────────────────────────────┘

9.2 核心组件

Rust 核心引擎（crates/） OpenViking 的核心检索引擎用 Rust 编写，提供高性能的文件系统式检索。Rust 的内存安全和并发性能，保证了在大规模上下文场景下的检索效率和稳定性。其中 ov_cli 组件以 Apache 2.0 协议开源，可以更宽松地引用。

Python SDK（sdk/、openviking/） 上层 Python 包暴露 API，提供 SyncOpenViking 等客户端类，方便开发者在 Python 项目中集成。Python 是 AI 开发的主流语言，这个选择大大降低了集成门槛。

命令行工具（openviking_cli/、crates/ov_cli） 提供 openviking-server（服务端管理）和 ov（客户端操作）两套命令行工具。ov 支持 ls、tree、find、grep、add-resource 等操作，是日常使用的主要入口。

Web Studio（web-studio/） TypeScript 编写的可视化控制台，提供目录浏览、语义搜索、检索轨迹查看、多 Agent 管理等功能。有在线 Demo 版本，不需要安装就能体验。

VikingBot（bot/） 构建在 OpenViking 之上的 AI Agent 框架，提供带记忆的对话能力。安装 openviking[bot] 后，用 openviking-server --with-bot 启动，另开终端 ov chat 就能开聊。

Agent 集成（agent-plugins/、integrations/） 提供对 Claude Code、Codex、OpenClaw、Hermes、Cursor、TRAE、OpenCode 等主流 Agent 的集成插件，以及 LangChain/LangGraph 集成和 MCP 客户端支持。

9.3 存储架构

存储层采用混合存储架构：

AGFS（Agent File System）：基于 Rust 开发的高性能虚拟文件系统，将非结构化上下文转为结构化目录树，存储 L0/L1/L2 三层内容、多媒体文件和关联关系；
向量索引：用于语义检索的向量存储，支持目录级别的向量索引；
文档存储：存储原始文档和解析后的内容；
目录元数据：存储目录结构、层级关系、URI 映射等元数据。

这种混合架构兼顾了结构化管理（文件系统）和语义检索（向量索引）的优势，是 OpenViking 能同时提供「确定性定位」和「模糊语义搜索」的基础。

十、实战体验：三步跑通 OpenViking

说了这么多理论，来看看实际怎么用。OpenViking 的安装和使用非常简洁，三分钟就能跑通。

10.1 安装

bash 复制代码

pip install openviking --upgrade
# 可选：安装 VikingBot 对话框架
pip install "openviking[bot]"

要求 Python 3.10 或更高版本。

10.2 初始化和启动

bash 复制代码

# 交互向导：选择 Provider（火山引擎/OpenAI/Kimi/GLM/Ollama），填写 API Key
openviking-server init

# 校验配置：检查配置文件、Python 版本、Provider 连通性、磁盘空间
openviking-server doctor

# 启动服务（后台运行）
nohup openviking-server > openviking.log 2>&1 &

init 命令会引导你完成 Provider 配置，并写入 ~/.openviking/ov.conf。支持火山引擎（推荐，成本低性能好）、OpenAI、Codex OAuth、Kimi、GLM 和本地 Ollama。对于 Ollama，它还能自动检测和安装运行时，并拉取适合你硬件的模型。

10.3 喂资源、查记忆

服务起来后，用 ov 客户端操作：

bash 复制代码

# 查看服务状态
ov status

# 添加资源（支持 GitHub 仓库、网页、本地文件/目录）
ov add-resource https://github.com/volcengine/OpenViking --wait

# 列出所有资源
ov ls viking://resources/

# 查看目录树
ov tree viking://resources/volcengine -L 2

# 语义搜索
ov find "what is openviking"

# 关键词搜索
ov grep "openviking" --uri viking://resources/volcengine/OpenViking/docs/en

--wait 参数会等待语义处理完成后再返回。不加的话，资源添加后语义处理是异步的，需要等一会儿再 find。

10.4 Python SDK 用法

如果你想在自己的 Agent 项目中集成，可以用 Python SDK：

python 复制代码

import openviking as ov

# 初始化客户端
client = ov.SyncOpenViking(path="./data")
client.initialize()

# 添加资源
add_result = client.add_resource(
    path="https://raw.githubusercontent.com/volcengine/OpenViking/main/README.md"
)
root_uri = add_result['root_uri']

# 等待语义处理完成
client.wait_processed()

# 获取分层摘要
abstract = client.abstract(root_uri)   # L0
overview = client.overview(root_uri)    # L1

# 语义搜索
results = client.find("what is openviking", target_uri=root_uri)
for r in results.resources:
    print(f"  {r.uri} (score: {r.score:.4f})")

# 读取完整内容（L2）
content = client.read("viking://resources/.../README.md")

client.close()

10.5 Docker 部署

生产环境推荐用 Docker：

bash 复制代码

git clone https://github.com/volcengine/OpenViking.git
cd OpenViking
docker compose up -d

官方 Docker 镜像默认捆绑 VikingBot，启动后同时运行服务端和控制台 UI。也支持 Helm 部署到 Kubernetes 集群。

十一、Benchmark 数据解读：数字不会说谎

OpenViking 0.3.22 版本在两个权威基准上做了评估：LoCoMo （长对话用户记忆）和 tau2-bench（多轮 Agent 任务）。我们来看看数据。

11.1 LoCoMo：长对话用户记忆

LoCoMo 是一个衡量 Agent 在长对话中记住用户偏好和历史信息能力的基准。OpenViking 测试了三个主流 Agent 接入前后的表现：

Agent	原生记忆准确率	接入 OpenViking 后	提升幅度
OpenClaw	24.20%	82.08%	+57.88pp
Hermes	33.38%	82.86%	+49.48pp
Claude Code	57.21%	80.32%	+23.11pp

几个值得注意的点：

第一，接入 OpenViking 后，三个 Agent 的准确率都达到了 80-83% 的区间，说明 OpenViking 的上下文管理能力可以把不同 Agent 的记忆表现拉到同一个高水平线上。

第二，原生记忆越弱的 Agent，提升幅度越大。OpenClaw 从 24% 提升到 82%，几乎是翻了三倍多；Hermes 从 33% 提升到 83%，也提升了近 50 个百分点。这说明对于记忆能力较弱的 Agent，OpenViking 的「外挂大脑」效果尤其明显。

第三，即使是 Claude Code 这种原生记忆已经不错的 Agent，接入后也能提升 23 个百分点，说明 OpenViking 的分层加载和目录递归检索确实能带来增量价值，而不只是「替代了原有记忆系统」。

除了准确率，还有两个关键指标：

输入 Token 消耗下降 34.3% - 91.0%：分层加载的效果直接体现在 Token 成本上；
查询延迟下降 58.45% - 66.10%：目录递归检索先锁定大方向再精细探索，比全库向量扫描快得多。

11.2 tau2-bench：多轮 Agent 任务

tau2-bench 是一个衡量 Agent 在多轮复杂任务中表现的基准，包含零售（Retail）和航空（Airline）两个场景：

场景	无记忆任务成功率	有经验记忆后	提升幅度
Retail（零售）	70.94%	77.81%	+6.87pp
Airline（航空）	54.38%	66.25%	+11.87pp

这个测试的控制变量是「同一个 LLM，有没有经验记忆」。结果显示，仅仅是把之前任务的经验沉淀下来并在后续任务中复用，就能带来 7-12 个百分点的任务成功率提升。

这就是「自进化」的量化价值------经验复用本身就能提升 Agent 的任务表现，而且随着经验积累越来越多，这个提升会持续放大。

11.3 评估配置说明

记忆评估使用了 Doubao 2.0 Pro 作为 VLM（视觉语言模型，用于多模态内容理解）和 Doubao-embedding-vision-251215 作为 Embedding 模型。完整的评估结果和复现脚本在项目的 benchmark/ 目录下，可以自行复现验证。

十二、AI Coding 场景：OpenViking 能为编码 Agent 带来什么

回到文章开头的场景------我们是在聊 AI Coding 中的自进化时提到 OpenViking 的。那它具体能为编码 Agent 带来什么？

12.1 代码仓库的分层理解

OpenViking 支持接入 GitHub 代码仓库，并自动生成目录树、索引和分层上下文。一个代码仓库被接入后，会被自动处理为：

L0（项目摘要）：一句话说明这个项目是做什么的、用什么技术栈；
L1（项目概述）：核心模块划分、目录结构说明、关键入口文件、技术架构要点；
L2（代码详情）：每个文件的完整代码，按需读取。

每个子目录也有自己的 L0/L1。这意味着 Coding Agent 在理解一个陌生项目时，不需要把整个仓库读一遍，而是可以「从宏观到微观」逐层深入，Token 消耗大幅降低。

12.2 跨会话的编码偏好记忆

每个开发者都有自己的编码习惯：命名风格、注释语言、代码格式化偏好、测试框架选择、Git 提交规范......传统 Coding Agent 每次对话都要重新适应，或者靠 .cursorrules 之类的配置文件手动维护。

OpenViking 的会话自迭代机制可以自动从历史对话中提取这些偏好，沉淀到 memories/preferences/ 目录下。下次对话时，Agent 自动加载这些偏好，不需要用户重复说明。

更重要的是，这些偏好是动态进化的------如果用户的习惯变了（比如从用 pytest 转到用 unittest），系统会从新的对话中捕捉到变化并更新记忆，而不是固守旧偏好。

12.3 编码经验的沉淀和复用

这是最有价值的部分。一个 Coding Agent 在帮你修 Bug、加功能、重构代码的过程中，会积累大量「项目特定」的经验：

这个项目的 Bug 通常出现在哪些模块？
加新功能时需要同步修改哪些文件？
这个项目的测试怎么跑？需要什么环境？
部署流程是怎样的？有哪些常见的坑？
代码审查时通常关注哪些点？

这些经验如果只存在于单次对话中，下次就忘了。但通过 OpenViking 的自迭代机制，它们会被沉淀到 Agent 的经验记忆中，下次遇到类似任务时自动复用。

举个具体的例子：Agent 第一次帮你给项目加一个新 API 接口，它需要探索项目结构、找到路由定义、理解认证机制、学习测试写法、搞清楚部署流程------这可能需要几十轮交互。但当它把这次经验沉淀下来后，第二次加接口时，它已经知道「路由在 src/routes/、认证用 JWT、测试用 pytest、部署走 GitHub Actions」，可能几轮交互就搞定了。

这就是经验复用的力量，也是 AI Coding 从「一次性工具」走向「长期合作伙伴」的关键。

12.4 多 Agent 协作的共享上下文

在复杂的 Coding 任务中，可能需要多个 Agent 协作：一个负责前端、一个负责后端、一个负责测试、一个负责部署。每个 Agent 都需要理解项目的整体结构和各自的模块细节。

OpenViking 的 viking:// 文件系统天然支持多 Agent 共享上下文。所有 Agent 都连接同一个 OpenViking 服务，访问同一份项目资源，但各自维护自己的记忆和技能。前端 Agent 可以在 memories/ 下记录自己的 UI 设计偏好，后端 Agent 可以记录自己的 API 设计经验，而它们共享同一份 resources/ 下的项目文档和代码。

这种「共享资源 + 独立记忆」的模式，为多 Agent 协作提供了坚实的上下文底座。

十三、适用场景与局限：什么时候该用 OpenViking

13.1 强烈推荐使用的场景

给编码 Agent 加跨会话长期记忆：如果你在用 Claude Code、Codex、Cursor、TRAE 等编码 Agent，希望它能记住你的编码习惯、项目经验和历史决策，OpenViking 是目前最成熟的方案之一。
搭建私有 RAG 知识库：如果你厌倦了传统 RAG 的碎片化切片和黑箱检索，希望知识库有清晰的目录结构、可观测的检索轨迹和分层加载能力，OpenViking 提供了全新的范式。
多 Agent 协作的共享上下文底座：如果你在构建多 Agent 系统，需要一个统一的上下文管理层来协调不同 Agent 的记忆和知识，OpenViking 的文件系统范式天然适合。
需要「自进化」能力的 Agent：如果你希望你的 Agent 能从每次任务中学习、沉淀经验、越用越聪明，OpenViking 的会话自迭代机制提供了开箱即用的闭环。
对 Token 成本敏感的长周期任务：如果你的 Agent 需要处理大量上下文、运行很长时间，分层加载带来的 30-90% Token 节省是实打实的成本下降。

13.2 可能不太适合的场景

极简单轮问答：如果你的应用只是一个单轮 FAQ 机器人，不需要记忆、不需要复杂推理、不需要跨会话学习，传统 RAG 可能更轻量。
对 AGPL 协议敏感的商业产品 ：OpenViking 主项目采用 AGPLv3 协议，如果你的产品需要闭源商用且不希望开源自己的代码，需要仔细评估协议合规性。不过 ov_cli 和 examples 是 Apache 2.0，可以更宽松地使用。
完全离线且无 GPU 的环境：OpenViking 需要 VLM 和 Embedding 模型支持，虽然可以用本地 Ollama，但如果完全没有 GPU 且无法连接任何模型服务，运行会比较困难。
超大规模（百万级文件）的极端场景：OpenViking 目前还在快速迭代中，对于超大规模的极端场景，可能需要等待分布式部署能力更加成熟（自管理版已经支持分布式部署）。

13.3 和传统方案的对比

维度	传统 RAG	纯文件系统	OpenViking
上下文组织	扁平切片	目录结构	虚拟文件系统 + 分层
检索方式	纯向量相似度	路径定位 + 关键词	目录递归检索（向量+结构）
加载策略	全量加载	全量读取	L0/L1/L2 按需加载
可观测性	黑箱	白盒但无检索轨迹	白盒 + 完整检索轨迹
自进化	无	无	会话自动沉淀记忆
多 Agent 共享	需自行实现	可共享但无语义检索	天然支持
Token 效率	低	低	高（节省 30-90%）

十四、生态与未来：OpenViking 的版图正在展开

14.1 丰富的 Agent 集成

OpenViking 目前已经支持了几乎所有主流 Agent 的集成：

编码 Agent：Claude Code、Codex、Cursor、TRAE / TRAE CN、OpenCode、OpenClaw
通用 Agent：Hermes、pi、Agent Plugins 1.0
框架集成：LangChain / LangGraph、MCP 客户端

这意味着无论你在用哪个 Agent，都可以相对低成本地接入 OpenViking 作为上下文底座。集成方式通常是注入 OpenViking recall 到 Agent 的上下文中，并自动提交会话记忆。

14.2 OpenViking Helper：桌面控制台

OpenViking 还推出了桌面端控制台 Helper（Beta），支持 macOS 和 Windows：

可视化本地 Agent 配置：自动检测 OpenViking CLI、Claude Code、Codex、Cursor、Trae、OpenCode，然后配置支持的插件、MCP、Hook 和 CLI 集成；
会话轨迹检查：解析 Claude Code、Codex 和 Trae 的会话，展示 OpenViking recall、Prompt 注入、MCP 调用、捕获和提交事件；
本地记忆和技能管理 ：查看本地记忆/规则文件和 SKILL.md 技能，然后同步到 OpenViking。

这大大降低了非专业开发者的使用门槛。

14.3 商业版本：SaaS + 自管理

开源版功能完整、无功能阉割、无需账号、无需激活密钥，可以直接在生产环境使用。在此基础上，火山引擎还提供了两个商业版本：

托管 SaaS：运行在火山引擎上，个人版免费试用（最多 50 个文件），企业版支持多用户上下文管理、团队协作和权限、企业 SLA。海外版将通过 BytePlus 提供；
自管理版：运行在你自己的环境中，数据不出域。支持在线部署（BYOC）和完全离线部署（气隙环境，适合监管行业），在开源版基础上增加了分布式部署和官方支持。

这种「开源完整 + 商业增值」的模式，既保证了社区的活力，又为企业用户提供了可靠的商业支持。

14.4 学术基础：VikingMem 论文

OpenViking 开源了 VikingMem 论文中描述的核心能力的子集。这篇论文《VikingMem: A Memory Base Management System for Stateful LLM-based Applications》已被 VLDB 2026 接收。VLDB 是数据库领域的顶级学术会议，能被接收说明 OpenViking 的技术方案得到了学术界的认可。

这也意味着 OpenViking 不是一个「工程拼凑」的项目，而是有扎实的学术研究支撑的。论文中的更多核心能力可能会在后续版本中逐步开源。

14.5 合作伙伴生态

OpenViking 已经和多个开源项目建立了合作关系，共同构建上下文数据生态：

deer-flow：开源长周期 SuperAgent 框架；
NoKV：AI 原生分布式文件系统；
loopx：轻量级循环工程状态内核；
Hermes Agent：与你共同成长的 Agent。

这个生态还在快速扩张中。随着越来越多的 Agent 框架和基础设施项目接入 OpenViking，它有可能成为 Agent 上下文管理的事实标准。

十五、写在最后：上下文工程，Agent 时代的新基础设施

回到文章开头的那个问题：Hermes 的技能和记忆，到底存在哪里？

现在答案很清楚了：在 OpenViking 之前，这个问题没有好的答案------记忆塞向量库、技能写文件、知识走 RAG，三套系统各自为政。而 OpenViking 给出了一个优雅的统一方案：全部存在一个 viking:// 虚拟文件系统里，用文件系统的范式管理，用数据库的能力检索，用自迭代的机制进化。

这背后是一个更大的趋势：上下文工程（Context Engineering）正在成为 Agent 时代的新基础设施。

大模型的能力在快速提升，但模型本身是通用的、无状态的。真正让一个 Agent 变得「聪明」「好用」「不可替代」的，是它的上下文------它记住了什么、知道什么、能做什么、经历过什么。这些上下文的组织、管理、检索和进化，就是上下文工程要解决的问题。

OpenViking 做的事情，本质上是给 Agent 造了一个「大脑」：

文件系统范式是大脑的记忆结构------信息分门别类、层次分明；
分层加载是大脑的注意力机制------需要多少取多少，不浪费认知资源；
目录递归检索是大脑的联想能力------从一个点出发，沿着关联路径找到完整答案；
可观测检索轨迹是大脑的内省能力------能回顾自己的思考过程，发现哪里走错了；
会话自迭代是大脑的学习能力------从每次经历中提取经验，越用越聪明。

当这个「大脑」和 Hermes Agent 这样的「学习策略引擎」结合起来时，就形成了一个完整的自进化闭环：Hermes 决定学什么、怎么学，OpenViking 负责存下来、找出来、用起来。

这也是为什么在 AI Coding 的自进化话题中，OpenViking 会被反复提及------它不是自进化的「策略」，而是自进化的「地基」。没有一个好的上下文数据库，自进化就只是空中楼阁。

OpenViking 目前还在快速迭代中（GitHub 上 2000+ commits、200+ issues、450+ PRs，活跃度极高），很多能力还在演进。但它已经展示了一个清晰的方向：Agent 的上下文管理，应该像数据库一样专业、像文件系统一样直观、像生命一样自进化。

如果你在做 AI Agent、在折腾 RAG、在给 Coding Agent 加记忆、在探索自进化的可能性，OpenViking 值得你花一个下午跑一跑、试一试。也许它就是你一直在找的那块「拼图」。

参考链接

GitHub 仓库：github.com/volcengine/...

官方网站：openviking.ai

在线 Demo：studio.openviking.ai

文档中心：docs.openviking.ai

VikingMem 论文：arXiv:2605.29640

火山引擎产品页：www.volcengine.com/product/ope...

全文约 6500 字。如果你觉得这篇文章有帮助，欢迎分享给更多对 AI Agent 感兴趣的朋友。有任何问题或想法，也欢迎在评论区交流。

✍️ 每天追踪 GitHub Trending，更多内容可关注公众号「AI Agent 赛道技术拆解」。