agent-native 的赌注：别再让你的 agent 点按钮
BuilderIO 的 agent-native 一天涨了 607 颗星到 5837，核心想法一句话就说完：agent 不点 UI，它走和 UI 同一条 action 层。MIT 协议，TypeScript，在 github.com/BuilderIO/agent-native。
机制是这样。每个能力你只定义一次，定义成一个 action。这一份定义随后会以五种形态出现：agent 的工具、UI 在代码里调用的 React 组件、HTTP 接口、MCP 接口、CLI 命令。他们的 hello world 例子字面意义上就是一个 action 长出五张脸。人能做的事 agent 都能做，走同一扇门，过同一套权限检查，而且两个面不可能漂移，因为压根只有一个面。
对比一下今天大多数 agent 应用是怎么干的。先做产品，然后把 agent 贴上去，要么给它一个浏览器让它自己找按钮，要么写第二套平行的工具定义去影射真实 API，然后在有人上新功能的那一刻开始腐烂。computer-use agent 之所以存在，正是因为软件是为眼睛和手造的。agent-native 的回答是，那就别再那样造软件。
框架剩下的部分是生产环境真需要、demo 框架通常给不了的无聊东西：PostgreSQL 后端、认证和权限、skills 和 memory、自动化、多 agent 团队。权限那块最值钱，因为共享 action 层意味着 agent 的权限和用户的权限定义在同一个地方，而不是「浏览器会话碰巧允许什么它就有什么」。
老实说的局限是，这套只对你从零写的、或者愿意重构的软件成立，而绝大多数软件不是。但趋势线很清楚，这是目前为止最干净的一件实物。把它、MCP、以及 agent 可读网页这一波放在一起，每个产品团队接下来要面对的问题不是要不要加 agent，而是自己的应用到底有没有一层 action，还是只有一堆把业务逻辑抹在里面的 React 组件。https://github.com/BuilderIO/agent-native
← 返回所有文章
机制是这样。每个能力你只定义一次，定义成一个 action。这一份定义随后会以五种形态出现：agent 的工具、UI 在代码里调用的 React 组件、HTTP 接口、MCP 接口、CLI 命令。他们的 hello world 例子字面意义上就是一个 action 长出五张脸。人能做的事 agent 都能做，走同一扇门，过同一套权限检查，而且两个面不可能漂移，因为压根只有一个面。
对比一下今天大多数 agent 应用是怎么干的。先做产品，然后把 agent 贴上去，要么给它一个浏览器让它自己找按钮，要么写第二套平行的工具定义去影射真实 API，然后在有人上新功能的那一刻开始腐烂。computer-use agent 之所以存在，正是因为软件是为眼睛和手造的。agent-native 的回答是，那就别再那样造软件。
框架剩下的部分是生产环境真需要、demo 框架通常给不了的无聊东西：PostgreSQL 后端、认证和权限、skills 和 memory、自动化、多 agent 团队。权限那块最值钱，因为共享 action 层意味着 agent 的权限和用户的权限定义在同一个地方，而不是「浏览器会话碰巧允许什么它就有什么」。
老实说的局限是，这套只对你从零写的、或者愿意重构的软件成立，而绝大多数软件不是。但趋势线很清楚，这是目前为止最干净的一件实物。把它、MCP、以及 agent 可读网页这一波放在一起，每个产品团队接下来要面对的问题不是要不要加 agent，而是自己的应用到底有没有一层 action，还是只有一堆把业务逻辑抹在里面的 React 组件。https://github.com/BuilderIO/agent-native
评论