AI 原生指以人工智能为系统的底层架构与能力中枢，而非在既有系统上外挂 AI 功能。落到资产领域，最先被触动的是数据入口—— 资产管理系统普遍失败于同一原因：它要求人工录入数据。交付时数据完整录入，三个月后开始失真，一年后系统数据不再被采信。 这不属于执行层面的问题，而属于架构层面的问题——人是最不可靠的数据源。
「AI 原生」一词已被过度使用。多数情况下，它仅指在既有流程上叠加一个对话框，使用户以自然语言操作原有的按钮。 这种做法有一项前提并未改变：数据仍依赖人工录入。对话框只是把「点击按钮」换成了「输入文字」，录入、核对与纠错的负担并未减少。
实质变化发生在数据来源上。当系统通过统一的动作契约对外开放，Agent 可自动获取数据、自动执行动作， 「人工录入数据」这一环节才第一次具备替代方案。随之而来的，是一组可被量化、可被质疑的工程问题：
M 个 AI 客户端 × N 个业务系统，点对点对接需完成 M×N 次。引入统一契约层后，两边各自实现一次即可。
这是架构层面的收益，而非功能层面的。它决定了企业内日常使用的 AI 工具能否接入。
外部 Agent 与 Web 控制台走同一条执行管道（executeAction），权限判定与审计记录不分叉。
「不绕过审批、不获得特权」必须由架构保证，不能依赖约定。
哪些动作 Agent 永远不得自行决定、发生错误时如何收口、人如何得知其发生错误——这些问题比「AI 能做什么」更应优先说明。
一个只陈述能力、不界定边界的 AI 叙事，在集团客户的评审会上经不起一句追问。
建议按顺序阅读：先接受主张，再了解集成与边界，最后落到具体实现与路线。
本专题回答「为什么」，下列各页回答「是什么、如何使用」。两者是同一件事的两个层面。
品类定义页。回答「为什么必须是 AI 原生，而非在既有系统上增加一个 AI 助手」。
这是全站的主张层页面。
动作契约层 actionRegistry 是唯一操作面；247 个动作同时投影为 Web 控制台、内嵌 AI 助手与 MCP 工具。
这是全站的通道轴——回答「谁在操作系统」。
无需采信本专题的任何陈述：使用演示环境，由贵方自己的 AI 核验其可见的工具数量。
将主张转化为可当场核验的事实。
AI 在 EAMX 中有三种身份，不可混同： ① 品类主张（为什么必须是 AI 原生，见 /why-ai-native/）、 ② 通道与技术（谁在操作系统、如何接入，见 /product/agent-access/）、 ③ 执行者（四个 AI Agent，在各业务阶段内部执行具体动作）。 仅陈述主张会流于空洞，仅陈述通道会近似于「传统 EAM + 一个 MCP 页」，仅陈述 Agent 功能则会退回「把 AI 当功能销售」。
AI 原生回答「数据从何而来」，其余专题回答「数据如何使用、依据何种规则使用」。
「247 个动作契约」「只读角色可见的工具清单由端点实时返回」「Agent 走同一条执行管道」—— 上述各项均无需采信，仅需连接一次演示环境即可核验。