從 OpenClaw 到 Hermes：重構長期可用的 Agentic AI 架構 (Rethinking Agentic AI Architecture: From OpenClaw to Hermes)

原始來源與檔名：20260512_2026-05-12T093057+0800-从 OpenClaw 到 Hermes：重看 Agentic AI 架构.md

來源：[[@xxxjzuo]] / X (Twitter) — 2026-05-11 原始檔名：2026-05-12T093057+0800-从 OpenClaw 到 Hermes：重看 Agentic AI 架构.md

NAPKIN | 餐巾紙

餐巾紙公式

Agent Usability = Interface (Real Workflow) + Routing (Capability Match) Agent Longevity = Managed Runtime (Memory + Configurable Skills + Observability + Safe Failure) Agent OS ≠ Chatbot. It is a set of engineering constraints.

讓 Agent 跑起來很容易，讓它長期活著很難。當底層模型都一樣聰明時，拉開差距的不是「它會用多少工具」，而是系統的控制面：它知不知道什麼時候該看流程、什麼時候該驗證環境、記憶體如何不變成垃圾堆。OpenClaw 解決了「如何讓 Agent 進入真實工作流（非對話框）」；Hermes 解決了「如何自主更新記憶與精細化管理 Skill」。一個成熟的個人 Agent，本質上是一個受嚴格工程約束的「代管執行階段 (Managed Runtime)」。

一句話

本文是作者連續兩個月深度使用 OpenClaw 與 Hermes Agent 後的架構復盤。作者破除了「誰的模型更聰明」的迷思，指出決定 Agent 系統能否長期運作的核心在於「基礎設施的管理能力」。文章將 Agent OS 拆解為七層架構（介面、路由、工具執行、能力、記憶、生命週期、可觀察性），並深入分析了為何 Skill 不該只是 Prompt 模板，而 Memory 也不該只是事實垃圾場。

餐巾紙草圖

[The 7-Layer Managed Runtime for Agents]

1. Interface       -> Where tasks enter (Telegram, CLI, Cron, Webhook). Not just a chat box.
2. Routing         -> Matching the task to the right Skill/Profile. Avoids context tax.
3. Tool Execution  -> Scoped "Hands". (Reading != Deleting).
4. Capability      -> "Skills". Progressive loading (Scripts, Refs, Assets), not giant prompts.
5. Memory          -> Stable facts (System rules). Temporary progress stays in Session.
6. Task Lifecycle  -> Agent-native cron (spawn with boundaries, logs, fail-safes).
7. Observability   -> Human control. Traceability. The emergency brake.

ROUND 1: SKELETON | 骨架掃描

“這篇文章在說什麼”

痛點: 網路熱度聚焦於「如何安裝」與「哪個更強」，但真正嚴峻的工程挑戰是：如何養一個長期工作的系統，管理記憶、權限與失敗恢復。
第一層 (Tool Selection vs Capability Routing): Agent 不能只是會呼叫工具。以 Resend 郵件報錯為例，Agent 需要知道先排查哪一層（收發層、API 層、環境層）。Skill 的描述本質上是「路由觸發器」，寫太寬會互相污染，造成系統性的 Context Tax。
第二層 (OpenClaw 的貢獻): 讓 Agent 脫離網頁對話框，接入真實工作流（如 CLI 報錯、Webhook）。並證明了記憶是可以分層管理的（L1 核心, L2 日誌, L3 歸檔）。
第三層 (Hermes 的進化): 實現了「自主記憶更新」與更精細的 Skill 結構。Skill 不再只是一段 Prompt，而是包含 scripts/, references/, config/ 的上下文漸進式載入架構。記憶體不該是垃圾堆，流程進 Skill，臨時狀態留 Session。
第四層 (隱性耦合的暴露): 系統遷移暴露出架構缺陷。例如：記憶說已授權，但真實 Token 已過期。Agent 執行前必須有能力驗證真實環境。
結論 (Agent OS 是工程約束): 個人 Agent 不是一個更聰明的聊天視窗，而是一個包含了進程、排程、權限收窄、日誌與可追溯性的 Runtime 系統。

ROUND 2: DISSECTION | 血肉解剖

“憑什麼這麼說”

核心論證鏈

能力過載導致的 Context Tax: 作者犀利指出，Skill 寫得越多不一定越強。如果 Routing 機制不嚴謹，每次任務啟動時模型都要在龐雜的描述中篩選，這就是在繳納「上下文稅」。沒有選擇機制的工具堆砌，只會讓系統陷入混亂。
記憶體的語義隔離 (Semantic Isolation of Memory): 這是對傳統 “Vector DB as Memory” 的嚴厲批判。作者精確定義了界線：穩定的事實（如環境變數、偏好）進 Memory；SOP 流程進 Skill；任務中的臨時進度（如我現在讀到了第幾行）只留在 Session。如果不做隔離，長期的 Memory 就會被垃圾填滿，導致幻覺與效能崩潰。
驗證與可觀察性 (Verification & Observability): 多 Agent 並行（Spawn）很簡單，難的是驗證。子 Agent 回報「已完成」，不代表檔案真的存在或 API 真的跑通了。沒有主 Agent 的 Guardrails 和日誌，多 Agent 系統只是在「並行化地製造錯誤」。

關鍵證據

引用了具體的 Debug 案例（Resend Webhook 的 Payload 層次結構）與 Google Workspace Token 過期的場景，這些都是只有真正在生產環境中重度使用過自動化系統的架構師，才會踩到的血淋淋的坑。

邊界條件

作者描繪的 7 層架構標準極高，接近現代雲端微服務 (Microservices) 的治理水平。對於只想讓 AI 幫忙寫寫腳本或潤飾文章的輕度使用者，這套 Runtime 架構過於沉重且維護成本極高。

ROUND 3: SOUL | 靈魂提取

“還能怎么用”

知識連結: 本文是對 YC CEO Garry Tan 《Meta-Meta-Prompting》的絕佳工程註解！Garry Tan 描述了系統多強大，而這篇文章指出了支撐這種強大的底層骨架（Thin Harness 具體應該做什麼）。同時也印證了 Anthropic 推出 Managed Agents (分離 Brain, Hands, Session) 的必然性。
深層洞見: “自动化只是稳定地重复错误。” (Automation is just repeating mistakes consistently.) 除非系統具備捕捉 Gotchas（踩坑經驗）並將其寫回 Skill 的能力，否則 AI 不會產生複利，它只是一個不知疲倦的闖禍機器。
行動呼籲: 如果你正在構建自己的 Prompt 庫或使用 Cursor Rules：
1. 停止把所有流程寫在同一個檔案裡。
2. 開始模組化：把「檢查環境是否就緒」的指令寫在最前面；把「具體操作的參考文獻」分開存放，按需載入。
3. 建立一個 gotchas.md，專門記錄 AI 之前犯過的愚蠢錯誤，強迫它每次執行同類任務前先讀一遍。