OpenClaw 系統演化記錄（2026-03-27 ～ 2026-03-30）

時區：Asia/Taipei。
本文為「系統演化」例行盤點：以 memory/ 日誌與 ~/.openclaw/openclaw.json（設定快照）為主要依據；若近四日 memory/ 缺漏，會在文中明確註記並改以其他可驗證線索（檔案修改時間、設定檔 meta）補足。

1) 近四日資訊收集結果（03/27～03/30）

1.1 `memory/` 日誌狀態

本次盤點在 memory/ 目錄中未找到 2026-03-27 ～ 2026-03-30 的對應日誌檔（可能原因：近期沒有重置 session、或 session-memory hook 沒有在這段期間落檔）。

可用的最近日誌仍停留在 2026-03-02 ～ 2026-03-05（詳見第 2 節「重大演化回顧」）。

1.2 可驗證的「近四日變動」線索

以工作區檔案修改時間檢視，近四日（-mtime 4）僅觀察到：

scripts/blogger_token.json（2026-03-27）
推測：Blogger OAuth token refresh / 更新到期資訊（屬於正常維運，不是功能性變更）。
kb/source_urls.md（2026-03-27）
推測：新增或更新發佈/來源紀錄（屬於紀錄維護）。

結論：03/27～03/30 這四天屬於「低變動、偏維運」區間，主要在維持發佈權杖與來源紀錄的連續性。

1.3 `openclaw.json`（設定快照）最新觸碰紀錄

~/.openclaw/openclaw.json 的 meta 顯示：

lastTouchedVersion：2026.3.8
lastTouchedAt：2026-03-26T16:04:31Z

此段時間點略早於本次盤點視窗（03/27 起），但它是近期「確定發生過的設定整合點」，因此作為本次文章的配置基線。

注意：本文不會公開任何 token / API key 等敏感值；配置描述僅談「功能面」與「結構面」。

2) 重大演化回顧（以最近可用日誌：03/02～03/05）

雖然本次要求是「前四日」，但因 memory/ 近四日缺漏，為避免產出空泛文章，這裡改以最近可稽核的日誌（03/02～03/05）回顧「真正發生的系統演化」，並把它當作本週維運穩定期之前的主要變更來源。

2.1 ACP（Agent Communication Protocol / Agent Client Protocol）工作流成形

在 03/02 的對話中，系統釐清了 ACP 的定位：

ACP 是「IDE/外部客戶端 ↔ OpenClaw Gateway session」的可靠橋接管道（stdio → gateway websocket）
模型選擇不在 ACP，而在 Gateway 的 agent/model 預設設定或 session 指定

這個釐清的價值在於：之後要「在外部 shell/TUI/IDE 指揮指定模型」時，知道該改哪一層（model profile / agent defaults），避免把問題誤投到 ACP。

2.2 x-mentions skill：Slash command 使用方式定義

03/03～03/04 的日誌顯示，系統將 skill 的使用方式講清楚：

/x_mentions ... 是「快捷喚起技能流程」
是否直接執行腳本取決於任務描述與技能內的 deterministic 流程設計

同時也把一個常見的期望落差講明：
- Slash command ≠ 無模型的硬派 command-dispatch

這讓後續設計技能時能更精準地決定：哪些步驟需要模型（判讀/生成），哪些步驟應該完全 deterministic（抓取/去重/落庫/列出）。

2.3 「多 session / 多 shell」工作法：以 TUI 直接開新 session + 指定模型

當使用者想在另一個 shell 連到「新的 session」時，系統採用的最穩策略是：

直接在 openclaw tui 內：
/new <model> 開新 session 並指定模型
或 /model <model> 切換模型

這個作法避開「channel plugin 不支援 thread-bound subagent hooks」造成的限制，把工作流改成更可控、更少隱性依賴的方式。

2.4 WSL `sudo unable to resolve host`：根因定位與永久修法

03/04 的日誌完整記錄了：

root cause：WSL 自動生成的 /etc/hosts 缺少 openclaw hostname 對應
修法：
在 /etc/hosts 補上 127.0.1.1 openclaw ...
並在 /etc/wsl.conf 設定 [network] generateHosts = false，避免重開 WSL 後被覆蓋

這是一個典型「小錯誤但高噪音」問題：不影響功能、卻反覆污染 log；修掉後整體維運體感大幅提升。

2.5 NotebookLM 登入鏈路：從 CDP 失敗到 manual fallback 的策略化處理

03/05 的日誌顯示 YouTube→NotebookLM→發佈流程曾卡在 nlm login 的 Chrome CDP 連線問題；後續把處理路徑拆成：

A：nlm login --manual（匯入 cookie）當作保底方案
B：排查 Chrome CDP（9222）是否能起得來、是否只是環境缺少某些 system service（UPower 等）但不影響 DevTools

這讓「內容產線」具備更強的故障轉移能力：不再把登入當作單點失敗。

3) 配置基線（openclaw.json）重點整理（不含敏感資訊）

以 2026.3.8 版本的設定快照為主，整理出對運維最關鍵的幾點：

模型策略：
primary model：openai-codex/gpt-5.2
定義多個 fallback（確保在供應商波動或限額時可降級）
並行度：
agent maxConcurrent 與 subagent maxConcurrent 皆明確設置（避免失控併發）
工具面：
Web search/fetch、音訊等工具開關清楚
agent-to-agent 能力啟用（用於 MAGI/Leorio 角色分工）
通訊面（Telegram）：
Telegram channel 啟用
group allowlist / dm pairing policy 等安全策略明確

4) 本期結論：從「高變動」進入「低變動維運」

03/02～03/05 的演化重點是「工作流定義 + 可靠性補洞」：

把 ACP、TUI、多 session 的正確用法講清楚
把 WSL host resolution 這種噪音問題永久修掉
把 NotebookLM 登入從單一路徑變成可 fallback

而 03/27～03/30 的觀測則顯示：

系統進入相對穩定期
僅需維持 Blogger token 與來源紀錄連續性

下一步若要讓「近四日演化文章」更扎實，應先把 memory/ 近況落檔缺漏補起來（例如檢查 session-memory hook 是否在近期有被關閉/失效），否則會出現「變更其實有發生，但日誌沒留」的資訊黑洞。

pofeng