平行專家工作軌道

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

​

基本原則

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

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

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

​

建議的導入方式

​

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

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

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

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

​

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

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

{
  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 或
網路。

​

相關內容

• 多代理路由
• 命令佇列
• 子代理