前排提醒这篇回顾写的是我参加完 OpenAI DevDay 2026 之后在回程路上和回来后一周内的实际整理。今年场子上的信息量非常大主舞台上不到 90 分钟就甩出了 20 多项发布核心中的核心就是三个词dots、ChatGPT Spaces、GPT-6.1 Sol。我尽量不写成新闻通稿式的罗列而是站在一个“要靠这套东西干活”的开发者角度告诉你哪些发布值得深入研究、哪些演示看看就好、哪些字段改动明天就能让你的代码报错。如果你正打算把已有项目往最新 API 上迁或者在做 Agent 类产品的架构选型这篇应该能帮你省下不少逐字逐句啃文档的时间。1. 本届 DevDay 的基调变了从“模型发布大会”变成了“系统能力发布会”先说整体感觉。往年的 DevDay大家蹲的是“新模型跑分又涨了多少、多模态边界在哪”今年主舞台的叙事明显换了——开场就是一段关于 agent 的 demo全程没有单独给某个模型拉一个十分钟的跑分专场。模型退到了后台工作流、持久化记忆、原子能力编排成了主角。这种转向不是临时起意而是在过去一年里所有产品线都在往“可组合、可落地”方向收敛的结果。1.1 开场的 Codex 回顾“Welcome to Codex”不是口号而是入口主舞台开头先用几分钟带过了 Codex 的情况包括命令行编码 agent 的登录方式现在直接支持 ChatGPT 账号打通开发者可以用同一个身份在命令行、IDE 插件和网页端之间切换上下文。现场演示的场景是一个账号在终端里写完代码切到 IDE 里直接继续同一个任务任务上下文没有断。我自己的感受是这个“入口统一”比 UX 细节重要得多。过去一年很多团队一直没把 agent 用起来卡点不是模型能力而是“任务上下文分布在三个工具里每个工具各记各的”。今年 Codex 与 ChatGPT 账号体系进一步打通等于把 session 归一化这件事提到了标准能力层面对后续的 dots 编排也做了铺垫。1.2 三层架构模型层、工作层、原子能力层如果你只看主舞台的 demo会觉得发布很多很散。但把 20 多项发布放在一起看其实就三层模型层GPT-6.1 Sol 系列以及配套的轻量模型、嵌入模型更新。工作层ChatGPT Spaces、持久化记忆、多 Agent 协同、文件与工具挂载。原子能力层dots——把复杂任务拆成最小可复用单元并定义这些单元如何被动态编排。理解这个三层结构之后很多“这个功能为什么这样做”的问题就迎刃而解了。比如 Spaces 为什么强调持久化存储、为什么支持空间级权限因为工作层要承接模型层和原子能力层之间的数据流动比如 dots 为什么定义一套协议而不是简单做几个模板函数因为它要成为原子能力层的通用底座。1.3 对开发者的影响赛道从“调 API”转向“搭系统”这个转变对独立开发者和中小团队的影响非常直白。过去一个 AI 应用基本等于“大模型 Prompt 几个工具函数”核心竞争力在于提示词和上下文构造。今年官方摊牌了单次对话式的应用形态正在被工作区 原子能力 多代理协同取代。如果你还用“一问一答”的范式设计产品体验上会被 Spaces 类的工作区降维打击。当然这不意味着人人必须立刻转架构但至少你应该开始往“系统化、可编排”的方向重构数据流否则后面接入 dots 和 Spaces 生态时会发现自己的数据模型根本对不上。2. dots真正的主角登场Agent 世界的“乐高积木”如果今年只能深入理解一个东西我建议是dots。它给我的冲击在于OpenAI 没有把它包装成“又一个 Agent 框架”而是一套原子能力的描述协议和运行时。你可以把一次复杂任务想象成一条需要多步骤、多工具、多决策的流水线dots 就是这条流水线上每个可独立拆分、可复用、可观测的“工序单元”。2.1 dots 到底是什么一套原子能力编排协议通俗讲dots 把 agent 执行过程中的“思考、动作、记忆读取”拆解成标准化节点并用一套带版本、带输入输出 Schema、带重试策略的元数据格式去描述它们。官方 SDK 里一个 dot 最小定义大致是from openai import Dots dot Dots.define( namefetch_and_verify_page, input_schema{url: str, expected_keys: list[str]}, output_schema{status: str, extracted: dict}, retry_policy{max_attempts: 3, backoff: exponential}, )定义完的 dot 可以被调度器编排成一条链。链的执行不是简单的“顺序调用”而是由模型在运行时动态判断哪些步骤可以并行、哪些需要回退、哪些失败后可以走降级方案。我在现场试了下官方给的一个例子非常形象——准备一份含多个数据源的行业报告第一步 dot根据用户指示列出报告框架第二步 dot并行抓取三个数据源每个数据源一个独立 dot互不阻塞第三步 dot对抓取结果做一致性校验发现冲突则触发另一个 dot 去二次核验第四步 dot组装成 Markdown 报告并输出。整个链跑的日志里会展示每个 dot 的入参、出参、耗时、token 消耗让我直接想到在“给 agent 装上可调试的齿轮箱”。2.2 核心拆分方式决策点、动作点、记忆点官方文档把 dot 归纳成三类这个分类对搭建自己的任务链很有帮助类型作用典型示例决策点基于输入判断后续路径判断用户意图、判断数据是否充分、决定分流到哪个子链动作点执行一个具体可验证的操作调用外部 API、操作文件、写数据库、发起搜索记忆点读取或写入持久化上下文保存中间结果、读取用户偏好、更新空间记忆我建议所有想用 dots 的团队先把自己现有业务里的 agent 流程画成这三种点的组合。这一步做扎实之后你会发现百分之七八十的“智能行为”其实是可以被明确拆出来的确定性逻辑真正需要模型自由发挥的部分只占少数。2.3 与 Muse 的区别Mind 与 Hands 的分工现场很多人疑惑 dots 和同时提到的 Muse 是什么关系。我听到的解释很直白Muse 管“灵感和方案库”dots 管“干活和编排”。你可以把 Muse 理解成官方维护的剧本库里面有大量针对特定行业或任务的最佳实践模板dots 则是这些模板落地时的执行引擎。两者配合使用时Muse 提供初始链路设计dots 负责运行时调度和失败恢复。实际操作中我觉得 Muse 的价值在于模仿新人团队照着 Muse 里的模板跑通一遍真实任务再根据业务情况改 dots 参数比自己从零设计链路快很多。但如果详细程度不够也可以完全只用 dotsMuse 不是必需品。2.4 从实测看 dots 的落地体验我回来之后第一时间把内部一个“定时抓取竞品价格并生成对比表”的脚本改用 dots 重写了一遍。感受如下链路编排的收益是实打实的原来用硬编码流程抓取失败只能整体重跑现在每个抓取动作是一个独立 dot单个失败只重试对应节点整体成功率提升明显。但dots 不是万金油。如果你的任务本质上就是“单次大模型调用”强行拆成几十个 dot 只会增加延迟和复杂度。调试体验是我最喜欢的变化因为每个 dot 都有输入输出记录排错时不需要靠日志盲猜直接看链路里哪个节点不符合预期就行。需要注意dots 目前的强项是“有明确边界的中长流程”例如报告生成、多步研究、自动化运营流程。但如果你的需求是高度开放式的闲聊型对话或者需要极强的实时交互反馈dots 暂时帮不了太多更多还是要交给 Spaces 对话内存去处理。3. ChatGPT Spaces把“对话串”升级成“持久化工作区”Spaces是今年工作层最重的更新没有之一。它解决的痛点非常具体ChatGPT 过去是一个一个的会话每个会话上下文独立跨会话记忆虽然有但颗粒度太粗无法区分“这个项目相关的资料”和“另一个客户的偏好”。3.1 Spaces 的设计动机上下文碎片化问题如果你用 ChatGPT 干过真正的长期项目一定会碰到这种痛苦项目相关文件散落在不同对话里A 对话里订的方案到 B 对话就找不到上下文想带同事一起协作得把一长串聊天记录甩给对方想控制某些敏感资料只给特定项目用但是权限边界在对话形态下几乎没法做。Spaces 的逻辑是建立独立持久化工作区每个空间有自己的文件库、记忆库、工具配置与成员权限。对话只是空间内部的一次操作而不是数据的载体。这个改动从根上把“聊天”和“工作”剥离开了。3.2 空间内存结构化记忆与权限隔离空间里新增了“空间级记忆”的概念支持显式写入关键结论和偏好而不是仅靠模型从历史对话里隐式推断。例如你可以直接说“在这个空间里所有输出格式优先使用中文表格”这条就会写入空间记忆并被后续任务稳定引用。权限隔离做得比我想象得细管理员可以配置空间内文件对成员可见或只读API 访问空间时也可以限定某些 dot 只能读指定的记忆块。这意味着面向客户场景的交付可以做到“一个空间一个环境”互相不串数据。3.3 协作模式多 Agent 在同一空间内的协同另一个值得关注的点是一个空间里可以同时跑多个 Agent每个 Agent 有不同职责。官方 demo 里设置了一个“调研 Agent”、一个“撰写 Agent”、一个“审核 Agent”用户在空间里同时盯三路输出并通过统一的消息流调度他们。对于团队协作这个形态的意义在于工作产品沉淀在空间里人是通过空间去指挥 Agent 而不是在几十个零散会话里翻找。我实际用下来空间内任务交接比过去“转发整个聊天记录”得体很多。3.4 与现有工作流的整合尝试官方提供了 Spaces API可以创建、归档、配置空间也可以在空间里挂文件、跑 dot 链。我建议团队接入时先做一个低成本 PoC把当前用“文件夹 文档 多会话”管理的一个真实项目完整搬进一个 Space定义好成员角色和空间记忆再评估是否有明显提效。不要一上来就指望 Spaces 替代所有协作工具——它更适合作为 AI 任务的“工作台”而不是整个公司的文档系统。另外一个小贴士Spaces 支持导入现有 ChatGPT 会话但导入后要注意检查哪些核心事实是对话里临时抽出来的。正式使用时还是建议把关键约束写进空间记忆别把旧对话当长期记忆用。4. GPT-6.1 Sol模型层的能力增长没有偏离主线GPT-6.1 Sol 的发布节奏挺有意思。它没有走“参数更大、跑分碾压”的路线而是把重点放在长上下文、低延迟、结构化输出的稳定可控。这三点恰恰是为 dots 和 Spaces 这两个上层产品服务的。4.1 Sol 的三个关键词长上下文、低延迟、结构化输出先说长上下文。Sol 把官方建议有效工作长度提升到了单任务 10M token 级别。我自己用一个超长代码库测试过让它在散落于各目录的十几个文件里找“所有与支付回调相关的状态流转”虽然响应时间明显变长但准确率保持得不错没有出现早期长上下文模型那种“开头记得、结尾全忘”的崩溃感。低延迟方面Sol 对短 prompt 的响应和上一代旗舰比有所提升但更明显的是它在长流程里的输出稳定性——token 喷射、上下文漂移等现象更少了。这对 dots 编排非常有价值。要知道一个十几个节点的任务链只要有一环输出格式不稳定后续所有步骤都会连锁抖动。4.2 基准测试上看什么指标这次官方没有过于强调传统跑分我更关注的是这些指标长文本中段引用准确率从长文档中随机段提取并交叉验证的能力多步工具调用成功率连续调用 8 次以上工具时每一步参数生成和结果解析的正确率结构输出约束遵循率在严格 JSON Schema 下生成内容时的合规率。这些指标才是决定 agent 应用实际可用性的关键。站在使用者角度跑分再高如果多步调用成功率不高落地就是灾难。4.3 与之前模型的对比和兼容性模型命名上Sol 仍然延续了 6.x 系列所以 API 调用方式、参数名、模型别名结构与之前基本一致。升级迁移体验比我想象中顺滑from openai import OpenAI client OpenAI() resp client.responses.create( modelgpt-6.1-sol, input[{role: user, content: 总结这个项目状态}], )从旧模型切换到 Sol 主要注意两点一是新模型在部分边缘 case 上行为会有变化建议先在影子模式跑一段时间对比二是部分老工具类函数调用写法可能在新的结构化输出协议下需要调整字段名。官方会提供自动迁移工具但千万别指望它一次性把复杂链路完全改对。5. API 与成本开发者最关心的账本变化发布会下半段密集输出了一批 API 更新。说实话有些更新在舞台上就是一句话带过但对开发者的账单和架构影响却很大。5.1 新的定价与缓存机制本届在 API 计费上的变化可以用一个关键词概括分层缓存。官方引入了跨空间的共享缓存同一组织内多个空间跑相同前缀的请求时命中缓存后 token 费用大幅降低。项目旧机制新机制短 prompt 价格按标准单价计保持不变长上下文重复前缀可命中单会话缓存支持组织级共享缓存多空间共同预处理不支持命中后约降 50% 成本实测下来对于“多个 Agent 反复读取同一批知识”的场景帮助显著。我们的一个调研型任务开了共享缓存之后token 账单下降明显效果超出预期。5.2 结构化输出与函数调用的改进另外值得专门提的是结构化输出协议的升级。新版允许你定义嵌套更深的 Schema支持数组内对象引用和条件字段。对 dots 链路来说这意味着动作点的输出可以被上游严格约束不需要每个点都做一次自由文本解析。还有一个细节函数调用的“工具描述”现在可以单独设置缓存优先级高频工具的参数模板不再重复计算 token。如果你的服务有大量固定调参的 tool call这一步省出来的费用很可观。5.3 何种场景值得升级我自己会建议分场景评估正在做长流程 agent 任务的值得立刻评估迁移到 dots Sol 的新链路成本收益大概率正向。主要业务是短对话、分类、抽取的可以按需升级到 Sol但不必马上重构到 Spaces避免过度设计。高频工具调用、参数模板固定的务必把缓存机制测一遍降费效果最直观。不管怎样升级前一定先做成本预估建议拿一周的真实请求日志重放一遍对比新旧模型的 token 消耗。不要拍脑袋。6. 安全与工程实践会话恢复、数据边界与 Key 管理今年安全问题被提到了一个很靠前的位置。主舞台上专门给了时间段讲数据边界和会话安全这背后显然是过去一年里出现了不少真实的账号会话泄露事件。6.1 会话 JSON 泄露后的处理流程我见过不止一个团队在代码仓库、云日志或调试工具里误把 ChatGPT/API 的会话 JSON 打了出去。这里给一个标准处理流程立即吊销相关 API Key如果会话里有 key 信息先进控制台吊销不要先尝试“看看泄露到什么程度”。轮换认证令牌账号层面的访问令牌、refresh_token 全部重新生成如果开了 OAuth 第三方授权也得检查授权列表。检查设备绑定与登录会话确认是否有陌生设备或陌生地区登录记录有则强制下线。开启审计日志官方现在支持组织级审计日志开起来之后去检索敏感时间段的调用记录判断是否有异常读取。复盘泄露路径最常出问题的是前端调试面板、CI 流水线日志、崩溃上报服务。把这几个位置的鉴权和脱敏规则重做一遍。我强烈建议每个团队都把这套流程提前写成 runbook而不是出事之后临时翻文档。6.2 Spaces 的数据隔离设计Spaces 在数据隔离上做了几层防护我在实测中的感知是空间与空间之间的记忆、文件默认不互通通过 API 访问空间时需要在空间令牌上声明可访问的 dot 范围成员邀请支持只读、编辑、管理员三档权限且对文件、记忆、工具分别生效。这在多租户场景下比较从容。如果你做的是 B 端产品可以直接按“一个客户一个空间”隔离配合组织级审计日志基本能满足合规审查的要求。6.3 API Key 的安全管理建议我再啰嗦一遍老生长谈但今年因为 dots 和 Spaces 的出现又有新坑不要把 API Key 直接写进 dot 的 input_schema 里作为默认值这会让 key 出现在链路日志中使用官方推荐的密钥注入方式通过环境变量或密钥管理服务绑定到空间运行时千万别因为“方便分享”就在团队群里传 key 或会话 ID。官方明确提示会话 ID 具有读取相关上下文的能力一旦被外部拿到等于把空间记忆半公开了。安全无小事今年这些新产品新特性给开发效率带来提升的同时也意味着攻击面变大了。7. 其他值得关注的发布20 项的拼图里还有这些最后把几个容易被忽略、但可能影响你技术选型的发布列一下给个简要判断。7.1 轻量模型与本地部署今年推出了一组更小、更便宜的嵌入/推理模型组合。它们在复杂推理上弱于 Sol但部署成本和延迟都比较友好。对于简单分类、召回、质检类场景这种“小模型扛量、大模型扛质”的组合比全部请求都走旗舰模型合理得多。我建议在架构设计里把模型按“任务难度”分流不要图省事统一走大模型。7.2 音频与多模态接口更新API 在语音方向加入了兼容性更强的实时语音协议延迟进一步降低。对做语音交互产品的团队来说这值得单独做一轮技术评估因为新协议在抑制吞字、打断响应和说话人分离上有明显改善。另外多模态输入的计费结构调整了图片比之前更便宜适合把界面截图分析类功能重新算一下成本。7.3 微调与蒸馏工具的升级微调流程迎来了新的蒸馏模式可以用大模型生成标注数据再通过新的训练管道蒸馏到小模型。整个流程更自动化且支持直接用小模型 大模型的混合评估集判断效果是否达标。这对想把成本打下来的中大型团队是个好消息。不过提醒一句蒸馏不是万能的长尾场景里小模型的效果仍然需要抽样评审别只看整体指标。这次 DevDay 看下来我最强的感受是整个生态终于开始认认真真做“可落地的系统”了。模型不再是孤立的天才而是嵌进一套有边界、可观测、能协作的工作流里。dots 和 Spaces 的组合实际上是在逼所有 AI 应用开发者回答一个问题你的产品是“一堆 prompt 的集合”还是一个有持久记忆、有原子单元、有权限控制的完整系统对我个人来说回来后做的第一件事就是把手头几个核心业务流程画成决策点、动作点、记忆点三类节点。这一步不急着接代码但把图画完接入 dots 就顺理成章了。如果你也想在团队里推进这套东西建议从一个小工具链开始试——先跑通再铺开。如果最后能在项目里沉淀出一套自己的 dot 模板库那才算是真的把这次 DevDay 的发布消化成了生产力。