我们一定要给自己提出这样的任务：第一，学习，第二是学习，第三还是学习。——列宁

https://github.com/BuilderIO/agent-native

当应用不再只是被点击：BuilderIO Agent-Native 正在把软件变成会行动的生命体

有些项目一眼看上去就像工具。
你知道它能帮你省时间、提效率、少写几段胶水代码。

但也有一些项目，不只是工具，它更像一种宣言。
它会轻轻拍一下你的肩膀，对你说：

别再把 AI 塞进聊天框边上了。
让它真正住进你的应用里。

BuilderIO 的 Agent-Native，就是这样一个项目。

它在仓库 description 里说得很干脆：A framework for building agent-native applications.
一句话，利落得像一记直球。
而 README 则把这句话真正展开：它不是要做一个“会聊天的小插件”，而是要做一个面向 agent-native 应用的开源框架，让智能体不再只是坐在应用旁边指手画脚，而是能直接在真实应用内部工作、协作、执行、同步、成长。

读完 README 后，我脑子里冒出的第一个画面是：

以前的 AI 像站在办公室门口的顾问，能给建议，但碰不到你的电脑。
而 Agent-Native 想做的，是让 AI 换上工牌、拿到工位、接入系统、参与流程，真正变成团队里那个会干活的同事。

这就是它迷人的地方。

它不是让 AI 陪着应用聊天，而是让 AI 真的进场做事

README 开头那句话非常有力量：

Agent-Native is an open-source framework for building robust agents that act inside real apps, not just chat next to them.

这句话其实已经把这个项目和很多 AI 项目划开了边界。

我们已经见过太多“AI+产品”的组合拳：

  • 页面右下角加个聊天按钮
  • 表单旁边加个智能建议
  • 文本编辑器上加个润色弹窗
  • 后台接一个大模型 API，就说自己 AI 化了

这些东西有价值，但很多时候，它们仍然只是“外挂式智能”。
Agent 站在产品外面，像个热心路人，能说，会提议，但很难真正接管流程。

而 Agent-Native 的思路是另一种路径：

让 agent 成为应用系统里的正式居民。

不是借宿，不是旁听，不是隔着玻璃窗指导你。
它要和 UI 共享动作、共享状态、共享数据库、共享上下文。
它不是在应用边上聊天，而是在应用里面行动。

这一下，味道就完全不同了。

它最核心的一句话，可以说是整套设计的灵魂

README 里有一句我特别喜欢：

The agent and the UI are equal citizens of one system. Every action works both ways: click it or ask for it.

翻成更有画面感的话就是：

在 Agent-Native 的世界里，UI 和 Agent 像住在同一座城市的两位正式市民。
谁都不是临时访客，谁都不是旁门左道。
按钮能做的事，Agent 也能做。
Agent 能调的能力，UI 也不是另起炉灶。
两边走的是同一条路，只是入口不同。

这一点特别重要。

因为很多系统一旦引入 AI，就会很快裂成两套：

  • 一套给人类用户点击
  • 一套给智能体工具调用

短期看很快，长期看很痛。
你会开始维护两份逻辑、两种权限、两套状态同步、两类 bug。
前台的按钮能做一件事，Agent 却要靠另一个隐藏接口去做；
Agent 修改了数据，UI 却不一定能及时感知；
UI 里的流程经过完整校验，Agent 走的捷径却可能漏掉规则。

Agent-Native 试图从根上避免这类“人格分裂”。

它给出的答案很漂亮：

One action powers UI, agent, HTTP, MCP, A2A, and CLI.

你定义一次 action，
它就可以同时服务于：

  • UI
  • Agent
  • HTTP
  • MCP
  • A2A
  • CLI

这不是“复用得不错”，这是设计哲学上的统一。
它像在说：别再为不同入口各写一份能力了，让能力本身成为真正的一等公民。

这个框架像一个很会统筹的大管家，把应用里的角色安排得明明白白

