从被动响应到主动智能：个人 Agent 的兴起时刻
Alex，我想深入聊聊 Dots。首先回顾一下行业阶段：个人 Agent 的兴起并非偶然，而是模型能力、浏览器/电脑操作技术以及 Harness（执行框架）成熟共同促成的结果。OpenAI 推出 Dots，正是对这一产品形态的压注。
回顾历史，从最初的聊天交互到后来的编程 Agent，最大的进步在于 Agent 开始“动手做事”。然而，即便拥有强大的编程能力，Agent 仍像一位只肯听指令的首席工程师——如果不主动吩咐，它就不会查看 Slack 或 Linear。普通用户很少配置复杂的自动化流程来赋予其独立性。
因此，当前的核心突破在于主动智能（Proactive Intelligence）。模型能力到位后，产品不再依赖用户费心拆解任务，而是能主动提议、告知计划并协助执行。这背后还有一个常被低估的因素：用户侧的适应与上下文接入。从第 0 天到第 400 天，团队逐渐将 Agent 接入各种工具以获取上下文。若无法获取足够信息，Agent 就无法真正“主动”。Dots 的推出标志着我们终于能以更符合人类直觉的方式提供智能，让 Agent 成为能持续跟进任务的伙伴。
技术演进路径：从多模态探索到云端持续运行
我加入 OpenAI 两年多来，一直渴望推出 Dots。起初我们以为下一波突破来自多模态进步（如语音和屏幕截图操作），但早期桌面应用通过截图控制电脑的方式既慢又效果不佳。真正的转折点来自编程能力的深化。在推进 Coding Agent 的一年中，我们开发了让 Agent 接入工具、获取上下文以及云端运行的基础设施。
有趣的是，操作电脑的路径如今回归了：因为模型擅长编写代码来控制浏览器或系统（比截图点击更快更准），所以“写代码操作电脑”成为新范式。Dots 的核心设计理念基于三点： 1. 持续做事：模型经过训练能长时间跟进任务（如监控 PR 或反馈频道），无需用户全程盯着。 2. 无处不在：在任何工具中都能与之交互。 3. 独立身份与云端电脑：Agent 拥有自己的计算环境，不占用用户本地资源。
开发过程中，我们内部原型显示用户对“长时任务”需求激增。最终决策是将 Agent 部署在云端并赋予独立身份。这解决了本地运行版本难以让所有用户受益的问题，使得 Agent 能处理耗时极长的任务。
独立身份的价值：统一上下文与降低认知负荷
为什么赋予 Agent 独立身份（如名字、头像）？这不仅是个性化，更是一种关键的认知类比。对于普通用户而言，无身份的工具往往只被用于一次性任务；而一旦 Agent 在 Slack 中拥有独立身份，用户便意识到可以将其视为一个长期存在的同事，从而委派需要数天跟进的复杂任务。
独立身份还解决了上下文连续性问题。无论我在通勤时通话、在 Slack 讨论串中@它，还是在应用内对话，Agent 都共享同一份记忆。这类似于人类社交：即使我们面对面聊过天再发短信，你依然知道我是谁，因为我有独立身份。相比在不同界面间同步对话记录这种反直觉的设计，赋予 Agent 人格化身份更符合人类认知习惯。
关于未来形态，我们认为大多数人只需一个主 Agent。如果每个人拥有多个命名各异的子 Agent（如“飞盘-Alice”、“市场-Bob”），将造成巨大的记忆负担。因此，产品策略是支持多 Agent 但默认推荐单一主入口：在 Slack/Teams 中，Agent 名称前缀为用户名（如“Alex-Dot”），使其成为用户本人的数字延伸。这种设计借鉴了人类社交中“一人一身份”的逻辑，确保交互的自然性与一致性。
从聊天到协作：Dots 与 Space 的设计哲学
在构建 Dots 的交互界面时，我们借鉴了个人生活与企业工作中成熟的交流设计思路。在个人场景中，如 iMessage 或 WhatsApp，交互通常是一对一的线性对话；而在企业场景（如 Slack 或 Teams）中，则通过频道和分支讨论来区分不同的交流情境。基于此，Dots 的初始界面被设计得极简，模拟“与人发消息”的体验。然而，随着任务复杂度的提升，单纯的聊天气泡无法承载长篇内容或结构化信息。
因此，我们引入了 Space 这一核心概念。如果 Agent 生成了十二种解决方案或长篇幅的分析，将其塞进聊天气泡会破坏体验。Space 作为一个 协作工作区，允许 Agent 和人以同等地位进行深度协同。例如在文档编辑中，用户可以直接 @ Dot 要求展开内容、调用数据或确认任务状态。这种设计让 Agent 能够持续更新文档，甚至通过页面内的指令（类似 agents.md）自主维护内容。此外，Space 充分利用了 HTML/CSS 的优势，因为 Agent 擅长生成富媒体内容（如动态图表、可交互原型），而传统文档格式难以呈现这些复杂视觉元素，从而实现了比纯文本更丰富的协作体验。
信任构建：安全架构与保守的默认策略
Dots 的核心竞争力在于打造 能力最强 且 最安全、最值得信任 的 Agent。为了平衡高自主性与安全性，我们在产品初期采取了极度保守的策略。例如，在 Slack 中赋予 Agent 独立账号时，默认仅响应用户的 @提及，而非自动回复所有人；在涉及购买或发送邮件等高风险操作时，Agent 会反复确认授权。这种“过度谨慎”虽在早期测试中引发反馈（如买鞋前需同意服务条款），但通过后续迭代，我们减少了不必要的确认步骤，转而建立更清晰的信任边界。
在技术架构上，安全防线分为多层：首先使用对齐良好的底层模型（如 GPT-6 Ultra）；其次运行在经过严格安全评估的 Codex Harness 中，该环境支持长时任务与子 Agent 调度；最后在产品层实施 自动审核机制，由另一个模型监督执行模型的合规性。所有操作均保持可追溯，用户可查看子 Agent 的具体行为。这种层层设防的架构确保了即便面对提示词注入攻击，Agent 也能保持稳健，从而让用户放心地将高责任任务（如合并 PR、硬件评估）交给它处理。
生态协同：从封闭沙箱到开放网络
随着 Agent 能力的普及，其与外部世界的交互方式成为关键议题。面对亚马逊封锁 Muse 等事件，我们选择将 生态合作 置于优先地位，而非采取激进的“先斩后奏”策略。在 DevDay 上公布的多项功能均围绕构建健康的 Agent 生态展开，例如与 Cloudflare 紧密合作实现 网页机器人身份验证。
我们的 Agent 会明确标识其机器属性，以便网站和平台能够识别并制定相应的交互规则。这种合作导向的方法旨在解决 Agent 购物、支付等场景下的信任与兼容性问题，确保技术演进不会破坏现有互联网生态的稳定性。未来，Dots 将逐步扩展到 iMessage、WhatsApp 等个人沟通渠道，但始终遵循“谨慎推进”的原则，先在小范围高信任用户群（如 Pro/Business 企业版）中验证安全性与体验，再向更广泛的大众市场开放。
生态合作与广告模式的博弈
在推进 Agent 抓取网页和执行任务时，OpenAI 采取了“合作优先”而非“先斩后奏”的策略。团队认为，购物、支付及网页机器人身份验证等场景需要与 Cloudflare 等生态伙伴紧密协作，确保 Agent 明确表明机器人身份并遵守各方规则。这种谨慎态度源于对行业利益一致性的考量：大多数工具提供商（如硬件工程师使用的缺陷排查软件）希望 AI 提升效率，利益目标一致；但依赖广告收入的公司面临挑战——当 Agent 替代真人浏览并执行任务时，用户不再直接看到广告。Alex 指出，虽然目前行业尚未完全解决这一矛盾，但 OpenAI 的原则是确保服务提供方获得合理回报（无论是通过广告还是其他补偿机制），避免让依赖流量的公司受损。
我觉得不会出现他们得不到这种回报的情况。
Dot 的订阅制定价与全天候可用性
Dot 采用了独立的永久免费额度机制，不计入 Codex 套餐限额。这一设计旨在解决传统“用完即停”的糟糕体验：如果用户因白天写代码耗尽额度，导致 Agent 无法在夜间执行“监控航班、叫车去机场”等持续任务，将违背 Agent 作为全天候可靠助手的核心定位。新的定价逻辑类似“请人接活”或“办宽带”：用户支付固定月费，Agent 始终在线且响应迅速；工作量的多少取决于付费档位（更强模型、更快速度），但可用性不受额度耗尽影响。当资源紧张时，Agent 会智能降级（如切换至低成本模型或夜间执行）并主动提醒用户，而非直接停止服务。这种模式确保了 Dot 作为长期伴随型助手的稳定性。
我们希望你的 Dot 全天候都能用，你每个月付一笔固定的费用就能使用你的 Dot。
产品矩阵演进与自动化惊喜
面对 ChatGPT 12亿周活用户的庞大基数，OpenAI 规划了清晰的产品分层：ChatGPT 作为面向大众的通用助手将保留并升级，Work 功能将被合并入 Chat；Codex 继续服务开发者；而 Dot 则作为高端前沿能力载体，先向 Pro 用户开放以打磨安全性与规模化经验，未来逐步下放至 Plus 及免费层。Alex 强调 Dot 并非取代 ChatGPT，而是将其能力“注入”ChatGPT，实现无感升级。未来一年重点包括：让 Dot 支持跨用户/跨 Agent 交流、推出由 IT 部门统一管理的“职能型 Dot”（用于组织级自动化），以及优化与 Codex Cloud 和 Space 的协同。一个典型案例展示了其潜力：一位工程师让 Dot 监控反馈频道，Dot 发现 Bug 后自动创建 PR、设为自动合并（基于对工程师习惯的学习），最终在无人干预下修复了生产环境隐患，体现了 Agent 从“被动响应”到主动闭环执行的进化。
Dot 看到反馈后发现了一个问题。就创建了一个 P R，但没有把这个 P R 设成草稿...后来有人批准了这个PR，他就合并了。