返回博客

Telegram 长任务机器人怎么设计:流式回复、停止与私聊主题

把流式草稿、停止操作和私聊主题写成可验收的 Telegram 机器人需求,让搜索、报告和 AI 任务既有进度反馈,也不会混淆上下文。

发布于 2026年10月12日

需要几十秒的搜索、文档整理或 AI 生成任务,不能只设计“输入问题—等待—返回答案”。用户还需要知道任务是否开始、能否停止,以及几项工作是否会串到同一段上下文里。

Telegram 的官方机器人能力为这三个问题提供了不同组件:流式草稿用于展示进行中的结果,停止操作用于撤销仍在执行的工作,私聊主题用于隔离长期会话。它们解决的是交互和会话组织问题,并不会自动提供模型、记忆、工具调用或任务调度。

先把三个组件分开

| 组件 | 解决的问题 | 不能替代什么 | | --- | --- | --- | | 流式草稿 | 减少长时间无反馈,让用户看到任务仍在进行 | 最终持久消息、错误恢复 | | 停止操作 | 让用户表达“不要继续”,并通知机器人取消后台工作 | 自动终止外部 API、退款或回滚 | | 私聊主题 | 将订单、项目或支持工单分开 | 权限隔离、数据库租户隔离 |

Telegram 官方文档说明,流式草稿只在私聊中作为临时预览;普通草稿约为 30 秒预览,完成后仍需发送最终消息,才能把结果保留在聊天中。Bot API 10.3(2026 年 8 月 24 日)还增加了可停止草稿以及用户停止生成后的更新。

私聊主题则需要先在 Telegram 官方 BotFather 中为机器人启用。机器人可以创建、编辑和删除主题,并在发消息时使用对应的消息线程标识。主题适合把“订单 1032”“每周市场报告”和“产品故障排查”分开,但不能把主题名称当成可信的访问控制。

一份可直接修改的需求

可以先把业务写成下面这种形式:

请创建一个只在 Telegram 私聊中工作的长报告机器人。用户提交任务后,机器人立即确认已开始,并在同一任务中显示临时进度;完成后发送一条可长期保留的最终消息。用户可以在生成期间停止任务,停止后不得继续发送该任务的后续草稿或最终结果。每个新项目可以建立独立私聊主题,后续消息和结果必须回到原主题。若当前运行环境不支持流式草稿、停止更新或私聊主题,请明确指出不支持的部分,并降级为“开始提示 + 最终消息 + /cancel”,不要模拟已支持的 Telegram 原生能力。第一版不需要付费模型、任意 npm 模块或外部任务队列。

这段需求刻意写了降级方式。若某项 Bot API 能力尚未出现在所用 SDK 或托管运行时中,正确结果应是明确缩小范围,而不是生成看似存在但无法工作的按钮或方法。

任务状态需要独立于消息

不要用“最近发出的消息”代表任务状态。至少为每项任务记录:

  • 稳定任务编号、发起用户和消息线程标识;
  • 当前状态,例如排队、运行、停止中、完成或失败;
  • 最后一次对用户可见的进度;
  • 是否已发送最终结果;
  • 取消请求发生的时间。

用户点击停止后,机器人应先把任务标为不可继续输出,再尝试取消模型请求、搜索或文档生成。外部服务不一定支持立即取消,因此“停止显示后续结果”和“后台计算已经终止”是两项不同的验收结果。

流式内容要限制频率和信息类型

草稿更新太频繁会浪费请求额度,也可能造成闪烁。可以约定只在内容有实质变化时更新,例如每隔固定时间或累计一定字符后更新一次。

进度文字应说明可观察的阶段,如“正在读取 3 份资料”或“正在生成最终摘要”。不要把“思考中”当成模型隐藏推理过程的公开记录。Telegram 官方也明确说明,Thinking 占位符是呈现元素,不是模型推理文本。

草稿里还应避免放入令牌、内部错误堆栈或尚未核实的最终结论。最终消息需要重新组装并检查;不能默认最后一个草稿已经等同于可保留结果。

用六组场景验收

  1. 正常完成: 提交任务后立即有确认,期间能看到进度,结束时出现持久的最终消息。
  2. 用户停止: 生成中停止后,状态变为已停止,不再出现迟到草稿或最终结果。
  3. 停止与完成竞争: 停止和完成几乎同时发生时,只能留下一个终态,不能同时显示“已停止”和完整结果。
  4. 主题隔离: 在主题 A 和 B 分别提交任务,进度、结果和后续问题不会发错主题。
  5. 重启恢复: 机器人重新启动后,能识别未完成任务并按约定恢复、失败或要求重试,不把旧草稿当成完成。
  6. 能力降级: 在不支持原生流式或主题的环境中,仍能用普通状态消息和命令完成主要流程,并清楚告知差异。

与 BotFatherV2 的关系和边界

BotFatherV2 支持通过 AI 对话创建和修改 Telegram 机器人。你可以用上面的需求和验收场景描述期望行为,再核对生成版本实际采用了哪些 Telegram 能力。

BotFatherV2 是与 Telegram 官方 BotFather 无隶属关系的独立产品。其当前公开 AI 开发文档说明,首版不新增依赖付费 AI 的机器人运行能力,固定 SDK 范围也不支持任意 npm 模块或 Node/Bun API。本文介绍 Telegram 平台公开能力,不代表 BotFatherV2 当前运行时已支持所有 Bot API 10.3 接口;生成前应以最新校验结果和产品文档为准。

来源与核验日期

  • Telegram,《Telegram Bot Features》,英文官方文档,页面未标注发布日期;2026 年 10 月 12 日核验。
  • Telegram,《Telegram Bot API》,英文官方文档;Bot API 10.3 更新日期为 2026 年 8 月 24 日,2026 年 10 月 12 日核验。
  • BitBear Studio,BotFatherV2 《使用 AI 开发》,中文产品文档,页面未标注发布日期;2026 年 10 月 12 日核验。

相关文章

继续阅读具有相同产品标签的内容。

Telegram 机器人深链怎么设计:启动参数、群组安装与来源识别

说明 Telegram 机器人 start 与 startgroup 深链的设计方式、64 字符限制、来源归因、安全边界和可验收的首次使用流程。

Telegram Serverless 机器人如何防止重复处理:Webhook 与幂等检查清单

根据 Telegram Webhook 的重试与 update_id 规则,把防重复写入、重复发券、乱序更新和安全校验写成可验收的 Serverless 机器人需求。

Telegram 机器人交互怎么选:命令、按钮还是自然语言

按任务类型选择 Telegram 机器人的命令、回复键盘、内联按钮和自然语言输入,并把交互方式写成可验收需求。

Telegram 原生 Checklist 还是待办机器人?先看是否需要自动化

比较 Telegram 原生协作清单与自定义待办机器人,按成员权限、提醒、数据隔离、统计和外部集成决定是否值得开发。

导入 Telegram Serverless 机器人:迁移前后的检查清单

确认机器人是否可导入、保存云端基线、盘点模块与外部服务,并在修改前后检查版本、数据和真实 Telegram 行为。

Telegram 机器人命令菜单怎么设计:范围、语言与权限

把私聊、群组、管理员和不同语言的命令菜单写成清晰需求,并避免把菜单可见性误当成后端授权。