【FDE前沿部署工程师实战教程】第61章：Enterprise AI Platform Engineering——企业级 AI 平台工程化建设与统一能力中台
一、从 AI 应用开发走向 AI 平台工程
在企业 AI 建设初期，很多团队通常采用项目驱动的方式推进 AI 应用落地。
例如：
-
为仓库管理部门开发一个 AI 库存分析助手。
-
为生产部门开发一个 AI 生产异常分析助手。
-
为设备部门开发一个 AI 设备故障诊断助手。
-
为质量部门开发一个 AI 质量追溯助手。
-
为管理层开发一个 AI 经营分析助手。
这些项目在初期通常能够快速交付，但随着 AI 应用数量增加，企业很快就会遇到新的问题：
-
不同项目重复接入大模型，缺少统一模型管理。
-
不同 Agent 重复开发工具调用和权限校验逻辑。
-
不同应用各自建设知识库，知识资源无法共享。
-
Prompt、Workflow、Agent 缺少统一版本管理。
-
AI 应用缺少统一测试、评估和发布机制。
-
不同部门使用不同 AI 服务，成本无法统一核算。
-
AI 应用出现异常后，缺少统一监控和审计能力。
-
AI 应用难以跨部门复制，项目交付成本不断增加。
这说明企业 AI 建设不能长期停留在单个应用开发阶段。
企业需要从：
AI Application Development（AI 应用开发）
逐步升级到：
Enterprise AI Platform Engineering（企业级 AI 平台工程化建设）。
核心目标是建设一个统一的 AI 能力中台，将模型、知识库、Agent、Workflow、工具、评估、安全治理、监控运营等能力进行标准化封装，让企业能够持续、规模化地开发和运营 AI 应用。
二、AI 平台、AI 应用与 AI 能力中台的区别
首先需要明确三个概念。
2.1 AI 应用（AI Application）
AI 应用是面向具体业务场景的产品。
例如：
| AI 应用 | 业务场景 |
|---|---|
| AI 仓库助手 | 库存查询、缺货分析、补货建议 |
| AI 生产助手 | 工单查询、生产异常分析 |
| AI 设备助手 | 故障诊断、维修知识查询 |
| AI 质量助手 | 不良分析、质量追溯 |
| AI 采购助手 | 供应商分析、采购建议 |
| AI 人事助手 | 员工政策查询、人事流程办理 |
AI 应用主要解决业务问题。
2.2 AI 能力中台（AI Capability Platform）
AI 能力中台是为多个 AI 应用提供公共能力的基础设施。
例如：
-
统一模型调用。
-
统一知识库检索。
-
统一 Agent Runtime。
-
统一 Workflow Engine。
-
统一工具注册。
-
统一身份认证。
-
统一权限控制。
-
统一评估和监控。
它不直接面向某一个业务部门，而是为所有 AI 应用提供可复用能力。
2.3 AI 平台（Enterprise AI Platform）
企业级 AI 平台是在能力中台之上，进一步提供开发、管理、治理和运营功能的综合平台。
它既包含底层技术能力，也包含面向开发人员、业务人员和平台管理员的管理工具。
三者之间的关系：
企业业务用户
│
┌───────────┴───────────┐
│ │
AI 仓库助手 AI 生产助手
│ │
AI 设备助手 AI 质量助手
│ │
└───────────┬───────────┘
│
Enterprise AI Platform
│
┌───────────┼───────────┐
│ │ │
模型服务 Agent服务 Workflow服务
│ │ │
├───────────┼───────────┤
│ │ │
RAG服务 Tool服务 Evaluation服务
│ │ │
└───────────┼───────────┘
│
企业基础设施
│
ERP / WMS / MES / CRM / HRM
AI 应用解决业务问题，AI 能力中台提供公共能力，AI 平台负责统一建设、开发、治理和运营。
三、企业级 AI 平台总体架构
企业 AI 平台不能简单理解为一个大模型管理页面，也不能只是一个 Agent 开发工具。
真正的企业级 AI 平台，需要覆盖从资源接入到应用交付的完整生命周期。
3.1 七层平台架构
┌──────────────────────────────────────────────────────────┐
│ 1. AI 应用层 │
│ │
│ AI 仓库助手 AI 生产助手 AI 设备助手 AI 质量助手 │
│ AI 采购助手 AI 人事助手 AI 经营分析 AI 客服助手 │
├──────────────────────────────────────────────────────────┤
│ 2. 应用平台层 │
│ │
│ 应用管理 应用编排 API 发布 应用模板 应用市场 │
│ 多渠道接入 用户工作台 应用生命周期管理 │
├──────────────────────────────────────────────────────────┤
│ 3. AI 能力平台层 │
│ │
│ Model Gateway Agent Runtime Workflow Engine │
│ RAG Engine Tool Registry Prompt Management │
│ Memory Service Evaluation Guardrails │
├──────────────────────────────────────────────────────────┤
│ 4. AI 资源管理层 │
│ │
│ 模型资源 知识资源 Prompt资源 Agent资源 工具资源 │
│ 数据资源 算力资源 AI资产版本与依赖管理 │
├──────────────────────────────────────────────────────────┤
│ 5. 企业集成层 │
│ │
│ API Gateway MCP Gateway 消息总线 数据连接器 │
│ ERP / WMS / MES / CRM / HRM / OA / IoT │
├──────────────────────────────────────────────────────────┤
│ 6. 基础设施层 │
│ │
│ Kubernetes GPU资源 模型推理服务 Redis MQ │
│ MySQL PostgreSQL 对象存储 向量数据库 │
├──────────────────────────────────────────────────────────┤
│ 7. 横向治理体系 │
│ │
│ 身份认证 权限控制 数据安全 审计追踪 可观测性 │
│ 评估管理 成本管理 多租户 版本管理 发布管理 │
└──────────────────────────────────────────────────────────┘
3.2 各层职责
| 架构层 | 核心职责 | 主要组件 |
|---|---|---|
| AI 应用层 | 面向业务提供 AI 服务 | AI 助手、智能分析、业务 Agent |
| 应用平台层 | 应用创建、发布和管理 | 应用管理、应用市场、API 发布 |
| AI 能力平台层 | 提供公共 AI 能力 | 模型、Agent、RAG、Workflow |
| AI 资源管理层 | 管理 AI 资产 | 模型、知识库、Prompt、工具 |
| 企业集成层 | 连接企业业务系统 | API、MCP、消息总线、连接器 |
| 基础设施层 | 提供计算和存储资源 | GPU、K8s、数据库、对象存储 |
| 横向治理体系 | 保障安全和稳定运行 | 权限、审计、监控、成本管理 |
四、企业 AI 平台核心功能模块
建议采用模块化方式建设平台，避免所有功能耦合在一个服务中。
4.1 平台工作台
平台工作台是用户进入 AI 平台后的统一入口。
主要展示：
-
AI 应用数量。
-
Agent 数量。
-
模型资源数量。
-
知识库数量。
-
Workflow 数量。
-
今日模型调用量。
-
Token 消耗量。
-
AI 应用运行成功率。
-
当前异常任务。
-
平台资源使用情况。
工作台应根据角色显示不同信息。
| 用户角色 | 工作台内容 |
|---|---|
| 平台管理员 | 平台资源、系统运行、成本与安全 |
| AI 开发人员 | 应用开发、Agent、Workflow、测试 |
| 业务管理员 | 部门应用、知识库、业务运行情况 |
| 普通用户 | 已授权 AI 应用、历史会话、常用助手 |
| 安全审计人员 | 权限变更、调用记录、风险事件 |
4.2 模型管理（Model Management）
模型管理负责统一接入和管理不同来源的大模型。
支持的模型类型：
-
云端商业模型。
-
开源大语言模型。
-
企业私有部署模型。
-
多模态模型。
-
Embedding 模型。
-
Reranker 模型。
-
语音识别与语音合成模型。
模型接入不应让业务应用直接依赖某一个模型供应商。
建议使用统一模型网关。
AI Application
│
▼
Model Gateway
│
├── OpenAI Compatible API
│
├── Cloud Model Provider
│
├── Private LLM
│
├── vLLM Inference
│
└── Embedding / Reranker
模型网关主要功能：
| 功能 | 说明 |
|---|---|
| 模型注册 | 注册模型名称、类型、地址和参数 |
| 模型路由 | 根据任务选择合适模型 |
| 统一接口 | 屏蔽不同模型厂商接口差异 |
| 配额管理 | 按用户、应用和部门控制调用量 |
| 限流熔断 | 防止模型服务过载 |
| 故障切换 | 主模型异常时切换备用模型 |
| 成本统计 | 统计 Token 和调用成本 |
| 调用审计 | 记录模型调用信息 |
模型调用示例：
POST /api/ai/v1/chat/completions
Content-Type: application/json
Authorization: Bearer ${TOKEN}
{
"model": "enterprise-general-model",
"messages": [
{
"role": "user",
"content": "分析当前仓库库存风险"
}
],
"temperature": 0.2,
"stream": true
}
业务应用只需要调用统一接口，不需要了解底层模型部署在哪里。
4.3 Agent Runtime（Agent 运行时）
Agent Runtime 是企业 AI 平台的核心执行引擎。
它负责管理 Agent 从接收任务到完成任务的全过程。
用户请求
│
▼
Agent Runtime
│
├── Intent Analysis
│ 意图识别
│
├── Planning
│ 任务规划
│
├── Context Manager
│ 上下文管理
│
├── Tool Selection
│ 工具选择
│
├── Permission Check
│ 权限校验
│
├── Tool Execution
│ 工具执行
│
├── Result Evaluation
│ 结果评估
│
└── Response Generation
结果生成
Agent Runtime 应具备以下能力：
-
Agent 生命周期管理。
-
任务规划和执行。
-
工具调用。
-
上下文管理。
-
Memory 管理。
-
执行状态管理。
-
超时与重试。
-
检查点和任务恢复。
-
人工审批与任务移交。
-
执行日志和追踪。
需要特别注意：
Agent Runtime 不应该直接绕过企业业务系统的权限控制。
工具调用必须经过完整的安全校验链路：
Authentication
│
▼
Agent
│
▼
Tool Selection
│
▼
Tool Schema Validation
│
▼
Authorization
│
▼
Data Permission
│
▼
Business Rule
│
▼
Risk Check
│
▼
Human Approval
│
▼
Enterprise API
│
▼
ERP / WMS / MES
│
▼
Audit Log
例如，AI 仓库助手可以查询库存、分析缺货风险、生成补货建议，但真正提交采购申请时，仍然需要执行权限校验、业务规则校验和必要的人工审批。
4.4 Workflow Engine（工作流引擎）
Workflow Engine 用于构建可控、可追踪、可恢复的 AI 业务流程。
Agent 更适合处理具有一定自主性的任务，而 Workflow 更适合执行明确的业务流程。
例如：仓库补货流程。
开始
│
▼
查询库存
│
▼
判断库存是否低于安全库存
│
├── 否 ──> 结束
│
▼ 是
分析近期出库趋势
│
▼
计算建议补货数量
│
▼
查询供应商
│
▼
检查采购预算
│
▼
风险校验
│
▼
人工审批
│
▼
提交采购申请
│
▼
同步 ERP
│
▼
结束
Workflow Engine 应支持：
-
流程定义。
-
节点配置。
-
条件分支。
-
并行执行。
-
循环执行。
-
Agent 节点。
-
API 节点。
-
人工审批节点。
-
定时任务。
-
失败重试。
-
超时控制。
-
状态持久化。
-
流程版本管理。
可以使用 LangGraph、Temporal、Camunda、Flowable 等技术实现不同类型的工作流能力。
其中，业务流程编排和长时间运行任务需要特别关注状态持久化、幂等性和故障恢复。
4.5 RAG Engine（知识检索引擎）
RAG Engine 负责为 AI 应用提供企业知识检索能力。
企业知识源
│
├── PDF
├── Word
├── Excel
├── 网页
├── 数据库
└── 业务系统
│
▼
数据接入
│
▼
文档解析
│
▼
文本清洗
│
▼
Chunking
│
▼
Embedding
│
▼
向量数据库
│
▼
Hybrid Search
│
▼
Reranker
│
▼
权限过滤
│
▼
返回相关知识
│
▼
LLM 生成答案
RAG Engine 主要功能：
| 功能 | 说明 |
|---|---|
| 知识源管理 | 接入文件、数据库和业务系统 |
| 文档解析 | 提取文本、表格和结构化内容 |
| 文本切分 | 根据语义和结构生成 Chunk |
| 向量化 | 使用 Embedding 模型生成向量 |
| 向量存储 | 管理知识向量 |
| 混合检索 | 结合关键词和向量检索 |
| 重排序 | 提高检索结果相关性 |
| 权限过滤 | 确保用户只能访问授权知识 |
| 知识更新 | 支持增量更新和重新索引 |
| 效果评估 | 评估召回率、准确率和答案质量 |
企业知识库建设不能只关注向量检索，还必须考虑文档版本、数据权限、知识来源和更新机制。
4.6 Tool Registry（工具注册中心）
Tool Registry 负责统一管理 AI Agent 可以调用的工具。
工具可以来自：
-
企业内部 REST API。
-
Java / Python SDK。
-
MCP Server。
-
数据库查询服务。
-
ERP、WMS、MES 等业务接口。
-
企业内部微服务。
建议统一工具描述规范。
示例：
{
"tool_name": "query_inventory",
"description": "查询指定物料的库存信息",
"method": "POST",
"endpoint": "/api/inventory/query",
"input_schema": {
"type": "object",
"properties": {
"materialCode": {
"type": "string"
},
"warehouseCode": {
"type": "string"
}
},
"required": [
"materialCode",
"warehouseCode"
]
},
"permission": "inventory:query"
}
工具注册中心需要管理：
-
工具基本信息。
-
工具参数 Schema。
-
工具调用地址。
-
工具认证方式。
-
工具授权范围。
-
工具版本。
-
工具调用超时。
-
工具重试策略。
-
工具风险等级。
-
工具调用审计。
MCP 可以作为工具接入的重要协议，但不应把所有企业接口都强制改造成 MCP。REST API、内部 SDK 和 MCP 可以共存，由平台统一管理。
4.7 Prompt Management（提示词管理）
Prompt 是 AI 应用的重要资产，需要从临时文本升级为可管理、可测试、可发布的工程资源。
建议支持：
-
Prompt 模板管理。
-
Prompt 变量管理。
-
Prompt 版本管理。
-
Prompt 发布管理。
-
Prompt 测试。
-
Prompt 评估。
-
Prompt 复用。
-
Prompt 权限控制。
-
Prompt 变更记录。
示例：
你是一名企业仓库管理助手。
请根据以下库存数据分析风险：
物料编码：{{material_code}}
当前库存：{{current_stock}}
安全库存：{{safety_stock}}
近期出库量：{{recent_outbound}}
请输出：
1. 库存风险等级
2. 风险原因
3. 建议补货数量
4. 是否需要人工审批
Prompt 不应直接散落在业务代码中，而应该通过统一管理机制维护版本。
4.8 Memory Service（记忆管理服务）
Memory Service 用于管理 Agent 在任务执行过程中的上下文和记忆。
可以分为：
| 类型 | 作用 |
|---|---|
| Session Memory | 当前会话上下文 |
| Task Memory | 当前任务执行状态 |
| User Memory | 用户授权范围内的偏好信息 |
| Agent Memory | Agent 运行所需的长期知识 |
| Workflow State | 工作流执行状态 |
需要区分记忆和知识库：
-
Memory 主要服务于会话连续性和任务执行。
-
RAG 主要服务于企业知识检索。
-
Workflow State 主要服务于流程恢复和状态管理。
涉及个人信息、业务敏感数据时，应实施明确的访问控制、保留策略和删除机制。
4.9 Evaluation Engine（评估引擎）
企业 AI 平台必须具备统一评估能力。
建议覆盖：
-
模型评估。
-
Prompt 评估。
-
RAG 评估。
-
Agent 评估。
-
Workflow 评估。
-
业务结果评估。
-
安全评估。
常见指标：
| 评估对象 | 关键指标 |
|---|---|
| 模型 | 响应时间、准确性、Token 消耗 |
| RAG | Recall@K、Precision@K、检索相关性 |
| Agent | 任务完成率、工具调用成功率 |
| Workflow | 流程成功率、平均执行时间 |
| 安全 | 越权调用率、风险拦截率 |
| 业务 | 人工节省时间、业务处理效率 |
评估应尽可能使用固定测试集、真实业务样本和人工复核结果，避免仅依赖模型自我评价。
4.10 Guardrails（安全护栏）
Guardrails 是企业 AI 平台的重要安全组件。
需要覆盖：
-
输入内容检测。
-
Prompt Injection 检测。
-
敏感信息识别。
-
输出内容过滤。
-
工具调用权限校验。
-
高风险操作拦截。
-
人工审批。
-
数据脱敏。
-
操作审计。
-
异常行为检测。
对于企业关键业务操作，应采用确定性的权限和业务规则，而不能只依靠大模型判断。
五、统一 API 与 SDK 体系
平台需要为不同类型的 AI 应用提供统一接入方式。
5.1 API 类型
| API 类型 | 使用场景 |
|---|---|
| REST API | 普通业务请求 |
| SSE | AI 流式响应 |
| WebSocket | 双向实时通信 |
| gRPC | 内部高性能服务通信 |
| MCP | Agent 工具与上下文接入 |
5.2 统一接口结构
建议采用统一 API 版本管理：
/api/ai/v1/
models/
chat/
agents/
workflows/
knowledge/
tools/
prompts/
evaluations/
applications/
audit/
5.3 SDK 建设
可以逐步提供：
-
Java SDK。
-
Python SDK。
-
TypeScript SDK。
-
Go SDK。
SDK 负责封装：
-
身份认证。
-
请求签名。
-
API 调用。
-
流式响应。
-
错误处理。
-
超时与重试。
-
请求追踪。
这样企业内部不同技术栈的团队都可以复用统一 AI 平台能力。
六、AI 资产管理与版本体系
企业 AI 平台中的模型、Prompt、Agent、Workflow、知识库和工具，都应该被视为可管理的软件资产。
6.1 AI 资产分类
| 资产类型 | 管理内容 |
|---|---|
| Model Asset | 模型名称、版本、参数和部署信息 |
| Prompt Asset | 提示词模板和版本 |
| Agent Asset | Agent 配置、工具和运行策略 |
| Workflow Asset | 流程定义和节点配置 |
| Knowledge Asset | 知识源、索引和权限 |
| Tool Asset | 工具接口、Schema 和授权 |
| Evaluation Asset | 测试集、评估规则和结果 |
6.2 资产依赖关系
一个 AI 应用通常依赖多个 AI 资产。
AI Warehouse Assistant
│
├── Model: General-LLM
│
├── Prompt: Inventory-Analysis
│
├── Agent: Warehouse-Agent
│ ├── Tool: Query-Inventory
│ └── Tool: Query-Order
│
├── Workflow: Replenishment-Workflow
│
├── Knowledge: Warehouse-KB
│
└── Evaluation: Warehouse-TestSet
当模型或工具版本发生变化时，平台应能够追踪哪些 AI 应用受到影响。
6.3 Release Manifest
建议在发布时生成统一版本清单。
{
"application": "warehouse-assistant",
"version": "1.0.0",
"model": "general-llm@2.1",
"prompt": "inventory-analysis@1.3",
"agent": "warehouse-agent@1.0",
"workflow": "replenishment@1.2",
"knowledge": "warehouse-kb@2026.10",
"evaluation": "warehouse-testset@1.0"
}
通过版本清单，可以实现：
-
发布记录。
-
依赖追踪。
-
版本回滚。
-
变更审计。
-
测试结果关联。
-
生产环境问题定位。
七、多租户与企业组织隔离
在集团型企业中，AI 平台通常需要服务多个部门、子公司和业务团队。
因此必须具备多租户管理能力。
Enterprise AI Platform
│
├── Tenant A：集团总部
│ ├── AI 应用
│ ├── 模型配额
│ └── 知识库
│
├── Tenant B：制造事业部
│ ├── AI 应用
│ ├── 模型配额
│ └── 知识库
│
└── Tenant C：物流事业部
├── AI 应用
├── 模型配额
└── 知识库
多租户管理需要考虑：
-
租户身份隔离。
-
用户和组织隔离。
-
知识库访问隔离。
-
模型调用配额。
-
API 访问权限。
-
Agent 工具授权。
-
数据存储隔离。
-
成本统计隔离。
-
日志和审计隔离。
需要注意，多租户并不意味着一定要为每个部门单独部署一套平台。
可以根据数据敏感等级和业务隔离要求，采用逻辑隔离、独立数据库、独立资源池或独立部署等不同方案。
八、企业 AI 平台技术选型
技术选型应根据企业已有技术体系、部署环境、数据安全要求和团队能力决定。
以下是一套可参考的技术组合。
| 技术领域 | 推荐技术 | 主要用途 |
|---|---|---|
| 前端框架 | Vue 3 / React | 平台管理界面 |
| UI 组件 | Element Plus / Ant Design | 管理端组件 |
| 后端框架 | Spring Boot 3.x | 平台业务服务 |
| AI 服务 | Python / FastAPI | 模型与 AI 引擎服务 |
| API 网关 | Kong / APISIX | 统一 API 接入 |
| Agent 编排 | LangGraph | Agent 执行与状态管理 |
| 工作流 | Temporal / Camunda / Flowable | 业务流程编排 |
| 模型推理 | vLLM | 私有模型推理 |
| 模型管理 | MLflow | 模型实验与版本管理 |
| 关系数据库 | PostgreSQL / MySQL | 业务数据 |
| 缓存 | Redis | 缓存和任务状态 |
| 消息队列 | Kafka / RabbitMQ | 异步任务 |
| 向量数据库 | Milvus / pgvector | 向量检索 |
| 对象存储 | MinIO | 文档和文件存储 |
| 容器平台 | Docker / Kubernetes | 服务部署 |
| 发布管理 | Helm / Argo CD | 应用发布 |
| 监控 | Prometheus / Grafana | 指标监控 |
| 链路追踪 | OpenTelemetry | 分布式追踪 |
| 密钥管理 | Vault | 密钥与凭据管理 |
8.1 为什么采用 Java + Python 双技术体系？
企业 AI 平台往往同时包含两类系统能力。
第一类是传统企业管理能力：
-
用户管理。
-
组织管理。
-
权限管理。
-
租户管理。
-
资源管理。
-
审批管理。
-
操作日志。
-
计费管理。
这些功能适合使用 Java、Spring Boot 等成熟企业开发技术实现。
第二类是 AI 专业能力：
-
模型调用。
-
Agent 执行。
-
RAG 检索。
-
Embedding。
-
Prompt 处理。
-
模型评估。
-
多模态处理。
这些能力通常更适合使用 Python 生态实现。
因此可以采用：
Vue 3 / React
│
▼
API Gateway
│
┌─────────┴─────────┐
│ │
▼ ▼
Java Platform API Python AI Services
│ │
│ ┌────┼────┐
│ │ │ │
│ RAG Agent Model
│ │ │ │
└──────────────┴────┴────┘
│
▼
Database / Redis / MQ
Java 负责平台业务治理，Python 负责 AI 能力执行。
两者通过标准 API、消息机制和服务契约进行协作。
九、企业 AI 平台部署架构
对于大型企业，建议采用分层部署架构。
企业用户
│
▼
WAF / Load Balancer
│
▼
API Gateway
│
┌──────────┴──────────┐
│ │
▼ ▼
Platform Services AI Services
│ │
│ ┌─────┼─────┐
│ │ │ │
│ Model Agent RAG
│ │ │ │
└───────────────┴─────┴─────┘
│
▼
Message Queue
│
┌──────────┼──────────┐
│ │ │
▼ ▼ ▼
MySQL Redis Vector DB
│ │ │
└──────────┴──────────┘
│
▼
Object Storage
│
▼
Enterprise Systems
│
ERP / WMS / MES / CRM
9.1 部署模式
| 部署模式 | 适用场景 |
|---|---|
| 公有云 SaaS | 对私有化要求较低的企业 |
| 私有化部署 | 对数据安全要求较高的企业 |
| 混合云部署 | 兼顾私有数据和云端模型能力 |
| 本地 GPU 集群 | 需要运行私有大模型的企业 |
| Kubernetes 集群 | 多服务、弹性扩展和统一运维 |
9.2 模型资源管理
模型推理资源通常具有较高的 GPU 成本。
平台需要支持：
-
GPU 资源统计。
-
模型实例管理。
-
模型并发控制。
-
模型动态扩缩容。
-
推理任务排队。
-
模型服务健康检查。
-
GPU 利用率监控。
-
模型资源成本核算。
对于模型服务，不应只统计调用次数，还应结合 Token 数量、GPU 使用时间和模型部署成本进行核算。
十、AI 平台可观测性与 FinOps
企业 AI 平台不仅要保证系统运行正常，还需要能够回答：
-
哪个部门使用 AI 最多？
-
哪个 AI 应用成本最高？
-
哪个模型响应速度最快？
-
哪个 Agent 经常执行失败？
-
哪个 Workflow 经常超时？
-
哪些工具调用失败率较高？
-
哪些知识库检索效果较差？
10.1 AI 可观测性
建议建立四类监控体系：
| 监控维度 | 主要指标 |
|---|---|
| 基础设施 | CPU、内存、GPU、网络、磁盘 |
| 模型服务 | 延迟、吞吐量、Token、错误率 |
| Agent 服务 | 任务成功率、工具调用次数、执行时长 |
| 业务应用 | 用户活跃度、任务完成率、业务效果 |
10.2 FinOps 成本管理
FinOps 是企业 AI 平台规模化运营的重要组成部分。
建议按以下维度统计：
AI 成本中心
│
├── 按租户统计
│
├── 按部门统计
│
├── 按应用统计
│
├── 按模型统计
│
├── 按用户统计
│
└── 按任务统计
成本管理需要覆盖：
-
模型调用成本。
-
Token 消耗。
-
GPU 资源成本。
-
向量数据库成本。
-
对象存储成本。
-
外部 API 调用成本。
-
AI 应用整体运营成本。
通过成本分析，企业可以调整模型路由策略，将简单任务分配给成本较低的模型，将复杂任务交给能力更强的模型。
十一、制造企业 AI 平台实战案例
以一家拥有多个工厂、仓库和事业部的大型制造企业为例。
企业计划建设统一 AI 平台，逐步接入 ERP、WMS、MES、设备管理系统和质量管理系统。
11.1 建设目标
第一阶段建设统一 AI 能力中台。
第二阶段建设部门级 AI 应用。
第三阶段实现跨部门 AI 协同。
11.2 应用规划
| AI 应用 | 主要功能 | 接入系统 |
|---|---|---|
| AI 仓库助手 | 库存查询、缺货预警、补货建议 | WMS、ERP |
| AI 生产助手 | 工单查询、生产异常分析 | MES、ERP |
| AI 设备助手 | 故障诊断、维修知识查询 | EAM、MES |
| AI 质量助手 | 不良分析、质量追溯 | QMS、MES |
| AI 采购助手 | 采购分析、供应商查询 | ERP、SRM |
| AI 人事助手 | 员工政策查询、人事流程 | HRM、OA |
| AI 经营助手 | 经营指标分析、管理报告 | ERP、BI |
11.3 AI 仓库助手架构
AI 仓库助手
│
▼
Agent Runtime
│
┌──────────┼──────────┐
│ │ │
▼ ▼ ▼
库存查询 订单查询 知识检索
│ │ │
▼ ▼ ▼
WMS ERP Warehouse KB
│ │ │
└──────────┼──────────┘
│
▼
风险分析
│
▼
补货建议
│
▼
风险校验
│
▼
人工审批
│
▼
采购申请
│
▼
ERP
11.4 业务执行示例
假设某仓库当前存在以下库存风险：
-
12 个 SKU 存在库存风险。
-
8 个 SKU 低于安全库存。
-
3 个 SKU 存在订单积压。
-
1 个 SKU 的生产计划无法满足需求。
AI 仓库助手执行以下任务：
-
调用 WMS 查询库存。
-
调用 ERP 查询采购订单。
-
查询近期出库记录。
-
检索企业补货规则。
-
计算建议补货数量。
-
检查供应商和交期。
-
生成补货分析报告。
-
对高风险操作发起人工审批。
-
审批通过后调用 ERP 创建采购申请。
这里的关键不是让大模型直接操作 ERP，而是通过统一平台的 Agent Runtime、Tool Registry、权限控制、Workflow Engine 和审计机制，完成安全、可控的业务执行。
11.5 建设效果评估
建议使用可量化指标衡量平台建设成果：
| 指标 | 评估目标 |
|---|---|
| AI 能力复用率 | 衡量公共能力被多个应用复用的程度 |
| 应用交付周期 | 衡量 AI 应用从开发到上线的时间 |
| Agent 任务成功率 | 衡量任务执行质量 |
| 工具调用成功率 | 衡量企业系统集成稳定性 |
| RAG 检索质量 | 衡量知识检索效果 |
| 平台可用性 | 衡量平台稳定运行能力 |
| 单位任务成本 | 衡量 AI 运营成本 |
| 安全事件数量 | 衡量平台治理效果 |
具体目标值应根据企业基线、业务复杂度和部署环境制定，不能在没有实际测量的情况下直接承诺固定收益。
十二、企业 AI 平台实施路线
企业 AI 平台建设不建议一次性完成所有模块。
更合理的方式是先建设基础能力，再逐步扩展。
第一阶段：基础平台建设
建议周期：4～6 周，实际以团队规模和现有基础设施为准。
主要任务：
-
建立平台基础工程。
-
建立统一用户认证。
-
建立组织和租户管理。
-
建立模型管理。
-
建立模型网关。
-
建立统一 API。
-
建立基础监控和日志。
阶段成果：具备统一模型接入和基础平台管理能力。
第二阶段：AI 核心引擎建设
建议周期：6～10 周。
主要任务：
-
Agent Runtime。
-
Workflow Engine。
-
RAG Engine。
-
Tool Registry。
-
Prompt Management。
-
Memory Service。
-
基础 AI 应用开发能力。
阶段成果：能够构建和运行企业级 AI 应用。
第三阶段：治理与工程化建设
建议周期：4～8 周。
主要任务：
-
AI 资产管理。
-
版本管理。
-
自动化评估。
-
Guardrails。
-
权限和审计。
-
多租户管理。
-
成本统计。
-
发布与回滚。
阶段成果：具备企业级安全治理和持续交付能力。
第四阶段：规模化运营
建议周期：持续迭代。
主要任务：
-
建设 AI 应用市场。
-
推广部门级 AI 应用。
-
建立 AI 运营体系。
-
优化模型路由。
-
优化推理资源。
-
建立应用效果评估机制。
-
推动 AI 与核心业务流程深度融合。
阶段成果：从单个 AI 项目交付升级为企业 AI 平台持续运营。
十三、企业 AI 平台建设常见问题
13.1 是否应该自己开发 Agent 平台？
不一定。
如果企业主要需求是快速开发 AI 应用，可以优先评估成熟的 Agent 开发框架和平台。
如果企业需要统一权限、业务集成、多租户、私有化部署和审计治理，则需要在成熟技术基础上建设企业自己的平台管理与运行体系。
13.2 是否应该把所有 AI 能力都放在一个系统中？
不建议。
可以统一门户、统一 API 和统一资产管理，但底层模型、Agent、RAG、Workflow 等能力应保持合理的模块边界。
13.3 是否必须采用微服务架构？
不必须。
平台初期可以采用模块化单体或少量核心服务。
当模型推理、Agent 执行、知识处理等模块出现独立扩展需求时，再逐步拆分服务。
架构应服务于实际业务规模，而不是为了微服务而微服务。
13.4 是否所有业务都应该使用大模型？
不是。
对于确定性的业务规则、金额计算、库存校验和权限判断，应优先使用传统程序和规则引擎。
大模型更适合处理自然语言理解、非结构化信息分析、知识问答和复杂任务规划。
13.5 AI 平台是否等于低代码平台？
不是。
AI 平台负责提供模型、Agent、知识库、工具和治理等基础能力。
低代码平台是 AI 平台之上的一种应用开发方式。
企业可以在统一 AI 平台之上，同时支持低代码开发和专业代码开发。
十四、FDE 项目交付检查清单
在企业 AI 平台项目交付前，FDE 应重点检查以下内容。
平台基础能力
-
是否具备统一身份认证？
-
是否支持组织和租户管理？
-
是否具备统一模型网关？
-
是否支持多模型接入？
-
是否具备统一 API 规范？
AI 核心引擎
-
是否具备 Agent Runtime？
-
是否具备 Workflow Engine？
-
是否具备 RAG Engine？
-
是否具备 Tool Registry？
-
是否支持 Prompt 版本管理？
-
是否支持 Memory 和任务状态管理？
工程化能力
-
是否具备 AI 资产管理？
-
是否支持版本发布和回滚？
-
是否具备自动化评估？
-
是否具备统一监控？
-
是否具备成本统计？
-
是否支持故障恢复？
安全治理
-
是否具备数据权限控制？
-
是否具备工具调用授权？
-
是否支持敏感数据保护？
-
是否支持高风险操作审批？
-
是否具备完整审计日志？
-
是否具备安全测试机制？
企业集成
-
是否能够连接 ERP？
-
是否能够连接 WMS？
-
是否能够连接 MES？
-
是否能够连接 CRM、HRM 等系统？
-
是否具备接口异常处理机制？
-
是否支持业务系统数据权限继承？
十五、本章总结
企业 AI 建设的真正挑战，不是如何调用一个大模型，而是如何让 AI 能力在企业内部安全、稳定、可控地持续运行。
当企业 AI 应用从几个发展到几十个、几百个时，单独开发和维护每一个 AI 应用将带来大量重复工作。
企业需要通过统一 AI 平台，将模型、Agent、Workflow、RAG、工具、Prompt、评估、安全和运营能力进行工程化封装。
本章重点介绍了企业级 AI 平台的七层架构，以及模型网关、Agent Runtime、Workflow Engine、RAG Engine、Tool Registry、Prompt Management、Evaluation Engine、多租户、AI 资产管理和 FinOps 等核心模块。
对于 FDE 前沿部署工程师而言，必须逐步建立平台化思维：
不只是交付一个 AI 应用，而是帮助企业建立可以持续开发、持续集成、持续治理和持续运营 AI 应用的基础平台。
下一章预告
第62章：Enterprise AI Developer Platform——企业级 AI 开发者平台与低代码 AI 应用工厂
下一章将进一步深入企业 AI 平台的开发者体验和应用生产体系，重点介绍：
-
AI 平台与 AI Developer Platform 的区别。
-
企业级 AI Developer Portal 架构。
-
AI 应用可视化创建与管理。
-
Prompt IDE 与调试工具。
-
Agent Builder 可视化设计器。
-
Workflow Builder 流程编排。
-
RAG 知识库构建工具。
-
Tool、MCP 与 API 连接器市场。
-
AI 应用模板与组件市场。
-
AI 应用测试、评估与发布。
-
低代码与专业代码协同开发。
-
企业 AI 应用工厂建设模式。
从统一 AI 能力平台，进一步走向标准化、可视化、规模化的企业 AI 应用生产体系。
修正全文中的错别字补充平台模块之间的调用链增加企业 AI 平台数据库设计
更多推荐
1
0- 0
已为社区贡献11条内容
所有评论(0)