企业官网建设流程全解析

最近刷到很多人在问：为什么我每次想用AI都得打开网页，要么排队，要么得登录，要么刷着刷着上下文就丢了。说实话，我自己在折腾AI智能体之前也是这个状态——网页版用起来确实简单，但距离“个人助理”这个定位，始终差着一口气。直到我拿Lighthouse做宿主，把Deepseek接进来，再用QQ当交互入口，拼出一个7x24小时在线的私人智能体之后，才算是真正解放了双手。

这篇文章就把我完整搭建这套东西的经过、踩坑记录和最终方案全部摊开来讲。先说结论：整套流程跑通之后，日常使用体验约等于“给QQ好友发消息”，但对面那个好友是一个能查资料、能写代码、能陪你梳理思路的Deepseek大模型。整个过程不需要很强的编程基础，关键步骤我会拆到可以照着操作的程度。这篇文章适合三类人：一是天天泡在AI工具里但受够了网页版限制的重度用户，二是想给团队或社群做个自动问答机器人的运营者，三是单纯想体验一把自建智能体的技术爱好者。

1. 整体方案拆解：Lighthouse、Deepseek和QQ各负责什么

很多人一听“自建智能体”，第一反应就是要买GPU、部署大模型、写一堆后端代码。这套方案能“5分钟跑通”的根本原因，就是把重活拆给了三个专注做自己事情的组件：QQ负责入口和消息触达，Deepseek负责思考和生成，Lighthouse负责提供一个24小时不关机的运行环境。

1.1 需求画像：我们要的“私人智能体”到底是什么

在开工之前先想清楚需求，不然很容易搭出来一个“能聊天的玩具”而不是“能办事的助理”。我给自己定的目标是这么几条：

• 7x24小时在线，半夜想起来一个问题也能立刻问。
• 响应速度要快，最好3到5秒内能出第一段回复。
• 要有上下文记忆，不是每次发消息都“失忆重来”。
• 部署成本要低，不想为了一个机器人专门买一台高配服务器。
• 操作入口要顺手，最好打开手机就能用，不用切App。

这几条需求列出来之后，选型其实已经很清楚了。要7x24小时在线，就得有一台长期运行的机器；要响应快，就不能在个人电脑上跑本地大模型，而是直接调云端API；要操作顺手，就得找个大家每天都在用的聊天软件当壳。

这套需求基本排除了“本地部署模型”方案。不是说本地部署不好，而是对“快速上手、低成本维护”这个目标来说，本地跑的7B、14B小模型，在指令遵循和复杂推理上和Deepseek这种大参数模型差距还是很明显的。我家里有一张消费级显卡，实测跑Qwen2.5-7B，回答速度倒是不慢，但遇到需要多步推理的问题，质量就明显露怯了。如果哪天你追求数据完全不出门，再考虑本地部署的事，今天这套方案先把“好用”排在第一位。

1.2 三个组件的角色分工

先给这套方案画个角色图，各位心里有个谱：

• QQ：交互层。用户感知到的“智能体”本质是一个QQ号，你可以把它理解成“住在QQ里的助手”。它负责接收消息、发消息，包括文字、图片甚至文件。
• Deepseek：大脑。它提供大模型API，负责把你发的消息转成合适的回复。我选择Deepseek的核心原因有两个：一是它的API定价在同类模型里非常有竞争力，日常使用成本极低；二是它的中文理解能力和推理能力表现很扎实，尤其适合做中文场景的智能体。
• Lighthouse：身体。它是一台云服务器，提供稳定的公网IP和持续运行的环境。QQ收到消息后，真正调用Deepseek API的逻辑部署在Lighthouse上，它像一个中转站，把QQ和Deepseek连接起来。

1.3 为什么没有选Coze、Dify这类平台方案

