向量搜尋已是過去式：OpenSpace 用 Graph + 自進化 Skill 重新定義 AI 知識庫

你的 RAG pipeline 上線三個月了，還是每次查詢都在重複推理相同的流程。向量資料庫找回了相似段落，LLM 重新組織了一遍答案，token 計費繼續跳。同樣的問題，同樣的成本，沒有任何學習發生。

這不是 RAG 的問題，這是架構層級的設計缺陷：你的系統沒有「記住如何做事」的能力，只有「找到相似資料」的能力。兩件事根本不同。

HKUDS（香港大學 Data Science 研究組）開源的 OpenSpace 正在解決這個問題。它的核心命題是：agent 應該從每次成功執行中提煉出可複用的技能，並把這些技能分享給其他 agent，形成集體知識網路。在真實世界的 220 個跨職業任務測試中，它把 token 消耗壓低了 46%，同時讓任務品質超過最佳 baseline 30 個百分點。

你的 RAG 正在做三件浪費的事

在進入 OpenSpace 之前，先把問題說清楚。現有的 RAG 工具鏈在三個層面製造了結構性浪費：

Token 浪費。 每次查詢，agent 都重新推理解題路徑。即使你上週已經完整解決了「把 PDF 轉換為結構化 JSON」這個問題，下次遇到類似任務，LLM 還是從零開始思考。Prompt template 沒有記憶，向量索引只存了資料，沒有存解題方法。

知識孤島。 你的 agent A 解決了一個困難的 API 報錯處理流程，但這個知識永遠留在 A 的執行日誌裡，agent B 永遠不知道。每個 agent 在孤立地累積經驗，沒有任何跨 agent 的知識流動機制。

技能退化。 API 改版了、工具的行為變了，但你的 prompt template 沒有自動更新機制。六個月前寫好的解題流程逐漸失效，而你不知道，直到 production 出了問題。

OpenSpace 把這三個問題當作架構的一階需求，而不是事後補丁。

OpenSpace 是什麼：自進化 Skill Engine

OpenSpace 的定位是「AI agent 的自進化技能引擎」。它不替換你的 LLM 或向量資料庫，而是在 agent 執行層和知識儲存層之間插入一個新的抽象：Skill。

Skill 是什麼？它是 agent 解決特定類型任務的完整流程描述——包含工具調用序列、錯誤處理模式、品質驗證邏輯。不是 prompt，不是 embedding，而是結構化的可執行知識。

OpenSpace 的 Skill 分三個維度管理：

發現（Discovery）：當新任務來臨，先搜尋現有 Skill 資料庫是否有可複用的方案。搜尋機制結合 BM25、embedding 相似度和 LLM 排名，三層 hybrid search 確保找到真正適合的 Skill，而不是語意相近但邏輯不符的雜訊。
執行（Execution）：呼叫選定 Skill，同時記錄完整的執行軌跡——工具調用成功率、代碼執行狀態、品質指標。
進化（Evolution）：根據執行結果決定 Skill 是否需要更新或衍生新版本。

整個系統透過 MCP（Model Context Protocol）暴露介面，因此對現有 agent 完全透明。

三模式進化引擎：Skill 如何自我更新

自進化是 OpenSpace 最核心的差異化設計，分為三種觸發模式：

Loading diagram...

FIX 模式是最常被觸發的進化。當品質監控偵測到 Skill 的執行成功率下降——工具 API 改了、依賴項更新了、環境變數失效——系統自動分析失敗軌跡，就地修復 Skill 的指令描述，不需要人工介入。

DERIVED 模式用於知識特化。假設你有一個通用的「網頁資料擷取」Skill，某次執行中 agent 發現了一個針對特定平台的更高效路徑，DERIVED 模式會從原始 Skill 分叉出一個特化子版本，原版保持不動，新版進入資料庫供後續相同場景直接調用。

CAPTURED 模式是知識擴張的引擎。每當 agent 完成了一個資料庫中沒有先例的任務，且執行過程品質達標，CAPTURED 模式自動把完整的執行模式提煉成新 Skill，加入本地庫，並可選擇推送到 Cloud Community 分享給其他 agent。

系統架構：從 Grounding Layer 到 Cloud Community

OpenSpace 系統架構圖，展示從 Agents 層到 MCP Interface、Skill Engine、Grounding Layer 和 Cloud Skill Community 的完整層次結構 — 四層架構：最上層是各類 Agent，透過 MCP 介面連接 Skill Engine，向下接 Grounding Layer 執行工具，向右同步 Cloud Skill Community

整體架構分為四個層次：

最上層是 Agents 層，支援 Claude Code、Codex、OpenClaw、nanobot 以及任何可以整合 MCP 的自訂 agent。

MCP Interface 是統一入口，支援 stdio、SSE、HTTP 三種傳輸模式，讓現有的 agent 設定只需要加幾行 JSON 就能接入。

Skill Engine 是核心，包含技能發現、品質監控、三模式進化引擎，以及本地 SQLite 持久化層。LiteLLM 作為多模型路由層，讓 Skill Engine 不綁定特定 LLM 供應商。

