让LLM Bot在群聊中说人话：OneBot v11人格化工程实践-洪萨配资

1. 项目概述：为什么群聊里的 LLM bot 总是“说话不像人”？

我花了一周时间，在公司内部的 QQ 群和测试用的 Telegram 群里，搭了一个能实时响应、能接龙、能查文档、还能偶尔讲冷笑话的 LLM bot。它背后调的是 DeepSeek-V4-Pro 的 API，用的是 OneBot v11 协议标准对接消息网关，整个服务跑在一台 4C8G 的 Kylin Server v11 虚拟机上——配置不高，但足够跑通全链路。上线第一天，同事发来截图：“这 bot 回复得挺快，就是一开口我就想关群免打扰。”这句话让我盯着日志看了两小时。后来发现，真正卡住项目的从来不是 API 调不通、token 算错、或者 context window 超限这些报错；最难啃的骨头，是让 bot 的每一句话都像一个“人在群里说话”，而不是一个端坐在服务器里的 AI 模型在念说明书。

这个“不像 AI”的问题，本质是语境坍缩：LLM 原生输出是面向通用知识问答优化的，而群聊是高度碎片化、强角色感、带情绪节奏、有历史包袱的微型社会场域。你不能指望它自动理解“刚说完‘收到’，下一句就该问‘老板这个需求下周能排吗？’”，也不能指望它默认把“好的”压缩成“ok”，把“请查阅附件”软化成“我顺手扔群里了，你瞅一眼”。它不会主动识别谁是新人、谁是常驻摸鱼选手、谁发言必带表情包，更不会在连续三条“？”后自动补一句“是不是卡住了？我重发一遍”。这些不是功能缺失，而是交互范式错位——我们把一个“知识引擎”硬塞进了“社交接口”的壳子里，却没给它装上群聊世界的操作系统。

所以这篇内容不讲怎么注册 API Key、不教你怎么写 curl 请求、也不堆砌 Codex 配置第三方 API 的 YAML 示例。我要拆解的是：当你已经拿到一个能返回文本的 LLM 接口之后，如何用工程手段把它“驯化”成群聊原住民。核心关键词 LLM、bot、OneBot、v11、API 全部落在实操层：LLM 是原料，bot 是形态，OneBot v11 是协议骨架，API 是供血管道。而所有技术选择，都服务于一个目标——让 bot 的回复在群聊上下文中“自然得让人忘记它是个 bot”。适合正在做内部提效工具、学生项目、开源 bot 开发，或单纯被“AI 味太重”折磨过的开发者。如果你试过调通 API 却被用户一句“这 bot 好官方啊”劝退，那接下来的内容，就是你这一周该省下的调试时间。

2. 整体设计思路：从“API 调用器”到“群聊人格化引擎”

2.1 为什么不能直接把 API 响应原样发回群聊？

这是绝大多数新手 bot 的第一道坎。我最初版本就是这么干的：收到消息 → 拼 prompt → 调 DeepSeek API → 把 response.text 原封不动塞进 OneBot 的 send_msg 接口。结果呢？一条普通提问“今天天气咋样”，bot 回复：

根据中国气象局最新数据，北京地区今日白天晴间多云，最高气温26℃，最低气温15℃，风向为东北风2-3级，空气湿度适中，紫外线强度中等。建议外出时佩戴太阳镜，并注意补充水分。

——这根本不是群聊语言，这是气象台早间播报稿。问题出在三个层面：

信息粒度失配：群聊需要“一句话结论”，不是“完整报告”。26℃ 就够了，“紫外线强度中等”属于冗余信息。
语气结构失配：没有主语（谁说的？）、没有共情锚点（“我也刚看天气App”）、没有收尾钩子（“要带伞不？”）。
角色认知失配：bot 没有自我定位。它是同事？助理？还是那个总在茶水间讲段子的行政小哥？原样输出等于放弃角色塑造。

所以架构的第一步，是明确分层：API 层只负责“生成内容”，不负责“决定怎么发”。中间必须插入一层“群聊语义转译器”。

