Agent执行失败后，企业怎么接管和补救？

企业第一次看Agent演示时，往往最关心它能不能把事情办成。

能不能查客户数据？

能不能生成采购申请？

能不能发起审批？

能不能调用ERP、CRM、OA里的接口，把原来要人工点半天的动作自动做掉？

这些问题当然重要。Agent如果只能聊天，不能进入业务系统，企业很难把它当成生产力工具。但真正到上线阶段，FDE前沿部署工程师还要追问另一个问题：如果Agent只办成了一半，后面谁来接？

这个问题听起来没有演示那么漂亮，却很现实。

销售让Agent批量更新客户状态，100条里面有92条成功，8条失败。失败的8条，是权限不足、字段缺失、客户状态冲突，还是接口返回异常？成功的92条要不要保留？失败的8条谁来处理？业务人员能不能一眼看懂？

采购让Agent根据缺料清单生成采购申请，草稿已经生成，提交审批时发现预算科目不对。这个时候要整张单据作废，还是保留已填字段，让用户补科目后继续提交？

设备告警以后，Agent创建了维修工单，但通知维修负责人失败。系统日志里只是一条消息接口异常，现场看到的结果却可能是没人去修设备。

很多企业做AI Agent试点，前期卡在模型效果，后期卡在异常处理。模型能把话听懂，只能说明它跨过了第一关。系统敢让它办事，还要看它失败以后能不能停得住、讲得清、交得出去、补得回来。

这篇文章要讨论的重点就在这里：企业上线Agent以后，怎样设计异常接管和补救机制。它表面上像技术排障，往深一层看，其实是企业业务系统的一套运行规则。

一、Agent失败不可怕，怕的是失败后状态不清

企业软件里，每天都会发生异常。

ERP里会有库存不足，OA里会有审批驳回，CRM里会有客户资料缺字段，MES里会有设备状态不同步，财务系统里会有科目不匹配。成熟系统能长期运行，靠的就是这些异常有记录、有规则、有处理人。

Agent进入企业执行层以后，也会遇到同样的问题，只是问题变得更复杂了一点。

传统系统里，一个按钮对应一个动作，出错位置相对明确。Agent执行任务时，前面可能经历了用户指令理解、上下文读取、权限判断、参数生成、接口调用、结果回写、消息通知等多个步骤。任何一步出问题，业务人员都可能只看到一句“执行失败”。

这就麻烦了。

因为企业真正关心的是几件具体事情，错误码只能作为技术排查的线索：

它到底做到哪一步？

哪些数据已经被读取？

哪些记录已经被修改？

哪些动作没有完成？

接下来该找谁？

如果这些问题说不清，业务人员就会慢慢不敢用Agent。哪怕它前面演示得很好，到了真实业务里，大家也会把关键动作重新拿回手工处理。

所以FDE设计Agent方案时，不能只把成功路径跑通。成功路径只是上线门槛，失败路径才决定系统能不能长期用。

这里可以借用一句很普通的话：路修得再宽，也要留应急车道。Agent也是一样。正常执行是一条主路，异常处理就是应急车道。没有这条车道，车一坏，整条路都堵住。

二、先分清异常类型，再决定处理方式

Agent执行失败以后，最忌讳把所有问题都归成一类。

有些异常应该让Agent追问用户，有些异常应该由平台直接拦截，有些异常可以自动重试，有些异常必须交给人工确认。分类不清，后面的处理就会乱。

FDE到现场做设计时，可以先把常见异常分成五类。

1、信息不完整

这是最常见的一类。

用户说“帮我整理一下重点客户”，系统不知道重点客户的范围是什么，是按成交金额、回款情况、跟进频次，还是按客户等级。用户说“把这批订单处理一下”，系统也要知道是哪一批订单，处理动作是什么，是否需要审批。

这类异常适合让Agent继续追问。追问时要保留用户已经输入的内容，不要让用户从头再说一遍。

2、权限不够

Agent能不能看数据、改字段、发流程，最终不能由模型自己决定。

比如普通销售让Agent批量修改客户等级，系统应该先检查这个销售有没有修改权限。没有权限时，平台要明确拦截，并告诉用户需要主管确认，或者需要管理员授权。

权限异常不能靠一句提示词解决。企业真正要控制的是角色、部门、字段、操作和审批边界。

3、业务规则不通过

企业流程里有很多规则。

采购申请超过预算不能提交，合同没归档不能发起回款，工单没验收不能关闭，费用报销缺发票不能进入财务审核。Agent生成的内容再完整，只要规则不通过，系统就不能继续往下走。

这类异常要把规则讲清楚。用户需要知道是哪一条规则没通过，应该补哪个字段，改哪个状态，或者走哪个审批。

4、系统调用失败

