OpenAI dots 实测：云端智能体开始交付文件

OpenAI dots 实测：云端智能体开始交付文件日报图文

判断一款 Agent 是否真的能干活，我现在只看一件事：它能不能在对话结束后继续推进任务，并把文件、链接或可运行结果交回来。能回答问题已经很常见，能接管一台持续在线的云电脑，同时调用工作软件、开发工具和外部服务，才接近“数字同事”的形态。

AI超元域这期 12 分钟实测，把 OpenAI dots 放进了一个相当苛刻的场景：语音查 Notion、整理论文、创建定时任务、连接 Slack 和 Supabase，还让两个开发任务并行运行。演示里有成功交付，也留下了不少问号。看完后，我最在意的变化很具体：Agent 的竞争正在从回答质量移向执行环境、任务持续性和交付验证。

来源说明：本文根据 AI超元域发布的视频《OpenAI dots 深度实测》、视频简介、章节信息和本地 Whisper 转录整理。产品名称、模型名称、机器配置及功能表现均按视频演示转述；由于公开检索服务在整理时不可用，文中不把演示口径扩写成独立官方结论。

dots 想解决的是“对话结束以后怎么办”

视频把 dots 描述为 ChatGPT 里的常驻 Agent，由 GPT-6 Astra 驱动，定位接近一位以工作为中心、可以后台运行的同事。演示所用云电脑有 10GB 内存和 32GB 硬盘，并预装或允许安装 Blender、FreeCAD 一类生产力软件。

这些参数本身没有太多故事。真正有用的是常驻状态。

普通聊天机器人依赖当前会话。你关掉页面，任务往往也停了。dots 在演示中保留自己的头像、历史记忆、连接器和云端桌面，可以继续处理已经分派的目标。用户回来的时候，理想结果应当是一份笔记、一个项目文件、一张渲染图，或者一个能打开的应用。

视频开头先创建了一个名为 Talos 的助手。Talos 是希腊神话中的青铜守卫，作者让助手自己设计形象，再把静态青铜机器人加工成动态头像。这个片段看似偏装饰，却展示了产品思路：每个助手都有可辨识的身份，也有一套长期保留的工作上下文。

作者随后询问自己擅长哪些技术栈。dots 根据此前在 ChatGPT 和 Codex 中留下的记录作答。准确度很难仅凭视频判断，但功能方向清楚：记忆不只用来寒暄，它要帮助 Agent 省掉重复说明背景的成本。

语音入口的价值，在于边说边派单

演示里最顺滑的一段发生在语音通话中。作者要求 dots 从 Notion 里查找与“微调大模型”有关的笔记。助手先复述目标，再检索相关页面，随后把一篇关于 AQLM、LoRA 或量化方法的资料整理成新笔记，写回 Notion，并承诺返回页面链接。

转录在论文名和部分术语上有明显误识别，无法据此还原完整技术内容。但助手在过程中主动补了一条限定：某项提速结论来自作者测试所用的 V100 环境；按量化误差挑选层的方案，在对照实验里没有超过同预算的随机选择。这个细节比一段漂亮摘要更有价值。它说明 Agent 至少尝试保留实验边界，没有把论文结论写成普遍规律。

语音并没有创造新的推理能力，它缩短了派单距离。人可以在走路或开会间隙说出任务，Agent 转去检索、整理、写回。真正影响体验的环节有四个：

能否找到正确的数据源；
能否理解“整理后写回”的动作链；
能否在执行中保留限定条件；
能否给出可点击、可核验的交付物。

前两项决定任务能不能启动，后两项决定结果敢不敢用。

Slack、Notion 和 Supabase 让助手进入现有工作流

视频展示了 Slack 连接。安装后，用户可以直接在 Slack 中询问 Talos 能做什么，并在那里下发生成内容、开发、修 bug、跑测试、资料查找、笔记整理和日程跟进等任务。

把 Agent 接入聊天工具不稀奇，难点是身份、权限和上下文能否保持一致。一个团队不会为了 AI 重建全部沟通习惯。Agent 必须进入大家已经使用的 Slack、Notion、GitHub 和数据库，理解谁在提需求，也要知道哪些内容可以读取、哪些操作需要确认。

Supabase 连接演示也说明了同一件事。作者在插件页面安装连接器，完成网页授权，再让 dots 查看数据库。视频转录在这段缺失较多，因此无法确认它读取了哪些表、执行了什么查询。能确认的是授权链已经打通，Agent 可以在云桌面与 SaaS 连接器之间切换。

