本文探讨了AgentKit的设计，这是一个旨在实现跨平台、统一的AI自动化框架。文章首先分析了Droidrun，一个基于Android无障碍服务的AI自动化项目，深入研究了其实现机制和局限性。随后，文章介绍了AccessKit，一个跨平台的无障碍基础设施，它为AgentKit提供了理想的基础。最终，文章提出了AgentKit的详细构想，旨在构建一个由AI驱动、能够跨越数字边界的自动化未来基础设施。

📱 Droidrun项目展示了如何利用Android的无障碍服务API和自然语言处理技术，实现对安卓设备的自动化控制，但其局限性在于仅支持安卓平台。

⚙️ AccessKit作为一个跨平台的无障碍基础设施，定义了一套描述UI元素层级树的数据结构，并采用推送模型，使得UI工具包能够主动将辅助功能信息推送给平台适配器，而非被动等待查询，从而实现跨平台支持。

💡 AgentKit的核心目标是构建一个通用的AI自动化框架，它将利用AccessKit提供的跨平台UI理解能力，结合AI技术，实现对不同平台设备的统一控制，解决跨平台自动化难题。

🤝 AgentKit的设计将借鉴Droidrun的ReAct（推理+行动）循环模式，并与Claude MCP和Google A2A等协议协同工作，实现更智能、更灵活的自动化操作。

🌐 AgentKit期望通过抽象不同平台的差异，提供一个统一的AI控制接口，使得AI Agent能够跨平台地与各种界面交互，从而实现真正的跨平台自动化。

原创 张汉东 2025-04-18 01:16 新加坡

AgentKit 的核心目标是超越平台孤岛，实现真正的跨平台统一自动化。通过 AgentKit 这一技术构想，我看到了 AI 驱动自动化从平台孤岛走向跨平台统一的一条可能的清晰路径

流程图说明:

用户启动: 用户通过 Droidrun CLI 输入自然语言任务。

环境设置: CLI 解析参数，获取设备序列号并设置环境变量 
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

 用于管理多设备连接。

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
 环境变量指定目标设备。

核心逻辑： 实现 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

 中的函数并执行。

使用 
click
 库提供命令行界面。

run

 命令是主要入口，负责解析参数、设置设备序列号环境变量、并启动 

ReActAgent

。
提供设备管理 (
devices
, 
connect
) 和 Portal 应用安装/设置 (
setup
) 的辅助命令。

“

ReAct 机制

ReAct (Reasoning + Acting，即推理 + 行动) 是 DroidRun 用来控制安卓设备的一种核心工作模式。它让 AI 像人一样，通过思考和动手相结合的方式来完成复杂的自动化任务。

核心思想：  ReAct 是模仿人类解决问题的循环。

1.  思考 (Reasoning): AI (LLM) 分析任务目标（比如“打开设置并开启深色模式”），结合当前屏幕状态，思考需要做什么。2.  行动 (Acting): AI 选择一个具体的动作（比如“点击‘显示’按钮”），并通过工具在安卓设备上执行。3.  观察 (Observing): AI 看到执行动作后的结果（比如屏幕跳转到了显示设置页面）。4.  再思考...再行动...: AI 根据观察到的结果，继续思考下一步该做什么，直到任务完成。

DroidRun 中的 ReAct 循环：

设定目标: 用户给出自然语言任务。

推理: LLM 分析任务和当前屏幕，决定步骤。

选择动作: Agent 选定一个可用动作（如点击、输入、滑动、分析 UI 元素）。

执行: 在安卓设备上执行该动作。

观察: Agent 获取执行结果（如新屏幕内容）。

再推理: Agent 评估进展，决定下一步。

重复 直到任务完成或达到最大步数限制。

关键特性 (DroidRun 中):

可用动作: 包括 UI 交互（点击、输入）、应用管理（启动、安装）、UI 分析（获取元素）和任务管理（完成）。

视觉能力 (可选): 启用 
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
) 时：

数据模型 (

ElementNode.kt

): 定义了存储 UI 元素信息的结构。

简单来说，Droidrun Portal 就是一个运行在安卓设备上的“助手”，它利用无障碍服务“看”屏幕上的内容，整理成结构化的 JSON 数据，然后通过“约定”（Logcat 里的文件路径）告诉 Python Agent 数据藏在哪里了。它还可以选择性地在屏幕上画框框来显示它看到了什么。

AgentKit 愿景的基础：AccessKit 的跨平台能力

Droidrun 看上去（我没有在本地运行）在安卓手机执行的很流畅，但从一个通用性的尺度来看它有明显的局限性。也正是它这个局限性，启发我持续思考 AgentKit 这个通用的跨平台跨设备的 AI 自动化套件 。

实现跨平台 AI 自动化面临的一个巨大挑战之一，就是各平台迥异的无障碍 API、UI 框架和开发语言。

幸好，在 Rust 生态有 AccessKit 这个基于 Rust 的跨平台无障碍基础设施库，旨在解决上述挑战，为 AgentKit 提供了理想的基础。

