新富策略智能体大战的分水岭时刻：四种技术路径全解析

文 | 硅谷101新富策略

美国时间7月17日，OpenAI终于迎来了它的“Agent时刻”——通用型ChatGPT Agent正式发布。它整合了深度研究工具Deep Research与执行工具Operator，可一站式完成复杂任务，但仍存在速度慢、个性化不足等短板。这款产品的发布，让市场重新审视通用AI代理的技术路径选择。

ChatGPT Agent的架构本质是“浏览器+沙盒虚拟机”，与Manus、Genspark形成鲜明的技术路线差异。在底层架构层面，浏览器（Browser-based）代理虽堪称万能，但运行速度较慢；沙盒虚拟机（Sandbox）高效，但无法联网操作、工具库受限；工作流集成（Workflow API）速度快、结果精准，但业务范围有限。

不同架构模式下的几大主流Agent，各有哪些优劣势？针对B端客户和C端客户的Agent产品，在适用场景和技术逻辑上有何差别？Agent将重塑互联网入口，那么依靠广告营收的创作者们将如何维持商业模式？本期《硅谷101》，主播泓君对话Pokee.ai创始人、前Meta AI应用强化学习团队负责人朱哲清，深入拆解Agent的技术逻辑与未来趋势（这期内容非常干货，我们将分为上下两集进行推送~）。

以下是这次对话内容的精选：

01 主流底层架构对比：浏览器、沙盒环境、工作流

泓君：和市面上的通用型AI Agent对比，你觉得ChatGPT Agent的主要区别是什么？市面上所有通用型的AI Agent，它们的优劣势分别是什么？我相信它们在解决不同场景的问题上，还是会有一些区分度。

来源：ChatGPT

朱哲清：目前的通用Agent包括这么几家：一个是Perplexity，一个是OpenAI；Anthropic现在还没有推出自己的通用Agent，但他们有编程的Agent；我们Pokee相对比较小一些，比较晚期才出来；有Manus，有Genspark，可能更偏向垂直一些。

首先，目前在基于浏览器的产品中，能力最强的还是OpenAI，特别是它把深度研究和浏览器操作加在一块以后。如果你去看一些基准测试里面，比如说像最新出来的Browsing Camp（一项浏览器智能体的基准测试），它能够在Browsing Camp上面达到50%多的Benchmark Score（基准分数），而别的最高现在目前也只有20多分，在开源环境下。

图源：ChatGPT

朱哲清：在浏览器（Browser）真正的执行层面，Operator做得还是相对比较好的，因为当年的Operator是跟很多有API（应用程序接口）、有虚拟机的环境去对比的，它只有一个浏览器；现在Operator加上虚拟机的能力以后，应该会超越市面上别的一些工具的浏览器加虚拟机。

它唯一的一个比较麻烦的点是，OpenAI的浏览器尝试做太多事情，它什么东西都想往浏览器里面塞。Manus也用浏览器，在另外一个方向完全只有大模型（LM），然后再加上一些执行，可能是也能算虚拟机，但它是一个有限的虚拟机，它并不是可以导航（navigate）整个系统里的所有的程序包（Package），它是有些预设的程序包，然后去做这件事情的。

来源：Perplexity

Perplexity在浏览器里面做了一个相对比较另类的，它的浏览器不是说“我做一个能够导航浏览器的Agent”，而是说用户在使用浏览器的时候，它给你一个助手，让你去说“我需要在这个页面上做些什么”，然后去帮你执行。

02 四大底层架构解析，浏览器更万能，虚拟机更高效

泓君：你提到了基于浏览器（Browser-based）跟沙盒（Sandbox）的这两种搭建方式，那么现在AI Agent的搭建有哪几种底层架构？

注：“沙盒”（Sandbox）是限制 AI 行动范围的隔离环境，“虚拟机”（Virtual Machine / VM）是构建沙盒环境的一种方式。播客中，朱哲清以使用英文“Sandbox”为主，而主播泓君部分用中文“虚拟机”指代，本文稿根据具体语境翻译这组概念。

朱哲清：现在的Agent有四种大的方向：第一种是基于浏览器的Agent。第二种是浏览器加沙盒的Agent，在这种Agent里面，会有很多通过沙盒里面的代码以及命令行来完成的操作。第三种是只有沙盒，但是在沙盒内部有非常大的限制的那种Agent，主要通过大模型的能力去生成代码，并且只能运行特定类型的代码。最后一种，是可以横跨很多工具集成的Agent。

