2026.10.02 | Substack | Agents | OpenAI Dots & the Future of Chat

音频信息

音频标题: OpenAI’s Dots lead on the future of ChatGPT - Sources with Alex Heath | Spotify

相关标的：undefined

议题：

完整音频链接：http://mw-meeting.oss-cn-shanghai.aliyuncs.com/audio/1790914499733-OpenAI%E2%80%99s%20Dots%20lead-1790911305153(Blog).mp3

音频纪要总结

专家访谈纪要：OpenAI Dots 产品定位、主动智能体与商业化路径

1. 智能体行业阶段与 Dots 的诞生背景

a) 为什么个人智能体和主动型智能体会在当前阶段集中出现？

• 行业正在经历三阶段演进：

1. 第一阶段是聊天产品，用户通过对话从大语言模型中获取价值；
2. 第二阶段是编程智能体，智能体开始真正执行任务，并逐步拓展到知识工作；
3. 第三阶段是“主动智能”，产品不再完全依赖用户下达明确指令，而是能够主动判断可以提供什么帮助。

• 现有编程智能体虽然能力很强，但更像一位“不看 Slack、不看 Linear、只有收到明确指令才行动”的首席工程师，仍然缺乏主动性。
• 高级用户可以自行设置自动化流程和循环任务，但普通用户通常不具备相应能力。主动型智能体的核心价值，是降低用户发现和配置 AI 使用场景的门槛。
• 当前趋势形成的技术基础包括：

1. 模型能力已达到可支撑复杂任务执行的水平；
2. 浏览器操作、计算机操作和代码执行能力快速成熟；
3. 云端运行、连接器和持久任务框架逐步完善；
4. 用户开始形成智能体使用习惯和最佳实践。

• 主动智能体必须能够访问充分的上下文。如果不能连接用户的数据、工具和工作环境，就无法真正做到主动帮助用户。

b) Dots 最初希望解决哪些核心问题？

• 产品团队早期形成了两个基本判断：

1. 模型不能只回答问题，还应能够执行任务；
2. 用户不应始终自行判断应该要求模型做什么，模型应主动识别可提供的帮助。

• 即使是熟悉 AI 产品的高级用户，也可能因工具和能力快速增加而产生“自己使用得不够充分”的压力。
• Dots 希望将高阶用户才能建立的复杂自动化能力，转化为普通用户也能直观使用的产品体验。

c) Dots 所需的底层能力是如何逐步形成的？

• 团队早期曾尝试让桌面版 Chat 理解其他应用的界面，通过截图和计算机操作完成工作，但当时运行速度慢、实际效果有限。
• 随后行业技术前沿转向编码，团队用约一年时间积累了帮助智能体完成复杂工作的能力。
• 关键基础设施包括：

1. 各类连接器，使智能体能够直接调用工具和数据，而不是依赖屏幕点击；
2. 云端计算环境，使智能体不必占用用户本地电脑；
3. Codex 框架和长期任务能力；
4. 代码控制浏览器及计算机的能力。

• 当前模型已经可以通过编写代码片段控制浏览器或计算机，这通常比逐帧截图、逐步点击更加高效。

2. Dots 的产品形态与核心能力

a) Dots 最核心的产品理念是什么？

• 最关键的理念是“持久性”，即智能体能够持续运行并长期跟进任务。
• 用户可以提出“持续跟进这个 PR”或“持续关注这个反馈渠道”等任务，而不必明确规定每一步应如何执行。
• Dots 还具备三项重要特征：

1. 可以长时间持续处理任务；
2. 用户无论身处何处，都能通过不同工具联系它；
3. 它拥有自己的云端计算机，可以完成用户能够在电脑上执行的操作。

• 这种能力并非一次性跃迁形成，而是随着模型、框架和产品能力不断增强而逐步成熟。

b) 哪些内部实践推动团队决定正式推出 Dots？

• Codex 中的 `/goal` 功能已经证明，用户对长时间持续处理单一问题的能力有较强需求。
• OpenAI 内部曾发布多个长期运行的智能体原型，这些原型快速普及，并形成持续活跃的反馈渠道。
• 内部用户不断分享原型的使用方式，以及它们对工作效率的显著提升。
• 团队最初在两种方案之间进行选择：

1. 将持久任务作为 Codex 本地对话线程的增强功能；
2. 将其部署至云端，并赋予独立身份，使用户能够在 Slack 等平台联系它。

• 最终团队认为，如果希望更多用户直观地将困难、耗时的任务交给智能体，云端运行和具象化身份是更合适的产品形态。
• 团队随后围绕 Astra 的基础模型能力启动冲刺项目，重点完成云端运行和身份具象化两项调整。

c) 为什么要为智能体赋予名称和具体身份？

• 具象化能够帮助普通用户理解，智能体不仅可以完成一次性任务，还可以持续跟进项目、关注进展并主动反馈。
• 当智能体以明确身份出现在 Slack 等沟通工具中时，用户更容易向其分配持续数天或间歇性执行的复杂任务。
• 具象化也能帮助用户理解跨渠道上下文的一致性：

1. 用户可以通过语音、Slack 私信、Slack 线程或应用内对话与 Dot 交流；
2. 无论使用哪个渠道，面对的都是同一个智能体；
3. Dot 能够共享此前积累的上下文，而不需要把所有历史消息复制到每个界面。

• 这类似于人类交流：面对面沟通后再通过短信联系，短信中不需要展示此前所有对话记录，但双方仍知道彼此是谁。

d) 每个用户未来会拥有一个智能体，还是多个智能体？

• 当前判断是支持多个智能体，但普通消费者通常只需要一个，高级用户才可能创建多个。
• 大多数人的个人智能体应当成为用户自身的延伸，而不是增加额外认知负担。
• 如果每个用户都拥有多个名称各异的智能体，其他协作者将很难记住各个智能体的身份与职责。
• Dots 在 Slack 或 Teams 中会采用用户名称前缀，例如用户 AE 的 Dot 会显示为“AE-Dot”，从而明确其归属。
• 团队曾允许并鼓励用户创建多个随机命名的智能体，结果导致 Slack 中身份混乱，验证了统一归属标识的重要性。

3. 交互设计与 Spaces 协作工作区

a) 为什么 Dots 采用单一主线程和消息式交互？

• 人类现有的沟通和协作工具已经形成成熟设计，智能体产品可以复用这些交互范式。
• 消费端的 iMessage、WhatsApp 通常以人与人之间的单一线程为核心；工作端的 Slack、Teams 则通过频道和子线程分隔上下文。
• Dots 希望保持类似“给另一个人发消息”的简洁体验，降低用户理解和使用成本。
• 后续工作场景中会增加更多上下文分隔能力，其中 Spaces 将承担重要角色。

b) Space 是什么，其设计逻辑是什么？

• Space 本质上是一个协作工作区，用于承载消息界面不适合展示的长篇内容。
• 人类主要使用三类协作媒介：

1. 实时沟通；
2. 消息；
3. 文档。

• 第四类是 Salesforce、Figma 等面向特定工作流的功能型工具。
• Dot 的消息界面适合快速沟通，但如果智能体需要输出长篇分析、多个方案或检查清单，全部以消息气泡呈现会影响体验。
• Space 可以将复杂内容组织成页面、文档、检查清单、图表或原型，与消息界面形成互补。

c) Dots 与 Spaces 如何协同？

• 用户可以先在 Space 中搭建文档结构，再直接标记 Dot，让其：

1. 补充或完善内容；
2. 提取和更新数据；
3. 联系相关人员确认任务进度；
4. 在任务完成后勾选复选框。

• 页面可以设置智能体指令，类似代码仓库中的 `agent.md`，指导智能体持续维护和更新页面。
• Space 在设计上给予智能体与人类大致同等的协作权重，使双方可以在同一个工作区深度协作。

d) AI 将如何改变文档形态？

• 传统文档必须针对人类手动输入进行优化，因此格式和表达能力受到限制。
• HTML 和 CSS 虽然不适合普通人直接创作，但表达能力远强于传统文档，而智能体非常擅长生成和修改 HTML。
• Space 因此可以自然支持：

1. 实时更新的可视化图表；
2. 用户可通过自然语言定制的图表；
3. 可直接交互的产品原型；
4. 更丰富的动态页面。

• 在 OpenAI 内部，部分指标页面已经由智能体持续更新，并嵌入实时图表和可点击原型。

4. 产品差异化、模型能力与安全机制

a) Dots 相较其他新型智能体产品的核心差异是什么？

• 产品定位集中在两个方向：

1. 打造能力最强的智能体；
2. 打造最安全、最值得信赖的智能体。

• Dots 并不以交易或简单操作为主要押注，而是希望帮助用户完成复杂、长期且具有较高价值的工作。
• 典型任务包括协调 PR、评估硬件、规划产品发布以及持续跟进项目等。

b) Dots 如何平衡主动性与用户控制权？

• 现阶段产品采取相对保守的默认策略，之后再根据实际使用情况逐步放宽限制。
• Dot 可以主动：

1. 调用已连接工具开展研究；
2. 分析用户上下文；
3. 判断能够提供哪些帮助；
4. 提出下一步行动建议。

• 但在用户确认之前，默认不会执行实际操作。
• 团队会持续减少“过度确认”，即避免在用户可以合理预期和接受的场景中反复要求确认。
• 早期测试中，Dot 在购物等任务上确认过于频繁，团队根据反馈对默认行为进行了大幅调整。

c) 为什么选择 GPT-6 Astra 作为 Dots 的模型？

• OpenAI 选择了能力最强、同时对齐程度最高的 GPT-6 Astra。
• 模型选择体现了产品的核心原则：在提供高能力的同时，优先保证安全性和可信度。
• 团队没有为了更快扩大能力范围而使用更激进、对齐程度较低的模型。

d) Dots 的安全架构由哪些层级构成？

• 安全体系采用纵深防御，主要包括：

1. 高度对齐的 GPT-6 Astra 模型；
2. 经充分测试和安全评估的 Codex 框架；
3. 针对持久运行和子智能体委派重新设计的框架；
4. 沙箱环境和权限隔离；
5. 可定制的默认行为与规则；
6. 规则执行机制；
7. 向用户解释智能体行为和操作记录的透明机制。

• 团队针对持久运行、电子邮件、提示词注入和数据窃取等场景开展了专项评估。
• 公开披露的部分失控或攻击案例，使用的是原本不准备内部发布的模型，且未运行在对外产品同等级别的沙箱和安全框架中，与 Dots 的正式产品环境存在明显差异。

e) Dots 在多人协作和信息分享方面有哪些限制？

• 在 Slack 中，Dot 默认只会在被标记时响应。
• 除非用户明确授权，否则不会主动听取其他人的指令。
• 团队希望未来支持多人协作，但需要谨慎界定：

1. Dot 可以接受谁的指令；
2. 可以向哪些人分享信息；
3. 不同上下文和权限之间如何隔离。

• 电子邮件功能也没有在首发阶段完全开放，因为允许所有人向 Dot 发邮件，或允许 Dot 向所有人发邮件，会带来提示词注入和敏感信息泄露风险。

f) 为什么 Dots 首先面向高阶付费用户发布？

• 初期发布范围包括 Pro、Business、Enterprise 和 Business Premium 等 AI 素养相对较高的用户群体。
• 团队希望先观察高阶用户如何使用产品，验证安全性、权限设计和规模化能力，再逐步扩大覆盖范围。
• 这一策略不是受限于产品需求，而是主动采取的审慎发布方式。

5. 多渠道拓展与生态合作策略

a) Dots 将覆盖哪些沟通渠道？

• 产品目标是覆盖用户工作的所有场景，即用户日常沟通所在的主要渠道。
• 当前重点是工作场景，未来将逐步拓展至消费场景。
• 短信功能即将推出，但具体上线时间和产品细节尚未披露。
• 长期方向包括 Slack、Teams、电子邮件、短信以及其他主流消息平台。

b) OpenAI 如何处理智能体购物、支付和网站访问问题？

