如何将 AI 助手接入 Telegram

你想让浏览器标签里那个已经在用的助手也住进 Telegram 里，好让你直接从口袋里的手机跟它对话，而不用每次都打开笔记本。好消息是，管道很简单：一个 bot 令牌、一个消息循环和一个 LLM。不那么显而易见的，是首次跑出 "hello world" 之后如何让这套管道持续在线。

为什么要把 AI 助手放到 Telegram 上

大部分 AI 工具都藏在一个 URL 后面。你打开它、输入内容、读完回复，然后关掉标签页。你一关，上下文就没了。

Telegram 把这件事翻了个面，它把你的助手当成通讯录里普通的一个对话来处理。你可以在车里发一条语音、把群里的链接转过去，或是在电脑登录着的时候把报错粘进对话。另一边，同一个助手会记住每一次交流的内容，因为回答问题的是一个持续运行的进程，而不是每次都重新加载的网页。

带着这个视角，真正有意思的问题就不再是"我能不能让 Telegram bot 回复一句话"，几乎每个教程五分钟就能演示到。真正的问题是：周二晚上 11 点 bot 突然不吱声的时候，谁来擦屁股。

步骤 1：在 BotFather 里创建 bot

打开 Telegram 搜索 @BotFather。它是带蓝色认证勾的官方账号。点 Start 后发送：

/newbot

BotFather 会问两个问题：

显示名：bot 联系人卡片上出现的名字。之后可以改。
用户名：链接和 @ 提及里用的 @handle，长度 5 到 32 个字符，只能是拉丁字符，且必须以 bot 结尾（比如 myai_assistant_bot）。

一旦你填入一个合法的用户名，BotFather 会返回一个令牌，样子像这样：

7123456789:AAHdqTcvCH1vGWJxfSeofSAs0K5PALDsaw

请像对待密码一样对待这串字符。不要把它贴到截图、群聊或公开仓库里。一旦泄露，就给 BotFather 发 /revoke，选中对应的 bot，它会立刻发你一枚新令牌，旧的当场失效。

步骤 2：决定"谁来思考"

bot 令牌只负责收发消息，它并不决定说什么。这是 LLM 的活。你大致有三个方向：

直接对接单一 LLM API：直连 OpenAI、Anthropic 或 Google。简单，但每个服务商都有自己的 SDK、自己的鉴权方式和自己的限流。
走 OpenRouter 这类路由：一把 API 密钥就能访问几十个模型。可以按任务切换模型（聊天用快而便宜的模型，推理用大模型），不用同时管几个账号。
本地模型：在自己的硬件上跑 Ollama 或 llama.cpp，没有按 token 计费的成本，但可用性得自己扛。

对于要"手感灵敏"的个人助手，大多数人最后都会落到托管 API。消费级硬件跑本地模型的延迟一般比不上一条网络通畅的商业 API，通用推理质量也仍有差距。

不管你选哪家服务商，先在它的控制台里生成密钥，并把它和 bot 令牌一起放好，下一步两者都要用。

步骤 3：写一段（或借用一段）消息循环

Telegram 和 LLM 之间需要一段小程序，负责：

用长轮询（或 webhook）从 Telegram Bot API 拉取新消息。
把消息文本（视情况附带聊天历史）传给 LLM。
把 LLM 的回复发回同一个 Telegram 聊天。
处理异常，避免一次失败就悄悄把循环卡死。

如果你熟悉 Python，用 python-telegram-bot 库加上服务商的 SDK，大约 40 行就能跑起来一个原型。Node 有等价的包。想走纯无代码路线，Make.com 或 n8n 之类的工具能把 Telegram 触发器和 OpenAI 动作拖到画布上用一根线连起来。

在真正投入使用之前，你几乎一定会想加上这两点：

允许名单，避免陌生人猜到 bot 的用户名后把你的 API 预算烧光。Telegram 上的 bot 是可以被搜到的；没有 allowlist，它就会给所有人回话。
对话记忆，让助手记住同一个聊天里的前几轮，而不是把每条消息都当作第一句。要么把消息历史按 chat_id 存到数据库里，要么用一个自带记忆的智能体框架。

步骤 4：让进程持续运行

大多数周末项目都是死在这一步的。

你的 Telegram bot 只在消息循环运行时才会响应。如果它跑在笔记本的终端里，笔记本一睡眠它就停。如果它是廉价 VPS 上的 python bot.py，下一次进程崩溃、VPS 因内核更新重启、或者凌晨三点抛一个未处理异常时，它就停了。

行业里通行的做法并不酷炫：

用 systemd（或 Docker 加 restart: unless-stopped）把进程包起来，让操作系统在崩溃或重启后把它拉起来。
把日志送到你真的会去看的地方（logrotate 轮转的文件，或托管日志服务）。
加一个健康检查，如果 bot 有 N 分钟没收到 Telegram 更新就通知你。
把 bot 令牌和 API 密钥放进 secret store，而不是和代码同一块盘上的 config.yaml。

单看，每一件都不难。它只是持续的一份责任，而正是这一部分决定了"Telegram 上的 AI 助手"到底是你天天顺手用的工具，还是每隔几周就得重新部署一次的项目。

捷径：使用托管的 Hermes Agent

如果你喜欢"AI 助手住在 Telegram 里"这件事，但不喜欢自己运维 Linux 服务器，捷径就是把中间两步交出去，只保留你真正在意的部分。

Hermify 会以托管方式为你运行一个作为 Telegram 联系人的 Hermes Agent。你只需要提供：

你的 bot 令牌（来自步骤 1）
一个模型服务商的密钥（来自步骤 2），或者选择包含模型访问的套餐

Hermify 负责消息循环、进程守护、跨会话保留的记忆文件，以及凭据的安全存储。bot 会在大约一分钟内在你的 Telegram 里上线；当进程需要重启时它会自己重启，你会在控制台里得到通知，而不是通过一个突然安静的聊天窗口才发现。开始使用 Hermify 试用托管路线。

底层的 Hermes Agent 是开源的，因此你并没有被托管方案锁死：以后如果你觉得自己扛得起运维负担，可以把同一套配置搬到自己的 VPS 上。大多数人最后都会发现，其实一直没搬。

在自建和托管之间选择

两条路都行得通。选哪条，主要取决于你想把注意力花在哪里：

自建，如果你本就在运维这一类基础设施、希望完全掌控模型、记忆文件和提示词，并把运维部分当作乐趣的一部分。
托管，如果你只想让助手就是一个可以随时随地发消息的 Telegram 联系人，而不想在周末做维护。

无论走哪条路，用户体验层面的收获都是相同的：你的助手不再是一个 URL，而变成一个你可以随手发消息的对象。它一旦住进 Telegram，你就真的会去用。

如果你想拿具体的部署步骤做对照，Telegram 部署指南会带你走完一整套配置。如果你想走捷径，开始使用 Hermify，你的助手大约一分钟就能在 Telegram 上线。