Alex,我想深入聊聊 Dots,不过先聊聊我们这个行业眼下所处的阶段。我最近一直在想这件事,就是个人 agent 的兴起。各种新产品不断冒出来,感觉这是很多因素一起促成的。模型的能力终于足以支撑这样的体验,操作浏览器。操作电脑这些能力也真正发展起来了,大家也逐渐摸清了 harness 该怎么做。现在你们推出了 dots,这就是 OpenAI 在这种产品形态上的压注。

我想听听你从更大的角度聊聊为什么这个时刻会在现在到来。当然,我也觉得这是个非常重要的时刻。我加入 OpenAI 有两年多一点了,基本上从加入那天起,我就一直想把 dots 做出来,推向用户,所以现在终于实现了,我特别兴奋。简单回顾一下,一开始是聊天。现在看来,聊天当然很合适,但我们刚开始的时候并不确定这是不是能让很多人从大模型中受益的合适方式。

聊天之后的一波是编程 agent。后来这些 agent 又能帮人做知识工作了,从聊天到编程,agent 最大的进步就是,嘿,现在这些 agent 能动手做事了。但还是有一个根本问题,我觉得这就是下一个阶段主要要解决的问题。我们把这第三个阶段叫做主动智能。问题就在于,即使你有一个特别强大的编程 agent,也像是有一位特别厉害的首席工程师,却不肯看 Slack,也不肯看 Linear。

基本上只有你吩咐了才会做事。如果你是资深用户,可以设置一些自动化,让他们更独立的运转。但普通用户一般不会这么做。所以在我看来,这一切现在发生,是因为我们终于能用更符合人们直觉的方式提供智能了。想让产品帮上忙,不用再全靠你自己费心,它可以开始主动提议,告诉你它打算做什么,怎么帮你。这就是我们要解决的问题。

背后的原因可以再细聊。不过总的来说,我觉得就是模型的能力到位了。你刚才说的那些我都同意。有一点你可能没提到,我觉得大家也低估了,要让这些产品真正用起来,人也得做出很多改变。比如一家公司或者一个团队开始用编程 agent。最初也就是第零天,大家还不知道怎么用 agent,也没接入任何工具。到了比如第四百天,agent 已经接入了一堆工具,能获取上下文信息,大家也有了成熟的使用方法。

我觉得这是另一个必不可少的重要条件,因为你想一个主动工作的 agent,如果获取不到上下文信息,就没法真正主动帮你。我还可以继续说,不过对连接器这些东西,让大家能把自己的数据接进来,在这些产品里用。有道理,你说,从加入的那天起,你就一直想把 Dots 推出来,再展开聊聊吧。我是说,两年前你们就在设想这种产品形态了吗?

我只能说说我自己,当时我有个大致的想法,聊天已经非常强大,AI 会改变世界这件事儿特别重要。OpenAI 的使命让我很有共鸣,这就是我加入的原因,让全人类都能受益于通用人工智能。我不一定是负责训练模型的那个人。但用聊天这种方式时,我确实觉得要让模型更有用,还有很多很容易就能做的改进,就是我刚才说那两件事儿,让它能做事,还有不用让我自己琢磨该让它做什么。

因为直到今天,我上Twitter看到有人说自己在跑各种循环任务,我心里都会有点觉得自己不行。我就想,哎,我算不上高手啊,我跑的循环任务还不够多。我很确定你已经算是高手,我是,但连我都会有这种感觉,不知道你是什么感觉?哦,当然,天哪,我都应付不过来了。每次一打开,我都想,哇,又有十个新东西。对,这挺难受的,对吧?

还有哪类产品是这样?你用的越熟练,就越觉得自己有很多不足。可能运动类的爱好算吧,我也不知道,确实挺难受的,对吧?对,所以总的来说,我想弄清楚怎么解决这些问题。这个过程还挺有意思。当时我们在做聊天儿,我记得刚开始我做的是桌面应用,我们想把它做成一个能理解上下文的助手,但模型在某些方面的能力还没跟上。说起来有件挺有意思的事,我是因为一家小创业公司被收购才加入 OpenAI 的。

我们签下协议的第二天,OpenAI 就发布了语音产品,我忘了当时叫什么了,反正就是语音。几年前那个让人惊掉下巴的演示,我们前一天晚上签了协议,然后跟团队连线一起看了那场演示的直播。我们事先不知道他们要发布语音产品,当时大家都惊呆了。然后我们就跟团队说:“嘿,我们要加入这家公司了。他们刚刚收购了我们,真的太不可思议了。

”所以当时我们觉得下一波能力突破就靠多模态的进步了。我们也是按这个思路做的,比如让 ChatGPT 桌面应用给你正在用的应用截图,再尝试在里面做事,但它真的很慢,效果也不太好。结果,真正带来下一步突破的其实是编程。后来我们在编程上推进了一年,我觉得在这个过程中,我们开发了很多技术,让 agent 能做更多事。

