Telegram Bot 接入 AI 模型：从 API 到群聊

Sat, 23 May 2026 00:00:00 +0000

前言

大家好，我是Seb。今天想聊聊怎么把 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 调用链。

搭建 sub2api AI API 中转：省钱又灵活

Sat, 23 May 2026 00:00:00 +0000

为什么需要 API 中转

做 AI 开发时间长了，手里攒的模型越来越多：OpenAI 的 GPT-4o、Claude 的 Sonnet 4、DeepSeek 的 V3 和 R1、还有本地跑的 Llama……每个模型都有自己的 API Key、独立的接口地址、不一样的计费方式。

一开始没啥感觉，反正写死一个模型也能用。但当你开始做稍微复杂点的项目——比如一个 Telegram Bot 同时接了好几个模型，或者你在做 RAG 应用需要根据任务类型自动选模型——这时候问题就来了：

代码里到处都是不同的 base_url 和 api_key
想换模型，得改代码、重新测试、重新部署
某个模型挂了切到另一个，手忙脚乱
月底对账一看，每个平台各算各的，根本理不清到底花了多少钱

sub2api 就是来解决这些问题的。 它本质上是一个轻量级的反向代理层，把你的所有 API 请求统一到一个入口。你的代码只认一个地址、一个 Key，背后路由到哪个模型由 sub2api 说了算。

架构概览

┌─────────────────┐     ┌──────────┐     ┌──────────────┐
│  你的客户端代码  │────▶│ sub2api  │────▶│  OpenAI      │
│  (Bot/Agent/App) │     │  (中转)   │     ├──────────────┤
└─────────────────┘     │          │     │  Claude      │
                        │          │     ├──────────────┤
                        │          │     │  DeepSeek    │
                        │          │     ├──────────────┤
                        │          │     │  其他/本地    │
                        └──────────┘     └──────────────┘

客户端看到的就是一个标准的 OpenAI 兼容 API。你传一个请求过来，sub2api 根据你指定的模型名，自动决定转发到哪个后端，拿到响应后再原样返回给你。中间的所有差异——不同厂商的认证方式、请求格式、响应结构——都由它来抹平。

API on Fanssen Notes

Telegram Bot 接入 AI 模型：从 API 到群聊

前言

架构

搭建 sub2api AI API 中转：省钱又灵活

为什么需要 API 中转

架构概览