仓库：BuilderIO/agent-native 作者：Builder.io 语言：TypeScript 许可：README 与核心 package.json 均声明 MIT；根目录独立许可文件情况另行核对，不能用 GitHub 的 null 分类推导“不是 MIT”。 站点：agent-native.com
「这是什么」一句话定性
一个把 Agent 作为应用入口之一的框架。最值得学的不是聊天框，而是把业务动作、参数校验和权限边界收在一处，让 UI 和 Agent 调用同一套实现。
比如“创建工单”：按钮和自然语言入口不该各写一份不同的权限逻辑。共享 action 可以降低分叉，但是否真做到一致，还要看你的 action 实现和各入口认证。
「它怎么转」逻辑全景图
官方 README用 defineAction 定义输入、权限与实现，再暴露给 UI、Agent、HTTP API、MCP、A2A 和 CLI。不是每个入口都可以跳过身份检查，更不是“声明了 schema 就不会误操作”。
用户/Agent/外部客户端
↓
入口认证与调用上下文
↓
共享 action：输入校验 → 权限判断 → 业务实现
↓
结果/错误 → 日志与业务验收
当前文档区分本地 PGlite 与生产 PostgreSQL 路径，不把“用了 Drizzle”外推成任意数据库随便替换。运行框架、模型连接、业务数据与执行工具也要分别配置。
「怎么升级」三段位路线图
| 段位 | 掌握目标 | 动作 |
|---|---|---|
| 入门 | 建最小应用、读清 action | 按脚手架建 chat 示例，先接一个低风险只读动作 |
| 进阶 | 检查入口一致性 | 用相同身份/参数测试 UI、Agent 与 API 的允许/拒绝行为 |
| 高手 | 集成业务与治理 | 补幂等、审计、确认、速率限制、部署及迁移测试 |
当前 README 的独立应用命令：
npx --yes @agent-native/core@latest create my-agent --standalone --template chat
这是文档入口，不是本次运行验证。@latest 会随时间改变，正式试点应记录安装版本和依赖锁。旧文的 skills 简写命令没有在本次读取的入口中得到确认，因此不再列为可直接运行的步骤。
「能用在哪」场景迁移
场景 1：企业内部管理系统
订单查询、工单分派、报表筛选很适合从共享 action 开始。新增 Agent 入口时保留原有数据权限；付款、删除、发信等不可逆动作加确认和幂等，不因为自然语言更方便就扩大可操作范围。
场景 2：SaaS 的“AI 增值功能”
Agent 可以调用已有业务能力，而不只是回答帮助文档。收益是复用与一致性，不是自动兑现转化率、付费率或人工成本下降。应先做真实任务完成率和误操作评估。
场景 3：AI 编程工作流
可以研究把工具能力接入不同客户端的方式。第三方 action、MCP 和模型供应商仍是独立信任边界；API 兼容不等于身份、模型质量或服务条款也兼容。
部署这个项目的收益 & 风险
收益：共享校验、权限和业务实现的方向是合理的，尤其能减少 UI 与工具接口长期维护时的重复。
许可核对：README与核心 package.json都声明 MIT。根目录没有独立 LICENSE 文件与 GitHub API 不识别，是文件/机器分类层面的观察，不足以推翻已有声明；分发采用前应保留适用许可说明，并核对具体包、第三方组件和模型服务条件。
工程边界：框架不会替你完成认证、租户隔离、备份或迁移。商业公司维护也不保证项目永远继续，不能用 stars、提交量或公司身份代替维护与兼容性评估。
数据边界：接远端模型时，提示词、action 参数和结果可能离开部署环境。先检查字段最小化、日志保留和工具执行权限，不把“Agent 原生”当安全认证。
一句话灵魂
让人和 Agent 使用同一套可审查业务动作，是我认为最有价值的部分；入口变多了，权限与验收不能变松。
资料核对：2026-10-13，读取官方 README、核心包清单与根目录清单；未生成或运行应用，未验证各入口权限一致性或生产效果。