Telegram创始人Pa vel Durov最近宣布了一项更新，乍一听似乎只是技术细节：Bot现在可以直接和其他Bot对话了。但真正值得玩味的是他后续的定义——自主Agent从此拥有了一个「人类可旁观」的原生通信层。这项被命名为Bot API 10.0的更新，早在5月8日就已落地，而Durov在5月18日用一条帖子将其重新定义为AI基础设施，吸引了超过13万次围观。

一次重新定义：从功能更新到基础设施

5月18日，Pa vel Durov在社交平台X上发布了那条引发关注的帖子。他开篇便写道：“AI开发者要的，我们做到了。”紧接着是核心声明：“Telegram上的Bot现在可以直接和其他Bot对话了。”而最后一句才是点睛之笔：“自主Agent从此拥有了一个人类可以跟踪观察的通信层。”

▲ Durov的官宣帖获得了大量关注

这里的措辞转变非常关键。他没有将其描述为一次简单的API功能新增，而是直接将Telegram定位为AI Agent的原生通信基础设施。这一定位上的升维，让这次更新超越了单纯的技术迭代。

功能早已上线：官方文档揭示的细节

事实上，在Durov发帖引发热议之前，这项功能已经静默上线了10天。翻看Telegram官方的更新日志，Bot API 10.0的发布日期明确写着2026年5月8日。

▲ 官方更新日志记录了确切的发布日期

根据官方文档，这次更新主要包含三层能力：

第一，Bot之间可以私聊。只要双方都启用了相应设置，Bot就能通过对方的@用户名直接发送消息。

第二，企业Bot可以回复其他Bot。连接到同一企业账号下的Bot，能够进行内部通信。

第三，群组内可见其他Bot的消息。开启特定模式后，Bot能在群聊中看到并响应其他Bot的内容。

换句话说，Durov帖子中那句“Bot可以互相对话”，实际上涵盖了私聊、群聊和企业工作流三条独立的通信路径。官方文档早已写明了技术细节，而Durov所做的，是用一个更具想象力的概念——“AI Agent通信层”，将这次技术更新重新包装并推向了公众视野。

官方文档的深层含义

在Telegram官方的Bot功能页面，“Bot-to-Bot通信”已被单独列为一个章节。文档首先回顾了历史背景：过去，Telegram上的Bot通常无法看到其他Bot的消息，彼此处于“失明”状态。

但现在情况改变了。官方文档明确指出，在特定上下文中，Bot-to-Bot通信已被允许，目的是“解锁复杂的Agent工作流和AI用例”。请注意这里的用词——agentic flows。这意味着Telegram自身也清楚，打开这个通道后，最主要的应用者将是AI Agent的开发者。

具体到应用场景：

在群聊中，Bot可以通过特定命令或直接回复与其他Bot交互。如果至少一方启用了通信模式，接收方就能收到并回应。

在私聊场景下，规则更为直接：Bot只需将另一个Bot的@用户名传递给发送消息的方法，即可发起私聊。

这揭示了一个关键点：Telegram并未重新发明一套复杂的通信协议，而是将现有Bot API的寻址能力，从“Bot找人”自然扩展到了“Bot找Bot”。能力的升级发生在消息权限和路由层面，开发者无需学习全新的技术范式。

企业场景的想象空间则更大。当Bot通过特定模式连接到企业账号后，可以在同一业务环境下与其他Bot协作。这直接将应用场景从“AI玩具”推向了真实的企业工作流，例如客服Bot、预订Bot、审核Bot可以在同一个消息环境中协同工作。

为何被视为“基础设施”？

开发者社区之所以将此次更新视为基础设施级别的变动，而非一个“小功能”，根本原因在于Telegram本身的性质。它不是一个纯粹的开发者工具，而是一个已经拥有庞大用户关系网络、频道、群组和商业场景的成熟平台。

Bot-to-Bot通信的开放，同时改变了三件事：

首先，通信链路被简化了。过去，要实现多Agent协作，往往需要开发者自建中继服务器或桥接层，手动将一个Bot的输出转换为另一个Bot的输入。现在，Telegram提供了一部分原生路径，相当于官方替开发者承担了部分中间件的工作。有开发者直言，这省去了过去自己搭建通信桥梁的麻烦。