你可能想问：Coze、Dify这些现成的智能体平台不是更省事吗？确实省事，而且我也用过。但用了一段时间后发现几个问题：一是免费额度用完后的价格不透明，二是平台对消息格式、触发词、模型选择都做了封装，灵活性打了折扣；三是数据全部存在别人平台上，如果你的智能体要做一些相对定制化的事情，比如读某个固定接口的数据再决定怎么回复，平台方的工作流搭建反而变得绕来绕去。

自建这套Lighthouse+Deepseek+QQ的方案，本质上就是把“智能体”的底座掌握在自己手里。我自己用了一套日子之后，最直观的感受是“可控”：想加个新功能就改代码，想换模型就换模型，AI平台服务不稳定了也不会波及到我，因为我这个部署在服务器上的组件只依赖QQ官方接口和Deepseek的API，这两个也都是公共服务，比任何第三方AI Agent平台都稳定得多。

当然，我不是劝所有人放弃Coze或Dify。如果你完全不会写代码，也不想碰服务器，那用平台版本来得更快。但这篇文章要讲的，是你还有一个门槛稍高一点但自由度也高很多的选项。

2. 环境准备：Lighthouse的选购、初始化和Docker部署

这一部分属于基建环节。很多人搭到一半放弃，都是因为环境没弄明白，Docker没装好，端口没开放，结果机器人上线了一分钟就失联。我们把这块一次做扎实。

2.1 Lighthouse服务器选型：到底买什么配置

Lighthouse是腾讯云推出的轻量应用服务器产品线，官方叫“轻量应用服务器”，大家习惯叫Lighthouse，它的定位就是“轻量、简单、便宜”。我个人非常推荐把它作为智能体的宿主，核心理由有三个：

• 一键防火墙配置，端口规则可视化，不用去折腾安全组。
• 自带固定公网IP，不用搞内网穿透，省掉一大半烦恼。
• 价格便宜，新用户经常有活动，最低配也能跑。

配置选择上直接给结论：2核2G内存、带宽3Mbps起步，系统盘选40G SSD就完全够用了。有人会问2G内存跑Docker会不会紧张？实测下来，跑NapCat（QQ协议端）+一个Python机器人进程+Docker本身，内存占用大约在700MB到1GB之间，剩余内存足够系统和其他小服务用。

3Mbps带宽要不要担心？完全不用担心。文本消息往返的流量极小，就算一分钟上百条消息，带宽也远用不满。我甚至用1核1G的配置跑过一个月，也没出什么大问题，只是偶尔模型回复特别长的时候会慢一点。如果你预算充足，直接上2核4G，这套配置未来想多跑几个服务也游刃有余。

2.2 系统初始化：两个命令搞定基础环境

拿到服务器之后，建议直接选择Ubuntu 22.04 LTS系统镜像。一方面Ubuntu的软件源比较新，另一方面社区资料多，踩坑之后搜得到解决方案。系统装好之后，第一步是更新软件源和基础工具：

apt update && apt upgrade -y apt install -y curl wget git vim ufw

第二步是装Docker。Docker在这套方案里的作用很关键——无论是后面的QQ机器人端（NapCat）还是我们自己的智能体服务，都可以跑在容器里，环境隔离，删掉重来也方便。用官方安装脚本是最稳妥的方式：

curl -fsSL https://get.docker.com | bash systemctl enable docker systemctl start docker

安装完成后用docker --version验证一下，能看到版本号就说明装好了。第三步是配一下防火墙，Ubuntu默认的ufw可能是关闭状态，打开并放行需要用到的端口：

ufw allow 22/tcp # SSH端口 ufw allow 8080/tcp # NapCat WebUI端口，后面会用到 ufw allow 9000/tcp # LLOneBot/OneBot HTTP端口，后面会用到 ufw enable

这里我必须多提醒一句：云服务商的“防火墙”和系统内的ufw是两层东西，两边都得放行。Lighthouse控制台里的防火墙也要把对应的TCP端口规则加进去，否则就算ufw放行了，外部流量一样进不来。我最初部署的时候就是只开了Lighthouse控制台的端口，忘了系统的ufw，结果QQ消息死活推不到服务器上，排查了半小时。

2.3 安装Lighthouse面板：让服务器管理可视化

