“给外部群接个 AI 机器人，客户问什么它自动答”——这个需求现在几乎每个做私域、做客服的团队都提过。听起来就是"群消息接个大模型"，但真正动手做才发现，难的从来不是调用模型那一步，而是怎么让 AI 在外部群这种真实、嘈杂、对延迟和准确度都敏感的环境里稳定可用。

这篇文章把"外部群机器人接入 AI"的完整链路拆开，讲清楚每一段该怎么设计，以及哪些地方决定了最终体验的好坏。

一、先看清这条链路的全貌

一个外部群 AI 机器人，本质是把"收消息—理解—生成—回消息"四段串起来：

群消息事件 → 回调接收 → 判断要不要答 → AI 生成回答 → 下行发送回群

每一段都有自己的工程难点：

• 收消息：靠 Webhook 回调，要鉴权、要快返回
• 判断要不要答：不是每条消息都该让 AI 接话
• AI 生成：模型选型、知识库、防胡说
• 回消息：指定节点下行发送，要节流

很多团队栽在第二段和第三段——要么 AI 见消息就抢答，把群变成刷屏现场；要么 AI 张口就来，答的全是产品里根本没有的功能。下面重点讲这两段。

二、第一段：把群消息接进来

这是基础。群里来消息，通过回调推到你的服务端：

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

要点和任何回调接入一样：鉴权 + 快速返回 + 异步处理。AI 生成是慢操作（动辄几秒），绝对不能堵在回调接口里同步做，否则推送方会判定超时甚至重试，造成重复回答。

三、第二段：判断"这条消息要不要 AI 接"

这是最容易被跳过、却最影响体验的一段。外部群里消息是混杂的：客户闲聊、互相 @、发表情、内部同事讨论……如果 AI 对每条都接话，群会瞬间变得很吵，客户反而反感。

合理的触发策略通常是几个条件的组合：

• 被 @ 时才答 —— 最克制，明确"在叫我"才回应
• 命中关键词 —— 比如出现"价格"“怎么用”"报错"等业务相关词
• 疑问句式 —— 带"吗"“怎么”“为什么”“能不能”
• 排除内部成员 —— 区分 external_userid 和内部 userId，只对外部客户的提问应答

def should_reply(msg) -> bool:
    if msg.is_at_me:                 # 被@必答
        return True
    if msg.from_internal_user:       # 内部成员发言不抢答
        return False
    if any(k in msg.text for k in KEYWORDS):
        return True
    return False

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

四、第三段：让 AI 答得准——RAG 是关键

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

解决办法是 RAG（检索增强生成）：先从你自己的知识库里检索相关内容，再让模型基于检索结果回答，而不是凭记忆瞎编。

客户问题 → 向量检索知识库 → 取出最相关的文档片段 → 拼进 Prompt → 模型基于片段生成回答

关键在 system prompt 的约束，要明确划定边界：

SYSTEM_PROMPT = """你是企业的在线技术客服，只能依据下面的知识库内容回答。

规则：
1. 只根据知识库检索结果回答，不要编造库里没有的信息。
2. 如果知识库没有覆盖，明确说"这个问题我需要转人工帮您确认"，不要硬答。
3. 与业务无关的问题，礼貌拒答。
4. 用中文，像真人客服一样清晰、直接。

知识库检索结果：
{context}
"""

这套约束做下来，AI 的回答会牢牢锚定在你的真实产品文档上。答得上来的它答，答不上来的它老实承认并转人工——这才是能放到客户面前的状态。

五、第四段：把回答发回群里

AI 生成完，下行发送回群：

POST /work-weixin/api/doApi
Header: X-QIWEI-TOKEN: <应用凭证>
Body: {
  "method": "/msg/sendText",
  "params": {
    "guid": "<群所在节点的 guid>",
    "toId": "<群 id>",
    "content": "<AI 生成的回答>"
  }
}

这里要注意两点：

• 节流：AI 可能短时间被多人提问，发送一定要走队列、按安全间隔匀速发出，不能瞬间刷屏。
• 节点在线：发送依赖挂群的节点在线，掉线就发不出去。所以要订阅"登录状态"事件，节点掉线及时告警。

六、把四段拼成完整架构

                ┌──────────────┐
  群消息回调 ──→ │ 接收+鉴权     │ ──→ 队列
                └──────────────┘
                       │
                       ▼
                ┌──────────────┐
                │ 是否该答(门)   │ ── 不答 → 丢弃
                └──────────────┘
                       │ 该答
                       ▼
                ┌──────────────┐
                │ RAG 检索知识库 │
                └──────────────┘
                       │
                       ▼
                ┌──────────────┐
                │ 大模型生成     │
                └──────────────┘
                       │
                       ▼
                ┌──────────────┐
  下行发送回群 ←─│ 发送队列+节流  │
                └──────────────┘

这套架构的几个设计原则：

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

七、关于"AI 客服"的边界，说点实在的

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

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

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

---

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