OpenAI DevDay 2026 的回放，我前前后后看了两遍，又把 release note 逐条过了一遍。20多项发布里，真正值得开发者上手的，其实就三件事：dots、ChatGPT Spaces、GPT-6.1 Sol。其他大多是既有功能的顺滑升级，但这三者合起来，正在悄悄改变我们写代码、管上下文、跑 Agent 的方式。这篇文章不打算给你把发布会从头到尾复述一遍，而是想聊聊我作为一线开发者最真实的拆解和实践记录，包括哪些东西值得立刻试、哪些最好再等等，以及我在上手过程中踩过的坑。

1. 先聊整体：20多项发布背后的主线

1.1 三个关键词，一条主线

发布会上的名字很多，但主线特别清晰：OpenAI 不再只卖“一个更强的模型”，而是在搭一套让开发者能稳定跑通 Agent 任务的基础设施。GPT-6.1 Sol 是这套设施里的推理底座，dots 是任务在代码仓库里的执行节点，ChatGPT Spaces 则是让这些 Agent 和人类团队共享上下文的工作区。

把这三样拼在一起看，你会发现它们其实在解决同一个问题：过去我们用 AI 聊天、补丁式地生成代码，但没法让 AI 长期盯住一个项目、记住上下文、按权限行动。DevDay 2026 的所有发布，几乎都在朝“AI 协作者”这个方向补位。模型负责理解与生成，dots 负责把理解变成 repo 里可追踪的改动，Spaces 负责把人、Agent、文档和运行记录放进同一个持久化空间。

1.2 用三个分类整理发布会内容，心里才有底

20多项发布听起来吓人，但按用途拆成三堆就好记了。

第一堆是模型层：以 GPT-6.1 Sol 为代表，还包括新一代的 embedding 模型、实时语音模型的小版本升级。Sol 最明显的进步不在排行榜参数，而在长时间任务里的指令遵循和工具调用稳定性。

第二堆是开发工具层：dots、Muse、Codex 的更新、API 结构化输出增强、Prompt Caching 自动生效、新的可观测性面板。这些是开发者真正每天会碰的东西，也是这场发布会含金量最高的部分。

第三堆是协作与平台层：ChatGPT Spaces、团队共享权限、审计日志、企业合规相关能力。这层看起来很“软”，但决定了 AI 能不能真正进入正式项目的交付流程。

我习惯先按这个三分法把更新归类，再决定哪些进我的 side project，哪些等客户有需求再说。盲目把所有新功能都接进生产环境，是我见过最多人犯的错误。

2. dots：从命令行里长出来的 Agent 节点

2.1 什么是 dots，它到底在解决什么问题

dots 这个名字我看第一眼没反应过来，后来看演示才明白：它把 Agent 的执行过程拆成一个个可命名、可复用、可共享的“节点”。每个 dots 对应代码仓库里的一个原子任务，比如“修掉这个函数的类型错误”“给 user-auth 模块补测试”“分析这个 issue 的根因并提出方案”。

你可以在终端里运行一个 dots，也可以把多个 dots 串成一条工作流，让它们在 CI 或本地按顺序执行。和普通脚本不一样的是，dots 背后有模型驱动，能感知上下文变化，而不是机械地跑固定命令。我试下来的感觉是：它比一个巨大的自动补全工具更克制，但比单纯聊天式编程更工程化。

它能解决的问题很实际：过去你让 ChatGPT 生成一段代码，还得自己复制、粘贴、验证。现在 dots 直接在仓库里操作，生成 diff、跑测试、汇报结果，改动全程有记录可回滚。相当于把“建议”升级成了“提交”。

2.2 从安装到运行第一个 dots：实操记录

先说安装。我是在 macOS 的 Node 20 环境下试的，命令很常规：

npm i -g openai-dots dots --version dots init

dots init会引导你选择默认模型、登录方式和仓库工作目录。登录可以用 ChatGPT 账户，也可以用 API Key。这里我特别提醒一句：如果你用 API Key，务必通过环境变量传入，不要写进项目配置文件。我见过有人图方便把 key 写进.env然后随手提交到公开仓库，几分钟后 key 就被刷爆了。

初始化完成后，我创建了第一个 dots，目标是修复某个函数的状态竞争问题：

