Agent 要接管真实设备了：openJiuwen 抛出 ADF 规范

让 Agent 帮你订机票，出错了最多改签；让 Agent 帮你开燃气灶，出错了是另一回事。当智能体从屏幕走进物理世界，调用成功和事情办成之间的距离，会变成致命的问题。

一分钟速览

• openJiuwen 发布智能体设备接入规范 ADF（Agent Device Foundation）；
• 首个版本为 ADF-EA，聚焦 Execution Assurance，即执行可信；
• ADF 不替代 API、SDK、IoT 协议和机器人框架，而是在其上加一层能力语义；
• 核心解决四类问题：接口异构、能力静态与动态之别、多设备多步任务、效果无法验证。

设备不缺接口，缺的是能力

现实中的设备并不缺控制方式。智能灯有网关，实验仪器有厂商 API，机器人有 SDK。但这些接口都是给知道该调什么的开发者设计的。Agent 面对的是另一个问题：它得先知道世界上有哪些能力、此刻哪些可用、调用之后现实发生了什么。

举个具体的例子。会议室里的投屏、摄像头、打印机分属不同厂商，接口各异。人类会先看现场情况再决定怎么连；Agent 拿到一份静态接口清单，却不知道某台设备是不是正被占用、网络通不通、权限够不够。清单是静态的，可用性是动态的。

接口返回 success 是个陷阱

这是 ADF-EA 最想解决的问题。命令发出去了，接口返回 200，只能证明一次软件调用完成，不能证明设备真的执行了。机械臂可能卡住了，门锁可能没弹开，打印机可能缺纸。

如果 Agent 分不清接口成功、效果发生、任务可继续这三种状态，后续规划就会建立在错误的前提上，错误还会沿着任务链放大。ADF-EA 因此围绕四件事建立统一语义：执行条件、预期效果、结果验证、中断恢复。

六个语义层

ADF 把设备能力拆成可被 Agent 理解的六个维度：能力描述（提供什么能力、需要什么输入）、动态状态（当前是否存在、是否可用）、执行条件（什么状态下允许执行、有哪些前置条件）、效果语义（这次调用应该改变什么真实状态）、验证依据（哪些反馈、状态回读或环境观测能证明效果发生）、中断与继续语义（执行被打断后如何恢复）。

向下，ADF 对接已有的设备接口与控制体系；向上，给 Agent 提供一致的能力描述。这个分层很关键——它不要求厂商推翻现有协议，只要求在之上补一层给 Agent 看的说明书。

为什么现在做这件事

时机不难理解。Agent 的能力边界正从操作软件扩展到操作设备，而设备侧的标准化几乎空白。谁能先把这层语义定下来，谁就有机会成为具身智能时代的驱动层。

但挑战同样明显：规范的生命力在于 adoption。设备厂商愿不愿意按这套语义描述能力，决定了 ADF 是成为标准，还是停留在论文里。接下来要看的，是有多少主流硬件厂商接入了 ADF-EA，以及有没有真实的跨品牌任务跑通。