用途：在运维 Exa 相关调用时，先对失败做分类，再决定是修复、重试还是升级处理，避免把不同性质的错误混为一谈。
主要能力：按 HTTP 状态码、错误标签（tag）、端点以及 Contents 响应中的逐项抓取状态进行归类。资料指出，已记录的错误可区分无效请求、认证失败、额度或预算耗尽、访问策略、单 URL 抓取失败、限流、服务过载以及 Answer 生成失败；多数错误包含 requestId、error 和 tag，429 可能使用更简单的响应体。即使外层请求成功，也需检查 Contents 内的细粒度状态。
使用方式：捕获端点、状态、标签、请求 ID、尝试次数和不含内容的输入形态；把请求缺陷与认证、计费、策略、抓取、容量类问题分开；400 类契约错误应修复而非原样重试；429 遵循 Retry-After，已记录的瞬时故障使用有界抖动重试；持续性的供应商故障携带请求 ID 和脱敏时间证据升级。认证方面，常规 REST 调用从服务端密钥管理器注入 EXA_API_KEY，仅以 Authorization: Bearer 发往配置的第一方 Exa API 主机，不得打印、提交、放入 URL 或暴露给不可信客户端。
适用场景：Exa 调用排障、错误分级、重试策略制定与供应商问题上报。
限制：涉及敏感意图的实时查询、生产凭据、花费或限流变更、强制实时抓取、生成摘要、外部投递、部署、成员或密钥变更、计划创建以及破坏性取消、停止、删除或吊销，均需有责任负责人批准；只读仓库检查与离线合成验证不授权实时供应商操作。402 属额度或预算边界而非瞬时服务器错误；503 SERVICE_OVERLOADED 不能仅靠降低调用方 QPS 解决；支持证据中不得包含 API 密钥、完整查询或返回页面文本。输出应包含操作范围、环境、团队与产品面、授权类别、契约与策略决策、确定性验证结果、无内容标识符、状态与成本计数、风险、清理或回滚状态及通过或失败回执。资料未提供具体端点清单、价格与限额数值。