Dots、Muse 和 Grok Bot——你最近可能听过这三个名字。它们属于同一类别：AI 个人助理。与过去的聊天机器人不同，它们是持久存在的；它们始终在线。即使你关闭窗口或关闭电脑，它们也会在云端继续为你工作，完成后会回来找你。而这正是问题所在。这三者都是个人助理，都具有持久性，并且都在竞相处理你的邮件、搜索信息和预订服务。环顾四周，它们看起来越来越相似，我不知道该用哪一个。我自己也有同样的困惑，然后我看到了 Claude Code Projects，这让情况变得更加混乱。它与这些其他服务有许多相似之处，那么它算作第四个吗？
在这一集中，我将使用相同的任务和测试邮件来检查这些服务。它们的差异实际上隐藏在一个问题中：究竟什么是持久存在的？嘿，大家好，欢迎回来。我看过很多比较视频，几乎没有人将 Claude Code Projects 纳入他们的评测中。有些人甚至询问 Anthropic 何时会发布一个，而截至今天，他们确实发布了名为 Claude Computer Use（注：原文误拼为 CloudDoIt/CloudCodeProject，结合语境指 Anthropic 的 Computer Use 功能或类似项目）的一个。但在此之前，Claude Code Projects 实际上已经存在了。如果你只关注它们是否能自动工作，它们确实看起来越来越相似。但一旦你打开它们的后端设置，“真正持久存在”的差异就会立即显现出来。
让我们首先看看我正在使用的 Muse（注：原文误拼为 Mats，结合语境指 Mus）。打开其数据库中的系统文件，你会看到一个系统文档列表。像 agent.md、memory.md 和 user.md 这样的文件——这种结构与开源的 OpenClaw（注：原文误拼为 OpenCloud，结合语境指类似框架）完全相同。当你打开 user.md 文件时，第一行写着：“你不是一个聊天机器人；你正在成为某个人。”这意味着你不只是一个聊天机器人，而是在成为一个特定的人。记忆作为那个人跟随你，文件可以直接查看、编辑和下载。因此，在 Muse 中持久存在的是一个“分身”（alter ego），而 OpenAI 的 Dots 也属于这一类别。每个账户获得一个 Dot，从你的聊天记忆开始。当你关闭窗口时，它会在自己的云端计算机上继续为你跑腿；它所保持持久存在的也是一个分身。
而 Anthropic 刚刚发布的 Claude Computer Use（注：原文误拼为 CloudDoIt）也属于这一类别。它拥有自己的云端计算机、内置浏览器，并与你保持单一的连续对话，继承了你已经在云中拥有的记忆和关联账户。它可以每隔几小时检查你的电子邮件、日历和其他账户，并且只有在出现问题时才会来找你。在发送消息、付款、转账、删除文件或其他操作之前，它会原样显示预期的行动以供你批准。购买股票或在账户间转账，即使你已批准，它也不会执行。目前仅在美国通过等待名单提供，所以我还无法使用它。因此，将其排除在以下测试之外。
现在看看我正在使用的 Grok Bot 的试用版；打开其列表显示的不是一个助理，而是两个名为机器人的助手。一个叫“Mao-Tao”，另一个叫“AI Radar”。它们各自记住自己的偏好和角色，每个机器人都有自己独立的聊天页面。更直观的是，如果你点击进入 AI Radar 对话，顶部明确写着“消息来源：Mao-Tao”。它们之间有各自的通信记录，并将任务传递给对方。因此，Grok Bot 中存在的不仅仅是一个人，而是一组同事团队。接下来，让我们切换到 Claude Code Projects。我专门创建了一个新的长期项目用于演示，并在目标字段中只写了一句话。在项目内部，我与之交谈的是协调员，但实际工作是它分发的线程（thread）。任务完成后，线程结束并被丢弃。然而，项目的记忆和创建的事物保留在项目内。因此，Projects 托管的是一个目标，或者说是任务（mission）。
在这里，我们获得了三个术语：分身、同事和项目。最初的困惑有了初步的答案，但仅靠这三个词不足以做出选择。真的将任务交给这三种类型的持久代理会有什么后果？为了清楚地看到这种后果，我进行了第一次比较测试。我向 Muse、Grok Bot 和 Claude Code Projects 发送了完全相同的指令，一个字都没有改。唯一的变量是接收任务的三个实体。任务只有一句话：“为下一个视频准备一个研究包，找到三个比较持久代理的公开视频。”“将核心要点整理成一份文档。”我在这里声明一点：Claude（模型）这次没有重新运行这个研究包任务。因为它和 Muse 属于同一“分身”类别，而在上一集中，我已经使用相同的提示词，一个字未改，让 Muse 和 Dots 创建了相同的手绘动画。在它们的组织方式上，它们都是一对一的；你告诉它，它就自己运行。因此，对于“分身”组，我们将直接看 Muse 的表现。
在 Muse 那边，我启动了一个新的侧边项目并发送了请求。我不需要催促他一次；他一次性完成了工作，并以 Muse 文档的形式交还给我。它不仅清楚地列出了三个视频的核心要点及其对本集的参考价值，还包括一个全面的比较表。更有用的是，它主动标记了哪些信息已过时，并添加了一个具体的注释，指出找到的三个视频都缺乏对 Bot 的深入测试。现在在 Grok Bot 那边，过程完全不同。每个机器人实际上都可以单独聊天，但它最大的特点是一组机器人协同工作。所以这次我专门设置了一个群聊，拉入 Mao-Tao 和其他人，并给了他们相同的任务。Mao-Tao 很快回复：“我来协调。”就在群里，它指派 A-Radar 去寻找视频。大约一分钟后，A-Radar 找到了三个视频并发布在群里。但在那之后，负责协调的 Mao-Tao 没有接手完成工作，群聊就停滞在那里了。
等待了几分钟没有任何进展后，我不得不催促他们，告诉他们视频已准备好并要求总结文档，然后它们才开始总结字幕。整个过程花了大约 18 分钟。最终，他们在群里提供了一份可读的文本信息包，但通过私人发送给我的 PDF 文件
在应用中打开时显示“无法读取文件”，无论尝试多少次都如此。接着测试 CloudCode Projects，我在已设置好的演示项目聊天中发送了相同的请求。协调者立即回复：“明白，马上开始编译。”随后它自动调度了一个专门的侧边栏，列出了四步检查清单并逐项处理。
中途它遇到了 YouTube 访问速率限制，但它没有停下来等待我干预；而是在进度日志中记录了情况，切换路径并继续收集数据。大约三分钟后，所有四项都标记为完成，生成的文档直接保存到了项目库中。你可以打开并滚动浏览它。运行完这个相同任务后，这三个工具的结果非常具有说明性：单个头像最让人省心；你给出指令它独自处理，但从头到尾只有一个实体。
而一组同事实际上会互相交接任务。但如果交接过程中掉链子，你就得跟进。你最终不得不成为群聊中的管理者。对于项目而言，它将任务分解为线程，在三分钟内就能将一份准备好的文档放入你的文件供参考。但一旦线程完成任务，它们就立刻消失；这些文件和项目并不是留下来与你聊天的助手，但它们确实在后台处理研究和文档工作。
如果你真的想选择一个为你工作的助手，最重要的是当事情可能出错时它的反应；例如，当你发送电子邮件或更改内容时，谁真正拥有决策权？这让我们回到了之前提到的测试邮件；这是同一封测试邮件，收件人是我自己的另一个邮箱，发件人是我要指定的地址，唯一的变量是哪个平台负责发送。
首先看 Notion；在开始阶段，在我连接 Gmail 之前，它不会直接发送，而是弹出一个卡片要求链接账户。一旦我链接了 Gmail 并再次请求发送，它弹出了一个审批卡片：是否允许“小桃子”发送此邮件？它清楚地说明了发件人，下方有三个按钮：“发送”、“始终允许此收件人”和“不发送”。所以我点击了
“发送”，邮件这才发出。你看，它默认将决策权留给我，但如果你信任某个收件人，卡片也提供了长期信任他们的选项。此外，在官方设计中，代理的所有出站网络流量都由独立的哨兵管理。代理仅持有代理凭证，甚至每笔支付都需要人类审批；现在让我们看看 GB（Grok Bot）。它的反应最令人惊讶。
我在群聊中要求它发送这封邮件，它首先告诉我指定的发件人地址无法使用。只能使用机器人自己的电子邮件地址。然后它主动提出为我起草一张卡片以供查看；当卡片弹出后，我点击了上面的“发送”按钮，但它回复说在群聊中无法完成发送邮件所需的安全审批。刚才什么都没发出去，它要求我在私聊中与它沟通。
于是我切换到私人聊天窗口并发送消息以发送测试邮件；在私聊中，它没有再次弹出卡片，消息通过了，邮件也发出了。乍一看似乎它们没给你审批权，但事实并非如此。后来我在私聊中让它从头发送另一封邮件时，它仍然弹出了“发送”卡片，等待我点击确认。官方文档实际上说得很清楚：使用 GB 的内置电子邮件功能时，每条消息都需要你手动点击审批。
在群聊中发送消息不算数，而且审批卡片也不会出现在群聊天中；我刚才只是在群里点击了它。由于我无法在群聊中进行审批，所以它要求我去私聊中发送这封已经批准的邮件。Grok Bot 的规则是，审批只能由你本人在私聊中给出。此外，你需要知道的是，你账户下的所有机器人实际上共享同一个持久化的云计算机；官方 FAQ 甚至指出不要将单独的机器人视为安全边界。
使用 OpenAI 的 Dots，我要求它使用特定发件人发送这封测试邮件，它回复说：“让我确认一下是否可以从该地址发送”，然后立即回复“已发送并验证”，在整个过程中没有任何审批或确认步骤就发出了邮件。如果你不希望它如此直接地行动，你必须进入其“自定义规则”中预先设置允许、禁止或需要审批的内容。
涉及账户设置或共享信息的操作将经过自动审查，一次批准并不意味着长期授权。由于 CloudCode Projects 之前的数据包任务不需要发送外部邮件，这次没有出现审批卡片。按设计，线程默认以自动模式运行。一旦遇到需要批准的操作，它将停止在该线程中并等待你。如果连接了代码仓库，它也将受限于仓库权限规则，任何更改都将作为 PR 提交以供人类审批。
因此，纵观整个过程，一切归结为决策权：机器人要么在行动前询问你，要么你在自定义规则和“始终允许”设置中预先确定规则。第二点是审批必须由你本人在私聊中给出，并且由于它们共享一个云计算机，因此没有独立的安全边界；项目将审批保留在特定线程中。保持输出在仓库内。现在，让我们进一步探讨这一点——如果它真的犯了错误，我们能回滚吗？当发生错误时，你甚至能看到它吗？
如果是已经发送的邮件，四者都是一样的；它们都无法撤回。但如果比较它们为同一任务生成的工作成果，那就是完全不同的故事了。P（Projects）生成并提交到 Git 仓库的文档和代码，如果出现问题允许你恢复到以前的版本。但如果 Gockbot（Grok Bot）发给我的损坏 PDF 打不开，我必须要求它再发一份副本。
遇到问题时，可见性也不同。Projects 内部会在日志中报告 YouTube 流媒体问题并自行重试，而在我等待去推动进展的几分钟里……
Grok Bot 的屏幕刚刚显示“您离开时，屏幕已暂停。”好了，我们已经了解了它们的工作原理以及如何处理质量控制。最后，让我们看看费用情况，根据官方条款，这四种工具是如何收费的。为此，您需要 P 订阅，每月起步价为 100 美元。其中包括第一个点；与 D 聊天不计入您的配额，只有分配给 Codex 或 W 的任务才会被记录。MILS（Muse）有免费和付费层级，分别为每月 20 美元和 100 美元，区别在于每周的配额限制。截至 10 月 12 日，GB（Grok Bot）已合并到统一的 X 订阅中，至少需要 30 美元的层级。配额与 GCER（Grok Code Enterprise/Runner）共享在一个每周池中，群组中的每次回复都计入您的使用量。
至于 Cloud Code Projects（Claude Code 项目），它在 P 和 Max 层级中不单独收费，但它们消耗的令牌会从同一个配额池中扣除。这肯定比单轮聊天消耗得更快，每天限制为 200 个新 Stripes（Stripe 令牌单位）。此外，Cloud Do It（Claude Code）在预览期间是免费的，并与其他 Claude 功能共享相同的 P/Max 配额，后台搜索和大任务都计入使用量。好了，说了这么多，从一开始关于该选择哪一个的困惑现在应该很容易解决了。
如果您需要帮助处理日常琐事，并希望有人为您跑腿办事，请交给您的数字分身——选择 M（Muse），或者 D（Dots），也可以等待 Oud 的公开发布，看看 Opic's Cloud（Claude Code）的表现如何。如果您有几条长期业务线，希望角色分工明确、相互协调，并且愿意充当团队中的经理来推动进度和监督交接，那么将其分配给同事团队——即选择 GB（Grok Bot）。
但如果您手头有一个具体目标，需要交付、验收、修订以及回滚到之前版本的能力，那么将其委托给一个项目并选择 Cloud Code Projects。所以回到最初的问题：Cloud Code Projects 算作第四个工具吗？它属于同一类别，因为它也保持持久运行。即使您关闭窗口后它仍在继续工作，但它托管的不是一个人，也不是一个团队，而是一个目标。
它从一开始就不在与 D（Dots）相同的领域竞争。真正与 D 竞争的是 Anthropic 的“Do It”（即 Claude Code），这意味着 Anthropic 现在同时拥有这两者：一个用于别名/代理，另一个用于项目。好了，在我们接下来的智能体系列中，我们将继续讨论如何将这些助手集成到我们的日常工作流程中，以及它们涉及的具体概念。好了，今天就到这里，我们下期再见。