ClawdBot保姆级部署指南：零配置运行Telegram全能翻译机器人

Ne0inhk

— 13 min read

ClawdBot保姆级部署指南：零配置运行Telegram全能翻译机器人

你是否试过在 Telegram 群里发一条中文消息，想让外国朋友立刻看懂，却要先复制、切到翻译 App、再粘贴、再发回群？又或者收到一张模糊的菜单图，想快速知道价格和菜品，却得手动打字识别？更别说语音留言听不清、汇率临时查不到、天气预报找不到入口……这些日常小痛点，本不该消耗你的时间。

ClawdBot 不是另一个“概念型”AI项目。它是一个真正能装进你本地设备、开箱即用、不依赖云服务、不上传隐私数据的个人 AI 助手。而它的核心能力，正由 vLLM 高效驱动——这意味着你在树莓派上也能跑起 4B 级别大模型，响应快、显存省、推理稳。它不追求参数堆砌，只专注一件事：把复杂技术藏在背后，把简单好用交到你手上。

但今天这篇文章，我们不聊架构设计，也不讲模型微调。我们要一起完成一件非常实在的事：5 分钟内，在你自己的机器上，跑起一个真正能翻译语音、识别图片、查天气、换汇率、还能自动响应群聊的 Telegram 全能翻译机器人。全程无需改一行代码，不用配环境变量，连 Docker 镜像都已打包好——你只需要一条命令，和一点耐心读完这篇指南。

1. 为什么是 ClawdBot + MoltBot？不是别的方案？

在动手前，先花两分钟理清一个关键问题：市面上已有不少 Telegram 翻译 Bot，为什么还要自己部署一套？答案就藏在三个词里：多模态、零配置、真离线。

1.1 它解决的不是“能不能翻”，而是“怎么翻得自然又全面”

很多 Bot 只做文字翻译，且严重依赖 Google 或 DeepL 的在线 API。一旦网络波动、API 限频、或地区屏蔽，整个功能就瘫痪。而 ClawdBot 背后的 MoltBot，从设计第一天起就拒绝“裸奔上云”：

  • 双引擎 fallback：默认走 LibreTranslate（开源、可自建），自动降级到 Google Translate（需配置 token）；翻译失败不报错，只默默换路。
  • 语音不靠上传：收到语音消息后，Whisper tiny 模型在本地实时转写，0.8 秒内完成“语音 → 文字 → 翻译”全链路，全程不触网。
  • 图片不传云端：PaddleOCR 轻量版直接在容器内识别图中文字，支持中/英/日/韩等 20+ 语言混排，识别完立刻翻译，无第三方 OCR 接口调用。
  • 不只是翻译：/weather 上海 返回实时温度与空气质量；/fx 100 USD to CNY 显示最新汇率；/wiki quantum computing 直接返回维基摘要——所有这些，都在同一个 Bot 里完成，无需切换多个工具。

1.2 “零配置”不是宣传话术，是真实体验

所谓零配置，是指你不需要：

  • ❌ 手动安装 Python 环境、编译 Whisper、下载 OCR 模型权重；
  • ❌ 修改 5 个配置文件、填 12 个 API Key、调试 WebSocket 连接超时；
  • ❌ 在 Telegram 开发者后台反复验证域名、设置 Webhook、处理 HTTPS 证书。

MoltBot 提供的是一个完整封装的 docker-compose 包：300 MB 镜像内已预置：

  • vLLM 推理服务（监听 http://localhost:8000/v1）
  • Whisper tiny（CPU 友好，树莓派 4 实测 1.2s/条）
  • PaddleOCR ch_ppocr_server_v2.0（支持竖排、模糊、低光照场景）
  • Telegram Bot SDK + 自动 polling 模式适配（国内网络友好）

你唯一要做的，就是复制粘贴一条命令，然后等待镜像拉取完成。

1.3 隐私不是选项，是默认行为

