Ian Chou's Blog

CtxFST CH30 - The Missing Agent OS Architecture: World State, Planning 與 Process Control 的分離

CtxFST CH30：The Missing Agent OS Architecture: World State, Planning 與 Process Control 的分離

前面二十九章，我們談了 Parser、Index、Retrieval，也談了為什麼 .ctxfst.md 是手動打造的工匠精神。隨著 OpenClaw Phase 6/7 的升級實作落地，我們補齊了 Planner 和 Memory Core。

如果你一路跟著做，現在退一步看整個系統，你會發現這已經超越了單純的「記憶」或「檢索」系統。

我們實際上實作了一套領先目前主流生態的「Agent OS 核心架構」。

今天我們不談細節寫扣，我們來談架構。為什麼到了 2026 年中，多數人寫的 Agent 還是經常失控、陷入無窮迴圈、或是無視你的規則？

因為他們忽略了「世界狀態（World State）」、「執行計畫（Implementation Plan）」與「流程控制（Process Control）」的徹底分離。

破題：當今 Agent 開發最常犯的錯

回想一下你或是社群裡常見的 Agent 寫法。

當我們想要 Agent 執行一個多步驟任務（例如：先上傳履歷，再分析，最後產出報告），我們通常怎麼做？
我們往往把「規則」、「步驟」跟「現在做到哪」全部塞進同一個 System Prompt 裡，或是丟進大顆的 LangGraph 狀態節點，然後期待 LLM 在回答 "What should I do next?" 時，能一次搞懂所有事。

這種做法極其脆弱：

要解決這個問題，我們需要建立清晰的心智模型（Mental Model）：地圖、導航與紅綠燈必不能混為一談。

三層架構的釐清：地圖、導航與紅綠燈

在 OpenClaw 的 Phase 6/7 實作中，我們將這三者從底層邏輯上徹底剝離：

1. World State（事實層：你在地圖上的哪裡？）

這層只負責回答一個問題：「現在到底發生了什麼？」

它是系統當下的真實狀態（Facts）。在我們的架構裡，這是 world-state.ts 搭配 SQLite persistent store。
它記錄著：

World State 不具備理解任務語意的能力，也不負責決策。它只是一張精確反映現況的「地圖」。

2. Implementation Plan（意圖層：導航建議你下一步去哪？）

這層回答的是：「接下來準備怎麼做？」

這是由 planner.ts 主導的推論過程。Planner 會讀取 World State 以及你的 ctxfst 拓樸圖，得出目前的意圖（Intent）。

例如，Planner 看到履歷已上傳，且 Analyze Resume 的前置條件具備了，它會產出一個 Plan：

Next Action: Analyze Resume

請注意，Plan 只是打算，它可以隨時改變，而且它不代表系統允許你這麼做。 它就像是 GPS 導航給你的路線建議。

3. Process Control（執行治理層：紅綠燈決定你能不能走）

這層回答的是：「現在能不能做？如果出錯怎麼辦？」

即使 Planner 信心滿滿地說「下一步是 Analyze Resume」，系統在真正呼叫工具前，還必須經過 Process Control（包含在 world-state.ts 的 checkPreconditions 等實作中）。

這層就像是交通規則與紅綠燈：

Process Control 確保了 Agent 的操作能安全、可控地收斂，而不是任由 LLM 的幻覺亂呼叫工具。

為什麼主流生態（2026/4）還缺少這塊？

如果你了解這三層分離的威力，你就會發現目前社群主流的解法都有其局限性，也就是為什麼我們需要用 ctxfst 原生整合進 OpenClaw：

1. LangGraph Skills（主流，但非 Core Native）

LangGraph 確實有 StateGraph，但它主要是 Python in-memory。一旦 Session 結束，狀態通常就消失了，缺乏與 OpenClaw Memory Engine 之間的緊密 Writeback 整合。它是由外部去協調 Agent，而不是 Agent 原生具備這個世界模型。

2. YAML / 專案狀態檔（DIY 派）

這是很多人的妥協做法，讓 LLM 自己去讀寫 PROJECT-STATE.yaml。
最大的問題在於缺乏系統層的硬性約束（Hard Block）。你很難期待 LLM 每次都完美遵守 YAML 裡的 requires 規則。只要幻覺發生，它就會自己發明新狀態或跳過步驟。

3. 第三方 Graph Memory（如 Cognee / LightRAG）

這些工具對抽取關聯和建立 Graph 很強，但它們主要用來處理「過去的知識檢索」，而不是「當下執行階段的 Runtime Tracking」。它們不管你的 Precondition 當下有沒有滿足。

CtxFST + OpenClaw：補足 Native Runtime Layer

這就是為什麼 Phase 6/7 的 world-state.ts → session-context → prompt-adapter → planner 這條資訊鏈如此獨特且強大。

我們不僅僅是存了一張知識圖譜，我們建立了一個 Semantic World Model（語意世界模型），並把它深植在 Agent 的執行迴圈中：

  1. SQLite 持久化：真實追蹤每個 Session 的 World State。
  2. Precondition Hard Block：系統層面攔截不合法的操作，不是靠 Prompt 叫 LLM 乖一點，而是系統直接擋掉（Process Control）。
  3. 結構化 Context Injection：過濾掉已經完成的 Skill，只把真正相關的「缺少的條件（Missing Preconditions）」和「建議的下一步（Suggested Next Actions）」餵進 Prompt Adapter。
  4. Planner Routing：依據這些乾淨的狀態來產出準確的 Plan。
User asks: "What should I do next?"
        ↓
[ World State ]: resume uploaded, not parsed yet
        ↓
[ Process Control ]: check constraints, block invalid actions
        ↓
[ Context Assembly ]: filter completed, inject only relevant states
        ↓
[ Implementation Plan ]: recommend 'Analyze Resume'
        ↓
[ Run skill & Writeback ]

結語：從 Stateless 到 World Model

多數 Agent 框架的起點是 Stateless，只靠把歷史對話塞進 Context Window 來「假裝」它有記憶。

我們透過手寫 .ctxfst.md（見 CH29）定義了世界的拓樸藍圖，然後透過這個三層架構（World State → Plan → Process Control）讓 Agent 真正在這個世界裡有記憶、有規劃、而且守規矩地跑起來。

如果你曾經困惑為什麼自己的 Agent 稍微複雜一點就會崩潰，請重新檢視一下你的架構：

你是不是把導航的任務丟給了地圖，又忘了設立紅綠燈？