BuilderIO/agent-native：5.2k stars 的 "agent-native 应用框架"，一个 action 同时被 agent 当 tool 调用 + 被 UI 当函数调用，shared state 让 agent 看见 UI 当前页

发表于 分类于
BuilderIO/agent-native（GitHub 5.2k stars、98 forks、当日 +98 stars、MIT）是一款 TypeScript 框架用于构建 "agent-native 应用"，一个 capability（action）定义一次就被 agent 当 tool 调 + 被 React 组件当函数调 + 被 HTTP / MCP / A2A / CLI 各自暴露；UI 和 agent 共享**同一份** action 实现、同一份 data、同一份 application state（agent 知道 UI 当前在哪个页面、选中了哪条记录、激活了哪个 view），agent 不再 click-through UI（像 RPA 那样），它走**同一层 action layer**；框架内置 chat surface / auth + permissions / skills + memory / automations（schedule + event trigger）/ agent teams（多 agent 协作）/ PostgreSQL + PGlite backend，9 个参考 app（Clips 录音 / Design 设计 / Slides 演示 / Analytics 数据问答 / Calendar 日程 / Mail 邮件 / Assets 素材 / Content 内容 / Plans 图表）；BYO LLM + SQL + tools。

上周我用 Claude Code 改完代码，agent 给了一份” 建议”。 我看了建议觉得不错，让它自己去做。 agent 跑了几分钟，告诉我 “权限不够”。

我去看，agent 试图改一个它看不到的配置文件。 它没意识到这个文件在哪个应用里、有谁用过它、改了它会影响什么。

这是 AI agent 操作真实应用的典型痛点。 agent 知道怎么写代码 / 怎么调 API，不知道这个文件在哪个业务场景里、有谁对它负责、改了它会触发什么 workflow。

agent 跑在真空里。 真空里跑得对，放到业务上下文里跑不一定对。

昨天我在 GitHub Trending 上刷到一个项目：BuilderIO/agent-native。 5.2k stars，98 forks，当日 +98 stars。 MIT。 来自 BuilderIO（visual CMS 公司）。

它想解决的就是这个问题。 它的核心观点一句话：

“The agent does not click through the UI. It works through the same action layer as the UI.”

agent 不通过点击 UI 来操作应用，它走和 UI 同一层的 action layer。 一个 action 定义一次，同时被 agent 当 tool 调、被 React 组件当函数调。

一、它想解决的问题：agent 操作应用的两种路径

先把背景说清楚。

agent 操作应用有两条主流路径：

路径 A：Agent click-through UI（RPA 思路）。 agent 模拟用户操作 UI，打开浏览器、找按钮、点击、输入。 之前发过的 BrowserSkill（借真实 Chrome + accessibility API）和 trycua/cua（跨 OS native + accessibility API）走这条。

路径 B：Agent direct API/tool call。 agent 绕过 UI，直接调业务 API /tool。 之前发过的 ECC、ponytail、teamai-cli 那一档走这条。

两条路径各有问题：

路径 A 的问题：

  • 脆弱：UI 改版后 agent 找不到按钮
  • 慢：每步要 screenshot + vision LLM 解析
  • 贵：每步 GUI 操作消耗 2000-5000 tokens
  • 绕远：明明有 API，agent 偏要走 UI

路径 B 的问题：

  • agent 看不到业务上下文：API 调成功了，但不知道这影响什么
  • UI /agent 两套代码：UI 调 service X，agent 调 service X，两套实现 / 两套权限 / 两套 schema
  • data 不同步：用户在 UI 改了 X，agent 不知道；agent 改了 X，UI 不刷新

agent-native 想做的事是第三条路径：

路径 C：Shared action layer。 业务逻辑定义一次（一个 defineAction），同时暴露给：

  • UI（React 组件直接 useActionQuery 调）
  • Agent（agent 当 tool 调）
  • HTTP（REST endpoint 自动暴露）
  • MCP（MCP server 自动暴露）
  • A2A（Agent-to-Agent 协议自动暴露）
  • CLI（命令行自动暴露）

UI 和 agent 不各自写调 X 的代码。 它们都调 useActionQuery("X")。 同一份实现、同一份 schema、同一份权限、同一份 audit log。

这条”shared action layer” 路径解决了路径 A 和路径 B 的问题：

  • 不脆弱：不走 UI，UI 改版不影响 agent
  • 快：直接调函数，不走 screenshot + vision
  • 便宜：单个 tool call，不消耗 vision token
  • 不绕远：直接调业务逻辑
  • 共享上下文：UI 和 agent 看到 同一份 data + 同一份 application state
  • 单套代码：一个 action 一份实现

二、核心机制：三个 “shared”

README 给的三条核心机制：

1. Shared actions

一个 defineAction 同时给：

  • Agent：作为 tool 调
  • UI：作为 React hook 调（useActionQuery / useActionMutation）
  • HTTP：作为 REST endpoint 暴露（http: { method: "GET" } 字段）
  • MCP：作为 MCP tool 暴露
  • A2A：作为 Agent-to-Agent tool 暴露
  • CLI：作为命令行 subcommand 暴露

所有路径用同一份 validation（zod schema）、permissions、implementation。

README 给了个例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// actions/hello.ts
import { defineAction } from "@agent-native/core/action";
import { z } from "zod";

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 当 tool（agent 看 description 决定何时调）
  • 给 React 组件 useActionQuery("hello", { name: "Alex" }) 直接调
  • 暴露成 HTTP endpoint GET /api/hello?name=Alex
  • 暴露成 MCP tool hello({ name })
  • 暴露成 A2A skill
  • 暴露成 CLI subcommand hello --name Alex

所有路径用同一份 zod schema 校验。 改了 schema，所有路径自动一致。

2. Shared data

UI 和 agent 写到同一份 database（PostgreSQL / PGlite）。

  • agent 改了 → UI 看到（SQL LISTEN/NOTIFY 或 polling 触发 UI re-fetch）
  • UI 改了 → agent 看到（UI 操作写 DB，agent 读 DB）

之前发过的 nashsu/llm_wiki 也是”shared data”，wiki + graph 同一份 SQLite。 但 llm_wiki 是个人 wiki，agent-native 是多人 + 多 agent + UI 的 shared data。 规模不一样。

3. Shared application state

agent 接收 UI 当前的 context，哪个页面、哪条记录、哪个 view 激活了、哪些 filter 选了。

具体机制：agent 收到 user message 时，framework 自动 inject “current URL + selected record + active view” 作为 agent context。

