人工智能可以帮你写一封电子邮件，但是它未必知道你在读哪一封电子邮件。

和人其中的差距不在于更加昂贵的模型，在于应用是否把眼前的工作上下文提供给模型。

BuilderIO的Agent-Native正好解决了这个问题，它是用TypeScript编写的框架，可以让智能体以及图形用户界面共享同一个应用程序的功能。

你可以让人工智能来做事情，也可以回到熟悉的操作界面上去查看、修改或者接替工作，并不需要把所有的操作都放到聊天框中去。

我认为它的最大价值在于没有把“人工智能操作软件”看作是“人工智能模仿人的点击按钮”。

别让人工智能绕着界面寻找入口

Agent-Native 最主要的部分就是 action，开发人员定义一次操作，界面从代码中调用它，智能体把它当作工具调用。

两边共用参数校验、权限验证以及业务实现，也可以用HTTP、MCP、A2A或者CLI的方式来提供调用途径，并不需要为每一个入口都去重写功能。

以官方最小示例来说明，在actions/hello.ts中用defineAction定义了一个打招呼的动作，description 描述用途，schema 验证姓名参数，run 返回问候语。

智能体有了一个叫作 hello 的工具，React 页面使用了 useActionQuery 来调用同样的操作，在这边的内容改变之后，那边也会跟着变化。

问候语没有实际意义，但是其中包含的限制却很有用。

假如“修改日程”的功能分别存在于界面和智能体两边的话，那么总有一天会遇到两边规则不一样的情况。

使用共享动作的好处就是可以少维护一套业务逻辑，并且减少绕过原有检查的路径。

但是共享权限检查并不等同于权限自动写对。

谁可以修改什么数据还是需要开发者来决定。

它得知道你说的“这个”是什么

仅仅会使用工具是不够的。

当用户选择了一部分内容并要求缩短时，或者在收到一封邮件之后希望得到回复的时候，如果没有智能体能够识别出被选取的内容或是收到的邮件的话，那么用户就需要不断地进行复制、粘贴以及补充背景的操作。

Agent-Native 将这些信息通过应用程序的状态来传播。

现在的页面、被打开的记录、被选中的对象等都可以成为智能体的上下文。

一个值得学习的地方就是官方建议的状态里只保留简单的语义信息以及稳定的标识，并不把整个文档以及所有的数据全部塞进去，然后用 view-screen 动作来获取相关的记录，并整理出当下工作场景的一个快照。

这就为“AI 解析界面”的另外一条途径打开了大门——即让应用程序自己去说明所要操作的对象是什么。

数据层也是如此，它也采用了相同的思路，即界面和智能体使用同一个动作来读取或者写入PostgreSQL，并且框架会将数据变更同步到界面中去。

当人工智能做出改变之后，并不只有一次“完成”的记录，在用户的实际工作中也会有所体现。

在聊天框旁边要有一个工作台

看下官方的 Readme 里展示的应用，就会知道其中的选择了。

Slides是用来制作、编辑演示文稿的，而Design则是用来生成、修改交互设计的。

二者本身都存在空间关系、布局以及视觉上的细节问题，仅仅从文字上回答是无法判断出好坏来的。

Analytics 将数据问答与仪表盘放在一起，Mail 主要讨论邮件的重要程度、草稿以及进展情况，而聊天的作用就是表达意图，界面则让用户可以看见结果并进行修改。

Calendar的日程安排功能，Clips中会议和录音的内容，Assets中的品牌素材，Content中的内容归档，Plans中的可视化的计划。

这是官方给出的起始点以及参考标准，并不代表装上框架之后就可以不用再进行配置而获得所有的功能。

我认为它更像是一个答案集：不同的工作需要不同的操作界面。

这就是我对于“智能体原生”的看法。

界面不一定要消逝，只需要不再负责所有的输入就可以了。

批量处理、表述模糊、需要理解意图的任务由智能体来做；准确调整、对比和确认的工作留给熟悉的人机交互方式。

观看官方演示视频

先做一件事情直到成功

可以先从官方的 Chat 模板入手来学习一下。

入门文档中提到需要使用 Node.js 22.22 及以上版本、pnpm，并且要有可用的模型连接。

官方命令如下：

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

cd my-app

corepack enable

pnpm install

pnpm dev用开发服务器提供的本地地址，并且选择 Continue as local dev 后再把模型连上，官方给的选择有 Builder.io、Anthropic、OpenAI API 以及本地的 Ollama 模型等。

接着依照入门文档中的指示让智能体调用 hello 动作，再增加一个调用同一动作的 React 页面。

在搞清楚了同一个动作有多种途径可以达到之后，在里面放入自家产品的相关工作内容。

这是官方的使用方法，并非本篇所指的本地测试结果，对于模型、数据库和其它外部服务的设置和费用问题，在框架开源之后也不能忽视。

本地开发用PGlite；官方规定生产或者多人共用的环境必须用持久化的PostgreSQL数据库，不可以把本地开发时使用的数据库直接作为生产环境使用；涉及到用户的查询时要正确地设置所有者和共享权限。

因此它更适合作为那些愿意去修改应用结构的开发者的工具，而不适合拿来安装一个插件之后就把整个老软件交给人工智能来管理的人。

Agent-Native并没有为模型解决所有的判断问题，它所做的就是将工作任务、业务行为以及操作界面三者联系起来，使智能体不需要在应用程序外胡乱猜测。

比起再添加一个可以对话的侧边栏来说，我觉得这样更好：人工智能做完之后留下痕迹，人们可以看到它是怎么变的，并且还可以继续做下去。

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