agent-native NEW

agent-native 是什么？

agent-native 是 BuilderIO 开源的 TypeScript 框架，目标是让 Web 应用天然可被 AI Agent 理解和操控。随着越来越多用户通过智能体访问网页服务，传统为人类视线优化的界面在 Agent 眼里往往是一片噪声：语义靠猜、状态难同步、操作靠脆弱的选择器。agent-native 把「Agent 原生」变成前端的一等公民，让应用在服务人类用户的同时，也为机器访客提供结构化、可验证的交互面。它与 Builder.io 多年积累的可视化开发经验一脉相承，把「把界面描述清楚」这件事从可视化编辑延伸到了 Agent 会话层，适合想让自己的产品接入 Agent 生态的前端团队与平台工程师。

核心功能

• Agent 可读界面：为页面元素补充结构化语义，让智能体无需依赖像素猜测即可定位区域、理解状态。
• 可控操作面：把表单、按钮、导航等交互暴露为 Agent 可调用的规范动作，降低误触与歧义。
• TypeScript 原生集成：以框架友好的方式接入现有前端项目，不要求推倒重写页面。
• 渐进式升级：可以从单个页面、单个组件开始试点，再逐步扩展到整站改造。
• 工具链协同：与 Builder.io 的可视化生态互补，团队可在同一套组件体系里同时服务人与 Agent。

版本/套餐对比

agent-native 是开源项目，仓库代码免费可用，没有商业套餐之分，区别主要体现在使用方式上：直接在自有项目里引入框架，适合有前端工程能力的团队，成本几乎为零，但适配与维护要自己承担；借助 Builder.io 周边工具链一起使用，适合希望在可视化环境里管理界面与 Agent 语义的团队，上手更快，但会贴近其平台的使用习惯；第三种是观望与试点，先在小范围内部工具上验证 Agent 访问的价值，再决定是否推广到核心产品。三种路径并不冲突，多数团队的合理节奏是从试点走向深度集成，而不是一次性全站铺开。

值不值得用？

值不值得引入，取决于你的产品会不会被 Agent 访问。电商、SaaS、内容平台这类高频被智能体检索、代操作的场景，Agent 原生界面的回报会越来越明显：用户可能不再亲手打开你的页面，而是让智能体替他完成下单、查单与配置，如果此时你的界面语义不友好，流量与转化就会悄悄流向对 Agent 更友好的竞品。反过来，纯移动 App、内部离线工具，或者用户几乎不会通过智能体触达的产品，收益有限，不必跟风。框架本身是 TypeScript 实现，对主流前端团队学习成本不高，试错代价低，这也是它值得先试一手的原因。

使用建议

• 先盘点产品里最可能被 Agent 调用的高频流程，比如查询、下单、预约，只对这些页面做 Agent 原生改造，避免一上来全站铺开。
• 把语义标注和操作面定义纳入组件库规范，让新组件默认携带 Agent 可读信息，避免后期补课。
• 用真实智能体反复测试改造后的页面，观察其能否正确完成端到端任务，而不是只看文档自我感觉良好。
• 关注上游仓库的迭代节奏，Agent 交互相关约定仍在演进，锁定版本并安排定期升级，防止语义层漂移。

适合谁用？

推荐使用：有稳定 Web 产品、希望被 Agent 生态顺畅访问的 SaaS 与电商平台；维护多页面复杂前端、想减少智能体误操作的前端团队。

可以考虑：正在做内部工具 Agent 化的企业开发者，先用它统一内部页面的 Agent 语义与操作规范。

不推荐：纯移动端 App 团队、没有前端工程能力的小型站点，以及短期内不关心 Agent 流量的产品，引入框架只会增加维护负担。