OpenAI dots云端AI编码代理：异步常驻工位实操与避坑指南

昨天群里有人转了一张图，标题是“OpenAI 给 AI 发了张工位”。我一开始以为是整活，仔细看完才发现，dots 这个产品真的就是把一个 AI 编码代理常驻在云端，让它自己值班。熟悉 Codex 的朋友应该记得那行welcome to codex——以前是我们把 Codex 叫到本地终端里帮忙，现在是 OpenAI 给 Codex 在云端搭了一间办公室，你下班了，它还在工位上继续跑。这篇文章我想聊聊这朵“云端 AI 工位”到底解决了什么问题，适合谁用，以及我把自己的一点实操经验整理出来，给准备试水的小伙伴当参考。

1. dots 是什么：OpenAI 给 AI 发的那张“云端工位”

先说结论：dots 不是一个简单的聊天窗口，也不是本地 IDE 里的插件。它是一个常驻云端的 AI 编码代理，有自己的工作目录、运行环境和任务队列。你把一个需求丢给它，它会自己在云端 clone 代码、读文件、写代码、跑测试，最后给你交出一份 diff 或者一个 Pull Request。整个过程不需要你一直盯着终端，也不需要你本地装好所有依赖。

1.1 从 Codex CLI 到云端常驻 Agent

我最早接触 Codex 时，它还是一个命令行工具：在终端里codex "帮我看看这个函数为什么 OOM"，它能读取当前目录的代码，给出修改建议。刚开始觉得很惊艳，但用了几天就发现一个问题——它始终是“本地临时工”。每次对话都要基于我当前的仓库状态，一旦仓库里有些历史包袱（比如旧的构建脚本、缺失的环境变量），AI 很容易被带偏。

dots 的思路是把“临时工”变成“正式员工”。它在云端给你这个 AI 分配了一个固定的工作区，代码在这个工作区里 checkout 一份，依赖在这个工作区里安装，连 shell 状态也保留着。于是它不再是一个每次都要重新理解的对话机器人，而是一个持续工作的代理。你只需要告诉它“接着上次的任务继续”，它就能沿用之前的上下文。

这种变化很微妙，但影响很大。我举个例子：以前用 Codex CLI 改一个项目，如果中途换电脑，会话就断了，之前改到一半的代码、记住的约定全部丢失。而 dots 常驻云端，它的记忆和文件状态都存在云端工位上，我本地换个终端甚至用手机看一眼状态都行。它不再是“我发起的一次性问答”，而是一个独立的生产者。

1.2 “下班它加班”的核心不是快，而是异步

很多人看到“你下班它加班”会觉得，这不就是让 AI 晚上跑任务吗。但我实测下来，真正核心的其实是“异步”。以前的 AI 编程工具是同步的，你坐在终端前，看着它一条条输出，它卡住了你也不知道该不该打断。这种体验很像电话客服，你必须在线等待。

dots 把这件事改成了发工单。你下午五点把任务提交上去，它自己安排执行。你去开会、写文档、或者干脆关电脑回家，它还在云端跑。第二天早上打开电脑，任务状态已经从“执行中”变成“已完成”，旁边躺着一条带测试结果的改动记录。

这种模式特别适合几类活儿：一是 CI 失败的修复，白天跑出来的报错，晚上丢给 dots 分析；二是依赖升级，把一个大版本升级涉及的兼容性问题交给它慢慢磨；三是批量重构，比如给全项目换日志库，这种机械但量大的工作，人类盯着做容易疲劳，AI 反而适合连续干。它本质上就是一个“不会下班的远程程序员”，而你不需要陪它加班。

2. 为什么需要把 AI 放在云端：设计逻辑与取舍

如果说 dots 的亮点是“常驻云端”，那就要问一句：为什么一定要放云端？放在我自己的电脑上，让它跑一宿不是也行吗？这里面的取舍，值得好好拆一拆。

2.1 云端工位的四个关键优势