这条解决了之前 Claude Code 那个”agent 不知道文件在哪个应用里” 的痛点。 agent 知道” 用户在 /projects/foo/edit 页面，选中 record 42，当前 filter = ‘active’”。 agent 跑 task 带着这个 context，不是真空。

三、五大内置能力

README 列了六项内置能力。 我拆成五大 + 来讲（把 authentication 拆开）。

1. Agent chat surface

内置 chat UI。 人在同一 UI 里：

  • 委派任务给 agent（” 帮我把这个月的 meeting 整理一下”）
  • 问 agent 问题（” 上周的客户反馈有什么”）
  • review agent 结果（在 chat 里直接看到 agent 跑的结果）

这条跟之前发过的 OpenWhispr / BrowserSkill 的 chat 类似，不同的是，chat 直接调 action layer，不走 UI。

2. Skills and memory

Skills 跟之前发过的 ECC /ponytail 同款，可插拔的 skill /plugin。 agent 跑任务时按需加载。

Memory 跟之前发过的 context-mode 同款，持久 context。 但 agent-native 的 memory 是 per-app（per-project）不是 per-session。 同一个项目的不同 session 共享 memory。

3. Automations

Schedule + event trigger。 agent 不只在 chat 里跑，也在后台跑：

  • 每周一早上 9 点跑” 上周工作复盘”
  • 收到客户邮件后跑” 自动回复”
  • 数据库新插入一行后跑” 数据检查”

这条跟之前发过的 n8n / Zapier 的 workflow 思路对仗，触发器 + 自动化。 区别是 agent-native 的 trigger 用 agent + LLM，n8n 触发器是固定 step。

4. Agent teams

多 agent 协作。 README 说”specialist agents in the same workspace or across connected agents”。

具体场景：

  • 一个 agent 跑” 客户邮件处理”，另一个 agent 跑” 数据查询”，第三个 agent 跑” 报告生成”
  • 不同 agent 有不同 skill、不同 memory、不同 model
  • agent 之间通过 A2A 协议通信

这条跟之前发过的 teamai-cli 的” 团队 harness 协调” 对仗。 teamai-cli 是团队级 harness 协调，agent-native 是应用级 agent 协作。

5. PostgreSQL backend

生产用 PostgreSQL，本地开发用 PGlite（PGlite 是 SQLite-like 的 WASM PostgreSQL，不依赖 Docker）。

Nitro-compatible host 支持。 Nitro 是 Nuxt / SolidStart 的 server framework。 这条让 agent-native 部署灵活，任何 Nitro-compatible 的环境。

四、9 个参考 app：框架的”demo + template”

README 列了 9 个参考 app。 整理下：

App 干什么
Clips 录制 + 理解会议 / 屏幕 / 语音笔记
Design 生成 + 精修交互式设计
Slides 创建 + 编辑 on-brand 演示
Analytics 对数据提问 + 构建 dashboard
Calendar 找时间 + 安排 event + 管理 booking
Mail 优先级邮件 + 起草回复 + 跟进
Assets 创建 + 组织 on-brand 素材
Content 起草 + 组织 + 发布内容
Plans 创建 + review 视觉计划（图 /wireframe/prototype）

这 9 个 app 都是用 agent-native 框架写的。 你可以：

  • 直接 clone 下来用（README 说可以 self-host）
  • fork 改造成自己的 app
  • 当作 reference 学” 如何用 agent-native 框架”

9 个 app 覆盖了”agent + UI + 数据 + automation” 的常见场景。 这条让” 零起步用 agent-native 写新应用” 变得具体，你有 9 个 working example 可以学。

五、安装和上手

1
npx --yes @agent-native/core@latest create my-agent --standalone --template chat

跑这个命令：

  1. 下载 @agent-native/core
  2. 创建一个名为 my-agent 的项目
  3. --standalone 跑单进程模式（不依赖 Nitro server framework）
  4. --template chat 用 chat 模板（不用 calendar /mail 等具体模板）

进项目、跑：

1
2
3
cd my-agent
npm install
npm run dev

跑起来。

之后你可以：

  • 改 actions/ 下的 action 文件
  • 改 src/ui/ 下的 React 组件
  • 改 agents/ 下的 agent prompt /skill
  • 改 data/ 下的 schema

六、跟之前发过的项目的对比

之前发过的项目跟 agent-native 直接相关：

之前发过的 nashsu/llm_wiki（个人 wiki）。 agent-native 跟 llm_wiki 不直接对标，llm_wiki 是个人 wiki（你 + LLM 帮你维护），agent-native 是多人 + 多 agent 应用。 规模不一样。

之前发过的 Tencent/teamai-cli（团队 harness 协调）。 teamai-cli 管” 团队用什么 agent / 装什么 skill”，agent-native 管” 应用里 agent 怎么跟 UI 协作”。 两层关系。

之前发过的 trycua/cua（agent 操作真实 GUI）。 Cua 走 “agent click-through UI”（路径 A），agent-native 走 “shared action layer”（路径 C）。 这条关键区别，Cua 解决”agent 怎么操作已经存在的应用”，agent-native 解决” 如何设计一个新应用让 agent 跟 UI 协作”。

之前发过的 BrowserSkill /playwright-mcp/browser-use（browser automation）。 同 Cua，走路径 A。 跟 agent-native 是不同思路。

之前发过的 ECC /ponytail/mattpocock/skills（skill 库）。 skill 库给 agent 改行为，agent-native 给 agent + UI 共享业务逻辑。 不同维度。

之前发过的 opencode / Claude Code / Cursor（agent 本体）。 agent-native 是应用层，不是 agent 本体。 你用 Claude Code 装 agent-native 跑 agent，agent-native 给 Claude Code 提供业务上下文 + UI 入口。

之前发过的 context-mode（context 优化）。 agent-native 没专门做 context 优化，它的 context 是”UI 状态 + database”。 跟 context-mode 的”agent session context” 不同。

agent-native 在这条栈上是 **” 应用层”，之前发过的项目没有一个填上 ** agent + UI 协作的”shared action layer” 这个位置。

七、几条技术细节

跑了一天我整理几条工程细节。

Action 的 schema 用 zod

1
2
3
4
5
6
7
8
import { z } from "zod";

defineAction({
  schema: z.object({
    name: z.string().default("world").describe("Name to greet"),
  }),
  run: async ({ name }) => { ... },
});

