持久化助手的同质化困惑与本质差异
Dots、Muse和Grok Bot近期频繁出现在视野中，它们同属AI个人助手类别。与过去的聊天机器人不同，这些助手的显著特征是“持久性”（persistent）。即使关闭窗口或关机，它们仍在云端持续工作并在完成后回归。这种特性使得三者都在竞相处理邮件、搜索信息和预订服务，导致外观和功能日益相似，让用户难以抉择。然而，真正的区别隐藏在“究竟什么在保持持久”这一核心问题上。虽然市面上许多对比视频忽略了Claude Code Projects，但一旦深入其后端设置，就能清晰看到三者在持久化实体上的根本分歧。这种差异不仅体现在界面交互上，更决定了任务执行的组织逻辑和最终结果。
Muse与Dots：以“分身”为核心的单人持久化
Muse作为作者正在使用的工具，其系统文件结构（如agent.md, memory.md）与开源OpenCloud一致。在user.md中明确写道：“You are not a chatbot; you are becoming someone.” 这意味着Muse维持的是一个特定的“分身”（alter ego），记忆随该人格延续，且文件可直接查看和编辑。Open的Dots也属于此类，每个账户拥有一个Dot，从聊天记忆开始，在云端计算机上独立运行。Anthropic刚发布的CloudDoIt同样归入此类，它拥有内置浏览器和云计算机，维持单一连续对话并继承用户记忆。CloudDoIt能定期检查邮件日历，仅在出现事项时联系用户，且在执行转账、删除等敏感操作前需人工审批。由于目前仅在美国开放等待列表，CloudDoIt被排除在本次测试之外。这三者的共同点是：持久化的是一个人格化的分身。
Grok Bot：以“同事团队”为架构的多智能体协作
与单人分身不同，Grok Bot的试用版展示了两个独立的Bot：“Mao-Tao”和“AI Radar”。每个Bot拥有独立的首选项、角色及聊天页面，构成了一个同事团队（Colleagues）。在AI Radar的对话界面顶部明确标注“Message Source: Mao-Tao”，显示Bot之间存在内部通信记录并互相传递任务。这种架构意味着Grok Bot持久化的不是单一意识，而是一个具备分工协作能力的团队实体。当任务下达时，系统倾向于通过组内协调来分配工作，而非由单一智能体全权处理。这种多Agent协作模式在逻辑上更接近人类职场中的项目分工，但也带来了协调成本增加和流程断裂的风险。
Claude Code Projects：以“目标”为驱动的临时线程执行
Claude Code Projects展示了另一种持久化逻辑。在演示中，作者创建了一个长期项目并在目标字段仅写入一句话。在项目内部，用户对话的对象是“协调员”，但实际执行工作的是由协调员分发的线程（thread）。任务完成后，该线程结束并被丢弃，但项目记忆和产出物保留在项目内。因此，Projects持久化的核心是目标或任务（Project/Mission）。这种机制将“记忆/人格”与“执行过程”分离，执行是临时的、一次性的，而成果和上下文则是持久的。这与Muse/Dots的持续人格交互以及Grok Bot的团队常驻模式形成了鲜明对比，体现了以结果为导向的任务驱动型AI架构。
同一任务下的执行效率与质量对比测试
为了验证上述三种持久化实体的实际后果，作者对Muse、Grok Bot和Claude Code Projects进行了控制变量测试。任务指令完全一致：“Prepare a research package for the next video, find three public videos comparing persistent agents. Organize the core points into a document.” 由于Claude与Muse同属“分身”类且组织方式均为一对一，此前已验证过其相似性，故本次仅展示Muse的表现。在Muse端，作者启动新项目并发送请求，无需任何催促（nudge），Muse一次性完成工作并以文档形式返回。结果不仅清晰列出三个视频的核心观点及参考价值，还包含综合对比表，并主动标记过时信息。相比之下，Grok Bot的过程截然不同：作者组建群组聊天，Mao-Tao协调并指派AI Radar查找视频。约一分钟后，AI Radar找到三个视频并发布在群内。随后协调者Mao-Tao未接手后续工作，群组陷入停滞。作者等待数分钟后不得不再次催促要求总结字幕，整个过程耗时约18分钟。最终Grok Bot在群内提供可读文本包并私发PDF，但效率远低于Muse的直接交付。
多智能体协作与单点执行的效率对比
在文档生成任务的测试中，不同工具展现了截然不同的工作流。CloudCode Projects 采用了类似“同事协作”的模式：协调员收到指令后立即启动编译，并自动分派专门的角色执行。该角色列出四步检查清单逐项推进。当遇到YouTube访问速率限制时，它并未停滞等待人工干预，而是记录日志、切换路径继续收集数据。仅用约三分钟，四项任务全部标记完成，最终文档直接保存至项目库中可供查阅。相比之下，Dots 作为单一大模型代理最为省心但缺乏灵活性。它从头到尾由单一实体处理，虽然无需用户操心交接问题，但也意味着无法像多智能体那样分工协作。如果这种单点执行出现失误或需要调整，用户往往只能被动等待结果。
群组聊天与私密对话中的审批机制差异
在邮件发送测试中，Grok Bot (GB) 的权限控制逻辑最为独特且严格。当在群组聊天中请求发送指定发件人的邮件时，GB 首先指出该地址不可用，随后主动提供草稿卡片。然而，尽管用户在群组中点击了“发送”按钮，邮件仍未发出。GB 回复称安全审批无法在群组中完成，要求用户切换至私密对话窗口。这一现象并非权限缺失，而是其设计规则使然：Grok Bot 规定审批必须由用户本人在私密聊天中亲自给出。官方文档明确指出，使用内置邮件功能时每条消息都需手动点击确认，且群组聊天中不会出现审批卡片。因此，用户在私密窗口重新发起请求时，系统再次弹出确认卡，验证了这一机制。所有归属于同一账户的机器人共享同一个持久化云计算机，官方FAQ甚至建议不要将单独的机器人生视为安全边界。
决策权归属与错误回滚能力的深度解析
不同工具在“谁掌握最终决定权”这一核心问题上给出了不同的答案。Notion 默认将决策权保留给用户，在连接Gmail后发送前会弹出包含“发送”、“始终允许此收件人”和“不发送”选项的审批卡片，且所有代理的网络流量受独立哨兵监管。OpenAI 的 Dots 则表现出极高的主动性，在测试中直接回复“已发送并验证”，全程无需任何审批或确认步骤。若用户希望限制其直接行动，必须预先在“自定义规则”中设定允许、禁止或需审批的操作项。而在错误处理与可见性方面，CloudCode Projects 展现了更强的工程化优势。它会在日志中报告YouTube流媒体问题并自动重试，且若连接代码仓库，所有更改将以PR形式提交供人工审批。对于产生的文档或代码，若存入Git仓库可实现版本回滚；而Grok Bot 发送的损坏PDF无法直接恢复，用户只能重新请求生成。这种差异凸显了项目型工具在后台处理研究文档时，通过线程隔离和版本控制提供了更高的可追溯性与安全性。
四款AI助手的订阅成本与计费逻辑深度解析
在明确了各助手的工作机制后，定价策略是用户做出最终选择的关键考量因素。根据官方条款，这四款产品的收费模式存在显著差异。首先看Dots（文中提及的“dot”），其基础门槛较高，需要P级订阅起步，月费为100美元。值得注意的是，Dots的计费逻辑具有特殊性：与D（即Grok Bot中的对话功能）聊天不计入配额，只有分配给Codex或W的任务才会被记录在案。相比之下，Muse（文中提及的“MILS”）提供了更灵活的层级选择，设有免费层和付费层，付费版分为20美元和100美元两档，主要区别在于每周的配额限制。这种分层设计使得预算有限的用户也能获得基础服务。
“For that, you need a P subscription, starting at $ 100 per month. It includes the first dot; chatting with D doesn't count against your quota, only tasks assigned to Codex or W are recorded.”
Grok Bot（文中提及的“GB”）的情况则更为复杂，截至10月12日已合并入统一的X订阅体系。用户至少需要选择30美元 tier 的套餐，且配额与Claude Code Projects共享一个每周池。这里有一个重要的细节：群聊中的每一次回复都计入使用量，这意味着高频互动会快速消耗配额。这种共享池机制要求用户更精细地管理自己的使用额度，避免意外超支。
Claude Code Projects 的配额消耗与独特限制
对于Claude Code Projects（文中提及的“CloudCodeProjects”），其计费方式与前几者截然不同。它不单独收费，而是包含在P和Max订阅中，但消耗的Token会从同一配额池中扣除。由于该项目涉及复杂的后台任务，其消耗速度肯定比单轮对话快得多。官方设定了明确的使用上限：每天限制200个新的Stripes（任务/步骤）。此外，Anthropic的“Do It”功能（文中提及的“CloudDoIt”）目前处于预览期，免费使用且与其他Claude功能共享P/Max配额。然而，后台搜索和大任务同样计入用量，这意味着即使是免费预览阶段，用户也需警惕配额耗尽的风险。
“As for CloudCodeProjects, it isn't charged separately in P and Max, but the tokens they consume are deducted from the same quota pool... with a limit of 200 new Stripes per day.”
基于场景的选型指南：从日常琐事到长期项目
理清了费用后，如何选择取决于具体的使用场景。如果用户需要处理日常琐事并希望有人代为跑腿，那么数字分身是最佳选择。推荐首选Muse（M），或者Dots（D）。如果用户希望观察Opic的Claude表现，可以等待Oud的公开发布版。这类场景强调自动化和日常辅助，对深度协作要求不高。
“If you need help with daily chores and want someone to run errands for you, hand it off to your digital twin—choose M, or maybe D... If you have several long-term business lines and want roles divided with mutual coordination...”
对于拥有多条长期业务线且需要角色分工、相互协调的用户，Grok Bot（GB）是更合适的选择。在这种模式下，用户扮演管理者角色，负责推动进度和监督交接。这本质上是一个团队协作场景，适合需要多人（多Agent）协同完成复杂流程的情况。而对于有明确目标、需要交付验收、修订以及版本回滚能力的任务，则应委托给项目制工具。选择Claude Code Projects（CloudCodeProjects）。这类场景强调结果的确定性和可追溯性，适合单次交付型任务。
核心结论：Claude Code Projects并非Dots的直接竞品
回到最初的问题：Claude Code Projects是否算作第四种竞争者？ 答案是否定的。虽然它具备持久性——关闭窗口后仍在后台工作，但它托管的不是“人”（如Dots）或“团队”（如Grok Bot），而是一个具体的目标。因此，它从一开始就不在与Dots相同的赛道竞争。真正与Dots形成直接竞争关系的是Anthropic的“Do It”功能，这意味着Anthropic同时提供了代理（Alias）和项目（Project）两种形态。未来的Agent系列将继续探讨如何将这些助手整合进日常工作流，深入解析其背后的具体概念。
“It belongs to the same category, because it also stays persistent... But what it hosts isn't a person. Nor is it a team. It's a goal...”
结论
测试证实，持久化实体的本质差异直接决定执行效率与安全性。Muse凭借单一分身架构实现无催促的高效交付，适合日常琐事自动化；Grok Bot的多智能体协作虽具分工潜力，但存在协调断裂与审批受限的短板；Claude Code Projects以目标驱动分离记忆与执行，通过版本控制提供高可追溯性。定价上Dots门槛最高且计费特殊，Grok Bot共享配额需精细管理。
核心结论是Claude Code Projects并非Dots的直接竞品，前者托管“目标”而非人格或团队。Anthropic同时提供代理与项目形态覆盖不同场景：日常跑腿选Muse/Dots，长期多线协作选Grok Bot，需交付验收及回滚能力的项目则委托Claude Code Projects。用户应根据任务性质而非单纯的功能相似性进行选型，明确各工具在决策权归属与错误处理上的机制差异。