OpenAI Dots 观察短评（v1.0）：云端常驻代理的职责边界与采用触发条件
| 字段 | 内容 |
|---|---|
| 文档类型 | 调研报告 |
| 版本 | v1.0 |
| 状态 | 已完成 |
| 密级 | 公开 |
| 作者 | zhenjun.feng |
| 生成日期 | 2026-10-16 |
| 研究截点 | 2026-10-16（以 OpenAI 官方文档与公告为一手来源；Dots 为逐步开放产品，可用范围以官方为准） |
| 目标读者 | 关注长期代理与云端代理产品的工程师、技术负责人与产品观察者 |
| 调研问题 | OpenAI Dots 的实际职责与治理边界是什么；与「旗舰主控 + 订阅制 CLI 执行」自托管模式的异同；哪些集成路径官方已证、哪些未证；额度口径如何；是否值得、何时值得评估采用 |
| 覆盖范围 | Dots 官方文档四页（dots / computers-and-apps / tasks-and-memory / controls）与 Introducing dots 公告（2026-09-29）：职责对照、部署边界、监督与审批、额度与可用性 |
| 排除范围 | 不做实机接入与账号实验；不推断未公布的配额数值与路线图；不涉及任何内部执行环境细节 |
姊妹篇：《多模型编排框架调研报告》——本短评是该报告「云端常驻代理」方向的观察延伸；本稿不改变该报告结论。
摘要
- OpenAI Dots 是官方定义的「常驻云端代理」：跨工具与项目持续跟踪一项责任，随变化推演下一步，在对话之间跟进，并把结果或需你决策的事项带回来；官方对照表把它的职责概括为「长期跟踪 → 推演 → 跟进 → 分派给 Work/Codex」[S01]。
- 它与「旗舰主控 + 订阅制 CLI 执行」模式的职责高度相近（长期责任、跟进、分派、决策回收），差异在治理边界：云端托管、闭源、账号与工作区权限体系；运行位置、记忆、监督逐项对照见正文 [S01][S03][S04]。
- 官方已证边界与未证边界必须分开：云侧工作设备关机可续、本机连接语义、Activity/审批/接管、额度三口径均有官方明文 [S01][S02][S04]；面向无头 Linux / SSH / tmux / 外部 CLI 执行器的集成未见接口说明（未证实，非否定），深入工作配额数值未给 [S01][S03]。
- 采用结论（按场景条件化）：在「保留现有订阅 CLI 与人工接管、迁移成本受控」的适用假设下，对自托管工作流不直接迁移、保留评估——护栏三条（不新增常驻「经理模型」、不接入本地执行环境与订阅 CLI、不改现有认证与路由）+ 评估触发条件三条（官方出现 headless 或外部执行器接口、本机连接扩展到无头环境、深入配额数字公布）[S01][S02]。
背景与现状
OpenAI 在 2026 年 9 月末发布 Dots：一种常驻型云端代理，官方定位是「跨工具与项目持续保持工作推进，并主动带回结果或需要你决策的事项」。与一次性问答或单次任务不同，Dots 强调长期责任：跟踪一件持续的事、随情况变化推演下一步、在对话之间自己跟进，并能把任务分派给其生态内的产品（ChatGPT Work、Codex 等）。它驻留在云端、拥有自己的云电脑与浏览器，因此设备关机也不影响其云侧工作；用户通过 ChatGPT 的桌面/移动 App 或桌面浏览器与其交互。Dots 属于逐步开放产品，可用范围以官方 Access 说明为准 [S01][S02]。
本短评要回答的是一个工程选型问题：这种「云端常驻代理」与自托管的「旗舰主控 + 订阅制 CLI 执行」模式是什么关系？前者由厂商托管、开箱即用；后者把会话、状态与凭证留在自己手里（注意：CLI 在本机运行不等于推理在本机——若使用云端模型，相关上下文会发送给服务端），主控负责规划/验收，订阅制 CLI 负责执行。两者职责上同构、治理上异构——对已经建设自托管工作流的团队，「是否迁移/是否并行采用」的判据应当是：官方公开了哪些集成路径、哪些还未证、额度口径是否可算。本稿只做这一步事实核对与条件判定 [S01][S03]。
口径说明：本稿以官方文档（learn.chatgpt.com 的 Dots 四页）与官方公告为一手来源，正文采用中文释义并附官方链接；事实与推断分开标注；「未见/未证实」=在已读官方材料中未发现相关说明（非产品否定）；界面标签保留官方英文名（如 Activity、Take over）。不安装、不注册、不做实机接入实验。采用判定带明确适用假设：读者已有（或计划建设）自托管多模型工作流，重视会话/台账/权限的自主掌控并希望控制迁移成本；假设不成立时判定可能不同，结论按场景条件化给出（见末节）。
图 1：Dots 职责环与主控模式的对照。来源：OpenAI Dots 官方文档（定位与对照表、暂停/唤醒、分派）[S01][S03]；数据口径：2026-10-16，按官方原文释义。
职责对照：Dots 与「旗舰主控」模式
见图 1。官方把 Dots 的职责链描述为「长期跟踪一项责任 → 随变化推演下一步 → 在对话之间跟进 → 分派给 Work/Codex」；这与「旗舰主控」模式（主控规划、派发、催办、回收决策）在职责上几乎同构。把两边逐项对照后，差异集中在治理与形态而不是职责清单：
| 维度 | Dots 官方事实（释义，附官方链接） | 与「旗舰主控」模式的对应 |
|---|---|---|
| 定位 | 常驻云端代理，跨工具与项目保持工作推进，主动带回结果或需你决策的事项 [S01] | 职责高度相近：长期责任 + 跟进 + 分派 + 决策回收，属同型模式 |
| 运行位置 | 驻留云端，自带云电脑与浏览器；设备关机仍可继续工作 [S01][S02] | 形态差异：自托管模式的会话、状态文件与脚本承载在本机（CLI 本地运行 ≠ 推理本地执行；若使用云端模型，相关上下文会发送给服务端）；Dots 是云端托管 |
| 节奏与事件 | 可自行决定何时暂停/唤醒，无需固定日程；也可指定时间或受支持的事件触发；连接服务支持时可做事件监控，仅连接来源不会自动创建监控任务 [S01][S03] | 与巡检/事件唤醒同构；监控支持范围以服务侧为准；其合并/去重实现未证实 |
| 分派与并行 | 后台代理并行、可开独立可见线程；任务四型：本地 Work/Codex（需所连电脑在线且 App 开启）、云 Codex 任务（电脑可离线）、续接本地 Codex、对自建任务继续跟进 [S03] | ≈ 分派执行者；对象为 Work/Codex/云环境；外部订阅制 CLI 执行器未见接口（未证实） |
| 记忆 | 以 ChatGPT 记忆为起点，另有自存笔记（偏好/决策/进行中工作），跨对话与渠道延续；新任务只接收该任务的指令与上下文，不会自动获得你与 dot 的全部对话 [S01][S03] | ≈ 交接文档 + 长期笔记；任务级上下文隔离是值得注意的设计差异 |
| 监督与介入 | Activity 可查看进度/文件/结果/待响应项，并可在进行中改向；动作前自动审查三路：放行 / 需你批准 / 需你亲自完成；自定义规则四档：免问执行 / 你说才执行 / 先问 / 转交你办；暂停与停任务、取消计划分治；云电脑支持 Take over 与 Return control [S04][S01][S02] | 人工接管模式覆盖较全（查看/审批/接手/暂停），可作信息结构参照；对象域仍在其生态内 |
一句话对照：Dots ≈ 托管版的长期主控——同型职责、不同治理边界（云端、闭源、账号与工作区权限体系）。对自托管模式而言，它既是「要不要换形态」的候选，也是「信息结构可以怎么学」的样本（Activity 流、审批三路、规则四档、暂停分治都是可平移的交互模式）[S04]。
边界与覆盖判定：官方已证与未证
见图 2。把「自托管工作流关心的问题」逐项放到 Dots 官方材料上核对，得到一张清晰的两分表：一边是已证边界（有官方明文），另一边是未证路径（官方材料未提及，不能反推为不支持）。
图 2：云端托管与本地自托管的边界对照，及官方已证/未证分界。来源：OpenAI Dots 官方文档（运行位置、本机连接、监督面、Access）[S01][S02][S04]；数据口径：2026-10-16，按官方原文释义。
| 关注点 | 判定 | 官方依据（释义，附链接） |
|---|---|---|
| 订阅制 CLI 执行（不转 API） | 不直接覆盖；集成未证实 | 任务面仅 Work/Codex/所连电脑/插件 [S01][S03] |
| 数据与会话留在本地 | 保留评估 | 存在「云电脑 + 本地电脑（单机、持久连接）+ 插件权限」模型与数据设置说明；接本地机器需走面向个人电脑 + 桌面 App 的连接，无头 Linux 路径未证实。注意：「本地」指会话与状态落盘位置——CLI 本地运行不等于推理本地；若使用云端模型，相关上下文会发送给服务端 [S02][S04] |
| 设备关机后云侧工作 | 不冲突（已证） | 云侧工作设备关机可续；「在线 + App 开启」要求仅适用于「使用所连电脑」的场景——两者不可混谈 [S01][S02] |
| 人工接管 | 模式上被覆盖（对象在其生态） | Activity / 审批三路 / 规则四档 / 暂停分治 / 接管与归还 [S04][S01][S02] |
边界的两条纪律：其一，「未见说明」只记未证实——官方四页没有 Linux 无头 / SSH / tmux / 外部 CLI 执行器的接入说明，这既不构成否定，也不构成承诺，只能作为「评估触发条件」观察；其二，云侧与所连电脑两套语义分开读——「设备关机可续」说的是云侧工作，「在线 + App」说的是本机连接，混谈会得出错误结论 [S01][S02]。
额度与可用性：三个消耗口径
额度是采用判定的硬信息。官方 Access 页给出了三个消耗口径，可数、可预期；但它没有给出「深入工作」配额的具体数字，因此不做数值推断：
| 消耗面 | 官方事实（释义，附链接） | 结论 |
|---|---|---|
| 与 dot 的对话 | 不计入 ChatGPT 使用限额 [S01] | 不计（已核） |
| dot 启动/管理的 Work/Codex 任务 | 照常计入对应产品限额 [S01] | 照常计（已核） |
| 深入工作 | 方案内含专门配额，上线首月有限额延长 [S01] | 存在专项配额；此页未给数字 → 数值未知 |
| 可用范围 | Pro 100/200/500（18 岁以上、欧洲经济区/英国/瑞士以外）；Business Premium 与 Enterprise 全球推出（Enterprise 默认关闭、需管理员启用）[S01] | 以官方为准；不推断个人方案是否适用 |
结论先行：Dots 消耗的是 OpenAI 侧额度，与第三方供应商（非 OpenAI）的订阅 CLI 额度分属不同账户、互不影响；但若执行者是 Codex，dot 启动/管理的相关任务仍计入对应 Codex 产品限额，不能额外获得一份独立额度；不同产品间限额是否共池，官方未说明，本稿不作概称 [S01][S05]。「对话不计」与「Work/Codex 任务照常计」两条已证，意味着若把它作为「第二主控」并行使用，任务型消耗仍会照常出现在对应产品限额里——这属于可设计的成本结构，而不是「免费/无限」的替代品。对成本设计的含义：既然对话不计、任务照常计，采用与否应围绕「任务量」做估算（例如每周预计新开多少 Work/Codex 任务、其中多少会触及限额），而不是围绕「聊了多少」；官方把更深工作单独设配额，也说明重任务与轻对话在成本结构中本就不是一回事 [S01]。
结论与采用建议
见图 3。综合职责对照、边界判定与额度口径，在背景所列适用假设下（保留现有订阅 CLI 与人工接管、控制迁移成本），对自托管工作流的结论是：职责高度相近，但集成路径未证实——不直接迁移，保留评估；该判定是前提条件式的：官方接口或需求场景变化时应重做增量评估，对公开信息的小范围试用不受此限。理由是迁移的真正门槛不在职责（两边同构），而在三个未证点与一个治理差异：外部 CLI 执行器接口未证、无头环境连接未证、深入配额数值未知，加上对象域与账号体系在其生态内 [S01][S02][S03]。
图 3：采用判定的护栏与评估触发条件。来源：按官方已证/未证边界整理 [S01][S02][S03][S04]；数据口径：2026-10-16。
具体建议分三层。护栏不变（三条）：不新增第二个常驻「经理模型」；不把云端代理接入本地执行环境、订阅制 CLI 或内部数据/凭证；不改动现有认证与模型路由。评估触发条件（三条，任一出现再做一次增量评估）：①官方出现 headless（无头）或外部执行器（含第三方 CLI/订阅会话）接口说明；②本机连接扩展到 Linux 无头环境；③深入工作配额的数字与口径公布。现在做什么：按姊妹篇《多模型编排框架调研报告》的建议 A–D 推进（事件 + 台账 + 真实交付），不改现有认证与路由；以上护栏与建议均以适用假设为条件（保留现有订阅与权限形态、控制迁移成本），对公开信息的小范围试用与官方接口变化后的重估不受此限；本短评只提供事实与触发条件，不替读者做采用决策 [S01][S03]。
参考来源
- [S01] OpenAI Dots 官方文档·总页（定位、运行位置、暂停/唤醒、记忆、连接与插件、对照表、Access 额度；2026-10-16 查阅）。 文档
- [S02] OpenAI Dots 官方文档·Computers and apps（云电脑、Take over/Return control、网站登录、连接本机、插件）。 文档
- [S03] OpenAI Dots 官方文档·Tasks and memory（分派任务四型、事件监控、记忆、主动研究边界）。 文档
- [S04] OpenAI Dots 官方文档·Controls（Activity、自动审批、自定义规则四档、停止工作、数据设置）。 文档
- [S05] Introducing dots（官方公告，2026-09-29；额度句与 S01 Access 一致）。 公告
- [S06] ChatGPT 数据控制说明（S04 引用页）。 帮助文档
附录 A：主要结论与依据对照
| 结论 | 依据（来源） |
|---|---|
| Dots 职责链：长期跟踪 → 推演下一步 → 对话间跟进 → 分派 Work/Codex | 官方文档定位与对照表 [S01] |
| 云侧工作设备关机可续（已证）；「在线 + App」仅限所连电脑场景（已证） | 官方文档运行位置与本机连接节 [S01][S02] |
| 监督面覆盖：Activity / 审批三路 / 规则四档 / 暂停分治 / 接管归还 | 官方文档 Controls 与云电脑节 [S04][S01][S02] |
| 额度三口径：对话不计、Work/Codex 任务照常计、深入工作有配额但无数字 | 官方文档 Access 节 [S01][S05] |
| 外部 CLI 执行器 / 无头 Linux / 合并去重实现：均未证实（官方未见说明，非否定） | 官方四页核对（未见）[S01][S02][S03] |
| 采用判定（条件化）：在保留现有订阅/权限与迁移成本受控的假设下，不直接迁移、保留评估；护栏三条 + 触发条件三条 | 本报告综合（上表各条）[S01][S02][S03][S04] |
附录 B：检查与验收清单
| 检查项 | 方法 | 结果 |
|---|---|---|
| 来源可点击 | 台账 S01–S06 均为官方 URL [S01] | 通过 |
| 事实与推断分开 | 「官方事实」与「判定/推断」分列；未证点逐条标注「未证实」[S01][S03] | 通过 |
| 不把「未见」当否定 | 全文未出现「不支持」式断言；统一「未见接口说明（未证实）」[S01][S02] | 通过 |
| 云侧/本机语义分离 | 「设备关机可续」与「在线 + App」分场景表述 [S01][S02] | 通过 |
| 不推断配额数值 | 深入工作配额写「存在但数值未知」[S01] | 通过 |
| 图注合规 | 三图图注含来源与口径，正文均「见图 N」[S01][S04] | 通过 |
| 公开合规 | 无内部环境细节；官方英文原文不整页转载；界面标签保留必要英文 [S01] | 通过 |
附录 C：研究方法与局限
方法：以官方 Dots 文档四页与官方公告为一手来源，逐页核对「职责、部署边界、监督与审批、额度与可用性」四组事实；把事实与推断分开标注；「未见/未证实」与「不支持」严格区分；额度口径只记录官方原文含义，不做数值推断。局限：其一，Dots 为逐步开放产品，官方材料持续更新，本稿结论以研究截点为准；其二，未做实机接入与账号实验，「合并/去重实现」「监控支持范围细节」等保持未证实；其三，对照侧的「旗舰主控 + 订阅制 CLI 执行」为通用形态描述，具体实现差异不影响本稿的边界判定；其四，「深入工作」配额数字、外部执行器接口属高变动信息，需按评估触发条件复查官方页面；其五，本稿为观察性短评，不替代官方文档本身，读者在做采用决策前应按触发条件回查官方页面，并结合自身方案核对可用范围与额度口径的适用性。复查入口：官方 Dots 文档总页及其三个子页（见参考来源 S01–S04）。