问题：代理对工具报错视而不见

假设你发布了一个AI代理，它负责调用工具、读取结果、继续调用、最终给出答案。大多数时候一切正常，直到某个用户报告异常。你打开运行轨迹，发现charge_card工具返回了402错误，而代理没有停下，反而继续执行，最后告诉客户订单已发货。

这不是传统意义上的“幻觉”——不是编造事实，而是运行过程中的结构性缺陷：代理忽略了工具错误。这类问题在复杂的代理工作流中并不罕见，但往往难以通过常规测试发现。

关键洞察：结构性缺陷无需LLM检测

这类缺陷有一个特点：你不需要另一个LLM来发现它。因为忽略工具错误是可以通过检查运行轨迹来判定的——这是确定性的逻辑问题，而非语义理解问题。

换句话说，只要代理在工具返回错误后没有采取适当的处理（如重试、上报或终止），而是继续执行并给出误导性答复，这就是一个明确的缺陷。这种缺陷可以通过规则或脚本在CI中自动捕获，而不必依赖昂贵的模型推理或人工审查。

如何在CI中捕获这类问题

要在持续集成（CI）流程中捕获这类缺陷，核心思路是检查代理的运行轨迹。具体做法包括：

  1. 记录完整轨迹：确保代理的每次工具调用、返回结果和后续决策都被记录。这是后续分析的基础。
  2. 定义错误处理规则：明确哪些工具错误是“致命”的，代理必须停止或采取特定行动；哪些是可容忍的，可以继续。例如，支付失败（402）通常应终止流程。
  3. 编写检查脚本：在CI中运行代理的测试用例，然后扫描轨迹，检查是否存在“工具返回错误但代理继续执行”的情况。如果发现，则构建失败。

这种方法将检测从“事后人工排查”提前到“代码合并前”，能显著减少生产环境中的此类问题。

为什么值得关注

随着AI代理在业务中承担更多关键任务（如支付、订单处理），工具调用的可靠性直接影响用户体验和业务安全。一个忽略错误的代理可能造成订单错误、资金损失或客户信任危机。而通过CI自动捕获这类结构性缺陷，开发者可以在部署前发现并修复问题，避免线上事故。

此外，这种方法不依赖额外的LLM调用，成本低、速度快，且结果确定性强，适合集成到现有开发流程中。

结语

AI代理的可靠性不仅取决于模型能力，还取决于其执行逻辑的健壮性。通过检查运行轨迹，在CI中自动捕获“忽略工具错误”这类结构性缺陷，是一种务实且高效的实践。下次当你发现代理对错误视而不见时，不妨考虑将这种检查纳入你的CI流程。

参考来源