OpenAI工程师实测DOTS：云端持久Agent如何接管On-call

OpenAI 工程师 Ali 在官方频道演示了 DOTS（内部代号）的工程化用法。它的定位很明确：一个拥有独立云电脑、同时能访问你本地机器、并在 Slack 等服务中拥有自己身份的持久云端 Agent。用 Ali 的话说，这套组合解锁了一种新的协作方式——不是你去调用 AI，而是 AI 主动接住你不想做的工作。

DOTS 是什么：一个带身份、能跨端工作的云端 Agent

DOTS 的核心设计可以拆成三块。第一，它运行在云端，有自己的云端计算机，意味着任务不依赖你本地设备的开机状态。第二，它能访问你的本地电脑，这让 Codex 会话可以真正在你笔记本上执行代码、跑构建。第三，它在 Slack 这类服务中拥有独立身份，你可以像 @ 同事一样在任意 thread 里 @ 它。

Ali 演示的第一步就是在 Codex 应用中点击自己的 DOT，然后把它连接到 Slack。连接完成后，DOTS 获得了一个 Slack 身份，可以在任意线程中被点名指派任务。

这种“身份 + 跨端”的组合，是它区别于普通聊天式 Agent 的关键。普通 Agent 是会话式的，你开一个窗口、问一个问题、拿一个回答；DOTS 是常驻的，它在后台待命，被触发时自己决定调用哪台机器、哪个工具。

用一句 prompt 搭起 On-call 自动化

Ali 展示的工作流围绕他自己的 on-call 值班。他在 Composer 里输入了一段指令：监控频道，任何进来的 page 都要做初步分诊，并创建一个线程去调查。发送之后，这条自动化就开始生效。

这段 prompt 本身很朴素，没有复杂的编排，也没有写脚本。它的价值在于把“值班响应”这个高频、重复、又必须及时的动作，变成了一个持续运行的后台任务。

对 on-call 工程师来说，真正消耗精力的往往不是修复本身，而是从被 page 吵醒到搞清“到底哪里挂了”之间的那段排查。Ali 的自动化恰好把这段前置工作外包了出去。

On-call 与 page

On-call（值班待命）是 SRE/运维和基础设施团队常见的轮值制度：在一段固定时间内，某位工程师对系统告警负第一响应责任，随时可能被叫醒处理故障。Page 指通过 PagerDuty、Opsgenie 等告警平台主动推送到值班人手机或即时通讯工具的通知，通常意味着线上服务已出现影响用户的异常。值班流程一般包含确认（ack）、分诊（triage）、升级（escalate）与复盘几个环节，其中分诊要求快速判断影响范围、可疑变更和负责团队。这类工作高频、重复且对响应时延敏感，因此非常适合交给常驻 Agent 承担前置排查，而把最终决策留给人。

凌晨 3 点的实战：手机端完成分诊

Ali 讲了最近一次真实经历。凌晨 3 点手机收到 page，他拿起手机确认，然后打开 ChatGPT 应用查看 DOT 的进展。此时 DOTS 已经完成了调查，定位了问题所在，并且创建了一个 Codex 线程供他进入、继续引导调查、发送后续消息。

关键细节是：这个 Codex 线程实际运行在他的笔记本上，所有消息同步发送到笔记本。也就是说，他不需要在凌晨 3 点起床打开电脑，调查已经在机器上跑起来了，而他只需要在手机上确认和推进。

这个案例里问题最终在手机上就解决了。但如果需要更深入的排查，他可以把手机放下，走到笔记本前，看到同一个 Codex 线程在本地继续可用。云端身份与本地执行之间的切换是无缝的——这也是 DOTS 架构上最值得关注的一点。

Codex 与 Codex 线程

Codex 是 OpenAI 的编程 Agent 产品形态，能够在受控环境中读取代码仓库、执行命令、修改文件并运行测试，常以“线程”组织工作：一个线程对应一段可持续追问的任务上下文，包含历史消息、工具调用记录和当前工作区状态。线程的价值在于可恢复与可接管——人可以在任意时刻进入同一线程继续引导，而不必重新描述背景。当线程运行在本地笔记本上时，代码、凭证和构建环境都不必离开本机，云端 Agent 只负责触发与转发消息，这也是文中手机与笔记本之间能无缝切换的技术前提。

更广的用法：从反馈分诊到 Slack 内写 PR

Ali 强调这只是一个小例子。通过发送简单 prompt 设置自动化，可以覆盖更多场景：比如对某个特定频道里所有进来的反馈做分诊，或者在 Slack 里 @ DOTS 让它创建 PR，并直接在 Slack 中与它迭代修改。

这些用法的共同点是：触发点在工程师已经在的地方（Slack、手机、ChatGPT 应用），执行发生在 DOTS 自己的环境里，人只需要在关键节点做判断和 steer。它把“上下文切换成本”从人身上转移到了 Agent 身上。

需要说明的是，目前这些能力来自 OpenAI 内部工程师的自述演示，来源单一，尚未看到第三方独立验证或公开的可用性、定价、权限模型细节。对于关注 Agent 工程化落地的人来说，DOTS 展示的方向——持久化、跨端、有身份——比具体功能更值得跟踪。

PR 与在聊天工具中迭代

PR（Pull Request）是代码协作平台上的合并请求：开发者把分支改动提交后发起 PR，经过评审、讨论和 CI 检查再合入主干。传统上 PR 的创建与修改需要在 IDE 或代码托管平台完成，而在 Slack 中 @ Agent 创建 PR 意味着把“描述需求—生成改动—提交评审”压缩进对话流。这种模式依赖 Agent 具备仓库写权限、能运行测试，并把结果以可评审的形式回传；同时也引出权限边界、审计记录和评审责任归属等问题，是评估此类持久 Agent 能否进入生产流程时必须考察的部分。