Agent-Native：真正重要的不是聊天框，而是应用动作层的治理

Agent-native 应用的关键不是把 AI 放进界面，而是重新定义应用动作的归属。过去一个功能先属于 UI，再被包装成 API，最后又被复制成 Agent tool。BuilderIO/agent-native 反过来：先定义 Action，再让 UI、Agent、HTTP、MCP、A2A、CLI 从同一个动作入口调用。

这个判断很重要。Agent 真进入产品后，最大风险不是模型不会说话，而是应用能力被拆成多套入口：按钮一套权限，API 一套校验，Agent 工具又一套参数。时间一长，谁改了数据、为什么改、用的是哪个规则，就会变得说不清。

Action-first 是治理问题

defineAction 看起来像一个开发便利设施，本质上是治理面。它让业务操作拥有统一 schema、统一 run context、统一审计机会和统一暴露策略。一个 action 可以选择给模型看，也可以只给前端用；可以通过 MCP 暴露，也可以要求认证或标记为 consequential。

这和传统“给 Agent 写 tools”不一样。工具不再是 prompt 边上的临时插件，而是应用能力的一种调用表面。对企业软件来说，这个边界更可信。

为什么它比普通 Copilot 组件更重

Copilot 组件强调交互层：聊天、生成 UI、共享状态、human-in-the-loop。Agent-Native 更靠近应用框架层：数据库、模板、actions、jobs、observability、A2A、MCP、skills、CLI、桌面和移动入口都在同一个仓库里。它不是给已有应用贴一个助手，而是在问：如果应用从第一天就预设 Agent 会参与操作，架构该怎么写。

这也是它的成本。团队不能只会接模型，还要理解状态、认证、权限、工具面、日志和评测。好处是这些复杂度本来就存在，框架只是把它提前摆到台面上。

采用建议

• 从 Headless 或 Chat 模板开始，不要一上来改复杂 Mail / Analytics 模板。
• 先把 3 到 5 个核心业务动作建成 Action，验证 UI 和 Agent 是否真的共用一套实现。
• 默认隐藏 UI-only action，减少模型工具列表；高风险 action 要确认、审计和最小权限。
• 把 MCP/A2A 暴露放到后面，先把本应用里的权限和 trace 跑通。
• 上线前建立 eval：至少覆盖关键 action、失败恢复、用户确认和数据边界。

结论

Agent-Native 代表的方向，比“AI 应用框架”这个标签更具体：应用动作要成为人和 Agent 的公共契约。谁能把 action、state、auth、observability 和 protocol surface 管住，谁才可能做出真正能长期运行的 agent-native 产品。