FDE怎么评估企业AI Agent的业务效果？别只看调用次数

企业AI Agent上线以后，项目组迟早会遇到一个问题：这个Agent到底有没有用？

这个问题看起来简单，实际并不好回答。

有些团队会先拿调用次数说话。今天被问了多少次，本周有多少活跃用户，累计生成了多少内容，看板上数字很好看，汇报时也比较方便。

但企业软件不能只看热闹。一个Agent被调用了很多次，不一定说明它真的进入了业务；一个Agent调用次数不高，也不一定说明它没有价值。有些场景本来就是低频高风险，比如合同审核、预算调整、客户信用变更、设备重大异常接管，它们不需要天天触发，但每一次触发都很关键。

所以，FDE前沿部署工程师在Agent上线以后，需要帮助企业回答的，不能只是一句“有没有人用”。它还要继续追问几个更具体的问题。

• 这个Agent处理了哪些业务动作？

• 它有没有减少人工重复操作？

• 有没有缩短流程周期？

• 有没有降低错误、漏填、重复录入和人工返工？

• 有没有让管理者更早看到风险？

• 出了问题以后，能不能查到原因，并把问题沉淀成下一轮优化？

这些问题都不能只靠感觉回答。它需要业务对象、操作日志、流程记录、异常记录、人工接管记录和看板指标放在一起看。

这也是FDE在企业AI项目中很重要的一项工作：把“AI好不好用”这个模糊判断，拆成企业能够长期观察、复盘和改进的业务指标。

一、先说清楚：评估对象不只是模型，还包括业务动作

很多企业一讨论AI效果，第一反应是问模型能力。

回答准不准，理解能力强不强，生成内容像不像人，推理链路是否完整。这些当然重要，但对于企业应用来说，它们只是其中一部分。

FDE要评估的对象，通常不只是单独一个模型，还包括Agent在某个业务场景里完成的一组动作。

比如客户跟进Agent，它可能包含几个动作：

• 读取客户基础信息。

• 读取最近跟进记录。

• 识别客户风险。

• 生成跟进建议。

• 创建下一次跟进任务。

• 必要时提醒销售经理。

再比如采购申请Agent，它可能包含：

• 读取库存和安全库存。

• 识别缺料物料。

• 生成采购申请草稿。

• 补齐供应商、数量、交期等字段。

• 提交审批。

• 把审批结果回写到采购记录。

这些动作每一个都可以评估，评估口径也不一样。

• 读取数据，要看数据来源是否正确、权限是否合规、字段是否完整。

• 生成建议，要看建议是否被采纳、是否被修改、修改集中在哪些地方。

• 触发流程，要看审批是否顺利、是否频繁驳回、驳回原因是什么。

• 回写系统，要看字段是否写准、是否有人工修正、日志是否能查到。

如果FDE不先把这些动作拆开，评估就会变得很粗。最后只能说“整体还行”“感觉一般”“业务部门反馈不太好”。这种评价没办法指导下一步优化。

所以，评估Agent效果的第一步，是建立业务动作清单。

每个动作都要说明：它服务哪个业务对象，读取哪些字段，输出什么结果，影响哪个流程节点，是否需要人工确认，最终记录在哪里。

只有评估对象清楚，后面的指标才不会乱。

二、第一层，看执行质量：它能不能把事办完整

Agent进入企业业务，首先要过的是执行质量这一关。

执行质量不等于回答得漂亮。它更接近传统企业软件里的“单据能不能走完、流程能不能闭环、数据能不能落账”。

FDE可以先看几个基础指标。

第一，任务完成率。

用户发起一次Agent任务以后，最终有没有完成。比如生成了跟进任务，提交了采购申请，完成了工单派发，生成了风险提醒。只停在聊天回答里，通常不能算真正完成。

第二，异常率。

任务执行过程中，哪些环节经常出问题。是字段缺失，权限不足，接口超时，审批规则冲突，还是用户输入不完整。异常率本身不是坏事，它可以告诉项目组问题集中在哪里。

第三，人工接管率。

有多少任务最后需要人工接管。人工接管率高，说明Agent还不能独立完成这类动作。但这里也要细分原因。有些是高风险动作本来就应该人工确认，有些是规则设计不清，有些是数据质量不够。

第四，字段修正率。