ClawdBot 默认开启“阅后即焚”模式：每条消息处理完即从内存清除，不落盘、不记录会话历史、不上传任何原始内容。你可以通过配置一键启用 SOCKS5 代理，把整个服务部署在国内服务器上，Telegram 流量经代理出海，而模型推理、OCR、语音转写全部在本地闭环完成。

这不仅是技术选择，更是使用逻辑的根本转变——AI 应该为你服务，而不是让你为 AI 提供数据。

2. 5 分钟部署实操：从空白系统到 Telegram Bot 上线

现在，让我们真正开始。以下步骤已在 Ubuntu 22.04、Debian 12、macOS Sonoma（Intel/M1）、树莓派 OS（64-bit）实测通过。全程无需 root 权限（除 Docker 安装外），不修改系统全局配置。

2.1 前置准备：确保基础环境就绪

请在终端中依次执行以下检查（若已安装可跳过）：

# 检查 Docker 是否安装（推荐 24.0+） docker --version # 若未安装，Ubuntu/Debian 执行： curl -fsSL https://get.docker.com | sh sudo usermod -aG docker $USER # 退出终端重登，或执行：newgrp docker # 检查 docker-compose（v2.20+） docker-compose --version # 若未安装，执行： sudo apt install docker-compose-plugin # Ubuntu/Debian # 或 macOS：brew install docker-compose
小提示：如果你用的是 Windows，建议使用 WSL2（Ubuntu 22.04），而非 Docker Desktop。后者在资源调度和端口映射上偶有异常，而 WSL2 下体验完全一致。

2.2 一键拉起服务：3 行命令搞定

创建一个空目录，进入后执行：

# 1. 下载官方 docker-compose.yml（含所有服务定义） curl -O https://raw.githubusercontent.com/moltbot/moltbot/main/docker-compose.yml # 2. 启动全部服务（含 vLLM、ClawdBot、Telegram Bot） docker-compose up -d # 3. 查看启动日志，确认无 ERROR docker-compose logs -f clawdbot | grep -E "(started|ready|listening)"

你会看到类似输出：

clawdbot-1 | 🦞 Clawdbot 2026.1.24-3 — Gateway listening on http://0.0.0.0:18780 clawdbot-1 | 🦞 ... UI dashboard ready at http://localhost:7860 vllm-1 | INFO 01-24 10:22:33 api_server.py:192 -- Started server process 1

此时，vLLM 已加载 Qwen3-4B-Instruct 模型，ClawdBot 主进程已就绪，Telegram Bot 正在轮询新消息——但你还不能直接使用它。因为 Telegram 要求每个 Bot 必须先完成“设备授权”，这是安全机制，无法跳过。

2.3 设备授权：3 步解锁 Telegram 访问权限

ClawdBot 采用“设备配对”机制替代传统 token 注册，更安全，也更适合个人部署。操作如下：

步骤 1：列出待批准的设备请求
# 进入容器执行命令（无需记容器名，用服务名即可） docker-compose exec clawdbot clawdbot devices list

输出类似：

ID Status Created At Last Seen a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8 pending 2026-01-24 10:25:33 -

只要看到 pending 状态，说明 Telegram 已检测到你的 Bot，正在等待你确认。

步骤 2：批准该设备

将上一步中的 ID 替换到下面命令：

docker-compose exec clawdbot clawdbot devices approve a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8

成功后会显示：

 Device approved. You may now use the dashboard and Telegram channel.
步骤 3：获取 Dashboard 访问链接
docker-compose exec clawdbot clawdbot dashboard

输出中会包含类似内容：

Dashboard URL: http://127.0.0.1:7860/?token=23588143fd1588692851f6cbe9218ec6b874bb859e775762 Then open: http://localhost:7860/
注意：如果你在远程服务器（如云主机）上部署，需用 SSH 端口转发：

然后在本地浏览器打开 http://localhost:7860 即可。

