点击、机器人或会话：人们经常混淆的 Telegram 自动化的三个层次

点击、机器人或会话：人们经常混淆的 Telegram 自动化的三个层次

通过云手机、Bot API 和用户级 MTProto 客户端管理 Telegram 有何不同——以及为什么选错层面会导致技术限制。

想象一个团队购买了 Telegram 账号、代理和云手机访问权限。每个账号都在独立的 Android 环境中打开。窗口同步功能让操作员能够同时在多个设备上重复点击。随之而来的问题是：团队如何自动读取对话、以普通用户账号身份回复、处理联系人、监控会话状态并收集结果？

问题不在于哪种方法本身有局限，而在于用户经常混淆三种不同的自动化机制，而每种机制控制的是不同类型的实体。

本文将解释 UI 自动化、Bot API 和 MTProto 的区别，每种方法实际解决的任务，以及何时仅靠移动端基础设施是不够的。

“自动化 Telegram” 是一个过于模糊的需求

当用户说“自动化”时，他们可能指的是完全不同的东西：

• 在 Android 应用中重复操作；
• 聊天机器人、客服工作流或通知系统；
• 以普通 Telegram 账号身份执行操作；
• 读取该账号可见的对话内容；
• 管理多个已授权的会话；
• 处理每个账号的错误和结果。

在定义“身份”（即谁或什么实体执行操作）之前，选择工具还为时过早。

一位 BlackHatWorld 用户 描述了一个典型场景：他购买了五个 Telegram 账号、住宅轮换代理和 AdsPower 订阅，创建了独立配置文件，并打开了 Telegram 网页版。准备好环境后，他询问如何同时自动化所有配置文件的操作，以及是否需要一个“特殊的 Telegram 机器人”。参与者给出了几种不同的解决方案：浏览器自动化、RPA、独立脚本、userbot（用户机器人）和第三方 Telegram 工具。仅靠隔离的任务环境并不能回答 Telegram 操作将如何实际执行的问题。

一位 Stack Overflow 用户更直接地提出了问题：他想让一个机器人访问普通账号、读取消息并以该用户的名义进行回复，使回复看起来像是用户发送的。回复解释说，Bot API 并不提供这种通用的访问模型。

这并非凭空想象的问题。在不同的社区中，人们都在使用“机器人”这个词来同时指代屏幕自动化、Bot API 以及用户客户端。

让我们从最直观的方法开始：像操作员一样通过应用界面观察 Telegram 的自动化。

第一层：UI 自动化：控制 Telegram 界面

什么是云手机？

云手机是运行在云端的虚拟 Android 设备。它模拟真实的智能手机，拥有自己的操作系统、环境和指纹数据。用户可以安装应用、打开它们，并像在实体手机上一样进行交互。

FlashID 提供此类云手机，并允许用户同时管理多个 Android 设备。

窗口同步的工作原理

窗口同步（Window Sync）在浏览器窗口和云手机之间同步操作。输入、点击、导航和滚动等动作在一个窗口中执行，并在选定的环境中重现。

对于云手机来说，这意味着控制多个 Android 实例和应用，包括 Telegram。

在实践中，窗口同步是一种半自动化工具，而非完全基于脚本的自动化：操作员继续实时控制过程，而系统在多个环境中重复相同的动作。

为什么这是界面自动化

UI 自动化控制屏幕上显示的内容。它：

• 打开应用程序；
• 点击界面元素；
• 输入文本；
• 滚动页面；
• 在选定的 Android 环境中重复动作。

它不是 Telegram API，也不直接调用 Telegram 的方法。

UI 自动化的适用场景

这种方法适用于：

• 仅能通过 Android 应用完成的流程；
• 对非标准屏幕的手动控制；
• 初始账号设置；
• 处理系统权限；
• 视觉验证结果；
• 操作员必须看到并确认每一步的操作；
• 在多个同步环境中重复相同的动作。

UI 自动化对 Telegram 的盲区

窗口同步处理的是可见的界面动作。它重现输入、点击和滚动，但不会解析每个 Telegram 会话的内部状态，也不会为每个账号选择 Telegram 工作流的不同分支。

UI 自动化本身无法知道：