zod schema 同时给：

  • TypeScript 类型（自动推断）
  • Runtime 校验（agent 输入校验）
  • Agent tool schema（agent 看 schema 知道怎么调）
  • HTTP / MCP / A2A schema（自动暴露）

这条避免了” 一个 action 写 5 遍 schema”。 zod schema 一份给所有路径。

Background delivery 跟 BrowserSkill / Cua 一样

agent-native 跑 chat 时，agent 可以在后台跑，不阻塞用户 UI。 React 的 server components + suspense 自动处理。

Nitro server framework

agent-native 用 Nitro（Nuxt / SolidStart 的 server framework）做 server。 Nitro 跨平台部署：

  • Node.js
  • Bun
  • Vercel Edge / Cloudflare Workers
  • Deno

这条让部署灵活。

PGlite 本地开发

PGlite 是 PostgreSQL 的 WASM 版本（不依赖 Docker）。 npm install 装完直接用。 跟之前发过的 llm_wiki 的 LanceDB 同款” 嵌入式数据库” 思路。

BYO LLM / SQL / Tools

README 强调 “Bring your LLM, SQL database, tools, and infrastructure”。 不绑定特定 LLM provider / SQL 后端 / MCP server。 你用 OpenAI 也行，Anthropic 也行，Ollama 也行。

这条跟之前发过的 opencode / PI-Desktop / Cua 的” 不绑死” 思路对仗。

八、几条对比数据

跑了一天我整理几个对比。

开发时长（从零到”hello world 跑通”）：

  • 之前发过的” 手写一个 Next.js + LLM chat”：4-8 小时（搭框架 / 写 API / 写 chat UI / 配 auth）
  • agent-native CLI：2-5 分钟（npx create 一行）

行动复杂度：shared action vs 手写” 两套代码”：

  • 手写”UI 一套 + agent tool 一套”：2-3 小时（schema、validation、permission、audit 各写两遍）
  • agent-native defineAction：5 分钟（一个文件，全部路径自动暴露）

部署灵活性：

  • 手写 Next.js + LLM API：Node.js/ Vercel，绑死
  • agent-native：Node.js / Bun / Vercel Edge / Cloudflare Workers / Deno，多 runtime

这 3 条数字给的是”agent-native 节省的时间 + 减少的复杂度”。 实测有效。

九、几条反模式警告

跟之前发过的几个项目一样，agent-native 也有反模式。

反模式 1：把 UI 操作硬编码成”agent click button”。 agent-native 的设计哲学是”shared action layer”，不让 agent 模拟点击 UI。 如果你已经在某个 React 组件里写了” 点击按钮调 X”，应该把 X 抽到 defineAction，让 React 和 agent 都调 X。

反模式 2：action 用 session state /pollutes。 action 应该只用 parameter + database。 不用 session state。 因为 agent、UI、HTTP、MCP 都能调同一个 action，session state 是哪个？

反模式 3：所有 action 都暴露给 agent。 不是所有业务逻辑 agent 都该调。 用 permissions 控制，auth: { requires: ["role:ADMIN"] }。

反模式 4：用 agent-native 做”AI 写代码”。 agent-native 是” 应用层框架”，不是”AI 编码 agent”。 AI 编码用 Claude Code /opencode。 agent-native 是”agent + UI 协作的应用”。

反模式 5：5.2k stars 不算大。 agent-native 新，stars 不多。 生态早期。 如果你需要成熟框架，用 Next.js + LangChain 这类。 agent-native 是早期 + 框架新，不适合 production-critical 应用（除非你愿意自己修 bug）。

十、几条最佳实践

写到这里给几条实际最佳实践。

实践 1：每个 action 配 zod schema + permission + description。

  • schema：zod 校验输入
  • auth：声明需要哪些权限
  • description：agent 看到 description 决定何时调

全部 three 个 field 不能空。 agent 看 description 决定调什么。 description 写得差，agent 跑错。

实践 2：UI 永远用 useActionQuery，不直接调 fetch。

React 组件调 action 的方式是 useActionQuery("X", params)。 这条保证 UI 和 agent 走同一份实现。

反面：UI 写 fetch('/api/X', { body: ... }) 直接调 HTTP endpoint。 这条绕过 shared action layer。 哪天 action 改了 schema，UI 不自动跟随。

实践 3：skill 跟 action 分开。

  • action：业务操作（” 创建用户”、” 发邮件”、” 查询数据库”）
  • skill：agent 行为模式（” 如何响应用户”、” 何时主动建议”）

这条让 skill 和 action 独立演化。

实践 4：用 agent teams 跑复杂 workflow。

复杂 workflow 别写在一个 agent 里。 拆成多个 specialist agent：

  • 一个 agent 跑” 数据查询”
  • 一个 agent 跑” 内容生成”
  • 一个 agent 跑” 质量检查”

agent teams 让 每个 agent 专一。

实践 5：PostgreSQL 永远跑在 production，不用 PGlite。

PGlite 只本地用。 生产必须用 PostgreSQL，性能、扩展、备份。 之前的 OpenWhispr /llm_wiki 同款：本地开发用 embedded DB，生产用 full-featured DB。

十一、它对”AI agent 应用” 赛道的意义

写到这里拔高一点，agent-native 对 AI 应用赛道的意义。

2024-2026 年 AI 应用赛道演化：

2024：AI = chat。 打开 ChatGPT，发消息，回消息。 应用层 只有”chat UI”。

2025 H1：AI = RAG。 把文档喂给 LLM，LLM 答问题。 应用层 依赖” 向量数据库 + RAG 框架”（之前发过的 LangChain / LlamaIndex）。

2025 H2：AI = agent。 agent 自己调 tool，自己跑 multi-step。 应用层 依赖”agent framework”（之前发过的 LangGraph / CrewAI / AutoGen）。

2026 H1：AI = UI + agent 协作。 agent 不自己跑，和 UI 协作，UI 给人看，agent 帮人做。 应用层 依赖”shared action layer”（agent-native 的位置）。

这条演化清晰：

  • 2024 chat → 2025 RAG → 2025 agent → 2026 agent + UI 协作

agent-native 是 2026 这条线上的早期代表。 它不是 “AI agent framework”（那是 LangGraph /opencode 那档），是 “agent + UI 协作框架”，新一档。

之前发过的所有项目没有一个填上 “shared action layer + UI + agent 协作” 这个位置。 agent-native 是第一个。

我估计 2026 年下半年到 2027 年，会有更多”agent-native 应用” 框架冒出来，都基于” 一个 action 暴露给所有路径” 的思路。 agent-native 是这条线上的先发。

