前面的章节我们已经逐步建立了Enterprise AI ↓ Context Engine ↓ Agent Runtime ↓ Workflow Runtime ↓ AI Gateway ↓ Model / Tool / MCP ↓ ERP / WMS / MES / CRM / OA从架构上看这已经是一套比较完整的企业AI平台。但是当系统真正上线之后客户通常不会问“你的Agent架构图漂亮吗”他们真正关心的是“这个系统每天运行10万次会不会出问题”例如Agent执行到一半超时怎么办 LLM突然不可用怎么办 ERP接口失败怎么办 Tool执行成功但是Agent没有收到结果怎么办 用户重复点击两次会不会创建两张采购订单 Agent运行到一半服务器重启怎么办 Workflow执行了30分钟状态丢失怎么办 一个Agent进入死循环怎么办 一个Tenant突然产生百万请求会不会影响其他客户这些问题都属于Reliability也就是可靠性工程。一、AI Demo与Production的区别一个Demo通常是User ↓ Agent ↓ LLM ↓ Answer只要能够返回结果就算成功。Production则完全不同User ↓ Authentication ↓ Tenant ↓ Agent ↓ Context ↓ Workflow ↓ AI Gateway ↓ LLM ↓ Tool ↓ Enterprise API ↓ Database中间任何一个环节都有可能Timeout Error Overload Network Failure Data Conflict Service Restart因此企业Agent真正的工程难点不只是让Agent能够工作而是让Agent在异常情况下仍然能够正确工作。二、Enterprise AI Reliability到底是什么可以简单理解为Reliability 系统在正常和异常情况下 持续提供正确服务的能力它至少包括Availability Latency Timeout Retry Fallback Circuit Breaker Idempotency Queue Backpressure Checkpoint State Recovery Disaster Recovery进一步还需要考虑Data Consistency Task Consistency Agent State Workflow State Tool State Audit State三、可靠性不能只看“服务是否在线”传统系统经常使用Availability例如99.9% 99.99% 99.999%但是Agent系统不能只看服务有没有响应。还需要考虑响应是否正确 Tool是否真正执行 Workflow状态是否正确 业务操作是否重复 Agent是否进入循环例如HTTP 200并不代表采购订单创建成功可能出现ERP已经创建订单 ↓ 网络断开 ↓ Agent没有收到响应Agent认为失败然后再次执行Create Purchase Order结果订单创建两次这就是典型的Distributed System Reliability Problem四、Agent系统本质上也是分布式系统很多人第一次开发Agent时会认为Agent LLM Prompt但是进入企业生产环境以后Agent ↓ LLM ↓ RAG ↓ Vector DB ↓ Tool ↓ MCP ↓ ERP ↓ Database ↓ Message Queue已经非常接近一个复杂的分布式系统。所以FDE需要开始掌握分布式系统 AI而不是只掌握Prompt五、第一项能力AvailabilityAvailability就是系统在多长时间内能够正常提供服务。例如99%表示一年中允许一定时间不可用。而99.99%要求明显更高。企业关键系统可能进一步要求High Availability例如Agent Runtime Agent Runtime Agent Runtime部署多个实例。六、Agent Runtime高可用不要Agent Runtime │ Instance而应该Load Balancer │ ┌────────────┼────────────┐ ↓ ↓ ↓ Agent A Agent B Agent C某一个实例发生Crash其他实例仍然可以Continue七、Stateless与Stateful这是Agent Runtime设计中的关键问题。如果Agent完全无状态Request ↓ Agent ↓ Response扩容非常简单Instance A Instance B Instance C但是企业Agent通常存在Conversation State Workflow State Task State Memory Approval State Tool State例如采购Agent ↓ 分析采购需求 ↓ 等待人工审批这时候Agent不能简单依赖服务器内存因为Instance A可能重启。八、State Externalization更可靠的方法是Agent Runtime │ ↓ State Store例如Redis Database Object Storage Event Store架构Agent Runtime │ ┌────────────┼────────────┐ ↓ ↓ ↓ State Memory Checkpoint │ │ │ └────────────┼────────────┘ ↓ Persistent Store这样Agent Instance即使发生Restart仍然可以Recover九、第二项能力TimeoutAI系统尤其容易遇到Slow Model Slow Tool Slow API Network Delay如果没有TimeoutRequest ↓ Agent ↓ Tool ↓ 一直等待最终Thread Connection Memory全部被占用。因此所有外部调用都应该有明确的Timeout。十、Timeout应该分层例如Agent Timeout │ ├── Context Timeout │ ├── LLM Timeout │ ├── Tool Timeout │ ├── MCP Timeout │ └── Enterprise API Timeout例如RAG 3s LLM 30s Tool 10s ERP API 10s 整个Task 120s这样系统才不会某一个Tool卡住 ↓ 整个Agent永久等待十一、第三项能力Retry企业系统一定会出现临时错误。例如Network Error 429 502 503 504这时候可以Retry但Retry必须谨慎。十二、什么情况下可以Retry通常Temporary Network Error Timeout 429 502 503 504可以考虑Retry。而400 401 403 Business Validation Error Permission Denied通常不能简单Retry。例如ERP ↓ 库存不足Retry 100次也不会让库存增加。所以Retry解决的是临时故障不是业务错误。十三、Exponential Backoff不能Retry ↓ 立即Retry ↓ 立即Retry否则会形成Retry Storm应该第1次 等待1秒 第2次 等待2秒 第3次 等待4秒也就是Exponential Backoff同时设置Max Retry例如最多3次十四、第四项能力Circuit Breaker假设ERP API已经连续失败Failure Failure Failure Failure Failure如果所有Agent继续调用Agent A → ERP Agent B → ERP Agent C → ERP Agent D → ERP只会让ERP压力越来越大。所以需要Circuit Breaker十五、Circuit Breaker工作方式Closed │ Error Increase ↓ Open │ Wait ↓ Half Open / \ ↓ ↓ Success Failure ↓ ↓ Closed Open当系统判断ERP异常暂时停止请求。这样可以防止局部故障扩散成全局故障。十六、第五项能力Fallback例如Primary Model突然不可用。可以Model A ↓ Failure ↓ Model B例如Cloud Model ↓ Network Failure ↓ Private Model但是Fallback不能只考虑能不能返回结果还要考虑能力是否兼容 Context是否足够 Tool Calling是否支持 Structured Output是否支持否则可能主模型支持Tool Calling 备用模型不支持Agent就会发生新的错误。十七、第六项能力Idempotency这是企业Agent最重要的可靠性能力之一。什么叫Idempotency简单理解同一个业务请求执行一次和执行多次最终结果应该一致。例如Create Purchase Order用户点击提交网络发生问题Request Timeout客户端再次发送提交如果没有幂等PO001 PO002创建两个订单。十八、Idempotency Key可以设计Idempotency-Key: purchase-request-20260930-001第一次Key ↓ Create ↓ Success第二次Same Key ↓ Already Processed ↓ Return Previous Result这样PO001不会变成PO001 PO002十九、Agent中的IdempotencyAgent调用Tool时也应该考虑Tool ↓ Business Operation例如create_purchase_order cancel_order refund payment shipment inventory_adjustment这些操作都应该重点考虑幂等。尤其是资金 库存 订单 合同 审批等高风险业务。二十、第七项能力Queue有些任务不适合同步执行例如生成10万条商品分析 批量处理100万条数据 生成大量报表 批量调用ERP应该Request ↓ Queue ↓ Worker ↓ Process例如User ↓ Create Task ↓ Message Queue ↓ Agent Worker ↓ Result二十一、为什么Agent需要Queue因为Agent任务可能耗时 不可预测 并发量高 需要重试 需要暂停 需要恢复Queue可以把生产和消费解耦。形成Producer ↓ Message Queue ↓ Worker ↓ Agent二十二、第八项能力Backpressure如果请求速度 系统处理速度就会出现Queue Queue Queue Queue最终Memory CPU Database全部被压垮。所以需要Backpressure也就是当系统处理不过来时主动限制进入系统的流量。例如正常 1000 req/min 高负载 500 req/min 极端负载 Reject / Queue二十三、Tenant级别BackpressureMulti-Tenant场景尤其重要。假设Tenant A突然产生1,000,000 requests如果没有隔离Tenant A ↓ 占满GPU ↓ 占满Queue ↓ Tenant B ↓ 全部变慢因此需要Tenant Quota Tenant Rate Limit Tenant Queue Tenant Concurrency最终Tenant A ├── Queue A └── Worker A Tenant B ├── Queue B └── Worker B二十四、第九项能力CheckpointAgent执行长流程时Step 1 ↓ Step 2 ↓ Step 3 ↓ Step 4 ↓ Step 5如果执行到Step 4服务器突然Crash如果没有Checkpoint重新开始如果有Checkpoint则Step 1 ✓ Step 2 ✓ Step 3 ✓ Step 4 ✓ Step 5 ✗恢复后从Step 4/5继续二十五、Workflow Checkpoint例如采购流程Validate ✓ ↓ Check Inventory ✓ ↓ Risk Analysis ✓ ↓ Human Approval ✓ ↓ Create PO ✗系统恢复后从Create PO继续而不是重新检查库存 重新分析风险 重新审批二十六、第十项能力State Recovery一个完整Agent任务应该有状态CREATED RUNNING WAITING PAUSED FAILED RETRYING COMPLETED CANCELLED例如Agent Task │ ├── CREATED ↓ RUNNING │ ├── WAITING │ ↓ │ APPROVAL │ ├── RETRYING │ ├── FAILED │ └── COMPLETED这样系统才能知道这个Agent到底运行到哪里了。二十七、Human Approval也是一种State结合之前的Human-in-the-loopAgent ↓ Risk Analysis ↓ WAITING_APPROVAL此时Agent不能被认为FAILED而应该是WAITING审批之后APPROVED ↓ RESUME或者REJECTED ↓ END所以Human-in-the-loop本质上也是Workflow State的一部分。二十八、Agent Loop DetectionAgent还有一种传统系统不太常见的问题无限循环例如Agent ↓ Tool ↓ Error ↓ Agent ↓ Tool ↓ Error ↓ Agent ↓ Tool如果没有控制无限循环最终导致Token暴涨 成本暴涨 系统资源耗尽二十九、Loop Guard可以设置Max Steps Max Tool Calls Max Tokens Max Runtime Max Retry例如Max Steps 20 Max Tool Calls 30 Max Runtime 5 min达到阈值STOP并记录Agent Loop Detected三十、Token Budget也是可靠性机制Token不仅是成本问题。它也是资源保护机制。例如Agent Task Token Budget 50K如果已经消耗48K系统可以Warning超过50K执行Stop这样可以防止Prompt Loop Agent Loop Context Explosion三十一、Context ExplosionAgent运行过程中可能不断加入Conversation RAG Tool Result History Memory Documents最终Context 越来越大导致Latency ↑ Cost ↑ Error ↑因此需要Context Compression Context Summarization Memory Management Relevant Retrieval这又与前面的Context Engineering形成闭环。三十二、第十一项能力Dead Letter Queue如果一个任务连续失败Retry 1 Retry 2 Retry 3仍然失败。不能无限Retry。应该进入Dead Letter Queue例如Queue ↓ Worker ↓ Failure ↓ Retry ↓ Retry ↓ Retry ↓ DLQ然后人工或后台系统Inspect Repair Replay三十三、Replay企业AI系统非常需要Replay例如Task ID: TASK-20260930-001历史执行Input Context Model Prompt Tool Calls Results State全部记录。出现问题后可以Replay重新执行。这对Debug Evaluation Incident Analysis都非常重要。三十四、Disaster Recovery真正企业级平台还需要考虑服务器故障 数据库故障 Redis故障 消息队列故障 GPU故障 机房故障因此需要Backup Replication Failover Recovery例如Primary │ ↓ Database │ ↓ Replica或者Region A │ ↓ Region B三十五、RTO与RPO企业项目中经常需要定义RTORecovery Time Objective故障后允许多久恢复。例如RTO 30 min表示30分钟内恢复服务RPORecovery Point Objective最多允许丢失多久的数据。例如RPO 5 min意味着最多允许丢失5分钟的数据三十六、Agent Reliability完整模型到这里可以把Reliability体系总结成Agent Reliability │ ┌───────────────────┼───────────────────┐ ↓ ↓ ↓ Availability Resilience Consistency │ │ │ Scaling Retry Idempotency Health Check Timeout State Load Balance Fallback Checkpoint Circuit Breaker Recovery │ │ │ └───────────────────┼───────────────────┘ ↓ Resource Control │ ┌────────────┼────────────┐ ↓ ↓ ↓ Rate Limit Queue Token ↓ ↓ ↓ Backpressure Worker Budget ↓ Observability ↓ Replay ↓ Audit三十七、一个完整的生产级Agent现在重新来看之前的采购Agent。最初User ↓ Agent ↓ ERP生产级User ↓ Authentication ↓ Tenant ↓ Policy ↓ Agent Runtime ↓ Context Engine ↓ Workflow ↓ AI Gateway ↓ Rate Limit ↓ Quota ↓ Model Routing ↓ LLM ↓ Risk Analysis ↓ Human Approval ↓ Tool ↓ Idempotency ↓ ERP ↓ Checkpoint ↓ Audit ↓ Observability如果ERP暂时不可用ERP ↓ Timeout ↓ Retry ↓ Circuit Breaker ↓ Queue ↓ Recovery这才是真正的Production Agent。三十八、FDE如何进行Reliability设计FDE拿到一个客户项目之后可以按照下面的方式分析。Step 1找出关键业务链路例如采购申请 库存检查 风险判断 订单创建Step 2找出外部依赖LLM RAG ERP WMS Database Message QueueStep 3定义每个依赖的Failure例如LLM → Timeout ERP → 503 WMS → Network Error Database → Connection Pool ExhaustedStep 4定义RecoveryTimeout → Retry Model Failure → Fallback ERP Failure → Queue Database Failure → FailoverStep 5定义业务幂等重点检查订单 支付 库存 退款 审批 合同Step 6定义StateCreated Running Waiting Retrying Failed CompletedStep 7定义Observability至少记录Trace ID Task ID Tenant ID Agent ID Model Tool Latency Tokens Cost Status Error三十九、Reliability ChecklistFDE交付Enterprise Agent之前可以进行检查项是否需要Health Check✓Timeout✓Retry✓Backoff✓Circuit Breaker✓Fallback✓Rate Limit✓Token Limit✓Queue按场景Idempotency高风险操作必须Checkpoint长流程必须State Recovery✓DLQ异步任务建议Replay建议Audit企业场景必须Monitoring✓Alert✓Backup✓Disaster Recovery按业务等级四十、本章核心思想很多人认为Agent开发 Prompt LLM Tool但真正进入Enterprise Production之后Agent AI Software Engineering Distributed Systems Security Reliability Observability因此Agent能回答问题只能说明AI能力存在。而Agent能够在异常、超时、网络故障、服务重启、重复请求和高并发情况下依然正确完成业务才说明它具备生产能力。四十一、FDE能力再次升级到了这里FDE的能力体系已经进一步扩展FDE │ ┌─────────────┼─────────────┐ ↓ ↓ ↓ Business Software AI Engineering Engineering Engineering │ │ │ ROI API LLM KPI DB RAG Process Docker Agent Workflow Cloud Tool MCP Eval │ ↓ Integration ↓ Deployment ↓ Reliability ↓ Observability ↓ Governance ↓ Business ValueFDE已经不再只是“把Agent做出来的人。”而是“把Agent真正运行在企业生产环境中的人。”四十二、下一章预告《FDE前沿部署工程师实战教程》29Enterprise AI SecurityAgent安全体系设计当Agent开始访问ERP 访问WMS 访问MES 读取企业知识库 调用MCP 执行Tool 修改业务数据新的问题就来了“如果Agent被攻击或者Agent做错了会发生什么”下一章将进入Enterprise Agent最核心的安全体系Identity Authentication Authorization RBAC ABAC Tenant Isolation Data Permission Tool Permission Prompt Injection Indirect Prompt Injection Data Exfiltration Tool Abuse Agent Hijacking Secrets Management Audit Policy Enforcement Human Approval并进一步建立Enterprise AI Security │ ┌───────────────────┼───────────────────┐ ↓ ↓ ↓ Identity Data Agent │ │ │ Authentication Classification Permission Authorization Encryption Tool Policy RBAC DLP Guardrails ABAC Masking Sandbox └───────────────────┼───────────────────┘ ↓ Security Gateway ↓ Agent / Tool / MCP ↓ Enterprise Systems下一章将回答一个关键问题“如何让Agent拥有足够的权限完成工作同时又不会拥有过大的权限”补充本章开头摘要与学习目标增加可靠性故障演练案例统一中英文术语和章节表达