dots create "fix race condition in session store" --target backend/session

它会自动分析代码结构，生成一个带上下文的执行节点。运行这个 dots：

dots run fix-race-condition

执行过程中，dots 会调用 GPT-6.1 Sol 做推理，然后生成候选补丁，跑单测，最后输出一个简洁的报告。第一次跑通大概花了两分钟，比我自己手写补丁再验证要快不少。

但你也别指望 dots 每次都完美。我建议第一次使用先在独立分支上跑，仔细 review 生成的 diff，再合入主干。它更像一个高效的结对程序员，而不是可以完全放权的机器人。

2.3 dots、Muse 和 Codex 是怎么分工的

DevDay 2026 上 dots 经常和 Codex、Muse 一起出现，很多人搞不清三者的边界。

Codex 是 OpenAI 的命令行编码 Agent，负责接收自然语言指令并执行多步骤编码任务，这次更新重点是支持 ChatGPT 登录和更深的仓库理解。Muse 则是一个更偏交互与语音的产品，可以用自然对话的方式驱动 IDE 或终端里的 AI。dots 和它们的关系，我理解是：Codex 负责“做”，Muse 负责“听和说”，dots 负责“留下可复用的任务节点”。

举个例子，我可以对着 Muse 说“把昨天那个登录超时问题再过一遍”，Muse 理解后唤起 Codex 去仓库里排查，同时把过程封装成一个 dots。下次其他人只需要调用这个 dots，就能复现同样的排查和修复流程。这个组合比“每次都用自然语言重新描述一遍”高效得多，特别是团队里有新人时，dots 本身就成了文档。

3. ChatGPT Spaces：把对话升级成协作空间

3.1 Spaces 和普通会话的本质区别

ChatGPT Spaces 在发布会上的定位是“Agent 时代的工作区”。普通会话是一次性的：聊完就散，上下文一长就乱。Spaces 则是持久化的容器，里面可以放多个 Agent、多个对话线程、共享文件、项目文档，甚至绑定外部代码仓库。

你可以把它想成一个小型办公室：走廊（chat thread）、会议室（group context）、档案室（shared files）、门禁（permissions）都齐全了。不同 Agent 在 Space 里各干各的活，但能读到同一个项目背景，不会出现“这个 Agent 不知道另一个 Agent 刚改过什么”的尴尬。

我实测下来最舒服的一点是，Spaces 让长周期任务变得连贯。以前我维护一个开源项目，每天都要重新给 AI 解释项目结构、依赖关系、历史决策。现在这些全部放进 Space 的静态上下文里，新开的每个 Agent 都默认携带这些信息，节省了大量重复描述的时间。

3.2 三种实用组法，建议直接抄

根据我这几天把 Spaces 用进真实项目的经验，有三种组法最值得模仿。

第一种是个人项目空间。适合独立开发者接自己的 GitHub 仓库。我会把 README、架构说明、最近的 issue 列表放进去，再挂一个负责“代码审查”的 Agent。每次 push 后让 Agent 审查 diff，把问题直接写在 Space 里的一个固定线程中。相当于免费请了一个只读 reviewer。

第二种是团队协作空间。适合 3-10 人的小团队。把成员按角色分配权限：开发者可以触发 Agent 运行，非工程岗只看结论。这个空间会和 CI 系统打通，每次构建结果自动汇总。团队共享的上下文是长期积累的：几个月后，新成员加入时甚至能通过 Space 的摘要快速熟悉项目背景。

第三种是对外发布空间。适合做开源项目维护者。你可以把 Space 设置成“访客可读”，让社区用户看到某些 Agent 的分析结论，同时限制他们不能触发写入类操作。这既透明又安全。我在自己的一个开源仓库上试了访客模式，反馈收集反而更集中了。

3.3 搭建 Spaces 的注意事项

搭建 Spaces 时有几个容易忽略的细节，我吃了亏才总结出来。

第一，权限别贪大。默认给 So 或 Admin 权限会让 Agent 直接修改主分支。建议先给 Agent 新建分支的权限，审查通过后再合并。

