Harness 不只是腳手架：從 Claude Code、Hermes 和 OpenClaw 看 Agent 架構的三條路

呢個理解冇錯，但只係眾多理解入面嘅一種。

最近我將 Claude Code、Hermes Agent 同 OpenClaw 嘅源碼同架構文檔都睇咗一次，發現一件幾得意嘅事：呢三個項目口口聲聲話 Harness，但做出嚟嘅嘢完全唔同。Claude Code 將 Harness 當做腳手架，越輕越好，模型搞得掂嘅嘢就唔好幫佢做。Hermes 將 Harness 當做學習系統，每次任務都喺度累積經驗，越用越聰明。OpenClaw 將 Harness 當做基礎設施，Gateway、路由、設備節點、任務調度，同模型強唔強冇乜關係。

對 Harness 嘅理解唔同，造出嚟嘅產品就完全唔同。下面我會帶你一齊拆開嚟睇佢哋係點樣設計 Harness 嘅。

Harness 核心設計

從呢三個項目嘅代碼結構同設計文檔睇，好容易發現佢哋嘅架構設計有明顯嘅唔同。

OpenClaw 嘅核心係 Gateway。官方架構文檔第一句都寫明咗佢係一個 long-lived Gateway，擁有所有 messaging surfaces。CLI、macOS app、Web UI、自動化任務，全部經由 WebSocket 連接 Gateway。

手機、Mac、遠程設備都經由同一個協議接入，不過佢哋會聲明自己係 node，開放返攝像頭、屏幕、Canvas 等功能。Gateway 默認監聽 127.0.0.1:18789，連 Canvas 同 A2UI 都由同一個 HTTP server 託管。

即係話，OpenClaw 將多個入口整合成單一控制平面。你喺 Telegram 發訊息，喺 Web UI 操作，喺手機節點觸發，最終都進入同一套協議、同一套會話管理、同一套工具策略、同一套事件流。即係話，OpenClaw 先做咗神經系統，而唔係大腦。

Hermes Agent 嘅核心係 AIAgent。佢透過一個過萬行嘅代碼，整合咗 prompt 裝配、provider 選擇、工具執行、重試、fallback、上下文壓縮、會話持久化等所有核心功能。CLI、Gateway、ACP、Batch Runner、API Server 呢啲入口最終都收斂埋一齊，後來先慢慢補充返 Gateway 同 messaging 平台嘅適配。

Hermes 嘅優先次序係先將 Agent Loop 做到夠強，等佢支持並發工具調用、子代理委派、多 provider fallback、上下文壓縮保護，然後再考慮點樣將呢個大腦連上外面嘅世界。

Claude Code 嘅核心唔係 Gateway 亦唔係 Agent Loop，而係權限系統同上下文管理。正如《Managed Agents 架構拆解：Anthropic 俾 Agent 造咗套 K8s》入面提到，Anthropic 將 Agent 嘅組件拆成 session、harness、sandbox 三個獨立接口，每個都可以獨立更換。Claude Code 嘅源碼都係呢個思路嘅體現。

睇返佢之前洩漏嘅源碼，最龐大嘅模塊係權限相關嘅代碼，處理咗六種權限模式、八個權限來源、分類器自動審批、hook 擴展等等。而主循環本身反而好薄，只係負責將每輪完整嘅訊息歷史交俾模型，工具執行完即刻流式返回，冇複雜嘅調度算法。

Claude Code 嘅設計哲學可以歸納為：信賴模型+管好邊界。模型自己決定調用咩工具、按咩順序執行、幾時停落嚟。Harness 唔替模型做決策，只喺兩個地方卡住：你有冇權限做呢件事，上下文係咪就快爆。

三個項目對 Harness 嘅理解，喺呢一層已經分化咗。OpenClaw 將重心放喺多入口收束同協議統一，Hermes 將重心放喺 Agent Loop 嘅能力密度，Claude Code 將重心放喺權限管控同上下文保護。

記憶系統設計

記憶係 Agent 由臨時工變成長期拍檔嘅關鍵一步。三個項目喺呢件事上嘅做法差異都好大。

Claude Code 嘅方案最簡單，簡單到有啲反直覺。CLAUDE.md 文件前綴加載，每次會話開始時注入 system prompt。Auto Memory 讓模型自己喺 ~/.claude/ 目錄下寫 Markdown 檔案，MEMORY.md 作為索引（最多 200 行、25KB）。冇向量檢索，冇 embedding，冇外部數據庫。記憶唔係主動召回，而係作為上下文嘅一部分俾模型睇到。

