企业官网建设流程全解析

先想一个问题：你是真的需要 AI，还是需要一个永远在线的贴身助理？

网页版 AI 用起来其实挺累的。解锁手机、找标签页、重新登录、复制粘贴、上下文丢失……和 AI 对话本来应该像发微信一样简单。但现实是，网页版 AI 把你拉回 PC 前，你只有端坐在电脑前才想起用它。所以我一直想做一个东西：把 AI 扔进 QQ，让我在哪儿都能随时喊一声，它就能回我。本文要讲的，就是基于腾讯云 Lighthouse + DeepSeek API + QQ 机器人协议，从零搭建一个 7x24 小时的私人智能体。整个过程不算复杂，按路径走的话，大概 5 分钟就能让 QQ 里的 AI 开始说话。

我不会写什么花里胡哨的前端界面，也不会上重型的 Agent 框架——就用最直接的组合：一台永远开机的轻量服务器当躯壳，DeepSeek 当大脑，QQ 当你的入口。适合想折腾 AI 应用又不想上来就啃 LangChain 的人，也适合想给团队做内部 AI 助手却不想开发 App 的产品、运营朋友。

1. 先拆解这套组合：Lighthouse、DeepSeek 和 QQ 各管哪一段

1.1 为什么非得要一台云服务器：本地电脑做不到的事

很多人第一反应是，我在自己电脑上跑个脚本不行吗？当然行，但你要接受三个现实：

• 电脑会关机、休眠、断网，AI 会失联；
• 家宽普遍没有固定公网 IP，QQ 侧回调根本找不到你；
• 万一你在打游戏、开大型软件，后台挂着一个 AI 服务，体验极差。

所以需要一台放在机房里、7x24 小时不关机的“小电脑”。这里我选的是腾讯云轻量应用服务器 Lighthouse。这玩意儿定位就是给小项目用的：有公网 IP，有系统盘，自带防火墙控制台，不需要你会复杂的网络配置，普通用户十分钟内能上手。

有人会问，那用云函数（Serverless）行不行？技术上完全可行，但云函数适合“事件驱动、短时运行”的场景，QQ 机器人需要维持 WebSocket 长连接，云函数的运行机制反而别扭。一台轻量服务器是更省心、更通用的底座。

1.2 DeepSeek 负责“说话”，但有两种接法

DeepSeek 是目前性价比极高的大模型，文章标题里直接点名它。它的接入方式有两种：

• 官方 API：按 token 计费，不需要显卡，响应速度极快，代码里设置一个base_url就能调用。这是绝大多数人和中小团队的默认选择。
• 本地部署：要有一块像样的显卡，还要解决显存、模型量化、并发等一系列问题。除非你做私密数据本地推理，否则我劝你别在入门阶段碰它。

下面的表格是我的建议对比：

我在这个项目里选的当然是官方 API。后面所有步骤，都是围绕“API 调用”来设计的。

1.3 QQ 的意义：把 AI 装进每天都打开的应用

QQ 的角色不复杂，它就是消息的入口和出口。智能体本身不需要有自己的界面，它只需要做一件事：收到你的消息，转给 DeepSeek，拿到回复再发回 QQ。为什么要用 QQ 而不是 Telegram 或 Discord？核心原因是你的朋友、同事、家人就在 QQ 上，它本来就是你的高频沟通工具。把一个 AI 放进 QQ，等于把助理塞进口袋，想找它的时候，打开对话框发条消息就行，不需要任何额外操作。

2. 服务器准备：Lighthouse 选型、购买与初始化

2.1 套餐怎么选：2 核 2G 真的够用吗

如果你只是跑一个 QQ 消息转发服务，核心负载几乎可以忽略不计。整个服务的瓶颈在网络和 API 响应时间上，不在 CPU 和内存。所以最低配的 2 核 2G 完全够用，系统选 Ubuntu 22.04 LTS。地域选离你近的，比如你在广东就选广州，在西边就选成都，延迟会低一点。

系统盘默认一般 40G 或更多，对于纯代码和日志来说绰绰有余。带宽是最容易被忽略的，个人机器人业务几乎不消耗带宽，官方给的 3M-4M 足够。这里有一个常见误区：有人为了跑本地模型去买高配服务器，结果发现 Lighthouse 最高配置也没有独立显卡，本地大模型跑不动。记住，如果你按我这篇文章用 DeepSeek API，2 核 2G 就是最优解，省下来的钱投到 API 里能用很久。

2.2 防火墙与安全组：不要暴露多余端口

