OpenAI Dot 与 Codex 如何搭配使用：交办找 Dot，结对找 Codex

OpenAI 开发者体验团队的 Dominic Kundal 经手过 Codex、GPT 和 Agents SDK，他在社交平台上发了一篇长文，专门讨论一个让很多人困惑的问题：OpenAI 自家的两款产品 Dot 和 Codex，到底该用哪个？他的答案很直接——两个一起用。

从「不确定有用」到「离不开」

Kundal 本人是重度 Codex 用户，他在 Codex 上下过不少功夫：用记忆插件和自动化搭了一套完整工作流，还配了一个帮他跟进手头工作的「幕僚长」式智能体。正因为自己的循环已经很顺手，他起初并不确定 Dot 能派上什么用场。

但用了一段时间后，他说已经离不开了。最大的区别是「省心」——事情交出去就不用再自己盯着每一步。Dot 是一个会主动做事的个人智能体，名字、形象和交流方式都能自定义，他给自己的 Dot 取名叫 Chopper。

过去他的工作流很琐碎：把 Slack 消息链接贴进 Codex，让它开发功能、盯着部署、再向 Slack 汇报，还要另外建一个自动化去跟进后续变动，每来一件新事就得重来一遍。现在他直接在 Slack 讨论串里 @ 他的 Dot，Dot 接下任务、处理完就在原处回复，之后的变动也会主动留意。

同一套框架，分工不同

Dot 和 Codex 用的是同一套开源的 Codex 智能体框架，你装过的插件它也能直接用。从结构上看，Codex 是「按需调用」，Dot 是「主动做事」，但底层是同一个 Codex 智能体——任务可以派到你的电脑、Codex Cloud，或者 Dot 自己的云端电脑上。

目前每人只能建一个 Dot。Kundal 认为这样反而更好：有活就交给它，不用先纠结该放进哪个 Codex 现成流程。相比直接用 Codex，Dot 的差异集中在三个方面：连续性、统筹调度、主动性。

Codex 智能体框架是 OpenAI 开源的编程智能体基础架构，允许开发者通过插件扩展其能力，并将任务分发到不同计算环境执行。「按需调用」意味着用户需要主动发起对话、明确指定任务；「主动做事」则意味着智能体能够自行感知环境变化、在无需用户触发的情况下启动行动。这种架构差异决定了两者的适用场景：Codex 更适合需要深度参与、反复迭代的编程协作，而 Dot 更适合将已明确的任务委托出去并由其全程跟进。共用同一框架的好处是，用户在 Codex 上积累的插件配置和工作流知识可以无缝迁移，不需要重新学习一套新系统。

连续性：换个地方接着聊

同事在 Slack 里报了个 bug，他转给 Chopper，Chopper 开始收集信息、着手处理。通勤路上他打电话给 Chopper 继续聊这件事，或者换个话题；回到工位再在桌面端接着来——始终是同一个 Dot，就像和家人朋友换个地方聊天，不用从头讲起。

几个渠道还能同时用：电话没挂，Chopper 可以发东西给他看，他打字回一句、发个链接，通话照常继续。

为了管住这种「不会结束」的长对话，Dot 在 Codex 已有的上下文压缩之外，还多了一套新工具：给自己记重点、定时醒来、在后台研究相关话题。它慢慢摸清他的工作细节和同事关系，他也更放心把工作交出去。Dot 还能读取 ChatGPT 的记忆和历史对话，并用上已经连好的插件——用过 Codex 的人不用从零开始。

统筹调度：边聊边干好几件事

因为只有一个 Dot，它必须能一边聊天一边并行推进多个任务：启动子智能体和独立任务，再把结果收回来。Dot 有自己的云端电脑和浏览器，能登录网站操作，甚至能用上 Blender 这样预装的专业软件。编程任务既可以放到 Codex Cloud，也可以派给本地电脑。

云端任务在他合上笔记本后照样运行；本地任务则要求电脑开着，好处是能用上本地的全部上下文，包括已经登录的浏览器。他的习惯是把后端改动和小的文案修改放到云端，大的前端改动留在本地，时间长了 Dot 会记住这些偏好自动安排。路上想到点子，他打电话讲给 Dot，Dot 一边聊一边开好 Codex Cloud 的任务；之后他可以打开那个线程直接和 Codex 迭代，也可以让 Dot 接着做。

