前言

大家好，我是一凡。今天想聊聊怎么把 AI 模型塞进 Telegram 里，做成一个能用、好用的 Bot。

起因很简单：我每天用 AI 的频率太高了。写代码要问、查资料要问、翻译要问、写文案也要问。每次都要打开浏览器、找到网页、粘贴 prompt、等回复。一天重复几十次，真的很烦。

我的想法很直接——能不能在 Telegram 里直接和 AI 对话？毕竟 Telegram 是我手机上打开频率最高的应用之一。不用切应用、不用开浏览器、不用管什么 API Key 放在哪，打开 Telegram 直接打字就行。

后来真做出来了，用了一段时间觉得挺香。这篇文章就把整个过程拆开讲讲，从架构设计到部署踩坑，都写清楚。

整体架构

先看看消息是怎么跑的：

用户 → Telegram → Bot 服务器 → Hermes Gateway → AI 模型 → 回复原路返回

每一步具体在做什么：

用户发了条消息 → Telegram 服务器收到，推送给我的 Bot → Bot 服务器（跑在香港的一台 VPS 上）把消息包装成 API 请求 → 请求经过 Hermes Gateway 路由到对应的 AI 模型 → 模型算完了返回结果 → 按原路返回给用户。

整条链路下来，用户在 Telegram 里看到的就是一条正常的回复，和跟真人聊天没什么区别。但实际上背后已经跑完了一个完整的 API 调用链。

这里有个关键点：Telegram 只是前端界面。Bot 服务器才是真正干活的——它负责接收消息、调用模型、处理流式输出、把结果送回 Telegram。界面可以换，逻辑都在服务器上。

部署全过程

第一步：注册 Bot

先去 Telegram 里找 BotFather，这是官方提供的 Bot 管理工具。和它对话，发 /newbot，给它起个名字，再起个用户名（必须以 bot 结尾），它会返回一个 Token。

这个 Token 就是 Bot 的身份证，后续所有 API 调用都要带上它。保管好，别泄露——谁拿到这个 Token 谁就能控制你的 Bot。

Token 长这样：123456789:ABCdefGHIjklmNOPqrstUVwxyz-1234567。一串随机字符，看起来不起眼，丢了很麻烦。

第二步：选服务器，这个坑踩过

这是整个部署过程中最大的坑，没有之一。

Telegram 的 API 服务器架设在海外。国内服务器去连它，网络层面的限制非常严重。不是延迟高不高的问题，是根本连不上、或者连上了秒断。

我第一次部署的时候，图省事直接用了一台国内的云服务器。结果 Bot 完全收不到消息——消息从 Telegram 发出去了，但我的服务器收不到推送。排查了整整一个下午，查代码、看日志、调防火墙，最后发现是网络问题。

后来换了一台香港服务器，同样的代码、同样的配置，部署上去立马就能用了。

所以如果你打算部署 Telegram Bot，第一步就是把服务器选在海外或者香港。这是个硬性条件，别想着绕过去，绕不过的。

香港服务器的优势很明显：离大陆近，延迟低，和 Telegram 的网络互通也没问题。如果是做通知类的 Bot，香港到大陆的延迟通常在 30-50ms 以内，体验很好。

第三步：Webhook 还是 Polling？

Telegram Bot 有两种接收消息的方式：长轮询（Long Polling）和 Webhook。

长轮询：Bot 每隔一小段时间去 Telegram 服务器问一次"有新消息吗？"。实现简单，代码量少，但有个明显的缺点——如果消息不多，大多数请求都是空跑，浪费资源。延迟大概在几百毫秒到几秒之间，取决于轮询间隔。

Webhook：Telegram 服务器收到新消息后，主动推送到你的 Bot 服务器地址。延迟更低，消息几乎是实时到达的。服务器资源消耗也小，因为不需要一直轮询。

我选的是 Webhook 模式，原因很直接：我的香港服务器上还跑着其他服务，不想让 Bot 的轮询占太多资源。而且 Webhook 配置起来也不复杂——在 Bot 服务器上启动一个 HTTPS 接口，然后用 Telegram API 设一下 Webhook URL 就行了。

需要注意：Telegram 的 Webhook 要求 HTTPS 地址。如果服务器没有配 HTTPS，可以用 Cloudflare 或者 Nginx 反代来解决。自签名证书也行，但很多自签名证书会被 Telegram 拒绝，建议直接用 Let’s Encrypt 的免费证书。

第四步：群聊适配

Bot 创建出来后，默认情况下在群聊里只会在被 @ 的时候才响应。这个叫做 Privacy Mode，是 Telegram 为了保证群聊隐私而设计的默认行为。

如果你的 Bot 需要监听群里的所有消息（比如做自动回复、消息转发、关键词触发），就需要在 BotFather 里手动关闭 Privacy Mode。

具体操作：打开 BotFather → 发送 /mybots → 选择你的 Bot → 点击 Bot Settings → 点击 Group Privacy → 点击 Disable。

这里有个容易忽略的地方：关闭 Privacy Mode 后，Bot 在群里的角色会改变。它可以看到群里所有的消息（除了其他 Bot 的消息）。如果群聊里有敏感信息，需要评估一下这个风险。

我第一次配置的时候完全忘了这回事，Bot 在群里像个聋子，对大部分消息都没反应。排查了半天才想起来有这个设置。

第五步：AI 模型对接

