企业微信AI客服机器人实战：从消息回调到大模型接入

1. 先想清楚边界：你做的到底是“群客服”还是“消息转发+AI大脑”

上个月我接了一个小需求。朋友经营一个本地服务群，六百多人，每天都被相似的问题包围：几点开门、怎么预约、收费多少、售后找谁。他想把这些高频问题直接丢给AI，搞一个微信群AI自助客服，让群里的人随手一提问，机器人就能给出靠谱回答。需求听起来很明确，但真正落地之前，有非常多边界问题要先想清楚。

如果你脑子里第一反应是“用协议工具直接接管个人微信号”，我必须先泼一盆冷水。个人微信没有官方开放的消息自动化接口，那些所谓“hook 机器人”“云控框架”本质上都在踩平台红线。账号行为一旦异常，轻则消息发不出去，重则整个号被封，高价值客户聊天记录全部蒸发。做私域运营的人应该都清楚，一个养了两三年的微信号，承载的是信任资产，拿它去赌自动化，完全不划算。

所以我一开始就把方向定在企业微信侧。从客户视角看，企业微信和微信是打通的，一样能在会话框里发文字、表情、图片，体验几乎没差别；但从开发者角度看，企业微信有完善的 API、回调事件、消息推送能力，可以合法地实现“机器人收到消息→调用大模型→返回答案”的完整闭环。个人微信群聊里没法做的那种稳定运营，在企业微信客户群里是可以落地的。

这篇文章适合谁看？一类是像我朋友这样在做私域社群、门店客服、教育培训、电商售后，有一堆重复问题需要自动应答的人；另一类是想把“大模型接入微信生态”作为练手项目的开发者。看完之后，你至少能搞明白三段事：第一，消息从哪里收、怎么收；第二，大模型怎么接、回答怎么控制得像个客服而不是段子手；第三，上线之后会遇到哪些我踩过的坑。这个项目我实际开发加调试用了大概一周，如果把弯路绕掉，三到四天能跑通第一个可用版本。

1.1 个人微信群为什么一上来就被我否了

很多人会说，我不需要企业微信，我就在个人微信群里放个机器人，挺多社群不都这么干吗？确实有，但那些方案要么是一次性的付费工具，要么是技术灰产。作为开发者，你应该知道以下几点：

• 个人微信没有官方消息推送接口。任何拦截和自动回复都需要注入进程、Hook 消息或模拟点击，存在明显的安全风险，一旦微信更新机制，整套东西可能立刻失效。
• 频繁自动操作会触发风控。一个真实账号突然变成 7x24 小时秒回，聊天频率和人工完全不一样，很快会被标记。
• 数据安全没法保障。客户的手机号、订单信息、聊天记录全经过第三方脚本，等于把最核心的用户资产交了出去。
• 账号一旦被封，申诉难度极大。客户要找的时候找不到人，所有群运营直接归零。

相比之下，企业微信官方的接口能力是我的首选。包括接收消息服务器的回调、应用消息推送、客户群管理、客服账号等，这些能力都写在公开文档里。正规场景下，我们不需要在“个人微信里硬塞机器人”这件事上死磕，而应该思考怎么把用户自然地引导到官方支持的会话场景中。这个思路对长期可持续运营来说，重要程度不亚于AI本身。

1.2 两条靠谱落地路径：企业微信会话客服和客户群机器人

落地路径有两条，取决于你的客户是在“单聊”里问，还是在“群里”问。

第一条是会话客服路径。用户在微信里添加了你的企业微信客服号，然后直接发消息提问，后端收到回调，调大模型回答，再通过应用消息主动推送给用户。这条路最稳，几乎每个企业微信版本都支持，适合从“全渠道客服中心”切入。

第二条是客户群机器人路径。把企业微信的机器人拉进一个“客户群”，或者让用户在企业微信群里 @ 机器人提问，机器人的回调服务收到群消息，生成回答后在群里展示。对用户来说，这个体验最接近大家想象中的“微信群AI自助客服”。不过它需要企业的管理后台具备相应机器人和消息回调能力，部分小型企业或者试用版不一定开放，要提前去管理后台确认。

