openJiuwen首发ADF：Agent怎么真正用上物理设备

如今写代码、查资料、调API、操作软件，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能理解、能判断、能持续使用的“能力”形式表达出来。往下，ADF对接已有设备接口与控制体系；往上，它给Agent提供一致的设备能力描述与运行语义，让不同类型、不同厂商的硬件以更统一的方式进入Agent任务体系。

对Agent而言，一项设备能力不只是一个可以调用的Tool。它还得知道：这项能力是什么、当前是否可用、在什么条件下可以执行、执行后应该产生什么效果，以及任务途中设备状态变了该怎么处理。所以ADF不只管设备接口本身，还要管围绕设备能力形成的一系列通用语义，例如：

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

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

• 执行条件说的是在哪些状态下才允许动手、哪些前置条件必须满足；效果语义指的是一次能力调用预期该改变现实里的什么状态；验证依据则是靠哪些设备反馈、状态回读或环境观测，能证明效果确实发生了。

• 中断与继续语义要回答的是：结果不明、设备用不了或者任务被打断时，哪些进度能留下，哪些动作得重新确认，任务还允不允许接着做。

这么一来，设备接入就不只是“给某个应用封个接口”，而会慢慢长出一套能被不同 Agent、不同任务反复使用的设备能力表达方式。

比如一台实验仪器适配完之后，不同科研 Agent 和实验任务都能复用它的能力；一个应用从单设备扩到多设备，也能沿用同一套能力访问方式，不用为每个应用重新设计设备集成逻辑。ADF 想推的转变是：从“按应用重复适配设备”，[[保留1]]走向“按能力接入设备，由不同 Agent 和任务按需使用”。

逐步走向：

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

让 Agent 看懂并调用设备能力，只是头一步。Execution Assurance（执行保障）是 ADF 当前首发并重点落地的一项能力，它先盯住一个真实设备接入后绕不开的问题：Agent 说完成了，现实世界真的完成了吗？

命令成功送达、接口返回成功，不等于设备已经做完动作，更不等于任务要的真实状态已经建立。设备一旦进入任务执行链路，“接口结果”和“实际效果”之间的这点差距，就会直接影响后续任务能不能可靠推进。放在家里，可能只是灯没亮；到了实验室，可能意味着实验条件根本没建立；到了机器人和工业现场，后续动作就可能建在错误状态之上。

所以 Agent 开始操作现实世界以后，光知道“命令发出去了”不够，还得知道：当前是否具备执行条件？预期效果是否真的发生？什么信息能够证明效果已经发生？结果不明确或任务中断后，应该如何继续？

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

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

Execution Assurance 则把这些要求放到实际运行里，结合设备状态、执行反馈和环境观测逐项检查和确认。[[保留3]]

它关心的不只是某一次 Tool 是否返回成功，而是要区分：设备调用是否成功、预期效果是否得到确认，以及任务是否具备继续推进的依据。

由此，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，方便后续查看、整理和使用。

这套工作流同样给 ADF 的执行保障找到了具体着落：拍摄有没有收尾、剪辑是否做完、文件到没到目标 PC，每一步都得有对应的状态和结果反馈，下一步才走得下去。随着 ADF 与华为设备、鸿蒙生态的协同再往深走，我们希望 Agent 能把设备功能组合得更充分，并靠着及时、可确认的执行结果，把从拍摄到内容处理的整条创作任务一路推下去。

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

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

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

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

ADF接下来会与伙伴一起，围绕设备能力描述、动态状态、执行保障以及跨设备协同等方向补齐规范，并分步集成到openJiuwen、对外开源，让面向Agent的设备接入标准不断往前推。