企业官网建设流程全解析

36氪刚说"React Native 黄金时代被 AI 终结"，Builder.io 转头押注 agent-native

【免费下载链接】agent-nativeA framework for building agentic apps项目地址: https://gitcode.com/GitHub_Trending/ag/agent-native

2026 年秋天，一篇标题极具冲击力的文章在技术圈流传开来——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 monorepo，packages/core是核心框架，另有desktop-app（Electron 桌面端）、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