企业官网建设流程全解析

P.S. 无意间发现了一个巨牛的人工智能教程，非常通俗易懂，对AI感兴趣的朋友强烈推荐去看看， 传送门https://blog.csdn.net/H1727548

先说个扎心的事。

上周我让 Agent 帮我改代码，改到一半我随口补了一句："以后注释都用中文写。"它答应得可痛快了。今天我一打开项目，好家伙，满屏英文注释，工整得像给美国人写的作业。它不光忘了我说过啥，还忘了自己答应过啥。

那一刻我悟了：大模型的记性，可能还不如我家金鱼。唯一的区别是，金鱼不会烧我的 Token。

今天聊的 OpenViking，就是专门来治这个病的：一个给 AI Agent 用的"会进化的大脑"。字节火山引擎 Viking 团队出品，GitHub 上已经 29k+ Star，主打一个"让 Agent 记住事"。官方 Benchmark 里，Hermes Agent 接上它之后，长对话记忆准确率从 33.38% 干到 82.86%，输入 Token 消耗最多降 91%。

1. 先聊聊这个让人破防的 AI 健忘症

1.1 记忆、知识、技能，三套系统各管各的

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

用户记忆，你的偏好和习惯，塞在向量数据库里；知识资源，项目文档和代码仓库，走 RAG 管道，又是一套切片加索引；技能经验，Agent 自己总结的操作流程，写成 Markdown 丢在文件系统的某个角落。

三套系统、三种格式、三份维护成本。你说它是三权分立吧，它分的是记忆、知识和技能；你说它是三国演义吧，最后掉头发的是你自己。

等 Agent 干活需要同时调用这三类信息时，开发者就得自己写胶水代码把它们拼进 Prompt。拼少了，信息不全，Agent 睁眼瞎；拼多了，Token 爆炸，你能听见钱包在哭。

1.2 朴素 RAG：切片切的是上下文，不是菜

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

单文档问答还好说。一旦面对有结构的信息，比如一个代码仓库、一套产品文档，它就露怯了。

你问"这个项目的认证流程是啥"，向量检索可能给你翻出来 auth.py 里的一个函数片段。看着没毛病，但你要的是从 README 到 docs/architecture.md 再到 src/auth/ 这条完整的理解路径。它给你的是碎片，拼图得你自己来。

就像你去餐厅点了一盘宫保鸡丁，服务员端上来一颗花生米，说这是这道菜的核心元素。没毛病，但我要的是一盘菜啊。

更致命的是，RAG 太执着于"语义相关"。Agent 不是搜索引擎，它需要的不是"最相关的 5 个片段"，而是"理解这个问题所需的完整上下文"。这俩的区别，大概就是"看过菜谱"和"会做饭"的区别。

1.3 Token 焦虑症

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

简单的做法是截断或压缩。但截断的本质就是丢卒保帅，你永远不知道被丢的那个卒，是不是下一盘棋的关键。

全塞进去呢？成本高不说，还会引入噪声。让模型在海量无关信息里找重点，相当于让它在早高峰地铁里找人，找得到，但得看缘分。

1.4 黑箱检索：它说找着了，你也不知道咋找的

从 DeepSeek 到 Manus 的爆火能看出一个趋势：AI 越强，用户越想要白盒体验，能看见它的思考轨迹和决策过程。

但传统 RAG 的检索链路是纯黑箱。你问一个问题，它甩回来几个片段。你不知道它怎么找到的、为什么选这几个、检索过程走了哪条路。结果不对的时候，你没法归因、没法调试，改进全靠许愿。

这种体验跟我家用扫地机器人一模一样：它扫没扫干净我不知道，它卡在哪儿我也不知道，它半夜自己跑起来的声音倒是听得清清楚楚。

2. OpenViking 到底是啥

2.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 团队不是来蹭 Agent 热度的。人家从 2019 年就开始做向量数据库 VikingDB，支撑字节内部全业务大规模使用；2024 年推出知识库和记忆库；2025 年做 AI 搜索和知识助手；2025 年 10 月开源了 MineContext；2026 年 1 月把多年积累浓缩成 OpenViking 开源。

