从 E2B 到 Browserbase，Agent Infra 新热点中有哪些大机会？ | 对谈 Grasp 创始人雷磊

There's something there.

我们今天很高兴请到 Grasp 的创始人磊磊。磊磊，跟大家打个招呼吧。

大家好，我也是曲老师的老观众，一直很关注《42章经》，谢谢。

我是一名程序员出身，最早在 Google，后来经历了很多创业过程，之后加入字节跳动，在字节跳动打造了一个开发者平台。2022 年，我跟现在的合伙人出来创业，也是做开发者方向的，后来一直在做 AI 相关的方向。最近我们在做一个给 AI 用的浏览器，叫 Grasp。

我们今天请到磊磊，是因为我们之前录过文峰那期讲 Agent 的节目，你们也挺熟的，对吧？

我觉得 Agent 今年这波热潮其实从 Manus 开始，到现在差不多有三四个月的时间了。各种 Agent，有通用 Agent、垂直 Agent、Agent 平台，各个行业很多 SaaS 也可以管自己叫 Agent。这波热潮我觉得已经过去得差不多了，下一波经常有人问我们，后面有什么东西可以投，或者什么东西会起来。

我确实觉得，给 Agent 做的产品可能比较有意思。磊磊他们正好就在做这一块。你们现在相当于是在做一个给 Agent 用的浏览器，对吧？你是怎么想到要做这件事的？

1. Agent Infra 迎来大机会

首先，刚才你讲到很多做 SaaS 的也开始说自己是 Agent。其实 Agent 跟 SaaS 完全是两个不同的东西。SaaS 是一种工具，你得去使用它；但是 Agent 交付的是结果。所以我们更应该用看待一个人的方式来理解 Agent。

但是，Agent 又是一种跟人完全不同的形态。当你给人设计一个软件，和你给 Agent 设计一个软件，应该是从完全不同的思路出发，因为它们有不同的场景、痛点和特点。

Agent 会越来越多，它可能会取代一部分人的工作，带着人类往前走，甚至推动未来的创新和发展。在这种情况下，设计一些为 Agent 使用的软件、场景和工具，也就是所谓的 Agent infra，就是一个非常巨大的机会，这个市场也会有很大的增量。

现在全球有几十亿人，如果再把各种网站、各种公司主体加起来，就不知道有多少了。你相信未来真的会有千亿甚至万亿个 Agent 吗？

2. 通用 Agent 与垂直 Agent 共存

业界经常会有一个讨论：Agent 到底是通用的还是垂直的。其实我觉得这个讨论没有必要，它们可以共存。

就像现在有一个大型商场，里面既有综合商超，也会有一个个小店。它们解决的需求、面向的人群和提供的服务是不一样的。未来会有一些通用 Agent，也会有无数垂直领域的小 Agent。

数量至少会比 SaaS 的数量成千倍地增长。SaaS 是一种通用工具，但 Agent 是一个交付结果的店面。只要你能够在某个垂直领域交付更好的结果，就会收获一波用户。这个用户量甚至不一定要很大，但是能养活你。

就像有很多小店，长期就那么多客人，但是它能活得很好。

所以未来像淘宝店一样？

对，但我觉得比淘宝店还要更进一步。它会更垂直、更小，但背后也会有几个大的通用 Agent。它们会是一种并存的状态，而且会长期并存。

大家畅想未来的时候，可能都想到过这个状态，但因为它离我们还比较远，所以还没有想清楚，到那个时候 AI 会是什么样子，它跟人的区别是什么，或者它跟人到底会如何协作、互通。

你刚才提到，AI 和人是完全不一样的。

3. 人类开始为 Agent 服务

对，有很大的区别。在这个阶段，大家可能还是认为 Agent 是为人服务的，但是在我看来，未来应该是人为 Agent 服务。

Agent 有更高的带宽，它能接触到比人更多的知识和信号，而人的认知是有限的。

我们上一期播客里面，金建也提到了这个观点。

那期我还没听。

对，说明不是抄他的观点。他的观点是，现在是工具为人服务，人输出结果，Agent 辅助人；未来应该是输入到 Agent，再得到结果，人辅助 Agent。

底下有人喷我，说：“人类为什么不是主体地位？”你怎么看这个问题？

我觉得不用太把自己当回事儿，更重要的是到底能不能交付一个好的结果。如果人辅助 AI 能够交付更好的结果，那为什么不用这种模式，而一定要强调自己的地位？我觉得这个地位本身也是一种溢价。

这里面有一个核心问题：谁去下命令？

现在相当于是老板让人执行任务，人是为人服务。未来是不是老板给 Agent 和人这个整体下命令？

首先，我觉得人和 Agent 不要处于对立状态。我们不是一定要打败它，它也不是一定要取代我们。最重要的目的，是把人类和 Agent 算在一起，作为一个群体往前发展。

在这个发展的过程中，不同阶段会有不同的形态。比如 AGI，大家现在比较认可的有 5 个阶段：第 1 个阶段是 chatbot，第 2 个阶段是 reasoning，这两个阶段都已经过去了；第 3 个阶段是 Agent，我们现在正处在这个阶段；第 4 个阶段是 innovative，也就是创新。

在创新阶段，Agent 会是什么角色？怎么让 Agent，甚至 AI，做出一些人类没有办法想到的结果？这些事情之前已经发生过一些，以后也会发生得越来越多。

所以在这种情况下，没必要把它作为对立面。只要它产生了更好的结果，对世界就是正向的。当然，这已经比较偏哲学层面了。