如果把一个现代应用想象成一栋大宅子，过去的很多 AI 能力像是窗外喊话的人。
你能听见他给建议，但他进不来，也碰不到房间里的东西。

Agent-Native 不一样。
它像一位拿着总钥匙、熟悉每个房间布局、又懂规矩的大管家。

README 里列出的几个核心点，很像这位大管家的能力清单：

  • Actions：工作定义一次，到处可用
  • Agent runtime：聊天、工具、技能、记忆、任务、可观测性、交接一起打包
  • Backend agnostic：数据库和宿主环境不锁死

这三条看起来平静，其实都很重。

Actions 像一份统一的工作说明书

你可以把 action 理解成“应用真正会做的事”。

它不是“某个页面上的按钮事件”，也不是“某个 Agent 临时学会的技巧”，
而是一种更本质的能力声明：

  • 输入是什么
  • 校验规则是什么
  • 执行逻辑是什么
  • 谁都可以通过规范入口来调用它

README 里的示例就很典型：

1
2
3
4
5
6
7
8
9
export default defineAction({
  schema: z.object({
    emailId: z.string(),
    body: z.string(),
  }),
  run: async ({ emailId, body }) => {
    await db.insert(replies).values({ emailId, body });
  },
});

这一小段代码气质非常明确。
它不炫技，不花哨，像一份认真写好的岗位说明书：

“如果你想回复一封邮件，请带上 emailId 和 body，格式按 schema 来，剩下的执行交给我。”

UI 看见它会说：好，我给用户一个按钮。
CLI 看见它会说：好，我给开发者一个命令。
Agent 看见它会说：好，我明白该怎么合法地完成这件事。
HTTP 接口也会说：好，我可以把它暴露给外部调用。
MCP、A2A 也都能接进来。

于是，这个 action 不再只是代码文件，它更像应用世界里的一个“公共岗位”。
谁来申请执行都可以，但流程一致，行为一致，结果一致。

Agent runtime 像给智能体配齐了办公室全套设施

README 里说得很直接：
Chat, tools, skills, memory, jobs, observability, and handoffs ship together.

这句话最妙的地方在于“ship together”。
它没有把 Agent 运行时拆成一堆你自己拼的积木，而是尽量把一整套生产级元素放进同一艘船里。

这意味着什么？

意味着这个 Agent 不是“会回复消息”就算完事，
它还有：

  • tools 去做事
  • skills 去组织能力
  • memory 去记住上下文
  • jobs 去跑任务
  • observability 去被追踪和理解
  • handoffs 去完成协作与交接

一个真正能在产品里长期工作的智能体，不能只靠嘴。
它得有手，有脑，有记忆，有流程意识，还有“工作日志”。
Agent-Native 给人的感觉，就是在认真为这个“数字同事”配置工位，而不是临时借把椅子给它坐。

Backend agnostic 像是在告诉你：放心，我不打算把你绑在我身上

README 里提到：

  • 任意 Drizzle 支持的 SQL 数据库
  • 任意 Nitro 支持的宿主环境

这是一种很成熟的姿态。
它没有强迫你把基础设施整套迁进它的帝国。
它更像一个很懂分寸的合作者：

“你保留自己的地基，我负责把这套 agent-native 能力铺进去。”

在今天这个时代，任何一个框架只要想做平台级能力，都绕不开一个敏感问题：
你究竟是在帮我搭东西，还是想把我锁进去。

Agent-Native 在 README 里的表达很明确：No lock-in.
这四个词很短，但对开发者来说很有安抚作用。
谁都不想花大力气造未来，最后发现未来的门只能从别人家后院进。

它最惊艳的地方，不是“能用 AI”，而是“Agent 和 UI 完全连上了”

README 有个章节标题非常有冲击力：

Agents and UIs, Fully Connected

我第一次看到这个标题时，脑子里浮现的是两条以前常常平行不相交的铁轨，终于被铺上一段真正可靠的联结桥。

它列出了几件很关键的事。

Everything syncs

One database, one state. Changes from either side show up instantly on the other.

