四個 Agent 框架，四種對「穩定性」的理解
這個系列讀了四個框架：hermes-agent、OpenClaw、CrewAI、Claude Code。每一個都在解「讓 Agent 在真實環境裡工作」這個問題，但讀到最後，它們對這件事的理解差得很遠。
這篇想做的事很簡單：把四個框架放在同一張桌上，用四個維度比較它們——上下文管理、控制流設計、錯誤恢復、反饋迴路。不是要評選哪個更好，而是試著說清楚這些差異從哪裡來，以及它們背後是哪些不同的問題意識。
可插拔的共識：所有框架都長成了機甲
在進入差異之前，有件事值得先說：這四個框架，在架構的最底層，收斂到了幾乎相同的模式。
它們都把 Agent 系統設計成一個可插拔的模組集合。核心是一個執行迴圈，但圍繞著它的每一個能力層，都被設計成可以抽換的：
| 能力層 | hermes | OpenClaw | CrewAI | Claude Code |
|---|---|---|---|---|
| 工具 | 40+ tools，tool registry | 40+ tools，Plugin SDK | BaseTool ABC | MCP 動態擴展 |
| 記憶 | 8 種 MemoryProvider ABC | vector / QMD 後端可選 | LanceDB / ChromaDB 可換 | MCP 提供 memory |
| Model | OpenAI-compat 任意端點 | 40+ provider 輪換 | LangChain BaseLLM | model flag |
| Skills | SKILL.md + Skills Hub | bundled skills | Skill 模組系統 | 20 bundled + MCP 動態 |
| 其他 Agent | SubAgent tool | SubagentRegistry spawn | Hierarchical manager + A2A | Agent tool + Team tools |
| Plugin / Hook | 13 個 hook 注入點 | 100+ plugins，Plugin SDK | callbacks + Flow decorators | Hooks / Skills / MCP 三層 |
這個結構有點像機甲機器人：框架本身是骨架和驅動核心，但手臂（工具）、記憶體（Memory）、行為程式（Skills）、外接模組（MCP / Plugin）都是可以根據場景抽換的零件。你在 coding 場景需要 bash + file tools；在研究場景需要 web search + 向量記憶；在企業流程場景需要 A2A 跨服務通信，換的是零件，不是重寫框架。
這個共識不是偶然的。它說明 Agent 系統有一組「幾乎所有人都踩過同樣的坑之後，收斂出來的設計判斷」：工具不能焊死，記憶後端不能焊死，模型不能焊死。把這些抽成介面，才能在不同場景下複用同一個框架。
但可插拔是共識，插什麼、怎麼插、什麼時候插，才是每個框架真正分歧的地方。
上下文管理 — 滿了之後留什麼
Context window 滿了是必然，每個框架都必須回答：壓縮的時候，留什麼？
這個問題的答案直接反映了框架對「對話裡什麼是有價值的」的假設：
hermes-agent：用 LLM 做摘要壓縮。先截短 tool call 結果（冗長、保留價值低），找到合適的邊界，送給 LLM 做段落摘要，用摘要替換原始內容。保留的是語意上重要的東西，由 LLM 判斷。Memory Fencing 把召回的記憶用 XML 包住，告訴模型「這是我記得的事，不是你剛說的話」，防止語意污染。
OpenClaw：同樣用 LLM 做摘要，但加了一道 Identifier Preservation Policy。原因是 LLM 在重構文字時傾向讓輸出「更易讀」，會自作主張縮短 UUID、重構 IP 地址、簡化 filename。壓縮後 Agent 拿著被改過的識別符去操作，當然找不到。strict 模式強制 UUID 就是 UUID，一字不改。LLM 的語意判斷加上規則層保護，兩層並用。
CrewAI：記憶系統的複雜度是這四個框架裡最高的。EncodingFlow 的 4-group 分類讓系統自己決定每條記憶的 scope、categories、importance——Group A（呼叫者自己填好，0 次 LLM 呼叫）到 Group D（什麼都讓系統推斷，2 次並行 LLM 呼叫）。召回時用複合評分（語意相似性 0.5 + 時效衰減 0.3 + LLM 推斷的重要性 0.2），RecallFlow 的 adaptive depth 在信心不夠時會繼續深挖。保留的是「系統認為重要」的東西。
Claude Code：唯一不用 LLM 做壓縮的框架。本地確定性算法，XML 結構化：“ 裡的推理過程丟棄，<summary> 裡的工作狀態保留（pending work、動過的 files、最近 3 個 request、timeline）。沒有額外成本，沒有隨機性。
| hermes | OpenClaw | CrewAI | Claude Code | |
|---|---|---|---|---|
| 壓縮方法 | LLM 摘要 | LLM 摘要 + 識別符保護 | LLM 評分 + 向量召回 | 本地確定性算法 |
| 留什麼 | 語意重要的內容 | 語意摘要，但識別符完整 | 重要性加權的記憶 | 工作狀態事實 |
| LLM 參與 | 是 | 是（+ 規則保護） | 是（深度參與） | 否 |
| 成本可預測性 | 中 | 中 | 低（Group D 難預測） | 高 |
核心分歧：選擇用不用 LLM 壓縮，本質上是在決定「context 的語意判斷，由框架主導還是由 LLM 主導」。CrewAI 把最多決策權給了 LLM，代價是成本難預測；Claude Code 完全不信任 LLM 的判斷，只留確定性事實。
控制流設計 — 誰決定下一步
四個框架的控制流從最扁平到最複雜，差距很大。
hermes-agent 和 Claude Code：扁平迴圈。核心邏輯是 while LLM 還在呼叫工具: 執行工具，直到 LLM 不再呼叫工具就結束。hermes 用 Middleware Stack（有序疊加的能力層）豐富了工具集，Claude Code 用 Bootstrap 7-stage 序列（含 trust gate 後才啟動 plugin/skill/MCP）管理啟動流程，但執行本身都是扁平的。扁平迴圈的優點是可測試、可推理，代價是天然不支援複雜的多 Agent 協作。
OpenClaw：有狀態的多 Agent 樹。SubagentRegistry 持久化每個 subagent 的生命週期（PENDING → RUNNING → COMPLETE | ERROR | KILLED），AnnounceFlow 讓 subagent 完成後非同步交付結果（parent 不 blocking，保持活躍），SessionKey 在一個 string 裡編碼 agent 身份、session 歸屬和 subagent 深度。這套機制的複雜度來自一個問題：Gateway crash 的時候，正在跑的 subagent 怎麼辦？Orphan Recovery 的需要，直接導致了 Registry 持久化的必要。
CrewAI：宣告式 DAG。用兩層分離解決兩個不同的問題：Crew 回答「誰做什麼」（Sequential 是靜態分工，Hierarchical 是 Manager 動態決策），Flow 回答「什麼時候做」（@start/@listen/@router 建立事件驅動的路由圖）。@router 的返回值在 class 定義時就用 AST 解析，所以路由圖可以靜態渲染。AND/OR 觸發條件讓多路並行和 barrier 收斂都能宣告式地表達。
控制流的複雜度和錯誤恢復的複雜度幾乎是正相關的。OpenClaw 的多 Agent 生命週期管理帶出了 Orphan Recovery；CrewAI 的 Hierarchical 模式帶出了 Manager 的 LLM 呼叫成本；而 hermes 和 Claude Code 的扁平迴圈，讓錯誤處理的問題更容易被推到其他層去解決。
錯誤恢復 — 出錯之後怎麼辦
這個維度最能揭示框架的威脅模型。四個框架的錯誤處理，發生在不同的層。
執行前預防（Claude Code）
Hook + Permission system 在工具執行之前就決定能不能跑。exit 2 是「永遠不讓這件事發生」，不是「發生了再補救」。Permission 系統的有序 enum（ReadOnly < WorkspaceWrite 結語：設計一個 Agent 系統，最重要的決策不是用哪個框架，而是先回答一個問題：在你的場景裡，「Agent 壞掉」最壞的情況是什麼？是輸出錯誤、是服務中斷、是執行造成傷害，還是永遠停在現在的能力水平？選定這個問題，後面的設計幾乎就跟著定了。