【FDE前沿部署工程师实战教程】52 | Enterprise AI Integration：构建企业 AI 与 ERP、WMS、MES、CRM 的统一集成架构

最新推荐文章于 2026-10-28 14:41:43 发布

原创最新推荐文章于 2026-10-28 14:41:43 发布 · 385 阅读

3 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

收录于

FDE前沿部署工程师实战教程

本文系统阐述企业AI集成的核心架构与工程实践，聚焦AI与ERP、WMS、MES、CRM等核心业务系统的安全、可靠、可观测集成。内容涵盖六大设计原则（如AI不直连数据库、读写分离、统一语义、可观测性、版本演进）、四种集成模式（同步API、事件驱动、RAG+数据平台、MCP+Tool Adapter）、统一业务适配层、跨系统编排与Saga补偿机制、六层安全架构（身份认证、工具授权、数据范围控制、业务规则、人工审批、审计追踪），以及幂等设计、异常处理与实施路线图，强调从技术调用成功到业务结果成功的本质跃迁。

一、为什么企业 AI 必须解决系统集成问题？

在企业 AI 项目中，一个常见误区是：只要接入大模型、配置好 Prompt，再开发一个 Agent，就能让 AI 真正参与企业业务。

但在实际落地中，企业业务往往分布在多个独立系统中。

例如，一家制造企业可能同时使用：

ERP：管理采购、销售、财务、物料和生产计划。
WMS：管理库存、库位、入库、出库和仓储作业。
MES：管理生产工单、工序执行、设备状态和生产追溯。
CRM：管理客户、商机、订单需求和客户服务。
HRM：管理员工、组织、岗位、考勤和薪酬。
PLM：管理产品设计、物料结构和工程变更。
数据平台：提供经营指标、历史数据和分析报表。

当企业引入 AI 后，用户可能提出这样的业务请求：

分析本周的订单交付风险，结合当前库存、生产进度和采购到货情况，给出调整建议；如果需要补货，生成采购申请草稿并提交审批。

这个请求并不是一个简单的问答任务。

AI 需要完成一系列跨系统操作：

从 ERP 获取订单、交付日期和物料需求。
从 WMS 获取可用库存、冻结库存和在途库存。
从 MES 获取生产工单、完工数量和工序进度。
从采购系统获取采购订单与预计到货时间。
综合分析订单延期风险。
根据业务规则生成调整建议。
必要时创建采购申请草稿。
校验权限、金额、物料和审批规则。
将需要人工确认的操作提交审批。
记录执行结果并向用户返回业务报告。

如果每个 Agent 都直接连接不同业务系统，就容易出现接口重复建设、权限控制不一致、数据口径冲突、异常难以追踪等问题。

因此，企业 AI 落地不仅需要模型能力、Agent 能力和治理能力，还需要一套统一的企业 AI 集成架构（Enterprise AI Integration Architecture）。

本章将围绕这一主题，介绍如何将 AI 与 ERP、WMS、MES、CRM 等企业系统连接起来，构建可治理、可扩展、可审计的业务集成体系。

二、什么是 Enterprise AI Integration？

Enterprise AI Integration 是指通过统一的接口、协议、数据访问、业务工具和安全控制机制，将大模型、Agent、Workflow 与企业现有业务系统连接起来，使 AI 能够在受控条件下读取业务数据、调用业务能力、执行经过授权的操作，并将执行结果反馈给用户或其他业务系统。

它不是简单地为大模型增加几个 API，而是建立一套可复用的企业集成能力。

2.1 传统系统集成与 AI 集成的区别

对比维度	传统系统集成	企业 AI 集成
触发方式	定时任务、事件、固定业务流程	用户自然语言、事件、工作流或 Agent
执行路径	通常由预先定义的程序控制	可由模型辅助规划，但必须受到规则约束
数据访问	固定查询与接口调用	结合上下文、检索和授权工具访问
业务逻辑	主要由代码和规则实现	模型负责理解与建议，确定性服务负责关键业务判断
接口参数	通常由程序构造	模型可能生成参数，需要严格校验
权限管理	系统账号、角色和接口权限	还需要用户身份传递、数据范围与 Agent 工具权限控制
异常处理	错误码、重试、补偿事务	还要防止模型误判、重复调用和错误恢复
结果判断	接口成功或业务状态完成	需要进一步验证真实业务结果
审计要求	记录接口与业务操作	还应记录 Agent 决策、工具调用、审批和结果验证

这里有一个关键区别：

传统集成关注系统之间如何交换数据，企业 AI 集成还必须解决 AI 如何安全、正确地使用这些数据和业务能力。

例如，ERP 接口返回 HTTP 200，只能说明接口请求成功，不一定意味着采购申请已经成功创建，更不意味着采购申请已经通过审批。

AI 集成必须区分：

技术调用成功。
业务操作执行成功。
业务状态达到预期。
整个用户任务完成。

这也是企业 AI 从演示原型走向生产系统时必须解决的问题。

三、企业 AI 集成的总体架构

企业 AI 集成应当建立在上一章企业 AI 平台的基础上。

AI 平台提供模型、Agent Runtime、Workflow、RAG、治理和评估能力；企业集成层负责连接 ERP、WMS、MES、CRM 等系统，并将这些系统的能力封装成 AI 可以安全使用的业务工具。

┌──────────────────────────────────────────────────────────────────────┐
│                         企业业务入口层                               │
│          Web 工作台 / 企业门户 / 移动端 / 业务系统 / API              │
└───────────────────────────────┬──────────────────────────────────────┘
                                ▼
┌──────────────────────────────────────────────────────────────────────┐
│                         AI 应用与编排层                              │
│                                                                      │
│     AI 应用        Agent Runtime       Workflow       Multi-Agent    │
│                                                                      │
│  负责：意图理解、任务规划、流程编排、上下文管理、结果汇总            │
└───────────────────────────────┬──────────────────────────────────────┘
                                ▼
┌──────────────────────────────────────────────────────────────────────┐
│                         统一 AI 集成层                               │
│                                                                      │
│  Tool Registry │ API Gateway │ MCP Adapter │ Workflow Connector     │
│                                                                      │
│  身份传递 │ 参数校验 │ 权限校验 │ 限流熔断 │ 超时重试 │ 结果标准化    │
└───────────────────────────────┬──────────────────────────────────────┘
                                ▼
