在前面的章节中，我们已经解决了三个重要问题：
第31章：
Agent如何稳定运行？
第32章：
如何证明Agent是可靠的？
但当Agent真正进入生产环境之后，还会出现一个更加现实的问题：
如果Agent出现问题，我们怎么知道问题发生在哪里？
例如用户反馈：
"采购Agent今天特别慢。"
工程师打开监控：
CPU 42%
Memory 58%
Network 35%看起来全部正常。
但是用户仍然觉得：
Agent
↓
非常慢为什么？
因为传统系统监控看到的是：
CPU
Memory
Network
QPS而Agent真正的问题可能发生在：
LLM
↓
RAG
↓
Vector DB
↓
Tool
↓
MCP
↓
ERP例如：
LLM 1.2s
RAG 0.3s
Vector DB 0.2s
Tool 6.8s
MCP 0.4s
ERP 6.1s真正的问题其实是：
ERP API变慢了。
因此企业Agent需要一种新的生产运维能力：
Enterprise AI Observability
一、什么是Observability？
Observability通常翻译为：
可观测性
它不是简单的：
MonitoringMonitoring解决的是：
"系统有没有异常？"
Observability进一步解决：
"为什么异常？"
例如：
Monitoring
Error Rate
↑只能告诉你：
系统出现错误而Observability希望进一步回答：
哪个Agent？
哪个Task？
哪个Workflow？
哪个Tool？
哪个模型？
哪个Prompt？
哪个RAG？
哪个API？最终找到：
Root Cause。
二、Monitoring与Observability
两者可以简单理解为：
Monitoring
=
发现问题而：
Observability
=
发现问题
+
理解问题
+
定位问题例如：
Monitoring
↓
Latency ↑Observability：
Latency ↑
↓
Agent Trace
↓
Tool Span
↓
ERP API
↓
Database Query
↓
Slow SQL最终定位：
ERP数据库查询变慢。
三、Enterprise AI Observability总体架构
可以建立：
Enterprise AI Observability
│
┌───────────────────┼───────────────────┐
↓ ↓ ↓
Logs Metrics Trace
│ │ │
Agent Logs Latency Agent
Tool Logs Token Workflow
Audit Logs Cost Tool
Error Logs Success RAG
└───────────────────┼───────────────────┘
↓
AI Dashboard
↓
Alert
↓
Diagnosis
↓
Automation进一步：
Observe
↓
Detect
↓
Diagnose
↓
Recover
↓
Optimize这就是企业Agent生产环境的可观测性闭环。
四、为什么Agent比传统系统更难观测？
传统应用：
Request
↓
API
↓
Service
↓
Database
↓
ResponseAgent：
Request
↓
Agent
↓
LLM
↓
Planning
↓
RAG
↓
Tool
↓
MCP
↓
Enterprise API
↓
Observation
↓
LLM
↓
Tool
↓
Final Answer甚至可能：
Agent
↓
Agent A
↓
Agent B
↓
Agent C
↓
Tool
↓
ERP因此一次用户请求可能产生：
20+
Spans甚至：
100+
Events如果没有完整Trace：
工程师根本无法知道Agent到底做了什么。
五、Agent Observability的核心对象
传统系统：
RequestAgent系统应该增加：
Request
Task
Session
Agent
Workflow
Model
Tool
RAG
Event可以形成：
User Request
│
↓
Session
│
↓
Task
│
┌──────────┼──────────┐
↓ ↓ ↓
Agent Workflow Event
│ │
┌──────┼──────┐ │
↓ ↓ ↓ ↓
LLM RAG Tool Step
│
MCP
│
API六、Request ID
首先必须解决：
怎么知道这些日志属于同一次请求？
例如：
Request ID:
REQ-20261006-001所有相关服务都携带：
Request ID例如：
API
↓
Agent
↓
RAG
↓
Tool
↓
ERP都记录：
REQ-20261006-001这样可以把整个请求串起来。
七、Trace ID
复杂Agent系统中：
Request可能进一步产生多个执行链。
因此通常还需要：
Trace ID例如：
Trace ID:
TRC-001整个调用链：
TRC-001
│
├── Agent
├── LLM
├── RAG
├── Tool
├── MCP
└── ERP八、Span
Trace可以进一步拆成多个：
Span
例如：
Trace
│
├── Agent Span
│
├── LLM Span
│
├── RAG Span
│ └── Vector DB Span
│
├── Tool Span
│
├── MCP Span
│
└── ERP API Span每个Span记录：
Start Time
End Time
Duration
Status
Attributes
Events
Error这样就能知道：
每一个步骤到底花了多少时间。
九、Agent Trace
一个完整Agent Trace可能是：
Trace ID: TRC-001
User Request
│
├── Agent
│
├── LLM #1
│
├── RAG
│ └── Vector Search
│
├── Tool Selection
│
├── Tool Call
│ └── WMS API
│
├── LLM #2
│
└── Final Answer这样工程师可以看到：
用户说了什么
Agent做了什么
模型调用了什么
检索了什么
调用了什么Tool
Tool返回什么
最终回答什么十、为什么Trace比日志更重要？
日志通常是：
2026-10-06 10:20:30
Tool inventory.query success但是单独看这条日志：
不知道它为什么被调用。
Trace则可以：
User
↓
Agent
↓
LLM
↓
Tool Selection
↓
inventory.query因此Trace能够保留：
因果关系。
这对Agent尤其重要。
十一、Agent Event
Agent运行过程中还会产生大量Event：
Task Created
Task Started
LLM Called
RAG Retrieved
Tool Selected
Tool Called
Tool Failed
Human Approval Requested
Human Approved
Workflow Step Completed
Task Completed例如：
Task
│
├── CREATED
├── RUNNING
├── TOOL_CALL
├── TOOL_SUCCESS
├── HUMAN_APPROVAL
├── APPROVED
└── COMPLETED这些Event可以帮助我们还原：
Agent完整生命周期。
十二、日志体系
Enterprise AI可以建立多层日志。
Enterprise AI Logs
│
├── Application Logs
├── Agent Logs
├── Workflow Logs
├── Tool Logs
├── Model Logs
├── RAG Logs
├── Security Logs
├── Audit Logs
└── Business Logs不同日志承担不同职责。
十三、Agent Log
例如：
Agent:
Purchase-Agent
Task:
TASK-001
Trace:
TRC-001
Status:
Running
Step:
Risk Analysis
Model:
Model-A
Prompt:
v12这样可以知道：
到底是哪一个Agent版本执行了任务。
十四、Tool Log
例如：
Tool:
purchase.create
Agent:
Purchase-Agent
Tenant:
TENANT-A
User:
USER-001
Input:
PurchaseRequest-001
Status:
Success
Latency:
320ms但需要注意：
敏感参数不能直接全部记录。
应该结合：
Masking
Encryption
Access Control
Retention十五、Security Log与Audit Log
Security Log：
关注：
Login
Authentication
Permission
Denied
Attack
InjectionAudit Log：
关注：
谁
什么时候
通过什么Agent
执行了什么操作
对什么数据
产生了什么结果例如：
User A
↓
Purchase Agent
↓
Create Purchase Order
↓
ERP
↓
PO-001必须可以审计。
十六、Metrics
日志告诉我们：
发生了什么。
Trace告诉我们：
为什么发生。
Metrics告诉我们：
整体趋势怎么样。
Agent Metrics可以分成：
System Metrics
AI Metrics
Business Metrics
Cost Metrics
Security Metrics十七、System Metrics
传统指标：
CPU
Memory
Disk
Network
QPS
Connection Pool
Queue Length这些仍然重要。
但是：
它们只是基础设施层指标。
十八、AI Metrics
Agent还需要：
LLM Requests
Token Usage
Model Latency
Model Error Rate
RAG Retrieval Count
Tool Calls
Tool Success Rate
Agent Task Success例如：
LLM Requests
1.2M
Token
820M
Tool Calls
3.6M
Task Success
96.4%十九、Latency Metrics
Agent必须重点监控延迟。
例如：
Agent Latency
│
├── LLM Latency
├── RAG Latency
├── Tool Latency
├── MCP Latency
├── Workflow Latency
└── Network Latency可以继续拆解：
Total Latency
=
LLM
+
RAG
+
Tool
+
MCP
+
Network
+
Queue二十、P50 / P95 / P99
不要只看：
Average例如：
Average = 2.5s看起来很好。
但：
P50 = 1.2s
P95 = 6.8s
P99 = 18.5s意味着：
少量用户体验非常差。
因此Agent生产监控应该重点关注：
P50
P95
P99二十一、Token Metrics
Agent的Token使用尤其重要。
例如：
Input Tokens
Output Tokens
Context Tokens
RAG Tokens
Tool Result Tokens可以统计：
Tokens / Request
Tokens / Task
Tokens / Agent
Tokens / Tenant例如：
Purchase-Agent
Average:
4,800 tokens/task如果突然变成：
18,000 tokens/task说明可能出现：
Context Explosion
Tool Output Explosion
Agent Loop
Prompt Growth二十二、Cost Metrics
结合第30章：
Cost
=
Model
+
Embedding
+
RAG
+
Tool
+
Runtime
+
InfrastructureObservability必须能够回答：
哪个Agent最贵？
哪个Tenant最贵？
哪个Task最贵？
哪个Model最贵？例如：
Agent A
¥12,000
Agent B
¥4,000
Agent C
¥85,000进一步发现：
Agent C
→ Agent Loop
→ Token Explosion于是：
Observability最终可以帮助Cost Governance。
二十三、Tool Metrics
Tool是企业Agent的重要执行能力。
应该监控：
Tool Calls
Tool Success
Tool Failure
Tool Latency
Tool Timeout
Tool Retry
Tool Permission Denied例如：
inventory.query
Calls:
1,200,000
Success:
99.2%
P95:
420ms
Timeout:
0.3%二十四、RAG Metrics
RAG也需要生产观测。
例如：
Retrieval Count
Top-K
Retrieval Latency
Empty Retrieval
Document Version
Knowledge Base
Embedding Model甚至可以结合Evaluation：
Context Relevance
Faithfulness
Answer Relevance形成：
RAG Observability
+
RAG Evaluation二十五、Model Routing Observability
如果平台支持Model Router：
Task
↓
Model Router
├── Small Model
├── Medium Model
└── Large Model就需要知道：
Task Distribution
Model Distribution
Success Rate
Latency
Cost例如：
Small Model
60%
Medium Model
30%
Large Model
10%如果Large Model突然变成：
40%说明：
路由策略可能发生异常。
二十六、Alert
Observability最终必须能够：
自动发现异常。
例如：
Tool Error Rate > 5%触发：
Alert例如：
Task Success < 90%触发：
Critical Alert二十七、Alert分级
可以建立：
P1
Critical
P2
High
P3
Medium
P4
Low例如：
P1
ERP全部不可用
P2
WMS Tool Error > 20%
P3
Latency增加30%
P4
单个Agent性能下降二十八、智能告警
传统：
CPU > 80%但是AI系统更需要：
Task Success
下降例如：
Task Success
96%
↓
94%
↓
91%即使：
CPU
50%系统也应该告警。
因为：
业务层已经出现异常。
二十九、Anomaly Detection
可以进一步使用AI进行异常检测。
例如：
历史Token：
1000
1200
1100
1300
1250突然：
28,000系统可以检测：
Anomaly同样可以用于：
Latency
Cost
Tool Calls
Task Duration
Error Rate三十、Agent Loop Detection
例如正常：
平均Tool Calls
3.2突然：
Tool Calls
48可能意味着：
Agent Loop可以设置：
Tool Calls > 20触发：
Warning如果：
Tool Calls > 50执行：
Stop Task三十一、Context Explosion
另一个典型问题：
Context
8K
↓
20K
↓
50K
↓
100K结果：
Latency ↑
Cost ↑
Quality ↓Observability可以发现：
Context Tokens
↑进一步定位：
RAG
Tool Output
Memory
Prompt到底是谁造成Context增长。
三十二、Tool Output Explosion
例如：
inventory.query本来应该返回：
{
"sku": "SKU001",
"available": 1200
}结果Tool返回：
50000条库存记录然后：
Tool
↓
LLM
↓
Context ExplosionObservability可以发现：
Tool Output Tokens
↑↑↑最终定位Tool设计问题。
三十三、Agent Dashboard
Enterprise AI应该建立专门Dashboard。
例如：
┌────────────────────────────────────────────┐
│ Enterprise AI Dashboard │
├────────────────────────────────────────────┤
│ │
│ Agents 128 Tasks 4.6M │
│ Success 96.4% Error 1.2% │
│ P95 4.2s Cost ¥8,620 │
│ Tokens 1.82B Tool Calls 8.2M │
│ │
├────────────────────────────────────────────┤
│ Agent Health │
│ │
│ Purchase Agent 99.2% │
│ WMS Agent 97.8% │
│ MES Agent 94.1% │
│ CRM Agent 98.7% │
│ │
└────────────────────────────────────────────┘三十四、Agent Health Score
甚至可以建立：
Agent Health Score例如：
Health Score
=
Availability
+
Success
+
Latency
+
Error
+
Cost
+
Security例如：
Purchase Agent
96如果下降：
96
↓
91
↓
83系统自动触发：
Investigation三十五、Root Cause Analysis
Observability的最终目标：
Root Cause Analysis
例如：
Task Success ↓系统进一步：
Task
↓
Workflow
↓
Tool
↓
MCP
↓
ERP
↓
Database发现：
ERP API Latency
↑再发现：
SQL Query
↑最终：
Missing Database Index于是：
真正的Root Cause被定位出来。
三十六、从Alert到Diagnosis
完整流程：
Metric
↓
Alert
↓
Trace
↓
Log
↓
Event
↓
Dependency
↓
Root Cause这比传统：
服务器报警
↓
工程师人工排查效率高得多。
三十七、AI辅助运维
进一步可以让Agent自己参与Observability。
例如：
Monitoring Agent发现：
WMS Agent Error Rate
↑然后自动：
查询Trace
↓
分析Logs
↓
检查Tool
↓
检查ERP
↓
分析历史
↓
生成Incident Report最终：
Incident:
WMS API latency abnormal
Root Cause:
ERP database slow query
Impact:
12% tasks delayed
Recommendation:
Enable fallback
Optimize SQL这就是：
AIOps + Agent
三十八、Observability Agent
可以建立：
Observability Agent
│
┌──────────────┼──────────────┐
↓ ↓ ↓
Logs Metrics Trace
│ │ │
└──────────────┼──────────────┘
↓
Analysis Agent
↓
Root Cause
↓
Recommendation
↓
Human Approval
↓
Action注意：
自动分析可以，但高风险修复仍然需要权限控制和人工审批。
三十九、Observability与Security
Observability不能绕过安全。
例如Trace中可能包含：
Customer Data
Employee Data
Purchase Data
Financial Data
API Key
Token因此：
Observability
+
Security必须一起设计。
需要：
Masking
Encryption
RBAC
Retention
Access Control
Audit四十、Observability与Multi-Tenant
多租户环境：
Tenant A
Tenant B
Tenant CDashboard必须隔离：
Tenant A
↓
只看到Tenant A数据平台管理员：
Platform Admin
↓
全局View因此Observability本身也需要：
Tenant Isolation四十一、Observability与Governance
Enterprise AI Governance需要知道：
哪个Agent？
哪个Model？
哪个Prompt？
哪个Tool？
哪个Knowledge？
哪个Version？Observability提供运行时证据。
因此：
Governance
+
Observability形成：
Policy
↓
Runtime
↓
Trace
↓
Audit四十二、Observability与Evaluation
第32章介绍：
Evaluation第33章介绍：
Observability两者应该结合。
例如：
Production
↓
Trace
↓
Sample
↓
Evaluation
↓
Quality Score发现：
Task Success
96%
↓
92%再通过Trace：
Tool Error
↑最终定位问题。
所以：
Observability告诉你"发生了什么"，Evaluation告诉你"结果好不好"。
四十三、Observability与Reliability
第31章：
Reliability第33章：
Observability关系：
Observability
↓
发现问题
↓
Reliability
↓
恢复问题例如：
Tool Timeout
↓
Observability Detect
↓
Circuit Breaker
↓
Fallback
↓
Recovery因此：
没有Observability，很难做好Reliability。
四十四、Enterprise AI全链路可观测架构
最终可以形成：
Enterprise AI
│
┌────────────┼────────────┐
↓ ↓ ↓
Agent Workflow Tool
│ │ │
└────────────┼────────────┘
↓
Observability SDK
│
┌───────────────────┼───────────────────┐
↓ ↓ ↓
Logs Metrics Trace
│ │ │
Agent Logs AI Metrics Agent
Tool Logs Token Workflow
Model Logs Cost Tool
Audit Logs Latency RAG
Error Logs Success MCP
└───────────────────┼───────────────────┘
↓
Observability Platform
│
┌───────────────┼───────────────┐
↓ ↓ ↓
Dashboard Alert Analytics
│ │ │
└───────────────┼───────────────┘
↓
Root Cause Analysis
↓
Incident Response
↓
Recovery四十五、Enterprise AI Observability四层模型
可以把整个体系总结成四层：
Observability
│
┌──────────────┼──────────────┐
↓ ↓ ↓
Logs Metrics Trace
│ │ │
└──────────────┼──────────────┘
↓
Analytics
│
↓
Intelligence
│
↓
Action也就是：
Data
↓
Insight
↓
Decision
↓
Action四十六、FDE如何设计Observability？
在客户项目中，FDE至少应该回答以下问题：
1. 用户请求能否追踪？
Request ID
Trace ID
Task ID
Session ID2. Agent做了什么？
Agent Trace3. 模型做了什么？
Model Span
Token
Latency4. RAG做了什么？
Retrieval
Documents
Latency5. Tool做了什么？
Tool Call
Input
Output
Latency
Status6. 为什么失败？
Error
Trace
Dependency7. 花了多少钱？
Token
Model
Runtime
Tool8. 业务结果怎么样？
Task Success
Business KPI四十七、FDE Observability Checklist
生产Agent上线前：
□ Request ID
□ Trace ID
□ Task ID
□ Session ID
□ Agent Trace
□ Workflow Trace
□ Tool Trace
□ MCP Trace
□ RAG Trace
□ Model Trace
□ Application Logs
□ Agent Logs
□ Tool Logs
□ Security Logs
□ Audit Logs
□ Latency
□ Error Rate
□ Task Success
□ Tool Success
□ Token
□ Cost
□ P50
□ P95
□ P99
□ Alert
□ Dashboard
□ Root Cause Analysis
□ Tenant Isolation
□ Data Masking
□ Retention Policy
□ Incident Response
□ Runbook
□ Recovery四十八、从Monitoring到AI Observability
传统系统：
Server Monitoring
↓
Application Monitoring
↓
APM企业Agent：
Infrastructure
↓
Application
↓
Agent
↓
LLM
↓
RAG
↓
Tool
↓
Workflow
↓
Business因此Observability也从：
Infrastructure Observability扩展到：
AI System Observability
最终再扩展到：
Business Observability
因为企业真正关心的是：
AI是否产生了业务价值。
四十九、Enterprise AI Operating System中的Observability
到了现在，我们可以把Observability放回Enterprise AI OS。
Enterprise AI OS
│
┌───────────────────┼───────────────────┐
↓ ↓ ↓
Control Plane Runtime Plane Governance
│ │ │
Registry Agent Security
Policy Workflow Policy
Version Task Audit
│ │ │
└───────────────────┼───────────────────┘
↓
Observability Layer
│
┌────────────┼────────────┐
↓ ↓ ↓
Logs Metrics Trace
│ │ │
└────────────┼────────────┘
↓
Evaluation
↓
Reliability
↓
FinOps
↓
Business Value这说明：
Observability不是Enterprise AI中的一个孤立模块，而是连接Runtime、Security、Evaluation、Reliability、FinOps和Governance的重要基础设施。
五十、FDE能力再次升级
最开始：
FDE
↓
部署Agent后来：
FDE
↓
部署Agent
↓
监控Agent再进一步：
FDE
↓
理解Agent运行过程
↓
定位问题
↓
分析质量
↓
分析成本
↓
分析业务价值最终：
FDE
↓
Enterprise AI Operations这时候FDE已经逐渐从：
Deployment Engineer走向：
AI Platform Engineer
AI Reliability Engineer
AI Solutions Architect五十一、一个完整案例：AI采购Agent故障分析
假设企业使用：
AI采购Agent上午10:00开始出现：
Task Success
96%
↓
89%系统触发Alert。
第一步：Metrics
发现：
Tool Error Rate
2%
↓
18%第二步：Trace
查看失败任务：
Agent
↓
Risk Analysis
↓
purchase.create
↓
Timeout第三步：Tool Log
发现：
purchase.create
P95:
500ms
↓
7.8s第四步：MCP
继续追踪：
Tool
↓
MCP
↓
ERP API发现ERP API延迟：
800ms
↓
8.2s第五步：ERP
进一步查看：
ERP
↓
Database
↓
SQL发现：
Slow Query第六步：Root Cause
最终：
Missing Index导致：
ERP Query Slow
↓
ERP API Slow
↓
MCP Slow
↓
Tool Timeout
↓
Agent Task Failed完整链路：
Database
↓
ERP
↓
MCP
↓
Tool
↓
Agent
↓
Business Task这就是Observability真正的价值：
从用户看到的"Agent不好用了"，一直追踪到最底层Root Cause。
五十二、Enterprise AI运维闭环
最终整个体系形成：
Production
│
↓
Observe
│
┌───────────────┼───────────────┐
↓ ↓ ↓
Logs Metrics Trace
└───────────────┼───────────────┘
↓
Detect
↓
Diagnose
↓
Root Cause
↓
Remediation
↓
Recovery
↓
Evaluation
↓
Optimize
↓
Release
↓
Production这是一个持续循环。
五十三、本章核心总结
Enterprise AI Observability解决的不是：
"系统有没有日志？"
而是：
"我们能不能理解AI系统正在发生什么？"
一个成熟的Agent生产环境应该能够回答：
谁发起了任务？
哪个Tenant？
哪个Agent？
哪个版本？
使用哪个Model？
使用哪个Prompt？
检索了哪些Knowledge？
调用了哪些Tool？
经过哪些Workflow？
调用了哪个MCP？
花了多少Token？
花了多少钱？
耗时多少？
为什么失败？
最终业务结果是什么？因此：
Logs
+
Metrics
+
Trace
+
Events
+
Evaluation
+
Business KPI共同构成：
Enterprise AI Observability
五十四、最终形成完整的AI生产工程体系
从前面的章节开始，我们已经逐渐建立起完整的Enterprise AI工程体系：
Business
↓
Requirement
↓
Architecture
↓
RAG
↓
Agent
↓
Tool
↓
MCP
↓
Workflow
↓
Runtime
↓
Security
↓
Governance
↓
FinOps
↓
Reliability
↓
Testing
↓
Observability
↓
Evaluation
↓
Production
↓
Business Value这已经不再是简单的：
AI Application而是一套完整的：
Enterprise AI Engineering
五十五、FDE真正需要理解的一句话
如果说：
Agent
=
让AI能够执行任务那么：
Reliability
=
让Agent稳定执行
Testing
=
证明Agent执行正确
Observability
=
理解Agent正在如何执行最终：
Agent
+
Reliability
+
Testing
+
Observability
+
Security
+
Governance
+
FinOps才能真正形成：
Enterprise-Grade AI
五十六、下一章预告
《FDE前沿部署工程师实战教程》34
Enterprise AI Data Plane：Context、Knowledge、Memory与Business Data统一架构
当Enterprise AI进入生产之后，一个新的问题会越来越重要：
Agent到底应该看到什么数据？
Agent可能同时需要：
Business Data
Knowledge
Memory
Events
Metadata
User Context
Tenant Context例如：
Enterprise AI Data Plane
│
┌─────────────────────┼─────────────────────┐
↓ ↓ ↓
Business Data Knowledge Memory
│ │ │
ERP / WMS / MES RAG User
CRM / OA / HR Vector Task
DB / API Document Agent
└─────────────────────┼─────────────────────┘
↓
Events
│
Event Bus
↓
Context Builder
↓
Context Package
↓
Agent / Workflow下一章将进一步回答一个越来越重要的问题：
在Enterprise AI中，数据不是简单地"给Agent"，而是要经过身份、权限、租户、知识、记忆和业务上下文处理之后，形成一个可控的Context Package。
也就是说，Enterprise AI正在从：
AI + Data逐渐走向：
Context Engineering
+
Enterprise Data Plane而这将成为下一阶段Enterprise AI架构的核心基础。