DeepSeek接入QQ群机器人：NoneBot2+OneBot 11保姆级教程

想让 QQ 群里有一个能聊天的 DeepSeek 机器人，听起来很简单：申请一个 API Key，写几行代码，把机器人拉进群，不就行了？

真做起来你会发现，大部分时间不是在调模型，而是在和设备登录、消息事件、WebSocket 断连、上下文串群、风控提示作斗争。从社区反馈和技术群里的讨论看，大家最深的体感是同一个：DeepSeek 本身的调用并不难，难的是把“QQ 的消息”和“大模型的回复”这两条链路稳定地接到一起。

这篇保姆级教学，就是要把这条链路拆开讲清楚。我会用 NoneBot2 + OneBot 11 协议端 + DeepSeek API 这套目前社区最主流、资料也最多的方案，带你从环境准备开始，一步步跑通一个最小可用的 QQ 群机器人，再补充上下文记忆、AT 触发、常见报错排查和生产环境建议。读完你应该能具备独立搭建和排错的能力，而不是只拿到一段复制粘贴就跑不起来的代码。

1. 这篇文章真正要解决的问题

1.1 为什么最近这么多人想把 DeepSeek 接进 QQ

QQ 是国内用户量最大的即时通讯软件之一，很多开发者的第一反应就是用 QQ 群机器人做一个“AI 助手”。DeepSeek 这种大模型刚好提供了价格低、中文效果好、API 调用门槛低的能力，两者结合以后，可以实现群内问答、知识查询、代码助手、每日推文等等场景。

但真正让这件事值得写成一篇文章的原因，不是一个“新玩法”，而是它的工程链路比大多数人预期的要长。你申请完 API Key，只是走出了第一步；后面还有协议端、机器人框架、消息事件解析、多轮上下文、并发控制、平台合规这些内容。很多新手在这条链路里卡住，不是代码写不出来，而是不知道每一步失败时该查哪里。

1.2 常见误区：接入 = 调一次 API？

很多人对“DeepSeek 接入 QQ 机器人”这件事的预期，是写一个脚本调用一下接口，然后就完事了。这里有三个最容易误导新人的误区：

第一，以为 DeepSeek 官方会提供一个“直接拉进 QQ 群的机器人”。目前并没有这样的官方产品，你需要自己搭一个程序来连接 QQ 消息和大模型。

第二，以为“接入”就是写一段调用 API 的脚本。这段脚本确实能跑，但它收不到 QQ 消息，也无法在群里自动回复。真实场景下，你需要一个常驻进程监听 QQ 事件，再在事件里调用模型，最后通过协议端把回复内容发回群里。

第三，以为把机器人拉进群就完成了权限配置。实际上消息能不能被监听、要不要在群里 @ 才能触发，这些都是需要代码里显式处理的。

1.3 核心架构：三段式

整条链路可以拆成三段：

• 消息接入层：负责登录 QQ 账号、接收消息、发送消息。常见方案有 NapCat、Lagrange、LLOneBot 等项目，它们把 QQ 客户端能力封装成标准协议。
• 业务逻辑层：负责处理消息事件、判断触发条件、管理会话状态。这里用 NoneBot2 这类机器人框架最方便。
• 模型调用层：负责把消息文本组装成 Prompt，调用 DeepSeek API，拿到回复后交回给业务层。

把这三段分开看，问题定位就会清晰很多。消息没收到，问题大概率在接入层；回复延迟，问题可能在网络或模型层；回错了对象，问题通常在业务层的群聊隔离逻辑。

1.4 这篇文章适合谁

适合：会用命令行、能写一点 Python、想在 QQ 群里跑一个 AI 机器人的开发者；以及想快速验证 DeepSeek API 能力、又不想自己从零写通信协议的人。

不适合：完全不会 Python 和命令行操作的小白，需要先补基础；以及希望零代码、完全不看技术原理就能跑起来的人。这篇文章的目标是让你真正理解链路，而不是拿一个“一键脚本”糊弄过去。

2. 基础概念与核心原理

2.1 DeepSeek API 是什么

DeepSeek 是国产大模型服务，提供了 API 调用能力。从技术角度看，它的接口兼容 OpenAI 的 Chat Completions 格式，所以你不需要额外学习新协议，可以直接用 OpenAI 的 Python SDK，只需要改 Base URL 和 API Key。

一个最基础的 API 调用过程是这样：

