7.4 路由基础：从单智能体到多智能体
路由解决的不是“模型能不能做”，而是“这条消息应该交给哪个智能体接管，以及它被允许做什么”。本节以 openclaw 的多智能体路由为主线，说明路由决策链、绑定规则的优先级、以及如何用可观测手段把路由做成可回放、可审计、可排障的工程能力。
7.4.1 路由要解决的核心问题：所有权、权限与状态隔离
在多智能体系统里，一条消息进入后必须尽快确定三件事：由谁处理（所有权）、能做什么（工具与权限）、状态写到哪里（会话与记忆）。如果不把这三件事拆清楚，就会出现两类常见故障：
责任不清：多个智能体同时响应或互相覆盖状态，导致输出不一致。
越权执行：低可信入口触发高风险工具，故障从“答错一句话”升级为“写错一条数据”。
openclaw 将“由谁接管”下沉为多智能体路由与绑定机制，并把“能做什么”交给工具策略与沙箱工具约束去兜底。路由层最重要的目标是把消息的处理权稳定地收敛到一个确定的智能体上，然后让后续执行在可控边界内进行。相关概念与配置细节见官方文档的多智能体路由与绑定说明：https://docs.openclaw.ai/concepts/multi-agent，https://docs.openclaw.ai/concepts/multi-agent#routing-rules-how-messages-pick-an-agent。
7.4.2 决策链：先绑定后路由，绑定命中时直接接管
openclaw 的典型决策链可以概括为“先匹配绑定，再进入路由器”。绑定用于把某些来源的消息稳定地交给指定智能体处理，从而减少模型分类的不确定性。官方文档明确了绑定的优先级与用途，并给出了基于 channelId、peerId、groupId 等字段的匹配方式。绑定命中时，系统会直接将消息交给绑定的智能体处理。https://docs.openclaw.ai/concepts/multi-agent
为了把这条链路讲清楚，下面用一个简化流程图刻画路由的关键分叉点。
图 7-2：多智能体路由中“绑定优先”的关键分叉
工程上建议把高风险或高确定性的入口优先落到绑定里，把需要意图理解的入口交给路由器。
7.4.3 绑定落地：用最小规则把高风险入口固定到受控智能体
绑定的好处是把“路由正确性”从概率问题变成规则问题。官方文档给出了一种常见写法：为某个智能体配置 bindings，按 channelId 与 peerId 等条件匹配消息来源。下面的示例展示了“渠道与对端绑定到特定智能体”的配置形态（字段名以本书示例与 status --deep/结构化日志的实际输出为准）。在实际工程中，建议把涉及写入或外部副作用的能力都集中在少量受控智能体内，然后只给这些智能体配置严格的工具允许列表，工具策略的写法详见 5.2 工具策略：允许、拒绝与分层策略。
当系统规模增长到“多账号、多群、多入口”时，建议把绑定策略拆成两层：
入口层绑定：按
channelId、peerId、groupId绑定到入口智能体，负责治理触发规则与上下文预处理。任务层路由：入口智能体再将任务分发给领域智能体，或使用子智能体并行处理。子智能体机制见 https://docs.openclaw.ai/tools/subagents。
验证绑定是否生效时，不建议靠“发消息看看”。更可靠的做法是先用命令查看绑定清单，再用探测命令确认渠道状态：
7.4.4 可观测与防失控：把路由原因写进日志
多智能体系统的排障难点在于“看起来像模型问题，实际上是路由与策略问题”。建议从一开始就把两类信息写进可检索日志：
路由原因：命中哪个绑定或路由器为什么选择该智能体。
执行边界：该智能体当次请求使用了哪些工具策略与沙箱约束。
openclaw 提供了结构化日志与诊断能力，便于在控制台或日志流中回放链路。排障时可先用 status 与 logs 定位是否为配置、配对或渠道状态问题，再回到路由策略本身做收敛：
工程层面还需要显式防止路由环路。如果允许智能体之间互相转交任务，建议实现跳数限制或链路去重，并在日志里记录链路标识；当同一条链路反复在智能体间往返时，直接中止并返回可操作的错误提示。
最后更新于