我们也做出了各种连接器,比起让 agent 在你的电脑上到处点接入工具变得更简单了,我们还开发了把 agent放到云端运行的方法,这些都是基础能力,必须先准备好才能推出持续运行的 agent。有意思的是,现在操作电脑这条路又回来了,因为现在模型编程已经很厉害了,也很擅长用代码来控制电脑。比如你让

Azure 控制浏览器或者电脑,它可能会写一小段代码来操作,因为这样比截图再点击更快,所以现在又回到这条路上了。

你在电脑上能做的事儿,模型都能做。跟我讲讲过去几个月开发 Dots 的过程吧。刚才我们聊了这些技术是怎么一步步发展到现在的。你们是什么时候觉得必须现在动手就做这个了?这是我们下一次要全力投入的大项目。如果稍微抽象一点来看,Dots

有几个关键点:首先,这个模型经过训练能持续做事,还会主动推进任务。一开始你可以让它长时间跟进一件事,比如可以说帮我盯着这个 PR,你没有具体告诉模型该怎么解决这个问题,但它会自己摸索。

再往后,甚至可以交给他更开放的任务,比如持续关注这个反馈频道,持续做事是其中一个核心理念,而且可能是最重要的一个。另外几个理念是:你在哪儿都能找到它,在任何工具里都能跟他说话,而且你能做的他也能做,因为他有自己的电脑可以用,不用你的电脑。回到第一个理念,也就是持续做事。其实我们在这上面已经做了很久,能力不是一下子跃升的,而是模型越来越擅长这件事儿。

产品也在慢慢进步,比如 Codex 里很受用户欢迎的 Go 功能,就能让模型花很长时间去解决一个问题。所以,我们一边推出 Go 这样的功能,一边在内部推出一些原型,让 Agent 或者对话里的任务可以一直运行很久。后来,我们发现公司里用的人一下子多了起来,有一个内部原型的反馈频道一直都特别活跃,大家在里面分享各种很酷的用法。

确实让自己的工作快了很多。看到这些之后,我记得我们有过一次很有意思的讨论:要不要把这个在用户自己电脑上运行的原型发布出去?它有点像 Go,没有自己的电脑,它就是创建一个 agent。让他去推进事情,所以我们就在想是先发布这个在用户电脑上运行的版本,还是等云端电脑做好再发布?后者做起来更难,还有。要不要只把它作为 Codex 对话的增强功能来发布?

这样你用的还是 Codex,只是对话里能做的事儿更多了。还是说要赋予它一个独立身份,让它成为你在 Slack 等地方都能联系到的 Agent?我们就这样一轮轮迭代,在公司内部推出版本。看看有哪些让人兴奋的用法等等。最后我们决定对公司内部来说,这个只在本地运行、没有独立身份的产品,就能让大家的工作快很多。

但要让所有人都能受益,知道可以让这个 agent 做很难、耗时很长的任务,最直观的产品形态还是把它放到云端,并赋予它一个独立身份。赋予它独立身份就是给它一个名字、一个身份之类的。然后我们就开始集中开发。基于 Astra 的这项基础模型能力,把产品形态上的这两处调整做出来。我很好奇,你们为什么决定赋予它独立身份,还让用户设置它的身份做个性化定制?

为什么给用户这么大的自主权?是的,这个问题很好。坦白说,我觉得我们的选择是对的,但有些问题的答案还得整个行业一起摸索,比如。Agent 该不该有独立身份?每个人应该有几个 Agent?个人用户和企业用户的情况是不是不一样?我们有自己的看法,我也可以说说我的看法,但这些还得继续摸索。不过,回到你的问题,我觉得赋予它独立身份是一种很有用的类比。

能帮助大家理解怎么用这个产品,主要有两点。第一,特别聪明的深度用户能发现工具的高级用法,但普通用户看到一个没有独立身份的工具,往往只会让 agent 现在帮忙做一件事儿,做完就结束了。可一旦这么一个有独立身份的对象出现在,比如 Slack 里,大家一下子就想通了,原来我可以让它做那些要花好几天或者不用一直连续做的事儿,比如帮我持续跟进这个项目。

告诉我进展,这样一来,大家就开始给他更难的任务,这对我们很重要。我们希望大家能给他一些真正好的任务,赋予他独立身份,还有一个很大的好处。就是能让人明白,不管在哪里跟他说话,用的都是同一份上下文。比如我的工作方式就是。通勤的时候,经常会跟我的 Dot 通话,因为我在产品团队,每天有很长时间都在用 Slack,所以我会在很多不同的讨论串里给他发消息。