腾讯云轻量服务器的控制台里有一个“防火墙”设置。很多人图省事全放行，这是安全隐患。实际上，QQ 机器人进程是主动外连到本地或云端的 WebSocket 服务，不需要公网入站端口。你需要放行的只有 SSH 默认的 22 端口。如果后面你需要在本地调试，可以临时放行 3001 等端口给 WebSocket，但调试完记得关掉。

2.3 连接服务器：网页终端足够，SSH 更方便

两种方式：

• 腾讯云控制台自带的网页终端，零配置，适合第一次接触 Linux 的人；
• 本地 SSH：ssh ubuntu@你的服务器IP，在 Windows 上推荐用 Windows Terminal 或者 MobaXterm。

连接成功后，先做两件事：更新软件源，安装 Python 和 pip：

sudo apt update && sudo apt upgrade -y sudo apt install -y python3 python3-pip python3-venv

注意：Ubuntu 22.04 自带的 Python 是 3.10，完全够用。不要手动乱装其他版本，免得搞乱系统默认环境。

3. 申请 DeepSeek API Key：先让模型能“开口”

3.1 注册开放平台与创建 Key

登录 DeepSeek 开放平台，手机号注册后，在“API Keys”页面创建一个新 Key。创建后只会显示一次，务必复制保存下来，格式大致是sk-开头的一长串字符。然后去“账户”里充一点点钱，个人使用的话十块钱就能用很久，按 token 扣费，用不完还能放着。

这里提醒一句：API Key 相当于密码，别贴到公开仓库、别发到群里。如果泄露了，在控制台里一键删除重建，30 秒的事。

3.2 30 秒连通性测试

DeepSeek 兼容 OpenAI 的接口格式，所以直接用openai这个官方 Python SDK 就能调。先安装：

pip3 install openai

创建test_deepseek.py：

from openai import OpenAI client = OpenAI( api_key="你的API Key", base_url="" ) resp = client.chat.completions.create( model="deepseek-chat", messages=[ {"role": "user", "content": "你好，回复一句话"} ] ) print(resp.choices[0].message.content)

运行python3 test_deepseek.py，如果能正常输出一句中文问候，说明 API 通了。这里有两个坑提前说：

• 一定不能漏掉base_url，默认它会去 OpenAI 官方服务器，然后报 404 或 401；
• 模型名是deepseek-chat（通用对话）和deepseek-reasoner（深度推理）。日常聊天用前者，响应更快、价格更低。

4. QQ 接入的三种方式：官方机器人、OneBot 协议端，怎么选

4.1 官方 QQ 机器人：最稳但需要审核

腾讯官方有 QQ 开放平台，个人开发者可以创建机器人。接入后通过官方 WebSocket 或 Webhook 接收消息，用官方 SDK 发消息，全程合规、稳定，不怕封号。但它有几个现实问题：机器人发消息有频率限制、部分能力需要审核通过才开放、面向的具体场景偏向频道和群聊，对“私人一对一聊天”支持不算灵活。如果你是正经创业团队做客服机器人，这是首选。

4.2 OneBot 协议端：社区方案，灵活但自带风险

OneBot 是一种统一消息协议标准，它把 QQ 消息抽象成标准事件。协议端负责登录 QQ 并转换成 OneBot 事件，业务端（你的 Python 脚本）只需要对接 WebSocket 或 HTTP 事件即可。

目前社区常用的协议端有：

• NapCatQQ：基于新版 QQNT 的协议实现，用 Docker 部署非常方便，支持 WebSocket 服务端/客户端两种模式，是目前比较活跃的一个项目；
• Lagrange：纯 .NET 实现，不需要真的装 QQ 客户端，API 兼容性好；
• go-cqhttp：老牌项目，但已经停止维护，新人不建议再用了。

用这类方案，你可以拿一个小号 QQ 扫码登录，让机器人以真实 QQ 号的身份收发私聊消息。代价是它不符合 QQ 官方用户协议，存在封号风险，这一点必须心里有数。我的建议是：自用、测试、给项目做演示，完全可以；但如果做面向大量用户的商业化产品，请走官方机器人通道。

4.3 我的推荐组合

考虑到标题强调“5 分钟搞定”，我推荐直接用 OneBot 协议端来做快速原型。下面我以 NapCat 为例，说说实际操作。

先安装 Docker：

curl -fsSL | sudo sh

然后拉取并启动 NapCat：

docker run -d \ --name napcat \ --restart=always \ -p 3001:3001 \ -e LICENCE=true \ -e MODE=ws \ -e WS_PORT=3001 \ --network=host \ mlikiowa/napcat-docker