Agent生成或填写的字段，被人工修改了多少。比如采购数量、客户等级、风险原因、工单分类、处理建议等字段，修改越集中，越说明这里需要重新检查字段口径、规则条件或提示词。

第五，回写成功率。

企业Agent不能只会说，很多场景还要写回系统。写回成功率可以帮助FDE判断，Agent和业务系统之间的接口、权限、校验规则是否稳定。

这些指标看起来比较基础，但很实用。

因为它们回答的是一个朴素问题：Agent到底有没有把业务动作办完。

企业里不缺能演示的AI，缺的是能够在日常业务里稳定执行的AI。FDE要先把这一层看住，后面才谈得上效率提升和管理价值。

三、第二层，看业务结果：有没有让流程真的变好

执行质量过关以后，还要继续看业务结果。

因为一个Agent可以稳定运行，但未必带来明显业务改进。它可能只是把原来人工填写的内容换成AI生成，流程时间没有缩短，返工没有减少，管理动作也没有变化。这样的项目，看起来用了AI，实际价值有限。

FDE评估业务结果时，可以从几个常见方向入手。

（一）处理时间有没有缩短

比如原来销售写一次客户跟进总结需要十分钟，现在Agent根据通话纪要、历史记录和客户状态生成草稿，销售只需要修改两分钟。

再比如原来采购申请要人工查库存、查供应商、填字段，现在Agent先生成申请草稿，采购员确认后提交审批。

这里要看的是完整业务动作的时间，而不是AI生成一段文字花了几秒。

如果只看模型响应时间，意义不大。业务人员真正关心的是从“我要处理这件事”到“这件事进入系统并进入下一步”用了多久。

（二）返工和驳回有没有减少

很多企业流程慢，原因不一定在审批人。更常见的情况是前面资料不完整、字段填错、口径不统一。

如果Agent能在提交前检查必填字段、预算范围、客户状态、合同信息、供应商资质，就有机会减少后续驳回。

FDE可以观察：上线前后，同类流程的驳回率有没有变化，驳回原因有没有变化，哪些原因被Agent提前拦截了。

（三）人工重复录入有没有减少

这是企业最容易感知的价值。

很多业务人员每天都在做重复动作：把会议纪要整理成跟进记录，把Excel里的数据录入系统，把工单信息复制到派单表，把审批意见再写入台账。

Agent如果只是生成一段建议，业务人员还要自己复制粘贴，那价值会打折。更好的方式是把结果落到对应对象、字段和流程里。

所以，FDE要看Agent是否真正减少了重复录入次数，是否让信息从一次输入进入多个业务环节，而不是让人换一种方式继续搬运数据。

（四）异常暴露有没有更早

有些Agent的价值不在提速，而在提前发现问题。

客户长期未跟进，合同快到期，设备多次异常，库存低于安全线，预算即将超支，供应商交付延迟。这些事情如果靠人定期看报表，往往会晚一步。

Agent如果能基于规则和数据主动识别，再把风险推给对应负责人，就能把事前提醒做起来。

这一类场景要评估的，不只是处理量，还要看风险发现时间、提醒触达率、负责人处理率、问题关闭周期。

企业AI Agent的业务效果，最终要落在流程周期、返工率、录入成本、风险暴露和管理可见性上。只看调用次数，很容易把评估带偏。

四、第三层，看管理价值：能不能帮助负责人看清现场

企业上线Agent，不只是为了让一线少填几张表。

管理者同样需要它。

因为Agent运行以后，会留下大量有价值的过程数据：用户在问什么，哪些任务经常失败，哪些字段总是缺，哪些流程经常被驳回，哪些业务对象最容易出现风险，哪些部门人工接管最多。

这些数据如果只留在日志里，就是技术记录；如果经过整理进入看板，就能变成管理信息。

FDE在这里要做的，是把运行数据转成业务负责人能看懂的指标。

比如销售负责人不一定关心模型调用了多少次，他更关心这些问题：

• 哪些客户长期没有跟进。

• 哪些商机的风险原因集中在价格、交付还是竞品。

• Agent生成的跟进建议，销售采纳率是多少。

• 哪些销售人员经常需要系统提醒。

• 哪些客户状态更新后没有进入下一步动作。

采购负责人关心的可能是：

• 哪些物料经常触发缺料提醒。

• 采购申请驳回原因主要集中在哪些字段。

• 哪些供应商相关异常最多。

• Agent生成申请草稿后，采购员主要修改哪些内容。