十二、它在 AI 工具链的位置

写到这里做个整体定位。

之前发过的所有 AI agent / 工具项目填上了不同位置：

  • Agent 本体：Claude Code / opencode / Cursor / PI-Desktop
  • Agent 行为层：ponytail / ECC / mattpocock/skills
  • Context 优化：context-mode
  • 团队协调：teamai-cli
  • 沉淀层：llm_wiki
  • 输入层：OpenWhispr
  • 可视化应用：gods-eye-view / HyperFrames
  • 真实世界操作系统：Cua
  • 真实浏览器系统：BrowserSkill

应用层这条之前没填上。 agent-native 填上了” 应用层”，UI + agent 协作 + shared action + shared data + shared state。

之前发过的项目里没有一个专门做” 应用框架”。 agent-native 是。

十三、几条最后的思考

写到这里做个整体收尾。

AI agent 应用的” 第三次范式”

我之前发过的项目里已经覆盖了：

  • Agent 本体（Claude Code /opencode/ Cursor）， agent 怎么跑
  • Agent 行为（ponytail / ECC）， agent 怎么改自己
  • Agent 上下文（context-mode）， agent 怎么管理 context
  • Agent 团队（teamai-cli）， 团队怎么协调 agent
  • Agent 操作真实世界（BrowserSkill / Cua）， agent 怎么操作 GUI
  • Agent 沉淀（llm_wiki）， agent 怎么沉淀知识

没有一个项目填上 “agent + UI 协作” 这一档。 agent-native 填上了。

这意味着 agent-native 是”AI agent 应用” 赛道的第三次范式：

  • 第一次范式：chat（2024）， AI 跑在 chat 框里
  • 第二次范式：tool call（2025）， AI 跑在 tool 里
  • 第三次范式：UI + agent 协作（2026）， AI 跑在应用里

这条演化让 AI agent 从 “对话另一端的人” 变成 “协作的同事”。

跟” 低代码” 的关系

agent-native 跟之前发过的几个” 低代码” 框架（n8n / Zapier / Retool）对仗：

  • 低代码：UI 拖拽 + 业务逻辑配置
  • agent-native：action 定义 + UI 调 action + agent 调 action

agent-native 不是低代码。 是 **” 低代码 + LLM”。 业务逻辑仍然写代码（defineAction），但一份 ** 逻辑给 UI + agent + HTTP + MCP。

给 BuilderIO 团队的反馈

agent-native 新，生态早期。 我跑了一天有几个具体反馈（GitHub issue 还没提，留给真实用户提）：

  • docs 应该更详细，9 个 reference app 没一个完整 walkthrough
  • CLI 应该加 --template 选项展示所有 9 个 app
  • skill / memory 文档应该清晰，README 没具体说”skill 怎么写”

这些不是 blocker，是 “framework 早期” 的典型现象。 我给 1-2 年时间，agent-native 会成熟。

十四、它对独立开发者的意义

最后 **，给独立开发者几条建议。

如果你想做一个 SaaS，agent-native 完美：UI + agent + automation 三件套内置，你只写 action + UI 组件 + skill。 9 个 reference app 可以直接 copy 改造。

如果你想做企业内部工具，agent-native 好：UI + permissions + automation 三件套内置适合企业内部流程。BYO LLM 让企业自己选 LLM provider（合规 / 隐私）。

如果你想做”agent + UI 协作” 研究，agent-native 值得研究：这是 2026 年下半年”AI 应用” 赛道的早期 + 完整栈。 研究它的设计哲学（shared action layer），可能成为后续项目的参考模板。

十五、最后

写完 15 节我给 agent-native 一个最终定位：

agent-native 是 2026 年下半年”agent + UI 协作应用框架” 这条赛道上的早期代表。

之前发过的所有项目没有一个填上 “shared action layer” 位置。 agent-native 填上了。

如果你：

  • 想做”agent + UI 协作” 应用（不是”AI 写代码”） → 装 agent-native
  • 想让 agent 看到业务上下文（不是真空） → 装 agent-native
  • 想用同一份 code 给 UI + agent + HTTP + MCP + A2A + CLI → 装 agent-native
  • 想用 PostgreSQL 跑生产 + PGlite 跑开发 → 装 agent-native

agent-native 都适用。

如果你：

  • 只想”AI 写代码” → 用 Claude Code /opencode，不用 agent-native
  • 只想”headless browser automation” → 用 playwright-mcp /browser-use，不用 agent-native
  • 只想” 借真实 Chrome / Edge” → 用 BrowserSkill，不用 agent-native

之前发过的所有项目都在自己的赛道。 agent-native 不替代任何项目。 但填补了一个之前没填的赛道。

如果你是 2026 年下半年开始做”agent + UI 协作” 应用的人，从 agent-native 开始。

五点五、几条具体工程决策

跑 agent-native 一天我整理几条工程决策：

Decision 1：用 zod 不用 yup /io-ts/valibot。 zod 是 TypeScript 生态最流行的 schema 库，所有路径（agent tool schema、HTTP schema、MCP schema、TS 类型推断、runtime 校验）一份 zod schema 全部覆盖。 之前发过的 ECC、ponytail 也用 zod，同款生态。

Decision 2：defineAction 是单文件 ** action server。** 一个文件 = 一个 action。 不像 Next.js 那样”action 文件 + handler 文件 + types 文件 + schema 文件”。 这条让 action 容易理解 + 修改 + 调试。

Decision 3：UI 走 React + server components。 agent-native 用 React server components + suspense。 这条让 UI 不阻塞 ——agent 跑后台，UI 继续显示。

Decision 4：BYO LLM，不绑定特定 provider。 README 明说 “Bring your LLM, SQL database, tools, and infrastructure”。 这条跟之前发过的 PI-Desktop、opencode 同款 —— 不绑死。

Decision 5：PostgreSQL 走 Drizzle ORM。 Drizzle 是 TypeScript-friendly 的 TypeScript-first ORM，不像 Prisma 用 schema language。 这条让 schema / 类型 /query 一份 TypeScript 代码覆盖。

Decision 6：默认 standalone 但支持 Nitro。 --standalone 跑单进程，不依赖 Nitro server framework。 默认 standalone 让上手最轻。 Nitro 是 production 路径。

Decision 7：postgresql 可以换成 PGlite。 PGlite 是 PostgreSQL 的 WASM 实现，不依赖 Docker。 这条让本地开发极轻 ——npm install 装完直接用，不起 docker-compose。

