openJiuwen发布ADF：让物理设备成为Agent可调用的能力

写代码、查资料、调 API、操作软件，现在的 Agent 已经能做这些。那要是它走出屏幕呢？

想象一下：

家里的门锁、空调、灯光、扫地机器人，不用再一个个去操作。家庭 Agent 能弄明白这些设备各自能干什么，拿到授权后按需要把它们组合起来调用。碰上某台设备临时不可用，它也会另找办法，把日常任务接着做完。

到了会议室也一样。投屏、摄像头、打印机不必挨个去连——办公 Agent 会先识别周围设备具备哪些能力，再照会议需求把设备配置好，现场情况有变就随时调整方案，让会议顺利开下去。

对科研 Agent 下的指令不再是“打开某台仪器”，而是“完成这一轮实验”。它得调用不同厂商的机械臂、检测仪器和实验设备，依据实时状态决定下一步怎么走，还要判断预期结果是不是真的出现了。

真正变的不只是 Agent 能连上更多设备。现实世界里的设备，开始成为 Agent 能够理解、挑选和组织的能力。要走到这一步，设备接入就得有一套面向 Agent 的统一协议规范。

一、设备已经有接口，为什么还需要新的协议？

现实中的设备并不缺接口。智能灯能通过网关控制，实验仪器往往带厂商 API，机器人也有自己的 SDK 和控制框架。可当 Agent 从调用单个设备，转向跨终端、跨设备、跨场景持续完成任务，光“把接口接进来”就不够了。

眼下大多数设备接口，说到底仍是给应用程序和开发者设计的：开发者清楚该调哪个 API、返回结果怎么解释、设备当前能不能用、失败了该怎么处理。Agent 面对的是另一类问题——现实世界中有哪些能力、哪些此刻能用，它要怎么动态弄明白；一次调用之后，现实世界到底发生了什么。

于是，当越来越多真实设备进入 Agent 的任务体系，几个共性问题就冒了出来：

• 其一，设备接口异构，能力缺少统一表达。

API、SDK、物联网协议、操作系统接口和机器人控制框架里，都散落着设备能力。同一种能力可能由不同接口提供，Agent 缺少一套跨设备、跨厂商理解能力的统一方式。

• 其二，“设备有什么能力”和“此刻能用什么能力”并不是一回事。

在线状态、权限、占用情况、网络条件、运行模式、环境状态，都会让能力的实际可用性发生变化。对 Agent 来说，静态的接口清单撑不起动态的任务执行。

• 其三，单设备调用正在变成多设备、多步骤的任务执行。

真实任务往往不是调一次 Tool 就完事：一场会议可能牵扯屏幕、摄像头和音响；一次实验可能牵扯机械臂、检测仪器和环境设备；家庭任务也可能横跨门锁、照明、空调和清洁设备。Agent 要的是能被挑选、组合并持续使用的设备能力，而非一堆彼此孤立的接口。

• 其四，调用成功不等于现实世界已经完成。

命令发出去了、API 返回 success，只能说明一次软件调用结束，证明不了设备产生了预期的物理效果。要是 Agent 分不清“接口成功”“设备效果发生”和“任务可以继续”，后面的规划就可能建在错误状态上。

这说明，Agent 与设备之间还差一个面向 Agent 的能力层。

我们正在构建智能体设备接入规范 ADF（Agent Device Foundation）。它想做的，是在现有设备接口之上立起一套面向 Agent 的统一能力表达与运行语义，让不同类型的真实设备以更一致的方式进入 Agent 的任务体系。ADF 眼下先发布 ADF-EA（Execution Assurance），从真实设备接入后最基础也最关键的执行可信问题入手，围绕执行条件、预期效果、结果验证与中断恢复建立统一的执行语义。

二、ADF：让硬件从“设备接口”变成“Agent 能力”

ADF 不替代已有的 API、SDK、IoT 协议和机器人控制框架，它盯的是这些接口上面的一层：怎样把不同硬件已有的功能，表达成 Agent 能理解、能判断、能持续使用的“能力”。往下，它对接现有设备接口与控制体系；往上，它给 Agent 提供一致的设备能力描述与运行语义，让不同类型、不同厂商的硬件以更统一的方式进入 Agent 任务体系。

