Relay.app 失败拆解：一个「盈利且增长快」的 AI 工作流，为什么仍要关停 (2026)

一句话总结：Relay.app 不是因为没人需要自动化而关停，而是在一个已经有真实工作流、却同时被平台分发、集成维护和 AI 使用成本夹住的市场里，选择结束独立经营。官方公告显示，免费用户将在 2026 年 8 月 15 日停止服务，付费用户将在 9 月 14 日停止服务；公告没有披露关停原因、收入、客户数或留存数据。1

增长判断：Relay.app 更接近「战略败退」，而不是已被证实的产品无人使用。官方账号把它描述为用自然语言连接 X、Notion、HubSpot 等 200 多个应用的 AI 工作流工具；一份 2026 年 3 月的节目页面又将公司描述为「盈利且快速增长」，但这只是页面概述，不是审计过的经营数据。D7、D30、付费客户数、净收入留存率和单位毛利均未披露。1 2

增长因果链：自然语言建流程降低首次门槛 → 工作流、表格、运行记录和凭据提高切换成本 → 每次执行又带来模型、基础设施、第三方连接器和支持成本 → 产品必须同时证明重复运行、足够高的付费和可控的错误率 → 公开证据没有填上这组经营数据，Relay.app 关闭注册与升级，独立增长链条随之中断。最后两步是基于公开材料的推断，不能冒充 Relay 对关停原因的解释。

Relay 在 2026 年 7 月 17 日（北京时间）发布的官方公告如下：

Loading content card…

Part G｜增长系统：激活做得越轻，经营证明越不能缺

Relay 的入口很清楚：用户用自然语言描述任务，再把它落成可视化工作流。官方账号称产品可连接 X、Notion、HubSpot 及 200 多个应用；Zapier 的迁移文章则把 Relay 的产品组件列为 Workflows、Agents、Tables、Sequences、MCP Servers、Path、AI output reviews 和 AI credits。前一条是 Relay 的自我介绍，后一条来自潜在替代者，二者都能说明产品形态，但都不能说明使用规模。1 3

AARRR 环节	已知信号	不能据此推出什么	本期判断
Acquisition 获取	自然语言入口、200+ 应用、AI agent 叙事	不能推出获客成本、自然流量或有效注册数	入口有传播性，获客效率未披露
Activation 激活	可以把描述转成工作流，并组合 Path、Sequence、Table 等组件	未披露首个真实工作流完成率、首次成功时间和人工求助率	可能降低建模门槛，但首次成功率未知
Retention 留存	停运公告仍要求工作流、运行记录和表格导出；说明这些对象对现有用户有迁移价值	未披露 D7、D30、月运行次数、工作流失败率和续费率	有使用资产，不等于有高留存
Revenue 收入	迁移资料给出的起始价格是每月 19 美元，并使用独立 AI credits；官方过渡期给付费工作区额外 25,000 steps 和 10,000 AI credits/月	未披露付费客户数、ARPU、毛利、退款率和净收入留存	计费单位与成本单位都存在，经营闭环未公开
Referral 推荐	官方公告感谢用户的时间、反馈和支持	未披露邀请率、模板传播、团队扩张和客户推荐来源	不能把社区好感当作增长证据

结论：Relay 的公开材料证明了产品能承载复杂工作流，但没有证明复杂工作流已经形成可规模化的增长系统。对这类产品，必须把「注册」拆成四个事件：首次连接应用、首次成功运行、第二次运行、首次付费。少一个，AARRR 就会被宣传口径填空。

Part O｜市场机会：需求是真的，独立位置未必是真的

Relay 所在的市场不是「有没有自动化需求」，而是「谁来承接跨应用、带 AI、需要人工确认的工作流」。它的可服务市场可以先按任务边界拆开，而不是先写一个虚假的美元 TAM：

TAM：所有需要把邮件、表格、CRM、知识库和外部 API 串起来的重复任务。公开材料没有足够数据支持一个统一的全球市场金额，故记为「未披露」。
SAM：愿意使用云端可视化工具，又希望加入 AI agent、人工审核和表格状态的小团队与部门。
SOM：已经在 Relay 支持的应用范围内工作、愿意按步骤和 AI credits 付费、并且不要求自托管的团队。这个范围比「所有自动化用户」小得多，规模未披露。