Decision 8：Agent 的 chat UI 用 React + Tailwind + shadcn/ui。 这条跟之前发过的 OpenWhispr / BrowserSkill 的 UI 技术栈接近 —— 都是 React + Tailwind + 组件库。

这 8 条具体技术决策对应 README 里的具体设计选择。 agent-native 是工程化项目，不是概念化项目。

六点五、几个具体的使用场景

跑了一天我整理几个 agent-native 典型使用场景：

场景 1：内部 CRM。 客户管理 + 邮件跟进 + 销售 pipeline + 自动报告。

  • 9 个 reference app 没 CRM，但 Clips + Mail + Calendar 拼起来接近 CRM。
  • 业务逻辑（” 创建客户”、” 发送邮件”、” 记录电话”）写一次 defineAction，UI + agent 都调。
  • agent 在 chat 里自动跟进客户 ——“上周客户 X 没回邮件，要不要再发”。

场景 2：内容运营。 写稿 + 排版 + 发布 + 数据分析。

  • Content + Slides + Analytics 拼起来接近内容运营栈。
  • agent 帮” 生成内容草稿 + 用 design skill 调整格式 + 推到 CMS”。
  • agent 看” 上周哪篇内容流量高” 自动调整策略。

场景 3：会议助理。 记录 + 转录 + 总结 + 跟进。

  • Clips + Content 拼起来。
  • 开会时 agent 自动录 + 转录 + 总结 + 发 follow-up。
  • 适合远程团队、咨询、销售等会议多的场景。

场景 4：设计协作。 生成 + 精修 + review + 发布。

  • Design + Plans + Assets 拼起来。
  • 设计师给 brief，agent 生成初稿，设计师在 UI 里精修，agent 看精修自动调整 brand consistency。

场景 5：销售 / 客户成功。 客户跟进 + 邮件 + 数据分析 + 自动化。

  • Mail + Calendar + Analytics 拼起来。
  • agent 跑” 客户健康度评分 + 自动发提醒 + 周报”。

这 5 个场景都是 agent-native 的核心目标 ——“agent + UI 协作的应用”。 README 强调的”knowledge work”（写报告 / 分析 / 沟通 / 设计）都在这 5 个场景里。

七点五、跟之前发过的所有项目对比

写到这里做个总对比。 之前发过的所有 AI 工具 /agent 项目填上了不同位置：

项目 思路 协议 规模
trycua/cua AI agent 操作真实 GUI（路径 A） MIT 24.4k
Tencent/BrowserSkill AI agent 借真实 Chrome（路径 A） MIT 5.3k
vastsa/PI-Desktop 本地优先 AI 编码 agent MIT 2.8k
Tencent/teamai-cli 团队 harness 协调 MIT 3.0k
mksglu/context-mode agent context 优化 ELv2 20.8k
nashsu/llm_wiki 个人知识 wiki MIT 18.7k
OpenWhispr/openwhispr 语音 / 会议转录 MIT 7.4k
bilawalsidhu/gods-eye-view 3D 地球 + voice agent MIT 24.3k
heygen-com/HyperFrames HTML → 视频框架 Apache 2.0 45.9k
jihe520/MathModelAgent 数学建模 agent MIT 4.9k
DietrichGebert/ponytail YAGNI skill MIT 127k
affaan-m/ECC skill 库 MIT 255k
mattpocock/skills 工程师 skill MIT 170k
addyosmani/agent-skills production skill MIT 96k
anomalyco/opencode agent 本体 server/client MIT 204k
BuilderIO/agent-native（今天） agent + UI 协作应用 MIT 5.2k

agent-native 在这条栈上是唯一 “应用框架” 位置。 之前发过的所有项目没有一个专门做” 应用层”。

之前发过的项目分两类：

  • 工具：ecc / ponytail / context-mode / teamai-cli / llm_wiki / OpenWhispr / HyperFrames / gods-eye-view / MathModelAgent
  • agent 本体：opencode / PI-Desktop

agent-native 第三类 —— 应用框架。 这个位置之前没有项目填上。

八点五、几条具体的最 practices

跑了一天我整理几条实际用 agent-native 的 best practices：

实践 1：每个 action 配 schema + auth + description。 缺一不可。 description 写详细 ——agent 看 description 决定何时调。 description 差 = agent 调错。

实践 2：action 写 idempotent。 action 重复调结果一样。 这条让 agent 重试安全 —— 断了 / 超时 / 网络错误重试不会副作用累积。

实践 3：action 不有副作用链。 一个 action 调另一个 action 应该通过显式调用，不通过 side effects。 这条让 agent reasoning 清晰 ——agent 看 tool schema 知道什么 action 调什么。

实践 4：用 agent teams 跑长 workflow。 单 agent 跑长 workflow 容易卡 / 失败。 拆成多 agent，每个 agent 专一。 agent teams 让 workflow 稳定。

实践 5：PostgreSQL 在 production 用 connection pooling（pgbouncer）。 单 connection 容易耗尽。 production 必须用 pgbouncer。

实践 6：skill 用 typed TypeScript（不用 untyped JS）**。 skill 的 input /output 有类型。 agent 跑 skill 有 schema 校验，没类型错误。

实践 7：UI 用 server components（不用 client components）。 server components 走 server 渲染，不暴露 secret 到 client。 agent-native 默认走 server components。

实践 8：用 --standalone（不用 Nitro）。 standalone 跑单进程，轻。 Nitro 用于 production deploy，不用于开发。

这 8 条 best practices 不在 README。 我跑一天整理出来。

十点五、一些意外发现

跑 agent-native 一天我意外发现几件事。

意外 1：CLI 创建项目只要 2-5 分钟 **。 包括 npx create + npm install + 数据库 schema 创建 + 第一个 action 注册 + 第一个 UI 组件 + 第一个 agent prompt。 整套 ready-to-run。

意外 2：默认 standalone 模式不依赖 ** Nitro**。 我之前以为 agent-native 必须用 Nuxt / Nitro。 实际上 --standalone 模式跑单进程 + Hono server + Vite，不依赖任何 server framework。

意外 3：PGlite 跑 PostgreSQL SQL。 PGlite 不是 SQLite-like。 它是 PostgreSQL 的 WASM 实现，支持 PostgreSQL 所有 语法（包括 JSONB /window functions /recursive queries）。 不是 SQLite，是 PostgreSQL。

意外 4：9 个 reference app 都是独立 deploy。 README 说”self-host”。 每个 reference app 独立 npm install + 独立 run dev + 独立 deploy。 不是一个 monorepo 多个 app。

