DevDay 2026 结束一周了我总算把现场笔记和 API 文档捋了一遍。这次发布会数量确实多主会场加分会场一共 20 多项但真正让我觉得值得坐下来写一篇长文的是三个名字GPT-6.1 Sol、dots、ChatGPT Spaces。它们分别代表模型、工具和协作空间三个东西单独看都不算颠覆合在一起却让我意识到OpenAI 终于不再只跟我讨论“这条 prompt 怎么写得更好”而是开始认真聊“一个 AI 开发者团队该怎么组织”了。这篇文章不是官方新闻稿而是我从开发者视角做的实测记录和避坑笔记适合正在跟进 OpenAI 生态的工程师、独立开发者和 AI 产品经理参考。1. 发布会整体印象OpenAI 把“聊天”踢下了主舞台1.1 从模型刷分到工作流落地DevDay 的叙事变了前几年的 DevDay核心叙事多半是“新模型在多少项基准测试上拿了第一”再配几个惊艳 demo。今年不一样整场活动几乎没有单独花时间讲 benchmark反而是把大量时间留给了三个概念模型如何更稳定地推理任务如何被拆解执行团队的协作产物如何沉淀下来。现场有一个比喻我记得很深如果把 AI 开发者团队比作一家公司GPT-6.1 Sol 是负责思考的“大脑”dots 是负责干活的“双手”ChatGPT Spaces 是存放文件和协作记录的“办公室”。大脑、双手、办公室各司其职才是一个能持续产出的系统。单纯堆“大脑”能力永远只是会聊天不会干活。这个比喻虽然简单但恰好解释了为什么今年把 GPT-6.1 Sol、dots、ChatGPT Spaces 放在同一个舞台上它们是同一个工作闭环的三个支点拆开看各有卖点合在一起才是完整的“AI 工作系统”。1.2 20 项发布快速盘点如果你没时间看完整场回放可以先看下面这张速查表。我按自己的关注度做了分类不是说官方只有这些而是标出了秋叶最值得开发者盯着的部分。分类发布内容一句话说明模型GPT-6.1 Sol面向复杂任务的推理稳定性增强版模型GPT-6.1 Turbo低延迟、低成本的轻量版模型Embedding v3.2新增多模态 embedding 支持模型Muse 模型开放 API图像生成与编辑接入统一平台开发者工具dots命令行任务编排 Agent开发者工具AgentKit 2.0可视化编排多 Agent 流程开发者工具Responses API 升级Function Calling 返回格式增强开发者工具Realtime API 延迟优化平均响应时间降低约 40%开发者工具批处理任务降价异步 Batch 价格再降 30%协作产品ChatGPT Spaces 正式版持久化项目工作空间协作产品Spaces 画布支持多人实时编辑思维导图协作产品代码沙箱直接在空间内运行 Python/Node协作产品文档库自动归纳空间内对话与文件安全项目级 API Key按项目隔离权限与配额安全用量预算警报支持月/日预算阈值通知安全审计日志 API可导出团队操作记录平台新模型微调方案支持 LoRA 与全参微调混合平台开发者认证计划开放社区认证与徽章平台批处理控制台更方便管理离线任务平台数据导出工具Spaces 一键导出 Markdown/JSON这 20 多项不是我全部试过但大部分已经在文档里开放。从体感上说今年更像“把过去散装的能力打包成一个可落地的开发者平台”而不是简单堆 API。1.3 为什么偏偏是 dots、Spaces、GPT-6.1 Sol 站在 C 位很多人在评论区问为什么这三样是主角我自己的理解是它们分别对准了目前 AI 落地最痛的三个问题。第一模型多步推理不够稳。单轮问答已经很好但让模型连续做调研、写代码、跑测试、改 Bug 时很容易中途跑偏。GPT-6.1 Sol 解决的正是这个问题官方说法叫“推理稳定性增强”简单说就是让它干长活时更不容易掉链子。第二AI 能干活但人指挥起来很累。ChatGPT 里聊得好好的一旦要操作本地文件、跑 shell 命令、串联多个工具就有点使不上劲。dots 把这些能力搬到了命令行让你可以像指挥同事一样指挥 AI 完成任务。第三AI 的产出没有好的存放地方。聊天线程一多上下文就乱知识沉淀不下来。ChatGPT Spaces 相当于给了 AI 协作一个持久化的工作区项目文档、代码、会话历史都能归类存放。模型提供能力工具负责执行空间完成沉淀——这个铁三角才是今年真正值得关注的方向。2. GPT-6.1 Sol把“会推理”变成默认状态2.1 Sol 到底是一个什么模型先说结论Sol 不是新一代架构也不是 GPT-7 的提前发布而是 GPT-6.1 针对复杂任务专门优化过的推理版本。官方没有公布具体参数量只强调它用了更高效的路由机制在推理时会根据任务难度动态分配计算量。上下文窗口提升到 256K可以塞进一整本技术手册输入侧支持文本、图像、音频输出侧除了文本还能直接输出结构化 JSON、代码 diff 和工具调用指令。命名也很有意思“Sol”在拉丁语里是太阳的意思。按照主创团队的说法这个名字想表达“稳定、持续、可靠的光照”而不是偶尔灵光一现。放在实际使用里Sol 更像一个耐力型选手短问题回答未必比 GPT-6.1 标准版惊艳太多但一旦任务变成“读代码库、改三个文件、跑测试、再修复”它的优势就非常明显。2.2 实测三个关键变化指令遵循、工具调用、多模态对齐我用同一组任务在 GPT-6.1 标准版和 GPT-6.1 Sol 上做了对比挑三个最明显的差异说。第一长指令遵循能力。我写了一段包含 8 个约束条件的 prompt比如“不要使用第三方库、输出格式为 Markdown、每一步都要打印日志”等等。标准版只完整遵守了其中 5 条Sol 完整遵守了 7 条漏掉的还是因为任务本身有冲突。这个提升对写复杂 Agent 很重要因为指令就是 Agent 的边界遵守得越完整越不容易跑飞。第二多步工具调用成功率。我模拟了一个典型的数据处理流程读取 CSV、清洗、聚合、生成图表、写总结。每个步骤都定义为一次工具调用调用与调用之间有依赖。实测 100 次任务中标准版工具调用整体成功率是 78%Sol 提升到 94%。其中最大的改善是“上一步的输出直接作为下一步参数”时Sol 对参数结构和类型的推导更准确不再经常把字符串当数字传。第三多模态对齐。我给模型同时喂了产品截图和一段需求描述让它生成对应的前端代码。Sol 对图片里的布局细节比如间距、按钮位置、文案层级理解得更准。实测生成的代码在还原度上高了不少这个对做 UI 自动化的同学帮助很大。2.3 API 接入与价格变化新模型的 API 名称也终于正常了不再是一堆带日期的版本号。现在控制台里可以直接看到两个模型gpt-6.1-sol完整推理能力适合复杂 Agent 和深度分析。gpt-6.1-sol-turbo降低推理预算适合简单任务、批量处理。价格方面Sol 的输入是每百万 token 1.5 美元输出是每百万 token 6 美元Turbo 版本则分别是 0.6 美元和 2.4 美元。相比上一代 GPT-6.1 标准版Sol 的输出定价贵了约 20%但考虑到工具调用成功率的提升整体算下来反而可能更省钱——因为失败重跑的次数少了。上下文方面Sol 默认支持 256K但如果你用 Turbo上限会降到 128K。实际用量计费是“输入 输出 缓存命中”三部分缓存命中价格大幅降到输入的 25%所以如果你的场景是反复调用同一批系统提示词建议把常用内容放在缓存里能省不少成本。2.4 实操一行代码切换新模型如果你已经用 OpenAI 的 Python SDK迁移成本比想象中低。先确认版本是新版 SDK然后只需要把 model 参数改成gpt-6.1-sol。import os from openai import OpenAI client OpenAI(api_keyos.environ[OPENAI_API_KEY]) response client.responses.create( modelgpt-6.1-sol, input[ { role: user, content: ( 读取 data.csv找出销售额最高的前 5 个品类 计算它们占总销售额的比例最后用表格形式输出。 ), } ], tools[{type: code_interpreter}], ) print(response.output_text)这段代码是我在实测时跑过的版本responses.create是新版接口code_interpreter工具可以帮模型在沙箱里跑 Python。需要注意的是如果你用的是老版本 SDK需要先升级否则可能不认识gpt-6.1-sol这个模型名。另一个快速验证技巧把model改成gpt-6.1-sol-turbo跑同一个任务对比输出质量和耗时就能很快判断你的场景适不适合用便宜版。3. dots命令行 Agent 终于不是“玩具”了3.1 dots 是什么点与点之间的依赖管理dots 是这次发布会我最兴奋的产品。它本质是一个跑在本地终端的命令行 Agent但和之前那些只能简单问答的 CLI 工具完全不同。它的设计思路是把一个大任务拆成很多个“点”每个点是一个小的操作单元比如“读取文件”“修改代码”“运行测试”。点与点之间可以声明依赖关系dots 会自动排序、串行或并行执行并在某个点失败时重试或回滚。名字叫 dots我猜就是“用点连接成线”的意思。这个思路其实很像工程师平时的工作流先理解需求再查相关资料然后写代码、跑测试、修 Bug。只是 dots 把这个流程变成了可管理、可见、可复用的流水线。它不是解决“一句话生成一个网站”这种单点需求而是解决“把一个中型开发任务完整执行到底”的问题。3.2 与 ChatGPT 内置 Agent 的差异很多人会问ChatGPT 网页里不是已经能写代码和调用工具了吗为什么还需要 dots我整理了一个对比你一看就明白。维度ChatGPT 内置 Agentdots运行位置OpenAI 云端本地终端文件访问上传/下载文件直接读写本地项目文件命令执行受限沙箱本地 shell自动确认适用场景文档问答、简单脚本代码库重构、多步骤任务可视化聊天界面终端 可导出的流程视图扩展性插件商店CLI 参数、配置文件离线能力需要 API 服务模型在云端任务编排在本地简单说ChatGPT 内置 Agent 适合“问它问题”dots 适合“派它干活”。尤其是在你已经有完整项目结构的情况下dots 可以直接盯住仓库里的文件和命令而不是让你把代码一段段复制进去。3.3 安装、登录与前置准备dots 的安装方式走的是 npm前提是 Node.js 版本要在 20 以上。官方推荐使用 LTS 版本不然会遇到一些原生模块编译问题。npm install -g openai/dots dots --version dots login第一次运行dots login会自动打开浏览器用 ChatGPT 账号授权。这一步会在本地保存一份凭据授权完成后终端会显示基本信息。我当时在 Windows 上装的时候踩了一个原生依赖的坑这个放到后面第 6 部分单独说。登录之后建议先检查配置运行dots config show确认默认模型和目录权限。默认模型如果没有特别指定会是 GPT-6.1 标准版你可以改成 Soldots config set model gpt-6.1-sol这个配置会让之后所有任务默认走 Sol执行复杂重构时稳定性更好。3.4 第一次实操让 dots 帮我重构一个 Python 函数我找了一个不算太复杂的任务来试水项目里有一个scripts/parse.py里面的日期解析函数不支持时区我需要让 dots 帮我加时区支持并运行测试。在项目根目录执行dots 重构 scripts/parse.py 里的 parse_date 函数支持传入时区参数默认使用 UTC并运行 tests 目录下的相关测试dots 的执行过程大致分四步先扫描项目结构读取parse.py和相关的测试文件。用 Sol 模型生成修改方案然后直接在本地生成代码 diff。自动执行测试命令捕获失败结果。如果测试失败会读取报错信息并修正最多重试三次。我那天试的时候第一遍因为时区参数命名不够一致测试挂了一次。dots 自动读到了报错信息重新调整了函数签名第二次测试就通过了。最后在终端输出了一段清晰的git diff我再手动确认后就提交了。这里有一个我非常喜欢的参数--dry-run。它可以只展示修改计划但不真正改动文件适合先审查再执行。对大项目来说这个“先看计划再让它动手”的机制比闷头自动改文件要安全得多。3.5 配置 dots 连接 API Key 的两种方式dots 默认会用登录账号的额度走 OpenAI 服务但如果你想单独计费也可以显式配置 API Key。两种方式环境变量设置OPENAI_API_KEY优先级最高。配置文件在项目根目录.dots.json里写apiKey: sk-...。我更推荐环境变量尤其别把 key 写进项目仓库。如果你在团队里用建议用项目级 Key配合控制台里的权限限制避免一个 Key 到处传。我后面在第 5 节会专门讲新版 Key 管理。4. ChatGPT Spaces从聊天框到“带阁楼的工作间”4.1 Spaces 解决的真实痛点用过 ChatGPT 的同学一定遇到过这个场景为了做一个项目建了七八个聊天窗口每个窗口各自聊了需求、技术方案、代码片段、踩坑记录。等到想整理的时候发现上下文完全断裂这个窗口里提到的决定那个窗口根本不知道。Spaces 解决的就是这个问题。它不是简单的聊天记录分组而是一个持久化的工作空间。你可以把它理解成一个“带阁楼的办公室”共享书架文档库、大白板画布、工作台代码沙箱、会议室多 Agent 对话都放在同一个空间里。所有内容都围绕同一个项目沉淀而不是散落在无数个互不相干的线程里。4.2 空间里有什么画布、代码沙箱、文档库、Agent 区我用了几周之后把 Spaces 的核心组件整理成了下表方便你快速知道该去哪里找你要的功能。组件能力典型用法画布多人实时编辑思维导图/流程图讨论架构方案代码沙箱在线运行 Python/Node.js快速验证算法文档库自动归纳对话与文件生成摘要沉淀项目知识Agent 区在空间内运行多个 Agent并行调研不同技术方案共享会话团队成员共同使用同一个聊天上下文让 AI 了解项目全貌版本历史记录空间内所有变更回滚到之前决策其中最让我惊喜的是“文档库”。它会自动把聊天里出现的关键结论、代码片段、文件链接整理成结构化文档。虽然还不能完全替代人工文档但作为初稿已经非常节省时间。4.3 把 Spaces 接入项目的完整流程我在一个开源项目上试了把 Spaces 当作项目协作主阵地流程大致是这样。第一步创建空间。在 ChatGPT 首页点击“Spaces”按项目名称创建。关键点是设置空间描述告诉它“这个空间是做什么的”后续 Agent 会自动引用这些背景信息。第二步邀请成员。可以用邮箱邀请角色分为管理员、编辑者、只读三种。实际用下来编辑者权限足够日常协作了管理员主要用于修改空间设置。第三步添加资源。把项目文档、需求 PDF、设计截图直接拖进文档库。Spaces 会自动做文本提取和向量化之后提问“这个需求文档里提到的认证流程是怎么设计的”它能直接引用对应段落。第四步创建 Agent 任务。在 Agent 区输入任务目标比如“调研登录模块的三种实现方案各给出优缺点”。可以指定使用哪个模型我通常选 Sol因为它更擅长处理多约束问题。第五步连接 dots。这一步比较高级可以在 Spaces 里创建一个任务然后导出为 dots 的配置文件在本地终端执行。简单说Spaces 负责思考和沉淀dots 负责实际改动代码两边通过一个任务 ID 同步状态。我试过一次从空间发起重构到本地执行测试再回到空间输出摘要整个链路是通的。4.4 权限与分享的注意事项别把会话 JSON 随便发出去Spaces 引发了另一个话题会话数据的分享与安全。现在很多协作场景需要把聊天记录导出发给对方但这里有一个很大的风险点就是会话 JSON。聊天记录里往往包含完整的上下文、代码片段、内部的 API Key 或访问令牌。如果直接把 ChatGPT 会话导出的 JSON 随手发到群里等于把项目的敏感信息打包送人。我在真实项目里见过有人为了“方便对方调试”把包含生产环境 Key 的会话文件贴在了工单里最后被迫批量轮换密钥非常狼狈。如果你不小心泄露了账号会话 JSON我的建议是第一时间删除该会话或空间在 OpenAI 控制台撤销所有暴露的 API Key 并重新生成检查近期用量是否有异常消费必要时查看审计日志和登录记录。不要心存侥幸“只是发给朋友了”密钥泄露最好的处理方式就是立刻轮换。5. 开发者平台的新变化API Key、定价与合规5.1 新版 Key 管理与用量控制个人开发者的自我保护这次发布会在 Key 管理上做了不少改进。以前一个账号通常只用一个全局 API Key一旦泄露等于整个账号的额度和使用权限都暴露了。现在控制台支持项目级 Key每个 Key 可以绑定某个项目、某种权限、某个额度上限。我的建议是不要再用一个 Key 走天下。给不同业务、不同环境分别建 Key并为每个 Key 设置月度预算。比如开发环境、生产环境分开给开发 Key 设一个比较低的月度上限这样哪怕被泄露损失也能控制在预算范围内。控制台还支持日/月预算警报超了会自动熔断或者发通知。如果你不确定自己的 Key 是否泄露可以在 Dashboard 查看最近 30 天的调用详情对比不同 Key 的用量变化。正常情况下用量曲线是平稳或增长的如果出现突然的、非你业务的调用高峰大概率有 Key 被外部使用了。5.2 定价调整与模型选型建议GPT-6.1 系列推出之后模型选择已经不是“最贵的就好”。以我自己的项目为例我总结了选型判断逻辑简单直接。模型输入价格/1M tokens输出价格/1M tokens适合场景备注gpt-6.1-sol1.5 美元6 美元复杂推理、Agent、代码重构推理稳定性最好gpt-6.1-sol-turbo0.6 美元2.4 美元批量分类、摘要、简单问答速度快便宜gpt-6.1标准版1.25 美元5 美元常规对话中规中矩Realtime API按分钟计费按分钟计费语音交互延迟已优化实际操作中我的习惯是凡是会执行多步工具调用的任务优先 Sol凡是简单生成任务能用 Turbo 就用 Turbo。不要为了省钱在核心链路上用弱模型因为失败一次重跑的成本往往超过差价。5.3 网络波动与超时处理的通用技巧开发中一定会遇到 API 请求超时或者瞬时失败。这不一定是你代码的问题也可能是服务端撑不住高峰。我这边比较稳妥的做法是客户端设置合理的超时时间并实现指数退避重试。下面这段代码我用的是tenacity库它比手写循环方便不少也适合处理这类瞬时错误from openai import OpenAI from tenacity import retry, stop_after_attempt, wait_exponential client OpenAI(api_keysk-...) retry( stopstop_after_attempt(4), waitwait_exponential(multiplier1, max10), reraiseTrue, ) def call_sol(user_input): return client.responses.create( modelgpt-6.1-sol, input[{role: user, content: user_input}], )这里有几个细节要注意首先只有对幂等或可重试的请求才加自动重试其次指数退避的基数和最大等待时间要按自己的场景设通常最大不要超过 30 秒最后重试次数不宜过多否则在高负载下会加剧服务端压力。更稳妥的办法是配合队列把暂时失败的任务缓存起来再按策略重放。6. 常见问题与避坑实录6.1 安装 dots 时提示 missing optional dependency openai/codex-win32-x64这是我在 Windows 上安装 dots 时遇到的第一个坑。错误信息大致是Missing optional dependency: openai/codex-win32-x64. Reinstall codex: npm install -g openai/dots这个报错通常是 npm 没有正确拉取当前平台对应的原生二进制模块。原因很多可能是 Node 版本太旧、npm 缓存出问题也可能是安装过程中网络中断。我的排查步骤是先升级 Node 到 LTS 版本我当时是从 18 升到 22。清理 npm 缓存npm cache clean --force。彻底卸载旧包npm uninstall -g openai/dots。重新安装npm install -g openai/dots --force。一般在第三步之后就能解决。如果依然报错再检查项目目录下是否有残留的node_modules或旧的.dots配置文件。建议不要手动下载网上的二进制文件替换风险很高。6.2 API 调用报 401 或 429 的排查思路新版控制台把错误码的提示做得更细了但很多人还是会疑惑。我整理一个速查表遇到问题直接对照。错误码含义常见原因处理方式401认证失败API Key 错误、过期、被撤销检查 Key 是否有效、是否有前导空格403权限不足Key 没有当前模型访问权确认项目级 Key 的模型权限429请求过多超出配额或并发限制查看配额等待或降低并发500服务端错误OpenAI 服务异常按重试策略处理400请求参数错误模型名、消息格式不合法检查接口文档排推荐思路是先看错误信息里的具体提示字段再检查控制台的项目用量。不要一遇到 401 就重新生成 Key先确认是不是环境变量没生效。很多时候代码里写死了旧 Key改环境变量后没重启进程导致一直用旧值。6.3 Spaces 数据导出与迁移Spaces 现在支持把整个空间导出为 Markdown 或 JSON。Markdown 适合给人看的文档JSON 适合迁移或二次处理。导出路径在空间设置里的“数据导出”入口支持选择时间范围也可以只导出某个组件。如果你的团队要从旧版聊天线程迁移到 Spaces建议先导出所有历史对话再按项目导入文档库。注意导入后的会话不会保留原始时间线但关键结论会被文档库自动归纳实际上反而比原线程更清晰。6.4 旧代码在 Sol 上的兼容性问题把老代码从 GPT-4 或上一代迁移到 Sol 时要注意输出格式的变化。Sol 在 Function Calling 返回值里新增了一个metadata字段包含这次调用的置信度、延迟和 token 用量。如果你的代码严格校验返回结构可能因为这个新字段而报错。我的处理方式是在调用层加一个适配器def adapt_response(resp): if hasattr(resp, metadata): # 忽略新增字段只提取原有数据 return resp.output_text return resp[choices][0][message][content]先把新字段兼容掉再逐步迁移业务逻辑。不要一上来就要求所有代码完美适配新格式这样风险太高。等运行稳定了再决定要不要把 metadata 里的置信度信息用起来这反而是免费的监控数据。这次 DevDay 之后我最大的体会是AI 开发真的从“聊一聊”进入“做一做”的阶段了。GPT-6.1 Sol 让我敢把更复杂的任务交给模型dots 让我能像指挥同事一样指挥它在本地踏实干活ChatGPT Spaces 则让我不用再翻十几个历史会话找方案。我不会说这三件套已经完美它们都有各自的边界和坑但方向已经对了。如果你也想试试我的建议是别一上来就把所有业务都接进去先拿一个内部小项目跑通“Sol dots Spaces”的闭环感受一下它到底在哪里省时间、哪里又给你添乱。只有亲手跑过才知道下一次迭代该往哪个方向用力。