# 策展 · X (Twitter) 🔥🔥

> 作者：Jason Zuo (@xxxjzuo) · 平台：X (Twitter) · 日期：2026-05-11

> 原始來源：https://x.com/xxxjzuo/status/2053611113548263474

## 中文摘要

# 從 OpenClaw 到 Hermes：重看 Agentic 程式開發架構

最近 🦞 的熱度明顯下來了，Hermes 也過了最熱的那幾天。

經過這段爆火，我一直在思考復盤一個更底層的問題：個人 Agent 系統如果要長期工作，架構應該怎麼設計。

熱度最高的時候，大家問的大多是：怎麼安裝、怎麼接入、哪個 SKILL 或是模型更強。

但連續用兩個月以後，我發現更重要的問題不是「哪個 Agent 更聰明」，而是它能不能被養成一個長期工作的系統。

跑起來是一回事。養起來是另一回事。

解決安裝、模型、入口、第一條訊息很容易。但是接下來的記憶怎麼治理，skills 怎麼維護，cron 怎麼管理，sub-agent 輸出怎麼驗證，工具權限怎麼收，失敗後人怎麼接管。

當龍蝦🦞和 Hermes 的後台主要接的都是 GPT-5.5 之後，差異就不能簡單歸因於「模型更聰明」。

真正拉開差距的，是模型外面的控制面：狀態怎麼管理，能力怎麼路由，權限怎麼收，失敗怎麼驗證。

更好的 Agentic 程式開發架構，不只是讓 Agent 會呼叫工具，而是讓它知道：什麼時候該用工具，什麼時候該找流程，什麼時候該驗證環境，什麼時候該停下來問人。

---

### 第一層：tool selection 不是工具列表問題

這兩個月最明顯的差別，是 Hermes 對 tool 和 skill 的選擇更主動，也更穩定。

這裡不是說模型本身更聰明，而是系統把「先找流程，再用工具」做得更明確。

比如寫對外文章，它不是直接開寫，而是先找內容生產 workflow，載入 writing style，再跑 content-lint，先約束帳號、平台、風格和發布門檻。

改線上專案，它會先走維護 SOP：看 git status 和 relevant diff，改完跑 syntax check、diff check，再做線上驗證。

一個很簡單但是典型的例子，是我遇到的 Resend 客服 email 正文轉發為空。

表面看，這是「信箱裡有沒有收到正文」的問題。

如果 Agent 只會找 Gmail 工具，它大概率會卡在第一層：讀信箱、查轉發、看收件匣。

但真正的問題不在 Gmail，而在 inbound webhook。

Resend 的 `email.received` payload 裡主要是 metadata 和 `email_id`，完整正文需要再透過 receiving API 拉取。

所以排查路徑必須拆層：

· Gmail / workspace 是收信與發送層

· Resend dashboard 是 inbound / outbound 事件層

· webhook payload 是系統介面層

· SDK version 是執行時能力層

· smoke test 和 live URL 是部署驗證層

這件事說明，tool selection 背後真正重要的是 capability routing。

任務進來後，Agent 要先判斷這是什麼類型的問題：信箱讀取、webhook 架構、credential state、SDK 版本，還是線上部署。

這裡的 routing 不只是選 tool，也包括選 skill。

Skill description 本質上不是說明書，而是 routing trigger。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1778485486259-diaHHigmjWEAADfIrjpg.jpg)

它決定 Agent 什麼時候載入這套能力。

寫得太寬，會誤觸。

寫得太窄，會漏觸。

和別的 skill 邊界不清，會互相污染。

所以 skill 多不一定更強。

每個 skill 都是一筆 context tax：寫得越鬆，後面所有任務都在替它付費。

有選擇機制，tool 和 skill 才能變成可復用能力。

沒有選擇機制，能力越多，系統越亂。

一次任務做完只是自動化。

下一次同類任務自動少踩一個坑，才開始有複利。

---

### 第二層：OpenClaw 解決的是入口和真實工作流

OpenClaw 當時最有價值的地方，是把 Agent 放進真實工作流。

個人 Agent 如果只存在於網頁聊天框裡，很難成為工作系統。真實任務通常來自 Telegram 訊息、瀏覽器連結、webhook、本地腳本報錯、定時任務，而不是使用者主動打開一個 AI 頁面。

OpenClaw 抓住的是 interface 和 routing 這兩層：

· Agent 怎麼被訊息觸發

· 怎麼呼叫本地腳本

· 怎麼接外部系統

· 怎麼把結果回到使用者正在看的地方

這裡要說清楚：這不是說 OpenClaw 沒有記憶。

恰恰相反，我之前在 OpenClaw 下已經搭了大量記憶架構。