2.2 架构选型：为什么用 OneBot v11 + Python + Kylin Server v11？

这不是炫技，而是基于真实约束的取舍：

OneBot v11 是当前国内群聊 bot 的事实标准：QQ 官方 Bot SDK、酷Q 替代方案（如 go-cqhttp）、以及大量现成的群管理插件（如禁言、撤回监听）都深度兼容 v11。它用 HTTP POST 接收事件、用 WebSocket 推送消息，协议清晰，调试友好。相比 Telegram Bot API 的 token 管理和 webhook 配置，OneBot v11 在内网环境部署更轻量，尤其适合 Kylin Server v11 这类国产系统——Kylin v11 自带的 systemd 服务管理、firewalld 规则配置、以及对国产 CPU（如飞腾、鲲鹏）的原生支持，让服务稳定性远超在 Ubuntu 上硬凑。我试过在 Ubuntu 22.04 上跑同样服务，三天崩两次，换 Kylin v11 后稳定运行 17 天无重启。
Python 是 LLM 工程的“胶水语言”：asyncio 对接异步 API、requests 处理 HTTP、Pydantic 做 prompt 结构校验、Jinja2 模板渲染人格化话术——没有比 Python 更快把想法落地的组合。有人问为什么不选 Rust 或 Go？答案很实在：LLM 调用本身不是性能瓶颈（DeepSeek-V4-Pro 平均响应 800ms），真正的耗时在 prompt 构建、上下文裁剪、回复润色上。Python 的开发效率优势，在一周周期内压倒一切。
Kylin Server v11 的“非技术价值”被严重低估：它自带的麒麟软件中心里，有预编译好的 python3.9、nginx、redis 包，安装命令就是sudo apt install python3.9 nginx redis-server，不用自己编译 OpenSSL 或解决 glibc 版本冲突。更重要的是，它的 SELinux 策略默认放行了本地 loopback 的 HTTP 请求，而 Ubuntu 的 AppArmor 会莫名其妙拦截 OneBot 的反向 HTTP 回调。这个细节，让我少踩了 6 小时的权限坑。

最终架构是三层洋葱模型：

外层：OneBot v11 事件网关（go-cqhttp 实例）——只做协议转换，不碰业务逻辑；
中层：Python 主服务（FastAPI + Uvicorn）——接收 OneBot 事件，调用 LLM，执行人格化转译，再调用 OneBot 发送接口；
内层：状态与缓存层（Redis + 本地 SQLite）——存群成员画像、最近 5 条上下文、用户偏好标签（如“讨厌长句”“爱听冷笑话”）。

这个设计放弃了“单二进制部署”的极简主义，换来的是可维护性：当某天需要加个“根据用户头像性别自动切换称呼”功能时，我只改 Python 层的user_profile.py，不用动 go-cqhttp 的 C++ 代码，也不用重编译整个服务。

2.3 “人格化引擎”的核心设计原则

我给中层 Python 服务定了三条铁律，每一条都对应一个真实翻车现场：