我认为浏览器（Browser）的意义在于，世界上所有的网页和互联网服务，都可以集中呈现在某个页面，所以我只需要我的Agent能够看到网页、去操作网页，我就可以完成我的任务。用户可以看到这个基于浏览器的Agent在页面上点了哪些地方，一页一页地去看浏览器是不是跟人一样在操作网页。

它的缺点是很慢，而且Token消耗特别高，原因在于你去看一个网页，等于把HTML的文件直接拉下来，可能还包含一些脚本（script），然后把它全部拉下来，从零开始全部读一遍，只为了操作一个网页。但是它确实是万能的。

来源：ChatGPT

朱哲清：第二种是沙盒（Sandbox）。沙盒的意义是可以线下写Python脚本（script），直接在沙盒环境里去跑脚本来完成一些任务。比如你要去做数据分析，你完全可以直接告诉沙盒说“我有这个文件，它的抬头是……”假设是销售文件，抬头是时间、每周销售、品类各种各样的抬头，你得到这个文件以后，直接问沙盒“能不能照着这个，帮我做一个每周对比的销售分析”。它给你写个Python脚本，然后就帮你运行、得到结果。

沙盒环境的好处在于，它可以运行任何不需要联网的、开源的程序包；但它的缺点在于，它很多情况下无法访问互联网，特别是那种需要认证的产品。比如新富策略，你要去登录你的Facebook，这些东西它都肯定做不到。

沙盒环境，来源：Sandboxie Plus

朱哲清：第三种，是大模型加沙盒放一块的Agent，它可能是限制一个大环境。Genspark是一个这样的例子，它并不给你完整的一个沙盒，连浏览器都没有。Genspark有一个大模型作为主体的推理过程，它写代码也完全靠这个大模型；有一个沙盒去运行一些代码、生成一些东西，然后再把它渲染出来。但那个沙盒甚至不能被称为一个沙盒，因为它是个非常有限的环境，只有三四个程序包。它是完全控制的，这个环境内部无法说“现在去下载一个开源的程序包”“现在需要临时去修改一张图片”等任务。如果在它原始的程序包设计里面没有，它自己不会下载一个程序包，然后去做这件事。

来源：Genspark

朱哲清：所以Genspark这种设计是，比如说像那种幻灯片Agent、表格Agent，它们在设计的时候把可用的包裹给限制住，不再让用户去用更多的程序包，是一个相对比较封闭的环境和工作流程——在限制环境下用一个大模型做主体写代码，同时用一个小的环境去执行。

最后一种，可能和我们还有以前的Zapier和UIPath这种，是工作流式的，但是工作流内部的每一个节点，是通过第三方服务提供商的直接集成来完成的。优势在于，可以保证每个服务的交付非常可靠。因为第三方服务，比如Facebook，是Facebook给我们的访问权限，不会出错。但与此同时，它有它的限制，如果用户想在个人的Facebook账户上发图片，那我们做不到，因为Facebook只让创作者和商业用户去自动化地发帖。

来源：Zapier

朱哲清：所以有这么四种类型，第二种和第三种之间的边界是很模糊的。唯一的区别在于：第二种的虚拟机是大模型执行完了以后，它所能够给你使用的虚拟机是几乎开放的，你自己可以选择说我要去下载新的程序包再去执行。所以虚拟机本身的能力是整个能力的主体。而第三种，可能是大模型的能力在现有程序包底下能生成什么代码，已经是限制了整个Agent能力的主体了。

03 用户体验差异化，速度与通用性的平衡艺术

泓君：从用户使用体验上来说，Pokee、Genspark、Manus和OpenAI的ChatGPT Agent有什么明显的区别吗？

朱哲清：有蛮多地方都还蛮不一样的。

Manus的体验是，它尽可能用一个虚拟机加上浏览器的环境，来搭建一个几乎让人觉得万能的环境。我有一个大模型作为一个规划主题，规划完、进入到浏览器以后，它是另外一个Agent，再完成浏览器导航，再总结得到的信息，再去进虚拟机做执行。如果有必要的话，它确实可以做很多事情、理论上可以涵盖市面上你所需要的所有功能。

与此同时，Manus的一个缺陷是被浏览器的能力所限制住了。比如，你要去真的发个帖，它做不到，因为它对于整个页面的导航，说我要去选择那个小的按钮，选择完之后去上传一个图片、生成一个视频等，这很难；你要把谷歌表格里的某个单元格改成某种格式，也比较难，因为注意力的空间太小了，浏览器是它的一个主要限制。