┌──────────────────────────────────────────────────────────────────────┐
│                       企业业务能力适配层                             │
│                                                                      │
│  订单服务 │ 库存服务 │ 生产服务 │ 采购服务 │ 客户服务 │ 人事服务      │
│                                                                      │
│       统一业务语义、统一参数模型、统一错误模型、统一审计              │
└───────────┬───────────┬───────────┬───────────┬──────────────────────┘
            ▼           ▼           ▼           ▼
         ┌──────┐    ┌──────┐    ┌──────┐    ┌──────┐
         │ ERP  │    │ WMS  │    │ MES  │    │ CRM  │
         └──────┘    └──────┘    └──────┘    └──────┘
            │           │           │           │
            └───────────┴─────┬─────┴───────────┘
                              ▼
┌──────────────────────────────────────────────────────────────────────┐
│                         集成基础设施层                               │
│                                                                      │
│ API / 消息总线 / CDC / 数据同步 / 事件订阅 / 监控告警 / 审计存储     │
└──────────────────────────────────────────────────────────────────────┘

贯穿所有层：身份认证、数据权限、业务规则、风险控制、人工审批与审计

3.1 为什么要设置独立的 AI 集成层？

一种看似简单的实现方式，是让每个 Agent 直接调用每个业务系统的 API。

例如：

库存 Agent ──────> WMS API
库存 Agent ──────> ERP API

订单 Agent ──────> ERP API
订单 Agent ──────> CRM API

生产 Agent ──────> MES API
生产 Agent ──────> ERP API

当 Agent 数量和业务系统不断增加时，集成关系会迅速膨胀。

假设有 $N$ 个 Agent 和 $M$ 个业务系统，如果每个 Agent 都需要独立适配所有系统，潜在的适配关系最多可能达到：

\[ N \times M \]

如果将重复的业务能力抽取到统一集成层，Agent 只需调用标准化业务工具，系统适配由集成层集中维护。

库存 Agent ──┐
订单 Agent ──┼──> 统一业务工具 ──> 企业集成适配器 ──> 业务系统
生产 Agent ──┘

这种设计能够降低重复开发成本，但并不意味着所有系统都必须经过同一个物理网关。高吞吐量业务、低延迟场景和已有集成平台可以保留独立链路，只要遵守统一的接口、安全和审计标准。

四、企业 AI 集成的六个核心设计原则

4.1 原则一：AI 不直接访问业务数据库

生产环境中，不应默认允许 Agent 直接连接 ERP、WMS、MES 的生产数据库并执行任意 SQL。

主要原因包括：

可能绕过原有业务规则。
容易暴露超出当前任务所需的数据。
不同系统的数据库结构与业务含义可能不一致。
写操作可能破坏事务完整性。
数据库结构调整会导致 Agent 集成失效。

推荐优先级如下：

官方业务 API。
企业服务层或领域服务。
经授权的只读查询服务。
CDC、数据仓库或分析平台，用于适合的分析场景。
经过严格审批和隔离的特殊数据访问方式。

例如，查询库存时，优先调用：

GET /api/v1/inventory/availability?materialCode=MAT-001&warehouseCode=WH-01

而不是让模型自行生成 SQL 查询生产数据库。

4.2 原则二：AI 负责理解与建议，业务系统负责最终业务事实

AI 可以推断某个订单可能延期，也可以建议调整生产计划，但它不能自行定义真实库存、实际完工数量或采购审批状态。

正确的职责划分是：

任务	主要负责方
理解用户意图	大模型 / Agent
规划任务与选择工具	Agent Runtime
获取权威业务数据	ERP、WMS、MES 等系统
校验库存和业务规则	确定性业务服务
判断调用者是否有权限	身份与授权服务
评估高风险操作	策略引擎与风险控制服务
决定是否需要审批	企业审批规则
执行采购申请或库存调整	对应业务系统
验证最终状态	业务查询服务与审计服务

不要把关键业务约束只写在 Prompt 中。提示词可以指导模型，但不能替代后端权限、金额限制、库存规则和审批机制。

4.3 原则三：读写分离

企业 AI 工具应根据风险和副作用进行分类。

工具类型	示例	建议控制
查询工具	查询库存、订单状态	数据权限、字段过滤、超时控制
分析工具	计算交付风险、分析产能	输入校验、数据来源标注
草稿工具	创建采购申请草稿	权限校验、重复提交保护
业务写入工具	提交申请、调整计划	业务规则、幂等控制、审计
高风险工具	付款、库存报废、生产停线	强制审批、风险阈值、必要时双人复核

建议将“生成建议”“创建草稿”“提交审批”“正式执行”拆分为独立能力，而不是提供一个没有边界的万能工具。

4.4 原则四：统一业务语义，不强求所有系统使用相同数据结构

ERP 中的“可用库存”、WMS 中的“可拣库存”和数据平台中的“库存余额”可能具有不同定义。

集成层需要明确业务口径，例如：

账面库存。
可用库存。
冻结库存。
已分配库存。
在途库存。
待检库存。

如果不统一语义，AI 即使计算正确，也可能给出错误结论。

4.5 原则五：集成必须可观测、可追踪

每一次 AI 工具调用，都应能够追溯到：

原始业务请求。
当前用户与组织。
Agent 任务 ID。
工具名称和版本。
被调用的业务系统。
参数校验结果。
权限与策略判断。
业务系统响应。
最终业务状态。
相关审批和审计记录。

4.6 原则六：集成接口应当支持版本演进

企业系统会持续升级。集成层需要提供稳定的业务接口，并通过版本管理隔离底层系统变化。

例如：

AI Agent
   │
   ▼
inventory.availability.v1
   │
   ▼
Inventory Capability Service
   ├── WMS Adapter V2
   └── ERP Adapter V1

当 WMS 升级接口时，优先修改适配器，而不是同时修改所有 Agent。

五、企业 AI 集成的四种主要模式

企业并不需要在所有场景中使用同一种集成技术。应根据数据实时性、业务复杂度、系统能力和一致性要求选择合适的模式。

