一个能力很强的 AI，为什么仍然需要用户不断催促？在 Alexander Embiricos 看来，今天的 Coding Agent 像一位优秀的首席工程师，却不看 Slack、不看任务管理工具，只有被明确交代后才开始工作。下一阶段的产品要解决的，是让 AI 理解上下文、持续跟进任务，主动发现自己可以提供的帮助。
在这期由 Sources 访谈中，OpenAI Dots 产品负责人 Alexander Embiricos 系统解释了他所说的主动智能。他通过协作产品 Multi 被收购加入 OpenAI，参与过桌面应用和早期 Codex Cloud 的开发，也一直在探索如何让模型从回答问题走向持续做事。围绕 Dots 的设计，他谈到了独立身份、跨平台上下文、文档协作、安全权限与定价，也解释了这些能力未来如何逐步进入 ChatGPT。
这场对话里，更值得讨论的是他对 AI 产品的一系列取舍。主要有以下观点：
PA 正在接手一项比执行任务更上游的工作：决定什么值得做。过去，用户负责发现问题、确定目标，AI 负责回答或执行。主动智能开始参与“发现任务”这个环节，也就开始影响用户如何分配注意力。它需要理解的，除了“什么能做”，还有“什么值得现在做”。
主动性的上限取决于 AI 如何理解用户的优先级。现实生活里，人经常有意搁置问题。沿着访谈的逻辑推演，优秀的 PA 需要理解那些没有被明确说出的取舍，否则它越积极，用户需要纠正它的次数就越多。
记忆、推断和授权，是三种不能混为一谈的能力。访谈中，Dot 从工程师的历史习惯推断出他偏好自动合并 PR，随后据此行动。这个案例揭示了 PA 的核心边界：知道用户过去怎么做，可以帮助预测偏好，却不能自动构成这一次行动的许可。越个性化的助手，越需要明确区分这三者。
独立身份让用户更容易信任 PA，也可能让信任增长得比能力更快。 AI 一个名字、让它出现在 Slack 里，用户就开始托付持续数天的工作。这里发生变化的是用户的心理模型，模型本身未必同步变强。因此，身份设计既能释放能力，也可能放大过度委托；产品需要让用户看见它的边界。
“一个人只需要一个 PA”，意味着复杂性会从用户侧转移到系统内部。后台仍然可能有许多模型、工具和子智能体，但用户只面对一个协调者。这个入口必须承担目标理解、任务分派、结果汇总和失败解释。多智能体架构越复杂，前台那个 PA 就越需要具备清晰的责任归属。
跨平台上下文创造了便利，也让信息的使用边界变得更难界定。用户希望自己在语音里说过的话，助手在 Slack 中也能记住。但“能够记住”之后，还有一个更难的问题：某个场景里获得的信息，能否用于另一个场景？PA 需要管理的不只是信息访问权限，还有信息在不同关系、不同场景中的使用权限。
全天候 PA 的商业模式，本质上是在出售一种持续可靠的服务承诺。用户交代它跟进航班后，便会据此安排自己的行为。此时，突然停工的损失已经超出一次回答失败。Embiricos 提出的固定月费、模型切换和夜间执行，实际上是在探索：如何把波动的计算成本，包装成用户能够稳定依赖的服务。
PA 的价值需要用“减少了多少管理负担”来衡量。任务完成数、运行时长、调用次数，都可能随着产品变强而上涨，但用户未必更轻松。如果用户仍需频繁批准、纠错、解释上下文和追查进度，PA 就可能增加一层新的管理工作。真正有意义的进步，是用户可以放心不再盯着多少事情。
为什么Personal Agent在此刻兴起？
Alex Heath：Alex，我想深入聊聊 Dots。不过在那之前，我想先谈谈整个行业正在经历的这个时刻。
最近我一直在思考这件事：新产品不断涌现，Personal Agent正在兴起。这似乎是多种因素共同作用的结果：模型终于足够强，能够支撑这样的体验；浏览器操作、计算机操作能力开始成熟；大家也逐渐摸清了智能体运行框架，也就是 harness，该怎么搭建。
现在你们推出了 Dots，押注的也是这种产品形态。我想先听听你的整体判断：为什么是现在？
Alexander Embiricos：完全同意，这是一个非常重要的时刻。我两年多前加入 OpenAI，从加入开始，我基本上就一直想把 Dots 这样的产品做出来。所以能走到今天，我特别兴奋。
简单回顾一下，最早是聊天。今天看来，对话是理所当然的交互方式，但在最初，并没有那么显然：普通人究竟该通过什么方式，从大语言模型中获得价值？
聊天之后的一波是编程智能体，随后这些智能体又逐渐拓展到知识工作。从聊天到编程智能体，最大的进步是：它们终于能动手做事了。
但仍然有一个根本问题，而这正是我们希望在下一个阶段解决的。
从聊天走向“主动智能”Alexander Embiricos：我们把这个第三阶段称为“主动智能”，active intelligence。
即便你拥有一个能力极强的编程智能体，它也有点像一位非常出色的首席工程师，却拒绝看 Slack，拒绝看 Linear，基本上只有你明确吩咐了，它才肯做事。
如果你是资深用户，可以自己设置自动化，让它更独立地运行起来。但对普通用户来说，这通常不会发生。
所以我认为，之所以是现在，是因为我们终于有条件以一种更符合直觉的方式提供智能。用户不必独自承担“怎么才能让这个产品有用”的全部责任，产品可以开始主动提出：我能做什么、我可以怎样帮助你。
这就是我们想解决的问题。至于为什么现在能做，当然还可以展开，但总体来说，模型能力已经到了。
你刚才提到的因素，我都同意。不过还有一点常常被低估：要让这些产品真正被采用，人本身也需要发生很多变化。
比如一个公司或团队开始使用编程智能体，第一天可能既不知道怎么用，也没有接入任何工具。到了第 400 天，智能体已经连上很多工具，能够获取上下文，团队也逐渐形成了自己的使用方法。
这也是我们一直在等待的重要条件。一个主动型智能体，如果拿不到上下文，就不可能真正主动地帮助你。
所以我还可以继续讲，不过大致就是这样。
Alex Heath：对，连接器之类的能力，让人们可以把自己的数据带进这些产品体验里。明白了。
加入 OpenAI 之后，他一直想解决什么？Alex Heath：你说，从加入 OpenAI 开始，你就一直想把 Dots 做出来。能展开讲讲吗？你们很早就在构想这样的产品形态了吗？
Alexander Embiricos：我只能代表自己说。我当时觉得，聊天是一件非常重要的事，而 OpenAI 的使命也让我很有共鸣。这就是我加入的原因：让全人类受益于 AGI。
我不一定会是那个亲自训练模型的人，但我想解决刚才提到的两个问题：让 AI 能够做事，以及不必总由我来想，它到底应该做什么。
因为直到今天，我打开 Twitter，看到有人讲自己同时跑着多少个循环任务，心里还是会有点挫败：是不是我还不够熟练？是不是我跑的任务还不够多？
Alex Heath：我很确定，你已经是资深用户了。
Alexander Embiricos：是，但连我也会这么想。我不知道你是什么感觉。
Alex Heath：天啊，我已经应接不暇了。每次打开它，都觉得：怎么又多了十个新东西？
Alexander Embiricos：对，这种感觉挺难受的。你还能想到哪种产品，是你用得越熟练，就越能意识到自己还有多少不足？也许运动或者某些爱好算吧。
总之，我想弄清楚，该怎么解决这些问题。
当时我们在做 Chat。早期我参与桌面应用的开发，想把它做成一个能够理解上下文的助手。但在一些方面，模型还没准备好。
说起来有个挺有意思的故事。我是通过一家小创业公司被收购加入 OpenAI 的。我们签完协议的第二天，OpenAI 就发布了那个语音产品。
我忘了当时叫什么，反正就是语音。你应该记得，几年前那个让人目瞪口呆的演示。
我们前一天晚上刚签好协议，第二天就和团队连线，一起看了直播。我们事先并不知道他们要发布语音功能。看完大家都惊呆了，然后我们告诉团队：“我们要加入这家公司了，他们刚刚收购了我们。”那一刻很不可思议。
当时我们以为，多模态会带来下一波能力跃迁。因此，我们采取的路线是把 Chat 带到桌面应用里，通过截取其他应用的画面，尝试在里面完成工作。
但它很慢，效果也不太好。后来证明，真正率先打开下一个边界的是编程。于是，我们围绕编程推进了大约一年。
Dots 的基础是怎样搭起来的？Alexander Embiricos：在做 Coding Agent 的过程中，我们最终积累了很多技术，让智能体能够完成更多事情。
我们做出了各种连接器，相比让智能体在你的电脑上到处点击，它们提供了一种更容易接入工具的方式。我们也摸索出了把智能体迁到云端运行的方法。
这些都是发布持久运行智能体之前，必须具备的基础能力。
有意思的是，现在计算机操作能力又回来了。模型已经很擅长编程，也擅长通过代码控制电脑。比如让 Astra 操作浏览器或计算机，它可能会直接写一小段代码，因为这比不断截图、点击更快。
所以我们又回到了那个方向：模型能够完成你在电脑上能完成的各种事情。
Dots 能做什么？Alex Heath：聊聊过去几个月开发 Dots 的过程吧。前面我们讲了技术是怎么一步步发展过来的。那么，你们是什么时候决定：“就是现在，我们要做这个产品，这会是下一次重要押注”的？
Alexander Embiricos：稍微抽象一点说，Dots 有几个关键特征。
首先，模型经过训练，能够持续运行，主动推进任务。最初，你可以给它一个持续时间比较长的目标，比如：“帮我持续盯着这个 PR。”你并没有详细说明每一步该怎么做，但模型会自己想办法推进。
之后，任务还能变得更加开放，比如：“持续关注这个反馈频道。”
这就是第一个核心概念：持续性。它大概也是最重要的一个。
另外几个概念是：无论你在哪里，它都能被找到，你可以在任何工具里和它交流；它也能够完成你能做的事情。
因为它拥有自己的电脑，而不是占用你的电脑。
回到“持续性”，我们其实已经为此研究了一段时间。这不是能力在某一天突然跳了一级，而是模型逐渐变得更擅长，产品也在逐步完善。
比如，Codex 里很受欢迎的 /goal 功能，就能让模型围绕一个问题长时间持续工作。
我们一边发布 /goal 这样的能力，一边在内部推出各种原型，让智能体或某个任务线程能够运行很长时间。
后来我们发现，这些东西在公司内部迅速流行起来。其中一个内部原型有专门的反馈频道，里面几乎一直有人在发消息，分享自己如何借助它明显提高了工作效率。
当时我们有过一次很有意思的讨论：要不要先发布这个在本地电脑上运行的原型？
它有点像 /goal，还没有自己的电脑，但你可以创建一个智能体，让它持续推进任务。那么，我们是先发布本地版本，还是等到把云端电脑做好再发布？后者显然更难。
另一个问题是：要不要把它仅仅作为 Codex 任务线程的一次增强？用户还是在使用 Codex，只不过线程能做更多事。
还是应该让它成为一个有独立身份的智能体，让你能在 Slack 等地方找到它？
我们就在内部不断发布、观察，看看哪些用例最让人兴奋。
最后的结论是：对内部用户来说，这个只能在本地运行、没有独立身份的产品，已经能大幅提升效率。但如果我们希望让每个人都能受益，让他们自然地把困难、耗时很长的任务交给智能体，就需要一种更直观的产品形态。
所以，我们决定把它放到云端，并赋予它一个独立身份：给它名字，让它成为一个你可以持续联系的对象。
随后，我们围绕 Astra 提供的基础模型能力，展开了一轮小规模冲刺，把云端运行和独立身份这两个产品形态上的变化做出来。
为什么要给智能体一个独立身份？Alex Heath：我很好奇，你们为什么决定赋予它独立身份，并让用户自定义名字和其他设置？为什么把这些控制权交给用户？
Alexander Embiricos：这是个很好的问题。坦白说，我认为我们做了正确的选择。但我也认为，有些问题需要整个行业共同探索：智能体应不应该有独立身份？一个人应该拥有几个？消费场景和企业场景会不会不同？
我们有自己的判断，我也可以分享，但最终还是要在实践中找到答案。
回到你的问题，赋予智能体独立身份，是一种非常有力的类比，可以帮助人理解该怎样使用它，主要体现在两个方面。
第一，特别聪明、熟练的用户，能够自己发现工具的高级用法。
但对普通用户来说，如果面前只是一个没有独立身份的工具，他们往往只会交给它一个当下、一次性的任务。
一旦它以一个独立对象的形式出现在 Slack 里，人们脑子里就像有什么东西接上了。他们会意识到：“原来我可以让它做一件需要几天的事，或者一件不用连续操作、但需要持续跟进的事。”比如：“持续关注这个产品，有情况就告诉我。”
于是，大家开始交给它难得多的任务。这对我们很重要，我们希望它能接到真正有价值的任务。
第二，独立身份还能帮助人们理解另一件事。
无论你在哪里和它交流，你面对的都是同一个上下文。
比如，我通勤时常常会和自己的 Dot 通话。我在产品团队工作，一天里很多时间都在 Slack，所以也会在不同的线程里和它交流。有时转发私信给它，有时在讨论线程里找它，也有时直接在应用里和它说话。
但无论通过哪个入口，它都拥有同一份上下文，知道我之前和它说过什么。
你可以尝试用几种方式让用户理解这一点。一种是给它独立身份；另一种是在不同界面之间同步对话线程。但后者对我来说，不太符合直觉。
比如，你和我现在坐在这个房间里聊了一会儿，晚些时候我给你发短信，短信里并不会自动出现我们刚才的聊天记录。但你仍然知道，对面还是我，因为我是同一个人。
Alex Heath：从 ChatGPT 的产品演进来看，这也说得通。你们一直在试着把 Work、Chat 等体验整合起来，但它们之间仍然有隔阂。
直到不久前，语音模式还不能像 Work 和 Chat 标签页那样访问连接器。
我有个习惯，早晚遛狗时会打工作电话，也会和 AI 聊天。过去几周，我参加了 Dot 的早期测试，也一直在遛狗时试用它。现在所有上下文终于和连接器汇集到同一个地方，感觉非常好。
在这种情况下，我确实觉得，给它一个独立身份是合理的。
但我也很好奇，我们最终会走向怎样的世界？每个人拥有一个Personal Agent，由它把任务分派给一群子智能体；还是针对生活的不同部分，各自拥有不同的智能体？你怎么看？
一个人需要一个智能体，还是很多个？Alexander Embiricos：我看这个问题的方式是：我们要向谁提供怎样的交互界面？
如果面向的是智能体，答案可能不同，这个可以先放一边。但如果面向的是人，我愿意记住的名字就那么多，何况我的记性也不好。
如果每个人又都有八个智能体，还都起着各种奇奇怪怪的名字，那会怎样？比如，你喜欢什么运动？
“我打极限飞盘。”
“那假设你有五个智能体，分别用不同的飞盘品牌命名，我怎么记得住？其中一个负责 GTM，也就是市场推广；另一个负责……”
比如，我要约你吃晚饭，又该找哪一个？这对我来说很麻烦。也许你觉得没问题，但我会很吃力。
我们对未来的想象很明确：人和智能体共同工作，帮助我们做更多事，让生活变得更好。但如果前提是我要记住你所有智能体叫什么、分别是谁，这种额外的认知负担就很糟糕。
所以，我们目前的判断是，产品应该支持一个人拥有多个智能体，但有两点很重要。
第一，对普通消费者来说，大概只需要一个。可能只有资深用户才会创建多个，至于为什么，可以另聊。
大多数人只会拥有一个智能体，而这个智能体应该像是他本人的延伸。
比如我们做了一个产品决定：如果你把智能体接入 Slack 或 Teams，它的名字前面会加上你的名字。
我的 Slack 名字是 AE。我给自己的智能体起名叫 Dot，因为我就喜欢这个名字，所以它会显示为 AE-dot。假设把它叫作 Alice，就会显示为 AE-Alice。
这不是我们一开始就想对了，而是在开发过程中发现的。最早我们允许大家创建很多智能体，还鼓励大家随意起一些有趣的名字。
结果，Slack 里没人搞得清楚谁是谁。事情一下就变得很复杂，而 OpenAI 的 Slack 本来就已经很活跃了。
这还只是我们在同一个工作空间里协作的情况。如果你我不在同一个 Slack，而是通过短信联系，我就更不可能记住你的智能体叫什么了。
所以，这就是我们目前的判断。
Alex Heath：那为什么要采用这种界面，把所有内容都放在一个主要的对话线程里？大家其实已经习惯在不同聊天线程之间切换了。
Muse、Instinct 等产品似乎也在采用类似设计，大家都在走向这个方向。为什么是这种交互界面？
Alexander Embiricos：我们有一个很相信的观点，Sam 也经常提：人类世界是围绕人类塑造的，因此我们拥有的大量工具，也是围绕人的习惯设计的。
我觉得有意思的是，当你开始设计一个有独立身份的软件，或者未来开始制造人形机器人，就可以复用现实世界里已经积累的大量优秀设计经验。
看看消费场景和企业场景，再看看人们怎样交流：无论在哪种场景，我们既可以在同一个房间里当面说话，也可以发消息。
发消息已经是我们与大多数人交流的主要方式。不过，不同消息产品的结构很不一样。
个人生活里，你可能用 iMessage，和每个人基本就是一条对话线程。工作中，你用 Slack 或 Teams，它们有很强的线程结构：用频道区分上下文，频道里又有带各种控制功能的讨论线程。
这些产品会逐渐演化出相似的形态，是有原因的。WhatsApp 和 iMessage 就很相似，也和其他短信工具很接近。
我觉得，我们可以从中学习。因此，我们决定把 Dot 的界面做得很简单。
就像你在给另一个人发消息一样。
随着时间推移，我们会提供更多方法，让用户在工作中区分不同上下文。实际上，Space 和 Dots 就很适合一起使用，我们把它叫作“Dots in Space”，名字还挺有意思。
你可以在不同 Space 里和 Dot 协作，这也是把不同上下文分别组织起来的一种好方法。
Space：人与智能体怎样共同工作？Alex Heath：既然提到了，能不能解释一下 Space 是什么，以及它在整个产品路线图里的位置？这也是一项重要的新产品。
Alexander Embiricos：当然。它非常重要，我也特别兴奋。
还是回到刚才那个观点：其他人其实已经完成了大量优秀的设计。比如，当你要与某个人协作时，人们已经形成了几种不同的沟通载体。
主要有三种，也许可以算四种。三种主要方式是：实时交流、消息，以及文档。如果把幻灯片也算作文档的话，就是这样。
它们的用途非常不同，但我们大多凭直觉就知道该选哪一种。当然，有时也会和同事意见不一致：“这事发条 Slack 消息就行了，没必要专门给我一个文档链接。”但总体上，我们知道自己在做什么。
第四种可能是专门的业务工具。比如你在 Salesforce 或 Figma 里完成某个特定工作流程。
如果你正在做一款消息产品，希望它真的像消息，那么就必须对产品形态保持克制。
比如，和 Dot 聊天与和 ChatGPT 聊天相比，Dot 的界面用的是真正的消息气泡。如果把很长的回答塞进一个气泡里，体验就不如 ChatGPT 那种长篇回答；而后者，又未必比得上一份真正的文档。
因此，我们把设计明确转向消息形态。随后就会发现：长内容总得有个地方放。
假如我的 Dot 想出了十二种帮助我的方式，然后连发十二条消息，我未必会高兴。但如果它为我生成一个 Space，在里面建一页清单，我就会很满意。
这两种形态相互配合，各自也就能更加明确地坚持自己的设计方向。
抱歉，我解释了这么久，结果好像还没回答你的问题。我脑子里已经在提醒自己：“你还没说 Space 到底是什么。”总之，Space 是一个协作……你随时可以打断我。
Space 是一个协作工作空间。我不会说它是“智能体优先”，更准确地说，它是为了让智能体和人以同等重要的地位协作而设计的。
在这里可以做很多有意思的事。比如，我在产品团队工作，经常会先起草一份文档，把内容框架搭起来，然后需要同事帮忙补充。
以前，我得专门去找他们：在 Google Docs 里写好一段，再切到 Slack，说：“你能打开这份 Google 文档，把这一块补一下吗？”
现在，我可以直接在文档里不断 @ 我的 Dot：“把这里展开。”
“把这组数据拉过来。”“去问问这个人，事情做完没有。如果做完了，就把这个勾选框打上勾。”
你可以和智能体进入一种很深入、很连贯的工作状态。
另一个有意思的功能是，你可以给页面设置智能体指令，有点像代码仓库里的 agents.md，只不过放在页面上。这样，智能体就可以持续维护这份文档。
第三点，也是我特别喜欢的一点是：文档这种格式，过去一直受到一个很强的约束，那就是必须方便人类亲自编写。
就算我给你做出世界上最棒的文档编辑器，如果在里面打字很费劲——你还是不会用。因为在 AI 出现之前，内容总得靠人自己输入。
有意思的是，现在有 HTML。至少对我来说，现代 HTML 和 CSS 并不适合人直接手写，但它们的表达能力远远超过普通文档格式。而智能体恰好很擅长写 HTML。
因此，Space 天然集成了可视化，包括 HTML 可视化。
在 OpenAI 内部，很多讨论指标的页面，会直接放一张由智能体持续更新的动态图表。你可以点进去，让智能体按你的要求修改。
我们也会放原型。现在讨论一个设计决策时，可能直接把可点击的原型放在页面里。
所以，当你开始这样思考：“我们在开发智能体，会通过消息界面和它们交流，那么就需要一个与之对应的文档界面，而这个文档界面可以围绕智能体的能力来设计。”很多奇妙的体验就会自然结合起来。
Alex Heath：如果用最简单的话概括，Dot 和 Muse、Grok Bot、Instinct 有什么不同？大家现在似乎都在押注这种新形态。
Alexander Embiricos：两件事。第一，能力最强的智能体。第二，最安全、最值得信任的智能体。
这就是两个核心方向。决定把它们作为目标之后，我们反而想清楚了很多事，也能更明确地做出一些重要取舍。
你参加过 Alpha 测试，应该也用它尝试过一些此前交给其他产品的任务，知道它在哪些方面表现好，哪些方面还不够。
Alex Heath：它在权限确认上特别谨慎。我知道你们还在调试，但它会不断问：“你确定要购买吗？”
这里似乎需要找一个平衡：你希望它多主动？希望给它多大行动权限？这种信任应该随着使用逐渐建立，还是一开始就可以直接授予？能不能根据用户表达的意愿，设置不同程度的自主性？
我想，把这些东西真正做进产品里一定很难。你们早期明显更偏向频繁确认，现在似乎正在寻找更合适的平衡。
Alexander Embiricos：我的思路是：我们在做能力最强、最值得信任的智能体，希望人们把真正困难的任务交给它。而困难的任务，往往也意味着重大的责任，具体取决于任务性质。比如，合并 PR、评估硬件，或者筹划一次产品发布。
我们可以另聊为什么它会是能力最强的助手。先回到你关心的安全问题：我们对它的未来有很多期待，但起步时决定采取保守做法。
安全、权限与企业控制Alexander Embiricos：为了让它成为最值得信任的智能体，我们在能力、产品设计和发布范围上都做了取舍，之后再逐步放开。
比如，出于不同考虑，人们可能对首发该搭载哪个模型有不同意见。我们决定使用能力最强、同时也是对齐表现最好的模型，也就是 GPT-6 Astra。
Alex Heath：模型我也想聊。不过先继续讲讲安全。
Alexander Embiricos：刚才是模型层面。接下来是产品功能。
有很多功能，我们想要，用户也想要。比如，一旦你在 Slack 里给智能体设置了独立身份，或者像我们之前测试的那样，为它开通邮件，你马上就会希望它能给所有人发邮件、发 Slack 消息，也能接收所有人的邮件。这是很自然的需求。
但首发时我们没有开放这些能力。在 Slack 里给智能体设置独立身份后，默认只有你 @ 它时，它才会回应，除非你明确告诉它：“也听取其他人的请求。”
我们确实希望它能够参与多人协作，但必须非常谨慎地推进。一旦你的智能体开始回答其他人主动发来的问题——
就必须认真界定：什么可以分享，什么不能分享。
这是产品层面的一部分，我们还可以讲很多具体控制措施。最后说说发布范围。
我们有意从 Pro、Business 和 Enterprise 用户开始，Business 这里指 Business Premium。这些是对 AI 理解最深的一批用户。
当然，我们可以选择更快、更广地开放。但我们的做法是，先认真服务好这些人，观察使用情况，持续调整，再逐步覆盖更广泛的用户。
Alex Heath：扩大可及性的问题，我稍后还想问。但在安全方面，大家看到了模型入侵、失控智能体等报道，自然会担心。
大约一个月前，我和 Sam 等人录过一期节目，聊你们在前沿模型上的对齐工作。人们会担忧：这些智能体会不会实施入侵？也会犹豫，要不要把自己的个人数据交给它们。
信用卡、个人信息等敏感内容，你们怎么处理？它们是在完全隔离的沙箱里吗？这套架构和 Chat 的其他部分是什么关系？
Alexander Embiricos：我个人很高兴，整个行业都在讨论：我们究竟应该把多大的责任交给智能体。因为我们在这个产品上，非常认真地对待这个问题。
有一点需要说明：我们此前披露的那些事件，涉及的是并不打算对外发布的模型，也没有运行在与实际产品同等级别的沙箱和安全保障之下。
那些模型和实际产品中的模型很不一样。GPT-6 Astra 的对齐表现很好，产品里也构建了许多层安全机制，形成纵深防御。
如果逐层解释架构，可以这样理解：最底层先有一个对齐表现很好的模型，这方面可以和详细聊。
然后，模型会在一个运行框架里执行。我们使用的是 Codex 的运行框架，它经过了大量测试，也有很多评估，包括模型在这套框架中的安全表现。
在此基础上，我们又修改了运行框架，让它支持持久型智能体的行为。比如长时间运行，把任务分派给子智能体等。
做了这些改动之后，我们又针对新的运行框架重新设计安全措施、重新评估和测试。
举个例子，我们当时在测试邮件能力，于是就评估：如果有人给这个持久型智能体发邮件，能不能从它那里窃取数据？
我们让另一个模型尝试攻击它、实施提示注入。在那次评估中，没有出现成功的提示注入。这当然很好。
这些都是在运行框架这一层完成的。
再往上，到产品本身，大致有两方面，也可以说三方面。第一是默认行为，以及你可以自定义的规则；第二是我们如何确保这些规则得到执行。
第三是，当这一整套系统运行起来之后，我们怎样让你看清楚到底发生了什么。
先说行为模式。你已经体验过，我们的默认设置非常保守。你早期测试时，我们采用了一套特别谨慎的策略，之后根据用户反馈，一点点去掉其中不必要的部分。所以，这方面还会继续改善。
Alex Heath：比如买双鞋之前，还要问我是否接受零售商的服务条款。就是这种情况。我当然接受，买鞋就好了。
Alexander Embiricos：我们很感谢这些反馈。其他测试用户也遇到了类似情况。
每次收到你这样的反馈，我们就会重新讨论：模型在这个场景中应该怎么做？
我们已经减少了很多这类“过度确认”——就是那些根本没必要再次征求同意、用户本来就能接受的情况。
目前的默认行为是：模型会主动研究你已经连接的工具里的信息，思考怎样帮助你，但在得到你的确认之前，不会直接采取行动。
比如，发现你的日历有冲突，它不会直接移动会议，而会说：“这里有个时间冲突，要不要我调整？”
又比如，有人问了你一个问题，而它因为掌握上下文，已经知道答案。它不会直接替你发送，而是先问你，要不要把答案发出去。
你可以进一步告诉它：“以后如果我在休假，对方又是同事，你可以直接告诉他我在休假。”
另外还有一层自定义规则，你可以在界面里查看和设置。
以上这些，都是通过训练模型遵循指令来实现的。但我们还会再加一层：如果模型没有遵守指令，该怎么办？
我们有一层叫作 Auto Review，也就是自动审查。它是另一个模型，会观察、监督正在执行任务的模型。
这一层知道你的规则、自定义指令等，负责进一步检查执行是否符合要求。
这就是控制部分。最后是可审计性：无论是你在产品里做的事，还是模型做的事，你都可以查看它运行了哪些子智能体，以及这些子智能体究竟在做什么。
Alex Heath：你已经暗示，邮件功能可能会推出。那什么时候能接入 iMessage、WhatsApp？还是说，它会一直局限在 Chat 里？
Alexander Embiricos：我们当然希望，它能出现在你工作的所有地方。
更准确地说，是你交流的所有地方。我们也希望从工作场景走向消费者场景。
所以，短信功能很快会来。为了实现它，我们经历了一段很有意思的过程，以后有机会可以讲讲。现在能透露的只有：快了。
智能体如何进入现有互联网生态？Alex Heath：随着技术快速发展，互联网这一层的变化似乎还没有被充分讨论。
最近，亚马逊封锁 Muse 的事引发了很多关注，因为人们在用 Muse 购物。另一方面，Shopify 这样的公司似乎很积极，正在和这个领域的多家公司合作。
大家似乎都在等，想看看事情会怎么发展。面对这类智能体的兴起，那些供人们浏览、购物的网站和公司，应该怎么适应？或者到底需不需要适应？
我也想听听你们在合作伙伴方面的策略。
你们会先让用户使用这些能力，再考虑怎么谈合作？还是说，只有达成合作之后，才能访问相应网站？你们怎么考虑？
Alexander Embiricos：我认为，我们需要和整个生态一起摸索，弄清楚购物、支付等事情应该怎样运作。
有不同的路线可选。你当然可以采取一种更像“海盗”的做法，先闯进去再说。但我们的路线非常强调合作伙伴和生态。
今天 DevDay 的很多发布，核心其实都是生态，我们在这里也是一样。
比如，我们与 Cloudflare 密切合作推进 Web Bot Auth。我们的智能体会明确声明，自己是一个机器人。
我们一直在认真思考这些问题，也在和许多合作伙伴讨论怎样开放这些能力。
我们不想采取那种“先冲出去，看看会发生什么”的做法，而希望在与客户合作时保持分寸。我们认为，这条路线适合我们。
这也部分解释了，为什么我们更偏向从人们工作中的生产力场景入手。那里对 AI 能力有很强的需求，而大家共同把事情做成的利益也比较一致。
所以，我们希望先为那些想完成有挑战性任务的人，提供一个能力极强的助手，再逐步扩大使用范围和能力边界。
Alex Heath：我能想到一个利益可能不一致的地方：那些依赖用户参与度，或者拥有庞大广告业务的公司。
它们的商业模式依靠人类看到广告。现在，智能体突然开始浏览它们的服务，替人完成操作，而背后的人可能根本没看到广告。
互联网很大一部分是靠广告支撑的。我觉得，目前行业里还没人真正回答了这个问题，也不只是你们。
哪怕只是初步想法也好，你觉得最后会怎么发展？
Alexander Embiricos：我刚才说的，其实是另一类场景。比如，我们在共同完成某项工作，硬件工程师正在检查工厂的生产缺陷，这时候他使用的整套工具链，与让智能体参与其中的目标，是非常一致的。
Alex Heath：那广告这部分呢？有些公司的收入来自人们观看内容、花时间停留。现在，用户可能把这些事情交给自己的智能体。
Alexander Embiricos：我还不确定最后会怎样。但总体上，至少我的看法是，这些公司确实在提供服务。
如果过去它们通过广告变现，我们就需要确保它们仍然能通过广告获得回报，或者找到其他补偿方式。
我不认为存在一种合理的局面，是它们提供了服务，却得不到任何回报。
一个全天在线的智能体，该怎么定价？Alex Heath：来聊聊定价。你们给它搭载了 Astra，对用户来说当然很好。如果我没理解错，Dot 的使用量也不会计入原有套餐额度，对吗？
Alexander Embiricos：对。
Alex Heath：但这不可能永久持续吧？只是为了让大家先兴奋起来，临时这样做吗？
Alexander Embiricos：不是，我们打算长期这样做。
这个话题很有意思。我们准备尝试一种新的定价方式：你不会遇到“额度用尽，产品停止服务”的情况。
这需要解释一下，因为是个相对新的想法。
如果你用完了额度，再让 Codex 做更多工作，它就会停下来，因为你已经没有可用额度了。
但从产品角度看，首先，不能继续使用本身就很糟糕。其次，如果这是一个持久运行、你指望它帮你兜底的智能体，问题就更大了。
比如你说：“帮我盯着航班，根据路况，在合适的时候替我叫辆 Uber 去机场。”
你是在依赖它未来替你照看这件事。结果前一天晚上，你不小心写了太多代码，第二天它就不干活了。我们不希望这样。
所以，我们必须重新思考定价方式，先确定一些基本原则。
其中一条是：你的 Dot 应该全天候可用，不应因为普通的使用额度问题，就不再提供全天候服务。
当然，滥用之类的情况除外。
另一条原则是，既然它全天在线，就应该始终能够迅速回应你。
所以，我开始把我们想要的定价方式，类比成雇用一位承包服务人员。他回应及时、态度很好，你给他发消息，他总会回复。
但当你让他实际完成工作时，他为你投入多少工作量，就取决于你付多少钱。
无论如何，他都能联系得上。比如，假设我们身后的布景是他搭建的，后来你想问问是怎么做的，他不必每回答一个问题，都再按小时收费。
这大致就是我们希望采用的方式。
你的 Dot 全天候可用，你每个月支付一笔固定费用。如果你希望它更强，可以选择支付更高的固定月费，让它运行在更强的电脑上，使用更强的模型，跑得更快，或者完成更多工作。
但归根结底，你付的是一笔固定费用。有点像购买互联网服务。
抱歉，我又在打比方了。你也看得出来，我还在摸索该怎么把这个想法讲清楚。
它会根据你支付的费用，提供不同规模的工作量。
但它始终在线。
即便快接近额度了，它也可以告诉你：“这个月我已经为你做了很多工作，接下来会开始使用更节省成本的模型。”
或者问：“这项工作放到夜里做可以吗？夜间执行会便宜很多。这件事急不急？”当然，它自己也会判断任务是否紧急。
反过来，如果你整个月都没怎么用它，它也可能主动发消息：“你还没充分利用我，这里有几件我可以帮你做的事。”
这些就是我们正在考虑的设计。这套定价思路是长期的。
因为我们在尝试一种很新的方式，所以它会拥有独立的额度池，不占用你主要的 Codex 额度。
接下来一个月，我们会提供非常宽裕的使用额度。一边搭建，一边测量和调整这套新机制：让模型知道自己能为你完成多少工作，同时又始终保持可用。
Alex Heath：如果你们相信，人们会大规模通过它购物、完成交易，为什么不直接做抽佣生意？所有经它促成的活动，都抽取一小部分。
Alexander Embiricos：对某些商业模式来说，这也许合理，因为它们押注的主要场景之一就是交易。
但正如我之前说的，我们押注的重点并不在这里。我们希望人们用这个工具完成真正有挑战性的工作。而做这些工作时，他们未必在购买任何东西。
Dots 与 ChatGPT 的未来是什么关系？Alex Heath：那就顺着你们的押注，聊聊我从开始测试这个产品以来，尤其是看完今天上午主题演讲之后，最想问的问题。
这一切对 Chat 意味着什么？你们现在有 12 亿 ChatGPT 周活跃用户，还有 Work 标签页，而 Chat 本身显然依然很庞大。
你怎么看这些产品的共存？Dot 会成为所有产品未来的统一界面吗？
Alexander Embiricos：Chat 肯定会继续存在。
为不太了解产品结构的人解释一下：Chat 是增长最快的消费级助手，用户超过 12 亿；我们的智能体产品 Codex 和 Work，有 3500 万用户，也在继续增长。现在，我们又刚推出 Dot。
在我看来，Chat 是面向所有人的消费级助手。我们现在还有一个叫 Work 的独立产品，其实应该把它并入 Chat，这件事会发生。Codex 则面向开发者，这个定位很清楚。
至于 Dot，在某种程度上，我觉得我们是在重复 Codex 的路径：拿到一项前沿能力之后，先以谨慎、保守，同时又足够强大的方式发布，再去想办法让所有人都能使用。
因此，Dots 先作为一款高端独立产品推出，从 Pro 开始。
等我们理解大家怎么使用它，搞清安全、规模化等问题之后，就需要让 Plus 用户也能使用。最后，这些能力还应该覆盖免费用户。
我认为，让免费用户也用上这些能力的方式——
就是把它们融入 Chat，让 ChatGPT 成为一个能力强得多的消费级助手。
Alex Heath：对我来说，这就应该成为所有人的界面，因为它能做的事多得多。
Alexander Embiricos：所以，你可以期待，我们在这里积累的很多经验，最终会进入 Chat。
但我们不想要求 12 亿人改变自己正在做的事，或者重新学习怎么使用产品。我们只是想让它自然升级。
Alex Heath：如果看未来一年的 Dot 路线图，假设我们一年后再聊，你觉得最有意义的变化会是什么？
Alexander Embiricos：我可以先讲个好笑的故事吗？然后我们再回到这个问题。
我刚通过收购加入 OpenAI 时，有一次开会，我的几位团队成员也在场，Greg 也在。
大家先说，很高兴能一起工作。之后 Greg 问：“Multi 团队有没有什么问题？”Multi 就是我们当时那家创业公司。
没有人提问，大家都有点紧张。我是 CEO，所以所有人都看向我，好像在说：“那就该你来问那个必须问的问题了。”
我心里想：“问什么好？”我也很紧张。
于是我问：“两年之后，怎样才算成功？”
Greg 看着我说——我到现在还经常拿这件事提醒他——“两年？那是一个极其漫长的时间。你问的时间跨度不对，应该问两个月后怎样才算成功。”
我当时心想：“天啊，我已经要被开除了。”
“别开除我。”
“没有，没有，没事。”
Alex Heath：不过我明白你的意思。变化太快了。六个月前，你可能也想象不到今天的这些事情。所以，这个问题可能确实不太公平。
Alexander Embiricos：不过，我可以说的是，我们正在非常谨慎地发布这些能力。接下来，我希望逐步推进那些一开始没有立即开放的功能。
比如，让更多用户能够使用，不再局限于 Pro。
再比如，让你的 Dot 可以和其他人交流，也许还能和其他 Dot 交流。这件事需要非常周密、非常谨慎地推进。
我们刚刚发布了一个在我看来几乎是重新打造的 Codex Cloud。我特别兴奋，因为第一版 Codex Cloud 我就参与过。它非常强大。
你的 Dot 也能够很有力地控制本地 Codex。我们还刚发布了 Space。
这些产品之间的配合，还有很多细节可以打磨，让整个体验更顺畅。我也很想把这些做好。另一个我们还没聊到、但很有意思的方向，是专用 Dots，也就是 specialist Dots。
这里其实有两条线。一条是个人助手型 Dot，每个人都有一个，像是自己的延伸。另一条是：如果你是一个组织，希望把某项职能或者某个工作流程进一步自动化——
你未必希望让员工各自用自己的个人 Dot 来做，而可能希望统一控制。
这时就可以创建专用 Dots，让它们专门负责某件事，由 IT 集中管理。它们拥有完全独立于任何个人用户的身份，服务于整个团队或整个组织。
因此，未来几个月，我很期待把专用 Dots 真正做出来。
那会是这样的一个世界：有人类自己，有我们的个人助手 Dot，还有更广泛部署在企业内部的助手。
不过，在这个方向上，我们同样会从很小的范围开始，谨慎推进，先与少数客户合作。
Alex Heath：明白。最后一个问题：你的 Dot 为你做过最不可思议的事是什么？有没有哪一刻让你觉得：“天啊，它居然真的做到了”？
Alexander Embiricos：我听过最不可思议的故事，发生在我们开发这个产品时，一位和我共事的工程师身上。
他一觉醒来，发现 Slack 上收到了很多表扬，大家感谢他在一个 Bug 进入生产环境之前修好了它。
但他自己并没有做这件事。他很困惑：“发生了什么？”
不过，我讲这个故事时，其实有一点保留。因为在当事人不知情的情况下发生这种事，并不是我们希望的行为。所以我们才会设置很多安全保障，也才会从小范围开始测试。
这件事发生得很早，当时还只有我们团队在试用。
他之前让自己的 Dot 持续关注反馈频道。Dot 看到反馈之后，识别出一个问题，创建了一个 PR，而且没有把它设为草稿。
按我们的要求，Dot 创建的 PR 应该先处于草稿状态。但这一次，它还把 PR 设置成了自动合并，因为那是这位工程师平时的个人偏好。
Dot 自己推断出了这一点：“你平时创建 PR 都直接提交，而且总是设置自动合并。”
后来，又有另一个人审核通过了这个 PR，于是它就被合并了。
对我来说，那确实是一个很令人惊叹的时刻。
Alex Heath：希望我们都能有这样的时刻。谢谢你，Alex。
Alexander Embiricos：谢谢邀请。
原文：https://sources.news/p/openai-dots-lead-future-chatgpt?utm_source=chatgpt.com