上下文壓縮都係反應式嘅：上下文窗口用到就快滿先觸發壓縮。壓縮方式係 fork 一個新嘅 Claude 實例嚟做摘要，壓縮算法會保護工具調用同結果嘅完整性，唔會將一個 tool call 同佢嘅 result 分開。如果壓縮連續失敗三次，circuit breaker 會停咗佢，避免死循環。

呢個方案嘅好處係簡單、可預測、唔依賴外部服務。代價係記憶容量有限，跨會話嘅資訊密度完全取決於 CLAUDE.md 寫得好唔好。

Hermes Agent 將記憶做成分層系統。第一層係 MEMORY.md 和 USER.md，類似 Claude Code 嘅方案，保存喺 ~/.hermes/memories/，會話開始時注入 prompt。第二層係 SQLite + FTS5 全文搜索，所有歷史會話都可以俾檢索同摘要。第三層係 8 個外部 memory provider 插件，包括 Honcho、Mem0、Hindsight 等。

Honcho 嘅設計值得單獨講嚇。佢唔只做向量檢索，而係將用戶同 AI 都建模為 peer，做跨會話嘅辯證推理，維護用戶表徵同 session summary。啟用之後，Hermes 每輪前會預取相關記憶，每輪後同步對話，會話結束時抽取長期記憶。

Hermes 嘅記憶哲學係：模型嘅短期記憶唔夠用，需要系統幫佢喺多個時間尺度上累積同召回資訊。呢個同 Claude Code 嘅「模型自己搞得掂」思路分別都幾大。

OpenClaw 就行咗另一條路：將 Context Engine 做成可替換嘅運行時插件，控制點樣構建模型上下文，決定包含邊啲消息、點樣摘要舊歷史、點樣跨 subagent 管理上下文。內置嘅係 legacy engine，但插件可以註冊完全唔同嘅 engine。

每次模型運行時，engine 有四個生命週期點：ingest（消息入嚟時）、assemble（構建上下文時）、compact（壓縮時）、after turn（一輪結束後）。插件 engine 甚至可以返回 systemPromptAddition，動態注入召回指導或檢索提示。

OpenClaw 嘅會話管理都好講究：DM 默認共享 session，羣聊按 group 隔離，rooms 按 room 隔離，cron 每次新 session。多 Agent 場景下，每個 Agent 有獨立嘅 workspace、auth profile、session store。

OpenClaw 嘅記憶哲學唔係記更多，而係令記憶管理本身成為一個可插拔嘅系統服務。長期 Agent 嘅記憶需求會不斷變化，與其內置一套固定方案，不如將接口留好，等生態去填充。

三種方案，背後係三種對 Agent 應該記咩嘅唔同理解。Claude Code 覺得模型夠聰明，俾佢睇到就得。Hermes 覺得淨係睇到唔夠，要幫佢喺多個時間尺度上累積。OpenClaw 覺得記憶本身嘅需求會變，不如將接口留好。

擴展性設計

落嚟再睇嚇擴展性嘅設計，呢個係令 Agent 可以搜索、瀏覽網頁、生成圖片、讀寫文件等各種外置能力嘅關鍵。

OpenClaw 將能力擴展拆成三層：內置 Tools 係 Agent 可以隨時調用嘅預裝能力，Skills 係教 Agent 幾時用、點樣用外部工具嘅擴展能力，而 Plugins 則係打包咗工具、技能、消息通道、模型等各種擴展嘅能力包。

呢個三層模型將三樣容易混淆嘅嘢拆開咗：工具係默認做到啲咩，技能係幾時/點樣去調用外部工具，插件係點樣打包、發現、分發呢啲能力。ClawHub 上架咗 58000 幾 個社區 Skill，一條命令安裝，呢個對 OpenClaw 帶起嚟功不可沒。

Hermes Agent 嘅工具系統用咗 registry 自注冊模式。tools/registry.py 係中心註冊表，每個工具文件喺模塊級調用 registry.register() 聲明 schema、handler、toolset 歸屬同可用性檢查。model_tools.py 係 registry 之上嘅薄編排層，負責導出工具定義、處理函數調用、維護工具到 toolset 嘅映射。