第二个缺陷是它很慢，这是Manus和ChatGPT Agent的一个通病，因为用了浏览器，所以它的速度会非常慢——30多分钟做一个任务。

来源：Manus

泓君：30多分钟我觉得还是快的。我最开始使用的时候可能是一两个小时，但那个时候非常早。

朱哲清：现在肯定比以前要快，因为整个基建什么的都上来了。但是它的瓶颈会在那，它的瓶颈甚至最后变成网页调用，你加载一个网页本身可能需要三四秒，这个是跳不掉的。

ChatGPT的优势在于Deep Research做得好，能够做出一个很详尽的报告。你如果通过这个报告再去执行某些任务，它会变得更全面一些。Manus的总体优势在于虚拟机的环境搭得可能比ChatGPT更好一些，但这个我还需要更详尽地去研究，因为我还不太清楚ChatGPT里面的虚拟机能做到什么程度，但我猜应该Manus在虚拟机里面已经花了很多精力去部署，应该会有一个比较小的优势。

来源：ChatGPT

朱哲清：Genspark一开始有个超级Agent，几乎可以做任何事情，但它后面能够处理的工具数量变得有限，所以它开始做模板。比如，幻灯片是一个Agent，AI调用是一个Agent，表格是一个Agent，浏览器也单独做了一个Agent。在同一个用例下面，它把用户体验作为核心目标，然后做一些模板。不管你问什么问题，它总是用这样的模板去生成幻灯片，总是用这些工具去搜索信息，使得它变得相对标化，越来越不是一个通用Agent。但它速度确实要比Manus和ChatGPT快一些，原因是它没有那么大的浏览器导航，同时它的虚拟机本身是非常有限制的，只有少量工具在某一个Agent里面。

泓君：这样是不是也更节省Token？

朱哲清：对，会相对节省一些Token。

泓君：它把大任务都拆成了细分的垂直的小任务。我猜它想做的是，当它把应用场景逐个完善新富策略，就可能类似于一个承载了很多小任务的大平台。

朱哲清：它会变成一个类似于微信小程序的存在。

Pokee最大的不同是，它可能是目前所有的Agent里面最快的——总体速度应该在市面上所有产品的4-10倍左右。我们有个正在开发中的Deep Research Agent，最后会有我们自己的Deep Research Agent，加上我们的执行Agent放在一块，总体体验会有大幅提升。

图源：Pokee

朱哲清：为什么可以做到？原因是我们不再需要用非常复杂的虚拟机和Tool Calling（工具调用），而是直接用第三方集成的SDK（软件开发工具包）和工具。通过我们自己的Tool Calling基础模型去调用这些函数，它的整体速度会大幅提升；没有了像MCP和现在市面上的Tool Calling里极其复杂的上下文问题，每次整体调用成本能削减50%-60%；再加上我们自己的上下文的工程，使得整个的成本在市面上至少跟OpenAI的ChatGPT Agent和Manus相比，是个数量级的差距；跟Genspark等垂直化的Agent相比，可能是几倍的差距。

在Token使用上，我们确实存在劣势，特别是跟基于浏览器的Agent相比，我们并不是完全万能的。比如要到Facebook、Instagram发帖，你必须是创作者账号或者是企业账户，个人账户没有办法发帖。

泓君：只有企业用户才能使用你们的Agent吗？因为比如说，你在接Instagram和Facebook接口的时候，它提供的是一个企业用户才能操作的界面吗？

来源：@Ali Mirza（YouTube）

朱哲清：是创作者或者企业账户。他们希望能够更多地去创作，但平台不希望个人用户全都用Agent发帖。这是符合商业逻辑的，因为如果所有个人用户都通过一个Agent，想办法用浏览器去破解Facebook、Instagram账户，或者破解某一个平台，比如通过Agent爬虫网页来完成一个任务，那以后要是没人上Facebook和Instagram了，对于平台来说就是一个损失；它们希望个人用户仍然每天去Facebook和Instagram上浏览帖子，然后再去发帖，这样能有参与度。

以前，有人通过非常复杂的写代码的方式完成产品上传，那现在会有人直接写一段文字，然后直接把视频创意上传到这些平台，别的平台也一样。它给你开放的权限，是他们认为开发者和非消费者用户真正最需要、用得上的一些工具。如果你可以把这些都放进Agent里面，那些原来会使用这些工具的人，它会转过来说，我写一行提示词就行了，不再需要写那么多代码。

04 专业端VS非专业端，技术选择分野