第二，静态上下文要克制，不是越多越好。我一开始把所有历史文档都塞进去，结果 token 消耗飙升，响应速度也变慢。后来只保留“当前架构说明+最近两周的决策记录”，效果反而更好。

第三，注意会话数据的敏感性。Space 里的对话、上传文件、Agent 中间结果都可能包含敏感信息。如果你需要把 Space 分享给外部协作者，一定先检查是否挂载了不应公开的文档。DevDay 上提到的审计日志和权限策略，正式项目里建议全部开启。

4. GPT-6.1 Sol：模型面世后的开发者视角

4.1 Sol 强在哪：工具调用和长任务执行

GPT-6.1 Sol 是这次发布会的主角模型。名字里的 Sol 不是太阳，而是强调“单点执行能力”的新系列标识。官方给的指标很多，但我作为实际使用者，最明显的感知是它在长任务链条中的稳定性。

举例来说，之前让模型完成“分析 issue→改代码→跑测试→提交 MR→写总结”这条流程，经常在第三步或第四步出现“断片”：要么工具调用参数格式出错，要么忘了前面某一步的结果。用 Sol 跑同样流程，成功率提升很明显。尤其是工具调用，它面对多步骤工具链时，不再频繁地反复确认，而是能合理规划执行顺序。

另一个提升是上下文长度的利用效率。Sol 的上下文窗口继续扩大，但更关键的是，它会更主动地“遗忘”不重要的早期内容，而不是把所有 token 都塞进注意力里。这听起来抽象，实际体验就是：用一个很长的 Space 背景跑任务，它的响应质量和速度比上一代更稳。

4.2 API 接入、价格与限流速览

DevDay 公布的价格与模型参数，我整理了一张速览表，方便你参考：

接入方式还是 OpenAI 的标准 Python SDK，但模型名变成了gpt-6.1-sol。一个最基础的调用长这样：

from openai import OpenAI import os client = OpenAI(api_key=os.environ["OPENAI_API_KEY"]) resp = client.responses.create( model="gpt-6.1-sol", input="分析当前仓库中 user-auth 模块的潜在安全风险，输出 JSON 报告。", tools=[{"type": "codex", "target": "repo://backend/user-auth"}] ) print(resp.output_text)

注意我用的是responses.create而不是老的chat.completions.create。今年 OpenAI 官方已经明确建议迁移到 Responses API，Sol 的很多新特性也只在这个接口上完整可用。

成本方面，缓存价格降得很猛。如果你的 Space 挂着大量只读上下文，建议开启自动缓存，长任务成本能降一半左右。

4.3 老项目迁移 Sol 的三个检查点

如果你已经有一个基于旧模型的应用，迁移到 Sol 前建议先查三件事。

第一，提示词里有没有依赖旧模型的“怪癖”。比如有人习惯在 prompt 里加“请仔细思考”，旧模型可能因此更谨慎，但 Sol 会准确执行，行为反而显得有点啰嗦。跑通测试后，把这类 prompt 精简掉就行。

第二，工具定义是否还匹配。Sol 对工具调用的 schema 验证更严格，以前一个含糊的参数描述可能也能跑，现在可能会被拒。建议重新用官方工具转换脚本校验一遍所有 function schema。

第三，流式输出和缓存的行为是否影响前端。Sol 的流式输出 token 节奏和旧版有差异，依赖“打字机效果”的产品需要微调缓冲逻辑。我就在一个聊天前端里发现 Sol 的流式输出很快，前端渲染有点跟不上，最后加了个小队列解决。

5. 除了三大件，还有哪些容易被忽略的福利

5.1 API 层的隐形升级

三大件之外，这次发布里 API 层的几个小改动其实很实用。

首先是结构化输出增强。以前让模型输出 JSON 偶尔还是会跑出多余文字，这次新版本在 Schema 约束上做了严格保证。我测试了一个要求输出数组嵌套对象的场景，20次调用全部格式正确，没有一次 escaping 事故。

然后是 Prompt Caching 自动生效。以前需要手动配置缓存策略，现在只要上下文前缀超过一定长度，系统会自动复用缓存。对 Spaces 这种挂大量固定上下文的产品，这是成本上的重大利好。

还有实时语音 API 的兼容性改进。OpenAI compatible speech 这次的更新解决了低延迟场景下首字延迟偏大的问题。做语音助手的团队可以关注一下，迁移成本不高，但体验提升明显。

