做客服 Agent 不会定 KPI？这 6 个指标直接抄

大家好我是大煊。最近整理企业 Agent 的运营资料时我注意到一个经常出现的指标Handoff Rate(人工接管率)。这个指标让我开始思考对于一个 Agent 项目到底哪些数字真正有参考价值模型回答得流不流畅只能证明它能对话。调用次数很多也可能只是大家在尝鲜。就连人工接管率也不能简单理解成越低越好有些任务是 Agent 能力不足有些是用户主动要求还有一些本来就应该进入人工审核。我继续查了几套官方指标体系。Microsoft 把升级率和解决率放在主要结果指标里AWS 直接提供 AI 人工接管指标Google Cloud 和 ServiceNow 也会统计计划转接、升级和人工介入。这说明人工接管不是一个可有可无的客服数字。它描述的是Agent 遇到不确定、越权或无法完成的任务时能不能正确停下并把事情交给人。因此人工接管率放在 P0。对于非客服型 Agent“人工接管”不一定是转在线客服也可以是进入人工复核、审批或工单队列。这篇参考了哪些官方资料Microsoft Copilot StudioMicrosoft Deflection OverviewAmazon Connect AI AgentGoogle Cloud Virtual AgentServiceNow AI AgentIBM watsonx AssistantSalesforce AgentforceZendesk AI AgentsLangSmith EvaluationNIST AI RMFOpenTelemetry GenAI Observability从 P0 到 P2项目越往后指标解决的问题越不同P0 结果与安全完成 / 正确 / 接管P1 执行可靠性Agent / ToolP2 成本价值单次成功任务成本阶段核心指标需要回答的问题P0目标完成率、业务结果正确率、人工接管率事情有没有办成、结果是否正确、该不该交给人P1Agent 技术执行成功率、工具调用成功率整条流程是否稳定、外部业务能力是否可用P2单次成功任务成本每完成一个有效任务究竟花了多少钱虽然成本放在 P2模型调用量、Token 和人工投入等原始数据仍要从 P0 开始记录。等任务口径和业务基线稳定后再用它们判断项目是否值得扩大。P0先建立 Agent 的最小结果闭环1. Goal Success Rate(目标完成率)它回答什么Agent 最终有没有完成用户要办的事情。计算公式目标完成率 被用户、业务系统或确定性规则确认完成的有效任务数 ÷ 真正尝试完成该目标的有效任务数。分母边界只打开窗口、测试流量、系统重放以及本来就不允许 Agent 处理的任务不进入分母。Agent 回复了一段话也不能自动算作完成。最小埋点task_id(任务ID)、task_type(任务类型)、outcome(任务结果)、outcome_source(结果确认来源)、business_state(业务状态)、completed_at(完成时间)。容易误读用户没有继续回复不等于问题已经解决。结果来源至少要区分用户确认、业务系统确认、规则确认和超时推断。2. Correctness Rate(业务结果正确率)完成任务不等于正确完成。尤其是企业内部查询、合同、资产和财务等场景错误答案可能比没有答案更危险。它回答什么Agent 给出的业务事实、判断和处理结果是否正确。计算公式业务结果正确率 业务事实和处理结果均正确的抽检任务数 ÷ 形成可评估业务结果的抽检任务数。分母边界抽检集不能只有简单成功案例还要覆盖无数据、缺参数、数据冲突、权限不足、超时和拒绝执行判断 Agent 是否做出了正确的降级或接管。如果一次运行因非预期技术异常没有形成可评估结果则标记为not_evaluable(不可评估)改由 Agent 技术执行成功率统计。**最小埋点error_severity(错误等级)、model_version(模型版本)、knowledge_version(知识版本)。容易误读一个较高的平均正确率可能掩盖少量严重错误。错误等级可以使用Critical(严重)、High(高)和Normal(一般)不要让大量简单问答冲淡资金、权限或合规问题。3. Handoff Rate(人工接管率)人工接管率也放在 P0因为一个企业 Agent 不但要知道自己能做什么还要知道什么时候应该停下。它回答什么有多少任务需要人工继续处理以及 Agent 是否在正确的时机交给人。计算公式人工接管率 进入人工复核、审批、客服或工单队列的有效任务数 ÷ Agent 受理的有效任务数。分母边界用户明确要求人工、高风险规则触发、Agent 能力不足和系统异常需要分开记录。预期中的人工审核不应被当作 Agent 失败也不应该为了降低比例而被隐藏。最小埋点handoff(是否人工接管)、context_summary(交接摘要)、abandoned(用户是否放弃)。容易误读人工接管率下降既可能代表 Agent 能力提升也可能代表用户直接离开、人工入口难找或风险规则没有生效。P1验证整条执行链路是否可靠4. Agent Invocation Success Rate(Agent技术执行成功率)这里沿用 AWS 的英文指标名。中文统一写成“Agent 技术执行成功率”因为这里的“成功”只指没有技术故障不评价业务结果对不对。最直观的区分是一次流程完整跑完却把合同金额答错技术执行算成功业务结果算错误一次流程因编排异常中断没有产出可评估结果技术执行算失败业务结果记为不可评估。它回答什么一次 Agent 执行能否在没有技术异常的情况下到达明确结束状态。计算公式Agent 技术执行成功率 无技术异常且正常结束的有效执行次数 ÷ 发起的有效执行次数。分母边界“没有查到业务数据”可以是一次正常执行接口超时、编排异常、状态丢失、服务不可用和非预期取消才属于技术失败。最小埋点started_at(开始时间)、completed_at(完成时间)、error_type(错误类型)、retry_count(重试次数)。容易误读HTTP 200 只说明接口有响应不代表 Agent 完整结束。反过来即使流程正常结束业务结果也可能是错的前者由 Agent 技术执行成功率判断后者由业务结果正确率判断。5. Tool Invocation Success Rate(工具调用成功率)企业 Agent 一旦开始访问订单、知识、工单或内部接口Tool 就变成了它和真实业务之间的桥。它回答什么Agent 发起的工具调用有多少次成功返回了可供后续流程使用的业务结果。计算公式工具调用成功率 成功返回有效业务结果并被后续节点消费的调用次数 ÷ 工具调用总次数。分母边界成功不能只看 HTTP 状态。接口返回 200但业务状态表示权限不足、参数错误或数据不可用仍然不能算成功。最小埋点tool_name(工具名称)、tool_version(工具版本)、arguments_valid(参数是否有效)、business_code(业务状态码)、tool_latency_ms(工具耗时毫秒)、retry_count(重试次数)、result_consumed(结果是否被后续节点消费)。容易误读总成功率无法直接告诉你是选错工具、传错参数还是下游接口失败。这些情况作为失败原因记录不再拆成多个并列指标。这两个成功率看起来接近实际关注的是不同故障层级指标观察范围典型失败Agent 技术执行成功率从请求进入到工作流形成明确结束状态编排异常、状态丢失、超时、非预期取消工具调用成功率某一次外部业务调用能否返回可消费结果参数错误、权限不足、下游失败、结果未消费P2口径稳定以后再核算经营价值6. Cost per Successful Task(单次成功任务成本)模型调用便宜不等于项目整体便宜。真正有业务意义的是每完成一个确认有效的任务企业总共花了多少钱。它回答什么Agent 的运行、人工补救和长期维护成本能否换来足够多的成功任务。计算公式单次成功任务成本 模型、检索、Tool、基础设施、人工复核、异常补救和维护分摊成本之和 ÷ 被确认完成的有效任务数。分母边界不能把所有自动回复都算成成功任务也不能只计算 Token 费用。上线前后的人工时长必须使用同类任务、相同起止点和相同质量要求。最小埋点input_tokens(输入Token数)、output_tokens(输出Token数)、model_cost(模型成本)、tool_cost(工具成本)。容易误读每次模型请求更便宜不代表每个成功任务更便宜。低成功率、反复重试、人工复核和错误返工都会把真实成本重新抬高。从小项目到大项目可以照这个顺序落地P0第一版就要有定义什么叫任务完成。建立业务结果正确率抽检严重错误单独看。记录什么时候进入人工流程以及为什么进入。提前记录 Token、耗时和成本原始数据。P1接入真实业务后补齐可靠性区分业务未完成和系统执行失败。记录 Agent 的结束状态、失败节点和重试次数。记录 Tool 从选择到结果消费的完整链路。让每一种失败都能回到具体节点和原因。P2准备扩大投入时核算建立上线前人工基线。将复核、返工和维护重新算回总成本。按任务类型比较单次成功任务成本。只对能够确认完成的任务计算收益。总的来说Agent 完成了多少任务结果是否正确哪些任务应该交给人失败发生在哪一层以及每次成功最终花了多少钱都是很通用的参考指标。