有個好細嘅設計：model_tools.py 會根據當前真正可用嘅工具重建 execute_code 嘅 schema。譬如 web API key 冇配置，模型就唔會喺 sandbox 度見到 web_search 呢個工具。呢個可以減少模型「以為自己做到但其實做唔到」嘅幻覺式調用。

Hermes 嘅技能系統用咗 progressive disclosure：Level 0 只加載 name 同 description，Level 1 加載完整技能內容，Level 2 加載技能引用嘅附件。模型先掃描技能列表，匹配到再深入加載。更重要嘅係，Agent 可以透過 skill_manage 自己創建、更新、刪除技能。解決咗一個非平凡任務之後，佢可以將方法保存做技能文件，下次遇到類似問題直接複用。

呢個就係 Hermes 講嘅「程序性記憶」。普通 Agent 完成任務後只係留低結果，Hermes 完成任務後仲嘗試留低方法。當你累積 20 個以上自創技能之後，同領域任務完成速度可以提升 40%。

Claude Code 嘅擴展體系同前兩者嘅思路都唔同，佢唔係圍繞工具註冊或技能發現嚟組織，而係圍繞權限邊界層層展開。

最底層係 28 個內置工具，覆蓋文件讀寫、搜索、Shell 執行、Web 訪問、子代理調度等基礎能力。呢啲工具分兩類：Read、Glob、Grep 呢類只讀工具唔需要權限，Bash、Edit、Write 呢類有副作用嘅工具每次執行都要過權限檢查。權限唔喺工具註冊時聲明，而係喺執行時由 harness 攔截，模型唔需要考慮「我係咪可以做呢件事」，該攔嘅時候自然會攔。

往上一層係 MCP 協議。Claude Code 透過 MCP 接入外部工具服務器，支援 stdio、HTTP、SSE 三種傳輸方式。MCP 工具默認係延遲加載嘅：會話開始時只將工具名稱放入上下文，模型需要用嘅時候透過 ToolSearch 工具按需拉取完整 schema。呢個設計同 Hermes 嘅 progressive disclosure 異曲同工，只係實現路徑唔同，一個喺技能層做分級加載，一個喺工具層做延遲發現。

再往上有 Hooks、Skills 同 Plugins 三層擴展。Hooks 提供咗 25 個生命週期事件，可以掛 shell 命令、HTTP 請求、甚至 LLM 評估。Skills 遵循開放嘅 Agent Skills 標準，用 Markdown + YAML frontmatter 定義可複用嘅 workflow，支援參數替換同條件觸發。Plugins 就係將 Skills、Hooks、MCP 配置、子代理定義打包成一個可分發嘅單元。

子代理係 Claude Code 處理複雜任務嘅核心機制。每個子代理運行喺獨立嘅上下文窗口入面，有自己嘅系統提示同會話歷史。內置咗 Explore（快速搜索，用 Haiku 模型）、Plan（規劃研究）、general-purpose（全功能）等預設類型，亦支援透過 .claude/agents/ 目錄自定義。自定義子代理可以精細控制工具白名單、權限規則、模型選擇，甚至預加載特定 Skills。

能力管理嘅複雜性擺喺邊？OpenClaw 交俾社區生態，Hermes 交俾 Agent 自身嘅累積，Claude Code 交俾分層嘅權限邊界。

點樣面對模型進步

呢個維度最值得諗。

Anthropic 有一個幾有意思嘅觀察：harness 編碼嘅係對模型能力邊界嘅假設，但模型會進步，假設會過期。Sonnet 4.5 嗰陣模型有上下文焦慮，隨住上下文窗口接近極限會提早收工，harness 入面加咗重置機制嚟應對。結果換到 Opus 4.5，呢個行為自己消失咗，重置機制變咗死代碼。

Claude Code 對呢一點嘅應對係大量嘅功能開關，從佢洩漏嘅源碼可以見到大量 HISTORY_SNIP、REACTIVE_COMPACT、TRANSCRIPT_CLASSIFIER 等等呢類開關。例如，去到 Opus 4.6，之前喺 harness 入面加嘅 Sprint 機制（將長任務拆成細塊、每塊結束後評估）就成個拎走咗，因為模型已經可以連續寫代碼唔會走偏。Evaluator 都從每個 Sprint 後評分改成咗全部開發完再做一輪 QA。