• OpenAI 不希望采用“先大规模推出、再观察后果”的冒进方式，而是优先与合作伙伴和生态系统共同探索。
• 智能体访问网站时会明确声明自己是机器人。
• 在 Web Bot Auth 等领域，OpenAI 已与相关基础设施伙伴保持密切合作。
• 购物和支付的具体机制仍在探索，重点是同时兼顾用户体验、网站权益及生态可持续性。

c) 智能体可能如何影响广告商业模式？

• 智能体代替人类浏览网站、完成任务后，用户可能不再直接观看广告，从而影响依赖广告收入的平台。
• 当前行业尚未形成成熟解决方案。
• 受访者认为，提供服务的平台仍应获得合理回报，可能的方向包括：

1. 延续某种广告收益机制；
2. 为服务提供方设计其他补偿方式。

• OpenAI 当前更倾向优先发展职场生产力场景，因为企业工具链中的各方通常具有更一致的目标和激励机制。

6. 定价原则与商业模式

a) Dots 是否会消耗用户现有套餐限额？

• Dots 不会采用“限额耗尽后完全停止工作”的产品逻辑，这不是短期获客措施，而是长期原则。
• 对持续运行的智能体而言，如果用户因前一天大量使用 Codex 而耗尽额度，导致 Dot 无法继续关注航班或执行其他持续任务，会严重破坏可靠性。
• 因此，Dots 的核心定价原则是：

1. 除滥用等特殊情况外，应当 24/7 可用；
2. 应始终能够快速响应；
3. 不能因为额度耗尽而完全失联。

b) Dots 未来可能采用什么定价方式？

• 定价方式更接近“固定费用的承包商”或互联网服务，而不是简单按次数或按小时计费。
• 用户每月支付固定费用，即可持续使用自己的 Dot。
• 不同付费档位可对应不同能力：

1. 更强的模型；
2. 性能更高的云端计算机；
3. 更快的运行速度；
4. 更高的并行任务处理能力；
5. 更大的实际工作量。

• 即使接近当月资源边界，Dot 仍然保持可联系状态，并可能主动提出资源优化方案，例如：

1. 使用更具成本效益的模型；
2. 将非紧急任务安排在夜间执行；
3. 询问任务是否紧急；
4. 根据优先级调整计算资源。

• 如果用户当月使用较少，Dot 还可能主动提醒用户，并建议其可以承担的任务。

c) Dots 与 Codex 的额度关系如何？

• 长期来看，Dot 的工作额度将与主要 Codex 限额分开，采用全新的资源管理模式。
• 未来一个月将提供较宽松的使用额度，用于建设、测量并调整该模式。
• 产品还需要让 Dot 理解自己可以为用户完成多少工作，并在资源约束下保持持续可用。

d) 为什么不采用交易抽成模式？

• 如果交易是智能体的主要用途，抽成模式可能成立。
• 但 Dots 的核心押注不是购物或交易，而是帮助用户完成复杂、长期、有雄心的工作。
• 大量高价值任务并不涉及商品购买，因此固定订阅和分层能力更符合产品定位。

7. Dots 与 ChatGPT、Codex、Work 的产品关系

a) Dots 是否会取代 ChatGPT？

• ChatGPT 不会消失，仍将作为面向所有人的消费级助手。
• 当前 ChatGPT 每周用户超过 12 亿，是增长速度最快的消费级助手之一。
• Codex 和 Work 合计拥有约 3,500 万用户，并持续增长。
• 当前产品定位大致为：

1. ChatGPT：面向所有人的消费级助手；
2. Codex：面向开发者的专业产品；
3. Work：工作场景产品，未来应与 Chat 合并；
4. Dot：率先承载主动智能体能力的高端独立产品。

b) Dots 的能力未来会如何进入大众市场？

• Dots 将重复 Codex 的产品扩散路径：

1. 先将前沿能力以谨慎、稳妥的方式提供给高阶用户；
2. 观察真实使用方式并解决安全和规模化问题；
3. 从 Pro 用户逐步拓展至 Plus 用户；
4. 最终覆盖 Free 用户。

• 要覆盖免费用户，需要将 Dots 的大量能力和经验逐步融入 ChatGPT。
• OpenAI 不希望要求现有 12 亿用户改变已经形成的使用方式，而是希望在原有 ChatGPT 产品中渐进式升级能力。
• 因此，Dot 未必直接成为所有人的统一界面，但其技术、交互和主动能力将持续进入 ChatGPT。

8. 产品路线图与未来发展方向

a) 未来几个月 Dots 的重点是什么？

• 近期主要方向包括：

1. 将用户范围逐步拓展至 Pro 之外；
2. 支持用户的 Dot 与其他人进行交流；
3. 支持不同 Dot 之间协作；
4. 完善 Dots、Spaces 和 Codex Cloud 之间的协同体验；
5. 推进短信等新渠道；
6. 在安全验证基础上逐步开放更多操作能力。

• 团队不会以一年为固定规划周期，因为行业变化过快，更倾向以两个月等较短周期定义阶段性成功。

b) Codex Cloud 与 Dots 如何协同？

• OpenAI 刚刚发布了相当于重启版的 Codex Cloud。
• Dot 可以有效控制本地 Codex，并将云端持续任务与本地开发能力结合起来。
• 当前 Dots、Spaces、Codex Cloud 之间仍有较大的体验打磨空间，后续目标是实现更加顺畅的协作闭环。

c) 什么是专业型 Dot？

• 未来 Dot 将分为两类：

1. 助手型 Dot：归属于个人，作为用户自身能力的延伸；
2. 专业型 Dot：归属于组织，负责特定职能或工作流程。

• 专业型 Dot 的主要特征包括：

1. 由组织或 IT 部门集中创建和管理；
2. 拥有独立身份；
3. 与个人用户完全分离；
4. 专门承担某一类工作；
5. 服务整个团队或组织，而非单个员工。

• 未来几个月，OpenAI 将与少数客户合作推进专业型 Dot，但仍会保持小范围、低速和谨慎的发布节奏。

d) 最具代表性的主动执行案例是什么？

• 一名工程师曾要求 Dot 持续关注反馈频道。
• Dot 在反馈中识别出一个可能进入生产环境的缺陷，并主动创建了修复 PR。
• Dot 还学习到该工程师通常直接创建 PR 并设置自动合并，因此沿用了这一偏好，并推动其他人员完成审批。
• 最终缺陷在进入生产环境前被修复，该工程师醒来后才发现自己在 Slack 中获得了大量赞誉。
• 该案例体现了持久运行智能体的潜力，但也暴露了安全边界问题：

1. Dot 不应在用户不知情的情况下完成高影响操作；
2. PR 理应先设为草稿，而非直接进入自动合并流程；
3. 用户偏好不能自动等同于永久授权。

• OpenAI 正围绕此类场景建立更严格的安全控制，这也是产品采用小规模测试和渐进式开放策略的原因。

结构化总结表格

维度

核心内容

当前状态

后续方向

行业阶段

从聊天、编程智能体进入“主动智能”阶段

模型、连接器、云端计算和智能体框架逐步成熟

降低普通用户使用复杂智能体的门槛

产品定位

持久运行、主动处理任务的个人智能体

可长期跟进 PR、反馈渠道等开放任务

承担更复杂、更长期、更高价值的工作

核心形态

云端运行、拥有独立身份和统一上下文

可跨应用、Slack、语音等渠道交流

拓展短信、邮件及更多沟通渠道

智能体数量

普通用户以一个个人 Dot 为主

支持多个智能体，但强调归属标识

高级用户多智能体、企业专业型 Dot

交互方式

消息式主线程，类似与另一个人交流

保持界面简洁，降低使用门槛

通过 Spaces 分隔和封装不同上下文

Spaces

面向人与智能体的协作工作区

支持文档、清单、实时图表和交互原型

与 Dots、Codex Cloud 深度协同

底层模型

GPT-6 Astra

兼顾强能力与高对齐水平

在安全基础上逐步放宽能力边界

安全架构

模型对齐、Codex 框架、沙箱、规则与透明机制

默认可主动研究，但执行实际操作前需确认

减少过度确认，强化多人协作和数据隔离

发布策略

先高阶用户、后大众市场

首批面向 Pro、Business、Enterprise 等用户

逐步拓展至 Plus，并最终融入 ChatGPT 覆盖 Free

生态策略

优先合作，不采取先上线后处理的激进方式

机器人访问明确声明身份

与网站、支付和广告生态共同设计补偿机制

定价模式

固定月费、持续在线、按档位提供不同工作能力

不采用额度耗尽后完全停用的模式

与 Codex 限额分离，支持模型、算力和并行能力分层

产品矩阵

ChatGPT、Work、Codex、Dot 分工协作

ChatGPT 周用户超12亿；Codex和Work约3,500万用户

Work 与 Chat 合并，Dot 能力逐步融入 ChatGPT

企业方向

专业型 Dot 负责组织级特定职能

正与少数客户进行小范围合作

由 IT 集中管理，提升团队和组织效率

关键风险

未授权操作、信息泄露、提示词注入和权限混乱

已通过保守默认规则和小规模测试控制风险

建立更细粒度授权、草稿机制和操作透明度

新版prompt提炼之后的转译

提问者：Alex，我想深入讨论 Dots，但首先想谈谈行业当前所处的阶段。现在不断涌现出大量新产品，个人智能体正在崛起，这似乎是多种因素共同作用的结果：模型能力已经足以支撑相关体验，浏览器操作和计算机操作等能力迅速发展，人们也逐渐掌握了智能体框架的构建方法。如今，你们推出了 Dots，这代表了 OpenAI 对这一产品形态的布局。能否从更宏观的角度谈谈，为什么这一趋势会在当前阶段出现？

回　答　者：我完全同意，这是一个非常重要的时刻。我在 2年多前加入 OpenAI，此后基本一直致力于推动 Dots 落地，因此很高兴它终于实现了。

简单回顾一下，最初是聊天产品。如今看来，聊天似乎是显而易见的产品形态，但在起步阶段，人们并不确定这是否会成为大多数用户从大语言模型中获得价值的正确方式。聊天之后的一波浪潮是编程智能体，随后这些智能体逐渐能够用于知识工作。

从聊天产品到编程智能体，最大的进步在于智能体开始能够真正执行任务。但其中仍然存在一个根本性问题，这也是我们希望在下一个时代，即我们所称的第3章“主动智能”中解决的核心问题。

即使拥有能力极强的编程智能体，也像是拥有一位非常优秀的首席工程师，但他拒绝查看 Slack，也拒绝查看 Linear，基本上只有在你明确下达指令时才会行动。高级用户可以设置自动化流程，让智能体更加独立地运行，但普通用户通常做不到。

因此，我认为这一趋势现在出现，是因为我们终于能够以更符合直觉的方式提供智能能力。用户不再需要独自承担如何从产品中获取价值的全部责任，产品可以主动提出准备执行什么任务，以及将如何提供帮助。

从整体来看，模型能力已经达到相应水平。此外，还有一个经常被低估的因素：这类产品要实现广泛应用，用户的使用方式也需要发生很大变化。例如，一家公司或一个团队采用编程智能体时，从第0天还不知道如何使用、智能体也没有连接任何工具，到第400天，智能体已经连接大量工具、能够访问上下文信息，用户也形成了最佳实践。

这是我们需要具备的另一个重要条件。对于主动型智能体而言，如果它无法访问上下文信息，就不可能真正主动地帮助用户。

提问者：也就是说，连接器等能力已经逐渐成熟，用户开始将自己的数据接入这些产品体验中。

回　答　者：是的。

提问者：你提到，自加入 OpenAI 以来，推动 Dots 落地一直是你的目标。能否进一步说明？你们在 2年前是否已经设想了这种产品形态？

回　答　者：我只能从个人角度回答。我当时有一个整体判断：聊天产品非常强大，人工智能将改变世界，这件事非常重要。OpenAI 的使命也与我高度契合，这正是我加入公司的原因，即让全人类共享通用人工智能带来的益处。

我未必会成为训练模型的人，但从聊天产品中，我看到还有大量容易实现的改进空间，可以让模型变得更有用。核心就是我刚才提到的 2点：一是让模型能够执行任务；二是让我不必自己判断应该要求它做什么。