• 当前打开的是哪个 Telegram 账号；
• 账号是否受到限制；
• 是否已经进入了所需的聊天；
• 上一步操作是否加载完成；
• 账号是否遇到了不同的系统对话框；
• Telegram 任务是否在服务器端完成；
• 统计数据中应该记录哪种结果。

当操作必须通过应用程序且界面保持预期状态时，UI 自动化是有效的。然而，它控制的对象仍然是屏幕，而不是作为一个结构化实体的 Telegram 会话。

当团队需要一个自动化的对话参与者，而不是一个自动化的屏幕时，第二种方法就派上用场了：Bot API。

第二层：Bot API：自动化特殊的 Telegram 账号

什么是 Telegram 机器人（Bot）？

Telegram 将机器人定义为由软件控制的特殊账号，不需要单独的手机号码。机器人的代码通常在外部服务器上运行，而 Telegram 通过 webhook 或 getUpdates 向其传递事件。

Bot API 的授权基于唯一的 Token。请求通过 HTTPS 发送到 Bot API 方法，响应以 JSON 格式返回。这与使用手机号、授权码和 2FA（双重认证）登录用户账号有着本质区别。

机器人 Token 不能被视为用户 Telegram 会话的替代品。它是一个具有不同权限模型的不同身份的凭据。

Bot API 擅长的任务

Bot API 文档齐全，专为构建以下内容而设计：

• 聊天机器人；
• 客户支持解决方案；
• 通知系统；
• 菜单和按钮；
• 小程序（Mini Apps）；
• 支付流程；
• 拥有所需权限时的群组和频道管理；
• 与主动联系机器人的用户进行交互。

Bot API 的限制

Telegram 建议机器人在单个聊天中每秒发送消息不超过 1 条左右。对于群组，规定的限制是每分钟不超过 20 条消息，而批量通知限制约为每秒 30 条消息。一旦超过这些限制，Bot API 就会开始返回 429 错误。

Telegram 还支持付费群发：在满足要求的情况下，机器人可以通过使用 Telegram Stars 支付费用，实现每秒发送高达 1,000 条消息。此功能专门用于向机器人的订阅者群发，它并不会将 Bot API 变成管理普通用户账号的系统。

即使在官方机器人模型中，扩展规模也不是通过模仿数百个用户账号实现的，而是通过拥有自身规则和限制的独立平台模型实现的。

商业机器人改变了机器人与用户之间的界限

2024 年，Telegram Business 允许用户连接聊天机器人，代表他们处理并回复消息。账号所有者可以选择机器人有权访问哪些聊天。

2026 年 5 月，Telegram 在个人资料设置中将此模型扩展为“聊天自动化”。现在，任何用户都可以将机器人连接到其个人资料并配置其聊天访问权限。自 2026 年 5 月 8 日起，连接商业机器人不再需要 Premium 订阅。

从技术上讲，交互是通过商业连接（business connection）进行的。机器人会接收到一个独立的 connection_id、一组权限和接收者设置。

通过授权连接，商业机器人可以使用支持的方法发送和编辑消息、将聊天记录标记为已读、修改个人资料信息、处理媒体、置顶消息以及执行许多其他操作。

然而，有一个重要的限制。can_reply 权限仅允许连接的商业机器人在过去 24 小时内收到过回复的私聊中发送和编辑消息。

因此，说 Bot API 完全不能代表用户操作是不准确的。通过受限的商业连接，它可以代表连接的个人资料执行某些操作。但是，这是一个具有自身标识符、权限和支持方法列表的委托模型，而不是完整的用户客户端会话。

当目标不是将选定操作委托给机器人，而是以编程方式将完整的用户账号作为 Telegram 客户端进行操作时，就会使用第三层：MTProto。

第三层：MTProto：自动化完整的用户会话

什么是 MTProto？

MTProto 是 Telegram 客户端使用的协议。对于第三方开发者，Telegram 提供了 TDLib，这是一个全功能的跨平台客户端库，负责处理网络通信、加密、本地存储和数据一致性。

用户客户端如何授权

用户客户端不是使用 BotFather Token，而是以与普通 Telegram 账号相同的方式进行授权：

• 使用 api_id 和 api_hash；
• 手机号码；
• 授权码；
• 2FA（如果需要）；
• 存储的密钥和会话数据。