泓君：在我的理解中，像Manus、Genspark还有ChatGPT Agent，它们的商业模式是ToC的，而你的商业模式听起来更偏ToB。

朱哲清：现在这个时代下，B端和C端的模糊性很高，但我们的产品一定是专业人士来使用的。对于专业人士以下的消费者用户，它们使用一款非常省时间的AI Agent的概率不是很高，这也是市面上很多AI Agent的感知非常差的原因。因为它没有重复性，很多的工作流用一次就结束了。而我们目前的很多用户每周都会跑一模一样的工作，我们发现这种使用有重复性。

来源：Pokee

泓君：这个是不是也很取决于平台会给你们开放什么样的SDK（软件开发工具包）和API（应用程序接口）？假设我每天的微信太多了，希望有一个Agent帮我管理所有信息、回复一些比较基础的信息，前提还是微信要给这样的Agent开放它的接口。那它们愿意把这些接口开放给开发者吗？

朱哲清：在美国，像这种开发者的社区，是很多大公司、特别是科技公司所崇尚的一个方向，所以大多数公司都有非常完善的接口和开发工具包，甚至于说他们给到你的是个非常简单的爬虫结构，它也不给你Python 开发工具包之类。国内公司可能相对差一些，很多接口不开放给你。但微信的话，比如企业微信创作者那种级别的微信，也会把接口放给你，你也可以自动回复，什么都有。

国内的整个生态也在慢慢在开放，特别是MCP（多智能体协作协议）这波出来了以后，有很多公司都开始被迫开放他们的SDK跟API，比如高德地图是一个例子。之前可能没有那么开放的高德地图，后面在MCP出来了以后，它首先把地图生态完全打开了，有蛮多这样的例子。目前，有些公司给我们开放的API或者接口是独家的，但有一些不是。

来源：高德开放平台

朱哲清：总体来说，这个商业模式一定是偏专业人士的，原因在于，许多C端场景具有极强的浏览器导向特征。比如说你去浏览网页规划出差，相关需求往往是标准化的——像每两周需飞往湾区、且每次入住同一家酒店，那系统可以每两周帮你买一次这个机票。

但如果是一个消费者出去旅行，它就有很多变数。我可能是为了探索新东西，住宿上希望尝试新的酒店，航班选择也可能存在变数，比如说今天我刚发了奖金，我就要飞商务舱了。所以这种用例它本身更适合基于浏览器的Agent，因为用户面前有笔记本电脑，可以开浏览器去做事情。

05 Agent重塑互联网入口，流量分发的深度变革

泓君：在你跟大公司合作的过程中，它们开放API接口的动力是什么？

朱哲清：首先，整个Agent浪潮会从某种意义上取代正常的Web流量，过往可能是一个人打开一个浏览器，然后在谷歌搜索里面打入一段搜索，得到这个搜索结果以后，点一个网页，再去做某件事情。但未来可能是，消费者端你打开ChatGPT，专业人士端你打开Pokee，你可能打一段字说，“今天早上我看到了回复CEO关于用户增长的采访，你能不能直接把YouTube上面的脚本直接拉下来，帮我写一段报告，告诉我它增长策略的关键要点是什么？”然后它直接做完了整个流程——我从来没有打开过YouTube，一个Agent从头到尾做完了这件事。

可能你以后购物的用例也是一样，你可能从头到尾只是打开了ChatGPT，说“我明天要去一个晚宴，需要一套正装”。它已经知道了你的身材是什么样子的，就自动帮你找到了最合适的衣服，并试穿在你的身上。你看一眼，觉得好，然后说现在有个折扣，就付款了，可能是这样的流程。

来源：Wired

它给我们的启示是：以前的工作流已经被改变了，它们不再是通过浏览器去启动整个工作流的开端，去下单或者获得信息，然后再进入另外一个网页进行操作。在接下来一到两年内，大多数门户网站，无论电商、搜索、视频网站，还是其他门户网站，流量一定会迅速下降，而入口变成了各个方向的Agent。

这就是当时谷歌要推出A2A(Agent-to-Agent Protocol，代理间通信协议)的原因。每一家公司都可能会有自己的Agent，可能是Agent跟Agent之间的交互，如果它能占用这个协议，在Gemini里抢先完成协议部署，最后它就会是最大的赢家，因为它成为了Agent入口。ChatGPT、Claude和我们Pokee也是一样，推出协议的核心目的是占据Agent入口。

泓君：你们为什么想自己推出协议，而不是接一个标准的MCP协议？这样大家都是统一用的，你也可以在一个更大的生态里直接接入很多已经接好了的APP。

