尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

Muse AI 注册实测:为什么最近突然火了,以及我如何用 Gmail + Lexmount Cloud Browser 跑通注册

Muse AI 注册实测:为什么最近突然火了,以及我如何用 Gmail + Lexmount Cloud Browser 跑通注册 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 PhoneBrowser Use CloudLexmount Cloud Browser最后真正完整跑通的是Gmail Lexmount Cloud Browser MuseMuse 注册页面https://muse.ai/joinLexmount Cloud Browserhttps://browser.lexmount.com/这篇文章主要记录最终成功的这条路径以及中间遇到的一个很有意思的问题ERR_TUNNEL_CONNECTION_FAILED二、为什么最后选择 Lexmount Cloud BrowserLexmount 提供的是一个运行在云端的 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 访问 个人数据存在哪里 凭据怎么保存 平台会不会阻止第三方 AgentAmazon 和 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/joinLexmount Cloud Browserhttps://browser.lexmount.com/本次测试邀请码U8GIDI邀请码是否仍然可以兑换请以自己 Muse 账号中的设置 → 通用 → 使用情况页面为准。测试时间2026-09-30本文记录个人实际测试过程。Muse、Lexmount、邀请码规则和相关网络策略均可能发生变化请以平台最新页面和规则为准。
返回列表