客服Agent的评测为什么不能停在“回答正确率”？任务完成、工具调用和异常恢复怎么测？

摘要：即便客服 Agent 答题正确率高达 95%，也不等于产品好用。回答正确仅代表 AI “会说”，任务闭环完成才代表它 “会办事”。文章提出四层评测链路：回答质量、任务完成率、工具调用效果、异常恢复能力。建议企业选型 POC 放弃单一 FAQ 题库测试，改用真实业务任务集，重点核验意图识别‑信息采集‑系统调用‑工单创建‑人机转交全链路，同时重视上线后的 Badcase 治理与回归测试，以此筛选适配生产落地的业务型客服 Agent。

如果一个客服 Agent 回答100个问题，答对了95个，企业是不是就可以认为它已经“很好用了”？

不一定。

因为真实客服场景里，客户问一句“帮我查一下订单”“我要申请退货”“我的设备坏了，帮我报修”，通常并不是为了得到一句解释，而是希望完成一个具体动作。这就带来一个很容易被忽略的问题：回答正确，只能证明 Agent“会说”；任务完成，才能证明它“会办事”。

当客服 Agent开始连接知识库、工单系统、CRM、订单系统等业务工具后，企业真正需要评测的，也就不再只是回答准确率，而是至少要继续看三件事：任务有没有完成、工具有没有正确调用、出错之后能不能恢复。

一、为什么“回答正确率高”，客服 Agent 仍然可能不好用？

先看一个最简单的场景。

客户说：

“我的空调坏了，帮我报修。”

Agent回答：

“空调出现故障后可以联系售后申请维修，请准备好相关信息。”

如果这是传统FAQ机器人，这个回答可能已经不错：信息没有明显错误，也回答了用户的问题。但如果这是一个客服 Agent，这次交互其实很可能是失败的。因为用户说“帮我报修”，真正期待的是：

识别报修需求 → 获取必要信息 → 创建工单 → 返回处理结果 → 必要时转人工。

如果 Agent 只是告诉用户“可以申请维修”，却没有完成后续动作，那么“回答正确率”再高，也没有真正解决用户的问题。这也是企业评测客服 Agent 时，第一个需要改变的认知：

不要再把“回答问题”当成任务终点。

对于售后报修、安装预约等场景，真实业务难点本身就是信息采集、字段完整、跨部门流转和进度追踪。知识库中对应的场景已经明确指向售后服务 Agent、工单系统以及业务系统联动，而不是单纯的知识问答。

所以，回答正确率应该保留，但它更像是第一道门槛。真正进入生产环境后，评测需要继续往下走。

二、客服 Agent 到底应该评测什么？

如果把客服 Agent 的能力拆开，可以得到一条非常清晰的链路：

回答正确 → 任务完成 → 工具调用正确 → 异常情况下仍能正确处理

这四层分别回答四个问题：

它们不是四个孤立指标，而是一层比一层更接近真实生产环境。

回答正确率解决“会不会答”，任务完成率解决“能不能办”，工具调用解决“办事过程中有没有做对”，异常恢复则决定“出了问题以后还能不能继续办”。

因此，企业做POC时，如果只拿100道FAQ测试模型回答，很可能测出来的是一个“知识问答能力很强”的机器人，而不是一个真正能够承担业务流程的客服 Agent。

三、第一关：回答正确率，到底应该怎么测？

回答正确率仍然重要，只是不能再把它当成最终答案。对于客服 Agent，首先要验证三个基础问题：

1. 知识有没有答对？

比如退款规则、服务时间、产品政策等，回答是否与企业知识保持一致。

1. 用户的问题有没有理解对？

同一句话可能存在不同意图。例如：

“这个订单怎么取消？”

可能是在询问取消规则，也可能是在要求 Agent直接执行取消。如果 Agent只回答“订单可以取消”，却没有识别用户是在要求执行操作，那么后续任务就会中断。

1. 多轮对话中有没有答偏？

用户在第二轮补充的信息，可能会改变第一轮的判断。因此，测试集不能只有单轮问答，还要加入上下文变化和多轮任务。但到这里，仍然只是第一层。即使100%的答案都答对了，也不能证明Agent具备业务执行能力。

四、第二关：任务完成率，才是客服 Agent 从“会答”走向“会办”的分水岭

任务完成率最重要的变化，是把测试单位从“一句话”换成“一个完整任务”。

例如：

“帮我查询一下订单什么时候送到。”

这句话至少可以拆成：

识别查询意图 → 获取订单信息 → 调用订单系统 → 获取结果 → 正确理解结果 → 告知用户。