说白了，这是一支在向量检索和上下文管理领域深耕了 7 年的团队。7 年啊兄弟们，我 7 年前立的减肥 flag 到现在还立着，人家已经迭代出一整条产品线了。

2.2 一句话定位

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

翻译成人话：以前 Agent 的记忆是散落三处的便利贴，现在给它一个整整齐齐的文件夹，还带自动整理功能。

3. 核心设计一：万物皆文件

3.1 为什么是文件系统

这个思路其实不少大佬提过：Manus 说文件系统是上下文的终极形态；Claude Code 证明了"文件系统 + Bash"这套简单方案在某些场景下比复杂向量索引还好使；Anthropic 的 Skills 系统也用文件夹组织能力模块。

道理很简单：文件系统有层级、有路径、有确定性的定位方式。程序员对它的心智模型已经刻进骨头里了，你让他用 ls 找东西，他比用地图导航还熟练。

但问题是，之前没有一个类似数据库的东西，能把 Agent 需要的所有上下文都管起来。OpenViking 干的就是这件事：把文件系统的组织能力，和数据库的管理能力，焊在一起。

3.2 viking:// 目录长啥样

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 把技能抽象成 Skill 文件，OpenViking 把它们统一管在 skills/ 目录下，Agent 可以像浏览代码库一样浏览自己的技能集合。

3.3 用文件命令管记忆

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 做关键词匹配。对开发者来说，这组命令的学习成本约等于零。

别的项目教你要学新 API，OpenViking 说你就当自己还在用 Linux。这波操作，我愿称之为：程序员的舒适区，AI 的记忆宫殿。

4. 核心设计二：L0/L1/L2 分层加载

4.1 问题：全量加载太贵

传统 RAG 的另一个毛病：检索到一个文档片段，就把完整内容塞进上下文。

但很多时候，Agent 根本不需要完整内容。它可能只需要知道这文档大概讲了啥，来判断要不要深入；或者只要核心要点来做规划；只有真正动手的时候，才需要完整细节。

不管什么阶段都塞原文，就是典型的杀鸡用牛刀。牛刀倒是不贵，贵的是 Token。

4.2 解法：写入时自动分层

OpenViking 在上下文写入的时候就自动分成三层：

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

这分层不止对文件做，每个目录也有自己的 L0/L1 层：

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 接到任务"给这个项目加一个微信登录功能"。它不需要把整个代码仓库读一遍，只需要：

1. 读项目根目录的 .abstract（约 100 tokens），确认这是个 Web 项目；
2. 读根目录的 .overview（约 2k tokens），发现有 src/auth/ 目录；
3. 读 src/auth/ 目录的 .abstract 和 .overview，了解现有认证机制；
4. 只有真正动手时，才去读 src/auth/login.py 的 L2 完整内容。

整个过程 Token 消耗被控制在最小必要范围，信息完整性一点没损失，因为 L2 原文一直在那儿，按需加载。

这就像逛商场：先看楼层导览图决定去几楼，再到楼层里看品牌分布，最后才进店试衣服。而不是一进门就把整栋楼每家店的库存全背下来。

4.3 省下来的都是真金白银

官方 Benchmark 显示：接入 OpenViking 后，三个 Agent 的输入 Token 消耗分别下降 34.3% 到 91.0%，查询延迟下降 58.45% 到 66.10%。

91% 是什么概念？原来花 100 块钱才能喂饱的上下文，现在 9 块钱就够了。省下的 91 块，够你请同事喝一个月的奶茶，然后在团建时听他夸你这 Agent 不错。

5. 核心设计三：目录递归检索

5.1 传统向量检索的两个毛病

传统向量检索的流程：查询向量化，全切片算相似度，返回 Top-K。这流程有两个问题。

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

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

打个比方：你在迷宫里找出口，传统 RAG 给你指了个"当前最像出口的方向"，结果那是条死胡同，还特亮堂。

5.2 五步检索法

OpenViking 的目录递归检索融合了多种检索方式的优点，流程分五步：

