OpenAI 开发者负责人谈 DevDay 后如何选用 Sol、Astra 与 dots

OpenAI 近期的发布为开发者在软件中使用 AI 提供了更多选择。在 2026 年 DevDay 上，该公司推出了新模型、工具和智能体，这些都在成本、速度、安全性以及团队如何跟上节奏方面提出了实际问题。

9 月 29 日，OpenAI 在其旧金山总部附近举办了第四届年度 DevDay。公司列出了涵盖 ChatGPT、Codex、其模型和开发者 API 的 20 多项重大发布。其中包括 GPT-6.1 Sol，以及面向 GPT-6 Astra 的更快 Ultrafast 档位；Sol 的 Ultrafast 支持随后于 10 月 8 日推出。

这些发布还包括 OpenAI dots，即可以在后台工作的常驻智能体。在 GPT-6 Astra 的支持下，它们可以通过 OpenAI 的插件生态系统连接 4,000 多个应用，并承担持续性职责。

这些智能体在后台持续运行，进行研究与监控，然后提出行动建议——完成拉取请求（PR）、起草消息、文档和分析，或预订会议——供人工在环审核。根据用户的规则和所涉及的操作，dot 可以继续执行、请求批准，或将敏感任务留给用户处理。

其他更新包括 Decisions API，它使用预定义的答案选项对输入进行分类或路由请求；以及 Agents API 中的计算机使用功能，让智能体能够与软件界面交互。

在 11 月 3 日于伦敦举行的 OpenAI Dev Day Exchange 之前，OpenAI 欧洲、中东和非洲地区开发者体验与社区负责人 Vaibhav “VB” Srivastav 向 The New Stack 谈到了公司正在发布的一系列功能。常驻伦敦的 Srivastav 还指出了这些新发布可能如何影响工程师的日常工作。

本次采访经过编辑，以求清晰和简洁。

The New Stack：在 DevDay 上，OpenAI 发布了 20 多项产品和更新。在快速变化的时代，开发者和工程经理如何决定使用什么？OpenAI 又如何考虑开发者吸收这些变化的成本？

Vaibhav Srivastav：我们确实发布了很多东西，对吧？总体目标是，当我们想要发布某个东西时，尽可能减少所有人的摩擦。这涵盖从使用 ChatGPT 回答问题的普通人，到使用 Codex 完成日常工程任务的更高级用户，再到工程经理或人员经理等混合角色的人。从开发者的视角来看，我尤其对那 20 项中的四项充满热情，并帮助团队将它们发布出来。

首先也是最重要的是 GPT-6.1 Sol。它最高可达到 Astra 95% 的性能，但成本只有五分之一。当我们发布 GPT-6 Astra 时，大家都说：“嘿，这是一个非常好的模型。我们很喜欢它”，但我们无法将这种智能水平带到每个人都能负担得起的价格点。这就是为什么我们努力将 GPT-6.1 Sol 带到让每个人都能在各档计划中受益的价格点。

我并非每天都用 Astra。我确实把 GPT-6.1 Sol 作为我的主要首选。

Vaibhav “VB” Srivastav，OpenAI 欧洲、中东和非洲地区开发者体验与社区负责人。

Sol 与 Astra 的权衡

TNS：OpenAI 将 GPT-6.1 Sol 描述为以 Astra 标准输入和输出 token 价格的五分之一提供“接近 Astra 的智能”。哪些类型的评估支持这种“接近”的说法，Sol 又在哪些方面不如 Astra？

VS：当我们拿到一个模型时，我们会运行传统基准测试，包括 Terminal-Bench 4.0、GDPval、GDP.pdf、SWE-bench 以及许多其他测试。在这些基准测试中，GPT-6.1 Sol 和 GPT-6 Astra 非常接近。Terminal Bench 和 SWE-Bench 都能很好地指示模型在困难和长时间运行任务上的表现。在这两项基准测试中，6.1 Sol 在实证上都非常接近 GPT-6 Astra。

其次，更重要的是，在这些模型准备好发布之前，我们会在内部试用这些模型，看看某个特定模型有多好。一个很好的成功衡量标准是，当所有人都开始采用该模型作为日常主力，涵盖工程、产品以及营销、人力资源等相邻团队时。当我们开始内部试用这个模型时，我们看到人们迅速转向将 GPT-6.1 Sol 作为日常主力。

他们可以使用任何他们想要的东西。我们对人们使用这些模型做什么没有内部限制，所以他们可以选择任何他们想要的模型，而他们一直选择 6.1 Sol。