第一，环境一致性。本地开发环境千奇百怪，有人在 macOS 上，有人在 Windows 上，还有人用 Docker 都懒得配。遇到“我本地能跑，你机器上跑不了”的问题，AI 排查半天可能都找不到原因。dots 在云端跑，它的环境是你预先定义的统一沙箱，比如 Python 3.12 + PostgreSQL 15 + Redis 7，所有任务都在这个环境里执行。它把“环境问题”从 AI 的工作清单里几乎删掉了。

第二，上下文连续性。这个前面提过，但值得再展开一下。本地工具每个会话都是“失忆”的，而 dots 的云端工位保存了 shell 历史、文件变更、命令输出。我上次让它给项目加日志模块，这次再让它写相关的测试，它会直接说“我知道你上次用的是 loguru，所以这次测试也是按 loguru 的写法来的”，这种连贯感非常有用。

第三，可协作性。本地执行的一个问题是，AI 干了什么只有你自己能看到。dots 不然，团队里其他人也可以登录同一个项目空间，看到任务的执行日志、当前状态和产出物。这就像团队里多了一个成员，他的产出是公开可查的。对于远程团队或者开源维护者来说，这种透明度特别重要。

第四，异步与自动化。云端常驻意味着可以定时触发，也可以接外部事件。比如我设了一个每天晚上十点自动执行的小任务：检查主分支上没有 running 的测试，跑一遍，把失败报告写到 issue 里。这些在本地工具上实现起来很别扭，因为我的电脑未必一直开着。dots 常驻云端，天然就是一台 24 小时在线的开发机。

2.2 云端 vs 本地：什么时候该选谁

很多人质疑“所有计算都在云端完成延迟较高”，这不是没有道理。你让它做一个很小的改动，它要先读文件、想半天，再给你输出，交互体验确实不如本地插件顺滑。但 dots 的定位恰恰是把高延迟变成可接受的异步等待——就像你不会用远程桌面的方式开一个只有 100ms 延迟的编辑器，但你不介意给同事发一封邮件，等他下午回复。

所以我的取舍标准不是“哪个更聪明”，而是“这个任务的交互密度高不高”。如果你是在 IDE 里写代码时希望 AI 实时补全、快速解释，那就用本地工具，它跟你的编辑器结合得再紧密也不过分。如果你要把一整个模块重构一遍、写一堆测试、处理历史遗留的兼容问题，这种长周期、高耗时的活，交给云端常驻 Agent 更合适。

另外还有隐私考量。有些代码不方便离开本地，那就不该用云端工具。我一般会把仓库分成两类：核心业务代码留在本地用工具做辅助，重复性较高且不太敏感的业务逻辑才交给 dots。它不是一个全能替代品，而是一个“你受得了异步等待”的任务处理器。

3. 上手实操：如何把任务交给 dots

说了一堆概念，下面聊聊怎么落地。我以自己实际用下来的流程为例，可能和官方最新界面略有出入，但核心路径是稳定的。如果你刚上手，照着这个流程走，基本能顺下来。

3.1 前置准备与登录

第一步是准备一个可以登录 OpenAI/ChatGPT 的账号，dots 的授权方式跟 Codex CLI 一样，都是sign in with ChatGPT。你在命令行里执行登录命令，它会弹出浏览器，确认授权后回填一个 token，之后 CLI 就能用这个身份发任务。

第二步是安装命令行客户端。我自己是用 npm 全局安装的，包名以官方 registry 为准。装好之后跑dots login，按提示走就行。装完先别急着用，执行一下dots doctor或类似命令检查配置，确认账号和网络连通都没问题。

第三步是关联代码仓库。dots 需要能访问你的代码，我一般用 GitHub 的 fine-grained token 授权，权限只开通目标仓库的 contents 和 pull requests，不给他写其他仓库。在 dots 的控制台或配置里把仓库地址和 token 填进去，它会在云端 clone 一份工作副本。这个步骤很多人会忽略权限范围，结果一手滑把整站权限都给了，我后面会说这是大坑。

3.2 一次完整任务：从需求到提交

我拿一个实际任务演示：给一个 Go 服务增加一个GET /healthz接口，返回 JSON 状态，并补一个单元测试。整个流程分五步。

第一步，提交任务。在终端里输入类似：