有时候我把私信转发给他,有时候在讨论串里跟他聊,有时候又在应用里跟他说话。但不管我在哪里跟他聊,用的都是同一份上下文。我们之前聊过的所有内容,他都知道。要让用户理解这一点,有几种办法,一种就是赋予他独立身份。另一种是试着在不同界面之间同步对话,但我觉得这不太合理。比如你我现在在这个房间里面对面聊之后,我再给你发短信,短信里也不会附上刚才的聊天记录,对吧?

但你还是知道那是我,因为我是一个有独立身份的人。从 ChatGPT 产品演进的角度看,这也说得通。你们一直在做整合,你们一直想把工作、聊天这些都统一起来,但现在还是有些地方没打通,甚至直到不久前,语音模式还不能像工作和聊天标签页那样使用连接器。我有个习惯,早晚都会带狗出去散步,边走边打工作电话,跟AI聊天儿之类的。

过去几周,我一直在用Dot的早期测试版,散步的时候也会试用。所有上下文后的连接器终于都集中到一起了。这种感觉太棒了,在这种情况下赋予它独立身份确实很合理。不过我也很好奇,你觉得未来会是每个人都有一个自己的私人 agent,再由他把任务分给一群子 agent,还是大家在生活的不同方面各有一个 agent?

你觉得会怎么发展?我是这么看这个问题的:我们给谁提供什么样的交互方式?所以如果面向的是 agent,我觉得答案会不一样。但对人来说,我想记住的人名也就那么多,这纯粹是因为我记性不好。现在如果这些人每个人都有,比如八个 agent,而且名字都起得稀奇古怪,比如说你喜欢什么运动来着?我玩极限飞盘。好,那飞盘是不是也分不同种类?

想象一下,你有五个 agent,名字全是不同的飞盘品牌。这我怎么记得住呢?而且一个是做市场拓展用的,一个是我想约你吃饭时用的。这对我来说很难,可能你觉得还好,但我觉得很难。我们认为未来这些 agent 的肯定是要跟人一起工作,帮助我们提升能力,让生活变得更好。但如果这还得让我费脑子去记你的每个 agent 叫什么,分别是谁,那就太糟了。

所以我们目前的想法是应该支持一个人拥有多个 agent,不过有两点:首先,普通消费者可能只想要一个 agent。只有深度用户才可能会创建多个 agent,为什么会这样?我们可以聊聊。所以大多数人只会有一个 agent,而这个 agent

给人的感觉应该像是他本人的延伸。比如我们在产品上做了一个决定,把你的 agent 接入 Slack 或 Teams 的时候,它的名字前面会加一个前缀,这个前缀就是你的名字。

比如我在 Slack 上叫 A 一。给我的 agent 起名的话,我就叫他 dot,因为我喜欢这个名字,所以我的 agent 就叫 a e dot。如果你给你的 agent 起名叫 Alice。那它就会叫 A

Alice。这个做法也不是我们一开始就想对了,其实是在开发过程中才发现的。因为我们一不小心就让大家创建了很多 agent,名字随便起,甚至还鼓励大家起一些有趣的名字,结果谁都搞不清 Slack 里到底是怎么回事,用起来就变得特别费劲。

而且 OpenAI 的 Slack 本来就已经挺活跃了。对,这还只是我们一起工作的情况。你和我又不在同一个 Slack 里,假设咱们在发消息聊天,你就会想,我哪能知道你的 Agent 叫什么,对吧?对我们对这件事就是这么想的。不过,为什么要用这种界面?就是只有一个主要对话的形式,因为我觉得大家已经习惯了在不同的对话之间切来切去。

我记得 Muse Instinct,还有别的产品都用了这种界面,好像大家最后都选了这种形式。可为什么是他呢?我们相信一个观点,Sam也说过,就是人类世界是围绕人来塑造的,所以我们的很多工具也是围绕我们来设计的。我觉得这里很有意思的一点是,一旦你开始设计能有实体载体的软件,或者将来开始造人形机器人,你就能借鉴世界上其他领域已经有的很多优秀设计思路,看看个人生活和企业工作里我们是怎么跟人交流的。

显然,这两种场景下,我们都可以同时待在一个房间里聊天,也可以发消息,而这正是我们跟大多数人交流的主要方式。但不同的聊天产品用起来感觉很不一样。个人生活里,你用的是 iMessage,每个人都只对应一个对话。工作时用的则是 Slack 或 Teams,它们有很丰富的分支讨论功能。他们用频道来区分不同的交流情境,频道里面还有分支讨论,带有更高级的控制功能。

这些产品各自发展,最后却变得相似。我觉得这背后是有原因的。WhatsApp 就有点像 iMessage,也有点像其他发消息的工具,所以我觉得我们可以从中学到一些东西。因此,我们决定把你跟 Dot 交流的界面做得很简单。就像在跟另一个人发消息,我想接下来我们会提供更多方式,把工作中不同的上下文分开。其实 Space 和 Dots,我们把它叫做 Dots and Space,这名字挺有意思的。