这几乎就是系统一致性的诗意表达。
一个数据库，一份状态。
不管是人点出来的，还是 Agent 做出来的，都会立刻反映到另一边。

你可以想象这样一个场景：

你在界面上选中一段内容，Agent 根据你的意图帮你修改；
它一动笔，UI 立刻更新；
你手动拖动了一块结构，Agent 也同时“看见”了变化；
双方不是你改一版我同步一版，而是共处一片实时流动的工作台。

这不是在做一个“智能建议器”，这更像在做一个“共创空间”。

Real-time multiplayer

README 甚至用了这样一种表述：
Humans and agents edit the same document together, with the agent as a first-class peer.

“first-class peer” 这个词特别有意思。
它不是说 Agent 是个影子助手，也不是说它只是一个增强功能。
它是一个真正的一等协作者。

如果人类协作编辑像几位设计师围着一张大桌子工作，
Agent-Native 的 Agent 就像其中一位已经坐下来的同伴。
它不是站在门口建议“你们可以再改改”，而是把椅子往前一拉，直接开始参与这张图、这份文档、这段内容、这套产品的共同编辑。

Context-aware

README 写得很生动：
The agent knows what you’re looking at. Select text, hit Cmd+I, and tell it what to do.

这个点特别关键。
因为 Agent 真正好不好用，很大程度上取决于它有没有“现场感”。

很多 AI 工具不差，问题是“它不知道你此刻正在看哪里”。
于是每次都要解释上下文、补充背景、重述目标，搞到最后像是在跟一个聪明但总不在场的同事协作。

而 Agent-Native 想做的是让 Agent 更像真的“站在你旁边”：

你看到哪，它就看到哪；
你选中了什么，它就知道你在意什么；
你敲下命令，它不是从宇宙真空里猜，而是从当前工作现场出发。

这会让交互从“命令 AI”变成“顺手吩咐”。
体验上差别极大。

Agents call agents

README 里还有一句很有野心的话：

Tag another agent from any app and they coordinate over A2A.

这意味着什么？

意味着在这个体系里，Agent 不是单兵作战。
它们可以像团队成员一样相互呼叫、分工、协同。

你在 Calendar 里发起一个任务，
它可以去找 Mail；
你在一个应用里提出问题，
另一个应用里的 Agent 可以接棒。

这时整个系统的味道，已经越来越接近“多智能体工作网络”了。
不是一个万能机器人包打天下，而是一群各司其职、可彼此协调的数字同事在同一公司里穿梭。

这个方向非常迷人。
因为现实世界的工作，本来就不是单线程完成的。
一个能真正进入业务流的 AI 体系，迟早都要走到协作这一层。

Self-improving

README 中最像科幻片台词、却又最让人心跳加快的一句是：

The agent can add features, fix bugs, and refine the UI over time.

应用不再只是被维护。
它开始能在一定边界内，参与改善自己。

这就像你搭建了一座房子，
然后住进来一位聪明的管家。
他不仅会收拾房间，还会发现哪个门轴响了、哪面墙灯光不好、哪条走廊太绕，甚至会主动建议装修、亲自修补、重新优化布局。

当然，这种能力越强，越需要规则、权限、审计与可观测性。
而这也正是 Agent-Native 之所以强调 product-grade、runtime、observability 这类工程元素的原因。
它并不是在鼓励无约束的自动化，而是在认真为“会进化的应用”打地基。

这些模板不像模板，更像一整排已经装修好的店铺等你开门营业

README 对模板的描述很有感染力：

Start with a full featured template. Each one is a complete, 100% free and open-source SaaS app: cloneable, not scaffolded, except you own the code and can customize everything.

这里有几个字我觉得很有味道：

  • full featured
  • complete
  • cloneable
  • not scaffolded
  • you own the code

这不是在卖“脚手架”，而是在给你现成的完整店面。
你不是拿到几块木板、几颗钉子回家自己搭，而是直接拿到一间已经能营业、但产权归你的铺子。