dots run "请实现 GET /healthz 接口，返回 {'status': 'ok'}，并补充对应的单元测试，要求使用标准库 httptest"

注意，这里不要把整段对话控制权交给它。dots run的语义是“去跑一个任务”，而不是“跟我聊一聊”。

第二步，观察执行。执行dots logs可以看实时日志。你会看到它先列出工作区文件结构，定位到路由注册的地方，然后写代码，再跑go test。这个过程可能需要几分钟，取决于任务复杂度。我第一次看的时候还觉得挺新奇，后来就习惯了，一般不会一直盯着，隔几分钟看一眼就行。

第三步，检查改动。任务完成后，执行dots diff查看它改了什么。如果改动符合预期，可以执行dots pr让它直接生成一个 Pull Request；如果不满意，可以在任务后面追加指令，比如“刚才的方式不符合项目规范，改用 httptest.NewServer 再试一次”。

第四步，人工审查。别的都可以自动化，这一步我不建议省。把 PR 拉到本地或者直接在 GitHub 上看 diff，重点关注它的边界处理和错误路径。AI 写的代码往往主路径很漂亮，但异常分支容易偷懒。

第五步，合入。确认 CI 通过后，人工点 merge。我的习惯是 dots 只负责开 PR，不直接推主分支，合入权始终留在人类手里。这样即使它写错了，影响范围也可控。

3.3 给 AI 写任务书的模板与技巧

dots 这类云端 Agent 对任务描述的敏感度，比我们想象中高得多。给得太模糊，它就会自由发挥，最后给你一个“看起来对了但方向不对”的结果。我自己整理了一个任务书模板，基本每次都会照着填。

任务目标： 在 xxx 模块中增加 yyy 功能，解决 zzz 问题。 验收标准： - 新增接口返回数据格式符合 xxx 规范 - 单测覆盖率达到 80% 以上 - 现有测试全部通过 约束条件： - 不要改动 xxx 文件 - 不要引入新的第三方依赖 - 沿用项目现有的错误处理方式 相关文件： - 入口文件：cmd/server/main.go - 路由文件：internal/router.go - 测试文件：internal/handler_test.go 交付形式： - 打开一个 Pull Request，标题和描述按项目规范填写

把这份任务书直接粘到dots run后面的引号里，它输出的结果质量会高一个台阶。核心原因是：它不需要猜你的意图，可以把全部精力放在执行上。

还有一个技巧，不要一上来就让它干活。可以先跑一次dots plan，只让它输出实施方案，你过目确认后再跑dots run。很多云端 Agent 工具都支持这种“先计划后执行”的模式。我实践下来，这样可以减少大概一半的无效执行，节省的 token 都够再开几个任务了。

4. 运营一个云端 AI 员工的避坑指南

用云端 Agent 就像带一个悟性不错但经验不多的新人：干得好是真省心，干砸了也是真添乱。我整理了几个经常踩的坑，每一个都是实打实付过学费的。

4.1 我遇到过的 6 个典型问题

第一个坑我印象最深。一开始我不懂，就让它处理一个仓库，结果它每次跑任务前都要把所有依赖重新装一遍，一个 Go 项目装二十分钟，浪费大量时间和配额。后来我把依赖缓存挂到持久目录，任务速度才正常。

第二个坑是上下文丢失。我让它重构一个模块，中间有事离开了一下，回来发现它在其他文件里顺手改了一堆东西。不是它不听话，而是它的上下文窗口有限，我最初说的约束条件在后面的执行中“被遗忘”了。所以我现在会把最重要的三条约束直接写进任务书的核心位置，而不是在聊天记录里反复强调。

4.2 权限、安全与代码审查红线

云端 AI 比本地工具多了一个远程执行属性，所以安全边界要认真划。我个人有三条红线：

第一条，密钥和 token 绝不能写进任务描述。你可能觉得一句“用数据库密码 xxx 连一下”没什么，但任务日志可能会被记录下来。正确做法是用环境变量注入，让 Agent 从运行环境里读，而不是从文本里抠。

第二条，权限遵循最小化。给 dots 的 GitHub token 只开通目标仓库的读写权限，最好也不要求 admin 权限。能用contents:write+pull_requests:write解决的问题，绝不给workflow权限。否则它一个手滑把 workflow 文件改了，问题就很麻烦。