原则一：永远先裁剪，再生成，绝不后处理
初期我尝试“先让 LLM 输出长文本，再用正则删掉‘根据资料’‘综上所述’这类词”，结果发现：LLM 一旦生成了冗余结构，后续删减会破坏语义连贯性。比如删掉“综上所述”后，句子突然断掉。正确做法是：在 prompt 里就锁死输出格式。我的 system prompt 第一行永远是：
你是一个在技术群活跃的资深工程师，说话简洁、带点幽默感，从不使用‘根据XX资料’‘综上所述’‘需要注意的是’等书面表达。回复长度严格控制在 1-2 句话，最多 45 字。
这个约束让 LLM 从生成源头就规避了“AI 味”结构。
原则二：上下文不是越多越好，而是越“像人”越好
群聊里没人会记住前 20 条消息。我把 Redis 缓存的上下文窗口设为“最近 3 条有效消息 + 当前提问”，并加了过滤器：自动忽略“哈哈”“收到”“？”这类无信息量消息。更关键的是，我会把上一条 bot 的回复也喂进去，形成“bot-人-bots”对话链。这样 LLM 能学着人类的接话节奏——比如人说“这个 bug 我修了”，bot 下一句就不会再问“bug 修好了吗？”，而是说“牛，今晚火锅我请”。
原则三：人格不是静态设定，而是动态协商
我没给 bot 设固定人设（如“技术宅小王”），而是让它根据群类型自动切换模式：
- 技术群 → 用术语但带解释（“这个用 RAG 就行，简单说就是让大模型先查文档再回答”）；
- 行政群 → 用短句+emoji（“会议室已订好 ✅”）；
- 闲聊群 → 加冷笑话（“问：为什么程序员分不清万圣节和圣诞节？答：因为 Oct 31 == Dec 25”）。
  模式切换不是靠关键词匹配，而是用一个轻量分类器（scikit-learn 训练的 TF-IDF + LogisticRegression），分析群公告和前 10 条高频词，准确率 89%。这个分类器只有 120 行代码，但让 bot 第一次有了“察言观色”的能力。

这三条原则，把“让 bot 不像 AI”这个模糊目标，转化成了可编码、可测试、可迭代的工程任务。

3. 核心细节解析：让 LLM 说人话的 7 个实操开关

3.1 Prompt 工程：不是写作文，是写“群聊操作手册”

很多人以为 prompt 就是拼一段文字丢给 API，其实这是最大误区。在群聊场景下，prompt 是一份精确的“行为契约”，必须包含四个强制字段：

字段	作用	实操示例	为什么关键
Role Definition	定义 bot 在群里的社会角色	`你是在腾讯会议技术支持群值班的运维老张，工龄12年，说话带点京片子，习惯用‘咱’代替‘我们’`	角色决定语气基线。没有角色，LLM 默认用百科全书口吻
Context Window	明确本次回复依赖的上下文范围	`上一条消息：@bot 查下昨天的数据库慢查询日志<br>你的回复需基于此，不要重复提问`	防止 LLM “假装不知道”，强行追问已知信息
Output Constraints	用机器可读方式限制输出格式	`- 必须以中文回复<br>- 字数≤35字<br>- 禁止出现‘根据’‘因此’‘综上’<br>- 结尾可加1个emoji（✅❌💡）`	正则后处理不可靠，前置约束才是根治方案
Failure Fallback	定义 API 失败时的兜底策略	`如果 API 调用失败，回复：“手抖了，重试一下？”并附上重试按钮`	用户感知不到技术故障，只看到“bot 在努力”

我用 Jinja2 模板管理这些字段，不同群组加载不同模板。比如行政群模板的 Role Definition 是：你是行政部的小林，负责订会议室和收快递，说话利索，从不废话；而技术群模板则是：你是 DevOps 组的阿哲，熟悉 Kubernetes 和 CI/CD，解释技术概念时会打比方。

提示：别信“让 LLM 自己决定风格”的 prompt。我试过加一句“请用适合群聊的风格回复”，结果 LLM 有时用古文，有时用诗，有时还押韵。风格必须显式定义，不能交给模型猜。

3.2 OneBot v11 协议的“隐藏开关”：message_id 与 reply 功能的妙用

OneBot v11 文档里有个不起眼的字段message_id，它不只是消息唯一标识，更是实现“群聊对话感”的关键杠杆。默认情况下，bot 发消息是平铺直叙的，但加上reply: true和message_id，就能触发客户端的“回复引用”样式——在 QQ 和 Telegram 里，这会让 bot 的消息自动缩进、显示“回复xxx”，视觉上立刻变成“参与对话”而非“广播通知”。

我的实操流程是：

收到用户消息 event，提取event.message_id；
构建 prompt 时，把event.message_id作为上下文的一部分传入（“用户刚发了这条消息，ID 是 xxx”）；
调用 LLM 得到回复后，用send_msg接口发送时，显式带上"message_id": event.message_id, "reply": true。

