OpenAI DevDay 2026：GPT-6.1 Sol、dots与Spaces重塑Agent工程-北京尧图网络

上午从DevDay 2026现场出来手机里存了三十多张PPT照片排队的空当已经把几个关键新接口的文档草稿翻了一遍。说实话过去几年的开发者日多少有些“模型秀”的味道但这一次的OpenAI DevDay 2026明显变了基调整场发布会的核心议题不是某个单点能力的炫技而是把Agent工程标准化。20多项更新里dots、ChatGPT Spaces、GPT-6.1 Sol这三样东西不是我预想中的“大新闻”却恰恰是接下来一年里普通开发者和中小团队最用得上的东西。如果你正在纠结要不要迁移模型、要不要把Agent任务拆成可追踪的流程或者想让团队从“翻聊天记录”里解放出来这篇文章就是照着这些需求写的。我会把发布会的重点拆开结合我在现场和回来后实测的经验讲清楚它们解决什么问题、怎么接入、坑在哪。1. GPT-6.1 Sol模型的进化方向其实在“省”字上1.1 Sol到底强在哪效率、多模态与工具调用先说结论GPT-6.1 Sol仍然是一个推理优先的大模型但这一代的侧重点不是“更难的问题也能答”而是“同样的任务花更少的token、更低的成本、更可控的时间完成”。Sol在架构上沿用并改进了混合专家MoE方案。官方没有给出完整的参数量但从发布会透露的稀疏激活逻辑来看每个token只激活一小部分专家网络整体计算量比上一代同规模模型低了不少。这个设计带来的直接好处是推理延迟更稳定不会因为上下文变长而线性恶化。开发者最直观的感受是原先需要拆成多轮工具调用才能做完的复杂任务Sol可以用更长的推理链一次性完成而且中间的工具调用路径更加收敛。官方数据的口径是“相比GPT-5级模型在标准Agent评测集上平均工具调用次数减少约30%”这个数字我实测下来比较诚实。多模态能力也不再是“能看图、能听音”这种基础层面。Sol把图像、音频、文本统一成同一条输入的token流处理这意味着你在API里可以同时传入一张截图、一段录音和一段文字描述模型会跨模态对齐信息。比如让它看一份UI设计图再听一段用户反馈录音最后生成一份产品改进说明这种复合任务在以前需要先转写再分析现在可以在一个请求里完成。工具调用方面Sol支持更加精细的并行工具执行。过去想让模型同时调用多个工具经常遇到参数冲突或结果互相覆盖的问题。Sol会在内部维护一个工具依赖图如果两个工具没有依赖关系就并行执行如果有先后依赖则自动串行等待。这个机制直接改善了Agent任务的成功率。1.2 价格与延迟为什么说这次最狠的是成本结构模型能力的提升当然重要但2026年开发者最在意的其实是成本。Sol这一代最狠的动作是把输出token价格大幅压下来同时把“推理成本”显性化让你能选择到底为推理过程付多少钱。看一下发布时的API定价对比项目GPT-5级模型参考价GPT-6.1 Sol 发布价备注输入token标准约$2.5 / 百万token$1.5 / 百万token降幅40%输出token约$12 / 百万token$7.5 / 百万token降幅37.5%缓存命中输入约$1.25 / 百万token$0.75 / 百万token适合长上下文场景快速模式低推理强度——输入$1.0输出$5.0不显示内部推理链慢速模式高推理强度——输入$2.5输出$12.5推理链完整输出这次我有一个很明确的感受OpenAI在逼着开发者把任务分档。过去所有请求都默认走同一个模型、同一个推理强度很多简单任务其实花了不少冤枉钱。Sol引入了更细粒度的推理强度控制你可以在API请求里通过reasoning_effort参数选择low、medium、high。简单问答用low代码生成用medium核心debug和复杂规划用high这样能把平均成本再压缩一大截。延迟方面官方给的数据是Sol在low推理强度下的首token延迟在0.3秒左右在high强度下会到3到5秒。这里必须提醒你推理强度并不等同于“质量越高越好”。我实测下来简单任务强行上high不仅慢还容易出现过度思考反而在一些格式要求严格的场景里变得更啰嗦。1.3 实际接入体验与API示例Sol沿用了OpenAI API的兼容风格官方推荐方式是直接用Responses API而不是旧的Chat Completions。如果你沿用旧端点很可能还是拿到默认的gpt-6.1-sol-preview别名但新特性不会全部开放。下面是一个最基础的请求示例注意参数的变化from openai import OpenAI client OpenAI() response client.responses.create( modelgpt-6.1-sol, reasoning_effortmedium, input[ { role: user, content: 分析这段客服会话记录总结用户的核心诉求并输出一个可执行的回复建议。, } ], tools[ { type: function, name: search_knowledge_base, description: 查询产品知识库, parameters: { type: object, properties: { query: {type: string} } } } ], ) print(response.output_text)这段代码里要注意几点第一是reasoning_effort参数在SDK里已经直接支持第二是tools参数格式与以往基本一致但Sol对工具描述的理解力更强工具描述写得越准确模型越不会乱调工具第三是output_text字段现在响应对象已经自动帮你把纯文本抽取出来不需要再手工遍历内容数组。我实测接入时遇到的一个问题是如果同时使用reasoning_efforthigh和streamTrue流式响应的结构会比旧模型多出两类事件reasoning.delta和tool_call.delta。如果你的流式客户端还在解析旧的增量格式建议先升级到SDK最新版或者在后端做一层事件格式适配。否则很容易出现“前半段正常到工具调用时突然断流”的诡异现象。1.4 影子模式升级前最稳的验证方法如果你已经有一个跑在旧模型上的应用直接切到Sol是有点冒险的。我的建议是做一周影子模式让Sol和旧模型同时接收生产请求但Sol的响应只记录不返回给用户然后每天对比两者的结果。具体做法是写一个旁路逻辑在原有请求发出后再复制一份请求发给Sol把两边输出存到日志表里标注任务类型、token消耗、延迟和人工评价。一周之后你基本能看出来哪些场景值得切换哪些场景还是留在旧模型更划算。我见过一些团队一上来就全量切换结果发现某些长文本摘要场景里Sol的输出风格变化太大导致下游解析逻辑崩了。影子模式虽然多花一点token钱但比线上事故便宜得多。2. dots把Agent拆成可以追踪的最小单元2.1 dots是什么从“一次调用”到“一串状态点”dots是这次发布会让我最兴奋的东西。简单说它是一个面向Agent工作流的状态原语专门解决长期运行任务“一断全没”的问题。过去我们跑一个多步骤Agent任务常规做法是写一个循环调用模型、解析结果、再调用模型直到任务完成。这个模式在小规模场景下没毛病但一旦任务变长中间任一环节出错整个流程就要从头再来。更麻烦的是你很难说清楚“这个Agent现在到底进行到哪一步了”出问题也没法定位。dots把Agent执行过程拆成一串有状态的“点”dots。每个dot代表工作流中的一个关键节点记录了这一步的输入、输出、所用工具、耗时和成本。这些dots组合成一个有向图模型按照图里的路径推进每个节点都能单独暂停、恢复和查看。你可以把dots理解成给Agent加上了断点和存档机制。以往Agent像是只能从头开始玩的一命游戏dots则允许你随时存档、读档甚至可以回到中间的某个节点改一下输入再继续前进。2.2 dots API的关键概念用dots之前需要先掌握四个基本概念Dot工作流中的一个最小执行单元可以是一次模型调用、一次工具调用或者一次人工确认。每个dot有全局唯一ID。Graphdots的有向图定义描述节点之间的依赖关系。Graph可以视为“Agent任务的蓝图”。Checkpoint某个dot执行完成后的状态快照包含当时的上下文、变量和中间结果。Checkpoint是恢复执行的基石。Run一次具体的执行实例。同一个Graph可以并发跑多个Run互不干扰。我个人的理解是dots真正聪明的地方在于它把“Agent编程”从写循环变成了搭有向图。你不再关心“while循环什么时候退出”而是关心“这个节点执行完下一步应该去哪个节点”。这种思维方式更接近传统的后端状态机对工程团队来说非常友好。2.3 一个dots落地例子用代码管理事件流这里给一个贴近实战的例子。假设你要做一个“调研行业趋势并生成周报”的Agent流程分三阶段搜集信息、分析归纳、生成报告。用dots实现的话大体是这样import dots graph dots.Graph( nodes[ dots.Node(namecollect_sources, toolweb_search), dots.Node(namesummarize_findings, modelgpt-6.1-sol, reasoning_effortmedium), dots.Node(namegenerate_report, modelgpt-6.1-sol, reasoning_efforthigh), ], edges[ (collect_sources, summarize_findings), (summarize_findings, generate_report), ], ) run dots.create_run( graphgraph, payload{topic: AI Agent 工程化趋势, weeks: 1}, ) dots.wait_for_checkpoint(run.id, summarize_findings) # 到这里可以人工检查一下归纳结果再决定是否继续 dots.resume_run(run.id)需要注意的点create_run之后任务不会立刻跑完而是边执行边落checkpoint。代码里wait_for_checkpoint就是我们主动等待某个节点完成的钩子。这里有个小技巧在进入高成本的“生成报告”节点前先人工检查一下归纳结果能避免报告生成完才发现中间步骤理解偏了。dots还提供了简单的可观测性查询接口dots log --run run_8xZkQ3 --format json输出会列出每个dot的触发时间、耗时、token消耗和校验状态。线上排查的时候这个日志比你自己打的print有用得多。2.4 什么时候不该用dotsdots不是银弹。对于单次请求、短小任务用它反而增加复杂度。比如一个简单的邮件分类任务直接用模型分类然后返回结果就够了完全没必要建Graph。我判断是否用dots的标准很简单如果这个任务预计要跑超过10个步骤或者包含多个工具调用或者有可能需要人工介入修正那就值得用dots。如果只是一个“输入、模型、输出”的线性过程直接用普通API更省事。另外一个实际经验dots的checkpoint会占用存储空间特别是当你的任务里包含大量长文本中间结果时。如果任务本身很轻量但你把每个dot都设置成自动checkpoint存储成本可能比模型调用成本还高。建议只在关键节点开启checkpoint频率控制在能接受的范围。3. ChatGPT Spaces从“聊天记录”到“工程现场”3.1 Spaces要解决什么问题如果你用过ChatGPT做正经项目一定经历过这种痛苦几条重要的信息散落在不同的对话里换个会话继续干活时模型完全不记得前一个会话里确认过的技术方案团队协作时每个人各自跟AI对话最后汇总出来的结论千奇百怪。ChatGPT Spaces就是冲着这个痛点去的。它把ChatGPT从一个“单轮对话工具”升级成“持久化项目工作区”。每个Space相当于一个独立项目空间里面有共享上下文、文件、任务清单和多个Agent成员。你在Space里讨论过的技术决策、上传过的设计稿、确认过的修改意见都会作为该空间的长期记忆保存下来。用一句话概括Spaces让AI从“随聊随忘的临时工”变成“有项目档案的项目成员”。3.2 核心功能拆解Spaces的核心功能可以分成四块共享上下文Shared ContextSpace内所有对话和Agent共享一个持续更新的上下文池。你在这个会话里确认的信息下一个会话里不需要重复交代。任务清单Task List你可以把项目拆成具体任务分配给不同的Agent或协作者。任务状态会在Space内同步更新。Agent工作区Agent Workspace每个Space可以添加多个Agent比如“代码助手”“研究助手”“内容助手”。你可以在一个对话里同时多个Agent让他们分工协作。审核机制Review ModeAgent生成的代码或文档不会直接写入正式版本而是先进入草稿状态由人工确认后才生效。这是我最看重的一点它给AI输出加了一道安全阀。我试用下来感觉最顺手的场景是在Space里上传产品需求文档然后让“研究助手”整理用户反馈“代码助手”直接生成MVP原型代码“内容助手”起草发布文案。三个Agent可以在同一个上下文背景下工作产出的东西一致性比独自对话强很多。3.3 对团队协作方式的影响Spaces实际上改变了团队和AI的交互单位。以前是“每个人各聊各的”现在是“团队围绕一个Space协作”。比如一个三人小团队做内部工具过去的流程很可能是各自在ChatGPT里折腾Prompt和代码片段最后拼不到一起。现在则可以把项目相关的全部资料、讨论记录、决策都放进一个Spaces新人加入时不需要翻聊天记录直接看Space就能了解项目全貌。这里有一个很关键的使用技巧Space的共享上下文不是越大越好。如果你什么东西都往里塞上下文池会被大量无关信息污染反而导致Agent在关键问题上的注意力下降。我的做法是每个Space只放一个明确主题的资料宁可多建几个Space也不要把研发、营销、客服全混在一起。3.4 权限模型与注意事项Spaces在权限上支持成员角色配置包括查看者、编辑者、管理员。查看者只能浏览对话和产物编辑者可以添加内容和执行任务管理员负责管理成员和Agent权限。我必须提醒一点如果你把Space变成公开链接任何拿到链接的人都能看到里面的上下文。这听起来像废话但实测中真有团队把包含数据库连接串的对话截图放进公开Space然后被搜索引擎收录了。敏感资料务必放进有权限管控的企业版Space或者干脆不要上传到AI工作区。另一个容易踩的坑是“上下文串味”。当你在同一Space里跑了多个相关性不高的任务后一个任务会莫名受到前一个任务残留信息的影响。我建议每个明确的项目阶段单独建Space任务结束后归档。这样既能保持上下文干净也能减少信息干扰。4. 二十多项更新里还有哪些值得关注4.1 开发者平台SDK、缓存与响应格式除了三个主角这次DevDay还有一批面向开发者的细节更新谈不上颠覆但很实用。Responses API已经成了官方主推的统一入口旧的Chat Completions API虽然还兼容但新功能只面向Responses优先开放。如果你还在维护旧接口今年内需要考虑迁移。Prompt Caching在这次更新里把缓存粒度从“前缀缓存”细化到了“逻辑块缓存”。也就是说即使两条请求的前缀不完全一致只要中间存在逻辑上共享的段落也能命中缓存。这对于做客服问答、文档助手这类大量重复上下文的场景能省下可观的token费用。Structured Outputs也升级了现在支持嵌套JSON Schema校验数组内元素类型可以分别约束。以前最头疼的“模型输出少个字段”问题现在能直接在API层面兜底。我建议所有做数据抽取的脚本都用上这个能力能让清洗数据的逻辑简化不少。此外Batch API在新版本里再次降价适合离线批量处理Predicted Outputs功能允许你告诉模型“这段重复文本大概率原样返回”在代码补全和模板渲染场景里能明显降低延迟。我没有在本文展开太多但这些细节都是可以立刻落到项目里的优化点。4.2 从Muse到搜索、语音内容生产链在补全这次发布里还有一个值得一提的产品叫Muse定位是“面向创意工作的多模态Agent”。和常规的文生图工具不同Muse更强调“可控生成”你给它一个设计草稿它能产出UI稿、配图、文案甚至背景音乐草稿并且保留版本历史方便回溯。官方展示的典型场景是设计师在Spaces里丢出一份线框图Muse自动生成多个视觉方向然后团队直接在Spaces里评论、选择并继续迭代。它没有试图替代设计师更像是把“灵感发散”和“素材准备”这两个环节自动化了。实时音频API这次也正式转正并且推出了专门的语音交互模型支持打断、情绪识别和更低延迟的流式对话。如果你在做语音助手类的产品这个更新值得重点测一遍。搜索端则把联网信息获取能力整合进了Spaces在没有显式的网络搜索工具时Agent也可以直接引用实时信息。4.3 兼容API生态与第三方集成这次还公布了新的第三方集成清单包括LangChain、Zapier、Notion、飞书文档等一批常见工具的官方对接插件。对开发者来说最直接的改变是在很多低代码平台里可以直接选“OpenAI Agent”作为节点而不需要自己写胶水代码。让我有点意外的是这次官方还发布了统一的可观测性与计费控制台。你可以在一个后台看到所有API调用、模型版本、token支出并按项目维度设置预算上限。过去要用第三方服务才能搞定的事现在官方直接提供了省去不少运维工作。当然“兼容API生态”也意味着市场上会出现一批基于新端点封装的中间层。如果你在用社区维护的SDK升级前记得确认它同步支持了新参数避免出现过时字段被静默忽略的坑。4.4 发布矩阵速览为了让你快速定位自己关心的内容我把这次发布会的主要更新整理成一张速查表发布项类型一句话说明GPT-6.1 Sol模型新一代推理模型多模态与工具调用大幅增强GPT-6.1 Flash模型轻量版本主打低延迟和高性价比GPT-6.1 mini模型面向小任务与边缘场景的紧凑模型dots开发者工具Agent工作流状态原语支持checkpoint与恢复ChatGPT Spaces产品持久化项目工作区共享上下文与任务管理Muse产品多模态创意Agent用于生成并迭代创意素材Realtime API GAAPI实时语音交互正式开放Prompt Caching升级API逻辑块缓存降低重复上下文成本Structured Outputs增强API支持更严格的嵌套Schema校验Batch API降价API离线批量处理成本进一步下降Predicted OutputsAPI对可预测文本优化延迟统一计费控制台平台跨项目预算管控与调用追踪第三方集成更新生态与LangChain、Zapier、Notion等完成对接新嵌入模型模型面向检索增强的新一代text-embedding这些更新单独看都不算惊天动地但放在一起你就会发现OpenAI这一年的重心已经从“做一个更聪明的模型”转向了“让Agent真正能被工程化管理”。5. 我在踩坑现场问题与排查实录5.1 dots状态丢失默认不落盘我第一个踩的坑就是dots的checkpoint。起初我天真地以为只要创建Run系统会自动保存每个步骤的状态。实际跑了一个20步的任务中途手动杀进程后恢复发现根本恢复不到断点。翻文档才发现checkpoint默认只在显式标记的节点上触发不是每个dot都会自动存档。排查思路是看Run日志里有没有checkpoint.persisted事件。如果没有就要在Graph定义里给关键节点加上checkpointTrue参数。我后来把finish节点、调用外部工具前的节点都改成显式checkpoint才实现“挂了能续”。这里也提醒你开启太多checkpoint会拖慢整体执行速度。要在“可恢复粒度”和“执行效率”之间取一个平衡。我的经验是每3到5个普通节点设置一个checkpoint比较合适人工介入节点之前必须设。5.2 Spaces上下文污染任务之间互相打架Spaces最让我头疼的是上下文污染。我在一个研发Space里同时跑UI设计讨论和数据库结构设计结果生成SQL时出现了“把界面配色变成字段名”这种荒谬错误。原因就是Space的共享上下文把所有对话混在一起模型分不清哪些信息属于当前任务。解决办法其实也简单第一只开一个独立Space给当前专注项目第二利用Spaces里的“指令文档”功能把每个任务的目标、范围和禁用词写清楚第三在进行切换度较大的任务前先清理会话上下文或者新建子会话。如果你遇到的Agent开始“串味”优先检查是不是同一个Space下塞了太多不相干内容。5.3 Sol的思考模式选择不是越强越好Sol的reasoning_effort参数是个双刃剑。我一开始为了图省事全部请求统一设成high结果两件事发生延迟明显变高输出token数量也比预期多月底账单拉出来让人肉疼。更麻烦的是在严格JSON输出任务里模型因为思考过多偶尔会在JSON里插入注释直接导致解析失败。后来我按任务类型做了匹配简单分类用low代码补全和中等推理用medium复杂重构和架构设计用high。同时把temperature固定在一个稳定值不对推理模型做过高的随机性设置。整体成本降了一半还不止效果反而更稳定。5.4 迁移检查清单如果你打算把现有应用从旧模型或旧API迁移到新体系我建议按下面清单走一遍能省很多试错时间确认SDK版本更新到支持新参数旧版本不会报错但会忽略新字段后果很隐蔽。检查流式响应处理逻辑是否兼容新增的reasoning.delta事件。梳理代码里所有使用model参数的位置统一替换为新的模型别名。在非核心请求上先开启影子模式观察输出差异。核对Structured Outputs的Schema定义新校验规则更严格旧的宽松Schema可能过不了。关注token计费口径变化Sol的推理链token不再隐藏在总输出里账单明细会更清晰。这个清单是我和几位做了同样迁移的朋友聊完后总结出来的照着做基本能避开绝大多数低级事故。6. 一些个人判断和建议6.1 值得立刻接入的两样东西如果只让我推荐立刻上手的两个发布我会选GPT-6.1 Sol的low推理模式和dots。前者的收益是立竿见影的成本下降后者则是长期可靠性的保障。Sol的low模式特别适合处理那些你本来就在用旧模型完成的“体力活”标题生成、文本分类、关键词抽取、简单的意图识别。你会发现质量没有下降价格却低了不少。在一个中等规模的自动化脚本里只改这一处月度成本就能有肉眼可见的改善。dots则更适合已经开始跑多Agent协作的团队。只要你的任务流程里出现过“中间挂了又要全部重来”的情况dots就能立刻体现价值。它现在的SDK成熟度虽然还不算完美但基本状态管理的能力已经够用越早接入越早积累调试经验。6.2 可以再等等的部分ChatGPT Spaces我建议小团队可以先试用但不必急于作为核心协作平台。它的共享上下文模型在单团队、单项目场景下很好用一旦涉及跨部门多项目权限管理和上下文隔离就需要额外配置。等官方完善企业级管理能力之后再大规模推广也不迟。Muse也属于“方向正确但还需打磨”的产品。目前它更适合作为创意辅助工具在早期概念阶段使用真要进入生产级设计流程还与成熟的专业设计工具有差距。偶尔拿来发散思路不错别指望它一步到位。6.3 一个务实的落地顺序如果你是一个个人开发者或中小团队我的建议是这样推进先花一周时间做Sol影子模式验证确认哪些任务适合切换然后评估现有Agent流程里最耗时的长任务试着用dots重构一个试点等流程稳定后再邀请团队试用Spaces做项目协作最后再考虑Muse这类创意辅助能力。这个顺序的核心逻辑是先省成本再稳流程然后提协作最后扩边界。盲目追新特性反而容易让团队陷入工具疲劳。AI工程的价值永远是先落在“解决问题”上其次才是“用最新的东西”。最后分享一个我自己的习惯每次大版本更新后我都会挑一个小项目做一次“全新技术栈重构”哪怕这个项目用旧方案也能跑。这既是对新特性的压力测试也是对自我知识体系的更新。技术人的手感就是在一次次主动折腾里练出来的。这次DevDay给我的感觉也是一样与其盯着参数表撕扯不如把手弄脏让真实项目告诉你什么值得用。

OpenAI DevDay 2026：GPT-6.1 Sol、dots与Spaces重塑Agent工程

相关推荐

微浦与清华产学研合作：AI与智能制造技术突破

音频传输原理与工程实践：从模拟采集、PCM编码到实时通话延迟排查

OpenClaw网关重启操作与故障排查指南

更多资讯

修仙类QQ机器人运营模式与技术架构对比分析

焊接数值模拟中热源路径规划与FLUENT仿真优化

DeepSeek Harness桌面版发布：开箱即用的AI工作台与插件体系解析

Linux下Redis安装配置与性能优化实战指南

Agent定时任务总跑偏？触发与补跑规则设计实战

Python频次统计与多关键字排序：数字次数排序题详解

今日更新

基于YOLOv11的石油泄漏智能检测系统开发实践

AI行业变局：合规、Mod化与上下文管理的实战启示

计算机视觉与AI原生应用融合的技术实践

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？