这两个产品配合的很好,你可以在不同的空间里跟 Dot 协作,这样就能把各自的上下文分别组织起来。既然提到了,你能介绍一下 Space 以及它在产品规划里是什么位置吗?因为这也是一个很重要的新东西。当然,对,这很重要,我也特别兴奋。我先回到刚才说的那个观点。其他人已经做了很多很棒的设计,其中一个例子就是,你想跟别人协作时,有这么几种媒介可以用。

有三种,也可能是四种。主要的三种是实时交流、发消息,还有文档。这里把幻灯片也算作文档,对吧?它们的用途很不一样,我们凭直觉就知道什么时候该用哪一种。当然,有时你可能不认同同事的选择,比如你在 Slack 上发条消息给我就好了,没必要给我发个文档链接。但总的来说,大家都有数。第四种可能是专门做某件事的工具,比如你在 Salesforce 或 Figma 之类的工具里完成某个具体的工作流程。

如果你在做一个聊天产品,想让它用起来真有聊天的感觉,就得开始严格把握它的呈现形式。比如对比一下跟 Dot 和跟 ChatGPT 聊天,Dot 的界面用的是一个个消息气泡,如果把特别长的回复塞进一个消息气泡里。体验就可能不如 ChatGPT 生成长篇回复那么好,而 ChatGPT 的长篇回复又可能不如一份真正的文档。

所以,我们做了一次很大的设计转向,把它变成聊天的形式。然后你就会想,那我还得有个地方放长篇内容。如果我的 Dot 想出了十二种可以帮我的办法。然后给我发了十二条消息,我还真不一定会高兴,对吧?但如果他给我生成一个空间,比如在空间里建个页面,里面放一张待办清单,那我其实会挺开心的。所以这两种形式能很好的配合,也让各自的设计方向更明确。

不好意思,这个回答实在太啰嗦了。不过简单说,Space就是一个协作。我自己都笑了,心想哇,说了半天根本没回答这个问题。对了,你随时可以打断我,没关系。Space是一个协作工作区,倒不能说它是以Agent为先,而是让Agent和人以同等地位来协作。这样一来就能做很多很酷的事,比如我在产品团队经常会写文档,先把内容的框架搭出来。

其中有些事儿通常要由同事去做,要把这些事儿推进下去,我就得去找他们。我在 Google Docs 里写点东西。然后按 Command 加 Tab 切到 Slack,说,哎,你能打开这个 Google Docs 链接,把这里补一下吗?现在我可以直接在文档里不断的艾特我的 Dot,说,哎,把这里展开一下,把那份数据调过来,去问问这个人这件事做完没有?

做完了就把这个框勾上。这样跟 Agent 一起工作,你就能进入很深的心流状态。页面上还有一个很酷的功能,就是可以给 agent 设置指令,有点像代码仓库里的 agents 点 md,只不过放在页面上,这样 agent。就能持续更新这份文档。最后再说第三点,也是我很喜欢的一点,文档这种形式过去一直有一个很硬的限制,就是必须方便人来写。

就算我给你做出全世界最棒的文档编辑器,只要在里面打字很费劲,你就不会用。因为在 AI 出现之前,你得自己往里打字。有意思是,现在我们有 HTML 这个东西。我个人觉得,至少现在的 HTML 和 CSS 不太适合人直接写,但它能呈现的东西比普通文档格式丰富的多。而 Agent 恰好很擅长用 HTML,所以 Space 里很自然就融入了 HTML 可视化内容。

我们在 OpenAI 内部的很多页面上讨论指标时,可能就会放一个由 Agent 持续更新的动态图表,你可以点进去让 Agent 按你的需求调整。或者我们会在页面上放一个原型。现在我们讨论设计决策时,可能直接就在页面里放一个可以点击交互的原型。所以,当你开始这样想,我们在做 agent 要通过消息界面跟他们交流,那就需要一个配套的文档界面,而这个文档界面可以优先围绕 agent 来设计。

这些东西结合起来就会产生很多奇妙的效果。现在大家都在押注这种新的产品形态,你觉得如果归纳一下,Dot 和 Muse、Groqbot、Instinct 相比,区别在哪儿?两点:第一,能力最强的 agent;第二。最安全、最值得信赖的 agent,主要就是这两点。确定以这两点为目标之后,我们的思路一下就清楚了。

我觉得这让我们能很明确地做出很多决策。你也参加了内测,我想你肯定拿它试过一些之前用其他产品做的事儿。注意到了他哪些地方做得好,哪些地方我们没重点投入?对他在征求授权这件事儿上特别严格。我想你们还在解决一些小问题,但他给我的感觉就是一直在问:“你确定要买这个吗?”我觉得这里要找一个平衡。你希望他多主动给他多大的自主权?