启动后，看日志里的二维码，用你的 QQ 小号扫码登录。登录成功后，NapCat 会在ws://服务器IP:3001提供 OneBot WebSocket 服务。这一步是最容易卡住的，常见问题有两个：

• Docker 拉镜像慢：国内环境建议给 Docker 配置镜像加速源；
• 扫码后一直转圈：确认小号没有被风控，新号或异地登录频繁的号容易被限制。

5. 服务端核心代码：收到 QQ 消息后如何交给 DeepSeek 再回传

5.1 消息流转设计

整套系统的消息流是这样的：

1. 你在 QQ 里给机器人小号发消息；
2. NapCat 收到消息，打包成 OneBot 事件，通过 WebSocket 推给 Python 脚本；
3. Python 脚本校验发送人是否为管理员（避免陌生人使唤你的机器人）；
4. 把消息文本追加到上下文，调用 DeepSeek API；
5. 拿到回复后，调用 NapCat 的send_private_msg接口，把回复发回你的 QQ。

5.2 目录与依赖

我习惯在一个目录里集中管理，比如/home/ubuntu/qq-bot/。需要两个 Python 依赖：openai和websockets。

pip3 install openai websockets

5.3 一个能直接跑的最小实现

下面是我实际在用的极简版本，去掉了复杂装饰器和框架，逻辑直白，适合快速上手：

import json import asyncio from openai import OpenAI import websockets ADMIN_QQ = "你的QQ号" API_KEY = "你的DeepSeek API Key" client = OpenAI( api_key=API_KEY, base_url="" ) conversations = {} SYSTEM_PROMPT = "你是一个靠谱的私人助理。回答要简洁、准确，不要长篇大论。" async def handle_event(ws, data): # 忽略心跳等元事件 if data.get("post_type") != "message": return # 只响应私聊，并且只响应管理员本人 if data.get("message_type") != "private": return uid = str(data.get("user_id")) if uid != ADMIN_QQ: return text = data.get("raw_message", "").strip() if not text: return reply = await call_deepseek(uid, text) # 回发消息 await ws.send(json.dumps({ "action": "send_private_msg", "params": { "user_id": int(uid), "message": reply } }, ensure_ascii=False)) async def call_deepseek(uid, text): history = conversations.get(uid, []) # 只保留最近 10 条，防止上下文无限膨胀 messages = [{"role": "system", "content": SYSTEM_PROMPT}] + history[-10:] messages.append({"role": "user", "content": text}) try: resp = client.chat.completions.create( model="deepseek-chat", messages=messages, timeout=60 ) reply = resp.choices[0].message.content.strip() history.append({"role": "user", "content": text}) history.append({"role": "assistant", "content": reply}) conversations[uid] = history[-20:] return reply except Exception as e: return f"我这边出错了：{e}" async def main(): # 这里的地址以你 NapCat 实际监听的地址为准 ws_url = "ws://:3001" print(f"连接 OneBot WebSocket: {ws_url}") async for websocket in websockets.connect(ws_url): print("已连接，等待消息...") try: async for raw in websocket: data = json.loads(raw) asyncio.create_task(handle_event(websocket, data)) except websockets.ConnectionClosed: print("连接断开，重连中...") await asyncio.sleep(3) continue if __name__ == "__main__": asyncio.run(main())

这段代码有几个设计细节值得说明：

• 管理员白名单：不是每个 QQ 号都能使唤你的智能体，避免机器人被别人当公共接口用。
• 上下文记忆：用内存里的字典保存每个用户最近的对话历史，让 AI 能接上话，而不是每句都当成新对话。缺点是服务器重启会丢记忆。如果你需要长期记忆，后续可以接入一个 SQLite 或 Redis。
• 自动重连：ConnectionClosed时等待 3 秒重新连接，这是长期运行必须考虑的。

跑起来试一下：

python3 bot.py

看到“已连接，等待消息...”后，用你的 QQ 给机器人小号发一句“你好”，它应该会在一两秒内回复你。到这里，最核心的链路已经通了。

6. 进程守护与开机自启：别用 nohup，用 systemd

6.1 nohup 为什么不推荐

很多人习惯用nohup python3 bot.py &把进程丢到后台。这个方案看起来简单，但问题很多：不支持自动重启（进程崩了就崩了）、没有日志轮转、不方便查看状态。对于要 7x24 小时跑的服务来说，这是给自己埋雷。

6.2 写一个 systemd 服务文件