第三条，AI 生成的代码必须人工审查，尤其是涉及命令执行、文件删除、外部网络请求的部分。我有一次让它加一个文件下载功能，它直接用了还没校验路径的代码，差点把目录打穿。这种问题模型很难自行发现，只有人工 review 才兜得住。

另外建议设置分支保护：dots 开的 PR 必须有一个真人批准才能合入，而且 CI 必须全绿。虽然流程上多了一道手续，但安全冗余很重要。

4.3 成本与任务编排建议

云端 Agent 是要花钱的，而且长任务花的钱比想象中多。我刚开始用的时候，一个不带约束的重构任务跑了几十分钟，账单出来让人肉疼。后来我养成了两个习惯。

第一个习惯是大任务先拆小。把“重构整个服务的错误处理”拆成“先把 A 模块的错误处理统一”“再把 B 模块统一”，每个任务独立跑，跑完看效果再继续。这样即使某一个子任务跑偏了，损失也可控。

第二个习惯是给任务设置明确的中止条件。比如 “如果发现需要改动的文件超过 20 个，请停下来报告，不要继续执行”，或者 “如果测试未通过，最多重试 3 次，然后输出失败原因”。这些条件能有效避免 AI 在一棵树上吊死，反复试错烧钱。

编排多个任务时，我的建议是不要让多个 dots 实例同时改同一个仓库的分支。它俩互相不知道对方的存在，很容易在同一个文件里产生冲突。可以让两个任务跑在独立的分支上，最后你来合；或者让它们分别负责不同目录，互不干扰。

5. 从 dots 到多 AI 协作：我的几点实践体会

dots 这个产品只是起点。真正有意思的是它背后的那个模式：一个常驻的、有记忆的、能调用工具的 AI 员工。这让我开始认真思考多 AI 协作是怎么落地。

5.1 让多个 Agent 分工

我们现在习惯的是一个 AI 处理一个任务，但真实项目里任务是有依赖关系的。比如一个需求涉及后端接口、前端页面和测试，你可以开三个 dots 任务，分别给后端、前端、测试各派一个工单，要求它们遵循同一份接口文档。

关键是让它们共享一份明确的接口契约。我在实践里会先把 API schema 定义好，放在仓库的一个api/contract.yaml文件里，然后每个任务都引用这个文件。后端 Agent 按这个 schema 实现接口，前端 Agent 按这个 schema 调接口，测试 Agent 按这个 schema 写断言。只要契约不变，三个 Agent 同时干活基本不会打架。

这种多 Agent 协作的收益不是简单“三倍效率”，而是大大压缩了串行等待的时间。以前要等后端做完，前端才能动手；现在两边可以同时进行。当然，如果契约中间发生变更，协调成本也会上来。所以一开始最好花时间把契约定细致点。

5.2 AI 工程化的下一步

代码生成只是 dots 这类产品最直观的落地场景。它底层的模式——持久上下文、云端沙箱、异步任务队列、工具调用权限——其实可以平移给很多领域。比如数据分析：你给它一个数据目录和几个问题，它自己写 SQL、调 Python、产出图表。比如日常运维：让它每天自动巡检日志，发现异常就汇报。

我对 AI 工程化的一个体会是：不要总想着让 AI 一步到位产出最终结果，而是把它当成一个有工位的协作者，设计好任务边界、验收标准和反馈回路。工具会越来越强，但你对任务的拆解能力，才是决定产出质量的上限。

最后分享一个小技巧。我会在项目里建一个tasks/文件夹，把每次提交给 dots 的任务描述、执行结果、踩过的坑都存成 markdown 文件。时间长了，这里会积累出很多“这个项目的隐性知识”。新来的同事不用问人，先翻这个文件夹就能了解很多前因后果。我甚至会让 dots 在开始新任务前先读一遍这个文件夹里的相关记录，避免它重复踩我们踩过的坑。

这个思路，比单纯追求一个更强的模型更让我兴奋。AI 不是一次性工具，而是一个可以沉淀经验的团队新成员。