Telegram 将授权与客户端的 auth_key_id 相关联。授权成功后，客户端可以调用用户账号可用的方法，而无需在每次启动时请求新代码。

技术上准确的术语是“自动化的 Telegram 用户客户端”。“Userbot”作为一个通用术语是可以接受的，但必须理解这不是一个机器人账号，而是一个通过客户端库控制的普通用户账号。

用户客户端能做什么

Telegram 维护着独立的方法列表：仅对用户可用、仅对机器人可用以及通过商业连接可用。

用户客户端可以操作已授权账号可见的实体，但受其权限、隐私设置和服务器端限制的约束。这就是为什么 MTProto 被选中用于以下场景：

• 以普通账号身份操作；
• 操作其可见的频道和群组；
• 读取其对话内容；
• 使用原生的用户方法；
• 定时发送消息；
• 从用户资料发布故事（Stories）；
• 处理额外的 Telegram 事件。

为什么 MTProto 不仅仅是另一个 API

使用 MTProto 涉及有状态的基础设施：

• 独立的授权；
• 会话密钥；
• 本地存储；
• 实体缓存；
• 更新（Updates）；
• RPC 错误；
• 并发访问管理；
• 会话恢复或撤销；
• 服务器端限制。

核心区别在于：在 Bot API 中，主要资产是机器人 Token；而在用户账号自动化中，主要资产是 Telegram 会话（Session）。

什么是会话文件（Session File）？

Telethon 将用户授权存储在会话文件中。该文件包含足够的信息以便再次登录而无需请求新代码。这个 SQLite 文件存储了连接数据、Telegram 服务器的地址和端口、授权密钥以及其他信息。

Telethon 还会将会话中先前遇到的实体（用户、聊天和频道）信息存储起来，这样就不需要向 Telegram 发送不必要的请求。

会话是一项敏感资产：任何获得包含有效授权的文件的人都可以访问相应的账号。

会话的并发访问

处理会话文件时，可能会出现 sqlite3.OperationalError: database is locked 错误。当两个或多个客户端同时使用同一个会话时，就会发生这种情况。推荐的解决方案是为每个客户端使用独立的会话。

在服务器层面，Telegram 定义了 AUTH_KEY_DUPLICATED 错误。当一个已授权的会话在并行的主 TCP 连接上发送的请求超过许可数量时，就会发生此错误。在这种情况下，密钥可能会失效。

扩展 MTProto 的规模并非简单地将一个会话文件复制到多个进程中那么简单。团队必须理解 Telegram 授权、MTProto 会话、本地会话存储和并发连接之间的区别。

错误是操作的常态

Telegram 的官方文档直接指出：在使用 API 时会发生错误，客户端必须正确处理它们。

FLOOD_WAIT_X 表示已超过调用某个方法的允许最大尝试次数，客户端必须等待指定的秒数。这是服务器端的限制，而不是界面错误或 MTProto 库的故障。

增加并发并不能消除 FloodWaitError。并行操作只会让系统更快达到流量限制阈值。

官方 API 并不意味着任何场景都是合规的

Telegram 欢迎第三方客户端的开发，但其 API 条款要求应用程序不得在用户不知情和未经同意的情况下代表用户执行操作。

Telegram 还警告说，API 客户端会受到严密监控以防止滥用。使用 API 进行灌水、垃圾信息或人为操纵计数器可能会导致永久封禁。

无论选择 UI 自动化、Bot API 还是 MTProto，都不能逾越 Telegram 的规则。无论是官方 Android 客户端、官方 API，还是专门的软件，都不能让被禁止的场景变得合规。

真正的问题不在于第一次登录，而在于首批一百个会话

单个 MTProto 客户端可以基于库构建。然而，随着账号数量的增加，挑战将从技术层面转向操作层面：

• 每个会话存储在哪里；
• 哪个账号目前活跃；
• 哪个会话受限或被撤销；
• 正在运行哪个任务；
• 哪些动作已完成；
• 2FA 凭据和附加参数存储在哪里；
• 特定账号是否可用于下一个任务；
• 每个账号完成了多少次动作；
• 如何处理 FLOOD_WAIT、授权错误和限制；
• 如何防止同一会话在多个进程中以冲突的方式启动。