对 Agent 来说，一项设备能力不只是一个能调的 Tool。它还要知道：这项能力是什么、当前能不能用、什么条件下可以执行、执行后该产生什么效果，以及任务途中设备状态变了怎么办。所以 ADF 关心的不只是设备接口本身，还有围绕设备能力形成的一整套通用语义，比如：

• 能力描述：设备能提供哪些能力，执行这项能力需要什么输入；

• 动态状态：这项能力当前是否存在、是否可用，以及影响可用性的设备与环境状态；

• 执行条件：处于哪些状态才允许动手，哪些前提必须先满足；

• 效果语义：调用一次能力，预期要让现实中的什么状态发生变化；

• 验证依据：靠哪些设备反馈、状态回读或环境观测，能证明效果确实发生了；

• 中断与继续语义：结果不明、设备不可用或任务被打断时，哪些进度可以留下，哪些动作得重新确认，任务又能不能接着往下走。

这样一来，设备接入就不再是“给某个应用单独包一层接口”，而是慢慢长出一套设备能力的表达方式，不同 Agent、不同任务都能拿来复用。

比方说，一台实验仪器适配完成之后，不同科研 Agent 和实验任务都能复用它的能力；一个应用从单设备铺到多设备，也能沿用同一套能力访问方式，不用为每个应用重做一遍设备集成逻辑。ADF 想推的是，设备接入从：

“按应用重复适配设备”

逐步走向：

转向“按能力接入设备，由不同 Agent 和任务按需取用”。

三、接进来之后，更关键的问题是：现实世界真的执行了吗？

让 Agent 看得懂、调得动设备能力，只是第一步。Execution Assurance（执行保障）是 ADF 当前首发并重点落地的一项能力，它先盯住一个真实设备接进来后绕不开的问题：

Agent 说完成了，现实世界真的完成了吗？

命令送达了、接口返回成功了，不等于设备已经把动作做完，更不等于任务需要的真实状态已经建立。设备一旦进入任务执行链路，“接口结果”和“实际效果”之间的这道缝，就会直接决定后面的任务能不能可靠推进。

放在家里，可能只是灯没亮；放到实验室，可能意味着实验条件根本没建立起来；到了机器人和工业现场，后续动作就可能踩在错误的状态上。

所以，Agent 一旦开始操作现实世界，光知道“命令发出去了”不够，还得知道：

• 眼下到底具不具备执行条件？

• 预期的效果是不是真的发生了？

• 哪些信息能证明效果已经发生？

• 结果不明或者任务中断之后，该怎么接着做？

这正是 ADF 里 Execution Assurance 要重点解决的问题。ADF 引入了机器可读的 Device Capability Contract（设备能力契约），把原本散落在设备文档、控制程序和业务流程里的执行要求，整理成智能体系统能读取、能检查的统一规范描述。

围绕一次设备能力执行，能力契约会描述它的调用语义、效果语义、验证语义和中断语义：执行前说清楚什么条件下允许调用；执行中说清楚预期产生什么状态变化；执行后说清楚靠哪些反馈或观测确认效果；结果不确定或任务被打断时，则说清楚哪些进度已经成立、后面该怎么继续。

Execution Assurance 则把设备状态、执行反馈和环境观测放在一起，在实际运行过程中核对这些要求。

它盯的不只是某一次 Tool 有没有返回成功，而是要分清：

设备调用成没成、预期效果有没有得到确认，以及任务还有没有依据继续往下推。

于是，Agent 判断任务状态的依据开始从：

“我调用过什么”，

走向：

到“我已经确认发生了什么”，Agent 判断任务状态的依据变了。

这也是 ADF 迈出的第一步：设备不再只是能被调用，设备能力开始能被 Agent 可靠地使用。

四、从单设备验证，到多设备真实场景

ADF v0.1 的参考实现挑了一盏智能台灯。场景不复杂，但要回答一个最基础的问题：Agent 认为灯开了，灯是不是真开了？

原型里，Agent 能通过接口控制台灯的开关与亮度。设备出故障、开关灯 Tool 实际调用失败时，ADF 会依据能力契约和实际调用反馈维护执行状态：没确认成功，任务就不算完成，也不会自行改走未经约定的其他控制路径。

这就构成了 ADF-EA 最小的执行保障闭环：

设备调用 -> 执行反馈 -> 状态确认 -> 任务是否可以继续。

用户通过 WorkSwarm 控制台灯打开

