企业第一次看 Agent 演示时，最关心的往往不是它有多会聊天，而是它到底能不能把事情真正办成。

能不能查客户数据？

能不能生成采购申请？

能不能发起审批？

能不能调用 ERP、CRM、OA 里的接口，把原本要人工反复点击的动作自动完成？

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

这个问题没有演示那么好看，却非常关键。

销售使用 Agent 批量更新客户状态时，100 条记录里可能有 92 条成功、8 条失败。随之而来的问题是：这 8 条失败分别是权限不足、字段缺失、客户状态冲突，还是接口返回异常？已经完成更新的 92 条是否需要保留，剩余失败记录由谁继续处理，业务人员又能否直接看懂当前结果？

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

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

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

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

图1：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 从“出错就报错”的工具，变成一个可以接入企业流程的执行系统。

图2：企业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 办事，靠的不只是成功率，还要靠失败以后这套接管能力。

图3：Agent异常接管工作台示意

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

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

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

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

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

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

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

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

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

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

这样做有几个好处。

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

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

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

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

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

图4：织信承载Agent异常处理结构

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

权限不够，平台能拦截。

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

接口失败，任务能接管。

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

需要补救，流程能继续。

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

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

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

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