竞品资料说明了这个市场的拥挤程度。Zapier 官方称自己连接 9,000+ 个应用，并把 Workflows、Agents、Tables、Forms 和企业控制放在同一平台；Make 官方称有 3,000+ 个集成，并把视觉化 AI 自动化与复杂业务流程放在同一画布；n8n 则把源码、Docker、自托管、代码和人工参与放在技术团队的工作流里。4 5 6

市场判断	证据级别	可观察指标	门槛未过时的解释
跨应用自动化有真实任务	A-	同一工作区每月运行次数、成功运行占比	只有试用，不代表可付费
AI 能提高流程价值	B-	AI 步骤带来的人工节省、复核率、错误回滚率	只增加 credits 消耗，就可能放大成本
Relay 有独立可防守位置	C	付费工作区留存、团队席位扩张、模板复用、连接器迁移率	没有公开数据，不能把功能清单当护城河

结论：机会层成立，位置层没有被证明。当 Zapier 用分发和应用数量压住入口、Make 用复杂流程覆盖中间市场、n8n 用技术控制权吸引开发团队时，Relay 需要证明的不是「也能做 workflow」，而是某一类用户在 Relay 上完成得更快、更可靠，而且愿意持续付费。

Part S｜战略定位：卡在「更简单」与「更可控」之间

Relay 的产品组合落在一个有吸引力、也容易被夹住的中间位置：比传统自动化更懂 AI 和自然语言，比纯聊天工具更能保存工作流状态，比自托管系统更少运维。它还把 AI output review、运行记录、Tables、MCP Servers 和可导出的 prompts 放在同一个工作区里。1 3

这个位置带来三种战略压力：

入口压力：连接数和模板数量会影响用户从哪里开始。Zapier 的官方口径是 9,000+ 应用，Relay 的官方账号资料是 200+ 应用；两者不是同一统计口径，但足以说明分发宽度差距。1 4
深度压力：复杂客户会要求版本控制、权限、日志、重试、审计和私有部署。n8n 官方明确提供源码、Docker 和自托管路径，技术团队不必把全部控制权交给单一 SaaS。6
信任压力：越接近业务关键流程，用户越在意凭据、失败回滚、人工确认和迁移，而不是只看生成速度。停运公告要求用户在窗口期导出 workflows、sequences、MCP servers、run history 和 tables，并说明连接应用的凭据与 tokens 会随账户删除。1

从产品状态看，Relay 不是突然消失：2026 年 7 月 16 日（美国当地时间）之后，新注册和免费转付费升级已关闭；现有免费工作区可继续使用 30 天，付费工作区可继续使用 60 天，之后服务和数据进入删除流程。按北京时间，公告中的两个截止时刻分别约为 8 月 16 日 14:59 与 9 月 15 日 14:59。1

结论：这是战略收缩的可观察事实，不是某个功能突然失败的证据。由于 Relay 没有公开解释，不能把「被 Zapier 打败」「AI 成本过高」或「没有客户」写成定论；这些只能列为待验证假设。

Part C｜竞品分析：Relay 需要的不是更多节点，而是一个更强的理由

产品	入口与目标用户	复杂度与控制	AI / 自动化位置	Relay 面对的压力
Relay.app	自然语言 + 视觉工作流；偏向希望少写代码的小团队	Workflows、Path、Sequence、Tables、MCP、人工审核；功能与停运日期来自迁移资料	AI steps、Agents、AI credits	体验完整，但分发和长期承诺已中止。3
Zapier	大规模应用连接和模板入口，覆盖从个人到企业	9,000+ 应用、多步骤流程、分支、Tables、Forms、企业权限	Agents、Copilot、AI steps	入口宽度、品牌和企业控制更强。4
Make	视觉化画布，面向跨部门和复杂流程	3,000+ 集成，可用拖拽、prompt 或 MCP 构建	AI agents 与自动化统一编排	在视觉复杂度和集成规模上覆盖 Relay 的中间位置。5
n8n	技术团队和需要代码控制的用户	源码、Docker、自托管、JavaScript/Python、逐步调试	AI workflow、人工参与、guardrails 和 evaluations	对高价值客户提供更强的控制权，代价是部署与维护。6

