小白 / Xiaobai
开发者 · 产品构建者
持续构建 AI 工程系统、开发者工具与长期数字资产。
关于作者与 XBSTACK →
n8n vs Make：AI 工作流怎么选？计费、自托管、开发能力与运维成本对比
n8n vs Make 怎么选？按 2026 当前计费与产品能力比较 n8n execution 模型、Make credits、自托管 TCO、AI 工作流、代码扩展、数据边界和运维责任，不再用“10 倍省钱”替代真实成本核算。
n8n 和 Make 的真正差异，不是“一个给程序员、一个给小白”，更不是“n8n 一定省 10 倍”。**2026 年选型首先要看计费单位、部署责任和你的真实 workload。**n8n Cloud 按完整工作流的 production executions 计费，工作流内部可以包含很多步骤；Make 当前把计费单位称为 credits，普通非 AI 模块通常是一项 operation 消耗一 credit，部分内置 AI 能力还会结合 token 与其他使用因素动态计费。自托管 n8n 则把一部分 SaaS 费用换成服务器、数据库、备份、升级和人工运维成本。
所以这篇不再给一个虚构的“10 倍成本答案”。下面用同一套工作量模型判断：哪一种计费方式对你的流程更友好，哪一种运维责任是你愿意承担的。
先看最关键的计费单位
截至本次核对，n8n 官方把 Cloud 使用量定义为 workflow executions：一次工作流从触发到结束算一次 execution，官方明确强调工作流内部步骤数量不是 Cloud execution 的计费单位。当前套餐、并发、历史保留和高级功能仍应在购买当天重新看官方价格页。
Make 当前已经从旧文章常写的“operations 作为计费货币”迁到 credits。普通非 AI 模块通常仍是一次 operation 对应一个 credit；第三方 AI 应用常见为 operation 消耗 credit、模型 token 另付给 Provider；Make 自己的部分 AI Provider/AI 功能则可能按 token、operation 和功能复杂度动态消耗 credits。
这意味着旧式比较：
Make：19 个节点 = 19 Ops
n8n：1 次 workflow = 1 次 execution
所以 n8n 便宜 N 倍
只能说明计费粒度不同，不能直接推导账单倍率。Make 的 credit 单价、模块消耗、计划档位，n8n 的 execution 套餐、自托管服务器和模型费用都需要一起算。
用一个 workload 复算，而不是编一个 ROI
假设有一个竞品监控流程：
定时触发
→ 拉取若干站点/RSS
→ 过滤新内容
→ 抓正文
→ 调模型总结
→ 写数据库/Notion
→ 汇总周报
→ 发通知
真正应该记录的是：
| 变量 | 你需要填的真实值 |
|---|---|
| monthly_runs | 一个月触发多少次 |
| items_per_run | 每次平均处理多少条 item |
| make_credit_per_item | 每条 item 触发哪些 Make module / AI credit |
| n8n_cloud_executions | 每次触发是否形成 1 个或多个 production execution |
| model_tokens | 两个平台实际调用模型的输入/输出 Token |
| external_api_cost | 搜索、OCR、数据库、邮件等外部费用 |
| infra_cost | 自托管主机、数据库、存储、备份、带宽 |
| ops_hours | 每月升级、监控、故障和备份需要多少人工时间 |
然后分别算：
Make TCO
= plan/credit cost
+ external AI/API cost
+ integration-specific cost
+ maintenance time
n8n Cloud TCO
= execution plan
+ external AI/API cost
+ optional paid services
+ maintenance time
self-hosted n8n TCO
= infrastructure
+ database/storage/backup
+ monitoring/network
+ external AI/API cost
+ license cost if using paid self-hosted features
+ operator time
这比“我跑了 10 万次，所以只有某工具活得下来”更有参考价值。
自托管 n8n 不是“运行成本为零”
n8n 提供标准的 self-hosted Community Edition，这对需要控制部署位置、网络和运行时的团队很有价值。但“代码可以免费下载运行”和“业务成本为零”是两回事。
至少要承担：
- 主机/容器资源；
- PostgreSQL 或其他持久化依赖；
- 磁盘、执行日志和备份；
- TLS、域名、反向代理或私网接入；
- 升级、迁移、回滚；
- OOM、磁盘满、队列积压和 Worker 故障；
- 模型 API、OCR、搜索、邮件等外部服务费用；
- 某些商业功能对应的 n8n Business/Enterprise 授权成本。
如果你本来就有 NAS/VPS，边际基础设施成本可能很低；如果公司需要高可用、多环境、SSO、集中日志和 SLA，运维成本可能高于直接买 SaaS。应该按你的资源与工时算，而不是把“自托管”自动翻译成“免费”。
本地部署也不等于“一个字符都不出公网”
自托管能让工作流引擎和你选择的数据存储留在指定网络边界，但数据是否出网取决于每一个节点：
n8n on LAN
→ OpenAI API # 数据出网
→ SaaS CRM # 数据出网
→ Gmail / Slack # 数据出网
→ local Ollama # 可留在本地
→ local PostgreSQL # 可留在本地
还要检查 Telemetry、日志、远程备份、错误追踪和管理员访问。因此合规判断应画一张 data-flow map，标记每个 processor/subprocessor 和敏感字段，而不是写“100% 私有”。
AI 工作流：不要再用“n8n 原生、Make 不懂 Agent”二分
n8n 确实提供了面向 AI 工作流的节点、模型、Memory、Tools 和向量存储组合，而且 Code、HTTP 请求、自定义节点和自托管能力让开发者能够深入介入执行路径。这是它在复杂工程场景中的真实优势。
但不能因此把 Make 描述成“只能用 HTTP 硬拼”。Make 也持续增加 AI/Agent 相关能力，并且它的 AI credit 计费已经单独体现了这类功能。比较时应该把你实际要用的功能列出来：
- 多轮 Tool Calling 是否需要？
- 是否需要 durable state？
- 能否显式控制 retries / error route？
- 是否需要自定义代码和 npm/Python 依赖？
- 是否需要私网数据库？
- 是否需要 Git/环境隔离/版本发布？
- 团队是否更看重现成 SaaS connector？
然后用一个真实流程在两边搭出来，再比较完成时间、失败恢复、可维护性和每月成本。
开发能力：n8n 的优势是“逃生通道更多”
对于开发者，n8n 的 Code 节点、HTTP Request、Webhook、自定义节点和 self-hosting 提供了较多逃生通道。当平台没有现成节点时，你通常仍可以回到通用 API 或代码。
例如清洗模型返回值：
const rawText = item.text;
const clean = rawText.replace(/`{3}(?:json)?/g, '').trim();
const parsed = JSON.parse(clean);
return {
title: parsed.title,
summary: parsed.summary,
};
但这不表示 Make “排斥代码”或复杂逻辑一定“痛苦十倍”。Make 的价值恰恰在于很多业务集成可以依靠现成模块、映射和 Router 快速交付。开发效率是 workload 属性，不是平台人格。
Connector 生态：不要再写死“1500 个 vs 数百个”
连接器数量变化很快，而且“有一个 App 图标”并不代表它覆盖你需要的全部 API。更实际的检查顺序是：
- 目标系统有没有官方 connector；
- 关键 endpoint、pagination、webhook 和 OAuth scope 是否覆盖；
- 缺失能力能否用通用 HTTP/API 补齐；
- 是否允许自定义 connector/node；
- connector 更新速度和错误处理是否满足要求。
对于长尾 SaaS、业务团队自助搭流程，Make 的托管连接生态可能减少开发工作；对于内部 API、私网服务和自定义逻辑，n8n 的通用接口与自托管更容易掌握主动权。
生产环境真正要比较的是失败语义
不要只看“能不能连起来”。对 AI 工作流至少测试：
- webhook 重复投递是否幂等；
- 429 是否遵守
Retry-After； - 5xx/timeout 是否会重复写外部系统；
- 某条 item 失败时是整批失败还是局部重试；
- workflow 被手工停止后，后台任务是否继续；
- 凭据轮换后旧 execution 如何处理；
- 大 payload 是否进入数据库/日志导致 OOM 或磁盘增长；
- AI 输出结构错误时是否有 deterministic validation；
- 生产/测试环境能否隔离。
自托管 n8n 常见问题可以包括 PostgreSQL/Redis/Worker/内存和升级；Make 则更多受 SaaS 计划、credit、connector 和平台能力边界约束。哪一个“更稳定”必须通过你的失败注入测试判断。
一张决策表
| 需求 | 更值得先验证的方向 | 原因 |
|---|---|---|
| 快速连接大量 SaaS、少运维 | Make | 托管交付与 connector 体验通常更省基础设施工作 |
| 私网 API / 数据库 / 自定义代码很多 | self-hosted n8n | 网络和运行时控制空间更大 |
| 工作流步骤很多、每次触发处理大量 item | n8n Cloud 与 Make 都要复算 | n8n execution 与 Make credit 粒度不同，可能造成明显成本差异 |
| 内部平台需要 Git/环境/治理 | n8n 商业自托管或 Enterprise 方向 | 需要结合当前套餐能力评估，Community Edition 不等于全套企业功能 |
| 业务团队不想维护服务器 | Make 或 n8n Cloud | 不应为了“自托管”承担不必要的 Ops |
| AI Agent / Tool Calling 很复杂 | 先做同一任务 PoC | 比节点宣传更重要的是状态、Tool、错误恢复和可观测性 |
最终怎么选
先选责任边界，再选产品。
如果你希望平台替你维护运行环境、团队主要依靠 SaaS connector 快速交付，Make 值得先验证。如果你需要大量自定义代码、私网系统、可控部署和复杂数据处理，n8n 往往更符合工程团队习惯。如果只是因为看到“自托管免费”就迁移，最后可能只是把 SaaS 账单换成了自己的值班和故障恢复时间。
成本也不要提前宣布赢家。拿最近一个月真实 workload，把触发次数、item 数、credits/executions、模型费用、服务器和运维时间全部填进表，再做决定。能被复算的 TCO，比“10 倍省钱”更适合生产选型。
继续阅读
- 自托管 n8n：Docker、Postgres、VPS 与 NAS
- n8n AI Workflow 错误处理、重试与成本监控
- Zapier vs Make vs n8n
- AI Agent vs Workflow Automation
继续按 n8n 生产排障链路读
自托管、Queue Mode、Webhook、错误处理和案例文统一沉淀到 Workflow 专题页：部署文做主力页，案例文做长尾页，对比文承接工具选择流量。
继续阅读
返回专题 →AI 工程周报
只发真正改变工程判断的变化、故障、实验和新资产。
参与讨论
问题、验证与勘误
登录后可发表评论。所有新评论先进入审核；审核期间仅评论者本人和管理员可见，通过后才公开。