Anthropic 認為 harness 應該為減法而設計。每個組件都應該可以被安全移除，而唔係越堆越厚。權限分類器都係同一思路，模型能力到咗之後，好多需要人類確認嘅操作可以自動放行（所以後來新增咗 Auto 權限模式）。

Hermes Agent 嘅思路有啲唔同。佢認為有啲嘢唔會因為模型變強而過期：五層記憶系統、技能文件沉澱、跨會話搜索、用戶建模。模型再強，都需要知道「上次呢個用戶叫我做過啲咩」同埋「呢類任務我上次係點樣解決」。

Hermes 甚至有一個獨立嘅 hermes-agent-self-evolution 倉庫，用 DSPy 同 GEPA 嚟做自動化嘅技能優化。具體做法係：跑一組評估任務，比較優化前後嘅技能文件喺完成效率同準確率上嘅差異，自動選擇更好嘅版本。目前實現咗 Phase 1 嘅技能文件優化，Phase 2 計劃覆蓋工具描述同系統提示詞。老實講，呢個想法幾得意，相當於俾 Agent 加咗一個慢速但持續嘅自然選擇過程。雖然模型會趨同，但邊個能夠將每次任務變成下一次嘅能力，邊個就有複利。

OpenClaw 嘅基礎設施層幾乎唔受模型進步影響。Gateway 唔會因為 Claude 變強就唔需要。多入口路由唔會過期，設備節點唔會過期，會話隔離唔會過期，權限分層唔會過期。

模型會越來越強，但連接現實世界嘅管道唔會自動出現。你始終需要一個嘢去管理「邊個喺幾時通過咩入口叫 Agent 做啲咩」，模型再強都取代唔到呢一層。

三個方向，對應三種對「模型進步會淘汰啲咩」嘅判斷。OpenClaw 認為基礎設施唔會過期，所以起管道。Hermes 認為經驗累積唔會過期，所以做加法。Claude Code 認為大部分腳手架會過期，所以做減法。

寫喺最後

得意嘅係，三條路正在向同一個方向收斂。Claude Code 加咗 auto memory 同 channels，Hermes 加咗 Gateway 同多平台適配，OpenClaw 做緊 Context Engine 可插拔化。起點唔同，但目的地越來越似：一個有記憶、有技能、有入口、有權限、有持久狀態嘅個人 AI 系統。

而家睇每個項目都係唔同嘅路，再過半年或者一年好可能就係同一個產品嘅三個發展階段。所以，揀選用邊啲 Agent 嗰陣，與其問邊個好啲，不如問自己更缺啲咩：缺入口同連接，睇 OpenClaw；缺經驗沉澱，睇 Hermes；咩都唔缺只想等模型充分發揮，Claude Code 就夠。

好啦，今日就傾到呢度。如果你都喺關注 AI Agent 嘅架構設計，歡迎關注 Feisky 公眾號，我會定期分享實踐入面嘅發現同踩坑經驗。

這個理解沒錯，但只是眾多理解中的一種。

最近我把 Claude Code、Hermes Agent 和 OpenClaw 的源碼和架構文檔都翻了一遍，發現一個挺有意思的事：這三個項目嘴上都在說 Harness，但做出來的東西完全不一樣。Claude Code 把 Harness 當腳手架，越輕越好，模型能搞定的事就別替它做。Hermes 把 harness 當學習系統，每次任務都在積累經驗，越用越聰明。OpenClaw 把 Harness 當基礎設施，Gateway、路由、設備節點、任務調度，跟模型強不強沒什麼關係。

對 Harness 的理解不同，造出來的產品就完全不同。下面我就帶你一起拆開看看它們都是如何設計 Harness 的。

Harness 核心設計

從這三個項目的代碼結構和設計文檔上，很容易發現它們的架構設計具有明顯的不同。

OpenClaw 的核心是 Gateway。官方架構文檔第一句也寫明瞭他是一個 long-lived Gateway 擁有所有 messaging surfaces。CLI、macOS app、Web UI、自動化任務，全部通過 WebSocket 連接 Gateway。

手機、Mac、遠程設備也通過同一個協議接入，只不過聲明自己是 node，暴露攝像頭、屏幕、Canvas 等能力。Gateway 默認監聽 127.0.0.1:18789，連 Canvas 和 A2UI 都由同一個 HTTP server 託管。

也就是說，OpenClaw 把多入口收束成了單控制平面。你從 Telegram 發消息，從 Web UI 操作，從手機節點觸發，最終都進入同一套協議、同一套會話管理、同一套工具策略、同一套事件流。也就是說，OpenClaw 先做了神經系統，而不是大腦。

