用途
本技能用于判断和处理需要使用 Telegram 用户账号（userbot）而非 bot token 的任务场景。文档基于 Telethon 1.44.0 与 core.telegram.org（截至 2026-08-25）整理，指出一个 bot token 是发给软件的凭证，而 MTProto 会话是一个已登录的真实人账号，持有与本人相同的权限，且缺乏 token 的保护机制。
主要能力与判断标准
技能提供一张判断表，区分哪些任务可以用 bot API、哪些必须用 userbot：
- 对机器人所在聊天中的消息做出反应：可用 bot。
- 向已启动机器人的用户发送消息：可用 bot。
- 读取机器人作为管理员管理的公开频道：可用 bot。
- 读取机器人并非管理员的频道历史：需 userbot。
- 读取聊天加入前的历史记录：需 userbot。
- 以特定人身份操作：需 userbot。
- 下载超过 20 MB 的文件：需 userbot，或本地 Bot API 服务器（本地服务器无需账号即可突破文件上限）。
- 批量枚举群组成员：需 userbot，但需注意风险。
使用方式与关键要点
会话文件是凭证：.session 文件可无密码、无 2FA 提示地完全访问账号，复制到另一台机器即可登录。应放入密钥库、加入 .gitignore，并像对待密码一样对待备份，绝不能放入镜像层或日志。api_id/api_hash 来自 my.telegram.org，标识应用而非账号。
FloodWaitError 是 API 正常工作：应捕获并设置可接受上限，超过则抛出；等待应放在带队列的 worker 中，而非请求处理路径内。极大秒数意味着账号正被限制，继续运行会将限制升级为封禁。
固定次版本号：次要版本会改变会话和实体缓存行为，用户机器人的依赖是持有登录态的协议客户端，升级需独立变更并验证。
实体解析需付出代价：get_entity 可能触发网络请求，循环调用易导致 FloodWait；应优先使用已有 ID，使用库自带的 iter_messages、iter_dialogs 迭代器，批量导出应使用 takeout。
适用场景与限制
当一个任务必须使用用户账号而非 bot token 时适用，例如读取 bot 无法看到的历史记录、以人身份操作、大规模导出或下载大文件。限制与风险包括：用户账号可能被限制或封禁，Telegram 通常不解释、不快速申诉、不恢复内容；若账号属于真实的人，影响范围涉及其消息、群组和登录信息。会话被撤销是终态故障，应告警并停止工作直至重新登录，绝不能进入崩溃循环。不应将用户机器人放在关键路径上。
发布前检查清单
- 已写明需要用户账号的原因，并核实过 bot API 替代方案。
- 会话已存入密钥库、加入 .gitignore 且可撤销。
- 已捕获、设上限并告警 FloodWaitError，绝不无界等待。
- 客户端版本已固定，升级是独立变更。
- 失效会话应通知人工而非无限重启。
文档另提及 Telethon 项目的实测情况：五个项目中五个将 session 加入 gitignore；六个项目中三个处理了 FloodWaitError；四个机器人固定 telethon==1.37.0，一个运行 1.44.0。