票是提前三个月抢的，凌晨五点半我就在Moscone Center门口排队了。今年主办方发了纸质胸牌，背面印着一行字：“This year, the API is not the product. The product is your agent.” 我拍下这行字发到团队群里，然后被人流裹着挤进了主会场。三个多小时后，我被一个叫dots的协议、一个叫ChatGPT Spaces的工作区、以及GPT-6.1 Sol这颗“太阳”砸得有点晕——朋友圈里的热词也验证了这一点：OpenAI DevDay 2026，dots、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_format='dots'。这不是提示词工程层面的花招，而是把模型的内部推理拆成可观测、可留存、可交换的结构化单元。这件事的影响范围远超一个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"] }, confidence=0.99, tags=["seed"] ) graph.add(seed) # 3. 并行扩展三个分支观察 branch_1 = client.dots.create( payload={"type": "observation", "source": "web", "summary": "Top3厂商份额"}, source_dots=[seed.id], confidence=0.81 ) branch_2 = client.dots.create( payload={"type": "observation", "source": "patents", "summary": "近一年专利布局"}, source_dots=[seed.id], confidence=0.76 ) branch_3 = client.dots.create( payload={"type": "observation", "source": "reports", "summary": "政策与补贴变化"}, source_dots=[seed.id], confidence=0.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], confidence=0.73 ) graph.add(conclusion) # 5. 按置信度过滤并导出 graph.filter(confidence_level=0.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 | 约105 | Sol在深度推理上有明显增强 |
| 多模态识别 | 100 | 约96 | 视频理解稍弱于旗舰 |
| 上下文窗口 | 1M | 2M | Sol翻倍 |
| 平均单次推理成本 | 基线 | 降低约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( model="gpt-6.1-sol", messages=[ {"role": "system", "content": "你是高级代码审计员。"}, {"role": "user", "content": "分析这个仓库里所有性能隐患，按严重程度排序。"} ], max_reasoning_steps=120, # 给模型更充裕的思考预算 temperature=0.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 Sol（GA） | 本场压轴模型，性价比+长上下文双杀 |
| 模型 | 上下文压缩技术（Preview） | 长期会话成本有望大降，值得紧盯 |
| 协议 | dots（Preview） | 本场最重要的技术发布，没有之一 |
| 交互层 | muse（邀请内测） | 统一多模态表达，现阶段影响有限 |
| 产品 | ChatGPT Spaces（GA） | 团队级AI工作区的标准答案雏形 |
| 产品 | 记忆系统升级为动态图谱 | 会话与知识的连续性大幅增强 |
| 产品 | Spaces移动端 | 适合轻量管理和快速反馈 |
| API | Realtime API v3 | 首token延迟再降，实时对话体验更顺滑 |
| API | Assistant SDK更新 | 原生支持多智能体编排，省很多胶水代码 |
| API | Function 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） |
|---|---|---|
| 每次输入token | 800K | 800K |
| 每次输出token | 8K | 10K（含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库实践细节再跑细一点，到时候有结论了继续写出来跟大家交流。
