今年的 DevDay 发布会看下来我最大的感受是OpenAI 不再只谈模型参数而是把模型、工作区、开发工具和 API 体验揉在一起讲。20 多项发布如果不做分类很容易看过就忘。这篇文章我把整场内容分成模型层、平台/API 层、开发者工具层、工作区层、治理与安全层五组重点拆解 GPT-6.1 Sol、ChatGPT Spaces、dots 这三样东西最后把我在实测中踩到的坑和上手建议一并写出来。如果你是做 Agent 或 AI 应用的开发者直接看第 2、3、4 节如果你在管理团队或搭基础设施第 6 节的坑列表能帮你少走不少弯路。1. 先看发布全景23 项新东西哪些值得你现在就上手1.1 为什么先看全景最近几年的 DevDay 都有一个共同特点发布的密集程度高到让开发者记不住细节。今年这场同样如此从模型、API 到工作区、开发者工具全都有更新。如果没有一个整体视图很容易被演示视频带偏把注意力放在最炫的技能上而忽略那些真正影响建站和生产流程的底层变更。所以我先把这个全景图摆出来。1.2 按使用场景做分组我照着发布会顺序和自己实际会碰到的场景把 23 项发布整理成了下面这张表。你可以先扫一眼心里有个定位再针对重点项精读后面的章节。分组发布一句话说明我的关注度模型层GPT-6.1 Sol旗舰推理模型显式思考预算极重要模型层GPT-6.1 Flash低延迟快速模型适合工具链较高模型层GPT-6.1 mini轻量模型目标定位成本敏感场景中模型层Vision 2多模态识别能力升级图表理解更强中高模型层Whisper Turbo语音转写延迟大幅下降中平台/API 层Responses API 扩展统一会话对象支持多工具并行极重要平台/API 层Function Calling v2工具选择与参数校验更稳健极重要平台/API 层语义缓存相似请求自动复用计算结果中高平台/API 层Agents SDK 1.2多智能体编排更稳定中高平台/API 层Batch 2.0异步批处理成本更低中高平台/API 层知识 API更简单的文件检索与知识库挂载中开发者工具Codex CLI 1.0 正式版命令行编码智能体ChatGPT 账号登录极重要开发者工具dots点文件与环境配置管理极高会后讨论度黑马开发者工具Codex plan/watch 模式计划模式和文件监听执行高开发者工具GitHub 集成直接处理 issue 和 PR 评审高开发者工具IDE 扩展在编辑器里使用 Codex 与 Spaces较高工作区ChatGPT Spaces持久化工作区极重要工作区Team Spaces团队权限隔离与共享高工作区Spaces API程序化创建与管理空间高工作区Spaces webhooks异步任务状态回调高治理/其他企业审计日志完整行为追踪看行业需求治理/其他用量计费面板重构按空间/项目拆分账单中高治理/其他MCP 更新模型上下文协议工具接入更顺滑中高1.3 三条主线把发布会串成一个故事这个表只是骨架真正有意思的是每一条发布背后的设计取舍。整场发布会没有刻意强调“API 还是 Chat”而是反复出现同一套逻辑上下文、工具、记忆。OpenAI 其实在告诉开发者——以后你不再区分“调用一个模型”还是“使用一个产品”你只需要搭一个空间、挂上工具、选一个模型剩下的交给平台编排。所以我的整体判断是三条主线模型往“深度推理”和“低成本快速响应”两个方向分化GPT-6.1 Sol 负责前者Flash/mini 负责后者。产品形态从“临时聊天会话”转向“持久化工作区”ChatGPT Spaces 是关键落地。面向开发者的 Codex 从实验性 CLI 变成正式生产力工具dots 则补齐了环境管理和团队协作这块短板。如果你平时只碰 Chat Completions 接口今年要花点时间重新认识 Responses API如果你已经在用 Codex 或 Claude Code 这类智能体工具dots 很可能是之后工作流里最值得装的东西如果你是团队负责人ChatGPT Spaces 的出现会直接影响你和队友之间的协作方式。下面我按这三个重点展开。2. GPT-6.1 Sol把“思考预算”做成显式参数的推理模型2.1 Sol 到底是什么它和标准版怎么选先别被名字吓到。Sol 不是全新的基础模型而是 GPT-6.1 系列的推理增强版本OpenAI 内部给它定义的关键词是 stable reasoning——就是那种“宁可多花几个 token 也要把逻辑链条收敛到明确结果”的模型。你可以把标准版理解成“什么都接得住的多面手”把 Sol 理解成“专门用来处理复杂业务规则的思考型选手”。实际使用中最直观的差异在三个地方。第一response 里的修订标记频率明显降低也就是说它对同一个问题的自我否定次数变少了。我拿同一套复杂的数据库 SQL 生成任务跑过对照标准版在高难度样本下经常出现“生成-纠正-又纠正-再纠正”的循环Sol 基本一轮成型偶尔两轮。第二它在长上下文里维持主题稳定性的能力更强比如给它一个 60 万 token 的代码仓库分析任务跑到后段不会忘记最初的约束条件。第三Sol 的输出更长也更有结构喜欢用 markdown 表格、代码块、边界条件清单组织答案这种风格对工程文档特别友好。那什么时候选标准版简单说凡是需要“快”而不是“深”的场景比如意图识别、信息抽取、短文本改写、常规问答用 GPT-6.1 Flash 甚至 mini 就够了。Sol 更适合系统设计评审、复杂迁移脚本生成、故障根因分析、数据管道审计这类任务。一句话别所有请求都切到 Sol成本会替你做选择。2.2 显式思考预算一个真正可调的核心参数这次发布里我认为最重要的模型层变化是把 reasoning budget 做成了用户可控制的显式参数不再只是一个后端隐藏开关。以前你调推理模型只能靠 prompt 去暗示“多想想”。现在你可以直接在请求里写清楚这轮任务允许想多少步、允许生成多少思维 token。from openai import OpenAI client OpenAI() resp client.responses.create( modelgpt-6.1-sol, input分析这段日志链路找出 user-service 和 order-service 之间超时的根因。, reasoning{ budget: high, # 可选 low / medium / high / max max_tokens: 8000, # 限制思考阶段的 token 上限 }, tools[{type: file_search}], ) print(resp.output_text)注意这里 max_tokens 的作用域是思考阶段不是最终输出阶段。我第一版测试时以为它限制的是总输出结果最终答案被截断后来才发现要把最终输出的 token 配额单独放在 max_output_tokens 参数里。这个区分很要命思考阶段的 token 是“内耗”终端用户根本看不见如果不设上限Sol 在极高难度任务里会默默烧掉上万 token 才给出答案。我的建议是先用 medium 预算跑通正常分支把正确率卡在可接受范围遇到失败样本再把那个任务单独升级为 high budget 重试。max budget 我基本只在故障复盘这类不差钱的场景用。2.3 和上一代模型的实际差距不是“更聪明”而是“更省事”很多文章会告诉你推理能力提升多少、评测分数涨了几个点。我作为使用者更关心工程收益以前一个需要写 100 行 prompt 和 5 次工具调用的任务用 Sol 可能只需要 40 行 prompt 加 2 次工具调用就能收敛。原因在于它内置了更强的任务分解能力并且会在多步工具调用后自己总结中间状态不需要你在 prompt 里反复强调“请你记住刚才的结果”。举一个我实测过的例子让模型根据一个包含 200 个字段的 OpenAPI 定义生成一套完整的 TypeScript SDK并要求带重试、带错误类型、带单元测试。上一代模型的做法是输出部分代码然后中断让你补充细节Sol 会先快速扫一遍字段分类把枚举、请求体、响应体分开处理最后一次性给出完整骨架。虽然耗时久一些但中间几乎不需要人工插话。这让“让智能体自己干活”的可行性高了很多。3. ChatGPT Spaces从“临时聊天”到“持久化工作空间”3.1 Spaces 到底解决了什么问题过去用 ChatGPT 处理真实项目最痛苦的是没有“项目”这个概念。你和同一个模型聊了几十轮突然刷新页面、换了一个会话之前的上下文就全丢了。你只能手动复制粘贴背景材料或者用 custom instructions 把背景塞进去但塞得太长模型又会丢重点。ChatGPT Spaces 把“会话”升级成了“工作区”。一个 Space 相当于一个独立的房间里面有固定的项目说明、成员列表、工具挂载、模型配置和历史文件。模型进入这个空间时会自动读取当前空间的背景文档不需要你在每一轮重新自我介绍。听完演示我脑子里冒出的类比是以前是“找朋友聊天”现在是“进办公室干活”。聊天记录、知识文档、工具配置都被绑定在空间里而不是散落在每次对话的临时窗口。3.2 我实测 Team Spaces 时的使用方式我第一时间把一个持续两个月的迁移项目切进了 Team Spaces。整个空间的配置大概是这样的空间名称legacy-to-service / 迁移专用固定背景一份 12 页的架构说明、迁移 checklist、历史上线记录成员三名后端、一名前端、一个只读观察员工具file_search 查资料、codex 执行代码修改、web search 查依赖文档默认模型gpt-6.1-sol简单任务时手动切到 flash日常流程变成我在空间里开一个任务先让模型读取迁移 checklist指出今天做哪一项模型自动从空间背景里提炼约束不会再犯“你怎么不记得我们不用 Redis”这种错误。成员保存的项目文档统一挂在空间里新人进来不用东问西问直接看背景文档加对话历史半小时就能跟上进度。最让我舒服的是空间里的权限粒度可以指定哪些人只能读、哪些人能编辑 prompt、哪些人能看到完整 API 调用日志。企业场景里这比单纯把对话链接发给同事安全得多。3.3 Spaces API把工作区当作普通对象操作对开发者来说真正值得研究的是 Spaces API。它把整个工作区生命周期程序化暴露了出来from openai import OpenAI client OpenAI() space client.spaces.create( nameorder-service-bot, instructions这是一个订单服务重构项目所有方案必须覆盖幂等性。, tools[ {type: codex}, {type: file_search}, ], modelgpt-6.1-sol, members[ {role: admin, user_id: usr_123}, {role: member, user_id: usr_456}, ], ) # 往空间里追加知识文档 client.spaces.files.add( space_idspace.id, filedocs/order-idempotency.md ) # 让空间里的智能体执行任务 thread client.spaces.threads.create( space_idspace.id, input按照最新幂等性约定生成新的下单 API 设计。, )这个设计思路其实把“人机协作环境”和“机器完成任务”统一了。以前写一个自动化办公工具你需要自己存会话、自己管权限、自己拼上下文现在 Spaces API 相当于给你一个托管的工作区后端知识库、工具、权限都封装好了。需要提醒的是目前 Spaces API 走异步任务模型。创建线程后不会立刻返回结果而是返回一个任务 ID你得轮询或等 webhook 回调。如果你习惯普通 chat 接口的同步响应这里会有一段适应期。4. dots一个“小”工具如何变成全场讨论度最高的黑马4.1 dots 不是“点文件同步”是“智能体环境定义”发布会公布 dots 的时候现场和评论区都有点安静因为名字太普通了。但等演示环节结束开发者社区的热度一下就上来了。简单说dots 是一个面向开发环境和 AI 智能体的配置同步工具。它让你把环境配置、工具参数、常用指令、甚至自定义脚本都抽象成一个个可分享的“点”然后用一条命令在多台机器、多个会话里复原。我第一次听到这个概念也觉得“这不就是 dotfiles 管理吗”仔细看过后发现区别很大dots 不只是同步配置文件它把“智能体如何在一个仓库里工作”这件事也定义了。dots 文件里可以声明这个项目使用哪个模型、需要哪些工具、允许智能体访问哪些目录、有哪些质量门槛。相当于给 Codex 这类命令行智能体做了一个项目级的“工作说明书”。4.2 三步上手 dots 的实际操作演示里给的工作流非常直接我复现后确实好用# 1. 初始化一个 dot 集合 dots init # 2. 给当前项目添加规则 dots add codex.instructions --value 提交前必须跑完整条测试链路 dots add tools.allowed --value file_search,bash,codex dots add model.default --value gpt-6.1-sol # 3. 在另一台机器恢复环境 dots apply --profile team/backend最实用的场景是团队协作。以前新同事入职配置开发环境能折腾一整天现在只要拉下项目仓库里的 dots 配置一条 apply 命令就能把模型、工具、代码检查脚本全部准备好。而且 dots 支持 profile 继承你可以在 team/base 之上叠加 team/frontend 或 team/backend避免“一人一份环境、配置互相打架”的老问题。4.3 dots、Codex 和 Spaces 的关系工作流的最后一块拼图我的理解是这次 OpenAI 的布局是Codex 负责干活Spaces 负责承载和管理工作环境dots 负责让不同机器、不同团队的环境保持一致。三者合起来就是一个相对完整的智能体时代工作流。拿我自己的用法举例本地仓库里用 dots 标记项目规则让 Codex 在提交代码前自动跑测试团队共享的 ChatGPT Spaces 里放着项目知识库和长期文档遇到需要深入分析的问题再用 Sol 处理。dots 解决的是“环境可移植”Spaces 解决的是“上下文可沉淀”。两者不重复前者是本地开发规范后者是团队协作容器。要说不足dots 目前对 Windows 的原生支持还比较粗糙。我在 Windows 机器上测试时路径分隔符和 shell 环境变量解析都有一些小问题。项目组已经明确后续版本会把跨平台作为优先事项macOS 和 Linux 上目前体验已经很顺滑。5. Codex 与 API把发布会演示落实到真实开发工作流5.1 Welcome to Codex登录、安装、跑通第一单发布会几乎一开场就放了“Welcome to Codex”的宣传语这就是命令行编码智能体项目。和之前曝光的一致Codex 用自己的 OpenAI 账号登录就能用不需要单独申请企业白名单。安装和登录流程现在是这样的npm install -g openai/codex # 用 ChatGPT 账号登录 codex login登录后会看到一个授权页面确认后本机 Codex 就能用你的账号发起智能体会话。整个过程大概 1 分钟不需要手动复制粘贴 API key也不需要自己管理令牌过期。对个人开发者很友好。如果你更习惯程序化调用不想把账号绑进终端可以设置 OPENAI_API_KEY 环境变量走 API 计费通道。两条路径的区别在于ChatGPT 登录走订阅额度适合日常交互式使用API key 走按量付费适合跑批任务和自动化脚本。我的建议是日常开发用登录模式正式 CI 环境用 API key两边分开避免互相污染配额。5.2 一个常见的安装坑缺失平台可选依赖我在新机器上安装时踩到了一个很典型的报错error: Missing optional dependency: openai/codex-win32-x64 Reinstall Codex: npm install -g openai/codex原因不复杂npm 在安装时没有拉取当前平台对应的二进制包。我在 Windows 上遇到 win32-x64 缺失其他架构机器也可能出现缺少 arm64 或 x64 可选依赖的情况。常规解法npm uninstall -g openai/codex npm cache clean --force npm install -g openai/codex如果还是不行就检查 npm 的 optional dependencies 开关。有些系统的 .npmrc 配置文件把 optional 关掉了导致可选依赖永远装不上。你也可以临时强制安装npm install -g openai/codex --includeoptional装完之后执行 codex --version 确认一下版本正常的 1.x 正式版输出很干净。5.3 API key 的生成、保存与使用规范如果你还没用过 OpenAI API这里说下安全路径登录官方平台后在 API Keys 页面创建一个新 key创建之后立刻把完整串复制保存到本地密码管理器里因为关闭页面后服务器不会再给你看第二遍。保存之后不要硬编码在业务代码里更不要贴在公共仓库或聊天群。我一般在本地项目根目录放一个 .env 文件OPENAI_API_KEYsk-xxxxxxxxxxxx然后在代码里用环境变量读取。注意 .env 文件必须加入 .gitignore否则一个不小心 push 上去等于把账单的开关公开了。有一次我在开源项目里看到有人把带 key 的 .env 直接提交了十分钟内那个 key 就被别人刷掉了几百美金。所以我的习惯是每个环境单独生成 keyCI、本地、客户端用不同 key 隔离发现异常用量立刻在后台吊销再重新生成。在使用 Codex 时如果你已经用 codex login 绑定了 ChatGPT 账号尽量不要同目录再设置 OPENAI_API_KEY。两个计费通道并存时Codex 优先读环境变量有时候你以为订阅在兜底实际已经默默走了按量计费。月底账单会很感人。6. 演示之外的暗坑我在实测中发现的 6 个问题6.1 思考预算与长上下文的 token 膨胀最容易被发布会带偏的一点是他们有几十万 token 的上下文窗口实际用起来不是免费的。GPT-6.1 Sol 的思维 token 同样计费预算设得越高长上下文里的推理成本会成倍增加。我测试过一份 30 万 token 的代码仓库budget 设为 high 后单次分析消耗的 token 比 medium 高出大概 2.5 倍但效果提升没有同比例增长。长上下文任务里一定要给模型明确边界“只分析 user-service 模块别动库存部分。”6.2 从 Chat Completions 迁到 Responses API 时字段不兼容官方推荐新项目直接用 Responses API 而不是老版 Chat Completions但迁移时有很多字段被改掉了。比如 chat.completions 里常用的 stop 序列到了 Responses API 变成了 truncation 策略的一部分tool_choice 对象结构不同system message 被塞进 instructions 字段。如果只是把 python SDK 里的 model 参数换一下大概率会拿到一堆校验错误。迁移前务必翻一遍官方兼容指南或者直接用新 SDK 的示例重写调用层。6.3 API key 的限额与“隐形”配额新功能上线后默认 tier 的配额并没有同步大幅放开。我有一段时间在跑批量任务RateLimitError 频繁出现对照后台才发现 key 所在的 tier 的 RPM 上限还是旧值。如果你打算大规模跑 Sol 或 Spaces API提前在后台申请提升 quota 非常必要否则生产环境会在关键节点崩溃。6.4 Spaces 共享权限的一个边界Team Spaces 里的人能互相看到对话内容这个我理解。但如果你把某个 Space 分享给只读用户这个用户依然能读取该 Space 里的全部历史文件和工具调用日志。如果我只想在群里展示一个最终报告结果把整个分析过程都共享出去了。建议对外分享前单独建一个只包含最终产物的 Space。6.5 dots 同步时的密钥冲突dots 在同步配置文件时默认会把敏感内容做占位符替换但如果你自定义脚本里硬编码了 token同步到另一台机器时会原样带过去。我们团队就曾经把一套 QA 环境的密钥通过 dots 配置传到了生产目录。建议密钥类内容不要写死在 dots 里统一用环境变量注入并在 dots 文件里加 denylist 规则禁用常见密钥文件名。6.6 异步任务的 webhook 回调需要自己搭接收端Spaces API 和 Batch 2.0 都走异步模型。提交任务后回调会发向你自己提供的 webhook 地址。如果没有提前准备一个可访问的接收端任务完成状态根本拿不到。测试阶段最简单的办法是把 webhook 指向本地调试工具先确认回调格式再部署正式接收服务。7. 落地建议如果只选三件事我先做这些7.1 三个值得立刻投入的方向通篇看下来真正值得马上落地的是三件事。第一新项目直接建立在 Responses API 和 Spaces API 上。不要再叠一层旧的 Chat Completions 抽象新接口的会话统一性、工具编排、异步任务管理都是为智能体时代设计的。老接口短期能用长期会越来越像历史包袱。第二给团队开发环境引入 dots。不管你现在用不用 Codexdots 这种“把环境配置代码化”的思路都值得借鉴。它能把新同事上手时间、多机同步成本、CI 环境准备时间压缩一个量级。我们从第二周开始就没有人再问“这个项目怎么跑”了。第三把 GPT-6.1 Sol 用在“最麻烦、最容易反复返工”的任务类型上并刻意练习调 budget。不是所有业务都迁过去而是先挑出那些过去需要人工介入十几次、改了又改的任务让 Sol 直接面对完整问题配上明确的收敛边界。省下的不只是单次调用时间而是整条工作流的人力和沟通成本。7.2 我对未来半年的判断和几个同行聊下来大家的共识是这次 DevDay 没有放出一个能让你一夜之间多赚一百万的“超级功能”但把模型、工作区、开发工具三件事拼接成了一个更有生产力的整体。接下来的半年拉开差距的不是谁更快抢先使用了新模型而是谁先把这套环境与智能体协作机制嵌入到日常开发里。dots 和 Spaces 这两个产品目前的迭代速度很快趁官方文档还在频繁更新建议找一个自己的真实小项目花半天时间试一下别只停留在看演示。把 Responses API 的迁移示例、Spaces API 的 quickstart、dots 的 profile 继承文档各跑一遍。你会发现这些功能单独看都挺朴素一旦组合起来就是很多人设想的“AI 原生办公室”的雏形。