打开链接后，你将看到一个简洁的控制台界面，左侧导航栏清晰标注“Config”、“Models”、“Channels”、“Logs”。至此，你的 ClawdBot 已完全激活，Telegram Bot 也已获得通信许可。

3. 核心功能验证：亲手测试语音、图片、文字翻译

光看状态页不够，我们来实打实验证三大核心能力。请提前在 Telegram 中搜索并关注你的 Bot（Bot 名称形如 @yourname_moltbot_bot，具体名称可在 Dashboard 的 Channels → Telegram 页面查看）。

3.1 文字翻译：群聊 & 私聊双模式自动识别

  • 私聊测试：直接给 Bot 发送任意中文句子，例如：
    你好，今天上海的天气怎么样？
    它会秒回英文翻译，并附带 /weather 上海 按钮（点击即查）。
  • 群聊测试：在任意群中 @yourname_moltbot_bot こんにちは、元気ですか？
    Bot 会自动识别日语源语言，翻译成中文，并标记 [JA→ZH]。无需加 /translate 命令，真正“所见即所得”。
技术细节：ClawdBot 内置 fasttext 语言检测模型，对短文本准确率 >98%，且支持混合语言（如“Hello 你好 world”）分段识别。

3.2 语音翻译：本地 Whisper，不传一秒音频

找一段 5 秒内的中文语音（可用手机录制），在 Telegram 中以“语音消息”形式发送给 Bot。

几秒后，你会收到两条回复：

  1. 文字转写结果：“今天要去超市买牛奶。”
  2. 翻译结果："I'm going to the supermarket to buy milk today."

整个过程不经过任何外部服务——音频文件在容器内被 FFmpeg 解码，送入 Whisper tiny 模型，再由 Qwen3 模型润色翻译。你甚至可以在 docker stats 中观察到 whisper 容器的 CPU 短暂飙升，这就是它在“思考”。

3.3 图片 OCR 翻译：菜单、路标、截图一图搞定

发送一张含文字的图片（推荐手机拍的餐厅菜单、地铁站牌、PDF 截图）。Bot 会自动：

  • 用 PaddleOCR 定位文字区域；
  • 识别中/英/日/韩等多语种混排；
  • 将识别结果送入翻译流水线；
  • 返回带原文框选的翻译图（保留原始排版）+ 纯文本翻译。

你还会发现，对于模糊或倾斜图片，它会先做自适应二值化和透视校正——这不是魔法，是 PaddleOCR 内置的预处理 pipeline 在默默工作。

4. 模型与配置进阶：按需替换 Qwen3，或接入自有模型

ClawdBot 默认使用 vllm/Qwen3-4B-Instruct-2507，这是一个平衡了速度、显存与效果的优选模型。但你完全可以替换成其他兼容 OpenAI API 的模型，比如本地部署的 Phi-3、Gemma-2B，甚至量化版 Llama3。

4.1 方式一：修改 JSON 配置文件（推荐，稳定可控）

编辑宿主机上的 docker-compose.yml 同级目录下的 clawdbot.json（若不存在则新建）：

{ "models": { "mode": "merge", "providers": { "vllm": { "baseUrl": "http://vllm:8000/v1", "apiKey": "sk-local", "api": "openai-responses", "models": [ { "id": "Phi-3-mini-4k-instruct", "name": "Phi-3-mini-4k-instruct" } ] } } }, "agents": { "defaults": { "model": { "primary": "vllm/Phi-3-mini-4k-instruct" } } } }

然后重启服务：

docker-compose down docker-compose up -d

4.2 方式二：UI 界面操作（适合快速试错）

在 Dashboard 页面：

  • 左侧点击 Config → Models → Providers
  • 找到 vllm Provider，点击右侧铅笔图标
  • 在 Models 列表中，点击 + Add Model，填入模型 ID 和名称
  • 保存后，回到 Models → List 页面，执行 Refresh，即可看到新模型出现在列表中