我在实际项目中是把两条路合成一个服务来做：外面进来的是单聊还是群聊，并不影响大脑的逻辑，只是“消息来源”不一样。你只需要在回调里判断一下，是来自用户单聊的消息，还是来自群聊的 @ 消息，然后走同一套“问题清洗→知识检索→大模型生成→发送回复”的流程。这样做的好处是代码只维护一套，后续接公众号、小程序客服都是复用同一个处理函数。

1.3 项目技术栈和整体消息链路

我最终使用的技术栈没有刻意追新，都是成熟好排查的组合：

• 服务端：Python + FastAPI + Uvicorn，理由很简单，FastAPI 异步处理回调很顺手，写起来快，部署也轻。
• 消息接入：企业微信自建应用/机器人的接收消息服务器回调。
• 大模型接入：使用 OpenAI 兼容协议，通过 DeepSeek 的接口来做对话生成。选这种兼容协议不是因为某个模型更好，而是因为换模型成本无限低，以后想切通义、智谱或者本地模型，只改一个 base_url。
• 会话存储：单机调试时用内存队列，多个实例跑的时候用 Redis。会话记录存最近几轮，配合系统提示词一起发给模型。
• 知识库：先用轻量级向量库做 FAQ 检索，可以是 Chroma 或者 FAISS，把高频问题的标准答案先捞出来，再让大模型做总结，降低胡说八道概率。

完整消息链路可以这样理解：用户在微信/企业微信窗口里发一句话 → 企业微信服务器把它封装成 XML 回调包 → 携带着签名和加密内容打到我的服务 → 服务验签并解密，拿到真实文本 → 进入 AI 处理逻辑 → 把结果通过发送消息接口或群机器人 Webhook 回传 → 用户看到最终回复。整个链路看起来简单，中间的加密验证、超时重试、并发控制、知识库匹配，任何一个环节没处理好都会翻车。下面我按顺序把每一步拆开写。

2. 动手前先搞定两个入口：消息回调和大模型接口

这个项目本质上就是“消息入口 + AI大脑 + 回复出口”的组合。很多人一上来就写 Prompt、调大模型，结果到了真实场景发现消息收不到，或者收到了不会回复，前面所有调试全部白费。我建议的次序是：先把回调跑通，再测大模型，最后把两者拼接。这样每一层出问题都很容易定位。

2.1 企业微信后台配置：自建应用、Token、EncodingAESKey

打开企业微信管理后台，在“应用管理”里创建一个自建应用，或者创建一个企业机器人之后，你会拿到几个核心参数：企业 ID（CorpID）、应用 AgentId、应用 Secret。这三个参数就是后续调用 API 的身份证，建议第一时间写进环境变量，不要硬编码在代码里。

接着进入应用的“接收消息”设置，需要配置三个东西：

• URL：你的回调服务地址，必须是可以公网访问的 HTTPS 地址。开发阶段没有正式域名时，可以先在本地起服务再临时映射出去调试，但最终上线必须是正式域名加证书。
• Token：自己随便填的一串随机字符串，相当于签名盐值，用来验证回调请求来自企业微信官方。
• EncodingAESKey：用于加解密消息内容的 43 位密钥。企业微信把所有回调消息都做了 AES 加密，防止链路中被人截获篡改。

很多新手在这个环节容易犯一个低级错误：Token 和 EncodingAESKey 在后台填完之后，点“保存”时会触发一次 GET 请求来验证 URL，如果服务端还没写好验签逻辑，后台会直接提示“URL 校验失败”。这属于正常流程，不是说配置错了，只是后端的校验接口还没起来。

2.2 回调服务骨架：验签、解密、解析

企业微信的验证规则是这样的：后台会用 Token、timestamp、nonce 三个参数先做字典序排序，拼接后用 SHA1 生成签名，放在 msg_signature 参数里带给你。你需要用同样的算法算一遍，如果签名一致，说明请求确实来自企业微信，再解密 echostr 并原样返回，后台那边才会认为 URL 可用。

