原创 张汉东 2025-04-18 01:16 新加坡
AgentKit 的核心目标是超越平台孤岛，实现真正的跨平台统一自动化。通过 AgentKit 这一技术构想，我看到了 AI 驱动自动化从平台孤岛走向跨平台统一的一条可能的清晰路径
🤖 Droidrun是安卓平台上的AI自动化实践，它通过自然语言命令控制安卓手机，核心机制是利用安卓的无障碍服务API。Droidrun由Python代理和安卓应用Droidrun Portal组成，前者负责代理逻辑和设备交互，后者扫描UI并构建层级，通过JSON文件与Python代理交互。
🌐 AccessKit是一个跨平台的无障碍基础设施库，为AgentKit提供了理想的基础。它采用推送模型，UI工具包主动推送辅助功能树信息给平台适配器，适配器维护内部状态并响应AT查询。AccessKit定义了描述UI元素层级树的数据结构，并提供跨语言支持，使得AgentKit能够跨平台感知和控制UI。
💡 AgentKit的目标是构建通用的AI自动化框架，它将结合Droidrun的经验和AccessKit的跨平台能力。AgentKit的核心在于通过AI驱动，实现跨平台统一自动化，使得AI能够跨越数字边界进行操作。AgentKit的设计将考虑与现有协议的协同，旨在构建一个由AI驱动的自动化未来基础设施。
原创 张汉东 2025-04-18 01:16 新加坡
AgentKit 的核心目标是超越平台孤岛，实现真正的跨平台统一自动化。通过 AgentKit 这一技术构想，我看到了 AI 驱动自动化从平台孤岛走向跨平台统一的一条可能的清晰路径
droidrun
（Python 代理）和droidrun-portal
（安卓应用）两个独立项目组成。应用整体工作流程如图所示：DROIDRUN_DEVICE_SERIAL
。Agent 启动:ReActAgent
被初始化。ReAct 循环:获取 UI 状态 (关键交互): 如果动作是get_clickables
或get_all_elements
：执行设备操作: 如果动作是tap
,swipe
,input_text
等：完成任务: 如果动作是complete
，则标记任务完成。Python 工具通过 ADB 发送广播命令给设备上的 Portal Service。Portal Service 使用无障碍 API 扫描 UI，构建层级，分配索引，将结果写入 JSON 文件，并通过 Logcat 打印文件路径。Python 工具轮询 Logcat 获取文件路径，然后通过 ADB 拉取该 JSON 文件，解析后作为观察结果返回给 Agent。Python 工具查找缓存中的元素（如果是tap(index=...)
），计算坐标或构建命令。通过 ADB 直接向设备发送相应的input
或am
等 shell 命令。返回操作成功或失败的消息作为观察结果。思考: Agent 将当前目标和历史步骤发送给LLM Reasoner
。决策: LLM 返回思考过程 (thought
)、要执行的动作 (action
) 和参数 (parameters
)。行动: Agent 调用tools.actions
中的相应函数来执行动作。观察: Agent 接收到动作执行的结果（UI 数据或操作状态）。循环/结束: 如果任务未完成且未达到最大步骤数，则带着新的观察结果回到“思考”阶段；否则，结束循环。结果输出: CLI 显示执行过程或最终结果给用户。接下来，我们分别看看这两部分的代码，了解其工作机制。Droidrun (Python 代理)这个 Python 包是 Droidrun 系统的核心控制端（类比为大脑和手），负责：代理逻辑实现： 包含智能决策和任务执行流程。设备交互工具： 提供与 Android 设备通信和控制的工具，主要依赖 ADB 和 Droidrun Portal 应用。命令行界面： 提供用户与 Agent 交互的入口。核心组件关键点：adb
包:提供异步方式封装和执行标准adb
命令（如shell
,pull
,install
）。Device
类代表一个设备，封装了如tap
,swipe
,input_text
,take_screenshot
等具体操作，这些操作最终都通过执行相应的adb shell
命令完成。DeviceManager
用于管理多设备连接。tools
包:tap
(基于索引) 在缓存中查找元素，计算坐标，最终执行adb shell input tap
。其他动作 (swipe
,input_text
等) 是对adb.Device
方法的封装，增加了错误处理和特定逻辑（如input_text
的转义和分块）。通过adb shell am broadcast
触发 Portal 应用扫描 UI。核心交互机制： 轮询adb shell logcat -d
监听 Portal 打印出的包含 JSON 文件路径的日志。获取路径后，使用adb pull
拉取设备上的 JSON 文件。解析 JSON（将嵌套结构扁平化处理），并缓存结果 (CLICKABLE_ELEMENTS_CACHE
)。关键接口： 这是 Python Agent 与 Android Portal 应用交互的主要桥梁。UI 感知 (get_clickables
/get_all_elements
):UI 操作 (tap
等):complete
工具: Agent 用来向 ReAct 循环表明任务已完成。依赖DROIDRUN_DEVICE_SERIAL
环境变量指定目标设备。agent
包:核心逻辑： 实现 ReAct (思考+行动) 代理模式。LLMReasoner
: 封装与 LLM (OpenAI, Anthropic, Gemini) 的交互，负责构建详细的系统提示（含工具签名）和用户提示（含历史），处理 API 调用（支持视觉输入），解析 LLM 返回的 JSON（thought
,action
,parameters
），并追踪 Token 限制。ReActAgent
: 编排 ReAct 循环，维护执行步骤历史 (ReActStep
)。其run
方法驱动整个流程：调用LLMReasoner
进行思考 -> 记录思考/行动 -> 调用execute_tool
执行动作 -> 记录观察结果 -> 检查是否完成。execute_tool
将 LLM 返回的动作名称映射到tools.actions
中的函数并执行。cli
包:使用click
库提供命令行界面。run
命令是主要入口，负责解析参数、设置设备序列号环境变量、并启动ReActAgent
。提供设备管理 (devices
,connect
) 和 Portal 应用安装/设置 (setup
) 的辅助命令。“ReAct 机制ReAct (Reasoning + Acting，即推理 + 行动) 是 DroidRun 用来控制安卓设备的一种核心工作模式。它让 AI 像人一样，通过思考和动手相结合的方式来完成复杂的自动化任务。核心思想： ReAct 是模仿人类解决问题的循环。DroidRun 中的 ReAct 循环：设定目标: 用户给出自然语言任务。推理: LLM 分析任务和当前屏幕，决定步骤。选择动作: Agent 选定一个可用动作（如点击、输入、滑动、分析 UI 元素）。执行: 在安卓设备上执行该动作。观察: Agent 获取执行结果（如新屏幕内容）。再推理: Agent 评估进展，决定下一步。重复 直到任务完成或达到最大步数限制。关键特性 (DroidRun 中):可用动作: 包括 UI 交互（点击、输入）、应用管理（启动、安装）、UI 分析（获取元素）和任务管理（完成）。视觉能力 (可选): 启用1. 思考 (Reasoning): AI (LLM) 分析任务目标（比如“打开设置并开启深色模式”），结合当前屏幕状态，思考需要做什么。2. 行动 (Acting): AI 选择一个具体的动作（比如“点击‘显示’按钮”），并通过工具在安卓设备上执行。3. 观察 (Observing): AI 看到执行动作后的结果（比如屏幕跳转到了显示设置页面）。4. 再思考...再行动...: AI 根据观察到的结果，继续思考下一步该做什么，直到任务完成。
vision=True
时，Agent 可以分析屏幕截图，更好地理解复杂或非标准 UI。Token 追踪: 记录与 LLM 交互的 Token 消耗，用于成本管理和性能优化。步骤记录: Agent 会记录每一步的类型（思考、行动、观察等），方便追踪和调试。值得一提的是 DroidRun Python 库中 Agent 包的一些细节：多 LLM 支持:LLMReasoner
类封装 OpenAI, Anthropic, Gemini API 调用。提示工程：精心设计的系统提示指导 LLM 分析 UI、逐步思考、选择工具并返回严格的 JSON。多模态能力 (可选)： 支持take_screenshot
工具，并将图像数据传递给视觉模型 (如 GPT-4o, Claude 3)。截图作为补充信息，用于处理无障碍 API 无法覆盖的场景（游戏、自定义绘制、WebView 内部细节、消除歧义）。历史记录与截断： 维护 ReAct 步骤历史，并实现简单的 Token 预算截断。工具抽象： LLM 只需输出工具名称和参数，ReActAgent
负责调用tools.actions
中的具体实现。简单来说，ReAct 就是让 AI 代理像一个有头脑、会动手、能观察、会反思的人一样，一步一步地在安卓设备上完成你交给它的任务。Droidrun Portal (安卓应用)这个安卓应用是 Droidrun 系统的感知层（类比为眼睛和耳朵），主要功能是：核心机制：作为一个无障碍服务 (Accessibility Service) 运行，利用系统 API 读取屏幕 UI 结构，无需截图或 root。UI 扫描： 周期性地 (非实时响应每个事件) 扫描当前活动窗口的 UI 元素 (AccessibilityNodeInfo
树)。元素处理：提取可见元素的信息 (边界、文本、类名、ID)。基于空间包含关系构建父子层级。为可交互/文本元素分配**连续索引 (clickableIndex
)**，供 Python Agent 引用。数据提供:将处理后的 UI 元素列表（含层级）序列化为嵌套 JSON。将 JSON 写入设备上的文件。关键： 通过 Android Logcat 打印（Log）出该 JSON 文件的路径，告知 Python Agent 去哪里获取数据。当收到 Python Agent 通过 ADB 广播发送的命令 (如GET_ELEMENTS
) 时：可视化 (可选): 通过OverlayManager
在屏幕上绘制带有索引和热力图颜色（基于检测时间）的矩形覆盖层，提供视觉反馈。数据模型 (ElementNode.kt
): 定义了存储 UI 元素信息的结构。配置: 通过AndroidManifest.xml
和无障碍服务配置文件声明服务和所需权限/能力。简单来说，Droidrun Portal 就是一个运行在安卓设备上的“助手”，它利用无障碍服务“看”屏幕上的内容，整理成结构化的 JSON 数据，然后通过“约定”（Logcat 里的文件路径）告诉 Python Agent 数据藏在哪里了。它还可以选择性地在屏幕上画框框来显示它看到了什么。common
(accesskit crate)： 定义平台无关的 UI 树数据模型 (Node
,Role
,Action
,TreeUpdate
) 和几何类型。consumer
(accesskit_consumer crate)： 维护完整的树状态，处理更新，提供高级 API (遍历、查询)。推送模型： UI 工具包主动推送完整的初始树状态和后续的增量TreeUpdate
给适配器。适配器维护内部状态，直接响应 AT 查询，无需频繁回调应用。这与传统 AT API 的“拉取模型”相对。优势： 解耦、性能好（尤其对立即模式 GUI）、异步友好（默认支持async-io
和提供tokio
可选特性，以适应不同的异步运行时）。平台适配器（platforms/*
crates）： 将 AccessKit 模型桥接到原生 API (Windows UIA, macOS NSAccessibility, Unix AT-SPI, Android Accessibility Framework)。跨语言支持： 核心库是 Rust 实现，带来内存安全、高性能、零成本抽象、并发安全、优秀 FFI 和跨平台编译能力。另外也提供了 C、Python 等语言的绑定，方便非 Rust 工具包集成。“拉取模型 vs 推送模型拉取模型 (Pull Model)： 这是传统或更直接的一种方式。想象一下，屏幕阅读器（或其他辅助技术，AT）想要知道某个按钮的名称。它会通过平台的辅助功能 API 向你的应用程序发送一个请求：“请告诉我 ID 为 X 的按钮的名称”。你的应用程序（或 UI 工具包）接收到这个请求，查找对应的信息，然后将名称返回给平台 API，最终传递给屏幕阅读器。在这个模型中，信息流是由 AT 或平台 API 主动拉取的。推送模型 (Push Model)： AccessKit 采用这种方式。你的应用程序（或 UI 工具包）不等待被动查询，而是主动地将整个或部分辅助功能树的状态推送给 AccessKit 的平台适配器。当 UI 发生变化时，你的应用程序会计算出差异，并将这些变化再次推送给适配器。平台适配器负责维护一个完整的、最新的辅助功能树的内部表示。当屏幕阅读器通过平台 API 查询信息时（例如，“ID 为 Y 的节点的名称是什么？”），平台适配器可以直接从它自己维护的树状态中查找并返回信息，通常不需要再回头去问你的应用程序。AccessKit 的核心目标是让 UI 工具包能够向操作系统的辅助功能 API 提供必要的信息，以便各种辅助技术（Assistive Technologies, ATs）能够理解和操作 UI。这些辅助技术包括但不限于：屏幕阅读器 (Screen Readers): 如 Windows 上的 NVDA、JAWS，macOS 和 iOS 上的 VoiceOver，Android 上的 TalkBack，Linux 上的 Orca。它们将屏幕上的文本和 UI 元素信息朗读出来，或输出到盲文显示器。屏幕放大器 (Screen Magnifiers): 如 Windows Magnifier, macOS Zoom。它们放大屏幕的部分区域，并可能需要跟踪焦点或鼠标位置。语音控制软件 (Voice Control): 如 Dragon NaturallySpeaking, Windows Voice Access, macOS Voice Control。用户通过语音命令与 UI 交互。切换设备 (Switch Devices): 用于有严重运动障碍的用户，通过一个或多个开关来扫描和选择 UI 元素。读写困难辅助工具: 可能需要高亮文本、改变字体或颜色等。AccessKit 的平台适配器则负责将这些信息有效地传递给各个平台的原生 API 和辅助技术，从而简化跨平台辅助功能的实现。所以，AccessKit 与 Droidrun Portal 相比， 都能提供结构化的 UI 感知能力，但 AccessKit 是跨平台的，提供更通用的抽象模型，Droidrun Portal 则仅限 Android。所以，能看得出来，AccessKit 对实现通用的 AI 自动化控制的关键是：结构化和语义化的 UI 理解： 提供比截图更深层次的界面理解（角色、状态、属性、关系）。标准化的交互接口： 定义统一的
Action
枚举，提供稳定的编程接口模拟交互。跨平台一致性： 核心模型和动作定义跨平台一致，便于复用控制逻辑。对于集成了 AccessKit 的应用，它提供了极其理想的感知和控制基础。AI Agent 可以：精确感知： 通过查询 AccessKit 树理解 UI 结构、元素角色、状态和属性。可靠执行： 通过请求标准的 AccessKitAction
来执行交互。跨平台操作： 复用大部分控制逻辑。当然，这里存在一个前提： 目标应用必须集成 AccessKit。对于未集成的应用，AI Agent 仍需依赖其他技术（原生 API、视觉自动化等）。对于那些使用 AccessKit 构建的应用程序，AccessKit 提供了一个极其强大和理想的基础设施，供 AI Agent 进行感知和控制。它提供了一种结构化、语义化、跨平台且相对稳定的方式来理解 UI 状态并执行交互动作，这比许多现有自动化技术（尤其是视觉自动化）具有明显优势。然而，其最大的限制在于应用程序的采用率。目前，AccessKit 还是一个相对较新的项目，采用它的 UI 工具包和应用程序还不多。因此，一个通用的、旨在控制任意桌面或移动应用的 AI Agent，目前还不能广泛依赖 AccessKit，必须具备使用其他自动化策略的能力。但随着 AccessKit 生态的发展，它有望成为 AI 控制领域一个非常有价值的工具。关键架构说明:三桥并行策略:AccessKit Bridge： 优先使用，获取结构化信息和执行标准动作。WebKit Bridge： 处理 Web 内容 (浏览器/WebView)，可执行 JS。解决 WebView 交互难题：WebView 会将内部 Web 无障碍树暴露给系统（AccessKit 可见），但 JS 操作更强大直接。此桥接提供 JS 执行能力。Device Bridge： 处理其他非手机类智能终端设备（树莓派、Jetson、香橙派等嵌入式 Linux 平台)。协调器模式： Core 层动态选择最合适的桥接方式，处理混合场景。逻辑/物理分离： 优先使用基于语义的逻辑动作 (┌─────────────────────────────────────────────┐│ AI Agent ││ (LLM/模型、任务规划、决策逻辑 - 可插拔) │└──────────────────────┬──────────────────────┘ │ (统一指令/状态)┌──────────────────────▼──────────────────────┐│ AgentKit Core ││ (状态管理、协调器、统一动作模型、安全管理) │└───┬───────────┬────────────────┬────────────┘ │ │ │┌───▼───┐ ┌───▼───┐ ┌────▼────┐│AccessKit│ │ WebKit│ │Device ││ Bridge │ │ Bridge│ │ Bridge │└───┬───┘ └───┬───┘ └────┬────┘ │ │ │┌───▼───┐ ┌───▼───┐ ┌────▼────┐│AccessKit│ │Browser/│ │ Platform ││Adapters│ │WebView │ │Specific │└───┬───┘ └───┬───┘ └────┬────┘ │ │ │┌───▼───────────▼────────────────▼───┐│ Applications & UIs │└───────────────────────────────────┘
ClickElement
)，必要时回退到物理动作 (ClickPosition
)。高效数据交换: 借鉴 Droidrun 经验，但使用共享内存/内存零拷贝/内存映射文件 + 通知机制，替代文件系统+ Logcat，提高效率。AgentKit 设计的一个核心优势将会是支持所有实现了 AccessKit 的 UI 框架，这包括但不限于：Rust 原生 UI 框架：Makepad：硬件加速的跨平台 UI 框架Druid：数据驱动的 Rust UI 工具包Iced：简单的跨平台 GUI 库Vizia：声明式 Rust GUI 库，专注于音频应用Slint：轻量级 UI 工具包，适合嵌入式系统Bevy UI：基于 Bevy 引擎的游戏 UI 系统跨语言 UI 框架：Flutter：通过 Rust 绑定可以集成 AccessKitGTK：通过 AccessKit 适配器支持Qt：可以通过 AccessKit 桥接提供支持wxWidgets：可以集成 AccessKit 提供跨平台无障碍支持实验性或未来可能支持的框架：Xilem：实验性的 Rust GUI 框架Egui：即时模式 GUI 库自定义渲染引擎：游戏和专业应用使用的定制渲染系统对于框架的支持，AgentKit 采用插件式架构，通过适配器接口实现灵活的集成，充分发挥 Rust 语言工程能力的优势。借助dora-rs
来实现自动化控制非手机智能终端让 AgentKit 控制树莓派、Jetson 等智能设备是完全可行且极具价值的扩展方向，能将 AgentKit 从 GUI 自动化扩展为更通用的 AI 控制平台，与物理世界交互。对应上面架构中的 Device Bridge 部分。其核心机制：设备端节点： 在目标智能设备上运行dora-rs
节点，这些节点作为设备驱动/代理，封装与特定硬件（GPIO、传感器、串口等）或软件（SDK、API）的交互逻辑。中央大脑： AgentKit Core（运行在 PC/服务器）负责决策。网络桥梁： AgentKit Core 通过网络与设备端的dora-rs
节点通信。标准化数据流： 使用dora-rs
消息传递标准化的指令（如SetPinHigh
,ReadTemperature
）、状态/数据（如PinState
,TemperatureReading
）和能力描述。主要优势：抽象解耦： AgentKit Core 无需关心设备细节，只需与标准化接口交互。利用dora-rs
优势： 充分发挥其在嵌入式 Linux 上的高性能、低延迟和数据流处理能力。易扩展： 添加新设备只需开发对应的dora-rs
节点。分布式智能： 可在设备端实现部分本地处理和控制逻辑。统一框架： 用一套 AgentKit 编排 GUI、Web 和物理设备的复杂工作流。可以设想一个应用示例（树莓派温控 LED）：树莓派运行sensor_node
(读温湿度节点) 和led_node
(控制 LED 节点)。AgentKit Core (PC) 指示sensor_node
读取温度。sensor_node
读取后将TemperatureReading(32.5)
发回 Core。Core 判断温度超限 (>30)，指示led_node
打开 LED。led_node
执行并返回LedStatus(on)
。这样通过在智能设备上运行dora-rs
节点，AgentKit 可以可靠、高效地将其自动化能力扩展到物理世界，成为一个更强大的通用 AI 自动化平台。AgentKit 这样的设计相较于平台专属方案（如 Droidrun.ai）具有显著优势：真正的跨平台：一次开发 AI Agent 逻辑，即可控制 Windows, macOS, Linux, Android, iOS (通过 Flutter 等框架), Web 等多种平台的应用。框架无关性：只要 UI 框架实现了 AccessKit（对于原生）或提供了 Web 访问接口，就能被 AgentKit 控制，开发者可以自由选择技术栈。代码复用与维护：核心 AI 逻辑和控制模型只需维护一套，大幅降低维护成本。统一用户体验：用户可以在不同设备和应用上获得一致的 AI 辅助或自动化体验。利用原生能力：通过 AccessKit 和 Web API，AgentKit 深度利用平台原生能力，实现精准、高效的感知和控制，避免了脆弱的图像识别。模块化与可扩展：可以轻松添加对新框架、新平台或新 AI 模型的支持，确保系统能够随技术发展而演进。性能优化：基于 Rust 的实现提供了卓越的性能和内存安全保证，特别适合实时 UI 控制场景。AgentKit 专用 AI Gateway 服务 (可选增强)为了更好地支持跨平台部署、集中管理和云端推理能力，AgentKit 可以引入专用的 AI Gateway 服务作为客户端和 AI 提供商之间的桥梁。这种架构并非必需，但能带来显著优势。抽象与统一： 为客户端提供单一、稳定的 API 接口，屏蔽底层 AI 提供商（OpenAI, Anthropic, Gemini 等）的差异和变化。客户端无需适配多种 API 格式和认证方式。智能路由与负载均衡： 根据请求类型（如需要视觉能力）、实时负载、成本、提供商健康状况等因素，自动选择最合适的 AI 提供商或模型进行推理。安全增强： 集中管理所有 AI 提供商的 API 密钥，客户端无需直接存储这些敏感凭证，降低泄露风险。Gateway 负责认证客户端身份。请求优化与转换：压缩: 智能压缩 UI 快照、历史记录等大型数据，减少网络传输量。格式转换: 将 AgentKit 的内部请求格式转换为特定 AI 提供商所需的格式。上下文管理: 可能对过长的历史记录进行智能截断或摘要。响应缓存： 对确定性或高频的请求（例如，低temperature
设置下的请求）进行缓存，避免重复调用昂贵的 AI API，降低成本和延迟。监控、分析与计费: 集中收集 API 调用次数、Token 消耗、延迟、错误率等指标，便于分析性能、成本、用户行为模式，并可实现统一计费。速率限制与配额管理： 对客户端实施统一的速率限制和配额管理，防止滥用。AI Gateway 系统架构设计大概如下：核心组件实现 (概念说明)认证与授权模块: 验证客户端 API Key 或 Token，管理客户端权限。请求路由与负载均衡: 基于规则（如请求特性、提供商状态、成本）选择后端 AI Provider。请求优化与转换: 实现压缩、格式适配、上下文处理逻辑。响应缓存管理: 使用 Redis 或内存缓存存储可缓存的响应。AI Provider 接口: 定义统一的┌───────────────────────┐│ AgentKit 客户端 ││ (Windows, macOS, ││ Linux, Mobile) │└───────────┬───────────┘ │ │ HTTPS / WebSockets (加密通信) │ (AgentKit Client <-> Gateway) ▼┌───────────────────────────────────────────┐│ AgentKit AI Gateway ││ ││ ┌─────────────┐ ┌─────────────────┐ ││ │ 认证与授权 │◀────▶│ 请求路由与负载 │ ││ │ (Client Auth)│ │ 均衡 │ ││ └──────┬──────┘ └───────┬─────────┘ ││ │ │ ││ ▼ ▼ ││ ┌─────────────┐ ┌─────────────────┐ ││ │ 请求优化与 │──────▶│ 响应缓存 │ ││ │ 转换 │ └───────┬─────────┘ ││ └──────┬──────┘ │ ││ │ │ ││ ▼ ▼ ││ ┌─────────────────┐ ┌─────────────────┐ ││ │ AI Provider I/F │ │ 监控与分析 │ ││ │ (统一接口) │ └─────────────────┘ ││ └──────┬──────┘ │└─────────┼─────────────────────────────────┘ │ HTTPS (Gateway <-> AI Provider) │ (含 Provider API Key) ▼ ┌────────────┐┌────────┐┌───────────────┐ │ OpenAI API ││Claude ││其他 AI 提供商 │ └────────────┘│ API │└───────────────┘ └────────┘
trait AiProvider
，并为各提供商实现具体的适配器，封装其 API 调用和密钥管理。监控与分析: 集成 Prometheus/Grafana 或类似系统，记录关键指标。技术
核心定位
主要解决的问题
(Anthropic) 协议
工具连接层
"AI 如何调用外部工具与数据源"
(Google) 协议
代理协作层
"不同 AI 代理如何安全地相互通信"
(工具)
UI 交互层
"AI 如何跨平台感知和操作用户界面"
MCP 当前面临的严重的安全挑战（如工具投毒攻击）也为 AgentKit 提供了重要警示：工具隔离：AgentKit 需实现类似沙箱机制，限制 UI 交互操作的权限范围明确的权限模型：AgentKit 应采用细粒度权限控制，区分读取 UI（低风险）和执行操作（高风险）二次确认机制：关键操作（如提交表单、删除内容）应要求明确的用户确认AgentKit 与 A2A 的关系分析A2A 协议专注于 AI Agent 之间的协作与通信，而 AgentKit 专注于 UI 交互能力，两者也是高度互补。 AgentKit 可以实现为 A2A 兼容的代理，用于专门处理 UI 交互任务，从而增强 AI Agent 分工协作。A2A 的安全机制（如 AgentCard、身份验证）也可以增强 AgentKit 的安全性。比如下面示例：# AgentKit 实现为 MCP 服务的示例from mcp.server.fastmcp import FastMCP# 创建 MCP 服务器mcp = FastMCP("AgentKit UI Automation")@mcp.tool()def click_element(element_id: str) -> bool: """点击指定 ID 的 UI 元素。""" # AgentKit 内部实现跨平台点击 return agent_kit.bridges.coordinator.execute_action( AgentAction.ClickElement(element_id=element_id) )
// AgentKit 作为 A2A 代理的 AgentCard 示例{ "name": "UI Interaction Agent", "description": "专门处理跨平台用户界面交互", "provider": { "organization": "AgentKit.org" }, "skills": [ { "id": "ui_discovery", "name": "UI Element Discovery", "description": "发现并分析界面上的交互元素" }, { "id": "ui_interaction", "name": "UI Element Interaction", "description": "与界面元素进行交互（点击、输入等）" } ], "authentication": { "schemes": ["bearer"] }}
“AgentCard：一个 A2A 协议中公共元数据文件（通常位于三层架构整合方案基于以上分析，可以构建一个将 MCP、A2A 和 AgentKit 整合的三层架构：/.well-known/agent.json
），描述代理的能力、技能、端点 URL 和认证要求。客户端使用此文件进行发现。
在这个架构中：A2A 层处理代理之间的任务分配和协作MCP 层提供标准化的工具调用接口AgentKit 层作为 MCP 的一个专业工具，提供跨平台 UI 交互能力┌─────────────────────────────────────────┐│ A2A 协作层 ││ (代理协调、任务分配、安全通信) │└───────────────────┬─────────────────────┘ │┌───────────────────▼─────────────────────┐│ MCP 工具层 ││ (标准化工具调用、资源访问) │└─────────┬─────────────────────┬─────────┘ │ │┌─────────▼────────┐ ┌────────▼─────────┐│ AgentKit UI层 │ │ 其他专业工具 ││ (跨平台UI交互) │ │ (搜索、计算等) │└──────────────────┘ └──────────────────┘
参考资料
[1] Droidrun: https://github.com/droidrun/droidrun
[2] Accesskit.dev: https://accesskit.dev/[3] AgentKitDev: https://github.com/AgentKitDevAI辅助创作，多种专业模板，深度分析，高质量内容生成。从观点提取到深度思考，FishAI为您提供全方位的创作支持。新版本引入自定义参数，让您的创作更加个性化和精准。
鱼阅，AI 时代的下一个智能信息助手，助你摆脱信息焦虑