回到更具体的层面，人和 AI 的行动模式有什么区别？

4. AI 需要全新的工作范式

第一个区别是，人是单线程的工作模式，而 Agent 是多线程、并行的工作模式。人只能一件事情一件事情地做，但 AI 可以同时提出 100 个方案，再从这 100 个方案中判断哪个结果更好，然后继续推进。

这种情况下，带来的不仅仅是工作结果的变化，而是一种工作范式的变化。所以我们需要为 AI 这种新的工作范式设计新的工具和环境。

你提到的这一点，是不是正好对应最近大家在聊的 multi-agent，也就是多 Agent 协同？你刚才说的，在某种程度上是不是也是多 Agent 的协同？

不完全是。多 Agent 是一种工作模式，我说的是 AI 和人的一个重要区别。人和人可以协作，Agent 和 Agent 之间也可以协作，但更关键的是，人和 Agent 在工作、处理一件事情时，本身有什么区别。

我们继续聊 Agent 和人的区别。你刚才提到了工作方式的区别。

第二个区别是责任问题。人可以为自己的行为负责，但是 AI 采取的行为所产生的责任到底由谁负责？这就引申出一个问题：AI 所处环境的边界应该如何划分？这种划分和人的边界也是完全不一样的。

这两个区别体现在产品上是什么样的？

有人说，现在我做 SaaS，把其中一个环节交给 Agent，它就代替了人。但你的观点好像是，这种方式完全不可行，未来应该是完全不同的产品形态。

对，完全不一样，原因就是刚才说的两点。我们可以分别讲一下，这两点落在产品上的区别到底是什么。

第一个是工作模式的区别。因为我是程序员，就用写代码来举例。人在写代码的时候，是一个确定性行为：先写第一个方法，再写第二个方法，然后通过某种逻辑把不同的方法串联起来，形成代码，也就是 workflow。

但是 AI 可能会先生成 100 个方法，把这 100 个方法都跑一遍，看哪个是有效的，再把这个结果通过某种方式反馈回系统中。这样它就会不断进步。

在这种情况下，更重要的不再是如何把顺序性的代码执行下去，而是如何设计一个很好的反馈系统，如何同时生成 100 个方案并实时反馈给它，然后让它生成下一个方案。

它的执行不再是先写好一个方法，然后执行一次，而是先输入第一个节点的 100 种方法，得到一个结果，把这个结果反馈回去，再生成第二个节点的 100 种方法，甚至 1,000 种方法。这是完全不一样的思路。

体现在软件上，我们需要有一个非常好的反馈循环。人的工作模式中不存在这种反馈循环，也不需要很实时的反馈，因为人最后看到结果就可以了。

你讲的其实是，人类还是线性思考，一步一步做，最后看到结果；但 AI 或者机器有点像拥有全局观，直接从结果导向倒推。

对。对于人来说，是我要去探索地图，先打开第一个地图，再打开第二个地图，这是一个局部最优。但 AI 有可能同时触发 100 种探索。

在计算机领域，有一个类似的对比：第一种叫贪婪算法，它永远看局部最优；第二种叫动态规划，它直接看全局最优。

人类的方法偏贪婪。人类在工作模式上是偏贪婪算法的。当然，有些时候人会先进行全局思考和规划，但真正执行下来，因为人是单线程的，只能一步一步执行。

AI 在执行层面上，可以在全局范围内寻找一个最优解。

现在有没有哪个产品已经在往这个方向走？可以举一个例子吗？

DeepMind 团队最近做了一个叫 AlphaProof 的产品，逻辑很简单，就是让模型解决奥林匹克数学问题。

人类可能会一步一步学习：遇到这个问题时，我应该怎么解？但 AlphaProof 是完全不同的模式。它只设计了一系列反馈信号，并且通过某种办法把数学问题转换成机器能够识别的题目，然后把题目交给它，告诉它要去解决这个问题，让它自己进行推导和训练。

最终也不知道它到底是怎么解决的，但从结果上来说，它确实可以解决这个问题。

所以这里最关键的是，如果你为人设计一套解题系统，需要设计如何引导它一步一步完成；但给 AI 设计系统时，最重要的是设计最后的反馈信号是什么样的，而不用在意中间它到底是怎么做的。

因为它中间的工作模式跟人完全不一样。我觉得这是最关键的，也就是我说的工作范式的区别：我们不再是设计流程，而是设计最后的反馈。

回到我们自己做产品的时候，设计 Grasp 时也考虑到了这一点。我们所做的浏览器，跟给人用的浏览器有一个很大的区别：我们会非常在意浏览器的结果如何反向反馈给系统。

在每一步的结果中，我们都会设计循环性的奖励机制，根据执行过程和结果的判断，把它作为奖励信号。这个奖励信号代表这次执行对结果产生了正向影响还是负向影响。我们会把它作为数据输入反馈到系统中。

在这种模式下，我们相信它会越来越智能、越来越优化，这也是所谓强化学习的一种方式。

这种感觉现在已经是比较公认的方法了。

对，只是到底怎么做、谁做得更好，还不知道。

5. 反馈循环决定 Agent 能力

这里有一个很重要的区别：反馈信号到底来自哪里？业界有一种说法叫 grounded signal，意思是这个信号到底来源于真实反馈，还是来源于人为判断。这是完全不同的。

现在的大模型在这个阶段，很多反馈还是来自 RLHF，也就是人类反馈。但真实情况下，它应该根据结果本身是否完善来判断。

这也是我们做这件事时非常重要的一点：要关注最后真正的真实结果。它操作网页完成任务之后，结论可能是它真的完成了，也可能没有完成；而不是我看到它一系列准备采取的行为后，去判断这些行为是好还是不好。

