一、为什么企业需要 AI Platform Engineering？
在企业 AI 建设的早期阶段，很多团队会从一个具体业务场景开始。
例如：
客服团队开发智能客服 Agent。
仓储团队开发 AI 仓库运营助手。
制造团队开发设备故障分析 Agent。
人力资源团队开发 HR 智能问答助手。
IT 团队开发企业知识库和内部研发助手。
这些应用通常能够快速验证 AI 的业务价值。但随着应用数量增加，新的问题也会逐渐出现。
第一个问题是重复建设。
每个团队都需要处理模型接入、Prompt 管理、RAG 检索、工具调用、权限控制、日志记录和异常处理。同样的基础能力被重复开发，导致维护成本不断增加。
第二个问题是技术栈碎片化。
不同团队可能使用不同的模型供应商、Agent 框架、向量数据库、工作流引擎和部署方式。应用之间难以共享能力，企业也无法统一管理整体 AI 资产。
第三个问题是生产环境难以治理。
模型调用量增加后，企业需要统一处理配额、成本、延迟、故障降级、数据安全、审计和版本管理。如果每个应用独立实现这些机制，系统很容易出现管理盲区。
第四个问题是AI 能力难以复用。
一个业务团队已经建设的知识检索能力、ERP 工具连接器或审批工作流，其他团队往往无法直接使用。
第五个问题是应用上线容易，持续运营困难。
企业不仅需要让 AI 应用运行起来，还需要持续监测质量、评估效果、管理变更、控制成本，并确保应用在模型升级或业务流程变化后仍然可靠。
因此，企业需要从单个 AI 应用建设转向统一的平台能力建设。
这就是 Enterprise AI Platform Engineering 要解决的问题。
二、什么是 Enterprise AI Platform Engineering？
Enterprise AI Platform Engineering，即企业级 AI 平台工程，是通过统一的架构、基础设施、标准接口、开发工具和运营机制，将企业 AI 应用所需的公共能力沉淀为可复用的平台服务。
它的目标不是让所有 AI 应用采用完全相同的技术，而是让它们在统一的治理边界和运行标准下构建。
可以从三个层面理解。
2.1 应用层：解决业务问题
这一层面向业务部门和最终用户。
典型应用包括：
企业知识问答。
AI 客服。
AI 销售助手。
AI 仓库运营助手。
AI 设备维护助手。
AI 财务分析助手。
AI 研发助手。
应用层关注业务流程、用户体验和业务结果，而不是重复建设底层基础设施。
2.2 平台层：提供公共 AI 能力
平台层将通用能力封装成标准服务。
例如：
模型接入与模型路由。
Agent Runtime。
Workflow Engine。
RAG 与知识检索。
Tool Gateway。
Prompt 与配置管理。
AI 身份与权限控制。
评估、追踪和可观测性。
成本、配额和限流。
安全治理与审计。
应用可以组合这些能力，而不必自行实现所有底层逻辑。
2.3 基础设施层：提供运行环境
基础设施层负责支撑平台运行，包括：
CPU、GPU 和推理资源。
容器与 Kubernetes。
网络、负载均衡和服务发现。
数据库、缓存和消息队列。
对象存储与向量数据库。
密钥管理与身份认证。
日志、指标和链路追踪基础设施。
需要注意：企业级 AI 平台并不要求所有组件都由企业自行开发。成熟的开源项目、商业服务和企业现有基础设施，都可以成为平台的一部分。
平台工程的核心，是统一能力的使用方式、运行边界和治理标准，而不是把所有技术重新造一遍。
三、企业级 AI 平台的总体架构
一个可扩展的企业 AI 平台，可以划分为七个逻辑层。
┌───────────────────────────────────────────────┐ │ 业务应用层 │ │ 智能客服 │ 仓库助手 │ 设备维护 │ HR 助手 │研发助手│ └──────────────────────┬────────────────────────┘ ↓ ┌───────────────────────────────────────────────┐ │ AI 接入层 │ │ API Gateway │ 身份认证 │ 限流配额 │ 租户隔离 │ └──────────────────────┬────────────────────────┘ ↓ ┌───────────────────────────────────────────────┐ │ AI 运行层 │ │ Agent Runtime │ Workflow Engine │ Human Review│ └──────────────────────┬────────────────────────┘ ↓ ┌───────────────────────────────────────────────┐ │ AI 能力层 │ │ Model Gateway │ RAG │ Tool Gateway │ Memory │ │ Prompt 管理 │ Context Assembly │ Output Schema│ └──────────────────────┬────────────────────────┘ ↓ ┌───────────────────────────────────────────────┐ │ 企业数据层 │ │ 业务数据库 │ 文档知识库 │ 向量索引 │ 业务 API │ └──────────────────────┬────────────────────────┘ ↓ ┌───────────────────────────────────────────────┐ │ 基础设施层 │ │ Kubernetes │ GPU/CPU │ Cache │ Storage │ MQ │ └───────────────────────────────────────────────┘ 横向贯穿所有层： 安全与治理 │ 可观测性 │ 评估体系 │ 成本管理 │ 生命周期管理这七个逻辑层并不意味着必须部署为七组独立服务。对于规模较小的企业，可以将多个模块部署在同一应用中；随着业务规模增长，再根据性能、可靠性和团队边界进行拆分。
架构设计应当从业务规模、数据敏感程度、部署环境和实际运维能力出发，而不是一开始就追求复杂的微服务架构。
四、统一模型接入：Model Gateway
企业 AI 平台的第一个核心能力，是统一模型接入。
企业可能同时使用云端大模型、私有化部署模型和本地推理模型。
例如：
通用复杂推理使用高能力模型。
简单分类任务使用低成本模型。
敏感数据处理使用企业内部模型。
向量检索使用专门的 Embedding 模型。
文档重排序使用 Reranker 模型。
语音业务使用语音识别与语音合成模型。
如果每个业务应用直接对接不同的模型供应商，应用就会与供应商的 SDK、认证方式和请求格式产生强耦合。
Model Gateway 的作用，是为不同模型提供统一的访问入口。
4.1 核心职责
| 能力 | 作用 |
|---|---|
| 统一 API | 屏蔽不同供应商的请求差异 |
| 模型注册 | 管理模型标识、能力、版本与部署位置 |
| 模型路由 | 根据任务、成本、延迟和策略选择模型 |
| 配额管理 | 限制用户、团队和应用的调用量 |
| 访问控制 | 控制哪些应用可以调用哪些模型 |
| 故障处理 | 执行超时、重试、熔断和降级策略 |
| 成本统计 | 记录 Token、请求量、GPU 用量及费用 |
| 版本管理 | 支持模型切换、灰度发布和回滚 |
4.2 模型路由示例
假设企业仓库助手需要完成三类任务：
查询库存和简单字段解释。
分析库存风险并生成补货建议。
分析复杂异常并生成跨系统处置方案。
平台可以制定如下路由策略：
| 任务类型 | 模型策略 | 主要考虑 |
|---|---|---|
| 简单分类、字段解释 | 低成本模型 | 低延迟、低成本 |
| 库存风险分析 | 通用推理模型 | 质量与成本平衡 |
| 复杂异常分析 | 高能力模型 | 推理质量优先 |
| 敏感业务数据处理 | 符合数据策略的内部模型 | 数据边界与合规 |
这里需要区分模型路由与模型降级。
模型路由是在请求执行前选择合适的模型；模型降级则是在服务异常、超时或容量不足时，按照预先验证的策略切换备用能力。
不能仅因为备用模型可用，就假定它能够提供相同质量的结果。涉及财务、库存扣减、生产调度等关键业务时，降级策略必须经过验证，必要时应拒绝执行或转人工处理。
4.3 统一接口示例
下面给出一个简化的模型网关请求：
{ "application_id": "warehouse-assistant", "task_type": "inventory_risk_analysis", "model_policy": "balanced", "input": { "warehouse_id": "WH-001", "question": "分析当前库存风险" }, "metadata": { "trace_id": "trace-001" } }平台根据应用身份、任务类型、模型策略和数据分类，决定调用哪个模型，并返回统一格式的结果。
实际生产环境还需要定义超时、错误码、输出格式、流式响应、取消请求和用量统计等协议。
此外，统一模型接口并不能消除所有模型差异。工具调用、结构化输出、上下文窗口、推理能力和多模态支持都需要通过能力声明与兼容性测试进行管理。
五、统一 Agent Runtime：让 Agent 有标准运行环境
Agent Runtime 是企业 AI 平台中负责运行 Agent 的核心组件。
如果说模型网关解决的是“如何调用模型”，那么 Agent Runtime 解决的就是“如何安全、可靠地运行一个具备多步执行能力的 AI Agent”。
一个企业级 Agent 通常包含以下步骤：
接收业务请求。
加载用户身份和业务上下文。
读取 Agent 配置和执行策略。
调用模型生成计划。
判断是否需要调用工具。
执行工具并获取结果。
根据结果继续推理或进入审批。
验证最终输出。
返回结果并记录执行轨迹。
5.1 Agent Runtime 的主要职责
Agent 实例创建与销毁。
执行状态管理。
步骤调度与执行次数限制。
工具调用协调。
上下文和记忆加载。
超时、取消和中断处理。
失败恢复与人工介入。
输出结构校验。
执行日志和追踪。
并发、资源与成本控制。
5.2 Agent 执行状态机
可以将 Agent 的执行过程抽象为一个状态机：
┌──────────┐ │ CREATED │ └────┬─────┘ ↓ ┌──────────┐ │ RUNNING │ └────┬─────┘ ↓ ┌──────────────┐ │ 需要调用工具？│ └───┬──────┬───┘ │是 │否 ↓ ↓ ┌──────────┐ ┌──────────┐ │TOOL_CALL │ │ VALIDATE │ └────┬─────┘ └────┬─────┘ ↓ ↓ ┌──────────┐ ┌──────────┐ │TOOL_RESULT│ │ COMPLETED│ └────┬─────┘ └──────────┘ ↓ 返回 RUNNING 异常或超时 → FAILED / CANCELLED 需要人工审批 → WAITING_FOR_APPROVAL 可恢复的中断 → PAUSED / RESUMABLE这是一种逻辑状态设计。具体状态及其转换规则应根据 Agent 的业务需求进一步细化。
例如，当 Agent 需要人工审批时，不应让一个 HTTP 请求无限等待。平台应持久化执行状态，返回任务标识，并通过事件、轮询或回调机制通知后续执行。
5.3 为什么需要持久化执行状态？
企业 Agent 可能执行数分钟甚至更长时间。
假设一个生产异常处理 Agent 需要：
查询 MES 生产记录。
查询设备历史告警。
检索维修知识库。
分析异常原因。
生成维修建议。
等待工程师审批。
审批通过后创建维修工单。
如果整个流程只存在于内存中，服务重启、网络故障或审批等待都可能导致执行上下文丢失。
因此，生产级 Agent Runtime 通常需要：
持久化执行实例。
保存步骤输入和输出。
记录状态变更。
保存人工审批状态。
支持任务恢复与取消。
防止重复执行产生副作用。
这里还要注意：持久化执行状态不等于自动获得业务事务能力。跨系统执行仍然需要幂等键、事务边界、补偿机制和业务状态核验。
六、统一 Workflow Engine：将 AI 与确定性流程结合
并不是所有业务都应该交给 Agent 自由决策。
对于流程固定、规则明确、合规要求高的业务，Workflow Engine 往往比纯 Agent 更合适。
例如：
员工入职审批。
采购申请。
库存盘点。
付款审批。
设备维修工单。
生产异常处理。
企业 AI 平台需要同时支持 Agent 和 Workflow，并让两者能够协同工作。
6.1 Agent 与 Workflow 的职责区别
| 对比项 | Agent | Workflow |
|---|---|---|
| 核心特点 | 根据上下文进行动态决策 | 按预定义流程执行 |
| 流程结构 | 可动态调整 | 通常预先定义 |
| 适合任务 | 信息分析、计划生成、复杂问题处理 | 审批、交易、固定业务流程 |
| 执行路径 | 可能随模型判断变化 | 主要由流程定义决定 |
| 结果确定性 | 需要额外约束和验证 | 更容易进行确定性控制 |
| 主要风险 | 错误推理、错误工具选择 | 流程配置错误、状态管理错误 |
两者不是相互替代的关系。
Agent 擅长处理模糊问题，Workflow 擅长执行明确流程。企业平台需要根据任务特征选择合适的执行方式。
6.2 Agent + Workflow 的协作模式
以仓库库存异常为例：
库存数据与订单数据 ↓ Workflow：定时触发库存检查 ↓ Agent：分析库存风险 ↓ 结构化风险结果 ↓ Workflow：校验风险规则 ↓ 是否需要人工审批？ ┌────┴────┐ ↓ ↓ 需要 不需要 ↓ ↓ 人工审批 仅生成建议 ↓ Workflow：执行授权操作 ↓ ERP/WMS 更新 ↓ 核验执行结果并记录审计在这个架构中：
Agent 负责分析、解释和生成建议。
Workflow 负责执行固定步骤和控制流程状态。
业务系统负责执行真正的库存或订单操作。
权限与治理层决定哪些操作可以执行。
可观测性系统记录从发现问题到完成处置的全过程。
这种设计可以降低 Agent 自由执行带来的风险，同时保留 AI 的灵活性。
七、统一 RAG 与企业知识服务
企业 AI 应用通常需要访问内部知识，包括制度文件、产品资料、技术文档、操作手册和业务规范。
如果每个应用独立搭建知识库，就会产生重复的数据处理链路和不一致的权限控制。
因此，企业 AI 平台应当将 RAG 能力建设为可复用的知识服务。
7.1 RAG 平台的核心模块
| 模块 | 主要职责 |
|---|---|
| 数据连接器 | 接入文档、数据库、业务系统和对象存储 |
| 文档解析 | 提取文本、表格、元数据和结构信息 |
| 文档切分 | 根据文档结构和检索需求生成片段 |
| Embedding | 将文本转换为向量表示 |
| 索引管理 | 管理向量索引、关键词索引和版本 |
| 检索引擎 | 执行关键词、向量或混合检索 |
| Reranker | 对候选结果进行相关性重排 |
| 权限过滤 | 根据用户和数据权限过滤内容 |
| Context Assembly | 将检索结果组织成模型上下文 |
| 质量评估 | 评估检索相关性、覆盖率和回答依据 |
7.2 为什么不能只建设一个向量数据库？
向量数据库只是知识检索链路中的一个组件。
企业知识服务还需要处理：
数据源连接与增量同步。
文档版本管理。
权限继承与动态过滤。
多语言文档检索。
文档删除与索引清理。
关键词与语义检索的组合。
检索结果的来源追踪。
检索质量的持续评估。
例如，某员工只能查看自己所在部门的制度文件。即使系统能够检索到其他部门的文档，也不能因为语义相关就把它们交给模型。
因此，权限过滤必须成为检索链路中的正式控制措施，而不是在回答生成之后才进行简单检查。
对于权限变化频繁或高敏感度的数据，应在检索时验证当前权限，并避免仅依赖长期缓存的权限结果。
7.3 统一知识服务接口
应用不应直接依赖某一种向量数据库的查询接口，而应通过企业知识服务访问内容。
示例：
{ "application_id": "hr-assistant", "knowledge_scope": "hr-policy", "query": "员工年假如何申请？", "filters": { "language": "zh-CN" }, "top_k": 5 }平台根据用户身份、知识范围、语言和权限策略执行检索，并返回经过授权的内容片段及其来源信息。
需要强调的是，示例中的filters不是授权凭证。真实系统必须根据已认证的用户身份，在服务端计算和校验权限，不能允许调用方通过修改请求参数扩大访问范围。
八、统一 Tool Gateway：管理企业系统的工具调用
企业 Agent 的价值不仅在于回答问题，还在于能够与 ERP、CRM、WMS、MES、HRM 和其他业务系统交互。
但直接把业务系统接口暴露给模型，会带来一系列风险：
模型可能选择错误的工具。
参数可能不完整或不符合业务规则。
调用方可能越权访问数据。
网络重试可能导致重复操作。
高风险操作可能绕过审批。
工具调用可能成为间接提示注入的攻击入口。
因此，企业平台需要建立统一的 Tool Gateway。
8.1 Tool Gateway 的主要能力
工具注册与发现
统一登记工具名称、功能说明、参数结构、所属系统、版本和负责人。
身份与权限控制
根据用户、应用、Agent、工具及业务资源的授权关系，判断请求是否允许执行。
参数校验
验证必填字段、数据类型、枚举范围、业务约束和参数长度。
调用治理
统一处理超时、限流、错误码、重试和调用记录。
风险控制
针对查询、写入、删除、付款、库存调整等不同风险等级设置不同的执行策略。
审计与追踪
记录谁发起请求、哪个 Agent 调用了什么工具、使用了哪些参数、返回了什么结果，以及最终产生了什么业务影响。
8.2 工具应当按照风险分级
| 工具类型 | 示例 | 推荐控制措施 |
|---|---|---|
| 只读查询 | 查询库存、查询订单 | 身份校验、数据权限、审计 |
| 低风险写入 | 创建草稿、生成建议 | 参数校验、幂等控制 |
| 业务变更 | 修改排班、调整库存 | 业务规则、权限校验、审批策略 |
| 高风险操作 | 付款、批量删除、关键生产控制 | 强授权、明确审批、执行确认、完整审计 |
并非所有写操作都必须人工审批，也并非所有只读操作都天然安全。具体控制应根据数据敏感度、操作影响、用户权限和业务风险确定。
8.3 Tool Gateway 的执行链路
Agent 请求调用工具 ↓ 解析工具标识与参数 ↓ 验证调用者身份 ↓ 检查工具权限与数据权限 ↓ 校验参数与业务约束 ↓ 风险评估与审批判断 ↓ 执行授权的业务 API ↓ 验证业务系统执行结果 ↓ 记录审计、成本和追踪信息 ↓ 向 Agent 返回受控结果一个关键原则是：模型可以提出操作请求，但是否允许操作，必须由可信的服务端策略决定。
模型输出不能替代身份认证、授权判断或业务系统的最终校验。
九、统一身份、安全与多租户管理
企业 AI 平台通常服务多个部门、业务系统和应用团队，因此需要建立统一的身份与访问控制机制。
平台至少应区分以下几类身份：
人类用户。
业务应用。
Agent 实例。
平台服务。
工具连接器。
外部模型服务。
这些身份具有不同的职责和权限，不能简单地共享同一个服务账号。
9.1 采用分层授权模型
可以从四个维度进行权限管理：
用户权限：用户是否有权访问相关业务数据。
应用权限：当前应用可以使用哪些平台能力。
Agent 权限：当前 Agent 在特定任务中可以调用哪些工具。
资源权限：调用涉及的具体数据、记录和业务对象是否允许访问。
最终的授权决策应综合这些约束。
例如，员工有权查看某个仓库的库存，不代表仓库 Agent 可以修改该仓库的库存；Agent 有权调用库存修改工具，也不代表当前用户有权发起库存调整。
9.2 多租户隔离
企业集团或平台型企业可能需要同时服务多个组织、子公司和业务团队。
多租户平台应考虑：
租户级身份与权限隔离。
配额和资源预算隔离。
知识库与索引隔离策略。
模型调用策略隔离。
日志与审计数据隔离。
配置和密钥隔离。
备份、恢复和数据保留策略。
不同数据的隔离要求可能不同。可以采用逻辑隔离、独立数据库、独立索引或独立部署等方式，并根据安全等级、成本和运维能力进行选择。
十、统一 AI Observability：从模型请求到业务结果
企业 AI 平台不能只记录模型调用是否成功。
对于复杂 Agent，一个业务请求可能经过多个模型调用、知识检索、工具执行、审批等待和业务系统更新。只有统一的追踪体系，才能还原完整的执行过程。
10.1 建立统一 Trace
每个业务请求都应有唯一的 Trace ID，并将相关的执行步骤关联起来。
业务请求 Trace │ ├── Context Assembly │ ├── 用户上下文加载 │ └── 权限校验 │ ├── RAG Retrieval │ ├── 向量检索 │ └── 结果重排 │ ├── Model Invocation │ └── 模型生成 │ ├── Tool Invocation │ └── WMS 查询库存 │ ├── Human Approval │ └── 等待审批 │ └── Business Result └── 库存调整结果核验Trace 不仅用于排查故障，还可以用于分析业务流程中的性能瓶颈、成本分布和执行质量。
10.2 统一观测指标
| 指标类别 | 示例 |
|---|---|
| 模型指标 | 请求成功率、延迟、Token 使用量 |
| Agent 指标 | 任务完成率、平均步骤数、失败率 |
| RAG 指标 | 检索延迟、相关性、引用覆盖率 |
| 工具指标 | 调用成功率、超时率、重复请求数 |
| Workflow 指标 | 流程完成率、等待时间、失败节点 |
| 业务指标 | 问题解决率、处理时长、人工接管率 |
| 成本指标 | 单任务成本、团队成本、模型成本分布 |
| 安全指标 | 越权拦截数、策略拒绝数、异常调用数 |
对于跨多个服务的请求，平台还应明确 Trace 的传播规则，并通过统一的日志、指标和链路追踪标准建立关联。
10.3 观测不等于评估
Observability 主要回答：
系统发生了什么？
哪个步骤出现了问题？
为什么任务延迟？
成本消耗在哪里？
哪个服务发生了故障？
Evaluation 则主要回答：
回答是否正确？
检索内容是否相关？
Agent 是否选择了合适的工具？
任务是否真正解决了业务问题？
新版本是否比旧版本更好？
两者应当共享追踪数据，但不能相互替代。
同时，日志中可能包含员工信息、客户数据、Prompt、检索内容和工具参数。平台应按数据敏感等级实施脱敏、访问控制、留存期限和审计策略，避免为了可观测性而扩大敏感数据暴露范围。
十一、统一评估体系：让 AI 能力可以比较
传统软件通常通过单元测试、集成测试和端到端测试验证行为。
AI 系统具有概率性，同样的输入可能产生不同输出。因此，企业 AI 平台还需要提供专门的评估能力。
11.1 建立统一评估流程
测试数据集 ↓ 固定评估场景 ↓ 执行模型 / Agent / Workflow ↓ 采集输入、输出与执行轨迹 ↓ 规则校验 + 自动评分 + 人工复核 ↓ 生成评估报告 ↓ 与基线版本比较 ↓ 通过门槛后进入发布流程11.2 不同层级的评估内容
模型层
任务准确率。
结构化输出合格率。
指令遵循能力。
延迟与成本。
安全拒答表现。
RAG 层
检索相关性。
关键证据召回率。
引用准确性。
权限过滤正确性。
知识更新后的检索表现。
Agent 层
工具选择正确率。
参数生成合格率。
任务完成率。
无效循环比例。
错误操作拦截率。
业务层
业务问题解决率。
人工处理时长变化。
业务错误率。
处理成本变化。
用户满意度。
自动评分模型可以帮助扩大评估规模，但不能作为所有场景的唯一判断依据。对高风险任务，应结合确定性规则、真实业务结果和人工复核。
11.3 评估必须进入发布门禁
当模型、Prompt、知识索引、Agent 工具或 Workflow 发生变更时，应重新执行与变更范围相关的测试。
例如：
更换模型，需要验证回答质量、延迟和成本。
修改 Prompt，需要验证任务完成率和安全边界。
修改 RAG 切分策略，需要验证检索和引用表现。
新增写入工具，需要验证授权、参数校验和幂等性。
修改审批流程，需要验证状态转换与异常恢复。
对于影响面较大的变更，可以增加影子测试、灰度发布和回滚机制。
十二、平台工程的开发者体验：Developer Portal 与 SDK
企业 AI 平台的成功不仅取决于底层架构，还取决于业务开发团队是否容易使用。
如果开发者必须理解所有模型供应商、部署组件、认证协议和底层数据库，平台就没有真正降低复杂度。
因此，需要提供统一的开发者入口。
12.1 Developer Portal 的主要功能
创建 AI 应用。
注册和配置 Agent。
选择模型策略。
创建知识检索服务。
注册工具与连接器。
配置 Workflow。
管理 Prompt 和版本。
运行评估任务。
查看调用日志和执行 Trace。
查看成本和配额。
管理发布与回滚。
申请平台能力和权限。
12.2 提供统一 SDK
以 Python 为例，可以设计一个简化的调用方式：
from enterprise_ai import AIPlatform client = AIPlatform( endpoint="https://ai-platform.example.com", application_id="warehouse-assistant" ) result = client.agents.run( agent_id="inventory-risk-agent", input={ "warehouse_id": "WH-001", "task": "分析库存风险" } ) print(result.status) print(result.output)这只是一个说明接口设计思路的示例，并非某个现成 SDK 的实际调用代码。
在真实实现中，还需要考虑凭证获取、短期令牌、请求超时、异步任务、流式输出、取消执行、异常类型、版本兼容和 Trace 上下文传播等问题。
12.3 建立平台模板
平台可以提供经过验证的应用模板，例如：
企业知识问答模板。
只读查询 Agent 模板。
RAG + Agent 模板。
Agent + Workflow 审批模板。
多工具协同模板。
批量数据分析模板。
人工审批与任务恢复模板。
模板不仅应该包含代码，还应包含权限配置、监控指标、评估数据、部署规范和风险控制策略。
好的平台不是限制开发者，而是让开发者能够更快地构建符合企业标准的应用。
十三、统一配置、版本与生命周期管理
企业 AI 平台会同时管理大量模型、Agent、Prompt、知识库、工具和工作流。
如果这些对象缺乏版本和依赖关系管理，系统变更就很难控制。
13.1 将 AI 资产纳入统一管理
| 资产类型 | 应管理的内容 |
|---|---|
| 模型 | 供应商、版本、能力、部署位置 |
| Prompt | 内容、版本、变量、评估结果 |
| Agent | 配置、工具依赖、运行策略 |
| Workflow | 流程定义、状态规则、版本 |
| 知识库 | 数据源、索引版本、权限策略 |
| Tool | 参数 Schema、权限、版本、负责人 |
| 应用 | 依赖关系、环境、发布记录 |
| 评估集 | 数据版本、评分规则、基线结果 |
13.2 建立依赖关系图
一个 Agent 可能依赖：
一个模型策略。
两个知识库。
三个业务工具。
一个 Workflow。
一套输出 Schema。
一组安全策略。
当其中一个组件发生变更时，平台应能够识别受影响的应用。
例如，WMS 查询工具修改了参数结构，平台应定位依赖该工具的 Agent，触发兼容性测试，并在必要时阻止不兼容版本发布。
13.3 配置即代码
对于需要严格版本控制的配置，可以采用 Configuration as Code 或 GitOps 思路。
配置变更 ↓ 提交代码仓库 ↓ 自动校验 Schema ↓ 执行安全与权限检查 ↓ 运行评估和回归测试 ↓ 审批与发布 ↓ 灰度部署 ↓ 监控运行结果 ↓ 成功推广 / 失败回滚并不是所有运行时数据都应该存入 Git。敏感凭证、业务数据、执行状态和大规模评估结果通常需要使用专门的存储和密钥管理机制。
平台应明确区分：
可版本化的声明式配置。
需要安全保存的密钥。
需要持久化的运行状态。
需要审计的变更事件。
需要长期留存的评估与业务证据。
十四、企业 AI 平台的可靠性设计
统一平台会成为多个 AI 应用的共同依赖，因此平台故障可能影响大量业务。
这意味着平台本身也需要可靠性工程。
14.1 识别关键故障点
常见故障包括：
模型供应商不可用。
GPU 资源耗尽。
模型请求持续超时。
向量数据库不可用。
Tool Gateway 出现故障。
Workflow 状态存储异常。
认证服务不可用。
任务队列积压。
单个租户占用过多资源。
14.2 采用分层保护机制
超时控制
为模型、检索、工具和整体任务分别设置超时预算，避免下游阻塞无限传播。
限流与配额
控制应用、租户、模型和工具的并发及调用量，避免单一业务挤占平台资源。
熔断与降级
当依赖服务持续失败时，暂时停止部分调用，避免故障扩散。降级行为应明确，不能将不可靠结果伪装成成功结果。
异步任务与队列
将长时间运行的任务转为异步执行，支持状态查询、任务取消和恢复。
隔离与资源调度
根据业务优先级、租户和工作负载类型分配资源，避免批量离线任务影响在线关键业务。
幂等与补偿
对可能产生副作用的工具调用建立幂等机制，并对跨系统流程设计可恢复和可补偿的业务步骤。
备份与恢复
对执行状态、配置、审计数据和关键索引制定备份及恢复策略，并通过演练验证恢复能力。
14.3 为不同业务定义不同 SLO
平台不应为所有 AI 任务设置相同的服务目标。
例如：
| 业务类型 | 重点关注 |
|---|---|
| 在线客服 | 响应延迟、可用性、问题解决率 |
| 批量文档处理 | 吞吐量、任务完成率、处理成本 |
| 设备异常分析 | 分析质量、告警时效、可追溯性 |
| 财务辅助分析 | 数据正确性、权限控制、审计完整性 |
| 高风险业务操作 | 授权正确性、重复操作防护、结果核验 |
表中的指标需要由企业根据业务需求定义具体目标，不能直接将示例当作生产承诺。
十五、平台成本工程：让 AI 规模化之后仍然可控
AI 应用的成本不只来自模型 Token。
企业还需要考虑 GPU 推理资源、Embedding、Reranker、向量数据库、对象存储、网络流量、日志存储和运维成本。
15.1 建立分层成本模型
可以将总成本拆分为：
[
C_{\text{total}} =
C_{\text{model}} +
C_{\text{compute}} +
C_{\text{retrieval}} +
C_{\text{storage}} +
C_{\text{network}} +
C_{\text{operations}}
]
其中：
(C_{\text{model}})：模型调用成本。
(C_{\text{compute}})：CPU、GPU 和推理服务成本。
(C_{\text{retrieval}})：检索、Embedding 与重排序成本。
(C_{\text{storage}})：数据库、对象存储与日志存储成本。
(C_{\text{network}})：网络传输成本。
(C_{\text{operations}})：部署、运维和平台管理成本。
企业应根据实际计费方式建立成本口径。对于自建模型，GPU 成本可以按资源占用时间、吞吐量或内部成本分摊规则核算。
15.2 从单次调用转向单个业务任务成本
只看 Token 数量，无法判断一个 AI 应用是否真正具有经济价值。
假设仓库运营助手完成一次库存风险分析，需要执行：
查询业务数据。
检索相关制度。
调用模型分析。
生成补货建议。
进行结果校验。
企业应将这些步骤的成本汇总为单个业务任务成本。
更重要的是，还要将其与业务结果联系起来。
例如：
每发现一个真实库存风险的成本。
每完成一次有效客服处理的成本。
每生成一份通过审核的分析报告的成本。
每减少一小时人工处理时间的成本。
只有当平台能够同时统计成本和业务结果时，企业才能判断 AI 应用是否值得扩大投入。
15.3 平台成本优化策略
根据任务复杂度进行模型路由。
减少重复上下文和无效工具调用。
对适合缓存的结果实施缓存。
优化 RAG 检索与重排序链路。
控制 Agent 最大步骤数和循环次数。
为离线任务安排合适的资源窗口。
建立租户级预算、告警和配额。
通过评估验证优化前后的质量变化。
成本优化不能以牺牲必要的安全控制、数据正确性和业务可靠性为代价。
十六、实战案例：构建 AI 仓库运营平台
假设一家制造企业拥有多个仓库，并且已经运行 ERP、WMS 和 MES 系统。
企业计划建设 AI 仓库运营助手，用于识别库存风险、分析订单积压、生成补货建议，并在授权后协助创建业务任务。
16.1 业务需求
系统需要实现：
定期扫描库存风险。
查询订单与生产计划。
检索安全库存制度。
分析库存不足和订单积压原因。
生成补货或协调建议。
对高风险操作执行审批。
将执行结果同步到业务系统。
记录完整的执行过程和业务结果。
16.2 平台能力映射
| 业务需求 | 平台能力 |
|---|---|
| 访问不同模型 | Model Gateway |
| 运行库存分析 Agent | Agent Runtime |
| 定时执行库存检查 | Workflow Engine |
| 查询安全库存制度 | RAG Knowledge Service |
| 查询 ERP/WMS 数据 | Tool Gateway |
| 管理用户和应用权限 | Identity & Access Control |
| 审批补货操作 | Human Review / Workflow |
| 追踪任务执行过程 | Observability |
| 评估分析质量 | Evaluation Service |
| 统计单任务成本 | Cost Management |
| 管理变更和审计 | Governance & Lifecycle |
16.3 端到端执行流程
定时触发库存检查 ↓ Workflow 获取待检查仓库 ↓ 通过 Tool Gateway 查询 WMS / ERP / MES ↓ RAG 检索安全库存与业务制度 ↓ Agent 分析库存、订单和生产风险 ↓ 输出结构化风险清单 ↓ 规则引擎进行业务校验 ↓ 生成处置建议 ↓ 是否涉及需要审批的业务操作？ ├── 是 → 人工审批 → 授权执行 └── 否 → 返回分析与建议 ↓ 业务系统确认执行结果 ↓ 记录 Trace、审计、成本和业务指标 ↓ 进入后续评估与优化16.4 示例输出
假设某次检查发现：
8 个 SKU 低于安全库存。
3 个 SKU 存在订单积压。
1 个 SKU 的生产计划无法满足需求。
Agent 不应直接把这些发现视为最终业务事实，而应提供可核验的证据，例如库存记录、订单状态、计划交期和制度来源。
平台应将分析结果转换为标准结构，并交给确定性规则进行校验。
例如：
{ "task_id": "inventory-risk-001", "warehouse_id": "WH-001", "risk_summary": { "below_safety_stock": 8, "order_backlog": 3, "production_plan_gap": 1 }, "recommendations": [ { "type": "replenishment_review", "status": "pending_review", "requires_approval": true } ] }这只是示例结构，不代表真实运行结果。
平台需要验证风险记录与业务系统数据是否一致，并确保推荐措施具有来源依据。真正的库存调整或采购创建操作，应由经过授权的业务接口执行。
16.5 业务价值评估
平台上线后，应重点比较上线前后的实际指标：
库存风险发现时效。
人工排查时间。
风险分析准确率。
补货建议采纳率。
误报率与漏报率。
任务执行失败率。
人工审批等待时间。
单次有效风险处置成本。
不能仅凭 Agent 输出了多少条建议，就认定项目成功。真正的价值来自经过核验的风险识别、有效的业务处置和可衡量的运营改善。
十七、如何分阶段建设企业 AI 平台？
企业不必一开始就建设完整的平台。更合理的方式是从少量高复用能力开始，逐步扩大覆盖范围。
阶段一：统一接入与基本治理
建设内容：
统一模型接入。
应用身份管理。
基本配额和限流。
请求日志与 Trace ID。
模型成本统计。
基础安全策略。
目标是解决模型接入分散、权限不统一和调用不可追踪的问题。
阶段二：建设公共 AI 能力
建设内容：
Agent Runtime。
RAG Knowledge Service。
Tool Gateway。
Prompt 与配置管理。
结构化输出校验。
基础评估框架。
目标是让不同业务团队能够复用公共能力，而不必从头构建完整技术链路。
阶段三：建设生产级运行体系
建设内容：
Workflow Engine。
持久化任务状态。
任务恢复和取消。
人工审批。
熔断、降级和幂等机制。
完整的评估门禁。
灰度发布和回滚。
目标是让 AI 应用具备稳定运行和受控执行能力。
阶段四：平台化运营
建设内容：
Developer Portal。
多租户管理。
成本分摊与预算。
资产依赖图。
治理策略自动化。
统一质量评估。
平台服务目录。
自助式应用部署。
目标是让平台成为企业 AI 应用的标准开发与运营入口。
阶段五：持续优化与规模化
建设内容：
多模型策略优化。
资源调度优化。
统一业务效果评估。
跨应用能力复用。
平台容量规划。
自动化风险检测。
基于真实业务反馈的持续优化。
目标是让平台能够支持更多业务场景，并在规模增长时持续控制风险、成本和复杂度。
十八、企业 AI 平台的技术选型原则
平台可以使用不同技术栈实现，但选型应当围绕能力边界，而不是单纯追逐技术热点。
| 能力领域 | 可考虑的技术方向 | 选型关注点 |
|---|---|---|
| API 接入 | API Gateway、反向代理 | 身份认证、限流、路由 |
| 模型接入 | 统一模型网关、自建适配层 | 模型兼容、路由、用量统计 |
| Agent Runtime | Agent 框架、状态机、持久化执行引擎 | 状态恢复、工具治理、可追踪性 |
| Workflow | 工作流引擎、事件驱动流程 | 长流程、审批、补偿、恢复 |
| RAG | 文档解析、检索、重排序组件 | 权限过滤、质量评估、数据更新 |
| Tool Gateway | 工具注册中心、受控 API 代理 | 授权、参数校验、幂等、审计 |
| 数据存储 | 关系数据库、对象存储、向量数据库 | 数据规模、一致性、备份恢复 |
| 任务调度 | 消息队列、任务执行器 | 削峰填谷、重试、死信处理 |
| 可观测性 | OpenTelemetry 及日志、指标、追踪系统 | 跨服务关联、数据脱敏 |
| 部署运行 | Docker、Kubernetes | 资源隔离、弹性扩缩、运维能力 |
| 配置管理 | Git、配置中心、GitOps | 版本、审批、回滚 |
| 安全治理 | IAM、密钥管理、策略引擎 | 最小权限、审计、策略执行 |
这些是技术方向，而非必须采用的唯一产品组合。
企业应优先评估现有基础设施和团队能力。对于早期项目，采用模块化单体、少量独立服务和托管基础设施，往往比一次性构建庞大的分布式平台更容易成功。
随着应用数量、并发规模、团队边界和故障隔离需求增长，再将模型网关、执行引擎、检索服务和工具网关拆分为独立服务。
十九、平台工程的常见误区
误区一：把平台理解为一个统一聊天入口
统一聊天界面可以是平台的一个组成部分，但它不是平台的全部。
真正的平台还需要管理模型、运行时、工作流、数据、工具、身份、评估、成本和治理。
误区二：认为所有应用都必须使用同一个 Agent 框架
企业需要统一的是接口、能力标准、运行约束和治理方式，而不是强制所有团队使用同一种实现技术。
对于简单任务，普通业务服务可能比 Agent 更合适；对于固定流程，Workflow 可能比自由规划更可靠。
误区三：一开始就把所有组件拆成微服务
过早拆分会增加网络调用、部署、监控和故障排查的复杂度。
平台架构应当根据真实负载、独立扩缩容需求、安全边界和团队协作方式逐步演进。
误区四：只统一模型接口，不统一安全策略
模型网关只能解决一部分问题。如果 Agent 可以绕过统一工具网关直接调用业务系统，企业仍然无法形成完整的执行控制链路。
误区五：只监控 Token 和延迟，不监控业务结果
模型调用成功不代表业务任务成功。
平台必须把技术指标与业务指标关联起来，才能判断 AI 是否真正产生价值。
误区六：平台建成后不再持续评估
模型、Prompt、知识数据和业务流程都会变化。
没有持续评估和变更管理，平台上的应用可能在不知不觉中出现质量下降、成本上升或风险扩大。
二十、企业 AI 平台成熟度模型
企业可以通过以下五个阶段评估平台建设水平。
| 阶段 | 成熟度 | 主要特征 |
|---|---|---|
| L1 | 单点应用 | 各团队独立开发，能力重复 |
| L2 | 基础统一 | 统一模型接入、身份和日志 |
| L3 | 能力平台化 | Agent、RAG、工具和工作流可复用 |
| L4 | 生产工程化 | 具备评估、灰度、恢复、成本和治理体系 |
| L5 | 规模化运营 | 统一运营多个业务域，持续优化资源与业务价值 |
成熟度不应只看平台拥有多少功能，还应关注平台能力的真实采用情况。
例如：
有多少应用使用统一模型网关。
有多少工具通过统一权限控制。
有多少 Agent 接入自动化评估。
有多少生产任务具备完整 Trace。
有多少高风险操作实现审批与审计。
有多少应用能够统计单任务成本和业务效果。
这些指标可以帮助企业判断平台是否真正减少了重复建设和运营风险。
二十一、本章总结
Enterprise AI Platform Engineering 的核心，是把企业 AI 从孤立的应用项目，升级为统一、可复用、可治理、可持续运营的能力体系。
一个成熟的企业 AI 平台，应当将以下能力组织成完整的工程闭环：
Model Gateway：统一模型接入、路由、配额与成本管理。
Agent Runtime：提供 Agent 的标准执行环境和状态管理。
Workflow Engine：负责确定性流程、审批与任务恢复。
RAG Knowledge Service：统一企业知识检索与权限控制。
Tool Gateway：安全管理企业系统的工具调用。
Identity & Security：统一身份、授权、隔离与安全策略。
Observability：追踪从模型调用到业务结果的完整链路。
Evaluation：持续验证模型、Agent 和业务任务的质量。
Lifecycle Management：管理资产、依赖、版本和发布。
Cost Management：衡量 AI 资源消耗和业务任务成本。
这些能力共同构成企业 AI 的平台底座。
从架构角度看，企业 AI 平台并不是简单地在业务应用与大模型之间增加一层代理服务，而是建立一套覆盖开发、运行、执行、评估、治理和运营的公共工程体系。
从业务角度看，平台的价值也不在于技术组件的数量，而在于让更多业务团队能够更快、更安全、更经济地交付真正有效的 AI 应用。
当模型能力成为可调用的资源，Agent 成为可运行的执行单元，Workflow 成为可控的业务流程，知识与工具成为可复用的企业能力时，企业 AI 才真正具备规模化发展的基础。
下一章预告
45｜Enterprise AI Operating Model：构建企业 AI 的组织协作、交付体系与运营机制
企业有了统一的 AI 平台，并不意味着 AI 能够自然地在整个组织中规模化落地。
接下来还需要回答：
AI 平台团队、业务团队、数据团队和安全团队如何分工？
如何建立从业务需求到 AI 交付的标准流程？
如何定义 AI 产品负责人、Agent 开发工程师和 AI 平台工程师的职责？
如何建立跨部门协作机制、服务目录和能力复用机制？
如何将 AI 的技术效果转化为可衡量的业务价值？
下一章将从组织架构、团队职责、交付流程和运营机制出发，讨论如何建立能够持续交付企业 AI 能力的组织运行模式。