这一段逻辑我强烈建议直接使用官方提供的 WXBizMsgCrypt 工具类，不要自己造轮子。企业微信官方文档里给出了 Python 版本的加解密 demo，虽然写得比较粗糙，但核心算法是没问题的。你把它放在项目根目录，参考下面的代码就能接好：

from fastapi import FastAPI, Request from fastapi.responses import PlainTextResponse from WXBizMsgCrypt import WXBizMsgCrypt app = FastAPI() TOKEN = "your_token" ENCODING_AES_KEY = "your_43char_key" CORP_ID = "your_corp_id" crypt = WXBizMsgCrypt(TOKEN, ENCODING_AES_KEY, CORP_ID) @app.get("/wecom/callback") async def verify_url(msg_signature: str, timestamp: str, nonce: str, echostr: str): # 后台保存配置时发来的是 GET 请求，返回解密后的 echostr 即可 ret, echo = crypt.VerifyURL(msg_signature, timestamp, nonce, echostr) if ret == 0: return PlainTextResponse(echo) return PlainTextResponse("verify failed")

保存成功之后，真正的消息会以 POST 请求的形式打过来，请求体是一段加密后的 XML。你需要做同样的验签和解密，然后从解出来的 XML 里读取发送人、消息类型、消息内容等字段。一个简化的 POST 处理如下：

@app.post("/wecom/callback") async def receive_message(request: Request): body = await request.body() query = request.query_params ret, xml_content = crypt.DecryptMsg( query.get("msg_signature", ""), query.get("timestamp", ""), query.get("nonce", ""), body.decode("utf-8"), ) if ret != 0: return PlainTextResponse("decrypt failed") # 到这里 xml_content 是明文 XML，继续用 ElementTree 解析 # 解析出 FromUserName、MsgType、Content、AgentID 等字段 return PlainTextResponse("success")

注意解密后这里有两个不同的返回。一个是解密失败时返回错误信息给企业微信服务器，一个是成功接收后返回固定字符串 success。企业微信服务器对回调服务有超时要求，建议在回调函数里只做“接收消息”和“把消息丢进处理队列”两件事，马上返回 success。AI 生成回答比较慢，如果在回调里同步等大模型推理完再返回，很容易超时，企业微信会判定这次回调失败并重复推送，造成同一条消息被处理多次。

2.3 大模型接口接入：OpenAI 兼容协议是最大公约数

消息入口通了之后，就开始接大模型。现在国产大模型几乎都提供 OpenAI 兼容协议，接口路径、请求格式基本一致，最省力的方式就是安装官方 OpenAI SDK，然后把 base_url 指到模型服务商地址。我用的是 DeepSeek，示例大概是这样：

from openai import OpenAI import os client = OpenAI( api_key=os.getenv("DEEPSEEK_API_KEY"), base_url=os.getenv("DEEPSEEK_BASE_URL", "https://api.deepseek.com/v1"), ) def ask_llm(system_prompt: str, user_message: str) -> str: resp = client.chat.completions.create( model="deepseek-chat", messages=[ {"role": "system", "content": system_prompt}, {"role": "user", "content": user_message}, ], temperature=0.2, max_tokens=512, ) return resp.choices[0].message.content

这段代码看起来简单，但有两个细节值得展开。

温度参数直接影响客服回答的稳定性。把 temperature 调成 0.2，模型会更倾向于选择概率最高的表达，避免同一个问题每次回答都不一样。做客服场景，宁可回答偏保守，也不要时好时坏。max_tokens 建议在早期就限制住，防止模型某一轮突然放飞，生成几百字小作文刷屏。

另一个细节是 API Key 的管理。为了方便把项目部署到服务器，我在项目根目录放一个 .env 文件，然后通过 python-dotenv 加载到环境变量。千万别把 Key 写死在代码里，也别提交到 Git 仓库。群里随便一个截图、一次代码分享都可能导致 Key 泄露，被人刷爆账单。实测中我见过不止一次因为 Key 明文提交到仓库发生的意外，这属于最不值得踩的坑。

3. 把“能回复”升级成“客服”：记忆、人设、知识库

