1. 大会整体观感与发布主线说实话今年 OpenAI DevDay 的办会思路和往年很不一样。过去那种千人主会场、雷射灯光、大屏幕倒计时这次统统退到了幕后。旧金山主会场被拆成十几个并行的 workshop 区OpenAI 的工程师直接坐在你旁边改代码整个氛围更像黑客松而不是发布会。开场也没搞什么花活Sam 上来只花了十五分钟过了一遍更新清单就把时间留给了各产品线负责人。这种“不煽情、直接给东西”的节奏开发者圈子反馈普遍不错——毕竟大家千里迢迢飞来不是看口号是想知道 API 底下去年吹的牛到底兑现了多少。这次 DevDay 2026 官方口径是“20 项发布”我大致数了数主要集中在四个方向模型层GPT-6.1 Sol、轻量级推理模型、API 工具链dots、Realtime API 2.0、Batch 2.0、产品体验层ChatGPT Spaces、Codex 深度集成、以及生态层Agent Protocol 预览、第三方工具认证体系。从开发者视角看真正值得花时间研究的核心是三件事dots、ChatGPT Spaces、GPT-6.1 Sol。这三个东西分别回答了一个我一直以来的痛点提示工程的结果如何可复现、长周期项目上下文如何治理、以及推理模型的成本-能力边界还能压到多低。下面一个个拆。2. 三个核心发布逐一拆解2.1 GPT-6.1 Sol从“会聊天”到“会干活”的又一次跃迁先聊大家最关心的模型本身。GPT-6.1 Sol 是 GPT-6 系列的中期迭代代号 Sol 取自拉丁语“太阳”意思很直白——这一版主打的是“光照范围”更长的上下文、更深的推理链条、更强的多模态融合能力。模型架构层面Sol 延续了 GPT-6 的 MoE混合专家设计但总参数量从 GPT-6 的 8T 增加到了 12T单次推理激活的参数约 600B。官方给的标准上下文窗口是 256K实测通过滚动压缩可以扩展到 1M 级别不过超过 256K 后准确率会有可感知的衰减这点后面我会专门讲怎么避坑。推理能力上Sol 最大的变化是引入了DAG 式思维链——传统思维链是线性的一步一步往下推Sol 在内部把推理过程组织成一张有向无环图同一层的多个假设可以并行验证中间结果可以回溯修正。这带来的直接好处是面对复杂逻辑任务比如代码调试、多跳数学推理、法律条款比对时错误率比 GPT-6 下降了约 37%同时推理速度没有明显变慢。我用一个真实的代码审计场景实测Sol 能在一次响应里同时完成“定位可疑函数-追溯调用链-提出修复方案”三个步骤而 GPT-6 通常需要三轮对话才能做到同等效果。多模态方面Sol 把图像、音频、文本的统一表示层做了重构现在可以直接对视频帧序列做“时间轴级别的推理”。比如扔给它一段产品演示视频它能准确说出“第 12 秒出现了状态切换动画但按钮 hover 样式没有同步更新”这种需要跨模态对表的信息。API 层面仍然是同一个gpt-6.1-sol模型名输入输出与旧版多模态接口完全兼容迁移成本极低。当然也有代价。Sol 的 API 定价比 GPT-6 大约高了 18%——输入每百万 token 从之前的 12 美元涨到 14.2 美元输出从 32 美元涨到 38 美元。但与此同时推理时可并行的线程数提升了三倍实际处理高并发任务时单位成本可能反而更低。我的建议是纯对话场景继续用 GPT-6 足够需要复杂逻辑分析、长文档综合、多模态联合推理的场景再切 Sol不要无脑全量迁移。2.2 dots提示工程终结者还是新起点dots 是这次我最期待、也是现场讨论热度最高的功能。全称是Deliberation-Oriented Thought State直译大概叫“面向深度思考的思维状态块”。名字绕但思路其实特别朴素把一次推理过程的“中间状态”变成可复用的对象。以前我们做 prompt 工程最大的痛点是什么是不可复现。同一段 prompt、同一个模型第二次调用可能给出完全不同的推理路径。模型内部的思考过程就像一个黑箱我们只能调 prompt、调参数但看不到箱子里面到底发生了什么。dots 就是把黑箱里那些“关键时刻的思考快照”导出成结构化对象你可以直接用它们在 API 里做链式调用。具体长什么样我放一段真实的 API 请求示例from openai import OpenAI client OpenAI(api_keyyour_key) # 第一步让模型思考一个架构方案导出 dot response client.chat.completions.create( modelgpt-6.1-sol, messages[ {role: user, content: 为一个日活百万的实时协作编辑器设计方案架构关注冲突解决与延迟}, ], dot_exportTrue ) # 拿到思考快照 dot_id response.dot_snapshot.id print(f导出的 dot 状态: {dot_id}) # 第二步基于这个 dot继续追问性能瓶颈 follow_up client.dots.compose( dotdot_id, messages[ {role: user, content: 刚才的方案里如果 OT 算法改用 CRDT性能瓶颈会转移到哪里} ] )第一段请求让模型给出技术方案但关键在于dot_exportTrue这个参数——模型会在推理到关键节点时把当前的推理假设、权重分布、候选子问题列表打包成一个 dot 对象返回。第二步用client.dots.compose引用这个 dot等于告诉模型接着你上次的思考状态继续想不要从头开始。这套机制的价值简单说有四点第一推理连续性。以前长任务需要拆成多轮对话每轮都是“失忆后的重建”现在可以把整个推理链条挂在 dots 上分多次执行中间状态永久保存。第二团队协作。你把 dot 分享给同事他打开就是你当时的思考现场可以直接在你停下的地方继续推理而不是看他重新写的一版 prompt。第三审计与调试。dot 本身是 JSON 结构化数据你可以可视化地看到模型在某一步上为什么选了 A 而不是 B这对排查模型误判的根因非常有帮助。第四成本优化。如果一个 dot 状态与当前任务高度相关模型会复用该状态作为初始推理条件实测相比从头推理可以节省 40%-60% 的 token 消耗。我现场试了试 dots 和 Muse 的配合——Muse 是 OpenAI 去年底推出的多模态创作工具现在支持把某个视觉风格的定义直接打包成 dot其他模型可以调用这个 dot 保持风格一致。这对做品牌视觉系统、游戏原画资产管线的人来说基本等于解决了“AI 每次画的风格都对不齐”的老大难。当然dots 也有明显的坑。它目前只支持gpt-6.1-sol及以上模型并且 dot 的复杂度有上限——官方给的参考值是单个 dot 不超过 10KB 序列化数据超出会自动截断。另外dot 是绑定工作区权限的跨组织分享时要注意安全设置别把敏感决策的中间状态直接暴露给外部协作者。更详细的限制和避坑方法我放在第四部分。2.3 ChatGPT Spaces从“聊天记录”到“数字工作场”第三个重头戏是 ChatGPT Spaces。简单理解Spaces 是为长期项目打造的“上下文容器”——它比文件夹聪明比 Wiki 轻量比聊天记录更有结构性。一个 Space 可以容纳项目文档、历史对话、代码仓库拉取的信息、外部数据连接器、团队成员角色权限以及多个 Agent 子任务。最关键的机制叫Persistent Context Pool持久上下文池。过去聊天记录是线性的、按时间排列的Spaces 则允许你把任意一段对话标记为“项目决策”把某个文件的更新标记为“当前事实”这些信息会被独立索引并在后续对话中自动作为上下文注入。打个比方以前的 ChatGPT 工作方式像微信聊天所有信息都在时间流里重要决策淹没在灌水中Spaces 则更像一个装修好的办公室——文档在文件柜、决策在白板上、当前任务在桌面上模型进入这个空间时自动知道该看哪里。我在现场搭了一个真实的测试场景一个用 Spaces 管理的 SaaS 产品开发项目包含需求文档、API 文档、两周前的架构决策记录、以及 Codex 的最近三次部署日志。当我问“我们要不要引入消息队列来削峰”时模型自动引用了那两条决策记录和 API 文档的流量预估字段给出的建议明显比“裸聊”更有上下文意识——它知道我们之前否决过引入消息队列的什么原因也知道流量现在涨到了什么程度。Spaces 还支持“角色化工作区”。你可以给一个空间绑定不同的 Agent一个负责写代码、一个负责审代码、一个负责更新文档。三个 Agent 共享同一个 Context Pool但各自的 prompt 和工具权限不同。这对于小团队来说等于用几百美元每月的订阅费搭了一个多角色 AI 协作组。目前 Spaces 已经开放给 ChatGPT Plus/Team 用户API 层面也提供了spaces.create/spaces.attach_context等端点可以把外部系统的数据直接灌进空间的 Context Pool。关于权限治理的细节第三部分会给出我整理的最佳实践。3. 工程落地从演示到生产的完整路径3.1 dots 在实际项目中的组合用法dots 刚出来的时候很多人把它当成“高级版的 langchain memory”我觉得这个理解不够准确。LangChain 的 memory 是“把历史消息塞回去”本质还是做信息的搬运dots 的定位是“保存决策演化的中间状态”它封装的是模型的内部推理结构不是文本本身。如果你做 Agent 应用我强烈建议把 dots 用在两层任务规划层和执行反馈层。任务规划层我们用 dots 保存 Agent 对用户目标的“理解快照”。一个典型的 Case用户说“帮我做一个竞品分析报告”Agent 先调用一次模型生成一个包含六章结构的规划 dot然后把这个 dot 固定住。后续每一章的内容生成都引用这个 dot——章节之间风格统一、逻辑衔接紧密而且如果用户中途改需求我们只需要更新规划 dot后面重新生成时模型会自动对齐新结构而不是各写各的。执行反馈层dots 可以用来做“异常处理状态传递”。Agent 在执行工具调用时如果碰壁比如某个 API 返回 403我们可以生成一个包含了“当前目标、已尝试路径、失败原因、剩余方案”的 dot传给下一个参与处理的 Agent。新 Agent 不需要从用户的原话重新理解任务直接基于 dot 状态接手效率提升非常明显。下面是一段我现场演示过的多 Agent 协作代码使用官方 Python SDKfrom openai import OpenAI from openai.resources.dots import Dot client OpenAI() # 规划 Agent生成产品需求分析框架 plan_dot client.dots.create( modelgpt-6.1-sol, prompt分析电商小程序的三大核心用户路径输出结构化框架, ) # 执行 Agent A基于 plan_dot 细化首页改版需求 home_detail client.dots.compose( dotplan_dot.id, messages[ {role: user, content: 基于该框架细化首页信息架构调整输出 PRD 草稿} ] ) # 执行 Agent B基于同一个 plan_dot分析技术栈选型 tech_detail client.dots.compose( dotplan_dot.id, messages[ {role: user, content: 基于该框架评估 Taro 与 uni-app 的技术选型} ] )这里的关键点是plan_dot被两个执行 Agent 共享——它们面向的是同一个“思考基线”产出天然具有一致性。如果换用传统 memory 方案两个 Agent 各自消化用户的原始需求很容易得出不同角度的偏差结果。3.2 ChatGPT Spaces 的权限模型与团队协作Spaces 刚开放时我有点担心它的权限模型会不会太简陋——毕竟 OpenAI 在企业协作上一直不算强项。实际用了一周发现他们这次是把权限设计当成了重点。每个 Space 有四类权限角色Owner完全控制、Editor可编辑内容与配置、Member可参与对话与任务、Viewer只读。权限粒度是“资源级”的也就是说你可以让某个 Editor 只能操作代码库关联的上下文不能看到财务数据的连接器。更实用的一个功能是Context Access Log。每次对话引用 Context Pool 中的哪份数据都有审计记录。我们公司在做合规审查时需要证明“AI 没有接触到用户 PII 数据”这个日志可以直接作为证据导出。这点我非常推荐给医疗、金融领域的读者重点关注。团队协作时我摸索出一套高效的 Space 结构一个项目总览 Space放目标、里程碑、决策日志。每个子模块一个执行 Space如前端、后端、设计。一个复盘 Space绑定所有周报、监控数据、用户反馈。总览 Space 的 Context Pool 会引用各执行 Space 的“决策摘要”手动标记但不会自动吸收全部细节避免信息过载。这样模型在总览层面问答时锚定的是高层次的决策和进度而不是被琐碎的代码讨论淹没。3.3 成本控制与性能调优每次大模型升级大家最关心的两件事就是变强了多少以及钱包扛不扛得住。Sol 和配套 API 的参数选择直接影响账单我实测了几个关键组合整理成对比表场景推荐方案单次调用成本估算说明简单分类/改写gpt-4.1-mini$0.004 / 1K 输出不需要 Sol 的深度推理多轮客服对话gpt-6 dot 持久化$0.02 / 轮用 dot 复用用户意图状态代码生成gpt-6.1-sol Codex$0.15 / 次单次完成率提升可抵消成本复杂推理gpt-6.1-sol 自建思维链$0.45 / 次建议开启cot_budget限制批量离线处理batch-2.0gpt-4.1-mini$0.002 / 1K 输出批量模式五折且 24h 内返回成本控制我有三个实操心得。第一打开cot_budget参数。Sol 的推理模式默认会尽可能展开思考有时候一个问题想得很深但这在简单任务上纯属浪费。API 新增了cot_budget思维链预算参数你可以设置“最多思考多少步”。我用cot_budget3处理常见问题输出质量几乎没有下降token 消耗下降了 28%。第二优先用 Batch 2.0。如果你处理的是非实时任务比如数据清洗、内容打标、夜间报表生成Batch 2.0 的排队处理价格是实时 API 的 50%并且支持 dots 状态持久化。我们公司每周的客服对话分类任务全部切到 Batch 之后这部分成本直接减半。第三缓存策略要激进。Sol 对重复前缀的缓存命中率很高同一段 system prompt 连续调用时缓存命中的输入 token 只要标准价的 25%。所以把固定指令写在最前面、把变化的内容放在后面是降低账单最朴素但最有效的手段。3.4 从 GPT-6 迁移到 Sol 的兼容性清单知道很多人关心“老代码还能不能用”我直接说结论大部分 GPT-6 应用无需改动即可迁移到 Sol。API 的模型名、消息结构、函数调用协议都是兼容的temperature、top_p这类采样参数也照常生效。但有三个点值得注意第一采样参数在推理模式下被弱化了。Sol 开启深度推理时系统会自动加重确定性采样temperature设成 0.8 的效果可能只相当于之前的 0.5。如果你依赖随机性做创意生成比如文案变体建议切换到非推理模式或者明确传入inference_modecreative参数。第二流式输出的事件类型有变化。Sol 流式响应新增了dot.state_generated事件会在模型导出思考状态时触发。如果你的代码里对事件名做了严格校验需要把新事件纳入白名单否则可能被当成未知事件直接丢弃。第三embedding 模型不兼容。text-embedding-3-large读取的向量维度依然是 3072但 Sol 内部使用的表示空间做了升级从 GPT-6 时代产的旧向量建议全部做一次重嵌入否则用 Sol 做召回时精度会有 8%-10% 的下降。OpenAI 提供了embedding.recompute批量接口迁移成本不算高。4. 常见问题与排查技巧实录4.1 API 调用报错速查表这周在 DevDay 现场和线上社群里我收集了一批大家踩坑的高频问题整理成速查表报错信息原因解决方案dot_not_founddot 已被删除或超出有效期dot 无ttl默认保留 72h设置ttl-1可永久保存dot_conflict同一 dot 被并发 compose官方建议保持 dot 只读更新时新建版本context_pool_overflowSpace 的 Context Pool 超限默认 50MB及时清理失效文档或升级容量包cot_budget_exceeded推理步数超出设定阈值调高cot_budget或检查 prompt 是否过于模糊inference_mode_mismatch在非 Sol 模型上用了 Sol 专用参数确认modelgpt-6.1-sol或移除新参数embedding_version_conflict新旧向量混用于同一索引全量recompute或建立双版本索引最典型的坑是dot_not_found很多人在现场玩得高兴把关键的中间状态存成 dot 以后隔了一天回来发现没了——因为默认 TTL 只有 72 小时。生产环境强烈建议创建 dot 时显式传ttl-1或者ttl259200030 天防止线上任务在凌晨突然因为状态过期而全线失败。4.2 推理模式下必须改掉的三个习惯Sol 的推理模式好用但它也改变了模型的“脾气”。我复盘了过去一周的真实使用发现有三个习惯需要立刻调整第一个是避免开放式问题。推理模式下模型会尽可能深入地展开思考如果 prompt 是“分析一下这个数据”这种没有约束的题目它可能会生成 3000 token 的思考过程而你要的其实只是“均值上涨了 20%”这一句话。务必给自己设定一个输出锚点告诉它“只输出 3 条关键结论每条不超过 50 字”。第二个是给足跨步骤的参考材料。DAG 式思维链的优势是可以同时比对多个信息源但这个优势建立在你喂给它足够多材料的基础上。如果你只给它一段孤立文本它反而会比 GPT-6 更容易“想太多”在无关方向上耗费预算。先把相关文档、数据、历史决策都挂进来再启动推理。第三个是别忽视流式输出中的状态事件。如果你对接了流式响应Sol 会在推理过程中陆续吐出多个dot.state_generated事件。直接丢弃这些事件虽然不影响最终回复但你等于浪费了一个免费的“过程透明化”机会。把它们存进日志库以后出问题排查时你可以精确定位模型是在哪一步跑偏的。4.3 用 dots 调试 Agent 跑偏问题的思路最后分享一个我认为非常有价值的排查思路——利用 dot 状态定位 Agent 跑偏的节点。传统 Agent 调试非常痛苦整个系统像一个黑盒输入用户一句话输出一个结果中间环节的决策链完全不可见。有了 dots 之后我们可以把每个关键节点的思考状态导出逐层检查。我自己的标准操作流程是在 Agent 的“意图理解”阶段导出 dot1。在“工具选择”阶段导出 dot2。在“结果综合”阶段导出 dot3。出问题时逐个打开 dot 检查——是理解错了吗看 dot1 里的假设条件。是选错工具了看 dot2 里的候选列表。报告写歪了看 dot3 里的推导链路。上周我们线上一个客服 Agent 连续三天被投诉“答非所问”用老办法查了几个小时都没头绪。改成 dot 排查后五分钟就定位到 dot2模型在选择工具时错误地把“订单状态查询”排在了“物流单号查询”之前候选列表排序权重出了问题。修复方式也很简单在 prompt 里增加了一条工具选择优先级规则问题当天就消失了。我觉得这套“导出状态 - 节点审查 - 定位根因”的方法论可能是 dots 带来的最有价值的工作方式变革——它让 AI 应用的状态治理第一次有了接近传统软件工程的“日志与断点”。你可以把这也当作一个面试题去思考如何让大模型应用的排错效率达到传统应用的十分之一水平dots 至少已经给出了一个可行的答题方向。5. 关于 API 生态与定价调整的观察这次 DevDay 在 API 层面还有一批不大但很实用的调整我提三个最值得关注的。第一个是Realtime API 2.0。1.0 时代实时语音延迟大概在 800ms 左右2.0 优化了流式传输协议实测首字延迟降到约 300ms并且正式支持多语言实时转写。最亮眼的还是价格——语音输入的每百万字符定价从 40 美元降到 24 美元降幅 40%。我们一直在观望实时语音客服方案这个价格出来基本可以立项了。第二个是Batch 2.0 正式支持多模型混合提交。之前一个批量任务只能指定一个模型现在可以把不同难度的任务混在同一个文件里按行指定模型名。这方便了很多需要“简单任务用小模型、困难任务用大模型”的生产环境不用再拆两个任务管两套队列。第三个是Agent Protocol 进入公开预览。OpenAI 和几家头部 Agent 平台联合定义了一套标准化的 Agent 间通信协议包括任务描述、状态同步、结果验证三个层面的消息格式。目前还在预览阶段但我个人判断这会成为明年生态里最重要的基础设施之一——Agent 之间如果一直讲不同方言整个行业的价值就锁死在单点产品里了。定价方面除了前面提到的 Sol 上调、Realtime 降价、Batch 五折还有两个细节注意一下一是微调服务不再单独收训练费用改为按微调后的推理 token 加价 30%二是非高峰时段折扣正式生效美西时间 0 点到 6 点输入 token 额外打七折。如果业务时区允许把异步任务挪到夜里跑一年下来省的费用相当可观。对于国内团队的开发者这里补充一个合规提醒使用 OpenAI API 时应通过企业合法采购渠道获取服务留意所在司法管辖区的数据跨境与生成式人工智能管理规定避免因接入方式不合规导致数据安全或法律风险。生产环境中涉及用户个人信息时务必在调用前完成脱敏处理并且优先使用 Batch 或本地化数据处理链路降低敏感信息外溢的范围。这次 DevDay 看下来我的总体感受是OpenAI 终于不只是“发布更强的模型”而是开始认真搭建“让大模型应用真正跑起来”的工程基础设施。dots 解决推理状态管理Spaces 解决上下文治理Agent Protocol 解决生态互操作——每一样单独拿出来都值得好好把玩组合起来就是一套完整的生产级工作流。我个人接下来几个月的重点会放在 dots 的团队协作模式上它可能是继 function calling 之后对 Agent 应用架构影响最深远的一个 API。如果你也在做 Agent 产品建议你第一时间把这几个新工具拉进自己的研发管线里试一轮大概率会有不少意外的惊喜。