5.1 模式一：同步 API 集成

适用于需要立即获取结果的场景。

例如：

查询订单状态。
查询可用库存。
获取生产工单进度。
查询客户信息。
创建采购申请草稿。

调用流程：

Agent
  │
  ▼
Tool Adapter
  │
  ▼
API Gateway
  │
  ▼
业务服务
  │
  ▼
ERP / WMS / MES
  │
  ▼
标准化结果
  │
  ▼
Agent

优点：

调用链路清晰。
容易返回实时结果。
适合短时间内能够完成的操作。

需要注意：

设置连接超时与响应超时。
对可重试错误和不可重试错误进行区分。
防止重复执行写操作。
避免模型等待过长时间的同步任务。

5.2 模式二：事件驱动集成

适用于业务状态变化后，需要触发后续分析或自动化任务的场景。

例如：

ERP 创建销售订单
       │
       ▼
发布 OrderCreated 事件
       │
       ▼
消息总线 / 事件平台
       │
       ▼
AI 风险分析 Workflow
       │
       ├── 查询 WMS 库存
       ├── 查询 MES 生产进度
       └── 分析预计交付日期
       │
       ▼
生成风险报告或待办

典型事件包括：

OrderCreated：订单创建。
InventoryChanged：库存发生变化。
ProductionOrderDelayed：生产工单延期。
PurchaseOrderReceived：采购到货。
ShipmentDelayed：发运延期。

事件驱动架构能够降低系统之间的直接依赖，但需要处理重复事件、乱序事件、消费失败和最终一致性问题。

注意：消息系统通常不能保证业务事件只被处理一次。工程实现应按至少一次投递的现实情况设计幂等消费。

5.3 模式三：数据平台与 RAG 集成

适用于需要检索大量文档、历史记录和业务知识的场景。

例如：

查询设备维护手册。
检索质量异常处理记录。
分析历史订单延期原因。
根据制度文件解释审批规则。
从产品规格书中提取物料要求。

推荐架构：

企业文档 / 业务数据 / 历史记录
              │
              ▼
       数据抽取与清洗
              │
              ▼
     分块、元数据与权限处理
              │
              ▼
      Embedding / 索引构建
              │
              ▼
         向量与关键词检索
              │
              ▼
          重排序与过滤
              │
              ▼
       权限校验后的检索结果
              │
              ▼
              RAG
              │
              ▼
          AI 生成回答

RAG 适合提供上下文和历史知识，但不能替代需要实时权威状态的业务查询。

例如，知识库中可能存在昨天的库存快照。若用户询问“现在还有多少库存”，应调用实时库存服务，而不是直接依据旧的向量检索结果。

5.4 模式四：MCP 与 Tool Adapter 集成

MCP（Model Context Protocol）可以为模型应用提供统一的工具发现和调用方式，适合连接不同工具服务。

但需要明确：

MCP 是工具交互协议，不是完整的企业集成治理体系。

它本身并不能自动解决：

企业用户身份映射。
数据级权限控制。
复杂业务事务。
采购审批。
跨系统一致性。
幂等与补偿。
完整的合规审计。

推荐采用分层设计：

Agent Runtime
      │
      ▼
MCP Client / Tool Calling
      │
      ▼
MCP Server / Tool Adapter
      │
      ▼
身份校验 + 参数校验 + 策略校验
      │
      ▼
领域业务服务
      │
      ▼
ERP / WMS / MES / CRM

MCP 可以作为工具暴露层，企业的身份、授权、业务规则和审计能力则应由相应的安全与业务服务提供。

六、建立统一的企业业务工具中心

企业 AI 集成的关键不只是连接系统，更是将业务系统中的接口转化为 AI 可以理解和使用的标准化能力。

建议在企业 AI 平台中建设 Tool Registry，即统一工具注册中心。

6.1 工具注册中心应该管理什么？

属性	说明	示例
工具 ID	全局唯一标识	`inventory.get_availability`
工具名称	面向业务人员的名称	查询可用库存
工具描述	说明用途和限制	查询指定仓库与物料的可用库存
工具版本	控制接口演进	`v1`
输入 Schema	定义合法参数	物料编码、仓库编码
输出 Schema	定义返回结构	可用量、单位、更新时间
权限要求	调用者必须具备的权限	`inventory:read`
风险等级	评估调用风险	低、中、高
副作用	是否修改业务状态	只读
超时配置	调用时间限制	3 秒或按场景配置
幂等策略	重复请求如何处理	查询无需幂等键，写操作按规则设置
适用范围	系统、组织和数据范围	指定仓库、组织
审计要求	需要记录的调用信息	用户、任务、结果状态

工具描述不能只写“操作库存”，而应说明准确的业务语义。

例如：

工具：inventory.get_availability

用途：
查询指定物料在指定仓库的当前可用库存。

输入：
- material_code：物料编码
- warehouse_code：仓库编码

输出：
- material_code：物料编码
- warehouse_code：仓库编码
- on_hand_qty：账面数量
- reserved_qty：已分配数量
- blocked_qty：冻结数量
- available_qty：可用数量
- unit：计量单位
- as_of：数据时间

限制：
- 只允许访问调用者有权查看的仓库。
- 只读，不修改库存。
- 必须标明数据更新时间。
- 不得把在途库存自动视为现存可用库存。

6.2 工具接口与模型 Schema

可以用 JSON Schema 描述工具参数。下面是一个简化示例：

{
  "type": "object",
  "properties": {
    "material_code": {
      "type": "string",
      "minLength": 1,
      "maxLength": 64
    },
    "warehouse_code": {
      "type": "string",
      "minLength": 1,
      "maxLength": 32
    }
  },
  "required": [
    "material_code",
    "warehouse_code"
  ],
  "additionalProperties": false
}

这里的 additionalProperties: false 可以防止调用方传入未经定义的额外字段。

不过，Schema 校验只能保证参数结构符合规范，不能证明调用者有权查询该仓库，也不能证明物料编码真实存在。这些校验仍需由服务端完成。

6.3 不要向模型暴露万能工具

不推荐设计：

execute_sql(sql)
call_any_api(url, method, body)
execute_shell(command)
update_any_table(table, data)