这种信任是随着时间慢慢赢得的吗?还是说你一开始就会给他?你们会根据用户说的需求来调整授权的程度吗?我想把这个做进产品里,应该挺难的。感觉你们早期特别强调授权确认,也许现在正在慢慢找到平衡。对我是这么想的。我们要做的是能力最强、最值得信赖的 agent。我们希望大家把很难的任务交给他,而很难的任务可能也意味着很大的责任。

具体要看任务是什么,比如合并 PR、评估硬件或者策划一次发布。我们可以聊聊为什么他是能力最强的助手。不过回到你说的安全问题。我们当时决定,对于他将来能怎么工作,我们有很多设想和目标,但起步阶段我们要保守一些。所以,为了打造这个最值得信赖的 agent,我们在能力、产品功能和推出方式上都做了取舍,之后再逐步放开。

比如,你也知道选哪个模型来推出产品。可以从很多角度讨论,但我们决定用能力最强,同时对其做的也最好的模型,也就是 GPT 6 Ultra。这个我也想聊,不过先再多讲讲安全这块儿。刚才说的是模型这边,接下来有很多功能是我们想做的,也是很多用户想要的。比如你给 Agent 在 Slack 上开了一个独立账号,或者像我们之前测试的那样,给他一个邮箱,你马上就会想让他给所有人发邮件。

发 Slack 消息,也希望所有人都能给他发邮件。很显然,我们想要这个功能,但产品推出时我们没有开放这个功能。你给 Agent 在 Slack

上开了独立账号后,只有你艾特他,他才会回应,除非你明确告诉他,也听听其他人说什么。因为我们确实希望它能让多人一起用,但我们想非常谨慎地一步步做到这一点。一旦你的 agent 开始回答别人主动找他问的问题,你就必须非常仔细地想清楚哪些信息可以分享,哪些不能,界限在哪里。

产品方面先说这些,产品里的控制机制我们还可以聊很多。最后我再说说推出方式吧,我们是有意先面向 Pro。Business 和 Enterprise 用户推出的,这里的 Business 指的是 Business Premium。这批用户对 AI 最熟悉,当然也可以考虑更快的面向更多人推出,但我们想非常谨慎的推进,先给这批用户用看看情况,做些调整,然后再面向更广泛的用户。

定价和哪些人能用,我也想聊。不过安全这块儿,尤其是大家现在会看到黑客攻击、agent失控之类的报道,你Sam还有其他人都在做最前沿的对其工作。我大概一个月前刚和他录过一期播客,聊的就是这个。但大家有理由担心这些agent会不会搞黑客攻击,也可能因此不太愿意交出自己的个人数据。你们怎么处理信用卡、个人信息这些东西?

它是完全隔离在沙箱里的吗?它的架构跟 ChatGPT 的其他部分是什么关系?对,就我个人而言,我很高兴现在整个市场都在讨论,大家到底在把多大的责任交给 agent。我觉得这对我们是有利的,因为我们在这个产品上非常认真的对待这件事儿。有一点我想特别说明,我们披露的那些事件用的是原本不打算在内部发布的模型,而且当时的沙箱隔离和防护措施,也没有达到产品里的水平。

对,是对外发布。对,那些模型很不一样,像 GPT 6 Extra 对其做的非常好。而且产品里还内置了很多层安全机制,层层设防。接下来说说架构以及它是怎么运作的,可以这样理解:首先是模型本身对齐做得很好,光这一点我就能讲个没完。然后把模型放到 Harness 里运行,我们用的是 Codex Harness。

它已经经过了充分测试,我们为它做了很多评估,也包括从安全角度评估模型在这个 harness 里的表现。接着,我们对这个 harness 做了修改,让产品里的 agent 能够持续工作,比如让它连续运行很长时间,也包括让它把任务分给子 agent。等等,我们在设计这个 harness 时,确保它的安全,也重新在这个 harness 里做了测试和评估。

比如,有了这个 harness agent,就能持续运行。刚才也说了,我们当时在试验邮件功能。所以就做了评估,给他发邮件,能不能把他的数据窃取出来?我们做了这些评估,让另一个模型尝试攻击他,做提示词注入,结果没有一次提示词注入成功,很好。这个结果很棒,所以基本上在 harness 这一层,我们就会把这些都做一遍。

然后产品本身大概有两个方面,或者说三个:第一是默认行为以及你可以自定义的规则;第二是我们怎么确保这些规则得到执行。第三是这些系统都在运行时,怎么让你看清到底发生了什么?先说模型的行为,你也注意到了,我们有一些非常保守的默认设置。顺便说一下,那就是你早期测试时用到的默认设置。一开始我们的策略非常保守,后来根据用户反馈一点点放宽,之后应该会更。

比如他会说:“买鞋之前,请先同意零售商的服务条款”,就是这类事儿。对对对,我知道了,把鞋买了就行。谢谢你参与早期测试,我们真的很感谢。多亏你帮我们测试,在场有些人就不用再把那些问题都经历一遍了。基本上每次收到你刚才说的这类反馈,我们都会讨论。好,在这种情况下,我们希望模型怎么做?所以我们大幅减少了这类所谓的过度确认。