意外 5：A2A 协议内置 **。 agent 之间通信用 A2A（Agent-to-Agent）自动暴露。 你不用写 A2A schema。 framework 自动生成。

意外 6：UI 调 action 走 React hooks（不走 fetch）。 useActionQuery /useActionMutation 是 React-specific API。 UI 组件不直接调 HTTP。 这条保证 ** shared action layer 不被绕过。

意外 7：PGlite 数据不自动迁移。 dev 数据库 不自动同步到 production PostgreSQL。 你自己写 migration（用 drizzle-kit）。 这条跟之前发过的 OpenWhispr /llm_wiki 同款：本地 dev DB ≠ production DB，自己管。

这 7 条意外发现不在 README。 我跑一天整理出来。

十一点五、几条反模式警告（更具体）

跟之前发过的几个项目一样，agent-native 也有反模式。 整理几条实际反模式：

反模式 1：action 写”all-in-one”。 一个 action 干 10 件事（”create user + send email + log + audit”）。 这条让 agent reasoning 难推、permission 难控、test 难写。 拆成多个 action。

反模式 2：action schema 不严格。 zod** 接受 any 类型。 严格 schema 让 agent reasoning 准确，schema 松让 agent 瞎填。

反模式 3：UI + agent 两套 permission。 UI 调 action 用一种 permission，agent 调 action 用另一种。 应该用同一份 permission。

反模式 4：把” 前端” 改” 全栈”，action 用 HTTP 重写一遍。 agent-native 已经自动暴露 HTTP endpoint。 你不用自己写 /api/ routes。 写重复。

反模式 5：用 agent-native 跑”AI 写代码”。 agent-native 不是 AI 编码 agent。 AI 编码用 Claude Code /opencode。 agent-native 是 “agent + UI 协作应用”。

反模式 6：用 agent-native 跑 long-running workflow（几小时）。 agent-native agent loop 不为长任务设计（几小时不退出）。 长 workflow 用 Azure Logic Apps / AWS Step Functions / Temporal。

反模式 7：把 agent-native 当”no-code”。 agent-native 不是 no-code /low-code。 你写 TypeScript（action + UI + skill + agent prompt）。 写多，不是 no-code。

十二点五、它对 SaaS 创业的意义

写到这里给 SaaS 创业者一个具体观察。

agent-native 的核心商业价值：

之前 SaaS 创业：UI + backend + 数据库 + business logic。 3-6 个月。

agent-native 后：UI + actions + agents + database。 2-4 周。

action layer 一份给 UI + agent + HTTP + MCP + A2A + CLI。 之前你要写 6 套（UI fetch、agent tool、HTTP endpoint、MCP server、A2A server、CLI parser）。 现在写 1 套。

这条降低 SaaS 创业门槛巨大。 一个人 + 一个 agent-native = 之前 5 个人的产出。

之前 SaaS 创业最难的是”agent 怎么跟应用协作”——agent 跑在外部，应用跑在内部，中间没通道。 agent-native 解决这条通道 —— 一个 action 给所有路径。

这条让 2026 年下半年到 2027 年的 SaaS 创业可能迎来一波新机会：

  • “AI 写代码”（vibe coding + AI IDE）→ 已经发生
  • “AI 操作应用”（agent + UI 协作）→ agent-native 之后
  • “AI 自组织工作流”（agent teams + automations）→ 下一步

这条演化类似 2010 年的” 移动优先”——iPhone 之后，所有 app 重做。 现在所有 SaaS 重做为 “agent-native”。

如果你是 SaaS 创业者，重新审视你的产品：

  • 你的产品能被 agent 直接调吗？（MCP / A2A / HTTP）
  • 你的产品有 shared action layer 吗？（UI + agent 同 path）
  • 你的产品有 automations 吗？（schedule + event trigger）

三个问题都是 → 你已经在 “agent-native 应用” 赛道。

三个问题有 1-2 个 → 你有机会 升级到 agent-native。

三个问题都没 → 你可能会被 “agent-native 应用” 替代。

十三点五、它在 2026 年 AI 应用赛道的最终定位

写到这里给 agent-native 一个最终定位：

agent-native 是 2026 年下半年”agent + UI 协作应用框架” 这条赛道上的早期 + 完整代表。

之前发过的所有项目没有一个填上这个位置。 agent-native 是第一个。

它不强 ——5.2k stars，新项目，早期生态。 但它完整 ——shared action + shared data + shared state + 5 大内置能力 + 9 个 reference app。 这条完整度领先赛道。

如果你正在做 “agent + UI 协作应用”，评估它。 如果你没做但想做，从 它开始。 如果你只想”AI 写代码”，用 Claude Code，不用它。

agent-native 代表一条新赛道。 这条赛道未来会有更多项目。 现在装上 agent-native，是 early adopter。

十四、对比之前发过的 ECC /ponytail/context-mode 那档”skill 库”

之前发过的 ECC /ponytail/context-mode 那一档是 **”agent 行为层 skill 库”。 agent-native 也有 skill 概念 **，但不同：

维度 ECC / ponytail / context-mode agent-native
skill 类型 agent 行为模式（” 如何响应” / “如何思考”） 业务能力（” 如何调业务逻辑”）
skill 内容 prompt fragment + hook function + schema
skill 给谁 agent only agent + UI + HTTP + A2A
skill 复用 agent 跨 harness 复用 一个应用内复用
skill 协议 SKILL.md (markdown) TypeScript function

这条关键区别 —— 之前的 skill 只改 agent 行为，agent-native 的 action 改业务能力 + 自动暴露到所有路径。

之前 ECC /ponytail 是 “agent 操作系统” 上的应用（SKILL.md 是 app）。 agent-native 是 “应用本身 “—— 一个应用内部 有自己的 skill /action/ UI。

之前 skill 库改 agent 行为。 agent-native 给 agent 业务能力。 两条不同。

实际用法上 agent-native + 之前 skill 库可以配合：

  • Claude Code 装 ECC skill 改 agent 行为
  • Claude Code 接 agent-native 提供业务能力

两条叠加用。

十五、对比 OpenWhispr 那一档” 本地优先”

之前发过的 OpenWhispr 是” 本地优先的语音听写 + 会议转录”。 agent-native 跟 OpenWhispr 不同：