这是第一个点。第二个点也可以讲一下具体例子。

6. 沙盒划定 Agent 安全边界

第二个点是安全边界，也就是承担责任的问题。

比如今天要生成一段代码，如果代码是我自己写的，在我的电脑上执行，出了问题我可以负责。但如果代码是 AI 生成的，它能直接在电脑上执行吗？如果它把文件全部删了，到底是谁的责任？

所以最基本的要求是，它需要有一个沙盒。为什么现在所有给 Agent 做环境的 infra 都在提沙盒、做虚拟化？因为我们需要划定一个边界，把 AI 产生的影响控制在一定范围内，同时在这个范围内让它能够更好地运行。

我们还希望沙盒的启动和执行足够快。因为 AI 可以同时执行很多步骤，所以希望这个过程足够短，让它更快拿到结果，从而更好地优化和迭代。

比如 E2B，它主打的就是提供一个安全沙盒，并且采用 MicroVM 这样的技术，让启动时间非常短。这是第二个点的现实例子。

你看，环境、沙盒，包括 E2B 这个产品，在美国现在都很火，但国内很多人可能还不太知道。能不能正好以 E2B 为例，给大家解释一下它大概是做什么的、怎么运行起来的？Manus 用的也是 E2B。

对，E2B 很大程度上也是被 Manus 带火的。很多 infra 的产品，都是因为上层应用火了，跟着火起来。

简单来说，E2B 提供了一种环境，让你运行 AI 生成的代码。为了让 AI 生成的代码更有效地运行，它做了很多工作。比如刚才提到的快速启动，它采用了一种叫 MicroVM 的技术，这是一种进程级沙盒，跟传统理解的 Docker 容器不一样，比 Docker 更快。

像 Manus 这种产品，大家哪怕没用过，也看过一些案例。它肯定会在后台生成代码、执行任务。大家下意识会觉得，它肯定是在虚拟机或者云上运行的。

那虚拟机、云、沙盒和 E2B 之间有什么异同？

首先，虚拟机是一种技术，不是一个场景。它最关键的作用，是把物理设备虚拟化出来，构建一个隔离环境。

虚拟化有很多不同方式。最早的虚拟机比较重，后来出现了更轻量化的方案。广义上，容器也可以算作虚拟机的一种，包括刚才说的进程级虚拟机 MicroVM。所以它是一种不同的技术方案。

E2B 是不是一种虚拟机？

E2B 是一个解决方案，虚拟机是它采用的其中一种技术路径。

云和本地也有区别。本地唯一的优点是没有网络延迟，但它带来了很多问题，比如安全隐患、无法弹性扩缩，也没有办法 7×24 小时运行。这些都是云要解决的问题。

像 Cursor 这一类产品，算本地化吗？

Cursor 本质上是 Copilot，主要目的是辅助你生成代码。它不是一个完全自主的 Agent，也不是一个环境。当然，它也在逐渐做 Agent。等它开始做 Agent，你就会发现它的技术架构会从本地转向云端，因为它需要在云端运行代码。

但我看到有人说，Cursor 或者其他类似产品会提示你：如果要运行这段程序，可能会遇到错误，需要关闭本地某个端口。会有这种情况吗？

它本质上还是在辅助你做判断，并不是交付结果。

我知道。但如果我不懂这段代码，它这样提示我，我同意了，确实有可能导致系统崩溃。

对，确实有这种风险。不过这也是一种思维模式的转变。

根据我的观察，这种模式正在逐渐发生。周围有很多工程师，之前使用 AI 代码生成器时，会关注生成的是什么代码，类似于做一次 code review。但现在很多人已经不关注了，直接让它执行，这就 Web coding 嘛。

执行之后，只要结果符合要求就可以了。

对，就像把工程师外包出去一样。

但在这种情况下，如何信任它是一个非常关键的问题。

未来这些东西是不是都应该到云端？

它一定会在云端执行，但会通过某种方式把界面展示给你，让你能够看到它。这个展示是一个构建信任的过程。

但归根结底，你关注的是结果，而不是它生成的代码本身。类似地，推广到其他行为上，比如 Browser Use，你关注的也是它使用浏览器、采取一系列行为后得到的结果，而不是它具体如何使用浏览器。

这也是给人用的浏览器和给 AI 用的浏览器之间一个很大的区别。

我觉得这是一个挺有意思、也比较大的观点：未来 Agent 往前发展，产品都应该云端化。

至少它的环境应该在云端，客户端可以在本地。

一个大前提是，如果要足够强大，模型就要运行在云端。在这种情况下，把环境和模型放在一起，是一种很自然的构建模式。

但这么听起来，E2B 做的事情好像也没有特别多。未来它跟云厂商的关系会是什么样？

云厂商更多的是基础设施。比如构建一栋房子，云厂商提供的是水电这样的资源；E2B 要做的是如何把这些资源真正交付给使用它的人。当然，这里的人要打引号，以后可能是 Agent。

所以 E2B 更像是装修商，负责布置水管，设计这些资源如何交付。它们本身没有冲突，底层的基础算力肯定还是由云厂商提供；中间这一层是 infra，提供的是 AI 或 Agent 真正运行的环境。

你刚才举的例子很妙。很多地产商后来会做精装修商品房，卖的都是装修好的房子。那后面云厂商是不是也会自己做这些事情？

反正我觉得，至少 E2B 是一个很好的被收购标的。

这是一个很有意思的问题：什么情况下房地产商会去做商品房？

