OpenClaw 桌面平台：Windows 現在有原生 Hub，而 Node 是硬性需求
Node 是必要的執行期，因為標準狀態儲存用 node:sqlite——Bun 只能拿來裝依賴。Windows 這邊變化最大：新增了原生的 Windows Hub companion app，不需要管理員權限，還能自己開一個 app 專屬的 WSL 發行版來裝 Gateway。
ai
1264 篇文章OpenClaw 行動平台：手機是周邊，不是 Gateway——連 Apple Watch 都有自己的傳輸
iOS 與 Android 的 app 是 node，不是 Gateway：它們不跑 Gateway 服務，Telegram 或 WhatsApp 的訊息也是落在 Gateway 上而不是手機上。Apple Watch 比較特別——因為 watchOS 擋掉一般 app 的低階網路，它改用簽章過的 HTTPS 輪詢。
OpenClaw Plugin 系統：把安裝當成執行程式碼，以及冷檢查證明不了執行期
官方對安裝 plugin 的定調是「把它當成執行程式碼」——ClawHub 與內建目錄是受信任來源，任意的 npm、git、本地路徑在非互動安裝時需要 --force。而驗證要用 inspect --runtime，因為不帶旗標的 inspect 只是冷的 manifest 檢查。
OpenClaw 沙箱機制：四種後端、三個獨立開關，與「以為在沙箱裡其實沒有」
沙箱由三個獨立設定決定：mode（何時套用）、scope（開幾個容器）、backend（在哪執行）。最容易出事的是預期落差——`tools.exec.host` 現在預設是 auto，所以「沒設就等於在沙箱裡」已經不成立，安全稽核有一條專門抓這個。
OpenClaw 的 Session 與記憶：一條滾動的主對話，加上四個會被寫進磁碟的檔案
預設下所有 DM 匯進同一條「主 session」，群組活動與背景工作都往那裡回報。記憶則完全是磁碟上的 Markdown——模型只記得被寫下來的東西，沒有隱藏狀態。但如果不只你一個人能私訊它，DM 隔離是必須主動打開的。
OpenClaw 的威脅模型：先講清楚它「不保護什麼」
OpenClaw 的安全文件現在開宗明義寫著：這是個人助理的信任模型，一個 Gateway 對應一個受信任的操作者。它明確「不是」多個互相敵對的使用者共用一個 agent 時的安全邊界——而且有一份『依設計不算漏洞』的清單把這件事寫死。
OpenClaw 工具篇（一）：一個專屬瀏覽器、三種附著方式，與被標成「不可信」的搜尋結果
OpenClaw 的瀏覽器是一個獨立的 agent 專用 profile，跟你的個人瀏覽器完全隔離。而 web_search 的回傳結構裡有一個 externalContent.untrusted 標記——搜尋結果在型別層就被標成不可信的外部內容。
OpenClaw 工具篇（三）：關掉檔案工具不會讓 exec 變成唯讀
exec 是一個會改變狀態的 shell 面：關掉 write、edit、apply_patch 這些檔案工具，完全不會讓它變成唯讀。而沙箱預設是關的，所以 host=auto 實際上會解析到 gateway——真的要沙箱就明確寫，它至少會 fail closed。
OpenClaw 工具篇（二）：Skills 的六層優先順序，與子 agent 不給訊息工具的理由
Skills 從六個來源載入、同名時高優先者勝，而 per-agent 的清單是取代不是合併。子 agent 預設拿不到 session 與訊息工具——它回傳純文字給父 agent，人看得到的回覆權留在父 agent 手上。
OpenClaw 工具篇（四）：當工具多到塞不進 prompt——Code Mode、Tool Search 與 MCP
工具目錄大到塞不進 prompt 時，OpenClaw 有兩個答案：Code Mode 只讓模型看到 exec 與 wait，由它寫小程式去搜尋與呼叫隱藏的目錄；Tool Search 則保留結構化的搜尋／描述／呼叫控制。兩者都不繞過工具政策。
OpenClaw 維運篇：前 60 秒的七行指令，與「感覺變笨了」通常不是模型的錯
官方的分診流程是七行指令跑一遍、兩分鐘出診斷。而「assistant 感覺受限、工具不見了」這個最常見的症狀，多半是工具 profile——minimal 只允許 session_status，coding 才是新本地設定的預設。
OpenClaw UI：新增的側欄可以問「這個 session 在幹嘛」而不打斷它
Control UI 加了一條 session rail：它用 utility model 產生執行摘要，還附一個唯讀的伴讀 thread，讓你問「這個 session 現在怎樣」而不會進入或打斷主 agent 執行。它的內容不會進入 chat.history。
Phil Schmid：為什麼 Agent Harness 是 2026 年最重要的事
模型是 CPU，harness 是作業系統，agent 是應用程式。模型能力再強，沒有好的 harness 就只是 demo。Phil Schmid 認為 harness 是 2026 年 AI 工程最關鍵的基礎設施。
LangGraph：用圖結構管理 Agent 工作流程
LangGraph 把 LLM 工作流程建模成有向圖，解決多輪迭代、條件分支、平行執行這些用線性 pipeline 做很痛的問題。
Langfuse 完整指南：LLM 應用的可觀測性從零開始
Langfuse 是目前最成熟的開源 LLM Observability 平台。這篇從 Tracing、Prompt 管理、評估、Dataset 四個核心功能切入，帶你搞清楚它在實際專案中怎麼用。
Context Engineering：為什麼你的 AI Agent 問題出在資訊，不在模型
Context Engineering 是 2025 年取代 Prompt Engineering 的核心概念：重點不再是「怎麼問」，而是「給什麼資訊」。把對的資訊在對的時機送進 context window，比換更強的模型更有效。這篇整理了定義、四大策略、實作技巧和常見失敗模式。
MCP（Model Context Protocol）：AI Agent 工具呼叫的標準化協定
每個 AI 工具都有自己的呼叫格式，整合成本高。MCP（Model Context Protocol）是 Anthropic 提出的開放標準，統一 AI Agent 與外部工具、資料源的通訊協定，讓工具可以跨 Agent 重用。
Agent Memory 系統：從 RAG 到 Read-Write 記憶的演化
RAG 是唯讀的。Agent Memory 讓 AI 不只能讀，還能寫入和持久化資訊。三種記憶類型：Procedural（行為模式）、Episodic（時間事件）、Semantic（事實知識），構成完整的認知記憶系統。
AI Agent 架構模式完整指南：從三支柱到 Multi-Agent 的系統化導航
AI Agent 不是一個技術，是一整個架構體系。本文是系統化導航：從 Agent 三支柱（Context/Cognition/Action）出發，穿過 AI 工程三階段演化（Prompt → Context → Harness），到八種 Multi-Agent 設計模式和生產級 Harness 基礎設施。每個主題都有對應專文深入。
AI Agent 的三個核心支柱：Context、Cognition、Action
AI Agent 不是黑盒子——它由三層構成：知道什麼（Context）、怎麼想（Cognition）、能做什麼（Action）。搞清楚這三層，才能理解 agent 為什麼有時聰明、有時失控，以及怎麼設計一個真正好用的 agent 系統。