微信机器人不是单一程序，而是 Eyun 接口与业务程序在 3 个层次上协同运行的系统。接口提供输入和输出的能力，机器人程序负责中间的处理逻辑。下面按协同层次拆解这 3 层关系。

一、输入层关系：Webhook 是消息输入源

关系说明：机器人程序部署 Webhook 接收服务 → Eyun 推送用户消息事件回调 → 机器人获取 content 字段 → 投递到处理队列。

Eyun API 的 Webhook 回调 JSON 含 eventType、fromUser、content、msgId 四个核心字段，机器人程序解析 content 提取用户意图。配置回调地址后，所有微信消息都会实时推送到机器人。

关键约束：5 秒回调超时（机器人必须先返回 200 再异步处理，否则触发 3 次重试）、msgId 幂等（机器人用 Redis 去重防重复处理）。输入层关系决定了机器人"能收到什么"。

二、处理层关系：机器人程序内部处理回调数据

关系说明：Eyun 只负责推送回调 JSON → 机器人程序内部做意图解析（规则匹配或 AI 理解）→ 生成回复策略。

处理层完全在机器人程序内部完成，Eyun 不参与处理。这层的代码质量直接决定机器人的"智能水平"。机器人程序从 content 提取关键词后路由到不同处理函数，按 fromUser 维护会话上下文。

关键约束：意图识别准确率（规则匹配 >95%、AI 理解 >85%）、多轮对话上下文管理（机器人用 Redis Hash 按 fromUser 维护会话历史）。处理层关系决定了机器人"怎么理解和决策"——接口提供数据输入，机器人程序负责处理。

三、输出层关系：sendText 是回复输出端

关系说明：机器人程序生成回复内容 → 调 Eyun 的 sendText 发送（wId+Token+toUser+content）→ code=1000 确认。

按照 Eyun 开发文档 的规范，sendText 需要传 wId、toUser、content 三个必填参数，Token 鉴权失败返回 1001、限频返回 1004。

关键约束：1002 Token 过期自动刷新、1004 限频退避 3 秒、回复时序控制（回调返回 200 后再调 sendText，不能在回调中同步调，否则 5 秒超时）。输出层关系决定了机器人"怎么回复用户"。

3 层关系对比

3 层关系健康度检查框架

输入成功率、处理准确率、输出成功率三个指标监控协同健康度，任一层掉链子机器人整体就卡。

def health_check(input_total, input_dup, intent_correct, output_ok, output_total):
    input_rate = (input_total - input_dup) / input_total
    process_rate = intent_correct / input_total
    output_rate = output_ok / output_total
    return {
        "输入成功率": f"{input_rate:.1%}",
        "处理准确率": f"{process_rate:.1%}",
        "输出成功率": f"{output_rate:.1%}",
    }

print(health_check(1000, 10, 900, 950, 960))

结尾

3 层关系中 Eyun 承担输入层（Webhook 感知）和输出层（sendText 执行），处理层由机器人程序自行实现。这个分工意味着：接口的稳定性影响机器人的输入和输出，而机器人的"智能水平"由处理层代码质量决定。想让机器人更聪明，重点不在堆接口调用次数，而在处理层的意图识别和上下文管理做扎实。想了解 Webhook 回调的完整规范，建议查看 Eyun 开发文档 中的回调说明，也可以在 Eyun 平台 开通 wId 实例开始机器人开发。