README 列出来的模板非常丰富，而且都很有明确角色感。

Calendar

一个带 AI 排程能力的日历和预约系统。
它像一个时间管理很强的秘书，能帮你管理事件、同步 Google Calendar、共享预约页面。

Content

一个面向 Markdown 和 MDX 的内容工作台。
它像一位擅长写作、编辑、排版、发布流程的内容搭档。
你可以编辑本地 Markdown/MDX 文件，生成交互式自定义区块，还能让 Agent 帮你起草、重写、发布。

Plans

这是我觉得非常有当代开发者共鸣的一类模板。
它主打给 coding agents 提供可视化计划和复盘能力，安装 /visual-plan 和 /visual-recap 后，Agent 不再一上来就闷头写代码，而是先摊开设计图，再在落地后做高空视角复盘。

这就像一个原本容易“先干再说”的程序员同事，突然学会了先画草图、再做总结，还会给你看图讲解。
很难不喜欢。

Slides

一个可以通过提示词或手动方式生成、编辑 React 演示文稿的应用。
它像一位会做 PPT、会讲故事、还懂视觉表达的演示搭档。

Analytics

它可以连接分析数据源、按提示生成真实图表、构建可复用仪表盘。
它像一位会盯指标、懂业务、也会做图的分析师。

Clips

屏幕录制、自动转录、可分享链接，还有能总结、加字幕、编辑片段的 Agent。
它像一个反应很快的视频剪辑助手。

而在 packages/core/README.md 里，你还能看到更丰富的模板宇宙：

  • Mail
  • Video
  • Design
  • Dispatch
  • Forms
  • Brain
  • Assets

每一个都不是抽象能力，而是具象产品形态。
这意味着 Agent-Native 不只是提供底层框架，它也在努力证明：
这套思路可以落到真实、完整、可拥有的应用上。

最让我上头的一句话，是“你拥有代码”

README 里多次强调一件事：

you own the code
fork it, customize it with the agent, own it

这句话其实戳中了很多团队现在最纠结的地方。

SaaS 很方便，但越来越多团队也越来越清楚：

  • 方便是方便，边界也是别人的
  • 智能是智能，数据和流程往往不完全属于你
  • 能接入是能接入，但真正深度改造的时候会撞墙

Agent-Native 的一个重要吸引力，是它试图把“产品级体验”和“代码所有权”同时递给你。
不是让你在“现成 SaaS”和“自己从零造轮子”之间二选一，
而是给你一个第三条路：

拿一个完整能跑的应用，直接拥有它，再让 Agent 帮你继续改。

这很像你不是去租一间办公室，而是直接买下一套已经装修好的空间。
桌椅板凳都齐了，网络也通了，灯也亮了，门锁也好使，
接下来你可以自己扩建、改造、分区、换风格，而且这个空间本身还会有一个懂业务的智能搭档陪着你折腾。

这种感觉，对创业团队、产品团队、工程团队都很有吸引力。

快速启动非常直接，像把钥匙塞进你手里然后说“进去吧”

README 的 Quick Start 非常干净。

1
2
3
4
npx @agent-native/core@latest create my-app
cd my-app
pnpm install
pnpm dev

就这么几行。
但它背后不是简单创建个空项目，而是在问你：
你想以什么姿势进入 agent-native 世界？

README 里提到，create 会先问你如何开始：

  • Full template(s)
  • Chat
  • Headless

这三个入口，像三种不同性格的大门。

Full template(s)

如果你想要的是一套完整应用，直接开干，这扇门最适合。
README 说得很诱人：你可以一次选多个完整应用放进同一个 workspace。比如 Mail + Calendar + Forms，一次拿下，且共享 auth。

这就像逛商场时，你不是买一张桌子，而是把书房、客厅、餐厅整套一并搬回家，还自动把电路、门锁、走廊全接好了。

Chat

如果你想从最简单的 UI 体验切入，它给你一个单应用最小聊天界面和已经接好的浏览器壳子。
就像先给你一间小型演示厅，方便你快速看到 Agent 在前台是怎么与用户见面的。

