说实话今年 DevDay 放出 20 项发布时我的第一反应不是又来了而是终于来了。OpenAI DevDay 2026 这场 keynote 从 GPT-6.1 Sol 开场到 dots、ChatGPT Spaces 两个产品级功能收尾全程看下来最强烈的感受是模型性能的比拼已经不是重点了他们把大量篇幅花在了智能体怎么被团队真正用起来这件事上。这篇文章把我现场准确说是线上直播加会后文档看到的东西、实测的感受、踩过的坑都整理出来给还没时间啃发布会和文档的开发者一份直给的经验参考。1. GPT-6.1 Sol 到底升级了什么必须先说清楚GPT-6.1 Sol 不是 GPT-6 的跳代版本OpenAI 自己定义是6.x 时代第一款工程化型号。名字里的 Sol 取自 solar他们对这款模型的定位是能晒着太阳连续跑一天任务的模型说白了就是专门为长时间、多步骤的智能体任务设计的而不是为了单纯刷榜。1.1 模型定位从考试型到工作型过去两年模型比拼的是单轮回答质量现在大家真正头疼的是让模型在一个长任务里连续决策上千步能不能不跑偏、不重复、不突然失忆。GPT-6.1 Sol 的几个核心技术指标都是冲这个去的我挑重点说。上下文窗口拉到 4M token。注意不是支持而是可稳定使用。现场演示直接把一份大型代码仓库的索引文件塞进去做整体重构全程没有分段处理这个能力对大型项目管理是质变。输出侧延迟下降明显。官方给的数据是首 token 延迟平均降低 38%我实测一个中等复杂度的流式回复体感上确实接近实时。工具调用可靠性提升。Function calling 在连续 50 轮调用测试里的成功率从上一代的 91% 提到 96.4%。这对智能体场景很关键——以前跑长途任务一半失败是模型自己把工具参数编错了。我没法验证官方每个数字但从文档里能看出一个明显变化GPT-6.1 Sol 的 reasoning effort 参数默认值改了系统更倾向于在后台做多路径推演而不是只给一条最优路径。好处是复杂任务的成功率上去了代价是输出长度变长后面算成本时要注意。1.2 基准和实测分数高不等于好用官方放出的对比表里SWE-bench Verified 从 GPT-6 的 78.2% 涨到 83.5%GAIA 的 avg 从 71.4% 到 76.1%Multilingual MMLU 也有 5 个点左右的提升。这些数字在发布现场很正常但我自己跑了三个真实任务感受会更具体。第一个任务把一个遗留 Python 服务的依赖从 pip 迁移到 uv60 多个包的版本兼容冲突模型全程自己查文档、改配置、跑测试只在中途问了我一次是否允许执行 shell 命令。第二个任务让模型把一份 PDF 发票批量转成结构化 JSON100 份文件里第一次跑就有 93 份直接成功剩下 7 份是扫描件质量问题不算模型责任。第三个任务最意外是长对话记忆连续 3 小时的项目排期对话到后面它还记得 2 小时前随口提过的一句约束这在上一代模型上是很难做到的。我要提醒的是官方基准普遍是在高温采样、多次重试的条件下跑的实际单次调用会打折扣。别把 83.5% 当成一次就能成功的概率智能体框架里该有的重试、校验、人工确认环节一个都不能省。1.3 API 价格变化和一次典型任务的成本测算这次 API 价格调整对开发者其实是友好的。我列一下发布时公布的官方价项目GPT-6旧GPT-6.1 Sol新输入非缓存$15/M tokens$10/M tokens输出$60/M tokens$48/M tokens缓存输入$1.5/M tokens$1/M tokens批量 API 折扣维持 50% 不变但新增了实时 API 并发折扣流量低谷时段调用还能再省 20%这个放在后面 API 章节细说。我自己算了一个典型业务每天 5 万个请求平均每请求 2K 输入、1.5K 输出。按新价格2K 输入 × 5 万请求 1 亿输入 token按 $10/M 算就是 1000 美元1.5K 输出 × 5 万 7500 万输出 token按 $48/M 算就是 3600 美元。一天大约 4600 美元比旧价格6000 美元省了大概 23%。如果命中缓存输入成本还能压到原来的 1/10。对做 SaaS 的人来说这个降价幅度基本能对冲掉模型输出变长带来的增量成本。2. dots把多智能体协作变成了可视化画布如果说 GPT-6.1 Sol 是发动机dots 就是今年最值得关注的新驾驶舱。它在发布会上的定位是一个让多个智能体在同一块画布上协作、并且让人类随时介入的工作界面。按我的理解它的本质是把你发给模型一条消息升级成你在观察一群智能体如何分工完成任务。2.1 dots 是什么从对话到工作台dots 的界面是一块无限画布每个任务、每个子智能体、每个工具调用结果都是画布上的一个节点。官方起名 dot 是因为这些节点看起来就像一个个发光的点拖拽连接起来就形成一条工作流。最核心的区别在两点。第一多个智能体可以并行跑。以前在 ChatGPT 里你只能等一个对话串完成dots 里你可以派三个子智能体分别去查资料、写代码、做测试它们在画布上各自推进你一眼就能看到谁卡住了、谁已经完成。第二人类可以中途踩一脚。任何节点上都能暂停、插入意见、改参数然后让后续节点基于你的修改继续。现场演示了一个很直观的例子让一个智能体整理会议纪要另一个根据纪要起草邮件第三个工程师在邮件草稿节点上改了一个语气词后面所有下游任务自动带着这个修改重算。这个设计思路我很认可——它承认了 AI 工作流里人机协作不是按下就跑而是需要随时纠偏。以前做 agent 工作流纠偏只能靠改 prompt 重跑现在 dots 把纠偏变成了画布上的一个小操作。2.2 现场演示里最有价值的三个场景我整理了一下现场 demo真正能落地的场景是这三个。场景一是代码评审。两个智能体分别做静态扫描和逻辑走查结果并排显示在 dots 画布上评审人可以直接在每个发现的问题节点上写批注批注会同步回代码仓库的 PR 评论区。这个流程过去要在多个工具间跳来跳去现在一块画布走完。场景二是数据处理管线的可视化。智能体把原始数据清洗、特征工程、模型训练分成三个节点每个节点运行完会显示结果摘要数据质量不过关时会在对应节点亮红点。做数据的人应该能体会以前 pipeline 跑挂了只能翻日志现在故障点直接出现在你眼前。场景三是跨智能体记忆共享。dots 允许把某个节点的输出保存为画布记忆后续新任务可以引用。这个特性让多智能体协作不再靠反复传递上下文而是有了一块共享工作记忆token 消耗也跟着降。2.3 dots 和 Muse、Codex 的关系很多人在问 dots 和 Muse、Codex 到底什么关系。我的理解是Codex 是干活的命令行编码智能体Muse 是产出创意内容的面向设计、文案等创意场景的工具dots 是把它们串起来并让人类看得见、可控制的编排层。严格说 dots 不是替代 ChatGPT 对话而是对话的工作台化。目前 dots 以独立产品形态开放ChatGPT Plus/Pro 用户可以直接用免费用户每天有额度限制。API 形式还没全量开放但文档里已经能看到 workflow 的 schema 定义估计很快会把 dots 的工作流导出成可编程的 JSON 配置。如果你想在自己的应用里复刻类似机制现在可以先用 LangGraph 或自建状态机做雏形等官方 API 推出再迁移。3. ChatGPT Spaces 和它背后的持久化上下文思路ChatGPT Spaces 在发布名单里排得很靠前它其实是给 ChatGPT 加了一层持久化工作区的能力。过去你用 ChatGPT 处理项目会话是零散的换个话题就得开新窗口项目相关的背景、文件、约定全丢了。Spaces 解决的就是这个问题。3.1 Spaces 的前身与定位Projects 的全面升级用过旧版 Projects 的同学可以快速理解Spaces 就是 Projects 的全面升级版。区别在于 Spaces 不只是把聊天记录分组而是构建了一个真正持久的上下文容器里面有四样东西固定指令每个 Space 可以写一份系统指令该 Space 下所有会话自动继承不用每条消息都重复交代背景。共享文件库把项目文档、代码、数据文件放进去所有会话共享读取权限不用每次手动上传。智能体成员可以在 Space 里挂载多个专用智能体比如代码审查员知识库问答各智能体共享 Space 的上下文。外部工具连接支持挂接 GitHub、Slack、Notion 等事件可以自动触发 Space 里的智能体任务。最妙的是指令 记忆的分离设计。传统做法是把所有背景塞进一条超长的 system promptSpaces 则是把背景拆成多个模块模型按需加载。现场给的数据是同样完成一个跨会话项目任务Spaces 模式的 token 消耗比传统超长 prompt 模式省了约 40%因为不需要每次对话都重发全部背景。这个设计逻辑对做 RAG 的人应该很眼熟——本质上是把上下文改成检索式加载而不是全量灌入。3.2 团队协作细节权限、共享与隔离Spaces 的团队协作是这次发布里我比较意外的点做得相当完整三种角色Owner完全控制、Editor可编辑内容但不能改权限、Viewer只读。这个权限模型足够覆盖大多数小团队。跨工作区分享Space 可以生成分享链接对方以 Viewer 身份进入不需要是同一组织。上下文隔离每个 Space 的上下文预算独立不会互相污染。这在多项目并行时非常重要——以前在同一个账号里切换场景模型经常把另一个项目的约定带过来。审计日志企业版支持导出 Space 内的操作记录对合规要求高的团队是刚需。我试下来有个小坑Space 里的文件更新后模型引用旧版本的情况仍然会发生官方解释是模型按需加载文件快照意味着你需要手动触发刷新快照。建议团队在 Space 里约定一个刷新缓存的固定动作否则容易拿到过期上下文。3.3 数据边界和隐私设计要点OpenAI 这次在隐私方面的表态比之前更明确付费用户包括 Spaces 企业版的数据默认不用于训练企业版还支持保留策略比如自动删除超过 90 天的日志和 BYOK自带密钥加密。这些对想用 Spaces 做内部知识库的团队很重要。开发者需要注意Spaces 目前是纯托管产品数据存在 OpenAI 侧没有本地部署选项。如果你有强数据驻留要求我建议暂时只把非敏感流程放进 Spaces敏感数据仍然走本地 RAG API 自己搭。别图省事把所有内部文档一股脑全传上去等出事再后悔就晚了。4. Codex CLI 迭代与 Windows 安装踩坑记录DevDay 期间 Codex 相关的发布虽然没站 C 位但对开发者来说信息量不小。命令行智能体welcome to codex的时代已经过了介绍期这次发布的是成熟度更新并行子代理、MCP 协议支持、以及和 dots 的联动。我自己在 Windows 环境折腾了几天踩了个大坑必须单独写一段。4.1 welcome to codex命令行智能体的定位没有变Codex 依然是 OpenAI 的终端编码智能体核心卖点没变在命令行里用自然语言下达任务它自己读仓库、改代码、跑测试、提交 PR。DevDay 更新的重点有三个。支持并行子代理一个大任务可以拆成多个子代理并行处理最终由主代理合并结果这跟 dots 的多智能体机制是打通的。MCP 支持可以接入外部 MCP 服务器比如数据库查询、浏览器操作等于把工具生态开放了。会话持久化codex resume可以恢复之前的会话配合新的--json输出模式方便做脚本集成。我实际用下来的体验是中型仓库几万行代码的日常任务完成率明显比上一代稳特别是根据 issue 改代码并补测试这类任务基本能一条龙做下来。不过稳定性提升的同时单次任务消耗的 token 也涨了批量任务记得配合预算告警使用。4.2 missing optional dependency openai/codex-win32-x64 的完整排查过程这是我这几天最想分享的坑。在 Windows 上用 npm 全局安装 Codexnpm install -g openai/codex然后运行codex直接报错Error: Missing optional dependency: openai/codex-win32-x64. Please run npm install -g openai/codex again. Reinstall codex: npm install -g openai/codex --force第一次看到这个报错我以为是网络问题重装了三次都一样。后来才搞明白原因Codex 的主包是纯 JS 封装真正干活的是平台特定的原生二进制包openai/codex-win32-x64它作为 npm 的 optionalDependencies 在安装时按平台选择。某些 npm 版本或者自定义 registry特别是镜像源环境下optionalDependencies 解析失败会被静默跳过于是只有壳、没有芯。完整排查和修复步骤先确认环境平台和 Node 架构node -e console.log(process.platform, process.arch)正常输出是win32 x64。如果架构不对就要去查原生包是否支持该架构。查看 npm 配置确认 registrynpm config get registry如果用了镜像源先直接改成官方源试试npm config set registry https://registry.npmjs.org/强制重装让 npm 重新评估 optionalDependenciesnpm uninstall -g openai/codex npm cache clean --force npm install -g openai/codex --force验证原生包是否安装成功npm ls -g openai/codex-win32-x64如果 npm 一直装不上可以直接下载官方发布的 Windows 安装包绕过 npm。Codex 官方仓库的 release 页面有免安装版本解压后把二进制路径加入 PATH 即可。我最后是靠第 5 步解决的。如果你在公司内网环境建议直接下载离线包别跟 npm optionalDependencies 较劲。另外报错日志里会包含用户目录路径发布 issue 反馈时记得打码。4.3 跑通之后的三个小技巧Codex 装好后有几个提升体验的小技巧。交互模式和自动模式分开用。日常调试用交互模式codex进入聊天界面批量任务用codex exec --full-auto 任务描述后者不需要人工确认每个动作但记得放在有版本控制的仓库里跑方便回滚。密钥放在环境变量里不要写进对话。Codex 会读取环境变量来辅助执行任务把OPENAI_API_KEY或云服务密钥放进环境变量模型在生成代码时就能引用不会把它写死在文件里。定期codex logout再重新登录。会话时效较长但长期挂着会增加会话被误用的风险。我习惯每周登出一次顺便清掉本地缓存的认证文件。5. API 生态更新speech、价格与密钥安全今年的 API 部分没有特别炸的新模型但几个增量更新对生产系统影响不小。我把 speech、价格和安全三个主题放在一起说因为它们在实际落地中是连在一起的。5.1 OpenAI-compatible speech统一语音接口的意义所谓 OpenAI-compatible speech是指语音服务的接口更标准化了一个 endpoint 同时覆盖语音转文字和文字转语音支持流式输入输出并且兼容社区通用的 OpenAI API 格式。这意味着你用惯的 SDK比如 openai-python可以直接调用from openai import OpenAI client OpenAI() # 语音转文字 with open(audio.mp3, rb) as f: transcript client.audio.transcriptions.create( modelgpt-4o-mini-transcribe, filef ) print(transcript.text) # 流式 TTS with client.audio.speech.with_streaming_response.create( modelgpt-4o-mini-tts, voicesol, input你好这是测试。 ) as response: response.stream_to_file(output.mp3)新增的语音模型价格定得很低转写约 $0.006/分钟、TTS 约 $15/百万字符。对做实时语音助手、客服质检、内容配音的团队来说这个费用基本可以放心冲量。实测下来中文识别准确率比上一代明显好吞字和标点错乱少了很多。5.2 价格体系变化和预算建议除了前面 GPT-6.1 Sol 的单价下调API 部分还有几个值得注意的变化。实时 API 新增低谷时段折扣非高峰时段调用实时模型有 20% 折扣适合跑非实时任务但想用实时接口的团队。Prompt Caching 命中价格进一步下降且缓存失效时间从 1 小时延长到 24 小时。对重复调用相同 prompt 的 RAG 场景成本能压得很低。批量 API 的窗口从 24 小时缩短到 6 小时批量任务的时效性更强了。我给团队的建议是上线前先跑一周成本账单重点看输出 token 和缓存命中率两个指标。如果缓存命中率低于 20%说明 prompt 设计里动态部分太多该把固定背景挪到缓存友好的位置。如果输出占比超过 70%要考虑是不是 reasoning effort 开太高了适当调低能用更少的钱换足够的质量。5.3 会话 JSON 泄露了怎么办一次真实的安全事故处理复盘最后聊一个和每个用 ChatGPT/Codex 的人都相关的安全问题。最近社区里泄露了 openai 账号会话 json 怎么办的求助特别多我也处理过类似事故。所谓会话 JSON通常指 ChatGPT 登录后在浏览器本地保存的 Session 信息或者 Codex 保存在~/.codex/auth.json里的认证数据。一旦这些文件被你意外提交到公开仓库、贴进聊天群、或者被截图发出去攻击者就能直接用你的身份访问账号不需要知道密码。发现泄露后的处理顺序按紧急程度排立刻登出所有设备。ChatGPT 网页端进入设置 - Security - Devices点击 Sign out all devices强制所有已保存会话失效。删除对应认证文件。如果是 Codex执行codex logout并手动删除~/.codex/auth.json然后重新登录生成新会话。轮换 API Key。在 OpenAI 平台把可疑的 key 全部删除重建。这一步别偷懒只要 key 出现在可疑位置就全部换。检查用量账单。平台 Usage 页面看最近 24 小时的调用记录确认有没有异常的高额消耗。发现陌生模型调用立刻加预算告警。开启双重验证和登录通知。打开 2FA以及新登录设备通知让下次异常登录第一时间被你发现。预防比处理重要得多。我的习惯是所有含密钥、认证信息的文件统一放在本地目录加入.gitignoreGitHub 开启 push protection防止密钥被推到公开仓库API Key 永远只建子 key、用只读权限不用主账号 key 跑生产。补一句遇到声称能帮你恢复会话的第三方工具要特别警惕多数情况是想把你的新会话再钓走一次。6. 我接下来的采用建议和避坑清单发布会看完热度最高的东西不一定适合马上用。以我这几年跟进发布节奏的经验给几条实在建议。6.1 值得立刻迁移的三个场景第一长耗时智能体任务直接上 GPT-6.1 Sol。以前模型跑半小时就开始说胡话的任务现在明显稳工具调用也少出错。第二团队内部项目知识库可以搬进 ChatGPT Spaces特别是跨成员协作的项目共享文件库加固定指令这套组合省掉的 token 是实打实的。第三多智能体编排的探索可以从 dots 开始它把过去要写代码才能实现的并行协作变成可视化操作适合先跑通思路再决定要不要工程化。6.2 建议观望的两个场景一是生产环境大规模切换。刚发布的模型通常前两周会有零星稳定性问题线上核心链路建议等一两个 patch 版本再切。二是依赖 dots 的自动化流程。dots 的 API 还没完全开放现在做太深的集成可能被后续接口变化打脸可以先观察官方 schema 稳定程度。6.3 给团队的最小落地清单模型切换先在一个非核心项目跑 3 天压测记录成功率、延迟、成本三个指标和旧模型对比后再决定全面迁移。密钥管理本周内做一次 API Key 全量轮换删除不再使用的 key开启预算告警。Spaces 权限把工作区角色定义清楚Owner 不超过 2 人对外分享一律 Viewer。Codex 环境Windows 机器按第 4 节的方法预装好别让同事再踩 optionalDependency 的坑。会话安全全员统一规则禁止把 ChatGPT/Codex 会话文件截图或发到公开渠道。最后说点个人体会。每次 DevDay 之后我都在想距离真正把这套东西用出价值还有多远今年的答案比往年短。GPT-6.1 Sol 让我敢把更长的任务交给模型dots 让我看清智能体在干什么Spaces 让团队协作有了持久根据地——三个都击中了我日常工作里最痛的点。回头细想20 项发布里真正会改变我下个月工作方式的其实就这几样。你们也别急着追所有新功能先挑一个场景用熟比什么都重要。