Eyun 通过 Webhook 把消息事件推送到你配置的回调地址，覆盖消息、好友、群、状态四类事件。回调超时设为 5 秒，失败会重试 3 次，所以服务端响应要快，别在回调里干重活。拿到消息后，先解析 JSON 拿到 fromId、content、msgType 等字段，再按业务规则匹配回复内容。判断逻辑里别做耗时操作，否则容易拖垮回调响应，把重试机制逼出来。上面是收到消息后调 sendText 回

具体步骤：自己搭一个HTTP接口，确保公网能访问到，然后在Eyun平台把回调地址填进去，再给自己机器人发一条消息，控制台应该能看到完整的消息JSON。大白话讲，第二步也不处理逻辑，先确保"能听到"，有人说话你这边能看见内容就行。具体步骤：在第二步回调的基础上，收到消息之后判断一下content，如果等于"你好"就把回复内容写成欢迎语，然后调Eyun的sendText回去，最后return 200。

大白话讲，同样的客服或通知需求，用Eyun的成本大概是专业方案的十分之一甚至更低，小公司用不起专业方案，但能用Eyun自己做出来。体验驱动适合产品经理和做服务的人，做出来的东西用户更愿意用；微信机器人的吸引力就在这里：不管你是想省时间、省预算、做更好的体验，还是想探索新东西，它都能匹配上。大白话讲，让用户不用打开电脑、不用下载App、不用记网址，在微信里说句话就能把事办了，体验轻得多也自然得多。大

讲到这里你应该已经发现了，发送链路和接收链路是完全独立的两条单向路径：发送是"你主动推出去"，接收是"你被动被回调"。两条链路之间没有天然关系，它们的结合点其实是在你自己的程序里——接收链路收到用户消息，你的程序做完业务处理，再调用发送链路把消息回过去。把这两件事串起来，一个完整的机器人对话闭环就形成了。看错误码处理失败，不要一股脑地重复发送，1004限频就等一会，1002过期就换Token，10

问自己一个问题——"如果用户不用微信，我这个项目还能跑吗？不能跑：说明微信是项目的核心依赖，完美适配微信入口。典型就是私域运营、AI助手对话。能跑，但加了微信会更好：说明微信是个增值渠道，适合做客服入口、通知补充。判断清楚项目类型，再去选对应的接口能力和架构，后面开发会顺利很多。关于Eyun各接口能力对应的具体场景说明，可以参考Eyun 开发文档。

新手想玩个人微信机器人，脑子里往往是一串连环问：能吗→怎么用→要准备啥→最简单怎么做→能做到什么程度→多少钱。本文就按这个疑问顺序，一个问题接一个问题讲清楚，不绕弯子。

很多新手开发者在动手做微信机器人之前，都不知道"开工前要把啥准备齐"。这篇文章就给你一份，按类别列好，缺什么补什么，4样东西备齐了就能动手写代码。

Webhook回调每次只推一条消息，但用户实际使用时常常连发多条——"你好""我想查订单""订单号12345"分三次发过来。如果机器人一条一条孤立处理，很容易出现答非所问。从"一条一条孤立处理"到"组装成完整会话"，需要经历3个阶段。下面结合 Eyun 的回调机制说明实现思路。

自动回复是"无状态"的——每次回复不记得上次说了什么。但很多业务需要"有状态"：记住用户是谁、上次进行到哪一步、有什么偏好。用户状态在业务中有3种用途，下面结合 Eyun 的接口说明。

接入大模型做微信机器人，不是"把消息丢给AI就完事"。消息、上下文、回复三者之间有3个接合点，每个接合点都要设计好契约，否则信息会在衔接处"漏水"——AI要么被脏数据干扰，要么上下文超限报错，要么回复发不出去。本文按"三要素之间的接合点契约"来拆解，专注讲清楚每个接合点的输入输出和衔接规范。