1. 大会全貌这场发布会把AI聊天讲到了头刚从旧金山回来时差还没倒利索我就想把这次OpenAI DevDay 2026的全程记录下来。原因很简单这届大会的信息量实在太大20多项发布集中在两天里光主题演讲就讲了近两个小时散场时我身边的开发者基本都在聊同一句话——这次不是升级是换赛道。整场活动的核心主角自然是dots、ChatGPT Spaces和GPT-6.1 Sol这三样东西。先说结论如果说前两年OpenAI还在给大模型练嘴皮子那今年它明显开始教模型长手了——从只会生成文本变成能编排工具、操作界面、参与完整工作流。整场发布会都在传递同一个信号AI的重心已经从会聊天迁移到能执行。会场布置也很有隐喻感主舞台背后是一块巨大的实时交互屏演讲过程中工作人员现场往上面拖拽各种面板——任务、代码、网页控件、多Agent对话——这些东西不只是一个炫技环节它们就是新产品Spaces的实景演示。站在台下能直观感受到今年的ChatGPT已经不是一个聊天框而是一个装满了工具的车间。这篇文章我分几块来写先是全貌然后是GPT-6.1 Sol、dots、ChatGPT Spaces三大主角接着盘点那些容易被忽略的增量更新最后聊一些迁移成本和避坑心得。不管你是做Prompt工程、后端接入还是前端自动化应该都能从中找到对自己有用的部分。1.1 20多项发布其实只分了三条线把发布会内容和官网文档按类别拆开基本是这三条线层级代表发布一句话解读模型层GPT-6.1 Sol、o6-mini、视觉定位模型从会推理到会自主编排交互层dots开放协议、Muse、Realtime API 2.0让AI真正看见并操作界面产品与平台层ChatGPT Spaces、Codex 2.0、记忆API 2.0、Function Calling 3.0、AgentKit 2.0、Data Zones把AI接入真实业务链路这三条线不是孤立的产品发布而是一套完整的技术栈模型层负责会想交互层负责能看见、能操作产品和平台层负责真正参与到业务流程里。尤其值得注意的是dots和GPT-6.1 Sol之间存在明显的协同设计——Sol的自主执行能力需要环境感知接口而dots正好补上了这一环。如果你只把这次发布会当成又出了个新模型那大概率会错过真正有价值的部分。1.2 今年真正的关键词执行如果你只记住GPT-6.1 Sol这个名字可能还会把它当作又一个更强的模型。但现场演示和官方文档都有一个明显转向判断AI成熟度的标准已经从回答得像不像人变成能不能把事办完。翻译过来就是——模型的输出质量当然重要但更关键的是它在长链路任务里的自主性、工具调用的稳定性和对环境的感知能力。这也是为什么今年最抢眼的全新东西不是模型本身而是dots这套让AI看懂界面的协议。它把网页里任意一个按钮、一张卡片、一个输入框定义成带稳定ID的语义节点AI和第三方应用都可以直接寻址、读取状态、触发操作。从这个角度看dots的意义不亚于当年浏览器里的DOM标准化——它第一次为AI操作界面这件事提供了一层公开、可编程的公共语义层。2. GPT-6.1 Sol从会想到会做的旗舰转身2.1 Sol的命名不是拍脑袋官方在技术文档里解释了命名的两层含义。第一层是拉丁语太阳——寓意模型成为复杂任务链路中的光源为其他工具和子Agent提供推理能量第二层是Self-Orchestrating Learner的缩写直译是自编排学习体核心强调模型具备在长任务中自主规划、拆解、调用工具、自我纠错的能力。这个定位和在场的开发者感受是一致的。过去用GPT-5、GPT-6我们习惯把任务拆成多轮对话每一步都靠Prompt喂得清清楚楚。而Sol的API里多了一个非常重要的参数reasoning你可以直接控制模型在任务开始前的规划深度以及是否允许它在执行过程中动态调整计划。这在以前是不可想象的——推理链从黑盒变成了可调教的半透明状态。我在现场问了一位OpenAI的工程师他给了一个很直白的类比以前你雇一个实习生每一步都要交代Sol更像一个组长你给目标它会自己拆活、派活、验收。虽然类比有些简化但基本说明了这一代模型在设计思路上的根本差异。2.2 核心指标三块硬骨头官方公布的Sol关键能力我整理成了表能力项参数/表现对比上一代上下文窗口2M tokens提升4倍多模态输入文本、图像、音频、视频统一token空间视频理解从抽帧变为连续语义推理可编程性reasoning参数暴露规划深度从黑盒变为可控工具调用稳定性200步以内自主调用成功率提升约35%大幅减少中途断链延迟首token延迟降低40%推理阶段可流式输出中间步骤适合交互式场景2M上下文是这次最容易被忽略但后劲最大的数字。它意味着你可以把一整本技术手册、一个中型代码仓库的说明文档、或者几个月的项目日志直接塞进上下文不需要再做繁琐的RAG切片。加上中间步骤的流式输出Sol尤其适合那种边想边干的任务——比如让AI先读全仓库代码再逐步重构一个模块过程中你随时能看到它在看哪个文件、改了哪些行。多模态方面值得多说一句。以往视频理解基本靠抽帧抽错关键帧信息就丢了。Sol的视觉编码器不再把视频当多张图片而是当成连续时空语义流处理。现场演示里它通过一段操作录屏直接推断出用户是在排查支付回调超时问题并自动生成了排查命令序列。虽然demo有排练成分但视频理解粒度的提升是实打实的。2.3 API接入参数和价格都变了接入方式仍然是标准的Chat Completions风格但有几个新参数需要关注。我直接给一段实际调用示例from openai import OpenAI client OpenAI() response client.chat.completions.create( modelgpt-6.1-sol, messages[ {role: user, content: 分析这个仓库的代码结构定位所有未处理的Promise异常并给出修复建议改动量控制在200行以内。} ], reasoning{ mode: balanced, # 可选 draft / balanced / deep visible: True, # 是否流式输出中间推理步骤 max_plan_tokens: 3000 }, tools[...], # 工具列表Sol支持200步自主编排 streamTrue )价格方面Sol相比上一代GPT-6实际上是降价的。公开的定价是输入每百万token约2.5美元输出每百万token约10美元降幅在15%左右。但注意如果开启reasoning.visible True中间推理token会额外计费。我会后实测了一轮代码审查任务推理token大约占总token的10%到20%在可控范围内。如果你对成本敏感建议先用draft模式跑通流程确认无误后再切deep模式做复杂推理。另外历史记录里那几个热词经常被问到——openai api价格确实是开发者迁移前最关心的点。我的建议是不要只看单价重点看任务单价Sol一次能完成过去需要5到10次调用才能完成的工作综合算下来总成本往往更低。毕竟上下文长了、调用次数少了云账单自然不会撒谎。2.4 现场Demo20分钟不干预最有冲击力的现场演示是工程师让Sol独立完成一个跨系统任务读取一份在线服务的技术指标、定位一个性能瓶颈、在代码仓库里开出修改PR、再写一份简洁的周报发送到Slack频道。整个过程大概20分钟工程师全程没有输入任何一条指令Sol在dots的帮助下自己打开了监控后台圈出了异常区间调用了仓库API定位到相关函数最后还把周报发到了指定频道。演示结束后掌声最响的不是模型回答得多好而是它真的把活干完了。对一个长期做AI应用落地的人来说这种把事办完的能力比任何Benchmark数字都更有说服力。3. dots把任意界面的元素变成可寻址的节点3.1 先理解dots解决的是什么问题在dots出现之前让AI操作网页的常规做法无非两种一是用爬虫和OCR去读页面再手工写选择器去点二是寄希望于截图多模态模型猜出按钮位置。前者脆得像玻璃页面一改就碎后者慢且不准尤其面对动态渲染的现代前端成功率惨不忍睹。dots的思路完全不同。它不要求AI去理解整个页面而是让页面上每一个有意义的元素——按钮、输入框、价格标签、购物车图标——都拥有一个全局唯一的语义ID。你可以把这个ID理解为给每个UI元素发了一张身份证。任意客户端只要拿着这张身份证就能像DNS解析域名一样定位到这个元素并读取它的状态、触发它的操作。发布会上有一张对比图我印象很深左边是传统自动化脚本密密麻麻的XPath选择器右边是dots的一行寻址代码。本质区别在于传统自动化面向的是DOM结构页面一重构就失效dots面向的是语义身份就算整个页面改头换面只要元素的应用层语义不变寻址就依然有效。3.2 dots的底层协议是怎么工作的dots不是简单给HTML加个属性而是一套分层的开放协议。最底层是元素身份层开发者给关键交互元素添加标准属性比如按钮可以声明为odt:checkout-submit-button。中间层是视觉定位引擎——官方发布了一个专门的视觉定位模型专门负责在那些没有正确标注的页面上通过语义理解把视觉区域映射到最近的dot节点相当于给老页面做了一层兜底。最上层是状态同步与事件层客户端可以通过协议读取元素当前状态、监听状态变化、派发操作事件。一个简单的使用场景代码大致是这样from dots_client import DotsClient client DotsClient() # 定位到应用页面上的结账按钮 checkout_btn await client.locate(https://shop.example.com/cart, odt:checkout-submit-button) # 读取按钮当前状态可点/禁用/加载中 state await checkout_btn.state() # 触发点击 await checkout_btn.click() # 监听支付结果面板的出现 result_panel await client.wait_for(odt:payment-result-panel, timeout10)实际跑起来最爽的部分是dots天然具备跨应用编排能力。同一个ID协议可以在不同站点间流转你不需要为每个网站单独写一套适配逻辑。它把UI自动化从一个页面一套脚本变成了一套寻址、处处可用。3.3 和Muse的关系设计师也能参与做AI可操作界面热词里反复出现dots和muse这对组合。Muse是配套dots推出的界面设计工具它让设计师在为网页或App设计原型时直接在组件上标记dot语义ID。也就是说dots不只是开发者的玩具它把可被AI操作的接口这件事提前到了设计阶段。我参加了一个Muse的动手工作坊体验下来它的核心理念是语义即设计。设计稿里一个按钮不只是视觉元素还会绑定状态枚举默认/悬停/点击/加载/禁用、操作事件submit/cancel/continue、数据属性价格、数量、状态。这些语义信息随设计稿一起输出给前端最终交付的页面天然具备dots能力。对团队来说这相当于把AI可操作性变成了产品需求的一部分而不是事后补救。3.4 该不该上车机会与风险对做UI自动化测试、RPA、智能客服、电商导购的团队来说dots带来的机会非常直接。以前AI操作浏览器是最不稳定的环节现在有了标准语义层自动化流程的鲁棒性会明显提升。但风险同样存在当前dots标准覆盖的主要是主流站点和开放生态那些拒绝标注dot属性的封闭页面依然只能靠视觉兜底模型去猜成功率没保障。安全方面也要注意dots让界面元素可寻址意味着如果权限校验没做好第三方可以更轻松地触发敏感操作。所以接入dots权限系统和操作审计必须同步跟上。4. ChatGPT Spaces把AI从聊天窗口搬进工作间4.1 一个Space里到底有什么如果你用过Notion、Jira再打开ChatGPT Spaces会有一种这些工具被AI重做了一遍的感觉。一个Space就是一个小型的工作间里面可以包含任务面板、知识库、多个智能体成员、实时协作光标、以及完整的历史活动记录。它不再是聊完即走的对话流而是一个有状态、有结构、有权限的长期运行空间。我回来后实际建了一个团队Space用来管理季度产品规划几个最直观的感受是任务面板能和对话内容双向关联在聊天里说把这篇文档的状态改成评审中卡片真的会变知识库可以上传各种文件并设置不同智能体的访问范围更重要的是整个Space有项目记忆——AI不会忘记三天前你提过的某个约束条件因为它已经写进了空间记忆库不需要每次对话都重新强调。4.2 多智能体协作的现场实感Spaces里最有意思的是多智能体编排。每个Space可以同时跑多个Agent它们有独立的角色、模型配置和工具权限但共享同一份项目记忆。官方演示的案例是一个产品发布计划一个Agent负责整理需求文档一个Agent负责估算技术排期还有一个Agent专门检查风险项。三个Agent在同一个Space里并行工作互相引用对方的产出最后由主持人一次性汇总成项目计划。我回来在自己的小团队里复现了这个场景配置了需求分析和代码审查两个Agent挂在同一个项目Space里效果超出预期。最关键的体验是多智能体不再需要你手工做复杂的消息传递Space本身提供了共享记忆和任务上下文Agent之间可以直接读取彼此的结果。这种共处一室的设计比外部框架里硬凑的multi-agent流程自然得多。4.3 开发者如何接入Spaces对开发者来说更重要的是Spaces把底层能力开放成了API。你可以创建空间、定义角色权限、往空间里注入任务、订阅空间内的事件。放一段简化的接入示例const client new OpenAI.SpacesClient({ apiKey }); // 创建一个项目空间 const space await client.spaces.create({ title: Q3 产品发布计划, members: [aliceexample.com, coder-agent], }); // 在空间里启动一个智能体 const agent await space.agents.spawn(code-reviewer, { model: gpt-6.1-sol, permissions: [repo:read, space:write], }); // 给智能体下发任务 const task await space.tasks.create({ title: 评审首页改版PR, agent: agent.id, input: https://github.com/example/app/pull/2081, }); // 订阅任务完成事件 space.on(task.completed, (event) { console.log(任务完成, event.task_id, event.summary); });这套API的设计思路是空间即应用容器你的业务可以按项目为单位组织AI工作流权限、记忆、事件都挂在空间上而不是散落在各个独立调用里。对B端集成来说这个模型比裸API调用友好太多审计和合规也更好做。4.4 和Notion/Jira等传统工具的对比维度ChatGPT SpacesNotionJira任务管理AI自动拆解、状态流转手工维护强流程引擎知识库AI可检索、可记忆静态文档弱多Agent协作原生支持不支持不支持API开放程度面向AI任务设计偏文档偏项目管理适合场景AI原生工作流知识沉淀大型研发流程当然传统工具在成熟度、插件生态和深度流程管理上仍有优势。但如果你所在的团队已经在大量使用AI辅助工作Spaces提供的记忆智能体任务三位一体模型明显更贴合AI原生的协作方式。我个人的判断是短期它还不会完全取代Jira这类重流程工具但在知识型团队和AI产品研发团队里渗透速度会非常快。5. 被闪光灯忽略的增量发布5.1 Codex 2.0从帮你写代码到帮你管代码库Codex的更新被三大主角的光芒盖住但对开发者来说这可能是日常最实用的升级。Codex 2.0不再只是一个命令行里的编码助手它变成了支持多个仓库并行操作的代码库管理员能同时读取多个项目的文件跨仓库搜索符号引用还能先生成一份改动计划文档供你评审确认后再批量执行修改。我最喜欢的是计划评审模式。以前让AI改代码最怕它闷头一顿改、把不该动的地方动了。现在Codex会先把改动计划列出来我用diff模式检查一遍再批准执行整个过程透明可控。对于接手的存量老项目这种先计划、后动手的模式能显著降低误改风险。5.2 记忆API 2.0与Function Calling 3.0生产级基础设施记忆API 2.0把记忆从单次对话的临时上下文升级为项目级、团队级、甚至组织级的持久化记忆库。它支持按空间隔离、按时间衰减、按权限读取。这意味着你可以把一个团队长期积累的业务约束、术语表、决策记录扔进记忆库所有智能体在完成任务时都能自动引用不再需要每轮对话都把背景讲一遍。我实测的感受是它把很多团队内部靠文档人肉同步的流程直接自动化了。Function Calling 3.0则是一次协议层的重写。新协议支持嵌套工具调用、并行工具调用和更严格的参数校验同时引入了工具结果回退机制如果某个工具调用失败模型会收到结构化的失败原因并在同一步内自动尝试备选方案。这对AI操作真实业务系统非常关键——真实世界的API没那么听话失败处理能力往往决定了任务能不能跑完。5.3 实时语音与多模态交互体验再往前一步Realtime API 2.0是我在会场试玩最久的一个新接口。它支持真正的全双工语音交互而且加入了实时翻译能力。演示里两个人一个说英语一个说西班牙语各自戴着耳机对话谁的耳机里听到的都是自己的母语延迟几乎感觉不到。这套能力对跨国客服、跨国会议场景的改造会非常直接。另外新发布的视觉定位模型不容小觑——它不是给人类用的而是给AI用的眼睛。dots协议能够跨页面识别未标注元素背后靠的就是它。这两个发布单独拿出来都够撑一场发布会但在今年只能当配角。5.4 企业合规与可观测性B端最在意的部分对做企业服务的团队来说Data Zones、审计日志和红队API这三样可能比模型本身更有价值。Data Zones让你可以把数据存储和处理限制在指定区域满足合规要求审计日志记录模型调用、工具操作、记忆访问的完整轨迹红队API则允许安全团队用自动化方式持续对模型做攻击测试。我接触的几个企业客户听到这部分时眼睛都在发亮——AI落地最难的不是能力而是出问题后谁能说清楚发生了什么。OpenAI这波明显是在补课。6. 我从DevDay带回来的迁移避坑与成本心得6.1 从GPT-6迁移到Sol三个注意点第一别直接改模型名就上线。Sol的推理行为与GPT-6差异很大尤其是在工具调用频率和自主性上。我们实测发现对同样的需求Sol会主动调用工具去验证信息而不是单纯凭训练数据回答。这本身是好事但如果你原来的Prompt写得不够严谨Sol可能会自由发挥到超出预期——建议先在小流量上跑灰度梳理清楚工具权限边界。第二reasoning参数要按场景差异化配置。简单问答用draft模式省钱复杂多步任务用deep模式保证质量日常任务用balanced。我们调了一周才总结出各场景的匹配策略核心原则是不要把推理强度和任务难度绑定要按出错代价绑定——出错代价高的任务再贵也要开deep。第三长上下文不等于免检。2M token窗口固然香但上下文里塞越多内容模型对关键信息的聚焦能力反而可能被稀释。我建议保留必要的结构化提取环节把长文档先整理成摘要和关键条目再喂给Sol效果比整本硬塞好得多。6.2 dots落地时容易踩的安全坑dots让AI操作界面变得简单但简单也意味着风险。最大的坑是寻址到了、权限没跟着走。理论上一个能拿到dot ID的客户端就能对元素发起操作——如果你的页面把删除、转账这类危险操作也标记成了dot节点又没有在服务端做二次校验被自动化工具误触发的概率会直线上升。我建议的落地规范是危险操作节点只暴露状态读取能力不暴露操作触发能力所有通过dots触发的高风险动作必须在服务端增加独立的二次确认机制另外dots事件日志要纳入监控至少能追溯到谁、在什么时间、通过哪个dot、做了什么操作。记住AI操作越顺畅审计越不能省。6.3 Spaces权限设计先想清楚别等出事了再补Spaces把知识库、任务和智能体绑在一起权限模型也随之变复杂。我们配置时踩过一个实际问题一个只应该读代码的Agent因为权限配得过大差点把测试环境的配置给改了。后来我们把权限收敛到最小必要并给每个Agent单独建立了角色和审计策略才算放心。另外一个容易被忽略的细节是共享记忆的污染。多个Agent共享一个记忆库A Agent写入的错误经验可能被B Agent当成正确规则使用。建议在项目里区分长期事实库和短期工作缓存写长期库的内容走审批流程防止错误信息被固化。6.4 成本控制任务单价才是真指标最后聊一个很多团队关心的问题——迁移后API费用会不会爆。我的经验账是这样的GPT-6时代完成一个市场竞品信息收集初步分析任务大约需要8到12次对话来回搬运大量上下文切到Sol之后一次带工具的调用就能解决中间推理token增加约15%但整体任务成本下降了差不多一半。所以不要盯着单个接口的单价建议按任务维度做成本对照而且一定要把deep推理的使用率控制在合理范围——我们目前约七成的任务跑balanced模式成本与质量最平衡。这次大会看下来我个人最大的收获不是某一个模型参数而是整个生态终于开始围绕执行做设计了。GPT-6.1 Sol给了AI自主规划的大脑dots给了AI感知和操作界面的手Spaces给了AI与人共同工作的场地。三件事凑在一起AI应用开发的下一个阶段会非常有意思。如果你也在观望要不要升级到Sol、要不要试dots我的建议很简单找一个流程重复、规则清晰、容错率高的业务场景先跑一个月试点。AI执行能力的红利只有真正放进生产流程里才能尝到味道。