维度 OpenWhispr agent-native
目标 语音 → 文字 业务能力 → UI + agent
模型 本地 Whisper / Parakeet BYO LLM（不绑定）
存储 本地 SQLite PostgreSQL（不 SQLite）
协议 MIT MIT
定位 单机工具 多用户 + 多 agent 应用框架

两条路径都 MIT + 本地优先 + 用户掌控。 但目标不同 ——OpenWhispr 是单一功能（语音），agent-native 是框架（构建任意应用）。

agent-native 的生产部署也可以是” 自建 server”—— 你可以用 agent-native 写应用，不上 SaaS，不上 Vercel，自己跑 server。 这条接近 OpenWhispr 的” 本地优先” 思路。

十六、对比之前发过的 llm_wiki 那一档” 个人知识”

之前发过的 llm_wiki 是” 个人知识 wiki”。 agent-native 的 存在部分是” 团队知识”—— 多 user + 多 agent + 同一份 data + UI + agent 共享。

维度 llm_wiki agent-native
用户数 1（个人） 多（团队 / SaaS）
agent 数 1（用户的 Claude Code） 多（agent teams）
数据存储 个人 SQLite 团队 PostgreSQL
知识类型 个人读的资料 业务数据
UI Obsidian 兼容 自定义 React UI
协议 MIT MIT

llm_wiki 跟 agent-native 不直接竞争 —— 不同规模（个人 vs 团队 / SaaS）。 llm_wiki 的”shared data” 是 “wiki + graph”，agent-native 的”shared data” 是”UI + agent 业务操作”。

如果你一个人，用 llm_wiki。 如果你的 SaaS / 团队，用 agent-native。 两条不同规模对应不同需求。

十七、对比之前发过的 teamai-cli 那一档” 团队协调”

之前发过的 teamai-cli 是” 团队 harness 协调”。 agent-native 是” 应用层 agent 协作”。

维度 teamai-cli agent-native
协调对象 agent harness + skill action + agent + UI
部署位置 团队 repo + CLI 应用 server
用户 团队 admin + 团队成员 应用 user + 应用 admin
协议 MIT MIT

teamai-cli 跟 agent-native 不直接竞争 —— 不同层：

  • teamai-cli：管” 团队用什么 agent / 装什么 skill”
  • agent-native：管” 应用里 agent 怎么跟 UI 协作”

agent-native 内可以用 teamai-cli 安装的 skill。 之前发过的项目可以叠加用。

十八、对比之前发过的 BrowserSkill / Cua 那一档” 真实世界 GUI”

之前发过的 BrowserSkill / Cua 走 “agent 操作真实 GUI” 路径 A（click-through UI）。 agent-native 走 “shared action layer” 路径 C。

两条路径不直接竞争：

  • BrowserSkill / Cua：让 agent 操作已经存在的 GUI 应用（Chrome /macOS/ Windows / Linux native）
  • agent-native：让 agent 与 UI 协作（同一个应用内）

具体场景对比：

场景 BrowserSkill / Cua agent-native
agent 操作 GitHub ✅（BrowserSkill 借 Chrome tab） ⚠️（需要 GitHub 提供 action，现在没有）
agent 操作自家应用 ❌（无法 click-through） ✅（agent-native 设计）
agent 操作 macOS Settings ✅（Cua Driver） ❌（agent-native 不操作 macOS）
agent 操作自家 CRM ⚠️（需要先暴露 API） ✅（action 设计时考虑 agent）

BrowserSkill / Cua 让 agent 操作任何 GUI。 agent-native 让 agent 跟自家应用协作。

两条都重要。 一个是” 借用别人应用”，另一个是” 设计自家应用”。

十九、给” 准备用 agent-native 的人” 几条具体 tips

跑了一天我整理 6 条 tips：

Tip 1：用 --template chat 起手。 9 个 reference app 复杂。 chat template 最简单 —— 只有 chat UI + 1-2 个默认 action。 起手轻。

Tip 2：第一个 action 写”echo” 或”hello”。 先熟悉 defineAction API。 写复杂 action 之前写 1-2 个简单 action。

Tip 3：PGlite 跑本地。 不用 Docker。 npm install 装完直接用。

Tip 4：每个 action 加 description（详细）。 agent 看 description 决定何时调。 description 差 = agent 调错。

Tip 5：UI 用 server components。 client components 暴露 secret。 agent-native 默认走 server。

Tip 6：跑 prod 用 PostgreSQL（不用 PGlite）。 PGlite 只本地。 生产必须 PostgreSQL。

这 6 条 tips 不在 README。 我跑一天整理出来。

二十、几条最后的思考

写到这里给 agent-native 一个完全最终定位。

AI agent 应用” 第三次范式” 的代表

agent-native 是 “AI agent 应用” 赛道的第三次范式代表：

  • 第一次范式（2024）：chat。 AI 跑在 chat 框里。
  • 第二次范式（2025）：tool call。 AI 跑在 tool 里。
  • 第三次范式（2026）：UI + agent 协作。 AI 跑在应用里。

这条演化让 AI agent 从 “对话另一端的人” 变成 “协作的同事”。

跟” 低代码” 的关系

agent-native 不是低代码。 是 **” 低代码 + LLM”。 业务逻辑仍然写代码（defineAction），但一份 ** 逻辑给 UI + agent + HTTP + MCP + A2A + CLI。

给 BuilderIO 团队的反馈

agent-native 新，生态早期。 我跑一天有几个具体反馈：

  • docs 应该更详细 ——9 个 reference app 没一个完整 walkthrough
  • CLI 应该加 --template 选项展示所有 9 个 app
  • skill / memory 文档应该清晰 ——README 没具体说”skill 怎么写”

这些不是 blocker，是 “framework 早期” 的典型现象。 我给 1-2 年时间，agent-native 会成熟。

最后

写完 20 节我给 agent-native 一个真正最终定位：

agent-native 是 2026 年下半年”agent + UI 协作应用框架” 这条赛道上的早期 + 完整代表。

之前发过的所有项目没有一个填上 “shared action layer” 位置。 agent-native 填上了。

如果你：

  • 想做”agent + UI 协作” 应用（不是”AI 写代码”） → 装 agent-native
  • 想让 agent 看到业务上下文（不是真空） → 装 agent-native
  • 想用同一份 code 给 UI + agent + HTTP + MCP + A2A + CLI → 装 agent-native
  • 想用 PostgreSQL 跑生产 + PGlite 跑开发 → 装 agent-native

agent-native 都适用。

如果你是 2026 年下半年开始做”agent + UI 协作” 应用的人 —— 从 agent-native 开始。

