OpenViking:把 Agent 上下文放进一套文件系统

转载请注明出处❤️

作者:测试蔡坨坨

原文链接:caituotuo.top/8ad04a89.html


你好,我是蔡坨坨。

现在用 AI 做研发,经常要在多个入口之间切换。群聊适合讨论,Coding Agent 适合改代码,文档工具适合沉淀结论。

工具可以换,问题出在上下文也跟着断了。刚在一个窗口里讲清楚的项目背景,换到另一个 Agent 又得重说一遍。

OpenViking 想解决的就是这件事:把分散在不同 Agent 里的资源、记忆和 Skills,放到同一层管理。

它不是另一个 Agent

OpenViking 是一个面向 AI Agent 的开源上下文数据库。它不负责代替 Claude Code、Codex 或其他 Agent 执行任务,而是位于这些工具背后,提供一份可以共同读取的 Context。

这份 Context 主要分成三类:

  • Resource:代码仓库、项目文档、网页和团队规范。
  • Memory:用户偏好、历史判断和任务经验。
  • Skill:可以重复使用的工作方法。

三类内容都通过 viking:// URI 组织。对 Agent 来说,它们更像一套文件系统,可以用 lstreefind 等方式浏览,而不是面对一个只能输入关键词的黑盒检索接口。

1
2
3
4
5
6
7
8
9
viking://
├── resources/
│ └── my_project/
│ ├── docs/
│ └── src/
└── user/{user_id}/
├── memories/
├── resources/
└── skills/

这个设计很适合研发场景。目录本身就在表达项目结构,Agent 找到一个结果后,还能继续查看同目录下的相关资料,不必把每个片段当成互不相干的搜索结果。

三层内容按需读取

把上下文统一存起来,不等于每次都要全部塞给模型。资料多了以后,一次性读取只会挤占上下文窗口。

OpenViking 在写入时把内容处理成三个层级:

  • L0 Abstract:一句话摘要,用于判断相关性。
  • L1 Overview:结构、重点和使用场景,用于制定下一步计划。
  • L2 Details:完整原文,需要时再读取。

目录也有自己的 L0 和 L1。Agent 可以先判断哪个目录相关,再逐层深入到文件,只在必要时加载原文。

它的重点不是让 Agent 记住所有内容,而是让 Agent 知道该去哪里找。

OpenViking 还会保留检索路径。结果不对时,可以回头看 Agent 经过了哪些目录、读取了哪一层内容。这比只拿到几个相似度分数更容易排查问题。

对话怎么变成长期记忆

一次任务里的上下文,大多会随着 Session 结束而消失。OpenViking 提供了 Session Commit,把任务过程继续沉淀下来。

按官方说明,Session 提交后,系统会异步提取用户偏好和 Agent 经验,再写入长期 Memory。下一次换 Session,甚至换 Agent,这些信息仍然可以被检索。

这里要注意边界。自动提取减少了手工整理,但抽取结果仍可能出错。涉及发布规则、权限要求和架构决策时,最好让写入内容可追踪、可检查,不要把一次临时讨论直接当成永久规范。

一个典型的研发协作场景是:群聊里的 Agent 处理 PR Review,Claude Code 在 CLI 里分析代码,飞书文档继续整理结论。几个入口读取的是同一份项目资源和长期记忆。

这不是要求所有任务都交给一个 Agent。它解决的是换入口之后,背景资料不用从头搬运。

本地跑起来

OpenViking 当前要求 Python 3.10 及以上。按照官方 README,可以这样安装和初始化:

1
2
3
4
pip install openviking --upgrade
openviking-server init
openviking-server doctor
openviking-server

init 会引导配置模型与服务提供方,默认把配置写到 ~/.openviking/ov.confdoctor 用来检查 Python 版本、配置、模型连接和磁盘空间。

服务启动后,可以先导入一个公开仓库:

1
2
3
4
5
ov status
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"

这一组命令足够观察资源如何进入目录、如何被检索。确认效果后,再接入自己的 Agent。官方已经提供 Claude Code、Codex、Cursor、OpenClaw、OpenCode、pi 和 MCP 客户端等集成说明。

适合什么场景

如果你经常在多个 Agent 之间切换,或者代码、文档、规范和 Skills 已经散落在不同位置,OpenViking 的文件系统思路会比较顺手。

它也有成本。引入上下文数据库后,需要维护模型配置、索引过程、访问权限和记忆质量。开源版采用 AGPLv3,准备嵌入产品或部署到团队环境前,也要先确认许可证与数据边界。

我的判断是,先选一个真实项目做小范围验证。导入代码和规范,用同一组问题测试原来的 Agent 与接入后的 Agent,再检查检索轨迹和输入 Token。

上下文能不能跨工具复用,最终要看任务结果。目录再整齐,也代替不了验证。

参考资料