1. 意图分析，生成多个检索条件。比如问"这个项目的支付流程安全吗"，系统可能生成"支付流程"“安全机制”"代码实现"等多个检索条件。
2. 向量检索，定位初始高分目录。先锁定大方向，答案大概率在哪个目录下。
3. 目录内二次检索，更新候选集合，把高相关的文件和子目录加进候选。
4. 逐层递归，持续下钻。候选目录下还有子目录，就递归重复上一步，直到找到最相关的具体文件。
5. 返回携带完整上下文的结果。最终返回的不是孤立片段，而是带着目录路径、层级关系和周边上下文的完整结果。

核心思想一句话：先锁定高分目录，再精细探索内容。先定大方向，再抠细节。

这思路跟相亲差不多：先在几个候选里划重点，再一对一深聊，最后才决定要不要掏彩礼。哦不对，是决定哪个文件值得读。

5.3 一个直观的对比

假设你有个电商项目，Agent 问"订单退款流程是怎样的"。

传统 RAG：可能返回 refund_service.py 里的一个函数片段。你看到几行代码，不知道它在整个流程中的位置，不知道上游是谁、下游是谁，也不知道有没有相关文档。就像你只拿到了菜谱的第 4 页，还不知道这是第几道菜。

OpenViking 目录递归检索：

1. 先定位到 src/order/ 目录（高分目录）；
2. 在 src/order/ 下二次检索，发现 refund/ 子目录和 docs/order-refund.md；
3. 递归进入 refund/，找到 refund_service.py、refund_controller.py、refund_validator.py；
4. 返回时带着完整的目录路径和层级关系。

Agent 拿到的是一个结构化的理解路径，而不是一堆碎片。一个是从万米高空扔你一张地图局部，一个是先带你看全景，再带你到街区，最后带你到那栋楼门口。

6. 核心设计四：检索轨迹可视化

6.1 黑箱变白盒

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

OpenViking 的层次化虚拟文件系统加上目录递归检索，天然给可观测性打了地基。每一次检索都会完整保留目录浏览轨迹：从哪个根目录开始、经过哪些子目录、在每个目录做了什么检索决策、最终选了哪些文件。

这意味着，当检索结果不对劲时，你能清楚地看到 Agent 是沿着哪条路找到这个结果的，是在哪个目录转错了弯，还是在某个环节漏掉了关键信息。

以前修检索问题像修祖传老电视：拍一拍，看运气。现在好了，电视自带回放功能，还能告诉你它为啥雪花。

6.2 Web Studio

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

对，不用安装。这年头连装个软件都要先被各种"全家桶"威胁一遍，这种打开即用的简直是一股清流。

7. 核心设计五：会话自迭代

7.1 session.commit() 都干了啥

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

每次会话结束时，通过 session.commit() 主动触发，系统异步做两件事。

第一，提取用户偏好记忆。分析本次会话中的用户行为、反馈和表达习惯，更新到 memories/preferences/ 目录。

比如你多次要求"代码注释用中文"“函数命名用小驼峰”“回复简洁一点”，系统就会把这些沉淀成长期记忆。下次对话不用你再啰嗦，Agent 自己就懂了。

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

比如 Agent 发现"用 grep -r 搜代码比语义检索更快定位到具体函数"“这项目的测试需要先启动 Docker 容器”，这些经验都会被沉淀下来，下次直接复用，不再重新踩坑。

你品品，这玩意儿连踩过的坑都能记住。而我呢？我上周踩过的坑，这周还能再踩一遍，踩得还挺熟练。

7.2 自迭代等于复利

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

第 1 天：Agent 从零开始，什么都得探索，笨得像我第一次用 Vim。

第 7 天：已经沉淀了一批用户偏好和基础经验，常见任务的执行效率明显提升。

第 30 天：记忆库相当丰富，对用户习惯、项目结构、常见问题解决方案了如指掌，很多任务直接上手，不用反复确认。

第 90 天：这个 Agent 已经成为"最懂你"的工作伙伴，它的记忆和经验本身就是不可替代的资产。

这就是"自进化"的真正含义：模型本身没变，是上下文在持续积累和优化。同一个模型，用着用着就变聪明了。