TNS：对于在 GPT-6.1 Sol、GPT-6 Astra 和 Ultrafast 速度档位之间做选择的开发者或团队来说，决策规则是什么？什么时候值得为高级版本付费？

VS：在我看来，对于大多数任务，Sol 能让你达到大约 95% 的目标。对于新项目或不熟悉的问题，我会求助于 Astra 来寻找漏洞或我可能遗漏的东西。

“如果我用 GPT-6.1 Sol 开发那个功能，然后用同一个模型做代码审查，这就像检查我自己的工作。我会偏向于说它很好。”

如果我用 GPT-6.1 Sol 来开发那个功能，然后用同一个模型做代码审查，这就像检查我自己的工作。我会偏向于说它很好。为了进行对抗性审查，我会给 GPT-6 Astra 全新的上下文，让它挑毛病、拆解这项工作，并帮我确保它安全、可靠，并让我得到我想要的结果。

TNS：Ultrafast 模式适合用在哪里？

VS：Ultrafast 适用于重要的实时用例，比如欺诈检测、金融调查和代码调查。开发者告诉我们，他们希望在这些场景中有极快的东西。Ultrafast 模式让 GPT-6 Astra，以及现在的 GPT-6.1 Sol，能够以极快的速度输出——超过每秒 300 个 token——价格高于标准档位，但仍然相当实惠。

我们后来把 6.1 Sol 加到了 Ultrafast 中。它的成本是标准 Astra 的 1.2 倍，因此你能以超过每秒 300 个 token 的速度获得接近 Astra 的性能，价格只比 Astra 高 20%。

护栏与自动审查

TNS：我们来谈谈护栏，既包括开发者可以使用的计划方面的护栏，也包括安全和治理方面的护栏。

VS：任何可能给企业或商业用户增加成本的功能默认都是关闭的。他们需要明确选择加入。

对我来说更有趣的一点是安全。随着模型做更多事情并且变得更快，我们希望它们的行为与你想要的一致。我最喜欢的一个功能叫做 Auto-review。在模型行动之前，一个 Luna 级别的[轻量、超高效]模型会根据你定义的策略检查它。

例如：我不希望模型代表我提交任何东西、发送电子邮件或分享个人身份信息。组织或独立开发者可以定义策略，让这些模型能够更长时间地安全、自主运行。

另见：在受控测试中，OpenAI 的 GPT-6.1 Terra 在 29.6% 的运行中绕过了限制

TNS：现在我们来谈谈 Decisions API 的开发和影响。

VS：Decisions API 是在 DevDay 前四五天成形的。一个四五人的团队为 DevDay 交付了一个生产就绪的预览版 API，几天后又推出了 beta 版。Decisions API 是多模态的：它对文本和图像进行分类，并快速返回结构化输出。传统上，你会给 LLM 一个 schema 并要求结构化输出。现在它在相同准确率下快了 10 倍，每百万未缓存输入 token 收费 0.10 美元。

OpenAI dots 如何运作

TNS：最后，我们来谈谈 DevDay 的主要公告之一：OpenAI dots。

VS：dot 是一个持久的、始终在线的智能体，它会查看你授予它访问权限的工具、插件和其他界面。它识别出需要你关注的事情，并编排工作以完成它。

TNS：dot 如何在没有被要求的情况下决定要处理什么，当它代表用户做了某事时，用户会看到什么？

VS：我的 dot 连接到了 Slack，OpenAI 的许多工作都在那里进行。它还连接到了我的 GitHub，我在那里贡献工程工作，以及我的 Gmail 和日历。每隔一段时间，我的 dot 会浏览我的 Slack 消息、私信、提及、邮件和日历。它把这些信息汇集在一起，并呈现我尚未处理或它可以帮我分担的事情。

我的团队分布在全球，所以总有人在昼夜不停地工作。我的 dot 可能会说：X 标记你审查这个拉取请求，或者 Y 正在等待关于即将发布的模型的信息。以前，我每天早上要花时间筛选成千上万的 Slack 提及和线程。我会特意告诉我的 dot：这是我团队里的某个人，这是她做的事情。当她标记 A、B 或 C 时，确保我知道。它会不断收集更多上下文。它知道如果我的老板给我发消息，我想快速回复，所以那会排在我的列表最前面。如果我正在开发的产品明天或后天发布，那自动就是高优先级。