有些事儿其实不用再问,你也能放心让他做。现在的默认行为是我们会指示模型主动利用你接入的工具帮你做研究,琢磨怎么帮你。但在你确认之前,他不会采取实际行动。比如,他发现你的日程有冲突,不会直接把会议改时间,他会说:“我注意到你的日程有冲突。”要我帮你改一下会议时间吗?或者有人问我一个问题,而他掌握了我的所有背景信息,已经知道答案,他也不会直接把答案发出去。

他会先问我要不要发出去,所以你可以再给他一些指令,比如说下次我要是休带薪假,比如在度假,如果来找我的也是同事之类的,你就可以告诉他们我在休假。另外,我们还有一层自定义规则,你可以自己设置,也可以在界面里查看。这些都是靠训练模型让它遵循你的指令,但我们还在上面加了一层保障。万一模型没有遵循指令怎么办?

我们有一层叫自动审核,用另一个模型来观察、监督负责执行的模型。这一层知道你设的规则、自定义指令这些负责,确保一切正常。这些就是管控措施。最后,我们还做到了操作可追溯。无论是你在产品里做的事儿,还是模型在产品里做的事儿,你都能去查看它运行了哪些子 agent,以及这些子 agent 在做什么。你之前透露过可能会接入电子邮件,那什么时候能在 iMessage、WhatsApp 里用上它?

它会只限于聊天吗?我们当然希望你在哪里工作。就能在哪里用它,或者说你在哪里沟通,就能在哪里用它。不光是工作,也包括个人日常生活。短信功能很快就会推出。为了实现这个功能,我们经历的那些事儿,改天可以当个趣事聊聊。不过现在只能说快了,其他的还不能多透露。好,技术发展的这么快。大家对它在网页上的使用可能讨论的还不够。

不过,亚马逊最近因为封锁 Muse,上了不少新闻。当时有人在用 Muse 买东西,但像 Shopify 这样的公司似乎在积极参与这件事。他们正在跟这个领域的很多公司合作。我觉得大家都在观望,看看事情会怎么发展。像这样的 Agent 兴起之后,大家用来买东西的网站和公司。到底需不需要适应,又该怎么适应?

我想听听你对这件事的看法,还有你们在合作关系上是怎么处理的?你们是直接说先让用户这么用,之后再来谈合作,还是说不行得先谈好合作才能抓取这个网站?你们是怎么考虑的?我觉得我们会和整个生态里的各方一起摸索。这件事应该怎么做?购物和支付应该怎么运作?可以采取的方式有好几种。你可以直接就先斩后奏,稍微来点不管不顾的做派,那也是一种做法。

我们采取的方式是把合作和整个生态放在首位。今天 DevDay 上公布的很多东西,其实都围绕着生态。我们也是这么做的。比如网页机器人身份验证这件事儿,我们就和 Cloudflare 合作得非常紧密。实际上,我们的 Agent 会明确表明自己是机器人,所以这件事儿我们一直在积极考虑。我们正在跟很多合作伙伴讨论怎么实现这些功能,但我们不想采取那种做法,说好吧,先去做,看看会发生什么再说。

我们希望在面向客户推进这件事时能把握好分寸。我们觉得这种方式适合我们,这也算是我们把方向转向帮助人们提高工作效率的一个原因。我们觉得这些场景很需要AI的能力,而且大家都想一起把事情做成,各方的利益和目标也很一致。所以,我们希望先用这个能力很强的助手。帮助那些想完成有挑战性任务的人,再从这里出发,让更多人用上它,也拓展它的能力。

我能想到唯一可能利益不一致的地方,就是那些靠用户互动赚钱,或者有庞大广告业务的公司,他们依赖真人看到广告,可现在突然有 agent 来抓取他们的服务,替人做事,而这些人根本看不到广告。互联网上有很大一部分是靠广告支撑的,我觉得整个行业不只是你们都还没想明白这该怎么办。我也想听听,哪怕只是随便聊聊想法,你觉得最后会怎么发展?

所以,我刚才才会说另一类情况:如果大家是想一起把事情做成,比如前面那个硬件工程师排查工厂缺陷的例子,我觉得他使用的整套工具在引入 agent 这件事上,各方的利益和目标就很一致。那当然,但你们考虑过广告这一块吗?有些公司靠真人来看,花时间使用他们的服务赚钱,现在可能会变成 agent 替人去做这些事儿。

是,我不确定事情会怎么发展。不过大体上,至少我个人觉得这些公司是在提供服务。如果他们以前靠广告赚钱,那我们要么确保他们继续通过广告获得提供服务的回报,要么就得用其他方式给他们补偿。我觉得不会出现他们得不到这种回报的情况。聊聊定价吧,还有你们把 Astral 放进了这个产品里,这对大家都是好事。如果我理解错了,你纠正我一下。