这类工具的权限边界过宽，很容易形成间接的高风险执行入口。

更推荐面向业务意图设计：

inventory.get_availability
orders.get_delivery_status
production.get_work_order_progress
procurement.create_requisition_draft
procurement.submit_requisition_for_approval

每个工具应具备明确的输入、输出、权限范围和业务副作用。

七、构建 ERP、WMS、MES、CRM 统一业务适配层

企业中的不同系统通常由不同厂商、团队和技术栈建设。它们的接口风格、字段命名、错误码、分页方式和业务状态都可能不同。

因此，建议在工具层和底层业务系统之间建立业务适配层。

7.1 业务适配层的职责

适配层主要解决五类问题：

协议适配：REST、SOAP、消息队列、RPC 或厂商 SDK。
数据映射：字段名称、数据类型、单位和编码转换。
业务语义统一：将不同系统的相似概念转换为统一业务模型。
错误标准化：把底层错误转换为稳定的业务错误。
调用治理：超时、限流、重试、幂等、审计和监控。

例如，不同系统可能返回不同格式的库存数据。

ERP：

{
  "materialId": "MAT-001",
  "stockQty": 120,
  "unitCode": "PCS"
}

WMS：

{
  "sku": "MAT-001",
  "availableQuantity": 96,
  "uom": "EA"
}

经过适配层后，可以转换为统一的库存查询结果：

{
  "material_code": "MAT-001",
  "warehouse_code": "WH-01",
  "quantity": 96,
  "unit": "EA",
  "quantity_type": "available",
  "source_system": "WMS",
  "as_of": "2026-10-28T08:20:00+08:00"
}

这里的 quantity_type 非常重要。不能把 ERP 的账面数量与 WMS 的可用数量直接相加，也不能因为两个系统返回相同字段名，就认定它们表达相同业务含义。

7.2 统一业务模型不等于强制所有系统使用相同数据库结构

适配层应统一对外契约，同时允许底层系统保留自身领域模型。

例如：

                    统一库存业务接口
                           │
                ┌──────────┴──────────┐
                ▼                     ▼
           ERP 库存适配器         WMS 库存适配器
                │                     │
                ▼                     ▼
           ERP 原有模型            WMS 原有模型

统一模型主要用于跨系统协作，不应该为了让 AI 调用方便而大规模重构成熟的 ERP 或 WMS。

7.3 推荐的统一响应格式

企业可以建立自己的统一响应规范，例如：

{
  "success": true,
  "code": "SUCCESS",
  "message": "查询成功",
  "data": {
    "material_code": "MAT-001",
    "available_qty": 96,
    "unit": "EA"
  },
  "meta": {
    "request_id": "req-example-001",
    "source_system": "WMS",
    "data_as_of": "2026-10-28T08:20:00+08:00",
    "schema_version": "v1"
  }
}

这只是推荐的接口契约示例，不代表所有企业都必须使用相同字段。

另外，success: true 只表示本次接口操作成功。对于写操作，还应返回明确的业务对象 ID、业务状态和后续处理状态。

例如：

{
  "success": true,
  "code": "REQUISITION_DRAFT_CREATED",
  "data": {
    "requisition_id": "PR-2026-00128",
    "status": "DRAFT"
  }
}

这表示草稿已经创建，并不表示申请已经提交或审批通过。

八、跨系统业务编排：让多个系统协同完成任务

单个业务工具通常只能完成一个局部操作，而企业 AI 任务往往需要多个系统协同。

例如，订单交付风险分析可能需要：

用户请求
   │
   ▼
订单查询
   │
   ▼
物料需求计算
   │
   ├──────────────> WMS 查询库存
   │
   ├──────────────> ERP 查询采购到货
   │
   └──────────────> MES 查询生产进度
   │
   ▼
统一数据校验
   │
   ▼
交付风险分析
   │
   ▼
规则校验
   │
   ▼
生成调整建议

8.1 哪些步骤应该由 Agent 决定，哪些步骤应该固定编排？

这是企业 AI 架构中的关键设计问题。

场景	推荐实现
理解用户的模糊请求	Agent
根据意图选择查询工具	Agent，在授权工具范围内选择
同时查询多个独立系统	Workflow 或受控并行执行
计算物料缺口	确定性业务服务
判断采购是否超预算	业务规则服务
判断是否必须审批	策略引擎
创建采购申请草稿	业务工具
正式提交采购申请	经过权限、风险和审批规则控制的工具
检查申请是否真实创建	业务系统查询与结果验证

Agent 适合处理语义理解、动态规划和非完全确定性的任务；Workflow 适合控制执行顺序、重试、状态和失败处理。

成熟的企业系统通常需要两者结合，而不是用 Agent 取代所有业务流程。

8.2 一个简化的工作流定义

下面展示一个概念性 YAML 配置。它用于说明编排逻辑，实际字段需要根据所选 Workflow 引擎进行适配。

workflow:
  id: order_delivery_risk_analysis
  version: "1.0"

  steps:
    - id: get_order
      type: tool
      tool: orders.get_delivery_status

    - id: get_inventory
      type: tool
      tool: inventory.get_availability
      depends_on:
        - get_order

    - id: get_production
      type: tool
      tool: production.get_work_order_progress
      depends_on:
        - get_order

    - id: calculate_risk
      type: service
      service: delivery-risk-calculator
      depends_on:
        - get_inventory
        - get_production

    - id: validate_policy
      type: policy
      policy: delivery-risk-policy
      depends_on:
        - calculate_risk

    - id: summarize
      type: agent
      agent: delivery-report-agent
      depends_on:
        - validate_policy

实际执行时，可以将库存查询与生产进度查询设置为并行步骤，前提是它们之间不存在数据依赖。

还应为每个步骤定义：

输入和输出契约。
超时策略。
最大重试次数。
错误分类。
失败后是否允许继续。
是否需要人工介入。
是否允许恢复执行。

不要让 Agent 仅凭一段自然语言决定整个流程的所有安全细节。

九、跨系统写操作：事务、幂等与补偿机制

这是企业 AI 集成中最容易被低估的部分。

读取多个系统的数据通常相对简单；真正困难的是，多个系统之间发生写操作时，如何保证状态一致。

