n8n还是Make：长流程按次计费，短流程按步骤更直观

选择 n8n 还是 Make，先看流程长度、运行频率和维护人手。n8n 的定价说明将云版用量按整条工作流的运行次数计算，单次运行的步骤数不设额度上限；因此，步骤多且反复运行的流程，执行额度较容易预估。

流程较短、由业务团队搭建且不想管理部署环境时，Make 更容易按动作估算。Make 的定价说明按 credits 计量模块动作，普通动作通常消耗 1 credit，免费档每月提供 1000 credits。两家的额度单位不同，数字大小不能直接当作费用高低。

先把“步骤”换成实际执行的动作

统一口径后，条件模型才有意义：假设每月运行次数固定，每次只处理一条数据，每个纳入计算的 Make 普通模块动作恰好执行一次。此时，n8n 云版的基础用量等于月度工作流运行次数；Make 的基础用量等于运行次数乘以每次实际执行的计费动作数。这只是额度换算，订阅价格、外部服务费用和维护成本要另算。

Make 的计费动作不等于画布上所有模块的数量。Make 的操作说明将一次 operation 定义为模块处理或检查数据的一次运行：同一模块处理多条数据时可能运行多次，而触发模块检查数据有自己的计算方式。因此，估算长流程时应数实际走过的路径和处理的数据量，不能把流程图中的方框简单相加。

普通动作按次换算还有边界。Make 的部分 AI 或高级功能会随 token、文件大小或处理时间消耗不同额度；循环和多条数据也会让后续模块重复执行。以下模型刻意排除这些变量，用来说明计费单位如何改变用量，而非预测某条已上线流程的账单。

短流程：少量动作更容易逐项估算

假设一条线索进入后，流程依次读取 Pipedrive 记录、更新 Google Sheets，并通过 Gmail 发出通知；把这三项都设为每次运行一次的普通计费动作。若每月运行 200 次，Make 的条件用量为 3 × 200＝600 credits，n8n 云版为 200 次工作流执行。在这些假设成立时，Make 的用量落在免费档额度内。

这个例子展示的是短流程的可读性：业务人员能把每项常规动作与预计额度对应起来，也能较直接地判断新增一个动作会带来多少用量。如果实际使用的是定时检查触发器、一次处理多条线索，或调用动态计费功能，600 credits 就不再是可靠估算。n8n 同样能完成这条流程，但其按整次运行计量的优势，在动作很少时尚未充分体现。

短流程的选择还取决于交接方式。如果流程由运营人员持续修改，现成模块和可视化配置的便利性可能比额度差异更重要；如果团队已经统一用 n8n 管理自动化，单独为这条短流程引入另一平台也会增加维护工作。这里需要比较的是整个团队的工作方式，而非孤立的一条算式。

高频长流程：动作增加会拉开用量曲线

把条件改为每月运行 1000 次，每次实际执行 10 个普通计费动作，n8n 云版对应 1000 次工作流执行，Make 的基础估算为 1 万 credits。若运行频率不变，每次执行的普通动作增加到 100 个，n8n 仍按 1000 次执行估算，Make 则升至 10 万 credits。这些都是同一组假设下的算术结果，并非对现成流程的实测。

差距来自计量位置：n8n 计算整次工作流运行，Make 计算运行中发生的模块动作。但长流程不意味着每次都会走完所有分支。假如条件分支只进入其中一条路径，把全部模块计入 Make 的每次用量会高估；反过来，一个模块若对多条记录反复执行，仅数静态步骤又会低估。

n8n 云版的步骤数不增加执行额度，也不等于计算资源没有边界。流程能否在所选方案的运行时间、并发和存储条件内完成，仍会影响方案选择。Make 若使用动态计费动作，也要把固定模块消耗与变动消耗分开估算。因此，长流程可能使 n8n 的额度更可预测，但不能仅凭 1000 次执行与 10 万 credits 断言哪一家的订阅费更低。

自托管：把部署与维护放进同一笔账

需要自行控制运行环境时，n8n 提供另一种选择。n8n 的部署对照列出可自行部署的免费社区版；Make 的场景运行于云端，企业客户使用本地 Agent 连接内部数据时，场景仍在云端执行。n8n 的付费自托管方案与社区版也应分开比较，前者有对应的方案额度和企业功能。

沿用每月运行 1000 次、每次执行 100 个普通动作的条件模型，社区版 n8n 不产生对应的云版执行额度账单。不过，部署者要承担服务器、存储、备份、升级、监控和故障处理。要比较总成本，应把基础设施支出与负责维护人员的工时计入，再与 Make 的订阅及可能购买的额外 credits 对照。

这笔维护成本会因团队条件而异。已有运行环境和运维人员的团队，可以把自托管纳入现有工作；缺少这些能力的团队，则需要为日常管理和故障响应安排人手。自托管带来的部署控制权是明确的，节省多少费用却无法仅从软件许可得出。

连接器与学习成本决定谁来维护流程

Zapier 的平台比较认为，Make 的可视化搭建方式较容易交给业务团队，现成集成覆盖也更广；n8n 更偏向熟悉表达式、代码和技术维护的团队。连接器总量只能作初筛：同一应用是否提供所需触发器、写入动作和认证方式，直接影响流程能否用现成模块完成。

缺少现成连接器时，两款平台都可以通过 HTTP 接入提供 API 的服务，但配置与后续维护会落到团队身上。对内部 API、复杂数据转换或自定义逻辑较多的流程，n8n 的技术灵活性更有价值；对常见业务应用之间的短流程，Make 的现成模块通常更方便交接。选择由实际动作、运行量和维护责任共同决定，而不是由连接器目录中的一个总数决定。

相关阅读：

• 可灵还是Runway：动态真实感领先，不等于镜头控制更好
• Calendly还是Cal.com：免费功能更宽，可能换来更多配置成本
• Kit还是beehiiv：0%抽成和自动化能力很难同时省钱