为什么现在要做这件事
渠道生态在变化，部分渠道已经更适合 plugin-only 模式。
如果你继续把所有渠道硬耦合在主流程里，后续维护和升级会越来越慢。
参考：
什么时候应该插件化
满足任意两条，就建议进入插件化：
- 渠道协议更新频繁
- 不同渠道需要不同鉴权方式
- 同一业务要接多个渠道
- 你希望独立发布某个渠道能力
迁移策略（分 3 阶段）
阶段 1：抽边界
- 把“渠道收发”“鉴权”“重试”从主流程拆出去
- 为插件定义统一输入输出契约
- 保留主流程只做编排，不做渠道细节
阶段 2：双轨运行
- 新渠道走插件链路
- 旧渠道先保持原链路
- 对同一任务跑 A/B 回归，验证结果一致性
阶段 3：逐步切换
- 先迁移低风险渠道
- 再迁移高流量渠道
- 每迁移一条都回放历史故障场景
你需要的最小治理规则
- 每个插件必须有版本号和变更记录
- 每个插件必须声明权限与外部依赖
- 每个插件必须有熔断和降级行为
- 每个插件发布前必须过回归清单
扩展生态怎么处理
针对 Matrix、Nostr、Zalo 等扩展渠道，建议先做“实验插件”，不要直接进主干。
实验阶段关注三件事：
- 鉴权稳定性
- 消息顺序一致性
- 异常重试是否可控
验收标准
- 主流程不再依赖渠道私有细节
- 渠道故障不会拖垮全局调用
- 新增渠道只改插件层，不动核心编排层
下一步
先看：