多租户自动化产品如何选引擎与许可证

做一个面向诊所、房产中介或代理公司的 AI 自动化产品，先别急着选 n8n 还是 Activepieces。作者认为，真正决定许可证、架构和利润空间的问题是：客户能不能自己创建、修改工作流？

作者交付过几类这样的产品，给出的路线是：团队设计流程、客户消费结果，可以考虑把 n8n 藏在后端；客户自己搭流程，则从 Activepieces CE 起步，或为 n8n Enterprise 留预算。文章更值得看的部分，是如何把自动化演示做成能隔离租户、核算成本、追查错误的产品。

客户能不能改流程，为什么比选引擎更重要

原文先提到 n8n 以 $2.5B 估值融资，但估值只是背景。选型要看产品把什么能力交给客户。

第一种是「结果即服务」：你设计好漏接电话短信回复、预约提醒等流程，客户只负责启用。第二种是「客户自己搭建」：客户能够选择步骤、连接服务、配置执行逻辑。

许可证边界取决于客户能做什么，而不只是界面属于谁。

按作者对 n8n 许可 FAQ 的转述，免费使用适用于工作流仅由你或组织内部人员创建、修改的情况；允许外部用户构建或配置工作流，需要 Enterprise 许可。入口即使换成自有 UI、API、MCP 或 AI agent，也不能据此绕过边界。

Activepieces 则有 MIT 许可的核心，以及商业许可的 ee 目录。作者建议客户搭建型产品考虑 Activepieces CE，但不能把整个项目都当成 MIT 代码。

这些是原文给出的许可判断，不是对你具体产品的授权结论。作者也明确建议：面向客户的实际用法，应拿到供应商书面确认。

把 n8n 藏在后端，租户边界仍要自己守住

结果型产品里，你的应用负责 UI、租户、计费和凭证，n8n 只与后端交互。

原文用下面这段结构说明一次启用如何落到执行与回写：

Customer UI (your app)
   |  toggles "Missed-call text back" for Clinic #42
   v
Your API  ──>  Template registry (versioned workflow JSON)
   |                 |
   |   instantiate with tenant params (phone, calendar id, timezone)
   v                 v
n8n (queue mode: main + workers + Redis)  <──  webhook in from Twilio/Calendar
   |
   v
Your API callback  ──>  tenant DB (Postgres, row-level security)

要留意最后一行：执行结果经过自有 API，才进入带行级安全策略的 Postgres 租户数据库。隔离责任仍在产品侧。

作者强调，工作流应保存为仓库中可版本化的 JSON 模板。客户启用时，由 API 注入电话、日历 ID、时区等参数，通过 n8n API 创建或更新，避免每个租户的配置逐渐变成无法追踪的特例。

每次执行还要携带 tenant_id，下游调用持续传递。回调不能直接相信这个字段，而要通过签名令牌验证其归属。

OAuth token 尽量留在自有凭证库，可以用加密列或 secrets manager。流程通过你的 API 操作第三方服务，n8n 只持有内部 API key。作者把退租简化为数据库里一次 DELETE；实际价值是减少引擎内散落的租户凭证，但文章没有展开其他数据的清理过程。

运行层面，作者建议从第一天采用 queue mode，用 main、workers 和 Redis 分开调度与执行，后续再把高负载租户放进独立 worker pool。Webhook 则必须在执行前去重，例如对事件 ID 做哈希，避免电话或日历系统重试时重复发短信。

客户自己搭流程，AI 节点也要受平台约束

一旦产品卖的是构建器，工作量就从「维护模板」变成「经营自动化平台」。

租户需要独立项目或命名空间，API 还要阻止跨租户触发。每分钟、每月执行额度必须在进入引擎前检查，执行完再统计只能用于计费，拦不住资源消耗。

允许自定义代码步骤，还要处理不可信代码：隔离 worker，并限制 CPU、内存和网络出口。计费则从执行日志按租户统计任务运行次数，每晚同步到账单系统。

AI 在这里也只是一个节点。作者推荐先用小而便宜的模型，把事件分成改期、投诉、新线索等类别，再交给确定性步骤处理，避免模型自由操作客户日历。

预约、取消、退款等工具调用都经过自有 API，由 API 做参数校验和审计。涉及付款或代表客户发送消息，先加入人工审批，直到错误率得到验证。同时按租户记录 prompt、输出和最终决策，方便回答「为什么给这个人发了这条消息」。

我的判断

这篇最有用的判断，是把产品能力、许可证和运维责任放在一起讨论。自有 API 承接凭证、权限和副作用，也让 Node 后端有机会统一控制规则，避免关键判断散落在工作流节点中。

但它主要是交付经验，没有给出 n8n 与 Activepieces 的性能对照、维护工时或故障率。不能据此断言某个引擎更便宜、更稳定。

成本部分同样只是草算：50 个租户，n8n main 加 2 个 workers 和 Redis 每月数百美元；托管 Postgres 为数十到数百美元；小模型配合积极缓存，分类调用每天每租户几美分。短信和电话通常是最大的可变成本，作者建议转嫁计费。

按每租户每月 $199，50 个租户约为 $10K MRR。这个数字是收入，不是利润。文章没有列出执行量、消息量和支持工时，也没有展开退租清理与失败恢复成本，因此不能当作商业计划的利润依据。

「第一天就上队列」也有前提。它适合准备承接多租户负载的产品；若还在验证客户是否愿意付费，自建队列集群、托管执行或更小的部署，仍需按真实负载取舍。原文没有做这些方案的对照。

能拿来做什么

• 先把客户可操作范围写成产品规则，区分启用固定模板与配置流程；前端开放哪些表单字段，也应进入许可确认的描述。
• 在 Node 后端统一承接第三方操作，校验 tenant_id、签名和参数，让工作流与 AI agent 都通过同一套接口执行。
• 给电话、日历等 webhook 加执行前去重，并把租户、事件和执行记录关联起来，方便定位重复触发与错误消息。
• 如果准备开放流程编辑器，先估算租户限流、代码沙箱、日志计量和支持成本，再决定售价与上线范围。