> ## Documentation Index
> Fetch the complete documentation index at: https://docs2.openclaw.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# 平行專家工作軌道

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

## 基本原則

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

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

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

## 建議的導入方式

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

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

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

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

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

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

```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}}
{
  agents: {
    defaults: {
      maxConcurrent: 4,
      subagents: { maxConcurrent: 8, delegationMode: "prefer" },
    },
  },
  messages: {
    queue: {
      mode: "collect",
      debounceMs: 1000,
      cap: 20,
      drop: "summarize",
    },
  },
}
```

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

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

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

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

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

## 最小分流契約範本

```md theme={"theme":{"light":"min-light","dark":"min-dark"}}
# 分流契約

## 負責範圍

- <job this lane is responsible for>

## 不負責範圍

- <work to hand off>

## 聊天預算

- 直接回答快速問題。
- 對於多步驟、耗時或大量使用工具的工作：先簡短確認，產生子代理／在背景執行
  工作，然後在完成時傳回結果。

## 交接

如果請求屬於另一個分流，請回覆：

- 目標分流
- 目標
- 相關脈絡
- 確切的下一步行動

## 工具使用方針

使用能完成任務的最小工具介面。除非此分流明確負責，否則請避免廣泛使用 Shell 或
網路。
```

## 相關內容

* [多代理路由](/zh-TW/concepts/multi-agent)
* [命令佇列](/zh-TW/concepts/queue)
* [子代理](/zh-TW/tools/subagents)