过去两年数字 Agent 世界发生了两件确立标准的事。Anthropic 在 2024 年底发布 Model Context ProtocolMCP定义了 Agent 怎么标准化地调用外部工具和数据源Google 在 2025 年发布 Agent2Agent ProtocolA2A定义了不同厂商、不同框架构建的 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这层协议现在谁都没有真正做出来眼下讨论的更多是它应该长什么样而不是已经有了答案。