其设计灵感部分来源于 Chromium 的多进程辅助功能架构，采用 推送（Push） 模型：UI 工具包主动将完整的辅助功能树信息和后续的增量更新推送给 AccessKit 的平台适配器，而不是等待适配器按需拉取。这种模型特别适合那些自行渲染 UI 元素（包括立即模式 GUI）的工具库。AgentKit 部分代码（尤其是设计理念和数据结构）也源自 Chromium 。

AccessKit 作为 UI 工具包和原生平台 API 之间的桥梁，其核心抽象如下:

数据模式: 定义了一套描述 UI 元素层级树（Accessibility Tree）的数据结构（节点、角色、属性、状态等）。这个模式是平台无关的。

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 结构、元素角色、状态和属性。

可靠执行： 通过请求标准的 AccessKit 
Action
 来执行交互。

跨平台操作： 复用大部分控制逻辑。

当然，这里存在一个前提： 目标应用必须集成 AccessKit。对于未集成的应用，AI Agent 仍需依赖其他技术（原生 API、视觉自动化等）。

对于那些使用 AccessKit 构建的应用程序，AccessKit 提供了一个极其强大和理想的基础设施，供 AI Agent 进行感知和控制。它提供了一种结构化、语义化、跨平台且相对稳定的方式来理解 UI 状态并执行交互动作，这比许多现有自动化技术（尤其是视觉自动化）具有明显优势。

然而，其最大的限制在于应用程序的采用率。目前，AccessKit 还是一个相对较新的项目，采用它的 UI 工具包和应用程序还不多。因此，一个通用的、旨在控制任意桌面或移动应用的 AI Agent，目前还不能广泛依赖 AccessKit，必须具备使用其他自动化策略的能力。但随着 AccessKit 生态的发展，它有望成为 AI 控制领域一个非常有价值的工具。

AgentKit：通用 AI 自动化框架

基于 AccessKit 提供的强大基础，我们可以构想一个更宏大、更通用的 AI 控制框架——AgentKit。AgentKit 的目标是成为一个面向所有平台的、模块化的、可扩展的 AI 自动化解决方案。

AgentKit 架构宏观概览

AgentKit 的设计理念是分层、模块化和框架无关：

┌─────────────────────────────────────────────┐│                  AI Agent                   ││  (LLM/模型、任务规划、决策逻辑 - 可插拔)     │└──────────────────────┬──────────────────────┘                       │ (统一指令/状态)┌──────────────────────▼──────────────────────┐│                 AgentKit Core               ││ (状态管理、协调器、统一动作模型、安全管理)  │└───┬───────────┬────────────────┬────────────┘    │           │                │┌───▼───┐   ┌───▼───┐      ┌────▼────┐│AccessKit│  │ WebKit│      │Device  ││ Bridge │  │ Bridge│      │ Bridge  │└───┬───┘   └───┬───┘      └────┬────┘    │           │                │┌───▼───┐   ┌───▼───┐      ┌────▼────┐│AccessKit│  │Browser/│      │ Platform ││Adapters│  │WebView │      │Specific  │└───┬───┘   └───┬───┘      └────┬────┘    │           │                │┌───▼───────────▼────────────────▼───┐│        Applications & UIs          │└───────────────────────────────────┘

关键架构说明:

三桥并行策略:

AccessKit Bridge： 优先使用，获取结构化信息和执行标准动作。

WebKit Bridge： 处理 Web 内容 (浏览器/WebView)，可执行 JS。解决 WebView 交互难题：WebView 会将内部 Web 无障碍树暴露给系统（AccessKit 可见），但 JS 操作更强大直接。此桥接提供 JS 执行能力。

Device Bridge：  处理其他非手机类智能终端设备（树莓派、Jetson、香橙派等嵌入式 Linux 平台)。

协调器模式： Core 层动态选择最合适的桥接方式，处理混合场景。

高效数据交换: 借鉴 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 绑定可以集成 AccessKit

GTK：通过 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)

。

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 提供商所需的格式。

上下文管理: 可能对过长的历史记录进行智能截断或摘要。

监控、分析与计费: 集中收集 API 调用次数、Token 消耗、延迟、错误率等指标，便于分析性能、成本、用户行为模式，并可实现统一计费。

速率限制与配额管理： 对客户端实施统一的速率限制和配额管理，防止滥用。

AI Gateway 系统架构设计大概如下：

┌───────────────────────┐│   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   │└───────────────┘                  └────────┘

核心组件实现 (概念说明)

认证与授权模块: 验证客户端 API Key 或 Token，管理客户端权限。

请求路由与负载均衡: 基于规则（如请求特性、提供商状态、成本）选择后端 AI Provider。

请求优化与转换: 实现压缩、格式适配、上下文处理逻辑。

响应缓存管理: 使用 Redis 或内存缓存存储可缓存的响应。

AI Provider 接口: 定义统一的 
trait AiProvider
，并为各提供商实现具体的适配器，封装其 API 调用和密钥管理。

监控与分析: 集成 Prometheus/Grafana 或类似系统，记录关键指标。