4.3 验证模型是否生效

执行命令检查模型加载状态：

docker-compose exec clawdbot clawdbot models list

正常输出应包含你刚添加的模型，且 Local Auth 列为 yes：

Model Input Ctx Local Auth Tags vllm/Phi-3-mini-4k-instruct text 4k yes default
小技巧：若想同时保留多个模型用于不同任务（如用 Qwen3 处理长文本，用 Phi-3 做轻量问答），可在 agents.defaults.model.fallback 中配置备用模型，ClawdBot 会在主模型超时时自动切换。

5. 常见问题与避坑指南：少走 80% 的弯路

部署顺利时很安静，出问题时往往卡在某个不起眼的环节。以下是社区高频问题的真实解法，非官方文档搬运，而是来自上百次实操的总结。

5.1 “Dashboard 打不开，一直转圈” —— 90% 是代理或端口冲突

  • 检查是否在远程服务器部署：必须用 ssh -L 转发端口，不能直接访问服务器 IP:7860（Docker 默认绑定 127.0.0.1）。
  • 检查端口占用：lsof -i :7860 或 netstat -tuln | grep 7860，如有冲突，修改 docker-compose.yml 中 clawdbot 服务的 ports 字段，如 "7861:7860"。
  • 关闭本地代理软件：Clash、Surge 等全局代理常劫持 localhost 请求，临时关闭即可。

5.2 “Telegram Bot 不回复，logs 显示 Gateway not reachable”

这不是 Bot 故障，而是 ClawdBot 主进程与内部网关通信中断。常见原因：

  • ❌ docker-compose.yml 中 vllm 服务未启动（检查 docker-compose ps 是否 all Up）；
  • ❌ clawdbot.json 中 baseUrl 写成 http://localhost:8000/v1（容器内 localhost 指自身，应写 http://vllm:8000/v1）；
  • ❌ 网络模式错误：确保 vllm 和 clawdbot 在同一 Docker 网络（docker-compose.yml 默认已配置 network_mode: service:vllm）。

修复后执行：

docker-compose restart clawdbot docker-compose logs -f clawdbot | grep "Gateway listening"

5.3 “语音/图片没反应，但文字翻译正常”

说明多模态模块未加载。请检查：

  • docker-compose.yml 中是否注释掉了 whisper 和 paddleocr 服务（默认是开启的）；
  • 宿主机是否禁用了 Docker 的 --privileged 模式（部分 ARM 设备需此权限运行 OCR）；
  • 执行 docker-compose exec whisper ls /app/models，确认 tiny 模型文件存在（约 150MB）。

6. 总结：你刚刚完成了一次真正的 AI 自主权实践

回顾这 5 分钟，你没有申请 API Key，没有填写信用卡，没有同意“将数据用于模型优化”，也没有把私人对话交给某个远在千里之外的数据中心。你只是：

  • 下载了一个配置文件；
  • 运行了一条 docker-compose up；
  • 点击两次确认按钮；
  • 然后，一个能听、能看、能说、能查的 AI 翻译官，就站在了你的 Telegram 里。

这背后是 MoltBot 对“零配置”的极致坚持，是 ClawdBot 对“隐私即默认”的技术兑现，更是 vLLM 让大模型真正下沉到个人设备的工程胜利。

它当然不是完美的——Qwen3 在长文档翻译上仍有提升空间，PaddleOCR 对手写体识别率一般，Whisper tiny 在嘈杂环境下的转写准确率约 85%。但它的价值，从来不在参数榜单上，而在于：当你需要它时，它就在那里，安静、可靠、完全属于你。

下一步，你可以：

  • 把 Bot 添加到家庭群，让父母轻松读懂海外亲戚的微信语音；
  • 部署在公司内网，为跨境团队提供即时会议纪要翻译；
  • 或仅仅把它当作一个“AI 桌面助手”，用 /wiki 快速扫盲新技术名词。