其实很简单。如果它只做拿地、修房，只交付毛坯房，市场容量不够了，也就没有竞争力了，所以要进一步竞争。

回到 AI 市场本身，这是一个很大的增量市场。我觉得在这个阶段，更应该用合作、把蛋糕做大的逻辑来看这件事，而不要过早考虑怎么分蛋糕。

在 AI 时代，所谓的壁垒都是不存在的。

如果按照以前的逻辑，是人使用 Agent，Agent 本身是 SaaS。但在这个时代，我觉得 Agent 绝对不能是 SaaS，Agent 本身就是一个主体。所以你们做的是给 Agent 用的 SaaS，而不是 PaaS。

我刚才还好奇一个问题，还是用 E2B 举例：代码不能跑在本地，是因为可能出现各种问题。E2B 说你把代码放到我这里来跑，那如果在它那里出了问题呢？它的安全能力也很关键，对吧？

对，这就是它定义的边界。它告诉你，即使在这里出了问题，影响最大会到什么程度。如果这个影响你能够接受，那就没有问题。

你做这一块，也做了多年的工程开发。你觉得什么样的团队最适合做 E2B？

我觉得是那些真正写代码、开发 Agent 的人。

给 Agent 做 SaaS，或者给 Agent 做环境，需要有两个非常重要的能力。第一，你一定要深入理解 Agent 的痛点，本身要是一个 Agent builder。第二，你本身要是这种环境的重要用户。

比如给 Agent 写代码时，你本身应该是一个深度写代码的人。

回到浏览器也是一样。第一，你需要 build Agent，有这样的经验；第二，你需要有非常深度的浏览器脚本编写经验。

在这种情况下，反倒是不是做浏览器内核的，并没有那么关键。首先，浏览器内核本身已经比较成熟；其次，在 Agent 时代，这个内核可能跟上个时代不一样。关键是如何构建一种好的开发体验和 Agent 使用体验，所以一定要对这个场景有很深的认知。

还是以 E2B 为例，它既要做过 Agent，又要做过环境，这其实还是一个很大范围的人群。如果再聚焦一点，它必须是安全能力特别好，还是云计算能力特别好？

我觉得不是安全能力特别好，而是它能理解安全边界在哪里。

这里有一个很有意思的例子。E2B 有一个竞争对手叫 ForeverVM。E2B 打的是安全，这一点大家拍脑袋也能想到，但 ForeverVM 打的是什么？它打的是状态。

写代码的人都知道，每次代码执行都会有一个状态，代码执行完成以后状态就没了。但在 AI 使用代码的过程中，它可能先执行一段脚本，中间又去做别的事情。比如过了 1 个小时，它想接着这段脚本继续运行，那怎样才能保持两段脚本的状态不丢失？

同时，这 1 个小时里不可能一直让环境热启动、在那里等着，因为这样会浪费巨大的资源。如何在实现上下两个状态无缝衔接的同时，极大节省资源？这就是 ForeverVM 解决的问题。

这不就是刚才你说的第一个问题的案例吗？它解决的是 Agent 并行的问题：并行执行任务，又要来回切换，还要能够接得上。

对，可以这么理解。

这个痛点在人类写代码时不会出现。你就算做了很多年代码编辑器，也不一定能发现这个痛点。反倒是那些一边写 Agent、一边写代码的人，会发现这种情况下存在这样的问题。

你解决了这个痛点，提供了一个解决方案，这个解决方案就具备价值，而这个价值本身就是产品的壁垒。

我再延伸一个问题。这个价值是给 Agent 的，Agent 会输出得更好，但最后反馈到人类能够衡量的指标上，是什么指标？是结果更精准、成本更低，还是别的？

就是成本更好。

安全其实很难衡量结果，因为安全是一种比较模糊的概念。所以我一直强调的是边界：在这个边界范围内，你能不能接受。

E2B 很重要的一点，是把 AI 放进一个围栏。在这个围栏中，你知道它最多只能产生这么大的影响。围栏到底有多大？太小了，可能对 AI 的限制太大，没办法发挥它的能力；太大了，大家可能又无法接受。这个度很难把控，我认为这也是 E2B 很重要的价值。

Manus 在年初的时候，是怎么发现 E2B，又怎么知道要用它的？

其实很简单。作为开发者，你要解决产品中的一个需求痛点。比如 Manus 可能需要给 Agent 一个虚拟机，在里面运行代码和脚本，这时就会去网上搜索相关解决方案。

为什么要找别人的方案？因为自己做，要解决一、二、三、四、五这些问题。如果它在 E2B 上看到这些问题都已经解决得很好了，就会直接使用。

开发者选择产品其实很简单：你能不能解决我的问题。

顺便问一句，哪些东西应该自己做，哪些东西可以直接拿别人的来用？作为开发者，只要有别人做好的东西，就会很开心地拿来用吗？

这是开发者圈特别有意思的一个问题：要不要重复造轮子？

我的观点是倾向于使用现成的。在我看来，开发者的关键价值也是交付结果。一个需求来了以后，你通过代码把程序构建出来，最终把程序交付出去，作为一个结果。

如何更好、更高效地构建和完成它，这是更关键的事情，而不是其中的代码到底是你自己写的，还是用了别人的。

所以从我自己的角度出发，会倾向于使用已经做好的东西，除非它无法满足需求，并且这个需求非常关键。那我可能会自己写，或者基于它做二次定制。这也是我们很喜欢开源世界的原因。

你看好 E2B 吗？

