好友申请处理不是一个接口的事，而是一条完整的自动化管线。从收到申请到完成处理，分三个环节。
一、感知环节——程序怎么知道有人申请
靠好友事件回调。用户发起好友申请时，Eyun 通过 Webhook 推送事件通知，回调数据里带申请人标识、申请来源、验证消息。
感知环节的关键是别漏——回调 5 秒内返回 1000，超时会重试 3 次。程序收到后先把申请记录入库，再异步处理，不阻塞回调响应。
二、判断环节——自动通过还是拒绝
拿到申请后程序做判断。判断依据通常有三类：来源渠道（某个活动来的自动通过）、验证消息关键词（含"代理""加人"等词拒绝）、已有客户匹配（CRM 里有记录的优先通过）。
判断结果分三种：明确通过、明确拒绝、不确定转人工。规则不要太复杂，覆盖 80% 的常见情况就够，剩下的交人工。
三、执行环节——通过后紧接着做什么
判断为通过后，程序执行一连串动作：调通过接口接受申请，改备注（加来源标签方便后续分组），发欢迎语（引导用户进入下一步流程）。
执行环节要处理失败情况——通过成功但发欢迎语失败，要有重试机制。每个动作独立执行，一个失败不影响其他。
三环节对照
处理环节 | 做什么 | 关键机制 |
|---|---|---|
感知 | 收到申请通知 | 好友事件回调、5 秒响应 |
判断 | 规则决定通过/拒绝/转人工 | 来源匹配、关键词、CRM 关联 |
执行 | 通过 + 改备注 + 发欢迎语 | 接口调用、失败重试 |
自动处理示例
@app.post("/webhook") def webhook(): d = request.json if d.get("eventType") == "friend_apply": apply_q.put({ # 入库异步处理 "wxid": d["fromUser"], "source": d.get("source", ""), "verify": d.get("verifyMsg", "") }) return {"code": "1000"} def apply_worker(): while True: a = apply_q.get() if a["source"] in AUTO_PASS_CHANNELS: # 来源自动通过 accept_friend(WID, a["wxid"]) set_remark(WID, a["wxid"], f"渠道-{a['source']}") sendText(WID, a["wxid"], "欢迎，回复1看菜单") else: notify_admin(a) # 转人工审核落地建议
好友申请自动化能省大量人工，但规则要保守。建议先用"感知 + 转人工"模式跑一段时间，观察申请来源分布和验证消息特征，再逐步开放自动通过。通过后的欢迎语和改备注动作要确保成功率，好友加了但没欢迎到位等于白加。
