openJiuwen初始化Agent Device Foundation，重新定义Agent与物理世界的交互方式

今天的 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 是否返回成