例如，AI 建议为缺货物料创建采购申请：

查询库存。
计算缺口。
创建采购申请草稿。
提交审批。
等待审批结果。
审批通过后由后续流程创建采购订单。

这些步骤可能跨越多个系统，也可能持续数分钟甚至数天。

不能简单地把它们当作一个数据库事务处理。

9.1 不要假设跨系统操作可以使用单一事务

传统数据库事务的 ACID 特性，通常无法直接覆盖 ERP、WMS、MES 和独立审批平台之间的全部操作。

更常见的方案包括：

Saga 模式：将长事务拆分为多个本地事务，并定义失败后的补偿动作。
Transactional Outbox：在本地事务中同时保存业务变更和待发布事件，降低数据库更新成功但事件丢失的风险。
幂等处理：对重复请求进行识别，避免重复创建业务对象。
状态机：明确每个业务步骤的状态与合法迁移。
人工介入：对于无法安全自动补偿的业务，进入人工处理队列。

9.2 幂等键设计

假设 Agent 调用采购申请创建接口后，网络超时。

此时存在两种可能：

请求根本没有到达 ERP。
ERP 已经创建申请，但响应在返回途中丢失。

如果 Agent 直接重新调用，可能生成两张采购申请。

建议在写操作中使用稳定的幂等键，例如：

POST /api/v1/procurement/requisitions
Idempotency-Key: task-8732-create-requisition-v1
Content-Type: application/json

请求体：

{
  "material_code": "MAT-001",
  "quantity": 500,
  "unit": "EA",
  "warehouse_code": "WH-01",
  "source_task_id": "task-8732"
}

服务端应当：

检查幂等键是否已处理。
对同一个键关联已创建的业务对象。
如果请求内容一致，返回原操作结果。
如果同一个键对应不同请求内容，拒绝处理并记录异常。
保留足够的幂等记录，以覆盖业务重试窗口。

幂等键必须由可信的服务端流程生成或校验，不能只依赖模型临时生成的随机字符串。

9.3 采购申请的状态机

           ┌─────────────┐
           │   CREATED   │
           └──────┬──────┘
                  ▼
           ┌─────────────┐
           │    DRAFT    │
           └──────┬──────┘
                  ▼
           ┌─────────────┐
           │  SUBMITTED  │
           └──────┬──────┘
                  ▼
           ┌─────────────┐
           │   PENDING   │
           │  APPROVAL   │
           └───┬─────┬───┘
               │     │
       审批通过│     │审批拒绝
               ▼     ▼
        ┌─────────┐ ┌──────────┐
        │ APPROVED│ │ REJECTED │
        └────┬────┘ └──────────┘
             ▼
       后续采购流程

这里需要明确：审批通过不一定意味着采购订单已经生成。采购订单的创建仍可能依赖其他业务条件。

AI 只能根据真实业务状态报告进度，不能因为某个 API 返回成功，就推断后续状态已经完成。

9.4 Saga 补偿示例

假设业务流程包括：

A. 创建采购申请草稿
B. 写入内部任务关联记录
C. 提交审批

如果步骤 C 失败，应根据业务规则决定如何处理：

如果申请仍是草稿，可以保留草稿并提示重试。
如果申请已提交，但本地任务状态未更新，应先查询审批系统确认真实状态。
如果业务对象可以安全撤销，可以执行经过授权的撤销操作。
如果无法自动恢复，则进入人工处理队列。

补偿不等于简单地删除之前的数据。补偿动作本身也需要权限、业务规则、审计与失败处理。

十、企业 AI 集成的安全架构

企业 AI 集成不是“让模型能调用 API”这么简单，而是要确保每次调用都在正确的身份、数据范围和业务规则下执行。

建议将安全控制分成六个层次。

10.1 第一层：身份认证

识别发起请求的真实用户或服务主体。

常见方式包括：

企业统一身份认证。
OAuth 2.0 / OpenID Connect。
企业内部服务身份。
工作负载身份。
受控的服务账号。

需要特别注意：不能把所有用户请求都映射成一个拥有全系统权限的 Agent 服务账号。

如果业务需要以用户身份访问数据，应设计可靠的身份传递或委托授权机制；如果使用服务身份，则应进一步限制其可访问的业务范围，并在后端执行用户级权限校验。

10.2 第二层：工具授权

即使用户能够查询订单，也不代表他能够调用所有订单相关工具。

例如：

工具	权限示例
`orders.get_delivery_status`	`orders:read`
`inventory.get_availability`	`inventory:read`
`procurement.create_requisition_draft`	`procurement:draft:create`
`procurement.submit_requisition`	`procurement:submit`
`inventory.adjust_stock`	`inventory:adjust`

工具注册中心可以声明所需权限，但最终授权必须由可信的后端服务执行，不能只依赖模型是否选择了某个工具。

10.3 第三层：数据范围授权

企业常常存在组织、工厂、仓库、部门和项目的数据边界。

例如，某用户可以查看工厂 A 的库存，却不能查看工厂 B 的库存。

权限判断不应只检查：

用户是否拥有 inventory:read？

还需要检查：

用户是否可以访问 WH-A01？
当前请求的组织范围是否合法？
返回字段是否包含受限信息？
检索结果是否来自用户有权访问的数据？

这意味着数据权限不仅要作用于业务 API，还应作用于：

RAG 文档检索。
数据平台查询。
工具执行结果。
Agent 之间传递的数据。
日志和报表中的敏感字段。

10.4 第四层：业务规则与风险控制

以采购申请为例，可以配置：

物料必须处于有效状态。
数量必须大于零。
供应商必须满足采购规则。
金额超过指定阈值时必须审批。
特定物料不能由 AI 自动提交。
同一业务任务不得重复创建申请。
库存或采购数据过期时禁止自动执行。

关键规则应在后端业务服务中执行。策略引擎可以集中管理风险决策，但最终写操作仍应经过业务系统的合法性校验。

10.5 第五层：人工审批

以下场景通常需要设置人工确认或审批机制：

付款与资金操作。
采购申请提交或高金额采购。
库存报废与库存调整。
生产计划大范围变更。
影响客户交付承诺的重大调整。
修改员工薪酬或敏感人事信息。