Lighthouse买回来本质上还是一台Linux服务器，如果对命令行不熟，建议装一个宝塔面板（BT Panel）来做可视化运维。这里需要说明，宝塔面板和腾讯云Lighthouse的控制台是两回事——前者装在系统内部，负责管理文件、Docker、定时任务等；后者是云厂商的控制台，负责重启、重装系统和配置防火墙。

宝塔的安装命令很简单：

wget -O install.sh https://download.bt.cn/install/install-ubuntu_6.0.sh bash install.sh

安装完会输出一个面板地址、用户名和密码，用浏览器打开，登录进去之后，在“软件商店”里确认一下Docker管理器已经安装。面板的主要用途是可视化查看日志、管理文件、跑定时任务，不用把每个操作都背成命令。不过我要强调，面板只是辅助，真正核心的配置我们还是用命令行操作更可控，避免面板的版本依赖导致环境不一致的问题。

3. QQ机器人接入：用NapCat搭出消息通道

这一章是整个方案里最容易“翻车”的模块。QQ官方并没有像Telegram那样提供开放的机器人API，所以我们只能用社区方案——通过实现OneBot协议的客户端来收发QQ消息。市面上主流的选择有go-cqhttp、NapCat、LLOneBot等，我最终选的是NapCat，稳定性比较好，而且不依赖手机QQ常驻在线。

3.1 OneBot协议和NapCat的工作原理

先帮大家理清一个概念，为什么这事能成立？

OneBot是一套定义了“聊天机器人应该怎么和上层应用通信”的开放协议。它规定了消息事件的格式、API调用的格式。你可以把它理解成“消息领域的USB接口标准”——不管你是哪种聊天软件，只要实现了OneBot协议，上层应用就能用统一的方式读写消息。

NapCat就是一个实现了OneBot协议的QQ客户端。它本质上是用一种无头（headless）的方式运行QQ的Web服务逻辑，能够接收和发送QQ消息，然后以HTTP或WebSocket的方式把消息事件推送出来。

我们这套架构里消息的流向是这样的：

QQ用户发消息 → NapCat容器接收 → 按OneBot协议推送给我们的机器人服务 → 机器人服务调用Deepseek API获取回复 → 再通过NapCat调用API把回复发送回QQ对话

所以NapCat在这套链路里扮演的是“耳朵”和“嘴巴”的角色，真正思考的还是背后的Deepseek。

3.2 用Docker部署NapCat

NapCat官方提供了Docker镜像，部署起来非常快。先建一个目录存放NapCat的配置和数据：

mkdir -p /opt/napcat && cd /opt/napcat

然后用Docker跑起来（这里以x86架构为例）：

docker run -d \ --name napcat \ --restart=always \ -p 8080:3000 \ -p 9000:3001 \ -v /opt/napcat/config:/app/config \ -v /opt/napcat/qq:/root/.config/QQ \ -e MODE=ws \ -e WS_ENABLE=true \ -e WS_PORT=3001 \ --network=host \ mlikiowa/napcat-docker:latest

说到--network=host我得解释一下。如果用默认的bridge网络模式，容器内的localhost和宿主机是隔离的，后续我们的Python机器人服务访问NapCat的WebSocket端口时，就需要填容器IP或者做端口映射。用host模式最省事，容器直接共享宿主机的网络栈，localhost:3001就是NapCat的WebSocket服务地址。

不过这个镜像的配置方式时不时会更新，我更推荐启动容器之后直接用WebUI来配置。启动后用浏览器访问http://你的服务器IP:8080，第一次会让你扫码登录QQ，用手机QQ扫一下，登录成功之后就能看到管理界面。在WebUI里配置WebSocket服务器监听端口、上报地址，把上报地址填成ws://localhost:9001/ws，这个地址指向后面要部署的智能体服务，作用是把QQ消息推给智能体。这里填错了后面就收不到消息，建议多检查一遍。