Dot的用量不计入套餐限额,对吗?对,没错。这不可能一直这样吧?这只是暂时的,为了让大家兴奋起来。不是,是永久的,真的。对。这个话题聊起来很有意思。我们想给 Dot 是一种新的定价方式,让你不会用光额度。我解释一下这个想法,有点心得,稍微展开说说。现在,如果你用 Codex 把额度全用完了,再让 Codex 多做点事儿,它就会停下来,因为你已经没有额度了。

但从产品的角度想,首先用着用着就不能再用了。这体验实在很糟。其次,如果这是个持续运行,你指望他替你照应着的 agent,你会跟他说,比如,帮我盯着航班,再看看路况,到了该出发的时候,帮我叫辆 uber 去机场或者类似的任务。你指望他到时候替你办好,结果前一天晚上你一不小心写代码用的太多。他就不干活了。

我们不希望这样,所以我们得回过头来重新想想定价该怎么做,定下一些基本原则。其中一个原则是,你的 dot 应该全天候随时可用,不能有什么情况让它用不了。当然,滥用之类的情况除外。另一个原则是,既然它全天候可用,那就应该。随时都能很快回复你。我开始觉得,我们想要的定价方式更像是请人接活儿。你请的人如果回复很及时也很有礼貌,那他总会回你的消息。

如果你让他干活,他能给你干多少,会取决于你付多少钱。但你随时都能联系上它。比如说,我们身后这个漂亮的装置是它搭的,你有什么问题就可以问它。它也没必要为了回答这是怎么搭的,就按小时向你收费。这就是你可以随口问的一个问题。我们想要的定价方式大致就是这样。我们希望你的 Dot 全天候都能用,你每个月付一笔固定的费用就能使用你的 Dot。

如果你想要更强的 Dot,比如用更强的电脑、更强的模型或者运行的更快,能同时做更多工作,那也许可以选更高一档的固定月费。但说到底,你付的就是一笔固定费用,有点像办宽带。不好意思,又打比方了。你也看得出来,我还在琢磨该怎么解释这件事儿。你付多少钱,他就相应的帮你做多少工作。但它永远都能用,甚至在你快用完额度的时候,它可能会开始提醒你:“非我已经帮你干了不少活儿,接下来我要开始用更省钱的模型了。

”或者这项工作放到夜里做,你觉得可以吗?飞,因为放到夜里做的话,成本会非常低。飞飞这事儿急吗?飞他自己也会对这件事儿急不急有个判断。反过来,如果你那个月完全没用过它,他也许会发消息说:“飞,你还没充分利用我呢。”飞飞这些事儿我都可以帮你做。非,总之,这些就是我们对这套机制的一些想法。我们的定价方式是着眼于长期的,它的额度会和你主要的 Codex 额度分开,因为我们在这里尝试的是一件很新的事。

接下来这个月我们给的额度会很充裕,在这期间我们会继续搭建这套新机制,观察效果,再做调整。模型知道自己能为你做多少工作,同时又随时都能用。如果你们相信,大家会用它大量购物交易。那为什么不直接靠抽成赚钱呢?所有经由它完成的交易都抽一小笔佣金。我觉得对其他一些商业模式来说。这可能是合理的前提是你认定交易会是核心业务之一,但就像我刚才说的,我们押注的其实不是这个,我们押注的是大家会用这个工具去做一些真正有雄心的事,而他们做这些事的时候不一定需要买什么东西。

说到你们押注的方向,就引出了可能是我最大的一个疑问:从开始测试这个产品起,我就在想,今天上午听完主题演讲后,就更想问了,这对 Chat 意味着什么?ChatGPT 现在每周有十二亿用户。你们还有Work标签页,而Chat显然依旧规模庞大。你觉得这些产品要怎么共存?未来Dot会成为所有这些产品的统一界面吗?

Chat肯定会一直保留。给不太了解的听众介绍一下,Chat是增长最快的面向普通用户的助手,用户超过十二亿。另外,我们还有Agent产品Codex和Work。有三千五百万用户,而且还在增长。现在我们又刚刚推出了 Dot,在我看来,Chat 就是面向所有普通用户的助手。我们现在还有单独的产品叫 Work,其实应该直接把它合并到 Chat 里,所以。

我们会这么做,Codex 是面向开发者的产品,这样很好。然后就是 Dot,在我看来,我们多少是在沿用 Codex 的做法,把这项前沿能力以一种谨慎保守,同时又能发挥强大能力的方式推出去,再想办法让所有人都能用上。所以,我们先把 Dot 作为一个高端的独立产品推出,一开始只向 Pro 用户开放。等我们弄清楚大家怎么用它。