比如三層記憶：

· L1：核心記憶，每次會話都載入

· L2：每日日誌，只載入最近視窗

· L3：歷史歸檔，透過語義搜尋按需召回

還有自動過期和回收機制：P0 永不過期，P1 / P2 按 90 天、30 天歸檔，避免長期記憶變成垃圾堆。

所以更準確的說法不是「OpenClaw 管入口，Hermes 才有記憶」。

而是 OpenClaw 讓我先把 Agent 接進真實工作流，並圍繞它手工搭出記憶 / 自動化 / gateway 體系。

Agent 必須先出現在任務發生的地方。

否則後面能力再強，使用者仍然要複製上下文、切視窗、手動執行下一步。

那不是工作流，只是旁邊開著的 assistant tab。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1778485486261-diaHHeDgpXwAAolpxjpg.jpg)

---

### 第三層：Hermes 把長期能力做得更細

遷到 Hermes 後，問題換了一層。

不是 OpenClaw 沒有記憶，也不是 Hermes 換了一個更聰明的模型。

在我看來，Hermes 更明顯的改進有兩點：自主記憶更新，以及更細的 skill 能力。

它把 Agent 接活以後怎麼保持可維護這件事，拆成了更明確的模組：

skills、記憶、session continuity、cron jobs、toolsets、provider abstraction、observability。

記憶不再只是我在系統外圍搭的一套分層文件，而是 Agent 可以在任務中主動判斷：哪些事實值得保存，哪些舊記憶需要替換，哪些臨時進度不該進長期記憶。

skills 也不只是「有一份 SOP」，而是變成更細的 capability package。

其中 skills 最關鍵。

我現在更傾向於把 skill 理解成 context architecture，而不是 prompt 模板。

成熟的 skill 也不只是一個 `SKILL.md`。

`SKILL.md` 是入口，負責觸發條件和核心判斷。

`scripts/` 放確定性邏輯，避免 Agent 每次重造輪子。

`references/` 放重文件，只在需要時載入。

`assets/` 放模板、schema、輸出格式。

`config` 放首次配置和環境差異。

這就是 progressive loading：不是把所有上下文一次塞進模型，而是按任務需要一層層展開。

好 skill 也不是把流程寫滿。

模型本來就知道的部分要刪掉，只留下它容易錯、必須穩定，或者體現個人判斷的部分。

沒有 skills，Agent 每次都靠上下文臨場發揮。同一個問題換個 session，可能又重新踩一遍。

記憶也不能簡單理解成「什麼都記住」。

記憶如果只是存東西，它只是文件櫃。

真正有用的 Agent 記憶，應該像神經系統：知道什麼相關、什麼變了、什麼時候該提醒人。

長期記憶只適合放穩定事實，比如使用者偏好、帳號規則、系統環境、專案約定。

流程應該進 skill。

臨時進度應該留在 session。

如果邊界不清，記憶會變成垃圾堆，而且會污染後續任務。

cron 也是類似問題。

普通 cron 是到點跑指令；agent-native cron 更像到點啟動一個帶任務說明、工具限制、上下文來源和交付目標的小 Agent。

長期任務如果沒有日誌、沒有失敗處理、沒有上下文邊界，自動化只是穩定地重複錯誤。

Hermes 給我的啟發是：Agent 接入工作流之後，還需要一套機制，把能力變成可復用、可限制、可觀察、可替換的系統組件。

這也是為什麼我最近看到 Anthropic 的 Managed Agents，會很有共鳴。

它表面上是在雲端託管 Agent，省掉 Sandbox、tool execution、state management、schedule 這些基礎設施。

但更重要的是，它把 Agent 拆成了幾個更穩定的介面：brain、hands、session。

brain 負責推理和呼叫工具，hands 負責執行，session 負責記錄發生過什麼。哪一層失敗，都不應該把整個任務狀態一起帶走。

這和個人 Agent 的方向其實是一致的。

一個真正能長期用的個人 Agent，不應該是「一個模型 + 一堆工具」。它應該有清楚的 session，有可維護的記憶，有按任務收窄的 toolsets，有能被復用的 skills，有定時觸發，有失敗記錄，也有權限邊界。

所以我現在更願意把個人 Agent 看成一個 managed runtime，而不是一個更聰明的聊天視窗。

---

### 第四層：遷移暴露的是隱性耦合

遷移最有價值的地方，是它把以前混在一起的問題拆開了。

一個功能能跑，不代表架構清楚。

遷移後必須重新判斷：這是入口問題、工具問題、credential 問題、記憶問題、skill 問題、cron 問題，還是權限和可觀察性問題。