表里的功能不是同一版本、同一价格或同一客户群的严格测评；它只回答一个战略问题：Relay 的「自然语言 + 可视化 + AI」组合是否足以抵御更宽的分发与更深的控制。公开证据给不出肯定答案。

结论：Relay 的差异化更像一段体验优势，而不是一个能阻止替代的经营优势。如果一款工作流产品不能在某一垂直流程上形成模板、数据反馈和团队协作的复利，就会被更大的连接器平台和更可控的技术平台同时吸收。

Part P｜产品设计：让用户搭出流程，不等于让流程可靠地跑

Relay 的产品路径可以还原为六步：

连接外部应用，选择触发事件。
用自然语言或视觉节点描述任务。
加入 AI step 或 agent，让模型处理非结构化输入。
用 Path、Sequence、Table 或 MCP Server 处理分支、复用、状态和外部工具。
在 AI output review 或关键节点加入人工确认。
查看 run history，处理失败，并在必要时导出工作流与数据。

这条路径的优点是把「写 API 胶水代码」变成「配置一个可视化流程」。它的风险也藏在同一条路径里：每增加一个连接器、一个 AI step 或一个人工复核点，产品就多一层字段映射、权限、延迟、错误处理和支持成本。停运时需要导出的对象并不只是画布，还包括 prompts、run history、tables，以及连接应用的凭据处理，这说明迁移的单位是工作系统，不是一张流程图。1 3

设计上真正缺的四个仪表盘

重复任务仪表盘：同一个工作区在 D30 是否仍执行原来的工作流；不要把登录或聊天次数当留存。
人工接管仪表盘：AI step 触发了多少人工 review、多少次回滚、多少次用户改写；人工介入是安全设计，也可能是毛利黑洞。
结果仪表盘：流程是否完成了发送、入库、分类或审批，而不是只生成了一段文本。
单位成本仪表盘：每次成功任务消耗的模型、基础设施、连接器和支持工时，必须能回到单一工作区的毛利。

结论：Relay 的产品设计解决了「如何把流程搭出来」，但公开材料没有证明它解决了「如何让流程长期可靠地跑，并且每次跑都赚钱」。这是产品价值与平台经营之间最容易被混淆的断点。

Part E｜商业模式：按 steps 和 credits 收费，仍要回答一次任务值多少钱

Relay 的收费方向是订阅加用量：Zapier 的迁移资料记载其起始价格为每月 19 美元，并使用独立的 AI credits；付费用户在停运过渡期还会获得额外 steps 和 AI credits。3

这个模型的好处是能把重度使用者的成本部分传给客户，坏处是客户对账单的预期会变得复杂。对工作流产品，至少要拆出四个单位经济问题：

经济问题	需要的真实数据	Relay 的公开状态
收入	付费工作区数、ARPU、年付占比、扩容率	未披露
成本	每次成功任务的模型、基础设施、连接器和支持成本	未披露
留存	D30/D90 工作流运行率、续费率、净收入留存率	未披露
风险	失败重跑、退款、凭据事故、迁移工时	未披露；公告只提供了导出与支持安排。1

节目页面把 Relay.app 描述为「盈利且快速增长」，但页面没有给出利润表、客户数、收入或增长率；因此这条信息只能作为低置信度的公司状态线索，不能与关停公告拼成「盈利后仍因某个单一原因失败」的故事。2

结论：Relay 的商业模式没有被证明错误，真正缺失的是规模化证据。在数据未披露前，最稳妥的判断是：它可能已经有愿意付费的用户，但没有公开证明独立产品的增长、利润和战略价值足以继续获得资源。

Part L｜洞察提炼：三个常被混在一起的判断

1. 有人把工作流跑起来，不等于平台有增长