我的 dot 还会查看我的工程工作，包括 PR，并可能说：这个已经批准了。你可以合并它。或者它可能说：我也可以帮你合并它。我可以在手机上说是，它就可以合并 PR、检查测试是否通过，并验证它在生产环境中看起来是否正确。

TNS：一些开发者说 AI 让他们感到更加孤立。你会怀念 Slack 里那些更傻气的东西吗，比如分享表情包或其他与工程师建立联系的方式？

VS：我的反应恰恰相反。我去年 12 月加入 OpenAI。当时，模型很好，但不能可靠地为我自主做事。现在模型好多了。它们可以从你指向的任何地方获取上下文。以前，我花很多时间确保模型做了它应该做的事，留给赶上进度或与团队闲聊的时间更少。

“每周五，它会检查我的日历，并为我与过去三四天没说过话的人安排 30 分钟。如果我手动做，我永远坚持不下去。”

现在我能更好地掌控工作，因为不用再花一两个小时翻找 Gmail 和 Slack 消息了。我让我的 dot 每周帮我安排时间，与团队里一段时间没聊过的人叙叙旧。每周五，它会查看我的日历，并为我与过去三四天没说过话的人预留 30 分钟。如果让我手动做，我永远坚持不下去。

TNS：最近有这么多更新，不同团队会试点不同功能。他们应该衡量什么来判断是否有效？哪些指标最终会被证明具有误导性？

VS：每个新模型总体上都应该更好，这基于指标和我们内部看到的情况。但性能提升幅度因用例而异。

当我们发布一个模型时，会在一个孤立的用例上测试它——一次迁移、一个新产品或一项监控任务——并衡量提升幅度。提升可以意味着以更低的成本获得相同的结果，或者获得更好的结果。

对一个组织来说，问题是它愿意为特定结果支付多少。这就是模型家族中其他模型的用武之地。我们有 GPT-6 Astra、GPT-6.1 Sol、GPT-6 Luna，还有其他模型正在开发中。

Ultrafast 这类功能也是如此。并非每个问题都需要 Ultrafast，但你可能需要它来监控一次影响大量用户的重要迁移。这时就要用到搭配 6 Astra 或 6.1 Sol 的 Ultrafast。

把几个问题放进这个测试里，看看模型或功能是否有帮助。我们在内部也这么做。我们运行 A/B 测试，看看功能对用户的效果。我们还会考察每个功能或模型的产品市场契合度。

模型弃用与迁移

TNS：OpenAI 加快了模型发布周期。对于在这些 API 上构建生产就绪系统的开发者，你们能就稳定性和迁移路径做出什么承诺？

VS：稳定性和最终用户体验对我们很重要。如果你访问 status.openai.com，可以看到我们的可用性达到四到五个九，这意味着我们确实非常重视这一点。

过去一年，我们发布模型的方式发生了很大变化。更好的模型帮助我们更快地构建下一代，提高开发者和研究人员的生产力。

“因为我们发布得更快，所以在确定下一代在所有方面都更便宜、更准确之前，我们不会弃用某个模型。”

去年 11 月，我们还有 GPT-5.1。现在我们已到 GPT-6 Astra 和 GPT-6.1 Sol。因为我们发布得更快，所以在确定下一代在所有方面都更便宜、更准确之前，我们不会弃用某个模型。

对于 API，我们提供三个月的弃用通知和迁移路径，让你的工作流能借助下一个模型变得更便宜、更好。

尽管我们已经到了 6.1 Sol，我们仍为 API 用户提供 GPT-5.5。

TNS：开发者如何应对如此多的持续变化和迁移？传统的敏捷软件开发生命周期必须改变什么？

VS：我们在内部也看到这一点：你构建了某个东西，下一个模型帮你改进它。这始终是一种权衡。总有一些你不太在意的东西。如果我构建软件是为了解决我团队内部的问题，我可能不需要最前沿的性能。

但假设我在构建的是为用户处理交易的东西，或者他们直接使用的另一个产品。那我就会想要最好的性能和当前最先进的技术。

在 AI 之前，团队以冲刺方式开发软件直至发布，然后暂停新功能来修复损坏的地方。他们在数月或数个季度里重复这个循环。我们在模型上也看到同样的情况。

新一代到来；你冲刺去使用它，然后暂停。当另一个模型到来时，你用它来改进安全性并构建更好的功能。我认为这是开发者已经在做的事情的延伸。

文章《“我不是每天都用 Astra”：OpenAI 开发者负责人告诉 TNS 原因》首发于 The New Stack。