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

基本原则

只有当专门处理通道减少了对 实际瓶颈的争用时,才能提高吞吐量:
  • 会话锁:同一时间应只有一个运行能够修改给定会话。
  • 全局模型容量:所有用户可见的聊天运行仍共享提供商限制。
  • 工具容量:Shell、浏览器、网络和仓库操作可能比 模型轮次本身更慢。
  • 上下文预算:冗长的对话记录会让之后的每个轮次更慢且更不 聚焦。
  • 所有权不明确:重复执行相同工作的智能体会浪费容量。
OpenClaw 已按会话串行执行运行,并通过 命令队列限制全局并行度。专门处理通道在此基础上添加策略: 哪个智能体负责哪些工作、哪些工作留在聊天中,以及哪些工作转为 后台任务。

推荐实施步骤

阶段 1:通道契约 + 后台繁重工作

在每个通道的工作区和系统提示词中为其提供书面契约:
  • 用途:此通道负责的工作。
  • 非目标:此通道应移交而非尝试处理的工作。
  • 聊天预算:快速回答留在聊天中;对于耗时任务,先简短确认, 然后在后台子智能体或任务中运行。
  • 移交规则:当工作由另一个通道负责时,说明应移交到哪里, 并提供简洁的移交摘要。
  • 工具风险规则:优先使用能够完成工作的最小工具集。
这是成本最低的阶段,并能解决大多数拥堵问题:一项编码工作不再 让研究通道变得极其迟缓,而且每个聊天都能保持自身上下文 整洁。

阶段 2:优先级和并发控制

根据每个通道的业务价值调整队列和模型容量:
将直接聊天、个人聊天和生产运维智能体用于高优先级工作。当系统 繁忙时,让研究、起草和批量编码转为后台任务。

阶段 3:协调器/流量控制器

在多个通道启用后,添加一个轻量级协调器模式:
  • 跟踪活跃的通道任务及其负责人。
  • 检测不同群组中的重复请求。
  • 在通道之间路由移交摘要。
  • 仅呈现阻塞项、已完成结果以及必须由人工做出的决策。
不要从这里开始。没有通道契约的协调器只会协调混乱。

最小通道契约模板

相关内容