我还蛮看好 E2B 的。我觉得它是 Agent 与这个世界交互的一个非常重要的渠道。

你刚才说的另一家竞品是 ForeverVM，对吗？

在我看来，给 Agent 用的环境这个市场足够大，能够容纳很多家公司。每家可能提供不同的解决方案，在不同场景下满足需求。

如果对标以前的产品，大概是哪一类？

我的感觉是，它像原来给人用的 SaaS，只是现在变成了给 Agent 用的 SaaS，或者叫 infra。但它不是最底层的 AWS 那种 infra，更像 Databricks、Snowflake 这样的中间层。

这是一层比较泛化的服务，但到了今天，可能已经不是过去那种一模一样的切分方式。

如果我们假设未来 Agent 真的起来了，全世界有千亿、万亿个 Agent 在无时无刻地运行，有很多为它们提供的环境、infra 和 SaaS，那这些会怎么影响现在的 infra，比如 Databricks？

要么顺应潮流，要么被历史淘汰。

这个事情我们已经经历过很多遍了。无数公司没有顺应潮流、没有变化，因为有惯性，就在历史长河中消失了。但也有一些公司能够很快调整，适应变化。

按这么讲，如果听众认可未来 Agent 会起来，哪怕不知道什么时候，大概率它会起来，那背后现在就有一大堆机会。很多东西都可以重新做一遍，市场非常大。应该能得到这样一个结论。

对，这个市场在我看来才刚刚开始。

如果把大模型的出现想象成人类刚刚拥有智能，我们可能还处于刚刚学会生火的阶段。实际上还有巨量的事情可以做。

现在的大模型还没有真正与世界发生交互、获取反馈，所以还有很长的路要走。这其中会蕴藏巨大的机会。

讲完 E2B，再回来讲 Browserbase。美国给 Agent 做的产品，两个典型就是 E2B 和 Browserbase，对吧？

Browser Use 好像被收购了，它之前是 YC 投资的，最近也刚刚拿到新融资，也是浏览器领域的一个玩家。

你们现在做的也是给 Agent 用的浏览器。可以先给大家介绍一下这个赛道，以及 Browserbase 这些公司的情况。

7. Browserbase 进入 Agent 赛道

Browserbase 算是现在的当红明星，从融资额也可以看出来，它在 1 年时间里估值涨到了 3 亿美元。

它的概念很简单，就是给 AI 用的浏览器。它跟传统浏览器的区别是，首先把浏览器云化了；其次针对 AI 使用浏览器的场景做了一些优化。

AI 需要 RAG，所以在使用过程中，它可以自动获取网站信息，作为上下文来辅助 AI 操作网站。它主要是在优化 AI 使用浏览器时可能遇到的一些痛点。

如果说 E2B 当时那一波主要靠 Manus 带起来，Browserbase 是谁带起来的？

我们为什么会做浏览器这个生意？也是同样的逻辑。

我在字节跳动时特别喜欢一鸣的一句话，叫“务实的浪漫”。我们前面一直在仰望星空，讨论未来很大，但回到今天，也需要解决具体问题，脚踏实地地切入。

一个最基本的数据是，现在互联网上的流量有 40% 已经来自机器人。能够解决这 40% 的流量在运行过程中遇到的问题，就是一个很好的切入点。

Browserbase 很多时候是在解决这些机器人爬取网页信息时遇到的具体问题，比如不够智能化、无法适应网页调整，或者因为不了解网页信息，所以网页发生变化后就失效。

所以它的客户很多是传统爬虫公司，可以这么理解？

对，也包括自动化测试、RPA 之类的场景。

但你看，从 Manus 到 Fellou，它们好像都没有用 Browserbase。它们都有 AI 使用浏览器的功能，同时 Manus 还选择了 E2B。为什么不选 Browserbase？

我觉得可能有一个原因是，Peak 自己本来就是做这一块的。

还有一点，如果你真正去使用 Browserbase，它的产品使用体验目前还是有比较多问题的。而且 Browserbase 不开源，E2B 是开源的，Manus 可以基于 E2B 去做。

这个阶段大家都还处于很早期，没办法真的拿来就用，实际上还有很多工程问题没有解决。

但过了这么久，应该已经有一些开源解决方案了吧？

Browser Use 里肯定有一些，但解决得都不算特别好。包括 Playwright 自己也开源了一个叫 Playwright MCP 的项目。

实际上，浏览器环境本身比代码环境复杂一些，因为它涉及网络、延迟和状态管理等问题，复杂很多。

正好讲一下，给 AI 用的浏览器和给人用的浏览器，具体有哪几个区别？

8. AI 浏览器必须重新设计

第一个比较简单的区别是，给 AI 用的浏览器一定运行在云端，因为 AI 不会睡觉。

第二个是，AI 读取浏览器页面时，不一定要像人一样通过视觉操作，所以它可以是 headless，也就是不需要真正像人一样看到界面、用鼠标操作。

headless 这个词在这类场景里经常出现。能不能用大家都听得懂的话解释一下，headless 到底是什么？

浏览器有前端界面，就是给人用的浏览器。如果没有前端界面，只是作为一个进程运行在后端，就是 headless。

顺便插一句，如果未来 Agent 真的起来了，是不是就都是这样？AI 都不需要前端了？

理论上，给 AI 用的东西完全不需要这样的交互界面，因为人的使用方式和 AI 的使用方式不一样。

但是给人用的浏览器也会长期存在，因为人也会一直存在。

第三个区别是安全问题。假设今天用浏览器操作，登录时到底要不要把账号和密码交给大模型？你肯定不希望这样，但也不希望每次遇到登录问题时，它都来问你：“你帮我操作一下。”

