专家通道

并行专家通道允许一个 Gateway 将不同的聊天或房间路由到不同的智能体，同时保持用户体验快速。将并行性视为稀缺资源设计问题，而不仅仅是“更多智能体”。

第一性原理¶

只有当专家通道减少了对真正瓶颈的争用时，它才能提高吞吐量：

• 会话锁：同一时间只应有一个运行实例修改给定会话。
• 全局模型容量：所有可见的聊天运行仍共享提供商限制。
• 工具容量：shell、浏览器、网络和仓库操作可能比模型回合本身更慢。
• 上下文预算：长转录会使每个后续回合更慢且更不聚焦。
• 所有权模糊：重复的智能体执行相同工作会浪费容量。

OpenClaw 已经按会话串行化运行，并通过 命令队列 限制全局并行度。专家通道在其上添加策略：哪个智能体拥有哪项工作、什么保留在聊天中，以及什么成为后台工作。

推荐推广¶

作为一个现成的起点，openclaw agents team create 将这些通道契约作为协调者、研究员、写作者和审阅者角色提供。每个角色将其范围、工件交接、审批门和升级规则写入 AGENTS.md。该预设将协调者连接到专家，并指示专家返回结果而不再进一步委派。参见 团队预设。

阶段 1：通道契约 + 后台重负载工作¶

为每个通道在其 智能体工作区 的 AGENTS.md 中提供一份书面契约，该文件会在每个会话开始时加载到系统提示中：

• 目的：该通道拥有的工作。
• 非目标：应交接出去而不是尝试完成的工作。
• 聊天预算：快速回答保留在聊天中；长任务先简短确认，然后在后台子智能体或任务中运行。
• 交接规则：当另一个通道拥有该工作时，说明它应去哪里，并提供紧凑的交接摘要。
• 工具风险规则：优先选择能够完成任务的最小工具面。

这是成本最低的阶段，并修复大多数堵塞：一个编码任务不再让研究通道变得像糖浆一样慢，每个聊天都保持自己的上下文干净。

阶段 2：优先级和并发控制¶

围绕每个通道的业务价值调整队列和模型容量：

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

maxConcurrent 限制共享主通道；subagents.maxConcurrent 为每个派生会话提供自己的子执行预算。

将直接/个人聊天和生产运维智能体用于高优先级工作。当系统繁忙时，让研究、起草和批量编码转移到后台任务。subagents.delegationMode 仅是提示指导；有关每个值的作用，参见 子智能体委派，有关 mode、cap 和 drop，参见 命令队列。

阶段 3：协调者 / 流量控制器¶

一旦多个通道处于活动状态，添加一个小型协调者模式：

• 跟踪活动通道任务和所有者。
• 检测跨组的重复请求。
• 在通道之间路由交接摘要。
• 仅呈现阻塞项、已完成结果以及人类必须做出的决策。

不要从这里开始。没有通道契约的协调者只是在协调混乱。

最小通道契约模板¶

将此保存在通道智能体工作区的 AGENTS.md 中：

# Lane contract

## Owns

- <job this lane is responsible for>

## Does not own

- <work to hand off>

## Chat budget

- Answer quick questions directly.
- For multi-step, slow, or tool-heavy work: acknowledge briefly, spawn/background
  the work, then return the result when complete.

## Handoff

If another lane owns the request, reply with:

- target lane
- objective
- relevant context
- exact next action

## Tool posture

Use the smallest tool surface that can complete the task. Avoid broad shell or
network work unless this lane explicitly owns it.

相关¶

• 多智能体路由
• 命令队列
• 子智能体