Bot 本身不直接调用 AI 模型，而是通过 Hermes Gateway 做了一层转发。

为什么要多这一层？因为我不想把模型 API 的 Key 直接暴露在 Bot 代码里。Gateway 处理了认证、限流、模型路由这些事情，Bot 只需要把消息发给 Gateway，Gateway 去调模型，再把结果返回。

模型层面，我通过 sub2api 路由到了 DeepSeek、GPT 等多个模型。sub2api 本身不做推理，它是一个流量调度器——收到请求后，根据配置把请求转发给对应的模型提供商，然后把结果拿回来。

这样做的好处非常明显：换模型不需要改 Bot 代码。今天用 DeepSeek，明天想试试 Claude，只需要改一下 sub2api 的配置。Bot 只认一个 API 地址，背后连的是哪个模型它不管。

流式输出

AI 模型的回复通常有两种模式：一次性返回和流式返回。

一次性返回就是等模型算完了，一次性把结果发回来。流式返回是模型一边算一边往外吐 token，用户能看到文字一个字一个字地出现。

流式输出的体验更好——用户不需要盯着一个加载转圈等好几秒，可以看到回复在实时生成。如果是长文本回复，这种体验差异特别明显。

Telegram Bot 要实现流式输出，需要把 Bot 的响应模式改成流式。具体来说，每次从模型拿到一小段 token 后，就通过 sendMessage 或者 editMessageText API 推送给用户。但这里有个技巧：不要每收到一个 token 就发一次请求，那样 Telegram API 会被打爆。最好是每隔几百毫秒批量推送一次，或者积累一定长度的文本后再发。

我用的是前者——设置了一个 200ms 的定时器，每 200ms 把缓冲区里的文本推送到 Telegram。实测效果不错，用户看到的是一段段跳出来的文字，流畅度可以接受。

使用场景

目前这个 Bot 在我的日常使用中有几个主要用途，分享出来给大家参考。

个人 AI 助手

这是最核心的用途。写代码遇到问题，直接在 Telegram 里问 Bot；要翻译一段英文，直接发给 Bot；要写个文案、总结一篇文章，也是直接丢给 Bot。

手机上和电脑上都能用——Telegram 全平台同步，消息记录随时随地都能查看。地铁上掏手机问一句，到工位电脑上继续聊，体验是连贯的。

相比用网页端 AI 产品，Telegram Bot 有个天然优势：不需要切换上下文。我在和同事讨论问题时，顺手就能把问题发给 Bot 让它帮忙分析，不用离开当前聊天界面。

交易机器人通知

我的另一个项目是量化交易机器人。每笔开仓、平仓、止盈、止损，都需要及时通知到我。

之前试过邮件通知——速度慢，有时会被丢进垃圾箱。也试过短信通知——要花钱，而且触发频率高了很烦。

最后发现 Telegram 是最合适的通知通道。推送速度快（秒级到达），不会被垃圾过滤，而且是免费的。交易机器人每笔操作都通过 API 发消息给 Bot，Bot 再推送到我的手机上。配合 Telegeram 的消息分组功能，不同类型的交易通知可以放在不同的分组里，一目了然。

后续可扩展的方向

这个架构搭好后，扩展起来很方便：

  • 客服系统：把 Bot 接入客服工作流，用户先和 AI 对话，解决不了的再转人工。Bot 作为统一的入口，后端可以接不同的处理逻辑。
  • 工作流自动化：把 Bot 和 Notion、Slack、Jira 这些工具连起来。在群里发一条消息，Bot 自动创建任务、更新状态、发送通知。
  • 群聊管理 Bot：关键词过滤、自动回复、定时提醒、入群欢迎——这些都可以通过 Bot 实现，比用第三方工具更可控。

踩坑总结

把整个过程遇到的坑汇总一下，给大家当个备忘录：

  1. 国内服务器连不上 Telegram API — 不要挣扎，直接上香港或者海外服务器。这不是配置能解决的问题，是网络层面的硬限制。

  2. Privacy Mode 默认开启 — Bot 在群里对大部分消息没反应时，先检查这个。BotFather → Bot Settings → Group Privacy → Disable。

  3. Webhook 必须走 HTTPS — HTTP 地址 Telegram 会拒绝。如果服务器来不及配 HTTPS，可以用 Cloudflare 的 Tunnel 或者 Nginx 反代来提供 HTTPS 支持。

  4. Token 别泄露 — 如果不小心把 Token 提交到公共仓库了，立即去 BotFather 用 /revoke 重新生成。不要心存侥幸，GitHub 上有人专门爬 Bot Token 做坏事。

  5. 流式输出频率控制 — 不要每拿到一个 token 就调用一次 Telegram API。加个缓冲区，批量推送，能省很多 API 调用。

  6. 模型限流 — 如果 Bot 同时在服务多个用户，注意模型的调用频率限制。建议在 Gateway 层做一下排队和限流，不然模型 API 返回 429 错误时 Bot 会卡住。

写在最后

这个方案用了一段时间了，整体体验比我想象中好。最大的收获不是技术层面的，而是使用习惯的改变——当 AI 的门槛降低到打开一个聊天窗口就能使用时，使用频率会自然地大幅提升。

如果你也经常用 AI，不妨尝试在 Telegram 里搭一个自己的 Bot。代码不复杂，成本也不高（一台香港轻量服务器一个月几十块），但用起来的便利性是值得的。

有什么问题欢迎留言交流。一凡，下篇见。