返回博客
WeChatAI AgentGroup BotImage GenerationNbility

微信群 AI 助手搭建思路：群聊答疑、总结、图片生成

第十七篇 AI Agent 上手系列：梳理微信群 AI 助手的三种接入路线，设计群聊答疑、定时总结、图片生成、权限、日志和成本控制。

微信群 AI 助手搭建思路：群聊答疑、总结、图片生成

很多人想把 AI 放进微信群，第一反应是：“能不能像 Telegram Bot 一样，直接创建一个机器人，拉进群就能用？”

现实里，微信生态没有这么简单。普通微信群、企业微信群、公众号、企微应用、Webhook 机器人的能力边界都不一样。如果一开始没有分清入口，很容易写出一个看起来能跑、实际上不稳定、容易打扰群友、也有封号或合规风险的方案。

这篇文章不鼓励你做刷屏机器人，也不建议把个人微信号拿去做高频自动化。我们更现实地讨论：如果你确实想做一个微信群 AI 助手，应该如何设计入口、触发方式、上下文、群总结、图片生成、权限和成本控制。

封面：微信群 AI 助手

先说结论：不要默认监听所有消息

微信群 AI 助手最容易失败的原因，不是模型不够聪明，而是“太吵”。

推荐默认策略：

  • 群聊答疑：只在 @机器人、/ask、问一下 等明确触发时响应；
  • 群总结：按时间窗口定时触发，比如每天 20:00，总结前一天或当天消息；
  • 图片生成：必须用显式命令触发，比如 /draw 一只橘猫在写代码；
  • 管理命令：只有管理员能开关总结、设置白名单、调整预算；
  • 日志：保存必要的消息片段和调用记录，但设置保留期限。

这套规则比“机器人很聪明”更重要。群聊环境是多人空间，AI 的第一目标应该是少打扰、可控制、可追溯。

三种接入路线

微信群 AI 助手架构

路线一：企业微信群机器人 Webhook

企业微信群机器人是官方文档里最清晰、最稳定的一类入口。企业微信开发者中心的“消息推送配置说明”文档写明：通过企业微信群机器人的 Webhook 地址发送 HTTP 请求，就可以向群里推送消息。

它支持的消息类型包括：

  • text 文本；
  • markdown；
  • markdown_v2；
  • image；
  • news 图文；
  • file；
  • voice；
  • template_card 模版卡片。

重要限制也要讲清楚：Webhook 机器人主要是“向群里推送消息”，不是一个完整的“读群消息 + 自动回复”的双向聊天机器人。如果你只需要每日总结推送、告警、任务提醒、生成图片后推送到群，这条路线很好；如果你要实时读取普通微信群聊天内容，就不是它的强项。

发送文本消息示例：

curl 'https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=[REDACTED]' \
  -H 'Content-Type: application/json' \
  -d '{
    "msgtype": "text",
    "text": {
      "content": "今晚 20:00 将自动发送群聊总结。"
    }
  }'

发送 Markdown：

curl 'https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=[REDACTED]' \
  -H 'Content-Type: application/json' \
  -d '{
    "msgtype": "markdown",
    "markdown": {
      "content": "## 今日群总结\n> 重点讨论：Agent 部署、模型成本、图片生成。"
    }
  }'

企业微信文档里还写到：text 内容最长不超过 2048 字节，markdown 内容最长不超过 4096 字节，内容必须是 UTF-8 编码。这意味着群总结不能无限长，应该做摘要压缩。

路线二：Wechaty / wxauto / itchat 等个人号自动化

如果你要“读取微信群消息并自动回复”，很多社区方案会提到 Wechaty、wxauto、itchat 等项目。

这类方案要特别谨慎：

  • Wechaty 是开源 Conversational RPA SDK，通过 Puppet 抽象适配不同 IM 协议；
  • wxauto 是 Windows 微信客户端自动化，README 明确写了用于 UIAutomation 技术交流学习，并提示不要用于实际生产项目或非法用途；
  • itchat 是较早的 Python 微信个人号接口，但个人号 Web 微信能力、登录稳定性和账号风险都要自己承担。

所以我的建议是：

  • 个人实验、内部低频工具：可以研究这些项目；
  • 长期生产、客服、商业场景：优先使用官方能力、企微、公众号、客服系统或合规的消息入口；
  • 不要做营销群发、骚扰、诱导关注、自动加人等高风险行为。

如果你仍然做实验，至少要做到：只监听白名单群、只响应明确触发、限频、可关闭、记录错误、不要保存敏感数据。

