外部群机器人是企微 API 里一个容易被误解的概念。很多人以为"机器人"是一个独立账号，实际上它是。这篇讲清楚外部群机器人能做什么、怎么发消息、以及交互怎么实现。

客服系统对接微信，难点不只在自动回复，更在于"机器人什么时候该让位给人工"。接得不好，机器人硬答复杂问题，或者用户想找人工找不到，体验会明显变差。这篇讲消息接收、自动回复和转人工怎么设计。

企微 API 最务实的价值不是搭炫酷的机器人，而是把团队每天在做的那几件重复活自动化。这篇不讲功能清单，讲五个真实团队在做的自动化场景，每个场景给一句"怎么做"。

群消息处理和单聊不一样，最容易被忽略的一点是归属判定——一条群消息是谁说的、@了谁、要不要回应。不处理归属，机器人会把群里所有人的话当成"发给自己的"，回复就会乱喊。

自动回复做出来容易，"回复得合适"很难。难点不在收消息，在回复时机的选择——收到就回可能内容还没准备好，等太久用户又觉得机器人不理人。回复时机、内容来源、多消息合并，三个点决定了自动回复的体验。

很多开发者卡在第一步——Webhook URL 填了，消息发过来就是收不到。问题不在代码，在配置链路没打通。公网可达、HTTPS、端口开放，三个条件缺一个就收不到。

任务不能只写成一个函数，要结构化定义。一个任务包含：目标（用户要什么）、步骤（达成目标的动作序列）、参数（每步需要的输入）、约束（时间限制、权限范围）。结构化的价值在于可复用和可追踪。任务模板化之后，"查订单"这个任务对任何用户都是同一套步骤，只是参数不同。执行时可以逐步记录，出问题能定位到哪一步。

一个机器人要应付多种场景：答常见问题、查订单、预约、转人工。如果每种场景写一套 if-else，代码很快失控。我们用"场景路由"把这几类拆开，机器人只负责识别场景和分发，每个场景自己处理自己的逻辑。接口层用的是开放的企微 API，接收走 Webhook，回发走 message 模块。

微信事件回调是机器人感知外界的方式——新消息、新好友、群变动、登录状态变化，都通过回调通知。但回调接入不是"写个接口接收"那么简单，要解决回调接收、事件解析、异步分发、错误处理四个问题。

消息量大了，直接处理会崩——高峰期消息堆积，处理不过来，回调超时重发，恶性循环。消息队列是解耦的关键——消息进队列立即ACK，后台慢慢消费，不阻塞回调。