Pokee.ai 朱哲清的 Agent 造法：强化学习作后端，语言模型作前端
欢迎收听本期晚点聊。我是晚点的作者孙海宁。今天很开心能和曼琪一起录制本期节目。
几乎所有主流AI agent的产品都把大语言模型或者它的多模态升级版当作角色中的核心。在用户使用界面下，是一个或几个大语言模型位居中心，编排工作调用工具。但也有不同的路。
我们的嘉宾Poke AI的创始人朱哲青Bill认为大语言模型只是agent理解人类需求，向人类递交产出的前端，后端决策。完成任务则可以靠用强化学习方法训练的、不依赖自然语言的模型完成。Bill提到把大语言模型当作大脑时，agent调用工具的能力有限。这是因为大语言模型使用工具时，需要先把工具描述、输入输出等相关信息作为上下文输入模型，而大语言模型支持的上下文长度有限。把agent决策中大语言模型换成另一个由强化学习方法训练的模型，可以解决这个问题。
本期播客中Bill还提到，优秀的通用agent需要具备四个要素：实现任务比人快，无需人工干预，能读取信息也能写入信息，成本低。agent产品的壁垒不在技术，而在于和用户的工作流深度结合。此外，我们还和Bill聊了他对通用agent接下来竞争态势的判断，以及他在强化学习还没有成为显学时便相信强化学习潜力的原因。
我们的对话将从Bill一边读强化学习方向的博士，一边在Meta工作的经历聊起。最后说一些声音上的注释：被有本科就开始在海外留学，不太熟悉常用部分专业名词的中文表达。本期多次提到的RL是Reinforcement Learning的缩写，即强化学习。和强化学习相关的表述还有Policy，即策略，指强化学习模型完成任务的方式；Reward Model，即奖励模型，用于评价某个决策的好坏；Ground Truth，即真值，指训练模型时使用的标准答案；Exploration，即探索，探索可能完成任务的新路径，是强化学习模型的一类动作。概念是Exploitation，即利用，利用已知信息选择最优的动作。此外，对话中提到的Prosumer，即Professional Consumer，是指专业用户；Context Length是指大模型的上下文长度。这些注释也能在本期的Show Notes中看到。
下面我们就正式开启本期节目吧。那请哲青Bill为听众简单介绍一下自己的经历可以吗？
我先讲讲我自己过去七年的事情。就是我2014年来到美国，然后是在Duke这边完成的CS本科。后面就立刻加入了Meta。在Meta的话，前三年多的时间是在2B的推研系统的业务这边。我们当时是从零开始搭建了一整套B2B的推研系统，包括正常的商业增长和广告增长的推研系统业务。当时也是刚开始有基于深度学习的推研系统，然后我们等于是在团队把一整套的推研系统就做出来。
后面的三年多转到了AI这边，做Apply Reinforcement Learning，就是应用强化学习这个团队的负责人，主要负责的业务就是把强化学习落地到整个Meta内部所有的产品线上，包括广告、推研系统、Reels短视频、Data Infra这一系列的产品上。与此同时，我们也开源了Meta的一个核心的强化学习框架，叫PURL，这是我们落地所有产品的一个核心机制。当时发出来以后，还是非常火的，大家都觉得这个方向和modularization做得特别好。与此同时我们也发了一些paper，所以我们其实后面三年在强化学习方面，在强化学习火之前其实已经做出了很大的硬派，估算下来每年将近5亿美金的年收入是由强化学习算法带来的，在广告上的硬派尤其突出，推荐系统和短视频这边也有很大的业务的贡献。所以其实我们在强化学习由Deepseek带火之前，已经有很大的一个硬派由强化学习带来的。
然后在Meta工作同时，我也在Stanford把强化学习的PhD读了，这两个是并行的一个时间状态。像你这样，就是一边在Meta，实际上你是全职工作，一边读博士，这种在同学同事之间常见吗？应该是不存在的。
那你当时是怎么达成这种安排？你怎么说服公司和你学校的老板、导师都接受这样的状态呢？这个是比较机缘巧合的东西，算是可遇不可求的。我所知道Berkeley好像有一个学生是这样的，NYU其实那个Proplexity的CTO他也干了一件类似的事情，但他在公司属于不算完全全职，工作的部分与他的PhD就非常强相关，因为他的导师是同一个人。
所以，基本上他做research就只聚焦于PhD的那个东西。其实我有很多的alignment，是我跟我在公司的老板、跟我自己的PhD老师align的，大家都感兴趣，并想落地。公司也同意这个事情，学校也觉得这个是可行，然后才能做这些事情。但是工作量非常大，一个礼拜大概110个小时的工作量，所以基本上除了睡觉以外，就是在做research工作。这五年你选了一个hard模式吧？
对，六年多。这段时间可能工作量就跟创业没什么太大区别，甚至比创业还艰辛一点，因为创业你至少还能delegate给别人。那段时间，你早期尤其是PhD的活，没有任何人可以delegate，只能自己干。而在我升TL和manager之前，也不能delegate给任何人，也得自己做。所以有很多事情只能自己苦干，也没有任何巧劲可以使。创业至少还有一点巧劲，雇个人，能把这些活给干了。
那你觉得这个过程，因为它是一个比较特殊的经历吗，你觉得给你带来什么呢？我觉得一个很重要的点是时间管理，这个其实跟我们现在创业的idea很相关。当年就希望，如果很多莫名其妙的事可以有AI帮我做了的话，我其实觉得会省下很多时间。时间管理的一个横向点就在于，你要知道你的priority是什么，什么时候应该摒弃一些东西，什么东西是值得花时间做的。这件事情是非常重要的一个career lesson。
就是说很多时候有些事情，你花20%的精力做到80分就可以了，而不用去100%的精力做到100分；而有些事情是非常非常关键的，你就需要花100%的精力做到100分；还有些事情你可能觉得可有可无的，甚至用0%的精力把它抛弃掉。怎么去取舍这件事情其实非常重要。如果每件事情都想要拿到的话，我觉得我可能读不下来这个PhD。
第二个事情可能就是要找准方向。其实我在PhD当中走了很多弯路，因为落地这件事情在当年不是一个很火的话题，而且很多人都不看好这个方向。甚至于我们当时的director有一阵子，在我加入Meta的212组之前要把这个组给关掉，我看到这个组要被关掉。然后原来带这个组的老板走了以后，我去找director说，别关这个组，我来带。这个组原来有20多号人，减到最后只剩三个人，然后我去带这个组以后再回到十几个人。
所以当中其实有很多很多弯路，但是你要找准方向以后得坚持下去。不停的换方向会有很大的沉没成本。你是中间试过想换方向吗？我倒没有试过换方向，从来没有想过这件事情，一定是以212落地为核心的目标，就一直走快十年了。
那你说的弯路是指什么？你说PhD中间有很多弯路？就是会有很多的诱惑。比如说我当时有人拉我去做早期的language model，做chatbot那种，也有人去找我做3D的vaging model，当时还有人找我做安全模型。这些东西我当时最后只做了一小段时间就停下来了，因为我觉得跟我的核心路径没什么太大关系。你要知道这个东西什么时候要cut off，不能让成本无限增加。
因为现在大语言模型其实是一个显学，很多人都在做这个方向。你说当时有人找你去做早期的大语言模型，还有chatbot的事情，你不觉得那是个好机会吗？人总不能这样回头去看这种事情的，比如当时做了，变成第一个做出instructivity的人，那我肯定会觉得那比现在更牛的一个路径了，对吧？但是你永远不能假设，当时我也不了解语言模型，最了解的还是RL这条路。
我只想把这条路做好，做精英，真的能落地，能在业界有reputation，真的有一些work是大家所熟知的东西，我觉得是更重要的事情。我觉得学术研究有一点确实挺有意思的，就是怎么选方向。因为每个方向都会经历沉浮，起起落落。你怎么在这个过程中间一直往下走？
比如说你之前跟那个图灵奖得主，强化学习之父Rich Sutton，交流比较多，你也觉得他给你很多启发。对，他早年其实是非常不顺利的，早年有将近四年时间，整个research无人问津。你能想象现在图灵奖得主，当年没有人理他的research，有四年时间没有一个教职愿意找他？当年没有人认为RL这个东西是有用的，到今天所有人都觉得RL是个must have。
这个过程的转变其实是非常inspiring的。其实当年Hinton也遇到过类似的情况，早期推deep neural network时，所有人都觉得这太无稽了，没有人会觉得这个东西有未来。所以我觉得最大的inspiration在于，如果你的思维框架认为某个方向是正确的，你可能就得坚持下去。
有时候你会认为，很多人都可以跟你做一样的事情，他们也能够做得很好，你觉得你可能没有优势，但别人可能就没有坚持下来做你这个方向，你可能最后还是成功了。很多时候可能还是得轴一点，如果自己有坚信的东西，至少得把它走通，或者说你真的证明了别人已经做出来，自己没有办法去takeover，可能才能问OK，what’s my next step。而在过程中不停地质疑自己，可能只会给自己带来过多的noise，阻碍发展。
所以Bill，刚开始研究RL的时候，RL已经是一门显学了吗？可以给听众讲讲你在念书的时候，学界对RL态度的变化。最早期的时候，我是跟Ron Parr做的RL，最早就是做planning，就是规划的研究。其实当时deep RL还没有那么火。Deep RL是2016年的时候，因为AlphaGo、AlphaZero，这一套东西变得活跃下来。这三个迭代其实花了蛮久时间。
当时deep RL这件事本身不是完全形成共识，其实还是在发酵的过程中。我当时还是与Fundamental的去学习planning的landscape，在做什么，就是现代规划能力与tree search相关，包括Monticolor tree search这一段。比较相关的一些研究。到了Stanford以后，发现当时deep RL已经形成气候，于是Monticolor tree search这套规划能力在新的deep RL的时代，并没有那么重要。当然，后面也证明它还是蛮重要的能力。
然后我就去找Ben McRoy读RL的PhD。 然后Ben McRoy可能做的东西跟RMonticolor就没有什么太大关系了，但是他俩呢是很好的朋友。所以当时我去Ben这边读PhD是RMonticolor推荐的。
然后在Ben这边读PhD的时候是更多的做sample efficiency，就是当时我们主要研究的是如何把那个reverse scaling law，就是把数据需求从最早的很高的数据需求不停地往下拉，就是拉到现在可以完全trackable的一个数据需求的状态，让RL算法真正可以落地。因为RL算法的一个核心的痛点就在于是说你所需要的交互数据量是非常非常大的，因为你所规划的并不只是一个单步的事情，而是一个非常非常多步的一个事情。
所以它所需要的数据量跟你的整个规划的整个steps的数量以及你有多少个action多少个state都正相关的一个东西。所以问题更复杂的情况下，你所需要的数据量就无限地往上找。从这个角度来说，你如何从一个比如说linear的scaling变成一个square root的scaling，这就变得非常非常重要。
比如说你有1万个工具可以调用，每一个工具你要用100个数据点可以学会这个工具，然后你要1万个工具要学会的话，你要100万个。那有几个step，第一个是你能不能泛化，就是从工具到工具的泛化。你可能可以比如说1万个缩小到5000个或者说1000个，然后你是不是可以把泛化完的数据，在不只是直接scale到1000个，而是说square root it，比如说变成根号1000。
就是说你的所有的理解这些1000个或者1万个action的数据量并不跟它本身的工具的数量乘成比，而是说跟它的开根号的工具乘成比。那这个东西的做法呢就是说怎么去有效探索，就是说我每去找这个工具本身去用一次，我都是有地方是在去用这个工具。
就是说我已经知道这个工具对于这件事情肯定不好用的情况下，我不要再去用它了。对吧，那你所需要的数据量因为这样更intelligent的这种我们叫exploration，就会使它所需要的数据量大幅地去压缩了。这件事情不只是对于工具本身，对于这个部数也是一样的。
当你的部数越长的时候，探索就变得更重要了。比如说有两条路径是很相近的，然后有一条路径已经证明肯定不可行了，那这条相近的路径，而且我们所知道它的nature也相近的情况下，你是不是就不用去探索它了，那你就可以去省掉探索一条路径的这个事情。
所以我们要做的事情就是说能不能从现有的数据和现有的知识和现有的knowledge上面去，对于这个解决的问题这个knowledge上面去distill说，哪些东西是已经探索过的，哪些东西是没有任何价值去探索的，哪些东西是值得去探索去解决我们未知的。只去探索那些解决未知的东西，而摒弃去探索那些重复性劳动，使得我们所需要训练的总数据量大幅缩减。
能达到同样结果的情况下，用的数据量可以比如说原来的十分之一甚至百分之一，这就是你在本科然后到博士的时候主要去研究的方向。对博士的时候主要做的就是这件事情，然后同时把这个技术想办法落地到实际环境当中去。
强化学系这个领域很长一段时间都是被大家诟病为说，可能所有的研究员自己在自己玩的一个。强化学系这个community这个社区内部在那自嗨的一个feel，但是大家看到了最近几年却是强化学系开始take off。那我们当时其实核心就是找到说怎么落地是最robust，真的能找到落地路径这么一件事情。所以在Meta在读博的时候主要关注的都是这一点。
然后在这个过程当中其实我就发现强化学系的可能potential，就它所带来的潜力远不止于说只是帮Meta的广告带来个1%、2%的revenue的提升， 它核心可能能够更大的幅度驱动的可能是一个新的AI agent或者说AI技术的景峰。因为我们都说强化学系是super intelligence的一个核心驱动力。
所以从我们的角度来说，就特别是从我个人的角度来说，强化学系的impact肯定不止于在公司内部这么一目三分地。 所以当时我们其实我跟我的朋友、投资人、然后我自己的导师其实都有简单聊过我自己的想法。其实我一直都思考说，既然强化学习能够帮助AI带来这种非常强的推力和规划能力，那能不能真的就用强化学系为核心，就不依赖语言模型的情况下，做出一个有强规划和推理能力以及工具调用能力的agent。
当时我跟我的导师和一些投资人聊完以后，大家都觉得这个idea比较exciting。投资人这边当时我聊的时候是去年90月份的时候，那时候其实agent还不火，RL也不火。那当时大家可能就觉得说这个是make sense的，但大多数VC可能都不能理解说RL是什么或者agent是什么，少数的VC可能理解了说OK，这个东西可能有一些potential在里面。
可能学界和业界的人听到我这个想法以后都觉得非常promising，甚至有很多人我10月份出来了以后都直接recharge给我说能不能加入这家公司。当时我还没有透露我们融资的各种情况的情况下，大家都非常有加入的倾向，所以我觉得这个大方向还是非常有潜力的。
总体来说可能整个创业的驱动力就在deep think我之前。我们就看到了RL在整个业界落地以及agent方向的一个巨大的潜力。为什么你觉得RL是deep think带活的不是OE带活的？OE其实他说了他是RL驱动的，但大家都不知道他背后的二要逻辑是什么。
大多数的猜测是在于OE可能用的是一个叫inference time reinforcement learning。就是说他可能在训练的时候做的还是RHF，但在inference time的时候做了一个chain of thought，就是Sweden的multicolor tree search style的一个做法。这个其实到目前为止都没有任何定论，因为OE自己的人也从来没说过这事，但从他的推理速度各方面来看，确实大概率他们在训练的时候应该没有做太多的优化，更多的是所有的effort都放在了就是inference，就是推理端。
然后deep think带为什么火的原因，是因为它其实核心就回到了可能当年alpha go到alpha zero之间的一个状态，就是说我不需要在非常复杂的人为去标注每一个点的performance，用一个像RU一样的一个东西就可以帮助你去判断说这个agent在某一次sequential的action taking的这个过程当中，你做的是不是好。
那它就解决两个问题吧，一个是在RHF这个过程当中你学大量的人为标注去训练一个reward model。那第二呢，就是你的整个训练速度会变得非常快，就是说我每次sequential action take完了以后所得到的结果可以立刻被一个几乎可以是ground truth的一个reward去evaluate，然后再去训练这么一个agent。因此它几乎就回到了当年alpha go和alpha zero这个中间带。
我还没有到selfplay的阶段，但我可以在没有外界干预的情况下就能够训练出一个超过现有最好模型的一个模型了。当然了，它有自己的问题在，比如说deepseek r10这个模型它是纯靠rl的rubus reward model，这个模型本身呢从某种意义上来说是人类不可读的一个东西，很多时候它output的东西就是jibberish。
就是它可能从rubus reward的这个系统里面可以score一直在往上涨，但你真的把那个output拿出来给人读，人可能就读不懂他在说什么。对，所以他后面又做了，从某种意义上来说他又包了一层，就是RHF的那一层。所以我为什么说它还没有完全到alpha zero的那个状态的原因，它需要大量的human的heuristics，就是人类的一些经验化的东西在里面去帮助它去找到一个人类比较喜欢的一个状态。
所以我为什么会把它放在这个阶段的原因，当然这个类也不是100%准确。你可以和我们的听友简单解释一下用rl来作为agent的核心。它大概是个什么概念，然后包括也可以对比一下就我们的听友可能知道的一些agent，比如像deep research或者说大家最近讨论比较多的malus，这些agent它又可能是以什么为核心的。
我觉得这个又牵扯回agent本质是什么，就是大家把很多不同的东西都称之为agent。那从我的概念上来说，我们设想的rl agent是以rl为核心做所有决策驱动的一个agent。它不再是说我只是输出一段文字，然后这段文字当中有一部分是工具调用，然后这段工具调用是嵌套在整个文字当中的一件事情。
而我们会认为说所有的planning和reasoning以及工具调用的过程是一个抽象化的过程。就是说它可能有一个concept after一个concept规划的能力，在完成这个规划以后，其中有一部分是某种工具，其中有一部分可能就是information retrieval。就是它的整个构想方式和现有的agent都不太一样，这就是为什么agent的核心模型都不是一个语言模型的原因。
那这个从用户角度怎么定义呢？因为可能对大部分人来说他其实不在意怎么实现。那我刚刚说的是偏技术层面的，那偏用户层面的话，我个人认为很重要的一点就在于说，无论是deep research还是manus以后，它仍然是一个surfed internet的一个状态，那它没有一个写入互联网的能力。
比如说你有facebook账户，或者说你有你微信，那么你所要的结果不只是说它可以从某一个人的facebook主页或者说从某一个人的某一个页面上去抓取一些信息，然后总结一下或者写入一个网页，而说你可能想要在facebook上面直接发个帖子，或者说你要在linkedin上面发一个招聘帖，或者说你要去amazon上面拉一个产品的review，并且把它post到某一个地方去，或者放到你自己的烧饭网站上。
那像这种内容的action都是真正要写入互联网的这种action，那这种能力是目前大多数也许都不具有的。这个和lm您觉得是矛盾的吗？因为如果我给它多一个function，那好像它也可以完成写入的功能。lm你可能可以试一下，一般来说你如果看市面上，如果你要横跨互联网大多数工具的话，可能有上千个工具，几千个工具。
那其实我们在用最好的language model上100个，甚至上50个工具的时候，它就开始hallucinate，就开始产生幻觉了，因为它的context length和attention就那么长。你需要比如说50工具，每个工具有比如说1000个token去描述它，那就是5万个token的光工具描述就是5万个token，然后你还有上下文，你还有agent memory，然后后面还有用户的给你的prompt。
这些东西全夹在一块，放进你的整个给到lm的prompt里面，让它去选择一个工具并去调用它，这是非常难的。更别说我们做的不是一个单一工具调用，我们是一个比如十步十几步的工具调用。那你想想你完成一部工具，然后你把这个工具调用做完了以后，你再把剩下已经出来的结果，可能说你拉了一篇文章出来，然后这篇文章再放回你的prompt里面，可能这篇文章本身又有一万个token，然后再放回去，再去执行下一步。
你想想如果是十几步下来，那就是上百万个token一次任务，百分之一百的所有的lm都会产生换句。所以一个核心点就是为什么我不用语言模型作为核心决策点的原因，就是因为想要规避掉这种问题。OpenAI的operator在功能上，它是希望能写入互联网的。 对不对
它是希望能做一些操作的，但operator成功率非常低，对它不是很好用。目前，其实从模拟上它比manus要强一点。就manus写入的能力其实没有operator强，但是manus的deep research和整合信息的功能更强一些。
所以它可以做到生成网页，生成内容的基础是大量的搜索和fetch information，然后就生成的内容相对比较好。然后operator它执行能力其实要比manus更强一点。你让它做一些比较基础的操作它能做，但是它又没有deep research的功能。
所以manus等于是把两个功能嵌套在一块了。就是它的一部分执行功能和检索功能是由网页带来的，然后另一部分信息抓取的功能是一部分网页和一部分线程工具，嵌套的deep research的工具嵌套在一块做到的。所以它是一个非常好的工程产品。
但我们要想解决的是更长期的问题。就是说如果长期以往互联网不再是互联网，它没有任何的用户前端了，你要怎么去解决这个问题。就是人跟互联网的交互不再由一个非常漂亮的前端完成，而是你直接跟一个agent接口说：我要干这么一二三四四件事情，你帮我做。
那怎么样去能够帮助用户在没有任何前端的情况下完成任务，同时能够让用户理解这个agent干了些什么。而且agent跟人类可以更可能有高效的去交互，这个是我们想解决的问题。
就是说从第一性原理来说，如果agent可以代替所有人类完成所有的这种操作型的事情的话，那UI的存在其实并不是很重要。今天的UI是帮助人类去理解这些信息和信息流的，而agent所要去理解这些信息流，你就给他完全RAW的文字和图片就好。它根本就不需要有一个非常fancy的前端，弄一大堆JavaScript，然后只会confuse agent，对吧。它也不需要看这些东西，所以这是我们想解决的问题。
就是说你觉得应对未来你刚刚说的那个比较中局的环境，其实RL你觉得是一个长期更有潜力的方向。我需要step back，就是RL是一个通用的工具。他在应对任何环境下都有他自己的优势在，而LM本身是为了帮助你去理解文字来进行操作的。但是文字的长度总有他的限制，就是他的整个context length和你的tension机制，总和你的模型大小是有正相关的。当你的信息量无穷大以及你有大量的memory的储存的时候，那你就需要想办法在一个相对比较抽象的环境当中去做决策。
我们希望说能够通过RL的方式去把整个决策层给抽象出来，然后把工具的规划以及调用完全由RL单一模型来完成，原层留着单纯作为理解和交互的功能。就相当于我们认为长期来说，LM可能会是一个UI，它可能是互联网的frontend，但互联网的backend所有的工具的交互以及connection是由某种protocol加上某种决策机制来完成的。
比如说你告诉agent，我今天早上去买一个菜，然后他可能都把这个语意理解下来后去pass给一个RL模型。RL模型说这个用户想要做的是买菜并在这个服务提供商这边去买，然后他就通过某个机制把这个信息传达给对方的某一个agent，就可能是B端的agent。这个B端agent收到这个信息以后，再把它从他们的某个数据库里面拉出来说，如果这个用户要在这个地方买这样的菜，需要在哪里可以买到。
然后把这个信息抓取回来以后，发一个request给比如说可能线下的某一个人，然后这个人收到这个request后就把东西送到这个人的家里。而这个过程当中是不一定要用文字信息来传输的，这个过程当中完全可以是由数据库operation加上你可能后端的一些信息的流动来完成的。
然后完成了这些所有的操作回给用户端的可能是一个偏文字的东西，在转化成文字说：OK，我已经帮你叫了这个人把你的菜送到了这个地点，然后你自己去取。
所以我们可能长期以来比较相信的是，未来的后端所有东西都会相对比较黑核化，而不是全部由文字的形式来输出。Bill，你的意思其实是像大语言模型更像一个翻译器，或者说人和机器交互解明，RL更像一个规划器一样的东西是这个意思吗？你可以这么理解。
但是我需要解释的是RL跟语言模型本身是不冲突的。你可以用RL来训练语言模型，但你也可以用RL来训练一个非语言模型，来解决更抽象的环境里面的任务，就像你用RL去做机器人一样。
比如说你把BLM里面的规划过程变成RL的一个决策，一个policy。在这个过程当中其实它也不是一个语言模型。RL是一个通用的工具，它在规划和推理能力上面很强，所以你可以用它来做任何抽象的规划以及决策的事情。这也是为什么我们决定说前端仍然由LM来完成，但后端就完完全全就不用LM。
刚才提到一个很好的问题，就是LM它其实没有办法承载太多的工具。就比如说你提到50个以上，它可能就记不清或是产生幻觉了。那这个是可以解决的吗？你觉得还是说这个长期来看也是不能解决的呢？这个事情你要说我有无限的计算量，然后我永远可以去scale我的模型大小，那eventory当然是可以的。
因为attention的复杂度基本上和你的模型大小基本上是可以成正比的。就是说你需要关注的点的数量和你的模型大小基本上是可以同比例去scale的。在这种情况下，如果我们假设有无限的计算资源以及无限的scaling，那确实是可以做到这一点。
但是前提就是我们没有，就是说你不能假设说永远的我们就不停地去扔计算资源去完成更复杂的任务。因为大多数情况下，未来的复杂任务可能变得更抽象，或者说你的工具都不停地几何几数的在往上涨，而LM只能比如说linearly去增长它的context lens。
所以它不可能说永远无止境的去把世界上所有的工具都包进来。就你可以想象一下，未来你可能平时想到的所有的工具，包括垂直领域的所有的工具都能够被集成在一个系统里面。那在这种情况下，它可能就并不是一个非常linear scale的东西，它可能是个信息爆炸式的工具的使用的事情。
那刚刚的假设其实是工具是无限多的。会不会有另外一种产品就是说，其实LM它不需要掌握50个、100个工具，而是说我掌握10个能造工具的工具。比如说我会Python代码写得非常好，我就可以自己造工具。
这个事是个很好的问题。那其实有一个非常简单的counter argument，就是你可以想象一下，他可以写Python，把common sense的一个tool写得很好。但是比如说你要让LM去写一个工具，能够直接去帮你去schedule一个zoom meeting，或者帮你schedule一个腾讯会议，那它根本就没有见过腾讯会议的documentation，它怎么能够写好这个任务呢？
所以这个东西除非你用browser，是一个common sense的东西可以做。那用browser回到了原来的问题，就是它变得非常复杂，然后token数量非常高，操作的速度还比人都慢，那何必要用browser呢？
那如果是让它自己写代码去完成这件事情，它没有见过这种documentation，那它如何又能够把这个代码写好了？你等于说我要重新再去训练一整遍language model，只为了去调用一些新的工具而已。
所以这个逻辑上面就是说，如何能够保证原模型做一个基座，或者说用户交流的一个媒介的情况下，在不重新训练它的情况下，我已有工具是不是能够完全自主调用。我甚至有成千上万个工具都会无限地去scale，这可能是我们的目标。
那接下来可以请Bill给听众简讲PokeAI具体的agent产品。我最近试了一下，感觉它的交互界面和其他的agent长得差不多，就是屏幕分两半，左边是和agent交互的聊天界面，右边是呈现agent执行任务的结果。
PokeAI和人类交互的方式在设计方面有什么不一样吗？我们的目标还是能够以非常简单的方式让用户能够体验到说，什么任务已经被完成了，什么任务没有被完成。那可能有一些不太一样的一点是说，我们是会在执行之前询问用户整个任务的完成情况和整个任务的规划情况是否是用户满意的，然后再执行。
目前大多数的agent的体验方式都是我们叫类似于free flow的体验方式，就是说你不知道agent每一步会干什么，而是他自己就会慢慢roll out，一步一步一步往外打开，做各种各样的function或call，或者说执行各种各样的生成式的任务。而由于我们的任务都会直接写入用户的互联网账户和他们自己生活和工作当中的各种各样的平台，所以我希望说我们所执行的操作的规划是用户所满意的。
所以有了这么一个设计，就是多了一步用户的approval的过程。然后与此同时的话，还有一点，不知道海尼你有没有试过，其实在整个流程当中，如果说当中是有一个叫step by step的执行，也就是说如果你点那个，他们每一步就很多步如果不是搜索的话，他都会让你去点是否同意执行。所以你可以看到这个执行的input是什么，如果这个输入你不满意你是可以手动修改的。
这样的话你对于整个产品的flow是有更多的控制的，而不是说你点了一个键，然后there’s nothing you can do，这种状态这是非常无助的。因为如果它真的卡那卡半多小时，然后最后说它不行了，那你其实觉得说这是完全在浪费时间。所以我们有这么一个设计。
那有一个非常重要的一点就是我们其实收到过非常两极分化的反馈。P&Business的那些人呢，他们会觉得说如果没有这个同意按钮，他们会觉得疯了，就是这个东西他就自己在那执行，然后写入我各种Facebook和Instagram账户和LinkedIn账户，然后也没有我的同意，这个我会非常没有安全感。
但是开发者这一段，真正的AI发烧友或者说researcher或者说开发者，他们会觉得说为什么要给我去点那个同意按钮，他就直接一下子全部拉完，越快越好就好了。所以在用户体验方面其实有很两极分化的情况出现。所以我们支持了两种模式。
你刚刚还提到就是说一开始会把那个流程给用户看，让用户去决定这个任务完成流程是不是合理，这个是不是很常见。Manus也会做类似的这个功能。如果是用operator的话很多时候它是不给你的，Anthropic也是不给你的。
OK，Manus它是会给你看，然后看完了以后它就自己去执行了。它也不会说你可以去改那个执行界面，然后你就一个一个就把它改完，让它就根据这个去执行，它应该也是不支持的。所以它就是会自己收，它会有一个Dockrider，然后这个Dockrider是一个LM，然后这个LM它会写一些bullet points，然后就放进一个txt file。
然后它在执行的过程当中会让你看一眼，但你并不能说我要把这个暂停下来，然后真的跑到那个txt file，把它全删了，再重新改一遍，然后它基于这个再去执行，这个我记得是不支持的。
我自己用的时候发现一个挺显著的区别。OK，它没有一个虚拟机，一个页面展示说这个机器具体在做什么，比如说它是不是打开网页，后面是不是在写文档之类的。这个是为什么不加这样一个页面展示？
首先我们其实大多数任务都不用browser-based，所以我们的，特别是写入互联网账户的这些都是跟那些公司有官方的借口和官方的，不说合作吧，就是官方的这个access的。从我们的角度来说，这些内部的信息就跟那个公司的privacy有关，跟公司的章程有关，我们不能一直去不停地pin它的status，然后把那个status告诉你。
这个可能不是特别好，然后我们后面在一些deep research方面的这些任务，我不会给你们虚拟机。 但是会告诉你们一步在干什么，这个会做到。在交互页面之下，Pokei它完成任务和其他legend产品有哪些差异呢？首先最大的差异一定就是在执行侧，就是和几十个互联网大公司和大平台的接口，以及这些平台接口背后那数千个目前可能一千多个api的接口的打通。这个是目前市面上没有任何人可以做到的。
然后一个核心的难点就在于，每个互联网大平台背后的接口本身是非常非常相似的，然后有很多很多api互相之间都是几乎长得一样的。那么这些东西你是怎么能够让它更好的去分开，让一个agent可以完全能够使用这一千多个接口，然后能把它做好，这是市面上没有的。
第二是我们尽可能避免了对网页端的依赖。就是说有很多东西你其实还是不得不用网页，然后你很多东西还是不得不说我要做一个search。那些东西我们还是仍然在做search，但是除此以外，我们如果能够用代码来解决就写代码去解决一个问题。如果说能够用接口来解决就用接口。我们未来也会接mcp跟agent to agent，如果能把现有mcp跟agent to agent接进来我们也会用它们，但是我们一定会避免用browser来解决问题，因为browser在我们眼里不是未来。
因为如果未来世界上都是agent to agent的话，那browser的存在只会是一个中间态，所以我们尽可能去避免这样的一个形态出现。为什么要把能接入各个平台的API作为核心买点，它对应poke AI核心用户的什么需求？Poke AI的核心用户一定是开发者和professionals，就是他们是我们可以理解成一个2B业内的一个2C加2B产品。
它的用户场景一定是2B的，就是说它是一个在工作流当中要完成一些任务来用这种方式，就是用poke来完成在工作流当中的所有的自动化。但是使用者很有可能是一个个人开发者，就是它是某家公司的一个个人的开发者。他有可能是某家社媒平台的某一个做市场营销的职员，他有可能是某个广告平台的广告投放员，他有可能是某一家公司的法务，也有可能是某一家公司的财务。
那他们做的事情仍然是一个B端的事情，但是他使用的人可能是个C端的人。然后在这之上我们未来会往更多的enterprise去走，就是跟某些公司的内部的infra去打通。那这里面其实有很多很多的问题在，就是为什么大多数公司，特别是大的公司，以及对数据有很多的sensitivity的公司，他没有跟OBI打通或者entropic打通的一个核心原因就在于这里面有很多的privacy的问题在里面。
所以你能不能做到private cloud，你的模型是不是足够小，是不是足够scalable，能够做到这一点，这个是非常非常重要的。所以我们之后也会花力气在这个方向。但目前我们的主要受众还是个人的开发者和professionals。这个我觉得还蛮有意思，因为可能更多的agent产品，它的目标受众就是最广大那些消费者。但是poket的定位是找那些专业的消费者。
这个定位是怎么找到的呢？因为我们最早有了这个idea的构想的时候，其实就跟好几家我自己认识的广告、社媒营销一些业内的人士就有沟通。然后他们听到我这个想法以后，他们就觉得这不可思议，因为他们的最大的痛点不在于生成内容，现在因为生成内容真的很容易了，但他们的问题是即便你能生成这些内容，我还是要花三个小时四个小时在各个平台上面去进行传播，进去推广。
但更麻烦的是如果你是个社媒平台，运营管理更麻烦，因为比如说你这个帖子发出去了，肯定有几十个回复出来了，你能够手动一个个去点它然后就回复它吗？现在poket的话你就可以直接说，找到这个帖子把下面所有的回复用个性化的方式每一个回出去，它就可以把你回完了。所以它可以省下大量大量的时间帮你做各种各样的事情。
理解，但就之后拓展的方向，为什么又再到企业端用户，而不是说更广大一些更普通的消费者？消费者我们要看情况，但是我们目前对于非常非常general的纯general agent的观感是，用户很有可能会被你能做的事情给overwound而去执行一些跟你能力范围不匹配的事情。就比如说像operator这样的一个2C产品，对吧。
然后我和我身边朋友第一反应是做我现在说的这些事情，不是去搜索内容，而是去真的是执行帮你去，比如说我安排个会议，发个邮件，类似的这种。我第一反应是想做这件事情，然后我试了以后发现一个都不行，就是0%的成功率。然后当时我拿到manus的邀请吧以后，我也干过一样的事情，比如说你帮我facebook发个帖，它也是几乎0%的成功率。
那当然了，跟我们一样做一些简单搜索，做一些内容的收集，代码什么的它都没有问题，对吧。那这个是我们可能还没有做那么深，但是在执行侧，目前是没有人可以跟我们做的一样深的，所以我们的目标群里更多的是说，OK那工作流在哪里，对吧？我们现在有个人开发者跟那些prosumer这些人群，他们有大量的非常繁杂的工作流，但真正的工作流还是在企业内。
就企业内部会有几十步上百步的工作流需要去解决，所以我们需要解决的是说，OK那未来这一百步工作流是不是能够直接被agent取代了？里面有些需要人在的地方agent去主动找人完成，而不是人做半天然后每一步当中去找一个lm去解决内容生成的问题。所以这是我们最终想要走的一个方向吧，能进入一个大公司的工作流，然后他取代几百步的可能是之前的自动化流程。
这个你觉得Pokey他和已经在提供这样服务的，比如说Salesforce这样的公司是竞争关系吗还是？我觉得不会。就是像大公司的工作流是足够复杂的，当然我不觉得Salesforce的agentforce做得很好，因为好多人都跟我吐槽的，主要是这种拖拽流的agent，无可避免就是它有一个rigidness，就是你除了这个工作流稍微变一变，它就又不行了的这个问题在。
所以我倾向于把agent或者工具，就是那种拖拽流agent工具，还有那些lm AI工具全都包成一样的态度，就是说他们都是某种工具而已，然后你需要的是一个更上层的，能够更好的规划已经知道无限调动的这样的一个功能。这个可能是我们最后的使命所在。拖拽这样一个就是相当于人工编排一个工作流，然后让agent按照这个工作流严肆合幅执行，这个可能就是大公司最重要的需求，因为他们的工作流可能是更加僵硬或者固定的。
而且变化比较少，那就当有一个有自己生成工作流的能力的agent出现之后，他们就真的会有这样的需求吗？这是个特别特别好的问题，这是为什么我们会从小的prosumer developer往上走的原因。原因是在于你要去改变大公司的工作流的走法，其实是非常难的。但是我即使有很多的观察，就是很多大公司的工作流是大家希望它改变的，而不是说大家都觉得安部就班就很好。
所以需要做的事情是一个bottom up的一个influence，就是说你可能很多原来二三十步的工作流，可能就只需要七八步就可以搞定，可能并不需要那真正二三十步的那种工作流，当中很多内容或者很多的步骤都是多余的。所以如果你有一个AI自动生成的工作流的模型，可以把工作流所对应的所有工具以及给人派遣任务的这个事情都可以做完的话，那eventually当这些我们在共同成长的这些小的公司或者说个人的开发者一起成长以后，他们会去influence那些更大的公司，说明他们已经做到那么有效率了，而且做事情做得那么好了，那这些大的公司也会想办法来adopt你的solution。
这个sell cycle是非常难的，因为没有人去希望做那种打破原有界限的这种改变。所以我们可能会先focus on中小型公司，加上个人开发者和prosumer，然后慢慢的再去influence enterprise。可能需要一些你自己的trust在里面，就是你认识的人，然后他们知道你的agent能力编辑在哪里，他们才会去deploy。但是我们已经看到一些比较好的sign，就是我们一些玩具的朋友，他们把我们的agent的demo和一些简单的尝试的一些用力发给他们的老板以后，他们老板其实很想买我们的产品。
所以在执行侧大家还是会有这个需求在里面。另一个比较好玩的点是PokeAI如果有一个子任务没有完成的话，其实不妨要他继续执行后面的任务。我们有因为是RL生成的整个规划以及执行，就是说他会知道说我的这个action之前的context是什么，然后这个RL agent会说这个action可能跟之前的context没什么关系，所以他就会跳过某一些内容然后去完成下一步。
就是说我尽可能的把你整个任务都完成掉，能完成多少完成多少。然后下一步你可以再跟我交互说这几步没有完成，然后怎么去根据现有的信息再去完成下一次。我们是这样去思考这个问题的，因为你的目标不是让用户被卡住，而是说能完成多少，尽可能去把它完成好。
理解解那如果Pokey整体任务失败的话，他可以继续自己debug重新尝试吗？因为我自己在试的时候他好像还没有这个功能。对，他现在我没有打开，因为我还在测试这个东西，还是跟原来那个情况很类似，就是说我们希望能够让他非常stable去debug，因为如果说他debug完了以后他自动执行了，而他可能把你的input的那些内容给改掉，比如说你想发布一个文章，然后debug的时候发现你这个文章内部有什么问题，然后他就直接给你改完了以后给你发出去了。
比如说我有一个非常classic的问题，就是linkedin。linkedin如果你连续发两篇一模一样的文章，他会把你block掉。那即便你用的是我们的官方接口，他还是会有这个问题。如果说一个足够聪明狡猾的agent，比如说Pokey，我们已经见过他干这些事情，他就会直接跟你绕开。他说我把你那个内容稍微改一改，然后再给你发出去，但这不一定是你想要的这个体验，对吧。所以我们要去找一些case，可能说有些是可以绕过，有些是就应该让他直接fail，然后告诉用户。
当然linkedin这个case，你可能是希望agent smart一点，就真的把他绕过的。但是有一些case就是你不希望他绕过。我自己试的时候发现Pokey完成任务的速度非常快，大概一分钟左右完成一项任务，这个是怎么做到的呢？对，你看我们的demo那个视频里面，从不管是什么社媒账号运营还是meeting，还是我们之前做分析这三个例子里面，所有东西我们都没有加过速度，就是原始速度。
就是当中包括了所有的approval，你可能来来回回再点那些加起来是60秒。如果那些pro全都不要就让他自己赚的话，可能就10几秒就搞定了。这个就不能细讲我们的做法不是browser use，我们也有browser的部分，但是有很多action taking的地方，我们和很多公司是有合作和集成的地方有极大程度的压缩。
我们可能最后会有一个你们会看到一个对比图，就是说我们和browser use的这些agent相比速度和整确率可以极大幅度的提升，然后在大多数的任务场景上面我们都可以autonomous，但那些非常nish的那些场景上面他们其实也做不好，所以我们也就不做那些场景。我们会告诉用户怎么去做，然后在对于那些mcp和agents sdk的竞品上面，我们所可以覆盖的产品和工具列表或者平台列表要远高于他们。
就是我们和两种竞争者对比起来我们都有很大的优势，所以你们去调工具的时候，你们不是用的mcp这个协议什么，或者说你们只用了一部分，不是，你们不是，我们完全没有用，但是我们后面会支持mcp，因为有很多人已经建了mcp了，why not。 但是我们之后会有个协议会更简单。你就告诉一个json file，把input、output和你的endpoint。就比如说你是个不管是什么样的api或者说工具，你把endpoint告诉我们，我们就可以直接调用了。你也不用host。
那你们现在能调这么多工具，相当于是你把你刚才说的那个更简单的协议，在那些你们想用的软件和工具上你们自己加了一层。对对对，但是并不只是正常的api或者browser，还有很多很多别的工具在里面。所以就不能非常的笼统地告诉你们说工具都是怎么生成的，因为有很多很多工具是以不同的形态呈现的。
那听起来感觉这个好像还是一个挺重人力的过程。因为当时提示mcp的想法就是说所有人能群色群力，你做好一个工具别人就不用再发明一次。这个你怎么看了？目前来说我们还没有遇到这个问题，后面肯定会遇到这个问题。我们也会做开发者社群，我们现在预估第一轮release也就是1000个工具左右，就是1000个可以调用的子工具，可能平台可能几十个，然后子工具加起来有上千个，这样子而已。
然后我们会做开发者社群，让所有的人使得他们的SaaS软件或者他们的工具能够非常轻易地被使用。他们只需要告诉我们他们工具长什么样，他也不需要告诉我上下文，也不需要告诉我任何的什么东西，就是直接告诉我input、output和他们的input怎么搞就结束了。然后我们就可以把他们的工具直接吸纳进我们的整个ecosystem里面。
所以你们这个属于mcp的竞品吗？我们也会用mcp，所以不算竞品。就是人家如果说想要更简单一点，不需要安装也不需要做什么java世界server，那他们就可以用我们。这就日子好过多了。有一个比较无线扩展的这种工具调用的能力，肯定是很多做agent的人都想实现的一个东西。也能很自然地看到这个东西是有价值的。
那实际上大家的实现方式主流的来说有哪些了？比如说你们的这种尝试可能是一种，你有看到市场上其他人有一些其他的你觉得比较有潜力的实现方式吗？大多数还是以LM为核心吧，就是还不太能见到非LM模型在这个方面的应用。有几家公司在做一些跟contrastive learning相关的approach，但我们试用下来可能也不是效果特别好。它们可能就偏传统的那种，带一点in supervision的那种模型，这种模型在我们现在试用下来可能效果并不是特别好，因为它的negative的那个noise太高了。
比如说你有上半个工具，这上半个工具当中只有一个是正确的，那你得到的negative signal就太高了。比如说你随便去调入里面任何一个工具，它大概率都是错的，那你等于说这个工具可能你被sample了无数次，人为帮它标注了也无数次，然后到最后连一个正确的解都没找到。那这样的话，你训练起来就难度非常大，所以从这个角度来说，你需要一个非常smart的一个机制去完成这个训练。这是我们的一个secret sauce吧。
你可以讲讲从24年10月，你当时比较明确地要出来创业，然后到你开始构建Pocket这个产品，中间关于一个好的agent应该怎么构建，应该具备什么样的要素，包括你们做了什么事，你一步一步大概是怎么想的吗？对，有几个问题。第一个要对比的就是人为操作的时间跟机器操作的时间的对比。如果一个agent做出来以后，人为自己去做某件事情，比机器做某件事情时间还短，不管你是有人involved还是没有人involved，这个agent一定都不会成功。
因为人的一个惯性思维就是，我如果要做这件事情，他就会在旁边盯着。不会说我要做这件事情，然后我就走开了，等30分钟回来以后发现这东西还是没有完成，然后他改来改了又走开了，然后还还没完成。大多数人，甚至于你们在下载文件的时候，你们都会在旁边去盯着他，因为人大概率都会想说，这个东西是不是会fail。对吧，每10分钟就会去check一下，这东西是不是有问题。
这是一个人的常态的一个思维惯事，所以从这个角度来说，如果说一个agent的执行速度比人做还慢，那这个agent就基本上不太可能成功，因为人不太可能脱离那个什么都想管一下的思维惯事。这个假设好像有些强啊，就是比如说，虽然可能大家都会盯着一个任务过程看，但是你可以一边看一边刷手机和一边你得全人贯注地看，似乎还是有一些区别，你不觉得吗？
是，你是可以这么说，但如果有这样的场景的例子的话，就那么简单的场景都需要比人的速度都要慢，那我觉得这个agent本身的实现就很有问题。我们希望可能能够达到的效果，就是说你完成一个任务，就是个二三十秒，甚至一分钟的事情，不可能说你要等半个小时，然后回来以后发现还是fail的一个状态。这是我们当时的第一个assumption，就是说你不管完成什么任务，肯定要比人的速度要快。
然后第二点呢，整个任务本身，它的串联是基本上minimize所有human input。就不能说OK，我完成了第一个任务，然后拿到那些信息，还需要人去复制粘贴放到第二个任务里面去，然后再去做第二个任务的执行。这个是一定要避免的。如果说他只是帮你完成单一任务，然后你还要去拿那个结果，然后再复制粘贴到下一个任务当中，然后再让下一个任务的agent去完成下一步的任务，那你还不如就让人去做。
因为很多时候整个contact switch的过程比人的成本还要高，所以我们希望能够把整个工作流上面的所有任务全部都写结好，你不再需要说从第一步到第二步当中还需要有人去involve了。这是第二个点。然后第三个就是不能只有毒，必须要有血。大多数现在的agent都只有毒，就是说我可以从互联网上抓取各种各样的信息，然后帮你做deep research，能够做一些分析。但是你能不能去写入互联网，或者写入你自己的个人账户，或者你的工作账户，或者你的公司账户，这个是目前缺乏的一个能力。这是我们想要做到的一件事情。
最后就是efficiency，它的算力不能够太高。如果说算力太高的情况下，比如说一个任务平均的cost是两到三美金，比如说你就简简单单写一个网页的summary，或者帮你去建立一个单一的网页是两到三美金的话，那你其实可以想象说，你一个月如果说去采取比如说100次任务，那就是可能三到五六百美金。那比如说一家公司，它可能一共比如说三个人共用这么一个intern，可能一个intern的价格也就是这个价格。
也就是说它的价格所有工具所执行的总的数量和人的cost几乎可以相当的情况下，那这个也很难去scale。所以我们希望说它跟人这个廉价劳动力本身的整个价格差距，至少要比如十分之一甚至百分之一的状态，这才能够真正的让AI的这个使用频率会大幅增加。因为如果说它的价格很高的情况下，你其实用一两次，如果有一次fail了，你可能就觉得我还不如去雇个人去干这件事情。
所以从我们的角度来说，它的成功率高的同时价格必须要压得很低，才能够使得这个东西真正去普及。就是刚刚也提到了哈，一个是RL它速度很快，另外一个就是好像之前你也提到说RL在一个CPU跑，为什么它的成本会比LM低这么多呢？不管是时间成本还是算力成本，就是我们要把模型跟算法拆开看。就是算法是RL，但是RLM也可以用RL来训练，但我们只是用了一个别的模型，但不是LM的模型用RL来训练。就是说你们是用RL训练了一个不是Transformer架构的语言模型的一个别的架构的，可以这么说吧。
就是一种别的模型，反正具体是什么架构我就不能说了，但它有一个别的架构的模型在里面。这个模型本身要便宜很多，跟RL本身没什么太大关系。它会宽很多，也会小一些。然后刚刚就还提到，其实就是一个很理想常讲家，就是模型能使用的工具会不断增加，而且有一群这个生态内的developer会不断提供这个工具库。工具增加之后模型需要重新去训练吗？因为在LM的场景下，其实你给工具加一个描述就可以了。
我们也是一个完全泛化的模型，因为我们训练的时候有见过一万五千个工具，但这一万五千个工具并不是每一个都我们可以直接使用。这些工具都是从互联网上抓下来的一些工具，还有我们自己构建的一些工具。所以这些工具本身就给了我们agent很强的泛化能力。所以从这个角度来说，agent本身可能不会需要在有新的工具以后去重新训练，但是如果出现了很多非常niche的锤类工具的介入的话，我认为可能会需要做一些fine tune。原因在于即便你把这些锤类工具给到LM，估计LM也handle不了。
那LM如果要重新训练一次，那成本就比我们高多了。所以我们应该就是在通用工具上面是不需要重新训练的，但是如果未来有一些非常小众的一些锤类的工具进来了，我们会考虑重新训练这个模型。就你刚刚说的那四点，就是你想到的用这几个构建agent的要素，是你创业一开始就想得比较清楚吗，还是有一个逐渐清晰的过程。包括你们的团队是怎么来组建的，能不能讲讲大家第一个Pocket的过程？
其实一开始的时候并没有那么清晰说这四个点必须都要完成，只有一个点是很清晰的就是跨平台。就是说我们一定是大量的不同的工具串在一块来完成一个人类任务，因为人平时就是这么去干活的。所以我们认为说如果一个agent真的能替人去干活，那他一定是跨平台多工具去完成一个非常复杂的任务。这是我们一开始的构想就有的。
那价格是我们当时确实就是在融资的时候也emphasize的一个点，就是说我们这个模型架构所带来的价格优势是非常大的。但我从来不会真的去因为这个打广告，因为价格这个东西真的不是一个非常长期的不能说不是长期优势吧，就是说eventually总会有人想办法把计算成本给压下来的。所以你价格很低并不代表说你有永久无限的价格优势或者资源优势。
所以我一般不会去advertise这个，但是多工具多平台无限scale和easy to use这个是我们一直都觉得这是核心要素。剩下两个点是我们目前后面在慢慢慢慢摸索当中总结出来的，就是说从某种意义上来说要比人快，而且你的scale非常好，这些事情都是我们在后面在摸索，就是整个产品慢慢在构建过程当中总结出来的事情。因为我们一开始也用operator跟computers去做很多的比如说task去体验嘛。
然后其实有60%到70%的这种任务啊，就是我们自己内部在使用的时候在测试的时候，我们都不等它做完，就没有耐心去等它做下去了。就是觉得说这个东西就那么简单一件事，我还等你可能两三个小时去跑一个东西，真的是没有什么太大必要。所以我们一般情况下总结下来就是，人没有那么长的耐心等你去完成那么复杂的任务，然后花那么多时间。
就很多这种东西都是在我们自己试用和自己的摸索的过程当中总结出来的。整个团队的构建其实跟这些摸索没有太大的关系，主要还是一开始的时候我在构建整家公司的时候，还是一个端到端的这么一个架构，就是从fundamental research到production engineering到产品的experience的engineering，这个都需要有最专业的人来做。所以我们的团队有一个research scientist，是我之前meta的一个下属，然后是做reinforcement research的，也是rich Sutton的学生。
然后有ml engineering，是之前我做b2b recommender system的一个下属，也是做production非常好的。 然后还有个prod engineering的partner。这个是我很多年的一个朋友了，然后也是之前meta的同事。他是做prod engineering，非常有经验的人，所以我们就是端到端每一个关键点上都有一个很有经验的人来带这个事情。
当然，我们现在团队一共全职员工就四个人，很多活都是靠AI来帮忙的。我们自己也写了一些AI tools，内部很多的scaling什么的，都是靠我们自己写的一些AI tools来完成的。然后呢，有一些contracting的contractor的help。那就是亚洲这边会有一些contractor在帮我忙，做一些相对比较杂的事情。
回到这个产品形态，我知道在你们现在这个产品形态之前，因为我跟一些早期见过的投资人聊过，你们早期还有一个方向是做旅游路线规划是吗？但我不知道这是你的一个方向还是个demo。就是个demo。我当时花了可能一两个礼拜的时间，然后就告诉他们说，如果你用我们这个架构去做一个规划能力和工具调取能力的这么一个agent，他能够有多powerful。
就是我们当时用了一个可能就几百万个parameter的一个模型，做了一个可以横跨很多个城市的google maps调用的功能，就是一个锤类的agent的功能。然后google maps下面所有的工具SDK的集成都可以全部集成进来。当时就想showcase一下说，如果你想做一个工具调用的agent，我们的这个方案可能是非常scalable和非常快速的，你也不需要等去打开网页或者怎么样。
那这个showcase里它还是不涉及到多平台的，对不对？它主要就是在google maps。对，当时还不涉及多，当时其实都是在google内部了，google maps加doc加calendar这种。这个其实也算多平台了，但可能从当时的角度来说，已经算是相对工具调用上面非常强的一个agent了。但是当时可能从投资人这边来说，没有一个共识说工具调用是未来的一个future。
那所以接下来做了一个帮shopify商家做推荐、做客服这个产品。当时是怎么想的呢？核心还是一样的，就是当时通用agent并没有一个共识，大家不觉得说这个东西能卖钱。所以所有人都说要不你们先找一个落地点，那我们当时就说那我们的agent能力很强，我们就直接把shopify底下的所有工具，不管是他们的command line、还是他们的graphql、还是他们的api、还是sdk，全部集成进来，变成一个面向商家和面向客户全功能的一个agent。
我们花了两个月就做完了，等于是说你平时要把这些逻辑全捏在一块儿，你可能花一两年时间才能把这些逻辑全捏完。我们就花了两个月就把整个背后所有的逻辑全都捏完了，就是完全靠我们现有技术能力就可以完成。
所以这个就是一个类似于技术测试的一样东西，就是说是不是真的能够通过这种方式，使得整个开发速度和robustness都有很大幅度提升的一件事情。当时我们就通过这个项目，我们也觉得说这个东西确实是有很大前景。然后与此同时我们当时还想说，OK，我们是不是要expand这个东西，然后去卖。
然后211就突然火了，火了以后所有人都来找我们了，都是说那你一开始那个vision怎么样？我就说那我们就回到原来的原始vision，从零把横向的平台给打通，把这个技术给做出来。所以这是为什么从12月份的时候开始，我们就开始回到原始vision，说OK，我们就把这个最核心的这个技术把它给铺开做好。
所以差不多是从24年10月到24年底，你们是在做跟这个电商场景有关的，更垂直一些的一个应用，而且有考虑过去落地。但后面因为市场环境的变化，就可以回到你觉得你本来最开始更想做的这个事情。你的核心问题是要卖嘛，就是你要去卖。
那如果没有人去意识到通用agent的核心能力和工具相关、规划相关、和RL相关的话，那很难拿到共识。Deepseek跟Athrobic两家的过去的这些effort，使得这件事情形成共识了，那就非常有利于我们。就是我们没有做任何marketing effort的情况下，流量就自然有很多偏向于了我们，因为有很多别的公司来帮我们做了这个education的过程。
所以我们就认为这个时机到了，可以回到我们的原始vision了。这个流量是说投资人的流量吗？还是应该说，是吧，投资人，然后客户，还有很多developer的关注，全都可能就是12月份、1月份、2月份，几乎就是以一个几何技术的增加。
就是一开始就是非常平的一个状态，就是我们自己在开发没人管我们，突然今天12月份就是所有人都来找我们，就是说几乎有上百个投资人来找过我们。客户的话有几十个大型客户来找过我们，小的developer就不计其数了。我们上那个demo当天，一个礼拜内有800多个waylist的sign up，后来三月份上线以后，有800多个人sign up，而且我们没有做任何，就连朋友都没让他们帮我们分享。
当时我们就觉得说，OK，这个确实是这个流量比我们想象中的大很多。因为一般来说Proud launch当天你会让很多很多朋友帮你分享，把那个流量给顶上去，然后我们发现转化率特别特别高。当时可能view量可能也就才1万左右，然后有差不多8%到9%的conversion rate，这个就有点非常离谱了。
就是说你一个网上的某一个帖子的waylist的转化率，有差不多8%到9%，这个比我们任何一个之前正确在meta阶级的产品的转化率都要高的一个状态。如果总结一下你就是从去年10月到现在没有半年的这个创业历程里面，没有4个多月吧，你觉得几个比较重要的里程碑或者说几个比较高兴或者比较down的点都是些什么样，发生了什么事。
首先第一件事情就是我们开始融资的时候没有人理解说RL加agent是个什么东西。其实今年我们有跟我这次GTC这段时间因为很多人请我去一些van，然后做一些panel，聊很多投资人。投资人就说you are like six months ahead of the curve，so no one’s going to invest in you because it’s like too early。然后当时就是一个非常down的过程。
就是说我们从一个brand vision我们认为一定会成功的vision，把它缩小到一个要落地的事情。我现在回过头来也不觉得这是个错误的决定，因为如果没有人帮你做education，这个市场就不认为工具调用加RL加agent全部放在一起，推理规划工具调用这件事情是一个核心agent所聚变的能力的话，它只是生成的话，那你即便想做这件事情也会足利匆匆，所有人都不认为你做的是对的事情。
第二个节点就是12月份的时候，当时deep seek出来，RL突然间变火以后，我们当时就突然间得到了很多投资人加客户的关注。他们说你们是不是有做通用agent这个能力的，然后我们说确实这是我们initial plan，然后就有很多的brainstorm，还有好几个我比较熟悉的投资人，有告诉我说他们觉得这个时机可能开始慢慢变成熟，你可以回到你的ground vision跟platformization上面去。
所以当时听到了好多次这种feedback，当时那个产品也做完了嘛，所以我们就觉得说OK，是时候把那个产品就放在那边，该卖就卖。然后我们这边就回到一个通用化的一个状态，这就是第二个点。这个时候我们整个团队的心路历程就说OK，我们本来是非常脚踏实地在做一个产品，现在突然间可能说是有一个j curve或者说有一个势能，或者说有一个势能出现了。
就是我们开始发现这个机会，然后我们到了那个点以后，我们就开始说，我们怎么去架构整个agent的整个backend和infrastructure。一直到了三月份的时候，我们把一开始这个demo做出来了。然后这个demo release以后，我们发现说这个兴趣量真的很高，这个事情非常巧合，因为我们的release是manus的release前两天。
我们release的那个视频，3月4号。对，我们3月3号的早上release的，然后国内3月4号看到的这个事情，两天以后manus就release了。manus release以后我们一开始还觉得说会不会已经有一家竞品在做这件事情了，然后看完以后发现不是，他们还是在做一个偏生成式的功能性的东西，速度还是以browser为主，所以速度还是比较慢。
所以我觉得说这个东西完全可以是互补的状态，就是我们这个领域还目前没有太多人去碰，所以是一个相对比较蓝海的状态。Malus的爆火出乎你的意料吗？不出乎我意料，首先他们的市场做得很好，这个是我知道我们学习的。
就是说如何使得一个非常technical的产品，看起来甚至对他们骗consumer，对于consumer来说非常boring的产品，让大家觉得非常exciting。这个就像艺术一样的事情，就是你需要有经验的marketer去帮你做这件事情。他们marketing做得非常好，所以这个是必须要给kudos的。
他们的整个产品设计和engineering的整个套用都是做得很好的，因为他们几乎把里面非常复杂的多部，从这个python写作到下一个browser使用，这些工具的嵌套几乎没有什么缝隙。就你不会出现说第一个工具弄完了，第二个工具完全卡在那儿就完全做不下去了，这种情况是不会出现的。虽然它还是很慢，但至少它是一个相对streamline的过程。
所以我认为说因为第一次有这么一个完全2C的产品出现，是会给市场一个震撼，同时marketing做得很好，所以它的爆火是有它自己的原因在那儿的。我们可能不会做那么酷的事情，因为我们还是偏向2developer为主，但我们应该也会尝试说找一些人分享之类的，去想办法让大家更多的知道我们这个产品的存在。
我们产品的用户的学习curve还是要比他们稍微deep一些，因为从某种意义上来说，用户需要知道一定程度他们的工作流逝什么，而他们就告诉他说我要建一个网站，可能就一句话搞定了。我们这个可能还是需要说我要做这么一件事情，这个事情要完成这几个东西的delivery，这几个东西是在什么平台上的delivery，这事情可能是需要用户告诉我们的。
但用户也是用自然语言告诉你就可以了，只不过他要说得更清楚一些，也不是说得更清楚一些，因为我们要真的去写入你的互联网账户或者是写入你的工作账户。如果你都不告诉你的工作账户在哪，那我也没地方可以去帮你写。那这个就是跟consumer最大的区别在于，因为如果我真正地去帮你去某一个账户里面执行的时候，我真的需要知道这个账户在哪，或者这个平台在哪。你也不能就告诉我说建立一个网站就好了，因为建立一个网站我们也可以做。
但是真的有价值的还是帮你把工作给完成。因为你刚刚讲到就是3月3号你们开始发这个demo，你们下一个节点或者说接下来的一个重要节点是什么？应该会是我们的beta launch。你们到时候是会给邀请网的那种形式，还是大家直接可以用？大家应该直接可以用，但会限制流量，因为一开始我们也不知道有多火，万一直接把我们这边的competition可能还好。 但是因为我们有很多很多的 rate limit，我们自己设置了很多的 rate limit。我们不希望说直接把某些网站给冲垮了，比如说去某个网页上抓信息，然后很多人都说我要去这网页上面抓信息。然后那个网页企业就说这 Pokey 还是什么，DDoS 或者怎么样把我们给封了那就不行。
所以我们还是要稍微小心一点。因此当天我们应该有用户会看到说有一些的工具可能用不了，今天的 rate 已经到上线了，我们不能再继续开放了，明天可以继续。邀请网的出现唯一的原因就是因为有 competition limit，我们完全可以 competition scalable，所以我们不会有这个问题。
Pokey 等此人物成本大概在多少呢？就是目前市面上所有的产品的可能几十分之一。因为你刚才说其实有一个比较重要的节点，就是你们在 24 年 12 月，RL 又火了之后，市场有了更多共识之后，你们回到你们最初的那个愿景，就是变得更通用，就是想去做更通用的 agent。
另一方面就是你会不会担心做更通用的东西，它的竞争压力也更大，比如说 GPT4O 释放了文生图功能之后，也是有很多人在讨论。当大模型本身的基础能力提升之后，跟这个能力重合的那些方向上的一些 agent，比如说生图其实也是有些 agent，它可能融合了一些工作流，让你的效果可以提升。
然后这些产品可能就会受到一些冲击。另一方面我觉得就是更通用的 agent 肯定也是各大模型公司，包括像 OpenAI 这种创业公司里的巨头，包括像 Meta、Google，还有像字节、阿里这种中美的大科技公司都会做的方向。你们的特别是在什么地方了？
我们肯定是以商业模式上，未来就形成我们护城河的一个主要方面。因为如果你纯靠技术，我其实觉得纯生成式的模型就有这个问题，就是你没有任何的 integration，没有挂靠，没有粘度，所有的东西都是靠你生成东西的质量。那生成东西的质量，纯粹的 backend 就只有一件东西，就是你的技术。除了技术以外，没有任何的额外的护城河，没有用户的年度，没有用户对你这边的绑定。
对吧？我们要形成的是一个工作流绑定式的东西，比如说从此以后你有大量的文件，过往的视频，比如说你是一个社媒的博主，你有大量的视频、文件，还有你的图片，什么都已经存在 Pokey 上面了。你只要告诉 Pokey 从我过往文件当中挑出三张，我过去的年度的 summary，然后帮我发到 Instagram 和 TikTok 上面，就可以完成你的任务的情况下，就没有办法直接跳到别的平台上面去了。
我们需要有个工作流上面的升榜定，这是我们要做到的一件事情。我不让我理解对不对。他可能就逻辑是我为用户也不能说创造，就是让用户有一个迁移成本在。如果是这样的话，事实意味着它其实是个速度游戏。就是如果同时 ABCDE 五个产品都能提供，同样的服务用户只能选一个和它绑定的话，其实做的最快那个人可能最后越容易活下来。
不一定，这还真不一定，因为这就跟早年互联网游戏一样。Facebook 不是第一家，但它活下来了。MySpace 当年其实有很多人跟它升榜定，但是仍然 Facebook 最后活下来了，还是跟市场迁移的过程有关。就是当市场在不停的 shift 的情况下，你是不是能够更快速的去进行你的策略的转变，然后能不能抓到一些用户群体和这些用户群体所相关的，不管是你自己做 service 也好，还是跟 Vertical 公司做合作的做 service 也好。
和这些用户进行更深度的绑定，把一些市场先站下来把这个用户粘度拉起来，然后才能够去扩张。这个东西到最后还是个商业的东西，不是一个纯技术上面的东西。技术上面我觉得 eventually 肯定有人能够做跟我们类似的东西，但是我们希望说我们有个先发优势，然后同时又有更强的集成用户粘度和绑定在里面，可以给我们带来更长时间的一个护身盒。
你觉得这个中美商业环境会有差异吗？比如说你在中国，如果你做写操作，甚至就是你刚才举的例子，有些是跟线下的服务有关的，我让他去帮我点个外卖什么的，那如果在中国的话，可能美团他就不想跟一个创业公司去做这种合作，是不是有可能？他觉得我可以自己做一个这样的事。
当然，其实国内的几家大厂商都有来找过我，就是说要有没有什么业务合作的可能性。我觉得我们还是 focus on 能够把这个集成，或者说能够把一体化的这个通用 agent 的最快速能够接出来的这些工具先全都接进来。然后把不管是各种形态的工具全都接进来以后，我们再去考虑说我们作为一个平台，给到比如说各个大公司去提供服务的方式去做这些事情。
因为你要打通国内的市场实在太难了。我其实当年融资的时候有回国待过一小段时间，来讲讲你的感受。总结下来就是国内的生态大多数情况下是相对比较封闭的一个生态。模型的生态是非常开放的，但是商业的生态是相对比较封闭的，和欧美的生态环境很不一样。
美国可能是最开放的，北美是最开放的，然后欧洲是居中的。欧洲其实有很多大公司也没有那么开放，比如说 booking.com，它们的整个生态也是有自己的护生盒在里面的，它们也没有完全的开放这件事情。所以这个事情在北美肯定会第一个先做出来。不管是我们还是别的哪家公司，一定是整个通用 agent 的能力的爆发。我猜大概留会在北美，因为商业的整个环境更开放。
国内的话就看各大巨头愿不愿意帮忙了，就是互相之间愿意协作了。因为从某种意义上来说，比如说我们就已经把 Google 和 Meta 的整个 ecosystem 全接完了，那就相当于在国内，你需要把百度和腾讯的所有的 ecosystem 全接在一块。我其实在这个地方去打巨大问号，这两家公司愿意合作在一块去完成这样一件事情，对吧？
请你解释一下就是所谓的开放具体是什么，比如说是什么在国内做不了，但国外是可以做的呢？比如说你要去 Facebook 上面去写一个 post，那你要去微信上面去发个朋友圈，你肯定不能代替别人去发朋友圈，就不算微信发朋友圈嘛。你就是说微信的企业端的账号，你要去帮人家发一个什么视频号，目前也没有结果让你做这件事情。但是在美国是可以做这件事情，它有各种各样的东西可以让你做到这件事情。
它有第三方的继承，它有你可以下载 SDK，它有 REST API，甚至有第三方的工具可以帮你去做这件事情。所以各种各样的生态来帮你完成这种事情。但国内这个生态就完全是封死了的，就是只有腾讯自己可以做这件事情，然后它可能有一些自己的 trusted partner，可以帮助它去做一些工具。但这些工具本身都是一家的，就是只给腾讯单家做的，所以它不会说我同时可以接入腾讯又可以同时接入比如说阿里之类的，这个很少见，非常少见。
所以你刚才设想的这个就是我在商业模式上建议的壁垒，你可能还是要先在北美市场跑通，可能是我们的最重要的一个 first milestone。然后后面当我们的 SDK 跟 API 的整个能力出来了以后，我们会找各大公司看看有没有协作的可能性。
你刚才说了很多次就是现在大家觉得 agent 然后强化学习，然后 agent 要去调用工具等等是一个共识。我想知道就是在实际的落地和实践上，就像你们这样以 RL 为核心，用这种通用的方法来做 agent 的团队到底有多少？目前不是很多，就是大家还是以快速落地为核心的，以套件为主的比较多，比如说去套一个 cloud，然后自己写一些工具，然后直接套进去用一下，或者直接套 GPT4，然后用有线的工具去套一下。
这个比较多，就很多雨过春损一般的公司都在尝试做这件事情。但是真的要做一个完全通用的无线 scale 的框架，市面上我还没有看到第二家公司在做这件事情。有很多的小公司 startup，他们在尝试用 cloud 或者用 GPT4 去套 MCP 或者套现有工具，来完成一个小规模的我们要做的事情。
然后它基本上大都是以 2C 为主的，就比如说最近你们看到那种 blender 很火的那种 cloud 的插件，或者说你们看到的那种纹身图的那种插件，或者甚至有一些做一些 MCP server 是给 Cloudflare 的那种插件，它都是偏有一些是直接几下几用的，给比如说 Cloudflare 的用户用的。有一些可能是说 blender 给 blender 小白用的， 那这些东西可能都是想要快速获得流量，快速落地，然后拿一些 traction 的这种小公司做垂直领域的很多。
然后做完全横向的无视 vertical，可以跨很多很多领域的这种公司，目前我还没有看到第二家。我们可能还是在这个方面比较执着的一家公司。为什么它是共识，但做的人又很少了，是因为它比较难做比较难实现，还是因为什么？
就是这个事儿是个技术壁。就是目前你除非想花时间花精力去做研究，从 fundamental 去解决这个问题，目前还没有什么特别特别好的解决方案。我觉得可能会从 research 上面会有一些突破，接下来可能各大院校或者说几家巨头，他们也肯定会花时间去做这件事情。我们做的解决方案是目前我们觉得比较领先的，但未来会不会有更好的解决方案和合作，或者说有别的集成方案很难说。
但是我们希望能够通过我们现在的优势，来完成第一波的市场的 integration 和市场的 scale。我有一个很好奇的问题，就是你们现在的这些做法，在你们之前开源过的那个 pro 的项目里，它有什么一万相成的思路吗，还是其实已经进化了很多？
进化了非常非常多了，就是那个是一个更 fundamental 的框架。我们确实有用 pro，就是我自己写的 library 里面的一部分，来写我们现在的这一部分。因为它是 MST license，所以我们也可以用一些，确实我自己个人还是觉得很好用，我们自己用下来是觉得很快速地加快了我们的整个开发精神。但是那个 library 里面确实只有非常 fundamental 的一些 components，它没有一个算法层面的逻辑或者算法层面的一个精髓，并不在那个 library 里面。
垂直 agent 和通用 agent 它们是相互取代的吗？还是说其实它可以共存？我并不觉得它会相互取代，比如说像我们的核心场景的目的是，我们讲 power vertical AI agent 公司，就是世界上有很多工具和很多的任务，它里面所需要做到的事情其实是通用的。比如说你要写文件、写 slides，或者说你要去建个网页，或者说你要去抓取一些，比如说社媒的信息、热点啊什么的，这些东西都是通用的。
但是只是你落在某一个落地的垂直领域上面，它有些特殊的工具要做。我举个例子，比如说你把社媒跟电商全绑一块，那电商它可能要做一些 Shopify 的事情，那 Shopify 里面有各种各样莫名其妙的工具在里面，但跟社媒相关的那一大块东西，并不区别于说你就是一个博主。所以不管你是个博主还是你一个社媒去卖电商 retail 的 business，他们俩所需要用的社媒工具都是一样的。
所以我们已经把你这边最痛苦集成的那些东西都解决掉了。你就告诉我你在 Shopify 上面要干点啥，或者说你自己的这个博主平台，或者说你自己有个博主网站，这个网站上你要干点啥，你把它集成卸卖，我就可以把你整个工作流做完了。那我们其实可以 power 很多很多 vertible AI 公司，说你不再需要去集成那 1000 个工具了，你只需要告诉我说你们这个 vertible 里面最重要的那 10 个工具是什么，你就可以直接调用 1010 个工具来完成你的任务。
你们这个产品最初肯定是应该在云端在电脑端用的，对吧？那比如说未来它有可能是需要拓展到更多中端吗？就比如手机、移动什么的。我们手机端应该也会做一下，但是感觉手机端做只是为了让更多人可以体验到这个功能。我们的核心的突破点还是会在 developer 端，就是以比如工具调用的数量。 工具调用的成果来完成我们的收费的这个。你觉得像这个通用 agent 框架这一层就这个市场，它可以容纳多少公司呀？因为现在做这个方向的创业公司肯定是不少了。
对，做的公司肯定不少。少说至少我觉得未来一年之内你能看到不小于10家公司。那我觉得最后一定会存留可能四五家、三四家公司。因为它就跟很多相当的 lm 的这个领域一样，就是你可能会有大量大量的不同的公司，非常同质化的涌现出来。
在涌现出来之后呢，它们就会开始进行怎么说，怎么去 differentiate themselves。就是说这些公司本身可能会去更注重某些 vertical 或更注重某些能力，然后使得它自己的能力区分于别的公司。比如说 Cloud 跟 OpenAI，XPT 一开始出来这个产品几乎是一模一样的，然后 Cloud 就更偏向于 coding 了，XPT 更偏向于 2C 了。所以它自己的能力就被拉开了。
它们用这种方式去区分于对方，然后使得自己的市占率仍然保持某一个状态。之后 agent 领域也会出现一个类似状态，但通用这个词语似乎和差异化本身就是矛盾的。你怎么看这个问题呢？就是如果到达一个非常高境界的通用的话，好像那就变成一个标准产品了。
那就跟你问 Android 跟 iOS 为什么还存在两个系统一样的道理。所有的只有两个吗？对对对。但是 Android 跟 iOS 这种操作系统的东西，它的整个背后的逻辑框架非常非常复杂，所以它的整个 replication 的成本很高。为什么会有人去想要去 replicate 它，也是个大问题。而且 Android 是开源的。
By the way，如果 Android 当年没有开源，可能就不止两家了，肯定会有第三家出现。那 MacOS 跟 Windows，然后还有 Linux，三个东西不都还存在吗？而且因为 Linux 存在，所以没有第四家出现，在想要去打 Windows 跟 MacOS 的市场。
就一旦开源的东西出现了，那就很难说我有很多很多很多很多的家出现，一定都会被开源的那个系统给统一化。因为很多后来的人都会用开源的那个系统，它就变成标准化的东西。Agent 这个市场后面也会出现一些可能偏开源的东西，但我觉得 agent 这个架构可能就偏向于 OS 一些，它的复杂度要高于纯 language model，所以它的开源的难度要高于纯 language model 的开源。
这个我觉得后面可以再去看一下会有什么样的开源市场出来。对，像 OWL 和 OpenMalus 是不是也算是开源的 agent 的框架？它不算一个框架吧，就是它并不是一个调用工具非常复杂的一个框架。因为我跟那个 OpenMalus 的团队聊过，其实他们本来那个项目的名字是叫 agent hub 的，他们之前没有上线，就是他们在开发，但是没有放到社区里。
其实也是几个个人开发者的工作，就也不完全是公司的工作。但是因为当时 Malus 就是刚好在那个时间点嘛，他们也用他们以前已经开发了一段时间的 agent hub，很快地做了这个 OpenMalus。所以后来这个名字就改成 OpenMalus 了。他们还是想做的是一个框架，就是它有这种调用工具的潜质，可以让别的开发者在这个基础上做你想做的 agent。
明白，那这个我倒还没有跟他们了解过这个，因为我确实没有跟他们去交流过。但具体看他们想做的未来的这个框架的愿景是什么，因为我也不是很确定他们最后的 vision 是一个什么样的 vision。它是一个偏 deep research 的 agent，还是说它是一个生成式的 agent，还是说我要去真的去 platform 去写入的那种 agent，都是不太一样的。
像最后那种 agent，它的整个 integration 难度是最高的。那前面那种就是开源比较好做，后面那个是最难做开源的一件事情。所以我对于最后那种 version 的开源，可能我认为难度会大一点，整个 life cycle 会长一些，但是一定会有某种形式的开源出现。
最后想问问 Bill 如何判断一项技术的潜力，因为之前你也提到自己一直坚信 RL，然后能做很多事情，之后 deepstickRE 出现之后也验证了你的判断。就想问你的信念是怎么来的？
我其实跟 Rush Sutton 很多时候聊，还有跟我自己的老板聊，就我自己 PHSvisor 聊。有一个很好的思维模式，就是 toy examples。比如说你看好一个技术方向，你能不能构建一个 toy example，用极少的计算量就可以证明说，这个问题是别的技术方向做不了的，而你的技术方向可以做的。
然后这个 toy example 必须是 intuitive enough，比如说这个东西是大家认为是一个 meaningful 的 example。比如说你举一些 common sense 的 example，或者说你举一个现在的话可以举一个小的 language mode 的 example。在这个 example 里面你能明确看到别的技术方向做不了，而你能够做到的。
那这个方向就已经有一个从某种意义上来说，第一性原理上面的一个优势在里面，就是说我能够判断在我所要解决的这个问题上面，只有我的技术目前有这个领先地位，而且它有 principally right solution for it，那我觉得就是值得可以追下去的。
而如果你做了一个 toy example，说明一个简单 language model 的 example，或者推荐系统的 example，或者说 data system 的 example，发现说你的技术跟别人没什么太大区别，这个时候你再有这个执念去追踪你自己的技术就没有什么太大意义。就是说如果别人已经有 scalable solution，就应该跟随别人的 solution 就可以了。
那如果按照这个思路会错过大语言模型吗？比如说其实大语言模型就是在它的规模没有到一定程度的时候，它的效果是没有那么明显，但是没有任何一个别的解决方案可以 even get close to what they’re doing。
OK，就是说虽然那个时候的效果没有到可能给工业界或者说给用户一个经验的程度，但是它是领先于其他的方法的，就是在实验的结果上来看。对，因为我在 GPT-2 的时候就接触了语言模型，因为当时有一个教授拉我去做兰工程报道的事情。
我当时是觉得这个东西方向是非常有意义的，但是我当时就觉得说我要从零开始 catch up 这个 topic，确实是有点晚了。就 GPT-2 的时候我已经基本上确定它一定会活了，就等于是这个船上面已经盛满了人，然后这些人已经知道自己要去哪了。
然后你一个半当中旁边一艘小船上的人，我这个小船要驶向一个不一样的地方，我非要跳到他的船上去去跟他凑这个热闹，我觉得可能意义不是很大。而且很有可能被人家淹没。所以我当时的决定就是说，OK，那东西 interesting，我应该 catch up，我要 learn from it。这个技术和这个技能是我要的，但是我真的要成为这个领域的可能是第一个落地者，或者前第一批的落地者可能已经不太可能了。
所以我就觉得说还是要专注自己最了解的方向。明白，你刚刚说的那个做一个最小的这个 toy example 的这个思路其实还是一个科学验证的思路，对不对？就是做实验。对，就是你要先找到一个可以自洽、就自圆其说的一个小的案例，这个案例本身得是 general enough，然后在这个案例当中，没有一个技术是目前可以解决你这个问题的，而你的技术本身又是 principally 解决这个问题的。
你不能说我 hack 一个 solution 出来把这个问题解决了，对吧？你得说我的技术是普适于这种 example 的，那你可能会有着 confidence，我的这个方向是正确的。
现在我知道的很多的 researcher 可能有一个问题，就在于你如果发 paper 的 researcher 你可以就是说 I hack 一片 paper 出来也是可以的。你可以找一个 corner case 就别人解决不了，你可以用你的技术解决得了。但真的落地的话不存在这种 corner case，你必须要找一个 minimal viable example。
这个我一般来说叫做 minimal viable example，就是这个 example 里面它是一个普适性的 example，然后有你的技术可以解决掉它，然后你也可以证明说这个技术是可以解决这一类 example 的，而别的技术解决不了它。那你接下来就可以说，OK，我能不能把这个变成一个 large scale 的问题，deploy 到现实系统里面有什么样的 bottleneck，有什么的 system integration 要做，然后把这些东西打通了。
最后落地它也不是 100% 会成的，但是至少你第一步做成了以后，你会有这个信心说至少这个技术方向有 80% 的可行性的概率，而不是我盲目的就去跑大型实验。
然后大型实验有各种各样的 complexity，它的 variable 太多，没法控制变量，导致说我也不知道什么东西 work，什么东西不 work。你自己感觉到强化学习和大元模型结合会非常有潜力，是在什么时候？
那那个时候我当时就觉得说，OK，如果可以在 token level 用 RL 去做那么复杂的 planning，那么长 horizon 的 planning，它都可以 work 的话，那我觉得说如果我们在更 abstract level 做 RL planning，它应该也会 work。因为它的整个复杂度可能并不比你每一个 step 都用 token 去做解析难多少。
所以我当时觉得说可能这个方向是个大的趋势。所以当时我其实一直在推推荐系统的 RL 落地，然后当时也有很多的落地成功案例，核心原因就因为推荐系统里面其实你可以想象每一个文章或者每一个 article，或者每个 recommendation 就是抽象的一个 action，然后你要把它们 sequence 起来，变成一个 planning 问题去用 RL 去落地。
然后和我们现在 agent 的落地，其实有异曲同工之妙的一个东西。所以从某种意义上来说，当时就觉得说这个东西一定是有 future 的，就是用语言模型其实解构了很多原来用 RL 直接加现有推荐系统，要解决的问题里面的不可解的地方。
因为语言是非常 flexible 的一个东西，你可以把它结构成任何方式，它的整个 sequential decision making 就变得更 natural，而不是说我做完一个 decision 以后，当中有出现各种各样乱七八糟的事情，然后我再做下一个 decision，然后再出现各种各样的事情，然后再做下一个 decision，而是每个 decision 之间其实是非常连贯的。
当中出现的 noise 跟 pulsually observable 的东西就变少了。你自己什么时候特别明确的感觉到就是用强化学习来做 agent 肯定会是一个方向？这肯定是在创业之前的某个时刻吧，就有这个感觉了。
我觉得毕业的时候就在想这个事，但是我构思了很久，我构思了快半年，我才想到现在的这个解决方案。就是我当时 10 月份出来融资的时候才确定这个技术方向是这个样子的。在此之前我都没有确认这个技术方向，当时一直在摸索这个技术方向怎么样是最靠谱的。
因为当时有很多很多 nuance 在里面，所以我当时也没有完全确定说，我们现在的这个环境构造以及模型的建立和 self play 是否是真的能 work。我们只是在我刚刚说的那个 toy example 上面，就在 travel 那个 toy example 上面跑通了，但是真的要 scale 到无数个场景，它是不是真的能够泛化，这个东西是个巨大问题。 但是后来验证下来是觉得他可以犯化的。 所以这件事情也是有一定冒险在里面的。 就是我觉得有的人他创业的习惯是，比如说在一些大公司的技术人员，他会先跑一段时间，就把想法验证得更清楚，甚至他人可能都找好了，甚至投资都找好了，他才跳出来。
我感觉你是直接做了决定你就出来了，但是我不知道北美是不是这样。我可能说的是国内的情况。我其实之前也有找自己认识的人聊聊，但也没有做得特别深。跳出来会有就可以给到投资人觉得说你有conviction。而且我当时也总说的就是，也没有必要一直待着。就是你一直待着，公司的经手靠会永远靠在你手上，因为mata也很忙嘛。
你如果真的在公司干着，你也不可能说真的不管公司的事。而且我手上的活当时很多都是report给整个head of monetization，然后甚至于之前有report写给CTO的那种。这种活你也不能不干嘛，这种活一定要干就要花很多时间。你也不能给这些大佬们留下坏的印象，以后在这个圈子里面还得混呢，对吧？
所以你要走的话就干脆一点就走了，然后可能就给别人一个明确的signal，而不是说一直拖着。拖着反正对自己的reputation也不好。对，其实我觉得这是一个更好的状态，只不过你自己就是承担更多的风险嘛。 That’s okay。
好的好的，那今天非常感谢Bill做客晚点聊跟我们分享了。他从本科时代就开始研究AI的规划，然后到后面做强化学习，一直在这个方向从冷门到热门见证了这个转变。然后现在他开始创业，从去年10月份的一个项目，到现在不到半年做RL的agent。我觉得这是一个非常新颖的方式，或者说比较特别的方式来实现，现在大家都很关注的agent领域的创新。
那今天非常感谢Bill，好拜拜。 本期节目就到这里，感谢收听。如果你对今天聊的话题有观察、好奇或疑问，欢迎在评论区分享想法，这也会成为我们节目的一个部分，让整个讨论更加完整。你也可以把我们的节目分享给对这个话题感兴趣的朋友们，欢迎推荐更多你想听的主题和嘉宾。
你可以从小宇宙、苹果podcast等渠道关注晚点聊，也欢迎关注我们的公众号un.leadpost。我们下期再见。