Hermes Agent 的核心是 AIAgent。它通過一個1萬多行的代碼，整合了 prompt 裝配、provider 選擇、工具執行、重試、fallback、上下文壓縮、會話持久化等所有的核心功能。CLI、Gateway、ACP、Batch Runner、API Server 這些入口最終都收斂到一起，後來才逐漸補充了 Gateway 和 messaging 平台的適配。

Hermes 的優先級是先把 Agent Loop 做到足夠強，讓它支持併發工具調用、子代理委派、多 provider fallback、上下文壓縮保護，然後再考慮怎麼把這個大腦連上外面的世界。

Claude Code 的核心既不是 Gateway 也不是 Agent Loop，而是權限系統和上下文管理。正如《Managed Agents 架構拆解：Anthropic 給 Agent 造了一套 K8s》裏提到的，Anthropic 把 Agent 的組件拆成了 session、harness、sandbox 三個獨立接口，每個可以獨立替換。Claude Code 的源碼也是這個思路的體現。

翻它之前泄漏的源碼，最龐大的模塊是權限相關的代碼，處理了六種權限模式、八個權限來源、分類器自動審批、hook 擴展等等。而主循環本身反而很薄，只是負責把每輪完整消息歷史交給模型，工具執行完立刻流式返回，沒有複雜的調度算法。

Claude Code 的設計哲學可以總結為信任模型+管好邊界。模型自己決定調用什麼工具、按什麼順序執行、什麼時候停下來。Harness 不替模型做決策，只在兩個地方卡住：你有沒有權限做這件事，上下文是不是快溢出了。

三個項目對 Harness 的理解，在這一層就分化了。OpenClaw 把重心放在多入口收束和協議統一，Hermes 把重心放在 Agent Loop 的能力密度，Claude Code 把重心放在權限管控和上下文保護。

記憶系統設計

記憶是 Agent 從臨時工變成長期搭檔的關鍵一步。三個項目在這件事上的做法差異也很大。

Claude Code 的方案最簡單，簡單到有點反直覺。CLAUDE.md 文件前綴加載，每次會話開始時注入 system prompt。Auto Memory 讓模型自己往 ~/.claude/ 目錄下寫 Markdown 文件，MEMORY.md 作為索引（最多 200 行、25KB）。沒有向量檢索，沒有 embedding，沒有外部數據庫。記憶不是主動召回的，而是作為上下文的一部分被模型看到。

上下文壓縮也是反應式的：上下文窗口用到快滿了才觸發壓縮。壓縮方式是 fork 一個新的 Claude 實例來做摘要，壓縮算法會保護工具調用和結果的完整性，不會把一個 tool call 和它的 result 切開。如果壓縮連續失敗三次，circuit breaker 會停掉，避免死循環。

這個方案的好處是簡單、可預測、不依賴外部服務。代價是記憶容量有限，跨會話的信息密度完全取決於 CLAUDE.md 寫得好不好。

Hermes Agent 把記憶做成了分層系統。第一層是 MEMORY.md 和 USER.md，類似 Claude Code 的方案，保存在 ~/.hermes/memories/，會話開始時注入 prompt。第二層是 SQLite + FTS5 全文搜索，所有歷史會話都能被檢索和摘要。第三層是 8 個外部 memory provider 插件，包括 Honcho、Mem0、Hindsight 等。

Honcho 的設計值得單獨說一下。它不只做向量檢索，而是把用戶和 AI 都建模為 peer，做跨會話的辯證推理，維護用戶表徵和 session summary。啓用後，Hermes 每輪前會預取相關記憶，每輪後同步對話，會話結束時抽取長期記憶。

Hermes 的記憶哲學是：模型的短期記憶不夠用，需要系統幫它在多個時間尺度上積累和召回信息。這和 Claude Code  模型自己能搞定的思路差別挺大的。

OpenClaw 則走了另一條路：把 Context Engine 做成可替換的運行時插件，控制如何構建模型上下文，決定包含哪些消息、如何摘要舊歷史、如何跨 subagent 管理上下文。內置的是 legacy engine，但插件可以註冊完全不同的 engine。

每次模型運行時，engine 有四個生命週期點：ingest(消息進來時)、assemble(構建上下文時)、compact(壓縮時)、after turn(一輪結束後)。插件 engine 甚至可以返回 systemPromptAddition，動態注入召回指導或檢索提示。