效果立竿见影：当用户问“这个需求啥时候上线？”，bot 回复“预计周五下班前，我盯进度”时，QQ 客户端会显示为“回复 @用户：预计周五下班前...”，用户一眼就知道这是在接他的话茬，而不是 bot 自言自语。

注意：message_id在不同 OneBot 实现中格式不同（go-cqhttp 是数字，onebot-qq 是字符串），必须在服务启动时通过/get_status接口探测实际格式，不能硬编码。我踩过这个坑——在测试环境用 go-cqhttp 是数字 ID，上线用 onebot-qq 就全崩了，因为字符串 ID 被当成整数解析报错。

3.3 Kylin Server v11 的系统级优化：让 bot 响应快 0.3 秒

别小看这 0.3 秒。群聊里，响应延迟超过 1.2 秒，用户就会觉得“bot 卡了”或“bot 不在线”。我在 Kylin v11 上做了三处针对性优化：

内核参数调优：编辑/etc/sysctl.conf，追加
```
net.core.somaxconn = 65535 net.ipv4.tcp_max_syn_backlog = 65535 fs.file-max = 100000
```
执行sudo sysctl -p生效。这解决了高并发时连接队列溢出导致的请求丢弃——尤其在群消息刷屏时，效果明显。
Python 进程绑定 CPU 核心：Kylin v11 的taskset命令可将 Uvicorn 进程绑定到特定 CPU 核心（如taskset -c 0,1 uvicorn main:app --host 0.0.0.0:8000）。避免多核调度抖动，实测 P95 延迟从 1120ms 降到 890ms。
Redis 连接池复用：不用每次请求都新建 Redis 连接。在 FastAPI 的lifespan中初始化连接池：
```
from redis import ConnectionPool pool = ConnectionPool(host='localhost', port=6379, db=0, max_connections=20) redis_client = redis.Redis(connection_pool=pool)
```
这个改动让 Redis 操作平均耗时从 15ms 降到 2ms。

这些不是玄学优化，而是 Kylin v11 系统特性与 Python 服务特性的精准咬合。Ubuntu 上也能做，但 Kylin 的 systemd 服务文件（/etc/systemd/system/bot.service）里，CPUAffinity=和MemoryLimit=参数开箱即用，配置起来更傻瓜。

3.4 LLM API 调用的“防抖”设计：应对 deepseek api 的各种 error

DeepSeek API 的报错信息非常诚实，但也非常“程序员友好”——它不会告诉你“用户网络不好”，只会甩一句api error: the socket connection was closed unexpectedly.。我整理了高频报错及对应策略：

错误码/信息	根本原因	我的应对策略	实操代码片段
`402 insufficient balance`	API 余额不足	自动切换备用模型（如降级到 DeepSeek-V3），并私聊管理员告警	`if "insufficient balance" in error_msg: use_fallback_model()`
`400 this model's maximum context length is 1048565 tokens`	输入 token 超限	启用两级裁剪：先按句子切分，保留最后 N 句；再对每句做关键词提取（TF-IDF），只留高权重词	`context = trim_by_sentences(history, max_sentences=3)`
`claude's response exceeded the 32000 output token maximum`	输出超长（虽用 DeepSeek，但提示词里写了 Claude 作对比）	强制在 prompt 末尾加约束：`<output_limit>32000 tokens</output_limit>`，并启用流式响应截断	`response = await stream_response(...); if len(response) > 32000: response = response[:32000]`
`the model has reached its context window limit`	上下文太长	在 Redis 缓存层加 TTL（30 分钟），并设置 LRU 驱逐策略，确保内存不爆	`redis.setex(f"ctx:{group_id}", 1800, json.dumps(context))`

最关键的是，所有错误处理都封装成retry_with_backoff装饰器，指数退避（1s→2s→4s），最多重试 3 次。用户完全感知不到——bot 只是“思考”了稍久一点，然后给出答案。

3.5 “人格化润色”的后置流水线：7 行代码解决 80% 的 AI 味