说白了，这是给 AI 装了套"肌肉记忆"。而我呢，我练了三年健身，肌肉记忆只记住了怎么吃夜宵。

7.3 和 Hermes 的配合

OpenViking 和 Hermes Agent 的关系，一句话说清：Hermes 负责学习和进化的策略层，决定从任务中提取什么技能、怎么优化、什么时候调用；OpenViking 负责存储和检索层，把技能、记忆、资源统一管起来，提供高效检索和按需加载。

Hermes 的技能文件可以直接存进 OpenViking 的 skills/ 目录，记忆存进 memories/，项目资源存进 resources/。用的时候，通过目录递归检索和分层加载，以最低的 Token 成本拿到最相关的上下文。

一个是教 Agent 怎么学，一个是帮 Agent 把学到的存起来、找出来、用起来。这配合，比豆浆配油条还稳。

8. 技术架构：Rust 打底，Python 上桌

OpenViking 是 Python + Rust 的多组件项目，整体分四层：

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

核心组件大概这么几个：

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

Python SDK（sdk/、openviking/）：暴露 SyncOpenViking 等客户端类，方便在 Python 项目里集成。Python 是 AI 开发的主流语言，这波直接把门槛降到了"会 pip install 就能用"。

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

Web Studio（web-studio/）：TypeScript 编写的可视化控制台，提供目录浏览、语义搜索、检索轨迹查看、多 Agent 管理，有在线 Demo。

VikingBot（bot/）：基于 OpenViking 的对话框架。装 openviking[bot] 后，用 openviking-server --with-bot 启动，另开终端 ov chat 就能聊。

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

存储层是混合架构：AGFS 虚拟文件系统管结构化组织，向量索引管语义检索，文档存储管原文，目录元数据管层级和 URI 映射。

一句话总结：Rust 负责快，Python 负责爽，TypeScript 负责好看。三兄弟各司其职，比我们团队的分工都明确。

9. 上手三分钟

理论扯了这么多，来点实战。OpenViking 的安装和使用相当简单，三分钟跑通。

9.1 安装

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

要求 Python 3.10 或更高版本。

9.2 初始化和启动

# 交互向导：选择 Provider（火山引擎/OpenAI/Kimi/GLM/Ollama），填写 API Key openviking-server init # 校验配置：检查配置文件、Python 版本、Provider 连通性、磁盘空间 openviking-server doctor # 启动服务（后台运行） nohup openviking-server > openviking.log 2>&1 &

init 会引导你配置 Provider：火山引擎（推荐，成本低性能好）、OpenAI、Codex OAuth、Kimi、GLM、本地 Ollama 都支持，配置写入 ~/.openviking/ov.conf。

Ollama 还能自动检测和安装运行时，并拉取适合你硬件的模型。主打一个你负责点击，它负责干活。

9.3 喂资源、查记忆

# 查看服务状态 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。心急吃不了热豆腐，也搜不出热结果。

9.4 Python SDK

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()

9.5 Docker 部署

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

官方 Docker 镜像默认捆绑 VikingBot，启动后服务端和控制台 UI 一起跑。也支持 Helm 部署到 Kubernetes。

从 pip 到 Docker 到 K8s，一条龙。你只需要一行 docker compose up -d，剩下的交给 CPU 和电费。

10. 数字不会骗人：Benchmark

OpenViking 0.3.22 版本在 LoCoMo（长对话用户记忆）和 tau2-bench（多轮 Agent 任务）上做了评估，来看看数据。

10.1 LoCoMo：长对话记忆

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

三个看点：

第一，接入后三个 Agent 的准确率都进了 80-83% 区间。说明 OpenViking 能把不同 Agent 的记忆表现拉到同一根高线上。不管是青铜还是王者，戴上这个外挂都能上分。

第二，原生记忆越弱的 Agent，提升越大。OpenClaw 从 24.20% 干到 82.08%，翻了三倍多；Hermes 从 33.38% 到 82.86%，涨了近 50 个百分点。都说差生文具多，但这次文具是真管用。