审批流程应绑定具体业务对象和操作内容。

例如，用户批准的是某个物料、某个数量、某个供应商和某个金额的采购申请，不能将这次批准泛化为“Agent 此后可以随意采购”。

如果审批内容发生变化，应根据企业规则重新审批。

10.6 第六层：审计与追踪

建议至少记录：

trace_id
request_id
task_id
user_id / service_principal
agent_id
tool_name
tool_version
target_system
resource_scope
policy_decision
approval_id
idempotency_key
business_object_id
execution_status
business_status
timestamp

日志中应避免直接保存不必要的敏感信息、访问令牌、密码或完整的个人数据。对于 Prompt、工具参数和模型输出，也应根据数据分类策略设置脱敏、访问控制和保留期限。

十一、统一异常处理与可靠性设计

企业业务系统可能出现网络超时、限流、服务不可用、业务规则拒绝和数据冲突等问题。

AI 集成层应区分技术异常与业务异常，避免让模型把所有错误都当作可以重试的问题。

11.1 建立标准错误分类

错误类型	示例	建议处理
参数错误	物料编码为空	修正输入，不自动重复原请求
权限错误	用户无权访问仓库	拒绝调用，提示申请权限
业务规则错误	采购数量超过限制	返回业务原因，要求调整或审批
资源不存在	订单编号不存在	核实编号或提示用户
限流错误	HTTP 429	按服务端规则退避重试
临时服务错误	HTTP 503	有条件地重试或进入待处理状态
网络超时	请求结果未知	先查询业务状态，避免盲目重放写请求
数据冲突	库存已被其他业务占用	重新读取权威状态并重新计算
系统配置错误	工具版本不匹配	停止调用并触发告警

11.2 重试策略

只对具有明确重试条件的错误进行重试。对于限流和临时服务错误，可以使用指数退避并增加随机抖动。

概念示例：

$delay_n = \min(delay_{\max}, delay_0 \times 2^n) + jitter$

其中：

$delay_0$ 是初始等待时间。
n 是重试次数。
$delay_{\max}$ 是最大等待时间。
jitter 用于减少大量请求同时重试造成的压力。

应设置最大重试次数、总执行时限和调用预算，防止 Agent 在失败后无限循环。

11.3 超时不等于失败

这是跨系统写操作中尤其重要的一点。

如果创建采购申请的请求超时，系统并不知道业务对象是否已经创建。

正确流程是：

提交创建请求
      │
      ▼
     超时
      │
      ▼
根据幂等键或任务 ID 查询操作状态
      │
      ├── 已创建：返回已有业务对象
      │
      ├── 明确未创建：在安全条件下重试
      │
      └── 状态未知：进入待确认状态并告警

不能因为没有收到响应，就直接假定业务操作失败。

11.4 熔断与降级

当某个业务系统持续不可用时，可以使用熔断器暂时停止对其发起大量请求。

同时，应定义合理的降级策略：

实时库存不可用时，返回“当前无法确认库存”，而不是把历史库存当成实时库存。
MES 暂时不可用时，可以展示最后一次同步时间明确的生产快照。
审批服务不可用时，可以保留申请草稿，但不应绕过审批直接执行。
数据平台不可用时，可以停止非关键分析任务或使用经过标记的缓存数据。

降级的目标是维持系统可用性，而不是牺牲业务正确性。

十二、实战案例：构建跨 ERP、WMS、MES 的订单交付风险 Agent

下面以制造企业为例，设计一个可以查询订单、分析缺料风险并生成采购申请草稿的 AI 业务流程。

12.1 业务需求

业务人员提出：

分析本周即将到期的订单，找出可能延期的订单，结合库存、生产进度和采购到货时间给出建议；如果需要补货，生成采购申请草稿，并告诉我哪些申请需要审批。

系统需要从多个数据源获取事实，并将分析与业务操作分开。

12.2 工具设计

工具	所属系统	类型	关键限制
`orders.list_due_soon`	ERP	查询	仅返回授权组织内的订单
`inventory.get_availability`	WMS	查询	返回库存口径与更新时间
`production.get_work_order_progress`	MES	查询	返回工单进度和数据时间
`procurement.get_expected_receipts`	ERP / 采购系统	查询	区分预计到货与实际到货
`delivery.calculate_risk`	业务服务	分析	使用确定性规则计算风险指标
`procurement.create_requisition_draft`	ERP / 采购系统	写入	需要创建权限和幂等控制
`procurement.get_requisition_status`	ERP / 采购系统	查询	验证申请真实状态

注意，delivery.calculate_risk 可以使用 AI 辅助解释风险原因，但风险指标、数量计算和强约束规则应由可测试的业务服务实现。

12.3 系统执行流程

用户请求
   │
   ▼
身份认证与用户权限检查
   │
   ▼
任务协调 Agent
   │
   ├── 查询本周到期订单
   │
   ├── 查询物料可用库存
   │
   ├── 查询生产工单进度
   │
   └── 查询采购预计到货
   │
   ▼
数据校验与口径统一
   │
   ▼
交付风险计算服务
   │
   ▼
风险分级与业务规则校验
   │
   ├── 无需补货：生成分析报告
   │
   ├── 需要补货：生成采购建议
   │
   └── 需要执行：创建采购申请草稿
                         │
                         ▼
                   权限与风险复核
                         │
                         ▼
                    返回草稿编号
                         │
                         ▼
                  人工确认与审批
                         │
                         ▼
                   查询真实状态
                         │
                         ▼
                    汇总业务结果

12.4 计算缺料量

对于某物料，可以使用简化公式：

$Q_{\text{gap}} = \max(0,\ Q_{\text{required}} - Q_{\text{available}} - Q_{\text{confirmed inbound}})$

其中：

$Q_{\text{required}}$ ：目标生产计划需要的数量。
$Q_{\text{available}}$ ：按企业库存规则计算的可用数量。
$Q_{\text{confirmed inbound}}$ ：在目标时间窗口内、满足企业规则的确认到货数量。
$Q_{\text{gap}}$ ：初步计算的物料缺口。

这只是一个示例公式。实际业务还可能需要考虑安全库存、批次、质量状态、已分配数量、替代料、最小采购量、采购周期、损耗率和不同订单之间的库存竞争。

