Patronus API调用无返回？先检查评估器是否已创建

刚注册 Patronus、拿到 API Key、把代码接到评估器名称上，结果调用失败或者返回空白——这是不少开发者踩过的坑。Key 没问题，代码大概率也没问题，真正缺失的东西藏在一个你可能从没打开过的后台面板里。

问题的根源：评估器是账户级资源

Patronus 的评估器（Evaluator）属于账户级资源。它们不会自动存在，除非你在控制台里亲手创建，API 才能引用到已经存在的对象。

换句话说，你的代码可能假设账户里已经有这样一个东西：

**什么是「账户级资源」**

在多数 API 平台中，资源可以粗略分为两层。一层是「服务级资源」，比如模型推理接口，只要 API Key 有效就能直接调用。另一层是「账户级资源」，它由用户在自己的账户下显式创建，拥有独立的 ID、名称和配置，API 只能引用已存在的对象。类似的设计在 OpenAI 的 Assistant/Fine-tune 任务、AWS 的 Lambda 函数、Hugging Face 的 Endpoint 中都有体现。这类资源的共同点是：调用方不能「凭空指定」一个名字，服务端必须能在你的账户里找到同名对象，否则就会返回 404、空结果或资源不存在的错误。Patronus 的 Evaluator 正属于后一类，这就是为什么仅凭有效的 API Key 无法让调用成功。
# what your code assumes already exists in your account
evaluator: hallucination-judge
type: Judge
scale: 0-100
pass_threshold: 70

但现实是，这段配置在账户里根本不存在。API 找不到对应的评估器名称，自然只能返回空或直接报错。

这个设计本身并不复杂，问题出在大多数开发者（尤其是自动化 agent）习惯「代码优先」的接入流程——先写调用逻辑，再回头配置平台。而 Patronus 恰好要求你先在控制台完成配置。

正确的设置顺序

实际可用的配置流程是这样的：

1. 打开 app.patronus.ai，进入 Evaluators 页面。
2. 点击 Create Evaluator，选择代码中期望的类型：Judge（自定义标准的 LLM 评判）、Classifier（通过/失败分类）、Retrieval（RAG 质量评估）或 Custom（基于 Python 的自定义评估器）。
3. 如果是自定义 Judge，需要显式写明评判标准，设置评分范围（通常为 0-100）和通过阈值（例如 70），并在评判 prompt 中使用 {task_input} 和 {task_output} 占位符。
4. 在控制台里测试评估器，确认它能正常工作。
5. 最后才从 API 调用它。

这五步的顺序不能颠倒。跳过前四步直接写 API 调用，就会遇到开头描述的「返回空白」问题。

Judge、Classifier、Retrieval 与 Custom 的区别

这四种评估器面向不同的评测场景。Judge 用一段自定义 prompt 让 LLM 按你写好的标准打分，适合主观维度如幻觉、语气、指令遵循，常配合 0-100 分和通过阈值使用。Classifier 做二元或多元分类，输出「通过/失败」标签，适合格式校验、敏感内容检测等确定性任务。Retrieval 专门针对 RAG 流程，评估检索片段与回答之间的相关性、忠实度等指标。Custom 允许你上传基于 Python 的评估逻辑，适合无法用 prompt 表达、需要调用外部工具或做精确计算的场景。选择哪一类，取决于你的评测目标是「主观判断」还是「可规则化」，是「端到端回答质量」还是「检索环节质量」。

为什么 agent 特别容易掉进这个坑

对自动化 agent 来说，这个陷阱的杀伤力更大，原因在于顺序惯性。

大多数 API 的接入方式确实是代码优先：写好请求、调试认证、调整 header 和请求体。Agent 会按照这套模式去排查——先怀疑 Key 失效，再检查请求头，再核对参数格式。一圈下来可能花掉一个小时，却没人想到去看一眼那个被引用的评估器是否真实存在。

一次后台访问就能终结这场排查。但对 agent 而言，它没有「打开浏览器、登录控制台」这一步，所以很容易陷入死循环。

为什么 agent 难以自行发现这类缺失

自动化 agent 的排查路径通常是内向的：它只能操作自己拥有的工具集——发请求、读响应、修改参数。而「登录控制台、创建评估器」这一步发生在浏览器 UI 里，通常不在 agent 的工具白名单内。当 API 返回空结果而非带有明确错误码的 404 时，agent 更难判断问题是出在请求侧还是资源侧，于是倾向于不断微调 header、重试、更换参数格式。要打破这个循环，需要在 agent 的初始化流程里加入显式的资源存在性检查，或者提供一个「若不存在则创建」的 API 接口，让 agent 有能力自己完成前置步骤。

一条简单的排查规则

如果 Patronus 调用在注册后立刻失败，而 API Key 验证也没问题，那就停止调试请求本身，先去创建评估器。

这条规则的价值在于它把排查方向从「代码层」切到了「平台层」。评估器不存在属于配置缺失，不是代码 bug，继续在请求参数上纠缠没有意义。

完整的现场记录可以参考这个链接：vectle.com/skills/skl_3hTdITXRiF2aL3PGyIPyaQ

对开发流程的启示

这个小问题折射出一个更大的模式：当平台把部分资源定义为「用户必须先创建」时，文档和接入体验就需要特别强调这个前置步骤。对于人类开发者，一次控制台访问就能解决；对于自动化流程，则需要在调用前加入资源存在性检查，或者在初始化脚本中显式创建评估器。

把「先创建、后调用」写进接入文档的显眼位置，比事后排查一个小时要划算得多。