导读
Telegram 创始人 Pavel Durov 宣布：Bot 现在可以直接和其他 Bot 对话。更关键的定义是——自主 Agent 从此拥有了一个「人类可旁观」的原生通信层。Bot API 10.0 早在 5 月 8 日就已落地，Durov 用一条帖子把它重新定义为 AI 基础设施，13 万人围观，2300 人点赞。
Durov 的原话，直接把 Telegram 定义成了 Agent 基础设施
5 月 18 日，Telegram 创始人 Pavel Durov 在 X 上发了一条帖子：
"AI devs asked for this — and we delivered."
「AI 开发者要的，我们做到了。」
"Bots can now talk to other bots on Telegram."
「Telegram 上的 Bot 现在可以直接和其他 Bot 对话了。」
"Autonomous agents now have a communication layer humans can follow."
「自主 Agent 从此拥有了一个人类可以跟踪观察的通信层。」
▲ Durov 在 X 上的官宣帖，13 万次查看，2300+ 点赞
最后那句才是重点。他没有把这次更新说成"Bot API 新增了一个开关"，而是直接把 Telegram 定位成了AI Agent 的原生通信基础设施。
但 Durov 发帖之前，功能已经上线 10 天了
很多人以为这是 Durov 一发帖就上线的功能。实际上不是。
翻开 Telegram 官方的 Bot API changelog，Bot API 10.0 的发布时间是 5 月 8 日——比 Durov 的帖子早了整整 10 天。
▲ Telegram 官方 Bot API changelog，Bot API 10.0 发布于 2026 年 5 月 8 日
changelog 里写得很明确，这次更新包含三层能力：
第一层：Bot 之间可以私聊。只要双方都启用了 bot-to-bot communication，Bot 就可以通过对方的 @username 直接发消息。
第二层：Business Bot 可以回复其他 Bot。连接到企业账号的 Bot，能给同一业务下的其他 Bot 发消息。
第三层：群组里可见其他 Bot 的消息。开启该模式的 Bot，能在群聊中看到其他 Bot 发的内容。
换句话说，Durov 帖子里的"Bots can now talk to other bots"其实包含了私聊、群聊、企业工作流三条独立路径。5 月 8 日官方文档就已经把能力写清楚了，Durov 做的事情是：用 AI Agent 通信层的说法，把开发者文档里的技术更新重新包装，送上了公众视野。
官方文档到底说了什么？比 Durov 的帖子详细得多
Telegram 官方的 Bot Features 页面，把 Bot-to-Bot Communication 单独列成了一节。
▲ Telegram 官方 Bot Features 文档中的 Bot-to-Bot Communication 章节
先看历史背景。Telegram 官方自己承认：
"On Telegram, bots generally cannot see messages from other bots."
「在 Telegram 上，Bot 通常看不到其他 Bot 的消息。」
过去的 Telegram Bot 生态里，Bot 之间默认是互相"失明"的。你在群里有两个 Bot，它们彼此看不到对方说了什么。
现在变了。官方在同一段里紧接着写：
"However, in specific contexts, Bot-to-Bot communication is allowed – unlocking complex agentic flows and AI-powered use cases."
「但在特定上下文中，Bot-to-Bot 通信被允许——从而解锁复杂的 Agent 工作流和 AI 用例。」
注意这里的用词：Telegram 官方自己把这项能力和agentic flows挂钩了。这意味着 Telegram 自己也知道，打开这个通道后，来用它的主力军会是 AI Agent 开发者。
具体来看适用场景：
群聊场景：Bot 可以通过 `/command@OtherBot` 或直接回复另一个 Bot 来交互。如果至少一方启用了 Bot-to-Bot Communication Mode，接收方就能收到并回应。某些情况下，开启该模式的 Bot 还能直接收到群里其他 Bot 的消息，不需要每次都被 @。
私聊场景：官方写法更直接——
"Bots can send private messages to other bots by passing their @username to the sendMessage method."
「Bot 可以把另一个 Bot 的 @username 传给 sendMessage，以私聊方式给它发消息。」
这说明 Telegram 没有重新发明一套 Agent 通信协议。它做的事情是：把现有 Bot API 的寻址能力，从"Bot 找人"扩展到了"Bot 找 Bot"。能力升级发生在消息权限和路由层，不需要开发者学习全新范式。
企业场景：如果某个 Bot 通过 Chat Access Mode 连接到了 Business Account，它可以给该业务账号下的其他 Bot 发消息。这让想象空间从"AI 玩具"直接跳到了企业工作流——客服 Bot、预订 Bot、审核 Bot、CRM Bot 可以挂进同一个业务消息环境里协作。
为什么开发者不把它当"小功能"，而是当基础设施看？
因为 Telegram 不是一个纯开发者平台。它是一个已经有大规模聊天关系、频道、群组、私聊和 Business 场景的消息网络。
当 Bot-to-Bot 通信打开之后，三件事同时发生了：
1. 通信链路从"人帮 Bot 转发"变成了"Bot 直接找 Bot"。
过去很多多 Agent 流程需要自建 relay server 或桥接层，把一个 Bot 的输出转成另一个 Bot 的输入。现在 Telegram 官方给了一部分原生路径，多 Agent 协作可以少搭一层中间件。
有开发者直接说：以前做跨 Bot 通信只能自己架 bridge/relay，这次更新等于官方把一部分桥接需求吃掉了。
2. 协作从黑盒后台走向了"聊天界面可观察"。
这是 Durov 那句 "humans can follow" 的真正含义。Bot 之间的对话可以发生在群聊里，人类能实时看到谁在对谁说什么。这对产品层面非常重要：它不仅提升了 Agent 的自治能力，还同时提升了可观察性。
想象一下这些场景：
- 一个总控 Bot 把任务拆给检索 Bot、分析 Bot、总结 Bot，全程在群聊里留痕
- 一个客服 Bot 遇到复杂问题，把问题转给 Specialist Bot，结果回给用户，过程可见
- 一个 Code Review Bot 在团队群里收到另一个 Bot 的请求，给出审核反馈
3. 分发、交互、协作发生在同一平台。
Telegram 原本就有 Bot 分发、深链、群聊、BotFather 管理、Business 接入、Managed Bots 等机制。现在加上 Bot-to-Bot，平台从"Bot 可用"推进到了"Agent 团队可以在同一消息网络里协作"。
放进时间线看，Telegram 在下一盘更大的棋
这次 Bot-to-Bot 更新不是孤立事件。放进 Telegram 近期的 Bot 路线里看：
4 月 3 日，Bot API 9.6：Managed Bots 上线。Telegram 新增了 `can_manage_bots`、`getManagedBotToken`、`replaceManagedBotToken` 等能力，让开发者可以通过 Bot API 创建和管理子 Bot。这是在解决 Agent 的"批量创建和生命周期管理"问题。
5 月 8 日，Bot API 10.0：Bot-to-Bot Communication 正式发布。解决的是 Agent 之间"怎么互相说话"的问题。
5 月 9 日，python-telegram-bot 社区跟进。主流 SDK 开始把 Bot-to-Bot 支持列入开发清单。
▲ python-telegram-bot 社区在 Bot API 10.0 发布次日就开了 Full Support issue
5 月 18 日，Durov 在 X 上重新定义。用 AI Agent 通信层的框架把整件事推到公众视野。
先有 Managed Bots 解决创建和管理，再有 Bot-to-Bot 解决互相通信，叠加 Business 接入、Streaming Text、Chat Automation——Telegram 正在把自己从「承载 Bot 的聊天软件」推向「承载 Agent 工作流的消息平台」。
媒体和社区的反应：兴奋和追问并存
TechTimes 在同一天发了专题报道，把这次更新定义为面向 autonomous AI agents 的原生协调层。
▲ TechTimes 报道标题：Telegram's Bot API Now Lets Autonomous AI Agents Coordinate Directly
X 上的开发者反应分成了几个方向：
兴奋派认为这是 Agent 基础设施的关键一块拼图。有人直接说 "agentic web just got a nervous system"——Agent 网络终于有了自己的神经系统。
工程派关注的是实际开发体验。以前做跨 Bot 通信要自己搭桥接层，现在这层中间件可以省掉一部分。
追问派马上提出了更深层的问题：有没有 scoped permissions？有没有 verifiable identity？有没有 signed provenance？有没有 rate-limit negotiation？这些问题指向的是同一个判断——消息层打通只是第一步，信任层和控制层还没有一起到位。
官方自己也在提醒：小心无限循环
Telegram 官方文档里最不该被忽略的一段，是Loop Prevention Requirements。
官方明确警告：
"Bot-to-bot communication can easily result in infinite interaction loops."
「Bot-to-Bot 通信很容易形成无限交互循环。」
Telegram 要求开发者必须做到：消息去重、限速、最大交互深度限制、超时控制。即使对面那个 Bot 故意高速连续回应，你的 Bot 也必须保持稳定。
这段提醒意味着什么？Telegram 在开放能力的同时，也在提前划安全红线。它没有假装 Bot-to-Bot 天然安全，而是把循环防护的责任明确交给了开发者。
这件事的真正边界在哪里？
需要冷静看待的是：这次更新很重要，但它有明确的能力边界。
Telegram 做到的是：在现有 Bot API 上，开放了 Bot-to-Bot 的几种原生消息路径。它确实显著降低了多 Agent 工作流接入 Telegram 的门槛。
Telegram 还没做到的是：Agent 身份认证、消息来源证明（provenance）、权限协商机制、可信执行框架——这些都还没有以完整产品能力发布。官方只给了 loop prevention 提醒，更深层的治理问题仍然留给开发者和后续生态来补。
简单说：消息通道打通了，但信任基础设施还在路上。
如果你把 Durov 的帖子当成"Telegram 已经发布了完整的 Agent 协议"，那会高估这次更新。但如果你只把它当成"多了一个 Bot 小功能"，那又会低估 Telegram 在 Agent 基础设施上的布局。
真正准确的判断在这两者之间：Telegram 给 AI Agent 开了一条原生通信通道，放在一个 9 亿用户的消息网络里——这个组合本身就是它最大的壁垒。
文章来自于"林叔说事"，作者 "图灵硅硅"。