即使 prompt 写得再好，LLM 仍有 15% 概率输出“AI 味”句子。我的解决方案不是重调 API，而是在返回后加一道轻量润色：

def polish_reply(text: str) -> str: # 1. 删除万能开头 text = re.sub(r'^[^\u4e00-\u9fa5]*?([，。！？；：])', r'\1', text) # 2. 合并短句（把“你好。”“我是bot。”→“你好，我是bot。”） text = re.sub(r'([。！？；])\s*([A-Za-z\u4e00-\u9fa5])', r'\1\2', text) # 3. 替换书面语 text = text.replace('因此', '所以').replace('综上所述', '总之').replace('需要注意的是', '注意') # 4. 添加口语化结尾（概率 30%） if random.random() < 0.3 and not text.endswith(('？', '！')): text += random.choice(['～', '哈', '啦']) return text.strip()

这段代码只有 7 行，但覆盖了 80% 的常见问题。它不改变语义，只调整“说话方式”。比如 LLM 输出“因此，建议您重启服务”，润色后变成“所以，重启一下服务吧～”。注意，润色是最后一步，必须在所有业务逻辑（如加 emoji、加按钮）之后执行，否则会破坏结构。

实操心得：润色规则必须可配置、可关闭。我在管理后台加了个开关，当 bot 出现异常回复时，管理员一键关闭润色，直接看原始输出，快速定位是 prompt 问题还是 LLM 问题。

3.6 群聊专属的“冷启动”策略：新用户第一句话怎么破冰？

新用户进群，bot 的第一句问候决定了信任感。我拒绝用“欢迎加入！”这种群发模板，而是设计了三级响应：

一级：静默观察（0-30秒）
bot 不主动打招呼，只监听新用户是否发消息。如果用户发了“大家好”，bot 回复“欢迎！我是群里的技术助手，有啥问题随时喊我 👋”；如果用户发了“这个怎么用？”，bot 直接答问题。
二级：头像分析（30-60秒）
调用 OneBot 的get_stranger_info接口，获取用户头像 URL，用 OpenCV 简单分析：
- 如果头像含文字（OCR 识别），且含“Java”“Python”等词 → 回复“同是码农，幸会！”
- 如果头像是卡通形象 → 回复“头像可爱！是哪个动漫角色？”
  这个分析只跑一次，结果缓存 24 小时。
三级：群公告学习（1分钟）
解析群公告（get_group_notice），提取关键词。如果公告里有“禁止发广告”，bot 对新用户加一句“悄悄说：群里不聊广告哈 😅”。

这套策略让新用户第一印象不是“又一个机器人”，而是“这 bot 好懂我”。

3.7 日志与监控：不是为了排查，而是为了“听见 bot 的心跳”

我给 bot 配了三类日志：

trace.log：记录每条消息的完整生命周期（收到→裁剪→prompt→API 耗时→润色→发送），用 JSON 格式，方便 ELK 分析；
persona.log：只记人格化相关决策（如“切换为行政模式”“启用冷笑话”），用于回溯 bot 行为逻辑；
error.log：仅记录未捕获异常，配合企业微信机器人告警。

最关键的监控指标不是“API 调用成功率”，而是“回复自然度得分”：我用一个轻量 BERT 模型（finetune 自 hfl/chinese-roberta-wwm-ext）对每条 bot 回复打分（1-5 分），分数低于 3 的自动标为“需人工审核”。上线一周，自然度平均分从 2.1 升到 4.3，证明人格化策略有效。

注意：日志路径必须符合 Kylin v11 规范。我把日志全放在/var/log/bot/下，而不是 Python 项目目录里，这样 systemd journalctl 可以统一管理，sudo journalctl -u bot -f就能实时看日志。

4. 实操过程：从零部署一个“不像 AI”的群聊 bot

4.1 环境准备：Kylin Server v11 上的 5 分钟初始化

在 Kylin Server v11 虚拟机上，执行以下命令完成基础环境搭建（全程无需 root 密码，用 sudo 即可）：