IT或数字化负责人关心的又是另一组问题：

• 哪些接口失败频率高。

• 哪些权限拦截是合理的，哪些说明权限模型需要调整。

• 哪些Agent动作需要增加审批节点。

• 哪些异常已经可以沉淀成规则。

这些问题背后，其实就是企业管理的老问题：业务是否透明，流程是否顺畅，责任是否清楚，数据是否可用。

只是到了AI Agent阶段，FDE要把这些老问题重新接到Agent运行数据上。

在织信里，这类评估可以通过业务对象、流程记录、操作日志、异常处理单和数据看板组合起来。前台是业务人员正常使用Agent和应用，后台则把运行过程沉淀为可查询、可统计、可复盘的数据。

五、FDE要把评估结果变成迭代清单

评估不是为了写一份汇报材料。

如果评估完以后，问题仍然停在表格里，那Agent还是不会变好。

FDE更应该做的是把评估结果转成迭代清单。

比如发现客户跟进Agent的字段修正率高，就要进一步看是哪些字段被改。

• 如果经常改的是客户阶段，可能是阶段定义不清。

• 如果经常改的是风险原因，可能是风险分类太粗。

• 如果经常改的是下一步建议，可能是Agent没有读取足够的历史跟进记录。

• 如果经常改的是负责人，可能是组织权限或客户归属关系没有同步好。

不同问题，对应的改法完全不同。

• 有些要改提示词。

• 有些要补字段。

• 有些要调整表单校验。

• 有些要增加审批节点。

• 有些要接入新的系统接口。

• 有些要把人工接管经验沉淀成固定规则。

所以，FDE不能只告诉企业“这个Agent效果一般”。更有价值的说法是：它在哪个动作上效果一般，原因是什么，下一轮要改哪个对象、哪个字段、哪个流程、哪个接口或哪个权限。

这就是企业AI项目和普通内容生成工具最大的不同。

企业Agent的优化，不只是换一个提示词。很多时候，它要回到业务系统结构里改。

• 字段不准，就改字段口径。

• 流程太长，就改流程节点。

• 权限太松，就收紧动作范围。

• 异常太多，就补校验和接管流程。

• 日志看不清，就补记录字段。

• 看板看不懂，就重新设计管理口径。

织信这样的AI智能开发平台，适合承接这类持续迭代。因为业务对象、表单、流程、权限、接口、日志和看板都在同一套平台结构中，FDE可以把评估发现的问题直接转成配置和应用改进，而不用每次都重新开一个开发项目。

六、评估Agent效果，最终要回到企业自己的业务目标

不同企业做Agent，目标不一样。

有些企业想减少人工录入，有些企业想缩短审批周期，有些企业想提高客户跟进质量，有些企业想把设备异常处理得更及时，还有些企业只是先把AI接入几个低风险流程，看看组织能不能用起来。

目标不同，评估口径也不同。

所以FDE在项目早期就要和企业一起把目标说清楚。

• 如果目标是降本，就要看减少了多少重复录入、多少人工核对、多少返工。

• 如果目标是提效，就要看流程周期、响应时间、任务完成率。

• 如果目标是控风险，就要看异常发现时间、审批拦截、权限命中、日志追溯。

• 如果目标是提升管理透明度，就要看负责人是否能通过看板看到问题，是否能根据数据做调整。

这些指标不需要一开始就做得很复杂，但必须和业务目标对应。

否则Agent跑了一段时间以后，大家会陷入一种很尴尬的状态：技术团队觉得系统已经上线，业务部门觉得价值不明显，管理层看不出投入产出，最后项目慢慢没了声音。

企业AI落地最怕的就是这种“说不上坏，也说不上好”的状态。

FDE要避免这种情况，就要从第一天开始建立评估口径。先拆业务动作，再看执行质量，再看业务结果，再看管理价值，最后把问题转成下一轮迭代。

这样Agent才不会停留在一次性的演示项目里，而会逐步变成企业业务中能够变稳、变准、变有用的系统能力。

结尾还是回到一句朴素的话。

企业做AI Agent，不能只问“它用了多少次”。更应该问：它帮企业少做了哪些重复工作，提前发现了哪些风险，缩短了哪些流程，沉淀了哪些规则，让哪些管理问题变得更清楚。

这些问题能回答清楚，Agent的价值才算真正落到业务里。