第一步能跑通时，你会有一种“我已经成功”的错觉：群里问一句，机器人能秒回。但用不了多久你就会发现，如果没有设计人设和知识库，机器人完全不像一个客服。它可能把营业时间说错，可能在客户问“多少钱”的时候编一个价格，甚至开始热情回答跟业务毫无关系的问题。所以第二阶段的重点，是让机器人变成一个“规矩的客服”。

3.1 角色设定：让 AI 只做客服，不瞎聊

客服场景和通用聊天最大的区别是，客服有明确的业务边界。我给系统提示词设计了一套模板，核心强调三件事：你是谁、你能回答什么、不能回答什么。一个实际使用的提示词大概是：

你是「某门店」的AI客服助手，你的职责是回答与门店业务相关的问题，包括营业时间、地址、预约方式、服务项目、价格范围、售后政策等。 规则： 1. 只依据提供的资料和对话历史回答，资料中没有的内容，明确告知用户“需要转人工核实”； 2. 不回答与业务无关的问题，不编造政策、价格、联系方式； 3. 不输出个人观点，不评价其他平台、机构或竞品； 4. 如果用户情绪激动或问题复杂，引导用户留下联系方式，告知人工客服会跟进； 5. 回答尽量简洁，控制在200字以内。

看到没有，关键不是让模型多聪明，而是让模型多克制。很多机器人的第一版问题不是不够聪明，而是太想回答问题。你给它一个“你是万能 AI”的设定，它就真的什么都聊，甚至客户问“帮我写一段差评”它也跟着写。在客服入口前面加上业务边界，能省掉后面大量内容审核和客诉麻烦。

另外，建议在提示词中明确要求模型不要扮演其他身份，也不要承认自己是 DeepSeek 或某个通用模型。内部叫什么不重要，客户看到的是一个统一品牌形象。

3.2 会话记忆：用短窗口缓存撑起连续问答

客服对话通常不是一问一答，而是有上下文的多轮交互。比如客户问“你们晚上营业到几点”，你回答之后他接着问“那周末呢”，如果模型不知道你刚才说的是营业时间，这轮回答就会偏。解决方法是给模型带上最近几轮对话内容。

最轻量的方案是使用 collections.deque，固定只保留最近 6 到 8 条消息：

from collections import defaultdict, deque sessions = defaultdict(lambda: deque(maxlen=8)) def build_messages(user_id: str, new_text: str): history = list(sessions[user_id]) sessions[user_id].append({"role": "user", "content": new_text}) messages = [{"role": "system", "content": SYSTEM_PROMPT}] for item in history: messages.append(item) messages.append({"role": "user", "content": new_text}) return messages

注意，单机用 deque 没问题，但如果服务起了多个副本，内存态 session 是不共享的，同一个人两次请求可能打到不同实例上，上下文就丢了。部署到正式环境时，建议把 session 放到 Redis，key 用 wecom:session:{user_id}，value 存最近几轮对话的 JSON，并设置过期时间。我的选择是保留 2 小时，超过两小时的会话直接归零，重新开始。

这里还有一个 Token 成本问题。如果每轮都把 8 条历史全发给模型，长时间聊下来上下文会越来越长，回答越来越慢，费用也越来越高。客服场景不需要长记忆，它只需要记得“上一件事聊到哪”就行。控制窗口长度，本质上是在控制成本，也是在控制响应延迟。

3.3 RAG 知识库：常见问题不再是靠模型瞎编

大模型知道的公共知识很丰富，但对你的门店、产品、售后政策一无所知。最开始我们把常见问题整理成一份文档塞进提示词里，但提示词长度有限，不能覆盖几百个问题。更好的做法是引入一个轻量级 RAG：先把高频问答切片向量化存到本地向量库，客户提问时先检索出最相关的 3 条 FAQ，再拼入提示词让模型基于这些资料回答。

我用的是 sentence-transformer 做文本转向量，用 Chroma 做向量存储。流程很简单：

