今天的 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）。ADF 希望在现有设备接口之上，建立一套面向 Agent 的统一能力表达与运行语义，使不同类型的真实设备能够以更一致的方式进入 Agent 的任务体系。ADF 当前首先发布 ADF-EA（Execution Assurance），从真实设备接入后最基础、也最关键的执行可信问题开始，围绕执行条件、预期效果、结果验证与中断恢复建立统一执行语义。

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

ADF 并不替代已有的 API、SDK、IoT 协议和机器人控制框架，而是关注这些接口之上的一层：如何把不同硬件已经具备的功能，以 Agent 可以理解、判断和持续使用的“能力”形式表达出来。向下，ADF 对接已有设备接口与控制体系；向上，则面向 Agent 提供一致的设备能力描述与运行语义，使不同类型、不同厂商的硬件能够以更统一的方式进入 Agent 任务体系。

对于 Agent 来说，一项设备能力并不只是一个可以调用的 Tool。它还需要知道：这项能力是什么、当前是否可用、在什么条件下可以执行、执行后应该产生什么效果，以及任务过程中设备状态发生变化时应该如何处理。因此，ADF 所关注的不只是设备接口本身，还包括围绕设备能力形成的一系列通用语义，例如：

能力描述：设备能够提供什么能力，以及执行该能力需要什么输入；动态状态：这一能力当前是否存在、是否可用，以及影响可用性的设备与环境状态；执行条件：在什么状态下允许执行，哪些前置条件必须满足；效果语义：一次能力调用预期应当改变什么真实状态；验证依据：什么设备反馈、状态回读或环境观测能够证明效果已经发生；中断与继续语义：当结果不明确、设备不可用或任务被中断时，哪些进度可以保留，哪些动作需要重新确认，以及任务是否允许继续。

这使设备接入不再只是“为某一个应用封装一个接口”，而是逐步形成一套可以被不同 Agent、不同任务复用的设备能力表达方式。

例如，一台实验仪器完成适配后，其能力可以被不同科研 Agent 和实验任务复用；一个应用从单设备扩展到多设备时，也能够沿用一致的能力访问方式，而不必针对每一个应用重新设计设备集成逻辑。ADF 希望推动设备接入从：

“按应用重复适配设备”

逐步走向：

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

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

让 Agent 能够理解并调用设备能力只是第一步。作为 ADF 当前首发并重点落地的一项能力，Execution Assurance（执行保障）首先解决一个真实设备接入后无法回避的问题：

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

命令成功送达、接口返回成功，并不等于设备已经完成动作，更不等于任务所需要的真实状态已经建立。当设备进入任务执行链路后，这种“接口结果”与“实际效果”之间的差异，就会直接影响后续任务能否可靠推进。

在家庭里，这可能只是灯没有亮；到了实验室，可能意味着实验条件并未真正建立；到了机器人和工业现场，则可能让后续动作建立在错误状态之上。

因此，当 Agent 开始操作现实世界，仅仅知道“命令发出去了”还不够，还需要知道：

当前是否具备执行条件？预期效果是否真的发生？什么信息能够证明效果已经发生？结果不明确或任务中断后，应该如何继续？

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

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

Execution Assurance 则结合设备状态、执行反馈和环境观测，对这些要求在实际运行过程中进行检查和确认。

它所关心的不只是某一次 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 的设备接入规范持续演进。