在前面的章节中我们已经解决了三个重要问题第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一、什么是ObservabilityObservability通常翻译为可观测性它不是简单的MonitoringMonitoring解决的是“系统有没有异常”Observability进一步解决“为什么异常”例如Monitoring Error Rate ↑只能告诉你系统出现错误而Observability希望进一步回答哪个Agent 哪个Task 哪个Workflow 哪个Tool 哪个模型 哪个Prompt 哪个RAG 哪个API最终找到Root Cause。二、Monitoring与Observability两者可以简单理解为Monitoring 发现问题而Observability 发现问题 理解问题 定位问题例如Monitoring ↓ Latency ↑ObservabilityLatency ↑ ↓ 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 ↓ ResponseAgentRequest ↓ 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八、SpanTrace可以进一步拆成多个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 EventAgent运行过程中还会产生大量EventTask 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 LogSecurity 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 MetricsAgent还需要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 MetricsAgent必须重点监控延迟。例如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 MetricsAgent的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 MetricsTool是企业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 MetricsRAG也需要生产观测。例如Retrieval Count Top-K Retrieval Latency Empty Retrieval Document Version Knowledge Base Embedding Model甚至可以结合EvaluationContext Relevance Faithfulness Answer Relevance形成RAG Observability RAG Evaluation二十五、Model Routing Observability如果平台支持Model RouterTask ↓ 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%说明路由策略可能发生异常。二十六、AlertObservability最终必须能够自动发现异常。例如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 DashboardEnterprise 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 AnalysisObservability的最终目标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与SecurityObservability不能绕过安全。例如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与GovernanceEnterprise AI Governance需要知道哪个Agent 哪个Model 哪个Prompt 哪个Tool 哪个Knowledge 哪个VersionObservability提供运行时证据。因此Governance Observability形成Policy ↓ Runtime ↓ Trace ↓ Audit四十二、Observability与Evaluation第32章介绍Evaluation第33章介绍Observability两者应该结合。例如Production ↓ Trace ↓ Sample ↓ Evaluation ↓ Quality Score发现Task Success 96% ↓ 92%再通过TraceTool 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企业AgentInfrastructure ↓ 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前沿部署工程师实战教程》34Enterprise AI Data PlaneContext、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架构的核心基础。