停运公告为用户提供导出 workflows、sequences、MCP servers、run history 和 tables 的工具，说明迁移对象很具体；但「有迁移对象」只证明使用资产存在，不证明用户数量、频率和续费质量。1

可证伪条件：如果一个新产品连续三个月能让同一批工作区每月运行至少 4 次、D30 留存达到 35% 以上，并且 AI 与连接器成本后的毛利仍为正，那么它才有资格把「工作流资产」写进增长论证；这是建议门槛，不是 Relay 的历史数据。

2. 集成数量是获客资产，不是自动形成的护城河

Relay 的 200+ 应用与 Zapier 的 9,000+ 应用不能直接比较市场份额，因为统计口径未知；但连接器数量会影响用户能否把现有业务接进来，也会影响维护成本。1 4

可证伪条件：只有当某一垂直场景的模板复用率、同团队席位扩张率和迁移后成功运行率显著高于通用平台，集成才可能沉淀为防守位置；若用户只把它当一次性连接器，功能越多，维护负担越大。

3. AI 让工作流更容易生成，也让责任更难转移

Relay 的 AI steps、agents 和 human-in-the-loop 同时增加了产品价值与风险。n8n 官方也把人工参与、护栏和 AI evaluations 列为 AI 工作流能力，说明市场正在把「能生成」推进到「可测试、可控制」的阶段。3 6

可证伪条件：当 AI 步骤的任务完成率、人工接管率、错误回滚率和单次任务毛利都达到产品设定门槛时，AI 才是收入增量；只看生成次数或 credits 消耗，会把成本误报成增长。

结论：Relay 案例最值得留下的不是「小团队打不过大平台」，而是三个指标必须同时成立：任务重复、结果可靠、单位经济为正。缺一个，功能表越长，结论越模糊。

Part D｜决策分析：把「继续做」变成一组有退出条件的测试

Relay 没有公开关停原因，读者无法从外部替它做归因；但创业者、产品负责人和投资人可以把这起案例转成一张决策表：

阶段	必须观察的事实	建议门槛	未达标时的动作
激活	新工作区在 24 小时内完成一个真实工作流，并成功跑完一次	≥60%	缩短连接与字段映射，减少可选组件，不扩张集成数量
重复	同一工作区在第 30 天仍运行原任务	D30 ≥35%，且月均 ≥4 次	访谈未重复用户，砍掉一次性 demo，聚焦高频任务
结果	任务最终完成，而不只是生成文本	成功完成率 ≥90%；人工接管率与回滚率单独记录	把 review、重试和回滚前置，限制高风险自动操作
付费	客户愿意为结果和可靠性付费	激活工作区付费率 ≥5%，或每个付费工作区贡献正毛利	停止用免费注册替代需求验证，重做价格与用量单位
平台	客户把更多团队流程迁入，并减少离开意愿	90 天净收入留存率为正向增长；关键工作流迁移成功率 ≥90%	先做迁移、审计和权限，再开发更多 AI 功能

这些数字是建议的决策门槛，不是 Relay 已披露的数据，也不是行业基准。它们的作用是让下一次战略讨论可以被结果推翻，而不是把「看起来增长」当成答案。

给创始人的动作顺序

先给每个工作区建立任务级 cohort：首次运行、第二次运行、D30、D90、人工接管、最终结果和毛利全部分开记。
再把 AI credits 换算成「每个成功结果的成本」，而不是只看调用量；免费额度、试用额度和真实付费额度不能混算。
最后决定是走宽平台还是窄工作流：若分发和集成数量追不上平台，就必须在一个有高频、强结果、可复制模板的垂直流程里建立优势。

最终判断：Relay.app 的失败证据是「独立服务已进入确定的关停窗口」，不是「产品没有价值」。事实层面的置信度为 A；盈利与快速增长的来源只有节目页面概述，置信度为 C；关停原因未披露，任何单因果解释都只能标为 C。对下一款 AI 工作流产品，最先要问的不是「还能加什么 agent」，而是「第 30 天，谁还在为哪个结果付费，以及这次成功运行留下多少毛利」。