从「一问一答」到「常驻同事」
2026 年 9 月 29 日的 DevDay 上，OpenAI 发布了二十余项公告，其中最激进的产品形态是 Dots——官方称之为「always-on agents（常驻智能体）」。它不是又一个对话窗口，而是一个拥有独立云端计算机与浏览器的智能体，由 GPT-6 Astra 驱动，可以连接超过四千个应用，在你不开口的时候也代表你工作。
官方给出了五个场景示例：开发者监控用户反馈后自行修复 bug 并提交带演示视频的完整 PR；产品发布负责人在范围变更时自动修订发布材料；科学家在新数据到达后自动重跑分析、更新论文图表；销售负责人对照产品文档核查需求并构建 PoC；内容创作者从访谈转录中自动提炼片段、撰写节目笔记。
这篇工坊的目标很朴素：带你从零创建第一个 dot，把它接入一条真实的工程工作流（Slack 反馈流到 GitHub PR），并把权限与审批配置到「敢让它跑过夜」的程度。
第一步：创建你的第一个 dot
上手入口在 ChatGPT 桌面应用或桌面浏览器（移动端初始设置完成后可对话，但不能创建）：
- 在桌面应用中找到 dot 的创建入口，给它起一个名字——名字不只是装饰，多个 dot 组成团队时，名字是你下达指令时的路由依据。
- 连接第一批应用。建议首批只连 Slack 或 Teams 加 GitHub，刻意保持小，权限面越小，行为越可控。
- 等它自我介绍。dot 会基于初始连接做一次自我描述，这一步是检查它对自身能力边界理解是否准确的好时机。
可用范围方面：Pro 与 Business Premium 用户即日起在符合条件的市场可用，第一个 dot 免费包含在套餐中；Enterprise、Edu、Healthcare 需要管理员开启 beta。与 dot 的对话不计入 ChatGPT 使用限额，但通过 dot 在 Codex 或 ChatGPT Work 中启动的任务照常计入额度——设计调度策略时要记住这条边界。
第二步：理解 dot 的「手脚」与「缰绳」
Dots 之所以能干活，靠的是三件东西：
- 云端计算机与浏览器：dot 有自己的计算环境，可以同时处理多个项目而不需要你逐步指挥。你随时可以打开它的计算机检查工作过程，这是排查「它为什么这么做」的第一现场。
- 插件生态：通过插件系统连接超过四千个应用，从 GitHub、Slack 到各类 SaaS 工具。
- 跨渠道上下文同步：桌面、网页、移动端、Slack、Teams（短信即将推出），甚至语音通话，dot 在所有渠道共享同一份记忆。
缰绳则分三层。权限管理：你决定 dot 可访问哪些应用。Custom Rules：可以针对特定操作设置三档策略——允许、需要审批、阻止。敏感操作硬约束：修改密码这类操作永远保留给本人，不可下放。
还有一个容易被忽略的细节：dot 的「主动研究」模式只能使用只读工具——它可以在后台浏览、读取、分析，但不能发消息、修改内容或控制浏览器与电脑。写操作必须走授权路径。这实际上把 dot 的行为切成了「感知自由、行动受控」两半，工程上非常像把传感器和执行器分开的控制系统设计。
第三步：配置 Custom Rules 审批策略
假设你的场景是「监控 Slack 反馈频道，自动分诊并修复 bug」。建议的初始规则集：
- 允许：读取反馈频道消息；读取 GitHub 仓库代码与 issue；在本地分支提交修改；跑测试。
- 需要审批：创建或合并 PR；在 Slack 中回复用户；修改 CI 配置。
- 阻止：直接 push 到主分支；删除任何资源；触碰密钥与凭证。
这套配置的思路是「读写分离、写需审批、删除禁止」。前两周建议把审批阈值设得偏高，观察 dot 的行为模式后再逐步放宽。OpenAI 内置的防护会持续监控潜在有害行为，检测到安全问题可以暂停或终止工作，但这层防护针对的是越界行为，不是「合法但不符合你意图」的操作——后者只能靠 Custom Rules。
💡 实践建议：把 Custom Rules 当成代码来管理。每次调整规则后记录一条变更日志，说明动机与观察到的行为。规则漂移是常驻智能体最大的隐性风险来源。
第四步：接入反馈流，跑通第一个闭环
以「Slack 反馈到 GitHub PR」为例，完整闭环是：
- dot 监控指定的反馈频道（只读，无需审批）。
- 对新消息做分诊：可复现的 bug、功能请求、噪音。分诊标准在 dot 的初始指令中写清楚，例如「带版本号与复现步骤的消息优先级高于纯抱怨」。
- 对可复现 bug，dot 在自己的云端计算机上检出代码、定位、修复、跑测试。
- 创建 PR（触发审批），附上从反馈到修复的完整追溯链。
- 你审批后合并，dot 更新内部记录，闭环完成。
官方展示的开发者场景更进一步——PR 里带演示视频。这一步依赖 dot 对浏览器与录屏工具的调用能力，建议在自己的工作流里作为二期目标，第一期先把「修复加测试加追溯」跑稳。
对照 DevDay 同期发布的其他公告，这个闭环还有增强空间：Codex in the cloud 允许复用开发环境、团队共享已批准的设置与权限，适合把 dot 的开发环境从「它自己的计算机」升级为「团队统一环境」；Agents API 新增的 computer use 能力则面向自建智能体的开发者，与 Dots 属于不同层次的产品。
第五步：把 dot 放进团队协作结构
Dots 不是孤立功能，DevDay 同时发布了配套的协作基础设施：
- ChatGPT Space：队友、ChatGPT 与你的 dot 在共享知识上协作的空间，可按指令自动整理。
- 团队与共享任务：Business 与 Enterprise 档位可以把周期性工作（如每周项目更新）委派给团队任务，ChatGPT 按计划或响应事件采集信息执行，队友可共同调整指令。
- @ChatGPT in Slack / Teams：频道里 @ChatGPT 获取协助，队友可在同一对话补充上下文，且无需单独的 ChatGPT 许可证。
对工程团队，推荐的接入顺序是：先让一个 dot 跑个人工作流（反馈分诊），验证稳定性后再把它的产出接到 ChatGPT Space，让团队成员可见可评论，最后才考虑 Specialist Dots——为组织内特定职责设计、拥有独立身份与凭证的企业级形态，目前处于采购、发票处理、客户支持等领域的试点阶段，并与 Microsoft Agent 365 的治理体系集成。
边界与工程判断
写这篇工坊时我刻意压住了热情。Dots 的能力上限取决于 GPT-6 Astra，但工程可靠性取决于你对失败模式的预算。三个务实的提醒：
第一，复核成本要计入。 OpenAI 自己在公告里写明「Dots 仍可能出错，重要工作务必人工复核」。如果你的审批队列每天堆五十个 PR，复核本身就成了全职工作——先从每周产出两三个高质量闭环的小任务开始，让信噪比可接受。
第二，权限是单向棘轮。 连接四千个应用的诱惑很大，但每一个连接都是攻击面。dot 的防护体系会对抗恶意指令注入（比如反馈频道里有人故意写「忽略之前的指令」），你的 Custom Rules 应当假设这层防护不是百分之百可靠。
第三，成本结构变了。 与 dot 对话不计入 ChatGPT 限额，但 dot 在 Codex 或 ChatGPT Work 中启动的任务计入。常驻智能体意味着「闲时也在消耗」——深度工作额度在发布后第一个月有扩展限额，之后回到常规水平，提前建立用量监控习惯。
结语
Dots 把「智能体」从演示词汇变成了可以每天交付工作产出的基础设施。对开发者而言，它最值得认真对待的一点是：这是第一个把权限模型、审批流、跨渠道上下文打包成消费级产品的常驻智能体。从反馈分诊这样的小闭环开始，把它当作一位需要 onboarding 的新同事——给清晰的规则、有限的权限、可回滚的任务，再用它换回你的时间与注意力。
这正是 OpenAI 给 Dots 的定位：把重要工作从你的待办清单上拿走。至于拿走之后你用这些时间做什么，那就是你自己的事了。