展开本页目录
开始前准备什么
- 明确输入、输出、来源、恢复方式和维护者。
- 记录两平台版本、部署方式和模型 Provider。
- 准备独立测试空间，断开正式业务写回。
- 确定主要任务
- 比较数据映射
- 完成同一夹具
- 模拟失败
- 核对维护与成本
普通 JSON 数据，固定 ID、SKU 与库存。
按 ID 核对 SKU 与状态，允许顺序变化。
虚构商品与规则，带固定来源编号。
3 个可回答问题与 1 个无答案问题。
填写实际答案与来源，没有预填成功结果。
检查固定事实、引用与拒答；没有 API 请求。
按主要工作选择入口
这是根据官方节点职责的选型判断，没有同硬件、同任务的速度排名。Dify 也有 HTTP 与迭代，n8n 也有 AI 与检索，功能不能简单划成互斥。
| 主要任务 | 优先评估 | 仍需验证 |
|---|---|---|
| 文档问答与来源引用 | Dify：Knowledge Retrieval → LLM → Answer | 向量、召回、引用与拒答 |
| 定时读表，逐行处理，再更新系统 | n8n：触发 → 数据 → AI / HTTP → 写回 | 行 ID、配对和失败恢复 |
| 多系统事件联动 | n8n 的应用节点与通用 HTTP | 实际连接器、认证、分页与限流 |
| 有对话入口的 AI 应用 | Dify Chatflow 与应用发布 | 变量、历史、上下文和权限 |
| 已经有两套系统 | n8n 调 Dify 应用 API，或各自调模型 | 两层 Key、超时、ID 和重试 |
- 主要任务
- 文档问答与来源引用
- 优先评估
- Dify：Knowledge Retrieval → LLM → Answer
- 仍需验证
- 向量、召回、引用与拒答
- 主要任务
- 定时读表，逐行处理，再更新系统
- 优先评估
- n8n：触发 → 数据 → AI / HTTP → 写回
- 仍需验证
- 行 ID、配对和失败恢复
- 主要任务
- 多系统事件联动
- 优先评估
- n8n 的应用节点与通用 HTTP
- 仍需验证
- 实际连接器、认证、分页与限流
- 主要任务
- 有对话入口的 AI 应用
- 优先评估
- Dify Chatflow 与应用发布
- 仍需验证
- 变量、历史、上下文和权限
- 主要任务
- 已经有两套系统
- 优先评估
- n8n 调 Dify 应用 API，或各自调模型
- 仍需验证
- 两层 Key、超时、ID 和重试
同一任务，画布字段不同
Dify 的 Remove Failed Results 会缩短数组；n8n 的 Merge、Aggregate 也可能改变顺序和配对。恢复和写回需要业务 ID，不把第几个输出直接当第几个输入。
| 对象 | Dify | n8n |
|---|---|---|
| 输入 | User Input / Workflow 变量 | 节点输出 items，每项有 json |
| 检索 | Knowledge Retrieval.result → LLM Context | 检索文本或工具结果进入模型 |
| 批处理 | Iteration 提供当前 item 与 index | 通常逐项处理；特定情况用 Loop |
| 失败 | 迭代可终止、保留 null 或移除失败项 | 错误分支、执行记录与稳定 row_id |
| 输出 | Answer / Output 变量 | 写回、通知或返回 |
- 对象
- 输入
- Dify
- User Input / Workflow 变量
- n8n
- 节点输出 items，每项有 json
- 对象
- 检索
- Dify
- Knowledge Retrieval.result → LLM Context
- n8n
- 检索文本或工具结果进入模型
- 对象
- 批处理
- Dify
- Iteration 提供当前 item 与 index
- n8n
- 通常逐项处理；特定情况用 Loop
- 对象
- 失败
- Dify
- 迭代可终止、保留 null 或移除失败项
- n8n
- 错误分支、执行记录与稳定 row_id
- 对象
- 输出
- Dify
- Answer / Output 变量
- n8n
- 写回、通知或返回
本站绘制的内容说明图：同一任务的画布字段不同；不能按第几个输出猜第几个原输入，失败结果删除后尤其要保留业务 ID。
批处理对照：3 行库存，固定 3 个 ID
两边都使用 n8n-item-fixture.json：库存 0 为 sold_out，1–5 为 low_stock，超过 5 为 available，要求输出 row_id、sku、status。这个任务检验对应关系，不证明复杂分类的质量。
Dify 用 Iteration 取本项字段，n8n 用 Prepare Code → Loop(batch=1) → Basic LLM Chain 后汇总。原行 ID 与模型输出必须相符，不按输出顺序补写。
固定期望，不是实际运行结果
[
{"row_id":"QR-ROW-A","sku":"QH-17","status":"sold_out"},
{"row_id":"QR-ROW-B","sku":"HL-42","status":"low_stock"},
{"row_id":"QR-ROW-C","sku":"BZ-90","status":"available"}
]知识库对照：相同资料与四问
两边导入 rag-fixture.md，使用相同的向量配置与分块原则。Dify 把 Knowledge Retrieval.result 放入 LLM Context；n8n 把真实召回文本送入模型或检索工具。记录原文、来源、答案和未知问题的拒答。
若一边送整份文件、另一边只送检索片段，输入范围不同，应在结果中注明，不能直接比较速度。下载检查器仅做固定事实检查，最终仍须看平台实际运行与语义。
对照记录
版本 / 部署 / Chat 型号 / Embedding 型号
问题 ID / 命中文本 / 来源 / 实际答案 / 是否编造
首次索引 + 查询向量化 + 全部生成 + 工具与重试失败恢复决定能否长期运行
- 保存 row_id、run_id、阶段与未知状态；超时先查执行，不直接再发整批。
- 让一行缺字段，在付费请求前由验证节点拦住；保留失败项，不删后再按下标写回。
- 首轮关闭生成自动重试，记录平台、SDK、模型节点与 HTTP 节点各层设置。
- 只读查询设置次数与总时长；生成与业务写回需要去重设计和未知结果核对。
本站绘制的内容说明图：本页比较可恢复性；没有实际故障运行数据时不画平台优劣分数。
按 5 个实际结果做决定
apizt 提供模型 API 入口；流程、知识库、发布与平台账户由对应系统维护。统一模型接入可减少重复配置，仍需独立管理向量库与工作流权限。
| 维度 | 记录什么 | 选择依据 |
|---|---|---|
| 任务正确 | 三行对应，四问事实与来源 | 先满足验收，再比速度 |
| 可恢复 | 缺字段、限流、超时和未知 | 保留 ID 与失败记录 |
| 连接成本 | 实际应用节点、认证与部署 | 按现有系统与维护技能 |
| 完整费用 | 索引、工具、模型、重试、平台与托管 | 同任务估价和实扣分列 |
| 维护 | 升级后的夹具、日志与权限 | 能持续复测的方案 |
- 维度
- 任务正确
- 记录什么
- 三行对应，四问事实与来源
- 选择依据
- 先满足验收，再比速度
- 维度
- 可恢复
- 记录什么
- 缺字段、限流、超时和未知
- 选择依据
- 保留 ID 与失败记录
- 维度
- 连接成本
- 记录什么
- 实际应用节点、认证与部署
- 选择依据
- 按现有系统与维护技能
- 维度
- 完整费用
- 记录什么
- 索引、工具、模型、重试、平台与托管
- 选择依据
- 同任务估价和实扣分列
- 维度
- 维护
- 记录什么
- 升级后的夹具、日志与权限
- 选择依据
- 能持续复测的方案
怎样确认已经完成
- 采用同一输入与明确记录的模型、向量和上下文。
- 三行按 ID 校验，顺序变化不串行。
- 四问来源真实，未知问题不编造。
- 保留失败项和全部成本，结论有同任务证据。
常见问题
Dify 和 n8n 哪个更便宜？
合计同一任务的模型、向量、重排、工具、重试、平台与托管。没有实际记录时，不能只用套餐或单次模型估价判断。
可以 n8n 调 Dify 再接 apizt 吗？
可以设计分层，但 Dify 应用 Key 与 apizt 上游 Key 分开管理；核对任务 ID、超时与两层重试，避免重复生成。
下载的是一键导入工作流吗？
是固定输入与离线验收材料。平台版本的节点和变量需按映射搭建，不声称是可执行完整导入文件。