Headless

如果你更偏动作优先、后面再补 UI，这个入口就很适合。
README 说得很清楚：CLI 会带你调用第一个 action 和 agent，UI 以后再加。

这像先把发动机装好，车壳先不急。
对一些后端思维强、想先跑业务能力的开发者来说，非常友好。

而如果你不想在交互式提示上多停留，还可以直接加 flag：

1
2
3
npx @agent-native/core@latest create my-app --template mail
npx @agent-native/core@latest create my-app --headless
npx @agent-native/core@latest create my-app --standalone

这类命令行体验很讨喜。
它像一个很懂你节奏的搭档：
想慢慢选，我陪你；
想一把梭，我也不拦着。

如果你不想立刻搭整套应用，它还给你留了一条很顺手的小路

README 里有一个特别实用的部分：Try it with a skill

如果你现在还不想 scaffold 整个应用，
但已经在用 Claude Code、Codex、Cursor、Pi、OpenCode、GitHub Copilot、VS Code 一类的 coding agent，
你可以先装一个技能试试：

1
npx @agent-native/core@latest skills add visual-plan

这一条命令的气质很像：

“你先别搬家，来我这儿试住一晚。”

装完之后，你会得到两个 slash commands：

  • /visual-plan
  • /visual-recap

它们特别像给 coding agent 加上了两种成熟职业习惯。

/visual-plan

在动手写代码之前，先把计划展开。
不是一堵密密麻麻的文字墙，而是结构化、可审阅、能评论的计划文档，包含：

  • 内联图示
  • UI 线框图
  • 文件级实施映射
  • 注释和评论空间

换句话说，Agent 不再像那个“嗯我懂了我先改改看”的同事，
而像一个会先把施工图摊在桌面上的资深工程师。

/visual-recap

变更落地之后，它还能把 PR 或 git diff 变成一个高空视角的视觉复盘。
不是只有生硬 diff，而是更适合 review、沟通、分享的变化总览。

这就像一位干完活以后还会认真交付汇报的同事。
他不仅说“我改完了”，还会把前后变化、结构影响、关键路径都给你讲清楚。

这两个技能看似只是“增强”，但其实和 Agent-Native 的整体哲学非常一致：
Agent 不是神神叨叨凭感觉行动，
而是逐渐具备更强的计划性、可视性、协作性和审阅友好度。

Workspaces 这一段特别有产品架构感，像给多应用世界搭了一条共享中轴线

在 packages/core/README.md 里，Workspaces 这一节非常值得看。

它告诉你，workspace 是 agent-native 项目的默认形态。
应用放在 apps/ 下，公共部分放在 packages/shared/，共享秘密、共享基础能力、共享身份。

目录结构大概像这样：

1
2
3
4
5
6
7
8
9
10
my-platform/
├── package.json
├── pnpm-workspace.yaml
├── .env
├── packages/
│   └── shared/
└── apps/
    ├── mail/
    ├── calendar/
    └── forms/

这种布局不是为了好看，而是为了支撑一种很自然的产品演化方式：

今天你先做 Mail。
明天你加 Calendar。
后天你把 Forms 也纳进来。
它们不是东一榔头西一棒子，而是从一开始就住在同一个社区里。

更舒服的是，你后面还可以继续加 app：

1
npx @agent-native/core@latest add-app notes --template content

这条命令像是在你已经建好的城市边上，再开一条新街区。
不是另起炉灶，而是自然扩张。

而部署也很有意思：

1
2
3
4
npx @agent-native/core@latest deploy
# https://your-agents.com/mail/*       → mail
# https://your-agents.com/calendar/*   → calendar
# https://your-agents.com/forms/*      → forms

README 提到，同源部署意味着：

  • 共享登录会话
  • 零配置跨应用 A2A

这听起来很技术，但带来的产品体验其实非常直观。
你从 calendar 的 agent 聊天里去 tag @mail，它就能自然协作。
没有繁琐 JWT 签名折腾，没有跨域大戏，没有一层层“等我先打通集成”。

