企业做AI Agent，最容易被演示打动的一刻，通常是它真的办成了一件事。
一句话查数据，一句话生成申请，一句话调接口，一句话推动审批。现场看起来很顺，业务负责人也会觉得，这套东西终于不只是聊天了，开始能进入流程、进入系统、进入真实工作。
但真正上线以后，FDE前沿部署工程师很快会遇到另一个问题：Agent办事不可能每次都顺。
用户少说了一个条件，Agent不知道该选哪批数据。
接口返回超时，前一步已经成功，后一步没有完成。
审批规则变了，系统发现这张单据不能继续提交。
外部系统状态被别人改过，Agent拿到的上下文已经过期。
模型给出的建议看起来合理，但业务人员觉得风险太高，不想让它继续执行。
这些情况都很正常。企业系统本来就充满分支、例外、权限、等待、驳回、撤回和人工判断。AI Agent进入企业执行层以后，也会遇到这些东西。
所以，FDE在设计Agent方案时，不能只画成功路径。只画成功路径的Agent，很适合演示，不适合长期跑业务。
企业真正需要的是一套异常处理机制：Agent执行失败后，系统能停得住、说得清、交得出去、补得回来，并且下次能少踩同一个坑。
前面几篇我们已经讲了业务对象、审批流、权限体系、API调用和操作日志。到这一篇，就要把问题继续往前推一步：当Agent执行中间出错时，FDE怎么设计异常处理、人工接管和补救恢复。
一、企业Agent真正怕的是失败后没人接
Agent执行失败并不可怕。
企业系统每天都会失败。接口会超时，流程会驳回，字段会校验不通过，权限会被拒绝，数据会冲突，用户也会填错信息。成熟的业务系统本来就要处理这些异常。
真正麻烦的是，Agent失败以后没有明确出口。
比如销售让Agent批量更新客户状态，系统处理中有30条成功，5条失败。失败的5条是权限问题、数据冲突，还是字段缺失？谁来看？要不要重试？成功的30条要不要保留？这件事如果没有机制承接，业务人员就会开始不信任系统。
再比如设备维修场景里，Agent根据告警自动创建工单，同时要通知维修负责人。工单创建成功了，通知发送失败了。对技术系统来说，这可能只是一个消息推送失败。对业务现场来说，没人收到通知，设备可能继续停在那里。
FDE要把这类问题提前说清楚。
Agent能办事以后，异常处理就不再只是技术排障。它还关系到责任、流程、现场效率和数据可信度。
如果失败后只弹一句“系统异常，请稍后重试”，企业基本不敢把关键动作交给Agent。因为业务人员不知道它到底做到哪一步，也不知道接下来该找谁。
所以FDE设计Agent时，第一条原则很朴素：能失败，就要能接住。
这个“接住”至少包含四件事。
第一，系统要知道失败发生在哪一步。
第二，业务人员要看得懂失败原因。
第三，要有明确的处理人或处理流程。
第四，已经产生的影响要能补救。
这四件事做好了，Agent才有机会从辅助工具进入真实业务。
二、异常要先分类，不能都扔给人工处理
很多团队处理异常时，容易走两个极端。
一种是所有异常都让系统自动重试。看起来省事，但风险很高。付款类、审批类、批量写入类动作，如果盲目重试，可能造成重复单据、重复通知、重复修改。
另一种是所有异常都转人工。看起来稳，实际会把业务人员淹没在一堆低价值待办里。参数少了一个、接口临时抖动、消息发送失败，全都让人处理，Agent的效率价值很快就被抵消。
FDE要先把异常分类。
第一类，信息缺失。
用户指令不完整，缺少对象、范围、时间、条件、数量、原因。比如“帮我把重点客户整理一下”，系统不知道是生成名单，还是更新客户等级，也不知道范围是哪一批客户。这类异常适合让Agent追问用户，补齐条件后再继续。
第二类，权限不足。
用户没有权限查看某些数据，或者没有权限修改某个字段。比如普通销售让Agent批量修改客户等级，平台应该直接拦截，并说明需要主管确认。权限异常不能靠Agent自己解释过去，必须由平台权限体系控制。
第三类，业务规则冲突。
字段格式、状态流转、审批条件、库存校验、金额阈值不满足。比如采购申请金额超过预算，合同状态还没归档，工单没有验收记录。这类异常要把规则讲清楚，让用户修改数据、补充材料，或进入审批。
第四类，系统调用失败。
API超时、外部系统不可用、网络异常、第三方接口返回错误。这类异常要区分可重试和不可重试。临时超时可以重试，外部系统明确拒绝就要转人工或生成待处理任务。
第五类，结果不确定。
Agent可以生成建议，但系统无法判断是否应该执行。比如客户分级调整、异常订单处理、合同风险说明，这些动作涉及业务判断。FDE可以设计成人工确认，先给出建议和依据，再由负责人决定是否执行。
异常分类完成以后，处理方式才会清楚。
能追问的，就让Agent追问。
能自动重试的，就按规则重试。
需要确认的，就进入确认或审批。
必须人工判断的，就生成待办并交给对应角色。
有数据影响的，就进入补偿或回滚。
这才是企业能接受的Agent异常处理方式。它不会把所有问题都推给人，也不会让系统在高风险动作上乱试。
三、FDE到现场要先画出失败路径
FDE做企业Agent项目，不能只拿一个“用户发起，Agent执行，系统返回成功”的流程图去沟通。
这个图太顺了，顺到有点不真实。
真正有用的现场流程图，一定要把失败路径画出来。
比如Agent发起采购申请，正常路径是：用户提出需求，Agent读取缺料清单，生成采购申请草稿，用户确认，系统提交审批，审批通过后同步采购系统。
失败路径至少要补几条。
缺料清单不完整怎么办？
供应商信息缺失怎么办？
申请金额超过预算怎么办？
审批人不在线怎么办？
采购系统接口超时怎么办？
草稿生成后用户发现数量不对怎么办？
审批被驳回后，Agent还要不要继续跟进？
这些问题如果不提前画出来，上线后就会变成现场临时讨论。临时讨论最容易出错，因为大家都在处理已经发生的问题，很难冷静设计规则。
FDE应该在需求调研阶段就把每个关键动作拆成三条线。
第一条，成功线。正常情况下怎么执行。
第二条，拦截线。哪些条件不满足时，平台必须阻止执行。
第三条，补救线。已经执行到一半时，后续失败该怎么处理。
这三条线画清楚，业务、IT和管理层就能一起判断：哪些异常由系统自动处理，哪些异常需要用户补充，哪些异常要升级给主管，哪些异常必须留给管理员。
这一步看起来比写提示词慢，但它能减少后面大量返工。
因为企业Agent上线后，最消耗团队精力的经常是那些没人提前定义的例外情况。
FDE的价值就在这里。把业务现场那些“不一定每次都会发生，但一发生就很麻烦”的情况，提前变成系统可以识别、可以分派、可以追踪的处理链路。
四、Agent执行失败后，企业至少要有四个动作
异常发生后，系统不能只记录一条失败日志。对业务来说，还要继续处理。
我建议FDE把失败后的动作设计成四步。
第一步，暂停。
高风险动作一旦异常，就要先暂停后续执行。比如批量改数据、提交审批、同步外部系统、关闭工单、调整库存。暂停的目的很直接：先防止问题继续扩大。
第二步，保留现场。
系统要保留用户原始指令、Agent解析结果、已确认摘要、调用参数、当前业务对象状态、成功和失败记录。以后复盘时，要能看见异常发生时的完整上下文。
第三步，派单接管。
异常不能停在后台日志里。系统要根据异常类型派给对应角色。权限问题给管理员，业务规则冲突给业务负责人，接口故障给IT运维，审批问题给审批节点负责人。
第四步，恢复或补偿。
有些动作可以继续执行，有些动作需要撤回，有些动作要生成补充任务，有些动作要标记为待人工确认。比如批量更新客户状态时，成功的记录保留，失败的记录进入异常清单，处理人确认后再补执行。
这四步做完，Agent执行失败就不会变成一个黑盒。
业务人员知道系统停在哪里。
管理人员知道谁在处理。
IT知道接口或规则哪里有问题。
FDE知道下一轮该优化哪个环节。
企业用Agent，真正要建立的是这种可运营能力。能成功固然重要，失败后还能继续把事情办完，才是上线系统该有的样子。
五、织信可以把异常处理做进业务对象和流程里
织信作为低代码和AI智能开发平台，适合承接Agent异常处理里的业务结构。
原因很简单。异常处理单独挂一个日志页面远远不够，它要和业务对象、表单字段、流程节点、权限角色、API结果、消息通知放在一起。
比如客户对象里，Agent批量更新失败，就要能回到客户记录、客户状态字段、失败原因、负责销售和主管确认。
比如采购申请里，Agent生成草稿失败，就要保留已填写字段，让用户补充供应商、预算科目或申请原因，避免整张单据重新来一遍。
比如工单流程里，Agent派工失败，就要能生成异常任务，通知设备主管或运维负责人处理。
这些都离不开平台层的业务结构。
FDE可以在织信里把关键业务对象先沉淀出来：客户、合同、订单、工单、设备、采购申请、费用申请、项目任务。每个对象有字段、权限、表单、视图、流程和操作动作。
Agent接入以后，不管是读取、生成、提交、修改、同步，动作都落在这些业务对象上。异常也跟着落在对象和流程里。
这样做有几个好处。
第一，异常能定位到具体对象。系统看到的应该是某个客户、某张单据、某个工单上的动作失败，而不只是一句孤立的“Agent执行失败”。
第二，异常能分派到具体角色。系统知道这个对象属于哪个部门、哪个负责人、哪个流程节点，就能把问题交给真正该处理的人。
第三，异常能挂回业务流程。审批驳回、数据补充、接口重试、人工确认，都可以变成流程里的节点，少靠群消息临时沟通。
第四，异常能进入后续分析。哪些动作失败最多，哪些字段最容易缺失，哪些接口最不稳定，哪些流程总被驳回。FDE可以基于这些数据继续优化Agent配置和业务规则。
这也是低代码平台在企业AI项目里的价值之一。
它不只是帮企业快速搭页面、搭表单，更重要的是把Agent要执行的业务动作，放到一个可配置、可管控、可追溯、可迭代的结构里。
六、异常处理要写进验收标准
很多企业验收AI Agent时，只看成功场景。
能不能问答，能不能查数据，能不能生成单据，能不能调用接口，能不能跑通一个完整流程。
这些要测，但不够。
FDE交付时，最好把异常处理也写进验收清单。否则项目上线后，业务人员遇到第一个复杂情况，就会觉得系统不可靠。
验收时可以重点看六项。
第一，信息缺失时，Agent能不能追问，并保留用户已经输入的内容。
第二，权限不足时，平台能不能拦截，并说明需要谁确认或授权。
第三，业务规则冲突时，系统能不能讲清楚是哪条规则没通过。
第四，接口失败时，系统能不能区分超时、拒绝、返回错误和外部系统不可用。
第五，部分成功时，系统能不能列出成功清单、失败清单和后续处理人。
第六，人工接管后，处理结果能不能回写到原业务对象和日志里。
这六项不一定都要在第一期做到很复杂，但至少要有明确设计。
FDE可以根据风险分阶段推进。第一期先处理高频异常和高风险动作，第二期再补更细的自动补偿、统计分析和规则优化。
企业AI落地不能只靠一次上线。它更像一个持续运营的系统。每一次异常，都是下一轮优化的材料。
七、结语：敢让Agent办事，先给它留好退路
企业上线Agent，真正难的地方经常不在“让它做一步动作”。
难的是让它在真实业务环境里持续运行。真实业务里有权限、有流程、有例外、有系统抖动、有人工判断，也有很多不能靠模型自己决定的边界。
FDE要做的，就是把这些边界提前设计成工程机制和业务流程。
用户指令不完整，系统能追问。
权限不够，平台能拦截。
规则不通过，流程能退回。
接口失败，任务能接管。
数据已改，日志能追溯。
需要补救，流程能继续。
这样Agent才不会变成一个只会在顺风场景里表现很好的工具。
织信这类低代码和AI智能开发平台，可以把业务对象、流程、权限、接口、日志和异常任务放在同一个结构里，让Agent的执行能力有落点，也让企业有能力管理它的失败。
企业AI真正进入核心业务之前，最好先问一句：如果它执行到一半失败了，我们准备怎么接？
这个问题回答清楚，Agent上线才算有底气。
