前阵子有个朋友问我能不能把自己团队内部那个天天刷屏的测试钉钉群改造成一个有问必答的 AI 助手。我说可以而且用 Docker 来安装运维这套东西会特别省事。今天这篇就来分享一个我刚搭完跑通的组合Docker 安装 MolBot接入钉钉DingTalk机器人再对接 DeepSeek 大模型。先简单介绍角色。MolBot 是钉钉消息和 DeepSeek 之间的一道桥它作为钉钉企业内部应用里的机器人服务端负责在群里接收成员 机器人 的消息提取文本后转发给 DeepSeek 的 Chat Completions 接口再把大模型生成的回复发回群聊。整个过程对使用者来说就是在群里 机器人 提了个问题十几秒后收到答案。为什么值得写成文章因为这条链路涉及的环节不少钉钉开放平台的应用配置、机器人事件订阅、DeepSeek 的 API Key、Docker 容器编排任何一个环节出错群里都是静悄悄的。我把这次部署过程中真正有效的步骤和踩过的坑整理出来适合手上已有钉钉企业或内部群、想低成本搭建 AI 群聊助手的同学参考也适合想搞懂容器化服务如何处理长连接事件的开发者。1. 先搞清楚这三个东西各自扮演什么角色1.1 为什么是 MolBot而不是直接用钉钉机器人 Webhook很多人第一次搜钉钉机器人会先看到自定义机器人 Webhook——它确实简单复制一个 Webhook 地址就能往群里发消息。但 Webhook 是单向的只能由你的程序主动 POST 消息到群里群成员在群里发的消息Webhook 收不到。要做群聊问答机器人核心问题不是如何发消息而是如何收群消息。钉钉开放的正式做法是在企业内部应用里启用机器人能力让应用订阅群聊消息事件。群成员 机器人 时钉钉把事件推送给你你的服务收到后再调用发消息接口回复。这中间的推送、接收、回复逻辑就是 MolBot 这类机器人网关服务的职责。我试了几个路线后觉得 MolBot 的价值主要有三块它把钉钉的消息协议封装了一层你不需要自己去碰一堆加解密和鉴权细节它预留了大模型后端接口DeepSeek 这类只暴露 HTTP API 的服务可以非常自然地对接它是可以无状态运行的放在 Docker 容器里进程退出或服务器重启后可以由 Docker 自动拉起不需要手工干预。所以这里说的 MolBot你可以理解成钉钉 AI 机器人的守护进程。如果你是基于官方 SDK 做的二次开发那么 MolBot 就是你装在容器里的那个业务进程名下面所有的部署逻辑都通用。1.2 消息从钉钉群到 DeepSeek 再到群里的完整路径用文字走一遍完整链路群成员在钉钉群中 机器人 并发送文本。钉钉服务端通过 Stream 长连接把消息事件推送给 MolBot。如果你选择的是传统回调模式则是推送到公网回调 URL下文会讲两者的取舍。MolBot 校验发送者身份和群信息取出消息内容再拼接最近几轮对话作为上下文。MolBot 构造 HTTP 请求调用 DeepSeek 的 chat/completions 接口模型参数默认 deepseek-chat。DeepSeek 返回生成结果MolBot 解析回复文本。MolBot 调用钉钉服务端的机器人发送消息接口把回复发回原群。群成员看到机器人的回答。这条链路里Docker 承担的是把环节 2 到 6 稳定跑起来的职责。容器内网络需要能访问两个外网服务钉钉的推送网关长连接和 DeepSeek 的 API 服务。除此之外没有别的外部依赖。这也意味着只要容器在跑、网络通畅机器人就是可用的。提示如果你准备用回调模式接收钉钉消息还需要一个公网可访问的 HTTPS 回调地址。而 Stream 模式是机器人主动建立长连接部署时可以少折腾公网回调这一环下文会详细展开。2. 部署前必须准备好的三样东西2.1 钉钉开放平台侧企业内部应用与机器人配置准备工作第一步是去钉钉开发者后台创建企业内部应用。这里说几个我实际操作中的关键点创建应用时填的名称会显示在机器人添加列表里可以起一个容易辨认的名字比如AI 小助手。进入应用详情后在应用能力里找到机器人选项添加企业内机器人。机器人支持发送文本、图片、卡片等消息类型问答机器人用文本就够了。然后是接收消息模式这一项最关键。在机器人配置里优先选择 Stream 模式长连接。如果后台只能看到 HTTP 回调模式那部署时就要确保容器所在服务器有公网 IP并且在网关层把回调路径转发到容器端口。Stream 模式的优势后面专门讲。配置完成后在应用凭证页面复制 AppKey 和 AppSecret。如果有多机器人场景可能还需要单独记录 BotCode单机器人一般留空即可。最后是权限。在权限管理里搜索并开通机器人相关权限。不同版本的开放平台权限点名称不完全一样常见的有获取群会话信息机器人发送消息等。这里要特别记住没开发送权限的典型表现是消息收得到回复发不出。另外一个很容易被忽略的点企业内部应用默认只有开发人员可用。要让普通群成员在群里添加机器人必须进入版本管理与发布设置好可用范围后发布一次。发布往往不是即时生效等一两分钟后去钉钉客户端刷新一下。2.2 DeepSeek API Key 与模型选择DeepSeek 的接入载体是 API Key。注册开放平台后在控制台创建Key 是一长串以 sk- 开头的字符串。创建后页面只完整展示一次建议马上复制到本地环境变量文件里不要截图发到聊天工具里。模型选择上机器人场景我默认用 deepseek-chat。它定位是通用对话模型响应快、成本低适合绝大多数群聊问答。另一个 deepseek-reasoner 是推理模型更适合数学、逻辑、代码分析但响应时间明显更慢费用也更高。我的建议是先跑通 deepseek-chat真有需要再切 reasoner。API 调用参数里除了 model还有 max_tokens、temperature。初次联调可以设置 max_tokens1024、temperature0.7。群聊场景不追求太强的随机性如果希望回答更稳定把 temperature 调到 0.3 左右会更合适。这个参数会在后面的环境变量配置里体现。注意API Key 等同于密码。大模型接口按 Token 计费如果 Key 泄露后被人拿去跑量可能产生不必要的费用。不要把 Key 写死在 docker-compose.yml 里推荐放在 .env 文件并且把 .env 加入 .gitignore。2.3 Docker 环境检查清单部署前花两分钟过一遍 Docker 环境能省去后面很多无效折腾Docker Engine 建议 20.10 以上Compose 使用 V2 语法也就是 docker compose 而不是 docker-compose 这种老命令。内存至少 512MB预留 1GB 更稳妥。MolBot 本身很轻但运行时加上 SDK 依赖会占一部分内存。磁盘 1GB 足够镜像加日志加数据都放得下。架构方面x86_64 最省事如果是 ARM 云主机要注意镜像是否提供对应架构版本。出网策略要确认容器能访问外网 443 端口。企业网络往往有防火墙白名单机制需要把钉钉和 DeepSeek 的域名加入出站白名单否则容器日志会一直报连接失败。时区建议在 Compose 里固定 TZAsia/Shanghai不然容器默认 UTC日志时间会和北京时间差 8 小时排查问题很容易误判。到这里三个必要的准备项就齐了钉钉应用凭证、DeepSeek API Key、正常的 Docker 环境。接下来就可以写编排文件。3. 用 Docker Compose 把 MolBot 拉起来3.1 目录规划与镜像选择我在服务器上习惯把所有状态放到固定目录方便备份和迁移。以 /opt/moltbot 为例/opt/moltbot ├── docker-compose.yml ├── .env ├── data/ # 会话上下文、历史记录 └── logs/ # 容器日志镜像这块如果 MolBot 有官方 Docker 镜像直接在 Compose 里引用镜像名和版本标签即可。如果没有现成镜像也可以从源码构建Dockerfile 很薄核心就是安装依赖并启动主进程。比如基于 Python 的写法大致是这样FROM python:3.11-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . EXPOSE 8080 CMD [python, main.py]构建命令docker build -t moltbot:latest .无论用现成镜像还是本地构建Compose 的逻辑都一致。下面统一用占位镜像名示意实际部署时替换成你拉取的镜像名即可。3.2 完整的 docker-compose.yml 示例以下是我实际使用的编排文件拿过来可以直接改环境变量用services: moltbot: image: your-registry.example.com/moltbot:latest container_name: moltbot restart: unless-stopped env_file: - .env environment: TZ: Asia/Shanghai MOLBOT_LOG_LEVEL: info ports: - 8080:8080 volumes: - ./data:/app/data - ./logs:/app/logs healthcheck: test: [CMD, curl, -f, http://localhost:8080/healthz] interval: 30s timeout: 5s retries: 3逐行解读几个关键配置restart: unless-stopped容器异常退出会自动拉起服务器重启后跟随 Docker 自启。这是长期运行机器人最重要的策略没有它宿主机一重启机器人就静默离线。env_file从 .env 读取环境变量避免密钥直接暴露在 Compose 文件里。ports8080 暴露出来主要用于健康检查和未来接 HTTP 回调。Stream 模式下钉钉消息本身不依赖这个端口。volumes把 data 和 logs 目录挂出来容器升级时状态不丢。healthcheck依赖镜像内置的 /healthz 端点。如果镜像没有这个端点把 healthcheck 整段删掉否则容器会被标记为 unhealthy。3.3 环境变量逐项解释与推荐值.env 文件内容如下DINGTALK_APP_KEYdingxxxxxxxxxxxxxxxx DINGTALK_APP_SECRET粘贴你的AppSecret DEEPSEEK_API_KEYsk-粘贴你的APIKey DEEPSEEK_MODELdeepseek-chat DEEPSEEK_MAX_TOKENS1024 DEEPSEEK_TEMPERATURE0.3 MOLBOT_PORT8080 TZAsia/Shanghai各变量含义和推荐值整理成表变量名必填说明推荐值DINGTALK_APP_KEY是钉钉企业应用 AppKey开发者后台复制DINGTALK_APP_SECRET是钉钉企业应用 AppSecret开发者后台复制DINGTALK_BOT_CODE否机器人编码多机器人时区分留空DEEPSEEK_API_KEY是DeepSeek 平台创建的 Keysk- 开头DEEPSEEK_BASE_URL否API 地址前缀https://api.deepseek.comDEEPSEEK_MODEL否对话模型名deepseek-chatDEEPSEEK_MAX_TOKENS否单次回复最大 Token 数1024DEEPSEEK_TEMPERATURE否采样随机性0.3MOLBOT_PORT否服务监听端口8080TZ否时区Asia/Shanghai这里专门提醒一句DEEPSEEK_BASE_URL 保持默认官方地址就好不要填写来路不明的自定义地址。API Key 一旦经过第三方服务对方就能看到你的完整请求内容风险和成本都不可控。3.4 启动、查日志、确认健康状态一切就绪后依次执行cd /opt/moltbot docker compose pull docker compose up -d docker compose ps查看实时日志docker compose logs -f --tail200正常启动时日志里会看到 Stream 连接建立成功的记录比如出现 stream connected 或 connection established 字样。如果容器立即退出先看日志再改配置不要反复 up -d。容器起来以后可以用健康检查确认主进程是活的curl http://localhost:8080/healthz到了这一步容器层面基本 OK。接下来去钉钉侧处理应用配置和群内添加这是新手最容易漏掉的地方。4. 钉钉侧的接入模式Stream 长连接省掉公网回调4.1 Stream 模式的工作原理钉钉机器人接收消息本质上只有两种路子。一种是传统回调模式你在开发者后台填一个 HTTPS 回调地址钉钉把群消息以 HTTP POST 的形式推送到那个地址。这意味着你必须在公网有一个可用域名而且证书有效否则事件推不过来。为了调试还得想办法让本地端口暴露到公网在企业网络环境里非常麻烦。另一种就是 Stream 模式机器人服务端主动向钉钉的推送网关发起 WebSocket 长连接连接建立后钉钉有新消息事件就通过这条连接推给应用。对部署方来说优点很直接不需要公网回调地址部署在云服务器、内网机器甚至 NAT 后面的环境都行不需要单独配置域名和 HTTPS 证书连接由 MolBot 主动维护断开后可以自动重连运维负担小。打个比方HTTP 回调像是你留了个门牌号等快递上门Stream 模式像是你自己派了个专员在快递公司驻场有件直接拎回来。后者对公网地址没有依赖容器部署体验好很多。需要说明的是不是所有后台版本都把 Stream 模式放在显眼位置。如果只能看到 HTTP 回调选项优先确认开发者后台是否在最新版有些旧后台需要升级应用版本后才会出现 Stream 模式。4.2 后台配置里容易被忽略的两处第一处是事件订阅。机器人要收到群聊消息光添加机器人还不够必须确认已经订阅了消息事件。如果后台提供事件订阅页签事件类型里要有机器人消息或类似选项。没有订阅群里不管怎么 MolBot 都不会收到任何推送。第二处是权限。发送消息的权限在权限管理里通常是独立权限点。我遇到过一种现象容器日志显示 DeepSeek 已经返回了回复但钉钉群里没有任何内容最后发现是发送消息的权限没开通。排查顺序上能收不能发优先怀疑权限完全收不到优先怀疑订阅和连接状态。4.3 发布应用与群里添加机器人的完整顺序企业内部应用必须发布并设置可用范围后群里才能正常添加使用在开发者后台进入版本管理与发布填写版本号、发布说明。设置可用范围一般选全员或者按部门和成员限定。提交发布等待生效。进入钉钉客户端目标群打开群设置、机器人、添加机器人在列表里找到刚发布的那个应用机器人。添加成功后群里会出现机器人头像这才具备被 的条件。一个常见的坑是在后台改了权限或机器人配置后没有重新发布版本。企业内部应用的许多配置改动都需要重新发布才生效改完记得再走一遍发布流程。5. 联调实录第一次在群里 机器人 会发生什么5.1 一条完整的第一轮对话日志我把日志级别调到 debug 后在群里 机器人发了句今天有什么安排容器日志大致是下面这个样子2025-01-15 10:00:01.231 INFO recv message | group测试群 | user张三 | text今天有什么安排 2025-01-15 10:00:01.410 INFO call deepseek | modeldeepseek-chat | max_tokens1024 2025-01-15 10:00:03.892 INFO deepseek response | status200 | usageprompt_tokens:120 completion_tokens:85 2025-01-15 10:00:03.990 INFO send reply | group测试群 | msgId5f8a...如果日志能走到 send reply 这一层群里的回复基本就稳了。哪一步缺失就顺着链条去查对应环节。这里的关键是日志必须一行一行看不要盯着最后一行就下结论。5.2 按症状定位的三个高频问题我整理了这次联调里踩到的三个问题直接用表格呈现症状最大嫌疑检查方式群里 了机器人容器完全没日志应用未发布 / 机器人没进群 / 事件订阅缺失看后台可用范围、群里机器人列表、事件订阅日志有 recv没有 deepseek 调用DEEPSEEK_API_KEY 错误或模型名错误检查 .env再手测 DeepSeek 接口日志有 deepseek response但群里没回复发送消息权限未开通 / 机器人被移出群查权限管理、重新添加机器人这里的通用排查套路是先看容器状态再看日志最后动配置。不要一上来就改环境变量否则很难判断是改动生效了还是本来就快好了。对于模型名错误这类问题我补充一个快速验证方式。拿 curl 直接测 DeepSeek 接口curl https://api.deepseek.com/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-xxx \ -d {model: deepseek-chat, messages: [{role: user, content: 你好}], max_tokens: 16}如果能正常返回内容说明 Key 和模型名没问题问题大概率在机器人配置或网络而不是 DeepSeek 侧。5.3 三个翻车细节时区、重启策略、日志驱动第一个细节是时区。默认状态下容器日志是 UTC 时间和北京时间差 8 小时。你下午三点 机器人日志却显示凌晨七点很容易误判成消息没到。在 Compose 里固定 TZAsia/Shanghai 后日志时间就正常了。第二个细节是重启策略。没有设置 restart 策略的容器在宿主机重启后不会自动起来机器人会一直处于离线状态。用 restart: unless-stopped 后Docker 会自动拉起容器钉钉侧的 Stream 长连接也会按 SDK 的逻辑自动重连。第三个细节是日志驱动与磁盘占用。容器默认的 json-file 日志驱动会一直累计日志群聊活跃时日志增长很快长期跑可能把磁盘填满。建议在 Compose 里限制日志文件大小logging: driver: json-file options: max-size: 10m max-file: 3加了这段配置日志会自动轮转排查问题的时候也能保留最近几份记录。6. 从跑通到跑稳上下文、限速与费用控制6.1 让机器人记住前几轮对话DeepSeek API 本身是无状态的每次调用都要把完整上下文放在 messages 数组里。要让机器人能接住刚才不是说……这类追问后端得自己缓存每个会话的历史。我用的方案会话 key 由群 ID 加发送人 ID 拼接避免群里不同人的问题串进同一段上下文缓存存到 data 目录下的 JSON 文件或 SQLite这样容器重启后历史还在每次请求前取最近 N 轮我设的是 6 轮超过后丢弃更早的轮次同时限制单轮文本长度历史过长时优先丢弃最长的消息。伪代码如下key f{group_id}:{user_id} history load_history(key) history.append({role: user, content: text}) history history[-6:] resp deepseek_chat(history) history.append({role: assistant, content: resp}) save_history(key, history)这里要强调上下文太长会同时拖慢响应速度和推高费用。即使 DeepSeek 的上下文窗口很大群聊机器人也不宜无限堆历史滑动窗口是性价比最高的做法。6.2 限流与冷却防止群聊刷屏打爆群聊场景和单聊不一样成员可能连续发好几条 如果每条都立刻请求大模型容易触发平台限频也会让机器人的回答前后打架。我加了两层控制第一层是单用户冷却。同一个用户两次请求间隔小于 5 秒直接忽略后续请求或者回复一个请稍候。实测下来这能过滤掉绝大多数手滑连发。第二层是全局并发控制。我把 MolBot 的并发请求数上限设为 2。超过上限的新请求进入等待队列或者直接丢弃让用户再 一次。对于企业内部测试群2 并发完全够用。如果你的机器人只希望在某些群生效可以再加群白名单配置。没在名单里的群收到消息后不调用 DeepSeek避免其他群误加机器人导致费用异常。6.3 费用估算与消费预警这部分直接说结论企业内部群聊问答机器人用 deepseek-chat 的日常开销很低。假设平均每轮对话消耗 1000 Token也就是 700 输入加 300 输出按公开的计费标准估算单轮成本大约在几分钱以内一天几千条也就几块钱量级。实际金额以开放平台账单为准。不过便宜不等于可以放任。我建议做三件事在 DeepSeek 开放平台设置余额或用量预警低于阈值主动通知把 max_tokens 控制在 512 到 1024 之间群聊回复太长没有意义在日志里记录每次响应的 usage 字段定期统计消费趋势出现异常能及时发现。如果这台服务器上还跑着其他服务也要防止 API Key 被误用。传参一律走 .env 文件不要出现在 shell 历史里更不要写进 CI 的明文日志中。最后分享两个我自己的运维习惯。第一我给这个机器人单独建了一个 runbook 文档里面记录了完整的环境变量、后台配置页面路径、常用排查命令和每次更新镜像的步骤。第二我把 docker-compose.yml 放进 Git 仓库但 .env 永远不提交改用 .env.example 做模板。这样就算哪天服务器要迁移只要把 data 目录和 .env 带过去在新机器上一条 docker compose up -d 就能复现整套服务。如果你也准备长期维护一个群聊 AI 机器人这两个习惯应该能帮你省下不少时间。
前阵子有个朋友问我能不能把自己团队内部那个天天刷屏的测试钉钉群改造成一个有问必答的 AI 助手。我说可以而且用 Docker 来安装运维这套东西会特别省事。今天这篇就来分享一个我刚搭完跑通的组合Docker 安装 MolBot接入钉钉DingTalk机器人再对接 DeepSeek 大模型。先简单介绍角色。MolBot 是钉钉消息和 DeepSeek 之间的一道桥它作为钉钉企业内部应用里的机器人服务端负责在群里接收成员 机器人 的消息提取文本后转发给 DeepSeek 的 Chat Completions 接口再把大模型生成的回复发回群聊。整个过程对使用者来说就是在群里 机器人 提了个问题十几秒后收到答案。为什么值得写成文章因为这条链路涉及的环节不少钉钉开放平台的应用配置、机器人事件订阅、DeepSeek 的 API Key、Docker 容器编排任何一个环节出错群里都是静悄悄的。我把这次部署过程中真正有效的步骤和踩过的坑整理出来适合手上已有钉钉企业或内部群、想低成本搭建 AI 群聊助手的同学参考也适合想搞懂容器化服务如何处理长连接事件的开发者。1. 先搞清楚这三个东西各自扮演什么角色1.1 为什么是 MolBot而不是直接用钉钉机器人 Webhook很多人第一次搜钉钉机器人会先看到自定义机器人 Webhook——它确实简单复制一个 Webhook 地址就能往群里发消息。但 Webhook 是单向的只能由你的程序主动 POST 消息到群里群成员在群里发的消息Webhook 收不到。要做群聊问答机器人核心问题不是如何发消息而是如何收群消息。钉钉开放的正式做法是在企业内部应用里启用机器人能力让应用订阅群聊消息事件。群成员 机器人 时钉钉把事件推送给你你的服务收到后再调用发消息接口回复。这中间的推送、接收、回复逻辑就是 MolBot 这类机器人网关服务的职责。我试了几个路线后觉得 MolBot 的价值主要有三块它把钉钉的消息协议封装了一层你不需要自己去碰一堆加解密和鉴权细节它预留了大模型后端接口DeepSeek 这类只暴露 HTTP API 的服务可以非常自然地对接它是可以无状态运行的放在 Docker 容器里进程退出或服务器重启后可以由 Docker 自动拉起不需要手工干预。所以这里说的 MolBot你可以理解成钉钉 AI 机器人的守护进程。如果你是基于官方 SDK 做的二次开发那么 MolBot 就是你装在容器里的那个业务进程名下面所有的部署逻辑都通用。1.2 消息从钉钉群到 DeepSeek 再到群里的完整路径用文字走一遍完整链路群成员在钉钉群中 机器人 并发送文本。钉钉服务端通过 Stream 长连接把消息事件推送给 MolBot。如果你选择的是传统回调模式则是推送到公网回调 URL下文会讲两者的取舍。MolBot 校验发送者身份和群信息取出消息内容再拼接最近几轮对话作为上下文。MolBot 构造 HTTP 请求调用 DeepSeek 的 chat/completions 接口模型参数默认 deepseek-chat。DeepSeek 返回生成结果MolBot 解析回复文本。MolBot 调用钉钉服务端的机器人发送消息接口把回复发回原群。群成员看到机器人的回答。这条链路里Docker 承担的是把环节 2 到 6 稳定跑起来的职责。容器内网络需要能访问两个外网服务钉钉的推送网关长连接和 DeepSeek 的 API 服务。除此之外没有别的外部依赖。这也意味着只要容器在跑、网络通畅机器人就是可用的。提示如果你准备用回调模式接收钉钉消息还需要一个公网可访问的 HTTPS 回调地址。而 Stream 模式是机器人主动建立长连接部署时可以少折腾公网回调这一环下文会详细展开。2. 部署前必须准备好的三样东西2.1 钉钉开放平台侧企业内部应用与机器人配置准备工作第一步是去钉钉开发者后台创建企业内部应用。这里说几个我实际操作中的关键点创建应用时填的名称会显示在机器人添加列表里可以起一个容易辨认的名字比如AI 小助手。进入应用详情后在应用能力里找到机器人选项添加企业内机器人。机器人支持发送文本、图片、卡片等消息类型问答机器人用文本就够了。然后是接收消息模式这一项最关键。在机器人配置里优先选择 Stream 模式长连接。如果后台只能看到 HTTP 回调模式那部署时就要确保容器所在服务器有公网 IP并且在网关层把回调路径转发到容器端口。Stream 模式的优势后面专门讲。配置完成后在应用凭证页面复制 AppKey 和 AppSecret。如果有多机器人场景可能还需要单独记录 BotCode单机器人一般留空即可。最后是权限。在权限管理里搜索并开通机器人相关权限。不同版本的开放平台权限点名称不完全一样常见的有获取群会话信息机器人发送消息等。这里要特别记住没开发送权限的典型表现是消息收得到回复发不出。另外一个很容易被忽略的点企业内部应用默认只有开发人员可用。要让普通群成员在群里添加机器人必须进入版本管理与发布设置好可用范围后发布一次。发布往往不是即时生效等一两分钟后去钉钉客户端刷新一下。2.2 DeepSeek API Key 与模型选择DeepSeek 的接入载体是 API Key。注册开放平台后在控制台创建Key 是一长串以 sk- 开头的字符串。创建后页面只完整展示一次建议马上复制到本地环境变量文件里不要截图发到聊天工具里。模型选择上机器人场景我默认用 deepseek-chat。它定位是通用对话模型响应快、成本低适合绝大多数群聊问答。另一个 deepseek-reasoner 是推理模型更适合数学、逻辑、代码分析但响应时间明显更慢费用也更高。我的建议是先跑通 deepseek-chat真有需要再切 reasoner。API 调用参数里除了 model还有 max_tokens、temperature。初次联调可以设置 max_tokens1024、temperature0.7。群聊场景不追求太强的随机性如果希望回答更稳定把 temperature 调到 0.3 左右会更合适。这个参数会在后面的环境变量配置里体现。注意API Key 等同于密码。大模型接口按 Token 计费如果 Key 泄露后被人拿去跑量可能产生不必要的费用。不要把 Key 写死在 docker-compose.yml 里推荐放在 .env 文件并且把 .env 加入 .gitignore。2.3 Docker 环境检查清单部署前花两分钟过一遍 Docker 环境能省去后面很多无效折腾Docker Engine 建议 20.10 以上Compose 使用 V2 语法也就是 docker compose 而不是 docker-compose 这种老命令。内存至少 512MB预留 1GB 更稳妥。MolBot 本身很轻但运行时加上 SDK 依赖会占一部分内存。磁盘 1GB 足够镜像加日志加数据都放得下。架构方面x86_64 最省事如果是 ARM 云主机要注意镜像是否提供对应架构版本。出网策略要确认容器能访问外网 443 端口。企业网络往往有防火墙白名单机制需要把钉钉和 DeepSeek 的域名加入出站白名单否则容器日志会一直报连接失败。时区建议在 Compose 里固定 TZAsia/Shanghai不然容器默认 UTC日志时间会和北京时间差 8 小时排查问题很容易误判。到这里三个必要的准备项就齐了钉钉应用凭证、DeepSeek API Key、正常的 Docker 环境。接下来就可以写编排文件。3. 用 Docker Compose 把 MolBot 拉起来3.1 目录规划与镜像选择我在服务器上习惯把所有状态放到固定目录方便备份和迁移。以 /opt/moltbot 为例/opt/moltbot ├── docker-compose.yml ├── .env ├── data/ # 会话上下文、历史记录 └── logs/ # 容器日志镜像这块如果 MolBot 有官方 Docker 镜像直接在 Compose 里引用镜像名和版本标签即可。如果没有现成镜像也可以从源码构建Dockerfile 很薄核心就是安装依赖并启动主进程。比如基于 Python 的写法大致是这样FROM python:3.11-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . EXPOSE 8080 CMD [python, main.py]构建命令docker build -t moltbot:latest .无论用现成镜像还是本地构建Compose 的逻辑都一致。下面统一用占位镜像名示意实际部署时替换成你拉取的镜像名即可。3.2 完整的 docker-compose.yml 示例以下是我实际使用的编排文件拿过来可以直接改环境变量用services: moltbot: image: your-registry.example.com/moltbot:latest container_name: moltbot restart: unless-stopped env_file: - .env environment: TZ: Asia/Shanghai MOLBOT_LOG_LEVEL: info ports: - 8080:8080 volumes: - ./data:/app/data - ./logs:/app/logs healthcheck: test: [CMD, curl, -f, http://localhost:8080/healthz] interval: 30s timeout: 5s retries: 3逐行解读几个关键配置restart: unless-stopped容器异常退出会自动拉起服务器重启后跟随 Docker 自启。这是长期运行机器人最重要的策略没有它宿主机一重启机器人就静默离线。env_file从 .env 读取环境变量避免密钥直接暴露在 Compose 文件里。ports8080 暴露出来主要用于健康检查和未来接 HTTP 回调。Stream 模式下钉钉消息本身不依赖这个端口。volumes把 data 和 logs 目录挂出来容器升级时状态不丢。healthcheck依赖镜像内置的 /healthz 端点。如果镜像没有这个端点把 healthcheck 整段删掉否则容器会被标记为 unhealthy。3.3 环境变量逐项解释与推荐值.env 文件内容如下DINGTALK_APP_KEYdingxxxxxxxxxxxxxxxx DINGTALK_APP_SECRET粘贴你的AppSecret DEEPSEEK_API_KEYsk-粘贴你的APIKey DEEPSEEK_MODELdeepseek-chat DEEPSEEK_MAX_TOKENS1024 DEEPSEEK_TEMPERATURE0.3 MOLBOT_PORT8080 TZAsia/Shanghai各变量含义和推荐值整理成表变量名必填说明推荐值DINGTALK_APP_KEY是钉钉企业应用 AppKey开发者后台复制DINGTALK_APP_SECRET是钉钉企业应用 AppSecret开发者后台复制DINGTALK_BOT_CODE否机器人编码多机器人时区分留空DEEPSEEK_API_KEY是DeepSeek 平台创建的 Keysk- 开头DEEPSEEK_BASE_URL否API 地址前缀https://api.deepseek.comDEEPSEEK_MODEL否对话模型名deepseek-chatDEEPSEEK_MAX_TOKENS否单次回复最大 Token 数1024DEEPSEEK_TEMPERATURE否采样随机性0.3MOLBOT_PORT否服务监听端口8080TZ否时区Asia/Shanghai这里专门提醒一句DEEPSEEK_BASE_URL 保持默认官方地址就好不要填写来路不明的自定义地址。API Key 一旦经过第三方服务对方就能看到你的完整请求内容风险和成本都不可控。3.4 启动、查日志、确认健康状态一切就绪后依次执行cd /opt/moltbot docker compose pull docker compose up -d docker compose ps查看实时日志docker compose logs -f --tail200正常启动时日志里会看到 Stream 连接建立成功的记录比如出现 stream connected 或 connection established 字样。如果容器立即退出先看日志再改配置不要反复 up -d。容器起来以后可以用健康检查确认主进程是活的curl http://localhost:8080/healthz到了这一步容器层面基本 OK。接下来去钉钉侧处理应用配置和群内添加这是新手最容易漏掉的地方。4. 钉钉侧的接入模式Stream 长连接省掉公网回调4.1 Stream 模式的工作原理钉钉机器人接收消息本质上只有两种路子。一种是传统回调模式你在开发者后台填一个 HTTPS 回调地址钉钉把群消息以 HTTP POST 的形式推送到那个地址。这意味着你必须在公网有一个可用域名而且证书有效否则事件推不过来。为了调试还得想办法让本地端口暴露到公网在企业网络环境里非常麻烦。另一种就是 Stream 模式机器人服务端主动向钉钉的推送网关发起 WebSocket 长连接连接建立后钉钉有新消息事件就通过这条连接推给应用。对部署方来说优点很直接不需要公网回调地址部署在云服务器、内网机器甚至 NAT 后面的环境都行不需要单独配置域名和 HTTPS 证书连接由 MolBot 主动维护断开后可以自动重连运维负担小。打个比方HTTP 回调像是你留了个门牌号等快递上门Stream 模式像是你自己派了个专员在快递公司驻场有件直接拎回来。后者对公网地址没有依赖容器部署体验好很多。需要说明的是不是所有后台版本都把 Stream 模式放在显眼位置。如果只能看到 HTTP 回调选项优先确认开发者后台是否在最新版有些旧后台需要升级应用版本后才会出现 Stream 模式。4.2 后台配置里容易被忽略的两处第一处是事件订阅。机器人要收到群聊消息光添加机器人还不够必须确认已经订阅了消息事件。如果后台提供事件订阅页签事件类型里要有机器人消息或类似选项。没有订阅群里不管怎么 MolBot 都不会收到任何推送。第二处是权限。发送消息的权限在权限管理里通常是独立权限点。我遇到过一种现象容器日志显示 DeepSeek 已经返回了回复但钉钉群里没有任何内容最后发现是发送消息的权限没开通。排查顺序上能收不能发优先怀疑权限完全收不到优先怀疑订阅和连接状态。4.3 发布应用与群里添加机器人的完整顺序企业内部应用必须发布并设置可用范围后群里才能正常添加使用在开发者后台进入版本管理与发布填写版本号、发布说明。设置可用范围一般选全员或者按部门和成员限定。提交发布等待生效。进入钉钉客户端目标群打开群设置、机器人、添加机器人在列表里找到刚发布的那个应用机器人。添加成功后群里会出现机器人头像这才具备被 的条件。一个常见的坑是在后台改了权限或机器人配置后没有重新发布版本。企业内部应用的许多配置改动都需要重新发布才生效改完记得再走一遍发布流程。5. 联调实录第一次在群里 机器人 会发生什么5.1 一条完整的第一轮对话日志我把日志级别调到 debug 后在群里 机器人发了句今天有什么安排容器日志大致是下面这个样子2025-01-15 10:00:01.231 INFO recv message | group测试群 | user张三 | text今天有什么安排 2025-01-15 10:00:01.410 INFO call deepseek | modeldeepseek-chat | max_tokens1024 2025-01-15 10:00:03.892 INFO deepseek response | status200 | usageprompt_tokens:120 completion_tokens:85 2025-01-15 10:00:03.990 INFO send reply | group测试群 | msgId5f8a...如果日志能走到 send reply 这一层群里的回复基本就稳了。哪一步缺失就顺着链条去查对应环节。这里的关键是日志必须一行一行看不要盯着最后一行就下结论。5.2 按症状定位的三个高频问题我整理了这次联调里踩到的三个问题直接用表格呈现症状最大嫌疑检查方式群里 了机器人容器完全没日志应用未发布 / 机器人没进群 / 事件订阅缺失看后台可用范围、群里机器人列表、事件订阅日志有 recv没有 deepseek 调用DEEPSEEK_API_KEY 错误或模型名错误检查 .env再手测 DeepSeek 接口日志有 deepseek response但群里没回复发送消息权限未开通 / 机器人被移出群查权限管理、重新添加机器人这里的通用排查套路是先看容器状态再看日志最后动配置。不要一上来就改环境变量否则很难判断是改动生效了还是本来就快好了。对于模型名错误这类问题我补充一个快速验证方式。拿 curl 直接测 DeepSeek 接口curl https://api.deepseek.com/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-xxx \ -d {model: deepseek-chat, messages: [{role: user, content: 你好}], max_tokens: 16}如果能正常返回内容说明 Key 和模型名没问题问题大概率在机器人配置或网络而不是 DeepSeek 侧。5.3 三个翻车细节时区、重启策略、日志驱动第一个细节是时区。默认状态下容器日志是 UTC 时间和北京时间差 8 小时。你下午三点 机器人日志却显示凌晨七点很容易误判成消息没到。在 Compose 里固定 TZAsia/Shanghai 后日志时间就正常了。第二个细节是重启策略。没有设置 restart 策略的容器在宿主机重启后不会自动起来机器人会一直处于离线状态。用 restart: unless-stopped 后Docker 会自动拉起容器钉钉侧的 Stream 长连接也会按 SDK 的逻辑自动重连。第三个细节是日志驱动与磁盘占用。容器默认的 json-file 日志驱动会一直累计日志群聊活跃时日志增长很快长期跑可能把磁盘填满。建议在 Compose 里限制日志文件大小logging: driver: json-file options: max-size: 10m max-file: 3加了这段配置日志会自动轮转排查问题的时候也能保留最近几份记录。6. 从跑通到跑稳上下文、限速与费用控制6.1 让机器人记住前几轮对话DeepSeek API 本身是无状态的每次调用都要把完整上下文放在 messages 数组里。要让机器人能接住刚才不是说……这类追问后端得自己缓存每个会话的历史。我用的方案会话 key 由群 ID 加发送人 ID 拼接避免群里不同人的问题串进同一段上下文缓存存到 data 目录下的 JSON 文件或 SQLite这样容器重启后历史还在每次请求前取最近 N 轮我设的是 6 轮超过后丢弃更早的轮次同时限制单轮文本长度历史过长时优先丢弃最长的消息。伪代码如下key f{group_id}:{user_id} history load_history(key) history.append({role: user, content: text}) history history[-6:] resp deepseek_chat(history) history.append({role: assistant, content: resp}) save_history(key, history)这里要强调上下文太长会同时拖慢响应速度和推高费用。即使 DeepSeek 的上下文窗口很大群聊机器人也不宜无限堆历史滑动窗口是性价比最高的做法。6.2 限流与冷却防止群聊刷屏打爆群聊场景和单聊不一样成员可能连续发好几条 如果每条都立刻请求大模型容易触发平台限频也会让机器人的回答前后打架。我加了两层控制第一层是单用户冷却。同一个用户两次请求间隔小于 5 秒直接忽略后续请求或者回复一个请稍候。实测下来这能过滤掉绝大多数手滑连发。第二层是全局并发控制。我把 MolBot 的并发请求数上限设为 2。超过上限的新请求进入等待队列或者直接丢弃让用户再 一次。对于企业内部测试群2 并发完全够用。如果你的机器人只希望在某些群生效可以再加群白名单配置。没在名单里的群收到消息后不调用 DeepSeek避免其他群误加机器人导致费用异常。6.3 费用估算与消费预警这部分直接说结论企业内部群聊问答机器人用 deepseek-chat 的日常开销很低。假设平均每轮对话消耗 1000 Token也就是 700 输入加 300 输出按公开的计费标准估算单轮成本大约在几分钱以内一天几千条也就几块钱量级。实际金额以开放平台账单为准。不过便宜不等于可以放任。我建议做三件事在 DeepSeek 开放平台设置余额或用量预警低于阈值主动通知把 max_tokens 控制在 512 到 1024 之间群聊回复太长没有意义在日志里记录每次响应的 usage 字段定期统计消费趋势出现异常能及时发现。如果这台服务器上还跑着其他服务也要防止 API Key 被误用。传参一律走 .env 文件不要出现在 shell 历史里更不要写进 CI 的明文日志中。最后分享两个我自己的运维习惯。第一我给这个机器人单独建了一个 runbook 文档里面记录了完整的环境变量、后台配置页面路径、常用排查命令和每次更新镜像的步骤。第二我把 docker-compose.yml 放进 Git 仓库但 .env 永远不提交改用 .env.example 做模板。这样就算哪天服务器要迁移只要把 data 目录和 .env 带过去在新机器上一条 docker compose up -d 就能复现整套服务。如果你也准备长期维护一个群聊 AI 机器人这两个习惯应该能帮你省下不少时间。
