快速开始

并行专家工作流

Status: active

并行专业通道让一个 Gateway 网关可以将不同聊天或房间路由到不同的智能体，同时保持快速的用户体验。应将并行处理视为稀缺资源的设计问题，而不只是“更多智能体”。

基本原则

只有在专业通道能够减少对真正瓶颈的争用时，才能提高吞吐量：

会话锁：同一时间只能有一个运行修改给定会话。
全局模型容量：所有用户可见的聊天运行仍然共享提供商限额。
工具容量：shell、浏览器、网络和仓库操作可能比模型轮次本身更慢。
上下文预算：过长的对话记录会使之后的每个轮次更慢、更不聚焦。
归属不明确：多个智能体重复执行同一工作会浪费容量。

OpenClaw 已经按会话串行化运行，并通过命令队列限制全局并行度。专业通道在此基础上添加策略：哪个智能体负责哪项工作、哪些工作留在聊天中，以及哪些工作转为后台任务。

建议的上线步骤

第一阶段：通道约定 + 后台处理繁重工作

在每个通道的工作区和系统提示中为其提供书面约定：

用途：该通道负责的工作。
非目标：该通道应移交而不是尝试完成的工作。
聊天预算：快速回答留在聊天中；耗时较长的任务先简短确认，然后由后台子智能体或任务运行。
移交规则：当工作由另一个通道负责时，说明应将其移交到哪里，并提供简明的移交摘要。
工具风险规则：优先使用能够完成工作的最小工具范围。

这是成本最低的阶段，并能解决大多数堵塞问题：单个编码任务不再拖慢研究通道，每个聊天也能保持自身上下文整洁。

第二阶段：优先级和并发控制

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

json5

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

将直接聊天、私人聊天和生产运维智能体用于高优先级工作。当系统繁忙时，让研究、起草和批量编码转为后台任务。

第三阶段：协调器 / 流量控制器

在启用多个通道后，添加一个轻量的协调器模式：

跟踪活跃的通道任务及其负责人。
检测不同群组中的重复请求。
在通道之间路由移交摘要。
仅呈现阻塞问题、已完成结果和必须由用户作出的决定。

不要从这里开始。没有通道约定的协调器只会协调混乱。

最小通道约定模板

# 通道约定 ## 负责 - <该通道负责的工作> ## 不负责 - <需要移交的工作> ## 聊天预算 - 直接回答简单问题。- 对于多步骤、耗时或大量使用工具的工作：简短确认，将工作交由  子智能体处理或放到后台运行，然后在完成后返回结果。 ## 移交 如果请求由另一个通道负责，请回复以下内容： - 目标通道- 目标- 相关上下文- 确切的下一步操作 ## 工具使用原则 使用能够完成任务的最小工具范围。除非该通道明确负责，否则应避免大范围使用 shell 或网络。