# 1. 更新源并安装基础包 sudo apt update && sudo apt install -y python3.9 python3.9-venv nginx redis-server git # 2. 创建项目目录并激活虚拟环境 mkdir -p ~/bot-project && cd ~/bot-project python3.9 -m venv venv source venv/bin/activate # 3. 安装 Python 依赖（精简版，不含 LLM SDK） pip install fastapi uvicorn requests pydantic jinja2 redis python-dotenv # 4. 配置 Redis（启用密码，符合 Kylin 安全策略） sudo sed -i 's/^# requirepass.*/requirepass your_strong_password/' /etc/redis/redis.conf sudo systemctl restart redis-server # 5. 配置 Nginx 反向代理（暴露 8000 端口为 80） echo "server { listen 80; server_name _; location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host \$host; proxy_set_header X-Real-IP \$remote_addr; } }" | sudo tee /etc/nginx/conf.d/bot.conf sudo nginx -t && sudo systemctl reload nginx

这 5 步完成后，你的 Kylin v11 就具备了运行 bot 的全部基础设施。注意：your_strong_password必须替换成强密码，Kylin 的安全审计会检查 Redis 是否启用了密码认证。

4.2 OneBot v11 网关部署：go-cqhttp 的 Kylin 适配版

我选用 go-cqhttp 作为 OneBot v11 网关，因为它对 Kylin 的 ARM64 架构（如飞腾 CPU）支持最好。下载地址：https://github.com/Mrs4s/go-cqhttp/releases （选linux_arm64.tar.gz或linux_amd64.tar.gz）。

解压后，编辑config.yml：

account: uin: 123456789 # 你的 QQ 号 password: "your_qq_password" encrypt: false status: 0 relogin: enabled: true delay: 3 max-times: 0 http: enabled: true host: 0.0.0.0 port: 5700 post-url: "http://127.0.0.1:80/callback" # 指向我们的 Python 服务 timeout: 30 websocket: enabled: false database: leveldb: enable: true

关键点：

post-url必须指向 Nginx 代理后的地址（http://127.0.0.1:80/callback），而不是直接http://127.0.0.1:8000/callback，否则 Kylin 的防火墙可能拦截；
encrypt: false是为了简化调试，生产环境可开启；
relogin.enabled: true确保 QQ 登录态失效后自动重连。

启动命令：./go-cqhttp -faststart。首次运行会生成data/目录和二维码，用手机 QQ 扫码登录即可。

4.3 Python 主服务：核心人格化引擎代码详解

创建main.py，这是整个 bot 的心脏：

from fastapi import FastAPI, Request, BackgroundTasks from pydantic import BaseModel import redis import json import asyncio from jinja2 import Environment, FileSystemLoader from dotenv import load_dotenv import os load_dotenv() app = FastAPI() # Redis 连接（复用 Kylin 上配置的密码） redis_client = redis.Redis( host='localhost', port=6379, password=os.getenv("REDIS_PASSWORD"), db=0, decode_responses=True ) # Jinja2 模板环境 env = Environment(loader=FileSystemLoader('templates')) class OneBotEvent(BaseModel): post_type: str message_type: str group_id: int user_id: int message: str message_id: str @app.post("/callback") async def handle_callback(event: OneBotEvent, background_tasks: BackgroundTasks): if event.post_type != "message" or event.message_type != "group": return {"status": "ok"} # 1. 从 Redis 获取群上下文（最近 3 条） context_key = f"group_ctx:{event.group_id}" history = redis_client.lrange(context_key, 0, 2) or [] # 2. 构建 prompt（调用模板） template = env.get_template("group.j2") prompt = template.render( role=get_group_role(event.group_id), history=history, current_message=event.message ) # 3. 异步调用 LLM（此处用 mock，实际替换为 requests.post） background_tasks.add_task(process_llm_call, event, prompt) return {"status": "ok"} async def process_llm_call(event: OneBotEvent, prompt: str): # 这里是真正的 LLM 调用逻辑（略，见 4.4 节） pass def get_group_role(group_id: int) -> str: # 根据群 ID 返回角色模板名（tech.j2, admin.j2, fun.j2） roles = {123456789: "tech", 987654321: "admin"} return roles.get(group_id, "fun")