尤其要注意：预计到货不一定能在需求日期前到达，也不应默认等同于已到货库存。

因此，最终采购建议应结合物料需求日期、预计到货日期和供应商交期计算，而不是只比较总数量。

12.5 结构化风险结果

建议先让业务服务返回结构化数据，再由 AI 生成可读报告。

{
  "order_id": "SO-2026-0188",
  "delivery_date": "2026-10-30",
  "risk_level": "HIGH",
  "risk_reasons": [
    "关键物料可用库存不足",
    "采购预计到货晚于需求日期"
  ],
  "material_gaps": [
    {
      "material_code": "MAT-001",
      "required_qty": 500,
      "available_qty": 180,
      "confirmed_inbound_qty": 100,
      "gap_qty": 220,
      "unit": "EA"
    }
  ],
  "recommended_actions": [
    "确认供应商能否提前交货",
    "评估合规的替代物料",
    "生成采购申请草稿供人工审核"
  ],
  "data_as_of": "2026-10-28T08:20:00+08:00"
}

以上是演示用的示例数据，不代表真实企业业务记录。

这里的 risk_level 应由已定义的业务规则或经过验证的风险模型产生，而不是仅依赖模型自由判断。

12.6 采购申请草稿的执行规则

当系统决定生成采购申请草稿时，应先检查：

当前用户是否有创建采购申请草稿的权限。
物料和仓库是否有效。
采购数量是否符合最小采购量和包装规则。
是否已有相同业务任务生成的申请。
申请金额是否超过自动化操作阈值。
供应商是否符合采购策略。
相关库存与到货数据是否仍然有效。
是否需要进一步人工确认。

随后调用采购系统的草稿创建接口，并记录真实返回的申请编号。

如果后续需要正式提交，则应进入独立的授权与审批流程。

12.7 最终报告示例

AI 可以将结构化结果整理为业务人员容易理解的报告：

订单交付风险分析

分析范围：本周即将到期的订单
风险订单：3 个
高风险订单：1 个

主要发现：
- 订单 SO-2026-0188 存在关键物料缺口。
- 当前可用库存不足以覆盖计划需求。
- 部分采购预计到货时间晚于需求日期。

建议措施：
1. 联系供应商确认是否可以提前交货。
2. 核实是否存在经过批准的替代物料。
3. 对无法按期到货的物料生成采购申请草稿。

执行状态：
- 采购申请草稿：已创建 / 待确认
- 审批状态：尚未审批
- 正式采购订单：尚未生成

数据时间：
以各业务系统返回的实际更新时间为准。

这里的状态字段必须根据真实工具调用结果填充。若草稿创建失败，系统必须明确报告失败或待确认，而不能将建议描述成已经完成的业务操作。

十三、企业 AI 集成的技术选型

技术选型不应以“哪种技术最热门”为核心，而应关注企业现有系统、集成复杂度、部署约束和运维能力。

13.1 常见技术组件

技术领域	可选方案	主要用途
API 网关	Kong、Apache APISIX、企业现有 API Gateway	统一入口、限流、路由与认证集成
后端集成服务	Spring Boot、ASP.NET Core、FastAPI	业务适配、参数校验与接口封装
工作流编排	Temporal、Camunda、企业现有 BPM / Workflow	长流程、状态管理、重试与人工任务
消息中间件	Kafka、RabbitMQ、企业现有消息平台	异步通信、事件驱动
事件同步	Debezium 等 CDC 组件	捕获数据变更并同步到下游
工具协议	MCP、模型平台原生 Tool Calling	暴露工具、标准化调用
数据访问	领域 API、只读查询服务、数据平台	获取权威业务数据
可观测性	OpenTelemetry、Prometheus、Grafana	调用链、指标和告警
审计与日志	企业日志平台、集中审计服务	操作追踪、合规审计
身份管理	企业 IdP、OAuth 2.0 / OIDC、企业权限服务	用户认证与访问控制
部署平台	Docker、Kubernetes	服务部署、弹性与高可用

以上是常见选项，不意味着每个项目都需要全部引入。

例如，中小型企业已经具备 Spring Boot 服务、RabbitMQ 和企业 API 网关时，可以先在现有架构上增加 AI 集成服务，不必为了 AI 项目立即引入新的消息平台、工作流平台和服务网格。

13.2 Spring Boot 集成服务示例

如果企业主要使用 Java 技术栈，可以通过 Spring Boot 构建统一业务工具服务。

一个简化的查询接口示例如下：

@RestController
@RequestMapping("/api/v1/inventory")
public class InventoryController {

    private final InventoryService inventoryService;

    public InventoryController(InventoryService inventoryService) {
        this.inventoryService = inventoryService;
    }

    @GetMapping("/availability")
    public InventoryAvailability getAvailability(
            @RequestParam String materialCode,
            @RequestParam String warehouseCode) {

        return inventoryService.getAvailability(
            materialCode,
            warehouseCode
        );
    }
}

真正的生产实现还需要补充：

请求身份验证。
仓库级数据权限检查。
参数格式与业务有效性验证。
统一异常处理。
请求追踪 ID。
超时和限流配置。
审计与敏感数据脱敏。
服务端返回结构定义。

关键点：不要把安全校验全部放在 Controller 中，也不要认为只要接口由内部网络访问就不需要权限控制。应将身份认证、授权策略、业务逻辑和审计职责合理分离。

13.3 Python 集成服务示例

对于已有 Python AI 平台的团队，也可以使用 FastAPI 建立工具适配服务。

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel, Field

app = FastAPI()

class InventoryQuery(BaseModel):
    material_code: str = Field(min_length=1, max_length=64)
    warehouse_code: str = Field(min_length=1, max_length=32)

@app.post("/tools/inventory/availability")
async def get_inventory(query: InventoryQuery):
    # 生产环境必须在这里或下游服务中完成：
    # 1. 身份与数据范围授权
    # 2. 调用可信的库存业务服务
    # 3. 超时、错误和审计处理

    result = await inventory_service.get_availability(
        material_code=query.material_code,
        warehouse_code=query.warehouse_code,
    )

    if result is None:
        raise HTTPException(
            status_code=404,
            detail="Inventory information not found"
        )

    return {
        "material_code": result.material_code,
        "warehouse_code": result.warehouse_code,
        "available_qty": result.available_qty,
        "unit": result.unit,
        "data_as_of": result.data_as_of,
    }

