Ian Chou's Blog

CtxFST CH21 - 整合 OpenClaw：把 Agent Skills 升級成 Semantic World Model

CtxFST CH21：整合 OpenClaw，把 Agent Skills 升級成 Semantic World Model

走到 CH20 為止，CtxFST 本身其實已經長成一個很完整的世界模型 runtime 了。

它現在已經有：

到這裡，一個很自然的問題就會冒出來：

這套東西如果不只在 CtxFST repo 裡跑，而是裝進一個真正的 agent runtime，例如 OpenClaw，會發生什麼事？

這就是 CH21 要回答的問題。

而答案其實很令人興奮：

把 CtxFST 裝進 OpenClaw，不只是多一個 skill，而是讓 OpenClaw 開始具備 semantic world model 能力。

先講一句最短的結論

這一章最值得記住的一句話是：

OpenClaw 原本擅長的是 skills orchestration；整合 CtxFST 之後，它開始多出一層 semantic world model substrate。

這個差別非常大。

因為它意味著 OpenClaw 不再只是：

而是開始能：

也就是說，這不是單純「在 OpenClaw 裡多一個 repo」，而是讓它的 skill system 開始有世界模型層。

為什麼 OpenClaw 是一個很適合的整合點？

因為 CtxFST 和 OpenClaw 之間，有一個很關鍵的共通介面：

SKILL.md

這件事非常重要。

OpenClaw 本來就支援：

而 CtxFST v2.x 剛好也把整個 world model contract 很多部分壓在 SKILL.md 上：

所以兩者之間其實天然就有一個相容層。

這代表整合時不需要發明一套全新 protocol，而是可以用一個很實際的方式：

直接把 skill-chunk-md 放進 OpenClaw 的 skills/ 目錄，讓它作為 AgentSkills-compatible skill 被載入。

這個路徑非常漂亮，因為它讓整合成本很低，但能力提升很大。

最簡單的整合方式：把 skill-chunk-md 放進 skills/

整合上最直觀的做法其實很簡單：

openclaw/
├── skills/
│   ├── some-existing-skill/
│   ├── cognitive-memory/
│   ├── ontology/
│   └── skill-chunk-md/
│       ├── SKILL.md
│       ├── scripts/
│       ├── tests/
│       └── ...

當 skill-chunk-md 被放進 OpenClaw 的 skills/ 目錄之後，OpenClaw 會把它當作一個標準 SKILL.md skill 載入。

這一步的價值不只在於「可以被叫用」，而在於：

CtxFST 整套 world model metadata 會開始進入 OpenClaw 的 skill 解譯流程。

也就是說，OpenClaw 不只是讀到一個 skill 名稱，而是讀到一個帶有：

的 skill 定義。

這就讓 OpenClaw 原本的技能系統開始往更深的語意層下沉。

這裡最關鍵的是什麼？不是安裝，而是語意相容

要強調的是，整合的難點其實不是「檔案怎麼放」，而是「語意怎麼對上」。

而 CtxFST 之所以能很自然地裝進 OpenClaw，是因為它和 OpenClaw 在 skill contract 上剛好高度相容：

OpenClaw 能讀的東西 CtxFST 提供的東西
SKILL.md frontmatter SKILL.md frontmatter
觸發時機與技能說明 description, progressive disclosure
前置條件 / 後置條件 preconditions, postconditions
skills 之間的串接線索 related_skills
context-aware 呼叫 related_nodes, world-state-driven routing

換句話說，CtxFST 不是硬塞進 OpenClaw，而是剛好把 OpenClaw 原本 skill 介面往更高維度延伸。

這也是為什麼我會說：

這次整合不是 plug-in 式的小功能，而是 OpenClaw skill runtime 的一次能力升級。

整合後，OpenClaw 會多出哪三層能力？

如果用最清楚的方式來拆，我會說 OpenClaw 至少多出三層能力。

1. Semantic Graph Layer

這是最直接的一層。

整合 CtxFST 之後，OpenClaw 不再只是面對一堆 text chunks 或技能說明，而是可以透過 CtxFST 的 pipeline 建出：

如果再接上：

這一層就能支援：

也就是說，OpenClaw 本來如果比較像在操作一組 skills，整合後就會開始比較像在操作一個 semantic graph-backed world。

2. Agent Loop Layer

這是第二層，也是我覺得最關鍵的一層。

一旦 OpenClaw 能透過 callback 或工具調用去呼叫：

它就不再只是單次調用 skill，而是能進入：

read world state
-> select next skill
-> execute
-> write back postconditions
-> append graph edges
-> replan

這就是真正的 world model loop。

而這件事對 OpenClaw 的提升非常大，因為它代表：

OpenClaw 不再只是在 orchestration skills，而是在一個會演化的語意世界裡持續規劃。

3. Memory + Planning Layer

第三層則是把 OpenClaw 既有的持久化記憶和 CtxFST 的 graph-aware planning 接起來。