Google workspace 是典型例子。

記憶裡可以寫「已經配置過」，但真實建立 Google Doc 時 token 可能已經 expired or revoked。

這不是寫作問題，也不是模型問題，而是 runtime state 和 long-term 記憶之間不一致。

長期 Agent 不能只相信記憶，執行前必須驗證當前環境。

skills 也會腐爛。

路徑會變，工具參數會變，帳號規則會變。舊 skill 如果不更新，就會從經驗復用變成事故復用。

維護 skill 也不是越寫越長。

真正值錢的是 gotchas。

Agent 在哪裡翻過車，就把那個坑寫回去。

但改 description 要非常謹慎。

因為 description 決定 routing，一改可能影響其它 skill。

這也是為什麼成熟系統需要 eval：它要測 skill 該載入時有沒有載入，不該載入時有沒有誤觸，相鄰任務有沒有混淆，換模型後行為有沒有漂移。

sub-agent 也是類似。

能 spawn 多個 agent 不難，難的是驗證輸出。

子 agent 可能說任務完成了，但文件不存在、API 沒跑通、路徑使用者存取不到。

沒有主 agent 的驗證、日誌和 guard，多 agent 只是把錯誤平行化。

這些不是 demo 裡最顯眼的部分，但決定系統能不能長期用。

---

我現在會把個人 Agent 拆成一個 runtime 看

它不是一條簡單的聊天鏈路，而是一組工程層疊在一起：

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1778485486247-diaHHiUXjWQAEq5l4jpg.jpg)

- interface 不是入口列表，而是任務從哪裡進來。Telegram、CLI、Web、IDE、email、browser 都屬於這一層。

- routing 不是把訊息轉給模型，而是判斷它應該進入哪個 session、profile、topic、skill 或 agent。

- tool execution 不是「能呼叫多少工具」，而是當前任務只給它哪些 hands。讀文件、寫文件、發 email、發文、刪文件、改配置，不應該是同一個風險級別。

- capability 不是 prompt，而是 skills / workflows / runbooks：重複任務應該寫成可維護流程，並配好 routing trigger、gotchas 和 eval。

- 記憶不是什麼都記住，而是保存穩定事實，不保存臨時過程；保存偏好和約定，不保存一堆過期狀態。

- task lifecycle 也不是普通 cron。cron、background process、watcher、event trigger、sub-agent 都要有建立、暫停、更新、追蹤、失敗恢復。

- observability / control 是最後一層：人要能知道 Agent 做了什麼、用了什麼上下文、哪裡失敗、什麼時候能接管。

不是 chatbot，是 runtime。用這套 runtime 看，OpenClaw 更強的是把前半段接進真實工作流：interface、routing、tool execution，以及圍繞真實任務外接自動化。

Hermes 更強的是把後半段做得更細：自主記憶 update、skills、task lifecycle、observability、provider abstraction。

這不是排座次，而是說明一個長期可用的 Agent 系統，前後兩端都要有。

前端要進入真實工作流。

後端要管理長期能力。

中間要有權限、驗證、日誌和失敗恢復。

---

### Agent OS 不是概念包裝，而是工程約束

我現在更願意把個人 Agent OS 理解成一組工程約束。

它不需要真的像 macOS 或 Linux，但它必須處理類似問題：入口、權限、進程、調度、日誌、配置、錯誤恢復、使用者接管。

幾個判斷標準會變得實際：

· capability 能不能模組化

· skill routing 會不會誤觸、漏觸

· 記憶、skill、session 邊界清不清楚

· 長期任務有沒有 lifecycle

· 工具權限能不能收窄

· 模型和 provider 能不能替換

· 失敗後能不能追溯

· 人能不能隨時接管

這些聽起來不如 demo 吸引人，但它們決定 Agent 能不能從「能跑」變成「能用」。

以前我看 Agent 專案，會先看它能呼叫哪些工具。

現在我會先看它怎麼管理複雜性。

OpenClaw 給我的啟發是：Agent 必須進入真實工作流，否則只是聊天視窗。

我在 OpenClaw 上已經搭過三層記憶和記憶回收，所以這不是「有沒有記憶」的差別。

Hermes 給我的啟發是：記憶 update 和 skill routing 如果變成 Agent 的內建動作，長期系統會更容易維護。

這兩件事合在一起，才是我這段時間對更好 Agentic 程式開發架構的理解。

不是更大的模型。

不是更多的工具。

也不是更熱的專案。

而是一套能把入口、工具、記憶、流程、權限、調度、失敗處理放在一起管理的系統。

## 標籤

Agent, Skills, 產業趨勢, 記憶系統, OpenClaw, Hermes