5.2 可观测性和调试工具

过去用 Agent 最头疼的是：它做了几步、为什么这么决策、中间每一步消耗了多少 token，全是一个黑盒。这届 DevDay 补上了这块短板，提供了新的 Trace 面板。

我具体在做的是把 dots 的每次执行都接到 Trace 面板上。这样每个任务节点的输入、工具调用、模型响应、耗时、成本全部可视化。排查问题时，我不再需要靠猜，直接看 trace 就能定位是哪一步的 tool call 出了错。

发布会上的一句话我印象很深：“如果 Agent 的行为不能审计，就不要让它进入生产环境。”工具链现在把可观测性作为一等公民，这是非常务实的进步。

5.3 API Key 和会话数据的安全提醒

今年很多开发者都在讨论 API Key 的管理，DevDay 上也强调了凭证安全。这里我结合最近社群里的一个高频问题“泄露了 OpenAI 账号会话 JSON 怎么办”，给你一套标准的应急流程。

如果你发现自己的会话数据、API Key 或登录凭证可能泄露，第一件事不是删库跑路，而是立刻去 OpenAI 后台吊销相关 Key，再重新生成。第二步，检查所有被共享的 Spaces 或文档，撤销可疑的协作链接。第三步，查看最近的用量记录和审计日志，确认有没有异常调用。最后，如果泄露的是完整账号会话 JSON，建议同时注销所有设备 session，强制重新登录。

这些操作听起来琐碎，但真出事的时候能省下很多麻烦。我也建议养成习惯：API Key 统一放环境变量或密钥管理服务，不要出现在任何会被同步到云盘的代码文件里。

6. 实操记录：踩坑与排雷

6.1 安装 Codex/dots 时遇到 optional dependency 报错

我在 Windows 环境装 Codex 时碰到一个很典型的报错，大意是“missing optional dependency @openai/codex-win32-x64. reinstall codex: npm install”。当时一度怀疑自己的 Node 环境有问题，后来排查下来发现是 npm 可选依赖下载不完整。

解决办法是三步走：先清掉 npm 缓存，然后强制重装相关二进制包，最后检查 Node 版本是否在官方支持范围内。

npm cache clean --force npm install -g openai-codex@latest node -v

如果你是 npm 锁文件导致的问题，可以删除node_modules和package-lock.json后重新安装。这类平台相关的可选依赖报错，最直接的判断方法是用 verbose 模式看是哪一步卡住，再对症下药。

6.2 把 dots 塞进现有 CI 的节奏建议

dots 很好用，但我不建议第一天就把它放进核心发布流程。更稳妥的节奏分三步。

第一阶段，本地启用 dots，只处理“建议类”任务，比如代码风格修正、生成单元测试模板。人工 review 后决定是否采纳。

第二阶段，把它接入 CI 的判断辅助流程。比如在 PR 阶段增加一个 Agent 分析任务，对变更文件做影响面分析。这个阶段 dots 只输出报告，不直接提交，风险可控。

第三阶段，等准确率稳定后，再开放到“自动修复并提交”的权限。即便如此，也需要设置分支保护和 reviewer 的人机协同机制。这样既能吃到 Agent 带来的效率红利，又不会因为一次误操作搞坏主干。

6.3 我最大的心得：工具要跟着工作流走，不是反过来

折腾了几天新发布的功能，我最想说的其实是句老话：工具应该跟着工作流走，而不是让工作流反过来适配工具。

dots 再强，如果你的团队本来就不习惯代码评审，那它只会帮你们更快地生成一堆需要评审的 diff。Spaces 再好，如果项目文档本身一塌糊涂，它也只是一个漂亮的垃圾箱。所以我的建议是，先把一个真实痛点和现有流程写清楚，再挑选 DevDay 发布里能补位的工具，小步验证。

我个人实际用过之后，最稳的组合是把 Spaces 当项目知识库底座，让 GPT-6.1 Sol 负责复杂规划，dots 去执行具体的仓库操作。这三者各管一段，形成了一条清晰、可审计的链路。剩下的 20 多项更新，等真需要时再回头翻 release note，也完全来得及。