南瓜丶奇迹师看到 Moltbot 在 GitHub 上挂着 7.6 万 Star 时，我第一反应是：又一个套壳聊天机器人。直到我真的把它部署到一台阿里云 ECS 上，才意识到这东西并不是“多轮对话玩具”，而是一套能把大模型、知识库、定时任务、群机器人、API 调用整合在一起的“AI 员工基础设施”。它解决的核心问题很现实：你已经能用 ChatGPT 或 DeepSeek 聊天，但企业真正需要的是一个能按你的制度、知识库和流程去自动完成重复工作的人，而不是一个只能空谈的对话框。
这篇文章不会跟你从概念讲到结构，我直接按一次真实的部署经历来写：从买阿里云服务器、配置域名证书，到用 Docker Compose 跑起 Moltbot，再接上大模型 API、上传知识库、接入钉钉群机器人。整个过程里我踩过的坑、调过的参数、反复确认过的安全项都会写出来。目标是让你按同样的步骤，最快 5 分钟把“核心服务”跑起来，后面接一个模型、传几份文档，它就能开始当你的数字员工用了。
1. 为什么要把 7.6 万 Star 的 Moltbot 接到自己的服务器上
1.1 聊天工具和 AI 员工之间缺的不是模型，而是工作流
如果你只给团队开一个 DeepSeek 网页版，很多人能拿它写邮件、改文案，但没人能拿它去查内部工单、统计昨天的订单量、把客服高频问题自动整理成表格。这不是大模型不够聪明，而是普通聊天页面没有权限、没有系统集成、没有定时触发、也没有持久化记忆。
Moltbot 这类项目的价值就在这个空档里。它本身不生产模型，而是把大模型能力变成了一个可以被“调度”的服务。你可以给它定义角色，告诉它“你是中文客服主管”；可以把公司产品手册传给它做知识库，让它回答时只基于这些资料；可以写一个定时任务，让它每天早上九点去查数据库、生成日报、再把日报推送到钉钉群。甚至可以让它调用外部 API，去创建任务、查询订单状态、更新表格。聊完之后，输出不只是一段文字，而是一个被执行过的动作。
1.2 自部署对数据安全和定制能力的实际意义
市面上类似能力的 SaaS 产品不少，但我选择自己部署 Moltbot，核心原因是数据边界。企业内部的客服聊天记录、客户资料、项目文档，如果全部过一遍第三方平台，哪怕对方承诺加密，合同审核、法务风险、客户隐私保护这些关卡也很难完全安心。Moltbot 部署在阿里云自己的 ECS 里，数据库、向量知识库、模型调用的日志都落在我自己的服务器上，这一点对很多团队来说是刚需。
另一个原因是定制空间。开源项目部署到自己的环境后，改 Prompt、调超参、加插件、定制数据库字段都不受影响。Moltbot 能很快在网上收获这么多 Star，社区贡献的插件和工作流模板也是一部分原因。部署到本地后，你能直接修改它的配置文件、增加新的环境变量、集成自己公司的登录系统，这些自由度是任何封闭云服务都给不了的。
1.3 它适合哪些人、不适合哪些人
我建议这几种情况优先考虑 Moltbot：一是公司里文档资料多、问答重复度高的客服/HR/IT 支持场景；二是需要定时整理数据、自动生成报告的日常运营场景；三是已经有大模型 API 额度，但缺一个“工作流编排层”的技术团队。
但如果你的需求只是“偶尔翻译一段话”“写一封会议纪要”，那完全没必要为了它买一台服务器，直接用现成的在线对话产品更省事。Moltbot 的部署和维护成本是真实存在的，你得会看日志、管 Docker、关注磁盘占用，还需要持续维护知识库和 Prompt。把它当工具箱里的员工用，才能体现价值；把它当万能问答网页用，只会觉得哪里都别扭。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 部署前准备：ECS 规格、系统初始化、域名与 SSL 证书
2.1 买一台什么配置的阿里云 ECS 才够用
我最初用的是 2 核 4G 的轻量应用服务器，部署完 Moltbot 接入云厂商的模型 API，跑客服问答和定时任务完全够用。后来加了本地向量模型做知识库索引，内存到 4G 后开始紧张，换成了 4 核 8G。如果你不打算在服务器上直接跑大模型，只把 Moltbot 当作调度和对话入口，那么 2 核 4G 起步就够了；团队并发超过二三十人，或者会上传大量文档做向量检索，建议直接选 4 核 8G。
| 使用场景 | 推荐规格 | 带宽 | 说明 |
|---|---|---|---|
| 个人体验、轻问答 | 2核4G | 3M~5M | 只接云端 API，知识库较小 |
| 团队试用、接入群机器人 | 2核4G~4核8G | 5M | 需处理几十人内并发 |
| 知识库较大、自定义插件多 | 4核8G以上 | 5M~10M | 向量检索、定时任务会占内存 |
| 额外跑 7B 本地模型 | 8核16G起步，最好带 GPU | 按需 | 建议单独一台机器，不和应用抢资源 |
地域选择主要看你的目标用户在哪。公司业务在国内，就选华东杭州、华北北京或华南深圳；用户集中在海外再考虑新加坡等节点。系统镜像我建议选 Ubuntu 22.04 LTS 或 Alibaba Cloud Linux 3，两者对 Docker 支持和软件包更新都比较友好。版本不要选太旧的，Moltbot 新版镜像对内核和 glibc 没有太苛刻的要求，但 Ubuntu 20.04 和 22.04 之间我还是推荐后者，遇到问题也更容易搜到解决方案。
2.2 安全组端口规划：少开放一个端口就少一分风险
阿里云的安全组是 ECS 外部的第一道防火墙，它的规则和服务器内部防火墙是独立的。很多新手只配了安全组，却在 Ubuntu 里启用了 ufw 后忘了放行，结果端口死活连不上。反过来，也有人只在服务器内部放行了端口，但安全组没开，一样访问不了。这两层是“与”的关系，要同时放行才算有效。
核心开放原则是：普通 Web 服务只暴露 80 和 443；SSH 的 22 端口尽量改成只允许你自己的办公网 IP 访问，或者直接使用密钥登录而不用密码。Moltbot 的 Web 管理界面本身可能监听 8000 或 8080 这类端口，但我不建议把那个端口直接暴露到公网，原因是等会儿会用 Nginx 做反向代理，外部只访问 443 的 HTTPS 端口，内部容器端口不直接对公网开放，能挡掉大量扫描和攻击。
| 端口 | 用途 | 建议 |
|---|---|---|
| 22 | SSH 登录 | 仅放行你的办公 IP，禁用密码登录 |
| 80 | HTTP 跳转 | 开放，用于自动跳转到 HTTPS |
| 443 | HTTPS 访问 | 开放，Moltbot 主入口 |
| 8000/8080 | 容器内部服务 | 不对公网开放，仅本机回环即可 |
| 3306/5432/6379 | 数据库/缓存 | 严禁对公网开放 |
2.3 域名解析与免费 SSL 证书申请
Moltbot 如果要接入钉钉、飞书或企业微信的机器人回调，域名基本是刚需，因为平台在配置回调地址时不允许你随便填一个 IP，且 SSL 证书也更符合平台要求。没有域名的先用便宜的域名把服务跑通，再把正式域名解析到服务器公网 IP。解析记录类型选 A，记录值填 ECS 公网 IP，TTL 默认即可。
阿里云 SSL 证书服务里有免费的 DV 证书可供申请，选“单域名证书”，验证方式用 DNS 验证。证书签发后下载 Nginx 格式的证书文件，包含一个 .pem 证书文件和一个 .key 私钥文件。后面挂载给 Nginx 容器时，这两个文件路径一定不要写错，这是排查 HTTPS 问题时最容易出错的环节。
2.4 服务器初始化：用户、依赖、Docker 与镜像源配置
我习惯新服务器到手后先创建一个普通用户用于日常维护，而不是直接拿 root 干活。虽然简单粗暴地 root 一把梭也能跑，但万一 Web 管理面出了漏洞被拿下，攻击者拿到的就是最高权限。创建用户并加入 sudo 组，同时把公钥放到对应用户的 authorized_keys 里，SSH 登录时就方便很多。
接下来安装 Docker。在 Ubuntu 上可以直接用官方提供的 apt 仓库安装，或者使用系统软件源里的 docker.io。我更推荐 Docker 官方源，包版本较新。安装完 docker 和 compose 插件后，还要配置 registry mirror。Moltbot 的镜像一般托管在 Docker Hub，直接拉取在某些网络环境下速度不稳定，可以把阿里云容器镜像服务提供的专属镜像源地址写到 /etc/docker/daemon.json，然后重启 Docker 服务。这里注意，专属地址是每个账号独立的，需要登录阿里云容器镜像服务控制台查看，地址格式形如 https://<你的编码>.mirror.aliyuncs.com，不要照抄网上别人的地址。
3. 核心部署过程：用 Docker Compose 把 Moltbot 跑起来
3.1 获取项目和配置文件
Moltbot 官方仓库的 Releases 页面会提供发布包，里面通常已经有 docker-compose.yml 和 .env.example。如果你在 GitHub Releases 页面下载 tar 包，解压后放到 /opt/moltbot 目录；如果你更习惯用 git 拉代码，直接从 GitHub 仓库 clone 到 /opt/moltbot 也行。仓库内容不算大，拉取很慢的话可以使用浅克隆 --depth=1，只保留最新版本。
拿到配置模板后，第一件事不是急着启动，而是把 .env.example 复制成 .env，然后逐个填空。这个文件的格式是 KEY=VALUE，注意不要在值两侧加引号，除非值本身包含需要解释的特殊字符。.env 里往往会有一串随机密钥，例如 MOLTBOT_SECRET_KEY，它负责给登录 Session 和 Webhook 签名做加密。这个值至少要 32 个字符，不能使用默认值，否则部署到公网后很容易被别人猜出来伪造请求。
3.2 docker-compose.yml 里到底跑哪些服务
Moltbot 的 docker-compose 一般会包含几个固定角色：应用容器负责跑主程序；PostgreSQL 负责持久化用户、会话、任务配置等结构化数据；Redis 负责缓存和异步任务队列；Nginx 容器负责接收外部请求并反向代理到应用容器。也可能有向量数据库容器，取决于你用的知识库模块。
我直接给一份常见的 compose 配置文件作为参考：
yaml复制version: "3.8"
services:
app:
image: moltbot/moltbot:latest
restart: unless-stopped
env_file:
- .env
depends_on:
- db
- redis
volumes:
- ./storage:/data/storage
networks:
- moltbot-net
db:
image: postgres:15-alpine
restart: unless-stopped
environment:
POSTGRES_DB: moltbot
POSTGRES_USER: moltbot
POSTGRES_PASSWORD: change-me
volumes:
- db-data:/var/lib/postgresql/data
networks:
- moltbot-net
redis:
image: redis:7-alpine
restart: unless-stopped
command: redis-server --appendonly yes
volumes:
- redis-data:/data
networks:
- moltbot-net
nginx:
image: nginx:1.27-alpine
restart: unless-stopped
ports:
- "80:80"
- "443:443"
volumes:
- ./nginx.conf:/etc/nginx/conf.d/default.conf:ro
- ./certs:/etc/nginx/certs:ro
depends_on:
- app
networks:
- moltbot-net
volumes:
db-data:
redis-data:
networks:
moltbot-net:
driver: bridge
这里强调两点。第一，PostgreSQL 和 Redis 的数据目录必须用命名卷或挂载宿主机目录，否则容器一旦被删，你的账号、知识库索引、会话记录全部清空。第二，正式环境一定不要用我上面示例里的弱密码，PostgreSQL 的 POSTGRES_PASSWORD、Redis 如果开启了 requirepass，都需要改成足够长的随机字符串。密码不要直接写进 yml 文件，放到 .env 里再引用会更安全。
3.3 启动前需要检查的几个系统状态
启动前花两分钟检查内存、端口和时区，避免启动后报错再来回折腾。用 free -h 看内存是否满足 docker compose 里配置的容器要求；用 ss -lntp | grep -E '80|443' 看这几个端口有没有被占用，如果之前装了 Apache 或者宝塔面板，需要先停掉冲突服务；用 timedatectl set-timezone Asia/Shanghai 把系统时区改成北京时间，不然定时任务执行时间会差 8 个小时。
如果你准备把 .env 里的时区变量也设置一下，记得要和系统时区保持一致。Moltbot 的定时任务调度器通常读的是应用容器内的时区，很多部署教程没有提醒这一点，导致用户设置“每天早上九点执行”，实际却是在凌晨一点就跑完了，排查半天发现不是代码问题，纯粹是时区错位。
3.4 启动并验证核心服务
在 /opt/moltbot 目录下执行：
bash复制docker compose pull
docker compose up -d
第一次启动会拉镜像，时间取决于网络和镜像大小，所以标题说的 5 分钟是指“基于已经准备好的配置文件和已拉取镜像”的情况下，真正第一次从零开始通常要 10 分钟左右。up -d 跑完后执行 docker compose ps，如果状态列显示 running 或 healthy，说明核心容器起来了。再执行 docker compose logs -f app 查看应用日志，看到类似“server started”或“listen on 0.0.0.0:8000”的日志，就可以通过 http://服务器IP:8080 或后续配置的域名去访问后台。
访问后让你登录时，先查看 .env 里是否配置了初始化管理员账号。如果没有，一般需要在应用容器里执行类似 docker compose exec app moltbot create-admin 的命令来创建管理员，具体命令以你的版本为准。创建完管理员后用邮箱和密码登录，尽快在后台修改初始化密码。
3.5 首次启动常见的几个翻车点
我把自己真实跑过一遍遇到的状况整理成表格，方便你对照排查：
| 现象 | 可能原因 | 处理方式 |
|---|---|---|
| 容器启动后反复重启 | 内存不足、.env 缺少必填变量 | 看 docker compose logs app 日志，补全配置 |
| 数据库一直 unhealthy | 数据库数据卷权限问题 | 检查 db-data 卷归属，或者删除后重新初始化 |
| 页面提示 502 Bad Gateway | Nginx 没找到应用端口，或应用还在启动中 | 确认 compose 里 depends_on 条件，等待几秒刷新 |
| 登录后会话很快失效 | MOLTBOT_SECRET_KEY 没有持久固定，每次变更导致会话签名变化 | 将 .env 里的密钥固定下来，不要每次重新生成 |
| 外网访问不了后台 | 安全组/防火墙没放行 80/443 或映射端口 | 检查阿里云安全组和系统防火墙两层配置 |
4. 接上大脑：让 Moltbot 学会调用不同的模型服务
4.1 模型供应商配置的基本逻辑
Moltbot 不自己训练模型，它的做法是把大模型接口统一抽象成“模型供应商”，你可以添加多个供应商，然后对话、知识库、插件分别指定用哪个模型。这样做的好处是灵活：知识库总结要求质量高，用大参数模型；日常简单问答想省钱，用小模型；有些内部内容不想出服务器，就走本地模型。
以配置一个国产模型为例，在管理后台的“模型设置”页面填入三样东西：接口地址 Base URL、API Key、模型名称。只要模型服务商提供了 OpenAI 兼容接口，Moltbot 通常都能直接用，因为它底层走的是兼容协议，不需要单独开发适配代码。我之前用过阿里云的通义千问 API，Base URL 指向 DashScope 的兼容地址，模型名填 qwen-plus，API Key 填账户下创建的密钥，三分钟就能连通。
4.2 我为什么推荐先接云端 API 而不是本地模型
如果你不是专门研究私有化部署，我建议第一步先接云端 API。原因是成本和时间可控。2 核 4G 的 ECS 实例即便能跑通 Ollama，也只能加载很小的量化模型，回答质量远不如云端那么大参数的模型。而 Moltbot 本身消耗的内存已经不低，再让它在同一台机器上加载模型，很容易触发 OOM，进程被系统杀掉。
模型选型上，现阶段国内云厂商提供的 API 按量付费，性价比不错。客服问答、文档总结这类任务，单次消耗的 token 不大，每个月冲到几十块钱可能够一个小团队使用了。把 Moltbot 接到云端 API 能解决 80% 的需求，剩下的 20% 如果涉及严格的内部数据隔离，再考虑单独购置一台 GPU 服务器跑本地模型。
4.3 用 Ollama 跑本地模型时需要注意什么
如果确实要把模型部署在本地，我的建议是让模型和应用跑在不同机器上，或者至少给模型机器分配独立的内存和 GPU。单独一台机器安装 Ollama 非常方便，只需执行一行安装命令，然后拉取模型。Moltbot 在配置模型供应商时，填入这台机器的 IP 和端口 11434，例如 http://192.168.1.20:11434/v1，再填模型名称就可以了。
注意两点：Ollama 默认监听 127.0.0.1，如果要在另一台服务器上访问它，需要修改 Ollama 的环境变量 OLLAMA_HOST=0.0.0.0，同时设置防火墙只允许内网 IP 或 Moltbot 所在服务器 IP 访问 11434 端口。我见过有人图省事，把 11434 直接暴露到公网，结果被外面的人扫描到后疯狂拉模型，带宽和显卡资源都被耗光。本地模型再省，也不应该用公网裸奔换取配置便利。
4.4 员工角色设定：Prompt 写得好，它才是真正的员工
很多人部署完 Moltbot 后随便在对话界面问两句，发现回答“也就那样”，就跑来抱怨项目不行。实际上问题出在角色设定上。Moltbot 后台的角色配置实际上是 Prompt 工程，你给它的身份边界越明确，表现越稳定。
我这边一个实际运行的角色例子是给公司客服团队用的：
text复制你是公司的客服助理小M，具备耐心、严谨的性格。
你只能基于系统知识库里的资料回答用户问题；如果知识库里没有答案，不要编造，要告诉用户“这个问题我需要转给人工客服处理”。
回答时先给出结论，再补充依据，控制在 200 字以内。
同时我会把温度参数调成 0.2 或更低，避免模型自由发挥。很多“AI 员工”回答不靠谱，不是模型不行，而是没有规定行为边界，也没有禁止幻觉。Prompt 里一句“不能编造”加上低温度系数，效果立竿见影。
5. 让它真正“上班”：知识库、定时任务与群聊机器人接入
5.1 把内部文档变成它能查询的知识库
Moltbot 的知识库模块本质上是把文档切分、向量化、存到向量存储里，用户提问时先做相似度检索，再把检索结果和问题一起交给大模型生成答案。所以知识库资料的质量，直接决定了回答效果。
我在实际使用中比较推荐的文档类型是 Markdown、TXT 或 PDF，文本要干净，不要直接传一堆带水印或扫描图片的 PDF。上传前先把文档分门别类，例如“产品介绍”“售后政策”“常见问题”分开建知识库，不要全部塞一个库里。文档切分长度也需要根据内容调整：短文档用默认分段没问题，长表格类型的文档如果分段太大，检索效果会变差。你可以先在后台测试几个典型问题，看检索命中的片段是否准确，再进行微调。
5.2 定时任务：自动生成日报、定时推送内容
定时任务是 Moltbot 从“问答工具”变成“AI 员工”的关键功能。它可以按 cron 表达式触发一个工作流或对话，比如周一至周五早上 8:50 自动拉取数据库里前一天的订单数量，按照模板生成日报文本，再推送到指定钉钉群。你不需要会写复杂代码，只需要在后台配置触发时间和执行动作。
配置时有几个细节容易忽略。第一，cron 表达式的时区是容器时区，不是你的浏览器时区，所以前面强调的系统时区和容器时区要提前统一。第二，定时任务调用的模型参数、知识库角色最好单独指定，避免和普通用户问答任务一起排队。第三，任务失败时最好开启失败通知，否则你以为日报已经发出去了，实际群里空空如也也没人发现，等老板问起来才一拍大腿。
5.3 把 Moltbot 接入钉钉、飞书或企业微信
Moltbot 接入群机器人的价值很明显：让业务同事直接在群里 @ 机器人提问，不用再单独打开一个管理后台。我在团队里是接的钉钉，流程大概是：先在钉钉开放平台创建一个企业内部机器人，设置回调地址为 Moltbot 提供的 Webhook 地址，拿到 AppKey 和 AppSecret，填到 Moltbot 后台的渠道配置里。之后在群内添加机器人，成员就可以 @ 它提问了。
接入过程中最容易出问题的是回调地址必须能从公网访问，而且必须是 HTTPS。如果你还没配置域名 SSL，钉钉会提示“回调地址不合法”。另外，如果你的服务器在阿里云且打开了 Web 应用防火墙，记得把钉钉回调的 IP 段纳入白名单，否则平台调用你的机器人接口时可能被 WAF 拦截，表现为机器人时好时坏，非常难受。
5.4 一个已经跑通的真实场景：客服问答加日报自动生成
我这里举一个可以直接复用的组合场景。把产品说明书上传到知识库后，设置角色为一线客服。接下来在钉钉群里，业务同事可以直接问“XX 型号的设备怎么重置密码”，机器人能基于知识库给出操作步骤。遇到知识库里没有答案的问题，它会明确答复转人工，并把问题写入待处理列表。
同时我配置了一个 cron 任务，每天下午 17:30 汇总当天的未解决问题数量、高频关键词、平均响应时长，自动生成一段客服日报，推送到客服主管的钉钉群。主管每天早上不再需要手动问“昨天情况怎么样”，而是直接看机器人推来的信息。这个场景上线后，原来每天耗费一小时的人工汇总基本省掉了。Moltbot 单看任何一个功能似乎都不复杂，但把这些能力串起来，它承担的就是一个初级运营助理的工作。
6. 线上运行几天后，你必须处理的事情
6.1 日志怎么看、怎么定位问题
应用跑起来后，最无力的瞬间是用户说“机器人没反应”，你打开服务器却不知从哪查起。我的排查顺序非常固定：先看容器状态，再看应用日志，最后看模型调用日志。执行 docker compose ps 确认所有容器都在运行；执行 docker compose logs -f app --tail=200 看应用日志里最近有没有报错；执行被调用模型的访问日志，确认是不是 API Key 余额不足或触发了限流。
日志里常见的关键词包括 timeout（模型接口超时）、connection refused（数据库或 Redis 连不上）、401 Unauthorized（API Key 无效）、context length exceeded（输入内容超过模型上下文窗口）。看到超时不要急着甩锅模型，先用 curl 直接测一下模型接口时延，如果单独测也要 5 秒以上，就需要在 Moltbot 里调大请求超时时间，或者更换更快的大模型服务商。
6.2 数据备份怎么做才不心虚
Moltbot 里有三类数据需要关心：PostgreSQL 里的业务配置、账号、任务记录；Redis 里的缓存和任务队列；知识库向量数据和上传的原始文件。PostgreSQL 的数据是最核心的，可以每天凌晨用 pg_dump 把数据库导出到文件并同步到异机或对象存储；向量数据如果你用的是独立卷，可以随 docker 卷备份或定期打包。
最简单但不推荐的做法是直接拷贝 /opt/moltbot 目录。里面如果包含数据库容器数据卷，容器停止状态下备份才能保证一致性。我更建议用 docker compose 里定义的 alias 直接执行备份命令，例如：
bash复制docker compose exec -T db pg_dump -U moltbot moltbot > backup_$(date +%Y%m%d).sql
备份文件产生后，还要注意不要和数据库放在同一台机器同一块盘里。云服务器磁盘故障是低概率事件，但一旦发生没有异地备份就全完了。可以写到阿里云 OSS，或者最简单用 crontab 每天传到另一台机器上，成本极低，收益很大。
6.3 升级镜像和版本回滚的保留手段
Moltbot 迭代速度很快，我建议不要频繁追新版本，但也别半年都不升级，主要安全修复就错过了。升级流程很常规：先备份数据库和 .env，然后拉取新镜像并重新创建容器：
bash复制docker compose pull
docker compose up -d
升级前把当前使用的镜像标签记录下来，比如 moltbot/moltbot:v1.2.3，如果升级后出现严重问题，可以修改 .env 或 .yml 中的标签回退到旧版本。Docker 不会立刻删除旧镜像，所以回滚一般是几分钟内能完成的。不要在生产环境使用 :latest 标签长期运行，因为无法保证每次重启读到哪个版本。
6.4 安全加固的常见事项
把 Moltbot 放上公网之前，有几件事我建议你直接规范化处理。SSH 登录改成密钥方式，禁用密码登录；PostgreSQL 端口不映射到宿主机公网；知识库里的隐私文件上传前做权限分级，不要让每个普通用户都能检索到所有文档；后台管理界面的账号开启强密码和两步验证，如果有 IP 白名单功能就把管理员入口限制在公司出口 IP 下。
还有云监控报警，在阿里云控制台给 ECS 配置 CPU、内存、磁盘使用率告警，设置 80% 阈值。因为 AI 类的知识库检索任务有时会瞬间吃满内存，如果没有监控告警，等到服务变得卡顿你才发现，往往已经晚了。实际使用中我最常后悔的就是没早点给服务器加磁盘扩容告警，日志和向量数据增长比预想快得多，一块 40G 数据盘不到三个月就写满了。
最后再分享一个小技巧：部署 Moltbot 这类开源项目时，把每次改动的 .env、docker-compose.yml、nginx.conf 都纳入 git 仓库管理。我在实际维护中吃过亏，改了某个环境变量后容器起不来，想回滚却记不清之前的值是什么，最后只能靠备份文件逐个比对。你只要把这些配置文件放进 Git，每次修改前先提交一个版本，出问题就能立刻 diff 出差异，定位效率提升不止一倍。