做企业微信外部群自动化，最常见的起点是错的：去后台找「群机器人 / 消息推送」。内部群有这个入口；外部客户群没有。不是少勾选项，是能力边界——官方机器人做不到外部群。

所以外部群里的「主动发」「自动回」，发言主体只能是已经在群里的成员账号。工程上要补的不是另一个官方机器人，而是：收得稳、发得准、账算清。

先把两种群分开看

维度	内部群机器人	企业微信外部群
官方消息推送入口	有	无
谁在说话	机器人身份	真实成员账号
业务怎么推	官方推送 URL	托管账号 + HTTP API / RPA 节点执行
怎么收客户侧消息	视官方能力	Webhook 回调到自有服务

混用内部群文档去设计外部群排期，会白做一周。外部群机器人这个名字可以保留在需求单里，实现落点必须改成「成员账号可控」。

可上线的只有这一条主链路

目标链路就一句话：

Webhook 收消息 → 业务 / 队列 /（可选）AI → API 主动回复外部群

拆开是四步：

1. 收：群发言、进群等事件 POST 到公网回调。

2. 快响应：校验、去重、入队，约 3 秒内返回 HTTP 200。超时丢事件，后面回复写得再好也没有触发源。

3. 慢处理：查工单、关键词、大模型，全部放 Worker。

4. 发：统一 doApi，例如 method 为 /msg/sendText，toId 填外部群 roomId，guid 用事件里的设备 ID。

另有一条不依赖客户先说话的支路：业务主动推（工单状态变更、报价通过）。发送接口可以共用，幂等键必须分开——自动回用设备 + 消息唯一标识，主动推用业务单号 + 状态版本。

回调层只做网关，不做业务

接收骨架刻意短：

@app.post("/qiwe/webhook")
def webhook():
    # 先入队；cmd / msgType / 群字段放到 Worker，以文档为准解析
    queue.push(request.get_data(as_text=True))
    return "", 200

再记住两条范围规则：

• 接口主动发出的消息，通常不会再进回调——发成功看当次响应，别干等 Webhook。

• 手机端人工消息会进回调——没有「人工接管」状态，自动回会抢话。

调试顺序也别反：Postman 先打自己的回调 → 再看真实事件 JSON → 再确认去重 → 最后才接发送。一边改文案一边怀疑「通道不稳」，排障成本最高。

主动发最小闭环

{
  "method": "/msg/sendText",
  "params": {
    "guid": "设备ID",
    "toId": "外部群roomId",
    "content": "工单已更新，请查看群内说明。"
  }
}

toId 填成客户个人 ID，人在群里也看不到群消息，只会落到私聊——这是外部群主动发最典型的「接口成功、业务失败」。roomId 不确定时，用同一 guid 拉群列表校准（接口名以文档为准）。

发送侧建议按账号串行、间隔模拟真人节奏；并发狂发短期看吞吐，长期看风控和投诉。队列、优先级、过期丢弃，比再封装一层发送 client 更重要。

哪些场景挂得上，哪些先别挂

适合先挂的：

• 入群欢迎（系统事件入队，延迟发，按「群+成员+日」幂等）

• 关键词自动回（默认沉默，命中再回，skip 打原因码）

• 工单 / 报价通知（业务事件主动推，状态合并，避免刷流水）

先别挂的：

• 回调线程里同步调大模型

• 无过滤的「有字就回」

• 把运营群发和客服应答塞进同一无优先级通道

私域自动化、AI 客服都可以接，但位置只能在队列之后；模型不是真相源，工单进度只查系统。

上线检查清单

1. 账号在线，且仍在目标外部群；guid 固定映射，掉线优先恢复而非新建。

2. 回调公网可达，验证请求能 200；耗时有监控。

3. 决策日志能区分 reply / skip 及原因。

4. 发送任务带 biz_id、source（webhook vs ticket）、正确的 roomId。

5. 主动推与自动回两套幂等互不覆盖。

创建设备时的省份、扫码时限等接入约束，漏了会表现为「偶发发不出」，别先怪发送接口。

小结

企业微信外部群自动化，承认官方做不到只是起点；真正能长期跑的，是「Webhook 收得稳 + API 主动发得准 + 主动推/自动回账本拆开」。把回调做成消息网关，把发送做成限速队列，欢迎、关键词、工单、AI 才有地方挂——而不是一上来堆回复文案。