# 策展 · X (Twitter) 🔥🔥🔥🔥

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

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

## 中文摘要

# Agent Harness 的 Swarm 管理

我們在 Arize 內部構建了自己的 harness 管理工具，同時觀察到像 @cognition 的 Devin 開始管理其他 Devin、@AnthropicAI 的託管 Agent，以及 Cursor 的 @leerob 所開發的長期運行 Agent，有一件事變得顯而易見：Swarm 管理是 AI 領域下一個真正的系統性難題。

不是單一 Agent，也不是一次性的工具呼叫，而是管理長期運行的 Agent Swarm。

大多數 Agent 框架已經跨過了第一道門檻：它們可以生成子 Agent。

但那並不是 Swarm 管理。

那只是問題的開端。

有趣的問題在於子 Agent 產生之後會發生什麼？它住在哪裡？誰擁有它？它能被定址嗎？它能被引導嗎？當父 Agent 結束任務後，它還能繼續執行嗎？如果程序重啟，系統知道還有什麼在運行嗎？

這是 Agent harness 之上的下一個層級。Harness 讓一個 Agent 可以呼叫工具、讀取文件、執行指令並保持迴圈運作。委派工具（Delegation tool）讓一個 Agent 可以借用工作者。而 Swarm 管理器則擁有一支艦隊。

Agent harness 的核心功能是圍繞工具的迴圈。而 Swarm 管理器則是圍繞運行中 harness 的迴圈，確保它們持續推進。

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

這種區別聽起來很學術，直到你審視真實的系統。

Hermes 有一個非常好的委派原語（primitive）。它的 `delegate_task` 工具可以建立子 AIAgent 實例、並行運行它們、串流傳輸進度、應用逾時、中斷它們，並將結構化的摘要回傳給父 Agent。簡潔、實用、易懂。

但子 Agent 存在於父 Agent 的工具呼叫內部。

當我們在生態系統中尋找真正運作中的 Swarm 管理範例時，最棒的例子之一其實一直就在眼前：OpenClaw。

OpenClaw 擁有一個紮實的 Swarm 管理系統。它的子 Agent 會成為閘道會話（gateway sessions）。它們擁有持久的會話金鑰、運行 ID、生命週期記錄、父子血緣關係、清理策略，以及一條基於推送（push-based）的回傳路徑，將結果送回請求者。

這就是架構上的分界線。

委派（Delegation）問的是：一個 Agent 如何拆分工作？而 Swarm 管理問的是：一個執行環境如何長期擁有並管理多個 Agent？

這篇文章將花費大量篇幅，根據 OpenClaw 中的許多概念，強調我們認為 Swarm 管理中必須具備的要素。

## Agent 需要一個 ID

Swarm 管理的第一個要求是識別性（identity）。

如果你無法定址一個子 Agent，你就無法管理它。你可以等待它完成，可以取消本地的 future，也可以要求父 Agent 總結發生了什麼。

但你無法操作一支艦隊。

在 OpenClaw 中，生成的子 Agent 會獲得一個會話金鑰：

`agent:<targetAgentId>:subagent:<uuid>`

這個金鑰正在發揮真正的作用。

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

它將子 Agent 變成了閘道可以識別的物件。子 Agent 可以被列出、被修補、被刪除，也可以連結回父 Agent。它能與一般的聊天會話、Cron 會話和 ACP 會話並列顯示。

子 Agent 還會獲得一個運行 ID（run ID）。會話金鑰命名了子 Agent 的居住地，而運行 ID 則命名了當前的執行過程。

這兩者缺一不可。

Swarm 管理器必須掌握基本資訊：子會話金鑰、運行 ID、請求者、控制器、深度、角色、workspace、任務標籤、清理策略、時間戳記和結果。這些元資料（metadata）回答了執行環境無法含糊帶過的問題。

是誰生成了這個子 Agent？它還在運行嗎？它有後代嗎？它應該作為會話保留，還是完成後刪除？結果真的送達了嗎？

如果這些答案只存在於模型的 context window 中，執行環境就無法管理 Swarm。

## 完成不只是一個回傳值

大多數委派系統都有一個簡單的合約：

1. 父 Agent 呼叫工具。
2. 子 Agent 運行。
3. 父 Agent 阻塞（等待）。
4. 子 Agent 回傳摘要。
5. 父 Agent 繼續。

這對於有界限的委派來說是一個很好的合約。

但一旦父 Agent 不僅僅是在等待同一個呼叫堆疊時，這個合約就會失效。

在真正的 Swarm 中，父 Agent 可能處於活躍狀態、閒置狀態、可能是另一個子 Agent、可能已重啟，或者已經消失。子 Agent 可能擁有自己的子 Agent。結果可能需要作為私有的編排上下文（orchestration context），而不是使用者可見的訊息。