这很像原本分散在不同楼层、不同系统、不同门禁里的同事，终于搬到了一个园区。
你喊一声，隔壁工位的人就能接话，不用先填三张表单开访客权限。

它对“人、应用、智能体”关系的理解，其实很超前

我觉得 Agent-Native 最深的价值，不只是提供了一套框架，而是它在悄悄推动一种软件世界观。

过去我们习惯的软件结构大概是：

  • 人类是主用户
  • UI 是主入口
  • API 是系统对系统的接口
  • 自动化只是附属能力

但 Agent-Native 给人的感觉是：
未来的软件，不应该只围着人类点击来设计。
它应该从一开始就承认，除了人类用户，还会有智能体作为一等使用者。

于是系统设计就会发生根本变化：

  • 能力不再只挂在按钮上，而是抽象为 action
  • 状态不再只服务前端渲染，而是对 UI 与 Agent 都可感知
  • 协作不再只发生在人与人之间，也发生在人与 Agent、Agent 与 Agent 之间
  • 应用不再是静态工具，而是可持续参与自我优化的工作体

这是一种很大的范式转向。
而 BuilderIO 这个项目最厉害的地方，是它没有只写一篇未来宣言，而是把这种范式尽可能变成了可下载、可运行、可定制、可部署的工程现实。

那张对比表，其实把它的野心讲得很清楚

README 里有一张很直白的表格，对比了：

  • SaaS Tools
  • Raw AI Agents
  • Internal Tools
  • Agent-Native

我特别喜欢这种不绕弯子的表达方式。
它几乎就是在说：

我们知道现有世界都有哪些选择，也知道每种选择痛在哪里。
现在，我们试图做一个不一样的答案。

从表里看，Agent-Native 希望同时拿到几件过去很难兼得的东西：

  • Full UI
  • Agent-first, integrated
  • You own the code
  • Agent modifies the app

这四件事能一起成立，本身就很有吸引力。
因为过去你常常只能在这些选项里二选一、三选二：

  • UI 好，但不能深改
  • AI 强，但没有产品感
  • 内部工具能控，但维护重
  • 代码在你手里，但体验粗糙

Agent-Native 明显是在追求“全都要”。
而且不是嘴上全都要，是试图用模板、运行时、工作区、技能、部署路径把这个目标落地。

如果把它拟人化，它像一个很会带团队的总导演

我忍不住想用拟人的方式来形容这个项目。

Agent-Native 像什么？

它像一个站在片场中央的总导演。

UI 是演员，负责和观众面对面。
Agent 是另一位演员，既能临场发挥，也能按剧本做事。
Actions 是剧本分镜，谁上场都按同一版台词和动作逻辑走。
Runtime 是片场调度，灯光、收音、场记、后勤全都在。
Templates 是现成的剧组布景，推门就能开拍。
Workspace 是摄影棚园区，不同场景共享资源、共享电力、共享人员。
A2A 像演员之间的对戏和接戏。
Observability 像监看器和回放室，确保每个镜头都看得见、说得清。
Memory 像角色小传，确保它不是演一会儿就失忆。
Self-improving 像演员不仅会演，还会在拍摄过程中主动帮你把走位和节奏越调越顺。

最妙的是，这位总导演还没有要求你必须签终身合约。
它说：片场你可以用，布景你可以改，版权你自己拿，拍出来的片子归你。

这种姿态，真的很难不让人产生好感。

我很喜欢它那种“不是替代你，而是和你一起做”的气质

很多人一提 AI，就会自然联想到替代。
但 Agent-Native 给我的感觉，不太像“替代”，更像“并肩上岗”。

它不是要把 UI 淘汰掉，README 反而明确强调 UI 和 Agent 是 equal citizens。
它不是说以后都不用产品设计了，反而在多个模板里强调真实界面、真实交互、真实应用体验。
它不是说开发者以后别写代码了，反而提供 actions、templates、workspace、deploy 这些非常工程化的抓手，让你用更强的方式继续掌控系统。