所以评测时不能只看：

Agent最后有没有说出正确的预计送达时间。

还要知道：

它是怎么得到这个结果的？

如果Agent没有调用订单系统，只是根据上下文猜了一个日期，即使碰巧答对，也不应该判定为真正完成任务。

任务完成率怎么定义？

第一步，是给每个业务任务明确“成功条件”。

例如售后报修：

• 是否识别出报修需求；
• 是否收集完整必要信息；
• 是否完成工单创建；
• 是否把结果反馈给用户；
• 是否在无法自动处理时进入正确的人工流程。

第二步，是把任务拆成关键节点。因为一个任务可能有5个步骤，Agent完成4个，并不意味着任务100%成功。因此，实际POC中更适合同时记录：最终任务完成率 + 关键步骤完成情况。这样才能定位问题究竟发生在哪里。

例如：

• 意图识别失败；
• 信息采集失败；
• 工具调用失败；
• 业务系统返回异常；
• 最终结果没有正确反馈。

否则，一个“任务失败”的数字只能告诉企业结果不好，却不能告诉企业为什么不好。

五、第三关：工具调用，不能只测“有没有调用成功”

当Agent开始真正办业务，工具调用就变成了核心能力。例如：用户要求退货。

Agent可能需要：

查询订单 → 判断订单状态 → 判断是否满足退货条件 → 创建售后单 → 返回处理结果。

这时候，“工具调用成功率”仍然太粗。真正应该测至少四件事：

1. 工具选对了吗？

用户需要查询订单，Agent却只查询了知识库。或者用户需要创建工单，Agent只给了一段操作说明。这种情况下，回答可能看起来没有问题，但业务动作根本没有发生。

1. 参数填对了吗？

工具选对了，参数也可能错。例如订单号、客户ID、产品型号、时间范围等关键参数错误，最终仍然会导致任务失败。所以测试时应该记录：

工具名称 + 输入参数 + 业务上下文

而不是只记录“调用了API”。

1. 调用顺序对了吗？

一些业务操作有明确的前置条件。例如：

身份确认 → 查询客户信息 → 判断权限 → 执行业务动作。

如果Agent跳过身份确认直接执行后续操作，即使每个工具本身都可以正常运行，也不能算一次合格的业务执行。

1. 工具返回结果有没有被正确使用？

假设订单系统明确返回：

“订单已取消。”

但Agent却告诉用户：

“您的订单正在配送。”

这里不是API调用失败，而是Agent在读取和使用工具结果时出错。

因此：

真正的工具调用评测，不是“工具有没有被调用”，而是“工具选得对不对、参数对不对、顺序对不对、结果有没有被正确使用”。

这是最容易被忽略的一层。对于企业级客服 Agent，这也是为什么流程编排和业务系统联动会成为重要能力。合力亿捷的 Synerow 支撑 Agent 构建、流程编排、工具调用、业务系统联动和持续运营，其价值并不只是让Agent“生成一句话”，而是让Agent进入实际业务流程。

六、第四关：异常恢复，才是真正拉开Agent差距的地方

正常流程谁都能演示。真正难的是：流程不正常的时候，Agent怎么办？

如果POC永远只有：

用户提问 → Agent回答 → 系统返回成功

那么测试出来的只能是“理想环境下的效果”。生产环境不会这么配合。所以异常恢复应该成为客服 Agent 的必测项目。

1. API超时：会不会无限重试？

例如订单查询接口连续两次超时。

需要观察：

• Agent是否按照预设策略重试；
• 是否出现无意义的重复调用；
• 是否能够告诉用户当前状态；
• 是否能够切换其他处理路径；
• 是否需要转人工。

异常测试的重点，不是API有没有超时，而是Agent知道超时之后应该做什么。

1. 关键字段缺失：会不会自己“猜”？

用户说：“我要退货。”但系统要求订单号才能继续，合格的Agent应该发现：任务可以继续，但信息还不完整。

于是向用户询问订单号，而不是直接调用退货接口，更不能自行编造一个参数。这个测试实际上是在验证Agent的流程状态判断能力。

1. 用户改变需求：能不能及时切换任务？

例如：

用户：帮我查一下订单。 Agent：好的，请提供订单号。 用户：不用查了，我想改收货地址。

此时Agent应该重新识别当前需求。如果它还继续追问订单号，那么从用户角度看，系统虽然“回答正确”，但已经失去了对任务状态的控制。

1. 超出业务边界：知道什么时候该停下来