这里的 inventory_service 是示意性的业务服务依赖，需要在实际项目中实现并注入。代码展示的是接口设计思路，不是可以直接连接任意 ERP 的完整实现。

十四、企业 AI 集成的实施路线图

不要一开始就建设覆盖所有业务系统的通用集成平台。更稳妥的方式是从一个高价值、低风险、边界清晰的业务场景开始。

01

阶段一：业务与系统盘点

建议周期：1～2 周，视系统数量调整

梳理 ERP、WMS、MES、CRM 的接口能力。
明确核心业务对象和数据权威来源。
识别身份、数据权限和审计要求。
选择首个 AI 集成场景。

02

阶段二：建设基础集成能力

建议周期：2～4 周

建立统一工具契约和业务适配器。
接入身份认证、参数校验和调用审计。
建立统一错误码、超时和重试规范。
优先实现只读查询工具。

03

阶段三：打通跨系统查询

建议周期：2～4 周

实现订单、库存、生产进度的联合查询。
统一字段、单位、业务口径和时间戳。
建立数据来源与新鲜度标识。
验证跨系统分析结果。

04

阶段四：引入受控业务写入

建议周期：2～4 周或更长

先实现业务草稿创建。
增加幂等键、状态机和结果验证。
接入人工审批与风险控制。
在测试环境验证失败恢复与重复调用。

05

阶段五：生产化与规模推广

持续迭代

建立集成测试、AI 评估与发布门禁。
配置调用链监控、成本统计和告警。
通过灰度发布验证稳定性。
逐步扩展到更多系统和业务场景。

以上周期是规划参考，实际工期取决于现有 API 质量、数据权限复杂度、供应商配合程度、部署环境和审批流程。

14.1 每个阶段都应该有可验收的交付物

阶段	核心交付物
系统盘点	系统清单、接口清单、业务对象清单、风险清单
基础集成	工具契约、适配器、统一错误模型、身份与审计方案
跨系统查询	数据映射规则、查询工具、业务口径说明、集成测试
受控写入	幂等机制、状态机、审批流程、异常恢复方案
生产化	监控看板、发布门禁、回滚方案、运维手册

十五、企业 AI 集成的常见错误

错误一：让每个 Agent 自己维护业务 API

这会造成接口重复建设、权限实现不一致和维护成本增加。

改进：建立统一工具注册中心与业务适配层，同时允许特殊业务保留独立适配器。

错误二：只验证 HTTP 状态码

接口返回成功不等于业务任务完成。

改进：对写操作查询业务对象状态，验证关键字段和预期状态。

错误三：认为 MCP 可以替代整个集成平台

MCP 解决工具交互协议问题，但不自动提供企业身份治理、跨系统事务、完整审计和业务规则。

改进：将 MCP 作为工具接入方式之一，底层仍使用企业集成、授权和业务服务。

错误四：所有调用都使用管理员账号

这会扩大数据泄露和误操作的影响范围。

改进：实施最小权限原则，区分用户身份、服务身份、工具权限与数据范围。

错误五：把 RAG 当成实时业务查询系统

知识库内容可能存在同步延迟，无法天然保证实时库存和订单状态的准确性。

改进：实时状态调用权威业务 API，历史知识和文档解释使用 RAG，并明确数据时间。

错误六：不处理重复调用

超时后重试可能导致重复创建采购申请、重复提交任务或重复触发业务动作。

改进：设计幂等键、业务唯一约束、状态查询和失败恢复机制。

错误七：把所有跨系统流程都交给 Agent 自由规划

自由规划无法替代确定性的业务状态控制。

改进：将 Agent 与 Workflow 结合，把关键顺序、审批、重试和终止条件固化到可验证的流程中。

错误八：忽略企业系统的数据语义

同样名为“数量”的字段可能代表账面量、可用量、已分配量或在途量。

改进：建立业务词汇表、数据字典、统一单位和来源标识。

错误九：只做正常路径测试

真实生产环境中，最难处理的往往是部分成功、状态未知、接口限流和业务数据冲突。

改进：将故障注入、重复请求、超时、权限拒绝、数据过期和补偿失败纳入测试。

十六、FDE 实战检查清单

FDE 不只是负责把 Agent 连接到 API，还需要协调业务、技术、安全和交付团队，确保集成能力真正解决业务问题。

企业 AI 集成交付自检

0/16

业务与数据

明确业务目标、业务对象与成功标准

确定 ERP、WMS、MES 等数据权威来源

统一字段、单位、状态与数据更新时间

明确实时查询、缓存和异步同步的边界

接口与架构

建立工具注册中心与版本管理

定义输入输出 Schema 和标准错误码

选择同步 API、事件、数据平台或 MCP 方案

将 Agent 规划与确定性业务流程分离

安全与治理

完成身份认证、最小权限与数据范围校验

对写操作设置风险分级与审批规则

实施参数校验、幂等控制和审计追踪

对敏感数据、日志和模型上下文进行保护

可靠性与交付

配置超时、限流、重试、熔断和降级

验证业务结果，而不只检查 HTTP 状态码

测试重复调用、部分成功和失败恢复

建立集成测试、监控告警、灰度发布与回滚

十七、如何衡量企业 AI 集成是否成功？

不能只看工具调用次数，也不能只看模型回答是否流畅。

企业 AI 集成至少需要从五个维度评估。

维度	推荐指标	说明
业务价值	任务完成率、平均处理时长、人工节省时间	AI 是否真正改善业务流程
数据质量	数据口径一致率、数据新鲜度、字段校验通过率	输入数据是否可信
集成可靠性	API 成功率、超时率、重试率、恢复时间	集成链路是否稳定
业务正确性	业务结果验证通过率、重复业务对象数	是否真正完成预期业务操作
安全与治理	越权拦截率、审批合规率、审计覆盖率	是否在受控范围内运行
成本与性能	单任务成本、端到端延迟、工具调用次数	能否稳定、经济地扩展