OpenClaw 使用基於推送的模型來處理這個問題。`sessions_spawn` 會回傳接受狀態與簿記資訊。結果稍後會透過註冊表（registry）和宣告流程（announce flow）送達。

大致流程如下：

1. 父 Agent 透過 `sessions_spawn` 生成子 Agent。
2. OpenClaw 建立一個子會話。
3. 子 Agent 的運行被註冊。
4. 子 Agent 在自己的會話中運行。
5. 註冊表等待生命週期完成。
6. OpenClaw 擷取子 Agent 的最新輸出。
7. 它建立一個內部的 `task_completion` 事件。
8. 它將該事件路由回請求者會話。

關鍵部分在於這個事件：

```json
{
  type: "task_completion",
  source: "subagent",
  childSessionKey,
  childSessionId,
  taskLabel,
  status,
  result,
  replyInstruction
}
```

這就是父子合約：捕捉完成狀態、保留來源資訊、將其路由到正確的會話，並讓該會話決定下一步做什麼。

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

交付層（delivery layer）具有策略。它可以引導活躍的請求者會話、將宣告排入佇列以供稍後處理、直接呼叫閘道 Agent 方法、傳送使用者可見的頻道訊息、重試，或退回到直接發送。大多數子 Agent 系統都跳過了這部分。

它們將完成視為一個回傳值。但在 Swarm 管理器中，完成是一個路由問題。

## 佇列比 Prompt 更重要

一旦 Agent 可以生成 Agent，執行環境就必須以非常實際的方式關注併發性。

你需要會話內的嚴格順序。兩條訊息不應該在同一個活躍的 Agent 迴圈中發生衝突。你還需要跨會話的並行性，否則艦隊就會變成單行道。

這就是為什麼 Swarm 管理看起來越來越不像 Agent 框架，而更像是執行環境基礎設施。

主 Agent 工作是一條通道，子 Agent 工作是另一條，Cron 或背景工作可能是另一條。每條通道都可以有自己的併發限制，同時每個會話仍然序列化其自身的活躍運行。

當 Agent 忙碌時，使用者發送了後續指令；當父 Agent 還在運行時，子 Agent 完成了任務；子 Agent 還有自己的子 Agent；Cron 工作完成並需要通知會話。當模型正在串流傳輸時，一條引導訊息到達了。

如果所有這些都只是訊息，系統很快就會變得混亂。

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

有些訊息應該引導活躍的運行，有些應該作為後續指令排入佇列，有些應該中斷當前工作，有些則應該在積壓過多時被總結或丟棄。答案存在於佇列策略中，而不是更好的 Prompt。

## 取消功能太過薄弱

最簡單的系統可以取消一個 future，這只是基本門檻。

一個真正的 Swarm 管理器需要能夠引導、中斷、終止和級聯（cascade）。其中「引導」是最有趣的。

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

當子 Agent 執行錯誤時，你不一定想殺掉它並丟失會話，你可能想重新導向它。

在 OpenClaw 中，引導一個受控的子 Agent 是一種控制平面（control-plane）操作。它會標記當前運行以進行「引導-重啟」（steer-restart），抑制過時的完成宣告，中止正在進行的運行，清除佇列，等待中止穩定，發送新的 Agent 訊息，並將註冊表從舊運行重新映射到新運行。系統正在告訴子 Agent 停止當前工作並進行轉向。

「終止」（Kill）則不同。終止應該結束運行、標記會話狀態、抑制不適當的完成宣告，並選擇性地級聯到後代。

級聯之所以重要，是因為 Swarm 是一棵樹。殺掉一個編排者（orchestrator）卻讓它的工作者活著通常是錯誤的，但有時這正是你想要的。執行環境需要足夠了解圖結構，才能做出這種區分。

這就是僅靠 Prompt 進行協調會失敗的地方。

你無法要求模型記住每一個活躍的子 Agent 並手動清理樹狀結構。執行環境必須擁有這張圖。

## 角色是一種安全機制

扁平化的 Swarm 無法擴展。如果每個子 Agent 都可以無限地生成其他子 Agent，系統最終會變得毫無用處甚至危險。

簡單的劃分是「編排者」和「葉子」。編排者負責協調，它們可以生成工作者、檢查狀態並綜合結果。葉子負責執行工作，它們不能進一步協調。

這應該在工具層面強制執行，而不僅僅是在 Prompt 中建議。

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

OpenClaw 會追蹤生成深度，並根據該深度解析子 Agent 的能力。它將 `spawnDepth`、`subagentRole` 和 `subagentControlScope` 儲存在子會話中。葉子會失去管理工具，而編排者則在配置的深度和子 Agent 限制內保留這些工具。

