Multi-agent

平行專家工作軌道

Status: active

專業分流可讓單一閘道將不同的聊天或聊天室路由至不同的代理，同時維持快速的使用者體驗。請將平行處理視為稀缺資源的設計問題，而不只是「更多代理」。

基本原則

只有在專業分流能降低實際瓶頸的資源爭用時，才能提升處理量：

工作階段鎖定：同一時間只能有一個執行作業變更指定的工作階段。
全域模型容量：所有可見的聊天執行作業仍共用供應商限制。
工具容量：Shell、瀏覽器、網路及儲存庫工作可能比模型回合本身更慢。
脈絡預算：過長的對話記錄會讓之後的每個回合更慢且更不聚焦。
歸屬不明確：多個代理重複執行相同工作會浪費容量。

OpenClaw 已透過命令佇列將每個工作階段的執行作業序列化，並限制全域平行處理量。專業分流則在此基礎上增添政策：哪個代理負責哪項工作、哪些工作留在聊天中，以及哪些工作轉為背景工作。

建議的導入方式

第 1 階段：分流契約與背景繁重工作

在每個分流的工作區與系統提示詞中提供書面契約：

用途：此分流負責的工作。
非目標：此分流應交接而非嘗試處理的工作。
聊天預算：快速回答留在聊天中；長時間任務則先簡短確認，再交由背景子代理或任務執行。
交接規則：當工作屬於另一個分流時，說明應交由何處處理，並提供精簡的交接摘要。
工具風險規則：優先使用能完成工作的最小工具介面。

這是成本最低的階段，也能解決大多數壅塞問題：單一程式設計工作不再拖慢研究分流，而每個聊天也能保持自身脈絡簡潔。

第 2 階段：優先順序與並行控制

根據每個分流的業務價值調整佇列與模型容量：

json5

{  agents: {    defaults: {      maxConcurrent: 4,      subagents: { maxConcurrent: 8, delegationMode: "prefer" },    },  },  messages: {    queue: {      mode: "collect",      debounceMs: 1000,      cap: 20,      drop: "summarize",    },  },}

將直接／個人聊天與正式環境維運代理用於高優先順序工作。當系統繁忙時，讓研究、草擬及批次程式設計轉至背景任務。

第 3 階段：協調器／流量控制器

當多個分流開始運作後，加入小型協調器模式：

追蹤進行中的分流任務及負責人。
偵測各群組間的重複請求。
在各分流間路由交接摘要。
只呈現阻礙、已完成的結果，以及必須由人員做出的決策。

不要從這裡開始。沒有分流契約的協調器只是在協調混亂。

最小分流契約範本

# 分流契約 ## 負責範圍 - <job this lane is responsible for> ## 不負責範圍 - <work to hand off> ## 聊天預算 - 直接回答快速問題。- 對於多步驟、耗時或大量使用工具的工作：先簡短確認，產生子代理／在背景執行  工作，然後在完成時傳回結果。 ## 交接 如果請求屬於另一個分流，請回覆： - 目標分流- 目標- 相關脈絡- 確切的下一步行動 ## 工具使用方針 使用能完成任務的最小工具介面。除非此分流明確負責，否則請避免廣泛使用 Shell 或網路。