Agent办事通常要接外部系统。ERP、CRM、OA、MES、财务系统、消息系统、知识库、第三方接口，都可能参与进来。

接口超时、网络异常、外部系统维护、返回结果格式变化，都会让Agent执行中断。这里要区分临时失败和明确拒绝。临时超时可以按规则重试，外部系统明确返回拒绝，就要生成待处理任务，交给IT或业务负责人。

5、结果需要人工判断

有些事情即使系统能做，也不适合自动做到底。

客户要不要降级，供应商要不要暂停合作，异常订单要不要放行，合同风险提示要不要影响审批，这些都带有业务判断。Agent可以提供建议和依据，但最后一步最好让负责人确认。

异常分清以后，处理方式就不会乱。

信息缺失，让Agent追问。

权限不足，平台拦截。

规则冲突，提示用户补充或退回流程。

接口失败，按风险决定重试、转人工或生成任务。

结果不确定，进入人工确认。

这套分类看起来不复杂，但它能把Agent从“出错就报错”的工具，变成一个可以接入企业流程的执行系统。

三、FDE要把失败路径画到流程图里

很多Agent方案在早期汇报时，流程图都很顺。

用户提出需求，Agent理解意图，系统读取数据，Agent生成结果，用户确认，系统提交审批，任务完成。

这个图没有错，但它只覆盖了最理想的情况。真到企业现场，墨菲定律往往比PPT更准。凡是可能出问题的环节，总会在某个时间点出问题。

所以FDE不能只画成功线，还要画失败线。

比如采购申请场景，正常流程是用户提出采购需求，Agent读取缺料清单，生成申请草稿，用户确认，系统提交审批，审批通过后同步采购系统。

这条线只回答了“顺利时怎么走”。FDE还要继续问：

缺料清单字段不完整怎么办？

供应商档案查不到怎么办？

预算科目不匹配怎么办？

申请金额超过审批阈值怎么办？

审批人临时离职或不在线怎么办？

采购系统接口超时怎么办？

审批被驳回以后，Agent还要不要继续跟进？

这些问题如果上线后再讨论，往往已经晚了。业务人员在催，IT在查日志，管理层在问责任，FDE再临时补规则，很容易顾此失彼。

比较稳的做法，是把关键动作拆成三条线。

第一条是成功线。正常情况下，用户、Agent、平台、外部系统分别做什么。

第二条是拦截线。哪些条件不满足时，系统必须停下来，比如权限不足、金额超限、字段缺失、状态不允许流转。

第三条是补救线。动作执行到一半后，后续失败了怎么处理，是保留草稿、撤回动作、重试接口、转人工，还是生成补充任务。

这三条线画出来以后，业务部门、IT部门和管理层才能一起确认边界。哪些事情可以自动处理，哪些事情需要用户确认，哪些事情必须升级，哪些事情要留审计记录。

FDE的价值就在这个地方。模型接上系统只是第一步，更重要的是把业务现场里那些容易失控的例外情况，提前变成可以识别、可以分派、可以追踪的流程规则。

四、失败后至少要有四个动作

Agent执行失败以后，系统不能只记一条日志。

日志是给技术排查用的，业务还要继续往下走。FDE可以把失败后的处理设计成四个动作。

1、暂停执行

高风险动作出异常时，先暂停后续执行。批量改数据、提交审批、同步外部系统、关闭工单、调整库存，都属于这类动作。

暂停这个动作，首先是止损。业务系统里最怕“半懂不懂地继续往前跑”。一旦继续执行带来更大影响，后面补救成本会更高。

2、保留现场

系统要保留当时的上下文。

包括用户原始指令、Agent解析出来的任务意图、用户确认过的内容、调用参数、权限判断结果、业务对象状态、成功记录、失败记录和外部系统返回信息。

这些信息以后要用于复盘。靠人回忆系统当时发生了什么，通常不可靠。尤其是跨部门、跨系统、跨流程的问题，现场信息一旦丢失，后面很难说清楚。

3、派单接管

异常不能躺在后台日志里。

权限问题要给管理员，业务规则问题要给业务负责人，接口问题要给IT运维，审批问题要给当前节点负责人。系统要根据异常类型，把任务交到对应角色手里。

很多企业其实有人能处理问题，麻烦常常出在系统没有把问题交给正确的人。

4、恢复或补偿

有些动作可以继续执行，有些动作需要撤回，有些动作要生成补充任务，有些动作要等待人工确认。

比如批量更新客户状态时，成功记录可以保留，失败记录进入异常清单。处理人确认原因以后，再选择补充执行、放弃执行，或者发起主管确认。

这四个动作做好以后，Agent失败就不会变成黑盒。

业务人员知道它停在哪里。

管理人员知道谁在处理。

IT知道哪个接口或规则出了问题。

FDE知道后续要优化哪一段链路。

