企业微信入站渠道与扩展边界

入站渠道让外部消息平台成为任务入口：平台回调先通过渠道适配器验签和解密，再归一化发送者与消息、选择绑定路由、创建或延续会话，最后按平台规则回复。

当前公开实现

BailingHub Core v0.5.1 当前包含企业微信（WeCom）入站实现。飞书、钉钉可以沿用 kind + config + route_key 的适配机制扩展，但不是该固定版本已经内置并可直接选择的渠道。

不要把“架构可以扩展”写成“平台已经支持”。新增渠道仍需实现平台自己的 URL 验证、签名或加解密、消息归一化、回复窗口和异步发送逻辑。

企业微信链路

企业微信回调
  -> 校验平台签名并解密
  -> 提取成员 UserID 和消息
  -> 选择渠道绑定的 route_key
  -> 创建或延续 BailingHub 会话
  -> 窗口内被动回复，超时后按配置异步发送

渠道名称会进入回调 URL。企业微信后台保存地址时会先发送验证请求；公网可达性、Token 和 EncodingAESKey 任一不一致都会使握手失败。

身份如何进入业务系统

企业微信验签后的成员 UserID 可以形成平台命名空间内的可信主体，例如 wxuid:<userid>。wecom:* 用于会话键，不是业务工具收到的可信主体。wxuid:* 证明消息来自已验证的平台成员，但不自动等于商城、CRM 或 ERP 中的业务账号。

业务后端应把该主体映射到自己的用户和租户，再走原权限表与资源级校验。找不到映射时应拒绝，不能把平台成员默认升级为管理员。

上线前检查

渠道只绑定预期路由，相关接入方和预算边界正确；
重复平台消息不会创建重复业务后果；
短回复窗口之外使用异步送达，不让平台超时变成盲目重试；
业务工具收到主体后仍做最终授权；
Trace 能关联平台消息、路由、工具调用和最终送达。

固定版本参考