还有个经验：用一个小号QQ专门做机器人，不要拿自己的主号。原因很简单，万一触发风控被限制登录，损失的只是一个小号。另外新注册的QQ号建议先养几天，每天登录一下聊聊天，立刻拿去做机器人容易异常。

3.3 检验消息通道是否打通

NapCat配好之后，先别急着去连Deepseek，先确认QQ消息到底能不能到达服务器。这里建议先用一个现成的WebSocket调试工具，或者干脆用Python快速写一个WebSocket测试服务，监听9001端口，把收到的消息原样打印出来。

# test_ws.py import asyncio import websockets async def handler(websocket): async for message in websocket: print(f"收到消息: {message}") async def main(): async with websockets.serve(handler, "0.0.0.0", 9001): print("WebSocket监听端口 9001") await asyncio.Future() asyncio.run(main())

跑起来之后发一条QQ消息给机器人，如果终端打印出了一段JSON，里面包含发送者的QQ号、消息内容、消息类型等字段，那说明通道已经通了。这一步是最关键的里程碑，它意味着后面的所有智能体逻辑都有了落地的管道。

4. 接入Deepseek：把“能收消息”变成“会聊天”

通道通了只是第一步，接下来才是重头戏：让QQ收到消息之后，知道调用Deepseek API，然后把回复发回去。这个逻辑我们用Python写，Python生态里不管是调API还是做WebSocket服务都足够成熟。

4.1 申请Deepseek API并理解计费逻辑

先去Deepseek开放平台注册账号，然后在后台创建一个API Key。创建之后记得马上复制保存，因为key只在创建时显示一次。

Deepseek的API接口和OpenAI兼容，所以你可以用openai这个Python库直接调用，也可以直接用requests手动发HTTP请求。我个人习惯用openai库，代码更简洁。计费上，Deepseek按输入和输出token分别计价，价格非常便宜，主要用的是deepseek-chat模型（对应Deepseek-V3系列）。我自己的用量，每天聊几十上百条，一个月下来也就几块钱人民币，基本约等于白嫖。

这里给个成本估算公式，方便你心里有数：

月成本 ≈ 日均消息数 × 平均每条消息的token消耗 × 单价 × 30

比如日均100条消息，每条消息平均消耗500个token（包含上下文），价格按输入0.5元/M token、输出2元/M token算，一个月也就几块钱。哪怕再加100倍的用量，还是远低于一杯咖啡的价格。

4.2 构建带上下文的对话引擎

如果每次收到消息都只是单独调一次API，那这个智能体就是个“没有记忆的客服”。要让对话连贯，必须做上下文管理。

目前最常见的做法是维护一个消息历史列表，每次请求把最近N轮对话一起发给模型。下面是我在项目里使用的一个极简实现：

from openai import OpenAI import json client = OpenAI( api_key="你的API Key", base_url="https://api.deepseek.com" ) # 系统提示词 system_prompt = """你是一个住在QQ里的私人智能体，名叫小助手。 你的风格是：友好、简洁、实用。 当用户提出复杂问题时，先拆解思路再给答案。 当用户聊天时，用自然的语气回应，不要总是说\"作为一个AI\"。""" # 维护每个QQ用户的上下文，key是QQ号 conversations = {} def get_reply(user_id, user_message): if user_id not in conversations: conversations[user_id] = [ {"role": "system", "content": system_prompt} ] conversations[user_id].append({"role": "user", "content": user_message}) # 控制上下文长度，最多保留最近20条消息 if len(conversations[user_id]) > 21: conversations[user_id] = [conversations[user_id][0]] + conversations[user_id][-20:] response = client.chat.completions.create( model="deepseek-chat", messages=conversations[user_id], max_tokens=1024, temperature=0.7 ) reply = response.choices[0].message.content conversations[user_id].append({"role": "assistant", "content": reply}) return reply

这段代码里有两个关键设计点值得展开讲：

第一是上下文窗口管理。很多人一开始不限制历史消息数量，聊了几天之后把整段历史全部发给模型，第一个出现问题的是token消耗不断变大，第二个是Deepseek的上下文窗口有上限，一旦超出就报错。我限制最近20轮，既保证对话连贯性，又控制成本和错误率。