第三，连 Claude Code 这种原生记忆本来就不错的，接入后也涨了 23.11 个百分点。说明这不是替代原有记忆系统，而是实打实的增量价值。

另外两个指标：输入 Token 消耗下降 34.3%-91.0%，查询延迟下降 58.45%-66.10%。

10.2 tau2-bench：多轮任务成功率

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

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

这不就是传说中的"工作经验"吗？原来 AI 也有"工作三年 vs 应届生"的差距，只不过它不需要三年，只需要你多跟它聊几轮。

10.3 评估配置

记忆评估使用了 Doubao 2.0 Pro 作为视觉语言模型，Doubao-embedding-vision-251215 作为 Embedding 模型。完整的评估结果和复现脚本在项目 benchmark/ 目录下，想复现的可以自己跑。

11. 对 Coding Agent 意味着什么

11.1 陌生仓库的分层理解

OpenViking 支持接入 GitHub 代码仓库，自动生成目录树、索引和分层上下文。接入后自动处理成：L0 一句话说明项目是干嘛的，L1 核心模块、目录结构、关键入口，L2 每个文件的完整代码按需读取。每个子目录也有自己的 L0/L1。

Coding Agent 理解陌生项目时，不用把整个仓库读一遍，而是从宏观到微观逐层深入。以前是接盘侠式通读，现在是老司机式扫一眼就知道重点在哪。

11.2 跨会话的编码偏好

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

OpenViking 的会话自迭代会自动从历史对话中提取这些偏好，沉淀到 memories/preferences/ 目录。而且偏好是动态进化的，你从 pytest 转投 unittest 了，它也能捕捉到变化并更新，不会固守旧习惯。

比某些同事强，人家说一次就记住了。现在你的 Agent 也能做到。

11.3 编码经验的沉淀复用

一个 Coding Agent 在帮你修 Bug、加功能、重构的过程中，会积累大量项目特定经验：这项目 Bug 通常出在哪些模块？加新功能要同步改哪些文件？测试怎么跑？部署有什么坑？代码审查关注哪些点？

这些经验如果只活在单次对话里，下次就归零。但通过自迭代，它们会被沉淀下来，下次遇到类似任务自动复用。

举个具体例子：Agent 第一次帮你加 API 接口，要探索项目结构、找路由定义、理解认证机制、学测试写法、搞清部署流程，可能得几十轮交互。第二次加接口，它已经知道路由在 src/routes/、认证用 JWT、测试用 pytest、部署走 GitHub Actions，几轮就搞定。

第一次是新人入职，第二次是老员工返场。而且它不要求涨工资。

11.4 多 Agent 协作的共享上下文

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

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

"共享资源 + 独立记忆"的模式，听起来就是我们公司理想中的协作方式：一个共享文档，各自独立干活。当然，我们公司实际的情况是，共享文档永远有人不更新。

12. 什么时候该用，什么时候别碰

12.1 强烈推荐

给编码 Agent 加跨会话长期记忆。用 Claude Code、Codex、Cursor、TRAE 的兄弟，想让 Agent 记住你的编码习惯、项目经验和历史决策，OpenViking 是目前最成熟的方案之一。

搭私有 RAG 知识库。厌倦了传统 RAG 的碎片化切片和黑箱检索，想要清晰目录结构、可观测检索轨迹和分层加载的，OpenViking 提供了一个新范式。

多 Agent 协作的共享上下文底座。在构建多 Agent 系统，需要一个统一的上下文管理层来协调不同 Agent 的记忆和知识。

需要自进化能力的 Agent。希望 Agent 能从每次任务中学习、沉淀经验、越用越聪明的，会话自迭代机制开箱即用。

对 Token 成本敏感的长周期任务。分层加载带来的 30-90% 节省是实打实的成本下降。

12.2 可能不太适合

极简单轮问答。单轮 FAQ 机器人，不需要记忆、不需要复杂推理、不需要跨会话学习，传统 RAG 更轻量。

对 AGPL 协议敏感的商业产品。主项目是 AGPLv3，闭源商用要仔细评估。不过 ov_cli 和 examples 是 Apache 2.0，可以更宽松地使用。