这里需要保持一点克制。连接成功只证明入口存在，不代表生产环境已经安全。数据库、代码仓库和内部文档都涉及敏感权限。团队真正部署这类 Agent 时，至少要把只读与写入权限拆开，记录每一次外部调用，并为删除、发布、付款和批量修改设置人工确认。

同一台云电脑上，两个任务真的一起跑了

视频后半段把测试重点转向云电脑。作者并行下发了两个开发任务：用 Godot 制作一个贪吃蛇游戏，用 Blender 创建巨石阵三维模型。

这组任务选得不错。它们会迫使 Agent 使用不同软件，也会产生可检查的文件。只看终端里几行日志，很容易把“命令运行过”误认为“项目做完了”；游戏能不能打开、模型文件能不能载入、渲染图是否存在，判断起来直接得多。

演示中，dots 在云端桌面里推进两个任务，并交付 Godot 项目和 Blender 文件。作者把贪吃蛇运行起来，实际操控角色移动；也查看了巨石阵模型与渲染结果。成品都很简单，离商业项目有很远距离，但交付方式比聊天窗口里粘贴代码可靠得多。

我会把这一段视为整期视频最关键的证据。Agent 产出代码时，最容易制造一种虚假的完成感：文件很多、说明很长、进度像模像样，打开后却跑不起来。视频至少补上了本地试玩和文件检查。测试规模有限，验证习惯值得保留。

并行执行也带来新的管理问题。两个任务都在跑时，用户需要知道各自处于规划、执行、等待还是失败状态。任务之间会不会争用 CPU、内存和磁盘？一个应用弹出授权窗口，会不会把另一个任务卡住？视频展示了并行能力，没有给出资源隔离和失败恢复的答案。面向长期工作，这些问题比“最多能开几个窗口”更重要。

Agent 还可以安装工具，再调用另一个 Agent

作者继续要求 dots 在云电脑里安装 Grok CLI。安装完成后，dots 打开官方授权页面并展示设备码，等待用户完成登录。授权结束，它调用 Grok CLI 生成了一个简单登录页 Demo。

这个过程很像真实工程师的工作方式：遇到任务时补装工具，通过浏览器做身份授权，再把工具纳入当前流程。对 Agent 平台而言，能安装软件意味着能力不必全部由平台原生提供。CLI、SDK 和开源工具都可以成为可组合部件。

风险也随之增加。安装脚本来自哪里，依赖是否可信，设备码是否会泄露，生成项目有没有把密钥写进文件，这些都需要审计。云电脑给了 Agent 更大自由度，也把传统终端安全问题带进了 AI 工作流。产品若只强调“什么都能装”，却缺少沙箱、操作记录和网络边界，团队很难放心把它接入正式环境。

定时任务展示了入口，还没证明长期可靠

视频还设置了一个每日自动检查任务。按照演示，用户可以指定事件和时间，让 dots 定时执行。视频简介也明确说明，这一段主要展示设置流程，没有进行长期无人值守测试。

这个边界很重要。定时任务创建成功，只能说明调度配置被保存。真正可用还要观察几天甚至几周：

机器休眠或会话断开后，任务是否照常触发；
外部服务授权过期时，系统是否能发现并提醒；
同一个任务重复触发时，是否会制造重复数据；
执行失败后采用什么重试策略；
用户在哪里查看历史记录、成本和失败原因。

长期 Agent 的质量常常死在这些无聊环节。演示容易拍出第一次成功，生产环境更关心第 30 次是否仍然可控。

这次实测证明了什么，也没证明什么

视频给出的有效证据可以分成三层。

第一层是交互入口。dots 支持网页、Slack 和语音，能从不同入口接收任务。第二层是执行环境。它拥有持续在线的云电脑，可以打开桌面软件、安装 CLI，并让多个任务同时推进。第三层是交付物。Notion 页面、Godot 项目、Blender 文件、渲染图和网页 Demo 都比一段口头回答更容易验收。

演示尚未覆盖复杂工程、长周期稳定性、多人协作权限、成本控制和失败恢复。Godot 贪吃蛇、巨石阵模型、登录页都属于短任务。它们适合验证工具链是否打通，却无法说明 dots 能维护大型代码库、处理模糊业务目标，或在无人看守时持续几天不偏航。

我也不会仅凭视频判断它已经“超越”某个竞品。Muse、Grokbot 与 dots 的运行环境、模型、连接器和计费方式需要放在同一套任务中比较。标题里的竞争叙事适合引起注意，实际选型仍要看任务成功率、人工接管次数、执行成本和交付质量。