路线三：把微信当入口，AI 服务独立部署

最稳的工程思路是：微信层只负责收发消息，真正的 AI 能力放在独立服务里。

微信/企微入口
  -> 消息适配器
  -> FastAPI / Node.js 后端
  -> 路由器：答疑 / 总结 / 生图 / 管理命令
  -> Nbility OpenAI-compatible API
  -> 返回文本、Markdown、CDN 图片或文件

这样做有几个好处：

  • 将来可以同时接 QQ、Telegram、飞书、企业微信；
  • 模型调用、日志、预算、用户权限可以统一管理；
  • 如果微信入口不稳定，可以替换入口，不用重写 AI 逻辑；
  • 方便把群总结、图片生成、知识库问答做成独立模块。

最小可用后端：FastAPI 版本

下面是一个最小服务示例。它不绑定具体微信 SDK，只提供一个 HTTP 接口，任何入口适配器都可以把群消息转发进来。

安装依赖：

python3 -m venv .venv
source .venv/bin/activate
pip install fastapi uvicorn openai pydantic

创建 app.py：

import os
import time
from typing import Literal
from fastapi import FastAPI
from pydantic import BaseModel
from openai import OpenAI

app = FastAPI()

client = OpenAI(
    api_key=os.environ["NBILITY_API_KEY"],
    base_url="https://api.nbility.dev/v1",
)

class IncomingMessage(BaseModel):
    platform: str = "wechat"
    group_id: str
    user_id: str
    user_name: str | None = None
    text: str
    message_id: str | None = None
    timestamp: int | None = None

class BotResponse(BaseModel):
    type: Literal["none", "text"]
    content: str = ""

def should_reply(msg: IncomingMessage) -> bool:
    text = msg.text.strip()
    return text.startswith("/ask ") or "@AI助手" in text

@app.post("/wechat/message", response_model=BotResponse)
def handle_message(msg: IncomingMessage):
    if not should_reply(msg):
        return BotResponse(type="none")

    question = msg.text.replace("@AI助手", "").replace("/ask", "", 1).strip()
    if not question:
        return BotResponse(type="text", content="请在 @AI助手 后面写上问题。")

    resp = client.chat.completions.create(
        model="gpt-4o",
        messages=[
            {"role": "system", "content": "你是微信群里的 AI 助手。回答要简洁，遇到不确定信息要说明不确定，不要编造。"},
            {"role": "user", "content": question},
        ],
        temperature=0.3,
    )
    answer = resp.choices[0].message.content or "我暂时没有生成有效回复。"
    return BotResponse(type="text", content=answer[:1200])

启动：

export NBILITY_API_KEY='[REDACTED]'
uvicorn app:app --host 0.0.0.0 --port 8787

这个后端使用 Nbility 的 OpenAI-compatible Chat Completions API：

Base URL: https://api.nbility.dev/v1
Authorization: Bearer [REDACTED]
Endpoint: POST /v1/chat/completions

它只解决“收到消息后如何判断是否回复、如何调用模型”的核心逻辑。接下来你可以用企业微信、Wechaty、wxauto 或你已有的桥接层把消息转发到 /wechat/message。

群聊答疑：只回答该回答的内容

群聊答疑建议用四层过滤：

  1. 群白名单：只有指定群启用；
  2. 触发器：必须 @、命令前缀或关键词；
  3. 频率限制：同一用户、同一群设置冷却时间；
  4. 内容边界：不回答隐私、账号、医疗、法律等高风险问题，或明确提示只供参考。

一个简单触发策略：

def route_message(text: str) -> str:
    text = text.strip()
    if text.startswith("/summary"):
        return "summary"
    if text.startswith("/draw"):
        return "image"
    if text.startswith("/ask") or "@AI助手" in text:
        return "qa"
    return "ignore"

上下文也不要无限保留。可以只取最近 20 条相关消息，并在送入模型前做脱敏：

def redact(text: str) -> str:
    import re
    text = re.sub(r"1[3-9]\d{9}", "[手机号]", text)
    text = re.sub(r"[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+", "[邮箱]", text)
    return text

群聊总结：定时、窗口、结构化输出

群总结比实时答疑更适合微信群，因为它不打断聊天。推荐按时间窗口保存消息，比如最近 24 小时、当天 0 点到现在、或管理员手动触发后的一段时间。

总结 Prompt 示例：