构建一个 MTProto 客户端并不等同于构建一个管理大量 Telegram 客户端的系统。

围绕标准 MTProto 库必须构建的内容

团队拥有的账号和工作流越多，就越需要自己实现更多的功能——或者通过脚本、数据库和管理表格的组合来覆盖：

• 会话存储；
• 账号与参数及代理的绑定；
• 任务队列；
• 并发操作控制；
• RPC 错误处理；
• 账号状态管理；
• 重试逻辑；
• 结果日志；
• 负载均衡；
• 操作员界面；
• 格式导入与导出；
• 报告统计。

Telegram Soft Expert：不是第四种自动化，而是现成的 MTProto 工作流管理系统

Telegram Expert 运行在不同的层面，解决了集中管理普通 Telegram 账号时出现的任务。

该产品集成了：

• 账号控制面板；
• 文件夹与状态管理；
• 批量账号检查；
• 会话管理；
• 支持 Session、JSON 和 TData 格式；
• 使用用户账号执行动作；
• 对话管理；
• 联系人管理；
• 消息处理；
• 受众管理；
• 报告统计；
• 追踪完成的操作数量；
• 代理及代理池检查。

在 Telegram Expert 中，账号可以被集中分配到活跃、临时受限、永久受限、冻结、Premium、已存档和已删除等类别。批量检查功能可以验证账号并根据结果将其移动到相应的文件夹。

面板的核心价值不仅仅是显示账号列表，它还防止操作员将每个会话文件都视为同样适合工作的状态。

Telegram Expert 理解任务，而非按钮坐标

Telegram Expert 在 Telegram 工作流层面接收任务：

• 检查选定的账号；
• 读取未读对话；
• 使用合适的会话执行动作；
• 记录结果；
• 分离出有问题的账号；
• 生成统计数据。

为什么 Session、JSON 和 TData 成为独立的基础设施层

账号格式不仅仅是装饰性的文件。

在 Telegram Expert 中：

• JSON 生成器可为会话（Session）创建缺失或损坏的 JSON 文件；
• 转换器可在 Session 和 TData 格式之间相互转换账号；
• 复制器为移动端和桌面端客户端创建会话；
• 面板提供对账号和会话本身的集中管理。

云手机存储工作的移动环境。Session 或 TData 代表 Telegram 客户端的授权。对于团队来说，不仅要保存每个组件，还要能在特定任务所需的格式之间迁移账号，这一点至关重要。

控制结果比启动任务更重要

UI 同步可以清楚地显示动作已经开始。然而，专业的自动化还必须回答：

• 有多少账号启动了任务；
• 有多少账号完成了任务；
• 有多少账号遇到了错误；
• 每个账号执行了多少次动作；
• 哪些数据应该排除或合并；
• 哪些账号不应再分配工作。

Telegram Soft Expert 包含报告生成器、数据库合并功能，以及追踪每个账号执行的广播和邀请数量的计算器。

FlashID 与 Telegram Expert 覆盖了同一流程的不同部分

FlashID：

• 提供独立的 Android 云手机；
• 隔离移动环境；
• 允许启动 Telegram 应用程序；
• 同步点击、输入和滚动；
• 帮助团队管理移动设备群组。

Telegram Expert：

• 管理用户 Telegram 会话；
• 追踪账号状态；
• 执行专门的 Telegram 任务；
• 分配工作负载；
• 记录结果；
• 维护 Session、JSON 和 TData 格式。

FlashID 管理环境和屏幕。Telegram Expert 将 Telegram 账号作为一个运营实体进行管理。

Bot API 仍然是构建聊天机器人、小程序、支持工作流和合规商业场景的独立工具。

结论

这三种方法都不能完全取代其他方法。

1. 当流程必须通过移动应用运行时，需要云手机。
2. 当公司需要 Telegram 中的独立软件参与者或通过授权实现商业聊天自动化时，Bot API 是合适的。
3. 当系统必须使用完整的用户会话进行工作时，需要 MTProto。

然而，一旦会话数量增加，核心问题就不再是发送单个 API 请求，而是管理整个账号生命周期。在这个层面上，Telegram Expert 将零散的会话文件和独立脚本转化为了一个集中的管理系统。

您可能还喜欢