展开本页目录
开始前准备什么
- 记录 n8n 与节点版本，在独立流程检查真实输入。
- 准备三行明显不同的虚构数据与固定 ID。
- 断开正式写回与生成自动重试，先验收结果。
- 识别表达式位置
- 保留原行 ID
- 逐行隔离
- 核对来源配对
- 验收三行结果
普通 JSON 数据，固定 ID、SKU 与库存。
在 Run Once for All Items 使用，保留 pairedItem。
状态留空，填写模型实际输出。
按 ID 核对 SKU 与状态，允许顺序变化。
先区别三种串数据
Key、模型价格和更多重试不会修复数据对应。成功数量等于输入数量，也不代表每行正确。
| 现象 | 线索 | 查哪里 |
|---|---|---|
| 每行都用第一行 | 动态表达式在模型或工具子节点 | 子节点 $json 的解析位置 |
| Info for expression missing | 中途节点没有来源配对 | Code 返回的 pairedItem |
| Multiple matching items | Merge / Aggregate 对应多个来源 | .item 的关联链 |
| 顺序改变后 SKU 不对 | 用数组下标猜原行 | 稳定 row_id 与明确关联 |
| HTTP 200 但状态错 | 模型、解析或写回丢身份 | 实际结果与固定夹具 |
- 现象
- 每行都用第一行
- 线索
- 动态表达式在模型或工具子节点
- 查哪里
- 子节点 $json 的解析位置
- 现象
- Info for expression missing
- 线索
- 中途节点没有来源配对
- 查哪里
- Code 返回的 pairedItem
- 现象
- Multiple matching items
- 线索
- Merge / Aggregate 对应多个来源
- 查哪里
- .item 的关联链
- 现象
- 顺序改变后 SKU 不对
- 线索
- 用数组下标猜原行
- 查哪里
- 稳定 row_id 与明确关联
- 现象
- HTTP 200 但状态错
- 线索
- 模型、解析或写回丢身份
- 查哪里
- 实际结果与固定夹具
固定子节点，动态文本放在根节点
模型子节点的 ID、凭据和 Base URL 固定配置，上游 Code 或 Edit Fields 构造每行 prompt，由根节点读取当前项。不要把 SKU、库存等动态内容放在子节点参数。
普通文本分类可用 Basic LLM Chain，无需 Agent。原业务必须使用 AI Agent 时，当前官方节点要求至少连接一个工具，并另验工具输入、执行和回传。
人工搭建结构，不是工作流导入文件
Prepare Code → Loop Over Items (Batch Size = 1)
loop → Basic LLM Chain → 保存 row_id 的结果 → 返回 Loop
done → 汇总 → 离线检查
根节点 Prompt：{{ $json.prompt }}
模型子节点：固定 ID / 凭据 / Base URL三行不同库存，让错配容易被发现
fixture 是普通 JSON 数组，先由自己的输入节点转换成三个 n8n items。将 n8n-prepare-items.js 放到 Code 的 Run Once for All Items，它构造每行 prompt 与 pairedItem；不能直接用终端 Node.js 执行。
脚本不把 expected_status 交给模型。保留模型真实 row_id、sku、status，不在写回前用正确答案覆盖错误。
| row_id | SKU | 库存 | 固定期望 |
|---|---|---|---|
| QR-ROW-A | QH-17 | 0 | sold_out |
| QR-ROW-B | HL-42 | 2 | low_stock |
| QR-ROW-C | BZ-90 | 40 | available |
- row_id
- QR-ROW-A
- SKU
- QH-17
- 库存
- 0
- 固定期望
- sold_out
- row_id
- QR-ROW-B
- SKU
- HL-42
- 库存
- 2
- 固定期望
- low_stock
- row_id
- QR-ROW-C
- SKU
- BZ-90
- 库存
- 40
- 固定期望
- available
本站绘制的内容说明图：此页三行 fixture 不是实际模型输出；官方 AI Agent 画布只解释主流程和子节点端口，不能证明多行配对正确。
新 item 需要来源配对
pairedItem.item 是当前节点输入索引，row_id 是业务身份，作用不同。多对一和一对多按真实关系建立配对，不能全部照搬 index。
官方允许 .first()、.last() 或 .all()[index] 明确选项，但仅当业务确实要该固定项时才用。把表达式全部改 .first()，可能将报错变成静默错配。
一对一 Code 最小示意
return $input.all().map((item, index) => ({
json: { ...item.json },
pairedItem: { item: index },
}));三行通过后，再恢复正式写回
- 检查器允许不同顺序，拒绝重复、缺失、未知 ID、SKU 错配和错误状态。
- 根节点与模型子节点的真实输入还要人工回看，离线结果不能证明节点执行正确。
- 交换两个 SKU 或把状态全改成 sold_out，应检查失败。
- 循环体处理结束后接回 Loop，done 用于最终汇总，不用于重新生成。
填写实际结果模板后检查
python3 check-item-results.py n8n-results.json
本站绘制的内容说明图：检查器允许顺序改变，但必须保留行身份；离线 JSON 通过不能替代真实节点输入和配对的人工回看。
ID 不能代替请求与费用记录
row_id 帮助业务对应，不保证请求幂等。保存 run_id、阶段、原行与未知状态；超时先查执行，不能自动重发整批。
字段依据 2026-10-08 官方文档，夹具与检查器离线验收。本页未声称在你的 n8n 实例完成付费调用；上线前以相同三行核对实际执行和全部费用。
怎样确认已经完成
- 三行身份全程保留，根节点读取当前 prompt。
- Code 配对正确，聚合不按输出顺序猜来源。
- 实际 ID、SKU、状态通过固定夹具检查。
- 正式写回前查看实际执行与完整费用。
常见问题
为什么子节点只读取第一项？
这是官方说明的参数解析行为。动态业务输入放在根节点，必要时循环每次只给一项，型号与凭据保持固定。
改 .first() 可以修复配对吗？
只有业务要第一项才适合。逐行对应需要修复来源配对或使用稳定 ID，不能全部取第一项。
三行 JSON 通过就证明 Agent 工具可用？
该夹具检查数据对应。Agent 还要验真实工具调用、参数、回传和最终回答。