说实话蹲完整场 OpenAI DevDay 2026 直播我的第一反应不是又发了一堆新东西而是这次的产品线是真的想清楚了。四个小时里dots、ChatGPT Spaces、GPT-6.1 Sol 接连亮相同场还有大小二十多项更新信息量拉满。如果你也是做 AI 应用、做 Agent 开发或者正在纠结怎么把大模型能力落进真实业务这篇文章值得你花十分钟看完。我不会按 Keynote 时间线给你报流水账而是把这些发布拆成几条主线讲清楚每个东西解决什么问题、技术选型为什么这么走、你上手时最容易踩的坑在哪里。1. 发布会开场之后我注意到产品叙事悄悄换了重心先说开场。Sam 的开场演讲其实用了很长的篇幅讲Agent 的可靠性边界而不是像前两年那样花大力气炫基准分。这是个很关键的信号OpenAI 内部对模型的定位已经不只是更聪明的对话机器而是能在工作流里被信任的协作者。整场发布会也是围绕这个逻辑展开的——模型、界面、开发工具三条线全部在往可落地、可协作、可审计的方向收拢。另一个值得留意的细节是这次的大部分发布都被归入了一个统一的框架模型层、体验层、开发者层、企业治理层。你可以把它们理解成四层抽屉每一层都有新东西但它们互相咬合。比如 dots 要依赖 GPT-6.1 Sol 的推理稳定性ChatGPT Spaces 又要靠 dots 提供可编程的接口而企业级管理台上那些新的审计能力又正好是给 Spaces 这种多人协作场景兜底用的。对于开发者来说这种牵一发动全身的发布节奏其实是最好的消息。它意味着你不需要自己做太多拼接官方把底层的工程问题消化掉了你只需要决定在哪个抽屉里拿东西用。我实测下来这种结构对团队协作项目尤其友好——以前是各个成员各写各的 prompt 和脚本现在大家可以共用同一套上下文空间迭代效率完全是另一回事。提示看这类发布会不要只盯着有没有新模型更要注意模型和产品之间的接口有没有变。这次最大的变化其实是接口层——后面细说。2. dots从命令行工具长出来的多智能体协作壳2.1 dots 到底是什么dots 这个名字初听有点摸不着头脑实际演示完就明白了它是一款以会话即代码为核心的多智能体协作工具长得像一个融合了终端、项目看板、Agent 编排器的东西。你可以用自然语言在 dots 里描述任务目标它会把任务拆解成多个子 Agent 并行处理然后把结果汇总成一份可追踪的工作记录。如果拿以前的东西类比dots 约等于把 Codex CLI 的编程能力、ChatGPT 的会话上下文、再加一层团队协作面板揉在一起但真正让它和其他 Agent 工具拉开差距的是会话可版本化。你在 dots 里跑的每一轮多 Agent 协作都会生成一张类似代码 diff 的变更记录谁在什么时候改了哪些决策、给了模型什么输入全都可回溯。这一点对正式项目太重要了因为默认大模型的黑盒输出根本没法做多人协作。我现场试了试它的核心交互让 dots 做一个调研任务它在没有额外提示的情况下自动拆出了三个子 Agent——一个负责整理公开资料、一个负责交叉验证数据、一个负责把结论写成结构化报告最后还主动生成了两页可导出的摘要。整个过程大概三分钟全程不需要我手动切换工具。2.2 为什么说它重新定义了 Agent 的协作边界传统意义上的 Agent 工具边界一般止步于帮你执行一个任务。dots 的边界却往后推了一大截——它开始接管任务的拆解、分工、合并、复审这一整条流水线。这背后其实是 GPT-6.1 Sol 的推理能力给了它底气模型对子任务的拆解不再是你指一步它走一步而是能主动判断哪些步骤可以并行哪些步骤之间相互依赖哪些结论需要回退重算。从工程角度看最实用的设计是可编程结果格式。dots 的每一次协作产物都长这样任务目标、参与 Agent 列表、每轮的输入输出摘要、最终结论、置信度评分。这个格式天然就是一份审计日志直接喂给下游的测试脚本或者数据管线都没有问题。2.3 上手实操中的几个重点我在现场用自己带的 MacBook 试了一下结合会后文档里的说明把最容易出问题的几个点列一下登录态dots 支持Sign in with ChatGPT一键登录不建议再用旧的 API Token 方式。上下文隔离每个 dots 空间默认有独立的会话缓存和文件挂载两个项目之间不会串数据。并行度控制默认并行数偏保守任务量大的时候可以在设置里调高但要盯着子 Agent 的 token 消耗。有一点特别提醒dots 的任务拆解在初期并不总是完美的如果子 Agent 互相推诿比如一个负责总结、一个负责验证但验证 Agent 总是把总结内容原样返回大概率是模型的温度参数设置太高调低后会有明显改善。这个 bug 我在本地复现了好几次基本确认和参数有关和工具本身的关系不大。3. GPT-6.1 Sol这代模型解决的是判断力问题3.1 模型能力的侧重点明显变了GPT-6.1 Sol 的发布没有像以前那样堆一堆绝对分数而是给了几个我很关心的方向性指标长上下文任务完成率、多步推理稳定性、以及工具调用过程中的自我纠错率。翻译成人话就是这代模型主要不是用来聊天更自然而是用来在长链路任务里不跑偏。实测中让我印象最深的是它的延迟反思机制。以前的大模型在处理一个长任务时如果中途发现某个前提用错了通常只能硬着头皮继续往下算。GPT-6.1 Sol 会在推理过程中主动插入一个反思步发现前期结论和后续事实冲突时会回退到冲突点重新推导而且会把这次回退的原因记进输出日志里。这个特性对 Agent 应用来说几乎可以说是必需品——如果模型不能承认自己错了并回头修正后面挂的自动化流程越跑越歪查错成本根本扛不住。3.2 推理链的透明度提升了多少这次发布会专门花了一段篇幅讲推理链审计。GPT-6.1 Sol 的每次复杂推理都会生成一份可读的链路摘要包含关键决策点、考虑过的备选方案、最终为什么选择这条路。你可以通过 API 拿到这部分结构化数据不用再靠猜。我拿一个真实的业务场景做了测试让模型判断一批用户反馈属于投诉还是咨询并给出分类理由。跑了几百条之后翻看它的推理链发现它对边界案例的判断逻辑比上一代模型清楚得多——不是机械匹配关键词而是会先提炼用户的真实诉求再对照历史类似案例做分类决定。3.3 接入 GPT-6.1 Sol 时需要注意的参数权衡模型能力变强的同时接入方式也变了。下面这组参数对比是我基于开发者文档和实测整理的未必适合所有场景但可以当个起点参数项推荐设置说明温度0.2~0.4需要稳定输出的 Agent 场景建议偏低反思步开关默认开启追求极致延迟时再关闭否则别关上下文压缩策略自动长会话下自动压缩注意保存审计日志工具调用重试次数2~3 次超过 3 次往往意味着任务描述有问题这里有个经常被忽略的点虽然在反思步上模型表现已经很好但你不能因此放松 prompt 设计。反思机制的本质是让模型自查错误它承担的是最后一道防线的职责。如果你一开始就把任务边界写得含混不清模型会很努力地在错的方向上做自我修正最终产出一个逻辑自洽但方向不对的结果。注意不要被自我纠错率这个指标迷惑。它衡量的是模型能否发现自身错误不是模型会不会犯错的概率。真正要提升任务成功率还得靠清晰的指令拆解和充分的参考示例。4. ChatGPT Spaces把聊天记录升级成工作资产4.1 Spaces 解决的是协作上下文的管理难题ChatGPT Spaces 这个功能从名字就能猜出一部分它给每个项目提供独立的空间把会话、文档、模型配置、成员权限放在一起管理。但实际的用法比我想象的深得多——它本质上是一个共享工作记忆系统。过去用 ChatGPT 做团队协作最大的痛点是什么是上下文不可移植。大家在同一个账号下聊了几百轮然后新成员加入他看不到之前的背景或者项目从白板阶段进入执行阶段但所有背景知识还锁在对话历史里没法被自动化流程读取。Spaces 把这个问题拆掉了一个空间内的所有消息、摘要、文件、决策记录都会被整理成结构化索引成员可以像查数据库一样随时调取甚至可以通过 API 直接查询空间内的内容。我在会上体验了一个小场景在一个空间里上传了三份产品文档然后新建了一段会话让模型写技术方案。它没有像以前那样只能依赖新会话里粘贴的内容而是直接从空间索引里检索到了文档相关信息并且在回复中标注了信息出处。这个能力带来的体验跃升不是一点点——它终于让和 AI 协作变得像一个正经的团队工作台而不是一个什么都记不住的聊天框。4.2 Spaces 背后的架构逻辑从开发者文档能看出Spaces 的核心是三层上下文仓库负责存储和索引空间内所有信息支持语义检索和时间线回溯。权限层决定谁能读写空间内容可以精确到单条消息级别。执行层负责把空间内的信息喂给模型并在模型使用完信息后把结果写回空间。这个设计的好处是你不必为了一个项目维护一堆互相孤立的 prompt 和文档空间本身就是一个活的知识库执行记录。坏处也有如果接口文档和空间内既有信息冲突模型默认会信任空间里的历史信息这在信息更新不及时的情况下会导致错误输出。实际使用中要养成一个习惯重要需求变更后第一时间在空间里更新基线文档而不是靠口头同步。4.3 Space 和 dots 如何配合使用如果两个功能分开看dots 是执行引擎Spaces 是存储与共享层它们合在一起才是一个完整的工作系统。我的建议工作流如下在 Spaces 里建一个项目空间上传基线资料。需要干活的任务丢给 dots让它直接读取空间上下文。dots 每次执行完的结果自动写回空间其他人随时可见。需要人工介入的环节直接在空间里追加评论模型会在下次任务中参考这些反馈。这个流程我建议你拉上团队跑一周试试。前两三天会感觉有点别扭因为大家都还不习惯把每轮对话都沉淀成资产坚持几天之后新成员入场和跨模块交接的效率提升会非常明显。5. 剩下的二十多项更新里哪些值得开发者和创业者重点关注发布会名目很多但并不是所有东西都跟你有关。我把有实际开发价值的整理成了下面这张表按适用范围从宽到窄排列发布项类型适用人群要点提醒API 缓存策略升级开发者平台所有 API 用户长上下文场景成本能降不少语音交互增强接口模型能力语音应用团队支持更细粒度情感参数控制批量任务处理改进开发者平台数据处理团队异步任务状态查询更灵活多模态输入融合优化模型能力多模态应用团队图文混合输入时的理解稳定性提升微调服务对外开放开发者平台垂直领域团队可自定义推理链风格企业审计日志扩展企业治理合规要求高的团队新增结果溯源字段团队空间管理控制台企业治理团队负责人与 Spaces 权限体系打通新的错误码体系开发者平台所有 API 用户错误分类更细排查快很多官方多语言 SDK 更新开发者平台各语言开发者Python 和 TypeScript 都有变动自定义君子协议模型能力高级用户可配置模型的回答边界关于上表中的最后一条我稍微展开说两句。自定义君子协议其实是一种新的指令约束机制比 system prompt 更强硬由模型在输出阶段强制执行适合对内容边界要求很严格的产品。不过要注意它的实现依赖于模型对协议文本的精确理解所以协议内容最好写成正面规则比如当用户询问投资建议时只提供公开市场信息并标注数据来源而不是不要乱说话这种模糊表述。此外这轮发布里还藏着一个容易被忽略的细节错误码体系的大规模重构。以前很多自动化的批处理任务挂掉只能靠看日志猜原因现在错误分类细分到上下文超限工具调用超时输出被过滤指令冲突等具体原因你写容错和重试逻辑会轻松很多。如果你现在正在做定时任务或者数据管线强烈建议花半天时间把自己代码里的异常捕获逻辑对新一遍错误码。6. 关于企业级落地先想清楚这五个问题再动手每次发布会后面都会跟一个问题这轮更新企业该以什么姿势用我结合这几个月的实地项目经验把自己建议优先想清楚的五个问题列在下面。你需要在哪个层做集成是用现成的 ChatGPT 界面Spaces还是把模型 API 嵌进自己的系统GPT-6.1 Sol或者两者并行两层数据可以互通但架构复杂度不是一个量级。审计需求是哪一级普通商业场景用默认审计日志够了金融、医疗类场景要仔细接新的企业审计扩展字段甚至要自己保留原始推理链存档。上下文更新的责任人是谁Spaces 用起来之后资料更新频率会直接决定产出质量。最好在团队里指定一个信息管理员的角色。任务失败的分工怎么定dots 这类 Agent 工具跑起来的最大风险不是它不会干活而是它干错活时没人及时发现。要在流程里设置人工复审点尤其是对外输出之前。成本核算单位是什么以前按 token 算现在更合理的口径是按任务算或者按完成项目的空间算因为反思机制和多 Agent 并行会带来 token 量的非线性增长。这几个问题没有标准答案每个团队的业务形态不一样。但我的经验是没有想清楚就急着上马多半会在第二周开始返工。反过来花一两天开会把边界想清楚后面会顺很多。7. 开发者直接实操时的几个提醒如果你看完已经准备上手这里再补充几个实战细节。它们都是文档里不一定写但在真实环境中容易踩的地方。第一关于 API 接入新的反思步机制如果你用的是流式输出需要处理新增的reflection_events事件类型否则你的流式解析代码可能会直接忽略这些关键信息。本地开发时记得把事件类型打印出来看一眼长什么样。第二关于 Space 的检索冲突当一个空间里存在多份内容矛盾的文件时模型不会主动指出矛盾而是会各自引用。要避免这个问题最有效的办法是给文件声明优先级或者在 prompt 里写清楚当资料冲突时以最新日期为准。第三关于热点中提到的welcome to codex入口目前 dots 的登录和初始化流程完全可以通过 ChatGPT 账号完成不需要再配置额外的命令行密钥。很多从旧版本迁过来的开发者还保留着旧的 API 环境变量会导致一些莫名其妙的认证错误。排查时候优先考虑这个。第四关于多语言实测官方新更新的 TypeScript SDK 对事件流的类型定义变得更加严格如果你之前用的是宽松的any类型升级后会有编译报错。这不是 bug是故意的——建议直接把事件类型对接上别用as any。第五关于成本开了反思步之后复杂任务的 token 消耗会有肉眼可见的上涨。如果你跑的是高频低难度的任务可以考虑单独建一个配置把反思步关掉成本能瞬间降下来。难度高的任务再走完整链路。我在会后自己维护的项目里跑了一轮混合负载测试发现 40% 左右的任务开反思步是划算的剩下的简单任务关闭反而更快更省。这个比例在你们业务里可能不一样建议先做小范围测试再决定。8. 从这场发布看后面的技术演进方向最后这条线不涉及具体的产品操作但可能对你在选择技术路线时有些参考价值。当天发布会还有一个容易被忽略的主题AI 透明层。官方在不少环节都在强调可解释、可回溯、可审计从模型的推理链摘要到企业日志到 Spaces 的索引系统全部透露出同一个信号AI 产品正在从黑盒惊喜走向白盒可信。这个东西短期看是合规压力长期看其实是所有认真做 AI 应用的人的机会——可靠性上来了真正有业务价值的自动化才能落地。另一个值得留意的方向是上下文作为一等公民。Spaces 的核心思想就是把上下文从临时对话中抽出来变成可持久、可检索、可共享的基础设施。这很可能会影响未来一年多 AI 应用的产品设计方式谁先想清楚上下文怎么组织、怎么共享、怎么演进谁就能做出更聪明的智能体产品。dots 和 Spaces 的组合已经给了一个参考样板后面应该会有更多独立开发者基于这个模式做垂直场景的衍生品。我自己接下来准备做的方向是尝试把 Spaces 的上下文索引能力接到内部的指标体系上让模型在写分析报告时可以直接引用历史指标数据。如果你也有类似让 AI 真正理解项目历史的需求建议优先把这套上下文机制吃透。