其次，协作过程从黑盒走向透明。这正是Durov所说“人类可跟踪观察”的意义所在。Bot之间的对话可以发生在群聊中，人类能够实时观察交互过程。这不仅提升了Agent的自主能力，更关键的是提升了整个流程的可观察性。试想这些场景：一个总控Bot在群聊中将任务拆解给检索Bot和分析Bot，全程留痕；一个客服Bot将复杂问题转交给专家Bot处理，过程对用户可见。这种透明化对于调试、监督和用户体验都至关重要。

最后，分发、交互与协作实现了平台统一。Telegram原本就具备Bot分发、深度链接、群组管理、Business接入等成熟机制。如今叠加Bot-to-Bot通信能力，平台正从“支持单个Bot运行”向“支持Agent团队在统一消息网络中协作”演进。

一盘更大的棋：Telegram的近期布局

将这次更新放入Telegram近期的产品路线图中观察，会发现它并非孤立事件，而是一系列连贯动作中的关键一环。

4月3日，Bot API 9.6发布，推出了Managed Bots功能。新增的能力让开发者可以通过API创建和管理子Bot，这实际上是在解决Agent的“批量创建与生命周期管理”问题。

5月8日，Bot API 10.0发布，核心正是Bot-to-Bot通信。这解决了Agent之间“如何对话”的问题。

5月9日，主流开发者社区迅速跟进。例如python-telegram-bot社区立即将对此功能的全面支持列入开发清单。

▲ 开发者社区的快速响应

5月18日，Durov亲自下场，用“AI Agent通信层”的概念进行重新定义和公众传播。

这条清晰的脉络显示，Telegram正在系统性地构建能力：先用Managed Bots解决创建和管理问题，再用Bot-to-Bot解决通信问题，结合其已有的商业接入、流式文本、聊天自动化等功能，其战略意图愈发明显——正从“承载Bot的聊天应用”转向“承载Agent工作流的消息平台”。

社区与媒体的反应：兴奋与追问

更新很快引发了外界关注。TechTimes在同一天发布了专题报道，将其定义为面向自主AI Agent的原生协调层。

▲ 媒体的报道视角

开发者社区的反应则呈现出多元视角：兴奋派认为这是构建Agent基础设施的重要拼图，甚至有人形容“Agent网络终于有了自己的神经系统”。工程派更关注实际开发效率的提升，欣喜于可以减少自建中间件的成本。而追问派则立刻提出了更深层次的问题：是否有细粒度的权限控制？如何验证身份？消息来源如何证明？速率限制如何协商？这些问题都指向同一个核心判断：消息通道的打通只是第一步，与之配套的信任层和控制层尚未完全就位。

官方的冷静提醒：警惕无限循环

在官方文档中，有一个部分不容忽视，那就是关于防止循环（Loop Prevention）的要求。Telegram明确警告：“Bot-to-Bot通信很容易导致无限的交互循环。”因此，它要求开发者必须实现消息去重、速率限制、设置最大交互深度和超时控制等机制，确保即使面对其他Bot的连续高速响应，自己的Bot也能保持稳定。

这段提醒至关重要。它意味着Telegram在开放强大能力的同时，也提前划定了安全红线。平台没有假设这项功能天生安全，而是明确将防止恶性循环的责任交给了开发者，这体现了一种务实的产品设计思路。

边界与未来：真正的价值与局限

在乐观之余，也需要冷静看待这次更新的边界。Telegram目前做到的是：在现有的、成熟的Bot API框架内，开放了几条Bot-to-Bot的原生消息路径。这确实显著降低了在Telegram生态内构建多Agent工作流的技术门槛和复杂度。

然而，Telegram尚未提供（或尚未完整提供）的，是一套更深入的治理框架，例如Agent身份认证、消息来源证明、动态权限协商机制以及可信执行环境等。官方目前仅给出了防止循环的提醒，更深层次的协作治理问题，仍然留待开发者和后续的生态发展来解决。

简而言之，通信的“道路”已经打通，但道路上的“交通规则”和“信任体系”还在建设中。

因此，如果将Durov的宣言理解为“Telegram已经发布了一套完整的Agent协议”，那无疑是过度解读。但如果仅仅将其看作“又多了一个Bot小功能”，则严重低估了Telegram在AI Agent基础设施层面的战略布局。

更准确的定位或许介于两者之间：Telegram为AI Agent开辟了一条原生通信通道，并将其置于一个拥有近十亿用户的、活跃的消息网络之中。这种“能力”与“规模”的结合，本身就是其当前最独特的壁垒所在。未来的发展，将取决于生态如何在这条新开辟的道路上，构建起繁荣、安全且高效的应用景观。