第二是系统提示词的分隔。conversations字典里始终保留第一条system消息，后续追加的都是user和assistant消息。OpenAI兼容接口要求一个对话里只能有一条system消息且必须在最前面，如果每次把系统提示词重复追加进去，模型行为会变得混乱。

4.3 增加“工具调用”：让智能体能查天气、算数学

只会纯聊天的智能体上限有限。Deepseek（以及大多数先进模型）支持function calling，也就是你声明一个函数，模型在判断需要用到这个函数时会返回一个调用请求，然后你来执行这个函数，把结果回传给模型，模型再基于结果生成最终回复。

这就像是你雇了一个聪明的助理，他不知道自己办公室的窗外天气，但知道“我手上有一部电话可以打给天气预报台”。他先打电话（调用工具）拿到结果，再告诉你“今天出门带伞”。

我们给智能体加一个最简单的工具：获取当前时间。同样是上面那段代码，扩展成支持工具调用：

tools = [ { "type": "function", "function": { "name": "get_current_time", "description": "获取用户当前的日期和时间", "parameters": { "type": "object", "properties": {}, "required": [] } } } ] def call_deepseek_with_tools(messages, user_id): response = client.chat.completions.create( model="deepseek-chat", messages=messages, tools=tools, tool_choice="auto" ) return response

实际使用体验中，加了工具调用之后，智能体回答问题的方式会发生很明显的变化。最直观的一个场景是：你问“现在几点了”它不再靠猜，而是真的执行了一次时间获取。从这个基础上往后扩，可以继续加“查天气”“搜网页”“记事本”等功能，每个功能都是往tools列表里加一个声明，再写对应的执行函数就行。这套扩展机制也是我后来推荐所有人优先掌握的能力——它是智能体从“聊天机器人”走向“助理”的分水岭。

4.4 把对话引擎接到OneBot协议上

第3章我们验证了WebSocket通道能收到QQ消息，第4章我们有了对话引擎，现在把它们黏合成一个完整的机器人服务。这里我用aiocqhttp这个库，它是专门对接OneBot协议的Python异步框架：

from aiocqhttp import Event, CQHttp bot = CQHttp(host="0.0.0.0", port=9001) @bot.on_message("private") async def handle_private_message(event: Event): user_id = str(event.user_id) user_message = event.message.extract_plain_text() reply = get_reply(user_id, user_message) await bot.send(event, reply, at_sender=False) @bot.on_message("group") async def handle_group_message(event: Event): # 只在消息包含"@机器人"时才处理，避免群聊刷屏 if event.message_type == "group": raw_msg = event.message.extract_plain_text().strip() # 假设机器人在群里被@时会带上CQ码，这里简单处理成包含特定触发词 if "小助手" not in raw_msg and not event.is_tome(): return user_id = str(event.user_id) reply = get_reply(user_id, raw_msg.replace("小助手", "").strip()) await bot.send(event, reply, at_sender=True) if __name__ == "__main__": bot.run(host="0.0.0.0", port=9001)

这里有几个坑必须提醒：

一是在aiocqhttp中，默认就是处理OneBot上报的事件，所以bot = CQHttp(host, port)这个port要监听在9001，和前面NapCat上报地址保持一致。

二是群聊场景如果不加触发条件，机器人会疯掉——群里每一条信息都来一次大模型回答，既浪费钱又招人烦。我自己的处理是只有“被@”或者消息里包含“小助手”这几个字才响应。

三是at_sender参数。私聊里设成False，避免回复时@引发多余的提示。群里通常设成True，这样别人知道你在叫它。

4.5 一个完整的回复链路调试案例

代码写完之后，建议用这种方式做一次端到端测试：

• 打开两个终端，一个跑Python服务，一个用tail -f跟踪日志。
• 用另一个QQ号给机器人发“你好，介绍下你自己”。
• 观察Python终端的日志，确认WebSocket收到的消息内容正确。
• 观察Deepseek API是否有调用，返回的reply是什么。
• 回到QQ对话框看是否收到了机器人回复。

