后台发现、任务执行和对外承诺，需要三套不同的规则。
2026 年 9 月 29 日，OpenAI 发布 Dots：拥有自己的云电脑、能持续处理项目、会从反馈中学习的常驻 Agent。官方称它由 GPT-6 Astra 驱动，通过插件生态可连接超过 4,000 个应用，并能在 ChatGPT、Slack 和 Teams 中接收任务、携带上下文。
这次变化落在工作关系上。普通聊天的节奏是“人提出问题，AI 给出回答”；Dots 描述的节奏则是“人给出目标与标准，Agent 持续推进，把成果和需要判断的问题带回来”。如果团队采用这种方式，任务不会随着窗口关闭而自然结束，原本靠人盯着的步骤也需要明确的规则。
但“持续在线”并不是一种不受限制的行动权限。Dots 的后台主动研究、正在执行的任务、组织试点中的专职 Dot，各有不同边界。先分清这些边界，才能判断该交出哪一部分工作。
Dots 把“聊天之外的工作”放到了产品中心
OpenAI 的发布页给出了几个具体场景：开发者的 Dot 从客户反馈里发现重复问题，准备修复、测试和带视频的 PR；产品负责人收到范围变化后，Dot 更新发布材料；销售负责人面对客户要求变化时，Dot 对照产品文档、准备概念验证与测试计划，再把未解决的问题交回来。
这些例子有一个共同点：交付物不是单独一条回答，而是一组相互依赖的产物。修复代码需要测试，发布材料需要跟着产品范围变，销售方案需要跟着验证结果变。Agent 要保留目标、来源、当前进度和人的修改，而不是每一步都等待重新解释。
这也是自己的云电脑和跨渠道上下文有价值的地方。用户可以打开 Dot 的电脑查看工作，也可以选择让它连接自己的设备。在 ChatGPT 发起的项目，可以在 Slack 中继续讨论；官方说 Dot 会跨渠道携带上下文。这里应把“产品提供这种机制”和“具体公司已经稳定跑通”分开：发布页里的业务场景是 OpenAI 对产品用法的介绍，不是各行业都有同样成效的证明。
最容易混淆的，是后台研究与任务执行
Dots 官方把用户没有主动与它工作时的后台行为称为 proactive research。这时，Dot 可以从已连接的应用寻找有用的信息，但工具被限制为只读：不能发消息、修改应用内容，不能操控浏览器或电脑。
另一方面，发布页也描述了 Dot 通过自己的电脑和浏览器执行项目。两段说明并不冲突：后台自主找线索与用户交付的执行任务，不是同一种工作状态。
例如，Dot 从资料中发现“这个客户可能漏开发票”，属于发现问题；准备发票草稿属于形成交付物；把发票发送给客户则是对外动作。OpenAI 的早期测试案例明确写了最后一步发生在用户批准之后。不能因为有这个案例，就推断所有后台发现都能自动触发发送。
团队需要给 Agent 的不是一句“别做危险的事”，而是每类动作的可执行范围。连接哪个应用，只解决了它能接触什么；允许哪些动作，才决定它能改变什么。
连接权限、动作规则与成果审核，是三道不同的关
第一道是数据与系统的访问范围。 用户通过既有 ChatGPT 应用控制管理 Dot 的连接与权限。即使某项资料有助于任务，也不代表应把整个业务系统开放给它。先列出完成目标所需的最小来源，避免把“可能有用”当作访问理由。
第二道是动作放行。 Dots 从内置规则开始，Custom Rules 可以允许具体动作、要求批准或阻止动作；内置安全要求仍然有效。官方还介绍了 auto-review：涉及账号影响或信息共享的动作，会根据指令、Custom Rules 和安全要求检查，决定能继续、需要批准还是必须由人完成。修改密码这类敏感任务仍由人处理。
第三道是交付物本身的正确性。 系统判断某个动作可以执行，不代表发票金额、客户要求、发布文案一定正确。OpenAI 也提醒要审核重要工作。对业务负责人来说，审批按钮前应看到的不只是“是否发送”，还有来源、关键变化、尚未验证的事实和影响对象。
一个客户提案可能格式完整、权限正确，却包含尚未验证的集成承诺。动作审核与业务验收解决的是两种问题，团队需要同时设计。
从一份客户提案开始，而不是把整个部门交出去
下面是一个建议的任务设计，不是已经测得效率的案例：销售团队需要随着客户的技术要求更新方案，但不允许 Agent 自动承诺交付日期或写回 CRM 商机阶段。
任务可以这样拆：
- 确定输入。 给出本轮客户需求、已确认的产品说明、上版提案和当前测试记录。指定哪份记录是最新版本，并标注不能共享给客户的内部资料。
- 定义持续工作。 有新要求时，对照已有能力找差异，更新提案草稿和测试清单。没有证据的能力保留为问题，不改写成已支持。
- 规定成果位置。 每轮交付包含一份可阅读的提案、一张变更表、一份未解决问题清单。原始来源与草稿分开保存，方便逐项核对。
- 划出动作边界。 内部草稿允许准备；外部邮件、报价、交期承诺和 CRM 状态变更由指定负责人确认。具体可执行规则仍需按实际产品能力配置，不能把这份设计当作现成权限模板。
- 验收关键事实。 解决方案工程师检查集成与测试，销售负责人检查商务承诺。审核意见必须回到下一轮任务，而不是只留在一条无关联的聊天消息里。
这样交付的好处是：负责人不用逐段指导起草，却仍能检查“哪里变了、依据是什么、有哪些问题”。若 Agent 只能给出一份漂亮提案，无法展示证据与未决项，就还没有满足这个任务的验收要求。
specialist dots 还不能直接理解成通用“AI 员工”
发布页还预告了组织专职的 specialist dots：公司给每个 Dot 配置独立身份、凭据和系统访问，让它承担明确职责。OpenAI 提到采购、发票处理、邮件营销、客户支持和商业合同的早期内部探索，并表示从聚焦的企业试点开始。
这与当前用户的主 Dot 有不同的管理问题。个人 Dot 代表一个人工作；组织专职 Dot 涉及岗位权限、系统记录和跨团队责任。OpenAI 与 Microsoft Agent 365 的合作目标，是把这些 Dot 接入企业既有治理与安全控制。发布页没有把这项集成描述成每个账号都可以立即启用的完整服务。
判断企业试点是否适合自己，应该先问：职责是否足够窄，访问范围能否确定，失败时能否暂停，结果有没有负责验收的人。没有这些条件，只是给 Agent 一个岗位名称，并不会让工作自然可靠。
在持续工作空间里，先把一个流程验收清楚
Buda 的 Agent Workspace 把会话、Drive、终端、浏览器和 Git 放在同一工作空间；持续文件使 Agent 能从已有资料和产物继续工作，用户也能检查执行过程与结果。适合先从一个有明确输入和成果的任务开始，例如维护提案草稿与待验证清单。
在这类任务中，Buda 承接资料整理、工具执行与可检查产物。流程稳定后，可以把方法沉淀为 Skill；可安装的 Skill 可以在 Buda AI 的 Marketplace 搜索并安装。需要按时间重复运行的工作再使用 Automations。文件留存、可复用指令、定时启动分别解决不同问题，不能用“已经自动化”代替业务验收。
先安排一轮手动触发的完整任务，确认来源、输出和负责人都清楚，再增加持续执行。这比一开始就承诺全天候自主处理全部工作更容易定位错误。
常见问题
Dots 全天在线，意味着所有动作都能在后台自动执行吗？
不是。官方明确限制后台 proactive research 的工具为只读。执行任务时，还要考虑应用权限、内置规则、Custom Rules 与动作审核。应该按具体状态和动作判断，而不是从“24/7”推断权限。
Activity View 和人工验收有什么区别？
Activity View 用于了解进展，包括后台工作，并可重新引导 Dot。人工验收则要检查关键事实、计算和承诺。看见它运行过某一步，有助于追踪过程，但不能替代对成果的判断。
哪些套餐可以开始使用？
按 9 月 29 日发布说明，Dots 在合格市场向 Pro 和 Business Premium 逐步推出；Enterprise（包括 Edu 与 Healthcare）由工作区管理员启用 beta。官方称首个 Dot 包含在 Pro 或 Business Premium 中，深度工作有额度，Codex 或 ChatGPT Work 任务仍按各自规则计入使用量。具体账号应核对当前开放情况，不能把“首个 Dot 包含在套餐”理解为所有执行都无限量。
团队第一轮试验该记录什么？
记录已交付与未交付的任务、需要人工修正的事实、因权限或规则停下的动作，以及最终审核人花在哪些步骤。先看哪些错误重复发生，再调整范围或标准；不要仅用生成文件的数量评价 Agent。
来源与延伸阅读
资料核对日期：2026-09-30。Dots 的能力与开放范围依据 OpenAI 发布说明；客户提案流程为本文建议的任务设计，未宣称双方性能等同，也未进行效率实测。