Agent 评测与调用错误处理

一、Agent 评测怎么做？#

1. 核心目标#

Agent 评测不只是判断最终回答是否正确，还要检查工具调用过程是否正确，以及最终业务结果是否符合预期。

主要评测四个维度：

评测维度	检查内容	示例
任务结果	是否完成用户需求	是否查询到正确订单
工具选择	是否选择正确工具	查询退款进度却调用了发起退款工具
参数正确性	参数是否符合要求	订单号错误、必需参数缺失
执行过程	工具是否真正执行、结果是否正确处理	工具执行失败却声称成功

注意：最终回答正确不代表执行过程正确。Agent 可能没有真正查询数据库，只是猜测结果，碰巧回答正确。

2. 建立固定评测集#

首先整理一批具有代表性的业务用例，每条用例包含：

用户输入：例如查询订单 10086 的状态。
预期行为：应该调用订单查询工具。
参数约束：订单号必须为 10086。
预期结果：返回数据库中的真实订单状态。
禁止行为：不能调用退款工具，不能编造查询结果。

测试集需要覆盖：

正常业务场景。
工具选择错误。
参数缺失或格式错误。
工具超时、限流或返回异常。
权限不足、数据不存在。
重复调用、无限重试、虚假宣布成功。

每次修改提示词、模型、工具描述或执行逻辑之后，都使用同一批用例进行回归测试，比较修改前后的结果。

3. 记录完整执行链路#

不能只保存 Agent 的最终回答，还需要记录完整调用过程。

建议记录：

request_id：请求唯一标识。
模型版本、提示词版本。
用户输入和上下文。
选择的工具及实际传入参数。
工具调用次数、耗时、异常信息。
工具实际返回结果。
最终回答和最终业务状态。

通过这些记录定位错误发生在哪一层：

现象	可能的问题
选错工具	工具描述不清晰、意图理解或路由错误
工具正确但参数错误	参数生成、上下文理解或校验缺失
参数正确但接口报错	下游服务异常、网络或权限问题
工具失败但回答成功	工具结果处理、最终回答约束有问题
重复调用同一工具	缺少重试上限、状态判断或终止条件

4. 自动评分与人工评估#

代码自动检查：

适用于有明确标准的指标，例如：

是否调用了指定工具。
参数是否与预期一致。
是否发生重复调用。
工具执行失败时是否错误地报告成功。
最终业务状态是否符合预期。

模型评分与人工抽检：

适用于回答自然度、需求覆盖度、解释合理性等难以完全通过规则判断的指标。

原则：工具是否执行、参数是否准确、业务状态是否改变，优先使用程序和真实业务数据校验，不要只依赖另一个模型评分。

5. 形成评测闭环#

构造固定测试集 → 执行 Agent 并记录 Trace → 自动评分 → 分析失败原因 → 修复问题 → 重新运行回归测试。

例如，发现“查询退款进度”经常被识别成“发起退款”，就把这个失败案例加入测试集。修改工具描述或路由逻辑后重新测试，并检查其他退款场景是否受到影响。

二、Agent 调用错误怎么解决？#

核心原则：先定位错误层级，再针对性处理，不要所有问题都靠修改提示词。

1. 选错工具#

场景： 用户要求查询退款进度，Agent 却调用了发起退款工具。

处理方式：

梳理工具边界，明确每个工具的功能、使用条件和参数要求。
优化工具描述，减少功能重叠和语义歧义。
对高风险操作增加调用前校验，包括用户意图、参数、权限和业务状态。
对边界明确的场景，必要时使用规则路由或限制候选工具。
通过相似意图测试集验证修改效果。

注意：查询、退款、扣费、删除等操作不能只依赖模型自行判断，涉及副作用的工具必须有后端安全校验。

2. 参数错误#

场景： 用户要求查询订单 10086，Agent 却传入 10068，或者遗漏订单号。

处理方式：

使用结构化工具定义或 JSON Schema 约束必需字段、数据类型、枚举值和格式。
在执行器调用业务接口之前进行参数校验。
缺少用户提供的必要信息时，要求补充；参数格式错误时，可以让模型在有限次数内修正。
对用户身份、订单归属、金额等关键数据，由后端根据认证信息和数据库记录进行验证。
记录参数错误类型和重试次数，持续补充回归用例。

注意：格式校验通过不代表业务参数合法。例如订单号格式正确，但订单不属于当前用户，仍然必须拒绝访问。