朱哲清：MCP现在的可用性很差：当前市面上应该有接近2万个MCP了，其中可用的MCP大概不到200个，而且大多数MCP都无人维护，这导致大多数公司不愿意花时间去做MCP协议。

我们的目标是，公司不再需要做MCP协议，你也不需要自己去做一个MCP 服务器，就直接把开发API给我们，我们处理剩下的事。所以在服务提供商层面，公司什么也不用干，就可以得到额外的流量入口。

来源：腾讯云官方社区

泓君：未来在接入了Agent以后，互联网会发生什么样的形态变化？你觉得未来对创作者的影响是什么？如果我现在做一档播客，比如我们上一期内容里面，有一个腾讯算法广告大赛的口播广告。只有更多人听这个播客，大家才可以听到这个广告，才能支撑一个播客的商业模式运转下去、把这档节目持续运营下去。还有人在下面说，这期播客为什么没有开AI总结？如果没有这样一个过程，观众就不去听这期播客了，就直接去看AI总结。这对广告来说是一种流量的折损。

朱哲清：我觉得广告这个行业会永远存在，但它的形式会发生改变。当前，市面上有很多专注于广告的AI公司，它们想要去看在大语言模型时代或者Agent时代，广告要如何植入。

我举个简单例子，在播客里插播广告这件事，未来会变成什么样？现在的播客大多数除了平台方收你钱以外，播客提供者本身是不收费的。比如说《硅谷101》是一个播客，但是大家都是免费听的，如果你在YouTube上只是用了YouTube的广告，然后YouTube通过广告给你们分成。

来源：@TeamYouTube（X）

朱哲清：那未来可能变成我们需要去访问你的播客，它本身的知识产权就是值钱的。每一次通过调用也好，通过网页访问也好，去找到你们这个播客的时候，或者是得到你这个信息的那一刻，任何的Agent方就要向你付款，你不再需要去担任广告流量的负责方，广告是由Agent来完成的。Agent 获取信息后，在给用户推荐其他Agent时，比如让用户选哪个Agent试用时，可以通过排名推荐收被推荐方的钱。而支持每个API、每个第三方的插件的产品本身，或者说知识产权本身是可以直接收费的。

所以对于创作者生态以及SaaS(Software as a Service，软件即服务)生态，从某种意义上来说是变好了，而不是变差了。你不再需要去在谷歌上面投广告，也不再需要去免费地把你的内容发给YouTube，让它去帮你投放，而是有一个Agent直接向你付费，通过它自己的广告机制去覆盖它自己的成本。我不觉得你们会受到很大的冲击。

泓君：整体上我觉得流量分成的模式会变得越来越弱。然后，如果Agent调用了很多创作者的内容，怎么给创作者付费？这是未来可能会讨论的一个问题。我稍微有一点疑问的是。基于流量的这套方式，比如说你有推荐算法，一个页面可以显示10条播客的内容或者视频信息，但是Agent在回答一个问题的时候，还是比较精准聚焦，可能引用的范围就相对更小了。

传统搜索引擎推荐，来源：wordstream

朱哲清：上礼拜在ICML(International Conference on Machine Learning，机器学习国际会议)的时候，有一个专门做推荐系统的人，我们俩聊到了这件事情。我当时说，推荐系统的大方向可能会受到巨大挤压。

在Agent的整个框架下面，它还是个推荐系统的一个端到端的决策过程，但是它每一次给你的交互只是给一条信息的结果，或者说几条最相关信息的结果。这个时候它的整个决策线不再是按照排行第一、第二、第三这样的方式去决策了，而是时间是它的决策点，因为一个人和一个Agent之间的交互总时长是基本固定的。Agent好，我就会交互时间久一点，它的目标可能是在每一个时间点上，我给你推荐的东西可以让你所消费的时间和能够得到的回报成正比。这个时候，它的整个原始的推荐系统算法可能就不那么成立了，因为原来推荐系统算法是说，我可能每一条点击的概率是跟排行成正比的。

而现在变成，我每一次给你推荐或者给你回复的这个信息，基本上都是你必定会去点的东西，但是你会有第二轮跟我交互的过程。下一次你花这个时间跟我交互，我所占用这个时间成本，给你推荐的这一条就必须是最精确的。这样会使得你跟我有更多的交互，所以它的目标可能就从“有五条、十条在一个页面给你呈现”，变成了“有五轮、十轮的对话，每一轮的目标是让你跟我做下一轮交互”。这个时候就跟传统推荐系统的算法完全不一样。