主动性：等来的那句「可以再试了」

这是 Kundal 眼里 Dot 最大的区别。Chopper 会在后台把各个应用里的信息拼起来——一条新的 Slack 消息，或者会议记录里的一个决定，可能和上周聊过的事有关，它会把两边联系起来提醒他。

有一次他让 Chopper 跟着一个 PR 一路到生产环境，确认什么时候可以重拾修复，他不用一遍遍去查，等来的就是那句「可以再试了」。另一个场景更能说明问题：某次活动当天，他在 Slack 查看主题演讲期间的故障会不会影响自己的演示，Dot 还顺带发现了另一起他没注意到的故障，把演讲稿、故障情况和他的日程对了一遍，提醒他用演示账号重新测一遍相关步骤。看到日历上他快要出门通勤，Dot 还会建议把本地任务挪到云端，路上接着跑。

团队另一位工程师放得更开：他授权自己的 Dot 盯着反馈频道排查问题、启动 Codex 任务去修、检查 CI 结果、处理失败，遇到大问题再叫人。这些能力 Codex 本来就有，Dot 随时能从停下的地方接手。

「主动性」在智能体领域对应的技术概念通常称为 proactive agency 或 event-driven agent，即智能体不依赖用户指令触发，而是持续监听外部信号（如消息通知、日历事件、CI 状态变化）并自主判断是否需要采取行动或提醒用户。这与传统的「请求-响应」交互模式有本质区别：传统模式下用户是唯一的发起方，智能体只是工具；主动性模式下智能体成为一个持续运行的协作者，能够将分散在不同应用中的信息关联起来，发现用户未注意到的潜在问题。这种能力的实现依赖于持久化上下文存储、跨应用数据读取权限以及后台任务调度机制，也因此带来了更高的权限管理需求，这也是文章强调「划清权限边界」的技术背景。

从保守到放权：信任是逐步建立的

默认情况下，Dot 只做研究、不执行操作。交给它的任务越多，它越清楚自己能帮上什么，信任也随之建立——你可以让它不打招呼就做更多事，也可以用自定义规则规定「什么时候必须先问你」。

Kundal 也坦白：如果你已经搭好了自己的一套循环，或者有一个调度其他现成流程的「总现成」，可能不会马上感到差别。但目前 Dot 不占用 ChatGPT 的使用额度、几乎不限量（除非它把任务交给本地 Codex 或 Codex Cloud），正适合试一试。

智能体的「默认只做研究、不执行操作」对应的是业界常见的 read-only 或 suggest-only 模式，即智能体在未获得明确授权前只收集和分析信息，不对外部系统产生写操作。随着用户逐步授权，智能体才会获得执行能力，如提交代码、发送消息、修改文件等。这种渐进式授权模型是智能体安全设计的重要原则，旨在降低自动化操作出错时的影响范围。「自定义规则」则类似于策略层（policy layer），叠加在平台内置安全措施之上，让用户能够针对具体场景定义审批门槛，例如「涉及生产环境的操作必须先确认」，从而在便利性和可控性之间找到适合自身工作流的平衡点。

上手建议

在 ChatGPT 桌面应用里设好 Dot，连上本地的 Codex，让它替你开 Codex 任务。接下来可以从三件事开始：

• 示范一件常做的事：挑一件你经常要做、又清楚什么是好结果的事，先示范给它看，一起调好再交出去，讲清它能处理到哪一步。Kundal 把这叫做「反待办清单」。
• 让它盯 bug：让 Dot 盯着你被标记的 bug，直接处理掉。
• 划清权限边界：讲清哪些事它可以自己做、哪些要交给你审，也可以写成自定义规则，叠加在应用权限和内置安全措施之上。

他的总结很简洁：交办找 Dot，结对找 Codex。想和 AI 一起钻研一个问题，他还是直接找 Codex；更多时候，他把想法和问题丢给 Dot，剩下的交出去——速度更快，也轻松得多。