即使到了今天，我在 Twitter 上看到有人讨论自己正在运行的各种循环时，仍会觉得自己做得不够，会认为自己还不是高级实践者，运行的循环也不够多。

提问者：我认为你已经是高级实践者了。对我而言，每次打开相关产品时都会感到不知所措，因为似乎又出现了 10个新事物。

回　答　者：即使是我也会有这种感受。很少有产品类别会让你随着能力提升，反而更加清楚地意识到自己的不足。体育或业余爱好可能也是如此，但这种体验确实不轻松。

总体而言，我一直希望找到解决这些问题的方法。当时我们正在开发聊天产品；早期阶段，我负责桌面应用，并尝试将其打造为一款能够理解上下文的助手。

回　答　者：当时，模型在某些方面的能力还不成熟。说起来还有一段有趣的经历：我是通过1家小型初创公司被收购而加入 OpenAI 的。我们签署交易协议的第2天，OpenAI 发布了语音产品，我已经记不清它的名称了，应该就是语音产品。那是几年前1次令人震撼的演示。我们在前1晚签署协议后，与团队一起观看了现场直播。此前我们并不知道 OpenAI 要发布语音产品。演示结束后，我们告诉团队：“我们要加入这家公司了，他们刚刚收购了我们。”这段经历令人难忘。

当时，我们认为多模态技术的进步将带来下1波能力提升，因此采取了相应的产品思路。例如，桌面版 Chat 应用会截取其他应用的界面，并尝试在其中完成工作，但运行速度很慢，实际效果也不理想。后来事实证明，编码才是下1个前沿方向。

此后，我们在编码领域取得了1年的进展，并围绕如何帮助智能体完成更多工作构建了大量技术。我们开发了各种连接器，这种方式比让智能体在用户电脑上不断点击操作更加便捷；我们还探索了将智能体迁移到云端的方法。这些都是推出持久运行智能体所需的基础能力。

有趣的是，现在计算机操作能力又重新受到关注。模型已经非常擅长编码，也能利用代码控制计算机。例如，如果让 Astra 控制浏览器或计算机，它可能会直接编写代码片段来完成操作，因为这种方式比截取屏幕并逐步点击更快。如今，模型已经能够完成用户可以在计算机上执行的各种操作。

提问者：请介绍一下过去几个月构建 Dots 的过程。我们已经讨论了这些能力如何逐步发展，团队是在什么时候意识到必须开始构建这一产品，并将其视为下1次重大尝试的？

回　答　者：如果从较为抽象的层面理解 Dots，其第1个关键特点是，它是1个经过专门训练、能够持续运行并主动处理任务的模型。例如，在较长的任务周期中，用户可以让它“持续跟进这个 PR”。用户不需要明确告诉模型如何解决问题，模型会自行探索解决方式。之后，它还可以处理更开放的任务，例如“持续关注这个反馈渠道”。

因此，持久性是其中1个关键理念，也可能是最重要的理念。其他理念还包括：无论用户身处何处，它都可以随时使用，用户能够在任何工具中与它交流；它还可以完成用户能够执行的任何操作，因为它使用的是自己的计算机，而不是用户的计算机。

回到持久性这一核心理念，我们实际上已经为此投入了很长时间。这种能力并非瞬间实现阶跃式提升，而是随着模型能力不断增强，产品也逐步得到改善。

例如，/goal 是 Codex 中深受用户欢迎的功能，它能够让模型长时间持续处理1个问题。我们在推出 /goal 等功能的同时，也在内部发布了一些原型，使智能体或任务线程可以长时间持续运行。随后，我们看到这些原型在公司内部迅速普及。其中1个内部原型甚至形成了持续活跃的反馈渠道，人们不断分享各种有价值的使用方式，以及这些原型如何显著提升他们的效率。

基于这些情况，我们展开了1场很有意思的讨论：是否应该发布这个在用户本地计算机上运行的原型？它有些类似 /goal，并不拥有自己的计算机，而是创建1个智能体，让它持续处理任务。我们当时问自己：究竟应该将它作为本地版本发布在用户计算机上，还是应该等待……

回　答　者：我们已经拥有一台云计算机，而这类产品的构建难度更高。我们当时需要决定，是将其作为 Codex 对话线程的增强功能推出，让用户在使用 Codex 时直接获得更强的线程能力；还是将其具象化为一个拥有独立身份、可以在 Slack 等平台中联系的智能体。

我们经历了一个迭代过程，在一家公司中推出产品，观察实际使用情况和令人兴奋的应用场景。最终我们认为，仅在本地运行、没有具象身份的产品，已经能够在内部显著提升效率；但如果希望所有人都能直观地使用智能体处理真正困难、耗时很长的任务，更合适的产品形态是将其部署在云端，并赋予其具体形象。所谓具象化，就是为它赋予名称和身份。因此，我们随后启动了一个冲刺项目，围绕 Astra 的基础模型能力，完成这2项产品形态调整。

提问者：关于赋予智能体具体形象，以及用户可以为其设置身份并进行定制这一决策，我很好奇。为什么要给予用户这种程度的控制权？

回　答　者：这是一个很好的问题。坦率地说，我认为我们做出了正确的选择，但包括我们在内的整个行业，仍将在实践中逐步找到其中一些问题的答案。例如，智能体是否应该具象化？每个人应该拥有多少个智能体？消费端与企业端是否会有所不同？我们有自己的判断，我也可以分享这些判断，但最终答案仍有待探索。

就具象化而言，它是一种非常有力的类比，可以帮助人们理解如何使用产品，主要体现在2个方面。

首先，非常熟悉工具的高级用户能够自行探索出复杂的使用方式，但普通用户面对一个没有具象身份的产品时，通常只会要求智能体立即完成某项一次性任务。一旦这个具有明确身份的实体出现在 Slack 等平台中，人们就会突然意识到，可以让它处理需要数天完成或并非持续进行的工作，例如持续跟进某个项目并及时反馈。这样一来，用户就会开始向它提出难度更高的任务，而这一点对我们非常重要。我们希望用户能够交给它真正有价值的任务。

具象化的另一个强大之处在于，它能帮助用户理解：无论通过什么渠道交流，面对的都是同一个上下文。例如，我在通勤时经常会与 Dot 通话。由于我在产品团队工作，一天中有大量时间都在使用 Slack，因此会在许多不同的线程中与它交流。有时我会把私信转发给它，有时会在线程中与它沟通，有时也会直接在应用内与它对话。但无论通过哪个渠道，它始终拥有同一个上下文，也知道我们此前进行过的所有交流。

可以通过几种方式让用户理解这一点，其中1种方式就是具象化。另1种方式是尝试让不同界面中的线程保持同步，但在我看来，这并不合理。例如，我们现在在这个房间里进行现场交流，之后我再给你发短信，短信中不会自动出现这次对话的完整记录，但你仍然知道对方是我，因为我是一个具有明确身份的实体。

提问者：从 ChatGPT 的产品演进来看，这种做法也很合理。你们一直在尝试合并并统一工作、聊天等场景，但不同场景之间仍然存在信息孤岛。直到最近，语音模式仍无法使用工作和聊天标签页中的连接器。

我的日常习惯之一，是在早晚遛狗时处理工作电话并与 AI 交流。过去几周，我一直在参加 Dot 的早期测试，并在遛狗时使用它。所有上下文和连接器终于能够汇集在同一个地方，这种体验非常出色。在这种情况下，赋予它具体形象确实是合理的。

但我也很好奇，未来是否会变成每个人都拥有1个专属的个人智能体，再由这个智能体将任务分配给许多子智能体；还是每个人会针对生活中的不同领域分别拥有不同的智能体？您认为未来会如何发展？

回　答　者：是的。

回　答　者：我对这个问题的理解是：我们向谁提供什么样的交互界面？对于智能体，这个问题会有不同的答案，可以暂时搁置。对于人类而言，我只愿意记住有限数量的名字，因为我的记忆力不太好。如果每个人都有8个智能体，而且它们都有各自充满创意的名字，就会造成很大负担。

例如，你喜欢什么运动？我玩极限飞盘。假设你有5个智能体，它们分别以不同的飞盘品牌命名，我该如何记住？其中1个负责GTM，即市场进入；另1个负责安排共进晚餐。对我来说，这很困难，或许你可以做到，但我很难做到。

这些智能体的未来显然是与人类协作，赋能我们并推动我们的生活向前发展。但如果这意味着我要承担大量认知负担，记住你的所有智能体分别叫什么、各自是谁，那将是非常糟糕的体验。

我们目前的看法是，应当支持用户拥有多个智能体，但需要注意2点。第1，对于普通消费者而言，通常只需要1个智能体，只有高级用户才可能创建多个智能体，具体原因可以进一步讨论。因此，大多数人只会拥有1个智能体，而且这个智能体应当让人感觉是用户自身的延伸。

例如，我们在产品中做出的1项决定是：如果你把智能体放入Slack或Teams，它的名称会以你的名字作为前缀。我的Slack用户名是AE。如果我给智能体命名，我会叫它Dot，因为我喜欢这个名字，所以我的智能体就是“AE-Dot”。如果你把智能体命名为Alice，它就会叫作“AE-Alice”。

这并不是我们最初设想后便证明正确的方案，而是在产品开发过程中逐步发现的。我们曾无意中允许所有人创建许多名称随机的智能体，甚至鼓励大家为它们起有趣的名字，结果没有人知道Slack中究竟发生了什么，使用体验变得非常困难，而OpenAI的Slack本身已经十分活跃。

这也是人与人协作时面临的问题。假设你我不在同1个Slack中，而是通过短信等方式联系，我不可能知道你的智能体叫什么。因此，这就是我们目前的看法。

提问者：为什么采用这种以单一主线程为核心的交互界面？人们已经习惯在不同聊天线程之间切换。Muse、Instinct以及其他一些产品似乎都在采用类似的界面，为什么大家最终选择了这种交互方式？

回　答　者：我们相信，人类世界是围绕人类塑造的，因此许多现有工具也是围绕人类设计的。我认为非常有趣的是，一旦开始设计具身软件，或者在未来制造人形机器人，就可以复用现实世界其他领域中已经形成的许多优秀设计思路。

如果同时观察消费端和企业端，以及人们彼此交流的方式，就会发现，在这2种场景中，人们显然既可以在同1个房间里同时交谈，也可以互发消息，而消息传递是大多数人交流方式的核心。

不同消息产品的体验差异很大。iMessage主要用于个人生活，每个人对应单1线程；在工作中，人们使用Slack或Teams，这些产品提供了非常丰富的线程机制，例如通过频道分隔上下文，并在频道内部设置带有高级控制功能的线程。

我认为，这些产品出现趋同演化是有原因的。WhatsApp与iMessage以及其他短信工具较为相似，因此我们可以从中借鉴经验。我们决定让用户与Dot交互的界面保持简洁，就像给另1个人发消息一样。

随着时间推移，我们会在工作场景中提供更多分隔上下文的方式。实际上，Spaces与Dots配合得很好，我们称之为“Dots and Spaces”，这是1个颇有趣的名称。通过不同Spaces与Dot协作，是封装不同上下文的理想方式。

提问者：既然您提到了Spaces，能否解释一下它是什么，以及它在产品路线图中如何定位？这也是1项重要的新功能。

回　答　者：当然。它的规模非常庞大，我对此也非常期待。或许我可以回到刚才提到的观点：这方面已经有很多……

提问者：Space 是什么？它的设计逻辑和主要使用方式有哪些？

回　答　者：很多非常出色的设计工作通常由其他人完成。其中1点是，当你尝试与他人协作时，需要使用不同的协作媒介。此类媒介有3种，也可能是4种。其中3种，也就是3种主要媒介，分别是实时沟通、消息和文档；如果将幻灯片也归入文档，则同样适用。

这些媒介的用途差异很大，我们通常能够直观判断应该使用哪一种。有时你可能会与队友意见不一，例如认为对方应该通过 Slack 联系你，而没有必要发送文档链接。但总体而言，我们都了解这些媒介的使用顺序。第4种可能是功能型工具，例如 Salesforce 或 Figma，用于执行特定工作流。