完全离线且无 GPU 的环境。OpenViking 需要 VLM 和 Embedding 模型支持，虽然可以用本地 Ollama，但要是啥都没有，那就是巧妇难为无米之炊。

超大规模（百万级文件）的极端场景。项目还在快速迭代，虽然自管理版已支持分布式部署，但极端场景可能还得等能力再成熟一点。

12.3 和传统方案的对比

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

13. 生态版图

13.1 Agent 集成

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

集成方式通常是注入 OpenViking recall 到 Agent 的上下文中，并自动提交会话记忆。无论你在用哪个 Agent，都能低成本接入。

13.2 桌面控制台 Helper

OpenViking 还推出了桌面端控制台 Helper（Beta），支持 macOS 和 Windows：自动检测本地 Agent 配置、解析会话轨迹、查看本地记忆和 SKILL.md 技能并同步到 OpenViking。

这玩意儿直接拉低了非专业开发者的使用门槛。以前搞这些得翻文档，现在点点鼠标就行。

13.3 商业版本

开源版功能完整、无阉割、无需账号、无需激活密钥，可以直接在生产环境用。在此基础上还有两个商业版：托管 SaaS（个人版免费试用，最多 50 个文件；企业版支持多用户、团队协作和 SLA）和自管理版（数据不出域，支持 BYOC 和完全离线部署，适合监管行业）。

这种"开源完整 + 商业增值"的模式，既保住了社区活力，又给企业用户兜了底。开源白嫖，付费真香，两边都舒服。

13.4 学术背书

OpenViking 开源了 VikingMem 论文中描述的核心能力的子集。这篇论文《VikingMem: A Memory Base Management System for Stateful LLM-based Applications》被 VLDB 2026 接收。VLDB 是数据库领域的顶级会议，能被接收说明这套方案不是工程拼凑，是有学术研究撑腰的。

13.5 合作伙伴

deer-flow（开源长周期 SuperAgent 框架）、NoKV（AI 原生分布式文件系统）、loopx（轻量级循环工程状态内核）、Hermes Agent。这个生态还在快速扩张，随着越来越多项目接入，OpenViking 有可能成为 Agent 上下文管理的事实标准。

14. 写在最后：上下文工程是 Agent 时代的新地基

回到开头的问题：Agent 的记性，还有救吗？

有救。答案就是这套方案：记忆、资源、技能全部存在一个 viking:// 虚拟文件系统里，用文件系统的范式管理，用数据库的能力检索，用自迭代的机制进化。

往大了说，这背后是一个更大的趋势：上下文工程正在成为 Agent 时代的新基础设施。

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

OpenViking 做的事，本质上是给 Agent 造了个大脑：文件系统范式是记忆结构，分层加载是注意力机制，目录递归检索是联想能力，可观测轨迹是内省能力，会话自迭代是学习能力。

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

这也是为什么聊到 AI Coding 自进化时，OpenViking 总被反复提起。它不是自进化的策略，而是自进化的地基。没有好的上下文数据库，自进化就只是空中楼阁。

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

如果你在做 AI Agent、折腾 RAG、给 Coding Agent 加记忆、探索自进化的可能性，OpenViking 值得你花一个下午跑一跑、试一试。

反正我的 Agent 已经装上了。以后它要是再敢忘了我说的话，我就给它减 Token 配额。开个玩笑，它现在记性好得很。

最后说句掏心窝子的话：AI 都开始给自己装长期记忆了，你呢？上次说的"明天开始学 Rust"，还记得吗？

参考链接：

• GitHub 仓库：https://github.com/volcengine/OpenViking
• 官方网站：https://openviking.ai
• 在线 Demo：https://studio.openviking.ai
• 文档中心：https://docs.openviking.ai
• VikingMem 论文：arXiv:2605.29640
• 火山引擎产品页：https://www.volcengine.com/product/openviking

P.S. 无意间发现了一个巨牛的人工智能教程，非常通俗易懂，对AI感兴趣的朋友强烈推荐去看看，传送门https://blog.csdn.net/H1727548