Muse AI 注册实测：为什么最近突然火了，以及我如何用 Gmail + Lexmount Cloud Browser 跑通注册
最近几天如果你关注 AI，应该很难绕过一个名字：
Muse AI。
它不是又一个单纯陪你聊天的大模型，而是 Meta 在 9 月 8 日正式推出的 Personal AI Agent，也就是个人 AI 智能体。
和传统 Chatbot 最大的不同在于，Muse 不只是回答“我应该怎么做”，而是希望直接替你把事情做掉。
按照 Meta 官方的介绍，Muse 可以处理邮件、安排任务、预订旅行、购物，也可以把一个长期目标拆成计划并持续推进。它运行在独立的 Muse Secure VM 中，这台虚拟机本身拥有浏览器，可以代表用户在不同网站和服务之间执行任务。
换句话说，过去我们熟悉的 AI 更像是：
你提出问题
↓
AI 告诉你应该怎么做
而 Muse 想做的是：
你告诉它目标
↓
AI 自己拆解任务
↓
打开浏览器 / 调用服务
↓
真正把事情执行下去
所以我觉得 Muse 最近突然火起来，并不只是因为“Meta 又发布了一个 AI”。
它真正踩中的，是：
Personal Agent 开始从技术圈走向普通消费者。
Muse 上线后的增长也非常快。
Reuters 在 9 月 23 日的报道中提到，Muse 上线约两周已经获得大约 280 万次下载，并登上苹果和 Google 应用商店免费榜前列。
资本市场也迅速开始讨论 Personal AI Agent 对购物、旅游、金融、订阅等行业可能造成的影响。Reuters 报道中提到，Meta 股价一度出现接近 13% 的上涨。
更有意思的是，Muse 已经开始直接碰到现有互联网平台的利益边界。
比如 Amazon 就开始阻止 Muse 在 Amazon 网站中执行部分自动浏览和购物操作。
这件事情本身就很有代表性。
以前 AI 更多还是：
帮用户生成内容
而 Agent 开始变成：
代表用户进入其他平台
↓
搜索
↓
比较
↓
填写
↓
购买
↓
完成操作
这意味着它开始真正碰到互联网平台原来的“入口价值”。
所以现在 Muse 火的已经不只是“一个 AI 产品”，而是大家开始意识到：
如果 AI 以后不是告诉你怎么买，而是直接替你比价、填写表格、预订、付款、执行任务，那么互联网很多原来的入口都会发生变化。
这也是为什么我自己看到 Muse 之后，第一反应不是只看新闻，而是想真正注册进去体验一下。
但问题来了：Muse 目前并不是所有地区都在同步推出
Meta 在 9 月 8 日的官方发布文章中明确写到：
Muse 正在美国的 iOS、Android 和 muse.ai 上推出。
所以当时我真正开始注册的时候，很快就遇到了实际问题。
直接用原来的普通浏览器和邮箱访问 Muse，并没有顺利进入完整的注册流程。
于是我开始测试：
到底是账号本身的问题，还是浏览器 / 网络环境的问题？
这也就是为什么后面会出现 Airtap、Browser Use Cloud 和 Lexmount Cloud Browser。
我并不是一开始就为了“用虚拟浏览器而用虚拟浏览器”。
而是普通环境没有顺利跑通以后，我才开始从：
- 浏览器环境
- Cloud Browser
- 网络出口
- 自动化控制链路
这些方向逐个测试。
说明：Cloud Browser 只是我本次测试使用的浏览器环境，并不代表可以绕过 Muse 自身的年龄、地区或其他资格要求。相关资格仍应按平台规则执行。
一、我前后测试了哪些方案
我先后尝试过：
- Airtap Cloud Phone
- Browser Use Cloud
- Lexmount Cloud Browser
最后真正完整跑通的是：
Gmail + Lexmount Cloud Browser + Muse
Muse 注册页面：
https://muse.ai/join
Lexmount Cloud Browser：
https://browser.lexmount.com/
这篇文章主要记录最终成功的这条路径，以及中间遇到的一个很有意思的问题：
ERR_TUNNEL_CONNECTION_FAILED
二、为什么最后选择 Lexmount Cloud Browser
Lexmount 提供的是一个运行在云端的 Chromium 浏览器环境。
对于这次测试来说，可以简单理解为：
本地浏览器
↓
Lexmount 控制台
↓
云端 Chromium
↓
Muse
所以实际访问 Muse 的，并不是我电脑本地的 Chrome，而是 Lexmount 中运行的 Chromium。
这和本地开一个无痕窗口并不是同一回事。
它提供的是另一套浏览器运行环境和网络链路，这也是我想测试它的主要原因。
三、注册并进入 Lexmount
打开：
https://browser.lexmount.com/
注册并登录后，进入 Cloud Browser / Playground 页面。
页面右侧会出现一个云端 Chromium。
如果启动正常，顶部通常能看到：
Connected
此时就说明云端浏览器已经启动。
四、在 Lexmount 中打开 Muse
在右侧 Chromium 地址栏输入：
https://muse.ai/join
我实际测试的时候出现了一个很容易让人误判的问题。
Lexmount 左侧的脚本执行区域报错：
Error: net::ERR_TUNNEL_CONNECTION_FAILED
乍一看，很像整个访问已经失败。
但我再看右边却发现：
Muse 页面实际上已经打开了。
也就是：
左侧自动化执行：
ERR_TUNNEL_CONNECTION_FAILED
右侧真实 Chromium：
Muse 正常加载
所以如果你遇到同样的问题，我建议先不要只看左侧错误日志。
重点观察：
右侧 Chromium 到底有没有真正加载出页面。
如果已经看到 Muse 登录界面，以及邮箱或手机号输入框，就可以直接手动操作右侧浏览器。
五、这个现象为什么值得记录
这个现象其实比“最后注册成功了”本身更值得技术人员注意。
因为 Cloud Browser 中至少存在两条不同的链路。
自动化控制链路
例如：
Playwright
CDP
WebSocket
Browser Automation API
浏览器真正访问网页的网络链路
例如：
Chromium
↓
HTTPS
↓
muse.ai
因此：
自动化接口失败
并不一定意味着：
浏览器页面访问失败
如果只盯着 Playwright 或自动化脚本的报错，很容易误判当前浏览器的真实状态。
这也是为什么我看到 ERR_TUNNEL_CONNECTION_FAILED 之后没有马上退出，而是继续观察右侧页面。
结果最后反而跑通了。
六、使用 Gmail 完成 Muse 注册
我本次测试实际使用的是 Gmail。
流程大致如下：
输入 Gmail
↓
接收验证码
↓
回到 Muse
↓
输入验证码
↓
继续完成账号信息
↓
进入 Muse
姓名、生日、年龄等内容按照 Muse 页面要求正常填写即可。
我建议在整个注册流程完成之前，不要频繁切换浏览器环境。
既然已经在 Lexmount 中打开了 Muse，就先在同一个 Cloud Browser 会话中完成后面的步骤。
七、怎么判断 Muse 已经真正注册成功
如果最后已经进入 Muse 主界面，而不是继续停留在 Waitlist 或注册提示页面，基本可以认为账号已经初始化完成。
之后可以打开：
设置
↓
通用
↓
使用情况
英文界面对应：
Settings
↓
General
↓
Usage
我自己的页面中可以看到：
- 免费版
- 免费额度重置时间
- 额外的使用额度
- 当前额度使用比例
这一页后面还有一个比较容易忽略的功能：
邀请码兑换。
八、Muse 的邀请码入口在哪里
我实际测试时，邀请码入口位于：
设置
↓
通用
↓
使用情况
↓
兑换邀请码
也就是：
Settings
↓
General
↓
Usage
↓
Redeem invite code
如果是刚加入 Muse 的账号，可以检查这里是否仍然存在兑换入口。
根据我本次看到的规则，这个兑换存在时间限制：
加入 Muse 后 48 小时内
如果超过时间，入口或兑换资格可能发生变化，因此以自己账号页面实际显示为准。
九、我实际测试的邀请码
这里把我这次真正完成兑换的邀请码也记录下来：
U8GIDI
需要说明：
邀请码不是 Muse 注册本身的必要步骤。
不填写邀请码，也不影响账号正常注册。
它属于 Muse 当前的邀请奖励机制。
如果账号仍然处于可以兑换邀请码的时间范围内，并且愿意使用：
U8GIDI
双方都会获得额外的 Muse 使用额度。
我自己已经实际完成了兑换。
页面当时显示：
邀请码兑现成功。你们都获得了 10 亿个 Muse 词元。
兑换完成后，我再回到：
设置 → 通用 → 使用情况
可以看到：
额外的使用额度
剩余 20 亿个词元
这部分和每周重置的免费版额度是分开显示的。
因此从产品机制上看，邀请码奖励属于单独的额外使用额度。
十、为什么 Browser Use Cloud 没跑通，而 Lexmount 跑通了
我前面还测试过 Browser Use Cloud。
当时 Browser Use Cloud 访问 Muse 时出现：
ERR_TUNNEL_CONNECTION_FAILED
并且最终没有像 Lexmount 一样顺利完成后续流程。
有意思的是，Lexmount 左侧同样出现过类似错误。
但是 Lexmount 的右侧 Chromium 却成功加载了 Muse。
所以这次测试至少说明了一点：
同样是 Cloud Browser，不同平台的浏览器运行环境、网络出口和自动化链路并不完全相同。
因此 A 平台失败，并不能直接推导出：
所有 Cloud Browser 都无法访问
反过来也一样。
Lexmount 现在能够成功，也不能说明它以后一直都会保持相同状态。
十一、为什么这种方法可能随时发生变化
Cloud Browser 本身存在很多变量，例如：
- 云服务商出口网络变化
- IP 节点变化
- 代理策略变化
- 网站风控规则变化
- 自动化检测规则变化
- Cloud Browser 套餐调整
- Muse 自身注册策略变化
因此我更愿意把本文定义成：
一次真实的实验记录。
而不是：
永久有效的注册教程。
本文能够确认的是：
测试日期：2026-09-30
环境：Gmail + Lexmount Cloud Browser
结果：成功进入 Muse 并完成注册
未来如果页面、注册方式或者平台策略发生变化，请以实际情况为准。
十二、回到最开始的问题：为什么 Muse 值得关注
这也是我觉得这次实验比较有意思的地方。
如果 Muse 只是一个“回答更聪明一点的聊天机器人”，其实没有必要折腾这么多。
真正值得观察的是：
Personal Agent 开始逐渐拥有执行权。
从：
AI 给建议
变成：
AI 代表用户执行
当 AI 开始能够操作：
- 浏览器
- 邮件
- 日历
- 电商
- 支付
- 旅行网站
- SaaS 服务
真正重要的问题就不再只是：
“这个模型回答得准不准？”
还会变成：
Agent 有没有执行权限？
执行失败能不能恢复？
用户什么时候需要确认？
哪些操作必须人工批准？
网站允许不允许 Agent 访问？
个人数据存在哪里？
凭据怎么保存？
平台会不会阻止第三方 Agent？
Amazon 和 Muse 之间发生的冲突，其实已经让其中一部分问题提前出现了。
所以我认为 Muse 这次真正值得关注的，并不只是 Meta 发布了一个新产品。
而是：
Personal AI Agent 可能正在从 Demo 和极客工具，变成普通用户真正会使用的互联网入口。
这也是我最终愿意花时间把整个注册、Cloud Browser 和报错流程完整跑一遍的原因。
十三、本次测试总结
最后简单总结：
1. Muse 是 Meta 在 2026-09-08 发布的 Personal AI Agent
2. 上线约两周获得约 280 万次下载，Personal Agent 概念迅速升温
3. Meta 官方发布时说明 Muse 正在美国推出
4. 我最初使用普通浏览器访问时没有顺利跑完整个流程
5. 之后依次测试 Airtap、Browser Use Cloud 和 Lexmount
6. Browser Use Cloud 遇到 ERR_TUNNEL_CONNECTION_FAILED
7. Lexmount 左侧虽然也出现错误，但右侧 Chromium 实际成功打开 Muse
8. 最终使用 Gmail + Lexmount Cloud Browser 完成注册
9. Muse 的额度可以在“设置 → 通用 → 使用情况”查看
10. 邀请码入口也位于这一设置区域
11. 我本次实际完成兑换的邀请码为 U8GIDI
相关地址
Muse 注册页面：
https://muse.ai/join
Lexmount Cloud Browser：
https://browser.lexmount.com/
本次测试邀请码：
U8GIDI
邀请码是否仍然可以兑换，请以自己 Muse 账号中的：
设置 → 通用 → 使用情况
页面为准。
测试时间：2026-09-30
本文记录个人实际测试过程。Muse、Lexmount、邀请码规则和相关网络策略均可能发生变化，请以平台最新页面和规则为准。
转载自 CSDN-专业IT技术社区
