火山引擎（字節跳動）開源的 OpenViking 把 agent 的記憶、資源、技能統一成檔案系統。LoCoMo10 測試中任務完成率提升 49%、token 成本降 83%。目前 22.3k stars，採用 AGPLv3。
目錄+
AI agent 的上下文管理一直是個老問題：記憶放在 vector DB、資源放在檔案系統、技能寫在 prompt 裡、session 存在 Redis——四套儲存、四套 API、四個要 debug 的地方。火山引擎（字節跳動）開源的 OpenViking 提出一個直接的解法：把所有東西當作檔案系統處理。
核心想法：viking:// URI
OpenViking 用 viking:// URI 組織所有上下文，結構類似 Unix 檔案系統——有階層、有路徑、有權限。Agent 的記憶不是塞進向量 DB 的一堆 chunk，而是結構化的目錄樹。
這個設計最大的好處是可觀察：可以列目錄、看檔案、追蹤修改，像 debug 一個專案那樣 debug agent 的上下文狀態。
分層載入：L0 / L1 / L2
OpenViking 為每個上下文節點維護三個版本：
- L0 抽象摘要：一兩句話，用來快速判斷節點是否相關
- L1 概述：段落級內容，用來定位
- L2 完整細節：實際資料，只在確定需要時才載入
這個設計直接回應「context 爆量」的問題——agent 不必每次把完整內容拉進 prompt，只在真正需要時深入讀取。
基準測試結果
LoCoMo10 基準（vs baseline，百分比）
在 LoCoMo10 資料集（1,540 個長期對話案例）上：
- vs baseline：任務完成率提升 49%、token 成本降 83%
- vs LanceDB：完成率提升 17%、token 節省 92%
49% 和 83% 同時出現並不常見——通常提升效能意味著消耗更多 token，提升效率則以犧牲品質為代價。OpenViking 的分層載入同時做到了兩件事。
五個解決的問題
| 問題 | 解決方法 |
|---|---|
| 上下文分散 | 檔案系統統一抽象 |
| Context 爆量 | L0/L1/L2 分層載入 |
| 檢索不準 | 目錄遞迴檢索 + 語意搜尋 |
| 不可觀察 | 視覺化檢索軌跡 |
| 記憶侷限 | 自動從 session 擷取記憶 |
技術細節
- 語言：Python 84.6% + Rust 5.7% + C++ 4.6%
- 支援模型：OpenAI、豆包、LiteLLM（Anthropic、DeepSeek、Gemini、Ollama 本地）
- 需求：Python 3.10+、Go 1.22+（AGFS 用）、GCC 9+
- 授權：主專案 AGPLv3、CLI 和範例 Apache 2.0
社群規模
22.3k stars、1.6k forks——從數字來看，OpenViking 不是小眾實驗專案，而是已經被廣泛採用的基礎建設。字節跳動把它作為 agent 上下文層開源，背後應該有實際產品（豆包 / Viking 相關產品）驗證過。
結語
OpenViking 的「檔案系統抽象」對 agent 工程而言是一個重要的心智模型轉換。把上下文當作可遍歷、可分層、可觀察的結構，而不是一堆 embeddings，agent 的行為因此變得更可理解、可 debug。
如果你在建構 agent 系統，尤其需要長期記憶與複雜上下文管理的那種，OpenViking 值得認真評估。49% 的完成率提升加 83% 的成本降低，不是拿來嘴的數字。