OpenClaw 的會話管理也很講究：DM 默認共享 session，羣聊按 group 隔離，rooms 按 room 隔離，cron 每次新 session。多 Agent 場景下，每個 Agent 有獨立的 workspace、auth profile、session store。

OpenClaw 的記憶哲學不是記更多，而是讓記憶管理本身成為一個可插拔的系統服務。長期 Agent 的記憶需求會不斷變化，與其內置一套固定方案，不如把接口留好，讓生態去填充。

三種方案，背後是三種對Agent 該記什麼的不同理解。Claude Code 覺得模型夠聰明，給它看到就行。Hermes 覺得光看到不夠，得幫它在多個時間尺度上積累。OpenClaw 覺得記憶本身的需求會變，不如把接口留好。

擴展性設計

接下來再來看看擴展性的設計，這是讓 Agent 能搜索、瀏覽網頁、生成圖片、讀寫文件等各種外置能力的關鍵。

OpenClaw 把能力擴展拆成了三層：內置 Tools 是 Agent 可以隨時調用的預裝能力，Skills 是教 Agent 什麼時候用、怎麼用外部工具的擴展能力，而 Plugins 則是打包了工具、技能、消息通道、模型等各種擴展的能力包。

這個三層模型把三個容易混淆的東西拆開了：工具是默認能做什麼，技能是什麼時候/怎麼樣去調用外部工具，插件是怎麼打包、發現、分發這些能力。ClawHub 上架了 58000 多個社區 Skill，一條命令安裝，這對於帶火 OpenClaw 功不可沒。

Hermes Agent 的工具系統用了 registry 自注冊模式。tools/registry.py 是中心註冊表，每個工具文件在模塊級調用 registry.register() 聲明 schema、handler、toolset 歸屬和可用性檢查。model_tools.py 是 registry 之上的薄編排層，負責導出工具定義、處理函數調用、維護工具到 toolset 的映射。

有個很細的設計：model_tools.py 會根據當前真正可用的工具重建 execute_code 的 schema。比如 web API key 沒配置，模型就不會在 sandbox 裏看到 web_search 這個工具。這能減少模型“以為自己能做但其實做不了”的幻覺式調用。

Hermes 的技能系統用了 progressive disclosure：Level 0 只加載 name 和 description，Level 1 加載完整技能內容，Level 2 加載技能引用的附件。模型先掃描技能列表，匹配到了再深入加載。更關鍵的是，Agent 可以通過 skill_manage 自己創建、更新、刪除技能。解決了一個非平凡任務後，它可以把方法保存為技能文件，下次遇到類似問題直接複用。

這就是 Hermes 說的“程序性記憶”。普通 Agent 完成任務後只留下結果，Hermes 完成任務後還試圖留下方法。當你積累 20 個以上自創技能後，同領域任務完成速度能提升 40%。

Claude Code 的擴展體系跟前兩者的思路都不一樣，它不是圍繞工具註冊或技能發現來組織的，而是圍繞權限邊界層層展開的。

最底層是 28 個內置工具，覆蓋文件讀寫、搜索、Shell 執行、Web 訪問、子代理調度等基礎能力。這些工具分兩類：Read、Glob、Grep 這類只讀工具不需要權限，Bash、Edit、Write 這類有副作用的工具每次執行都要過權限檢查。權限不在工具註冊時聲明，而是在執行時由 harness 攔截，模型不需要考慮“我能不能做這件事”，該攔的時候自然會攔。

往上一層是 MCP 協議。Claude Code 通過 MCP 接入外部工具服務器，支持 stdio、HTTP、SSE 三種傳輸方式。MCP 工具默認是延遲加載的：會話開始時只把工具名稱放進上下文，模型需要用的時候通過 ToolSearch 工具按需拉取完整 schema。這個設計跟 Hermes 的 progressive disclosure 異曲同工,只是實現路徑不同，一個在技能層做分級加載,一個在工具層做延遲發現。

再往上是 Hooks、Skills 和 Plugins 三層擴展。Hooks 提供了 25 個生命週期事件，可以掛 shell 命令、HTTP 請求、甚至 LLM 評估。Skills 遵循開放的 Agent Skills 標準，用 Markdown + YAML frontmatter 定義可複用的工作流,，持參數替換和條件觸發。Plugins 則是把 Skills、Hooks、MCP 配置、子代理定義打包成一個可分發的單元。