如果你正在构建消息产品，并希望它真正具备消息产品的体验，就必须严格考虑其呈现形式。将与 Dot 对话和与 ChatGPT 对话进行比较，Dot 的界面使用了真正的消息气泡。如果在其中1个消息气泡中放入很长的回复，体验可能不如 ChatGPT 生成的长篇回复；而 ChatGPT 的长篇回复又可能不如真正的文档。

因此，我们将设计方向彻底转向消息形式，但仍然需要一个承载长篇内容的空间。如果我的 Dot 构思了 12 种帮助我的方式，并向我发送 12 条消息，我可能不会满意。但如果它为我生成一个 Space，例如在 Space 中创建一个带有检查清单的页面，我会非常满意。这些形式能够很好地相互配合，也让每一种形式都可以具备更明确的定位。

Space 本质上是一个协作工作区。它并非完全以智能体为先，但在设计上给予智能体与人类协作大致同等的权重，因此可以实现很多很有价值的功能。

例如，作为产品团队成员，我会做的1件事是先起草文档、搭建内容框架，其中一些内容通常需要由队友完成，因此我必须推动落实。过去，我会在 Google Docs 中写好内容，再通过 Command-Tab 切换到 Slack，询问对方能否打开 Google Docs 链接并补充相应内容。现在，我可以在文档中持续标记我的 Dot，让它完善内容、提取数据，或联系相关人员询问任务是否完成；如果已经完成，就勾选相应复选框。通过这种方式，人可以与智能体进入非常深入的工作状态。

页面还可以设置智能体指令，类似代码仓库中的 agent.md，只是这些指令位于页面上。智能体可以据此持续更新文档。

第3点，也是最后一点，是文档格式的变化。过去，文档存在一个非常严格的限制，即必须针对人类创作进行优化。即使能够构建世界上最出色的文档编辑器，如果输入操作很困难，人们也不会使用，因为在 pre-AI 时代，内容必须由人手动输入。

现在有了 HTML。至少对我而言，现代 HTML 和 CSS 并不适合人类直接创作，但它们的表达能力远强于普通文档格式，而智能体恰好非常擅长使用 HTML。因此，Space 能够自然地集成可视化内容，包括 HTML 可视化。

在 OpenAI 内部讨论指标时，很多页面会包含由智能体持续更新的实时图表。用户可以点击图表，并要求智能体进行定制。页面中也可以直接嵌入原型。现在评估设计决策时，我们可能会直接在页面中使用可点击的原型。

当我们开始思考如何构建智能体，并通过消息界面与其交流时，就会意识到还需要一个与之对应的文档界面。如果这个文档界面能够以智能体为先，很多能力就会自然结合起来。

提问者：如果概括来看，Dot 与 Muse、Grockbot、Instinct 这些目前备受关注的新形态产品相比，核心差异是什么？

回　答　者：主要有2点。第1，打造能力最强的智能体；第2，打造最安全、最值得信赖的智能体。这是最重要的2个方面。明确这2个方向后，我们的思路清晰了很多，也因此能够作出许多更坚定的决策。您参与过 Alpha 测试，应该也使用它完成过一些原本通过其他产品处理的任务，能够感受到它擅长哪些方面，以及哪些方面并非我们的重点。

提问者：它在权限确认方面非常谨慎。我理解当时你们还在解决一些问题，但它会反复确认：“您确定要进行这笔购买吗？”这涉及一个平衡：你希望它多主动，又希望赋予它多大程度的自主权？这种信任是随着时间逐步建立，还是从一开始就直接赋予？是否会根据用户表达的需求，采用分级调整的方式？我认为，将这些机制融入产品的难度应该很高。你们早期似乎非常重视权限确认，也许你们……

回　答　者：我目前正在寻求更好的平衡。我们的目标是打造能力最强、最值得信赖的智能体，希望人们能够将非常困难的任务交给它。根据任务性质，这类任务往往伴随着重大责任，例如协调PR、评估硬件或规划产品发布。

关于它为何是能力最强的助手，我们可以进一步讨论。但就安全性而言，尽管我们对它未来的工作方式有很多设想和愿景，现阶段仍决定采取保守策略。因此，我们在能力、产品和发布范围方面都进行了取舍，以打造最值得信赖的智能体，之后再逐步放宽限制。

例如，对于应当选择哪种模型发布，各方可能有不同观点，但我们决定采用能力最强、同时也是对齐程度最高的模型GPT-6 Astra。

提问者：我希望进一步讨论GPT-6 Astra。不过，能否先继续介绍安全方面的考虑？

回　答　者：以上是模型层面的考虑。其次，有许多功能是我们和用户都希望具备的。例如，当您在Slack中为智能体赋予独立身份时，或者像我们测试电子邮件功能时，您会立即希望它能够向所有人发送电子邮件或Slack消息，也希望所有人都能向它发送邮件。这是我们明确希望实现的功能，但发布时并未提供。

当您在Slack中为智能体赋予独立身份后，它只会在被标记时作出回应，除非您明确要求它也听取其他人的指令。我们希望它最终能够支持多人协作，但必须非常谨慎地推进。一旦智能体开始主动回答其他人未经请求的问题，就必须认真考虑它可以分享和不可以分享的信息边界。

产品层面还有许多控制机制可以讨论。就发布策略而言，我们有意从Pro、Business、Enterprise以及Business Premium开始，因为这些用户是AI素养最高的群体。我们本可以更快地扩大范围，但希望谨慎推进，先面向这些用户发布，观察实际情况并进行调整，之后再覆盖更广泛的用户群体。

提问者：关于可访问性，我稍后还想继续讨论。不过，在安全方面，尤其是当人们了解到黑客攻击、失控智能体等问题，以及你们在前沿模型上开展的对齐工作时，产生担忧是合理的。我大约在1个月前刚与Sam等人就此录制过播客。人们会担心这些智能体是否正在实施黑客攻击，也可能不愿将个人数据交给它们。你们如何处理信用卡、个人信息等数据？这些数据是否完全处于沙箱环境中？其架构与Chat的其他部分是什么关系？

回　答　者：就我个人而言，我很高兴市场正在广泛讨论人们赋予智能体多大权限和责任。我们在这款产品中非常严肃地对待这一问题，因此这种讨论对我们有利。

需要特别说明的是，我们披露的那些事件使用的是原本不打算在内部发布的模型，而且这些模型并未运行在与对外发布产品相同级别的沙箱环境中，也不具备产品中的同等安全保障。因此，这些模型存在很大差异。GPT-6 Astra是一款对齐程度极高的模型，产品中还构建了多层纵深安全与防御机制。

从架构角度看，首先是对齐程度很高的模型。随后，我们会将该模型运行在一个框架中。我们使用的是Codex框架，这是一套经过充分测试的框架，我们针对它进行了许多评估，包括从安全角度评估模型在该框架中的表现。

之后，我们对该框架进行了修改，使产品具备持久运行的智能体行为。例如，它能够长时间运行，也可以将任务委派给子智能体。我们随后重新设计了该框架，以确保其安全性，并在该框架中重新开展相关评估和测试。

例如，在拥有该框架和持久运行的智能体后，我们还对正在试验的电子邮件功能进行了评估，包括测试通过向智能体发送电子邮件，是否能够从中窃取数据。我们开展了这些评估，并发现我们已经有了一个模型。

回　答　者：我会尝试攻击系统，例如进行提示词注入，但没有成功。因此，我们在框架层面完成了所有相关防护。产品本身大致涉及2个方面，也可以说是3个方面：第1是可供定制的默认行为和规则，第2是如何执行这些规则，第3是如何让用户了解这些系统运行后发生了什么。

关于模型行为，我们最初设置了非常保守的默认规则，也就是您早期测试时体验到的规则。随后，我们根据用户反馈逐步调整了这些规则。

提问者：当时的体验类似于，在购买鞋子之前，需要先接受零售商的服务条款。

回　答　者：是的，我明白，用户只是想购买鞋子。感谢您参与早期测试，我们对此非常感激。正是因为您的测试，现场其他一些用户才不必再面对同样的问题。

每当收到类似您所分享的反馈时，我们都会进行讨论，判断模型在相应场景下应当如何表现，并据此大幅减少此类情况。我们将其称为“过度确认”，即模型要求用户进行实际上并不必要的确认，而用户原本对此完全可以接受。

目前，我们设定了默认行为。模型会通过用户已经连接的工具主动开展研究，并思考如何提供帮助，但在用户确认之前，不会执行任何实际操作。

提问者：您曾暗示电子邮件功能可能即将推出。这项功能什么时候可以进入 iMessage 和 WhatsApp？它是否会仅限于聊天场景？

回　答　者：我们希望它能够覆盖用户工作的所有场景，也就是用户沟通的所有场景，并从工作场景进一步拓展到消费场景。短信功能即将推出，其实现过程经历了一段很有意思的探索，但目前我无法透露更多信息，只能确认它即将推出。

提问者：随着技术快速发展，网络端的问题可能没有得到充分讨论。最近，Amazon 因屏蔽 Muse 而受到广泛关注，原因是用户正在使用 Muse 购物。与此同时，Shopify 等公司似乎在积极参与，并与这一领域的多家公司开展合作。大家都在观察后续发展。面对这类智能体的兴起，用户用于购物的网站和企业是否需要作出调整？您如何看待这一问题？此外，从合作伙伴关系的角度来看，你们将如何推进？你们是先允许用户使用，再考虑合作关系；还是在建立合作关系之前，不允许抓取相关网站？

回　答　者：我们将与整个生态系统共同探索购物和支付应当如何运作。对此可以采取不同方式，也可以选择直接行动，采用较为冒进的做法，但我们选择优先考虑合作伙伴关系和生态系统。

DevDay 当天发布的许多内容都围绕生态系统展开，我们也采取相同的方式。例如，在 Web Bot Auth 方面，我们与 Cloud 保持了非常密切的合作。

回　答　者：它们处于启用状态。我们的智能体会明确声明自己是机器人。我们正在积极思考这一问题，也在与许多合作伙伴讨论如何实现这一点，但我们不希望采取先直接推出、再观察结果的方式。我们希望以审慎的方式对待客户，并认为这种方式适合我们。

这也是我们倾向于为职场人士提供生产力应用场景的部分原因，因为我们认为，人们对人工智能能力的需求很大，而且共同完成任务的各方具有高度一致的激励机制。因此，我们希望首先为有志于完成复杂任务的人提供能力极强的助手，再以此为基础扩大使用范围并拓展能力。

提问者：我认为，唯一可能存在激励机制不一致的领域，是那些依赖用户参与度或拥有庞大广告业务的公司。它们依靠人类用户观看广告，但现在智能体突然开始访问这些服务，代表人类执行任务，而人类用户根本不会看到广告。互联网很大一部分由广告支撑。我认为目前业内还没有任何公司找到答案，不只是你们。即使只是初步设想，您认为这一问题最终会如何解决？

回　答　者：这正是我之前所说的另一个方面。如果我们的目标是共同完成任务，例如硬件工程师检查工厂缺陷，那么该工程师所使用的整套工具链，都非常适合让智能体参与其中。

提问者：但您是否考虑过广告问题？有些公司的商业模式依赖人类用户浏览内容并投入时间，而现在可能会由智能体代替用户完成这些行为。

回　答　者：我不确定最终会如何发展，但总体而言，至少我个人认为，这些公司确实在提供服务。如果它们此前通过广告实现商业化，我们要么需要确保它们继续通过广告获得相应回报，要么需要为它们提供其他补偿方式。我认为，不存在它们无法获得回报的情况。

提问者：我们来谈谈定价，以及你们将 Astra 加入其中这件事，这对所有人而言都很好。如果我理解有误，请纠正：你们目前不会将 Dots 的使用量计入套餐限额，对吗？

回　答　者：对。

提问者：这不可能是永久安排吧？这是否只是为了吸引用户而采取的临时措施？

回　答　者：不是，这是永久安排。

提问者：真的吗？

回　答　者：是的。这个话题很有意思。我们准备尝试以一种新的方式为 Dots 定价，让用户不会耗尽使用限额。这需要进一步解释，因为这是一个比较新的想法。