这条链路里任何一步断了，都能通过日志定位到具体环节。我第一次跑的时候，发现QQ消息收到了，但Python端没有打印任何日志——后来检查是NapCat的WebSocket客户端连接失败，需要把上报地址设为ws://127.0.0.1:9001/ws而不是localhost，因为在某些环境里localhost解析会走到IPv6导致连接失败。改成IP后问题解决。

5. 部署上线与稳定性优化：从“能跑”到“7x24不掉线”

本地能跑通和服务器上稳定运行是两码事。这一章讲的是如何让机器人长期稳定运行，以及在异常情况下能自愈。

5.1 让机器人服务开机自启、崩溃自动重启

Python服务直接挂在终端里跑，中断SSH连接服务就挂了，这是新手最常犯的错误。解决方案有两个方案任选。

方案一：用nohup和&挂后台。简单但不够优雅。

cd /opt/bot nohup python3 bot.py > bot.log 2>&1 &

方案二：写systemd服务，实现开机自启和崩溃重启。在/etc/systemd/system/qqbot.service里写入：

[Unit] Description=QQ Bot Service After=network.target [Service] WorkingDirectory=/opt/bot ExecStart=/usr/bin/python3 /opt/bot/bot.py Restart=always RestartSec=5 [Install] WantedBy=multi-user.target

然后执行：

systemctl daemon-reload systemctl enable qqbot systemctl start qqbot

这里我强烈推荐方案二，因为Restart=always意味着即使进程因为未捕获的异常崩溃，systemd也会在5秒后自动拉起。有一次我凌晨3点改了代码引入了一个bug，机器人在半夜崩了，systemd自动重启了三轮，第二天我看日志才发现问题，但这期间用户感知到的最多是某几条消息没被回复。

同样，NapCat容器在启动时加了--restart=always，它能保证容器崩溃或服务器重启后自动拉起。所以整套服务在服务器层面是有自愈能力的。

5.2 日志管理：避免磁盘被日志塞满

跑久了之后会遇到一个问题：日志文件越来越大。Python服务里如果没控制日志输出，bot.log一个月能涨到几个GB。小机器磁盘只有40G，容易被日志撑爆。

我的做法是两段式：第一，在Python里使用logging模块设置日志级别和轮转；第二，配置一个crontab定时任务，把超过7天的日志文件清掉。

import logging from logging.handlers import RotatingFileHandler handler = RotatingFileHandler("bot.log", maxBytes=10*1024*1024, backupCount=5) logging.basicConfig(handlers=[handler], level=logging.INFO)

这样单个日志文件超过10MB就自动轮转，保留最近5份，磁盘占用被限制在60MB以内。

另外提醒一点，Docker容器本身也会产生日志，默认没有限制会一直增长。在/etc/docker/daemon.json里加上：

{ "log-driver": "json-file", "log-opts": { "max-size": "10m", "max-file": "3" } }

然后systemctl restart docker。这个配置能让每个容器的日志单文件不超过10MB且最多保留3份。这两招同时上，磁盘空间基本不用操心。

5.3 并发控制：防止多个消息同时触发导致资源耗尽

如果你的机器人被拉进一个活跃群，高峰期可能同时来几十条消息。Python的asyncio能并发处理多个请求，但Deepseek API有速率限制，而且你的服务器内存也有限。如果不加并发控制，可能出现两个问题：一是API返回429限流错误，二是服务器内存被并发占满。

我的做法是给Deepseek调用增加一个简单的信号量控制并发数：

import asyncio # 最多同时处理3个Deepseek请求 semaphore = asyncio.Semaphore(3) async def safe_get_reply(user_id, user_message): async with semaphore: # 这里是同步调用，可以在线程池里跑 loop = asyncio.get_running_loop() reply = await loop.run_in_executor(None, get_reply, user_id, user_message) return reply

