企业每引入一个 AI 客户端，都要与每一个业务系统分别商定一次接入。M 个客户端与 N 个业务系统之间， 需要处理的集成关系为 M×N；引入统一契约层之后降为 M+N。 这一变化的意义不在于节省多少开发工时，而在于它决定了企业能否让所有在用的 AI 工具都具备操作能力， 还是只能从中挑选少数几个。
企业在评估 AI 客户端时，通常把成本分为三类：模型调用费用、席位许可费用、实施服务费用。 这三类都会写进预算表。未被列入的是第四类——使 AI 客户端能够操作贵方业务系统所需的工作量。 在立项文件中，它常被记为「系统对接」一行。
这一项之所以被低估，与它的增长形态有关。模型调用费用随使用量增长，席位费用随人数增长， 两者都是线性的；接入工作量随 AI 客户端数量与业务系统数量的乘积增长。
当企业只在用的 AI 客户端为单一类型时，乘法与加法没有区别。实际情形通常并非如此： 办公侧的智能体平台、研发侧的编码助手、业务部门自行接入的对话工具、以及各系统厂商自带的助手， 往往同时在用。此时乘法开始生效，且每一项新出现的工具都会再次触发一轮集成。
更值得注意的是工作量的分布，而非总量。M×N 组集成关系不会平均落在各个项目上， 而是集中在信息中心：业务部门每引入一个 AI 工具，都会向信息中心提出一次接入需求。 信息中心由此成为全部集成关系的汇聚点，其人力上限直接决定了企业能够接入多少工具。
依据：某集团 EAM 一期蓝图（2024）中的数据与流程现状描述（数据「没有信息化手段」「靠纸质与邮件流转」）；EAMX 动作契约与权限设计的内部实现记录。
点对点对接的实际内容并非「打开一个接口」，而是客户端与业务系统就下列六类事项逐项达成一致。 六类事项中没有一项在技术上困难，困难在于它们需要在每一组关系上各做一次。
| 事项 | 每一次集成需要重新确定的内容 |
|---|---|
| 身份认证 | 客户端如何证明调用者身份。API Key、OAuth 授权、服务账号三种方式在各系统间选型不一 |
| 权限映射 | 业务系统内的角色如何映射到客户端的使用者，映射表由哪一侧维护、何时复核 |
| 字段对齐 | 资产编号规则、状态枚举取值、组织编码层级在两侧的定义差异 |
| 异常处理 | 业务系统返回错误时，客户端应当重试、终止，还是转为人工处理 |
| 审计留痕 | 操作记录写入哪一侧，两侧记录口径能否对齐，事后由谁出示 |
| 版本演进 | 任一侧接口变更时，另一侧由谁负责适配，变更窗口如何约定 |
六类事项中，权限语义最难在事后统一。同一次「修改资产状态」操作， 经由客户端 A 发起时经过审批，经由客户端 B 发起时由持有数据库直连权限的账号完成； 审计记录中无法分辨操作主体，也无法证明该操作曾经进入审批环节。
这类情况不属于安全策略配置失误，而属于集成方式本身没有留下统一的执行入口。 只要接口按需逐项开通，权限与审计的口径就会随开通方式发生偏移，且偏移量随集成数量增长。
上述六类事项提取自 EAMX 在客户现场处理过的接入需求；权限语义的表述依据 CASL 同构权限设计与统一执行管道的实现记录。
统一契约层指把业务系统对外提供的能力定义为一份带类型、带权限、带审计的清单，
客户端不再与各个系统逐一协商接口，而是向这份清单调用。在 EAMX 的实现中，该层为
动作契约（actionRegistry）。
该设计的关键在于：actionRegistry 是唯一的操作面。
系统内不存在分别面向 Web 控制台、内嵌助手与外部 Agent 的三套接口，
247 条动作契约同时支撑三种调用通道。
所有调用统一进入一条执行管道 executeAction，依次经过七道环节：
参数校验 → 权限裁决 → 预演 → 人工确认 →
幂等键 → 执行 → 审计。
权限裁决与 Web 控制台使用同一套 CASL 规则、同一套五个维度的数据范围。
因此不存在「AI 可改、人工不可改」的情形，也不存在两套权限口径。
管道中的两项机制值得单独说明。预演（dryRun）在执行前返回将要发生的结果，
本身不产生任何写入，使审批人看到的是预演结果而非自然语言描述；
高危动作在动作定义上标注 confirm，未携带确认一律拒绝执行。
这两项共同构成了外部 Agent 写入前的强制暴露环节。
同一份动作契约同时投影为三条通道。三条通道的身份来源不同， 但权限裁决、执行管道与审计口径完全一致——这一点决定了「统一契约层」是否成立。
| 通道 | 使用者 | 身份来源 | 对本方的含义 |
|---|---|---|---|
| Web 控制台 | 业务人员 | 登录会话 |
按角色授权，操作路径固定；AI 能力上线不影响既有界面操作 |
| 内嵌 AI 助手 | 系统内的对话式操作 | 请求级上下文 |
按当前登录身份授权，可自然语言触发；无需另建一套「AI 功能」 |
| MCP 工具 | 外部 AI 客户端 | API Key |
按接入凭证授权，可由企业既有 AI 工具调用；不限于厂商自带助手 |
第三条通道的可见范围可当场核对：登录页内演示账号即可导出工具清单，覆盖 35 个业务域， 与站内所述的动作契约总数逐项比对。清单本身可实时导出，无需申请即可调阅。
口径：截至本文发布，动作契约共 247 条，覆盖 35 个业务域；演示账号可见的工具由端点实时返回。三项均可由演示环境实时导出核验。
工具清单无需采信本文陈述：以演示账号接入无需申请的演示端点，由贵方 AI 助手自行报出工具数量与业务域覆盖。 查看核验方式 →
引入统一契约层之后，集成工作量由 M×N 降为 M+N： 每个 AI 客户端只需实现一次标准协议，业务系统只需发布一次服务端点。 新增客户端不触发业务系统改造，新增业务系统不触发客户端改造。
第一层意义是工程成本。第二层意义更重要：它决定企业能否让所有在用的 AI 工具都接入， 还是只能从中挑选少数几个。
在 M×N 的模式下，接入决策被迫成为排序决策：先接哪一个客户端、先接哪几个业务系统， 其余一律搁置。搁置的结果可以预期——被搁置的通常恰好是需要现场使用的那些工具， 因为它们分散、数量多，单个接入所显现的价值不高，在排序中天然靠后。
在 M+N 的模式下，接入的边际成本不再与业务系统数量相关。企业可以按使用需求接入，而不必按集成预算排序。 由此产生的差异不在单个集成的质量，而在覆盖范围：是全部在用工具都具备操作资产数据的能力， 还是只有一两个具备。前者改变了信息中心与业务部门协作的方式，后者只是增加了一个可用入口。
需要说明的是，M+N 并不降低单次接入在安全一侧的要求，只是改变了这些要求的位置： 权限、审批、幂等与审计由契约层一次性承担，不再由每一组集成各自重复实现。
统一契约层对客户端提出的要求低于点对点对接。任何实现 MCP 协议（Streamable HTTP 传输）的客户端均可接入，
接入配置为四项：名称、传输协议、端点地址、认证方式。无需为业务系统单独开发插件，
也无需在客户端一侧重复实现业务逻辑。
| 条件 | 说明 |
|---|---|
| 实现标准协议 | 客户端支持 MCP 协议与 Streamable HTTP 传输，无需为对接单独定制适配层 |
| 使用签发凭证接入 | API Key 在 EAMX 后台按角色签发，权限随凭证走；集团可见全域，子公司只见本单位 |
| 接受统一执行管道 | 写操作在 confirm 确认后执行，不接受绕过管道的直连方式 |
| 接受统一审计口径 | 操作记录与人工操作同一口径，可按通道、身份、动作、参数与结果回溯 |
以下三项约束属架构设计结果，不属于可协商的配置项：
confirm，未携带确认一律拒绝执行；人在环因此是接口层的强约束，而非操作规范。上述条件的适用范围限于资产事务这一层。本系统处于实物过程层，通过集成接口与 ERP、MES 等系统对接， 不替代 ERP 的财务账；Agent 操作的对象是资产事务。
依据：executeAction 管道的七道环节与 CASL 同构权限设计；工具清单由服务端按账号权限生成，演示账号为全部试用权限，其清单覆盖全部动作。
247 条动作契约、35 个业务域、该账号可见工具数由端点实时返回、统一执行管道七道环节—— 上述各项均无需采信本文陈述，可由演示环境自行核实。