OpenAI 的 Dots 文档里有一条很容易漏掉：按下 Pause，只会停掉 Dot 当前的主任务。它已经委派出去的后台任务可能还在跑，未来的 Schedule 也不会自动取消。已经发出的消息更不会收回来。
这个细节比“常驻 Agent”四个字更能说明 Dots 是什么。它接手的不是一次对话，而是一项持续责任；责任下面会长出主任务、后台任务和计划任务。启动很简单，停干净反而要理解这三层状态。
它不是跑得久，而是会自己决定何时再动
长任务也许会跑一小时，但通常有明确终点，比如比较三个方案并交付文档。持续责任做完一轮以后还不能算结束。它要判断现在是否休眠、等什么变化、何时再醒来。
OpenAI 文档说 Dot 能在对话之间跟踪进度，自己决定何时暂停、何时醒来，也能用后台 Agent 并行处理工作。固定时间重复的事情仍然要保存为 Schedule；如果连接服务支持事件监控，则可以针对指定事件行动。三种路径不能混成一个模糊的“它会主动处理”。
三条路各有用途。依赖上下文的跟进留给主任务，明确时间用 Schedule，外部系统能发出事件时再用事件监控。用主任务记“每周一九点”，触发时间很难核对；用高频 Schedule 等一个偶发事件，又会制造一堆无意义检查。把 Dot 拉进 Slack 频道也只代表它能收到消息，不代表监控已经建立。
交代持续责任时，我至少会写清它盯什么、何时继续、什么情况来问我、到什么时候结束。漏掉结束条件，主动性就没有边；漏掉通知条件，用户只能在毫无消息和反复打扰之间碰运气。
同一句“正在处理”，可能跑在三个地方
Dot 自带云端计算机和浏览器，设备关机后仍能处理研究、文件和软件。它还可以使用已安装并授权的插件，或者连接一台本地电脑去访问本地文件、应用和任务。这三条路径看起来都能“做事”，权限和可用性却完全不同。
云电脑有独立浏览器会话。用户在私密登录流程中输入凭据，之后 Dot 可以在会话有效期内继续使用；它不会自动继承用户本机浏览器的登录。插件受各自连接和权限限制。连接本地电脑则要求设备在线并打开 ChatGPT 应用，而且这个授权与 Codex 或 Work Sync 的连接分开。
用户在 Slack 里给 Dot 发消息，不表示它同时拿到了邮箱和本地电脑；消息渠道只是沟通入口。云浏览器打不开网站时，改用本地电脑可能另起一项任务，也不会把原来的登录会话搬过去。
所以“正在处理”这四个字信息量太低。Activity 至少要告诉我它跑在云电脑、本地电脑还是插件里。否则我不知道设备能不能关，也分不清失败来自权限、离线，还是网站拦了云浏览器。
主 Dot 说停，后台任务未必听见
Dot 可以把工作委派给后台 Agent。OpenAI 文档说得很清楚：新任务有自己的对话，只收到主 Dot 为这项工作准备的指令和上下文，不会自动拿到全部历史。这能少带一些无关信息，也很考验交接。
交得少了，后台任务会重复问问题，或者自己补假设；交得太多，又把不相干的私人信息带了进去。我更愿意传一份短任务单：目标、来源、允许使用的工具、交付物，还有哪些问题必须带回来。整段聊天历史不该成为默认附件。
还有一个容易误读的词：completed。官方文档专门提醒，Run 完成了，仍要检查输出和错误；这个状态并不证明请求的结果已经实现或送达。
例如后台任务完成了“准备邮件”这个动作，可能只生成草稿；完成了“上传文件”，也可能停在网站确认页。Dot 需要把任务终态与外部结果分开呈现。用户能打开文件、看到目标系统记录或收到对方确认，才是更强的结果证据。
记忆可以记偏好，别让它记住过期事实
Dot 使用当前对话、相关 ChatGPT Memory 和自己的笔记来维持偏好、决定和持续工作。跨设备、Slack、Teams 或电话联系的是同一个 Dot，换沟通渠道不会自动创建新实例。它可以利用相关上下文接着工作，但消息仍留在各自渠道，在把私人会话内容分享到多人环境前还要检查授权。
记忆适合保存稳定规则，例如预算上限、偏好的输出形式和谁拥有最终决定。会变化的事实不应只靠记忆。某个文件已经更新、会议时间已经改动、外部页面仍然有效，都要回到当前来源重新读取。
偏好可以跨任务复用，事实却要带来源和更新时间。用户改口时也要问清楚：只改这一轮，还是以后都按新规则？长期记忆没有作用范围，积得越多，冲突越难发现。
跨渠道同样存在泄露边界。Dot 在私聊里知道一项敏感约束，不等于可以在团队频道解释原因。它可以据此改变行动，却应在公开渠道只说允许披露的结论。产品是否每次都能正确判断，仍然需要用户通过低风险场景检验，不能只靠功能说明推定。
Pause 停不干净，是因为系统里有三棵状态树
OpenAI 控制文档把停止分成三类：Pause 停止主 Dot 当前任务，但不会自动停止全部后台任务，也不会取消未来 Schedule；后台任务要在 Activity 里单独停止；Recurring Task 要到 Scheduled 中禁用或删除。已经发生的外部动作不会因为停止而撤销。
用户说“停”，听起来像一个全局命令，系统里却有三棵各自运行的状态树。主 Dot 暂停了，某个委派任务可能仍在生成文件，今晚的 Schedule 还会启动，插件发出去的消息也收不回来。
图里把它们拆开，是因为一个停止按钮确实管不了全部。真要终止一项责任，我会同时翻 Activity 和 Scheduled，再看连接权限与已经完成的动作。删除 Dot 也不能撤销外部应用里的改动。
自定义规则也不是绝对防线。规则可以要求某类动作自动执行、仅在明确要求后执行、每次询问或交还用户；它们不会替用户连接应用，不会覆盖内置安全要求，模型也可能理解错误。高风险规则写窄一点更稳妥：对象、动作、参与者和时间范围都说明白，别留一句“这类事情以后你自己看着办”。
不用拿真实工作做试验
没必要拿公司流程或私人邮箱冒险。让 Dot 维护一个开源项目的观察页就够了，只盯官方发布源：版本变了就更新页面，没有变化就别吵，发布动作必须先确认。
等它跑过一轮，再把页面改版交给后台任务。去 Activity 看后台任务到底收到什么指令、生成了什么文件。Run 显示完成后，亲手打开页面，点链接，缩到手机宽度。页面没变就是失败，主 Dot 写得再漂亮也没用。
再建一个只活两天的 Schedule，写清时区和通知位置。运行一次后暂停主 Dot，看看计划是否照常触发。最后分别停后台任务、删 Schedule、撤销连接。这个小实验能把三层状态摸清楚，又不泄露真实资料。
Dots 适合接责任，不适合接愿望
目标相对稳定、信息会变化、每轮都有东西可检查，这类事情适合交给 Dots。用户不用每次从头解释，Dot 可以保留责任背景，在需要判断时回来找人。
一次性问答、十分钟能做完的资料整理，不值得创建持续责任。像“帮我一直优化影响力”这样的愿望也别直接扔进去：动作会源源不断，什么叫做对、什么时候该停，却没人说得清。
Dots 的新鲜之处，是把目标、记忆、计算机、后台任务和 Schedule 都挂在同一项责任下面。东西挂得越多，停止就越麻烦。它能不能主动继续，只是演示里的前半段；后半段应该回答三句话：现在还有什么在跑，它还能改什么，我怎样把它们全部停掉。
引用信息
- 作者：邓明瑞 / 纯粹（Chuncui）
- 主题：常驻 Agent 的持续责任与控制面
- 核心结论：Dots 把一项责任拆成主任务、后台任务和计划任务；Pause 只管其中一层。
- 永久链接：https://blog.chuncui.icu/2026/10/09/openai-dots-ongoing-responsibility/