Hermes 在 `delegate_task` 中也有類似的想法：`role="leaf"` 與 `role="orchestrator"`、可配置的 `delegation.max_spawn_depth`，以及針對編排者行為的終止開關。這是正確的直覺。

但在 Swarm 管理器中，邊界屬於控制平面。模型可以請求生成，但執行環境決定這是否合法。

執行環境應該知道子 Agent 的深度、父 Agent 已經擁有了多少子 Agent、哪些工具被該角色拒絕，以及子 Agent 是否可以創建更多子 Agent。

不需要標籤，也不需要手把手教導。系統會強制執行 Swarm 的形狀。

## 恢復機制是執行環境保持所有權的方式

Swarm 管理器不能「發射後不管」（fire-and-forget）。

如果系統擁有子 Agent，它就需要知道它們何時卡住、遺失、成為孤兒、完成，或者已經完成但未送達。

OpenClaw 的子 Agent 註冊表會監聽生命週期事件。它使用 `agent.wait`，追蹤活躍的運行上下文，將註冊表持久化到磁碟，並在啟動時恢復運行。它有針對宣告送達的重試計時器，以及針對暫時性生命週期錯誤的寬限期。

它還運行一個清理器（sweeper）。

這個清理器並不華麗，但它正是讓系統變得真實的關鍵。

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

它會檢查沒有活躍運行上下文的運行狀態，將其與會話狀態進行對帳。它會在清理後過期舊的會話模式記錄，移除或重試卡住的待處理生命週期狀態，並將交付失敗標記出來，而不是讓清理工作永遠處於半完成狀態。

這是作業系統級別的工作。

這個類比並不完美，但很有用：Swarm 管理器需要類似於「行程表」（process table）的東西，因為管理問題的本質是相似的。

什麼在運行？誰擁有它？當它退出時會發生什麼？哪些子 Agent 應該隨父 Agent 一起死亡？哪些會話應該在重啟後存活？哪些輸出尚未送達？

沒有這些，系統大多只是在啟動工作並祈禱成功。

## 狀態比運行更長久

每個 Swarm 管理器最終都會變成一個清理系統。

子 Agent 會產生狀態：文字記錄、運行記錄、瀏覽器會話、綁定的 MCP 執行環境、附件目錄、workspace 文件、交付狀態、生命週期鉤子和成本元資料。

當模型停止思考這些內容後，必須有人擁有這些狀態。

OpenClaw 允許子 Agent 被保留或刪除。這個選擇很重要。一次性運行可以清理文字記錄和執行環境狀態；而持久的子會話應該保持可定址；附件可以被保留或移除；瀏覽器和 MCP 執行環境需要退役；上下文引擎需要知道子 Agent 是結束了還是被刪除了。

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

這是委派與 Swarm 管理分歧的另一個地方。

在有界委派中，清理可以是本地的。子物件關閉，執行緒退出，父 Agent 獲得 JSON。

在 Swarm 管理中，清理是分散式的。子 Agent 可能是一個會話；運行可能已完成但交付尚未完成；會話可能被保留但附件被移除；父 Agent 可能需要在後代穩定後再被喚醒一次。

清理是一個狀態機。

這聽起來很沉重，因為它確實如此。

但長期運行的多 Agent 系統會累積狀態。假裝沒有這些狀態只會將複雜性轉化為 Bug。

## Harness 之上的層級

OpenClaw 之所以有趣，是因為它在程式碼中暴露了 Swarm 管理器層。

沒有什麼神奇的 `SwarmManager` 物件能讓一切變得優雅。Swarm 是從普通的執行環境機制中湧現出來的：

- 會話金鑰
- 通道（lanes）
- 運行 ID
- 註冊表記錄
- 生命週期事件
- 內部完成事件
- 佇列策略
- 交付路由
- 清理決策
- 恢復掃描

這可能就是真實 Swarm 管理的樣子：一套枯燥的控制平面原語，讓眾多 Agent 能夠存活並協作。

Hermes 展示了良好的委派是什麼樣子：生成工作者、串流傳輸進度、回傳摘要、綜合結果。

OpenClaw 則展示了當委派變成會話基礎設施時會發生什麼。

下一代 Agent 系統將不會只問 Agent 是否能呼叫工具，那是 harness 的問題。

下一個問題是 Agent 住在哪裡、誰擁有它們、它們如何回報、它們如何被停止，以及重啟後什麼會留下來。

這就是將「單一 Agent harness」轉變為一支能夠處理廣泛任務、協調良好的「Agent 艦隊」的層級。

## 標籤

Agent, 產業趨勢, Arize, Cognition, Anthropic, Cursor