import chromadb from chromadb.utils import embedding_functions embed_fn = embedding_functions.SentenceTransformerEmbeddingFunction( model_name="BAAI/bge-small-zh-v1.5" ) client = chromadb.PersistentClient(path="./faq_db") collection = client.get_or_create_collection( name="faq", embedding_function=embed_fn, metadata={"hnsw:space": "cosine"}, )

第一次上线前，写一个脚本把 FAQ 批量灌进去。每条 FAQ 的内容我建议写成“问题 + 标准回复”的形式，向量化时同时考虑问题语义和回答内容，检索效果比只放问题好很多。用户提问进来后，检索到最相关的几条资料，再把资料文本拼进提示词：

def ask_with_faq(user_message: str, user_id: str): hits = collection.query(query_texts=[user_message], n_results=3) docs = hits["documents"][0] context = "\n\n".join(docs) user_prompt = ( f"以下是内部资料：\n{context}\n\n" f"用户问题：{user_message}\n" "请优先根据上述资料回答，资料不足时明确说需要转人工。" ) # 继续调用 ask_llm，传入 user_prompt

实测下来，加了这层知识库之后，机器人的专业度会从“像一个实习生”变成“像一个做过员工培训的老客服”。知识库最大的好处是改起来方便。门店明天调整营业时间，你不需要改代码，只需要改一条 FAQ 文档，重新灌入库即可。运营人员完全可以自己维护知识库内容。

4. 消息收发的完整实现细节

到这里，核心对话逻辑已经可用了。但要让机器人真正在企业微信里工作，还需要处理 access_token、消息类型区分、群聊触发、部署持久化等工程细节。这一章虽然不性感的，但上线后稳定不稳定，全看这些细节做得到不到位。

4.1 access_token 缓存与主动回复

企业微信大部分 API 都需要 access_token。这个 token 的获取方式是调用 gettoken 接口，传入 corpid 和 secret。调用频率理论上没有严格限制，但有有效期，默认两小时过期，而且获取 token 的接口本身有一定开销，不能每次都现取现用。我建议做一个简单的缓存函数：

import time import requests _cache = {"token": "", "expire_at": 0} def get_access_token(): now = time.time() if _cache["token"] and now < _cache["expire_at"]: return _cache["token"] url = "https://qyapi.weixin.qq.com/cgi-bin/gettoken" params = {"corpid": CORP_ID, "corpsecret": APP_SECRET} resp = requests.get(url, params=params, timeout=3).json() if resp.get("errcode") != 0: raise RuntimeError(f"get token failed: {resp}") _cache["token"] = resp["access_token"] _cache["expire_at"] = now + resp["expires_in"] - 300 return _cache["token"]

提前五分钟左右刷新 token 是常规做法，避免边缘情况下 token 刚失效导致请求失败。如果服务是多实例部署，进程内缓存会各自取 token，虽然不至于出错但会产生冗余调用。规模大了可以放到 Redis 统一管理，单机场景用上面的内存缓存就足够了。

获取 token 之后，主动给用户发消息要走 message/send 接口。我们需要传入 touser、msgtype、agentid 和文本内容。特别注意 agentid 必须填应用自己的 AgentId，用错会出现无权限或消息发不出去的错误。

4.2 单聊、群聊、@触发的消息分类处理

回调收到一条消息后，首先要判断它来自哪里。企业微信回调的 XML 里有 FromUserName、ToUserName、AgentID 等字段，但从 XML 本身不一定能直接区分是单聊还是群聊，还需要结合消息事件类型。项目中最常见的情况是：企业微信应用配置了接收消息后，成员在单聊窗口给应用发消息；在群聊里把应用机器人拉进去后，成员 @ 机器人发消息也能触发事件。

我的处理策略是写一个 message_router，先根据消息来源和内容决定要不要触发 AI：

• 单聊消息：默认全部进入 AI 客服流程，因为用户主动来找应用，意图很明确。
• 群聊消息：只处理包含 @机器人 或者以“客服”“小助手”开头的消息，避免机器人把群里所有人聊天的内容都接走。
• 非文本消息：图片、语音、视频等先不做识别，给一个固定提示：“当前暂时只支持文字提问，或者请转人工”。
• 判断是否是发给自己的消息：有些 SDK 解析群消息时会带上 @ 信息，你需要确认文本里是否包含机器人的名字。不同版本的企微回调格式有点差异，上线前可以用一个测试群反复验证。

