前面的章节，我们已经完成了Enterprise AI的大部分核心能力：
Enterprise AI
│
├── Agent
├── Tool
├── RAG
├── MCP
├── Workflow
├── Multi-Agent
├── Runtime
├── Security
├── Governance
└── FinOps但是，一个Agent真正进入生产环境之后，企业面对的问题会发生变化。
开发阶段关注的是：
能不能运行？生产阶段关注的是：
能不能持续稳定运行？例如：
Agent
↓
LLM
↓
RAG
↓
Tool
↓
MCP
↓
ERP / WMS / MES任何一个环节出现问题，都可能导致整个任务失败。
例如：
LLM Timeout
RAG Timeout
Vector DB Error
Tool Timeout
MCP Error
ERP API Error
Network Error
Permission Error
Rate Limit
Token Limit因此：
Enterprise Agent上线不是开发结束，而是生产工程的开始。
一、为什么Agent需要Reliability？
传统应用：
User
↓
Application
↓
Database通常调用链比较固定。
而Agent：
User
↓
Agent
↓
LLM
↓
Planning
↓
RAG
↓
Tool
↓
MCP
↓
API
↓
Enterprise System甚至可能：
Agent
↓
Agent A
↓
Agent B
↓
Tool
↓
Agent C
↓
API调用链具有动态性。
因此Agent可能出现：
任务失败
响应过慢
循环调用
Tool失败
模型切换
上下文过长
成本异常这意味着：
Agent Reliability比普通API Reliability更加复杂。
二、Enterprise AI Reliability架构
可以建立：
Enterprise AI Reliability
│
┌──────────────────────┼──────────────────────┐
↓ ↓ ↓
Observability Resilience Operations
│ │ │
Metrics Retry Deployment
Logs Timeout Scaling
Trace Circuit Breaker Rollback
Events Fallback Incident
│ │ │
└──────────────────────┼──────────────────────┘
↓
Agent Runtime
↓
Enterprise Systems核心可以概括成：
Observe
↓
Detect
↓
Recover
↓
Optimize三、第一原则：定义SLA
企业Agent不能只说：
"这个Agent很好用。"
而应该定义明确的服务指标。
例如：
WMS Agent
Availability
99.9%
P95 Latency
< 5s
Task Success Rate
> 95%
Tool Success Rate
> 98%
Error Rate
< 1%这样才可以真正进入生产管理。
四、SLA、SLO、SLI
这是FDE需要掌握的重要概念。
SLI
Service Level Indicator：
实际测量指标。
例如：
Latency
Availability
Error Rate
Task Success
Tool SuccessSLO
Service Level Objective：
目标。
例如：
P95 Latency < 5s
Task Success > 95%SLA
Service Level Agreement：
对客户承诺的服务水平。
例如：
Monthly Availability
≥ 99.9%三者关系：
SLI
↓
实际数据
SLO
↓
内部目标
SLA
↓
对外承诺五、Agent核心指标
传统系统通常关注：
QPS
Latency
Error Rate
CPU
MemoryAgent还需要增加：
Task Success Rate
Tool Success Rate
RAG Quality
LLM Success Rate
Agent Completion Rate
Human Escalation Rate
Token Usage
Cost per Task因此：
Agent Reliability Metrics
│
├── Availability
├── Latency
├── Error Rate
├── Task Success
├── Tool Success
├── RAG Quality
├── LLM Success
├── Escalation Rate
└── Cost六、Task Success Rate
这是Agent区别于普通API的重要指标。
例如：
1000次任务其中：
成功：968
失败：32那么：
Task Success Rate
=
968 / 1000
=
96.8%例如：
WMS库存分析Agent
Task Success
96.8%这个指标比单纯的：
HTTP 200更加有意义。
因为：
API返回200，不代表Agent完成了业务任务。
七、Agent成功不等于Tool成功
例如：
Agent
↓
分析需求
↓
调用WMS Tool
↓
Tool TimeoutAgent可能最终：
任务失败所以需要区分：
Agent Success
Tool Success
Workflow Success
Business Success例如：
Agent Success
98%
Tool Success
99%
Business Success
94%最终应该关注：
Business Success。
八、Latency
Agent延迟通常来自多个部分：
Total Latency
=
LLM
+
RAG
+
Tool
+
MCP
+
Network
+
Workflow例如：
LLM 1.2s
RAG 0.3s
WMS Tool 0.8s
MCP 0.2s
Network 0.3s
----------------
Total 2.8s如果只监控：
LLM Latency就无法发现：
WMS API才是真正的瓶颈。
九、P50 / P95 / P99
不能只看平均值。
例如：
Average Latency
2.8s看起来很好。
但是：
P50 = 1.8s
P95 = 6.5s
P99 = 18s意味着部分用户体验非常差。
因此企业Agent通常需要：
P50
P95
P99同时监控。
十、Distributed Tracing
Agent系统尤其需要Trace。
一次请求：
User
↓
Agent
↓
LLM
↓
RAG
↓
Vector DB
↓
Tool
↓
MCP
↓
ERP应该形成完整Trace：
Trace ID
│
├── Agent Span
├── LLM Span
├── RAG Span
├── Vector DB Span
├── Tool Span
├── MCP Span
└── ERP API Span这样出现问题时可以快速找到：
到底是哪一层慢了。
十一、Agent Trace
一个完整Agent Trace可以记录：
Trace
│
├── User Request
├── Agent
├── Model
├── Prompt Version
├── Knowledge Retrieval
├── Retrieved Documents
├── Tool Selection
├── Tool Input
├── Tool Result
├── Decision
└── Final Response但是要注意：
Trace不能无条件记录所有敏感内容。
应该结合：
Data Masking
PII Masking
Access Control
Retention Policy十二、日志体系
Agent日志可以分成：
Application Logs
Agent Logs
Tool Logs
Security Logs
Audit Logs
Business Logs例如：
Agent Log
Agent:
WMS-Agent
Task:
Inventory Analysis
Trace ID:
abc123
Tool:
inventory.query
Status:
Success
Latency:
320ms十三、Retry
生产环境最常见的问题之一：
Tool Timeout不能直接：
失败可以采用：
Request
↓
Tool
↓
Timeout
↓
Retry
↓
Tool
↓
Success但是：
不是所有错误都应该Retry。
十四、Retry Policy
例如：
Network Timeout
→ Retry
Rate Limit
→ Backoff Retry
Temporary Service Error
→ Retry
Permission Denied
→ Do Not Retry
Invalid Parameter
→ Do Not Retry所以Retry应该根据错误类型决定。
十五、Exponential Backoff
不能这样：
Retry
Retry
Retry
Retry
Retry否则可能造成：
Retry Storm
更合理：
1s
↓
2s
↓
4s
↓
8s即：
Exponential Backoff同时增加：
Jitter避免大量Agent同时重试。
十六、Timeout
每个Agent任务都应该有明确Timeout。
例如：
LLM Timeout
30s
RAG Timeout
5s
Tool Timeout
10s
Workflow Timeout
120s否则可能出现：
Agent
↓
Tool
↓
等待
↓
等待
↓
等待
↓
无限等待因此：
所有外部依赖都应该有Timeout。
十七、Circuit Breaker
如果ERP已经故障：
Agent
↓
ERP
↓
ErrorAgent不应该持续调用：
1000次
10000次
100000次应该：
Agent
↓
Circuit Breaker
↓
ERP当错误超过阈值：
Closed
↓
Open暂时停止调用。
恢复后：
Open
↓
Half Open
↓
Success
↓
Closed这就是：
Circuit Breaker
十八、Fallback
Agent生产系统必须考虑：
如果主模型不可用怎么办？
例如：
Primary Model
GPT
↓
Unavailable
↓
Fallback Model
↓
Continue也可以：
RAG Service
↓
Unavailable
↓
Cached Knowledge或者：
WMS API
↓
Unavailable
↓
Read Replica所以：
高可用系统不能只有Primary Path，还需要Fallback Path。
十九、Model Routing
结合第30章FinOps，还可以进行：
Dynamic Model Routing
例如：
Simple Task
↓
Small Model
Complex Reasoning
↓
Large Model
Critical Task
↓
High Reliability Model可以形成：
Task
↓
Classifier
↓
Model Router
├── Small Model
├── Medium Model
└── Large Model这样同时优化：
Cost
Latency
Quality
Reliability二十、Graceful Degradation
当部分系统不可用时：
不要让整个Agent系统全部停止。
例如：
RAG unavailable可以：
Agent
↓
Knowledge unavailable
↓
Use Structured Database
↓
Continue或者：
Recommendation unavailable
↓
Return Manual Workflow这叫：
Graceful Degradation
二十一、Queue与异步任务
有些Agent任务不应该同步执行。
例如：
生成月度经营分析报告可能需要：
5分钟不应该让HTTP请求一直等待。
可以：
User
↓
Create Task
↓
Queue
↓
Agent Worker
↓
Process
↓
Result
↓
Notify User例如：
RabbitMQ
Kafka
Redis Stream二十二、Agent Task Queue
可以设计：
Task Queue
│
├── Pending
├── Running
├── Success
├── Failed
├── Retry
├── Cancelled
└── Timeout这样Agent任务就可以被统一管理。
二十三、Agent Worker
架构：
Agent Platform
│
Queue
│
┌────────────────┼────────────────┐
↓ ↓ ↓
Worker A Worker B Worker C
│ │ │
Agent Agent Agent
│ │ │
└────────────────┼────────────────┘
↓
Enterprise这样可以实现：
Horizontal Scaling二十四、Autoscaling
Agent任务高峰：
09:00
↓
100 Requests
10:00
↓
10,000 Requests系统需要：
Worker
2
↓
10
↓
50高峰结束：
50
↓
10
↓
2这就是：
Autoscaling
二十五、Rate Limit
企业Agent必须限制：
Requests
Tokens
Tool Calls
Concurrent Tasks例如：
Tenant A
1000 requests/min
Agent A
100 requests/min
Tool A
50 calls/min避免：
Abuse
Cost Explosion
Resource Exhaustion二十六、Quota
Quota用于控制资源上限。
例如：
Tenant A
│
├── Token
10M / month
│
├── Agent
20
│
├── Tool Call
1M / month
│
└── Storage
500GB超过额度：
Warning
↓
Limit
↓
Block这也与第30章的FinOps直接关联。
二十七、Idempotency
Agent可能重复执行Tool。
例如：
Create Purchase Order由于网络超时：
Agent
↓
ERP
↓
Success
↓
Response LostAgent以为失败：
Retry
↓
Create Purchase Order结果可能产生：
PO001
PO002这就是严重的业务问题。
因此关键Tool需要：
Idempotency
例如：
Idempotency-Key:
PO-REQ-20261003-001重复请求：
Same Key
↓
Same Result二十八、Transaction与Compensation
复杂Workflow中可能出现：
Step 1
Create Purchase Request
↓
Step 2
Reserve Budget
↓
Step 3
Create PO
↓
Step 4
Notify Supplier如果：
Step 4 Failed怎么办？
不能简单：
Retry Everything可以设计：
Compensation例如：
Create PO
↓
Notify Supplier Failed
↓
Cancel PO这就是Agent Workflow中的：
补偿事务。
二十九、Agent Loop Detection
Agent还有一个特殊问题：
无限循环
例如：
Agent
↓
Tool A
↓
Tool B
↓
Tool A
↓
Tool B
↓
Tool A
↓
Tool B如果没有控制：
无限运行最终：
Token Explosion
Cost Explosion
Task Failure因此需要：
Max Steps
Max Tool Calls
Max Tokens
Max Time
Loop Detection三十、Agent Runtime Guardrail
可以建立：
Agent Runtime
│
┌────────────┼────────────┐
↓ ↓ ↓
Max Steps Max Tokens Max Time
│ │ │
└────────────┼────────────┘
↓
Loop Detector
↓
Stop / Continue三十一、Deployment Strategy
Agent升级不能直接：
Version 1
↓
Version 2生产环境应该采用：
Dev
↓
Test
↓
Staging
↓
Canary
↓
Production例如：
V2
↓
5% Traffic
↓
Monitor
↓
20%
↓
50%
↓
100%如果异常：
Rollback三十二、Agent Version
Agent不仅代码有版本。
还包括：
Agent Version
Prompt Version
Model Version
Tool Version
Knowledge Version
Workflow Version
Policy Version因此一个Agent实际上可能是：
Agent
│
├── Prompt v12
├── Model v5
├── RAG v8
├── Tool v16
└── Policy v7必须能够追踪：
这一次结果到底由哪个版本产生？
三十三、Rollback
如果上线后发现：
Task Success
96%
↓
Version 2
↓
88%应该可以：
V2
↓
Rollback
↓
V1同时恢复：
Prompt
Model
Tool
Workflow
Policy因此：
Agent平台必须具备版本化和可回滚能力。
三十四、Incident Management
生产环境一定会出现事故。
例如：
10:20
WMS Agent Error Rate
↑
10:21
Tool Timeout
↑
10:22
WMS API
Unavailable系统应该自动：
Alert
↓
Incident
↓
Diagnosis
↓
Mitigation
↓
Recovery
↓
Postmortem三十五、AI Incident Response
Agent故障处理可以设计成：
Detect
↓
Classify
↓
Contain
↓
Recover
↓
Analyze
↓
Improve例如：
Tool Error Rate > 20%
↓
Circuit Breaker
↓
Fallback
↓
Alert
↓
Engineer Investigation三十六、Runbook
生产Agent应该配套Runbook。
例如：
Incident:
WMS Agent Tool Timeout
检查：
1. WMS API
2. Network
3. MCP Server
4. Tool Queue
5. Database
6. Rate Limit
处理：
1. Enable Fallback
2. Reduce Traffic
3. Restart Worker
4. Restore Service这样出现问题时：
不依赖某一个工程师的个人经验。
三十七、Disaster Recovery
企业AI平台还需要考虑：
Database Failure
Region Failure
Model Failure
Network Failure
Storage Failure
MCP Failure因此需要：
Backup
Replication
Failover
Recovery核心指标：
RPO
RTO三十八、RPO与RTO
RPO：
Recovery Point Objective
例如：
RPO = 5 minutes意味着最多允许丢失5分钟的数据。
RTO：
Recovery Time Objective
例如：
RTO = 30 minutes意味着：
30分钟内恢复服务三十九、Enterprise Agent生产架构
最终可以形成：
Enterprise AI
│
┌───────────────────────┼───────────────────────┐
↓ ↓ ↓
Control Plane Runtime Plane Governance
│ │ │
Registry Agent Runtime Policy
Config Workflow Security
Version Task Queue Audit
│ │ │
└───────────────────────┼───────────────────────┘
↓
Observability
│
┌──────────────┼──────────────┐
↓ ↓ ↓
Metrics Logs Trace
│ │ │
└──────────────┼──────────────┘
↓
Reliability
┌──────────────┼──────────────┐
↓ ↓ ↓
Retry Fallback Circuit Breaker
↓ ↓ ↓
Timeout Queue Autoscaling
└──────────────┼──────────────┘
↓
Enterprise Systems四十、Agent生产成熟度
可以把企业Agent分成四个阶段。
Level 1：Prototype
能运行Level 2：Production
有监控
有日志
有权限Level 3：Reliable
有SLA
有Retry
有Fallback
有Auto Scaling
有DRLevel 4：Enterprise Grade
Security
Governance
FinOps
Reliability
Observability
Evaluation最终：
Prototype
↓
Production
↓
Reliable
↓
Enterprise Grade四十一、FDE需要掌握的生产能力
FDE不能只会：
Prompt
RAG
Agent进入企业生产环境之后，还必须理解：
SLA
SLO
SLI
Monitoring
Logging
Tracing
Retry
Timeout
Circuit Breaker
Fallback
Queue
Autoscaling
Rate Limit
Quota
Idempotency
Rollback
Disaster Recovery
Incident Management也就是说：
FDE不仅负责把Agent做出来，还要负责让Agent活下来。
四十二、完整的Enterprise Agent Engineering体系
经过前面的章节，现在可以把整个体系串起来：
Enterprise AI
│
┌───────────────────────┼───────────────────────┐
↓ ↓ ↓
Business Software AI
│ │ │
Process API LLM
Requirement DB RAG
ROI Cloud Agent
KPI Docker Tool
│ MCP
│ Eval
└───────────────────────┼───────────────────────┘
↓
Architecture
↓
Integration
↓
Deployment
↓
Observability
↓
Security
↓
Governance
↓
FinOps
↓
Reliability
↓
Business Value这其实就是FDE真正需要建立的能力闭环。
四十三、本章核心思想
传统软件的生产问题通常是：
服务是否稳定？
Enterprise Agent还需要进一步回答：
Agent是否稳定？
Tool是否稳定？
模型是否稳定？
RAG是否稳定？
Workflow是否稳定？
业务流程是否稳定？因此：
Agent Reliability不是单纯的服务器高可用，而是从模型、Agent、Tool、Workflow一直延伸到企业业务系统的端到端可靠性。
最终可以形成：
Observe
↓
Measure
↓
Detect
↓
Recover
↓
Optimize
↓
Improve真正成熟的Enterprise Agent，不应该只是：
"能够完成任务。"
而应该是：
"能够持续、稳定、可恢复、可追踪、可扩展地完成任务。"
四十四、下一章预告
《FDE前沿部署工程师实战教程》32
Enterprise AI Testing：Agent测试与质量工程
Agent进入生产之后，还有一个非常现实的问题：
怎么证明这个Agent真的可靠？
传统软件可以：
Unit Test
Integration Test
E2E Test但Agent还需要测试：
Prompt
RAG
Tool Calling
Reasoning
Agent Behavior
Workflow
Multi-Agent
Security
Cost
Business Outcome下一章将建立完整的：
Enterprise AI Testing
│
┌────────────────────┼────────────────────┐
↓ ↓ ↓
Model Agent System
│ │ │
LLM Eval Task Eval E2E
Prompt Eval Tool Eval API
Safety Eval Workflow Eval Load
└────────────────────┼────────────────────┘
↓
Business Eval
↓
Quality Gate
↓
Production最终解决一个关键问题：
如何从"Agent能运行"，走向"Agent可以被证明是可靠的"。