「AI 原生」一词被用于指称大量彼此不同的做法。本文只讨论其中一处可检验的差别： 系统的数据来源是人工录入，还是系统自行获取。 这一处差别决定了资产管理系统的数据在三个月后仍然可用，还是需要第二次集中治理。
资产管理系统的实施结果高度一致：上线验收时数据完整，半年后开始出现无法解释的差异，一年后业务部门不再以系统数据作为判断依据。
对这一现象的常见归因是执行力不足——录入不及时、审核不严格、考核没跟上。这类归因在下一次实施中依然成立， 原因在于它没有触及真正的机制：系统的数据质量上限，由数据入口决定。
只要入口是人工录入，就会同时成立三件事：
依据：某集团 EAM 一期蓝图中的现状描述（数据「没有信息化手段」「靠纸质与邮件流转」）与实施复盘。见 docs/蓝图-某集团EAM资产管理.md。
把上述现象归为执行力问题，会导出一个隐含结论：只要管理更严格，问题就能解决。 但人工录入的成本不会因为管理严格而下降——它只会被转移到流程的其他环节，例如增加一次复核、增加一项考核。
因此这属于架构层面的问题：数据由谁产生、在何时产生、是否需要人工介入， 在设计阶段就已经确定，后续管理手段只能在其边界内微调。
资产管理系统普遍失败于同一原因：要求人工录入数据。 因此「AI 原生」如果是一个有实质内容的说法，它必须首先改变这一件事；在既有流程上增加一个对话入口，并不构成这一层面的变化。
更换数据入口，指系统通过统一的能力接口对外开放，使数据可以由系统自行获取，而不是等待人工填写。 在 EAMX 的实现中，这一层是动作契约（action registry）。
动作契约把系统的每一项业务能力定义为一条带类型、带权限、带审计的契约。 同一份契约同时投影为三种通道：
| 通道 | 使用者 | 特点 |
|---|---|---|
| Web 控制台 | 业务人员 | 按角色授权，操作路径固定 |
| 内嵌 AI 助手 | 对话式操作者 | 按当前登录身份授权，可自然语言触发 |
| MCP 工具 | 外部 AI 客户端 | 按接入凭证授权，可被企业既有的 AI 工具调用 |
口径：截至本文发布，动作契约共 247 条，覆盖 35 个业务域。演示账号可见的工具数由端点实时返回。该清单可实时导出并用演示环境核验。
企业内部的 AI 客户端数量在持续增加，业务系统的数量同样如此。 若采用点对点对接，M 个客户端与 N 个系统之间需要实现 M×N 次集成；每新增一方，工作量按乘法增长。
引入统一契约层后，两侧各自实现一次即可，集成工作量降为 M+N。 这一变化的实际意义已经超出开发量本身：它决定了一个企业能否让所有在用工具都接入，或只能挑选少数几个。
工具清单可由演示环境实时导出，无需申请。 查看核验方式 →
开放接口会引出一个必须正面回答的问题：外部 Agent 是否因此获得了绕过审批的能力。
EAMX 的处理方式是：所有通道都经过同一条执行管道（executeAction）。
权限判定、状态校验、审批校验、审计写入在执行管道内部完成，与调用方是 Web 控制台还是外部 Agent 无关。
因此「Agent 不绕过审批」并非一项约定，而是架构结果：它没有可以绕过的路径。 工具清单由服务端按账号权限生成，客户端拿到的清单即为服务端的授权结果， 前端不存在可绕过的调用路径；演示账号为全部试用权限，其清单覆盖站内所述的动作契约。
依据：executeAction 管道的七道环节与 CASL 同构权限设计；该账号可见工具数以系统实时返回为准。
讨论 AI 在资产管理系统中的作用时，能力清单通常被放在最前面。这个顺序值得调整： 对集团客户的评审而言，下述三类信息比能力清单更早被追问。
| 事项 | 说明 |
|---|---|
| 哪些动作不得自主执行 | 改账、报废、权限变更等高危动作在动作定义上标注 confirm，未携带确认一律拒绝执行 |
| 只读角色不可见什么 | 只读角色的工具清单不含写操作。边界由权限设计在清单生成时划定，不依靠调用时的拦截 |
| 不承诺什么 | 不承诺识别准确率 100%，不承诺完全无人值守。 |
「AI」在 EAMX 的对外表述中承担三种不同角色。混用会导致论述失去焦点，也会让读者无法判断所指的是哪一层。
只讲主张会显得空洞；只讲通道会把系统描述为「传统 EAM 加一个接入页」；只讲执行能力则会退回「把 AI 当作功能售卖」。
247 条动作契约、35 个业务域、该账号可见工具数由端点实时返回、统一执行管道—— 上述各项均无需采信本文陈述，可由演示环境自行核实。