asyncio.Semaphore(3)意味着同一时间最多只有3个请求在等待Deepseek响应，后面的请求排队。这样可以避免突发流量打爆API配额。如果你发现响应变慢，把这个数字调到5到10也行，但要同时观察服务器负载。2核2G的机器建议别超过5。

6. 常见问题与排错清单：这些坑我全踩过

这部分是把我在搭建和使用过程中遇到的典型问题汇总成一张速查表，你如果遇到类似情况，可以直接对照排查。

6.1 QQ登录、消息收发等核心故障

6.2 API调用相关的隐形坑

Deepseek API本身比较稳定，但在调用方式上有几个细节容易踩坑。

第一个是上下文里的system消息重复。我在第4章提过一次，这里再强调：如果每次请求都往messages列表里插入一条新的system消息，模型会“精分”，因为它会看到多条冲突的角色设定。

第二个是输入内容的长度控制。如果你在QQ里直接发一大段文本，比如粘贴了几千字的文章让模型做分析，要提前检查字符数对应的token量。Deepseek的上下文窗口是64K，看起来很大，但如果你频繁发送超长文本，很快就会把窗口占满。我的建议是在调用模型前做一个预检查，超过一定长度就截断或分片发送。

第三个是temperature参数。如果做创意写作、闲聊，设置0.7到0.9比较合适；如果做代码生成、数据处理，建议调到0.1到0.3，因为过高会让模型编造内容，过低会让回答变得机械。很多人用一套参数跑所有任务，有时候觉得模型“变笨了”，很可能就是temperature没调整。

6.3 服务器资源不足导致的“假死”

2核2G的机器跑这套方案本来绰绰有余，但如果你在同一台机器上还跑了其他Docker容器，比如数据库、网站，那内存就可能成为瓶颈。症状是：机器人服务进程还在，但响应变得极其缓慢，甚至整个SSH都卡住。

排查方式：

free -h # 查看内存使用 docker stats # 查看每个容器的资源占用

如果内存接近耗尽，优先考虑清理无用的容器，或者去掉不需要的服务，而不是先加内存。这台机器如果只是跑智能体，2G内存是非常充裕的。

6.4 关于QQ号安全与风控的经验

这个话题很多人不重视，但实际做起来影响特别大。我总结几点亲测有效的经验：

• 新QQ号不要立刻拉去测试风控接口，先正常聊天、加几个好友，养一周左右。
• 不要用机器人做营销类群发，这是触发风控的最快方式。
• 登录后避免频繁在异地IP切换——你的服务器IP是固定的，这其实是优势。
• 如果被限制登录，不要反复重试，等12小时再试，重试太频繁会延长封禁时间。
• 多准备一个备用QQ号，以便主登录号出问题能快速切换。

这套东西说到底是在QQ的灰色地带运行，所以一定控制使用频次，不要搞骚操作。对个人助理这个场景来说，一天几百条消息的量级，问题不大。

7. 功能的横向扩展：从聊天助手到多功能智能体

机器人稳定上线两周之后，我开始琢磨如何把“聊天助手”扩展成“多功能智能体”。这个阶段的核心思想是：让模型学会“用工具”，而不是所有问题都靠模型本身的参数记忆回答。

7.1 加一个有持久化存储的“记忆便签”

一种最简单的扩展是让智能体具备“记住你说的事”的能力。比如你说“帮我记住明天下午3点开会”，智能体把这条信息存到服务器的SQLite数据库里。下次你问“我明天有什么安排”，它自动查出并返回。

实现上，新增一个save_note工具函数，模型的调用链变成：

用户消息 -> 模型判断需要调用save_note -> 程序执行写数据库 -> 返回执行结果 -> 模型组织最终回复

不要小看这个功能。有了持久化存储之后，智能体从一个“每次对话都失忆”的工具变成了“有长期记忆的助理”。你可以让它记录你的快递单号、跟踪你的学习计划、帮你汇总某个人发的消息，等等。这让“私人”两个字有了真正的含义。

