# 策展 · X (Twitter) 🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：Aparna Dhinakaran (@aparnadhinak) · 平台：X (Twitter) · 日期：2026-05-31

> 原始來源：https://x.com/aparnadhinak/status/2060406977357070522

## 中文摘要

# Hermes Harness 架構

Hermes（來自 @NousResearch）是目前生態系統中最優秀的開源 harness 之一。我們希望直接檢視其程式碼實作，並將我們的發現對應到我們用於分析 harness 的架構框架中。

在我們之前的文章《什麼是 Agent Harness》中，我們使用了一個九部分模型：

- 外部迭代迴圈 (outer iteration loop)
- 記憶體管理與壓縮 (context management and compression)
- skill 與工具管理 (skills and tools management)
- 子 Agent 管理 (subagent management)
- 內建預封裝 skill (built-in pre-packaged skills)
- 工作階段持久化與復原 (session persistence and recovery)
- 系統提示詞組裝與專案記憶體注入 (system prompt assembly with project context injection)
- 生命週期掛鉤 (lifecycle hooks)
- 權限與安全層 (permission and safety layer)

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

Hermes 實作了上述所有九個部分。有趣的地方在於它如何實作這些功能，以及它在該框架之外所具備的額外系統。

## 外部迭代迴圈 (The outer iteration loop)

核心迴圈很常見：模型呼叫、工具分派、附加工具結果，重複直到獲得最終回應或中斷。

Hermes 比大多數開放式 harness 強大的地方在於其供應商抽象化。相同的執行時期（runtime）可以驅動 chat-completions 風格的 API、Anthropic Messages、Codex Responses、處理程序外的 Codex 應用伺服器路徑以及 Bedrock。工具呼叫格式和供應商的特性會透過傳輸轉接器（transport adapters）進行標準化。在迴圈層級上，模型介面看起來是一致的。對於我們這些非常喜歡擁有一個支援所有模型的開放式 harness 供應商的人來說，這種開放式方法比 Claude Code 好得多。

## 記憶體管理與壓縮 (Context management and compression)

Hermes 擁有完整的壓縮路徑，而不僅僅是簡單的記憶體修剪。

較舊的對話輪次會由輔助模型進行摘要。頭部和尾部區段會受到 token 預算的保護。超過可配置閾值的工具輸出會在摘要前被刪除。摘要預算會隨著壓縮內容按大約 20% 的比例縮放，並設有 2,000 個 token 的下限和 12,000 個 token 的上限。實際上，這避免了在微小的壓縮上花費過多記憶體，同時仍為大型壓縮留出了足夠的空間以發揮作用。

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

壓縮也是一個工作階段生命週期事件。在壓縮時，Hermes 會關閉目前的 SQLite 工作階段列，建立一個由摘要作為種子的子工作階段，輪替工作階段 ID，並記錄父子關係。Plugin 記憶體引擎和記憶體提供者會收到邊界移動的通知。如果一個長對話多次壓縮，你會得到一個關係鏈，而不是一個被重複重寫的轉錄檔。相較於我們審查過的其他 harness 架構，這是相當獨特的。

## Skill 與工具管理 (Skills and tools management)

在 Hermes 中，工具註冊與工具暴露是兩個獨立的關注點。

工具在匯入時會註冊到中央註冊表中。一個獨立的 toolset 層決定了模型在特定執行中實際能看到什麼。該暴露集合由平台和場景進行範圍限制，並可針對委派執行再次縮小範圍。每個設定檔（profile）都有其專屬的啟用範圍。

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

這種分離在操作上很重要。你可以保留一個廣泛的已安裝工具庫，同時將單次執行中模型可見的表面積保持在足夠小的範圍內，以利於管理 token 成本和安全性。

## 子 Agent 管理 (Subagent management)

委派原語（delegation primitives）非常穩固。子執行會獲得自己的任務 ID、自己的終端記憶體，並向父級返回結構化摘要。危險指令在委派記憶體中預設為拒絕，且遞迴深度有限制。

目前的限制在於生命週期所有權。大多數子工作仍然存在於父呼叫路徑下。當父級完成時，子級也就完成了。目前還沒有一個具備獨立控制語義、可從外部導向的持久化子執行平面。

## 工作階段持久化與復原 (Session persistence and recovery)

這是 Hermes 與「編輯器優先」的 harness 差異最大的地方。

工作階段狀態儲存在具有 FTS5 搜尋和 WAL 日誌記錄功能的 SQLite 中，並針對無法支援 WAL 協調的檔案系統提供備援行為。工作階段會追蹤對話輪次的來源標籤、壓縮分割的父子關係，以及閘道器（gateway）在模型執行前可用於解析路由的中繼資料。

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

