n8n 多智能体流程怎么评估？用固定测试集核对最终分类

评估 n8n 多智能体流程，先选一个可以稳定判定的最终结果。例如，让“识别工单的智能体”和“整理答复的智能体”合作后，仍输出正确的工单分类。用 Evaluation Trigger 逐行读取固定测试集，再把实际分类和预期分类对照，能发现修改分工或提示词后是否退化。

本文评估已有流程，不从头搭建多个智能体。前提是你的流程接收一条 text，完成智能体间的处理后输出一个顶层字符串字段 category。示例数据为虚构工单；本教程依据 2026 年 10 月 1 日读取的官方文档整理，没有在读者的 n8n 实例和模型账号上执行，也没有实测合格率。

先冻结这个测试的判定规则

本例只检查三类：billing 表示发票或账单；delivery 表示配送；human 表示需要人工核实。本次规则为：发票问题归 billing，物流进度归 delivery，同时涉及退款与收货事实争议的请求归 human。这里的 human 是演示业务规则，不是 n8n 内置分类。

把规则传给负责分类的智能体，并要求后续答复智能体保留该类别。不要让测试用的 expected 字段进入模型提示词，否则相当于把标准答案交给了被测流程。最终分类以工作流实际输出为准，不能从答复语气猜测。

建一张小测试表

轻量评估指南支持 Data table 或 Google Sheets。使用 Google Sheets 时需配置对应凭证；本例用 n8n Data table，建下面五列。actual 和 failure_reason 先留空。

这三行分别验证普通类别与人工交接边界，不能代表真实业务全部问题。先用它们验证评估链路，之后再加入脱敏的历史失败、空输入和复杂表达。每轮比较前保持测试输入与 expected 不变。

把测试入口接进已有流程

1. 为已有流程复制一份评估版本，停用会发消息、退款或写正式系统的动作；如果这些动作参与判断，换成只读或模拟节点。
2. 添加 Evaluation Trigger，节点名保持 Evaluation Trigger，Source 选 Data table，选择上述表。
3. 先开启 Limit Rows，将 Max Rows to Process 设为 1，用 Execute node 读入一行，核对 text 和 expected 字段。
4. 把该触发器连接到被测流程第一步，将用户输入明确设为表达式 {{ $json.text }}；不要把整行数据序列化后交给模型。
5. 在最后一个智能体之后，确保输出名为 category。若类别在嵌套对象里，先用 Edit Fields 把实际路径映射成顶层 category，再运行下一步。

Evaluation Trigger 文档说明了数据源和行数限制。逐行运行会分别启动工作流；若流程使用记忆，本评估应关闭不需要的历史，或给每个 case 独立会话，防止上一个样本影响下一个样本。

用确定规则计算匹配结果

最终 category 后加 Code，设 JavaScript、Run Once for All Items，复制下面代码。这里取 Evaluation Trigger 的 first 是因为每次评估执行只有当前一行，不是在一批工单中任选第一行。

const input = $input.first().json;
const test = $("Evaluation Trigger").first().json;
const actual = typeof input.category === "string" ? input.category : "";
const allowed = ["billing", "delivery", "human"];
const valid = allowed.includes(actual);
const matches = valid && actual === test.expected;
return [{
  json: {
    case_id: test.case_id,
    actual,
    category_exact: matches ? 1 : 0,
    failure_reason: !valid
      ? "输出缺少有效 category"
      : matches ? "" : "分类与固定预期不一致"
  }
}];

这里按字符串精确匹配：Delivery、delivery 或一段解释文字都会失败，因为下游约定的是三个精确值。若业务确实允许同义表达，应先明确统一规则，然后同时更新业务输出约定和评估规则，不能为了得分临时放宽。

回填输出，再看每条失败

Code 后添加 Evaluation 节点，Operation 选 Set Outputs，Source 选择同一张 Data table。Outputs 映射 actual 为 {{ $json.actual }}，failure_reason 为 {{ $json.failure_reason }}。不要覆盖 text 或 expected。

Evaluation 节点文档区分 Set Outputs、Set Metrics 和 Check If Evaluating。先把 Limit Rows 关闭或设为本表行数，使用触发器旁的 Evaluate all 运行全表，再查看三行 actual 与 failure_reason。只 Execute node 一次不等于已评估全部样本。

验收时确认每个 case 都得到一条结果，没有漏行、覆盖 expected 或写到另一张表。若 case_03 返回 delivery，打开该 case 的执行，分别检查分类智能体的结果、传给下一个智能体的字段和最终 category；这样能区分“分类错了”与“第二个智能体改掉正确分类”。

有权限时再记录数值指标

保留已有的 Code → Evaluation（Set Outputs） 连线，再从同一个 Code 主输出另接一个 Evaluation 节点，Operation 选 Set Metrics、Metric 选 Custom Metrics。指标名设为 category_exact，数值映射 {{ $json.category_exact }}；这样两个分支分别从同一份 Code 结果回填表格和记录指标，无需重复调用智能体。在 Evaluations 页运行 Run Test，查看汇总和单个 case。该值只评估分类是否精确匹配，不是多个智能体的综合能力评分。

指标评估指南截至核验日说明：轻量评估与指标评估的可用套餐不同，指标评估主要面向 Cloud Pro/Enterprise 和自托管 Enterprise；Registered Community 与 Starter 可用于一个工作流。以自己的当前套餐和界面权限为准。没有指标权限时，保留 Set Outputs 逐行检查仍可完成本例验证。

一次合格之后还应怎么比较

保存模型、提示词、节点设置和测试表版本；更改其中一项后重跑同一张表，逐条核对失败是否修复、旧样本是否退化。正式任务还应分别检查工具结果、事实和禁止动作。本例只证明这三个固定输入的最终分类符合规则，不证明退款权限、事实回答或其他类型任务都正确。