当企业拥有一个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 RegistryPrompt也应该版本化很多团队会忽略一个问题Prompt其实也是软件资产。例如v1 请分析当前库存情况。升级v2 请分析当前库存情况并结合历史销量、 安全库存和采购周期给出补货建议。看起来只是增加几句话。但是实际上Prompt变化 ↓ Agent行为变化 ↓ Tool调用可能变化 ↓ 输出结果变化 ↓ 业务结果变化所以生产环境 Prompt 不能随意修改。七、Prompt RegistryPrompt 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 RegistryAgent也需要注册中心当企业只有一个 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 DatasetAI系统也需要测试数据传统软件Unit Test Integration Test E2E TestAI系统则需要Evaluation Dataset例如仓库 AgentQuestion 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 ManagementAI不能“改完就上线”企业 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特别需要灰度发布因为传统软件代码是否正确通常可以通过测试获得较强确定性。但是 AIPrompt Model Knowledge Context Tool组合之后输出具有一定不确定性。所以Evaluation Canary Monitoring非常重要。二十二、RollbackAI系统必须可以回滚假设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单Agent1 Agent 1 Model 少量Tool简单版本管理即可。Level 2多Agent5~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 4AI 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到底值不值得部署