此类情况在信息中心正在真实发生，且呈加速趋势。
当前企业内同时在用的 AI 客户端不止一个：办公侧的智能体平台、研发侧的编码助手、 自研的行业 Agent，以及各业务部门自行接入的对话机器人。它们都需要操作业务系统—— 而非仅查询一个 API。
传统做法是逐个对接：M 个客户端 × N 个业务系统 = M × N 次集成。 每一次集成都要重新处理身份认证、权限映射、字段对齐、异常处理、审计留痕。 集成数量随客户端增加呈平方增长，而每一个接口都是一份需要长期维护的技术债。
更为关键的是权限语义无法统一：同一次"修改资产状态"操作，在客户端 A 中经过审批， 在客户端 B 中则由直连数据库绕过——审计层面无法判断操作主体。
客户端只需实现一次 MCP 协议；业务系统只需发布一次 MCP Server。 新增任意一个客户端，不变更业务系统； 新增任意一个业务系统，不重启已有客户端。
对信息中心而言，AI 落地的瓶颈已不在模型能力，而在业务系统能否被 Agent 安全地调用。 MCP 将这一环节从"每个项目做一次"变为"平台做一次"。
系统中不存在"给 Web 用的接口"与"给 AI 用的接口"之分——
actionRegistry 是唯一的操作面，247 个动作同时支撑三种通道。
| 通道 | 谁在操作 | 身份来源 | 对本方的实际含义 |
|---|---|---|---|
| ① Web 控制台 | 业务人员 | cookie JWT |
传统界面操作照常，不受 AI 能力上线影响。 |
| ② 内嵌 AI 助手 | 系统内的对话式操作 | 请求级上下文 |
同一批动作，换对话方式使用，不必重新开发一套 AI 功能。 |
| ③ MCP Server | 外部 Agent WorkBuddy / Claude Desktop / Cursor / 自研 |
API Key |
将系统能力开放给企业自身的 Agent 生态，而非限定于厂商自带的助手。 |
如果 AI 能力只能通过厂商自带的助手使用，那么"AI 原生"就只是一个功能； 当任意 Agent 都能通过标准协议操作同一批动作，它才变成一种架构。 区别在于：前者你要迁就厂商，后者你用自己的 Agent 生态。
AI 原生并非第六个能力柱，而是横切在五柱与五阶段之上的第二条轴—— 每一个能力都可以被三条通道中的任意一条触达。
| 业务轴（管什么） | ① Web 控制台 | ② 内嵌 AI 助手 | ③ MCP 外部 Agent |
|---|---|---|---|
| 看得见 · 集团资产全景 | ✓ | ✓ | ✓ |
| 调得动 · 闲置与共享调剂 | ✓ | ✓ | ✓ |
| 买得准 · 预算与重复购置 | ✓ | ✓ | ✓ |
| 算得清 · 成本核算 TCO | ✓ | ✓ | ✓ |
| 跑得顺 · 流程监控 | ✓ | ✓ | ✓ |
| ② 取得与立卡 | ✓ | ✓ | ✓ |
| ③ 使用与运维 | ✓ | ✓ | ✓ |
| 底座 · 资产主数据与卡片 | ✓ | ✓ | ✓ |
本部分最应接受质疑，也最便于验证。 所有写操作——无论来自哪条通道——均须经过同一道管道。
zod 校验 ·
CASL 裁决 ·
dryRun 预演 ·
confirm 确认 ·
idempotencyKey ·
audit
| 机制 | 它做什么 | 所以对你意味着什么 |
|---|---|---|
统一执行管道 |
写操作只有一个入口，任何通道都无法绕过。 | Agent 不取得特权。人工操作须经审批，Agent 操作同样须经审批，二者通过同一道闸门。 |
CASL 权限裁决 |
按角色与五维度数据范围裁决，与 Web 端同一套规则。 | 不会出现"AI 可改、人工不可改"或相反情况。权限即契约，不存在第二套口径。 |
dryRun 预演 |
执行前返回将要发生什么，不产生任何写入。 | 可让 Agent 先"试算"再执行，审批人看到的是预演结果而非口头描述。 |
confirm 确认 |
高危动作在动作定义上标注，未携带确认一律拒绝。 | 人在环并非宣传语，而是接口层的强约束。Agent 如需改账或报废，必须经人工确认。 |
幂等键 |
同一次调用重复提交只生效一次。 | Agent 重试、网络抖动不会造成重复入账——此即 AI 操作企业系统最常见的风险点。 |
审计留痕 |
记录通道、身份、动作、参数、结果。 | 事后可回答"该条资产状态由谁、在何时、通过哪条通道修改"，包括 Agent。 |
"AI 操作系统"的真正门槛并非模型能力，而在于权限与审计能否保持同一套口径。 若一个 Agent 能绕过审批直连数据库，则不属于 AI 原生，而属于后门。
EAMX 已作为 MCP Server 运行。在客户端的连接器管理中填入地址即可， 无需在 Agent 侧重复搭建业务系统，也无需为其单独开发插件。
| 名称 | EAMX 资产管理 |
| 传输协议 | Streamable HTTP |
| URL | https://app.eamx.com.cn/mcp |
| 认证 | Authorization: Bearer <API Key> |
仅上述四项。API Key 在 app.eamx.com.cn 后台按角色签发，权限随 Key 走；演示账号页内公开，无需申请。
任何实现 MCP 协议的客户端均可接入。已验证：
协议为标准协议，新增客户端无需 EAMX 侧做任何改造—— 此即 M+N 与 M×N 的区别。
能力边界在接口层即已确定，不依赖 Agent 的自觉。
| 动作类型 | Agent 可达性 | 说明 |
|---|---|---|
| 查询与读 | ✓ 可读 | 台账、状态、工单、报表数据。该账号为全部试用权限，可见工具数与动作契约总数一致。 |
| 预演 | ✓ 可用 | dryRun 只返回将要发生什么，不写入。 |
| 常规写入 | ✓ 需确认 | 经 confirm 确认后执行，与人工操作同一管道。 |
| 高危动作 改账、报废、权限变更 |
✓ 需人工确认 | 动作定义中已固定，未携带确认一律拒绝。 |
| 演示账号 | ✓ 全部试用权限 | 可调用全部 247 个动作；其中标注 confirm 的高风险动作须经人工确认方会执行。 |
常见的说法是"本方不存在权限问题"。更可验证的表述为： 用页内演示账号接入 MCP，核验工具清单与业务域覆盖。 权限判定与确认要求均由服务端在执行前完成，客户端拿到的清单与可执行范围即为服务端的裁决结果。
演示环境页内公开演示账号。 将贵方 AI 助手接入，由其自行报出工具清单与业务域覆盖，与本站所述逐项比对。
三步验证动线：① 用页内演示账号登录 app.eamx.com.cn → ② 填入贵方 MCP 客户端 → ③ 让 Agent 列出工具清单并对齐业务域。 领取步骤见 在线试用 MCP。
所有写操作必须经统一管道：参数校验 → 权限裁决 → 预演 → 人工确认 → 幂等 → 审计。 高危动作在动作定义中已固定，未携带确认一律拒绝执行。Agent 无法跳过任何环节。
与 Web 端同一套 CASL 规则、同一套五维度数据隔离。 API Key 按角色签发，权限随 Key 走。集团可见全域，子公司只见本单位。
可以，且口径与人工操作一致。审计记录通道、身份、动作、参数与结果—— 可回答"该条资产状态由谁、在何时、通过哪条通道修改"，包括 Agent 代操作。
本系统处于实物过程这一层，通过集成接口与 ERP、MES 等系统对接。 Agent 操作的是资产事务，不替代 ERP 的财务账。