AI自动化创业公司Relay要关闭了。创始人兼CEO Jacob Bank确认，他和团队成员将加入Google的Chrome团队。
更关键的是他留下的那句话：“我们有一些很有野心的计划，帮助你在Chrome里使用AI完成工作，很快会分享更多消息。”
这句话比“加入Google”更有信息量。Relay作为独立产品退场，但它试图解决的问题没有消失：让AI跨应用操作，替用户把任务真正做完。现在，这个方向可能被搬进浏览器。
Relay停了，Google拿到的是团队和经验
目前能够确认的事实并不复杂：
| 已经确认 | 目前还看不清 |
|---|---|
| Relay停止运营 | Google是否收购了Relay公司或相关资产 |
| Bank及团队成员加入Chrome | 交易金额、人员规模和具体入职安排 |
| Chrome将推进AI任务执行能力 | Relay的技术会否直接并入Chrome |
| Bank称很快会公布更多消息 | 原产品能力会以何种名称重新出现 |
因此，把这件事直接写成“Google收购Relay”并不严谨。公开信息只够支持一个更克制的判断：Google吸收了这支团队，并准备在Chrome里继续做AI自动化。
Relay原本做的是多步骤工作流。用户把邮件、表格、CRM和其他网络服务串起来，再让AI参与判断和执行。它与Zapier、Make、n8n处在相近赛道，只是更强调AI参与流程，而非单纯按照固定规则搬运数据。
这类产品一直有一个难题：演示很顺，长期使用很难。
真正进入日常工作后，授权会过期，网页会改版，接口会限流，模型也会误判。一个自动化流程能跑通一次，不代表它能稳定跑半年。创业公司必须同时处理模型、连接器、权限和售后，任何一层失灵，用户看到的都只是“任务没完成”。
Google则少了一道最难的门槛：分发。
Chrome本身就在用户和网页之间。若AI能读取当前页面、调用网站功能，并在用户授权后连续执行操作，很多人不必再单独购买一套自动化工具。这正是Relay团队进入Chrome后最值得观察的方向。
用户现在要处理的，是工作流搬家
创业故事可以慢慢分析，Relay用户没有这种余裕。一个自动化服务关闭，消失的不只是一项订阅，还包括触发条件、字段映射、审批节点和团队内部已经形成的操作习惯。
如果你仍在使用Relay，现实动作应该排在前面：
| 使用情况 | 现在应做的事 |
|---|---|
| 流程仍在运行 | 记录触发器、步骤、条件分支和输出位置 |
| 连接了邮箱、CRM等账号 | 检查授权范围，迁移完成后撤销不再需要的权限 |
| 保存了提示词或业务规则 | 单独导出或整理，避免和平台一起消失 |
| 团队共同使用 | 明确流程负责人，并安排人工兜底 |
| 已经付费 | 核对官方停服、退款和数据处理通知 |
替代工具也不能只看功能列表。Zapier适合连接大量常见SaaS；Make更适合可视化编排复杂流程；n8n给技术团队更多部署和定制空间。迁移时最费时间的通常不是重新连账号，而是复原那些没人写进文档的例外规则。
Chrome未来也许能接住部分需求，但目前不能把一句预告当成迁移方案。Google尚未公布产品形态、开放范围、收费方式和权限边界。把正式业务流程押在尚未发布的能力上，风险太高。
浏览器正在争夺AI的执行权
我更在意的，不是Relay为什么没能继续独立运营，而是Google为什么把这支团队放进Chrome。
过去两年，AI产品争的是对话入口。下一阶段争的是执行入口：谁能看到用户正在处理什么，谁能调用工具，谁能拿到最后一次确认。
浏览器天然占据这个位置。它知道用户打开了哪些页面，也承载邮件、文档、后台系统和大量企业软件。AI一旦从“回答问题”走到“替你操作”，Chrome就不再只是网页容器，而可能成为任务调度层。
历史上，平台吸收独立工具并不新鲜。浏览器曾经吞下下载、翻译、密码管理和PDF阅读等功能。今天的情况并不完全一样，因为AI代理还涉及更敏感的账户权限和操作责任，但权力结构很熟悉：独立产品验证需求，平台利用分发把功能变成默认配置。
这也是我对Relay结局的判断。产品关闭不能证明方向失败，团队进入Chrome也不能证明方向已经跑通。它至少说明，AI自动化正在从单独购买的工具，变成浏览器必须争夺的基础能力。
接下来要看三个具体变量：Chrome是否允许AI跨网站连续执行任务，用户能否逐步确认和撤销操作，以及这套能力是否向第三方开发者开放。
少了权限控制，AI代理容易变成高风险的网页脚本；不开放接口，独立开发者只能围着Google提供的能力做薄薄一层包装。模型强弱反而排在后面。
“天下熙熙，皆为利来。”Relay的团队找到了更大的产品入口，Google补上了自动化经验，各取所需。代价也很清楚：独立AI工具辛苦教育出的市场，最后可能由掌握浏览器分发权的平台收走。