例如 OpenClaw 自己如果已經有：

那 CtxFST 可以補上的是：

也就是說，記憶不再只是「存下來」，而是開始被拿來：

驅動下一步的 graph-aware decision making。

這點非常關鍵。

這代表 OpenClaw 會從什麼，變成什麼？

我會這樣總結這次整合的本質。

沒整合前

OpenClaw 比較像：

但它對「世界」的表示仍然比較鬆散。

整合後

OpenClaw 開始更像：

它不只知道：

還開始知道：

這個差別，就是世界模型層的差別。

一張圖看懂整合後的架構

flowchart LR
    A[OpenClaw Runtime] --> B[skills/skill-chunk-md/SKILL.md]
    B --> C[CtxFST World Model Layer]
    C --> D[world_state.py]
    C --> E[skill_selector.py]
    C --> F[agent_loop.py]
    C --> G[entity graph / chunks / entities]
    G --> H[LanceDB / HelixDB]
    A --> I[persistent memory]
    I --> D
    F --> D
    F --> G

這張圖裡最重要的不是檔案名稱，而是 flow：

這就讓 OpenClaw 從「技能系統」開始長成「技能 + 世界狀態 + 圖譜 + 規劃」的系統。

為什麼這比一般 RAG integration 更有價值？

因為一般把某個系統接到 agent 裡，常常只是：

但 CtxFST 整合進 OpenClaw 之後，不只是 retrieval 升級而已。

它真正做的是：

把 OpenClaw 的技能系統接上一個可操作的世界模型層。

所以提升不只在：

還在：

這些都是一般 RAG integration 沒辦法自然帶來的。

CallbackExecutor 在這裡扮演什麼角色？

如果要真的讓 OpenClaw 調用 CtxFST runtime，CallbackExecutor 會是一個很自然的整合點。

因為它讓 agent_loop.py 不用自己知道 OpenClaw 的內部執行方式，而只需要：

把某個 OpenClaw skill execution function 包成 callback。

這會讓整合變得很乾淨：

這種設計很重要，因為它避免把兩個系統硬耦合在一起。

也就是說，OpenClaw 可以把 CtxFST 當成：

而不一定要把整個內部架構重寫掉。

這和 OpenClaw 既有的 memory / ontology skills 有什麼關係？

這點我覺得很值得講。

如果 OpenClaw 本來就已經有像：

這類 skills，那麼 CtxFST 整合進去之後，不會是重複造輪子，而更像是：

把這些能力往 production-grade world model 再推進一步。

為什麼？

因為 CtxFST 補上的不是單一功能，而是一整條能力鏈：

所以它可以被視為：

把 OpenClaw 原本偏知識管理、偏技能管理的能力，升級成可規劃、可回寫、可互動的 semantic world model stack。

這不是替代，而是擴張。

一個很實際的使用場景：長期任務規劃

如果要用一句話講這次整合最適合的場景，我會說：

長期任務規劃。

例如：

在這些場景裡，最重要的不是單次回答對不對，而是：

這正是 CtxFST 擅長的地方。

而 OpenClaw 如果接上這一層，就會在這類任務上變得特別有力。

這一章真正想說的是什麼？

我覺得最核心的一句話其實是：

CtxFST 裝進 OpenClaw，不只是讓 OpenClaw 多一個 skill，而是讓它的 skills 開始共享同一個語意世界。

這句話很重要。

因為沒有 world model 時，skills 往往只是：

有了 CtxFST 之後，這些 skills 開始能：

這就是從「技能集合」走向「共享語意世界」的差別。

這一步也意味著什麼？

如果把整個系列拉高來看，這其實是很關鍵的一步。

前面 CH1 到 CH20 比較像是在把 CtxFST 自己做完整：

到了 CH21，第一次真正往外部 agent runtime 接。

也就是說，這一章的意義不是再多一個 feature，而是：

證明 CtxFST 不只是能自洽地工作，也能成為別的 agent 系統的 world model backend。

這很重要，因為這代表它開始有平台價值，而不只是 repo 內部價值。

結語：從這一章開始，CtxFST 不只是自己的 world model，而是別人的 semantic substrate

如果 CH20 的重點是：

planner 已經能進入 human-in-the-loop

那 CH21 的重點就是：

這整套東西已經不只屬於 CtxFST 自己，而是可以作為其他 agent runtime 的 semantic substrate。

這是很重要的成熟標誌。

因為一個系統真正有生命力，往往不是只靠自己能跑，而是：

它能不能成為別的系統的底座。

而 CtxFST 整合進 OpenClaw 之後，開始具備的正是這種能力：

也就是說，它不只是能做 semantic world model。

它已經開始能：

把 semantic world model 能力輸出給別的 agent 系統。

而這，正是我認為 CH21 最值得記住的地方。

參考整合方向

📌 CH20 讓 planner 變成可協作介面，而 CH21 則把這套介面帶進 OpenClaw，讓 agent skills 開始共享同一個 semantic world model。