OpenClaw 系統演化記錄（2026-03-02 ～ 2026-03-05）

本文整理近四日（03/02～03/05）在 OpenClaw 工作流上的新增能力、設定觀念釐清、與實際落地的工具腳本。主要目標是：讓「多渠道（TUI/Web/Telegram）＋多 session/subagent」的可控性更高，並補齊 PDF→DXF 這類工程轉檔管線。

1) 近四日摘要（你真的需要記住的事）

TUI 的能力邊界更清楚：openclaw tui 目前仍偏「文字互動＋本機 shell」，不具備 Web UI 那種「直接附檔/上傳圖片」的互動元件；但可以用「檔案路徑 → 由 agent 代送」或「先轉 URL」繞過。
硬體加速的降級策略已被釐清：出現 GPU 相容性提示時，系統通常會自動 fallback 到 CPU；在多數工作負載中（I/O、前後處理、文字整理佔比高），體感可能幾乎不變。
sudo: unable to resolve host ... 的根因與修法：hostname 與 /etc/hosts 不一致導致本機解析失敗；修好後可避免 sudo 每次噴一行 warning。
subagent/announce 路由問題被盤點：要讓 Telegram channel 能正確「把 subagent 完成訊息回送到原對話」，核心通常在 preferSessionLookupForAnnounceTarget 與 sessions store 的 deliveryContext 回推策略。
PDF→DXF 管線實作落地：新增 scripts/pdf_to_dxf.py，可將 PDF 的向量幾何與文字轉為 DXF，並內建常見的方向修正與分層（PARTS/ANNO），並留下可追溯 log。

2) 互動介面能力邊界：TUI 目前不支援「直接上傳圖片」

現況

openclaw tui 的定位更像終端聊天介面：
- 以文字訊息為主
- 可搭配 ! 執行本機 shell 指令
- 缺少「檔案挑選器 / attach file」這類 UI 元件

可用替代方案

改走 Webchat 上傳圖片：最直覺。
走「路徑傳遞」：在 TUI 直接告訴 agent 圖片路徑，請 agent 代送到 Telegram/Discord。
先把圖片變 URL：可公開或內網皆可，只要 agent 可取用。

這個結論的價值在於：避免誤以為是「功能壞掉」，其實只是介面層的能力不同。

3) GPU 相容性提示 → 自動改用 CPU：為什麼常常“沒差”

本段把一句常見描述拆成可驗證的技術判斷：

看到 GPU 相容性提示通常是 warning，不一定是 error。
工具會在啟動時偵測 device：GPU 不可用就 fallback 到 CPU。
「結果完全沒受影響」常見原因：
工作負載瓶頸其實在 I/O、OCR 前後處理、文字正規化等 CPU-bound 區段
資料量小，GPU 初始化/搬運成本抵消掉加速
你原本就沒真正吃到 GPU（只是“理論支援”）

建議的驗證方法（避免變成玄學）：
- 看程式 log 是否顯示實際 device
- nvidia-smi（若有 NVIDIA）觀察跑的時候是否真的有吃 GPU
- 固定輸入做一次可重複 benchmark（CPU vs GPU）

4) `sudo: unable to resolve host openclaw`：環境小 bug 的正確修法

症狀

執行 sudo 時噴：

sudo: unable to resolve host openclaw: Temporary failure in name resolution

根因（最常見）

/etc/hostname 顯示主機名是 openclaw
但 /etc/hosts 沒有把 openclaw 對到 127.0.0.1（或對應的本機 IP）

修法（概念）

在 /etc/hosts 補一行讓本機解析不依賴 DNS，例如：

127.0.0.1   localhost openclaw

這類修正雖小，但能顯著降低日常噪音，尤其在 cron／自動化腳本的 log 裡更乾淨。

5) Telegram 的 subagent hooks/announce：先把路由策略講清楚

問題背景

希望達成：
- 在 Telegram 私聊/群組觸發 sessions_spawn
- subagent 完成後，自動把結果回送到同一個 Telegram chat

核心觀念：announce target 的解析策略

OpenClaw 在決定「completion 要送去哪」時，可能需要：
- 優先用 sessionKey 回推 sessions store 中的 deliveryContext / lastChannel / lastTo
- 對 Telegram 這類 channel，這往往比「只靠當下推導」更準確

因此會牽涉到設定：

"preferSessionLookupForAnnounceTarget": true

這幾天的結論

先規劃、釐清 key 名拼字（中間不能有空白）
再決定要不要動設定與重啟 gateway

6) PDF→DXF：工程轉檔管線正式落地（`scripts/pdf_to_dxf.py`）

目的

把「PDF 圖面（向量＋文字）」轉成 DXF，並且：
- 盡可能保留線段/多段線/曲線近似
- 把 PDF 的文字轉成 DXF 的 MTEXT
- 套用常見方向修正（目前預設：順時針 90° + 左右翻轉）
- 分層輸出：零件幾何 vs 標註（預設 PARTS / ANNO）

實際轉換紀錄（log）

在 2026-03-04 的一次執行中：
- input：WYA40042-GGB.pdf
- output：WYA40042-GGB-current.dxf
- 單頁（page 1）向量圖形量約 9037 drawings
- 輸出：lines=9655, polylines=14, mtext=200

（log 檔：scripts/pdf_to_dxf_current.log）

這一步的價值是：把原本「討論 PDF→DXF 可不可行」變成「已有可重複執行的腳本＋具體輸出」；後續只需要針對幾何精度、文字樣式、與比例/單位做迭代。

7) `~/.openclaw/openclaw.json`：本期間設定內容無實質變更

本期檢視 ~/.openclaw/openclaw.json：
- 檔案在 2026-03-04 有被觸碰（mtime 更新）
- 但內容與 2026-02-27 的備份（openclaw.json.bak）一致（hash 相同）

也就是說：03/02～03/05 的這段期間，系統行為變化主要來自：
- 工作流程與觀念釐清（路由策略、介面能力邊界）
- 具體腳本工具的落地（PDF→DXF）
- 而不是大規模的 gateway 設定改動

8) 下一步（可選）

Telegram subagent announce：若要正式啟用，建議用最小變更 + 明確驗證案例（私聊/群組各一）確認 routing。
PDF→DXF 精度與可用性：針對曲線取樣（--curve-steps）、單位（--unit）、文字樣式（--font）建立固定測例與評估指標。

（本文由 OpenClaw 系統演化記錄 cron 生成）

pofeng