AgentKit 与 Claude MCP / Google A2A 协议的互补协作

最近，MCP 和 A2A 这两个 AI Agent 相关协议开始流行。所以我想有必要比较一下。

首先，让我们明确这三种技术各自解决的核心问题：

技术	核心定位	主要解决的问题
MCP  (Anthropic) 协议	工具连接层	"AI 如何调用外部工具与数据源"
A2A  (Google) 协议	代理协作层	"不同 AI 代理如何安全地相互通信"
AgentKit  (工具)	UI 交互层	"AI 如何跨平台感知和操作用户界面"

AgentKit 与 MCP 的关系分析

MCP 提供了 AI 模型与外部工具之间的标准化连接方式，而 AgentKit 专注于提供跨平台 UI 控制能力。这种关系天然互补。

MCP 可以处理"工具调用"（如获取天气、搜索信息、访问文件），AgentKit 则来处理"UI 交互"（如点击按钮、输入文本、解析界面结构）。

AgentKit 可以作为 MCP 工具提供者。AgentKit 可以实现为 MCP 服务器，提供一套标准化的 UI 交互工具。比如：

# 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) )

MCP 当前面临的严重的安全挑战（如工具投毒攻击）也为 AgentKit 提供了重要警示：

工具隔离：AgentKit 需实现类似沙箱机制，限制 UI 交互操作的权限范围

明确的权限模型：AgentKit 应采用细粒度权限控制，区分读取 UI（低风险）和执行操作（高风险）

二次确认机制：关键操作（如提交表单、删除内容）应要求明确的用户确认

AgentKit 与 A2A 的关系分析

A2A 协议专注于 AI Agent 之间的协作与通信，而 AgentKit 专注于 UI 交互能力，两者也是高度互补。 AgentKit 可以实现为 A2A 兼容的代理，用于专门处理 UI 交互任务，从而增强 AI Agent 分工协作。A2A 的安全机制（如 AgentCard、身份验证）也可以增强 AgentKit 的安全性。

比如下面示例：

// 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 协议中公共元数据文件（通常位于 

/.well-known/agent.json

 ），描述代理的能力、技能、端点 URL 和认证要求。客户端使用此文件进行发现。

三层架构整合方案

基于以上分析，可以构建一个将 MCP、A2A 和 AgentKit 整合的三层架构：

┌─────────────────────────────────────────┐│              A2A 协作层                 ││  (代理协调、任务分配、安全通信)         │└───────────────────┬─────────────────────┘                    │┌───────────────────▼─────────────────────┐│              MCP 工具层                 ││  (标准化工具调用、资源访问)             │└─────────┬─────────────────────┬─────────┘          │                     │┌─────────▼────────┐   ┌────────▼─────────┐│   AgentKit UI层  │   │  其他专业工具    ││  (跨平台UI交互)  │   │  (搜索、计算等)  │└──────────────────┘   └──────────────────┘

在这个架构中：

A2A 层处理代理之间的任务分配和协作

MCP 层提供标准化的工具调用接口

AgentKit 层作为 MCP 的一个专业工具，提供跨平台 UI 交互能力

总结

以上，便是我对 AgentKit 这一通用 AI 自动化框架（或套件）的技术展望。

我们正处在 AI 技术深刻影响人机交互的时代。我预见，未来的应用程序不会被 AI 完全替代，而是将形成一个多元化的交互生态： AI 代理、传统图形应用、以及融合两者的混合系统将共存。

用户体验也将随之分层：在高层，用户通过自然语言便捷地表达意图；底层则由 AI 负责将意图转化为具体操作，并在必要时调用合适的图形界面，供用户进行精细控制或获取直观反馈。

这种演变趋势，恰恰凸显了对新型基础设施的需求。我的 AgentKit 构想，正是深受 Droidrun.ai 在 Android 平台自动化探索的启发。Droidrun.ai 的实践验证了 AI 驱动设备控制的可行性，但也暴露了其单平台局限性。

因此，AgentKit 的核心目标是超越平台孤岛，实现真正的跨平台统一自动化。这一愿景的关键技术支撑，在于 AccessKit。它提供了一个标准化的、跨平台的无障碍接口，使得 AI Agent 能够以一致的方式“理解”和“操作”不同操作系统及应用框架下的用户界面。

通过 AgentKit 这一技术构想，我看到了 AI 驱动自动化从平台孤岛走向跨平台统一的一条可能的清晰路径。Rust 的安全性、性能和跨平台能力，结合 AccessKit 的统一无障碍接口，以及现代 LLM 的理解能力，共同为这一愿景提供了坚实的技术基础。

如果看完本文后你对此愿景感兴趣，欢迎你在公众号私信我加群，一起交流与推进 AgentKit 的未来。 当前我创建的 GitHub 组织：AgentKitDev^[3]。

感谢阅读。

参考资料

[1] 

Droidrun: https://github.com/droidrun/droidrun

[2] 

Accesskit.dev: https://accesskit.dev/

[3] 

AgentKitDev: https://github.com/AgentKitDev

阅读原文

跳转微信打开