Skip to main content

Documentation Index

Fetch the complete documentation index at: https://openclaw.zhcndoc.com/llms.txt

Use this file to discover all available pages before exploring further.

并行专长通道允许一个 Gateway 将不同的聊天或房间路由到不同的代理，同时保持用户体验流畅。关键在于把并行性视为一种稀缺资源设计问题，而不只是“更多代理”。

​
第一原则

只有当专长通道减少了真实瓶颈的争用时，它才会提升吞吐量：
  • 会话锁：同一时间只应有一个运行修改给定会话。
  • 全局模型容量：所有可见的聊天运行仍然共享提供方限制。
  • 工具容量：shell、浏览器、网络和仓库工作可能比模型轮次本身更慢。
  • 上下文预算：较长的对话记录会让未来每一轮更慢且更不聚焦。
  • 所有权歧义：多个代理重复做同一件事会浪费容量。
OpenClaw 已经通过 命令队列 按会话串行化运行，并限制全局并行度。专长通道则在此基础上增加策略： 哪个代理拥有哪项工作，什么留在聊天中，什么变成后台工作。

​
推荐推进方式

​
阶段 1：通道契约 + 后台重任务

在每个通道的工作区和系统提示中写明契约：
  • 目的：该通道负责的工作。
  • 非目标：应当交接而不是尝试处理的工作。
  • 聊天预算：简短回答留在聊天中；长任务应简短确认，然后在后台子代理或任务中运行。
  • 交接规则：当其他通道拥有该工作时，说明应去哪里，并提供简洁的交接摘要。
  • 工具风险规则：优先使用能够完成工作的最小工具面。
这是最便宜的阶段，也能解决大多数堵塞：一个编码任务不再把研究通道拖成浆糊，每个聊天也都能保持自己的上下文整洁。

​
阶段 2：优先级与并发控制

围绕每个通道的业务价值来调整队列和模型容量： 
{
  agents: {
    defaults: {
      maxConcurrent: 4,
      subagents: { maxConcurrent: 8 },
    },
  },
  messages: {
    queue: {
      mode: "collect",
      debounceMs: 1000,
      cap: 20,
      drop: "summarize",
    },
  },
}
将直接/个人聊天以及生产运维代理用于高优先级工作。在系统繁忙时，让研究、撰写和批量编码转入后台任务。

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

当多个通道开始活跃后，再添加一个小型协调器模式：
  • 跟踪活跃的通道任务和所有者。
  • 检测跨群组的重复请求。
  • 在通道之间路由交接摘要。
  • 只暴露阻塞项、完成结果，以及人类必须做出的决策。
不要从这里开始。没有通道契约的协调器，只是在协调混乱。

​
最小通道契约模板

# 通道契约

## 拥有

- <此通道负责的工作>

## 不拥有

- <需要交接的工作>

## 聊天预算

- 直接回答简短问题。
- 对于多步骤、缓慢或工具密集型工作：简短确认，启动/转入后台
  执行，然后在完成后返回结果。

## 交接

如果其他通道拥有该请求，回复：

- 目标通道
- 目标
- 相关上下文
- 精确的下一步操作

## 工具姿态

使用能够完成任务的最小工具面。除非此通道明确拥有，否则避免广泛的 shell 或
网络工作。

​
相关内容