这个main.py只有 58 行，但完成了事件路由、上下文管理、模板渲染三大核心。它不碰 LLM 调用细节，只做“指挥官”，把具体执行交给后台任务，保证 HTTP 接口的低延迟。

4.4 LLM API 调用：DeepSeek-V4-Pro 的 Kylin 专用配置

DeepSeek API 的调用，关键在 headers 和 payload 的 Kylin 适配：

import requests import json def call_deepseek_api(prompt: str) -> str: url = "https://api.deepseek.com/v1/chat/completions" headers = { "Authorization": f"Bearer {os.getenv('DEEPSEEK_API_KEY')}", "Content-Type": "application/json", # Kylin 的 curl 版本较老，必须指定 Accept "Accept": "application/json" } payload = { "model": "deepseek-v4-pro", "messages": [ {"role": "system", "content": "你是在技术群值班的工程师，说话简洁带幽默..."}, {"role": "user", "content": prompt} ], "max_tokens": 512, "temperature": 0.7, # 0.7 是群聊最佳平衡点：太低（0.3）死板，太高（0.9）飘忽 "stream": False } try: response = requests.post( url, headers=headers, json=payload, timeout=(10, 60) # connect=10s, read=60s，Kylin 网络可能慢 ) response.raise_for_status() data = response.json() return data["choices"][0]["message"]["content"].strip() except requests.exceptions.Timeout: return "手抖了，重试一下？" except Exception as e: return f"出错了：{str(e)[:30]}"

注意timeout参数：Kylin Server v11 的内网 DNS 解析有时慢，connect设为 10 秒防止卡死；read设为 60 秒，因为 DeepSeek-V4-Pro 处理长上下文可能耗时。这个配置在 Kylin 上实测最稳。

4.5 启动与验证：5 步确认 bot 已“活”在群里

启动 Python 服务：
uvicorn main:app --host 0.0.0.0 --port 8000 --reload
确认日志输出Uvicorn running on http://0.0.0.0:8000。
启动 go-cqhttp：
./go-cqhttp -faststart
确认日志出现HTTP Server listening on 0.0.0.0:5700。

测试回调通路：
用 curl 模拟 OneBot 事件：

curl -X POST http://localhost/callback \ -H "Content-Type: application/json" \ -d '{"post_type":"message","message_type":"group","group_id":123456789,"user_id":987654321,"message":"test","message_id":"123"}'

查看 Python 日志是否有handle_callback记录。

在群内发送测试消息：
任意群内 @bot 发“你好”，检查 bot 是否回复，且回复是否带引用样式（即reply: true生效）。
检查自然度：
查看persona.log，确认是否记录了“切换为 tech 模式”；查看trace.log，确认llm_time字段是否在 800-1200ms 区间。

五步走完，你的 bot 就正式“活”在群里了。它不再是一个 API 调用器，而是一个会看场合、懂节奏、有脾气的群聊原住民。

5. 常见问题与排查技巧实录：那些文档里不会写的坑

5.1 “bot 回复了，但没显示引用样式” —— OneBot v11 的 message_id 陷阱

现象：bot 消息平铺在聊天窗口，没有缩进，也没有“回复 @XXX”字样。
排查路径：

检查 go-cqhttp 日志，搜索post_url，确认请求确实发到了http://127.0.0.1:80/callback；
检查 Python 服务日志，确认handle_callback被调用，且event.message_id字段存在；
检查send_msg请求的 JSON body，确认包含"message_id": "xxx", "reply": true；
终极原因：OneBot v11 协议规定，message_id必须是本次会话中真实存在的消息 ID。如果 bot 收到的是群消息，但message_id是私聊 ID，或 ID 格式错误（如数字 vs 字符串），客户端会忽略reply。