所以，如何让它能够自主登录、自主操作，同时又不把账号密码交给大模型，是给 AI 用的浏览器中特别重要的问题，跟人用浏览器完全不一样。

这个问题你们能解决吗？

我们做了一个功能，叫 Security Local Login，也就是安全本地登录。

我们通过定制浏览器，使得浏览器需要登录时能够自动判断，并通过纯本地的方式填入账号、密码，甚至接收邮件验证码。整个过程不需要人的干预，是完全自主的，并且绝对不会把任何信息传给大模型。

这是我们比较核心的差异化功能。

第四个区别跟刚才提到的 ForeverVM 很类似。大模型操作浏览器时，很多时候会有多步骤，中间也会有很多间隔。

比如先去携程搜索机票，把信息拿到另外一个系统中推理，整个过程可能还需要人的介入和参与。最后决定买哪张机票，再回来操作浏览器时，肯定不希望浏览器从头开始，而是继续上一个页面。

但是中间的推理和人做决定的过程可能持续很长时间。浏览器运行在云端，如果一直让它等在那里，就会非常消耗资源和时间。

所以，如何让你下次回来时直接接着之前的状态继续运行，让你感觉网页从来没有消失过，但中间又不消耗资源？这就是我们做的一个功能，叫 Stateful Browser Session，解决的就是这个问题。

这些都是非常具体的问题，也就是人使用浏览器和 Agent 使用浏览器时的显著区别。

你刚才讲的最后一点，我觉得人类也会遇到。我经常跳出去再跳回来，它就不让我买了，说价格已更新，然后重新搜索、重新进入，很烦。

但这里有一点，你的行为是在个人电脑上运行的，本质上是在浪费你个人的资源。可以浪费个人资源，但不能浪费 Agent 的资源。

因为浏览器运行在云端，而且 Agent 是并行的，可能同时进行很多任务，资源浪费就不一定能接受。

Browserbase 已经做得还可以了，对吧？那你们还要做这件事的原因是什么？跟它的区别是什么？

9. Agent Browser 分成三层

如果你想构建一个有 Browser Use 功能的 Agent，一共可以分成 3 层。

最下面是浏览器运行时。你可以把它理解成一个传统的内核浏览器，解决的是访问网页时如何从网上把网页信息拉下来，拉下来以后如何执行浏览器脚本，以及如何渲染图片等问题。它有点像云端的引擎，我们把这一层叫作 runtime。

Browserbase，或者传统的 Playwright、To C 使用的 Chromium，本质上都属于这一层。

但 AI 来了以后，上面多了第二层，叫 Agent 层。这一层控制 AI 如何与网页交互，如何从网页获取信息，如何产生信息来影响网页，以及如何在整个过程中进行推理，形成它到底要做什么。

再上面一层是 Knowledge 层，也就是垂直行业的 know-how。这一层是所有真正 build Agent 的人需要关注的，因为他们需要设计如何反馈这个系统，优化最终交付给终端用户的结果。

我们做的是最底下两部分，也就是 Agentic 加 Runtime，把它们合二为一。

根据我们的观察，这两部分第一是工程量非常大，需要解决很多问题；第二是很多问题都比较通用，开发时大家都会遇到。我们把它们统一解决以后，提供一个封装好的 Agent Browser 给开发者。

开发者以后只需要带着自己的行业认知，就可以构建自己的 Manus 或自己的 Fellou。

Browserbase 做的是哪一层？

Browserbase 做的是 runtime，也就是最下面一层。

但最下面这一层，浏览器已经发展这么多年，应该有很多成熟方案了。假设今天 Google 说想做这个东西，是不是分分钟就能做出来？

如果只做下面这一层，确实壁垒不够大。

但 Browserbase 有很强的先发优势，而且它也提供了一个开源框架，叫 Stagehand。它的逻辑是，开发者可以通过 Stagehand 实现 Agentic 这一层，再接上它的 runtime，构建一个 Agentic Browser，然后加入自己的行业认知。

但在我看来，这样工程量太大。我们实际做下来，中间这一层，包括刚才提到的 Secure Local Login、长状态管理等，都非常复杂。

要解决这些问题，实际上需要对底层 runtime 有控制能力，才能做得更好。所以必须把最下面一层和中间一层一起做，不能只接 Browserbase 做中间层。

如果这样做，很多想实现的功能是实现不了的。

这也解释了为什么 Manus 和 Fellou 不用这些产品。它们可能做的是更通用的 Agent，需要对底层有更充分的控制，自己设计反馈循环，所以可能从最底层开始做。

对。但未来不是每个人都需要这样做，也不是每个人都有这么强大的工程团队。我们要做的就是解决这些工程问题，提供这样的技术架构，让大家基于我们去构建自己的 Agent。

你说的中间那一层，也就是 Agentic 那部分，具体在产品上会体现为什么？

比如你给我一个任务，我们会先基于当前网页和你的任务进行一次推理，判断到底要执行哪些步骤，而不是让你明确告诉我每一步要怎么做。

但从这个角度来看，你们跟 Fellou 的区别是什么？它也是人类给一个需求，然后自己拆解步骤、执行任务。

首先，Fellou 是 To C 的，而我们是给开发者使用的，面向的用户不一样。

理论上，Fellou 也可以基于我们构建。当 Fellou 无法解决你的需求时，你就可以快速基于我们构建一个 Agent。

比如我想基于你们做一个 Fellou，应该还蛮快的，对吧？