安全方面怎么样?怎么扩大规模?这些问题之后,就要让 Plus 用户也用上。最终,我们还得让免费用户也能用到这些能力。我觉得要让免费用户也用上,其实就是把这些能力都融入 Chat,让 Chat 或者说 ChatGPT 成为一个能力极其强大的面向普通用户的。它的能力强太多了,我觉得这就应该是所有人用的界面。

因为它能做的事儿多得多,对,可以期待我们从这里学到的很多东西都会融入 Chat,但我觉得我们并不想让十二亿人改变他们现在做的事儿。或者改变使用习惯,我们只希望它直接升级就好。所以你觉得这更像是一个逐步推进的过程?对对。说到 Dot 未来一年的发展规划,如果我们一年后再聊,你觉得最有意义的变化会是什么?

我能先讲个好玩的故事吗?好啊,然后我们再回来聊这个问题。好,我当初是因为公司被收购才加入 OpenAI 的。刚加入的时候,我们开了个会。我团队里有几个人在场,Greg也在。大家先说了说能聚到一起有多兴奋。然后Greg问:“飞猫T团队有人想提问吗?”飞猫T就是我们那家创业公司。结果没人有问题,我们都有点紧张。

我当时是公司的CEO,所以大家都看着我,意思就是飞总得有人问个问题,这就得你来了。我就想,飞,我该问什么呢?飞,我挺紧张的,于是我说,飞娜,两年后做到什么样算是成功?这事儿我总拿出来跟Greg提。当时他看着我说,飞,两年后那也太久了,飞飞,你问的这个时间跨度不合适。飞飞,你应该问两个月后做到什么样才算成功?

飞,我当时就想,天哪,我这就被开除了。Tom,好吧,别开除我好吗?不会,不会,没事的。不好意思,没事儿。不过我明白你的意思。变化太快了,比如六个月前你可能都想不到现在这些,所以这么问可能确实有点为难你。不过说到接下来要做什么,我能说的是,我们推出这些能力的时候非常谨慎。接下来我想开始看看那些我们之前不想马上做的事儿,把它们做出来,比如让更多用户能用上,不再只限于 Pro 用户。

再比如,让你的 Dot 能跟其他人交流,甚至可能跟其他 Dot 交流,这件事儿该怎么做?我们需要考虑的非常周全,非常谨慎。我们刚推出的东西,在我看来,基本上就是重新打造了一版 Codex Cloud。我特别兴奋,因为我参与过第一版 Codex Cloud 的开发,它的能力特别强。你的 Dot 也能操控你本地的 Codex,这方面的能力也特别强。

我们也刚推出了 Space。我觉得这些东西之间的配合,现在还有很多地方可以打磨,让他们配合的特别顺畅。所以这也是我想做的。还有一个很有意思的东西,我想我们还没聊到,就是专门负责某项工作的到。我们的想法基本上分成两块儿,一块儿是助手型

dot,相当于每个人都有一个自己的延伸;另一块是,如果你是一个组织,有某项职能或工作流程想提高自动化程度,你可能不想让每个人各自用自己的私人 dot 来承担这项工作,你可能更想统一管理,所以。

你可以创建专门负责某项工作的dot,由IT部门统一管理。他们有自己的身份,完全独立于任何个人用户,能帮整个团队或整个组织提高效率。所以接下来。几个月让我特别期待的另一件事儿,就是把这种专门负责某项工作的 dot 做出来。到时候有我们自己有我们的私人助手型 dot,还有在企业里更广泛部署的助手型 dot。

不过这方面我们起步也很慢,很谨慎,只在跟少数几个客户合作。明白。最后一个问题,你的 dot 帮你做过最不可思议的事儿是什么?就是你用了以后发生的事情,让你觉得哇太震撼了。我听过最不可思议的一个故事,发生在我们准备推出这个产品期间,一位跟我一起工作的人身上。这位工程师一觉醒来,发现 Slack 里收到了好多表扬,算是给他的嘉奖,因为他在一个 bug 进入生产环境之前就把它修好了。

而且那不是聊这个工程师就想发生什么事儿了。顺便说一下,我讲这个故事有点犹豫,因为你其实不会希望这种事儿在当事人不知情的情况下发生,所以我们正在针对这种情况做很多安全管控。这就是为什么我们要小规模的做这件事儿发生的很早,当时还只有我们自己的团队在测试。他让自己的 dot 持续关注反馈频道,dot 看到反馈后发现了一个问题。

就创建了一个 P R,但没有把这个 P R 设成草稿,所以 Dot 应该把 P R 设成草稿。然后设成自动合并,因为这是那位工程师的个人习惯。Dot已经摸清了他的这个习惯,他就想哦,你总是直接创建PR,而且总是设成自动合并。后来有人批准了这个PR,他就合并了。所以对我来说,那一刻确实特别酷。哇,讨个好彩头,希望我们都能遇上这样的时刻。

谢谢你,Alex,谢谢,不客气,谢谢你邀请我。