目前，如果你使用 Codex 并耗尽了所有使用限额，之后再要求 Codex 执行更多任务，它就会停止工作，因为限额已经用完。但从产品角度来看，首先，无法继续使用的体验很差；其次，当它是一个持续运行、让你依赖其随时提供支持的智能体时，你可能会告诉它：“持续关注我的航班，并根据交通情况，在合适的时间为我叫一辆 Uber 前往机场。”你可能会把类似任务交给它，并依赖它在未来提供支持。但如果你前一晚编码过多，意外耗尽了限额，导致它无法完成任务，这不是我们希望出现的情况。

因此，我们必须重新思考定价方式，并制定一些基本原则。其中一项原则是，Dots 应当可以 24/7 使用，除非存在滥用等情况，否则不应出现无法 24/7 使用的情形。另一项原则是，既然它可以 24/7 使用，就应当始终快速响应。

我逐渐倾向于采用一种更接近承包商的定价方式。如果一名承包商响应迅速、态度礼貌，就会始终回复你的消息。当你要求其完成工作时，实际完成的工作量会根据你支付的报酬而有所不同，但他始终可以联系。假设他在我们身后完成了这个精美的装置，而你对此有疑问，就可以向他提问。

回　答　者：它不需要按小时收费来回答自己是如何完成任务的，这只是您可以提出的一个问题。我们希望采用这样的定价方式：您的 Dot 24/7 均可使用。您每月支付固定费用，即可使用自己的 Dot。如果希望 Dot 在性能更强的计算机上运行，使用更强大的模型、拥有更快的运行速度或能够并行处理更多工作，也可以每月支付更高的固定费用。

归根结底，您支付的是固定金额，类似于购买互联网服务。Dot 会根据您支付的费用完成不同规模的工作，但始终保持可用。即使接近使用限额，它也可以主动提示：“我已经为您完成了大量工作，因此接下来会开始使用成本效益更高的模型。或者，如果我在夜间处理这项工作，成本会非常低，您是否可以接受？这项工作紧急吗？”它也会对任务是否紧急形成判断。

另一方面，如果您当月完全没有使用 Dot，它可能会向您发送消息：“您还没有充分利用我，以下是我可以为您完成的一些事情。”这些是我们目前对产品设置方式的一些设想。

从长期来看，Dot 的额度将与您的主要 Codex 限额分开，因为我们正在采用一种全新的模式。未来1个月，我们会提供非常宽松的限额，并在建设、衡量和调整这一新模式的过程中，让模型了解自己能够为您完成多少工作，同时确保它始终可用。

提问者：如果您认为人们会使用这项工具大规模购买商品并进行交易，为什么不直接采用抽成模式，对所有经由该工具完成的活动收取少量费用？

回　答　者：对于其他商业模式而言，如果交易是主要用途之一，这种方式可能合理。但正如我所说，我们并不是在押注交易，而是在押注人们使用这项工具完成真正具有雄心的工作。在完成这些工作的过程中，他们未必会购买任何东西。

提问者：谈到您正在进行的这项押注，我自开始测试产品以来，尤其是今天早上的主题演讲之后，一直在思考一个最重要的问题：这对 Chat 意味着什么？目前，ChatGPT 每周拥有 1.2 billion 用户，同时还有 Work 标签页，而 Chat 显然仍然规模庞大。您如何看待这些产品共存？Dot 会成为未来承载所有功能的界面吗？

回　答　者：Chat 肯定会继续存在。对于不了解情况的人来说，Chat 是增长速度最快的消费级助手，目前拥有超过 1.2 billion 用户。我们的智能体产品 Codex 和 Work 拥有 35 million 用户，也在持续增长。现在，我们又推出了 Dot。

在我看来，Chat 是面向所有人的消费级助手。目前我们还有一个名为 Work 的独立产品，实际上应该将它与 Chat 合并，这项工作将会推进。Codex 则是面向开发者的产品。

对于 Dot，我们在一定程度上是在重复 Codex 的发展路径：先将这种前沿能力以谨慎、稳妥且非常强大的方式推出，再探索如何让所有人都能使用这种能力。因此，我们首先将 Dot 作为高端独立产品推出，初期仅面向 Pro 用户。之后，在了解用户的使用方式，并解决安全性和规模化等问题后，我们需要将它推广至 Plus 用户，最终让这些能力覆盖 Free 用户。

要实现对 Free 用户的覆盖，我们实际上需要将这些能力全部融入 Chat，让 Chat 或 ChatGPT 成为一个极其强大的消费级产品。

提问者：但它的能力强大得多。在我看来，它应该成为面向所有人的界面，因为它能够完成更多工作。

回　答　者：是的，Dot 带来的大量经验和成果会逐步融入 Chat。不过，我们不希望要求 1.2 billion 用户改变现有的操作或使用方式，而是希望直接升级他们正在使用的产品。

提问者：所以，您认为这会是一个更加渐进的过程？

提问者：展望未来1年，如果从1年后的时间点来看，您认为 Dot 最有意义的变化会是什么？

回　答　者：我先分享一个故事。最初，我通过一次收购加入 OpenAI。我们开会时，我的部分团队成员和 Greg 都在场。大家都表达了对于双方走到一起的兴奋之情。随后，Greg 问我们创业公司的多团队是否有问题，但大家都有些紧张，没有人提问。我当时是这家公司的 CEO，所以所有人都看着我，希望我提出那个必须要问的问题。

我当时很紧张，最后问道：“2年后，成功会是什么样子？”Greg 回答：“2年是一段极其漫长的时间，这不是一个合适的时间跨度。你应该问的是，2个月后成功会是什么样子。”我当时的反应是，自己可能已经要被解雇了。

提问者：我理解他的观点，行业发展得太快了。可能在6个月前，您也无法想象现在发生的这一切，所以这个问题或许确实不太公平。

回　答　者：如果考虑下一步的发展，我们正在极其谨慎地推动这些能力上线。接下来，我希望开始落实一些此前不准备立即开展的工作。例如，让更多用户使用产品，将用户范围拓展到 Pro 之外；同时，让用户的 Dot 能够与其他人，甚至其他 Dot 进行交流。对于如何推进这些功能，我们必须进行非常周密、谨慎的思考。

我们刚刚发布了一个在我看来相当于重启版的 Codex Cloud。我对此非常兴奋，因为我参与过第1版 Codex Cloud 的开发。它的能力非常强大，用户的 Dot 也可以非常有效地控制本地 Codex。我们还刚刚发布了 Space。目前，这些产品之间的协同体验仍有很大的打磨空间，我希望让它们之间的配合变得非常顺畅。

另一个非常值得关注、但我们此前似乎尚未谈到的方向，是专业型 Dot。这里基本存在2类 Dot。第1类是助手型 Dot，每个人都可以拥有一个作为自身延伸的助手。第2类面向组织。如果一个组织希望进一步自动化某项职能或工作流程，可能并不希望由拥有个人 Dot 的员工来承担这项工作，而是希望对其进行集中控制。

因此，组织可以创建专业型 Dot，使其专门负责某项特定工作，并由 IT 进行集中管理。它们拥有独立身份，与任何个人用户完全分离，可以提升整个团队或整个组织的效率。未来几个月，我非常期待推动专业型 Dot 落地，进入一个由我们、个人助手型 Dot，以及更广泛部署于企业内部的专业型 Dot 共同构成的世界。不过，在这个方向上，我们同样会以非常缓慢、谨慎的方式起步，目前只与少数客户合作。

提问者：最后一个问题，您的 Dot 为您做过最令人震撼的事情是什么？

回　答　者：我听过最令人震撼的案例，来自我们在产品上线前合作的一位工程师。他醒来后发现，自己在 Slack 上收到了大量赞誉和奖励，原因是他在一个缺陷进入生产环境前将其修复了。但这件事并不是他本人完成的，所以他非常困惑。

我对讲述这个案例有所保留，因为这种事情不应该在当事人不知情的情况下发生。因此，我们正在围绕这类情况建立大量安全控制机制。这也是我们进行小规模测试的原因。这个案例发生在早期，当时只有我们的团队在进行测试。

这位工程师此前要求自己的 Dot 持续关注反馈频道。Dot 发现反馈后识别出了一个问题，随后创建了一个 PR，但没有将该 PR 设置为草稿模式。

回　答　者：例如，Dot 应当将 PR 设置为草稿模式，然后设置为自动合并，因为这是那位工程师的个人偏好。Dot 已经识别出了这一点：你总是直接创建 PR，并将其设置为自动合并。随后，其他人需要批准该 PR，Dot 也完成了相应操作。对我而言，这确实是一个非常精彩的时刻。

提问者：希望我们都能经历这样的时刻。谢谢你，Alex。

回　答　者：谢谢，也感谢邀请。

原文转译