systemd 是 Linux 自带的进程管理工具，用它来管理我们的机器人进程最合适。创建服务文件：

sudo nano /etc/systemd/system/qq-bot.service

填入以下内容：

[Unit] Description=QQ DeepSeek Bot After=network-online.target [Service] WorkingDirectory=/home/ubuntu/qq-bot ExecStart=/usr/bin/python3 /home/ubuntu/qq-bot/bot.py Restart=always RestartSec=5 Environment=PYTHONUNBUFFERED=1 [Install] WantedBy=multi-user.target

关键点说明：

• Restart=always：进程崩了自动拉起，这是 24 小时在线的基础；
• RestartSec=5：崩溃后 5 秒再重启，避免疯狂重启打爆日志；
• PYTHONUNBUFFERED=1：让 Python 的 print 输出实时写进日志，否则你在 journal 里看不到任何输出。

然后让 systemd 生效并启动：

sudo systemctl daemon-reload sudo systemctl enable qq-bot sudo systemctl start qq-bot

查看运行状态和日志：

sudo systemctl status qq-bot sudo journalctl -u qq-bot -f

看到已连接，等待消息...日志，说明服务已经托管给 systemd。以后哪怕服务器重启，机器人也会自动起来，你什么都不用管。

6.3 验证一整天

一个合格的 24 小时服务，至少得跑满一整天再下结论。我实测中遇到的情况是：WebSocket 连接会因为网络波动偶发断开，但 systemd 的Restart=always配合代码里的自动重连，能保证最终状态是“断开-重连-恢复”，对用户体验几乎无感。建议你部署后第二天看一眼journalctl，确认没有反复重启的异常。

7. 实测表现、踩坑清单与进阶方向

7.1 我实测的延迟和稳定性数据

以下是我在 2 核 2G Lighthouse + DeepSeek 官方 API + NapCat 组合下的实测数据，供你参考：

如果你发现回复普遍超过 10 秒，先排查 DeepSeek API 是否限流，再排查服务器地域和你的网络链路。多数时候问题不在服务器上。

7.2 一定要说的避坑清单

• DeepSeek API 拿不到回复：最常见的不是网络问题，而是base_url写错。它必须精确到https://api.deepseek.com，不需要再加/v1之类的后缀。加了反而可能 404。
• QQ 小号被风控：新注册的 QQ 号直接扫码登录机器人，很容易被限制登录。建议先养几天号，每天正常聊几句，再用来做机器人。
• 多轮对话越聊越贵：如果不限制上下文长度，历史消息会无限增长，API 费用随之上涨。我在代码里做了最近 10 条截断，这是个人使用场景下的折中。如果你要做知识库问答，建议改用向量检索来精确找相关内容，而不是全量堆历史。
• 服务器被入侵的风险：我见过不少人把 API Key 硬编码在脚本里后，又把整个项目传到 GitHub 上。这是很危险的。建议把 Key 放到环境变量或者.env文件里，并在.gitignore里排除掉。
• 端口全部暴露：只放行 22 端口。如果你的协议端 WebSocket 需要外部访问，用完立刻关掉，或者给端口设置连接鉴权。

7.3 进阶：从“聊天机器人”到“智能体”

基础版跑通后，你可以往真正的“智能体”方向扩展：

• 接 Dify 或 Coze：如果不想继续写 Python，把 DeepSeek API 接到 Dify 这类平台上，用拖拽的方式编排提示词、知识库、工作流，再把 Dify 的 API 接到 QQ 机器人上。适合非程序员。
• 工具调用（Function Calling）：DeepSeek 支持 function call。你可以让机器人查天气、查日历、执行你服务器上的脚本。这就是 Agent 的雏形。
• 记忆持久化：把对话历史从内存迁到 SQLite 或 Redis，重启不丢记忆，机器人才能更“懂你”。
• 更精细的权限控制：比如哥哥能用、妹妹不能用，或者只允许在特定群聊里响应。

我自己跑这套东西的大半年时间里，最大的体会是：所谓智能体，本质上就是“一个可靠的消息入口 + 一个聪明的模型 + 几行把两者缝起来的胶水代码”。真正值钱的不是堆了多少框架，而是你有没有把它接入到自己的生活流里。如果你的 QQ 里还没有一个 24 小时随叫随到的智能体，现在就可以动手了。服务器买便宜套餐，API Key 申请五秒钟，核心脚本复制粘贴，剩下的系统让它自己跑去。等你在被窝里发一句“帮我写个周报提纲”然后秒收到回复时，你就会明白这 5 分钟花得有多值。