子代理是 Claude Code 處理複雜任務的核心機制。每個子代理運行在獨立的上下文窗口裏,有自己的系統提示和會話歷史。內置了 Explore（快速搜索，用 Haiku 模型）、Plan（規劃研究）、general-purpose（全功能）等預設類型，也支持通過 .claude/agents/ 目錄自定義。自定義子代理可以精細控制工具白名單、權限規則、模型選擇,甚至預加載特定 Skills。

能力管理的複雜性往哪放？OpenClaw 交給社區生態，Hermes 交給 Agent 自身的積累，Claude Code 交給分層的權限邊界。

怎麼面對模型進步

這個維度最值得琢磨。

Anthropic 有一個很有意思的觀察：harness 編碼的是對模型能力邊界的假設，但模型在進步，假設會過期。Sonnet 4.5 的時候模型有上下文焦慮，隨着上下文窗口接近極限會提前收工，harness 里加了重置機制來應對。結果換到 Opus 4.5，這個行為自己消失了，重置機制變成了死代碼。

Claude Code 對這一點的應對是大量的功能開關，從它泄露的源碼能看到大量 HISTORY_SNIP、REACTIVE_COMPACT、TRANSCRIPT_CLASSIFIER 等等這樣的開關。比如，到了 Opus 4.6，之前在 harness 里加的 Sprint 機制（把長任務拆成小塊、每塊結束後評估）就被整個拿掉了，因為模型已經可以連續寫代碼不跑偏。Evaluator 也從每個 Sprint 後評分改成了全部開發完再做一輪 QA。

Anthropic 認為 harness 應該為減法而設計。每個組件都應該能被安全移除，而不是越堆越厚。權限分類器也是同一思路，模型能力到了之後，很多需要人類確認的操作可以自動放行（所以後來新增了 Auto 權限模式）。

Hermes Agent 的思路不太一樣。它認為有些東西不會因為模型變強而過期：五層記憶系統、技能文件沉澱、跨會話搜索、用戶建模。模型再強，也需要知道“上次這個用戶讓我做過什麼”和“這類任務我之前是怎麼解決的”。

Hermes 甚至有一個單獨的 hermes-agent-self-evolution 倉庫，用 DSPy 和 GEPA 來做自動化的技能優化。具體做法是：跑一組評估任務，比較優化前後的技能文件在完成效率和準確率上的差異，自動選擇更好的版本。目前實現了 Phase 1 的技能文件優化，Phase 2 計劃覆蓋工具描述和系統提示詞。說實話，這個想法挺有意思的，相當於給 Agent 加了一個慢速但持續的自然選擇過程。雖然模型會趨同，但誰能把每次任務變成下一次的能力，誰就有了複利。

OpenClaw 的基礎設施層幾乎不受模型進步的影響。Gateway 不會因為 Claude 變強就不需要了。多入口路由不會過期，設備節點不會過期，會話隔離不會過期，權限分層不會過期。

模型會越來越強，但連接現實世界的管道不會自動出現。你還是需要一個東西來管理“誰能在什麼時候通過什麼入口讓 Agent 做什麼事”，模型再強也替代不了這一層。

三種方向，對應三種對“模型進步會淘汰什麼”的判斷。OpenClaw 認為基礎設施不會過期，所以建管道。Hermes 認為經驗積累不會過期，所以做加法。Claude Code 認為大部分腳手架會過期，所以做減法。

寫在最後

有意思的是，三條路正在往一個方向收斂。Claude Code 加了 auto memory 和 channels，Hermes 加了 Gateway 和多平台適配，OpenClaw 在做 Context Engine 可插拔化。起點不同，但目的地越來越像：一個有記憶、有技能、有入口、有權限、有持久狀態的個人 AI 系統。

現在看每個項目都是不同的路，再過半年或者一年很可能就是同一個產品的三個發展階段了。所以，在選擇使用哪些 Agent 時，與其問哪個更好，不如問自己更缺什麼：缺入口和連接，看 OpenClaw；缺經驗沉澱，看 Hermes；什麼都不缺只想讓模型充分發揮，Claude Code 就夠了。

好了，今天就聊到這兒。如果你也在關注 AI Agent 的架構設計，歡迎關注 Feisky 公眾號，我會定期分享實踐中的發現和踩坑經驗。