Appearance
在 OpenClaw 中配置并行专家通道（specialist lanes）可让不同聊天室或群聊的请求路由到专属智能体，避免一个长任务阻塞其他对话。核心方法是把并行当作稀缺资源设计问题：先为每个通道编写 lane contract（定义职责、非目标、聊天预算和交接规则），再通过队列模式（collect + debounceMs）和 maxConcurrent 限制全局并发。不要直接用 coordinator，否则只会协调混乱。关键命令：创建 workspace 时写入 system prompt 作为 lane contract，或在已有 workspace 的 system prompt 字段追加。
OpenClaw 并行通道配置：如何分流专家智能体避免阻塞
Parallel specialist lanes 让一个 Gateway 能把不同聊天或房间路由到不同智能体，同时保持用户体验流畅。关键在于把并行视为稀缺资源设计问题，而不是简单加更多智能体。
核心原理：哪些资源会变成瓶颈
一个 specialist lane 只有在减少真实瓶颈的争用时才提升吞吐量：
- Session locks：同一时间只能有一个 run 修改给定 session。
- Global model capacity：所有可见的 chat run 仍然共享 provider 限制。
- Tool capacity：shell、browser、network 和 repository 工作可能比模型轮次本身慢。
- Context budget：长对话记录让每次后续轮次变慢且注意力分散。
- Ownership ambiguity：重复的智能体做相同工作浪费容量。
OpenClaw 已经通过 command queue 对每个 session 串行化 run 并限制全局并行。Specialist lanes 在此基础上增加策略：哪个智能体拥有哪个工作、什么留在聊天内、什么变成后台工作。
推荐部署路线
阶段 1：Lane contracts + 后台重型工作
为每个 lane 在 workflow 和 system prompt 中编写书面 contract：
- Purpose：该 lane 拥有的工作。
- Non-goals：它应该交接而不是尝试去做的工作。
- Chat budget：快速回答留在聊天内；长任务应简短确认，然后在后台 sub-agent 或 task 中运行。
- Handoff rule：当另一个 lane 拥有该工作时，说明应该去哪并提供简洁的交接摘要。
- Tool-risk rule：优先使用能完成工作的最小工具面。
这是最便宜的阶段，能解决大部分堵塞问题：一个编码工作不再让 research lane 变得像糖浆一样慢，每个 chat 也保持自己的上下文干净。
阶段 2：优先级和并发控制
围绕每个 lane 的业务价值调整队列和模型容量：
json5
{
agents: {
defaults: {
maxConcurrent: 4,
subagents: { maxConcurrent: 8, delegationMode: "prefer" },
},
},
messages: {
queue: {
mode: "collect",
debounceMs: 1000,
cap: 20,
drop: "summarize",
},
},
}对高优先级工作使用 direct/personal 聊天和 production-ops agents。让 research、drafting 和 batch coding 在系统繁忙时进入后台任务。
阶段 3：Coordinator / 流量控制器
当多个 lane 活跃时添加一个小型 coordinator 模式：
- 跟踪活跃的 lane 任务和所有者。
- 跨群组检测重复请求。
- 在 lane 之间路由交接摘要。
- 只呈现阻塞项、已完成结果和人类必须做的决策。
不要从这里开始。没有 lane contract 的 coordinator 只是协调混乱。
Lane contract 模板（最小版本）
md
# Lane contract
## Owns
- <该 lane 负责的工作>
## Does not own
- <要交接的工作>
## Chat budget
- 快速问题直接回答。
- 对于多步骤、慢速或工具密集型工作：简短确认，生成/后台任务，然后完成时返回结果。
## Handoff
如果另一个 lane 拥有请求，回复：
- 目标 lane
- 目标
- 相关上下文
- 确切下一动作
## Tool posture
使用能完成该任务的最小工具面。避免广泛的 shell 或网络工作，除非该 lane 明确拥有它。常见问题
配置了 specialist lanes 后为什么还是感觉卡顿？
检查是否所有 lane 共享同一个 provider 的 maxConcurrent 上限。确保在 agent 配置中显式设置 maxConcurrent 和子智能体并发限制，并确认队列模式是否正确（推荐 collect + debounceMs 组合）。
怎么知道 lane contract 写得够不够细？
测试两个场景：一个 lane 收到另一个 lane 所属的请求时，是否直接告知交接目标和上下文；一个长任务启动时，是否先返回一条“任务已后台处理”的消息而非卡住聊天入口。如果做不到，contract 不够细。
多个 lane 之间出现重复请求怎么办？
Phase 3 引入的 coordinator 能检测跨群组的重复请求。在此之前，可在 lane contract 中加入 dedupKey 字段，或在交接时会话中标识请求 ID 来手动去重。