3. 工具执行失败#

场景： Agent 正确调用订单查询工具，但下游服务超时或返回 HTTP 500。

错误类型	处理方式
参数校验失败	返回明确错误，修正参数
HTTP 429	根据限流策略等待后重试
超时、临时 5xx	有界重试、指数退避，必要时熔断
401、403	检查身份与权限，不盲目重试
业务数据不存在	返回明确业务结果，不当作系统故障
多次重试仍失败	停止执行，返回可识别的失败状态

重试必须有最大次数、总超时时间和退避策略，避免 Agent 无限循环。

特别注意： 扣费、退款等有副作用的操作，超时不代表执行失败。下游可能已经执行成功，只是响应丢失。

此时应使用幂等键、业务流水号或结果查询机制确认状态，不能直接重复执行。

4. Agent 声称调用成功，但实际没有执行#

场景： Agent 回复“退款已成功”，但后端没有实际调用退款服务。

这不能单靠提示词解决，需要从执行架构上约束。

正确流程：

Agent 生成结构化工具调用请求。
后端执行器校验工具名称、参数、权限和业务前置条件。
执行器实际调用对应业务接口。
后端记录工具调用结果和业务状态。
将真实结果返回给 Agent。
最终回答依据已验证的执行结果生成。

例如：

1
用户请求退款
2
→ Agent 请求调用 create_refund
3
→ 后端执行器调用退款服务
4
→ 退款服务返回 PROCESSING
5
→ 后端记录退款处理中
6
→ Agent 回复“退款申请已提交，正在处理中”。

只有确认实际业务状态成功后，才能回复“退款成功”。

不能把模型生成的 Tool Call 当作工具执行成功的证据，也不能只凭 HTTP 200 就认定退款已经完成。

核心原则：工具调用意图、工具执行结果、最终业务状态是三个不同的概念。

5. Agent 反复调用、陷入循环#

处理方式：

设置单次任务最大工具调用次数。
设置整体执行超时和最大重试次数。
记录相同工具和相同参数的重复调用。
将工具错误返回给 Agent 时，提供明确的错误类型和可采取的下一步操作。
同一错误多次出现时停止自动重试，转为失败、人工处理或向用户询问。

对于需要多步执行的任务，还需要定义终止条件，避免 Agent 在没有取得有效进展的情况下不断调用工具。

三、如何把评测和错误处理结合起来？#

以订单查询 Agent 为例。

用户提出查询订单的需求。
Agent 选择订单查询工具并生成参数。
后端执行器校验参数和权限。
执行器调用订单服务。
系统记录调用过程和真实返回结果。
根据预期工具、参数、返回结果和最终业务状态进行评分。
如果发现问题，定位对应环节并修复。
将失败案例保留在固定测试集中，后续持续回归。

这样就形成了“发现问题—定位原因—修复问题—验证修复”的闭环。

四、面试口播版#

我会从评测体系和错误处理两个方面来做。

首先是 Agent 评测。我会建立固定测试集，覆盖正常业务、工具选择错误、参数错误、工具超时以及权限不足等场景。每条用例定义预期工具、参数约束和业务结果。执行过程中记录完整调用链路，再通过程序校验工具选择、参数和实际业务状态；对于回答质量等难以通过规则判断的指标，再结合模型评分和人工抽检。

其次是解决 Agent 调用错误。我会先定位错误层级。如果是选错工具，就优化工具描述，必要时增加路由规则；如果是参数错误，就通过结构化参数约束和后端校验解决；如果是工具执行失败，就根据异常类型采取有界重试、退避或熔断等措施。

对于 Agent 声称调用成功但实际上没有执行的问题，我会让后端执行器统一处理工具调用，并记录真实执行状态。最终回复必须以实际执行结果为依据；涉及扣费、退款等关键业务时，还需要确认真实业务状态，并通过幂等机制避免重复操作。

最后，把线上发现的失败案例加入回归测试集，每次修改提示词、工具定义或执行逻辑后重新评测，确认问题得到改善，同时没有引入新的问题。

五、记忆提纲#

评测： 固定测试集、完整 Trace、自动评分、回归验证。
排错： 工具选择、参数生成、工具执行、结果判断。
修复： 工具定义、参数校验、异常处理、执行状态约束。
防循环： 调用次数上限、超时、重试上限、终止条件。
关键原则： 不只看最终回答，要验证真实执行过程和业务结果。