这种气质其实很高级。
真正有前景的工具，通常不是逼你交出方向盘，而是让你开得更远、更多线并行、更少重复劳动、更自然地引入新协作者。

Agent-Native 就像在说：

你继续做产品。
你继续写代码。
你继续设计体验。
只是从今天开始，你的团队里多了一类新成员。
它叫 Agent。
而我负责让它别像外包实习生，更像能真正干活的正式同事。

对开发者来说，它最值得关注的不是新鲜，而是统一

技术世界每天都有新概念。
真正能留下来的，往往不是“听起来最炸”的那一个，而是“把复杂性统一得最好”的那一个。

Agent-Native 的强点，我觉得恰恰在统一：

  • 统一能力入口
  • 统一人机执行语义
  • 统一状态同步
  • 统一应用与 Agent 的协作模型
  • 统一从模板、启动、扩展到部署的路径

这种统一不是表面上的“一站式”，而是深层结构上的一以贯之。
你越读 README，越会感到它不是东拼西凑的功能清单，而是在围绕一个主轴做设计：

应用不该只是给人点击，也该能被 Agent 可靠地使用、协作和扩展。

这句话如果成立，那么大量设计都会顺着它自然长出来。
而 Agent-Native 看起来正是在沿着这条逻辑生长。

快速启动命令整理

如果你打算直接上手，README 里提到的几组命令很值得先收好。

创建新项目

1
2
3
4
npx @agent-native/core@latest create my-app
cd my-app
pnpm install
pnpm dev

直接选择模板或模式

1
2
3
npx @agent-native/core@latest create my-app --template mail
npx @agent-native/core@latest create my-app --headless
npx @agent-native/core@latest create my-app --standalone

给现有 coding agent 加技能

1
npx @agent-native/core@latest skills add visual-plan

在 workspace 里新增应用

1
npx @agent-native/core@latest add-app notes --template content

部署多应用 workspace

1
npx @agent-native/core@latest deploy

一个 action 的示意写法

1
2
3
4
5
6
7
8
9
export default defineAction({
  schema: z.object({
    emailId: z.string(),
    body: z.string(),
  }),
  run: async ({ emailId, body }) => {
    await db.insert(replies).values({ emailId, body });
  },
});

这些命令和代码片段本身就能看出项目的风格：
不绕，不虚，不藏。
它更像把一串钥匙放在桌上，对你说：

门都在这儿。
你想先进哪一间，都可以。

写在最后

读完 BuilderIO 的 Agent-Native，我最大的感受不是“这个框架功能很多”，而是：

它在认真重写应用和智能体之间的关系。

在它描绘的世界里，Agent 不再只是聊天框里那个会说话的存在。
它会行动，会协作，会记忆，会调用，会计划，会交接，会跨应用联动，会和 UI 共用同一份能力系统，还可能随着时间推移帮应用变得更好。

而应用本身，也不再只是一个被手指点击的壳。
它开始像一座真正有生命流动的工作现场：

有人在里面操作，
Agent 在里面行动，
状态在里面同步，
能力在里面复用，
多个应用在里面协作，
未来在里面慢慢长出来。

如果说过去的软件更像一台机器，
那 Agent-Native 想推动的软件，更像一个会呼吸的组织体。

UI 是它的面孔。
Actions 是它的骨架。
Runtime 是它的神经。
Memory 是它的经验。
A2A 是它的社交能力。
Templates 是它已经长好的器官。
而 Agent，则像它刚刚苏醒的第二意识。

你不再只是“使用一个应用”。
你是在培养一个能和你一起工作的数字生命体。

这大概就是 BuilderIO Agent-Native 最迷人的地方。
它没有把 AI 摆在应用旁边。
它把 AI 请进了屋里，给了它工位、权限、职责和舞台。

然后轻声说了一句：

来吧，别只聊天了，开始一起工作。