都叫 Bot，做的却不是同一件事。Grok Bot 靠多个专业 Bot 分工，Dots 让任务跨时间往前走，Cue 把电话、邮箱和钱包一并交出去，Muse 攒的是你的生活记忆。真正的差别不在功能，在权限模型。

过去的 AI 助手大多停在一个聊天窗口里：你发出问题，它给出答案，下一步仍由你手动接上。最近出现的 Grok Bot、Dots、Cue 和 Muse，虽然都带着 Bot 的名字，做的却不是同一种事。

它们的共同点是拥有一个可以持续工作的执行环境，可以接任务、使用工具、保留部分上下文；差别在于每家对“替人做事”划出的边界不同。Grok Bot 把重点放在多 Bot 协作，Dots 强调跨时间推进任务，Cue 将电话、邮箱和支付纳入执行能力，Muse 则试图围绕个人生活信息建立长期记忆。

开发者和普通用户选 Personal Agent 时，不该只看模型会不会聊天，而要看四个问题：它在哪台机器上执行、能保存什么状态、能触达哪些外部系统、每一步是否需要人类确认。

四家产品其实在回答四个不同的问题

这张表看起来像功能差异，背后却是权限模型的差异。多 Agent 的核心风险是共享状态和重复操作；长期任务的核心风险是任务漂移；电话与钱包的核心风险是对外代表用户；长期记忆的核心风险是隐私和错误画像。

Grok Bot：关键不在“一个更强的 Bot”，而在协作协议

Grok Bot 的设计更接近一个可分工的小团队。每个 Bot 可以有独立名称、职责和长期背景：一个处理邮件，一个管理报销，另一个负责复现软件问题。工程 Bot 能在产品界面复现 Bug、创建问题单，再将修复交给调试 Bot；销售 Bot 则可以更新 CRM 通话记录并准备后续联系草稿。

真正值得注意的是，Bot 之间可以直接传递消息，也可以进入同一个群聊。传统 AI 工作流里，用户往往充当人工消息队列：从模型 A 复制资料，到模型 B 解释上下文，再让模型 C 做审查。Grok Bot 试图把这些交接改成系统内的协作行为。

同账号下的 Bots 共用一台云电脑，文件、浏览器登录状态和应用账号集中在一起；每个 Bot 仍有独立对话与记忆，并通过共享文件和消息进行背景交接。这个结构带来效率，也带来明确的工程问题：

1. 哪个 Bot 有权读写共享文件，如何避免覆盖？
2. 多个 Bot 同时操作同一个 SaaS 页面时，如何防止重复提交？
3. 一个 Bot 的浏览器登录状态是否应自动对其他 Bot 开放？
4. 子任务失败后，谁负责汇总失败原因并决定是否重试？

多 Agent 产品要可用，不能只靠“把几个 Agent 放进群聊”。更重要的是任务幂等、共享状态隔离、结果可追溯，以及对外操作前有清晰的审批点。

Dots：价值在于任务不会因你关机而失去上下文

OpenAI 的 Dots 为每个 Dot 配置云端电脑和浏览器。本机关闭后，云端任务仍能继续推进。这适合处理那些不会在一次对话中结束的事务，例如组织团队出行：人数会变化、预算有上限、场地需要比较、外部回复也不会同时到齐。

Dot 可以在等待参与者确认后更新人数，发现需要重新询价时再询问是否发送请求。它保存已有笔记、已经做出的决定和当前任务进度，因此用户不必每收到一条新消息就重新开对话、重新解释历史背景。

但“云端持续运行”不等于“自动拥有你的所有资源”。要访问本机文件和应用，本机仍要在线，ChatGPT 客户端也要保持运行；云电脑中的浏览器也不会默认继承本机所有登录状态。

这是一个容易被忽略的边界。持续执行的 Agent 需要四类明确输入：任务目标、可访问的数据、可使用的账号、必须回来确认的决策。缺少其中任何一项，长任务很容易退化为无效等待，或在错误的假设上持续推进。

Cue：当 Agent 有了电话、邮箱和钱包，重点从能力转向授权

Manus 的 Cue 给每个 Agent 配置电话、邮箱、钱包和电脑。这个组合意味着 Agent 不再只做研究和整理，还可能成为一个能持续对外联系、接收回复、在预算内付款的执行主体。

对于现实任务，最难的经常不是“找出选项”，而是联系商家、确认需求、下单付款。Cue 的设计就是把任务终点推到这些原来需要用户亲自接手的动作上。电话可以接听并留下摘要，邮箱可以持续询价和确认，钱包可以在设定预算内支付。

这类 Agent 的风险也更高，建议在产品设计中至少落实以下控制：