這種設計有效地將工作階段視為執行時期基礎設施，而不僅僅是為了恢復而存在的轉錄檔。CLI、訊息平台和排程工作都可以連接到同一個工作階段平面。訊息可以在推論前路由到正確的工作階段。即使沒有活動的終端，排程工作也可以寫入工作階段。

Hermes 還公開了一個面向模型的 `session_search` 工具，用於針對過往工作階段進行聚焦回憶。這是將記憶體管理決策推入模型迴圈本身，而不是僅僅依賴靜態注入的一個具體範例。

## 系統提示詞組裝與專案記憶體注入 (System prompt assembly and project context injection)

Hermes 明確地將系統提示詞分為三個層級：穩定層（stable）、記憶體層（context）和易變層（volatile）。

穩定層包含身份資訊（存在時為 SOUL.md）、僅針對已啟用工具的工具指引、skill 索引內容、環境提示（如 Tmux/容器偵測）以及平台提示。記憶體層會從當前工作目錄（cwd）讀取專案檔案（AGENTS.md、CLAUDE.md、.cursorrules），並在載入該內容前執行提示詞注入掃描。易變層包含記憶體快照、使用者設定檔素材、外部記憶體提供者區塊，以及帶有模型/供應商中繼資料的時間戳記行。

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

分層本身在程式碼中是明確的，這使得不變量更容易進行推理。穩定層保持穩定，記憶體層保持從 cwd 衍生，易變層則隨對話輪次變化。提示詞重建與壓縮及相關的失效點掛鉤，這有助於在正常對話輪次中保持提示詞前綴對快取友善。

## 生命週期掛鉤 (Lifecycle hooks)

Hermes 有兩個具有不同信任模型的掛鉤表面。

首先，plugin 生命週期掛鉤在 harness 處理程序內執行，可以在工具呼叫前後、閘道器預分派以及批准請求/回應等事件中封鎖、重寫或透過操作。其次，檔案系統驅動的閘道器掛鉤允許使用者安裝在閘道器啟動、Agent 步驟和指令觸發路徑等事件上執行的 Shell 或 Python 腳本。

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

在架構上，這兩個表面服務於相同的目的：策略執行、稽核和主機副作用應獨立於模型的配合而執行。

## Hermes 在框架之外的增強

除了九組件 harness 模型外，有三個子系統脫穎而出。

第一個是訊息閘道器。Hermes 支援廣泛的平台轉接器表面（Telegram、Discord、Slack、WhatsApp 等），並透過共用的工作階段模型路由流量。這感覺像是一種在 OpenClaw 中取得成功的 UI 體驗，專為使用者與長時間運行的 Agent 互動而設計。

第二個是設定檔系統。設定檔是一個隔離的 Agent 根目錄。在同一台機器上的兩個設定檔，從狀態和佔用空間的角度來看，表現得就像兩個不同的 Agent。

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

第三個是作為一等公民子系統的 cron。工作是持久化的，受到與互動式工作階段相同的權限機制保護，透過閘道器路徑傳遞，並按設定檔隔離。這將無人值守操作的考量強制納入主架構中，而不是將其作為周邊腳本處理。

## 我們認為 Hermes 的下一步方向

顯而易見的下一步是從強委派轉向一等公民的編排（orchestration）。

`delegate_task` 已經產生了有用的工作者行為和結構化回傳。目前還缺少的是持久化的子執行控制：執行 ID、明確的生命週期管理、外部導向以及在父級完成後仍能存續的清理語義。Hermes 已經透過工作階段基礎設施和閘道器路由擁有了大部分基底。將子執行提升為一等公民控制平面物件，是最自然的下一步架構演進。這是我們看到它與 OpenClaw Agent 編排層相比的差距之一。

## 結語

Hermes 已經具備了出色的執行品質和強大的系統基礎，足以成為一個開放式的 harness。它可能是目前生態系統中最優秀的開放模型 harness 之一。其發布節奏簡直……瘋狂，而且大部分困難的基礎工作都已經到位。很期待看到 Agent 編排層在該基礎上成熟。Hermes 已經能夠支援比當前典型程式開發 harness 所能處理的更廣泛、長壽命的 Agent 工作負載，期待看到它的發展。

本文參考了我之前撰寫的《什麼是 Agent Harness》作為框架，並受到 Agent harness 中的 Swarm 管理以及 Anthropic 關於 Managed Agents 文章的啟發。

## 標籤

Agent, 開源專案, 研究論文, NousResearch, Hermes