Grounding Layer 在底部，統一封裝了四種執行環境：Shell 命令、GUI（Anthropic Computer Use 介面）、MCP 工具調用、以及網頁自動化。

右側的 Cloud Skill Community 是集體智慧層：agent 可以把高品質 Skill 推送到 open-space.cloud，也可以搜尋社群貢獻的 Skill，支援公開、私有、團隊三種存取控制。完整的版本 DAG 讓每個 Skill 的演化歷史都可追溯。

數字說話：GDPVal Benchmark

OpenSpace 在 GDPVal 測試集上的表現值得仔細拆解。這個 benchmark 包含 220 個真實世界的跨職業任務，涵蓋 44 種職業——不是刻意設計的 AI 友好題目，而是實際工作場景。

GDPVal Benchmark：Phase 1 vs Phase 2 任務收益對比（基準值=100）

測試分兩階段：Phase 1 是冷啟動，50 個任務從零開始，系統在執行過程中自動進化出 165 個 Skill，主要集中在檔案格式處理（44 個）、執行錯誤恢復（29 個）、文件生成（26 個）。

Phase 2 是熱重跑：同樣 50 個任務，但這次有 Phase 1 積累的 Skill 資料庫可用。結果是：token 消耗從基準降到 45.9%，品質分數從 40% 區間跳到 70.8%，任務收益是使用相同 backbone LLM（Qwen 3.5-Plus）的 ClawWork baseline 的 4.2 倍。

這組數字說明的不只是「技能複用有效」，更重要的是：Phase 2 的品質提升幅度大於 token 節省幅度。換句話說，複用不是在「用更少資源做更差的事」，而是真的在「用更少資源做更好的事」。已經驗證過的 Skill 帶來了更穩定的執行路徑，減少了試錯的浪費。

5 分鐘接入你的 Agent

如果你已經有一個支援 MCP 的 agent 環境，接入 OpenSpace 的成本非常低：

git clone https://github.com/HKUDS/OpenSpace.git
cd OpenSpace
pip install -e .

在你的 agent MCP 設定檔加入：

{
  "mcpServers": {
    "openspace": {
      "command": "openspace-mcp",
      "env": {
        "OPENSPACE_HOST_SKILL_DIRS": "/path/to/your/agent/skills"
      }
    }
  }
}

OPENSPACE_HOST_SKILL_DIRS 指向你現有的 skill 目錄，OpenSpace 會在執行過程中逐步擴充這個目錄的內容。冷啟動後，你會發現目錄裡開始出現自動生成的 Skill 檔案。

如果你想先看效果再整合，也可以作為獨立的 co-worker 直接執行：

openspace --query "把這個 CSV 裡的日期格式統一轉換成 ISO 8601"

React Dashboard 在 localhost:8080 提供視覺化介面，可以瀏覽 Skill 的版本歷史和執行統計。

支援平台：Claude Code、Codex、OpenClaw、nanobot，以及任何暴露 MCP 介面的自訂 agent。LiteLLM 路由層讓你可以選擇背後使用的 LLM——不強制綁定特定模型。

批判視角：Graph RAG 的邊界在哪裡

OpenSpace 的架構設計優雅，但有幾個邊界需要誠實交代。

冷啟動成本仍然存在。 Phase 1 的 50 個任務是純成本投入，Skill 資料庫從空白開始，沒有現成知識可用。對於任務分布高度離散的使用場景（每次都是全新類型的任務），自進化的累積效益會大幅降低——你付出了記錄和分析的開銷，但 Skill 複用率趨近於零。

SQLite 的規模上限。 本地 SQLite 作為持久層對個人或小團隊使用完全夠用，但如果 Skill 資料庫擴張到數萬個條目，或多個 agent 需要高並發讀寫，SQLite 的鎖定機制會成為瓶頸。目前官方沒有 PostgreSQL 等替代後端的現成方案。

Skill 品質的評估依賴仍然是 LLM。 進化引擎的品質判斷最終還是由 LLM 執行，這意味著評估本身的成本和準確性受制於你使用的模型。GDPVal 測試使用 Qwen 3.5-Plus，換成更小的模型，品質分數的可靠性可能下降。

開放社群 Skill 的安全性問題。 Cloud Community 的公開 Skill 目前沒有明確的沙箱隔離或惡意 Skill 過濾機制的詳細說明。在生產環境引入他人貢獻的 Skill 之前，需要自行做執行隔離。

這些不是否定 OpenSpace 的理由，而是在評估是否適合你的使用場景時，需要加入考量的真實約束。

你的知識庫應該越用越聰明

向量搜尋解決了「找到相似資料」的問題，但沒有解決「記住如何做事」的問題。這兩件事的差距，正是 OpenSpace 試圖填補的空間。

5,900 顆 GitHub stars、726 個 forks、MIT 授權——HKUDS 的研究成果是完全開放的，你可以在自己的任務集上驗證 Phase 1 → Phase 2 的進化效益，不需要相信任何測試報告。

如果你的 agent 每天在重複相似的任務類型，且你有耐心投入一批冷啟動成本，OpenSpace 值得嚴肅評估。