设备异常情况下，ADF 进行执行状态确认

从一盏灯，进一步走向多设备协同

出差在外，家里的宠物有没有按时吃饭？屋里是不是太热？能远程查看家里情况，不代表所有事都能顺利办完。你可能得先看摄像头和温湿度计，再分别操作喂食器和风扇；设备没按预期工作，还得再确认一遍。

交给 Agent 来做，它就得把环境感知和设备控制接起来：靠 HarmonyOS 手机摄像头和传感器了解家里的情况，按实际状态调用智能喂食器、风扇等设备，并确认这些操作是否真的执行。Demo 中，Agent 围绕宠物喂食、保持适宜室温等任务，结合实时环境状态选择设备能力，与鸿蒙设备进行流程感知和监控。我们还构造了设备正常与故障两类场景，对比接入和未接入 ADF-EA 时的执行结果。设备没有产生预期效果时，ADF-EA 能识别出执行结果尚未成立，避免 Agent 只凭 Tool 调用结果就把任务误判为完成。

这一场景验证的不再只是单个设备能不能被调用，而是环境感知、条件判断和设备执行如何一起推动任务。不同设备的能力可以围绕同一任务被选择和组合，再依据实际执行状态继续推进。

用户通过 WorkSwarm 完成宠物关怀任务，ADF-EA 基于环境状态确认设备执行结果

五、在华为设备上实现更强大的 Agent 能力

华为设备的软硬件能力与鸿蒙生态也能被 ADF 用起来，使设备接入进一步走向能力层面的协同。在具备相关能力、完成适配并取得用户授权的设备上，跨设备连接与通信的底座由鸿蒙分布式软总线（DSoftBus）提供；不同终端开放的感知、交互和执行能力，则由 ADF 在设备互联与现有控制接口之上组织成 Agent 能理解、能组合、能验证的能力。下层设备互联加上上层能力语义，配合起来能少做重复集成，也让 Agent 围绕同一任务把多台设备协同调用起来。

这种协同也给执行保障提供了更充分的依据。接入设备开放的状态接口、传感器数据和执行反馈后，ADF 能把真实状态纳入能力契约的检查与验证；再结合适合在端侧运行的计算环节与本地通信链路，还能减少不必要的云端往返，让环境判断和执行反馈更及时地进入 Agent 的任务过程。

鸿蒙全场景 Vlog 快创工作流就是一个具体场景。围绕“手机与云台轻量拍摄、拍后剪辑并上传鸿蒙 PC”的创作目标，Jiuwen WorkSwarm 把电脑上的软件操作与手机、云台参与的物理拍摄过程串了起来。拍摄时，用户对着鸿蒙 PC 上的字幕口播，手机负责画面采集，大疆云台通过人脸追踪辅助保持人物入镜。画面采集与云台跟拍配合，让用户更专注内容表达，减少拍摄中手动调整机位的操作。拍完之后，Jiuwen WorkSwarm 衔接素材剪辑与上传，把剪辑后的内容传到鸿蒙 PC，方便后续查看、整理和使用。

拍摄有没有结束、剪辑有没有做完、文件有没有到目标 PC，这些状态与结果反馈都是进入下一步的依据，ADF 的执行保障由此有了具体落点。随着 ADF 与华为设备及鸿蒙生态的协同继续加深，我们希望 Agent 能更充分地组合使用设备功能，并依托及时、可确认的执行结果，把从拍摄到内容处理的完整创作任务一步步推进下去。

用户通过 WorkSwarm 完成自媒体工作流快速创建

六、让真实世界成为 Agent 的能力空间

往后，Agent 能用的能力不只来自 App 和云服务。在家里，它可能同时用上摄像头、传感器、照明、空调、门锁和家电；在办公室，它可能调用会议设备、显示终端、打印机和环境设备；在实验室，它可能组合不同厂商的机械臂、检测仪器和实验设备；到了工业现场，它还要面对持续变化的传感器、执行设备和机器人。

Agent 承担的任务越来越复杂，它需要的就不只是更多设备接口，而是能理解能力、判断可用性、验证执行结果，并在状态变化时合理推进任务。

接下来，ADF 会跟伙伴一起把设备能力描述、动态状态、执行保障、跨设备协同这几类规范继续做下去，并陆续集成进 openJiuwen、对外开源，让面向 Agent 的设备接入规范不断往前迭代。