技术的意义，从来不是让人仰望，而是让人伸手可及。

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 ZEEKLOG星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。

Read more

Java 大视界 -- 5230 台物联网设备时序数据难题破解：Java+Redis+HBase+Kafka 实战全解析（查询延迟 18ms）(438)

Java 大视界 -- 5230 台物联网设备时序数据难题破解：Java+Redis+HBase+Kafka 实战全解析（查询延迟 18ms）(438)

Java 大视界 -- 5230 台物联网设备时序数据难题破解：Java+Redis+HBase+Kafka 实战全解析（查询延迟 18ms）（438） * 引言： * 正文： * 一、技术选型：务实为王，拒绝炫技 * 1.1 核心技术栈选型对比 * 1.2 选型核心原则（10 余年实战经验总结） * 二、架构设计：闭环为王，层层兜底 * 2.1 整体架构图 * 2.2.1 生产设备层（数据源头） * 2.2.2 边缘网关层（数据预处理） * 2.2.3 消息接入层（数据缓冲） * 2.

By Ne0inhk
Java连接电科金仓数据库（KingbaseES）实战指南

Java连接电科金仓数据库（KingbaseES）实战指南

摘要：本文分享了KingbaseES V8.6数据库与SpringBoot 2.7.x框架的集成实战经验。内容包括：1. 环境准备（Ubuntu系统安装配置、驱动获取方式）；2. JDBC基础操作（连接、查询、事务处理）；3. SpringBoot项目完整配置（pom依赖、数据源配置）；4. MyBatis-Plus集成（实体类、Mapper、Service层实现）；5. RESTful接口开发示例。文章提供了详细的代码示例，涵盖从数据库安装到应用开发的完整流程，帮助开发者快速实现国产数据库适配。 目录 前言 一、环境准备与驱动获取 1.1 数据库安装与配置 1.2 JDBC驱动获取与配置 1.3 创建测试数据库 二、基础JDBC连接与操作 2.1 最基础的JDBC连接示例 2.

By Ne0inhk
【Linux系统】理解管道通信，匿名管道实现进程池+命名管道实现服务端客户端通信模型（附源码）

【Linux系统】理解管道通信，匿名管道实现进程池+命名管道实现服务端客户端通信模型（附源码）

文章目录 * 一、进程间通信是什么 * 二、管道 * 1. 什么是管道 * 2. 匿名管道 * 3. 命名管道 * 三、实例：匿名管道实现进程池 * 四、实例：命名管道实现服务端客户端通信模型 一、进程间通信是什么 进程间通信（IPC），顾名思义，进程之间需要进行信息交换。 如：数据传输、资源共享、通知事件、进程控制。 进程间通信的方式有：管道、System V IPC、POSIX IPC。 由于进程具有独立性，进程间通信的前提就是，不同的进程能看到同一份资源。 二、管道 1. 什么是管道 管道是类Unix系统中最古老的进程间通信的方式。我们把从一个进程连接到另一个进程的数据流称为一个“管道”。 管道是单向通信的，称为单工通信。 管道分为匿名管道和命名管道。 2. 匿名管道

By Ne0inhk
【Java 开发日记】我们来说一下无锁队列 Disruptor 的原理

【Java 开发日记】我们来说一下无锁队列 Disruptor 的原理

目录 一、为什么需要 Disruptor？—— 背景与问题 二、核心设计思想 三、核心组件与原理 1. 环形缓冲区（Ring Buffer） 2. 序列（Sequence） 3. 序列屏障（Sequence Barrier） 4. 等待策略（Wait Strategy） 5. 事件处理器（EventProcessor） 6. 生产者（Producer） 四、工作流程示例（单生产者 -> 单消费者） 五、多消费者与依赖关系 六、总结：Disruptor 高性能的秘诀 一、为什么需要 Disruptor？—— 背景与问题 在高并发编程中，传统的队列（如 java.

By Ne0inhk