你是群聊总结助手。请基于以下群聊记录生成总结，要求：
1. 不编造记录中没有出现的结论；
2. 按“主要话题、已形成共识、待办事项、需要跟进的问题、值得保存的链接”输出；
3. 如果聊天内容很少，输出“今天暂无有效总结”；
4. 不要暴露手机号、邮箱、token、个人隐私。

输出格式：

## 今日群总结

### 主要话题
-

### 已形成共识
-

### 待办事项
- 负责人：事项：截止时间：

### 需要跟进的问题
-

### 值得保存的链接
-

定时任务可以用 cron、systemd timer、APScheduler 或 Hermes/Agent 的调度能力来做。关键是：如果没有足够消息，就不要强行发一篇“废话总结”。

图片生成：命令触发、结果可回溯

图片生成很适合群聊，但也最容易失控。建议只接受显式命令：

/draw 一只黑猫程序员在月光下调试服务器，赛博朋克风格

处理流程：

识别 /draw
  -> 安全检查和长度限制
  -> 调用图片生成 API
  -> 保存任务 ID、Prompt、用户、群、成本
  -> 返回 CDN 链接或图片消息

注意事项：

  • 不要让机器人自动把所有聊天内容都拿去生图；
  • 对敏感、侵权、真人肖像、政治暴力等内容做拒绝或改写；
  • 失败后最多自动重试一次；
  • 如果微信原生图片发送不稳定，可以先返回 CDN 图片链接；
  • 生图成本要单独限额，因为一次生图通常比一次短问答贵。

上线前检查清单

微信群 AI 助手上线检查

上线前至少确认：

  • 是否只在白名单群启用；
  • 是否默认不监听或不回复无关消息；
  • 是否忽略机器人自己发的消息，避免循环；
  • 是否设置每群每日预算；
  • 是否限制每个用户的频率；
  • 是否能一条命令关闭机器人；
  • 是否对日志设置保留期限；
  • 是否对图片生成、链接抓取、文件读取做权限隔离；
  • 是否能查到失败原因和模型消耗；
  • 是否明确告知群成员机器人能力和边界。

推荐的产品化模块

一个长期可维护的微信群 AI 助手，建议拆成这些模块：

adapter-wechat       # 微信/企微入口适配
router               # 命令和触发器
memory               # 最近消息窗口、群配置、用户偏好
qa                   # 群聊答疑
summary              # 定时总结
image                # 图片生成
moderation           # 安全策略与限流
billing              # 每群预算和模型消耗
admin                # 管理命令
observability        # 日志、失败原因、重试记录

最开始不用一次做完，但“触发器、限流、预算、日志”要第一天就做。它们不是锦上添花，而是防止机器人变成噪音源的基础设施。

常见问题

1. 能不能直接做普通微信群机器人？

可以实验，但要谨慎。普通微信群没有像 Telegram Bot 那样稳定开放的官方 Bot API。社区方案大多依赖个人号、客户端自动化或协议适配，稳定性、合规和账号风险都需要自己承担。

2. 企业微信群机器人能读群消息吗？

企业微信群 Webhook 机器人主要用于向群里推送消息。它适合告警、日报、总结推送、生成图片结果通知；不等同于完整的双向聊天机器人。

3. 用 Nbility 放在哪一层？

放在模型调用层。微信入口负责收发消息，你的后端负责路由和风控，Nbility 提供 OpenAI-compatible API、模型调用、日志和成本观察入口。

4. 群总结要保存所有聊天记录吗？

不建议长期保存所有原文。可以按窗口短期保存必要消息，生成总结后只保留摘要、任务、链接和必要审计日志，并设置删除周期。

5. 生图结果应该直接发图片还是发链接？

看入口稳定性。企业微信 Webhook 支持图片消息，但需要 base64 和 md5；普通微信或桥接层有时原生媒体发送不稳定。工程上可以优先返回 CDN 链接，稳定后再加原生图片发送。

参考链接

小结

微信群 AI 助手不是简单地“接一个大模型”。真正难的是入口选择、触发规则、群聊礼貌、权限、日志、预算和失败兜底。

如果你只是做通知和总结推送，企业微信 Webhook 是更稳的起点；如果你要实时读普通微信群消息，必须认真评估社区方案的稳定性和账号风险；如果你想长期做成产品，就把微信入口和 AI 服务解耦，把 Nbility 这样的 OpenAI-compatible 模型入口放在统一后端里。

相关文章

用 Nbility 跑通你的 Agent 工作流

获取 API Key，统一接入 OpenAI 兼容模型和开发工具。

管理 API Key