高德刚开源 AGenUI，Builder.io 的 agent-native 坐不住了：Agent UI 大战正式开卷

高德刚开源 AGenUIBuilder.io 的 agent-native 坐不住了Agent UI 大战正式开卷【免费下载链接】agent-nativeA framework for building agentic apps项目地址: https://gitcode.com/GitHub_Trending/ag/agent-native当大模型厂商还在卷 Agent 的思考能力时一场关于 Agent 界面形态的战争已经悄悄打响。据品玩报道高德联合千问Qwen开源了 AGenUI主打一套代码让 Agent UI 同时跑在 iOS、安卓和鸿蒙上而几乎同一时间Builder.io 开源的 agent-native 框架凭借Agent 与 UI 共享动作的设计在开发者社区持续刷屏——CSDN 上关于它统一 Action 接入面、兼容 MCP/A2A/OpenAI/Claude 协议的解读文章已有数十篇累计阅读数千人次。两个项目一个从跨端渲染切入一个从能力共享切入看似赛道不同实则都在回答同一个问题Agent 应用的用户界面到底该怎么长本文基于公开报道与本仓库源码还原 AGenUI 的跨端信号拆解 agent-native 的共享动作架构并给出两条路线的终局判断。一、AGenUI 开源一个跨端信号背后是 Agent UI 的三端觉醒高德联合千问开源的 AGenUI新闻点非常明确一套代码同时输出 iOS、安卓和鸿蒙三端。这看起来是又一个跨端框架但放在 Agent UI 的时间轴上它的信号意义大于技术意义。过去两年Agent 的承载界面经历了三次迁移先是纯文本聊天框再是 Web 端的工作台上下文、工具、文件、预览全部可视化现在则是移动端。而移动端恰恰是跨端框架竞争最激烈、也最碎片化的战场——iOS、安卓之外鸿蒙正在以惊人速度成为第三极。掘金社区近两年的高热度技术讨论已经暴露了这场底座的演进脉络React Native 0.76 将 New Architecture 设为默认模式、OpenHarmony-SIG 开源了鸿蒙版 RNohos_react_native、Flutter 完成鸿蒙适配。也就是说一套代码跑三端并非 AGenUI 的独门绝技而是跨端技术底座在 2025-2026 年恰好成熟到了可以承接 Agent UI 的节点。AGenUI 真正的信号在于一家出行巨头联合头部大模型团队愿意把自家 Agent UI 的跨端方案开源出来。这等于宣告——Agent UI 不再是实验室玩具而是需要像传统 App 一样被规模化分发到每一个用户手里的产品形态。当鸿蒙生态加入 Agent UI 的载体清单跨端就从开发效率问题升级成了生态覆盖问题。二、agent-native 的同场竞技不渲染 UI而是让 Agent 与 UI 共享一切如果说 AGenUI 的答案是把同一套 UI 渲染到所有平台那么 Builder.io 的 agent-native 给出了另一个方向的答案与其让 UI 跨端不如让能力跨端——把 UI 和 Agent 共同依赖的那一层做成唯一的、可被所有表面复用的 Action 层。这是仓库 README.md 首页就点明的核心设计Define each capability once as an action: the agent uses it as a tool, and the UI calls it from code.翻译过来就是每一个业务能力只定义一次Agent 把它当作工具调用UI 从代码里调用它。两条路径共用同一份校验、同一份权限、同一份实现。共享动作一个 hello 函数打通九种调用面仓库中 packages/core/src/action.ts 的ActionCaller类型直接枚举了这个框架支持的调用面export type ActionCaller | tool // Agent 工具调用 | http // HTTP 接口 | frontend // 前端 React Hook | mcp-widget // MCP Widget | cli // 命令行 | mcp // MCP 协议 | webmcp // WebMCP | a2a // Agent-to-Agent | automation; // 自动化触发这意味着开发者用defineAction写一个能力它同时成为Agent 的 tool、前端的 React Hook、HTTP 路由、MCP 工具、A2A 远程能力、CLI 命令和自动化触发器。README 里的actions/hello.ts是最小示例import { defineAction } from agent-native/core/action; import { z } from zod; // One action powers every app surface: UI, agent, HTTP, MCP, A2A, and CLI. export default defineAction({ description: Return a friendly greeting., schema: z.object({ name: z.string().default(world).describe(Name to greet), }), http: { method: GET }, run: async ({ name }) { return { message: Hello, ${name}! }; }, });Agent 端拿它当工具前端则通过 packages/core/src/client/use-action.ts 导出的useActionQuery/useActionMutation直接调用同一个函数useActionQuery(hello, { name: Alex });defineAction的配置项也印证了一函数多面复用不是营销话术needsApproval、authorize、access、audit、uiOnly、endsTurn、planMode这些字段在 action.ts 中都被设计为对每一个调用者生效——Agent 调用要走审批前端调用同样要走审批权限边界不因入口不同而失守。这是共享能成立的安全前提。共享数据与共享状态Agent 不做 UI 的眼睛agent-native 的另一层共享是数据和状态。packages/core/src/application-state/ 目录下的emitter.ts、handlers.ts实现了应用状态的事件发射与处理机制让 Agent 能感知当前页面、选中记录、激活视图这类 UI 上下文Agent 产生的工作成果写入共享数据层后UI 立即可见。README 对此有一句关键描述The agent does not click through the UI. It works through the same action layer as the UI.Agent 不去点击 UI而是与 UI 走同一条 Action 通道。这恰好是 AGenUI 所代表的跨端渲染路线从未触及的层面——无论 UI 渲染到几个平台Agent 与 UI 之间谁握着操作权的问题都必须靠这一层统一能力面来解决。协议兼容与移动端形态同一套能力的多端延展为了不把自己锁死在单一 Agent 生态agent-native 在 packages/core/src/a2a/ 目录实现了完整的 A2A 服务端与客户端client.ts、server.ts、invoke.ts、handlers.ts并与 MCP、OpenAI 工具协议、Anthropic 工具协议并行暴露——这正是 CSDN 社区解读中反复提及的统一 Action 接入面兼容 MCP、A2A、OpenAI、Claude 协议的源码落点。值得注意的是agent-native 并未回避移动端仓库中的 packages/mobile-app/ 是完整的 Expo / React Native 应用依赖 Expo SDK 57、React Native 生态app.json同时配置了 iOS、Android 与 Web 三端它复用的是agent-native/core与agent-native/agentkit的同一套 Action 能力。这说明统一 Action 层路线与跨端渲染并不互斥——agent-native 的立场是渲染层可以用任何跨端方案但能力层必须收敛为一。下图是 agent-native 生态中一个典型 Agent UI 应用Analytics的实际界面可直观感受Agent 工作台这一产品形态三、两条路线的终局之辨跨端渲染 vs 统一 Action 层回到开篇的问题。AGenUI 与 agent-native 谁更接近 Agent UI 的终局从事实层面拆解两条路线的出发点完全不同AGenUI 解决的是同一套 UI 去哪里它把 Agent UI 当作需要规模化分发的产品用跨端渲染消灭平台差异让鸿蒙用户也能获得与 iOS/安卓一致的能力入口。它的战场在渲染层。agent-native 解决的是同一份能力从哪来它把 Agent 与 UI 之间的能力供给收敛为一个 Action 层消灭UI 一套实现、Agent 一套实现的割裂让审批、权限、审计、状态在所有入口保持一致。它的战场在能力层。二者并非同一层的竞争但终局判断依然清晰跨端渲染解决的是界面怎么画统一 Action 层解决的是能力怎么调——后者才是 Agent UI 区别于传统 App 的根本矛盾。传统 App 的 UI 与后端 API 可以各写一套因为操作者只有人而 Agent UI 的操作者同时是人和 Agent任何UI 一套、Agent 一套的双轨实现最终都会在权限一致性和状态一致性上崩溃。AGenUI 解决了平台碎片却没有至少公开信息中未体现解决人与 Agent 共用同一能力面的问题agent-native 解决了能力共享却把渲染层交给了开发者自选其移动端同样基于 Expo/RN。真正接近终局的形态大概率是两者叠加统一 Action 层作为 Agent 应用的底座跨端渲染框架作为它的皮肤。从这个角度看高德开源 AGenUI 与 Builder.io 开源 agent-native 并非同一赛道的正面交锋而是 Agent UI 大爆发前夜渲染层与能力层各自加速的注脚。当两股力量在某一天汇合——一个既能让 UI 一套代码跑遍三端、又能让 Agent 与 UI 共享同一份动作能力的开源方案出现时Agent UI 的终局才算真正落定。而眼下这场开卷至少把终局提前了两年。【免费下载链接】agent-nativeA framework for building agentic apps项目地址: https://gitcode.com/GitHub_Trending/ag/agent-native创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考