当企业拥有一个Agent时，重点是把它做出来；当企业拥有几十个Agent时，重点就变成如何管理它们。
在前面的章节中，我们已经完成了企业 Agent 从单点应用到平台化的演进：
LLM
↓
RAG
↓
Tool Calling
↓
Agent
↓
Multi-Agent
↓
Tool Registry
↓
MCP
↓
Agent Runtime
↓
Enterprise Agent Platform但是，当企业真正开始规模化使用 Agent 后，会出现一个新的问题：
AI 系统中的资产越来越多，却越来越难管理。
例如：
-
使用了哪些模型？
-
哪个 Agent 使用哪个模型？
-
Prompt 到底是哪一个版本？
-
知识库什么时候更新过？
-
Tool 谁开发的？
-
Tool 哪个版本正在生产环境运行？
-
Agent A 为什么昨天和今天表现不一样？
-
RAG 数据变了以后，Evaluation 是否重新执行？
-
一个 Prompt 修改后，哪些 Agent 会受到影响？
-
一个 Tool 升级后，会不会影响其他 Agent？
-
生产环境出现问题，能不能快速回滚？
这就引出了企业 AI 的下一阶段：
AI Governance------企业级 AI 治理。
一、为什么企业需要 AI Governance？
传统软件系统已经有成熟的治理体系。
例如：
代码
↓
Git
↓
Branch
↓
Code Review
↓
CI/CD
↓
Test
↓
Release
↓
Production但是 AI 系统比传统软件复杂。
因为一个 Agent 的行为不仅由代码决定，还受到：
Model
Prompt
Knowledge
Tool
Agent Config
Workflow
Policy
Data等多个因素影响。
因此：
传统软件版本
=
Code Version而：
企业Agent版本
=
Model
+
Prompt
+
Knowledge
+
Tool
+
Config
+
Policy
+
Code这也是为什么 AI 系统需要独立的治理体系。
二、企业 AI 到底需要管理什么？
可以把企业 AI 的核心资产分成六类：
Enterprise AI Governance
│
┌──────────────────┼──────────────────┐
↓ ↓ ↓
Models Agents Tools
│ │ │
↓ ↓ ↓
Prompts Knowledge MCP
│ │ │
└──────────────────┼──────────────────┘
↓
Version Control
↓
Evaluation
↓
Release / Rollback
↓
Production也就是说：
企业 AI 治理不是只管理 Agent，而是管理 Agent 周围的完整 AI 资产。
三、Model Registry：模型注册中心
企业部署多个 Agent 后，第一个问题就是：
到底用了哪些模型？
例如：
GPT-5.6
Claude
Gemini
Qwen
Llama
DeepSeek
企业私有模型不同模型可能承担不同任务。
例如：
复杂推理
↓
Reasoning Model
普通问答
↓
General LLM
Embedding
↓
Embedding Model
Reranker
↓
Reranker Model
Vision
↓
Vision Model因此企业需要：
Model Registry------模型注册中心。
四、Model Registry应该管理什么？
一个模型注册中心至少需要记录：
Model
├ Name
├ Provider
├ Version
├ Endpoint
├ Context Window
├ Capability
├ Cost
├ Latency
├ Status
├ Security
└ Owner例如：
Model: Enterprise-LLM-01
Provider:
Internal AI Platform
Version:
v3.2
Capability:
Reasoning / Chat / Tool Calling
Context:
128K
Status:
Production
Owner:
AI Platform Team这样企业就可以知道：
哪个模型正在被什么业务使用。
五、为什么不能让Agent直接写死模型？
一种常见的错误设计：
Agent
│
└── model = xxx-model-v1如果模型发生变化：
xxx-model-v1
↓
xxx-model-v2就必须修改 Agent 代码。
更好的设计是：
Agent
↓
Model Registry
↓
Model Version
↓
Model Endpoint例如：
Agent
↓
Model Registry
↓
Enterprise-LLM
↓
Production Version
↓
Endpoint这样就可以实现：
模型升级
↓
Evaluation
↓
灰度发布
↓
Production而不需要修改 Agent 核心代码。
六、Prompt Registry：Prompt也应该版本化
很多团队会忽略一个问题：
Prompt其实也是软件资产。
例如：
v1
请分析当前库存情况。升级：
v2
请分析当前库存情况，并结合历史销量、
安全库存和采购周期给出补货建议。看起来只是增加几句话。
但是实际上：
Prompt变化
↓
Agent行为变化
↓
Tool调用可能变化
↓
输出结果变化
↓
业务结果变化所以：
生产环境 Prompt 不能随意修改。
七、Prompt Registry
Prompt Registry 可以管理：
Prompt
├ Name
├ Version
├ Template
├ Variables
├ Model
├ Owner
├ Environment
├ Status
├ Evaluation Score
└ Release Time例如：
Prompt:
warehouse_replenishment
Version:
v2.3
Variables:
{{inventory}}
{{sales}}
{{lead_time}}
{{safety_stock}}
Status:
Production
Evaluation:
92.6这样当 Agent 表现异常时，就可以追溯：
Agent
↓
Prompt v2.3
↓
Model v3.2
↓
Knowledge v18
↓
Tool v4.1八、Prompt版本管理
推荐采用：
Draft
↓
Test
↓
Evaluation
↓
Staging
↓
Production而不是：
修改Prompt
↓
直接上线生产 Prompt 至少应该支持：
v1.0
v1.1
v1.2
v2.0并支持：
Compare
Rollback
Audit九、Knowledge Registry：知识库也需要治理
企业 Agent 经常使用 RAG。
因此：
Knowledge
↓
Documents
↓
Chunk
↓
Embedding
↓
Vector DB也必须进行版本管理。
例如：
仓库SOP
v1.0
2026-01
v1.1
2026-03
v2.0
2026-08如果生产 Agent 的回答发生变化，必须能够知道：
它到底使用了哪一版知识。
十、为什么知识库版本非常重要？
假设：
8月1日：
安全库存 = 1008月20日：
安全库存 = 150知识库更新以后：
RAG
↓
检索新规则
↓
Agent
↓
补货建议变化如果没有 Knowledge Version：
你很难解释：
为什么同一个问题，今天和一个月前得到的结果不同？
因此需要：
Knowledge Base
├ Version
├ Documents
├ Metadata
├ Embedding Version
├ Chunk Strategy
├ Update Time
└ Owner十一、Knowledge Version不只是文档版本
这里还有一个非常容易忽略的问题。
RAG 的结果不仅取决于文档。
还取决于：
Document
+
Chunk Strategy
+
Embedding Model
+
Vector Database
+
Retriever
+
Reranker所以严格来说：
Knowledge Version
=
Document Version
+
Embedding Version
+
Index Version
+
Retrieval Config这也是企业 RAG 治理比普通文件管理复杂的原因。
十二、Tool Registry：工具治理
前面我们已经详细介绍过 Tool Registry。
到了企业平台阶段，它的重要性进一步提升。
企业可能拥有：
WMS Tools
ERP Tools
CRM Tools
MES Tools
OA Tools
BI Tools例如：
WMS
├ query_inventory
├ query_stockout
├ create_replenishment
└ lock_inventory
ERP
├ query_purchase_order
├ create_purchase_order
└ query_supplier这些 Tool 本质上已经成为：
企业 AI 的能力资产。
十三、Tool治理需要哪些能力？
至少包括：
Tool Registry
├ Metadata
├ Schema
├ Version
├ Permission
├ Owner
├ Risk Level
├ Status
├ Dependency
├ Health Check
└ Audit例如：
Tool:
create_purchase_order
Risk:
HIGH
Permission:
PURCHASE_CREATE
Approval:
Required
Version:
v2.1
Status:
ProductionAgent 不能因为"知道这个Tool"就自动拥有调用权限。
必须经过：
Agent
↓
Tool Registry
↓
Permission
↓
Policy
↓
Risk Check
↓
Human Approval
↓
Tool十四、Agent Registry：Agent也需要注册中心
当企业只有一个 Agent 时：
warehouse-agent管理起来很简单。
但是当企业拥有：
Warehouse Agent
Sales Agent
Finance Agent
HR Agent
Customer Agent
Production Agent
BI Agent就需要：
Agent Registry。
十五、Agent Registry管理什么？
例如：
Agent
├ Name
├ Description
├ Owner
├ Version
├ Model
├ Prompt
├ Knowledge
├ Tools
├ Workflow
├ Permission
├ Environment
├ Status
└ Evaluation最终可以形成完整依赖关系：
Agent
│
├── Model
│
├── Prompt
│
├── Knowledge
│
├── Tools
│
├── Workflow
│
└── Policy十六、一个Agent的完整版本到底是什么？
这是企业 AI 治理中的核心问题。
假设：
Warehouse Agent v3.5不能只意味着：
Agent Code v3.5真正的完整版本应该类似：
Warehouse Agent
├ Code: v3.5
├ Model: Enterprise-LLM v3.2
├ Prompt: v2.3
├ Knowledge: KB v18
├ Tool: WMS Tool v4.1
├ Workflow: WF v2.0
└ Policy: Policy v1.8因此：
Agent Version实际上是一组AI资产版本的组合。
十七、建立AI Asset Manifest
可以借鉴软件工程中的依赖清单，为 Agent 建立：
AI Asset Manifest
例如：
agent:
name: warehouse-agent
version: 3.5
model:
name: enterprise-llm
version: 3.2
prompt:
name: warehouse-analysis
version: 2.3
knowledge:
name: warehouse-kb
version: 18
tools:
- name: query_inventory
version: 4.1
- name: create_replenishment
version: 2.0
policy:
version: 1.8这样一个 Agent 就拥有了：
可追踪、可复制、可回滚的完整运行环境。
十八、Evaluation Dataset：AI系统也需要测试数据
传统软件：
Unit Test
Integration Test
E2E TestAI系统则需要：
Evaluation Dataset例如仓库 Agent：
Question
Expected Answer
Expected Tool
Expected Result
Risk Level
Business KPI测试案例：
Case 001
问题：
SKU-A库存是否不足？
Expected:
应该查询库存Tool
Case 002
问题：
创建采购订单
Expected:
需要调用采购Tool
Case 003
问题：
创建一笔50万元采购订单
Expected:
必须触发人工审批十九、Evaluation Dataset为什么必须版本化？
因为：
Agent v1和：
Agent v2应该使用同一套核心测试集进行比较。
例如：
Dataset v10
Agent v1.0 → 82%
Agent v1.1 → 87%
Agent v1.2 → 91%
Agent v2.0 → 94%这样才能知道：
升级到底有没有真正变好。
二十、Release Management：AI不能"改完就上线"
企业 AI 发布应该形成标准流程：
Development
↓
Draft
↓
Evaluation
↓
Review
↓
Staging
↓
Canary
↓
Production例如：
Prompt v2.4
↓
Offline Evaluation
↓
Score > Threshold
↓
Security Review
↓
Staging
↓
5% Traffic
↓
Monitoring
↓
50%
↓
100%这就是：
AI Gray Release------AI灰度发布。
二十一、为什么AI特别需要灰度发布？
因为传统软件：
代码是否正确通常可以通过测试获得较强确定性。
但是 AI：
Prompt
+
Model
+
Knowledge
+
Context
+
Tool组合之后，输出具有一定不确定性。
所以：
Evaluation
+
Canary
+
Monitoring非常重要。
二十二、Rollback：AI系统必须可以回滚
假设：
Agent v3.5发布之后出现：
Tool调用错误 ↑
Token成本 ↑
回答准确率 ↓
业务成功率 ↓不能要求工程师临时修改代码。
应该直接：
Production v3.5
↓
Rollback
↓
Production v3.4同时恢复：
Model
Prompt
Knowledge
Tool
Config
Policy而不是只回滚代码。
二十三、完整AI发布链路
企业级 AI 发布可以设计为：
AI Asset
│
↓
Version
│
↓
Evaluation
│
↓
Security Review
│
↓
Approval
│
↓
Release
│
↓
Canary
│
↓
Monitoring
│
↓
Production
│
↓
Evaluation
│
↓
Optimization形成完整闭环：
Build
↓
Evaluate
↓
Release
↓
Observe
↓
Optimize
↓
Release二十四、AI Governance与Security Governance
企业 AI 治理不能脱离安全。
例如：
Agent
↓
Model
↓
Prompt
↓
Knowledge
↓
Tool
↓
Enterprise Data每一层都存在安全问题。
因此治理体系应该同时管理：
Identity
Permission
Data Permission
Tool Permission
Prompt Security
Knowledge Permission
Model Access
Audit
Compliance二十五、AI Governance总体架构
可以形成如下架构：
二十六、Control Plane与Runtime Plane
前面的平台化章节中，我们已经介绍过两个核心概念：
Control Plane
Runtime PlaneAI Governance主要属于：
Control Plane。
而 Agent 实际执行任务属于：
Runtime Plane。
整体结构：
Control Plane
│
┌────────────────┼────────────────┐
↓ ↓ ↓
Agent Registry Tool Registry Policy
Model Registry Knowledge Config
Prompt Registry Evaluation Version
│ │ │
└────────────────┼────────────────┘
↓
Release
↓
Runtime Plane
│
┌──────────┼──────────┐
↓ ↓ ↓
Agent Agent Agent
↓ ↓ ↓
Tool RAG MCP
↓ ↓ ↓
Enterprise
Systems二十七、Control Plane负责"管"
Control Plane主要解决：
谁可以使用？
哪个版本？
什么配置？
什么权限？
哪个模型？
哪个Prompt？
哪个知识库？
哪些Tool？
是否通过Evaluation？
是否允许发布？也就是：
定义规则。
二十八、Runtime Plane负责"跑"
Runtime Plane负责：
接收任务
↓
选择Agent
↓
加载Context
↓
调用Model
↓
选择Tool
↓
执行Workflow
↓
调用MCP
↓
访问企业系统
↓
返回结果也就是：
执行任务。
二十九、为什么要把Control与Runtime分离？
如果所有东西混在一起：
Agent
├ Model
├ Prompt
├ Permission
├ Tool
├ Config
├ Version
├ Runtime
└ Audit随着规模扩大，会越来越难维护。
分离以后：
Control Plane
↓
统一治理
Runtime Plane
↓
统一执行于是：
治理逻辑
≠
业务执行逻辑平台就更容易扩展。
三十、企业AI治理的最终目标
治理不是为了增加审批流程。
治理最终要解决的是：
AI越来越多
↓
资产统一管理
↓
版本统一管理
↓
权限统一管理
↓
Evaluation统一
↓
发布统一
↓
监控统一
↓
审计统一最终实现：
AI可控、可追踪、可评估、可回滚、可审计。
三十一、FDE在AI Governance中的角色
传统开发工程师可能主要关注：
Code
API
DB
DeploymentAI工程师可能主要关注：
Model
Prompt
RAG
Agent
Evaluation而 FDE 需要把这些能力连接起来。
客户业务
↓
业务问题
↓
AI场景
↓
Agent
↓
Model
↓
Prompt
↓
Knowledge
↓
Tool
↓
Enterprise System
↓
Deployment
↓
Evaluation
↓
Governance
↓
Business Value这也是 FDE 的独特价值。
三十二、一个真实企业案例
假设企业建设：
AI仓库运营平台。
包含：
Inventory Agent
Purchase Agent
Order Agent
Warehouse Agent
BI Agent它们共享：
Model Registry
Prompt Registry
Knowledge Registry
Tool Registry
Evaluation Dataset例如：
AI Platform
│
┌──────────────┼──────────────┐
↓ ↓ ↓
Inventory Agent Purchase Agent Order Agent
│ │ │
└──────────────┼──────────────┘
↓
Shared Platform
│
┌──────────────┼──────────────┐
↓ ↓ ↓
Models Prompts Knowledge
│ │ │
└──────────────┼──────────────┘
↓
Tool Registry
↓
MCP
↓
ERP / WMS / MES这样企业就不需要为每个 Agent 建设一套独立基础设施。
三十三、AI治理平台的核心数据模型
从系统设计角度，可以抽象出：
AI_MODEL
AI_PROMPT
AI_KNOWLEDGE
AI_TOOL
AI_AGENT
AI_POLICY
AI_VERSION
AI_EVALUATION
AI_RELEASE
AI_AUDIT它们之间存在关系：
Agent
│
├ Model
├ Prompt
├ Knowledge
├ Tool
├ Policy
└ Version
│
↓
Evaluation
│
↓
Release
│
↓
Production这已经非常接近一个真正的：
Enterprise AI Management Platform。
三十四、AI治理平台可以有哪些菜单？
如果做成企业后台系统，可以设计：
AI平台
│
├── 模型管理
│ ├ 模型注册
│ ├ 模型版本
│ ├ 模型路由
│ └ 模型成本
│
├── Prompt管理
│ ├ Prompt模板
│ ├ Prompt版本
│ ├ Prompt测试
│ └ Prompt发布
│
├── 知识管理
│ ├ 知识库
│ ├ 文档
│ ├ 索引
│ └ 知识版本
│
├── Tool管理
│ ├ Tool Registry
│ ├ Tool Schema
│ ├ Tool权限
│ └ Tool版本
│
├── Agent管理
│ ├ Agent
│ ├ Agent版本
│ ├ Agent配置
│ └ Agent发布
│
├── Evaluation
│ ├ 测试集
│ ├ 自动评估
│ ├ LLM Judge
│ └ KPI
│
├── Release
│ ├ 发布
│ ├ 灰度
│ ├ 回滚
│ └ 发布记录
│
└── Governance
├ 权限
├ 审计
├ Policy
└ 合规三十五、FDE如何判断一个企业是否需要AI Governance？
并不是所有项目一开始都需要完整治理平台。
可以按照规模判断：
Level 1：单Agent
1 Agent
1 Model
少量Tool简单版本管理即可。
Level 2：多Agent
5~20 Agents
多个Tool
多个Knowledge开始需要：
Agent Registry
Tool Registry
Prompt Version
EvaluationLevel 3：企业级
20+
Agents
100+
Tools
多个业务部门
多个环境
多个模型需要：
Model Registry
Prompt Registry
Knowledge Registry
Tool Registry
Agent Registry
Evaluation
Release
Audit
Policy
Cost GovernanceLevel 4：AI Platform
当企业已经形成：
多个业务AI
+
多个Agent
+
大量Tool
+
多个模型
+
多个业务系统就应该考虑建设：
Enterprise AI Platform + AI Governance Platform。
三十六、企业AI治理不是"限制AI"
这是一个非常重要的认知。
很多人认为：
Governance
=
限制实际上：
Governance
=
让AI能够安全地规模化运行没有治理：
1 Agent
↓
5 Agent
↓
20 Agent
↓
混乱有治理：
1 Agent
↓
5 Agent
↓
20 Agent
↓
100 Agent
↓
Platform所以：
治理不是阻碍 AI，而是让 AI 从项目走向企业基础设施。
三十七、FDE的治理思维
FDE在面对一个新 Agent 项目时，不应该只问：
"这个 Agent 怎么开发？"
还应该问：
使用什么Model？
Prompt在哪里管理？
Knowledge来自哪里？
Tool由谁维护？
权限如何控制？
Evaluation怎么做？
版本如何管理？
如何发布？
出现问题怎么回滚？
谁负责审计？
成本如何统计？这就是：
FDE从"项目交付思维"进入"平台治理思维"。
三十八、企业AI Governance完整闭环
最终可以形成：
AI Asset
│
┌──────────┼──────────┐
↓ ↓ ↓
Model Prompt Knowledge
↓ ↓ ↓
Agent Tool MCP
└──────────┼──────────┘
↓
Version Control
↓
Evaluation
↓
Security Review
↓
Release
↓
Production
↓
Observability
↓
Audit
↓
Continuous Optimization
│
└──────────────→ New Version这就是企业 AI 的：
Govern → Build → Evaluate → Release → Observe → Optimize
闭环。
三十九、FDE能力进一步升级
到这一阶段，FDE的能力结构已经发生变化。
FDE
│
┌───────────┼───────────┐
↓ ↓ ↓
Business Engineering AI
│ │ │
Process API LLM
Requirement DB RAG
ROI Docker Agent
KPI Cloud Tool
DevOps MCP
Eval
│
↓
Integration
↓
Deployment
↓
Observability
↓
Evaluation
↓
Platform
↓
Governance
↓
Business ValueFDE最终不是单纯的：
Developer也不是单纯的：
AI Engineer而是：
连接业务、软件工程、AI、系统集成、部署、平台和治理的综合型工程师。
四十、总结
本章重点讨论了企业 Agent 从"平台化"进一步走向"治理化"的过程。
企业 AI 需要统一管理：
Model
Prompt
Knowledge
Tool
Agent
Policy
Version
Evaluation
Release
Audit核心治理链路可以总结为：
AI Assets
↓
Registry
↓
Version Control
↓
Evaluation
↓
Security Review
↓
Release
↓
Production
↓
Monitoring
↓
Audit
↓
Optimization其中：
Model Registry管理模型。
Prompt Registry管理Prompt。
Knowledge Registry管理企业知识。
Tool Registry管理AI能力。
Agent Registry管理智能体。
Evaluation验证AI质量。
Release Management负责发布与回滚。
Governance负责权限、安全、审计和合规。
最终形成：
这意味着企业 AI 正在从"一个个AI应用"，逐渐演变成一套可管理、可治理、可持续演进的企业基础设施。
下一章
下一章将继续向企业 AI 的运行机制深入：
《FDE前沿部署工程师实战教程》16 - 企业Agent成本治理：Token、模型路由、资源调度与ROI》
我们将重点解决一个企业非常现实的问题：
Agent越来越多、模型越来越强，但是成本也越来越高，怎么办？
下一章将围绕：
Token Cost
Model Cost
GPU Cost
Tool Cost
RAG Cost
Agent Runtime Cost
Inference Cost
Infrastructure Cost建立企业 AI 成本模型，并进一步介绍：
Model Routing
↓
Small Model / Large Model
↓
Task Classification
↓
Cost-aware Agent
↓
Budget Control
↓
Usage Quota
↓
Cost Monitoring
↓
ROI最终回答 FDE 最重要的问题之一：
一个企业 Agent，到底值不值得部署？