企业敢让Agent办事，靠的不只是成功率，还要靠失败以后这套接管能力。

五、异常处理要落在业务对象上，不能只留在技术日志里

很多系统处理异常时，会先做一个日志页面。

日志页面当然有用。它能记录时间、接口、参数、错误码和返回结果，方便技术人员排查。但对业务人员来说，这还不够。

业务人员更关心的是：这次异常影响了哪个客户、哪张合同、哪条订单、哪张采购申请、哪个设备工单。

Agent批量更新客户失败，异常应该能回到客户记录里，看到客户状态、负责销售、失败原因和后续确认人。

Agent生成采购申请失败，系统应该保留已经填写的物料、数量、供应商、预算科目，让用户补充缺失字段以后继续提交。

Agent派工失败，系统应该生成异常任务，通知设备主管或运维负责人处理，不能只在后台留一条错误信息。

这也是织信这类低代码和AI智能开发平台适合参与Agent落地的原因。

FDE可以先在织信里沉淀企业的关键业务对象，比如客户、合同、订单、工单、设备、采购申请、费用申请、项目任务。每个对象有字段、表单、视图、权限、流程和操作动作。

Agent接入以后，读取、生成、提交、修改、同步这些动作，都可以落在业务对象上。异常也跟着落在对象和流程里。

这样做有几个好处。

第一，异常能定位到具体对象。系统看到的是某个客户、某张单据、某个工单上的动作失败，技术错误只作为其中一部分信息。

第二，异常能分派到具体角色。系统知道这个对象属于哪个部门、哪个负责人、哪个流程节点，就能把问题交给真正该处理的人。

第三，异常能挂回业务流程。审批驳回、数据补充、接口重试、人工确认，都可以变成流程里的节点，少靠群消息临时沟通。

第四，异常能进入后续分析。哪些动作失败最多，哪些字段最容易缺失，哪些接口最不稳定，哪些流程总被驳回，这些数据都可以成为下一轮优化的依据。

低代码平台在企业AI项目里的价值，不只在于搭页面、搭表单。更重要的是，它能把Agent要执行的业务动作，放到一个可配置、可管控、可追溯、可持续调整的结构里。

六、异常处理要写进验收标准

企业验收Agent时，不能只看它能不能跑通一条成功流程。

能问答、能查数据、能生成单据、能调用接口，这些都要测。但真正上线以后，最容易暴露问题的地方，常常是异常场景。

用户少说了一个条件，系统能不能追问？

权限不够，平台能不能拦住？

规则不通过，系统能不能说清楚？

接口失败，任务能不能转给IT？

部分成功，部分失败，系统能不能列出清单？

人工接管以后，处理结果能不能回写到原来的业务对象和日志里？

这些问题如果没有纳入验收，项目上线后很容易出现一种情况：演示时很顺，真实使用时到处卡。

FDE可以把异常处理列成验收清单。至少包括六项。

第一，信息缺失时，Agent能不能追问，并保留用户已经输入的内容。

第二，权限不足时，平台能不能拦截，并说明需要谁确认或授权。

第三，业务规则冲突时，系统能不能指出是哪条规则没有通过。

第四，接口失败时，系统能不能区分超时、拒绝、返回错误和外部系统不可用。

第五，部分成功时，系统能不能列出成功清单、失败清单和后续处理人。

第六，人工接管后，处理结果能不能回写到原业务对象和操作日志里。

这六项不一定第一期全部做得很复杂，但至少要有明确设计。第一期可以先处理高频异常和高风险动作，第二期再补自动补偿、统计分析和规则优化。

企业AI落地不会在一次上线后结束。每一次异常，都是下一轮优化的材料。谁能把这些材料沉淀下来，谁的Agent就更容易从试点走向长期使用。

七、结语：先问怎么失败，再谈怎么上线

企业上Agent，最容易兴奋的是“它终于能办事了”。

但只要Agent开始办事，它就会碰到权限、流程、接口、数据和人工判断。这里面任何一个环节没有设计好，都可能让系统停在半路。

FDE做Agent落地，不能只追求一条漂亮的成功路径。更重要的是提前设计失败以后怎么接。

用户指令不完整，系统能追问。

权限不够，平台能拦截。

规则不通过，流程能退回。

接口失败，任务能接管。

数据已经变更，日志能追溯。

需要补救，流程能继续。

这些机制都准备好以后，企业才敢把Agent放进更关键的业务环节。

织信这类低代码和AI智能开发平台，可以把业务对象、流程、权限、接口、日志和异常任务放在同一个业务结构里，让Agent不只是能执行动作，也能在失败后被管理、被接管、被补救。

所以，企业AI真正进入核心业务之前，最好先问一句：如果它执行到一半失败了，我们准备怎么接？

这个问题回答清楚，Agent上线才算有底气。