过去两年数字 Agent 世界发生了两件确立标准的事。Anthropic 在 2024 年底发布 Model Context Protocol（MCP），定义了 Agent 怎么标准化地调用外部工具和数据源；Google 在 2025 年发布 Agent2Agent Protocol（A2A），定义了不同厂商、不同框架构建的 Agent 之间怎么互相通信协作。这两层协议加起来，数字世界里"Agent 怎么连接工具、怎么和别的 Agent 对话"基本有了公共答案，不需要每接一个新工具或者新 Agent 就重新写一套适配代码。
MCP 解决的是 Agent 和工具、数据源之间的连接问题，相当于给每个工具接了一个统一插座；A2A 解决的是 Agent 和 Agent 之间的对话问题，让不同公司做的 Agent 能互相理解对方的能力和状态。这两者边界很清楚，各自解决一层问题，合在一起数字世界的互联互通基本闭环了。
机器人网络目前没有对应的东西。工业机器人内部有 ROS 2 这类成熟的通信中间件，但它解决的是同一套系统内部节点之间的实时通信，不是解决"这台机器人怎么和一个外部的数字 Agent 对话"，也不是解决"这台机器人怎么和另一家厂商的机器人协作"。现状是机器人和数字 Agent 之间的连接大多是厂商各自定制的私有接口，换一个机器人品牌就要重新对接一次，这件事的工程成本没有被摊薄过。
这层协议要解决的问题，结构上和互联网早期 SMTP 解决的问题很像——不需要做到最优，需要足够开放、足够简单，让不同厂商的设备愿意接进来。SMTP 没有解决所有邮件场景的性能问题，但它足够简单，所以所有邮件服务商都愿意支持；机器人通信协议如果绑定某个厂商的私有格式，大概率会重复移动互联网早期各家 App 互相不能分享文件的封闭阶段，只是换了个领域重演一次。
具体要求上，这层协议至少要处理三件事。异构硬件之间的能力描述，这台机器人能做什么、状态怎么表达，不能靠人工写适配文档；低延迟的实时状态同步，机器人的动作不能等一轮 HTTP 请求响应；不绑定单一厂商的开放性，否则退化成又一个私有生态，重复了封闭的老路。这三条里最难的其实是第一条——数字世界的工具能力可以用一份 API 文档说清楚，机器人的能力边界和物理约束要怎么用一套通用格式描述，目前没有行业共识。
我们在数字侧做的编排层，处理的是"哪个 Agent 负责什么、任务怎么在多个 Agent 之间路由"这类问题；往物理世界延伸的时候，如果机器人也要接入这张网络，就需要先解决它怎么被网络里的其他节点识别和调用——这和数字 Agent 接入协作网络时用一张能力名片声明自己会做什么，是同一类设计问题的物理版本，只是描述对象从软件能力变成了硬件能力和物理约束。https://github.com/orgs/Mininglamp-OSS/repositories
这层协议现在谁都没有真正做出来，眼下讨论的更多是它应该长什么样，而不是已经有了答案。
