文章目录1. 先聊聊这个让人破防的 AI 健忘症1.1 记忆、知识、技能三套系统各管各的1.2 朴素 RAG切片切的是上下文不是菜1.3 Token 焦虑症1.4 黑箱检索它说找着了你也不知道咋找的2. OpenViking 到底是啥2.1 先上项目档案2.2 一句话定位3. 核心设计一万物皆文件3.1 为什么是文件系统3.2 viking:// 目录长啥样3.3 用文件命令管记忆4. 核心设计二L0/L1/L2 分层加载4.1 问题全量加载太贵4.2 解法写入时自动分层4.3 省下来的都是真金白银5. 核心设计三目录递归检索5.1 传统向量检索的两个毛病5.2 五步检索法5.3 一个直观的对比6. 核心设计四检索轨迹可视化6.1 黑箱变白盒6.2 Web Studio7. 核心设计五会话自迭代7.1 session.commit() 都干了啥7.2 自迭代等于复利7.3 和 Hermes 的配合8. 技术架构Rust 打底Python 上桌9. 上手三分钟9.1 安装9.2 初始化和启动9.3 喂资源、查记忆9.4 Python SDK9.5 Docker 部署10. 数字不会骗人Benchmark10.1 LoCoMo长对话记忆10.2 tau2-bench多轮任务成功率10.3 评估配置11. 对 Coding Agent 意味着什么11.1 陌生仓库的分层理解11.2 跨会话的编码偏好11.3 编码经验的沉淀复用11.4 多 Agent 协作的共享上下文12. 什么时候该用什么时候别碰12.1 强烈推荐12.2 可能不太适合12.3 和传统方案的对比13. 生态版图13.1 Agent 集成13.2 桌面控制台 Helper13.3 商业版本13.4 学术背书13.5 合作伙伴14. 写在最后上下文工程是 Agent 时代的新地基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.0GitHub Star29k技术栈Rust核心引擎 Python 3.10SDK/CLI TypeScriptWeb Studio学术基础VLDB 2026 论文 VikingMem部署方式pip 安装、Docker、docker-compose、HelmViking 团队不是来蹭 Agent 热度的。人家从 2019 年就开始做向量数据库 VikingDB支撑字节内部全业务大规模使用2024 年推出知识库和记忆库2025 年做 AI 搜索和知识助手2025 年 10 月开源了 MineContext2026 年 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:// URIAgent 可以精确定位、引用、操作某条上下文而不是靠大概是这个意思的模糊匹配。程序员最怕的就是大概“可能”“应该”这波直接治好了。第四技能即文件。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 做关键词匹配。对开发者来说这组命令的学习成本约等于零。别的项目教你要学新 APIOpenViking 说你就当自己还在用 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 接到任务给这个项目加一个微信登录功能。它不需要把整个代码仓库读一遍只需要读项目根目录的 .abstract约 100 tokens确认这是个 Web 项目读根目录的 .overview约 2k tokens发现有 src/auth/ 目录读 src/auth/ 目录的 .abstract 和 .overview了解现有认证机制只有真正动手时才去读 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 的目录递归检索融合了多种检索方式的优点流程分五步意图分析生成多个检索条件。比如问这个项目的支付流程安全吗系统可能生成支付流程“安全机制”代码实现等多个检索条件。向量检索定位初始高分目录。先锁定大方向答案大概率在哪个目录下。目录内二次检索更新候选集合把高相关的文件和子目录加进候选。逐层递归持续下钻。候选目录下还有子目录就递归重复上一步直到找到最相关的具体文件。返回携带完整上下文的结果。最终返回的不是孤立片段而是带着目录路径、层级关系和周边上下文的完整结果。核心思想一句话先锁定高分目录再精细探索内容。先定大方向再抠细节。这思路跟相亲差不多先在几个候选里划重点再一对一深聊最后才决定要不要掏彩礼。哦不对是决定哪个文件值得读。5.3 一个直观的对比假设你有个电商项目Agent 问订单退款流程是怎样的。传统 RAG可能返回 refund_service.py 里的一个函数片段。你看到几行代码不知道它在整个流程中的位置不知道上游是谁、下游是谁也不知道有没有相关文档。就像你只拿到了菜谱的第 4 页还不知道这是第几道菜。OpenViking 目录递归检索先定位到 src/order/ 目录高分目录在 src/order/ 下二次检索发现 refund/ 子目录和 docs/order-refund.md递归进入 refund/找到 refund_service.py、refund_controller.py、refund_validator.py返回时带着完整的目录路径和层级关系。Agent 拿到的是一个结构化的理解路径而不是一堆碎片。一个是从万米高空扔你一张地图局部一个是先带你看全景再带你到街区最后带你到那栋楼门口。6. 核心设计四检索轨迹可视化6.1 黑箱变白盒前面说过传统 RAG 的检索链路是黑箱。结果不对你不知道是切片有问题、检索策略有问题还是排序有问题。调试全靠猜改进全靠试。OpenViking 的层次化虚拟文件系统加上目录递归检索天然给可观测性打了地基。每一次检索都会完整保留目录浏览轨迹从哪个根目录开始、经过哪些子目录、在每个目录做了什么检索决策、最终选了哪些文件。这意味着当检索结果不对劲时你能清楚地看到 Agent 是沿着哪条路找到这个结果的是在哪个目录转错了弯还是在某个环节漏掉了关键信息。以前修检索问题像修祖传老电视拍一拍看运气。现在好了电视自带回放功能还能告诉你它为啥雪花。6.2 Web StudioOpenViking 还提供了 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 SDKsdk/、openviking/暴露 SyncOpenViking 等客户端类方便在 Python 项目里集成。Python 是 AI 开发的主流语言这波直接把门槛降到了会 pip install 就能用。命令行工具openviking_cli/、crates/ov_cliopenviking-server 管服务端ov 管客户端支持 ls、tree、find、grep、add-resource 等操作是日常使用的主要入口。Web Studioweb-studio/TypeScript 编写的可视化控制台提供目录浏览、语义搜索、检索轨迹查看、多 Agent 管理有在线 Demo。VikingBotbot/基于 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 21 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 SDKimport openviking as ov # 初始化客户端 client ov.SyncOpenViking(path./data) client.initialize() # 添加资源 add_result client.add_resource( pathhttps://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_uriroot_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. 数字不会骗人BenchmarkOpenViking 0.3.22 版本在 LoCoMo长对话用户记忆和 tau2-bench多轮 Agent 任务上做了评估来看看数据。10.1 LoCoMo长对话记忆Agent原生记忆准确率接入 OpenViking 后提升幅度OpenClaw24.20%82.08%57.88ppHermes33.38%82.86%49.48ppClaude Code57.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.87ppAirline航空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 集成编码 AgentClaude Code、Codex、Cursor、TRAE / TRAE CN、OpenCode、OpenClaw。通用 AgentHermes、pi、Agent Plugins 1.0。框架集成LangChain / LangGraph、MCP 客户端。集成方式通常是注入 OpenViking recall 到 Agent 的上下文中并自动提交会话记忆。无论你在用哪个 Agent都能低成本接入。13.2 桌面控制台 HelperOpenViking 还推出了桌面端控制台 HelperBeta支持 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 框架、NoKVAI 原生分布式文件系统、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在线 Demohttps://studio.openviking.ai文档中心https://docs.openviking.aiVikingMem 论文arXiv:2605.29640火山引擎产品页https://www.volcengine.com/product/openvikingP.S. 无意间发现了一个巨牛的人工智能教程非常通俗易懂对AI感兴趣的朋友强烈推荐去看看传送门https://blog.csdn.net/H1727548 一个给 AI Agent 用的“会进化的大脑“
文章目录1. 先聊聊这个让人破防的 AI 健忘症1.1 记忆、知识、技能三套系统各管各的1.2 朴素 RAG切片切的是上下文不是菜1.3 Token 焦虑症1.4 黑箱检索它说找着了你也不知道咋找的2. OpenViking 到底是啥2.1 先上项目档案2.2 一句话定位3. 核心设计一万物皆文件3.1 为什么是文件系统3.2 viking:// 目录长啥样3.3 用文件命令管记忆4. 核心设计二L0/L1/L2 分层加载4.1 问题全量加载太贵4.2 解法写入时自动分层4.3 省下来的都是真金白银5. 核心设计三目录递归检索5.1 传统向量检索的两个毛病5.2 五步检索法5.3 一个直观的对比6. 核心设计四检索轨迹可视化6.1 黑箱变白盒6.2 Web Studio7. 核心设计五会话自迭代7.1 session.commit() 都干了啥7.2 自迭代等于复利7.3 和 Hermes 的配合8. 技术架构Rust 打底Python 上桌9. 上手三分钟9.1 安装9.2 初始化和启动9.3 喂资源、查记忆9.4 Python SDK9.5 Docker 部署10. 数字不会骗人Benchmark10.1 LoCoMo长对话记忆10.2 tau2-bench多轮任务成功率10.3 评估配置11. 对 Coding Agent 意味着什么11.1 陌生仓库的分层理解11.2 跨会话的编码偏好11.3 编码经验的沉淀复用11.4 多 Agent 协作的共享上下文12. 什么时候该用什么时候别碰12.1 强烈推荐12.2 可能不太适合12.3 和传统方案的对比13. 生态版图13.1 Agent 集成13.2 桌面控制台 Helper13.3 商业版本13.4 学术背书13.5 合作伙伴14. 写在最后上下文工程是 Agent 时代的新地基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.0GitHub Star29k技术栈Rust核心引擎 Python 3.10SDK/CLI TypeScriptWeb Studio学术基础VLDB 2026 论文 VikingMem部署方式pip 安装、Docker、docker-compose、HelmViking 团队不是来蹭 Agent 热度的。人家从 2019 年就开始做向量数据库 VikingDB支撑字节内部全业务大规模使用2024 年推出知识库和记忆库2025 年做 AI 搜索和知识助手2025 年 10 月开源了 MineContext2026 年 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:// URIAgent 可以精确定位、引用、操作某条上下文而不是靠大概是这个意思的模糊匹配。程序员最怕的就是大概“可能”“应该”这波直接治好了。第四技能即文件。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 做关键词匹配。对开发者来说这组命令的学习成本约等于零。别的项目教你要学新 APIOpenViking 说你就当自己还在用 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 接到任务给这个项目加一个微信登录功能。它不需要把整个代码仓库读一遍只需要读项目根目录的 .abstract约 100 tokens确认这是个 Web 项目读根目录的 .overview约 2k tokens发现有 src/auth/ 目录读 src/auth/ 目录的 .abstract 和 .overview了解现有认证机制只有真正动手时才去读 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 的目录递归检索融合了多种检索方式的优点流程分五步意图分析生成多个检索条件。比如问这个项目的支付流程安全吗系统可能生成支付流程“安全机制”代码实现等多个检索条件。向量检索定位初始高分目录。先锁定大方向答案大概率在哪个目录下。目录内二次检索更新候选集合把高相关的文件和子目录加进候选。逐层递归持续下钻。候选目录下还有子目录就递归重复上一步直到找到最相关的具体文件。返回携带完整上下文的结果。最终返回的不是孤立片段而是带着目录路径、层级关系和周边上下文的完整结果。核心思想一句话先锁定高分目录再精细探索内容。先定大方向再抠细节。这思路跟相亲差不多先在几个候选里划重点再一对一深聊最后才决定要不要掏彩礼。哦不对是决定哪个文件值得读。5.3 一个直观的对比假设你有个电商项目Agent 问订单退款流程是怎样的。传统 RAG可能返回 refund_service.py 里的一个函数片段。你看到几行代码不知道它在整个流程中的位置不知道上游是谁、下游是谁也不知道有没有相关文档。就像你只拿到了菜谱的第 4 页还不知道这是第几道菜。OpenViking 目录递归检索先定位到 src/order/ 目录高分目录在 src/order/ 下二次检索发现 refund/ 子目录和 docs/order-refund.md递归进入 refund/找到 refund_service.py、refund_controller.py、refund_validator.py返回时带着完整的目录路径和层级关系。Agent 拿到的是一个结构化的理解路径而不是一堆碎片。一个是从万米高空扔你一张地图局部一个是先带你看全景再带你到街区最后带你到那栋楼门口。6. 核心设计四检索轨迹可视化6.1 黑箱变白盒前面说过传统 RAG 的检索链路是黑箱。结果不对你不知道是切片有问题、检索策略有问题还是排序有问题。调试全靠猜改进全靠试。OpenViking 的层次化虚拟文件系统加上目录递归检索天然给可观测性打了地基。每一次检索都会完整保留目录浏览轨迹从哪个根目录开始、经过哪些子目录、在每个目录做了什么检索决策、最终选了哪些文件。这意味着当检索结果不对劲时你能清楚地看到 Agent 是沿着哪条路找到这个结果的是在哪个目录转错了弯还是在某个环节漏掉了关键信息。以前修检索问题像修祖传老电视拍一拍看运气。现在好了电视自带回放功能还能告诉你它为啥雪花。6.2 Web StudioOpenViking 还提供了 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 SDKsdk/、openviking/暴露 SyncOpenViking 等客户端类方便在 Python 项目里集成。Python 是 AI 开发的主流语言这波直接把门槛降到了会 pip install 就能用。命令行工具openviking_cli/、crates/ov_cliopenviking-server 管服务端ov 管客户端支持 ls、tree、find、grep、add-resource 等操作是日常使用的主要入口。Web Studioweb-studio/TypeScript 编写的可视化控制台提供目录浏览、语义搜索、检索轨迹查看、多 Agent 管理有在线 Demo。VikingBotbot/基于 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 21 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 SDKimport openviking as ov # 初始化客户端 client ov.SyncOpenViking(path./data) client.initialize() # 添加资源 add_result client.add_resource( pathhttps://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_uriroot_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. 数字不会骗人BenchmarkOpenViking 0.3.22 版本在 LoCoMo长对话用户记忆和 tau2-bench多轮 Agent 任务上做了评估来看看数据。10.1 LoCoMo长对话记忆Agent原生记忆准确率接入 OpenViking 后提升幅度OpenClaw24.20%82.08%57.88ppHermes33.38%82.86%49.48ppClaude Code57.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.87ppAirline航空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 集成编码 AgentClaude Code、Codex、Cursor、TRAE / TRAE CN、OpenCode、OpenClaw。通用 AgentHermes、pi、Agent Plugins 1.0。框架集成LangChain / LangGraph、MCP 客户端。集成方式通常是注入 OpenViking recall 到 Agent 的上下文中并自动提交会话记忆。无论你在用哪个 Agent都能低成本接入。13.2 桌面控制台 HelperOpenViking 还推出了桌面端控制台 HelperBeta支持 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 框架、NoKVAI 原生分布式文件系统、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在线 Demohttps://studio.openviking.ai文档中心https://docs.openviking.aiVikingMem 论文arXiv:2605.29640火山引擎产品页https://www.volcengine.com/product/openvikingP.S. 无意间发现了一个巨牛的人工智能教程非常通俗易懂对AI感兴趣的朋友强烈推荐去看看传送门https://blog.csdn.net/H1727548 RELATED READING
延伸阅读
更多一线实战笔记与深度复盘，助您持续精进
