OpenAI Dots 初体验：既有惊喜也有局限

本周早些时候，我参加了 OpenAI 的年度 DevDay 大会，会上该公司发布了 Dots——一个驻留在 ChatGPT 应用内的个人智能体。我设置好了我的 Dot，并给它取名为 Puck，取自莎士比亚《仲夏夜之梦》中那个淘气的小精灵。从那以后，我发现自己越来越频繁地使用 Puck。它仍然存在一些粗糙之处，但我想分享一下哪些功能好用、哪些不好用，以及 Dots 与 ChatGPT 和 Codex 中已有功能的不同之处。

Dots 是持久的云端智能体，在你允许后，它们可以使用你已连接到 ChatGPT 的插件和其他工具。你的 Dot 拥有一台专属的虚拟 Linux 计算机来协助你完成工作。起初，你的 Dot（以一个你可以自定义的彩色角色呈现）无法访问任何其他内容。然而，当你交给 Dot 的任务需要访问其他工具时，它会请求你授予相应权限。这种与 Dot 的初次交互节奏处理得非常好。这些请求感觉自然，让我在扩大 Puck 的权限时感到舒适，而不会觉得被打扰。

Dots 可在移动端和桌面端使用，而且由于它们基于云端，你的 Dot 的聊天记录始终在设备间同步。但云端智能体也有其缺点。开箱即用时，你的 Dot 无法访问你电脑上的文件和应用程序。这个问题很容易解决：点击你的 Dot 并授予它访问你 Mac 的权限，这样它就可以在自己的虚拟机之外同时使用这台 Mac。与 Codex 的 Remote 功能一样，将远程 Mac 与你的 Dot 配合使用时，需要在这台 Mac 上也打开 ChatGPT 应用。

一个很大的限制是，你一次只能连接一台 Mac。我的桌上放着一台 Mac Studio 用于工作，但同时还有两台 Mac mini 运行着各种脚本和工作流。然而，要连接这两台 mini 中的任何一台，我首先必须在那台 Mac mini 上授予 Dot 使用该 Mac 的权限，当你在远程工作时，这远非理想。当然，当我在咖啡店里用手提电脑打字时，很容易就能授予我的 Dot 使用手提电脑的权限，但一旦我想让它更新我 Mac mini 服务器上的脚本，我就得先远程连接到那台 mini，授权 Dot 访问它，然后切换回我的手提电脑。如果我的 Wi-Fi 信号不好，这就不一定可行了。我希望看到 Dots 能像 Meta 的 Muses 那样成为独立的 Tailscale 实体，这样就能解决这个限制。

Dots 的第二个限制是你只能拥有一个。如果你整天使用它，你的对话会变得很长，你会发现自己不断在历史记录中翻找早些时候从 Dot 那里获得的某个内容。搜索功能不适用于你的 Dot 线程。此外，OpenAI 可能会告诉你，你只需要一个 Dot 就够了，因为它基于 Astra——一个强大的通用模型，可以取代对专门智能体的需求。然而，这只是解决了你为什么要多个 Dots 的其中一个方面。你可能希望你的 Dot 并行运行多个大型项目，并且能够监控它们的进度，而不必与你的 Dot 来回交流，让多个主题交织在一起。或者，你可能只是希望把个人任务和工作任务，或不同项目分隔开来，保持条理清晰。

好消息是，OpenAI 非常清楚 Grok Bot 多智能体方法的受欢迎程度，并表示未来计划推出多 Dot 方案。然而，由于 OpenAI 拥有庞大的用户群，而 Dots 目前并不计入订阅的使用量，我离开时的印象是，这一限制更多源于 OpenAI 采取保守策略以避免服务器容量耗尽，而非在理念上反对 Dot 团队。

我发现应对单一 Dot 问题的最佳策略是，当一个想法变成一个完整的项目时，把任务转移到 Codex 线程中，让你的 Dot 负责管理它。我已经这样做过几次，这是减少主 Dot 线程流量的可靠方法。第二种方法是把你 Dot 生成的某些书面成果转存到一个 Space 中——Space 有点像简陋的 Notion 文档，你可以继续就文档相关内容向 ChatGPT 提问，并与同事协作。唯一的缺点是，根据我的体验，Spaces 目前还有一些小毛病。

我更希望看到的是 Dots 取代 Projects。与其采用一整套线程文件夹体系，不如让一个 Dot 接管一个项目，并将代码仓库、文档、Spaces 和其他资源与之关联，让你主控的 Dot 协调多个 Dots 并行工作。那个统筹的 Dot 还应该能够在各 Dot 集群之间充当信使，让一组 Dots 能把他们在某个项目上的成果分享给面临类似问题的另一组 Dots。

不过就目前而言，你的 Dot 是孤立工作的，承担着你所有大大小小的请求。它没有可选的模型、可指定的推理力度或可调整的速度，只需让你的 Dot 做某事，它就会开始工作。这是一种应对日常任务的简单而有吸引力的方式，但对于大型项目来说并不理想。

如前所述，我已经开始把较大的项目从我的 Dot 线程中转移出去。这正是 Dots 推出之前我的工作方式。我有一些大型项目，各自拥有独立的文件夹、资源和线程。然而，我养成了在一个我创建的用于日常工作的“运营”项目中启动每日线程的习惯。这个“运营”项目存储着我做事方式的记忆，并能访问包含日程、追踪和其他参考资料在内的 Notion 数据库。

如果这听起来很像我的 Dot 能做到的事，那是因为确实如此。然而其中的差异是有意义的。当我在 Codex 的“运营”项目中创建新线程时，除非我告诉它或把它指向那个线程或能提供所需上下文的工具，否则新线程完全不知道上一个线程里有什么。此外，尽管 Codex 的 Remote 功能现在比几个月前好多了，但我仍然发现自己会置顶最新的运营线程，因为它仍然可能淹没在 Codex Remote 视图中的众多线程里。

相比之下，Puck 驻留在云端，只有一个始终同步的线程，并且可以访问我所有的工具。这意味着它能够将我的偏好和进行中工作的有用上下文从一天带到下一天，而且由于它就在侧边栏“新聊天”的正下方，很容易找到。我也很欣赏这样一个事实：我不必考虑使用哪个模型或推理级别。那只是额外的心理负担，当你意识到自己不小心让 Astra 用“最大”推理力度去加几个数字时，你会懊恼不已。

因此，总的来说，我对 Dots 的体验是好的，但也有保留意见。我希望我的 Dot 不仅能统筹 Codex 项目，还能在我无需干预的情况下在多个 Mac 之间工作，让我能够在 Mac Studio 上开发脚本，并无缝部署到我的服务器上。我还希望创建具有特定工具集、权限、专业领域和能力的专家 Dot，它们可以被派去并行处理多个项目，由我的主 Dot 统筹一切。

想象一下，像在 RPG 中创建一队英雄那样组建一个 Dot 团队，平衡他们的能力以适应你的工作内容。不过就目前而言，我满足于让我的 Dot 设置任务、查看邮件、协调我的 Codex 项目、做轻量研究以及执行其他小任务，尤其是因为这样做目前不会计入我的 OpenAI 订阅用量（除非你的 Dot 启动了 Codex 或 Work 会话），从而节省我的 token 配额，用于更大的项目。