回调响应要非常快。不要在 POST 接口里直接调用大模型接口，因为大模型生成可能需要两三秒甚至更久，企业微信服务器在等待响应期间容易超时重试。我把处理函数做成异步任务，收到了消息先返回 success，然后在后台线程里执行 AI 对话和消息回复。这样既避免重复推送，也让用户感觉响应速度更快。为了避免多线程并发问题，初始化一个线程池来跑后台任务是更稳妥的选择。

4.3 部署到服务器：用 systemd 托管进程

开发环境跑通以后，下一步就是把代码放到云服务器上。Uvicorn 进程本身管理比较简单，但为了让服务在重启后自动拉起，我一般用 systemd 托管。

项目放到 /opt/wecom-ai 目录下，服务文件放在 /etc/systemd/system/wecom-ai.service：

[Unit] Description=WeCom AI Bot Service After=network.target [Service] WorkingDirectory=/opt/wecom-ai EnvironmentFile=/opt/wecom-ai/.env ExecStart=/usr/bin/python3 -m uvicorn main:app --host 0.0.0.0 --port 8000 Restart=always RestartSec=3 [Install] WantedBy=multi-user.target

启动后执行 systemctl daemon-reload、systemctl enable wecom-ai、systemctl start wecom-ai，然后通过 tail -f 查看日志确认服务正常监听。需要注意 EnvironmentFile 指定的 .env 文件路径，systemd 在启动进程前会先加载里面的环境变量，这样代码里 os.getenv 才能拿到配置。

服务器前面的域名和 HTTPS 证书必须要配好。企业微信后台填写的回调 URL 必须是 HTTPS，不能用裸 IP。我的实践是 Nginx 监听 443，配置证书后把 /wecom/callback 路径代理到本机 8000 端口。Nginx 配置里把 client_max_body_size 调大一点点以防万一，其他默认配置就行。

部署完成后做一次全链路冒烟测试：添加机器人到测试群，发送一条问题，观察日志中是否能收到回调、是否能打印出解密后的文本、是否调用大模型、是否成功回复。任何一个环节没出现你都不要继续加功能，先把链路补齐再说。

5. 上线后一定会遇到的各种坑

这一章是全篇里面含金量最高的部分，因为这些问题全都不是我预先想出来的，是在真机调试、试运行中一个个踩出来并解决的。提前写在这里，能帮你省掉不少无意义的排查时间。

5.1 回调验证失败和消息丢失的排查清单

回调类问题有一个特别讨厌的地方：错误信息不直观，你不知道是企业微信没发过来，还是发过来了服务没收到，又或者收到了但解密失败。遇到这种情况，我习惯用一张表格逐项排查：

特别要提醒的是 Webhook 机器人和“能收消息的机器人”不是同一种东西。很多人理解的是群机器人 Webhook 地址，那个只能往群里推消息，不能接收群里的提问，更没法做交互问答。真正做 AI 客服必须依赖接收消息服务器配置，让企业微信把群里的消息事件回调给你的后端。如果只是接了个 Webhook，你只能单向通知，无法实现双向对话。

我的排查习惯是，在服务入口处打一行日志，把收到的原始 body 全量打印出来。别看这行日志简单，它能帮你确认三种情况：消息到底有没有到服务、原始格式是什么样、解密前和解密后的数据差在哪。生产环境注意脱敏，日志里不要把客户手机号一类敏感信息全量打出来，只保留必要的 user_id 和消息内容。

5.2 机器人“很爱说”和“胡说八道”的处理

第二阶段最常遇到的投诉是：机器人话太多、口吻不像客服、回答内容看着有道理但其实是编的。这些问题虽然表现在输出端，但根因往往在输入端和参数设计上。

解决话痨问题的第一招是调低 temperature。我最终稳定在 0.2，几乎不再出现情绪化的多余表达。如果还是话多，就在系统提示词里明确“总字数控制在100字以内，不要使用感叹号，不需要寒暄”。这比通用 Prompt 直接“请简洁回答”有效得多。

