个人微信实例和服务器进程不一样，它有真实的登录态，会掉线。客服机器人、订单提醒这类长期跑的业务，掉线意味着消息静默失败——接口报错你看日志能发现，实例掉了但没人盯，业务就断在那。这篇给一套我们在用的三层保障：探活、自动重连、告警分层。接口以 Eyun 个人微信 API 文档为准，代码需校验后使用。

客服下班后客户消息没人回，是中小团队最常见的痛点。一个最小可用的自动应答服务，核心就三段：接收推送、识别意图、回复消息。这篇用 Express 实现一个关键词应答机器人，重点讲清楚两件容易被忽略的事：重推幂等和应答顺序。接口行为基于实际联调，代码需按文档校验。

四个接口覆盖了群运营的高频动作，剩下的是把它挂到业务事件上：客户成交后自动建群拉人，公告随活动排期更新。这篇示例基于Eyun 平台的企微接口整理，接口清单和身份要求在开发文档里有一张总表；建议先用小群把参数验证清楚，再上批量流程。

三步收个尾：控制台领凭证扫码登录、用个人信息接口确认发送目标、封装 sendText 加上错误处理。这套示例基于 Eyun 平台的企微接口整理，参数细节以官方文档为准，调用失败先查错误码表再改代码，能少走不少弯路。

客服 RAG 不好用的常见原因，不是检索算法不行，而是知识库里根本没有能用的知识。历史聊天记录里其实藏着大量真实问答对，但直接灌进去会带来噪声、过期答案和互相矛盾的版本。这篇讲怎么把它洗干净再入库。

Dify 把知识库、编排、模型管理都做完了，Java 团队真正要写的只有两段胶水：把群消息喂给它，把回答送回群里。之前写过 Python 对接 Dify 做客服的思路，这篇换成 Java，重点讲最容易漏的一环——。

之前写过 Java 收发卡片消息（Webhook 机器人那条路），这篇补另一半：怎么封装一个正经的，把 token 管理和 sendText 跑通。企微这类平台没有官方 Java SDK，第三方包质量参差，自己封装百来行反而最稳——出错行为完全可控，字段和文档一一对应。

营销机器人和客服机器人的最大区别是"主动发消息"——客服是被动等用户来问，营销要主动推活动、推新品、推福利。主动发就有两个必须解决的问题：任务排队和发送频控。做不好要么被限流、要么打扰用户、要么账号被风控。

很多人把"API 接口"和"微信机器人"当成一回事，其实它们是两层东西——API 是能力层（能做什么），机器人是应用层（怎么组合这些能力解决业务问题）。分不清这两层，就会出现"接口都调通了但机器人不好用"的情况。这篇讲清两层的关系和组装方法。

24 小时自动客服的核心不是"能自动回消息"，是"对话有头有尾"——用户半夜来咨询，机器人要能引导他说清需求、给答案、确认解决没有，解决不了挂起到早上转人工。这篇讲客服机器人的对话状态机设计。