前面的章节，我们已经完成了企业Agent从单点应用到平台化、治理化、多租户化的演进。
整体路线已经变成：
Single Agent
↓
Multi Tool
↓
Multi Agent
↓
Agent Platform
↓
AI Governance
↓
Cost Governance
↓
Multi-Tenant
↓
AI SaaS但当企业中的Agent越来越多，又会出现一个新的问题：
不同Agent之间，如何协作？
例如一家大型制造集团可能已经拥有：
WMS Agent
MES Agent
ERP Agent
CRM Agent
Finance Agent
Procurement Agent
HR Agent
BI Agent
Customer Service Agent如果每个Agent都是一个孤立系统：
WMS Agent MES Agent ERP Agent
│ │ │
↓ ↓ ↓
WMS MES ERP
CRM Agent Finance Agent HR Agent
│ │ │
↓ ↓ ↓
CRM Finance HR那么复杂业务仍然需要人工在多个Agent之间切换。
例如：
"分析库存异常，并结合生产计划判断未来7天是否存在缺料风险，如果存在，请生成采购建议。"
这个任务实际上涉及：
WMS
↓
MES
↓
ERP
↓
Procurement
↓
BI单个Agent很难独立完成。
因此，企业AI开始进入新的阶段：
从Agent Platform走向Agent Network，从单Agent执行走向Agent之间的协作。
一、什么是Enterprise Agent Mesh？
可以把Enterprise Agent Mesh理解成：
连接企业内部多个Agent，并让它们能够发现、通信、授权和协作执行任务的网络。
简单来说：
Enterprise Agent Mesh
│
┌──────────────┼──────────────┐
↓ ↓ ↓
WMS Agent MES Agent ERP Agent
│ │ │
└──────────────┼──────────────┘
↓
Procurement
AgentAgent不再只是：
User
↓
Agent
↓
Tool
↓
Enterprise System而可能变成：
User
↓
Supervisor Agent
↓
┌──────────────┬──────────────┐
↓ ↓ ↓
WMS Agent MES Agent ERP Agent
↓ ↓ ↓
WMS MES ERP
└──────────────┼──────────────┘
↓
Procurement Agent
↓
Procurement System这就是Agent-to-Agent，也就是：
A2A：Agent与Agent之间的协作。
二、为什么企业需要Agent之间协作？
企业业务本身就是跨系统的。
例如一个"库存异常处理"任务：
库存不足
↓
WMS发现库存异常
↓
MES检查生产计划
↓
ERP检查采购订单
↓
Finance检查预算
↓
Procurement生成采购建议如果让一个Agent完成全部任务：
General Agent
│
├── WMS Tool
├── MES Tool
├── ERP Tool
├── Finance Tool
└── Procurement Tool理论上可以实现。
但随着业务规模扩大，Tool数量可能达到：
100+
500+
1000+这时候一个Agent承担所有能力，会出现：
-
Tool选择复杂
-
Prompt越来越长
-
上下文越来越大
-
权限越来越复杂
-
Tool发现困难
-
错误处理复杂
-
Agent职责不清晰
-
Evaluation越来越困难
因此，可以把能力拆分成多个专业Agent。
Supervisor
Agent
│
┌──────────────┼──────────────┐
↓ ↓ ↓
WMS Agent MES Agent ERP Agent
│ │ │
↓ ↓ ↓
WMS MES ERP这就是：
Specialized Agent Architecture
三、Agent Mesh与Multi-Agent有什么区别？
这两个概念容易混淆。
Multi-Agent
Multi-Agent主要强调：
系统中存在多个Agent，并且这些Agent可以共同完成任务。
例如：
Supervisor
│
┌──┼───┐
↓ ↓ ↓
WMS MES ERP重点是：
Multiple Agents
+
CollaborationAgent Mesh
Agent Mesh强调的是更大的基础设施问题：
Agent Discovery
Agent Identity
Agent Communication
Agent Authorization
Agent Routing
Agent Observability
Agent Governance也就是说：
Multi-Agent解决"多个Agent一起工作"。
而：
Agent Mesh解决"企业里大量Agent如何形成一个可治理的网络"。
可以理解为：
Multi-Agent
↓
多个Agent协作
Agent Mesh
↓
多个Agent组成企业级Agent网络四、Agent Mesh的核心能力
一个企业级Agent Mesh通常至少需要以下能力：
Agent Mesh
│
┌──────────────┼──────────────┐
↓ ↓ ↓
Agent Discovery Identity Communication
↓ ↓ ↓
Authorization Routing Task Protocol
↓ ↓ ↓
Observability Governance Audit核心可以总结成八个部分：
1. Agent Discovery
2. Agent Identity
3. Agent Communication
4. Agent Authorization
5. Agent Routing
6. Task Orchestration
7. Observability
8. Governance五、Agent Discovery：Agent如何找到另一个Agent？
假设：
WMS Agent需要调用：
Procurement Agent它首先需要知道：
"系统里有没有采购Agent？"
这就是Agent Discovery。
最简单的方式是建立：
Agent Registry例如：
Agent Registry
┌───────────────────────────────┐
│ WMS Agent │
│ Capability: Inventory │
│ Status: Online │
└───────────────────────────────┘
┌───────────────────────────────┐
│ MES Agent │
│ Capability: Production Plan │
│ Status: Online │
└───────────────────────────────┘
┌───────────────────────────────┐
│ Procurement Agent │
│ Capability: Purchase Planning │
│ Status: Online │
└───────────────────────────────┘Agent Registry记录：
Agent ID
Agent Name
Description
Capabilities
Version
Endpoint
Tenant
Owner
Status
Permissions例如：
{
"agent_id": "procurement-agent",
"name": "Procurement Agent",
"capabilities": [
"purchase_query",
"supplier_analysis",
"purchase_plan"
],
"version": "1.4.0",
"status": "online"
}于是其他Agent可以通过Registry发现它。
六、Agent Identity：每个Agent都应该有身份
在企业系统里：
User有身份。
例如：
User ID
Role
Department
Tenant
Permission同样，Agent也应该拥有自己的Identity。
例如：
Agent Identity
Agent ID
Tenant ID
Owner
Role
Permission
Credential
Certificate
Policy因此：
User
↓
Identity
Agent
↓
Agent Identity不能因为"这是AI Agent"，就跳过身份体系。
七、Agent-to-Agent通信
两个Agent需要交换任务。
例如：
WMS Agent
│
│ Request
↓
MES Agent
│
│ Response
↓
WMS Agent请求可能类似：
{
"task_id": "TASK-20260918-001",
"from_agent": "wms-agent",
"to_agent": "mes-agent",
"action": "check_production_plan",
"input": {
"sku": "SKU-001",
"days": 7
}
}MES Agent返回：
{
"task_id": "TASK-20260918-001",
"status": "success",
"result": {
"shortage_risk": true,
"required_qty": 1200
}
}这样，Agent之间就可以像企业服务一样进行协作。
八、Agent不能直接信任另一个Agent
这里是企业级Agent架构中非常重要的一点。
不能简单设计成：
Agent A
↓
Agent B
↓
执行而应该是：
Agent A
↓
Agent Identity
↓
Authentication
↓
Authorization
↓
Policy Check
↓
Agent B
↓
Tool Permission
↓
Business Rule
↓
Execution因为：
Agent-to-Agent本质上也是一次跨服务调用。
甚至可以把Agent看成一种特殊的Service Principal。
九、Agent Permission：Agent之间也需要权限
例如：
WMS Agent可以：
读取库存
查询库位
查询库存锁定但不能：
修改财务数据
审批付款
删除采购订单而：
Finance Agent可能拥有：
查询预算
查询付款
查询财务数据但是不能：
修改WMS库存因此需要：
Agent A
↓
Can Call?
↓
Target Agent
↓
Allowed Capability?
↓
Allowed Action?
↓
Execute十、Agent Capability
Agent不应该只描述自己"是什么"。
更重要的是描述：
我能做什么。
例如：
WMS Agent
Capabilities:
inventory.query
inventory.lock
inventory.release
location.query
order.pickMES Agent：
MES Agent
Capabilities:
production.query
production.plan
workorder.query
equipment.statusProcurement Agent：
Procurement Agent
Capabilities:
supplier.query
purchase.query
purchase.plan
purchase.create这样，Supervisor Agent就可以根据任务寻找能力。
十一、Supervisor Agent
最常见的Multi-Agent模式之一就是Supervisor。
Supervisor Agent
│
┌────────────┼────────────┐
↓ ↓ ↓
WMS Agent MES Agent ERP Agent
↓ ↓ ↓
WMS MES ERPSupervisor主要负责：
任务理解
↓
任务拆解
↓
Agent选择
↓
任务分发
↓
结果汇总
↓
最终决策例如：
"分析SKU-001未来7天是否存在缺料风险。"
Supervisor可以拆解成：
Task
↓
查询库存
↓
查询生产计划
↓
查询采购订单
↓
分析缺口
↓
生成建议分别交给：
WMS Agent
MES Agent
ERP Agent
Procurement Agent最后：
Supervisor
↓
汇总结果
↓
生成最终报告十二、Pipeline Agent
另一种模式是Pipeline。
Agent A
↓
Agent B
↓
Agent C
↓
Agent D例如：
WMS Agent
↓
库存分析 Agent
↓
采购分析 Agent
↓
财务分析 Agent
↓
报告 Agent每个Agent负责一个步骤。
这种模式适合：
流程明确
顺序固定
输入输出清晰例如：
订单
↓
库存检查
↓
生产检查
↓
采购检查
↓
成本计算
↓
报告生成十三、Parallel Agent
有些任务可以并行执行。
例如：
Supervisor
│
┌───────────┼───────────┐
↓ ↓ ↓
WMS Agent MES Agent ERP Agent
↓ ↓ ↓
Inventory Production Purchase
└───────────┼───────────┘
↓
Merge三个Agent同时执行：
WMS → 查询库存
MES → 查询生产计划
ERP → 查询采购订单然后统一汇总。
这种方式可以降低整体等待时间。
十四、Hierarchical Agent
当企业Agent数量进一步增加，可以采用层级式架构。
Enterprise Supervisor
│
┌──────────────┼──────────────┐
↓ ↓ ↓
Supply Chain Production Finance
Supervisor Supervisor Supervisor
│ │ │
┌────┼────┐ ┌───┼───┐ ┌──┼──┐
↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓
WMS ERP Proc MES IoT QA AP AR BI这种架构特别适合大型集团。
因为企业可能拥有：
100+
500+
1000+个不同Agent。
不可能让所有Agent直接连接到一个Supervisor。
因此需要：
Enterprise Level
↓
Domain Level
↓
Business Level
↓
Specialized Agent十五、Agent Network
当Agent数量进一步增长之后，可以形成Agent Network。
Agent Network
│
┌───────────────────┼───────────────────┐
↓ ↓ ↓
Supply Chain Manufacturing Finance
│ │ │
┌────┼────┐ ┌────┼────┐ ┌───┼───┐
↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓
WMS ERP Proc MES IoT QA AP AR BI此时，Agent已经不再是几个独立的AI应用。
它开始成为：
企业AI服务网络。
十六、Agent Mesh的核心架构
可以把企业级Agent Mesh设计成：
Enterprise Agent Mesh
│
┌─────────────────┼─────────────────┐
↓ ↓ ↓
Agent Registry Policy Engine Identity
│ │ │
└─────────────────┼─────────────────┘
↓
Agent Gateway
│
┌────────────────────┼────────────────────┐
↓ ↓ ↓
Supervisor A Supervisor B Supervisor C
│ │ │
┌─────┼─────┐ ┌─────┼─────┐ ┌────┼────┐
↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓
WMS MES ERP CRM Finance HR BI QA IoT
│ │ │ │ │ │ │ │ │
↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓
Tools / MCP / APIs / Enterprise Systems外围还需要：
Observability
Audit
Evaluation
Security
Cost Governance形成完整闭环：
Agent
↓
Identity
↓
Discovery
↓
Routing
↓
Authorization
↓
Execution
↓
Observability
↓
Evaluation
↓
Governance十七、Agent Gateway
当Agent数量增加以后，不建议Agent之间完全点对点连接。
例如：
WMS → MES
WMS → ERP
WMS → CRM
WMS → Finance
MES → ERP
MES → Procurement
ERP → Finance
...最终会产生大量连接。
可以引入：
Agent Gateway变成：
Agent Gateway
│
┌───────────┼───────────┐
↓ ↓ ↓
WMS Agent MES Agent ERP AgentGateway可以负责：
Authentication
Authorization
Routing
Rate Limit
Policy
Logging
Audit
Retry
Timeout
Tracing这和传统微服务中的：
API Gateway
Service Mesh存在一定的架构类比。
但Agent Gateway还需要理解：
Agent Identity
Agent Capability
Task
Context
Policy
AI-specific Metadata十八、Agent-to-Agent与Tool Calling的关系
前面的章节我们已经介绍过：
Agent
↓
Tool Calling
↓
API
↓
Enterprise System现在增加Agent-to-Agent之后：
Agent A
↓
Agent B
↓
Tool
↓
Enterprise System因此：
Tool Calling
↓
Agent调用能力
Agent-to-Agent
↓
Agent调用另一个Agent的能力可以理解成：
Tool
↓
能力封装
Agent
↓
能力组合
Agent Mesh
↓
Agent能力网络化十九、Agent-to-Agent + MCP
MCP可以作为Agent连接外部能力的一种标准化机制。
例如：
Agent
↓
MCP
├── Database
├── Files
├── APIs
└── Enterprise Tools在Agent Mesh中：
Agent A
↓
Agent Gateway / Protocol
↓
Agent B
↓
MCP / Tools
↓
Enterprise System因此整个体系可以形成：
Agent
│
┌──────────┼──────────┐
↓ ↓ ↓
Agent Tool MCP
│ │ │
↓ ↓ ↓
Agent Network Enterprise Capabilities二十、Multi-Tenant环境下的Agent Mesh
如果前面的AI平台已经支持Multi-Tenant，那么Agent Mesh同样必须支持Tenant Isolation。
例如：
Agent Mesh
│
┌───────────────┼───────────────┐
↓ ↓ ↓
Tenant A Tenant B Tenant C
│ │ │
WMS Agent WMS Agent WMS Agent
MES Agent MES Agent MES Agent
ERP Agent ERP Agent ERP Agent必须保证：
Tenant A Agent
✕
Tenant B Agent默认不能互相调用。
除非存在明确的：
Cross-Tenant Policy例如集团总部场景：
Group Tenant
│
├── Subsidiary A
├── Subsidiary B
└── Subsidiary C总部Agent可能需要：
查询A公司库存
查询B公司库存
查询C公司库存但这不是简单地取消Tenant隔离。
而应该通过：
Tenant Scope
↓
Cross-Tenant Permission
↓
Policy Check
↓
Allowed Agent
↓
Allowed Data进行控制。
二十一、Agent-to-Agent的安全模型
企业级Agent Mesh建议采用：
Agent A
↓
Agent Identity
↓
Authentication
↓
Target Agent Discovery
↓
Authorization
↓
Capability Check
↓
Tenant Check
↓
Data Permission
↓
Business Rule
↓
Risk Check
↓
Human Approval
↓
Agent B这意味着：
Agent之间的调用，本质上仍然必须经过企业安全边界。
尤其是以下操作：
创建订单
修改订单
修改库存
采购
付款
删除数据不应该因为"调用方是另一个Agent"而自动获得高权限。
二十二、Agent Mesh中的Human-in-the-loop
对于高风险操作：
Agent A
↓
Agent B
↓
High Risk Action
↓
Human Approval
↓
Execute例如：
Agent发现库存不足
↓
计算采购需求
↓
生成采购建议
↓
采购Agent
↓
创建采购订单
↓
Human Approval
↓
正式提交这体现了企业Agent的一个重要原则：
AI负责分析和准备，人负责最终授权。
二十三、Agent Mesh的可观测性
当系统只有一个Agent时：
User
↓
Agent
↓
Tool日志还比较简单。
但是Multi-Agent之后：
User
↓
Supervisor
↓
WMS Agent
↓
MES Agent
↓
ERP Agent
↓
Procurement Agent
↓
Tool一次请求可能产生几十甚至上百个调用。
因此必须建立：
Trace ID
Task ID
Agent ID
Tenant ID
Parent Task ID
Tool Call ID例如：
Trace
└── Task
├── WMS Agent
│ ├── Tool A
│ └── Tool B
│
├── MES Agent
│ └── Tool C
│
└── ERP Agent
└── Tool D最终形成完整Agent Trace。
二十四、Agent Mesh中的Cost Governance
Multi-Agent会进一步增加AI成本。
例如：
User
↓
Supervisor
↓
WMS Agent
↓
LLM
↓
MES Agent
↓
LLM
↓
ERP Agent
↓
LLM
↓
Procurement Agent
↓
LLM原本一个任务：
1 Agent现在可能变成：
1 Supervisor
+
4 Agents
+
Multiple Tools
+
Multiple LLM Calls因此成本治理必须从：
Agent Cost进一步扩展到：
Task Cost
Agent Cost
Tenant Cost
Department Cost
Business Cost例如：
Task-001
│
├── Supervisor: $0.02
├── WMS Agent: $0.03
├── MES Agent: $0.04
├── ERP Agent: $0.03
└── Procurement Agent: $0.05
↓
Total: $0.17这就是企业AI成本精细化管理。
二十五、什么时候不应该使用Multi-Agent？
Multi-Agent并不是越多越好。
如果一个Agent就可以完成：
查询库存没必要设计：
Supervisor
↓
Inventory Agent
↓
WMS Agent
↓
Tool
↓
WMS这样反而增加：
Latency
Cost
Complexity
Failure Points因此：
能用单Agent解决的问题，不要为了架构复杂而使用Multi-Agent。
适合Multi-Agent的场景通常具有：
复杂任务
+
多个专业领域
+
多个系统
+
多个独立能力
+
需要并行处理
+
需要不同权限边界二十六、一个完整的企业Agent Mesh案例
假设企业提出需求：
"分析未来7天库存风险，并结合生产计划、采购订单和预算情况，生成采购建议。"
系统可以这样执行：
User
↓
Enterprise Supervisor
↓
Task Planning
│
├──────────────┬──────────────┐
↓ ↓ ↓
WMS Agent MES Agent ERP Agent
↓ ↓ ↓
Inventory Production Purchase
Analysis Plan Orders
│ │ │
└──────────────┼──────────────┘
↓
Finance Agent
↓
Budget Check
↓
Procurement Agent
↓
Purchase Proposal
↓
Human Approval
↓
Purchase System最终用户得到：
SKU-001
当前库存：800
未来7天需求：2,000
生产计划需求：700
已有采购订单：300
预计缺口：1,600
预算状态：正常
建议：
创建采购申请 1,600 件
状态：
等待人工审批这个例子已经不是传统意义上的Chatbot。
而是：
一个由多个专业Agent组成的企业智能工作网络。
二十七、Enterprise Agent Mesh完整架构
综合前面的内容，可以得到：
外围再增加：
Cost Governance
Observability
Audit
Identity
Data Permission
Human Approval这就形成了企业级Agent Network。
二十八、从Agent Platform到Agent Mesh
前面的架构演进：
Single Agent
↓
Multi Tool
↓
Multi Agent
↓
Agent Platform现在进一步变成：
Agent Platform
↓
Agent Registry
↓
Agent Discovery
↓
Agent-to-Agent
↓
Agent Gateway
↓
Agent Network
↓
Enterprise Agent Mesh因此：
Agent Platform解决"如何运行Agent"。
Agent Mesh解决"如何让大量Agent形成一个可发现、可通信、可授权、可治理的企业AI网络"。
二十九、FDE需要掌握的Agent Mesh能力
对于FDE来说，不需要一开始就构建一个拥有数百Agent的复杂平台。
更重要的是理解下面这张能力地图：
FDE
│
┌──────────────────┼──────────────────┐
↓ ↓ ↓
Business Engineering AI
│ │ │
Process API LLM
Workflow DB RAG
Domain Gateway Agent
KPI Docker Tool
Cloud MCP
DevOps Eval
│
↓
Agent Mesh
│
┌───────────────────┼───────────────────┐
↓ ↓ ↓
Discovery Identity Communication
↓ ↓ ↓
Routing Authorization Orchestration
↓ ↓ ↓
Observability Governance Cost
│
↓
Business Value三十、FDE设计Agent Mesh时的关键问题
真正做项目时，可以先问下面这些问题。
1. 为什么需要多个Agent？
是不是：
业务领域不同？
系统不同？
权限不同？
能力不同？2. Agent之间如何发现？
Agent Registry
Service Registry
Capability Registry采用什么方式？
3. Agent如何通信？
HTTP
Event
Message Queue
Agent Protocol需要同步还是异步？
4. Agent如何认证？
OAuth
JWT
mTLS
API Key
Service Identity5. Agent如何授权？
RBAC
ABAC
Capability Permission
Policy Engine6. Agent如何隔离Tenant？
Tenant Context
Tenant Policy
Tenant Data
Tenant Tool
Tenant Agent7. 如何追踪一次复杂任务？
至少需要：
Trace ID
Task ID
Agent ID
Tenant ID
Parent Task ID8. 如何控制Multi-Agent成本？
需要：
Token Budget
Agent Budget
Task Budget
Tenant Budget
Rate Limit
Quota9. 哪些操作需要人工审批？
例如：
查询 → 自动
分析 → 自动
建议 → 自动
创建订单 → 视风险决定
付款 → 人工审批
删除数据 → 人工审批三十一、Enterprise Agent Mesh最终形态
当企业的Agent越来越多时，最终可能形成：
最终形成的已经不再是：
一个AI应用而是：
企业AI基础设施
+
Agent Network
+
Enterprise Systems
+
Governance
+
Security
+
Cost
+
Observability三十二、本章核心总结
本章从Multi-Tenant进一步进入Enterprise Agent Mesh。
核心概念可以总结为：
Multi-Agent
↓
Agent-to-Agent
↓
Agent Discovery
↓
Agent Identity
↓
Agent Authorization
↓
Agent Gateway
↓
Agent Network
↓
Enterprise Agent Mesh其中：
Agent Registry
→ 管理Agent
Agent Discovery
→ 找到Agent
Agent Identity
→ 识别Agent
Agent Gateway
→ 管理Agent通信
Agent-to-Agent
→ Agent之间协作
Supervisor
→ 负责任务编排
Pipeline
→ 顺序执行
Parallel
→ 并行执行
Hierarchical
→ 层级协作
Agent Mesh
→ 构建企业级Agent网络而企业级Agent Mesh真正需要解决的是：
发现
通信
身份
权限
隔离
路由
编排
安全
成本
监控
审计
评估因此：
Multi-Agent解决的是"多个Agent如何协作"，而Enterprise Agent Mesh解决的是"企业中大量Agent如何形成一个可发现、可通信、可授权、可治理的AI网络"。
三十三、FDE的能力再次升级
到这里，FDE的技术能力已经从：
Software Engineering
↓
AI Engineering
↓
Agent
↓
Agent Platform
↓
Governance
↓
Cost Governance
↓
Multi-Tenant
↓
AI SaaS
↓
Agent Mesh进一步形成：
FDE
│
┌────────────┼────────────┐
↓ ↓ ↓
Business Engineering AI
│ │ │
Process API LLM
Domain DB RAG
KPI Cloud Agent
ROI Docker Tool
DevOps MCP
Eval
│
↓
Enterprise AI
│
┌──────────┼──────────┐
↓ ↓ ↓
Platform Governance Mesh
│ │ │
└──────────┼──────────┘
↓
Integration
↓
Deployment
↓
Business Value这意味着FDE已经不再只是：
"把一个Agent部署到客户现场的人。"
而逐渐成为：
"能够设计、集成、部署和运营企业AI系统的人。"
三十四、下一阶段：从Agent Mesh进入AI Operating System
当企业拥有：
大量Tenant
大量Agent
大量Tool
大量Knowledge
大量Model
大量MCP
大量AI应用下一步就会出现更大的问题：
谁来统一管理整个企业AI生态？
这时，平台可能继续演进：
AI SaaS
↓
Agent Mesh
↓
Enterprise AI Platform
↓
AI Operating System届时需要统一管理：
Models
Agents
Tools
MCP
Knowledge
Prompts
Policies
Tenants
Users
Costs
Evaluation
Security
Workflows最终形成：
Enterprise AI Operating System
│
┌─────────────────────┼─────────────────────┐
↓ ↓ ↓
Models Agents Tools
↓ ↓ ↓
Knowledge MCP Workflows
↓ ↓ ↓
Policies Governance Security
└─────────────────────┼─────────────────────┘
↓
Enterprise Systems
ERP / WMS / MES / CRM
↓
Business Value这将成为企业AI平台化之后更加重要的方向。
下一篇：
《FDE前沿部署工程师实战教程》19 - Enterprise AI Operating System：从Agent平台到企业AI操作系统
下一章将进一步讨论：当企业拥有大量Model、Agent、Tool、Knowledge、MCP、Workflow和AI应用之后，如何构建统一的 Enterprise AI Operating System，以及FDE如何从"AI项目交付"进一步走向"企业AI基础设施设计"。
补充本章开头的学习目标减少重复段落并合并架构图修正库存缺口计算示例