企业官网建设流程全解析

当企业拥有一个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日： 安全库存 = 100

8月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: Production

Agent 不能因为“知道这个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 Test

AI系统则需要：

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 Plane

AI 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 Deployment

AI工程师可能主要关注：

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 Evaluation

Level 3：企业级

20+ Agents 100+ Tools 多个业务部门 多个环境 多个模型

需要：

Model Registry Prompt Registry Knowledge Registry Tool Registry Agent Registry Evaluation Release Audit Policy Cost Governance

Level 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 Value

FDE最终不是单纯的：

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，到底值不值得部署？