API

前言 大家好，我是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 调用链。 ...

为什么需要 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 根据你指定的模型名，自动决定转发到哪个后端，拿到响应后再原样返回给你。中间的所有差异——不同厂商的认证方式、请求格式、响应结构——都由它来抹平。 ...