開場故事

一路看到第 20 天，最常出現的一種感覺就是：

我好像每一篇都看懂了，但它們加起來到底長什麼樣？

這其實很正常。

因為 OpenClaw 不是那種單點爆破就看懂的系統。
它比較像一座城市：

• 城門要先認人
• 工廠要知道怎麼排隊
• 檔案館要知道什麼該留、什麼該壓縮
• 夜班和排程要知道自己怎麼進場
• 能力卡要知道怎麼進到這一輪的上下文

所以第 20 天我想做的不是新主題，而是收斂。

前 20 天收斂，把 OpenClaw 畫成一張地圖

今天要解的問題

• 前 20 天到底在講哪幾條主線？
• 哪些概念是 OpenClaw 的骨架？
• cron 和 skill 在整張地圖上各站哪裡？
• 哪些問題該去看入口，哪些問題該去看 state，哪些問題該去看 prompt？
• 為什麼看懂地圖比死背函式名稱更重要？

架構總覽

如果把前 20 天重新整理，我會把 OpenClaw 畫成六區：

1. 入口區：接住請求、做 admission、裝配 turn
2. 執行區：model、tool、subagent、lifecycle
3. 狀態區：session store、transcript、memory
4. 壓縮區：compaction、pruning
5. 特殊 turn 區：cron、heartbeat、background automation
6. 能力區：skill.md、skills snapshot、prompt injection

這六區看起來分散，其實都是同一條資料流的不同面。

所以今天的重點不是再講一次每一塊，而是把它們串回來看。

原始碼節錄

先用入口和地圖中心做回顧。

📄 原始碼：src/agents/agent-command.ts:1042-1045

const sessionWorkAdmission = await beginSessionWorkAdmission({
	scope: storePath ?? `agent:${sessionAgentId}`,
	identities: [sessionKey, sessionId],
	signal: opts.abortSignal,
	onInterrupt: () => lifecycleAbortController.abort(createAgentRunRestartAbortError()),
	assertAllowed: () => { ... }
});

📄 原始碼：src/agents/agent-command.ts:1400-1412

const skillFilter = resolveEffectiveAgentSkillFilter(cfg, sessionAgentId);
const currentSkillsSnapshot = sessionEntry?.skillsSnapshot;
const skillSnapshotState = resolveReusableWorkspaceSkillSnapshot({
	skillFilter,
	currentSkillsSnapshot,
	workspaceDir,
	agentDir,
	agentId: sessionAgentId,
	canExecRequestNode,
	getRemoteSkillEligibility
});

這兩段放在一起看就很清楚：

• 一邊是「誰能進來」
• 一邊是「這輪能用什麼能力」

前者是門禁，後者是能力背景。

再看 cron 和 skill 的特殊處理，為什麼它們不是普通 turn。

📄 原始碼：extensions/codex/src/app-server/thread-lifecycle.ts（本機版本行號已變動，僅標到檔案）

function buildTurnScopedCollaborationInstructions(params) {
	if (params.trigger === "cron") return buildCronCollaborationInstructions();
	if (params.trigger === "heartbeat") return buildHeartbeatCollaborationInstructions();
	return null;
}

📄 原始碼：extensions/codex/src/app-server/thread-lifecycle.ts:3062-3062

function buildDeveloperInstructions(params) {
	return [
		"Running inside OpenClaw. Use dynamic tools for messaging, cron, sessions, media, gateway, and nodes when available.",
		renderCodexRuntimePromptOverlay(params),
		params.extraSystemPrompt,
		params.skillsSnapshot?.prompt
	].filter((section) => typeof section === "string" && section.trim()).join("\\n\\n");
}

這兩段就是第 17 到 19 天的核心縮影：

• cron 會切到專屬協作模式
• skill 會進到 developer instructions
• 兩者都不是單純的 config，而是會改變 runtime 行為的上下文

白話拆解

1. OpenClaw 的中心不是 model，而是 session

這是前 20 天最重要的一句話。

很多人初看 AI 系統，會覺得 model 才是中心。

但 OpenClaw 的地圖中心比較像 session：

• session 決定這輪屬於誰
• session 決定歷史怎麼延續
• session 決定 state 要寫哪裡
• session 決定這輪可不可以開始

model 很重要，但它是在 session 這個容器裡運作。

2. OpenClaw 真正在跑的是狀態流，不只是字串輸出

如果你只看最終 reply，會誤會 OpenClaw 只是聊天機器人。

但前 20 天一路看下來，它其實一直在處理：

• ingress 狀態
• admission 狀態
• lifecycle 狀態
• transcript 狀態
• memory 狀態
• delivery 狀態
• fallback 狀態

字串只是最後一層的外觀。
真正流動的是狀態。

3. cron 和 skill 是兩種不同的特殊性

這兩個很容易被混在一起。

• cron 是特殊 turn：它代表「系統自己安排的工作」
• skill 是特殊能力：它代表「這輪可用的工作背景」

一個偏執行時機，一個偏能力上下文。

所以它們不是同一層的東西。

4. 入口、狀態、能力，三者一定要一起看

如果你只看入口，會以為 OpenClaw 只是排隊系統。
如果你只看 state，會以為它只是 session store。
如果你只看 skill，會以為它只是 prompt 補丁。

但真正的 OpenClaw 是：

• 入口決定怎麼進
• 狀態決定怎麼活
• 能力決定怎麼做

三者合起來，才是它能跑長流程的原因。

5. 前 20 天其實一直在回答同一個問題

那個問題就是：

一個任務怎麼在有 session、有工具、有排程、有技能、有子代理的系統裡，穩穩地跑完？

答案被拆成很多篇，但主線一直都沒變。

設計取捨

• 好處是 OpenClaw 很適合長流程與多來源任務
• 好處是特殊 turn 和一般 turn 可以分開處理
• 好處是 skill / cron 都有自己的語意層，不會亂混
• 好處是 debug 時可以先定位自己在地圖哪一區
• 代價是學習門檻高，不可能只看一篇就懂
• 代價是模組多，心智模型要先建立好

但這些代價，換來的是可擴充性。

如果你想把系統從「能聊天」推到「能工作」，這些複雜度就是要付的學費。

今天的結論

• 前 20 天的主線不是很多題，而是一張完整的工作流地圖
• 地圖中心是 session，不是 model
• cron 是特殊的 scheduled turn
• skill.md 是能力上下文，會進到 prompt 和 runtime
• 入口、狀態、能力三者一起看，才看得懂 OpenClaw
• 看到這裡，後面再進 Telegram / LINE plugin 會更順

下一步

前 20 天把本體地圖畫完了。
接下來就要開始看它怎麼接外部世界：

• Telegram plugin
• LINE plugin
• ClawHub 上的 skill / plugin 舞台

這樣整個系列就會從「內部怎麼跑」走到「怎麼對外發生作用」。