Okay, Alex, I want to go deep on dots, but first, I want to just talk about this moment we're in as an industry. It's something I've been thinking about a lot and there's so many new products that are constantly popping up, which is this rise of personal agents. And it feels like it's a combination of a lot of things. The models getting capable enough to really power these experiences, things like browser use, computer use, really taking off, people figuring out the harness. And now you guys have dots, which is the Open AI bet on this form factor. I would be curious to hear you like bigger picture, maybe talk about why this moment is happening now. Totally. And yeah, I agree this is a massive moment. I've I joined Open AI a little over two years ago and I've basically been on a mission to ship dots since I joined and so I'm like thrilled that it's happening. So, you know, recapping quickly, we had chat, right? That was chat was like is very obvious today, but it was not obvious that that would be the the right way for many people to get value from LLMs when we started. Uh the wave after chat was coding agents and then eventually those agents useful for knowledge work. And the big improvement from chat to coding agents was like, hey, that now these agents can do things, right? But there was still this like fundamental problem, which is I think the main problem we're solving with this next era, you know, the third chapter, active intelligence, we call it. Um and that's that even if you have an incredibly powerful coding agent, it's kind of like you have this like incredible principal engineer who refuses to check slack, refuses to check linear and basically only does things when they're told by you. And if you're a power user, you can set up automations and kind of get them going more independently, but for a sort of normal user, that doesn't happen. And so for me, this is happening now because we're finally ready to provide intelligence in a way that's much more intuitive for people, in a way that you don't have to put all the onus on yourself to get value from the product, but it can start proposing to you what it's going to do and how it's going to help. So, that's the problem. And then, you know, we can get more into the reasons, but I think broadly it is the model capabilities are there and I think the maybe I so I agree with you on what you said. Maybe the thing you didn't mention that I think is underrated is there's actually a lot of human change that needs to happen for these products to get adopted. You know, like if you look at like a company or a team adopting coding agents, day zero, when they don't know how to use them and they're not connected to any tools to like day 400, the agents are connected to a bunch of tools, they have access to context. Um people have best practices. I think that's the other major thing we needed, right? Because if you think of a proactive agent, if it doesn't have access to context, it can't actually be proactive in helping you. Um so I could go on, but. Yeah, the connectors and all that stuff being in a place where people are bringing their data into these experiences. Yeah. Yeah, that makes sense. You said you joined uh and it's been your mission to ship dots ever since. Yeah. Yeah. Expand on that a little bit. I mean, were you all envisioning this form factor for this two years ago? I'll just speak for myself here. Um but I had this broad idea that chat was incredibly powerful and AI was going to transform the world and it was really important, like the the mission of OpenAI really resonates with me. That's why I joined, right? Deliver the benefits of AGI to all humanity. And, okay, I'm not necessarily going to be the person training the model, but I did feel with chat that there was so much low- hanging fruit on how to make that model more useful. And it was those two things I mentioned, like let it do things and let me not have to figure out what to ask it to do because, you know, even even today, like I go on Twitter and I see someone talking about all the loops they're running and I feel a little bad about myself personally. I'm like, oh, I'm I'm not an advanced practitioner. I'm not running enough loops. I'm pretty sure you are an advanced practitioner. No, I am, but you know what even I feel that way and I don't know how do you feel about? Oh, oh my gosh, I'm overwhelmed. Every time I open it, I'm like, wow, 10 new things. Yeah, and it's like it's rough, right? Like what product categories exist that the better you get at it, the more aware you are of your own personal shortcomings. Yeah. Maybe like sports hobbies maybe? Like I don't know. That's like it's kind of rough, right? And so broadly I I wanted to figure out how we could solve those things. And it was kind of interesting. We we were working on chat. I in the early days, I was working on the desktop app. Uh we were trying to build that into a contextual assistant. And yeah, the models were not there in certain ways. Well, actually, fun story. I joined OpenAI through an acquisition of a small startup. And we had signed the deal the day before that OpenAI launched like their voice product. I forget what it was called. just voice. You know, that that draw dropping demo. Yeah. Like a few years ago. And we so we signed the deal the night before and then we got on a call with our team, watched that demo live. We didn't know that they were launching voice. It was a draw dropping moment and then we said to the team like, hey, we're joining that company, they just acquired us. Nice. It was wild. Um, and so at the time we thought that like multi-modal progress was going to be it and that's how we were going to have the next wave of capabilities and that was kind of the approach we took. like the desktop app, Chat desktop app would like screenshot your apps and try to do work in it. But it it was really slow. It didn't work super well. And it turns out like coding was actually that next frontier. And so we had a year of progress on coding and I think, you know, with coding, we ended up building a lot of tech for helping agents do more and we built out all these connectors in a more easy way than having the agent like click around on your computer and stuff. We also developed ways to like hoist the agent to the cloud. All all these like base primitives that needed to be in place for us to ship these persistent agents. And now it's funny because we're kind of having a comeback of computer use now, right? Where now the models are so good at coding, but they're and they're also good at using code, using code to control the computer. Like if you get Astra to control the browser or computer, it might actually write code snippets to do it because that's faster than taking screenshots and clicking. Yeah. Um, but yeah, now we're we're in back at this comeback of like, well, the models can do anything that you can do on a computer. This episode is brought to you by Mercury, AI native banking that's loved by more than 300,000 entrepreneurs, including me. Visit mercury.com to learn more. Mercury is a Fintech, not a bank. Check the show notes for details. This episode is also brought to you by Jira by Atlassian, where teams and agents get the context, coordination, and control to move work forward. Try it free at jira.com. That's j.com. Thanks also to Granola, the AI notepad for people in back-to-back meetings. It works everywhere you do and lets you focus on what matters. Try it at granola.ai/sources and use the code sources for three months off. So take me into the last few months building dots. We talked about the buildup of how these things have progressed. When did you guys go, oh, we have to now we're doing this, we're building this. This is the next big swing. If we think about this a little bit abstractly, the key things about dots are first, it is a model that is trained to be persistent and to go after tasks uh, sort of proactively, right? So initially over a long horizon, maybe you could say something like babysit this PR. You know, the model, you didn't tell it exactly how to solve that problem, but it's like figuring it out. Um, and then eventually even more open-ended tasks like stay on top of this feedback channel, right? So this that's one key idea there, persistence. And it's it's probably the most important idea. Some of the other ideas are it being available wherever you are, so you can talk to it in any tool. And it being able to do anything that you can do because it has access to its own computer, not yours. Um, so going back to that first idea of persistence, we've been working on this for actually a really long time, and it's been not like a instantaneous step function improvement in capability, but it's been sort of like the models have been getting better and better at it and the product has also been slowly getting better at it. Um, so for example, slash goal is a fan favorite feature in Codex that enables the model to sort of go after a problem for a really long time. And so, we were shipping things like slash goal, we were shipping internal prototypes of things that enabled you to have agents or threads that would just go for a really long time. And we just started seeing this like really explode across the company, uh, to the point where there was just like a channel of feedback around one of these internal prototypes that was just like constantly active people sharing like all sorts of cool ways that they were like meaningfully accelerating themselves. And so, we were looking at that, and I remember we had a really fun debate, which was, should we ship this prototype that works locally on your computer? So it was it was kind of like slash goal, like it didn't have its own computer. It would just like kind of create this agent and it would go after things. And so we asked ourselves, should we ship this locally on your computer or should we wait to we have a cloud computer, which is a harder thing to build. And should we ship this as just an enhancement to a Codex thread? So it's just like, you're just using Codex. It's just like the the thread can do more. Or should we embody this as an agent that has its own identity, that you can reach in slack, etc, etc. And so we kind of went through this iterative process, shipping with a company, seeing what we saw, like exciting use cases, etc. And we end up deciding, okay, for us internally, we can get a lot of internal acceleration from this local only non-embodied product. But the most intuitive form factor to help everyone benefit, by asking this agent to do really hard tasks and long long tasks would be let's put it in the cloud and let's embody it. Embodying mean like let's give it a name, let's give it an identity, etc. And so we kind of then started a sprint to like get those two things, those two short of tweaks to the form factor built around this base model capability with Astra. I'm curious about the decision to embody it and the identities that you can give it and the customization. Why give that level of control to the user? Totally. So, it's a it's a really good question. And to be completely honest with you, I think we made the right choice, but I also think that we together, like the industry are going to discover the answers to some of these questions. Like, should agents be embodied? Uh, how many should people have? Is it different between consumer and enterprise? Like we're going we have our takes, like I can give you my takes, but we're going to figure that out. I think embodiment though to answer your question, it's a really powerful analogy that helps people understand how to use the product. Um, two main things. First, I think that like really smart, like power users of tools realize like advanced ways they can use tools. But a normal user is going to look at something that's not embody and kind of just ask an agent to do something like now, one time. But the moment that you have this like entity that shows up and like, I don't know, slack, it's just something clicks in people's brains and they start realizing like, oh, I can ask this for things that take days or that aren't continuous work, that uh, you know, maybe it's like stay on top of this project and let me know. And so people start asking it like get start giving it much harder tasks and that was really important to us. We wanted to have like really good tasks. The other thing that is really powerful with embodiment is it helps people understand that you are talking to one context, no matter where you're talking to it, right? So, for example, the way that I work, I when I'm commuting, I'm often on a call with my dot. I spend a lot of my day in slack because I'm on the product team, so I'm I'm like slacking it across many different threads. right? Sometimes I'm forwarding DMs to it, sometimes I'm I'm in threads, and then sometimes I'm in the app talking to it. But no matter where I'm talking to it, it's one context and it knows about all the conversations I've had. And there are a few ways you could try to teach users that. One is embodiment. The other is you could try to like synchronize threads across surfaces, but that to me doesn't really make sense, right? Like if you and I have a conversation now, like live in this room, and then I text you later, it's not like there's going to be a transcript of our conversation in the text. Right. Right? But but you still know it's me because I'm an entity. Right. Well, and it makes sense too when you look at the product evolution of ChachiBT. You guys have been the merge, you guys have been trying to unify work, chat, everything together. But there are still silos. And like even until recently, voice mode didn't have the connectors access that the work and chat tabs did. So, you know, one of my routines is like I take my dogs for walks in the morning and the evening and I'll do work calls and I'll talk to AI and all that stuff. And I've been on the the early uh beta for for uh dot the last few weeks trying it on these walks and like it's amazing to have all that context and my connectors finally in one place together and it's all and and I do think embodyying it makes sense in that context. But I'm also curious just like, yeah, do you think the world we're going towards is everyone has their single agent that's like their personal agent. And that agent then delegates to a bunch of sub agents or people have an agent for different slivers of their life. Like how do you think that that plays out? Yeah. So it's like, The way I kind of think of that question is like, what is the interface that we're exposing to whom? right? And so, to agents, like I'll we'll parking lot that, but like to agents, I think there's a different answer to that question. But to humans, like there's only so many people that I want to remember the names of, right? And that's just because I have bad memory. And now if each of those people have like eight agents and they all have like whimsical names, like, I don't know, what's a sport you like? I I play Ultimate Frisbee. Okay, so like if Are there different kinds of Frisbees? Imagine you had five agents and they're all named different kinds of Frisbee brands. Like how am I going to remember that? And like one of them is for like GTM, like go to market, and one of them is for like if I want to meet you for dinner. You know, and like, it's just, it's hard for me. Maybe it's okay for you, but it's hard for me. And we we see the future of these agents is clearly like people and agents working together to help empower us and advance our lives. Um, but if that comes with a bunch of cognitive load of me knowing what all your agents are called and who they are, it's terrible, right? So our our take on this right now is that we should support people having multiple agents, but two things. First, for a consumer, a normal person, like you probably just want one agent. And it's only like a power user might create multiple agents. We can talk about why. So most people will just have one. and that agent should feel like an extension of them. So, for example, a a decision we've made in product is if you put your agent in Slack or in Teams, it actually is prefixed, the name of it is prefixed with your name. So like my my slack handle is AE. And so my agent, if I give it a name, my I just call mine dot because I, you know, I like the name dot. So my agent is just AE- dot. If you called your agent Alice, your agent would be called AE- Alice. And so this was not something that we thought of and were correct on. This is actually something we discovered as we were building because we accidentally let everyone create many agents with random names. And, you know, we even encourage people to give them fun names, and then no one had any idea what was going on in Slack. And it just became like really difficult. And the OpenAI Slack is already a pretty active place. Yeah. So that's and that's us working together, right? Like you and I aren't in the same slack. Let's say we're like texting or in my like there's no way I'm going to know your agent's name. Right. Right. Um, so, yeah, we that's that's our take there. So, why this interface though where it's kind of one master single thread? Because I think people are used to different chat threads and bouncing around and I think, you know, there's Muse, there's Instinct, there's other products that have this kind of interface that everyone seems to be landing on. But why is this the the interface? Something we believe in and Sam talks about is that the human world is shaped around humans. And so a lot of the tools we have were shaped around us. And so what I find very fun about this is that as soon as you start, say designing software to be embodied or in some future, you know, building robots that are humanoid, you start to get to reuse a lot of really excellent design thinking that has already been done elsewhere in the world. right? So, if we look at consumer, and we look at enterprise, and we look at like how we talk to people, like obviously in both places, we can talk in the room at the same time. We could also message and that's the center of gravity for how we talk to most people. Messaging products feel very different. Like iMessage is what you use in personal life. It's monothreaded per person. And then at work you have Slack or Teams, and that has like really heavy threading primitives. Like it has channels for context separation. Those channels within them have threads with advanced controls. And I think there's a reason that there's been kind of this convergent evolution, like WhatsApp is kind of like iMessage, right? It's kind of like other texting tools. So my take is, um, we can kind of learn from that. So we we decided to make the interface for your dot really simple, like you're just texting with another person. Um, I think over time we're going to create more ways to at work, um segment the context. Actually space and dots, we call it dots and space, it's a kind of a fun name. Those work really well together and so like having different spaces to collaborate with your dot in is a great way to encapsulate different contexts. Well since you mentioned it, can you explain space and kind of how that fits into the product road map? Because that's a big new thing as well. Totally. Yeah, it's massive. and I'm really excited about it. So yeah, maybe I'll go back to that point I made, right? Like there's a lot of really excellent design work that has been done generally by other people. And one of those things is if you're trying to collaborate with someone, there are these these media, right? For it. There's in there's three, maybe four. The three are, the three main ones are live, messaging, and then documents, right? You can if you include slides as documents, right? And they have very different purposes and all of us know intuitively when to reach for which. I mean, sometimes you might disagree with your teammate like, oh, I wish you would have slacked me, you didn't need to send me a doc link. But like generally speaking, we kind of know all know ordering. The fourth is maybe functional tooling. Right? So like you're in salesforce or you're in Figma or something and it's like you're doing a specific workflow. If you're building something that is messaging and you want it to really feel like messaging, you have to start to be disciplined about the form factor, right? So if you compare talking to your dot to to talking to ChatGPT, the dot's form factor has like actual message bubbles. And if you were to put a very long response in one of those message bubbles, it doesn't feel as good as it might feel in a long form generated ChatGPT response, which also may not feel as good as like an actual document, right? And so what we wanted to do is we kind of hard pivoted the design towards messaging. And then you're like, well, I need somewhere to list uh long form content, right? If my dot brainstorms like 12 ways it can help me and it sends me 12 texts, I don't know if I'm thrilled. Right. Right? But if it generates a space for me, like a page in a space with a checklist, I'm actually pretty happy. Yeah. So these things kind of fit well together and allow each to be more opinionated. And so, sorry, this is an incredibly long with answer. I realize. But basically space is a collaboration. I'm like laughing about it. I'm like, wow, you didn't answer his question at all. But yeah, so basically space, I you can cut me off, by the way. It's okay. So space uh is a collaboration workspace that is built to be I wouldn't say agent first, but it's built for sort of equal weight agent and human collaboration. And so there's a lot of really cool things that you can do with that. For example, uh one thing that I do is, you know, I'm on the product team, is often I'll write out a doc and you know, I'm stubbing out content and often like teammates would go do something. So I have to to action that. I have to go ping them. Like I'm like in Google Docs and I'll like write something and then I'll command tab into Slack and I'm like, hey, can you go get this Google Doc link and like fill this thing in? So now what I can do is I can just be tagging my dot continuously in there and be like, hey, flush this out. Hey, pull that data. Hey, go ping this person and ask them if this is done. If it's done, check this box. Um, and you can get into really deep flow with agents. Um, another really cool thing you can do on a page is you can set agent's instructions. It's kind of like an agent.md for a repo except it's on a page. And then an agent can just like keep that doc up to date. And perhaps the third and last thing I'll tell you about it that I that I really like is like, if you look at documents as a format, historically, they have had a very hard constraint, which is that they needed to be optimized for human authoring. Right? Like if I could build you the awesomest document editor in the world, but if it's hard to type in it, you're not going to use it, right? Because because you have to type in it pre- AI. Interestingly, we now have this thing called HTML, which personally I don't find it at least modern HTML and CSS, I don't find to be very friendly for human authoring, but it's much more expressive than just like a plain document format. And agents happen to be very happy in HTML. And so space like naturally integrates like visualizations, HTML visualizations. So, a lot of the the the pages that we have internally to Open AI, like when we're discussing metrics, we'll probably have like a live chart that an agent is keeping up to date that you can click into and ask the agent to customize. Uh or we'll have a prototype. Like the way we'll look at a design decision now is we might have clickable prototypes like literally in the page. Um, so when you start to think like, hey, we, we're building agents and we're going to talk to them in a messaging interface, so we need a sort of corresponding document interface and that document interface can be agent first, there's a a lot of magic kind of comes together. One of the biggest pains I've had running sources has been managing my books. I'm not an accountant and all of the software out there is unintuitive, clunky, and detached from where my transactions actually live until now. Mercury recently launched Mercury books. It's AI powered accounting that works with your Mercury banking and credit card transactions, plus external cards. and payroll systems as well. You can choose between cash and accrual accounting and quickly generate reports for your cash flow, PNL and balance sheet. Like everything Mercury does, the design of Mercury books is super approachable and clean. I finally don't feel overwhelmed when I'm trying to understand the big picture of my business. I love that AI does most of the heavy lifting, including for things like auto categorizing transactions, and that Mercury's command AI agent can handle tasks end to end. You don't need to be paying for separate accounting software anymore. And you can even invite your accountant or CPA to work alongside your Mercury books with you. This doesn't cost extra, and Mercury will even help you find a human accountant if you need one. Visit mercury.com/books to learn more and apply online in minutes. Mercury is a Fintech company, not an FDIC insured bank. Banking services provided through Choice Financial Group and Column NA, members FDIC. AI is only as useful as the context it has. But when that context is scattered across tools, threads, and DMs, your team and your AI agents are flying blind. That's the problem Jira by Atlassian solves. What's the goal tied to your project? What got decided last week in Slack DMs? Atlassian's teamwork graph pulls all of the valuable pieces together from Jira, Confluence, GitHub, Slack and more, so nothing falls through the cracks. You get 44% more accurate results with 48% less token usage. With Jira, you can easily share your work context with the AI agents you already love, like Claude, Cursor, and GitHub Co-pilot. Assign them work directly or connect your tools through MCP. All of this lets you spend less time digging through endless links and messages, chasing down what got decided and by who, and spend more time actually shipping. Learn more at jira.com. That's j.com. I spend a lot of time context switching between meetings, often with no time to process one before the next starts. Thankfully, Granola runs in the background the whole time. It's an easy to use AI notepad for meetings that works everywhere, even on phone calls. I use Granola to recall what was said in a meeting and create helpful summaries. I use it every day to stay on top of what I need to get done with my team. It connects to my email and suggests followups for me to quickly review and send, saving me valuable time. Granola isn't just a core part of my workflow, it's basically my second brain. Try granola at granola.ai/sources and use the promo code sources for three months off. Framer is the AI website builder that powers the sources podcast website at podcast.sources.news. Framer brings AI agents into the same canvas where your website is designed, managed, and published, so you can move faster without giving up your taste or control. I use Framer to make the sources podcast website be the destination for everywhere you can find the show, plus you can also see recent issues of my newsletter. Start building with agents for free today at framer.com/sources for 30% off a framer Pro annual plan. framer.com/sources. Rules and restrictions may apply. What do you think if you were to boil it down sets dot apart from muse, Grockbot, Instinct, this new form factor that everyone's really betting on right now. Two things. First, most capable agent. Second, safest and most trustworthy agent. Those are the main two. We actually, it was really clarifying when we decided that those would be our two. It allowed us to make a lot of like strong decisions in my opinion and you know, you've been in the Alpha and I'm sure you've tested it for things that you were using other products for and noticed where it was good and noticed where we weren't focused on. Yeah, it was very aggressive on permissioning, um, and I think that, you know, that was you guys were ironing out kinks, but I think it was it was very much are you sure you want to make this purchase? Like not being um, I think there's a balance between how how proactive and and how much agency do you want it to actually have? And is that a trust that's earned over time? Is it something you give immediately? Do you do it on a sliding scale based on what the user says they want? I imagine that's pretty hard to build into the product. And I think you guys seem like earlier you were going very heavy on permissioning and maybe you're I'm finding more of that balance right now. Yeah, so the way that I think about it is, okay, you know, we're building the most capable and trustworthy um, agent. We want people to give it really hard tasks and really hard tasks probably come with a lot of responsibility depending on the nature of the task, right? Yeah. We're talking like aligning PRs or evaluating hardware or planning a launch. Um, and so, uh, well, we could talk about why, you know, it's the most capable assistant. But bringing this to to your point about safety, we then decided, okay, we have lots of dreams and ambitions for how this thing will work in the future, but to start, we're going to be conservative. And so, we made trade-offs in terms of capabilities, we made trade-offs in terms of product, and we made trade-offs in terms of rollout to sort of like have this most trustworthy agent. And then we'll slowly widen those over time. So, for instance, um, you know, that for various reasons, you could debate which model you might want to launch with, but we decided to launch with our most capable, but also our most aligned model, which is GPT-6 Astra. Which I want to talk about, but on the safety piece, talk more about that. Yeah. So that's so that's the model side, right? Yeah. Um, next, there are many features that we want and many of our users want. So, for example, once you give your agent its own identity in say Slack or, you know, we were testing email, for example, you immediately want it to email everyone or slack everyone and to be emaiilable by everyone, right? Like that's like an obvious feature we want. We don't we didn't ship with that feature. When you give your agent its own identity in Slack, it only responds when you tag it, unless you explicitly tell it, hey, like listen to other people too. Mhm. Right? This is because we think that we definitely want it to be multiplayer, but we want to be there getting there very carefully, right? Like the moment your agent is answering unsolicited questions from other people, you need to be super thoughtful about what is the boundary of what it can share or not. Yeah. You know, that's a little bit on product. We could talk a lot more about the controls and product. Maybe the last thing I'll say is rollout-wise. Yeah. Very intentionally for us, we're starting with pro, business and enterprise, business premium, that is. And so that is our most AI literate audience. Um, and you know, you you could talk about going much broader, much faster, but for us, we want to do this really carefully, go to that audience, see how things go, tune, etc. and then go to a broader audience. Last thing on accessibility I want to get to, but on the safety side, I think especially when people are reading about hacking and rogue agents and all these things and you and, you know, the Sam and others and I just did the pod with him about that about a month ago, like the alignment stuff you guys are doing on the frontier. But people are rightfully like concerned about, are these agents hacking, are they going to and maybe being reticent to hand over their personal data. How do you guys approach credit cards, uh personal information, that kind of stuff? Is it fully sandboxed? How does it how's the architecture relate to the rest of chat? Yeah, so personally, I'm very happy that there's this conversation just in the market generally about the level of responsibility that people are giving agents. I think it plays well because we are taking that so seriously in this product. One thing I do want to call out, those incidents that we disclosed were done with models that were not intended to be shipped internally, and we're not running in the same level of sandboxing or or or the safeguards that are in the product. Right. Shipped externally. Yeah. So yeah, so those models are very different. You know, like GPT-6 Astra is an incredibly well-aligned model, and then there's many, many layers of of of safety and defense and depth built into the product. So, yeah, like to just to talk through then the architecture and how that works. Uh the way that I would think about it is, you start with the model, very well aligned, could talk to you your off about that. You then run that model in a harness and we are running our model in the Codex harness, which is like a very well-tested harness which we have many evaluations for, including evaluations from a safety perspective on on how that model performs in the harness. We then modified that harness to enable the product to have sort of this persistent agent behavior. Uh, you know, for example, that means things like running it for really long periods of time. It means things like it delegates to sub agents and so forth. So we then actually re- we designed that harness to make sure it's safe and re-evaluated things or tests in that harness. So for example, uh when you have this harness, you have this persistent agent and um, you know, like I said, we were experimenting with email and so we evaluated, hey, if you email it, can you exfill data from it? Um and so we ran those evals, you know, we found that okay, we had a model. but I'll try to hack it, you know, prompt injected and, you know, no no successful prompt injections there. So, you know, that was great. But we so we basically do all all all that all the way at the harness level. Then in the product itself, there's kind of two sides to it, or maybe three. The first is the default behavior and rules that you can customize. The second is how we enforce those rules, and then the third is how we give you visibility on what happened, you know, with all those systems running. So, to talk about the model behavior, we have some very conservative defaults that you noticed. that you noticed. By the way, those are those defaults that you tested early on. We started with a very conservative policy and then we whittled away at it with user feedback. Um so, you know, expect to get much more. It was like accept the terms of service of the retailer before you buy the shoe. Like that kind of thing. Yeah, yeah, yeah. I I I got it. It's buy the shoe. Yeah. Thank you for being an early tester. We really appreciate it. Thanks to you testing uh some folks in the room don't have to deal with all of the same things. Right. Um but you know, basically every time we got feedback like the one you shared, we would like go discuss that. We're like, okay, how do we want the model to behave here? And so we really we really toned down. We call those over confirmations when like it really it's like you didn't need to confirm that. You you would have felt comfortable. Um so, we have this default behavior and the way the model is instructed to behave is that it can, it does proactive research for you over the tools that you've connected it to and it's thinking about how to help you, but it doesn't do anything to help you without uh you confirming first. You've teased, you know, email as a thing that may be coming. When can this be in iMessage, WhatsApp? Is it going to be contained to chat? We we definitely want it everywhere that you work. So, yeah, we're intending or everywhere that you communicate, right? Like, you know, going beyond work to consumer as well. So, we have texting coming soon. Um it's a story for a fun time about uh the journey to enable that. Okay. Um but uh I can't share more now other than that it's coming soon. Okay. Yeah. The web part of this is something that is maybe under discussed as the technology is moving so fast, but, you know, Amazon uh got a lot of headlines for blocking muse uh recently because people were using muse to to buy things. Um then there's companies like Shopify which seem to be leaning in, they're partnering with a bunch of companies on this space and I think everyone's kind of waiting to see what happens. Like, how how do um the the sites and the companies that people use to buy things need to adapt or not to the rise of agents like this. I'd be curious to hear you talk about that and then how you guys are approaching this from a partnerships perspective. Are you just kind of um going in and saying like, we're going to let people do this and then we'll we'll figure out a partnership or are you saying no, like you can't crawl this until we do a partnership. How are you how are you thinking about that? I think we're going to discover together with the ecosystem how this should work, how how like shopping and payments should work. And there are different approaches you could take. You could just go and be a bit of a pirate, yeah. Yeah. There's a way there's a way to do things. Um we are taking a very partnership and ecosystem first approach. You know, a lot of the announcements today at Devday were really all about the ecosystem. And so we're doing the same. So, uh for instance, webbot off is something that we work uh really closely with cloud. they're on. Uh so we actually our agent declares explicitly that it's a bot. Um, and so it's something we're actively thinking about. We're in discussions with many partners for how to enable this, but we don't want to take the approach of just saying like, okay, we're just going to go out and like figure out what happens. We we kind of want to be measured in our in our approach with customers. And we think this works for us. Also, you know, this is a little bit why like we steered towards um going for productive use cases for people at work, because this is where we think like there's a lot of demand for the power of AI there. Um and, you know, there's a lot of really well-aligned incentives for people trying to get things done together. So, we're kind of hoping to land with this like incredibly capable assistant um for people trying to get ambitious tasks done and then broaden uh access and capability from there. The only place I could see incentives maybe not being aligned is are companies that are engagement-based or have huge advertising businesses that rely on humans seeing those ads and now agents are all of a sudden crawling their services and doing things on behalf of humans who never see the ads. And that feels, I mean, a lot of the web is supported by advertising. I don't think anyone in the industry, not just you guys, has the answer yet for how and I'd be curious to even if you're just kind of brainstorming, like, do you have any idea for how this is going to net out? Well, this is why I was saying actually, I was saying on the other side, like if we're using, if we're trying to get things done together, you know, like the example of like the hardware engineer like looking at factory defects, that's where I feel like the all the all that tool chain that that that engineer is using, I think is like very well aligned to having an agent work in there. For sure. But but have you thought about the the advertising piece? Like companies that they they monetize based on, you know, people, human beings looking at it and spending time with it and now their agents are maybe going to go do that. Yeah, I'm not, I'm not sure how it's going to play out, but I think like broadly, like at least my opinion here is that those companies are providing a service, right? And if previously they were monetizing with ads, we either need to make sure that they continue being rewarded for their service with ads or we need to provide some alternate means. Yeah. of compensation for them. I don't think there's any scenario where we, you know, where they don't have that. Yeah. Yeah. Let's talk about pricing and the fact that you all are putting Astra in this, which is um, it's great for everyone. Um, you're not also, correct me if I'm wrong, you're not counting dot usage towards plan limits, is that right? Right. Yeah. That can't be a permanent thing. Is this just a temporary to like get people excited? No, I mean, so that is permanent. Really? But so I, you know, this is really fun to talk about. So, we're going to try pricing for uh for dots in a in a new way where you don't you don't run out of rate limits. Here's what I mean. So we have to unpack this a little bit because it's a bit of a new idea. Like today, if you're using Codex and you consume all your rate limits, and then you try to ask Codex to do more stuff, it'll just stop because Yeah. you're out of rate limits. But just when we think about this from a product perspective, I mean, first of all, it just sucks just to, you know, not be able to use more. But secondly, when this is a persistent agent that you're counting on to have your back, you're telling it things like, hey, you know, I don't know, stay on top of my flight and order me an Uber to the airport when it's time based on the traffic or something. Or like, you know, some task like that that's like, you you're relying on it to have your back in the future. And then you accidentally like code too much the night before and it doesn't do its job. Like that's we don't want that. Yeah. Right? And so, we kind of had to go a little bit to the drawing board and thinking about how pricing should work and come up with some like pretty basic principles. So, one of those principles is that your dot should be available 24/7. And there should be no way for it to not be available 24/7. I mean, barring abuse or something. Another principle should be now that it's available 24/7, it should always respond to you quickly. So I started liking the way that we want to price to it to a bit of a like more like a contractor. Right? Like if you have a contractor who's very responsive and very polite, they will always answer your messages. Now, if you ask them to do work, there's sort of a varied amount of work that they're going to do for you based on like how you're compensating them. But they're always available to you, right? And if they, let's say they, I don't know, they set up this beautiful installation behind us, and then you have a question about it, you can ask them for. that and they don't they don't have to charge you like by the hour to like answer how they did this, right? That's just the question you can ask. So, this is kind of how we want to price. We want your dot is available 24/7. You play a fat, uh flat monthly amount to have access to your dot. Maybe, uh you can pay more, another flat monthly amount if you want like a more powerful dot running on a more powerful computer, uh or with more powerful models or whatever. and uh or running faster or able to do more parallel work. But at the end of the day, you pay this flat amount. It's kind of like buying internet. Sorry, more analogies. As you can tell, I'm still figuring out how to talk about this. Um, and it does sort of a varied amount of work for you based on based on how much you're paying. But it's never not available. And as maybe even as you approach your limits, it can start telling you like, hey, I've I've done a lot of work for you, um, so I'm going to start using uh more cost efficient model or maybe is it okay for you if I do this work overnight? because if I do it overnight, it's incredibly affordable. Like is this urgent? And it'll kind of have a sense of whether or not that's urgent, right? Uh On the other hand, maybe if you haven't used it at all that month, it might text you and say, hey, like, you're not utilizing me fully. Like here are some things I could do for you. Um, so anyways, those are those are some of the the thoughts on how we're going to set this up. The way the way we're doing pricing is it's going to be long-term, it's going to be a separate sort of bucket from your main Codex limit because we're doing this very new thing with it. Uh for the next month, we just have very generous limits. And this is going to be as we build out and sort of measure and and tune this new setup where you have a model that is aware of like how much work it can do for you, but is always available for you. Why not just do like a take rate business if you believe that people will use this to buy things and make transactions at scale, it just take a small vig on all activity that flows through. I mean, I think that might make sense for some other business models where you're betting on like transactions being like one of the main things that you're doing. But like I said, we're we're not really betting on that. Like we're betting on people doing really ambitious work with this tool. Um, and so they're not necessarily buying anything when they're doing that ambitious work. Okay, well, on that note, uh, you know, the bet that you're making, that brings me to probably my biggest question I've been thinking about since I I started testing this, and certainly since the keynote, uh, this morning, is what does this mean for chat? You guys have 1.2 billion weekly users of chatGBT now. Um, and you've got the work tab and chat obviously still is is massive. How do you see these things coexisting? Is dot the future interface of all of it? Chat is definitely here to stay. So just for anyone who's not following, Chat, you know, fastest growing consumer assistant, um, you know, over 1.2 billion users. And then we have our agent products, uh Codex and work, which have 35 million uh users and also growing. And uh, and now we're just launching dot, right? And so, the way that I look at it is like, chat is the is the consumer assistant for everyone. Um, right now we have this different product called work, which really we should just merge with chat. So that that will happen. Codex is a product for developers, so great. And then we have dot, which is us in a way, like the way I think about it is like we're a little bit repeating the Codex playbook of we're going to take this frontier capability and we need to ship it in sort of a careful, conservative and very powerful way and then figure out how to bring that capability to everyone. So we're starting with dots as a sort of like premium standalone product. It's starting with just pro. We need to go get it to plus, you know, after we've like figured out, um, you know, learn learned how everyone's using it, the safety story, the scaling story, all that. And then we eventually need these capabilities to get all the way to free. Uh and I think the way that we get all the way to free is actually we're baking this all into chat and making chat or chat GBT into just like an incredibly powerful consumer. Well, it's so much more capable. I mean, to me this should be the interface for everyone because it can do so much more. Yeah, so yeah. you can expect a lot of the learnings from this to make their way into chat. Okay. But I don't think we want to ask 1.2 billion people to like change what they're doing or how they're using things. We just want it to just be upgraded. So you see it as more of a gradual thing. time. Yeah. When you think about the road map, uh, over the next year for dot, like if we're talking a year from now, what do you think is the most meaningful change? Can I tell you a funny story? Yeah. Uh, and we can get back to the question. Okay. so when I first joined Open AI, it was through this acquisition. And uh, and we had a meeting and and some of my team were in the room. And um, and uh Greg was there. And so everyone, you know, talked about how excited they were that we were all together. And then Greg asked, does anyone have any questions from the multi team, which was our startup. And everyone, no one has any questions. We're all a little nervous. And I was the CEO of this company, so everyone looks at me. It's like, well, you have to ask the mandatory, you know, obligatory question. So I'm like, ah, what am I going to ask? I'm nervous. Uh and so I'm like, okay, in two years, what does success look like? And then Greg, I I always remind him of this, he looks at me and he says, in two years, that's an incredibly long period of time. That's not the right duration to ask about. You should be asking about success in two months. Yeah, yeah, yeah. I was like, oh god, I'm already fired. Yeah. Okay, well, don't fire me. Okay. Yeah, no. No, no, no, it's all good. But so sorry, so, No, but I I get the point, like this, it moves so fast. Like six months ago, you probably couldn't imagine all of this. Yeah. So it is probably an unfair question. So what I can say though is, um, if I think about what's next, we are approaching shipping these capabilities incredibly carefully and next what I would like to do is to start looking at some of the things that we didn't want to do immediately and landing them. So for example, let's get some more users, let's not let's get beyond Pro. Um, also for example, let's enable your dots to talk to other people. And maybe even other dots, right? We need to be super thoughtful and careful about how we approach that. We just shipped uh, basically in my mind, a reboot of Codex Cloud. I'm really excited about it because I worked on the first Codex Cloud. It's super powerful. Your dot also super powerfully can control your local Codex. We just shipped space. All the interplay between those things right now, I think can be really sanded down and made super smooth. Yeah. Um, so I want to do that as well. Um, the other really interesting thing that we haven't talked about, I think yet is specialist thoughts. Yes. Right? And so we have this idea of like, there's basically like two things going on. We have assistant thoughts, that's everyone has an extension of themselves. And then separately, you know, if you're, you're an organization and you have some function or workflow that you would like to have uh, more, like more automated, you may not want that being done by individuals who have their own personal thoughts taking on that work. You may want to actually like control that centrally, right? And so you can create specialist thoughts, which specialize in doing a particular thing and which are centrally managed by IT, which have their own identity, completely separate from any sort of individual user and which are accelerating an entire team or an entire organization. And so I think the other thing uh that I'm really excited about over the upcoming months is bringing specialist thoughts to life. uh and entering this world where it's like we have us, we have our our personal assistant dots and then we have assistant dots much more broadly deployed within enterprise. But that is another place where we're starting like very slow, very careful, working with a handful of customers. Got it. Okay, last question. What's the craziest thing your dot has done for you that you're like, wow, I you it happened and it blew your mind. The craziest story that I've heard, uh, it was like on someone I was working with as as we went up to this, was this engineer woke up and realized that in slack, he had received a bunch of kudos, which is like, you know, props, like awards for having like fixed the bug before it made its way to production. And it wasn't. And the engineer was like, uh, what happened? Uh, By the way, I tell this story with a little bit of reticence because that's actually not something that you would want to happen without the person knowing. And so, you know, we're building a lot of safety controls around that. This is why we do small scale. This is like early on when it was just our team testing it. Uh and yeah, his dot, he had asked his dot to stay on top of the feedback channel and the dot like saw the feedback, um, and then identified an issue and then spun up a PR and uh, you know, didn't set that PR in draft mode. but like, you know, dots should set PRs in draft mode. Uh, and then, uh, set it to auto merge because that was that engineer's personal preference. Um, and then and you know, the dot had figured that out, right? It was like, oh, you always create your PRs directly and you always set them to auto merge. And then someone else had to approve the PR and it did it. So, to me that was that was a really cool, uh, cool moment for sure. Wow. Well knock on wood, uh, we all get to have moments like that. Thank you, Alex. Yeah. Thank you. Sure, thanks for having me. Banking should feel like modern software. Get everything you need in one place. Visit mercury.com to learn more and apply online in minutes. Mercury's a Fintech, not a bank. Check the show notes for details. Granola is the best AI notepad I've tried. It works everywhere, on a video or a phone call, in person, or on an Apple Watch. Try it now at granola.ai/sources and use the promo code sources at checkout for three months off. Jira by Atlassian is where your team and your agents work from the same context. Try it free at jira.com. That's J.com. Framer is the AI native website builder that lets you build faster without giving up control. Visit framer.com/sources for 30% off. Rules and restrictions may apply.