企业微信群机器人自动播报怎么搭

播报和对话机器人是两套东西

群里的机器人有两种形态，长得像但工程性质相反。一种是入站的：有人说话，它接住并回应，难点在理解和路由。另一种是出站的，也就是播报：外部系统产生了一个事件，它把事件送进正确的群，难点在筛选和投递。两者放进同一个服务没问题，但如果用同一套思路去设计，出站那半边一定先烂。

• 入站关心「这句话是什么意思」，出站关心「这条事件谁需要看见」。
• 入站由人触发，频率天然受人控制；出站由机器触发，频率不设防就会失控。
• 入站坏了，五分钟内有人在群里点名它；出站坏了，群里只是变安静，没人会来报。

这三条差异决定了播报系统的重心：绝大部分代码应该花在路由、抑制和对账上。真正调用发送接口的那一段，是整条链路里最短、也最不容易出错的一段。把工期按这个比例排，才不会做出一个「一小时搭完、三个月后没人看」的通道。

先选投递通道：一群一地址，还是统一接入

企业微信本身允许在群里添加一个机器人，拿到一个只对这个群生效的推送地址，业务系统往这个地址发请求就能把消息送进群。这条路上手最快，适用场景也很清楚：单个群或几个群、纯单向的企业微信群通知、不需要点名到人、不和入站消息共用逻辑。这种情况下别过度设计，直接用。

它的天花板出现在群数量上来之后。地址与群一一绑定，新增一个接收群就要改一次配置甚至改一次代码；群被解散重建，地址随之失效；播报要按排班点名到具体的人时，只有群维度的通道很难做到；出站和入站分属两套凭证、两套日志，排障时对不上号。这时候统一接入的价值才显出来 —— 用 wecomapi 这类统一入口，一套凭证发所有群，群标识只是请求里的一个参数，不再是一条独立的通道。

curl -X POST https://manager.wecomapi.com/message/sendText \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "guid":    "7db8...",
    "toId":    "<路由表算出的接收群标识>",
    "content": "【P1】支付回调超时率 8.2%"
  }'

三类播报，三种设计

告警、审批、发布经常被塞进同一个「通知」模板，然后同时变得难用。它们的频率分布、收敛需求和后续动作完全不一样，共用一套渲染和投递策略，等于按最坏的那一类来对待所有事件。

• 告警：高频、会连续重复、需要合并与恢复通知。同一个告警在抑制窗口内只发首条并累计次数，恢复时补一条「已恢复」。不这么做，群会被同一件事刷屏，真正的新问题淹没在里面。
• 审批：低频、强指向、必须落到具体的人。播报进群的价值是让人看见并能立刻处理，所以点名到审批人比把消息排版做漂亮重要得多；超时未处理要有一次升级提醒，而不是发完就不管。
• 发布：中频、面向多个角色。研发关心变更了什么，客服关心影响哪些功能 —— 他们需要的是同一个事件的两种渲染，而不是同一段文本发两遍。

三类里告警最危险，因为它是唯一会自己刷屏的一类。落地顺序建议是先把告警的抑制与合并做扎实，再接审批和发布 —— 后两类的量级天然可控，晚做几周也不会出事，而告警的抑制晚做一周，群就已经被养成「屏蔽掉」的习惯了。

静默窗口与排班：挂在接收群上，不挂在事件源上

「夜里不要吵人」不是把开关关掉那么简单。可用的做法是四层过滤串起来，每一层解决一个独立的问题。

1. 1级别阈值：每个接收群配一个最低级别，低于阈值的事件不进这个群，只落库备查。
2. 2时间窗：工作时间全量放行；非工作时间只放行最高级别，其余进积压队列。
3. 3排班：放行的高级别事件，按当班表点名到具体的值班人；无人当班时降级到一个固定的兜底群。
4. 4摘要：被积压的事件在次日上班时间合并成一条摘要发出。既不是丢弃，也不是攒到早上一条条炸出来。

关键判断是：静默窗口必须挂在接收群上，不能挂在事件源上。同一条支付异常告警可能同时要进研发群和客服群，研发群有夜间值班、客服群没有；把静默配置写进告警规则里，这两个群就只能共用一份作息，而它们的作息本来就不一样。挂到群上之后，配置的语义变成「这个群什么时候可以被打扰」—— 这才是真正需要被表达的东西。

多群模板化：路由表和模板表分开放

业务系统里不该出现任何群标识。它只负责产出一个结构化事件：类型、级别、一组标签，以及渲染需要的数据。往哪些群发、发成什么样，由投递侧的两张表决定 —— 一张把标签映射到群集合，一张把事件类型映射到模板。两张表要分开，因为它们的变更频率差一个数量级：新增接收群每周都可能发生，改文案可能几个月才一次。

groups:
  dev-core: { name: "研发核心群", min_level: P2, quiet: "22:00-09:00", oncall: rota-dev }
  cs-daily: { name: "客服日常群", min_level: P1, quiet: "20:00-09:00", oncall: none }

routes:
  - match: { tags: ["payment"] }
    to: [dev-core, cs-daily]
  - match: { type: "deploy" }
    to: [dev-core]

templates:
  alert:  "【{level}】{title} / {summary} / 首次 {first_at} · 累计 {count} 次"
  deploy: "{service} 已发布 {version} / 变更 {change_count} 项 · 负责人 {owner}"

注意配置里用的是 dev-core 这样的业务别名，真实群标识在另一处做一次映射。这一层间接看着多余，直到某个群被解散重建 —— 别名不变，只改一处映射，历史投递记录还能对得上。硬编码群标识的系统，换一次群就要翻一遍代码和一遍日志。

最阴险的失败是它悄悄不响了

凭证过期、群被解散、路由表里某个别名指向了不存在的群、上游事件源换了字段结构 —— 这几种故障有个共同点：它们都不会让任何人发现。群里只是变安静，而安静看起来和「最近没出事」一模一样。等到有人问「上周那个故障怎么没告警」，通道可能已经断了半个月。还要加一维：发送侧的账号本身。播报通常固定用一两个账号发，它一掉线所有群同时安静，而每个群单独看都只是「今天没事」。wecomapi 侧一个企业微信账号对应一个独立实例，实例状态可以单独查，把它和投递计数摆在同一张面板上，才分得清「没有事件」和「发不出去」；在线率这个指标怎么拆、告警发给谁，站内讲告警监控的那篇讲得更细。

• 心跳：每天固定时间往一个运维群发一条状态消息，内容是过去 24 小时各通道的投递计数。没收到心跳这件事本身就是告警。
• 对账：投递侧同时记录「应发」与「实发」，把 wecomapi 每次调用返回的结果一并落库，出现持续差额就报出来。只记成功日志，是发现不了静默失效的。
• 死信与重试上限：发送失败要落死信队列并重试，但次数必须有上限 —— 一个已经解散的群，重试一万次也发不进去，只会把日志淹掉。
• 定期校验路由表：把配置里所有群别名跑一遍可达性检查，比等出事再排查快得多，也便宜得多。