• 金额分级：低于小额阈值可自动执行，超过阈值必须确认。
• 收件人校验：首次联系、外部域名和敏感地址必须显示预览并等待批准。
• 支付白名单：只允许向已验证商家、已绑定服务和限定类别付款。
• 行动回执：电话、邮件、订单和支付都需要可审计日志、撤销窗口和异常告警。

“在预算内付款”不是一句产品文案，而是一套资金授权模型。预算还要配合支付范围、次数上限、收款方约束和不可逆操作的二次确认，才能真正控制风险。

Muse：个人生活助理的难点是长期记忆，不是推荐一份清单

Meta 的 Muse 从更日常的场景切入：手机里收藏了一条菜谱视频，下周要请朋友吃饭，有朋友不能吃某种食物。信息分散在收藏、聊天和个人记忆中，Muse 试图把它们整理成购物清单、聚餐建议和邀请计划。

它还试图处理长期目标：根据日历与生活安排调整健身计划，持续推进旅行事项，或者发现一笔即将到期的机票抵扣额度并提醒用户选择是否处理。

这类产品的价值，在于帮助用户记住那些“没那么紧急、但错过会损失”的事情；难点则在于它必须理解什么可以记住、什么只应短暂处理、什么必须征求用户确认。长期记忆一旦出错，系统可能把旧偏好当作当前意愿，把私人信息带入不该使用的场景。

曾有关于 Muse 在 Facebook Marketplace 交易中向陌生人提供用户住址的争议讨论。无论具体事件的细节如何，它都说明运行环境隔离只能解决一部分问题：Agent 即使在独立云电脑中执行，也必须准确理解用户授予的操作范围和可披露的信息。

四类 Agent 的底层分界：状态、身份、执行和确认

四款产品最终可能都会向 Personal Agent 靠拢，但当前差别足够明显：

Grok Bot  -> 多个 Agent 怎样协作和交接

Dots      -> 一件任务怎样跨时间持续推进

Cue       -> Agent 怎样代表用户联系和支付

Muse      -> Agent 怎样理解长期生活信息

这也给应用设计提供了一个拆分方法：先定义状态保存在哪，再定义 Agent 以什么身份行动，然后限制它能执行的动作，最后设置哪些节点必须由人确认。没有这四层边界，“替你做事”的 Agent 很容易在便利与失控之间越线。

对于开发者而言，真正需要的不是一个能够无限自主的 Bot，而是一个在正确时间自主、在高风险节点暂停、在所有外部动作后留痕的系统。

怎样选择适合自己的 AI Bot

选择 Grok Bot 类产品的场景

适合已经有明确任务分工、希望把资料收集、代码修复、测试和汇总交给多个 Agent 协同处理的场景。优先评估共享文件、消息路由、并发冲突和审批机制，而不只是 Agent 数量。

选择 Dots 类产品的场景

适合等待外部信息、跨多天推进、期间需要多次补充条件的任务。重点确认任务恢复、长时间等待、账号状态、访问权限和失败后提醒方式。

选择 Cue 类产品的场景

适合需要对外沟通、询价、预约或在有限预算内完成交易的流程。必须先建立预算、收件人、商家、支付类别和人工确认规则。

选择 Muse 类产品的场景

适合日历、待办、生活规划和长期提醒。重点不是让它记住越多越好，而是让用户能查看、编辑、删除和限制它使用哪些记忆。

国内开发者在接入 Claude Code、GPT 或 Gemini 等工具的兼容 API 时，可通过 Code80 统一配置 endpoint；但账号权限、数据隔离、预算上限与审批流程仍需在自己的项目侧落实。

常见问题

四款产品是不是都已经具备完全自主执行能力？

不是。它们都在向持续执行靠近，但自主范围取决于具体权限、云端环境、任务条件和用户确认。尤其涉及外部消息、支付和隐私信息时，仍需要明确授权。

云端电脑是否会自动拥有本机所有数据和登录状态？

不会。Dots 的云端环境可以在本机关闭后继续工作，但访问本机文件和应用仍需要本机在线，云端浏览器也不会默认继承本机所有登录状态。

多 Agent 共用文件和账号会有什么风险？

可能出现文件覆盖、重复提交、权限扩散和错误上下文传递。应通过任务锁、文件版本、最小权限、操作日志和审批节点降低风险。

为什么支付能力需要比普通聊天更严格的控制？

支付一旦完成通常不可逆。预算上限只能控制金额，还需要限制收款方、商品类别、支付次数和异常条件，并为高风险动作增加二次确认。

Personal Agent 的长期记忆如何避免侵犯隐私？

用户应该能清楚查看记忆来源、编辑或删除条目、限制记忆适用范围，并为地址、健康、财务等敏感信息设置默认不记忆或必须确认的规则。