OpenViking 是什麼？用 viking:// 管理 AI Agent Context 的導入指南

OpenViking 是什麼？用 viking:// 管理 AI Agent Context 的導入指南

OpenViking是為AI Agent設計的開源Context Database，以viking://虛擬檔案系統統一管理Resources、User Memory、Agent Memory、Session、Instructions與Skills。它保留目錄、路徑與內容層級，再結合語意搜尋，讓Agent先定位相關範圍，之後才按需讀取全文。

OpenViking 的重點不是多存一份聊天紀錄，而是把 memory、resources 與 skills 用 viking:// 組成可瀏覽的 context 結構；系統可先讀摘要，再按需求讀到完整內容。這讓團隊能追查「為何拿到這段 context」，但不會自動解決資料品質、權限或過期內容問題。本文以官方 repository 為準，說明何時值得試用、怎麼避開常見誤解。

OpenViking最具辨識度的能力，是L0／L1／L2分層Context與可觀察的遞迴檢索。它不是一般聊天記憶外掛，也不負責完整Agent Workflow與Checkpoint執行；更接近可被Claude Code、Codex、OpenClaw、Hermes或LangGraph使用的外部Context Layer。

文章實體化：OpenViking 是什麼？用 viking:// 管理 AI Agent Context 的導入指南

本文以「OpenViking 是什麼？用 viking:// 管理 AI Agent Context 的導入指南」為主線，補回模型／工具、輸入輸出、版本、成本、測試與使用邊界，讓技術名詞回到可執行的工作流程。

• 核心元件：把標題中的模型、工具、格式或協定對應到實際輸入、輸出與依賴。
• 驗證方法：記錄版本、資料、環境、基準、錯誤案例與人工檢查，避免只引用功能宣稱。
• 治理邊界：說明權限、資料保存、成本、失敗回復與何時需要人工介入。

涉及版本、價格或 API 行為時，以文章原始資料與供應商最新文件核對。

先理解它解決的問題

• viking://提供Resources、User、Agent與Session等統一Scope。
• L0是一句摘要，L1提供Overview，L2保存原始完整內容。
• 檢索結合檔案路徑、目錄遞迴與語意搜尋。
• Resources、Memory與Skills保留不同生命週期與目錄。
• OpenViking仍需要模型服務、Embedding、權限設計與外部Agent Runtime。

viking://檔案系統如何組織Context？

viking://
├── resources/
│   └── project-a/
├── user/
│   └── memories/
│       ├── preferences/
│       ├── entities/
│       └── events/
├── agent/
│   ├── memories/
│   │   ├── cases/
│   │   └── patterns/
│   ├── instructions/
│   └── skills/
└── session/{session_id}/
    ├── messages.json
    ├── checkpoints/
    ├── summaries/
    └── tools/

<

p class=”wp-block-paragraph”>官方文件將公開Scope分成resources、user、agent與session。User與Agent短路徑會依目前請求身份展開到實際Namespace，避免不同使用者或Agent直接共用同一記憶目錄。

Scope	用途	生命週期
resources	文件、Repository、網頁與專案資源	長期
user	使用者偏好、實體與事件記憶	跨任務
agent	Agent案例、模式、Instructions與Skills	跨任務
session	訊息、工具、摘要與Checkpoint	Session範圍

L0、L1、L2分層載入

層級	內容	適用階段
L0 Abstract	約一句話的極短摘要	快速判斷是否相關
L1 Overview	核心資訊、結構與使用情境	規劃與候選選擇
L2 Details	原始全文、程式碼或完整資料	深度閱讀與最終驗證

每個目錄可以包含.abstract.md、.overview.md、.meta.json與關係資料。Agent先讀L0與L1，只有真正需要時才打開L2，降低大量文件直接進入Prompt的成本。

分層摘要不能取代原始資料。價格、權限、程式行為與正式決策仍要回到L2與來源版本核對；L0與L1比較適合導航與規劃。

OpenViking和一般Vector Database差在哪？

比較	一般Vector Database	OpenViking
基本單位	Chunk、Embedding與Metadata	目錄、檔案、URI與分層摘要
組織	偏平面集合	檔案系統層級
檢索	向量相似度與Filter	路徑、目錄遞迴、Grep與語意搜尋
資料類型	以知識文件為主	Resources、Memory、Session與Skills
可觀測性	常只看到最後Chunks	可檢查定位與目錄檢索軌跡

OpenViking仍使用向量索引與模型摘要。差異是它在語意檢索外保留確定性路徑、目錄與Context類型，使Agent能像瀏覽檔案一樣逐步探索。

Resources如何加入與更新？

1. 解析網址、文件、Repository或上傳內容。
2. 建立暫存目錄與資源樹。
3. 處理URI衝突與目錄關係。
4. 寫入持久儲存。
5. 產生L0、L1摘要與Vector Index。
6. 需要時建立Watch Task進行增量更新。