相对来说是这样。但实际上，Fellou 和 Manus 不仅仅使用了 Browser 这一种环境。

未来的形态会是：大量 AI infra 或 AI 环境公司提供基础设施，每个基础设施就像一块乐高积木。你把它们组合起来，再加入自己的行业认知或特定解决方案，就可以构建自己的 Agent。

现在大家会认为，Agent 肯定有一些组成部分。AI coding 肯定是其中一部分，它会选择一个 E2B 这样的在线云端 coding 环境；同时还要用浏览器跟人的互联网世界交互，搜集信息、完成 action，所以会有 Browserbase 这一类产品。

除了这两个，你觉得还会有什么？

在我看来，coding 和 browser 一定是两个非常重要的环境。

其实不用看 Manus 和 Fellou，直接看行业最大的公司。ChatGPT 的 Deep Research Agent，本质上就是一个 o3 模型，加上网页浏览能力和 Python 代码执行器。

所以代码和浏览器一定是两个最重要的环节。

除此之外，可能还有一些更抽象的环境，比如运行数学公式的环境。再往下一层，可能还有一些更具体的环境，比如跟物理世界接触的传感器、具身智能，包括李飞飞关注的空间智能。这些都是给模型提供与真实世界交互的环境。

所以你觉得中间这一块，除了 E2B 和 Browser Use，就没有别的了？

这两个是非常大的类别。一个是 coding，解决执行逻辑的问题；另一个是 browser，解决与 Web 信息交互的问题。

从大类上来说，确实就是这两类。但中间会有很多细分。比如浏览器有不同的使用方式，有的更偏向获取信息，有的更偏向产生信息。不同方式会有不同痛点，就会有不同的解决方案和环境公司出现。

代码也是一样。执行的是脚本代码，使用解释型语言还是编译型语言，都会存在不同。

所以这两个赛道，包括你们现在选的这个赛道，应该都是未来非常大的赛道。

我记得之前我们聊天时，你提到过一句：今天的 Browser Use 有点像 2023 年的 AI coding。这个观点可以再给大家解释一下吗？因为你们在 2023 年一开始做 AirCode，也算是 coding 产品。

10. Browser Use 复制 AI Coding

回过头看 2023 年，那时 AI coding 也有很多问题，大家都在怀疑它到底能不能用。但到今天，基本上已经没有疑问了。

一个大模型能不能解决某个具体问题，有一个很简单的公式，就是这个事情的样本数乘以模型的成功率。大模型本质上是概率模型，两者相乘以后，得到的成功次数能不能满足人的需求。如果能满足人的需求，它就会开始变成主流。

回到 2022 年，那时 GPT-3 还不行；但从 GPT-3.5 开始，它突破了一个阈值，使得代码这种规模的样本数乘以模型概率后，达到了能够满足人的结果。

回到今天，Browser Use 的样本数更大，而今天模型的概率显然还没有办法满足它的成功率，所以现在仍然有很多人认为它不实用。

但随着大模型能力增长、概率提升，当样本数乘以概率所得到的结果能够满足人的阈值和需求时，这件事就会立刻变成今天的 coding。

而且这个过程会比之前更快。

AI coding 现在甚至有全球几百家公司在做，估值很高的也有很多家。你觉得未来 Browserbase 或者 Browser Use 这个领域也会这样吗？

其实即使是 AI coding，我觉得也还处于非常早期。

从商业层面来看，全球软件开发的总市场大概是 3 万亿到 4 万亿美元。如果 AI 能够在其中提升 5% 的效率，那就是一个 1,500 亿美元的市场。

但今天 AI coding 可能也就是几十亿美元，接近 100 亿美元的市场规模，所以它还有很大的增长空间。

Browser Use 也是同样的道理。今天大量商业行为都发生在互联网上：销售、招聘、沟通、展示成果、获客，都是通过互联网完成的。

如果这些事情能够通过 AI 提升哪怕 5% 的效率，也会形成一个非常巨大的潜在增长市场。在这个市场机会下，做这件事就有非常大的机会。

所以我觉得现在其实才刚刚起步。

你日常也会跟不少人聊类似的话题。对于给 Agent 做产品这件事，大家现在有没有什么很强的非共识？Agent 产品到底最需要什么？

我觉得这本身就是一个非共识，每个人看法都不一样。

很多人会认为，需要给 Agent 更好的上下文、更好的知识，或者采用更合适的模型。但在我看来，最关键的是如何设计最好的反馈循环。

这是设计整个 Agent 最重要的一点。

对做 Agent 来说，产品设计本身也是一种环境。你们的环境是另外一种环境，你们做的不是 Agent 本身。

对。环境是 AI 和它所处外部世界的交互方式。通过这种交互方式，AI 获取真实结果，作用到 Agent 本身，再通过反馈设计奖励机制或反馈循环，让它不断提升能力，交付更好的结果。

对于 Cursor 来讲，VS Code 那套东西应该是环境吧？

对于 Cursor 来说，VS Code 里面内置的代码执行器是它的环境。

但未来这些东西都应该到云端吗？

对。

如果这么讲，话题就有点偏了，但我还蛮好奇：如果 E2B 未来把这些事情都做了，而你们也在做类似的事情，那你们的产品什么时候上线？

我们预计下个月就可以开放。

如果用你们的产品，很快就能做出一个 Fellou，那未来我用 E2B 很快也能做出自己的 Cursor，至少是一个低级版 Cursor。可以这么类比吗？

可能是一个更专注于特定领域的 Cursor。

