一個 AI Agent 的記憶準確率，從 24% 跳到 82%。同一份工作，token 用量少了 91%。
一句話結論：OpenViking 是火山引擎開源的 AI Agent 上下文資料庫，官方 benchmark 顯示 OpenClaw 的長對話記憶準確率由 24.20% 升到 82.08%、token 省 91.0%；但中文圈流行的「它取代了向量資料庫」是誤讀：它自己的評測表格，檢索方式那一欄寫著 Vector retrieval。
過去一個月，這個項目在中文技術圈被反覆轉載，標題幾乎都是同一句：告別向量資料庫。我翻完它的 README、benchmark 表和 release 紀錄之後，覺得這句話賣得太順口了，順口到把真正值得學的那一層蓋掉了。
（本文數據截至 2026 年 8 月 19 日，GitHub 頁面實查。）
OpenViking 到底解決什麼問題？
解決的是「Agent 的記憶散在四個地方」這件事。
用它的 README 原話，開發 Agent 時的痛點有五個：記憶在程式碼裡、資源在向量資料庫、技能散落各處（Fragmented Context）；長任務不斷產生新脈絡，截斷或壓縮就掉資訊；傳統 RAG 用扁平儲存，缺乏全局視角；檢索鏈是黑盒，出錯了無從 debug；記憶只記錄了「使用者說過什麼」，沒有記錄「Agent 自己做過什麼」。
OpenViking 的答案是把這一切放進一個虛擬檔案系統，掛在 viking:// 協定底下。Agent 不再對著一個黑盒 API 問「跟這句話最像的五段文字是什麼」，而是像工程師一樣，用 ls、tree、find 自己走目錄。
每一份內容會被切成三層，按需要載入：
| 層級 | 內容 | 大小 | 什麼時候讀 |
|---|---|---|---|
| L0（Abstract） | 一句話摘要 | 約 100 tokens | 快速判斷相不相關 |
| L1（Overview） | 核心資訊與使用場景 | 約 2,000 tokens | Agent 規劃階段做決策 |
| L2（Details） | 完整原文 | 不限 | 真的非讀不可才載入 |
這套分層邏輯本身不算新鮮，我們之前寫過的 TencentDB 分層記憶 也是同一個思路。OpenViking 的差別在於，它把「層」和「路徑」綁在一起：每個目錄都有自己的 .abstract 和 .overview，所以 Agent 可以先在目錄層級判斷方向，再往下鑽。
「它幹掉了向量資料庫」這句話，錯在哪？
錯在把「不再是唯一入口」講成「不再存在」。
先看它自己怎麼寫。README 的 Overview 段落原句是：OpenViking abandons the fragmented vector storage model of traditional RAG，放棄的是傳統 RAG 那種碎片化的向量儲存模型。關鍵詞是 fragmented，不是 vector。
再往下三行，同一段的功能清單寫得更白：目錄遞歸檢索的做法是「結合目錄定位與語意搜尋」。語意搜尋就是 embedding，就是向量。
最直接的證據在 benchmark 表本身。在 HotpotQA 多跳問答那張表裡，每一列都標了檢索方式：
| 方案 | 檢索方式 | 準確率 | 檢索延遲 |
|---|---|---|---|
| Naive RAG | Vector retrieval | 62.50% | 0.11s |
| HippoRAG 2 | Vector + knowledge graph | 61.00% | 20s |
| LightRAG | Vector + knowledge graph | 89.00% | 75s |
| LangChain SQL | SQL agent | 78.00% | 132s |
| OpenViking（top-20） | Vector retrieval | 91.00% | 0.23s |
OpenViking 那一列，檢索方式欄寫的是 Vector retrieval。跟 Naive RAG 同一欄。
而且它的設定檔支援的 embedding 供應商列了一長串：volcengine（豆包）、openai、azure、jina、ollama、voyage、dashscope、minimax、cohere、vikingdb、gemini、litellm、local。一個真的不用向量的系統，不需要接十三家 embedding。
所以準確的講法是：向量沒有走，只是不再是唯一的入口。它從「一步到位撈碎片」，降級成「先定位目錄」這一步的其中一個工具。
我要挑這句話的骨頭，不是為了咬文嚼字。如果你以為裝了 OpenViking 就可以把 embedding 那條線整個拆掉，你會在配置階段直接撞牆，因為它第一件事就是叫你選 embedding 供應商。
那準確率是怎麼從 24% 推到 82% 的？
靠的是「先鎖目錄、再讀內容」這個兩段式檢索，而不是換掉向量。
傳統 RAG 的失敗模式很典型：你問一個問題，它撈回五段語意最像的文字，但這五段可能來自五個毫不相干的檔案，彼此沒有上下文。答案看起來字字相關，合起來卻答非所問。
OpenViking 的做法是先用語意分數找出得分最高的目錄，鎖定之後再逐層往下細化。README 的說法是「先鎖定高分目錄，再細化內容探索」。找到的不只是最匹配的片段，還有那個片段所在的完整脈絡。
另外兩個設計也直接影響數字：
- 分層載入省 token：判斷相關性只讀 L0 的 100 tokens，不用把整份 L2 塞進 context。省下來的量非常誇張，下一節有數字。
- 檢索軌跡可視化：它會把目錄檢索的路徑畫出來。傳統 RAG 出錯你只能重寫 prompt 猜，這裡你看得到它走錯了哪一個岔路。
還有一個學術背景值得看：OpenViking 開源的是 VikingMem 論文核心能力的一個子集，該論文《VikingMem: A Memory Base Management System for Stateful LLM-based Applications》已被 VLDB 2026 接收。VLDB 是資料庫領域的頂級會議。這在一堆「週末寫出來的 Agent 記憶工具」裡面，是少見的背書。
benchmark 數字撐得住嗎？
撐得住，但要看清楚它是「加在誰身上」的提升。
LoCoMo 是長對話記憶的標準測試。官方表格用三個 Agent 各測一次原生記憶 vs 接上 OpenViking：
| 整合對象 | 準確率變化 | 延遲變化 | Token 變化 |
|---|---|---|---|
| OpenClaw | 24.20% → 82.08%（3.39 倍） | −59.22% | −91.0% |
| Hermes | 33.38% → 82.86%（2.48 倍） | −66.10% | −34.3% |
| Claude Code auto-memory | 57.21% → 80.32%（1.40 倍） | −58.45% | −63.2% |
這張表最誠實的一行，其實是 Claude Code 那行。它的原生記憶本來就有 57.21%，接上去只升到 80.32%——1.40 倍，遠不如 OpenClaw 的 3.39 倍。
翻譯成人話：你原本的記憶方案越爛，OpenViking 幫你提升越多。那個 3.39 倍不是 OpenViking 有多神，一半是 OpenClaw 的原生記憶只有 24% 這件事撐出來的。三個 Agent 接上之後全部落在 80–83% 這個區間，這個天花板才是它真正的實力水位。
另一組是 tau2-bench 多輪任務，測的是「Agent 記住自己做過什麼」：零售 70.94% → 77.81%（+6.87pp），航空 54.38% → 66.25%（+11.87pp）。提升幅度比 LoCoMo 溫和得多，因為這裡沒有一個爛到 24% 的基準線可以對比。
跟 LightRAG、HippoRAG 比，值不值得換？
如果你在意的是延遲和索引成本，值得；如果只追求準確率絕對值，它不是第一名。
長文件 RAG 那張表（資料集包含 FinanceBench、NaturalQuestions、ClapNQ、Qasper、SyllabusQA）講得很清楚：
| 方案 | 平均準確率 | 檢索延遲 | 索引 token 成本 |
|---|---|---|---|
| Naive RAG | 53.93% | 0.13s | 2,755,356 |
| PageIndex | 36.75% | 84.60s | 5,609,206 |
| HippoRAG 2 | 44.50% | 18.83s | 124,963,618 |
| LightRAG | 76.00% | 9.19s | 62,705,469 |
| OpenViking | 66.87% | 0.19s | 8,671,538 |
LightRAG 準確率高 9 個百分點，但延遲是 48 倍、索引成本是 7.2 倍。OpenViking 的索引成本只有 LightRAG 的 13.8%。
這是很典型的工程取捨：你要最準，選 LightRAG；你要在互動式 Agent 裡面即時回應（0.19 秒 vs 9.19 秒，使用者感受完全是兩回事），選 OpenViking。做即時對話的 Agent，9 秒的檢索延遲基本上是不能用的。
為什麼你看到的星數可能是錯的？
因為大量二手內容抄的是 GitHub trending 表格，而那張表很容易抄錯列。
我今天實開 GitHub repo 頁核對，跟中文圈廣泛流傳的數字對不上：
| 項目 | 流傳版本 | 8 月 19 日實查 |
|---|---|---|
| 總星數 | 29,332（有的寫「3 萬星」） | 26.9k |
| 最新版本 | v0.2.5 | v0.4.13（2026-08-07） |
| 開源時間 | 2026 年 3 月 | 2026 年 1 月 |
| 維護狀態 | 「三月發布後回潮」 | 共 59 個 release，一個月內發了 4 個 |
其他實查數字：2.1k forks、71 watchers、1,753 commits、AGPLv3 授權。語言組成是 Python 75.4%、Rust 13.7%、TypeScript 5.7%、C++ 2.1%。
「回潮」這個標籤特別誤導人。v0.4.10（7 月 16 日）、v0.4.11（7 月 23 日）、v0.4.12（8 月 3 日）、v0.4.13（8 月 7 日）——一個月四個 release，這是持續高頻迭代，不是被人挖出來的舊項目。有中文技術媒體在 7 月 13 日記錄約 26,620 顆星，對照今天的 26.9k，五個星期大約增加兩百多顆，平均一天不到十顆。任何說它「單日暴增數百星」的敘述，都跟這條成長曲線對不上。
星數不是裝飾品。它常常就是別人推薦這個項目給你的唯一理由。理由錯了，推薦就是擲骰子。這一點我們在寫 agentmemory 那篇 的時候剛踩過一次。
現在就能動手：三種試法
按投入程度由低到高，選一個：
- 零安裝先看效果：開 OpenViking Studio（
openviking.ai/studio），官方託管的實例，有上下文遊樂場、語意搜尋和多 Agent hub，不用裝任何東西。想先確認「檔案系統式記憶」到底長什麼樣，從這裡開始。 - 裝桌面版：OpenViking Helper（beta，支援 macOS 與 Windows x64）。它會偵測本機的 OpenViking CLI、Claude Code、Codex、Cursor、Trae、OpenCode，然後幫你配置 plugin、MCP、Hook。也能解析 session 紀錄，看得到 recall、prompt 注入、MCP 呼叫這些事件實際發生在哪一步。
- 直接接進專案：
pip install openviking。接著在設定檔選 embedding 供應商：本機跑選ollama或local，雲端可選 openai、gemini、cohere 等十多家。原始碼與完整文件在 GitHub 官方 repo。
建議的驗證順序：先用 Studio 確認這套範式你接受，再用 Helper 看它在你現有 Agent 上跑得順不順，最後才動生產環境的程式碼。
誰該用？誰先別碰？
值得認真評估的：
- 做即時互動 Agent，卡在檢索延遲的（0.19 秒這個數字是它最硬的賣點）
- context 成本已經燒到心痛的（token 省 34–91%，帳單有感）
- RAG 檢索出錯但完全不知道錯在哪的（軌跡可視化就是為這件事設計）
- 同時要管記憶、文件、技能三種脈絡，受夠了各存一處的
先不要碰的：
- 做商業閉源產品的：AGPLv3 是強傳染性授權，接進去之前先問法務，這條比技術問題嚴重得多
- 現有記憶方案已經跑到 57% 以上準確率的：參考 Claude Code 那行，你能拿到的提升是 1.40 倍，不是 3.39 倍
- 純粹的單次問答場景，沒有長對話、沒有跨 session，這套分層架構是殺雞用牛刀
- Windows 使用者要注意 Helper 仍在 beta
如果你的痛點只是「換一個 Agent 就要重新解釋一次專案」，那不是 OpenViking 的守備範圍，可以看看我們寫過的 mem0 或 LoopX 狀態核心。
常見問題
OpenViking 真的不用向量資料庫嗎？
不是。它自己的 benchmark 表格把 OpenViking 的檢索方式標為 Vector retrieval，設定檔也要求你選 embedding 供應商。它放棄的是傳統 RAG 的扁平、碎片化向量儲存，改成先用語意分數鎖定目錄、再逐層往下讀。向量還在，只是不再是唯一入口。
OpenViking 是免費的嗎？授權有什麼限制？
主專案採 AGPLv3，完全開源、無功能閘、不需帳號或啟用碼。但 AGPLv3 具強傳染性：若你以網路服務形式提供修改版，需要開放對應原始碼。做閉源商業產品前務必先確認授權相容性。
接上 OpenViking 一定能讓準確率變成 82% 嗎？
不一定，提升幅度取決於你原本的方案有多弱。官方 LoCoMo 數據顯示，OpenClaw 由 24.20% 升到 82.08%（3.39 倍），但 Claude Code auto-memory 由 57.21% 升到 80.32%，只有 1.40 倍。三者接上後都落在 80–83% 區間，這個區間才是合理預期。
OpenViking 和 LightRAG 該選哪一個？
看你要準確率還是速度。長文件 RAG 測試中 LightRAG 平均準確率 76.00%、OpenViking 66.87%；但延遲分別是 9.19 秒與 0.19 秒，索引成本 OpenViking 只有 LightRAG 的 13.8%。做即時對話 Agent 選 OpenViking，做離線知識庫問答可以考慮 LightRAG。
結論：值得裝，但別為了錯的理由裝
OpenViking 是目前少數同時具備頂會論文背書、高頻迭代、和完整公開 benchmark 的 Agent 記憶方案。0.19 秒的檢索延遲配上 13.8% 的索引成本，這個組合在互動式 Agent 上是實打實的優勢。
但如果你是被「幹掉向量資料庫」這句話吸引進來的，你買到的東西跟你以為的不一樣。它真正做對的事，是給向量檢索加了一層地址——讓檢索結果帶著脈絡回來，讓出錯的時候你看得見它走過哪條路。
這一層比「換掉向量資料庫」樸素得多，也有用得多。
順帶一提，這篇文章裡每一個數字我都自己開 GitHub repo 核過，因為二手轉載給我的四項數據全部是錯的。在 AI 工具更新以週為單位的今天，這已經是必要成本，不是龜毛。
免責聲明：本文為技術工具介紹與分析，不構成任何投資建議。文中數據截至 2026 年 8 月 19 日，來自 GitHub 官方 repo 頁面與專案 README 的公開 benchmark，實際效果依你的資料與環境而異。開源專案授權條款可能變動，商業使用前請自行確認。
同主題延伸閱讀
AI 工具實測與工作流
實用工具與下一步 · 免費工具 →
發佈留言