官方API文件顯示，Resource語意處理可非同步執行，Watch Task可依間隔重新加入指定資源。企業使用時仍需確認來源授權、更新頻率、刪除與索引一致性。

User Memory與Agent Memory

記憶	內容	範例
User Memory	Profile、Preferences、Entities、Events	語言偏好、重要人物、行程事件
Agent Memory	Cases、Patterns、Tools與經驗	某類任務成功方法、工具錯誤模式
Session	當前訊息、工具、摘要與Checkpoint	這次研究進度與最近錯誤

自動記憶抽取可能記錯。使用者聲明、系統事實、文件內容與模型推論應分開標示，並保存來源、時間、信心、Scope與刪除方式。OpenViking提供儲存與分類能力，實際治理仍由部署方負責。

Skills如何管理？

Skills會加入viking://agent/skills/，可與Resources和Memory共同檢索。這讓Agent能依任務找到程序知識，但不代表Skill自動取得Tool權限。

• Skill內容與腳本需要版本與來源。
• 第三方Skill要審查Prompt Injection與依賴。
• Tool、網路與資料權限由Harness強制。
• 更新後重新執行觸發、輸出與安全測試。

AI Skills的Task Contract與治理，可閱讀AI Skills完整指南與企業AI技能庫治理。

OpenViking負責什麼、不負責什麼？

負責	不直接負責
Context儲存、路徑與分層摘要	完整Agent決策迴路
Resources、Memory、Session與Skills	業務Workflow與人工工作台
語意與檔案式檢索	正式IAM與企業Policy
檢索Trace與Context觀測	所有Tool副作用與Rollback
資源更新與索引	業務資料本身的正確性

LangGraph可以負責Graph State、Durable Execution與Workflow；OpenViking提供外部Context與記憶。Agent Harness則負責工具、權限、驗證與回復。三者是不同層級。

部署需求與限制

• 官方Quick Start目前要求Python 3.10以上。
• 從原始碼建置部分元件需要Rust Toolchain與C／C++編譯器。
• 需要VLM或LLM能力產生摘要與解析媒體。
• 需要Embedding Model建立語意索引。
• 自架時要管理模型端點、儲存、權限與備份。
• 主專案採AGPLv3，部分CLI與Examples採Apache 2.0，商業部署需檢查授權。

導入前要先計算摘要生成、Embedding、更新與檢索成本。大量匯入全部聊天與硬碟，可能先製造高成本Context垃圾場；應從一個專案與高價值Resources開始。

最小導入流程

1. 選一個Repository或文件集合。
2. 建立使用者、Agent與專案Namespace。
3. 加入少量正式Resources與Skills。
4. 檢查L0、L1摘要是否正確。
5. 測試路徑、Grep與語意檢索。
6. 記錄實際載入Token與任務成功率。
7. 建立更新、衝突、刪除與重新索引流程。
8. 通過後再加入Memory與更多專案。

AI記憶不同層級的分工，可閱讀AI記憶怎麼分層？；Context Builder如何選擇OpenViking內容，可閱讀Context Engineering怎麼做？。

常見問題

OpenViking可以取代RAG嗎？

它能承擔Resources檢索與Context管理，但仍使用語意索引。它的差異是加入檔案系統、分層摘要、Session、Memory與Skills。

OpenViking可以取代LangGraph嗎？

不能直接取代。LangGraph主要負責狀態圖與Durable Execution，OpenViking主要負責外部Context資料與檢索。

自動記憶會不會記錯？

會。需要來源、信心、版本、Namespace、人工修正與失效機制，不能把抽取結果直接視為事實。

官方資料

• OpenViking GitHub Repository
• Viking URI官方說明
• Resources與Skill API流程
• OpenViking官方文件

OpenViking的價值，在於讓Context有位置、層級與可觀察檢索路徑。它是否適合部署，仍要回到任務成功率、模型與索引成本、權限、資料品質與維護能力。

增量：OpenViking 的重點，不只是用 URI 存內容，而是讓 Agent Context 具備可定位、可分層的結構

把 context 想成資料夾、資源與狀態的階層，可以讓 Agent 不必每次從空白 prompt 開始。viking:// 這類命名方式的價值，在於它把資料位置、來源、生命週期與存取方式放進一個可追蹤的介面。

Context 管理仍要處理摘要、索引、權限、版本與淘汰。路徑可讀不代表內容仍然新鮮；同一份資源被不同任務使用時，也要知道它是原始文件、摘要、推論還是暫時狀態。

導入時可先建立幾種 context contract：任務背景、工具說明、使用者偏好、階段產物與外部資源。每一種都定義 schema、更新者、保留期限與衝突處理，避免所有內容最後又變成一個無法管理的大記憶庫。

評估要看 cache hit、取證準確度、stale context、權限隔離、刪除與恢復。OpenViking 的價值只有在它讓 Agent 更容易找到正確 context、少帶無關資料、並能在錯誤時追溯來源時才成立。