你可以把 Cursor 认为是一种通用的代码 Agent，但实际上还有很多专业领域的代码 Agent。比如有一个 Agent 专门生成更好的登录页面，它在这个环境下需要关注的点是不一样的。这些点更多来自上层需求，而底层代码执行环境没有区别。

这套公用的代码执行环境可以运行在 E2B 中。

如果未来 Agent 特别多，现在捋下来，好像 E2B 的环境和 Browser Use 的环境是值得做的。

假设我今天想创业，相信未来 Agent 会起来，想给 Agent 做产品，除了这两件事，你觉得还有什么可以做？

除了环境以外，还可以做工具。

如果把 Agent 作为一种新的服务对象，那么在服务人的过程中，这些工具都有机会重新做一遍。

比如身份。Agent 要不要有自己的身份？它甚至要不要有自己的电话号码，用来接收短信？Agent 要不要有支付能力？所以支付也有机会重新做。

这些你们应该也都考虑过，最后选择了 Browser Use 这个方向，对吗？

对。第一，我们本身有很多年前端开发经验，对于浏览器本身以及自动化流程有非常深入的理解。

第二，在我看来，浏览器是 Agent 与世界交互的一个非常重要的渠道，所以这是一个非常大的机会。我们希望在今天这个很早期的阶段，去做这个更大的机会。

未来几年，甚至更长时间，你怎么看 Agent 的整体发展？

11. AI 通过真实体验进化

在我看来，一个最重要的范式转变是，AI 会从使用人类的数据，转变为自己去体验世界，然后从体验中获取真实反馈，把这些反馈作为数据训练自己，不断增强能力。

只有这样，它才可能突破人类认知，发现一些更新的东西。

怎么理解“它自己的体验和数据”？可以举个例子吗？

比如让大模型生成一个川菜菜谱。今天的做法是找一个很厉害的川菜大厨，看这个菜谱，然后让大厨告诉你这个菜谱行不行，再把结果告诉 AI，让 AI 不断学习。

但这样做的后果是，AI 会越来越受人类偏见的影响。

我觉得人类最大的偏见之一，可能就是太相信人类的知识和经验，认为这些对大模型很重要。所以我们不停地把人类知识灌给它，希望它越来越聪明。

有没有一种可能，人类知识对它来说其实没有那么必要？就像 AlphaGo，最后发现人类棋谱其实没有那么重要。

这就是所谓的 Bitter Lesson。

在这种情况下，我们能不能找到一种更好的方式，让 AI 获取更多适合它的数据？

那就是让它跟世界进行交互。回到刚才的例子，让一个大厨判断菜谱好不好，它永远只能无限逼近这个大厨。

真实情况难道不应该是，按照这个菜谱把川菜做出来，然后尝一下，要么很好吃，要么很难吃，再把真实结果反馈给它？这样学习下去，它才有可能某一天做出一个菜谱，川菜大厨觉得很难吃，但实际做出来很好吃。

这就叫创新，它才能突破人类的边界。

所以我觉得，未来 AI 的发展一定是通过跟环境和世界进行真实交互，获取真实反馈。这也是整个 Agent 发展中，环境为什么非常重要的原因。

我最后一个问题是，听了半天，我觉得是不是有些云厂商的股票未来会涨得更好？

关键是，你到底能不能在这个时代快速转变，跟上时代的发展。

今天的智能手机市场比 10 年前、20 年前大了很多，但并不是 20 年前只要做手机，股票就一定涨得很好。你可能像诺基亚一样被淘汰，也可能从一个完全不做手机的公司，变成非常知名的厂商。

不过整体上来说，你说得对。未来云厂商会有更多机会，因为云厂商的机会来源于它卖的是资源。如果这个世界会消耗更多资源、产生更多数据，那这些资源和数据就更值钱。

所以你甚至觉得，现在有新的云厂商的机会？

在我看来，AI 环境这件事就是一个 AWS 级别的机会。

这又回到最早聊过的问题：它最后跟 AWS 的关系会是什么？现在这些产品肯定都基于其他云，既然是 AWS 级别的机会，AWS 自己也可以做，这毫无疑问。

更关键的是谁能够抓住这个机会。

如果聊到非常遥远的未来的竞争关系，可以认为像我们这种 AI-native infra，是从上往下做的。我们从最贴近 Agent 使用的环境和工具开始，慢慢往下做。未来有一天，我们可能会构建完全属于自己的浏览器内核。

但这就太难了，最后还是大厂在做，肯定有它的道理。浏览器内核还是一个重资源的事情。

我觉得更多是一种相互合作、相互补足的关系。

我们今天聊了很多内容，基础都是未来 Agent 会起来，对吧？

对。

那到底什么时候会起来？

我没有办法判断这么长远的事情，但我能看到的是，今天 Agent 正在不断崛起。

比起思考 Agent 什么时候会起来，更重要的是思考 Agent 是不是一定会来，以及 Agent 到来的那一天，我们能够为它做什么、发挥什么价值。

但从商业上讲，time to market 肯定很重要。你们的产品做出来以后，也会像 Browserbase 一样，先面向传统已有的用户，比如 RPA？

对，它一定是一个转型过程。这个世界不会凭空出现需求，一定是现阶段已经在使用产品的人，因为有一些需求没有办法被满足，而大模型正好能够很好地满足这些需求。

比如智能营销、智能销售。原来的销售工作流和营销工作流不够智能化，而 AI 或 Agent 给了它们这样的机会。这些人可能是第一批转型的用户，包括自动化测试用户。我们可能会先服务这样的用户。

好，今天就聊到这里。

谢谢曲凯老师。拜拜。