1. 微信/钉钉场景下，多 Agent 绑定不是“加几个 worker”那么简单OpenClaw 接入微信和钉钉时，我见过太多团队把「多 Agent 绑定」理解成“在 config.yaml 里多写几行 agent.name”，然后上线就崩。上周一个金融客户反馈：同一用户发来「查余额」和「转 5000 块给张三」两条消息，系统居然用同一个 Agent 处理了转账请求——而这个 Agent 根本没被授权调用支付接口。日志里只有一行agent routing fallback to default，没人知道它为什么 fallback，更没人知道 fallback 到底 fallback 到了谁。问题不在 OpenClaw 本身。它默认的round-robin路由策略，在 Telegram 这类单向广播型平台能跑通，但在微信/钉钉这种强会话上下文、高并发短连接、且存在「用户-会话-业务意图」三层耦合的国内平台，直接照搬就是灾难。真正卡住落地效果的，是消息路由策略与平台通信模型的错配。微信服务号每条消息带MsgId + FromUserName + ToUserName + CreateTime四元组，钉钉机器人回调则带tenant_key + conversation_id + msg_id；而 OpenClaw 的AgentRouter默认只认user_id字段。你没做字段映射，它就永远拿不到真实会话粒度——结果就是：用户刚问完贷款利率，下一秒发「我要提前还款」，系统却把它扔给了负责营销活动的 Agent。这不是配置疏漏，是