企业智能体项目失败,往往不是败在模型不会说话,而是败在事情做了一半停住:需求抓到了数据没取到,取到了数据系统改不动,系统改了没人确认结果。任务闭环能力衡量的就是这条链路能否走完——需求捕获、数据获取、跨系统执行、结果验证、人工兜底,任何一环断裂,业务价值都归零。在从聊天机器人试点转向业务任务型智能体的阶段,它比参数规模和生成效果更值得作为验收标尺。
闭环不等于全自动
把"无人干预"当成闭环标志,是常见的误判。人工兜底是闭环的组成部分,而不是失败的证据:异常人工干预入口、人机协同审批是否存在,审批时效与准确率如何,都应纳入评估。真正危险的是没有兜底路径的自动化——一旦异常,任务卡在系统里,既无回滚也无转交。
可度量是另一个前提。业务目标需要拆解为数据采集、决策推理、系统执行、结果校验、人工兜底五个子任务,每一步都有可度量的输出,并定义闭环成功率、平均处理时长、异常回滚率作为比较基准。缺少这组基准,平台之间的对比就只剩印象分。
七个维度,验证方式各不相同
评估可以落在业务价值、数据基础与治理、集成深度、权限治理、人工兜底、可观测性、交付风险七个维度上,且不能用一次演示替代验证。业务价值看能否对应工单处理时效、订单完成率一类指标,靠试点流程的对比数据说话;数据基础与治理看私有化部署、全链路日志、数据脱敏与权限细分,依据安全审计报告与合规认证;集成深度常是项目的真实分水岭,标准 API 之外的遗留系统能否被实际调用,要看真实调用老旧系统接口的演示,而不是接口清单;权限治理用权限矩阵检查与模拟违规操作测试;可观测性看端到端追踪、异常告警与执行日志可视化;交付风险则涉及部署复杂度、运维成本与供应商支持,可通过项目计划评审和运维 SLA 对比判断。
用小范围试点换确定性
稳妥的路径是分阶段推进:先选重复性高、规则明确、已有清晰指标的业务环节做闭环定位,例如工单分配、费用报销、客户投诉处理;再按上述维度对候选平台打分并搭建原型,在受控环境下跑通一次完整闭环,记录任务成功率与人工干预次数。单流程闭环稳定之后,再横向扩展到 ERP、CRM、OA 等核心系统,补齐全链路审计、细粒度权限与统一监控,并核算不同计费模式下的总拥有成本。
选型的落点并不复杂:让候选方案在真实流程里跑一遍,看它能否带着指标走完全程,以及走不完时由谁接手。
