自动处理咨询不靠「AI 专用接口」靠两条已有能力串起来。收设置回调{ method: /client/setCallback, params: { callbackUrl: 你的公网可访问地址, authType: Authorization, authSecret: 自行保管的密钥 } }发纯文本回复{ method: /msg/sendText, params: { guid: 设备ID, toId: 外部群roomId或客户userId, content: 答复正文, isNoNeedRead: true } }请求头带应用 Token。回调需在约 3 秒内返回接口自己发出的消息一般不会再回调。事件里的guid、群/人 ID、文本字段以回调结构说明为准不要猜。功能怎么从这条接口长出来「自动处理咨询」 收到客户话 → 你的服务判断能否自动答 → 能则生成答复并发送不能则转人工。建议固定成回调进公网地址验签后写入队列立刻返回成功Worker 取出guid、会话toId、客户原文先规则工单号、关键词再知识库/模型无把握就标「转人工」仅自动路径调用/msg/sendTextguid必须与回调事件一致用消息唯一标识做入站去重用「入站ID reply」做出站幂等群是多人会话按「群 发送人」隔离上下文避免把 A 的咨询答给 B。投诉、要人工、知识库未命中只回一句转接说明或保持沉默并写 SCRM不要硬答。调用前要挡住的错在回调线程里直接调大模型超时丢咨询。每条群消息都进模型刷屏。发送时换了另一个guid。toId群聊却填成个人 ID或反过来。无知识来源仍让模型编价格、时效、责任条款。人工已接手仍继续自动回。怎么验收测试外部群用固定话术问「进度」应先入队、再出现一条合理答复且只一条。连打三次同一回调体不得出现三倍回复。知识库故意清空后应走转人工而不是瞎编。客服手机端接手后自动回复应停止。