36氪刚说React Native 黄金时代被 AI 终结Builder.io 转头押注 agent-native【免费下载链接】agent-nativeA framework for building agentic apps项目地址: https://gitcode.com/GitHub_Trending/ag/agent-native2026 年秋天一篇标题极具冲击力的文章在技术圈流传开来——36氪以React Native 的黄金时代在 AI 手里结束了为题把过去几年移动跨平台开发最大的叙事之一画上句号。几乎在同一时间曾经以可视化、低代码生成著称的 Builder.io正把全部重心押向一个叫 agent-native 的开源框架一个让 Agent 与 UI 共享同一个操作层的 TypeScript 框架。这两件事放在一起看指向的不是某个框架的生死而是一整代人写 UI、机器写逻辑的应用开发范式正在被重构。本文结合社区舆论与仓库源码拆解这场转向背后的逻辑以及 agent-native 到底用代码做了什么。一场关于黄金时代终结的争论是怎么来的先还原 36氪那篇引爆讨论的文章说了什么。核心观点并不复杂React Native 这类跨平台框架的价值主张是一套代码、多处运行开发者用 JavaScript 编写 UI桥接到 iOS 与 Android 双端原生渲染。但 AI 编码能力爆发后这个主张的前提开始松动——既然大模型能同时高质量地生成并维护多套原生代码那为减少重复劳动而引入的抽象层就不再是刚需反而成了需要持续维护的第三套代码。桥接层、New Architecture 迁移、鸿蒙适配这些 RN 社区的热点议题掘金社区中 RN 0.76 新架构成为默认、ohos_react_native 开源等讨论均有数万阅读在 AI 面前都变成了可以绕开的中间环节。值得注意的是掘金社区的数据显示 RN 生态其实仍在活跃演进0.76 之后 New Architecture 成为默认模式、Expo 零配置体验、鸿蒙版开源说明黄金时代终结更准确的表述是RN 不再是下一代应用开发的默认起点。AI 终结的不是 RN 这个技术本身而是跨平台框架作为唯一正确答案的时代叙事。Builder.io 的转身从帮人写代码到让 Agent 和 UI 平起平坐理解 agent-native要先看 Builder.io 是谁。Builder.io 的成名路径是可视化开发与无头 CMS拖拽组件、生成代码、接入现有前端工程本质上是把设计师的意图翻译成代码的低代码/可视化平台。这个赛道与 RN 有一个共同的隐含前提——代码的产出方是人或帮人省事的工具。而当 AI 可以直接看设计稿、说出代码时可视化生成代码的中间人价值被大幅压缩。Builder.io 的回应不是加固旧工具而是把产品哲学整个翻转不再替人生成代码而是构建一个让 Agent 与人类 UI 共享同一套能力的运行时。仓库 README 里写得很直白The agent does not click through the UI. It works through the same action layer as the UI.Agent 不再通过模拟点击、读取像素的方式操作你的应用而是和你写的界面代码走同一条执行路径。这个设计的选择非常关键——它承认了两件事其一UI 不会消失人类依然需要可视化地审查、编辑、批准 Agent 的工作其二Agent 也不该被关在聊天框里它需要拥有与 UI 同等的操作能力。于是 Builder.io 从一个代码生成器转型为Agent 应用的运行时底座这恰好是对AI 终结 RN 黄金时代论调的另一种回答与其被 AI 取代不如把 AI 变成应用的一等公民。一次定义处处复用agent-native 的核心机制打开仓库源码最先看到的是packages/core/src/action.ts中定义的ActionCaller类型export type ActionCaller | tool // Agent 把它当工具调用 | http // HTTP 接口 | frontend // React 前端调用 | mcp-widget | cli | mcp // MCP 协议暴露 | webmcp | a2a // Agent 间协议 | automation; // 定时/事件自动化这是整个框架的支点一个 capability 只定义一次但能以九种身份被消费。文档 Actions 总览 对它的描述是单一事实来源single source of truth——写一次逻辑没有哪个表面会拿到自己的一份拷贝也就没有哪份拷贝会漂移失配。以 Chat 模板中的 hello 动作 为例代码极简import { defineAction } from agent-native/core/action; import { z } from zod; export default defineAction({ description: Return a friendly greeting., mcpTool: true, schema: z.object({ name: z.string().default(world).describe(Name to greet), }), http: { method: GET }, run: async ({ name }) { return { message: Hello, ${name}! }; }, });一个defineAction()调用同时产出了Agent 的工具基于 Zod schema 自动生成类型化工具描述、React 端的useActionQueryHook、HTTP 路由、MCP 工具、A2A 工具与 CLI 命令。这正是社区文章反复强调的消除 UI 与 AI 逻辑割裂的工程实现——传统应用要为 Agent 单独写一套集成代码agent-native 直接把写一遍变成了写一次。更进一步动作层的run里可以读取前端正在使用的应用状态。view-screen 动作 展示了这个机制import { readAppState } from agent-native/core/application-state; // ... run: async () { const navigation await readAppState(navigation); // ... }Agent 拿到的是当前页面、当前选中记录、当前视图这类真实的应用上下文而不是自己脑补的上下文。应用状态存储 提供putState/getState/compareAndSet等原语支撑Agent 的工作出现在 UI 里、UI 里的操作对 Agent 可见的双向同步。README 将此概括为三大支柱共享动作Shared actions、共享数据Shared data、共享应用状态Shared application state。源码里还有一个值得注意的细节——packages/core/src/action.ts中的WriteReceipt接口写入回执动作在写入后返回changed、verified、subject、checks等字段Agent 循环在结果字符串化之前先读取这份回执让最终回答与写入实际发生了什么对齐而不是与模型对 JSON 字符串的解读对齐。这体现了 Agent 原生应用对幻觉导致错误汇报这一真实问题的工程化防御——它关心的是 Agent 的执行结果能否被系统自证。三种形态与技能体系Agent 原生应用的工程化框架的野心不止于UI 与 Agent 共享动作。仓库 开发指南 展示了完整的工程化配套这是一个 pnpm monorepopackages/core是核心框架另有desktop-appElectron 桌面端、mobile-app移动端、dispatch工作区控制平面、scheduling排期原语等包templates/下则是 14 个可直接落地的生产级模板应用从chat、mail、calendar到analytics、design、clips每个模板都是独立应用自带 Drizzle schema、actions 与 UI。chat 模板 的定位最能说明产品分层一个开箱即用的 ChatGPT 风格外壳带持久化线程、认证、实时同步与动作层是最小可扩展的起点。而完整形态则由社区总结为三种纯 API 应用、富聊天界面应用、完整 SaaS 应用——同一套动作层可以只暴露接口也可以长出完整的前后端。对团队而言这意味着可以从先让 Agent 跑通业务闭环的最小形态起步再逐步叠加 UI而不是一开始就押注某个固定形态。技能skills体系则回答了Agent 应用如何沉淀领域知识仓库根目录的skills/收录了visual-edit、turn-into-app、visual-recap等技能包配合模板中的learnings.defaults.md让 Agent 拥有可复用的专业能力与持续积累的上下文。加上 A2A 协议仓库packages/core/src/a2a/目录支持跨应用 Agent 协作agent-native 试图覆盖的已不止于一个聊天机器人而是完整的 Agent 组织形态。范式之问前端开发真的被 Agent 原生应用接管了吗回到开头那个争论。36氪的论断有一定的事实基础——跨平台桥接的稀缺性确实在下降Agent 直接产出原生代码的能力在增强但终结一词过于绝对。掘金社区的高热度讨论RN 新架构、RN vs Flutter 选型、独立开发者用 RN 做产品说明在人依然在写产品的范围内RN 的生态、性能与心智积累仍有庞大惯性。agent-native 给出的第三条路更有参考价值它不否认 UI也不否认 Agent而是重新分配两者的分工——重复、批量的操作交给 Agent 通过动作层完成审查、决策、微调、异常处理留给人类在 UI 里完成。当 Agent 拥有与你相同的操作接口和可自证的结果回执时接管就不再是夺权而是协作。这与社区近期关于AI Native 研发范式的讨论Agent 作为执行主体的全流程重构、CI/CD 新增 AI 审查闸门等形成了同频共振被终结的不是某个框架而是应用由单一主体单向驱动的旧假设。Builder.io 用一次开源押注给出了自己的答案UI 与 Agent 共享动作层、共享数据、共享状态谁都不会被淘汰因为两者最终服务的是同一个业务闭环。至于 React Native 的黄金时代是否落幕答案或许取决于你怎么定义黄金——如果它指跨平台方案独占移动开发那确实结束了如果它指用最合适的工具服务真实用户那新篇章才刚刚开始。【免费下载链接】agent-nativeA framework for building agentic apps项目地址: https://gitcode.com/GitHub_Trending/ag/agent-native创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考