并不是所有事情都应该由Agent自动完成。例如涉及高风险、复杂投诉、特殊审批或明确需要人工处理的业务，Agent需要知道自己的边界。因此：一个成熟的客服 Agent，不是追求100%自动化，而是知道什么应该自动处理、什么应该继续追问、什么应该切换路径、什么应该交给人工。AI质检等能力不能替代人工终审；类似的人机协同边界，同样需要在Agent的业务流程中明确。

七、真正有效的Agent测试集，不应该只有FAQ

做到这里，企业就会发现一个问题：如果按照上面的标准评测，原来的FAQ题库根本不够用了。

因为FAQ只能测试：

“Agent会不会回答？”

而Agent真正进入生产后，需要测试的是：

“Agent能不能完成一件事情？”

因此，测试集应该从“问题集”升级成“任务集”。可以至少分成七类：

① 正常任务

验证最常见的业务流程能否稳定完成。

② 多轮任务

用户分多次提供信息，测试Agent能否保持上下文和任务状态。

③ 工具任务

专门测试工具选择、参数、调用顺序和结果使用。

④ 跨系统任务

测试Agent是否能够完成从客服入口到业务系统的完整链路。

⑤ 异常任务

人为制造接口超时、返回空值、字段缺失等情况。

⑥ 边界任务

测试什么时候继续自动处理，什么时候转人工。

⑦ 变化任务

修改知识、价格、流程或业务规则后，重新验证相关任务。

最后一类尤其容易被忽略。客服 Agent 上线以后，业务不会停止变化。价格会变、活动会变、知识会更新、接口会调整，原来的流程也可能发生变化。因此，Agent评测不应该是“上线前考一次试”，而应该变成持续的回归验证。

八、POC别再只让Agent“回答100道题”，应该让它完成一组真实任务

如果企业正在做客服 Agent 选型，这里可以直接把评测方法转化成POC验收标准。

建议把测试分成六组：

其中最值得改变的是POC的测试方式。不要只让供应商演示正常路径。

应该主动给Agent制造问题：

API超时怎么办？ 用户缺一个关键字段怎么办？ 用户突然改变需求怎么办？ 工具返回的数据与上下文冲突怎么办？ 这个任务超出Agent权限怎么办？ 知识发生变化后，原来的流程还能不能通过回归测试？

如果一个Agent只能在“准备好的演示环境”里表现良好，那么它的回答正确率再高，也不足以证明它适合生产。

九、从一次POC到长期运营：Agent评测应该形成闭环

客服 Agent 上线并不意味着评测结束。真正的生产环境会不断产生新的Badcase，而这些Badcase又会反过来暴露知识、流程、工具和模型的问题。因此，一个完整的闭环应该是：

测试 → 上线 → 监控 → 发现Badcase → 分析原因 → 调整知识/流程/模型 → 回归测试 → 再上线。

合力亿捷的Agent交付流程中，也将业务调研、Agent设计、编排调试、上线试运行和运营优化分成连续阶段，并明确包含会话监控、异常处理以及Badcase发现、分析和修复。这意味着企业评估客服 Agent 时，除了问“现在效果怎么样”，还应该问：

出了问题之后，供应商能不能找到问题？ 找到问题之后，能不能定位是知识、流程、工具还是模型的问题？ 修改之后，能不能重新验证，而不是改完就直接上线？

这其实比一次演示里的回答准确率，更接近Agent的长期生产能力。

十、真正应该评测的，不是“Agent会不会说”，而是“Agent能不能把事情办完”

客服 Agent 的评测并不是要抛弃回答正确率。恰恰相反，回答正确是起点，但不是终点。当Agent开始承担真实业务以后，企业应该把评测链路从：“问题 → 答案” 升级成：“用户需求 → 任务理解 → 流程执行 → 工具调用 → 业务结果 → 异常恢复 → 人机协同”，这也是判断一个客服 Agent 是否真正具备生产价值的关键。

如果只测回答正确率，你得到的答案是：

“它会不会说。”

如果把任务完成、工具调用和异常恢复都纳入测试，你真正得到的答案才是：

“它能不能办事。”

对于正在做客服 Agent POC的企业来说，这也是一个更直接的判断标准：不要只让Agent回答100道题，应该让它完成一组真实业务任务，并主动制造失败条件。

能在正常路径下完成任务只是第一步；能够正确调用工具、处理异常、知道何时继续、何时补充信息、何时转人工，并且在上线后持续通过Badcase和回归测试优化，才更接近一个可以真正进入生产环境的客服 Agent。