OpenClaw 的 routing precedence 正在成为更明确的排障坐标系

OpenClaw 最近这轮 Channel Routing 文档，一个很值得中文用户注意的变化是：routing precedence 已经越来越像一套固定坐标系，而不是“消息为什么进了这个 agent”的经验判断。

官方当前写得很明确：

1. exact peer
2. parent peer
3. guild + roles
4. guild
5. team
6. account
7. channel
8. default agent

这条顺序看起来像文档细节，但实际会直接改变排障方式。

1. thread inheritance 被正式摆到了高优先级

这轮文档里很值的一点，是把：

• parent peer match

也就是线程继承，明确放到了第二层。

这意味着在线程化渠道里，很多看起来像“频道里重新选 agent”的情况，实际可能是：

• 线程先继承了上层 peer 路由

2. routing 问题越来越不该再先怪模型

官方也一直在强调：

• routing 是 deterministic 的
• 渠道不是模型自己选的

这会把很多中文社区里常见的“模型选错了 agent”叙事，重新拉回到：

• binding 命中了哪一层

3. 排障开始更像查层级，而不是猜默认值

以前很多人看到 agent 进错了，会先去看：

• default agent

但当前优先级写法更清楚以后，更稳的排法其实是：

• 先看 peer 和 thread
• 再看组织、账号和渠道
• 最后才回到 default

这会明显提高团队频道、Discord、Slack 这类入口的排障效率。

4. Broadcast Groups 也让 routing 概念更清楚了

随着 Broadcast Groups 被单独拆出来，普通 routing 的职责反而变得更纯粹：

• 它负责单 agent 选择

而多 agent 协作交给另一套能力处理。
这也让“为什么这条消息只进了一个 agent”与“为什么这个 peer 会触发多个 agent”第一次有了更稳定的解释边界。

对中文用户最有价值的提醒

如果你现在正在排：

• 线程为什么继承了上层 agent
• 同一群里为什么不是默认 agent 接手
• 多账号 / 多渠道下为什么消息进了别的 workspace

那最值得优先补的已经不是更多模型知识，而是：

• 先按 routing precedence 一层一层查命中

推荐延伸阅读

• bindings 的优先级怎么影响 agent 选择
• 频道与 Session 路由怎么决定上下文边界
• 用 message CLI 和命令入口时，怎么避免发到错误会话