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% 成本降低不是拿來嘴的數字。