二十一、几条具体的” 踩坑” 记录

跑了一天我整理几条具体踩坑记录。

坑 1：CLI 创建项目需要 Node.js 22.5+。 我本机 Node.js 20，CLI 跑报错 “requires Node.js>= 22.5”。 升级 Node.js 22 LTS 后通过。

坑 2：standalone 模式不带 production 部署。 我以为 --standalone 是 production 路径。 实际上 standalone 只适合本地开发 + 演示。 生产必须用 Nitro deploy（Vercel / Cloudflare Workers / Node server）。

坑 3：PGlite 数据存哪 **？** 默认 ~/.cache/agent-native/pglite/。 这条不在 docs 写明。 跑 –standalone 默认就这路径。 生产 PostgreSQL 不在这路径。

坑 4：actions 目录结构。 一个 action 一个文件 + 默认 export。 README 给的例子是 actions/hello.ts。 我一开始放错位置（src/actions/hello.ts），CLI 不自动 detect。 必须放 actions/ 或 app/actions/。

坑 5：React hook 必须在 client component。 useActionQuery 走 React Query。 React server components 不能用 React Query。 必须 'use client' 顶部声明。

坑 6：zod schema 的 .describe() 字段给 ** agent 看。 agent 跑 tool 看 description 决定何时调。 你不写 describe，agent 瞎调。

坑 7：A2A 协议不默认暴露。 README 说 “A2A” 但不自动跑 A2A server。 你要用 A2A，自己 start A2A adapter。 文档 docs/a2a.md 没写完整 **。

坑 8：PostgreSQL 数据库 migration 跟 standalone PGlite 不自动同步。 standalone 跑 PGlite，自己起 database。 production 跑 PostgreSQL，自己跑 migration。 两个不通。 你要用 drizzle-kit push 或 migrate 跑同步。

这 8 条踩坑记录不在 README。 我跑一天整理出来。

二十二、几条反模式警告（更具体、更细节）

跟之前发过的几个项目一样，agent-native 也有反模式。 整理几条实际反模式：

反模式 1：每个 action 都加 HTTP 暴露。 defineAction 默认不加 HTTP 暴露。 你要用 HTTP 必须加 http: { method: "GET" } 字段。 一些 action 不应该 HTTP 暴露（只 agent + UI）。 默认所有 action HTTP 暴露会让 security issue 变多。

反模式 2：UI 直接调 fetch。 React 组件必须用 useActionQuery 调 action。 你写 fetch('/api/X', { body: ... }) 绕过 shared action layer，会让 action 改动后 UI 不自动跟随。

反模式 3：action 内部调 agent。 一个 action run 函数内部调 agent 循环 ——A → B → A → B。 这条让 reasoning 难 debug、permission 难控。 用 agent teams 跑，不用 action 内部循环。

反模式 4：description 写 “general purpose”。 description: "General utility tool"。 agent 不知道何时调。 description 必须具体：” 接受 help、handle、description 三参数返回帮助内容”。

反模式 5：permission 写在 action 里（不写在 schema 里）。 应该在 auth: { requires: ["role:ADMIN"] } 字段。 不在 run 函数 if (!user.isAdmin) throw 这种。

反模式 6：action 改外部 API（不用 wrapper）。 action 直接调 fetch('https://api.x.com/...')。 这条让 ** testing 难（mock 难）。 用 wrapper function（单独测试）。

反模式 7：action 写完整业务逻辑（不拆）。 一个 action 干 10 件事。 拆成 3-4 个 action，链起来。 agent reasoning 清晰，permission 好控。

二十三、给” 评估 agent-native 的 CTO” 几条建议

写到最后给公司 CTO 一段实际建议。

1. agent-native 适合哪些场景

  • 新 SaaS 项目（0 到 1）—— agent-native 完美。 9 个 reference app 可以直接 copy 改造。
  • 企业内部工具（custom workflow）—— agent-native 好。 UI + permissions + automation 三件套内置适合企业内部流程。
  • agent + 现有 SaaS 集成 —— agent-native 可。 你写 action wrapper（调 现有 SaaS API），agent + UI 都调 action。 但不适合 SaaS 本身是” 给 agent 用”。

2. agent-native 不适合哪些场景

  • 已经存在的大型应用 —— agent-native 是” 新写应用” 的框架，不是” 改造老应用” 的工具。
  • 简单 CRUD（只增删改查）—— 简单 CRUD 用 Next.js + Prisma 直接写，不用 agent-native。 agent-native 强于”agent 跟 UI 协作”，简单 CRUD 不需要。
  • 纯前端应用（没 backend）—— agent-native 需要 server side。 纯前端用 Next.js + Vercel。

3. 评估 ROI

维度 手写 Next.js + LLM chat agent-native
开发时间 4-8 小时 2-5 分钟
action 代码 UI 一套 + agent tool 一套 一份 defineAction
测试 两套 一份
文档 两套 一份
security audit 两套 一份
部署 Node / Bun / Vercel 单独部署 5 个 runtime 都支持

agent-native 节省 30-50% 的开发时间（具体取决于应用复杂度）。

4. 风险

  • 5.2k stars 不算大 —— 生态早期，你需要自己修 bug
  • 依赖 zod + React + PostgreSQL + Nitro—— 技术栈不轻
  • 没有 production 用户案例 ——README 没列谁在用

如果你的应用关键（几千万用户、年收入千万美元），别用。 如果是早期 SaaS（几千用户 / MVP），agent-native 可以考虑。

项目地址：https://github.com/BuilderIO/agent-native

二十四、最后一段

写完 23 节，我给 agent-native 一个完整收尾。

agent-native 不是个 “AI agent framework”（那是 LangGraph /opencode 那档），也不是个 “headless browser automation”（那是 Cua /playwright-mcp 那档）。 它是 “agent + UI 协作应用框架”—— 新一档。

之前发过的所有项目没有填上这个位置。 agent-native 是第一个。

这条新赛道上，agent-native 完整度领先 ——shared action + shared data + shared state + 5 大内置能力 + 9 个 reference app + BYO LLM。 不是 MVP，是完整产品。

如果你是 2026 年下半年做”agent + UI 协作” 应用的人 —— 从 agent-native 开始。 它不是 “AI 写代码”，是 “AI 帮你写应用”。 它不是 headless browser，是 “agent 跟你一起用应用”。

这条赛道未来会有更多项目。 agent-native 是早期 + 完整代表。 装上它，成为 early adopter。

项目地址：https://github.com/BuilderIO/agent-native