OpenAI DevDay 2026：dots协议、ChatGPT Spaces与GPT-6.1 Sol的Agent开发范式-北京尧图网络

票是提前三个月抢的凌晨五点半我就在Moscone Center门口排队了。今年主办方发了纸质胸牌背面印着一行字“This year, the API is not the product. The product is your agent.” 我拍下这行字发到团队群里然后被人流裹着挤进了主会场。三个多小时后我被一个叫dots的协议、一个叫ChatGPT Spaces的工作区、以及GPT-6.1 Sol这颗“太阳”砸得有点晕——朋友圈里的热词也验证了这一点OpenAI DevDay 2026dots、ChatGPT Spaces、GPT-6.1 Sol确实承包了所有AI从业者的首页。这篇文章不做流水账我只想把最核心的发布掰开揉碎讲清楚dots到底是什么、Spaces解决了什么真实问题、Sol该怎么接进生产环境以及那20多项发布里哪些值得你立刻跟进、哪些可以再等等。1. 三个小时主演讲里透出的信号比发版本身更值得琢磨1.1 开场基调从“模型能力”全面转向“协作状态”今年的主题演讲没有像往年那样花大量时间跑分、叠benchmark第一个出场的就是ChatGPT产品线的负责人讲的是“persistent context”持久上下文。这不是一个词的变化而是整个产品逻辑的变化过去模型是“你问我答”用完即走现在模型是一块“一直在线的画布”你在上面留下的每一个动作都会被记住、被组织、被复用。主演讲里反复出现一个词叫“muse”全场都在讨论它——因为muse不是一个独立功能而是这一轮更新的交互层总称它把多模态输入、空间内协作、智能体编排统一成一套可继承的上下文语言。简单说muse是“粘合剂”dots是“最小单元”Spaces是“承载场景”三者合并才是这次DevDay的真正主线。我在现场的感受是OpenAI已经不太关心“下一个token怎么生成”而是投入了大量资源去解决“多个智能体、多个成员、多个文件在同一个工作状态下如何保持认知一致”。这一点在后面的dots发布里体现得尤其明显建议开发者别只盯着单点API先把这个全局逻辑理顺。1.2 发布节奏模型、产品、平台三条线同时推进官方宣布了20多项发布但仔细归类其实是三条线模型线以GPT-6.1 Sol为主强调推理成本可控附带一批增强的多模态能力和上下文压缩能力。产品线ChatGPT Spaces正式可用移动端同步上线ChatGPT记忆系统升级为动态记忆图谱。平台线dots协议进入Preview、muse交互层开始邀请内测、Assistant SDK更新、Function Calling vNext、新的评估与安全工具。这种发布节奏暗示了一个明确信号OpenAI想把“模型、产品、平台”三者打包成一个开发者无法拒绝的闭环。单用API的人会发现自己缺失了Spaces的产品化能力单用ChatGPT的人会发现自己没办法把dots落到生产环境。两条腿走路在2026年的OpenAI生态里会是常态。1.3 最让我意外的一件事推理模式变成了可声明参数过去我们反复在“要不要让模型思考久一点”之间纠结这次官方直接把推理过程做成了API参数并引入了一个全新的概念reasoning_formatdots。这不是提示词工程层面的花招而是把模型的内部推理拆成可观测、可留存、可交换的结构化单元。这件事的影响范围远超一个SDK更新——它等于承认了“推理过程”本身是有价值的资产而不再是黑盒。对开发团队来说这意味着评估方式也要跟着变新的发布不仅是看模型输出质量还得检查推理图的质量、点的连接效率、以及信任边界。这条变化我会在下面详细展开。2. dots不是前端框架而是Agent思考的单位化标准2.1 先把dots究竟是什么说清楚dot直译是“点”。官方给的定义是一个自包含的最小推理单元包含意图、观察、结论、来源追踪、置信度与token开销。多个dot通过link连接构成一张有向无环图称为“思想图”Thought Graph。开发者可以对这个图做任意检索、裁剪、合并和复用。一句话理解以前我们调模型输入一段话吐出一段话中间过程不可控现在dots协议允许你把“模型的思考过程”切成一个个可以命名的节点像积木一样自由拼装。每个dot都带自己的来源信息因此审计和追溯变得非常直接。我现场看demo时最直观的感受是它有点像“把提示词工程、Agent状态管理和可观测性三合一”了。以前做复杂Agent最痛苦的是中间状态散落在不同变量里排错靠日志有dots之后每个中间结论本身就是一个结构化对象随存随取。2.2 用一次真实跑通来理解dots的开发体验官方SDK里新增了一个openai.dots命名空间。下面是一段接近真实用法的Python代码演示如何创建一个多智能体调研工作流from openai import OpenAI from openai.dots import ThoughtGraph client OpenAI() # 1. 初始化一张空空的思想图 graph ThoughtGraph() # 2. 创建第一个seed dot定义任务目标 seed client.dots.create( payload{ type: task, goal: 分析新能源汽车充电桩市场的竞品格局, constraints: [只看北美市场, 时间范围2024-2026] }, confidence0.99, tags[seed] ) graph.add(seed) # 3. 并行扩展三个分支观察 branch_1 client.dots.create( payload{type: observation, source: web, summary: Top3厂商份额}, source_dots[seed.id], confidence0.81 ) branch_2 client.dots.create( payload{type: observation, source: patents, summary: 近一年专利布局}, source_dots[seed.id], confidence0.76 ) branch_3 client.dots.create( payload{type: observation, source: reports, summary: 政策与补贴变化}, source_dots[seed.id], confidence0.88 ) graph.add_many([branch_1, branch_2, branch_3]) # 4. 将三个观察聚合成结论dot conclusion client.dots.create( payload{type: conclusion, summary: 竞争格局总结与切入建议}, source_dots[branch_1.id, branch_2.id, branch_3.id], confidence0.73 ) graph.add(conclusion) # 5. 按置信度过滤并导出 graph.filter(confidence_level0.7) graph.export(thought_map.jsonl)这段代码的执行效果是模型把所有推理过程拆成了7个可追踪的节点每个节点都知道自己“从哪来、置信度多少、花了多少token”。你可以在任意环节插入人工审核也可以把某个分支单独提取出来复用。这套体验跑通一次你就回不去了——因为排错时不再需要盯着一整段黑盒输出猜原因。2.3 dots的三个确定性优势不只是“看起来高级”第一可追踪性。合规和风控场景最需要这个。以前Agent说错话我们只能复现上下文现在每个dot都带有来源责任链路清晰。尤其金融、医疗领域“我们凭什么相信这个结论”会变成一个可回答的问题。第二可复用性。公司沉淀的排障经验、行业知识可以通过“配方”recipe的方式保存下来。配方就是一组预先定义好的dots骨架新项目直接套用不用从零写提示词。举个例子你可以把“客服工单升级到技术二线”的判断流程固化成recipe新来的实习生也能跑出标准质量的分类结果。第三可评估性。老一套的人工评分只能评价最终答案而dots允许你对每一跳中间推理做打分定位到底是“检索错了”还是“归纳错了”。这直接改变了评测方式官方同步更新的Evals也专门加了多智能体评估模式。2.4 上线前必须想清楚的几个坑dots不是银弹我至少看到四个坑值得注意上下文成本会明显上升。每个dot自带来源和元数据如果图太大token开销可能比传统单轮调用高30%-50%。建议设置dot保留策略比如只保留最终结论和关键分支。警惕外部注入。既然dots是结构化数据那么恶意用户也有可能构造带“毒”的dot来诱导系统做错误推理。官方提供了签名校验机制生产环境务必开启并只接受来自可信域的graph。状态爆炸。复杂任务会导致思想图节点数快速膨胀。建议像代码管理一样做定期“压缩提交”把局部结论合并成高置信度的总节点而不是让图无限膨胀。调试习惯要改变。不熟悉图结构的话初期会感觉比读日志麻烦但坚持一周后你会发现排错面从“整段文本”缩小到了“单点链路”效率反而更高。3. ChatGPT Spaces从“聊天框”到“常驻工作区”的产品逻辑3.1 Spaces的形态你打开的不是历史消息是一个项目状态机ChatGPT Spaces简单说是ChatGPT里的持久化项目空间。它不再是一条条对话记录而是一个包含文件、成员、智能体协作者、运行记录、知识库绑定的“状态空间”。界面左侧是文件树中间是协作主画布右侧是智能体协作者列表——以及一个实时更新的记忆视图。这个设计直接解决了过去ChatGPT团队协作被吐槽最多的痛点文件散落在对话里、上下文互相覆盖、权限只能靠截屏。Spaces把这些统一收纳了。更关键的是Spaces内部的所有操作——谁说了一句话、谁改了一个文件、哪个Agent执行了什么任务——都会沉淀成结构化事件流可以被回放、检索和审计。我用一个真实场景来说我们团队把一个“每周竞品情报分析”任务搬进了Spaces空间里预先绑定了一个“行业新闻采集Agent”和一个“报告生成Agent”。周一早晨采集Agent自动把新闻丢进空间报告Agent读取后生成摘要草稿我们只需要做审核和批注。整个过程在同一个空间里完成不再需要人工搬运文件、复制摘要、再打开文档粘贴。3.2 团队协作里的角色设计成员、Agent、权限三条线Spaces的权限模型比普通聊天产品严谨得多。空间所有者可以定义三类身份成员、访客、Agent协作者。每个角色可以绑定不同的工具权限和数据可见范围。比如“报告生成Agent”只能读取“已归档”标签下的文件不能读取“机密”标签外部顾问作为访客只能看到空间内特定目录的内容无法看到Agent内部执行日志。这点在实际落地中非常重要。我们公司在试用时最担心的是AI空间会不会让数据边界变得模糊。目前看Spaces的权限粒度支持到“文件级标签级”且提供了完整的操作审计达到了多数中小团队的合规要求。3.3 把自家系统接到Spaces很顺但思考边界要想清楚官方这次放出了Spaces API允许外部系统创建空间、写入事件、读取Agent产物。这意味着企业可以把自己内部的工单系统、数据库、文档库通过API接到Spaces让Agent直接在真实业务数据上工作。下面是一个简单的接入示例把内部工单同步成空间事件const OpenAI require(openai); const client new OpenAI(); // 创建/获取空间 const space await client.spaces.get(space_weekly_ops); // 将工单系统更新注入为事件 await client.spaces.events.create(space.id, { type: ticket.sla_breached, payload: { ticket_id: TKT-2049, owner: oncall-team, severity: P1 }, source: internal-ticketing, timestamp: new Date().toISOString() }); // 给空间内Agent下发处理任务 await client.spaces.agents.trigger(space.id, { agent_id: sla_response_agent, task: 分析此工单并给出处理建议 });接入本身确实不复杂但接什么样的数据进来需要克制。我的建议是宁可在Spaces里建立一个“经过脱敏的业务镜像层”也不要直接把所有内部系统一股脑接进来。AI协作的边界往往不是技术限制而是你愿不愿意让Agent看到那部分原始业务数据。3.4 什么时候不该用Spaces虽然Spaces很好用但我不推荐所有场景都用它。一次性问答、临时翻译、即时改写这类轻量任务在普通会话里完成效率更高硬塞进空间反而制造噪音。另外如果你的业务流程强依赖自定义审批流、人工逐级确认Spaces内置的workflow能力目前还覆盖不了建议等一等后续更新。在移动端上Spaces这次也同步上线了App版本但实际体验下来我更建议大家把它当作“查看和快速反应”的入口真正重的操作还是留在桌面端。毕竟空间内动辄几十个文件和多个Agent状态小屏幕上的信息密度撑不住。4. GPT-6.1 Sol模型选型要点与API实战4.1 为什么叫Sol这颗“太阳”解决的是什么问题Sol的名字取自太阳官方的解释是“Energy-Aware Reasoning”——按需能量分配。很大一个新特性是模型允许你直接指定推理预算也就是max_reasoning_steps参数。你敢相信吗以前我们要么任由模型“想到哪算哪”要么只能靠强行截断输出现在推理深度变成了一个可调旋钮。此外Sol上下文窗口扩展到2M token原生支持在超长上下文内保持推理一致性官方给出的长文本基准测试里Sol在100万token以上的记忆保持率明显优于前代旗舰。尤其适合处理长代码库分析、年度财报研究、科学文献综述这类“喂进去就忘不了”的场景。4.2 性能与价格清单别只看跑分看单位成本官方给了几张基准表我不打算全部搬运只挑对选型最有用的维度。以下是我整理的对比项目GPT-6原旗舰GPT-6.1 Sol备注通用文本质量100基线大约97略降但换来了低成本数学/逻辑推理100约105Sol在深度推理上有明显增强多模态识别100约96视频理解稍弱于旗舰上下文窗口1M2MSol翻倍平均单次推理成本基线降低约45%取决于max_reasoning_steps设置响应延迟流式首token基线降低约30%更适合实时对话这个定位非常清晰Sol不是GPT-6的“升级版”而是“高性价比长上下文推理版”。如果你的业务每天都要处理大量长文档、需要复杂推理链路Sol的单位性价比明显更划算如果任务本身是轻量但高频的则要小心推理预算参数设置过大导致成本反而升高。4.3 三种调用方式与一份最小可运行代码Sol的调用方式非常灵活常用有三种普通补全适合零门槛快速迁移。带推理预算的补全适合需要控制成本的中长任务。dots格式推理适合需要追踪/复用的生产级Agent。下面是最典型的第二种调用方式推荐大多数团队第一时间测试因为改动成本极低from openai import OpenAI client OpenAI() resp client.chat.completions.create( modelgpt-6.1-sol, messages[ {role: system, content: 你是高级代码审计员。}, {role: user, content: 分析这个仓库里所有性能隐患按严重程度排序。} ], max_reasoning_steps120, # 给模型更充裕的思考预算 temperature0.2, response_format{type: json_object} ) print(resp.choices[0].message.content)实测下来设置max_reasoning_steps的效果明显在120步与20步之间同一个代码审计任务输出结果差异很大——120步版本能发现深层的数据竞争问题而20步版本只会停留在表层API误用。这也提醒我们Sol的定价面向“可控”开发者必须自己做好步骤校准。4.4 模型选型的经验判断不是所有场景都该换我的建议是分三类评估立即替换长文档分析、历史数据问答、复杂多跳推理、代码仓库级理解。这类场景Sol的成本优势和2M上下文优势非常明显。谨慎评估高频短对话、客服情绪识别、极低延迟交互。互动体验里首token延迟虽然降低但推理预算一不小心就会拉高成本建议先跑影子流量对比。暂不建议需要极致多模态融合、多媒体内容创作等任务。Sol的多模态能力略有取舍如果你的核心场景依赖图像/音频深度理解保留原旗舰版本更稳。顺带提一句官方还开了“微调版Sol”的企业早鸟通道。如果你有垂类领域数据能进一步压低推理步骤浪费我觉得这是最值得关注的企业级项目但不建议小团队一开始就冲先把基础API调明白再说。5. 20多项发布的完整清单与一句话评审5.1 全部发布盘点按开发链路排序我把现场记录整理成一张速查表按“模型/API、产品、工具链、企业能力”四类划分类别发布内容一句话点评模型GPT-6.1 SolGA本场压轴模型性价比长上下文双杀模型上下文压缩技术Preview长期会话成本有望大降值得紧盯协议dotsPreview本场最重要的技术发布没有之一交互层muse邀请内测统一多模态表达现阶段影响有限产品ChatGPT SpacesGA团队级AI工作区的标准答案雏形产品记忆系统升级为动态图谱会话与知识的连续性大幅增强产品Spaces移动端适合轻量管理和快速反馈APIRealtime API v3首token延迟再降实时对话体验更顺滑APIAssistant SDK更新原生支持多智能体编排省很多胶水代码APIFunction Calling vNext结构化约束更强工具调用失败率降低API批量推理优惠离线任务成本再降一轮工具链Evals多智能体评估版评估体系终于跟上Agent时代工具链可观测性套件增强支持dots级别的链路追踪排错体验质变工具链自动化测试生成器辅助生成测试用例质量较稳定多模态视频理解增强长视频摘要可用性显著提升多模态图像生成升级精细指令遵循能力增强安全Agent审计日志合规刚需企业采用率会因此提升安全外部dot签名校验防注入的关键机制务必开启企业组织知识库原生绑定让Spaces直接读取内部文档落地价值高企业私有化部署方案预览大企业更愿意上车的信号开发者认证计划与初创基金利好个人开发者生态5.2 被低估的三项发布我建议你重点关注第一是上下文压缩技术。它和dots是绝配dots图再大最后都能压缩成关键摘要节点长期运行成本能得到控制。这项技术和Spaces结合后一个空间运行一整年也不会变成“吞金兽”。第二是Evals多智能体评估版。过去我们没法在CI里自动跑“两个Agent互相协作”的回归测试现在官方提供了一套可编程的评估场景。对做严肃Agent产品的人来说这是一等一的好消息。第三是组织知识库原生绑定。很多企业团队卡在“AI不好用”的原因是数据进不去。Spaces直接绑定机构知识库之后回答的准确性和业务相关性会跨一个台阶这比单纯换模型管用得多。5.3 成本测算示例一个每周分析师Agent到底花多少钱我给团队做了个粗略测算假设每周运行50次每次输入长文档输出摘要项旧方案GPT-6新方案Sol dots每次输入token800K800K每次输出token8K10K含dot元数据单次成本基准1.0x约0.55x每周净成本50x约27.5x附带价值无追溯可追溯、可复用推理图从成本角度看省了差不多一半但更重要的是换来了“中间推理过程可审计”。对大企业来说这笔账往往比省下的成本更值钱。6. 会后48小时给团队的两条可复制落地路径6.1 路径A以Spaces重做团队的AI工作流如果你现在用的是“普通ChatGPT 手动整理文档”的方式我建议直接按这五步走选一个高频重复的周报/分析类任务建一个Spaces。把常用文件、参考链接、知识库绑定进空间。创建一个采集Agent和一个撰写Agent设定触发节奏。跑两周影子期每天人工审核Agent产物并打标。稳定后逐步把审核动作从“逐字修改”降级为“抽样检查”。核心心法是先选一个小而痛的任务跑通别一上来就武装到牙齿。我们团队用这个方法第三周就看到了明显的效率提升。6.2 路径B用dots与Sol构建自有Agent编排服务这套组合拳适合已经有API调用经验、想构建复杂Agent的团队确认核心场景是否需要可追溯。如果只是单轮问答没必要上dots。将任务拆解成“seed dot 若干分支观察汇总结论”的标准结构。为每个dot设置置信阈值低于阈值的自动转人工。用Sol的max_reasoning_steps控制整体推理预算。给dots图做版本管理沉淀成团队内部recipe库。一个很重要的经验是dots协议非常适合“跨Agent交接”。A Agent的结论dot可以作为B Agent的输入seed实现了真正意义上的信息传递而不是简单地把文本拼进下一段提示词。6.3 我个人的踩坑心得提前帮你排雷我这两天已经踩了几个坑写出来供大家参考别把所有中间结果都保存成dot。过度结构化会让成本飙升我们实际项目里只保留“有明确决策意义”的关键节点其他临时内容直接丢掉。谨慎开放外部来源的dot。收到的任何graph都要做来源校验和置信度审查防止恶意dot污染整个推理链。Spaces里的Agent协作不要设太多自由权限。先给最小必要权限运行稳定后再逐步放开否则排错时根本分不清是哪个Agent改坏了文件。Sol的max_reasoning_steps要做分档配置。简单任务10步以内中等任务50步复杂推理才上100无脑开满只会让你的账单变难看。这次DevDay最让我感慨的不是某一个模型刷新了多少分数而是整个开发范式确实在往“可观测、可协作、可复用的智能体状态”迁移。dots把思考变成可管理的资产Spaces把协作变成确定的场地Sol把成本变成可预算的参数——三者合在一起就是一套真正能落到生产环境的AI原生开发底座。接下来几周我会把dots的recipe库实践细节再跑细一点到时候有结论了继续写出来跟大家交流。

OpenAI DevDay 2026：dots协议、ChatGPT Spaces与GPT-6.1 Sol的Agent开发范式

相关推荐

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

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

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

更多资讯

修仙类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 成本测算与选型避坑（附配置）

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