“在外部群里放一个 AI 机器人，客户一问就自动答”——这个需求几乎是所有做私域、做客服团队的标配。但真正落地时会发现：调用大模型只是其中最简单的一环，难的是怎么把"收消息—判断—生成—回消息"这条 API 链路串稳、串准。

这篇文章从接口实战角度，把企业微信外部群机器人接入 AI 自动回复的完整流程拆开，讲清楚每个 API 环节怎么对接。

一、自动回复机器人的 API 链路全貌

一个外部群 AI 自动回复机器人，本质是四个 API 动作的串联：

群消息（回调 API） → 判断要不要答 → AI 生成（模型 API） → 自动回复（发送 API）

对应到接口层面：

• 接收：Webhook 回调 （设置回调地址方法：https://www.qiwx.online），把群消息事件推到你的服务
• 判断：你的业务逻辑，决定哪条消息该触发 AI
• 生成：调用大模型 API（最好接知识库做 RAG）
• 回复：调用发送消息 API（发送消息接口:https://www.qiwx.online），把答案发回群里

下面逐个环节讲怎么对接。

二、第一环：用回调 API 接收群消息

机器人要"听见"群里说话，靠的是回调（Webhook）。在控制台配置好回调地址后，群里来消息，系统会 POST 推到你的接口：

from fastapi import FastAPI, Request, Header, HTTPException

app = FastAPI()
SECRET = "your_callback_secret"

@app.post("/api/data")
async def on_message(request: Request, authorization: str | None = Header(default=None)):
    if authorization != SECRET:          # 回调鉴权
        raise HTTPException(401)
    event = await request.json()
    enqueue(event)                        # 入队，立即返回
    return {"code": 0}

两个实战要点：

• 必须鉴权：回调地址是公网的，配 Authorization 密钥逐条校验，挡掉伪造请求
• 必须快速返回：AI 生成是慢操作（几秒），绝不能堵在回调接口里同步做，否则推送方超时重试，导致重复回复

三、第二环：判断"这条消息要不要让 AI 答"

这是最影响体验、却最容易被跳过的一环。外部群消息很杂：客户闲聊、互相 @、发表情、内部同事讨论。如果 AI 见消息就抢答，群会变得很吵，客户反感。

合理的触发判断通常是几个条件的组合：

def should_reply(msg) -> bool:
    if msg["is_at_bot"]:                  # 被@必答
        return True
    if msg["from_internal"]:              # 内部成员不抢答
        return False
    if any(k in msg["text"] for k in KEYWORDS):   # 命中业务关键词
        return True
    if msg["text"].endswith(("？", "?", "吗")):    # 疑问句
        return True
    return False

把这道"门"做好，AI 才显得"懂分寸"，而不是一个抢话的机器人。

四、第三环：调用 AI 生成回答（RAG 是关键）

直接把客户问题丢给大模型，最大的风险是它会自信地编造。客户问"你们支持私有化部署吗"，模型可能凭通用知识答"支持"，但你的产品未必有——这种错误回答比不回答更糟。

正确做法是 RAG（检索增强生成）：先从你的知识库检索相关内容，再让模型基于检索结果回答：

async def ai_reply(question: str) -> str:
    # 1. 从知识库检索相关片段
    docs = await retrieve(question, top_k=3)
    if not docs:
        return "这个问题我需要帮您转人工确认一下。"
    # 2. 拼进 system prompt，约束模型只依据知识库回答
    context = "\n\n".join(docs)
    system = f"""你是企业的在线客服，只能依据下面的知识库回答。
规则：
1. 只根据知识库内容回答，不要编造库里没有的信息。
2. 知识库没覆盖的，明确说"需要转人工"，不要硬答。
3. 用中文，像真人客服一样清晰、直接。

知识库：
{context}"""
    # 3. 调用大模型
    return await call_llm(system, question)

关键在 system prompt 的边界约束：答得上来的才答，答不上来老实承认并转人工。这是 AI 客服能不能放到客户面前的底线。

五、第四环：调用发送 API 自动回复

AI 生成完，调用发送消息 API 把答案发回群：

import httpx

async def send_reply(guid: str, group_id: str, content: str):
    async with httpx.AsyncClient() as client:
        await client.post(
            "http://api.qiwx.online/work-weixin/api/doApi",
            headers={"Content-Type": "application/json", "X-QIWEI-TOKEN": "your_token"},
            json={"method": "/msg/sendText",
                  "params": {"guid": guid, "toId": group_id, "content": content}},
            timeout=30,
        )

• guid：群所在的企业微信执行节点
• toId：目标外部群 id

注意节点要在线，掉线了答案发不出去，所以要订阅"登录状态"事件做监控。

六、把四环串成完整自动回复流程

async def handle_event(event):
    msg = parse(event)
    if not should_reply(msg):             # 门：要不要答
        return
    answer = await ai_reply(msg["text"])  # AI 生成（RAG）
    await send_reply(msg["guid"], msg["group_id"], answer)  # 自动回复

配合回调入队，整条链路就是：

回调收消息 → 入队 → should_reply 判断 → RAG + 大模型生成 → 发送 API 回复

设计原则四条：

1. AI 生成永远异步，不堵回调接口
2. 触发判断在 AI 之前，省成本也省尴尬
3. RAG 是默认而非可选，没有知识库约束的客服 AI 不能上生产
4. 答不上来要会转人工，这是底线能力

七、自动回复的边界：AI 接高频，人接复杂

接了 AI 不等于裁掉人工。AI 在外部群该承担的是高频、确定、可知识库化的部分：产品怎么用、价格怎么算、报错怎么办、文档在哪。这部分占咨询量的大头，AI 接住了，人就能从重复劳动里解放出来。

而商务谈判、客诉处理、个性化方案这些复杂沟通，AI 该做的是识别出"这个超出我能力了"并干净地转人工，而不是硬答到底。一个会说"这个我帮您转人工"的机器人，比什么都敢答的靠谱得多。

技术上，企业微信外部群机器人接入 AI 自动回复这条 API 链路已经很成熟：回调接收、触发判断、RAG 检索、模型生成、发送回复，每一环都有标准做法。真正拉开差距的是细节——触发策略是否克制、知识库是否扎实、转人工是否顺滑。把这几点打磨好，外部群 AI 自动回复机器人就能从"演示时惊艳"变成"客户天天用都不出戏"。

---

如果你要落地，建议先跑通一条最小链路：群里 @ 机器人问一个产品问题 → 回调收到 → RAG 检索到文档 → AI 基于文档生成 → 发送 API 回复到群里。这条跑通了，触发策略、知识库扩充、转人工都是在它之上叠加的事。先把"准"做出来，再谈"全"。