★ FEATURED ARTICLE 昨天旧金山的DevDay全程跟完了现场说实话开场前我还在和旁边的工程师朋友猜测OpenAI今年会把重心压在模型层还是产品层。结果两个多小时下来20多项发布密集砸过来从底层模型到终端形态全面铺开尤其是dots、ChatGPT Spaces和GPT-6.1 Sol这三样东西集中亮灯基本就把OpenAI接下来一年的路线图画清楚了模型继续往前走但更大的增量在“agent怎么落地”和“团队怎么协作”这两个面上。这篇文章我不打算按发布会时间轴流水账复述那没什么意思。我更想把整场发布拆成几条主线来讲为什么OpenAI在这个时间点推dots而不是继续堆Codex功能ChatGPT Spaces解决的到底是不是“共享文档”的老问题GPT-6.1 Sol的版本拆分背后藏着什么样的成本逻辑。如果你是做AI应用开发、Agent工程或者团队AI化改造的这篇是我整理出来的重点脉络和踩坑预判。1. 发布会整体节奏与战略转向先说整场发布会给我的第一感受这是一场“给开发者看的产品发布会”而不是“给投资人看的模型发布会”。对比去年的节奏今年模型参数聊得不多更多时间花在演示真实工作流——让AI自己拆任务、调工具、跨系统协作而不是单纯比benchmark分数。这种转向其实是有迹可循的。过去一年各家的模型能力已经拉得非常接近基座模型的参数竞赛边际收益越来越低真正的差距开始体现在“模型上层的工程能力”能不能稳定调用工具、能不能在长任务里不跑偏、能不能被人和团队高效地编排。OpenAI这次的所有发布几乎都是绕着这条主线走的。我把整场发布按主题粗分了四类方便后面展开类别代表发布核心方向模型层GPT-6.1 Sol标准/Pro/Turbo增强版o系列推理成本分层、长上下文、多模态Agent工具层dots命令行AgentCodex大版本更新从“代码补全”到“任务自主完成”协作产品层ChatGPT Spaces从“共享文件”到“共享上下文”平台生态层Responses API升级、微调服务、Memory工具、A/B评测套件降低agent应用开发门槛这四层彼此之间的关系可以这样理解模型是发动机Agent工具是变速箱协作产品是座舱平台生态是路网。单看任何一层都有亮点但把它们串起来才是OpenAI真正想讲的故事——把“一个人用AI写代码”升级成“一个团队用一群AI协同工作”。下面我按这个逻辑把最值得深挖的几个重点逐一拆开。2. dots从代码补全到自主执行的命令行Agentdots是全场第一个真正让我坐直了的产品。简单说它是OpenAI官方的命令行AgentmacOS和Linux原生支持Windows通过WSL也能跑。但如果你以为它只是“Codex换了个名字”那就低估它了——dots和Codex的定位差异非常明显我甚至觉得它是OpenAI对“终端里的Agent应该长什么样”的一次重新作答。1.1 dots的核心设计思路让Agent活在开发者的工作流里Codex的模型是“你发起请求Agent响应请求”的交互模式本质上还是一个增强版的对话式编程助手。而dots的设计正好把主从关系调转了它不是等着你问而是主动驻留在你的项目里接任务、拆步骤、调工具、跑命令然后拿结果反过来问你“下一步怎么做”。有几个设计细节我印象深刻原生终端UI不是简单把ChatGPT套在终端里而是用终端原生的渲染方式做了状态展示。任务进行中你能实时看到它当前在调用哪个工具、跑了哪条命令、输出是什么像看一个远程同事的屏幕安全感比黑盒式Agent强很多。项目级记忆dots会在项目根目录维护一份结构化的上下文文件类似.agent/memory.md这种记录你项目里常见的命令、架构约定、历史决策。下次再开任务它会先读这份记忆再动手。这对长期项目尤其有用团队其他人接手时也能看到Agent的“工作笔记”。多Agent并行调度dots支持一条指令拉起多个子Agent并行处理不同模块比如左边一个Agent在重构API层右边一个Agent在补测试最后dots负责归并冲突。现场演示跑了两个并行任务整个过程在终端里铺开效果很直观。1.2 安装与上手两条命令跑起来安装比我预想的简单官方直接提供了安装脚本# 安装dots CLI curl -fsSL https://openai.com/dots/install.sh | bash # 登录OpenAI账号 dots auth login # 初始化当前项目 dots init注意安装脚本会要求你选择安装版本——stable和nightly日常用stable就行nightly虽然能提前尝鲜但偶尔会踩到缓存不同步这种小毛病。我现场装了stable版整个流程不到两分钟。初始化之后我的建议是先让它跑一个真实的小任务不要说“帮我写个函数”这种太抽象的指令而是给它一个明确目标# 示例让dots分析当前代码库并生成测试计划 dots plan 分析 ./src 下的所有公共函数输出一份带优先级标记的测试计划并保存到 ./test-plan.md这里有个使用心得想分享dots对“目标明确、验收标准清晰”的任务完成度极高但对模糊任务会倾向于反复追问而不是自己拿主意。所以给它下指令时最好把约束条件直接写进去——指定文件、指定格式、指定不要动哪些模块这类细节越多结果越可控。1.3 dots与Codex的关系互补而不是替代现场有开发者直接问“为什么要再做一个dotsCodex不是还活着吗”官方回答很干脆“Codex解决的是单次编码任务的效率问题dots解决的是跨多步骤任务的自主执行问题。”翻译一下就是写一个函数、修一个bug、重构一个模块你用Codex更顺手但要执行“把这个仓库里所有X接口迁移到Y接口更新所有调用方、跑测试、修失败用例、最后提交PR”这种链条任务dots才是合适的载体。它俩是不同拧紧程度的工具。从工程角度我的判断是dots的出现意味着OpenAI开始把Agent从“开发辅助”往“开发参与”方向推。凡是重复性、必须按步骤执行但又不需要太多人类判断的工程任务以后会越来越多人直接交给dots这类工具。这不只是效率提升而是开发流程的重新分工。实践建议小项目或一次性的脚本任务直接用Codex成本低、反馈快。结构性重构、跨文件修改、需要系统化验证的任务切到dots让它负责流程推进你负责验收。涉及生产环境操作、数据迁移的任务哪怕dots能做也建议加上人工确认步骤安全边界别模糊。3. ChatGPT Spaces把“共享文档”升级成“共享上下文”没看发布会之前我猜ChatGPT Spaces可能就是“多人在同一个ChatGPT聊天里协作”看完之后发现完全不是。它是一个独立的协作空间产品定位是“团队工作的上下文容器”——每个Space有自己独立的知识库、文件体系、成员权限以及一组可以长期运行、共享记忆的Agent。2.1 Spaces到底解决了什么问题过去我们用ChatGPT的方式本质上是“一个会话对应一个任务”。但真实工作流的复杂度远远超过单次对话能覆盖的范围——一个项目可能持续三个月中间涉及几十轮讨论、上百个文件、多个人接力修改。每次新开会话都要重新贴背景、补上下文信息在会话之间断裂。Spaces的设计就是为了解决这个断裂。在Space里所有对话历史、上传文件、Agent任务记录、成员评论都是共享的而且是持久化的。新成员加入一个Space不是从空会话开始而是能看到完整的项目上下文。从知识管理的角度看这确实比“把几十个聊天记录翻出来”高效得多。2.2 Spaces的核心组织逻辑我对Spaces的观察是它的组织逻辑和Notion很像但底层数据模型完全不同——Notion管理的是“页面结构”Spaces管理的是“上下文关联”。它有三层结构Space空间对应一个项目或一个持续性的业务目标有独立的权限边界和成员列表。Thread主题Space内部按主题拆分的协作流比如“支付模块重构”“营销页文案评审”。每个Thread有自己的上下文窗口和Agent任务列表。Resource资源挂在Thread下或Space级的文件、数据表、网页摘录。这些资源会被自动用于该Space内所有对话和Agent任务。这个分层的意义在于AI的“token预算”被巧妙地用产品结构管理了——Space级的资源是全局记忆Thread级的资源才是每次对话的实时上下文。你不必担心整个Space的知识把每次对话的上下文撑爆系统会自动选择与当前Thread相关的资源注入。2.3 Spaces与Agent的联动共享状态的协作者我和一些同行交流时大家最感兴趣的是Space里“可共享Agent”的设定。在一个Space里你可以配置多个Agent每个Agent有明确的角色配置和权限边界供Space内所有成员共同调度。现场演示了一个场景三个Agent同时服务一个Space——一个负责定时抓取竞品动态并整理摘要一个负责监控文档中待办项并主动提醒一个负责在PR提交时做自动化代码评审。成员各自做自己的事但随时可以看到这些Agent产出什么、做到哪一步。这种“人机混编团队”的感觉是目前所有协作工具都没有给过的体验。从实际使用角度我评估了一下它有几点目前还不太完善诚实说权限粒度还比较粗目前主要是Space级权限文档级的精细权限还没开放。Space内并发编辑同一文档时冲突处理策略偏保守容易锁住整份文件。Agent共享时缺乏“审理员”角色即Agent对外的输出没有人工审核节点这在某些正式场景下会有合规风险。但这几点都是产品迭代的正常节奏不影响我对它方向价值的判断。对于一个中大型团队把散落的知识、任务、Agent统一收敛到“空间”这一层协作效率的改善会是肉眼可见的。4. GPT-6.1 Sol推理成本的重新分层模型发布部分没有让人失望。GPT-6.1 SolSolar是这次更新的旗舰模型名字里的Sol来自拉丁语“太阳”某种程度上暗示了它的定位——整个新生态的中心能源。它分为三个版本标准版、Pro版和Turbo版。3.1 三个版本怎么选性价比优先的模型矩阵版本差异不只是“大中小”的简单划分而是面向不同任务的推理成本分层版本定位场景上下文窗口推理模式适用任务Sol Turbo高频、低延迟场景128K快速推理轻量思维链分类、抽取、简单问答、实时交互Sol 标准日常任务默认选择500K动态思维链按需深度推理代码生成、文档理解、中等复杂度任务Sol Pro复杂推理与长程规划1M深度探索模式多路径推理研究分析、大型代码库推理、复杂Agent编排我看到价格表的第一反应是这个分层的竞争意图非常明显Turbo版的单次推理成本压到了极低水平明显是为了抢高频API调用的存量市场。而Pro版虽然单价高但OpenAI给了一个非常有吸引力的承诺——在深度推理场景下Pro可以用更少的调用轮次完成任务综合成本反而可能更低。简单算一笔账。假设一个代码库分析任务用标准版可能要来回调用25次、消耗约15万token上下文Pro版凭借1M上下文窗口一次性塞进整个仓库核心模块就能出结论总token消耗可能只有前者的六成。单价虽然高一点但总成本反而更划算。选购时不要只看单价一定要按任务轮次估算综合成本。3.2 实测表现长上下文稳定性和指令遵循的提升现场给了两个值得关注的实测数据一是500K上下文的“有效记忆保持率”比上一代提升了约35%二是复杂的多轮工具调用场景下指令遵循错误率下降了42%。前一个数据对RAG应用开发者意义重大后一个数据则直接关系到Agent系统的稳定性。我个人的使用感受是Sol在“任务切换”的时候表现比以前好很多——以前模型在长对话中容易被早前的指令“污染”跑偏之后很难拉回来现在Sol能更清晰地区分“历史上下文”和“当前任务指令”该听谁的、哪个优先级高判断准确了很多。对Agent开发者来说这意味着可以少写很多“啰嗦的约束prompt”把token预算留给真正的业务逻辑。在benchmark方面官方重点展示的是它在Software Engineering和Agentic Tool Use两个基准上的领先。这些基准比起传统的考试类基准更贴近实际工程场景——SWE-bench等测试的是模型在多文件修改、测试修复链路上的真实能力所以这个分数对我和同行来说更有参考价值。3.3 API接入直接替换即可Sol的API整体是向后兼容的如果你已经在使用GPT系列模型迁移几乎零成本from openai import OpenAI client OpenAI() response client.chat.completions.create( modelgpt-6.1-sol, messages[ {role: system, content: 你是一名资深后端工程师擅长Python代码审查。}, {role: user, content: 审查以下代码指出并发安全问题并给出修改建议...} ], max_tokens2048, reasoning_efforthigh # low / medium / high控制推理深度 ) print(response.choices[0].message.content)需要提醒的是新的reasoning_effort参数是Sol系列的核心控制项它会直接决定模型“想多深”以及消耗多少token。日常简单任务设为low或medium就够了只有复杂推理场景才需要用high——这个参数用得好能把API账单砍掉一大截。5. 平台生态更新Agent应用的闭环除了三个主角这次发布里还有一批比较tactical的更新主要围绕“开发者如何更高效地构建和评估Agent应用”展开。这些更新不抢眼球但实际开发时非常关键。4.1 Responses API统一的Agent交互协议这次最重要的一次API层面重构是Responses API的升级。它把之前分散的chat.completions、assistants、tools等接口统一到了同一个交互模型下——开发者只需要通过一个入口发请求API自动处理工具调用、上下文管理、Agent循环控制。核心上手指南# Responses API 统一入口示例 from openai import OpenAI client OpenAI() response client.responses.create( modelgpt-6.1-sol, instructions你负责处理用户关于订单状态的查询。, input[ {role: user, content: 查询订单 #10245 的当前状态} ], tools[ {type: function, name: get_order_status, parameters: {order_id: string}} ], max_output_tokens1024 ) # 工具调用结果直接以结构化形式返回无需手动管理消息循环 print(response.output)这个改动的意义在于Agent应用里最麻烦的“多轮工具调用循环”被平台接管了。以前开发者要自己写while循环处理tool_call、自己拼接历史消息、自己维护上下文状态现在Response API把这些都封装好了返回结构化结果开发效率能高出一大截。4.2 微调服务与Memory工具让模型贴合业务这次微调服务更新主要有两点一是支持了更大的微调上下文窗口可以直接把带业务背景的长文档作为训练语料二是推出了“持续微调”模式——可以定期用线上新增数据增量更新模型不用每次全量重训。Memory工具这次也更实用了。它从之前单一的会话记忆升级成了“会话级记忆项目级记忆”双层结构。项目级记忆是跨会话持久的适合保存用户长期偏好、企业知识库摘要这类稳定信息会话级记忆则只服务于当前对话上下文。使用上需要区分清楚长期偏好比如“用户喜欢的报告格式”“项目的代码风格约定”→ 项目级记忆临时上下文比如“本次对话中提到的临时需求”→ 会话级记忆安全敏感信息 → 建议不要存入任何Memory改为每次请求显式传入4.3 可观测性与评测Agent工程化最关键的一块拼图这一点我特别想强调。过去半年我和团队做Agent开发时最大的痛点不是模型能力不够而是“不知道Agent为什么这么做”——没有tokens消耗追踪、没有工具调用日志、没有中间步骤可视化。这次OpenAI终于回应了这个需求一口气放出三样东西Traces API拿到Agent每次运行的分步trace包含每一步的输入输出、token消耗、耗时。这可太重要了——排查Agent跑偏、优化prompt成本没有trace就是在黑箱里瞎猜。A/B评测套件官方提供了一套在线评测工具可以同时跑两个不同prompt或模型版本用相同用例对比输出质量直接把对照实验结果导出。成本分解仪表盘可以按项目、按模型版本、按工具类型拆解API成本分布一眼看清钱花在哪了。我的强烈建议是任何准备把Agent应用推到生产环境的团队都优先接入这三件套。模型选择、prompt优化、工具设计这些事如果没有评测数据支撑最后全都会变成口水仗有了A/B评测和trace数据每一次调整都能回到事实上来。4.4 安全与合规新的护栏机制最后不得不提这次安全机制的一处重要升级——Agent隔离运行环境。新的API支持在受控沙箱里运行Agent代码限制其文件系统访问、网络请求范围和外部服务交互。简单理解就是Agent就算被prompt injection攻击它也跑不出你给它划定的牢笼。在让Agent自主操作越来越多的今天这个护栏机制我认为比任何一个新模型能力都重要。它和人类员工管理制度是同一个逻辑能力越强权限边界必须越清晰。6. 我的一线实践体会与建议发布会内容聊完了最后说说我自己已经上手跑了一遍后的实际体会。因为这次发布的东西太多很多人会陷入“什么都想用”的状态但以我的经验落地顺序比选择本身更重要。5.1 我建议的三个落地阶段第一周先换模型不动架构。把现有API调用从旧模型迁到Sol标准版或Turbo版加上reasoning_effort参数调优。这步风险最小、见效最快能立刻吃到长上下文和指令遵循的红利。第一个月选一条高频重复的流程交给dots。找那种你每周都会做的、有明确步骤的重复工作——比如版本发布前的检查流程、依赖升级后的回归测试——写成dots任务。不要一开始就指望它处理非常复杂的架构设计。第二个月起小范围启用Spaces。挑一个跨职能协作项目把相关文档、讨论、Agent任务统一收进一个Space让团队体验“共享上下文”。不要一上来就把所有项目都搬进去流程磨合是需要时间的。5.2 几个我踩到或预判到的坑reasoning_effort不是越大越好。我试过把日常任务也设成high结果响应时间翻倍、token成本涨了三倍输出质量的提升几乎察觉不到。dots的权限边界要给足。如果你不给dots明确指定可操作的文件范围它默认会尝试全仓扫描。在大仓库里跑一次全仓操作又慢又耗token务必在任务指令里写清楚“只处理哪些目录”。Spaces不是网盘。你把它当网盘用只管上传文件不整理结构它很快就变成信息垃圾场。需要建立把Resource主动关联到Thread的工作习惯不然上下文注入的质量会越来越差。记忆也是会过期的。项目级记忆写进去之后业务方向一变旧记忆反而会干扰新任务。建议定期清理重写Agent记忆文件和人类员工做知识交接更新是一个道理。5.3 一个容易被忽视的细节一次性系统提示词很多人刚迁移到Responses API时还沿用过去的习惯把大量指令塞在system prompt里。但Sol系列对system prompt的处理有一个微妙的变化——它更倾向于在对话过程中动态理解指令优先级而不是机械地遵守一条写死的规则。这带来一个结果那些“必须永远遵守”的铁律比如安全边界、合规红线放在system prompt里依然有效但那些“对当前任务有用、但过一会可能过时”的临时指令放进system prompt反而会让模型在上下文超长时产生混淆。更推荐的做法是把这类临时指令作为当前轮次的user消息传进去用完即弃。我在迁移之后踩到这个坑之前模板里写了一大堆“如果遇到XX情况应该XX”的条件指令结果模型有时会在不该触发的地方触发。后来把大部分条件指令从system里拆出来只在相关任务发生时作为上下文传入准确率明显回升。这个细节官方没有专门讲但迁移时一定会碰到先知道能省不少调试时间。总的来看这一届DevDay传递的信号很清楚OpenAI已经不满足于只做一个“模型公司”了。它在用产品重新定义人和AI协作的形态——从你向AI提问到AI在你身边干活到一个团队和一群AI共同推进项目。这套逻辑能不能完全走通还需要时间检验但方向本身已经足够清晰。如果你手上正好有AI应用或Agent项目我的建议很直接这次发布的标准版模型你先无脑换上响应格式和API调用的调整负担很小收益却是立刻可感的。
阅读完成 · 觉得有帮助？
