企业微信系统集成的四种形态

分界线是两个问题

分类不是为了好看，是为了在需求评审会上十分钟内定下工程量。两个问题就够：数据往哪个方向流，状态由谁持有。

• 通知型：数据单向流出，业务系统推向企业微信，企业微信侧不持有任何状态。
• 双向型：出去一条、回来一条，状态是短期的会话上下文，由你的系统持有。
• 数据同步型：两侧各持有同一份数据的副本，必须先定义谁是权威源。
• 编排型：一个流程跨三个以上系统，长期状态和流转规则都在你这一侧。

四种形态的工程量大致是 1、3、5、10 的量级关系。真正的浪费不是做错形态，是明明只需要第一种，却按第四种的架构起了个头 —— 三个月后那套状态机里跑的还是一条告警通知。

通知型：难点不在发出去，在收件人和降噪

监控告警、审批提醒、订单变更推到群或个人，这是最常见也最容易被低估的一种。发送本身是一次调用的事，真正吃时间的是另外两件。

第一件是收件人映射。你的系统里存的是工号或邮箱，发送需要的是企业微信侧的标识，中间必须有一张映射表，还要处理入职、离职、转岗带来的漂移。用 wecomapi 的事件回调订阅成员变更，把这张表做成事件驱动更新，比每天跑一次全量同步准得多 —— 但全量对账只能降频，不能取消，理由在第四节。

第二件是降噪。通知型系统上线两周后最常见的反馈不是「没收到」，是「太吵，已屏蔽」。降噪的标准可以定得很具体：同一事件源在一个时间窗内的第二条起就合并成摘要，而不是逐条发。这个规则要做在发送前的聚合层，指望业务方自己少发是不现实的。

双向型：难点是把回复关联回原来那件事

发一条审批提醒出去，用户回一句「同意」，你要知道这句「同意」对应哪一张单子。这就是双向型的全部难度，其余部分和通知型没有区别。

错误做法有两种：解析文本猜意图，或者要求用户回复时带上单号。正确做法是在发送的那一刻就把关联关系落库 —— 这条消息发给了谁、属于哪个业务对象、多久失效。回调进来时按「会话 + 时间窗 + 未关闭」反查，命中唯一一条就是它。

// 示意逻辑：端点与事件字段以 wecomapi 文档为准，evt 是归一化后的自有结构
async function ask(ticket, toId) {
  await http.post("https://manager.wecomapi.com/message/sendText", {
    guid:    ACCOUNT,
    toId:    toId,
    content: `工单 ${ticket.no} 待确认，回复「同意」或「驳回」`,
  });
  await pending.put({ toId, ticketId: ticket.id, expireAt: after(30) });
}

onEvent(async (raw) => {
  await ack();                                 // 先快速 ACK，重活异步做
  const evt = normalize(raw);
  const hit = await pending.findOpen(evt.from); // 按会话反查，不解析文本猜
  if (!hit) return asPlainMessage(evt);         // 没命中就当普通消息
  await advance(hit.ticketId, parseIntent(evt.text));
});

双向型必须定义「这个交互多久算结束」。没有过期机制的关联表会一直涨，更糟的是三天后用户补一句「同意」，会把一张早已关闭的单子重新推进 —— 这种缺陷在测试环境永远复现不出来，只会在真实用户手上出现。

数据同步型：先回答删除怎么办

组织架构、客户档案、群成员这类需要两侧保持一致的数据属于第三种形态。工程量比前两种高一档，因为要同时处理增量、乱序和删除三件事，而它们的失效方式互不相同。

取数分工固定是三件套：事件增量做时效、定时对账做正确性、按需回源补单点差异。三者的具体写法 —— 水位线怎么取、对账分几级、补偿怎么分类 —— 在「企业微信数据同步怎么做增量」里已经拆开讲过，这里只留一条影响形态判断的结论：删除是唯一没有后续事件替你纠正的变更，所以选了这种形态，对账预算必须跟着一起排，不能等幽灵数据出现了再补。

另一条纪律：一个字段只能有一个写入方。两侧都能改同一个字段，就一定会出现冲突，然后你要写一套冲突解决规则，而那套规则的复杂度会超过同步本身。在设计阶段把每个字段的权威源钉死，比事后做双向合并便宜一个数量级。

编排型：状态必须放在你自己这边

跨三个以上系统的流程 —— 客户在群里提需求、生成工单、走审批、回写 CRM、结果再播报回群 —— 属于第四种。它和前三种不是难度差别，是种类差别：前三种是接口调用，它是分布式事务。

• 流程状态存在你自己的库里，用状态机描述。不要把状态藏在消息文本、群公告或某个下游系统的字段里 —— 那些地方没有事务，也没法查询。
• 每一步都要能重入。重复投递、超时重试、人工重放都会让同一步执行两次，副作用必须幂等。
• 每一步都要有超时和补偿动作。没有补偿的编排卡住之后，只能人工查库改数据，而人工改数据本身又是新的故障源。

判断标准可以定得很硬：流程只跨两个系统，用双向型加几个状态字段就够；跨三个以上，或者存在需要回滚的动作，才值得上编排。编排型的成本是前三种加起来的量级，做早了是纯浪费，而且浪费的不只是工期，还有后面每个人的理解成本。

对照表与升级路径

形态        数据流向      状态归属        典型工期  最容易踩的坑
----------  ------------  --------------  --------  --------------------
通知型      单向流出      无状态          天        收件人映射漂移、通知过载
双向型      一出一回      短期会话上下文  周        关联不上、关联不过期
数据同步型  两侧各持副本  需指定权威源    数周      删除丢失、双写冲突
编排型      跨系统流转    长期流程状态    月        状态外置、步骤不可重入

升级路径按这个顺序走：通知型 → 双向型 →（需要时）数据同步型 → 编排型。跳级的代价很具体：直接从零做编排型的团队，通常会卡在收件人映射和事件幂等这两件小事上，而它们本该在第一、第二阶段就解决掉。

一个务实的做法是让四种形态共用同一套接入层。wecomapi 的消息、客户、群与事件回调走的是同一套请求结构与错误模型，所以往上升级时换掉的是编排逻辑，不是接入代码 —— 这能省掉每升一级重接一次的返工，也是「先做通知型」这条建议成立的前提。