7.2 对接外部API：让它去查天气、查资讯

同理，你可以一个个接外部API。比如接和风天气API实现查天气，接一个新闻API实现查热点，接一个翻译API实现翻译。只要在tools列表里加声明，再写对应的调用函数即可。

我自己的实践是接了一个RSS解析脚本，让智能体能读我关注的几个博客的更新。每天下午5点它会主动给我发一条消息，汇总当天的新内容。这本质上就是一个低配版的“信息助理”，而它运行在这个Lighthouse+Deepseek+QQ的底座上。

扩展的过程中有一个经验：不要贪多，一次加一个功能，测试稳定了再加下一个。一次性接五六个工具，一旦某个工具报错，排查排查半天也定位不到是哪个环节出了问题。增量开发在这种个人项目里体验最好。

7.3 多会话场景：私聊和群聊采用不同“人格”

如果你的机器人在私聊和群聊里都工作，建议在后台维护两套上下文，或者至少在系统提示词里区分场景。私聊里它可以更随意、更像朋友；群聊里它要更克制、更正式，甚至可以增加“发言前确认自己是否被@”的约束。

我实际见过的错误案例是：有人在群里问了个技术问题，机器人立刻把群聊里所有历史消息都纳入上下文，然后生成了很长一段回答，把整个群刷屏了。这个问题的根源就是没有区分场景。我的处理方式是：群聊上下文只保留最近5条，而且只有当用户明确@机器人时才进行对话。

8. 这套方案背后的成本、性能与替代选项分析

聊完具体的搭建过程，我们来算一笔总账，看看这套方案到底值不值。

8.1 成本明细：每月真正花多少钱

以我自己用的配置为例：

合计下来，一个月成本在40到80元之间。如果只是个人使用，这个花费换来的是一台7x24小时在线的服务器和一个随时可用的智能体。横向对比那些按席位收费的AI助理SaaS，这个成本几乎可以忽略。

8.2 性能和稳定性实测数据

• 平均单条回复延迟：2到5秒（取决于模型响应速度和消息长度）。
• 7x24小时在线率：连续运行3个月，除了服务器例行维护外，没有主动宕机。
• 上下文窗口：可配置，维持最近20轮对话不会消耗过多token。
• 并发能力：2核2G机器配合信号量配置，同时服务5到10个重度用户没问题，群聊场景更多。

8.3 替代方案横向对比

如果你还在犹豫是否采用这套方案，可以参考下面的结论：

• 网页版Deepseek：零成本，但每次要打开浏览器、登录，没有上下文连续性，无法主动推送，不适合当“助理”。
• Coze/Dify平台：搭建快，内置不少插件，但定制性差，长期使用费用不稳定，数据隔离感弱。
• Telegram Bot + API：非常稳定，但国内用户使用Telegram有额外的访问门槛，不推荐作为主力。
• 自建Lighthouse+Deepseek+QQ：初期有一点搭建成本，但一旦跑通，稳定性和自由度都是最高的，长期来看性价比最好。

我自己在几个方案之间都折腾过，最终还是回到了这套组合上。QQ让我随时随地能触达它，Lighthouse让它永不下线，Deepseek给了它足够聪明的头脑，三个角色配合得刚刚好。

最后说一点个人体会吧。自从这套智能体跑起来之后，我对“AI工具”的看法发生了不小的变化。以前用网页版，总觉得AI是一个“需要专门打开的东西”；现在它住在QQ好友列表里，随时叫一声就能出来，这种“在场感”是完全不一样的体验。它帮我整理过长文、翻译过资料、核对过数据，也在我失眠的凌晨陪我理清楚过思路。它没有多惊艳，但它一直在那里。

如果你也想搭一套，从这篇文章的架构开始，一步一步来，不要着急。先跑通“能收发消息”，再加上“会调用模型”，最后慢慢加工具和记忆。过程中遇到任何问题都可以对照第6章的排查清单，大部分坑我都提前替你踩过了。如果你搭出了更有趣的玩法，欢迎回来分享。