1. 发布会观察20多个发布三个主角1.1 现场节奏与核心情绪我很少用“炸裂”来形容一场发布会但这次实在没忍住。DevDay 2026开场不到三分钟大屏幕就放出了“20 announcements”的字样直播间的弹幕直接翻了一倍。整场活动节奏非常快没有冗长的情怀铺垫配角产品用短片快速带过真正的舞台时间留给了三样东西dots、ChatGPT Spaces、GPT-6.1 Sol。先说整体感受。OpenAI这几年在开发者大会上的节奏变化很明显早期是“放出一个模型让你自己折腾”中间的版本是“模型加API全家桶”到了2026年这场思路变成了“把模型、工具、应用场景一起打包端给你”。你不再需要自己拼装积木——官方连拼装模板、调试面板和落地方案都给你备好了。这对资深开发者来说省下的是从零到一的架构时间对新入行的开发者来说则是把上手门槛直接从“会写接口”降到了“会描述需求”。也有一个必须承认的现实发布太多真正能看懂全貌的人是少数。当天下午社群讨论里问得最密集的问题基本上是“dots到底是不是一个新的IDE”“Spaces跟之前的Projects有什么区别”“GPT-6.1 Sol是不是就是GPT-6改名”。这些问题都很典型说明注意力被20多个名词摊薄了。所以这篇文章我不打算把所有发布都流水账式地罗列一遍而是先把三个主角讲透再把其余的发布收拢成几条清晰的脉络最后聊聊这一周实测下来踩过的坑。看完你至少能明确知道自己该从哪个入口进去。1.2 三个主角如何互相咬合这三样产品不是孤立存在的它们正好覆盖了智能应用的三层结构。GPT-6.1 Sol在最底层是推理能力的来源你可以把它理解成“大脑”。它对上下文理解、复杂推理、多模态解析这些底层能力做了全面升级所有上层应用都是在这个基础上长出来的。dots在最靠近开发的中间层它管的是“怎么让AI替你干活时你能看得见、管得住”。过去用代码模型最大的痛点就是它一顿操作猛如虎你却不知道它每一步在干什么出了问题也不知道回滚到哪里。dots把这个问题解决了它把推理过程拆成一个个可视化的“点”让开发者可以追踪、暂停、跳转、回滚。ChatGPT Spaces则站在最上面的应用层解决的是“多个人、多个AI、多个任务怎么放在同一个空间里协作”的问题。它不是又一个聊天窗口而是一个具有持久记忆的工作区适合团队作为项目中枢来用。更好的理解方式是把它们当成一条流水线你的需求在Spaces里被拆成任务GPT-6.1 Sol负责执行高难度的推理判断dots随时记录和展示每一步进展最后再把结果沉淀回Spaces。这样一来整个开发过程的可见性、可控性和协作性都往前跨了一大步。1.3 值得关注的两条战略信号除了产品本身我更在意发布会里透出的两个信号。第一个信号是对“智能体验”的理解已经从单次对话快照走向了“多模态状态持续化”。现场反复强调一个概念对话是瞬时的空间是持续的技能是可追踪的。翻译成大白话就是过去AI只在你提出问题的那一刻工作未来AI会长期驻留在某个项目里像团队成员一样不断接收上下文、更新状态、产出结果。这对所有做SaaS应用、做协作工具、做自动化平台的人都有直接冲击。第二个信号是官方对开发者的态度明显变得更务实。整场演讲里没有太多炫技式Demo更多是展示真实的生产链路从初始化项目到接入模型再到部署监控。这说明他们很清楚开发者要的不是“最聪明的模型”而是“最不容易翻车的工程环境”。务实的结果就是发布内容的含金量整体变高了——有些东西看起来平平无奇实际上是把过去几个月社区反复踩的坑直接固化成产品功能。2. dots把推理过程摊开给你看的开发利器2.1 dots到底是什么dots是我这次最关注的产品。它不是一个聊天机器人也不是传统意义上的IDE而是一个“智能体运行可视化与运维平台”。如果你想在一句话里理解它可以这么记它让AI干活时留下的每一步“思维痕迹”都变成可查看、可分析、可回滚的节点。发布会现场演示了一个场景给dots下达一个包含十二个子任务的项目指令它会在一个类似流程图的工作台上把这些任务全部可视化展示出来每个任务之间有关联线颜色深浅代表完成状态点击任意节点还能看到那一步具体调用了哪些工具、改动了哪些文件、输出了什么结果。整个过程非常直观哪怕完全不懂代码的人也能看懂“AI到底干了什么”。它跟Codex命令行工具的关系也值得单独说。Codex是OpenAI官方推出的命令行编码智能体很多开发者已经把它接入日常开发流。dots更像是给这类智能体加了一层“驾驶仪表盘”——Codex负责开车dots负责显示路况、油耗和导航。本地运行时会自动生成一个轻量级存储把每次运行的决策点落盘保存你随时可以查看一台“推理记录仪”的完整回放。我的判断是dots的长期价值不在可视化本身而在“可复现性”。开发者最害怕的事情就是智能体跑出一个好结果但不知道怎么复现或者跑出一个坏结果但不知道怎么回退。有了点级别的记录智能体开发就从“黑盒赌博”变成了“白盒工程”。2.2 核心能力拆解追踪、分支、复盘dots的核心能力可以拆成四个模块。第一个是SUBSTEP追踪。智能体执行任务的时候系统会把过程拆解成多个点而不是只记录一个最终结果。这解决了一个很实际的问题以前智能体说“我完成了”你其实分不清它是真的完成还是自己骗自己。现在你可以展开每一步看到它使用的关键证据。第二个是分支回滚。这功能非常像Git但作用对象不是代码而是智能体的执行路径。比如第12个点执行之后开始跑偏你可以直接把状态回滚到第12点之前的那个时刻修改提示词重新分支。对做自动化流程的人来说这个能力省下的调试时间相当可观。第三个是沉浸式复盘。智能体跑完一个半小时的长任务后你可以用类似倍速回放的方式查看整个过程系统会自动标注出“这里重复调用了两遍”“这里检索失败了三次”这类信息。我之前一直靠日志文件复盘说实话效率很低dots把这部分直接做成了时间轴效率不是一个量级。第四个是产物快照。每执行完成一个重要节点dots会把当时的代码、配置、输出结果打包成快照。这意味着你不需要担心智能体中途改了某个文件导致整个项目状态混乱因为每个节点都能恢复到当时的完整状态。2.3 命令行实操与验证路径发布会后我第一时间装了预览版安装过程很简单前提是你已经有Node.js环境。官方推荐的安装方式如下npm install -g openai/dots dots init初始化完成后在项目目录里直接运行这样的指令dots run review the current repository, find the top 3 performance bottlenecks, and fix them one by one你会看到终端里逐渐生成一批带有编号的节点每个节点就是一次关键决策。运行完后用下面的命令查看整个过程报告dots trace dots replay --range 5..12我个人实践下来比较推荐的工作流是先在Spaces里把需求描述清楚再把这份描述导入dots让它拆解执行。动作不太大的任务用默认配置就够了长任务建议在提示词里明确“每一个子任务执行完后先汇报关键变化”这样生成出来的节点信息密度会更高复盘体验更好。诚实地说dots目前的预览版还不算完全没有毛病比如项目特别大的时候图渲染会有明显延迟我刚装上的第一个小时就遇到了界面卡顿。但整体方向没有跑偏它精准击中了智能体开发调试困难的要害。3. ChatGPT Spaces从对话窗口到协作工作区3.1 Spaces的产品形态如果说dots解决的是“AI干活过程不可见”的问题ChatGPT Spaces解决的是“工作场景不能沉淀”的问题。过去两年用ChatGPT最大的别扭之处在于每个对话都是孤立的。今天聊完一个需求明天再打开上下文得重新导入想邀请同事一起看一个工程方案只能把链接甩过去对方看到的也只是一段对话记录没有项目上下文。Spaces把这种局面直接换了一套逻辑。新的Spaces更像是一个“房间”房间里有站点、文件、对话子模块、AI角色配置以及共享记忆。每个空间服务于一个长期项目所有重要的知识都沉淀在里面。你可以把不同任务拆成不同的子对话让多个AI智能体并行干活最后再把它们的结果汇入同一个空间。最明显的体验提升是上下文不再每次都从零开始。你一周后再打开同一个空间所有进度和结论都还在AI也能基于这些进度继续推进而不是把之前说过的话再重复一遍。用一个比喻来说以前的ChatGPT是一张白纸每次对话都是重新写字聊完了纸就丢掉现在的Spaces是一个文件夹加一块白板加一个会议室的组合体你不但可以在上面写写画画还能把参与者和资料都固定下来。3.2 对真实工作流的改变我拿一个自己手头的小项目试了试。项目要整理一份关于内容社区增长策略的文档需要做竞品分析、数据复盘、方向规划三块内容。以前的做法是分别开三个对话窗口让AI各写各的最后我自己复制粘贴到一个文档里整合。这样做最烦的不是复制粘贴而是三个对话之间缺少共识每一段都像是从不同的陌生人嘴里说出来的。用Spaces以后我在同一空间里建立三个子任务并把项目背景、基础数据、目标人群描述统一放到空间记忆里。三个子任务共享这些背景知识输出风格和口径明显更一致。我甚至在其中一个子任务跑完后把它生成的结论作为另一个子任务的输入条件形成了上下文的流动。团队协作场景的提升更明显。你可以给每个成员分配不同的访问级别有的只能查看结果有的可以编辑任务有的可以管理配置。所有人看到的是同一个项目全景不用再把信息转来转去。从演示来看它对“项目型工作”的贴合度非常高适合产品团队做需求管理适合分析团队做报告产出适合内容团队做选题库和知识库。3.3 权限设计和注意事项试用过程中有几个细节值得提醒。第一是权限管理。Spaces的权限模型比ChatGPT自带的多了一个“AI代理权限”概念你可以指定某个空间内的智能体能否读取外部资源、能否执行外部工具。建议开始就收紧权限尤其是涉及代码仓库和云服务的场景给AI最小必要权限就够了不要图省事直接开到全权限。第二是存储配额。Spaces的媒体资源和文件快照也会计入配额频繁跑长任务的话消耗速度比预期快。团队使用前最好先确认计费模式免得月底看到账单懵了。第三是敏感信息。把一个包含客户信息的空间分享给外部协作者时一定要确认哪些智能体和成员能看到哪些数据。我测试时发现空间记忆是可以被该空间内所有子任务共享的所以只要有一个协作者权限没设好AI就可能在某个子任务中引用到不该出现的信息。这不是危言耸听是实测踩过之一。4. GPT-6.1 Sol模型层的一次规模化跃迁4.1 Sol意味着什么GPT-6.1 Sol这个名字很有意思。Sol在拉丁语里是太阳的意思发布会上官方给的解释是“像太阳一样照亮知识盲区”。但我觉得更实际的理解是它是GPT-6系列里更强调全局推理、长程规划和自主探索能力的版本。从现场公布的演示来看Sol相比前代有明显进步的方面有三个方向。第一个是长程一致性。过去长对话跑到最后容易出现前后矛盾的问题Sol在这方面用了新的思维链管理机制长任务拆解时能够更好地维持主线。现场演示里它在一个跨两小时的复杂数据整理任务中保持了一致的口径最后的结论和一开始的前提是完全咬合的。第二个是多模态理解。Sol对图像、视频帧、音频、代码混合输入的理解明显更细。现场展示的例子是从一段产品演示视频里直接抽取关键界面改动点再对应到代码文件这个链路以前基本需要人工介入现在模型可以自己串起来。第三个是“稀疏注意力”架构。简单的说官方宣称它可以更聪明地选择该关注哪些上下文而不是把所有内容无条件堆进去。这个变化对成本控制有直接影响因为它意味着处理长文档时不需要总是付出全量计算的代价。需要提醒的是这些能力很多还处于“发布会演示”阶段最终表现要以模型卡和实测为准。但方向是明确的模型正在从“回答得聪明”走向“干得靠谱”。4.2 面向开发者的API变化GPT-6.1 Sol以API形式开放后我第一反应是看它跟GPT-6.0的接口差异。好消息是主体接口保持了兼容不会逼着大家重写一套代码。关键的差异集中在几个新增参数上。一个值得关注的是reasoning_effort从原来的三档扩展到了五档提供了low、medium、high、deep、ultra五个选项。这个参数直接控制模型内部推理的深度。日常任务用medium就够复杂任务上deep极少情况下才用ultra。这样做的价值是灵活控制成本和效果而不是所有人一刀切地用最大算力跑。再一个是新增了plan和execute双阶段调用模式。你可以在请求里先要求模型输出一份执行计划确认计划后再让它实际操作。这个方法在自动化场景下特别有用相当于给智能体加了一道人工审核闸门。凡是涉及写代码、改配置这类高风险操作的任务我都建议强制开启这个模式。还是以最小化示例来演示from openai import OpenAI client OpenAI() response client.chat.completions.create( modelgpt-6.1-sol, messages[ {role: user, content: 分析当前目录下的项目结构找出测试覆盖最低的三个模块并说明原因} ], reasoning_efforthigh, plan_firstTrue, ) print(response.choices[0].message.content)上面只是一个最简单的请求实际使用中可以把code_interpreter和custom_tools也挂进来。重点不是这段代码而是你意识到API开始支持“先给计划再干活”的模式了这是智能体类应用开发里非常重要的一步。4.3 成本与模型选型建议配合Sol一起推出的还有几个衍生产品包括面向轻量任务的小型版本和高吞吐版本。正常情况下官方推荐的选型思路大致是这样的处理简单问答、文本改写、信息抽取用小版本就行便宜且快处理代码生成、多步骤任务、工具调用用标准版Sol处理跨领域复杂规划或超长文本推理再上deep档位。一个常见的误解是模型选再大就对了。实际上GPT-6.1 Sol在medium和deep档位的推理次数差异可以达到数倍费用差别也不小。开发者更合理的做法是把任务按难度分桶再用不同档位去承接。我建议每一个进入生产环境的请求都做一次“档位调优测试”先用不同参数跑同一批样本记录质量分数和延迟再定最适合组合。成本控制上新版API推出了按token之外更细粒度的计费维度比如按规划步骤、按工具调用次数维度混合计价。一开始看到这个计费模型会觉得有点复杂但用顺之后会发现它对成本的控制更精准。上线前务必跑一次小规模费用估算不要凭感觉拍脑袋。5. 其余20发布中值得做功课的地方5.1 API与工具链的主干升级三位主角之外剩下20多个发布看起来杂实际上可以分成三条线API能力线、Agent开发线、企业优化线。API能力线里最值得注意的是实时API和多模态API的升级。实时API新增了更细腻的语音情绪控制可以在流式对话中调整语气和语速这对语音客服、AI陪伴类应用的体验影响很大。多模态API则正式支持了视频输入与局部分析开发者可以自定义时间戳粒度让模型只分析指定片段而不是整段视频成本可以控制得更好。Agent开发线上新版的Responses API基本可以理解为是Assistants API的延续与重构它把“单次对话”和“多轮任务执行”之间的边界打通了。另一个重要更新是Memory API的正式开放开发者可以为应用创建长期记忆存储在项目层面。这个能力解决了过去做个性化应用最大的麻烦——每次对话都要重新了解用户背景。5.2 模型定制与评估链路企业优化线这次也放了不少料。微调平台升级成了个性化训练工作室可以导入更多类型的训练数据并直接在界面上对比多个微调版本的效果。过去微调模型后总要自己写评估脚本这次官方内置了编排评估工具可以自动跑测试集、生成对比报告。这一块我个人觉得是很多团队真正需要的。模型的能力再强落到具体业务里还是需要适配而适配离不开微调和评估两步。过去这两步的工程成本很高现在平台把它们标准化之后中小型团队也可以负担得起了。这次还公布了新的护栏机制对不安全内容识别和政策合规检查做了分层接入可以不同业务口配置不同严格程度。说实话合规问题在大企业落地时往往比模型效果更棘手官方愿意在这一层持续投入对开发者生态是长远的正反馈。5.3 发布全景速查下面的表是我按自己的理解整理的本次重点发布概览不全但抓的是主线。发布/更新类别一句话价值GPT-6.1 Sol模型长程推理和高档位推理控制的升级dots开发工具智能体运行过程可视化与回滚ChatGPT Spaces应用协作多成员多智能体持久化工作区Responses APIAPI统一对话与任务执行的调用入口Memory APIAPI跨会话长期记忆能力实时API 2.0API语音情绪控制与低延迟流式交互多模态API增强API视频输入、时间戳级片段分析微调工作台企业可视化微调与效果对比编排评估工具企业自动化模型测试与报告护栏分层机制合规按业务场景配置安全红线这些发布单独看都不是核弹级但组合起来的意义很大。它们共同构成了一套从模型、到开发调试、到应用部署、再到评估合规的完整闭环。这也是今年以来我越来越明显的一个感知OpenAI正在从一个“模型公司”转向“模型加工程平台公司”。6. 开发者落地时容易翻车的细节速查6.1 API Key管理千万别把钥匙乱发每次这种规模的新版本发布后顺手搜索相关内容的人都会多一批这里面就混杂着大量关于API Key的错误姿势。有些是单纯为了测试方便把密钥直接贴在代码里有些是团队协作时想省事把同一个密钥发给所有人。我非常不建议这么做。API Key本质上就是钱袋子的钥匙别人拿到它可以调用你的额度你怎么控制成本都没有意义。正确的做法是优先使用环境变量或密钥管理服务不要把密钥硬编码进代码仓库给不同项目分配不同密钥设置不同的配额上限出了任何异常能快速定位到是哪条链路定期轮换密钥团队有人离职时第一时间吊销并重建生产环境里务必在服务端完成API调用不要在浏览器前端暴露密钥。我个人被坑过一次之后现在给任何团队提的第一条建议都是“先设计好密钥的权限边界再谈模型选型。”这个顺序不能反。6.2 Codex与dot相关的安装难题如何破新工具发布后讨论区最多的就是安装报错。有一个报错非常典型报错信息大概是missing optional dependency openai/codex-win32-x64让重新执行安装命令。这其实是平台二进制包和当前环境不匹配导致的通常出现在Windows环境下偶尔也会在跨平台的容器镜像里出现。遇到这类错误不要慌按下面顺序排查npm uninstall -g openai/codex npm cache clean --force npm install -g openai/codex如果依然不行检查Node.js版本是否符合要求。官方目前推荐使用LTS版本的Node版本太老或太新都可能导致原生模块加载失败。还有一种情况是网络没有拉取到对应平台的二进制包这时候不要在源头不稳定的网络环境里反复重试先确认依赖镜像源配置是否正常干等着只会浪费时间。6.3 多Agent稳定性与成本失控的排查这次发布之后很多开发者开始尝试多Agent并行协作。心愿是美好的但现实是复杂的。我实测过程中遇到的最典型问题是“两个Agent同时操作同一份文件结果互相踩踏”。这不算bug而是并发冲突的必然。解决办法有三个第一给不同Agent分配明确的任务边界尽量让它们操作互不重叠的文件或数据块。第二使用官方提供的任务锁机制某一个文件或资源被Agent接管时其他Agent只能等待。第三设置合理的迭代上限避免Agent陷入死循环。这个参数一定要设不要靠侥幸。成本失控是另一个隐蔽问题。多Agent并行时如果每个Agent都开启了高推理档位费用是肉眼可见地往上跳。建议先把所有Agent的档位统一设置为medium等整个流程跑通之后再针对卡顿环节单独上调档位。别一上来就用最重型配置去试错。6.4 上线前必须做的合规自查最后聊合规这是很多个人开发者最容易忽略的环节但也是绝对不能跳过的环节。新版模型和API的能力更强意味着它可以被用来生成更逼真的内容也因此更需要把安全边界提前设好。我的建议是在应用里明确输入输出内容的用途不能利用模型生成误导性内容涉及个人信息处理时确保有明确的授权流程不要因为模型能处理就直接往里灌数据面向公众开放的应用建议在发布前用一批恶意测试样本过一遍内容审核接口确认拦截逻辑生效。多说一句doc出的“合规护栏分层”这个功能非常适合多行业应用场景。医疗、金融、教育等不同领域可以设置不同的敏感词库让模型在各自的安全边界内运作。这套机制上手成本不高但能避免大量后期救火的麻烦。说到底新技术发布后的黄金窗口期就那么几周。能跑通测试、避开常见坑、把成本控制在合理区间的人往往就能在下一轮应用创新里占到身位。我这些经验也都是趟水趟出来的希望你们不需要把同样的坑再踩一遍。