bindings 的优先级怎么影响 agent 选择

中文用户在排“为什么进了这个 agent”时，经常会直觉地去猜：

• 模型是不是自己选错了

但官方最近的 Channel Routing 文档其实已经把这件事说得很明确：

• reply routing 是 deterministic 的
• agent 选择来自 host configuration

也就是说，这本质上是：

• binding 命中问题

不是模型自由发挥。

先记住最关键的一句

如果要压成一句最有用的话，就是：

• routing 决定 agent
• session key 决定上下文桶

很多看起来像“上下文怪怪的”的问题，第一层其实是 agent 已经先被路由错了。

官方当前给出的 binding 优先级

根据最近官方文档，优先级大致是：

1. 精确 peer match
2. parent peer / thread inheritance
3. guild + roles
4. guild
5. team
6. account
7. channel
8. default agent

这条顺序非常值，因为它说明：

• 不是“谁写在前面谁赢”
• 而是路由器有固定命中层级

精确 peer match 为什么最强

这是最细粒度的绑定：

• 针对某个具体 peer / sender / DM 对象

它最适合：

• 明确指定某个联系人或明确私聊对象应该去哪个 agent

也因此优先级最高。

thread inheritance 为什么容易被忽略

官方现在把：

• parent peer / thread inheritance

单独放进优先级里，很值。

这意味着在线程化渠道里，很多路由不是重新从零决定，而会继承：

• 上层频道 / 对话对象

如果你不记住这点，就会很容易误判：

• “明明我只配了频道，为什么线程里也进了这个 agent”

guild / team / account / channel 这些层有什么差别

更适合这样记：

guild / team

更偏组织或工作区级范围。

account

更偏某个渠道账号实例本身。

channel

更偏具体房间 / 频道 / 对话位点。

它们不是同一层粒度，所以命中顺序当然不能混着看。

default agent 为什么不该被当成第一排查对象

很多人一看到“消息进了这个 agent”，就先去看 default agent。

但如果按官方当前优先级，只有前面那些更具体的 binding 都没命中时，default agent 才会接手。

所以更稳的排查顺序通常是：

1. 先看是否有更精细的 peer / thread / guild 命中
2. 再看 account / channel
3. 最后才看 default

为什么 binding 问题经常看起来像“行为问题”

因为一旦 agent 先选错，后面你看到的一切都会一起偏掉：

• 看到的会话历史不对
• 用到的 skills / tools 不同
• 回复风格和 persona 不同

于是很容易让人误以为：

• 模型抽风了
• memory 错了
• session 混了

实际第一步可能只是：

• binding 命中了另一个 agent

哪些场景最容易踩这个坑

团队频道 + 线程

线程继承和频道 binding 叠在一起时，最容易误判。

多账号环境

同一渠道有多个 bot/account 时，account 级 binding 特别重要。

WebChat + 外部渠道并用

WebChat 默认挂到 agent 主会话，但外部渠道是否进同一个 agent 还是要看 binding。

中文用户最容易踩的坑

1. 以为 bindings 是“顺序匹配”

官方更像固定层级匹配。

2. 只配 channel，不考虑 thread / peer 继承

这在 Discord / Slack 场景里很常见。

3. 遇到路由异常就先查 memory

很多时候 agent 入口先错了，memory 只是后续表现。

一条更稳的排查顺序

建议按这个顺序看：

1. 当前消息对象是 peer、thread、channel 还是 guild 级
2. 按官方优先级逐层排 binding 命中
3. 确认最后选中的 agent
4. 再去看 session key 和上下文桶

下一步推荐

• 频道与 Session 路由怎么决定上下文边界
• 用 message CLI 和命令入口时，怎么避免发到错误会话
• 团队频道里的 Session 隔离策略