from openai import OpenAI client = OpenAI( api_key="你的_deepseek_api_key", base_url="https://api.deepseek.com" # 以官方控制台提供为准 ) resp = client.chat.completions.create( model="deepseek-chat", # 模型名以官方控制台为准 messages=[ {"role": "system", "content": "你是一个乐于助人的群聊助手"}, {"role": "user", "content": "用三句话介绍你自己"}, ] ) print(resp.choices[0].message.content)

这段代码最值得注意的地方是：API Key 等同于账号的访问凭证，要像密码一样保管，不要提交到公开仓库，更不要写在会被群成员看到的配置里。如果 Key 泄露，别人就能用你的账号调用模型，产生费用和合规风险。

2.2 QQ 机器人的接入方式

QQ 机器人有两种主流的接入思路。

官方思路是通过 QQ 开放平台申请官方机器人，它支持群聊和私聊，但审核、类目、接口权限都有要求，适合做正式上线的服务。

社区思路是使用协议端程序，用一个 QQ 账号模拟客户端登录，再通过标准协议对外提供消息收发能力。常见工具有 NapCat、Lagrange、LLOneBot，早期还有 go-cqhttp，但 go-cqhttp 停更之后，社区推荐逐渐转向了仍在维护的项目。这类方案胜在灵活、可以自己控制逻辑，但也要认真对待账号安全和平台规则。

OneBot 11 是社区里通用的消息协议规范，它定义了消息的 JSON 格式、事件类型和 HTTP/WebSocket 通信方式。无论你选哪个协议端，只要它支持 OneBot 11，就可以对接同一个机器人框架。

2.3 NoneBot2 是什么

NoneBot2 是一个基于 Python 的事件驱动机器人框架。它本身不直接连接 QQ，而是通过适配器连接不同的消息平台。所谓适配器，就是把 OneBot 协议里的事件数据转换成框架统一的事件对象。

开发时你不需要关心底层 WebSocket 怎么收发消息，只需要写插件：监听某个事件，然后执行逻辑。这也是它适合做 DeepSeek 接入的原因：模型调用逻辑完全可以在插件里实现，改起来非常快。相比自己写 WebSocket 客户端去解析 JSON 事件，NoneBot2 把最繁琐的部分都封装掉了。

2.4 一次完整的数据流

一条消息从发出到模型回复，实际经过的路径如下：

QQ 群消息 -> 协议端捕获，转成 OneBot 事件 -> NoneBot2 适配器解析，交给插件 -> 插件调用 DeepSeek API -> 拿到回复，调用协议端发送 API -> QQ 群里显示回复

理解这个数据流之后，你就能明白为什么很多故障排查不是看 DeepSeek，而是先看链路哪一段断了。后面遇到问题时，我会反复强调“当前卡在哪一段”。

3. 方案选型与账号准备

3.1 三种主流通用方案对比

方案	技术栈	适合人群	优点	缺点
NoneBot2 + OneBot 11 协议端	Python	会 Python，想深度控制逻辑	生态丰富、结构清晰、插件可复用	初始配置略多
Koishi	Node.js	前端开发者	内置控制台、插件管理方便	需要 Node 环境
低代码平台	图形界面	非开发者	上手快	定制能力受限

对大多数开发者来说，NoneBot2 是更稳的选择。它文档全、社区大、遇到问题容易搜到答案，而且插件机制以后还可以接入钉钉、飞书等多个平台。

3.2 为什么选用 NoneBot2 + NapCat 组合

NapCat 作为 OneBot 11 协议端，保持了较高活跃度，安装方式也提供了普通客户端和容器化等选择。NoneBot2 负责业务逻辑，NapCat 负责 QQ 登录和消息收发，两者通过 WebSocket 通信，逻辑边界非常清楚。

这套组合的主要优势是：任何一个部分换掉都不影响整体思路。就算以后 NapCat 不能用了，你仍然可以用兼容 OneBot 11 的其他协议端替换，业务代码不需要大规模改动。从工程角度讲，这种“接口稳定、实现可替换”的设计就是它最大的价值。

3.3 账号准备与风险提示

你需要准备一个能正常登录的 QQ 账号。考虑到机器人可能处于高频运行状态，建议使用专用账号，不要直接用个人主号。同时在正式使用前，先小范围测试群观察账号状态。如果遇到平台提示异常，优先降低发送频率、避免群发、暂停机器人，检查是否触发了频率限制。

这里必须强调：任何基于社区协议端的接入方式都存在账号风险，实际使用请遵守平台规则和法律法规，合理控制频率和内容。本文只讲技术实现，不鼓励任何滥用行为。

4. 环境准备与前置条件

4.1 运行环境

本文的示例基于 Windows / macOS / Linux 都能运行。核心要求是能安装 Python 3.10 或更高版本，并能正常安装 pip 包。如果你在服务器上部署，建议用 Linux + systemd 或 Docker；如果只是本机体验，Windows 也可以先跑通。

正文代码以通用命令为主，不限定具体版本。如果你的 Python 版本较老，建议先升级到 3.10+，因为新版本框架对旧 Python 的支持越来越弱。

4.2 安装 Python 与依赖管理

这里推荐使用uv或纯pip。先说最简单的 pip 方式。

python -m pip install --upgrade pip python -m pip install nb-cli

nb-cli是 NoneBot2 的命令行工具，装好之后可以用它快速创建项目、安装适配器和启动项目。

如果你想先手动安装核心库，也可以执行：

python -m pip install nonebot2 nonebot-adapter-onebot python -m pip install openai

4.3 创建项目

最推荐的做法是用nb create创建标准项目。它会生成pyproject.toml、.env、src/plugins等结构。

nb create

命令执行后，按提示选择驱动、适配器。适配器选择 OneBot V11，驱动建议选择 FastAPI + httpx + websockets 的组合。如果你熟悉编辑器，也可以手动创建目录，核心文件只需要三个：bot.py、.env、plugins/。

4.4 获取 DeepSeek API Key

到 DeepSeek 开放平台注册账号，进入控制台创建 API Key。创建后把 Key 复制下来，保存到本地。注意：Key 只会在创建时完整显示一次，遗失后需要重新创建。

在开始写代码前，先用一个最小请求验证 Key 是否可用。直接运行第 2.1 节的最小示例，能正常打印内容，说明 API Key 和环境没问题。如果这一步就报错，请先解决它再继续，否则后面全串起来会非常难排查。

5. 完整实操：从零跑通

这一章我们真正开始接线。目标很简单：在 QQ 群里 @ 机器人，它调用 DeepSeek，回复到群里。

5.1 安装并启动协议端

协议端是 QQ 账号和机器人框架之间的桥梁。你需要下载并安装支持 OneBot 11 的协议端（推荐 NapCat）。安装完成后，在它的配置中找到 OneBot 11 的连接方式，建议使用反向 WebSocket：先启动 NoneBot2，让 NoneBot2 监听 8080 端口，然后让协议端主动连接ws://127.0.0.1:8080/onebot/v11/ws。

不同协议端版本界面差异较大，这里不展开具体截图。重点是记住原理：协议端负责把 QQ 消息包装成 OneBot 事件，并通过 WebSocket 发给 NoneBot2。连接配置成功后，先不要扫码登录，等 NoneBot2 启动后再登录。

5.2 编写 NoneBot2 入口文件

如果你的项目是用nb create生成的，项目根目录下通常有一个bot.py。这个文件是框架的入口，它启动了 NoneBot2 进程。一个标准入口文件不需要写太多逻辑，插件里的代码会自动被加载。

# 文件路径：bot.py from nonebot import get_driver driver = get_driver() @driver.on_startup async def startup(): print("NoneBot2 启动完成，等待 QQ 消息事件")

如果你用的是最小手动方式创建，这个入口文件也能直接使用。但注意，标准插件写法不需要把所有代码都堆在bot.py里，更推荐放到src/plugins下，这样每个插件独立一个目录，维护成本低很多。

5.3 配置 .env

在项目根目录创建.env，内容如下：

DRIVER=~fastapi+~httpx+~websockets HOST=127.0.0.1 PORT=8080 DEEPSEEK_API_KEY=sk-你的key DEEPSEEK_BASE_URL=https://api.deepseek.com DEEPSEEK_MODEL=deepseek-chat

DRIVER决定了 NoneBot2 支持哪些通信能力。~fastapi提供服务器能力，~httpx提供发起 HTTP 请求能力，~websockets让 NoneBot2 既能连接 WebSocket，也能启动 WebSocket 服务端。PORT要和协议端的连接地址保持一致，如果改了端口，协议端那边的 WebSocket 地址也要同步修改。

5.4 编写 DeepSeek 插件

在src/plugins/chat_deepseek/目录下创建__init__.py。

# 文件路径：src/plugins/chat_deepseek/__init__.py import os from nonebot import on_message from nonebot.adapters.onebot.v11 import Bot, MessageEvent from openai import OpenAI client = OpenAI( api_key=os.getenv("DEEPSEEK_API_KEY", ""), base_url=os.getenv("DEEPSEEK_BASE_URL", "https://api.deepseek.com"), ) chat = on_message(priority=10, block=False) @chat.handle() async def handle_deepseek(bot: Bot, event: MessageEvent): text = event.get_plaintext().strip() if not text: return # 先只在私聊场景回复，保证最小链路 if event.message_type == "group": return try: resp = client.chat.completions.create( model=os.getenv("DEEPSEEK_MODEL", "deepseek-chat"), messages=[ {"role": "system", "content": "你是一个由 DeepSeek 驱动的 QQ 机器人助手，回答简洁准确。"}, {"role": "user", "content": text}, ], timeout=30, ) reply = resp.choices[0].message.content except Exception as e: reply = f"调用 DeepSeek API 失败：{e}" await chat.finish(reply)

这个插件只处理私聊场景，群聊先不回复。这样做的原因是先把最小链路跑通等链路通了，再改成群聊 @ 触发，不然出了问题很难分清是模型调用问题还是群消息触发问题。

5.5 启动和验证

启动 NoneBot2：

nb run

正常情况下你会在终端看到类似日志：驱动模块加载完成、适配器注册成功、WebSocket 服务监听在 8080 端口。

然后再启动协议端并扫码登录。连接建立后，终端会打印一条连接成功的日志。此时给机器人发一条私聊消息，例如“你好”，它应该会调用 DeepSeek 并回复。如果这一步通了，你的第一个 DeepSeek QQ 机器人就跑通了。

6. 增强示例：群聊 AT 触发与上下文记忆

最小闭环跑通后，你可以继续扩展两个高频需求：群聊 AT 触发和多轮上下文记忆。

6.1 群聊 AT 触发

在群聊场景里，最常见的要求是“只有被 @ 时才回复”，避免机器人每一条群消息都调用 API，既费钱又打扰别人。

你可以使用 OneBot V11 消息事件里的event.to_me来判断消息是否提到机器人，或者自己解析消息段中的at类型。

from nonebot.adapters.onebot.v11 import MessageEvent @chat.handle() async def handle_deepseek(bot: Bot, event: MessageEvent): text = event.get_plaintext().strip() if not text: return if event.message_type == "group": # 只有被 @ 时才响应 if not event.to_me: return # 去掉 @ 后的纯文本 text = text.replace("机器人", "", 1).strip()

这里event.to_me是 NoneBot2 适配器已经帮你解析好的字段。当消息内容包含 @ 机器人，或者回复了机器人时，它都会为 True。这个判断逻辑能避免机器人被群里的普通聊天频繁“误唤醒”。

6.2 简单的多轮上下文记忆

大模型是无状态的，每次调用都要把所有上下文重新传给 API。你可以用一个全局字典，按“用户 ID + 群 ID”作为 session key，保存最近几轮消息。

from collections import deque # session_key -> deque(maxlen=8) sessions = {} @chat.handle() async def handle_deepseek(bot: Bot, event: MessageEvent): text = event.get_plaintext().strip() if not text: return # 构造 session key，群聊用 group_id，私聊用 user_id if event.message_type == "group": session_key = f"group_{event.group_id}_user_{event.user_id}" else: session_key = f"private_{event.user_id}" if session_key not in sessions: sessions[session_key] = deque(maxlen=8) history = sessions[session_key] history.append({"role": "user", "content": text}) messages = [{"role": "system", "content": "你是 DeepSeek 驱动的 QQ 机器人助手。"}] messages.extend(history) try: resp = client.chat.completions.create( model=os.getenv("DEEPSEEK_MODEL", "deepseek-chat"), messages=messages, timeout=30, ) reply = resp.choices[0].message.content except Exception as e: reply = f"调用 DeepSeek API 失败：{e}" history.append({"role": "assistant", "content": reply}) await chat.finish(reply)

这个写法只是内存级实现，进程重启后上下文会丢失；但对个人群机器人足够了。如果你后续要做成正式服务，建议把会话存到 Redis 或数据库，并设置过期时间。

6.3 使用 HTTP 直接调用的备选方案

有些环境不便安装 OpenAI SDK，用 requests 直接调用也一样。下面是一个最小示例：

import os import requests def chat_once(text: str) -> str: resp = requests.post( os.getenv("DEEPSEEK_BASE_URL", "https://api.deepseek.com") + "/chat/completions", headers={"Authorization": f"Bearer {os.getenv('DEEPSEEK_API_KEY', '')}"}, json={ "model": os.getenv("DEEPSEEK_MODEL", "deepseek-chat"), "messages": [{"role": "user", "content": text}], }, timeout=30, ) resp.raise_for_status() return resp.json()["choices"][0]["message"]["content"]

这段代码强调一个知识点：OpenAI 兼容接口的路径是BASE_URL + /chat/completions。如果你在 URLs 拼接上出问题导致 404，优先检查 Base URL 和路径是否写对。

6.4 流式输出与长回复

QQ 消息长度有限制，过长的回复建议拆分发送，或者先说明“内容较长，我分条发送”。在插件里可以先用普通非流式请求拿完整内容，再做长度判断。

if len(reply) > 1500: reply = reply[:1500] + "\n\n（回复过长已截断，建议换个问法）"

这是最省事的处理方式。真正的流式输出需要处理 SSE 事件，代码会更复杂，对普通群聊体验提升有限，建议先不做。等机器人真正在群里稳定运行一段时间、确认有大量长文本需求，再考虑流式改造。

7. 运行结果与效果验证

7.1 预期日志

启动 NoneBot2 后，终端应能看到类似下面的日志（具体文本以你的版本为准）：

[INFO] NoneBot is initializing... [INFO] Scheduler Started [INFO] OneBot V11 Adapter loaded [INFO] __main__: NoneBot2 启动完成，等待 QQ 消息事件 [INFO] Uvicorn running on http://127.0.0.1:8080

如果看到 WebSocket 连接成功的日志，说明协议端已经连上了。如果连这些日志都没有，说明项目初始化失败，先检查环境依赖和.env配置，不要急着去查协议端。

7.2 测试步骤

建议按这个顺序测试：

1. 先私聊机器人，发送“你好”，确认能收到回复。
2. 再在群聊中 @ 机器人，确认能被触发，并且没有 AT 就不会回复。
3. 连续发送两条有上下文关联的消息（如“给我推荐一部电影”“为什么推荐这部？”），确认上下文记忆生效。
4. 故意发送空消息或只 @ 机器人，确认不会触发异常调用。

这几步测试能帮你确认：消息监听正常、模型调用正常、触发条件正常、会话隔离正常。每一步都对应一个独立的模块，后面出现问题可以直接按阶段定位。

7.3 如何判断成功与失败

判断成功最直接的标准是：QQ 端收到模型回复，且终端没有打印明显异常栈。如果终端打印了异常，就照着异常信息去查。

如果没有任何回复，优先看两条日志：协议端是否显示消息已上报；NoneBot2 是否打印了收到事件。通过日志能快速缩小问题范围。这也是我把“日志”放到这么靠前的原因——接入 DeepSeek 本身容易，链路排错才是真正考验工程能力的地方。

8. 常见问题与排查思路

问题现象	可能原因	排查方式	解决方案
协议端登录失败或扫码后掉线	账号状态异常、网络环境异常	查看协议端日志、确认账号可正常登录官方客户端	使用常用设备网络，遵守平台规则，必要时暂停机器人并人工登录验证
机器人完全不回复	协议端未连接 NoneBot2、监听端口不一致	检查 NoneBot2 终端日志和协议端连接状态	统一 WebSocket 地址与端口，重启两边进程
只有群聊不回复	插件里限制了群聊事件	检查event.message_type分支与to_me条件	改为“群聊时检查 AT 后回复”
API 返回 401	API Key 错误或未正确读取环境变量	打印api_key前几位，确认 .env 路径正确	重新复制 Key，重启服务
API 返回 400 / 404	模型名错误、Base URL 路径错误	查看响应 body、比对官方文档	使用控制台提供的正确模型名和 Base URL
请求一直超时	网络不稳定、上下文过长	查看请求耗时、减少 messages 轮数	缩短历史轮数，增加 timeout，重试一次
使用 deepseek-reasoner 时流式报错	未把历史 reasoning_content 传回	报错信息提示reasoning_content ... must be passed back	检查多轮上下文是否保留并传回 thinking 内容，或改用非流式模式
上下文串群 / 串用户	全局字典没有按会话隔离	检查 session_key 生成逻辑	统一用 group_id + user_id 拼接 key

上面表格里，最容易被忽略的是最后两种情况。尤其是 reasoning 模型的流式调用，如果你自己管理多轮上下文，经验是：把返回对象原样保存到历史里，不要只保存content字段，这样大概率能避开这类问题。

9. 最佳实践与工程建议

9.1 API Key 管理

不要把 Key 写在插件代码或提交到 Git 仓库。推荐用环境变量、.env文件或密钥管理服务。至少要做到：.env加入.gitignore，日志里不打印完整 Key。如果你用 Docker 部署，可以通过环境变量注入，避免把 Key 写进镜像。

9.2 成本控制与限流

DeepSeek API 是按 token 计费的。群聊是典型的高频场景，如果每个群成员都能随意触发，一个群一天产生的费用可能超出预期。建议在插件层做三层控制：

• 频率限制：同一用户 30 秒内只能触发一次。
• 长度限制：消息过长时截断或提示。
• 白名单：只在测试群开放，正式环境先小范围试点。

这三层并不复杂，但对长期运行帮助很大。不要等账单出来才后悔，前期把这几个限制加上，后面会省很多事。

9.3 人设与 Prompt 设计

群聊场景的 Prompt 和通用聊天不太一样。群里消息碎片化、多人并行提问，建议在 system prompt 里写清楚“你是谁”“回答风格”“遇到不确定内容怎么办”。例如：

你是 QQ 群里的 AI 助手“小深”，回答要友好、简洁，单次回复不超过 500 字。如果用户的问题涉及隐私、违法或平台禁止的内容，礼貌拒绝并建议咨询专业人士。

好的 system prompt 能显著提升群聊体验，也能减少 API 浪费。群成员不会喜欢一个每次回答都写一千字论文的机器人。

9.4 多群隔离与数据安全

如果机器人同时服务多个群，务必按群隔离上下文，避免 A 群的问题在 B 群被“回忆”出来。所有发往大模型的文本都可能被服务方记录，不要在 Prompt 里放入密码、身份证号、密钥等敏感信息。如果必须处理用户隐私，应做脱敏。

对于企业场景，更稳妥的做法是：不把真实用户名和手机号传给模型，用匿名 ID 代替；敏感操作不做自动化回复，只提示人工介入。

9.5 稳定性与监控

个人机器人可以接受重启，但线上服务不能。建议用 systemd 或 Docker 让 NoneBot2 常驻，并设置自动重启。日志按天滚动，方便回溯。机器人不回复时，加一个简单的健康检查接口或定时消息，确保模型链路是活的。

如果你用的是 Linux 服务器，可以写一个 systemd service 文件，把nb run托管给 systemd，加Restart=always，这样进程挂了会自动拉起。

9.6 升级与维护

协议端和框架版本都会迭代，不要长期停在旧版本上。升级前先备份配置，注意协议端大版本更新后，OneBot 连接地址和事件字段可能变化。不要迷信“某个版本最稳”，适配你的真实版本才是关键。

升级后第一件事是先跑一遍第 7.2 节的四步测试，确认核心链路没有断。如果出现新报错，优先去对应项目的 GitHub Issues 和文档里搜错误码。

10. 总结与后续学习方向

这篇文章的核心不是教你怎么调用一次 DeepSeek API，而是帮你建立“消息接入层 + 业务逻辑层 + 模型调用层”的三段式思维。跑通最小闭环后，你已经掌握了 DeepSeek 接入 QQ 机器人的完整链路，后续所有复杂功能都是在这条链路上叠加。

下一步，建议从三个方向继续深入：一是把会话存储从内存迁移到 Redis，解决重启丢上下文的问题；二是研究 DeepSeek 的函数调用能力，让机器人可以查询天气、查数据库、执行简单任务；三是给机器人加一个 Web 管理面板，方便查看日志、调整人设和统计用量。

最后给你一个实用建议：先把“只回复私聊”的最小版本跑通，再逐步开放群聊、上下文、流式。每次只改一个变量，出问题就能立刻定位。这样即使以后协议端换了、模型换了、平台规则调整了，你都能快速适配，而不是推倒重来。