微信机器人不是只有一种形态。按 Eyun 接口在机器人中的调用范式划分，有三种典型模式：单向推送、事件响应、闭环对话。三种范式按交互深度递进，工程复杂度也逐级递增，对应不同的接口组合。本文按接口调用范式拆解三种自动交互的实现路径。

一、单向推送范式：机器人主动发消息，用户被动接收

范式特征：机器人主动发消息 → 用户被动接收 → 无回复通道。调用模式：业务逻辑触发 → sendText 推送 → code=1000 确认 → 结束。

适用场景：定时播报机器人（每日新闻/天气/股价推送）、状态监控机器人（服务器异常告警/库存预警推送）、任务提醒机器人（待办到期/会议开始提醒）。

技术实现：定时任务或事件触发 → 构建 {wId, Token, toUser, content} 请求体 → POST 到 Eyun API 端点 → 解析 {code, msg, data:{msgId}} → code=1000 记录 msgId。按照 Eyun 开发文档 的规范，sendText 需要传 wId、toUser、content 三个必填参数。

技术约束：1002 Token 过期自动刷新、1004 限频退避 3 秒、content 长度限制。单向推送范式的工程复杂度最低——只需 HTTP 调用能力，不需要部署 Webhook 接收服务。在 Eyun 平台管理 wId 实例即可。价值：最小成本实现机器人推送能力（1 人天）。

二、事件响应范式：用户主动发消息，机器人被动响应

范式特征：用户主动发消息 → 机器人被动响应 → 单轮问答。调用模式：用户发消息 → Eyun Webhook 回调 → 5 秒返回 200 → 规则匹配 → sendText 回复。

适用场景：FAQ 机器人（关键词匹配自动回复常见问题）、命令机器人（用户发指令机器人执行并回复）、群管机器人（入群欢迎/违规检测/自动踢人）。

技术实现：部署 Webhook 接收服务 → Eyun 推送 4 类事件回调（消息/好友/群/状态）→ 回调 JSON 含 eventType+fromUser+content+msgId → 5 秒内返回 200 → 异步投递到规则引擎 → 关键词/正则/模糊匹配 → sendText 回复匹配结果。

技术约束：5 秒回调超时需异步处理、msgId 幂等去重、3 次重试需队列缓冲、规则引擎匹配准确率。Eyun API 的 Webhook 回调是事件响应范式的核心——没有 Webhook 机器人就是"聋子"。价值：实现单轮自动问答能力（3-5 人天）。

三、闭环对话范式：sendText+Webhook 构建多轮对话闭环

范式特征：机器人主动推送 → 用户回复 → 机器人理解 → 机器人再推送 → 多轮交互。调用模式：sendText 推送引导语 → 用户回复 → Webhook 接收 → 会话状态机判断 → sendText 推送下一步引导或结果 → 循环直到对话结束。

适用场景：审批机器人（推送审批 → 回复同意/拒绝 → 推送确认）、问卷机器人（推送问题 → 接收答案 → 推送下一题 → 推送汇总）、AI 助手（推送欢迎 → 接收用户意图 → 大模型推理 → sendText 回复 → 循环对话）。

技术实现：sendText 推送+Webhook 接收+msgId 关联（sentMsgId → inResponseTo 匹配）+会话状态机（等待回复 → 已回复 → 处理中 → 已回写 → 已超时/已结束）+上下文管理（按 fromUser 维护会话历史）。

技术约束：msgId 跨轮关联、会话状态机多轮管理、上下文存储（Redis Hash 按 fromUser 维度）、30 分钟超时自动关闭。通过 Eyun 平台 的 sendText 和 Webhook 构建多轮对话闭环。价值：实现多轮智能对话能力（8-15 人天）。

四、3 种范式对比

三种范式的工程复杂度差距源于接口的调用深度：单向推送只调 sendText 一个接口，事件响应多了 Webhook 接收链路，闭环对话还要叠加状态机和上下文存储。

五、3 种范式选择决策框架

def choose_paradigm(interaction_depth, budget_days):
    # interaction_depth: 1=推送 2=问答 3=多轮对话
    # budget_days: 工程预算人天
    # 返回: (范式名称, 所需组件列表)
    if interaction_depth == 1 and budget_days <= 1:
        return "单向推送范式", ["sendText", "定时任务"]
    if interaction_depth == 2 and 3 <= budget_days <= 5:
        return "事件响应范式", ["Webhook", "规则引擎", "sendText"]
    if interaction_depth == 3 and budget_days >= 8:
        return "闭环对话范式", ["sendText", "Webhook", "状态机", "Redis"]
    if interaction_depth == 3 and budget_days < 8:
        return "降级到事件响应范式，闭环对话需 8 人天以上", []
    return "建议先单向推送验证链路，再逐级演进", []

结语

3 种范式按交互深度递进——单向推送范式是"广播"（机器人说用户听）、事件响应范式是"问答"（用户问机器人答）、闭环对话范式是"对话"（双向多轮交互）。按交互需求选择范式，而非一开始就用最复杂的闭环。从趋势看，AI 大模型会让闭环对话范式的构建门槛降低——大模型负责理解和决策，Eyun 负责感知和执行，但 3 种范式本身不会消失，因为不同场景需要不同交互深度。