解决胡说八道的核心是知识库兜底。我模拟过一类极端场景：资料库里根本没有某条政策，客服机器人却根据公开网络的类似政策编了一个答案，用户照着操作后产生了损失。后来我给知识库加了“兜底判定”：如果检索结果相似度低于某个阈值，不直接回答，只回复统一话术——“这个问题我需要核实后才能答复，已帮你记录，稍后转人工跟进”。检索相似度阈值推荐设置在 0.35 到 0.5 之间，不同向量模型阈值有差异，要凭真实问题做一次校准。

5.3 并发消息、限流与人工兜底

上线后流量一旦起来，会同时遇到三类问题：并发调用大模型速度变慢、单用户刷屏导致成本失控、以及 AI 无论如何都处理不了的特殊情况。

并发问题在早期没有那么夸张，但一个百人活跃群里同时有两三个人提问时，如果每个请求都同步等待大模型响应，后面的提问就会排队越来越久。我的做法是用线程池限制并发，比如最多同时处理 5 个大模型请求，多余的排队，同时在回调入口做限流：同一个用户在一分钟内最多发起 3 次请求，超过限制的提问直接回复模板“问题已收到，请稍等，不要连续刷屏”。设置限流的初衷不是限制用户，而是保护服务不被单个会话拖垮。

成本控制也要在这里提。模型 API 按 Token 计费，有些对话如果上下文很长，一次请求就可能烧掉几千 token。在客服场景里，单次回答的 max_tokens 我压到 512，上下文只保留 8 条以内的消息，这样单次请求整体消耗可控。上线后第二天看一次日志里的 token 消耗统计，用“平均每问消耗 token 数 x 每天问题数”算一下日成本。如果超出预算，优先把最高频的 50 个问题固化到知识库，让 AI 不经过大模型也能命中的就纯检索回复，减少调用次数。

人工兜底是客服 AI 绝对不能省略的一环。我在知识库里建了一个“转人工”规则，当用户明确表达“投诉”“退款不满意”“找真人”“人工客服”时，机器人不继续硬答，而是自动回复“已为你登记，客服会在 30 分钟内联系你”，同时把该会话标记为重点事件。宁可让机器人少回答，也不能让客户觉得被一个不存在的人工客服晾着。上线期间我用一个共享表格记录每天“转人工清单”，每周复盘，看看哪些需求应该被补充进知识库，哪些处理逻辑还需要改进。

6. 从单群客服到可复用对话服务的一点经验

项目跑通到现在，最明显的感受是：这类微信群AI自助客服的价值不在于“AI 有多聪明”，而在于把高频重复问题挡在人工客服前面，让人有时间处理真正复杂和紧急的事情。我朋友那个六百人群，上线一周后粗略统计，大约 70% 的常规问题都由机器人直接消化掉了，剩下 30% 转人工后基本都能快速解决。这个比例对早期版本来说已经相当理想。

如果让我重新做一遍，我会把项目拆分得更清晰：消息接入是一个独立模块，对话引擎是另一个独立模块，知识库维护再单独拆出来。这样做的好处是，之后接公众号、小程序客服、网页客服时，只需要替换接入模块，AI 对话引擎和知识库可以直接复用，不用重写。我甚至觉得后续可以给每个客户的知识库建一个独立 collection，然后通过一个简单的管理后台让运营人员在线增删 FAQ，不用每次改代码。

最后再分享一个运维层面的小技巧。上线最初几天，不要只看“回答正确率”，要看“哪些问题被转人工了”。转人工的问题清单就是知识库迭代和模型提示词改进的最佳素材。把这些问题按出现频次排序，高频的补进 FAQ，低频但重要的设置关键词兜底提示，连续迭代两周之后，机器人的能力和稳定性会有一个肉眼可见的提升。这个过程没有高深算法，就是踏踏实实把运营闭环跑起来。如果你正打算做同类项目，希望这篇记录能帮你少走几天弯路，把宝贵的时间花在真正有价值的业务问题上。