We're sunsetting PodQuest on 2025-07-28. Thank you for your support!
Export Podcast Subscriptions
cover of episode 111: Pokee.ai 朱哲清的 Agent 造法:强化学习作后端,语言模型作前端

111: Pokee.ai 朱哲清的 Agent 造法:强化学习作后端,语言模型作前端

2025/4/22
logo of podcast 晚点聊 LateTalk

晚点聊 LateTalk

AI Deep Dive AI Chapters Transcript
People
朱哲清
Topics
我与团队成员认为,当下主流的AI Agent产品都将大语言模型(LLM)或其多模态版本作为决策中枢,这种方式在工具调用方面存在局限性。LLM使用工具需要将工具描述、输入、输出等信息添加到上下文,而LLM的上下文长度有限,限制了其调用工具的能力。 我们提出的方案是:将LLM作为Agent理解人类需求和呈现结果的“前端”,而将强化学习训练的模型作为后端的决策和任务执行中枢。这种方式能够克服LLM上下文长度的限制,实现更强大的工具调用能力。 此外,我们认为优秀的通用Agent应该具备四个要素:速度快、无需人工干预、能够读写信息、成本低廉。Agent产品的壁垒不在技术,而在于与用户工作流程的深度绑定。 我们的Pokee.ai产品正是基于这一理念开发的。我们已经与许多互联网大公司和大平台的API接口打通,并尽可能避免对网页端的依赖。这使得我们的Agent能够快速、高效地完成任务,并能与用户的工作流程深度绑定。 我们相信,长期来看,LLM可能只是Agent与用户交互的界面,而Agent之间的沟通并不一定需要依赖自然语言。后端的决策和任务执行将由强化学习模型完成,这将是未来Agent发展的一个重要方向。

Deep Dive

Chapters
本节回顾了朱哲清在强化学习领域的十年研究历程,包括他在杜克大学攻读本科和斯坦福大学攻读博士学位期间,以及在Meta工作期间的经历。他分享了在强化学习并非显学时坚持研究的经历,以及从早期大模型等其他方向的诱惑中坚持下来的原因。
  • 在杜克大学完成CS本科,后加入Meta,前三年从事B2B推荐系统工作,后三年从事应用强化学习工作,并开源了Meta的核心强化学习框架PoRL。
  • 在读博期间,每周工作110小时,并行完成学业和工作。
  • 坚持强化学习研究方向,未被早期大模型等其他方向的诱惑所动摇。
  • 在强化学习并非热门领域时就已坚持研究,并取得了显著成果。
  • 从图灵奖得主Rich Sutton的经历中获得启发,强调坚持方向和专注的重要性。

Shownotes Transcript

欢迎收听本期晚点聊我是晚点的作者孙海宁今天很开心能和曼琪一起录制本期节目几乎所有主流 AI Agent 的产品都把大语言模型或者它的多摩菜升级版当作决策中枢在用户使用界面下是一个或几个大语言模型位居中心编排工作 调用工具但也有不同的路我们今天的嘉宾 Poke AI 的创始人朱哲青

Bio 认为大语言模型只是 agent 理解人类需求向人类递交产出的前端后端决策完成任务则可以靠用强化学习方法训练的不依赖自然语言的模型完成 Bio 提到把大语言模型当作大脑时 agent 调用工具的能力有限这是因为大语言模型使用工具时需要先把工具描述输入输出等相关信息作为上下文输入模型

而大圆模型支持的上下文长度有限把 agent 决策中枢换成另一个由强化学习方法训练的模型可以解决这个问题本期播客中 Bill 还提到优秀的通用 agent 需要具备四个要素实现任务比人快无需人工干预能读取信息也能写入信息成本低 agent 产品的壁垒不在技术而在于和用户的工作流深度绑定此外我们还和 Bill 聊了他对通用 agent 接下来竞争态势的判断

以及他在强化学习还没有成为显学时便相信强化学习潜力的原因我们的对话将从贝尔一边读强化学习方向的博士一边在 Meta 工作的经历聊起最后说一些声音上的注释贝尔本科就开始在海外留学不太熟悉常用部分专业名词的中文表达

本期多次提到的 RL 是 reinforcement learning 的缩写即强化学习和强化学习相关的表述还有 policy 即策略指强化学习模型完成任务的方式 reward model 即奖励模型用于评价某个决策的好和坏 ground truth

即真值,指训练模型师使用的标准答案 Exploration,即探索,探索可能完成任务的新路径是强化学习模型的一类动作和 Exploration 相对的概念是 Exploitation,即利用利用已知信息选择最优的动作此外,对话中提到的 Presumer,即 Professional Consumer 是指专业用户 Context Length 是指大模型的上下文长度这些注释也能在本期的 show notes 中看到下面我们就正式开启本期节目吧

那先请哲青被我为听众简单介绍一下自己的经历可以吗

我先讲讲我自己过去七年的事情就是我 14 年来美国然后是在 Duke 这边完成的 CS 本科然后后面就立刻加入了 Meta 在 Meta 的话前三年多的时间是在 2B 的推荐系统的业务这边我们当时是从零开始搭建了一整套 B2B 的推荐系统包括正常的商业增长和广告增长的推荐系统业务当时也是刚开始有基于深度学习的推荐系统

然后我们等于是带团队把一整套的推荐系统就做出来后面的三年多转到了 AI 这边做 Apply Reinforcement Learning 就是应用强化学习这个团队的负责人然后主要负责的业务就是把强化学习落地到整个 Meta 内部所有的产品线上面包括广告 推荐系统 Reels 短视频 Data Infra 这一系列的这些产品上面然后与此同时我们也开源了 Meta 的一个核心的强化学习框架叫 PoRL

这是我们落地所有产品的一个核心机制当时发出来以后还是非常火的大家都觉得这个方向和 modelization 做得特别好然后与此同时我们也发了一些 paper 所以我们其实后面三年在强化学习方面在强化学习火之前其实已经做出了很大的硬盘其实估算下来每年将近有 5 亿美金的年收入是由强化学习算法带来的

在广告上面的硬派尤其突出然后在推荐系统和短期视频这边也有很大的业务的贡献所以其实我们在强化学习由 DeepSeek 带火之前其实就已经有很大的一个硬派由强化学习带来的

然后在 META 工作同时我也在 Stanford 把强化系的 PhD 读了这个两个是并行的一个时间状态像你这样就是一边在 META 其实你是全职工作然后一边读博士这种在同学同事之间常见吗应该是不存在的

那你当时是怎么达成这种安排你怎么说服公司和你学校的老板就是导师都接受这样一个状态了这个是比较机缘巧合的东西就是你可遇不可求的我所知道 Berkeley 好像有一个学生是这样的然后 MYU

其实 Proplexity 的 CTO 他也干了一件类似的事情但是他在公司属于不算完全全职就是他的工作跟他的 PhD 是非常强相关的因为他的导师是同一个所以他基本上他做 research 就只 focus on PhD 的那个东西

所以还是有一些这样的我有很多的 alignment 是我跟我在公司的老板跟我自己的 PhD 导师 aligned 就是说这个方向是不是大家都感兴趣大家都想落地公司也同意这个事情然后学校也觉得这个是可行

然后才能做这些但是工作量非常大一个礼拜大概 110 个小时的工作量所以就是基本上除了睡觉以外就是在做 research 工作所以就是你这五年选了一个 hard 模式对吧一边上班一边读博对六年多这段时间可能工作量就跟创业没什么太大区别甚至于比创业还减轻一点因为创业你至少还能 delegate 给别人对吧那段时间你早期特别 PhD 的活你没有任何人可以 delegate 你就自己看吧

然后公司我是那个 TL 和 manager 之前也不能 delegate 给任何人也得自己做所以有很多事情就只能自己苦干也没有任何的巧见可以使创业嘛至少还有点巧见可以使你花点钱雇个人是吧那也能把一些活给干了那你觉得这个过程因为他是个比较特殊的经理吗你觉得给你带来什么呀

我觉得一个很重要的点是时间管理这个其实跟我们现在创业的 idea 很相关就当年就 hopelike wish I had this 因为当年如果很多这种莫名其妙的事可以由 AI 帮我做了的话我其实觉得会省下很多很多的时间时间管理的一个核心点就在于说你要知道你的 priority 是什么

比如说你什么时候应该摒弃一些东西什么东西是值得花时间做的这个事情是非常重要的一个 career lesson 就是说很多时候有些事情你花 20%的精力做到 80 分就亏了而不用学 100%的精力做到 100 分而有些事情是非常非常关键的你就需要花 100%的精力做到 100 分然后有些事情你可能觉得可有可无的你甚至用 0%的精力把它给抛弃掉

那怎么去取舍这件事情其实非常重要如果每件事情都想要拿到的话我觉得我可能读不下来这个 PHD 然后第二个事情可能就是说要找准方向其实我在 PHD 当中走了很多弯路就因为 RL 落地这件事情在当年不是一个很火的话题而且很多人都不看好这个方向甚至于我们当时 director 有一阵子就我加入 MetaRL 组之前我们的 director 是要把这个组给关掉的就是我

看到这个组要被关掉了然后原来带这个组的老板走了以后我去找那个 director 说你别关这个组我来带这个组原来有 20 多号人剪到最后只剩三个人然后我去带这个组以后再回到十几个人这么一个 turn around 所以当中其实有很多很多弯路但是你要找准方向以后你得坚持下去

就是说你不停的换方向这件事情是有很大的就是沉默成本的你是中间试过想换方向是吗我倒没有试过换方向我没有想过换方向就从来没有想过这件事情就一定是 RL 落地为核心的这个目标就一直走了

十年了快那你说的弯路是指什么了你说 PHD 中间有很多弯路就是会有很多的诱惑比如说我当时有人拉我去做比如说早期的蓝规矩 model 做 chipboard 那种然后也有人去找我做 3D 的 vision model 当时还有人找我做那种 safety 的 model

这些东西我当时到最后就做了一小段时间就停下来了因为我觉得跟我的核心路径没什么太大关系就你要知道这个东西什么时候要把它 cut off 你不能说让它成功成本无限的去增加因为回头看的话现在大圆模型其实是一个你可以叫它显学吧反正就是很多人做一个方向然后你也说当时有人找你去做早期的大圆模型还有 chad ball 的这些事情你不觉得那是个好机会吗人总不能这样回头去看这种事情的

比如说我当时做了然后我变成了第一个做出比如说 instructivity 的人那我肯定觉得说那可能是比现在更牛的一个路径了对吧但是你永远不能假设但是我当时也不了解预言模型我当时最了解的还是 RL 这条路那我就是把这条路做好做精真的能落地能在业界有 reputation 真的有一些 work 是大家所熟知的东西这

这个我觉得是更重要的事情我觉得学术研究有一点确实挺有意思就是你怎么选方向因为每个方向都会经历沉浮就起起落落然后你怎么在这个过程中间一直往下走比如说你之前跟图灵奖得主强化学习之父 Rich Sutton 你们也交流比较多然后你也觉得他给你很多启发对他早年其实是非常不顺利的他早年有将近四年时间是整个 research 无人问津的一个状态

你能想象现在图灵奖得主当年没有人理他的 research 有四年时间连没有一个教职愿意找他就类似于这种状态当年没有人认为 RL 这个东西是 useful 的到今天所有人都觉得 RL 是一个就是 must have 那这个过程的转变其实是非常 inspiring 的

其实当年 Hinton 有遇到过类似的情况当年他早期推 Deep Neural Network 的时候也是所有人都觉得说 This is bullshit 没有人会觉得说这个东西有未来所以我觉得最大的 inspiration 就是说如果你自己的思维框架认为某一个方向是正确的

你可能就得坚持下去然后你可能有时候也会认为说很多人都可以跟你做一样的事情然后他们也能够做得很好你觉得你可能没有优势但是别人可能就没有坚持下来做你这个方向你可能最后还是成功了

就是说很多时候可能还是得拙一点你如果自己有很坚信的东西至少得把它走通了或者说你真的证明了说别人已经做出来你没有办法去 take over 了可能你才能去说 OK what's my next step 而在办当中不停地去 question 自己可能只会给自己带来过多的 noise 然后去阻碍自己的发展所以 Bill 你刚开始研究 RL 的时候 RL 已经是门选学了吗就 Bill 可以给听众讲讲你在念书的时候学界对 RL 态度的变化

就是最早期的时候我是跟 Romper 做的 RL 然后最早就是做 planning 就是规划的一些 research 当时的话其实 DeepRL 还没有那么火 DeepRL 是 2016 年的时候因为 AlphaGo AlphaZero 然后这一套东西变火的

从 AlphaGo 到 AlphaGo Zero 到 AlphaZero 这三个迭代其实花了蛮久时间的当时 DeepRL 这件东西本身是不是完全形成共识其实还是在一个发酵的过程当中所以当时我还是更 fundamental 的去学了一下 planning 的整个 landscape 是在做什么就是现在的规划能力的这个跟 tree search 更相关就 Multicolor tree search 这一段

比较相关的一些研究然后到了 Stanford 以后呢发现就当时其实 Deep RL 已经形成气候了所以 Montecarlo Tree Search 这一套的 planning 能力从某种意义上来说在新的 Deep RL 的这个时代呢没有那么重要

当然了后面就证明他还是蛮重要的一个能力然后我就去找 Ben Ben Roy 读 RL 的 PhD 然后 Ben Ben Roy 可能做的东西跟 Ron Paul 就没有什么太大关系了但是他俩是很好的朋友所以当时我去 Ben 这边读 PhD 是 Ron 推荐的

然后在 Bench 这边读 PHC 的时候是更多的做 sample efficiency 当时我们主要研究的是如何把那个 reverse scaling 就是把数据需求从最早的很高的数据需求不停的往下拉就是拉到现在可以完全 trackable 的一个数据需求的状态让 RL 算法真正可以落地

因为奥拉算法的一个核心的痛点就在于是说你所需要的交互数据量是非常非常大的因为你所规划的并不是一个单步的事情而是一个非常非常多步的事情所以它所需要的数据量跟你的整个规划的整个 steps 的数量以及你有多少个 action 多少个 state 都正相关的一个东西

所以问题更复杂的情况下你所需要的数据量就无限的在往上涨所以从这个角度来说你如何从一个比如说 linear scaling 变成一个 square root scaling 这就变成非常非常重要比如说你有 1 万个工具可以调用每一个工具你要用 100 个数据点可以学会这个工具然后你要 1 万个工具要学会的话你就要 100 万个

有几个 step 第一个是你能不能泛化就是从工具到工具的泛化你可能可以比如说一万个缩小到比如说五千个或者说一千个然后你是不是可以把泛化完的数据在不只是直接 scale 到比如说一千个而是说 square root 比如说变成根号一千

就是说你的所有的理解这些一千个或者一万个 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 甚至有很多人我十月份出来了以后都直接 reach out 给我说能不能加入这家公司当时我还没有透露我们融资的各种情况的情况下大家都非常有加入的倾向

所以我觉得这个大方向还是非常有潜力的总体来说可能整个创业的驱动力就在 Deep Seek 火之前我们就看到了 RL 在整个业界落地以及 agent 方向的一个巨大的潜力为什么你觉得 RL 是 Deep Seek 带火的不是 OE 带火的呀

OE 其实他说了他是二摇驱动的但是大家都不知道他背后的二摇逻辑是什么大多数的猜测是在于 OE 可能用的是一个叫 Inference Time Reinforcement Learning 就是说他可能在训练的时候做的还是 RHF 但在 Inference Time 的时候做了一个 Chain of Thought

就是斯维莲的 Multicolor Tree Search style 的一个做法这个其实到目前为止都没有任何定论就是因为欧巴亚自己的人也从来没说过这事但是从它的推理速度各方面来看确实大概率他们在训练的时候应该没有做太多的优化更多的是所有的 effort 都放在了就是 inference 就是推理端

然后 DPC 为什么火的原因是因为它其实核心就回到了可能当年 alpha goal 到 alpha zero 之间的一个状态就是说我不需要在非常复杂的人为去标注每一个点的 performance 用一个像 RU 一样的一个东西就可以帮助你去判断说这个 agent 在某一次 sequential 的 action taking 的这个过程当中你做的是不是好那

那它就解决了两个问题吧一个是在 RHF 这个过程当中你学大量的人为标注去训练一个 reward model 那第二呢就是你的整个训练速度会变得非常快就是说我每次 sequence actiontake 完了以后所得到的结果可以立刻被一个几乎可以是 ground truth 的一个 reward 去 evaluate 然后再去训练这么一个 agent

所以它几乎就回到了当年 AlphaGo 和 AlphaZero 这个中间代我还没有到 self play 的阶段但是我可以在没有外界干预的情况下就能够训练出一个超过现有最好模型的一个模型了当然了它有自己的问题在比如说 DeepSeek R10 这个模型它是纯靠 RL 的 Rubis Roar Model 这个模型本身呢从某种意义上来说是人类不可读的一个东西就很多时候它 output 的东西就是 Gibberish 就是

就是他可能从 Ruby 的这个系统里面可以 score 一直在往上涨但是你真的把那个 output 拿出来给人赌

人可能就读不懂他在说什么了对所以他后面又做了从某种意义上来他又包了一层就 RHF 的那一层所以我为什么说他还没有完全到 alpha zero 的那个状态的原因他需要大量的 human 的 heuristics 就是人类的一些经验化的东西在里面去帮助他去找到一个人类比较喜欢的一个状态所以我为什么会把他放在这个阶段的原因当然这个类也不是百分之一百准确

你可以和我们的听友简单解释一下用 RL 来作为 agent 的核心它大概是一个什么概念然后包括也可以对比一下就我们的听友可能知道的一些 agent 比如像 deep research 或者说大家最近讨论比较多的 malice 就这些 agent 它又可能是以什么为核心的我觉得这个又牵扯回 agent 本质是什么就是大家把很多不同的东西都称之为 agent 那

那从我的概念上来说我们设想的 RL agent 是以 RL 为核心做所有决策驱动的一个 agent 它不再是说我只是输出一段文字然后这段文字当中有一部分是工具调用然后这段工具调用是嵌套在整个文字当中的一件事情

而我们会认为说所有的 planning 和 reasoning 以及工具调用的过程是一个抽象化的过程就是说它可能有一个 conceptafter 一个 concept 规划的能力在完成这个规划以后其中有一部分是某种工具其中有一部分可能就是 information retrieval 就是它的整个构想方式和现有的 agent 都不太一样这是为什么 agent

Agent 的核心模型都不是一个语言模型的原因那这个从用户角度怎么定义了因为可能对大部分人来说他其实不在意怎么实现吗所以我刚刚说的是偏技术层面的那偏用户层面的话我个人认为很重要的一点就在于说不管是 Deep Research 还是 Manas 也好它仍然是一个 Serve the Internet 的一个状态那它没有一个写入 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 里面让他选择一个工具并去调用它这是非常难的更别说我们做的不是一个单一工具调用我们是一个比如 10 步十几步的工具调用

那你想想你完成一步工具然后你把这个工具调用做完了以后你再把剩下已经出来的结果可能说你拉了一篇文章出来然后这篇文章再放回你的 prompt 里面可能这篇文章本身又有一半个 token 然后再放回去然后再去执行下一步你想想如果是十几步下来那就是上百万个 token 一次任务 100%的所有的 OM 都会产生换取所以

一个核心点就是为什么我不用语言模型作为核心决策点的原因就是因为想要规避掉这种问题 OpenAI 的 operator 在功能上它是希望能写入互联网的对不对它是希望能做一些操作的对对对但是 operator 的成功率非常低对它不是很好用目前

其实从多者意义上它比 minus 要强一点对 minus 写入的能力其实没有 offer 的强但是 minus 的 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 就是

二辽是一个通用的工具它在应对任何环境下它都有它自己的优势在而 LM 本身是为了帮助你去理解文字来进行操作的但是文字的长度总有它自己的限制就是它的整个 context 你的 tension 的机制总和你的模型大小是有正相关的当你的信息量无穷大以及你有大量的 memory

的储存的时候那你就需要想办法在一个相对比较抽象的环境当中去做决策我们希望说能够通过 RL 的方式去把整个决策层给抽象出来然后把工具的规划以及调用完全由 RL 单一模型来完成然后原层留着单纯作为理解和交互的功能就相当于我们认为长期来说 LM

可能会是一个 UI 它可能是互联网的 frontend 但是互联网的 backend 所有的工具的交互以及 connection 是由某种 protocol 加上某种决策机制来完成的比如说你告诉 agent 说我今天是早上去买一个菜然后他可能他把这个语义理解下来以后就 pass 给一个 URL 模型 URL 模型说这个用户想要做的是买菜并在

这个服务提供商这边去买然后他就通过某一个机制把这个信息传达给对方的某一个 agent 就可能是 B 端的 agent 这个 B 端 agent 收到这个信息以后再把它从他们的某个库里面数据库里面去拉出来说如果这个用户要在这个地方买这样的菜需要在哪里可以买到

然后把这个信息抓取回来以后发一个 request 给比如说可能线下的某一个人然后这个人收到这个 request 以后就把东西送到了这个人的家里而这个过程当中是不一定要用语文字信息来传输的在这个过程当中完全可以是由数据库 operation 加上你可能后端的一些信息的流动来完成的

然后完成了这些所有的操作回给用户端的可能是一个偏文字的东西再转化成文字说 OK 我已经帮你叫了这个人把你的菜送到了这个地点然后你自己去取所以我们可能长期以往比较相信的是未来的后端的所有东西都会相对比较黑和化而不是全部由文字的形式来输出

被问的意思其实是像大语言模型它更像一个翻译器或者说人和机器交互解密而 RL 更像一个规划器一样的东西是这个意思吗你可以这么理解但是我需要解释一件事情就是 RL 跟语言模型本身是不冲突你可以用 RL 来训练语言模型但是你也可以用 RL 来训练一个非语言模型来解决更抽象的环境里面的任务

就像你用 RL 去做机器人一样比如说你把 VLM 里面的规划过程变成一个 RL 的一个决策一个 policy 那在这个过程当中其实它也不是一个语言模型 RL 是一个通用的工具它在规划和推理能力上面很强所以你可以用它来做任何的抽象的规划以及决策的这个事情这也是为什么我们决定说前端仍然由 LM 来完成但是后端就完完全全就不用 LM 了

刚才提到一个很好的问题就是那个 LM 它其实没有办法承载太多的工具就比如说比如你提到 50 个以上它可能就记不清或者说产生幻觉了那这个是可以解决的吗你觉得还是说这个长期来看也是不能解决的就是这个事情你要说我有无限的计算量然后

然后我永远可以去 scale 我的模型大小那 eventually 当然是可以的因为就是 attention 的复杂度基本上跟你的模型大小基本上是可以成正比的就是说你需要关注的点的数量和你的模型大小基本上是可以同比例去 scale 的那在这种情况下如果我们假设有无限的

计算资源以及无限的 scaling 那确实是可以做到这一点但是前提就是我们没有就是说你不能假设说永远的我们就不停的去扔计算资源去完成更复杂的任务因为大多数情况下未来的复杂任务可能变得更抽象或者说你的工具都不停的几何几数的在往上涨那 LM 只能比如说 linearly 去增长它的 context length 所以它不可能说永远无止境的去把世界上所有的工具都包进来

就是你可以想象一下未来你可能平时想到的所有的工具包括垂直领域的所有的工具都能够被集成在一个系统里面那在这种情况下它可能就并不是一个非常 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 给听众讲讲 Poke AI 具体的 agent 产品我最近试了一下感觉它的交互界面和其他的 agent 长得差不多就是屏幕分两半左边是和 agent 交互的聊天界面右边是呈现 agent 执行任务的结果 Poke AI 和人类交互的方式在设计方面有什么不一样吗

我们的目标还是能够以非常简单的方式让用户能够体验到说什么任务已经被完成了什么任务没有被完成那可能有一些不太一样的一点是说我们是会在执行之前询问用户整个任务的完成情况和整个任务的规划情况是否是用户满意的然后再执行目前大多数的 agent 的体验方式都是我们叫 free flow 的体验方式

就是说你不知道 agent 每一步会干什么而是他自己就会慢慢 roll out 一步一步一步一步的往外打开做各种各样的 function call 或者说执行各种各样的生存式的任务而由于我们的任务都会直接写入用户的互联网账户和他们自己生活和工作当中的各种各样的平台所以我们希望说我们所执行的操作的规划是用户所满意的

所以有了这么一个设计就是多了一步用户的 approval 的过程与此同时的话还有一点不知道海宁你有没有试过其实在整个流程当中如果说当中是有一个叫 step by step 的一个 execution 也就是说如果你点那个它每一步有很多步如果不是搜索的话它都会让你去点是否同意执行所以你可以看到说这个执行的 input 是什么如果这个输入你不满意你是可以手动修改的

这样的话你对于整个产品的 flow 是有更多的控制的而不是说你点了一个键然后 there's nothing you can do 这种状态这是非常无助的因为如果他真的卡那卡半多小时然后最后说他不行了那你其实觉得说这是完全在浪费时间所以我们有这么一个设计那有一个非常重要的点就是我们其实收到过非常两极分化的反馈

就偏 business 的那些人他们会觉得说如果没有这个同意按钮他们会觉得疯了就是这个东西他就自己在那执行然后写入我各种 Facebook 和 Instagram 账户和 LinkedIn 账户然后也没有我的同意这个我会非常没有安全感但是开发者这一段就是真正 AI 发烧友或者说 researcher 或者说开发者他们会觉得说为什么要给我去点那个同意按钮

就直接一下子全部拉完越快越好就好了所以在用户体验方面其实有很两极分化的这么一个情况出现所以我们支持了两种模式你刚才还提到就是说一开始会把那个流程给用户看然后让用户去决定这个任务完成流程是不是合理的

这个是不是很常见的 Manus 也会做类似的功能如果是用 operator 的话很多时候它是不给你的 Athropic 也是不给你的 OKManus 它是会给你看然后看完了以后它就自己去执行了它也不会说你可以去改执行界面然后你就一个个去把它改完了然后让它就根据这个去执行它应该也是不是

所以他就是会自己收他会有一个 Dock Rider 然后这个 Dock Rider 是一个 LM 然后这个 LM 他会写一些 bullet points 然后就放进一个 TXT file 然后他在执行的过程当中会让你看一眼但你并不能说我要把这个暂停下来然后真的跑到那个 TXT file 然后把这边全删了然后重新改一遍然后他继续这个再去执行这个我记得是不支持的我自己用的时候发现一个挺显著的区别

OK 它没有一个虚拟机一个页面展示说这个机器具体在做什么比如说它是不是打开网页然后是不是在写文档之类的这个是为什么不加这样一个页面展示它首先我们其实大多数任务都不用 browser based 所以我们的特别是写入互联网账户的这些都是跟那些公司有官方的借口和官方的不说合作就是官方的这个 access 的

所以从我们的角度来说这些内部的信息就跟那个公司的 privacy 有关跟公司的章程有关我们不能一直去不停地去拼他的那个 status 然后把那个 status 告诉你这个可能不是特别好然后我们后面在一些 deep research 方面的这些任务呢不会给你们虚拟机吧但是会告诉你们一步在干什么这个会做到在交互页面之下 Pokeye 它完成任务和其他 Legend 产品有哪些差异呢

首先最大的差异一定就是在执行册就是和几十个互联网大公司和大平台的接口以及这些平台接口背后那数千个目前可能一千多个 API 的接口的打通这个是目前市面上没有任何人可以做到

然后一个核心的难点就在于每个互联网大平台背后的接口本身是非常相似的然后有很多 API 互相之间都是几乎长得一样的这些东西你是怎么能够让它更好的去分开让一个 agent 可以完全能够使用这 1000 多个接口然后能把它做好这是视频上没有第二是我们尽可能避免了对网页端的依赖

就是说有很多东西你其实还是不得不用网页然后你很多东西还是不得不说我要做一个 search 那这些东西我们还是仍然在做 search 但是除此以外我们如果能够用代码来解决就写代码去解决一个问题我们就写代码如果说能够用接口来解决就用接口我们

我们未来也会接 mcp 跟 agent to agent 如果能把现有的 mcp 跟 agent to agent 接进来我们也会用它们但是我们一定会避免用 browser 来解决问题因为 browser 在我们眼里不是未来因为如果未来世界上都是 agent to agent 的话那 browser 的存在只会是一个中间态所以我们尽可能去避免这样的一个形态出现为什么要把能接入各个平台的 API 作为核心买点它对应 pokeai 核心户的什么需求

Pokea 的核心用户一定是开发者和 professionals 就是他们是我们可以理解成一个 2B 业内的一个 2C 加 2B 产品就是它的用户场景一定是 2B 的就是说它是一个在工作流当中要完成一些任务来用这种方式就是用 Pokea 来完成在工作流当中的所有的自动化

但是使用者很有可能是一个个人开发者就是他是某家公司的一个个人的开发者他有可能是某家社媒平台的某一个做市场营销的职员他有可能是个某个广告平台的广告投放员他有可能是某一家公司的法务也有可能是某一家公司的财务

那他们做的事情仍然是一个 B 端的事情但是他使用的人可能是个 C 端的人然后在这之上我们未来会往更多的 enterprise 去走就是跟某些公司内部的 infra 去打通那这里面其实有很多很多的问题在就是为什么大多数公司特别是大的公司以及对数据有很多的 sensitivity 的公司他没有跟 OBI 打通或者 anthropic 打通的一个核心原因就在于这里面有很多的 privacy 的问题在里面

所以你能不能做到 private cloud 你的模型是不是足够小是不是足够 scalable 能够做到这一点这个是非常非常重要的所以我们之后也会花力气在这个方向但目前我们的主要受众还是个人的开发者和 professionals

这个我觉得还蛮有意思因为可能更多的 agent 产品它的目标说中就是最广大那些消费者但是 Poke 的定位是找那些专业的消费者这个定位是怎么找到的呢因为我们最早有了这个 idea 的构想的时候其实就跟好几家我自己认识的广告社媒营销一些业内的人士就有沟通然后他们听到我这个想法以后他们就觉得这不可思议因为他们的最大的痛点不在于生成内容

现在因为生成内容真的很容易了但他们的问题是即便你能生成这些内容我还是要花三个小时四个小时在各个平台上面去进行传播进行推广但更麻烦的是如果你是个社媒平台运营管理更麻烦因为比如说你这个帖子发出去了可能有几十个回复出来了你能到手动一个个去点它然后就回复它吗

现在 Pookie 的话你就可以直接说找到这个帖子把下面所有的回复用个性化的方式每一个回出去他就可以把你回完了所以他可以省下大量大量的时间帮你做各种各样的事情理解但就之后拓展的方向为什么又再到企业端用户而不是说更广大的一些更普通的消费者消费者我们要看情况但是我们目前对于非常非常 general 的纯 general agent

的观感是用户很有可能会被你能做的事情给 overwhelm 而去执行一些跟你能力范围不匹配的事情就比如说像 operator 这样的一个 2C 产品对吧然后我和我身边的朋友第一反应是做我现在说的这些事情不是去搜索内容而是去真的是执行帮你去比如说安排个会议发个邮件类似于这种我第一反应是想做这件事情

然后我试了以后发现一个都不行就是 0%的成功率然后当时我拿到 Mindless 邀请码以后我也干过一样的事情比如说你帮我 Facebook 发个帖它也是几乎 0%的成功率那当然了跟我们一样做一些简单搜索啊做一些内容的收集啊生成一些代码啊什么的它都没有问题对吧那这个是我们可能还没有做那么深但是在执行侧目前是没有人可以跟我们做的一样深的

所以我们的目标请你更多的是说 OK 那工作流在哪里对吧

我们现在有个人开发者跟那些 presumer 这些人群他们有大量的非常繁杂的工作流但真正的工作流还是在企业内就企业内部会有几十步上百步的工作流需要去解决所以我们需要解决的是说 OK 那未来这一百步工作流是不是能够直接被 agent 取代了里面有些需要人在的地方 agent 去主动找人完成而不是人做半天然后每一步当中去找一个 LM 去解决内容生成的问题

所以这是我们最终想要走的一个方向能进入一个大公司的工作流然后它取代几百部的可能是之前的自动化流程这个你觉得 Poke 它和已经在提供这样服务的比如说 South Force 这样的公司是竞争关系吗还是

我觉得不会就是像大公司的工作流是足够复杂的当然我不觉得 Salesforce 和 Agentforce 做得很好因为好多人都跟我吐槽的主要是这种拖拽流的 agent 无可避免就是它有一个 regioness 就是除了这个工作流稍微变一变它就又不行了的这个问题在所以我倾向于把 agent 或者工具就是那种拖拽流 agent 工具还有那些 LM AI 工具全都包成一样的

态度就是说他们都是某种工具而已然后你需要的是一个更上层的能够更好的规划已经知道无限调用的这样的一个功能这个可能是我们最后的使命所在 Torch 这样一个相当于是人工编排一个工作流按照这个工作流严丝合缝执行这个可能就是大公司最重要的需求因为他们的工作流可能是更加僵硬或者固定的而且变化比较少

那就当有一个有自己生成工作流的能力的 agent 出现之后他们就真的会有这样的需求吗这是个特别特别好的问题这是为什么我们会从小的 presumerdeveloper 往上走的原因原因是在于你要去改变大公司的工作流的走法其实是非常难的

但是我其实有很多的观察就是很多大公司的工作流是大家希望它改变的而不是说大家都觉得按部就班就很好所以需要做的事情是一个 bottom up 的一个 influence 就是说你可能很多原来二三十步的工作流可能就只需要七八步就可以搞定可能并不需要那真正二三十步的那种工作流当中很多内容或者很多的步骤都是多余的

所以如果你有一个 AI 自动生成的工作流的模型可以把工作流所对应的所有工具以及给人派遣任务的这个事情都可以做完的话那因为

那 Eventually 当这些我们在共同成长的这些小的公司或者说个人的开发者一起成长以后呢他们会去 influence 那些更大的公司说他们已经做到那么有效率了而且做事情做得那么好了那这些大的公司也会想办法来 adopt 你的 solution 这个 sell cycle 是非常难的因为没有人去希望做那种打破原有界限的这种改变嘛

所以我们可能会先 focus on 中小型公司加上个人开发者和 presumer 然后慢慢的再去 influence enterprise 可能需要一些你自己的 trust 在里面就是你认识的人然后他们知道你的 agent 能力边界在哪里他们才会去 deploy 但是我们已经看到一个比较好的 sign 了就是我们一些 one2 的朋友他们把我们的 agent 的 demo 和一些简单的尝试的一些用力发给他们的老板以后他们老板其实很想买我们的产品

所以在执行侧大家还是会有这个需求在里面另一个比较好玩的点是 Poke AI 如果有一个子任务没有完成的话其实不妨碍他继续执行后面的任务

我们有因为是 RL 生成的整个规划以及执行就是说他会知道说我的这个 action 之前的 context 是什么然后这个 RL agent 会说这个 action 可能跟之前的 context 没什么关系所以他就会跳过某一些内容然后去完成下一步就是说我尽可能的把你整个任务都完成掉

能完成多少完成多少然后下一步你可以再跟我交互说这几步没有完成然后怎么去根据现有的信息再去完成下一次我们是这样去思考这个问题的因为你的目标不是让用户被卡住而是说能完成多少尽可能去把它完成好理解那如果 Poke 整体任务失败的话它可以继续自己 debug 重新尝试吗因为我自己在试的时候它好像还没有这个功能对它现在我没有打开因为我还在测试这个东西还是跟原来那个情况很类似就是说

我们希望能够让他非常 stable 去 debug 因为如果说他 debug 完了以后他自动执行了而他可能把你的 input 的那些内容给改掉比如说你想发布一个文章然后他 debug 的时候发现你这个文章内部有什么问题然后他就直接给你改完了以后给你发出去了比如说我有一个非常 classic 的问题就是 linkedinlinkedin 如果你连续发两篇一模一样的文章他会把你 blog 掉那即便你用的是我们的官方借口

他还是会有这个问题那如果说一个足够聪明狡猾的 agent 比如说 Pokey 我们已经见过他干这种事情他就会直接给你绕开他说我把你那个内容稍微改一改然后再给你发出去但这不一定是你想要的这个体验对吧所以我们要去找一些 case 可能说有些是可以绕过有些是就应该让他直接 fail 然后告诉用户当然 LinkedIn 这个 case 你可能是希望 agent smart 一点就真的把它绕过的但是有一些 case 就是你不希望他绕过

我自己试的时候发现 Poke 完成任务的速度非常快大概一分钟左右就能完成一项任务这个是怎么做到的呢对你看我们的 demo 那个视频里面从不管是什么社媒账号运营还是 meeting 还是我们之前做分析这三个例子里面所有东西我们都没有加过速就是原始速度当中包括了所有的 approval 你可能来来回回再点那些加起来是 60 秒如果那些 approval 全都不要就让它自己转的话可能就十几二十秒就搞定了

这个就不能细讲我们的做法不是 browser use 我们有 browser 的部分但是呢有很多 action taking 的地方我们和很多公司是有合作和集成的所以很多 action taking 的地方是有极大程度的压缩的我们可能最后会有一个你们会看到一个对比图就是说我们和 browser use 的这些 agent 相比

速度和准确率可以极大幅度的提升然后在大多数的任务场景下面我们都可以 autonomous 但那些非常 niche 的那些场景上面他们其实也做不好所以我们也就不做那些场景我们会告诉用户怎么去做然后在对于那些 MCP 和 agent SDK 的这种竞品上面我们所可以覆盖的产品

和工具列表或者平台列表要远高于他们就是我们和两种竞争者对比起来我们都有很大的优势所以你们去调工具你们不是用的 MCP 这个协议是吗或者说你们只用了一部分不是你们不是用

我们完全没有用但是我们后面会支持 mcp 因为有很多人已经建了 mcp 了 why not 但是我们之后会有个协议会更简单你就告诉一个 json file 把 input output 和你的 endpoint 就比如说你是个不管是什么样的 api 或者说工具你把 endpoint 告诉我们我们就可以直接调用了你也不用 host 嗯

那你们现在能调这么多工具相当于是就是你把你刚才说的那个更简单的协议在那些你们想用的软件和工具上你们自己加了一层对对对但是并不只是就正常的 API 或者 browser 还有很多很多别的工具在里面嗯所以就不能非常的笼统的告诉你们说工具都是怎么生成的因为有很多很多工具是以不同的形态呈现的嗯

听起来感觉这个好像还是一个挺重人力的过程因为当时提示 MCP 的想法就是说所有人能群测群力你做好一个工具别人就不用再发明一次这个你怎么看目前来说我们还没有遇到这个问题后面肯定会遇到这个问题我们也会做开发者社群我们现在预估第一轮 release 也就是 1000 个工具左右就是 1000 个可以调用的子工具可能平台可能几十个然后子工具加起来

上千个这样子而已然后我们会做开发者社群让所有的人使得他们的 SaaS 软件或者他们的工具能够非常轻易的被使用然后他们只需要告诉我们他们工具长什么样他也不需要告诉我上下文他也不需要告诉我任何的什么东西就是直接告诉我 input output 和他们 endpoint 怎么靠他们就结束了然后我们就可以把他们的工具直接吸纳进我们的整个 ecosystem 里面所以你们这个属于 mcp 的竞品吗

我们也会用 MCP 所以不算竞品就是人家如果说想要更简单一点不需要安装也不需要做什么 JavaScript Server 那他们就可以用我们这个就日子好过多了有一个比较无限扩展的这种工具调用的能力肯定是很多做 agent 的人都想实现的一个东西也能很自然的看到这个东西是有价值的

那实际上大家的实现方式主流的来说有哪些了比如说你们的这种尝试可能是一种你有看到市场上其他人有一些其他的你觉得比较有潜力的实现方式吗大多数还是以 LM 为核心吧就是还不太能见到非 LM 模型在这个方面的应用的

有几家公司在做一些跟 contrastive learning 相关的一些 approach 但我们试用下来可能也不是效果特别好他们可能就偏传统的那种带一定 supervision 的那种模型就这种模型在我们现在试用下来可能效果并不是特别好因为它的 negative 的 noise 太高了比如说你有上半个工具这上半个工具当中只有一个是正确的

那你得到的 negative signal 就太高了比如说你随便去调用里面任何一个工具它大概率都是错的那你等于说这个工具可能你被 sample 了无数次人为帮它标注了也无数次然后到最后连一个正确的解都没找到那这样的话你训练起来就难度非常大

所以从这个角度来说你需要一个非常 smart 的一个机制去完成这个训练这是我们的一个 secret sauce 吧你可以讲讲就是从 24 年 10 月你当时比较明确的要出来创业然后到你开始构建 Pocket 这个产品你中间关于一个好 agent 应该怎么构建应该具备什么样的要素包括你们做了什么事你一步一步大概是怎么想的吗对有几个问题

第一个要对比的就是人为操作的时间跟机器操作时间的对比如果一个 agent 做出来以后人为自己去做某件事情比机器做某件事情时间还短不管你是有人 involve 没有人 involve 这 agent 一定都不会成功

因为人的一个惯性思维就是我如果要做这件事情他就会在旁边盯着他不会说我要做这件事情然后我就走开了然后等 30 分钟回来以后发现这东西还是没完成然后他改来改来又走开了然后又还没完成大多数人正是因为你们在下载文件的时候你们都会在旁边去盯着他就是因为人大概率都会想说这个东西是不是会 fail 对吧每 10 分钟就会去 check 一下这东西是不是有问题

对吧这是一个人的常态的一个思维惯式所以从这个角度来说如果说一个 agent 的执行速度比人做还慢那这个 agent 就基本上不太可能成因为人不太可能脱离那个什么都想管一下的思维惯式这是第一点这个假设好像有些强啊就是比如说虽然可能大家都会盯着一个任务过程看但是你可以一边看一边刷手机和一边你得全人贯注的看似乎还是有一些区别你不觉得吗

是你是可以这么说但如果有这样的场景的例子的话就那么简单的场景都需要比人的速度都要慢那我觉得这个 agent 本身的实现就很有问题我们希望可能能够达到的效果就是说你完成一个任务就是个二三十秒甚至一分钟的事情不可能说你要等半个小时然后回来以后他发现还是 fail 的一个状态

这是我们当时的第一个 assumption 就是说你不管完成什么任务肯定要比人的速度要快然后第二点呢就是整个任务本身它的串联是

基本上 minimize 所有 human input 就不能说 OK 我完成了第一个任务然后拿到那些信息还需要人去复制粘贴放到第二个任务里面去然后再去做第二个任务的执行这个是一定要避免的如果说他只是帮你完成单一任务然后你还要去拿那个结果然后再复制粘贴到下一个任务当中然后再让下一个任务的 agent 去完成下一步的任务那你还不如就让人去做因为很多时候整个 contact switch 的过程比人的 cost 还要高

所以我们希望能够把整个工作流上面的所有的任务全部都写接好你不再需要说从第一步到第二步当中还需要有人去 involve 了这是第二个点然后第三个就是不能只有读必须要有写大部分的

大多数现在 agent 都只有读就是说我可以从互联网上抓取更重要的信息然后帮你做 deep research 能够做一些分析但是你能不能去写入互联网或者写入你自己的个人账户或者你的工作账户或者你的公司账户这个是目前缺乏的一个能力这是我们想要做到的一件事情最后就是 efficiency 它的算力不能够太高

如果说算力太高的情况下举个例子如果说一个任务平均的 cost 是两到三美金比如说你就简简单单写一个网页的 summary 或者帮你去建立一个单一的网页是两到三美金的话

那你其实可以想象说你一个月如果说去采取比如说 100 次任务那就是可能三到五六百美金那比如说一家公司他可能一共比如说三个人共用这么一个 inter 可能一个 inter 的价格也就是这个价格

也就是说它的价格所有工具所执行的总的数量和人的 cost 几乎可以相当的情况下那这个也很难去 scale 所以我们就是希望说它跟人就是廉价劳动力本身的整个价格差距至少要比如十分之一甚至百分之一的状态这个才能够真正的让 AI 的使用频率会大幅增加因为如果说它的价格很高的情况下你去用一两次如果有一次 fail 了

你可能就觉得我还不如去雇个人去干这件事情所以从我们的角度来说它的成功率高的同时价格必须要压得很低才能够使得这个东西真正的去普及就是刚刚也提到了一个是 RL 它速度很快另外一个就是好像之前你也提到说 RL 在一个 CPU 上跑为什么它的成本会比 LMD 这么多呢

不管是时间成本还是算力成本因为我们不是 LM 就是我们要把模型跟算法拆开来看就是算法是 RL 但是 LM 也可以用 RL 来训练但是我们只是用了一个别的模型但不是 LM 的模型用 RL 来训练就是你们是用 RL 训练了一个不是 Transformer 架构的语言模型的一个别的架构的就可以这么说吧就一种别的模型反正

具体是什么架构我就不能说了但是它有个别的架构的模型在里面就是这个模型本身要便宜很多跟 RL 本身没什么太大关系它会宽很多也会小一些然后刚刚就还提到其实就是一个很理想的创建下来就是模型能使用的工具会不断增加而且有一群生态内的 developer 会不断提供工具库

工具增加之后模型需要重新去训练吗因为在 LM 的场景下其实你给工具加一个描述就可以了我们也是一个完全泛化的模型因为我们训练的时候有见过 15000 个工具但这 15000 个工具并不是每一个都可以我们可以直接使用这些工具都是从互联网上抓下来的一些工具还有我们自己构建的一些工具所以这些工具本身就给了我们一种很强的泛化能力

所以从这个角度来说 agent 本身可能不会需要在因为加了工具以后去重新训练但是如果出现了很多非常 niche 的锤类工具的介入的话我认为可能会需要做一些 funtune 原因在于即便你把这些锤类工具给到 L1 估计 L1 也 handle 不了

那 LM 如果要重新训练一次那成本就比我们高多了所以我们应该就是在通用工具上面是不需要重新训练的但是如果未来有一些非常小众的一些锤类的工具进来了我们会考虑重新训练这个模型

就你刚刚说那四点就是你想到用这是几个构建 agent 的要素是你创业一开始就想得比较清楚吗还是有一个逐渐清晰的过程包括你们的团队是怎么来组建的就可以讲讲大家第一个 poke 的过程吗这个产品其实一开始的时候并没有那么清晰说这四个点必须都要完成只有一个点是很清晰的就是要跨平台就是说我们一定是大量的不同的工具串在一块来完成一个人类任务因为

人平时就是这么去干活的所以我们认为说如果一个 agent 真的能替人去干活那他一定是跨平台多工具去完成一个非常复杂的任务这是我们一开始的构想就有的那价格是我们当时也确实就是在融资的时候也 emphasize 的一个点就是说我们这个模型架构所带来的价格优势是非常大的但我从来不会真的去因为这个去打广告因为价格这东西真的不是一个非常长期的

不能说不是长期优势吧就是说 Eventually 总会有人想办法把就是 computational cost 给压下来的所以你价格很低并不代表说你有永久无限的价格优势或者资源优势所以我一般不会去 appetize 这个但是多工具多平台无限 scale 和 easy to use 这个是我们一直都觉得这是核心要素

剩下两个点是我们目前后面在慢慢摸索当中总结出来的就是说从某种意义上来说要比人快而且你的 skill 非常好这些事情都是我们在后面在摸索就是整个产品慢慢的构建过程当中总结出来的事情因为我们一开始也用 operator 跟 computer use

去做很多的比如说他自己是体验然后其实有 6%到 70%的这种任务就是我们自己内部在使用的时候在测试的时候我们都不等他做完就没有耐心去等他做下去了就是觉得说这个东西就那么简单一件事我还等你可能两三个小时去跑一个这个东西真的是没有什么太大必要

所以我们一般情况下总结下来就是人没有那么长的耐心等你去完成那么复杂的任务然后花那么多时间就很多这种东西都是在我们自己试用和自己的这个摸索过程当中总结出来的整个团队的构建其实跟这些摸索没有太大的关系

主要还是一开始的时候我在构建整家公司的时候还是一个端到端的这么一个架构就是从 Foundamental Research 到 Production Engineering 到产品的 Experienced Engineering 这个都需要有最专业的人来做所以我们的团队有一个 Research Scientist 是我之前 Meta 的一个下属然后是做 Reinforcement Research 的也是 Rich Sutton 的学生

然后 ML Engine 是之前我做 B2B Recommender System 的一个下属也是做 Production 非常好的

然后还有个 product engineering 的一个 partner 这个是我很多年的一个朋友了然后也是之前 Meta 的同事他是做 product engineering 有非常有经验的一个人所以我们就是端到端每一个关键点上都有一个很有经验的人来带这个事情当然我们现在团队一共全职员工就四个人然后很多活都是靠 AI 来帮忙的然后我们自己也写了一些 AI tools 内部很多的 scaling 什么的都是靠我们自己写的一些 AI tool 来完成的

然后有一些 contractor 的 help 就是亚洲这边会有一些 contractor 在帮我忙忙做一些相对比较杂的事情

回到就是这个产品形态我知道就是在你们现在这个产品形态之前因为我跟一些早期跟你见过的投资人聊过你们早期还有一个方向是做旅游路线规划是吗但我不知道这是你的一个方向还是个 demo 就是个 demo 就是我当时花了可能一两个礼拜的时间然后就告诉他们说如果你用我们这个架构去做一个规划能力和工具调取能力的这么一个 agent

它能够有多 powerful 就是我们当时用了一个可能就几百万个 parameter 的一个模型就做了一个可以很跨很多个城市 Google Maps 调用的一个功能就是一个锤类的 agent 的功能然后 Google Maps 下面所有的工具 SDK 的集成什么的都可以全部集成进来当时就想 showcase 一下说如果你想做一个工具调用的 agent 我们的这个方案可能是非常 scalable 和非常快速的你也不需要等

就是去扒网页或者怎么样对那这个 showcase 里面它还是不涉及到多平台的对不对它主要就是在 Google Maps 对当时还不涉及多平台当时其实都是在 Google 内部了就是 Google Maps 加 Docs 加 Calendar 这种这个其实也算多平台了

但就可能从当时的角度来说已经算是相对就是工具调用上面已经是非常强的一个 agent 了但是当时可能从投资人这边来说没有一个共识说工具调用是未来的一个 future 所以接下来做了一个帮 shopify 商家做推荐做客服这个产品当时是怎么想的

核心还是一样的就是当时通用 agent 并没有一个共识大家不觉得说这个东西能卖钱或者怎么样所以所有人都说要不你们先找一个落地点那我们当时就说那我们这个 agent 能力很强我们就直接把 shopify 底下的所有工具不管是他们的 command line 还是他们的 graph2l 还是他们的 API 还是 SDK 全部集成进来

然后变成一个面向商家和面向客户全功能的一个 agent 我们花了两个月就做完了等于是说你平时要把这些逻辑全捏在一块你可能花一两年时间才能把这些逻辑全捏完我们就花了两个月就把整个背后所有的逻辑全都捏完了就是完全都靠我们现有的技术能力就可以完成所以这个就是一个类似于像技术测试一样的东西就是说

是不是真的能够通过这种方式使得整个开发速度和 robustness 都有很大幅度提升的一件事情当时我们就通过这个项目我们也觉得说这个东西确实是有很大前景然后与此同时呢我们当时还想说 OK 我们是不是要 expand 这个东西然后去卖或者怎么样

然后二辆就突然火了然后火了以后呢就所有人都来找我们了就说那你一开始那个 vision 怎么样然后我就说那我们就回到原来的原始 vision 就从零就把横向那个平台给打通把这个技术给做出来所以这是为什么从 12 月份的时候开始我们就开始回到原始 vision 说 OK 我们就把这个最核心的这个技术把它给铺开做好

所以差不多是从 2014 年 10 月到 2014 年底你们是在做就是跟这个电商场景有关的跟垂直一些的一个应用而且有考虑过去落地但后面因为市场环境的变化你就可以回到你觉得你本来最开始更想做的这个事情你的核心问题是要卖嘛就是你要去卖那如果没有人去意识到通用 agent 的核心能力和工具相关和规划相关和 RL 相关的话那很难拿到赏共识那 DeepSeek 跟 Athorabic

两家的过去的这些 effort 使得这件事情形成共识了

那就非常有利于我们就是我们没有做任何 market effort 的情况下流量就自然的有很多偏向于了我们就是因为有很多别的公司来帮我们做了这个 education 的过程所以我们就认为这个时机到了可以回到我们的原始别增这个流量是说投资人的流量吗还是应该是是吧投资人然后客户还有很多 developer 的关注全都可能就是 12 月份 1 月份 2 月份

几乎就是以一个几何几乎的增加就是一开始就是非常频利的状态就是我们自己在开发没人管我们然后突然今天 12 月份就是所有人都来找我们就是说几乎有上百个投资人来找过我们然后客户的话有几十个客户就大型客户来找过我们然后小的 developer 就不计其数了就我们上那个 demo 当天一个礼拜内有 800 多个 waitlist sign up

后来三月份上线以后有 800 多个人 sign up 而且我们没有做任何就连朋友都没让他们帮我们分享当时我们就觉得说 OK 这个确实是这个流量比我们想象中的大很多因为一般来说 PlanLounge 当天你会让很多很多朋友帮你分享然后把那个流量给顶上去嘛

然后我们发现转化率特别特别高就是当时可能 view 量可能也就才一万左右然后有差不多 8%到 9%的 conversion rate 这个就有点非常离谱了就是说你一个网上的某一个帖子的到 waylist 的转化率有将近 8%到 9%

这个就是比我们任何一个之前甚至在 Meta 建筑的产品的转化率都要高的一个状态那如果总结一下你就是从去年 10 月到现在没有半年的这个创业历程里面没有四个多月吧你觉得几个比较重要的里程碑或者说几个比较高兴或者比较 down 的点都是些什么呀当时发生了什么事儿

首先第一件事情就是我们开始融资的时候没有人理解说二楼加 agent 是个什么东西其实今年我没有跟就我这次 gtt 这段时间因为很多人请我去一些 van 然后做些 panel 嘛然后其实有聊很多投资人投资人就说 you are like six months ahead of the curveso no one's gonna invest in you because it's like too early 然后

当时就是一个非常 down 的过程就是说我们从一个 brand vision 我们认为一定会成功的 vision 把它缩小到一个要落地的一个事情我现在回过头来也不觉得这是个错误的决定因为如果说没有人帮你做 education 这个市场就不认为说工具调用加 RL 加 agent 全部放一块推理规划工具调用这件事情是一个核心 agent 所具备的能力的话

它只是生成的话那你即便想做这件事情也会足力重重就所有人都不认为你做的是对的事情第二个节点就是 12 月份的时候当时 DeepSeek 出来 RL 突然间变火以后呢我们当时就突然间得到了很多投资人家客户的一个关注他们说你们是不是有做通用 agent 这个能力的然后

然后我们说确实这是我们 initial plan 然后就有很多的 brainstorm 然后有好几个我比较熟悉的投资人其实有告诉我说他们觉得这个时机可能开始慢慢变成熟你可以回到你的 grand vision 跟 platformization 上面去

所以当时听到了好多次这种 feedback 当时那个产品也做完了所以我们就觉得说 OK 是时候把那个产品就放在那边该卖就卖然后我们这边就回到一个通用化的一个状态然后这是第二个点这个时候我们整个团队的心路历程就是说 OK 我们本来就是非常脚踏实地在做一个产品然后现在突然间可能说是有一个 J curve 或者说有一个势能 Curve 的可能

对有个试能出现了就是我们发现这个机会然后我们到了那个点以后我们就开始说我们怎么去架构整个 agent 的整个 backend 和 infrastructure

然后一直到了三月份的时候我们把一开始这个 demo 做出来了然后这个 demo release 以后呢我们发现说这个兴趣量真的很高这个事情非常巧合因为我们的 releaseMannus 的 release 前两天我们 release 的我们的那个视频 3 月 4 号对我们 3 月 3 号的早上 release 然后国内 3 月 4 号看到的这个事情

然后两天以后 Malice 就 release 了 Malice release 以后我们一开始还觉得说会不会已经有一家竞品已经在做这件事情了然后看完以后发现不是他们还是在做一个偏深人士的一个功能性的东西然后速度还是以 browser 为主所以速度还比较慢所以我觉得说这个东西完全可以互补的一个状态就是我们这个领域还目前没有太多人去碰所以是一个相对比较蓝海的状态 Malice 的爆火出乎你的意料吗不出乎我意料

首先他们的市场做得很好这个是值得我们学习的就是说如何使得一个非常 technical 的产品看起来甚至对于对他们偏 consumer 对于 consumer 来说非常 boring 的一个产品让大家觉得非常 exciting 这个是就像艺术一样的一个事情就是你需要有经验的 marketer 去帮你做这件事情他们 marketing 做得非常好所以这个是必须要给 kudos 的

他们的整个产品设计和就 engineering 的整个套用都是做得很好的因为他几乎把里面非常复杂的多步的就是从这个 Python 写作到下一个 browser 使用这些东西的工具的嵌套都嵌套的几乎没有什么缝隙就不会出现说第一个工具弄完了第二个工具完全卡在那就完全做不下去了这种情况是不会出现的虽然他还是很慢但是至少他是一个相对

streamline 的一个过程吧所以我认为说因为第一次有这么一个完全 2C 的产品出现

是会给市场一个震撼同时 marketing 要做得很好所以它的爆火是有它自己的原因在那我们可能不会做那么粗的事情因为我们还是偏 to developer 为主但是我们应该也会尝试说找一些人分享之类的去想办法让大家更多的知道我们这个产品的存在我们产品的用户的可能是 learning 的 curve 还是要比他们的要稍微的 deep 一些

因为从某种意义上来说用户需要知道一定程度他们的工作流是什么而他们就告诉他说我要建一个网站可能就一句话就搞定了我们这个可能还是需要说我要做这么一件事情这个事情要完成这几个东西的 delivery 这几个东西是在什么平台上面的 delivery 这个事情可能是需要用户告诉我们的但用户也是用自然语言告诉你就可以了

只不过他要说的更清楚不是要说的更清楚一些因为我们要真的去写入你的互联网账户或者写入你的工作账户如果你都不告诉你的工作账户在哪那我也没地方可以去帮你写那这就是跟 consumer 最大的区别在哪因为如果我真正的去帮你去某一个账户里面去执行的时候我真的需要知道这个账户在哪或者这个平台在哪你也不能就告诉我说建立个网站就好了因为建立个网站我们也可以做但是真的有价值的还是帮你把工作给完成

因为你刚刚讲到就是 3 月 3 号你们开始发这个 demo 你们下一个节点或者说接下来的一个重要节点是什么应该会是我们的 beta launch 你们到时候是会给邀请瓦的那种形式还是大家直接可以用大家应该直接可以用但是会限制流量因为一开始我们不知道有多火万一直接把就是我们这边 competition 可能还好但是因为我们有很多很多的 rate limit 我们自己设置了很多的 rate limit 我们不希望说直接把某些网站给冲垮

比如说去某个网页上抓信息然后很多人都说我要去这网页上抓信息然后那个网页就说这 PokeEye 是什么 DDoS 或者怎么样把我们给疯了就不行所以我们还是要稍微小心一点所以当天我们应该有用户会看到说有一些的工具可能用不了

说今天的 rate 已经到上限了我们不能再继续开放明天可以继续邀请码的出现唯一的原因就是因为有 computation limit 我们完全可以 computational scalable 所以我们不会有这个问题

Pokeye 等此人物成本大概在多少呢就是目前市面上所有的产品的可能几十分之一因为你刚才说其实有一个比较重要的节点就是你们在 24 年 12 月 RL 又火了之后市场有了更多共识之后你们回到你们最初的那个愿景就是变得更通用就是想去做更通用的 agent 另一方面就是你会不会担心做更通用的东西

它的竞争压力也更大比如说 GBT-4O 释放了纹生图功能之后也是有很多人在讨论当大模型本身的基础能力提升之后跟这个能力重合的那些方向上的一些 agent 比如说生图其实也是有些 agent 它可能融合一些工作流让你的效果可以提升然后这些产品可能就会受到一些冲击

然后另一方面我觉得就是更通用的 agent 肯定也是各大模型公司包括像 OpenAI 这种创业公司里的巨头包括像 Meta Google 还有像字节阿里这种中美的大科技公司都会做的方向

就你们的特别是在什么地方我们肯定是以商业模式上未来就是就形成我们护城河的一个主要方面因为如果你纯靠技术我其实觉得纯生成式的模型就有这个问题就是你没有任何的 integration 没有挂靠没有粘度所有的东西都是靠你生成东西的质量那生成东西的质量纯粹的 backend 就只有一件东西就是你的技术

除了技术以外没有任何的额外的护身盒没有用户的年度没有用户对你这边的绑定对吧我们要形成的是一个工作流绑定式的东西比如说从此以后你有大量的文件过往的视频

比如说你是一个社媒的博主你有大量的视频文件还有你的图片什么都已经存在 Poke 上面了你只要告诉我可以从我过往文件当中挑出三张我过去的年度的 summary 然后帮我发到 Instagram 和 TikTok 上面就可以完成你的任务的情况下

就没有办法直接就跳到别的平台上面去了就我们需要有个工作流上面的深绑定这是我们要做到的一件事情我不知道我理解对不对他可能就逻辑是我为用户也不能说创造就是让用户有一个迁移成本在那如果是这样的话是不是因为它其实是个速度游戏呢就是如果同时 ABCDE 五个产品都能提供同样的服务用户只能选一个和他绑定的话其实做得最快那个人可能最后越容易活下来

不一定这还真不一定因为这就跟早年互联网游戏一样就是 Facebook 不是第一家但它活下来了

myspace 当年其实有很多人跟他深绑定但是仍然 Facebook 最后火下来了还是跟市场迁移的过程有关就是当市场在不停的 shift 的情况下你是不是能够更快速的去进行你的策略的转变然后能不能抓到一些用户群体和这些用户群体所相关的不管是你自己做 service 也好还是跟 vertical 公司做合作做 service 也好和这些用户进行更深度的绑定

把一些市场先占下来把这个用户年度拉起来然后才能够去扩张就是说这个东西到最后还是个商业的东西不是一个纯技术上面的东西技术上面我觉得 eventually 肯定有人能够做跟我们类似的东西但是我们希望说我们有个先发优势然后同时又有更强的集成用户年度和绑定在里面可以给我们带来更长时间的一个护身盒注意

你觉得这个中美商业环境会有差异吗比如说你在中国如果你做写操作甚至就是你刚才举的例子有一些是跟线下的服务有关的我让他去帮我点个外卖什么的那如果在中国的话可能美团他就不想跟一个创业公司去做这种合作是不是有可能他觉得我可以自己做一个这样的事当然其实国内的几家大厂商都有来找过我

就是说要有没有什么业务合作的可能性我觉得我们还是 focus on 能够把这个集成或者说能够把一体化的这个通用 Azure 的最快速能够接出来的这些工具先全都接进来

然后把不管是各种形态的工具全都接进来以后我们再去考虑说我们作为一个平台给到比如说各个大公司去提供服务的方式去做这些事情因为你要打通国内的市场实在太难了我其实当年融资的时候有回国待过一小段时间来教教你的感受总

总结下来就是国内的生态大多数情况下是相对比较封闭的一个生态模型的生态是非常开放的但是商业的生态是相对比较封闭的和欧美的生态环境很不一样美国可能是最开放就北美是最开放的然后欧洲是居中的欧洲其实有很多大公司也没有那么开放比如说 booking.com 他们的整个生态也是有自己的护身盒在里面他们也没有完全的开放这件事情

所以这个事情在北美肯定会第一个先做出来不管是我们还是别的哪家公司一定是整个通用 agent 的能力的爆发我猜大概率会在北美

因为商业的整个环境更开放国内的话就看各大巨头愿不愿意帮忙了就是互相之间愿意协作了因为从某种意义上来说比如说我们就已经把 Google 跟 Meta 的整个 Ecosystem 全接完了那就相当于在国内你需要把百度跟腾讯的所有的 Ecosystem 全接在一块我其实在这个地方去打巨大问号这两家公司愿不愿意合作在一块去完成这样一件事情对吧

请你解释一下就是所谓的开放具体是什么比如说是什么在国内做不了但国外是可以做的呢比如说你要去 Facebook 上面去写一个 post 那你要去微信上面去发个朋友圈你肯定不能代替别人去发朋友圈就不算微信发朋友圈你就说微信的企业端的账号你要去帮人家发一个什么视频号目前也没有解释过让你做这件事情但是在美国是可以做这件事情它有各种各样的东西可以让你做到这件事情

它有第三方的基层它有可以下载 SDK 它有 REST API 甚至有第三方的工具可以帮你去做这件事情所以各种各样的生态来帮你完成这种事情但国内这个生态就完全是封死了的

就是只有腾讯自己可以做这件事情然后他可能有一些自己的 trusted partner 可以帮助他去做一些工具但这些工具本身都是一家的就是只给腾讯单家做的所以他不会说我同时可以接入腾讯又可以同时接入比如说阿里之类的这个很少见非常少见

对所以你刚才设想的这个就是我在商业模式上建立的壁垒你可能还是要先在北美市场跑通对北美市场可能是我们的最重要的一个 first milestone 然后后面当我们的 SEK 跟 API 的

整个能力出来了以后我们会找各大公司看看有没有协作的可能性吧你刚才说了很多次就是现在大家觉得 agent 然后强化学习然后 agent 要去调用工具等等是一个共识我想知道就是在实际的落地和实践上就像你们这样以 RL 为核心用这种通用的方法来做 agent 的团队到底有多少啊

目前不是很多就是大家还是以快速落地为核心的以套件为主的比较多比如说去套一个 cloud 然后自己写一些工具然后直接套进去用一下或者是直接套 gpt4 然后用有线的工具去套一下这个比较多就很多与过春笋一般的公司都在尝试做这件事情

但是真的要做一个完全通用的无限 scale 的框架目前市面上我还没有看到第二家公司在做这件事情有很多的小公司 startup 他们在尝试用 cloud 或者用 gpt4o 去套 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 里面 trade agent 和 tone agent 他们是相互取代的吗还是说其实它可以共存我并不觉得它会相互取代比如说像我们的核心场景的目的是我们讲 power vertical AI agent 公司就是世界上有很多工具和很多的任务

它里面所需要做到的事情其实是通用的比如说你要写文件写 slides 或者说你要去建个网页或者说你要去抓取一些比如说社媒的信息热点什么的这些东西都是通用的但是只是你落在某一个落地的垂直领域上面它有些特殊的工具要做

我举个例子比如说你把社媒跟电商全绑一块那电商他可能要做一些 shopify 的事情那 shopify 里面有各种各样莫名其妙的工具在里面但是跟社媒相关的那一大块东西并不区别于说你就是一个博主所以不管你是个博主还是你一个去卖电商 retail 的 business 他们俩所需要用的社媒工具都是一样的

所以我们已经把你这边最痛苦集成的那些东西都解决掉了你就告诉我你在 shopify 上面要干点啥或者说你自己的这个博主平台或者说你自己有个博主网站这个网站上要干点啥你把它集成起来我就可以把你整个工作流做完了那我们其实可以 power 很多很多 vertical AI 公司说你不再需要去集成那 1000 个工具了你只需要告诉我说你们这个 vertical 里面最重要的那 10 个工具是什么

你就可以直接调用 1010 个工具来完成你的任务你们这个产品最初肯定是应该在云端在电脑端用的对吧那比如说未来它有可能是需要拓展到更多终端吗就比如手机移动什么的我们手机端应该也会做一下但是感觉手机端做只是为了让更多人可以体验到这个功能我们核心的突破点还是会在

developer 端就是以比如工具调用的数量工具调用的成果来完成我们的收费的你觉得像通用 agent 框架这一层就这个市场它可以容纳多少公司因为现在做方向的创业公司肯定是不少的对做的公司肯定不少少说至少我觉得未来一年之内你能看到不小于十家公司的

那我觉得最后一定会存留可能四五家三四家公司因为它就跟很多像 LM 的这个领域一样就是你可能会有大量大量的不同的公司非常同质化的涌现出来在涌现出来之后呢他们就会开始进行怎么说怎么去 differentiate themselves 就是

就是说这些公司本身可能会去更注重某些 Vertical 或更注重某些能力然后使得他自己的能力区分于别的公司比如说 Cloud 跟 OpenAIChaiGPT 一开始出来的这个产品几乎是一模一样的然后

然后 Cloud 就更偏向于 coding 了 GPT 更偏向于 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 和 open malice 是不是也算是开源的 agent 的框架

它不算一个框架吧就是它并不是一个调用工具非常复杂的一个框架吧因为我跟那个 OpenMiles 的团队聊过其实他们本来那个项目的名字是叫 Agent Hub 的他们之前没有上线就是他们在开发但是没有放到社区里就其实也是几个个人开发者的工作就也不完全是公司的工作

但是因为当时 Mallus 就是刚好在那个时间点嘛然后他们也用他们以前已经开发了一段时间的这个 agent hub 很快地做了这个 open mallus 所以后来这个名字就改成 open mallus 了就他们还是想做的是一个框架就是他有这种调用工具的潜质就是可以让别的开发者在这个基础上再做你想做的 agent

明白这个我倒还没有跟他们了解过因为我确实没有跟他们去交流过但具体看他们想做的未来的框架的愿景是什么因为我也不是很确定他们最后的 vision 是一个什么样的 vision 他是一个偏 deep research 的 agent 还是说他是一个生成式的 agent 还是说我要去真的去 platform 去写入的那种 agent 都不太一样像最后那种 agent 它的整个 integration 难度最高的前面那种就是开源比较好做后面那个是最难做开源的一件事情

所以我对于最后那种 version 的开源可能我认为难度会大一点这个 life cycle 会长一点但是一定会有某种形式的开源出现最后想问问 Bill 如何判断一项技术的潜力因为之前你也提到自己一直坚信 RL 能做很多事情之后 DeepSick RE 出来之后也验证了你的判断就想问你的信念是怎么来的

我其实跟 Rush Sutton 很多时候聊还有跟我自己的老板聊就我自己 PH Advisor 聊有一个很好的思维模式就是 tool examples 就是说比如说你看好一个技术方向你能不能构建一个 tool example 用极少的计算能量就可以证明说这个问题是别的技术方向做不了的

然后你的技术方向可以做的然后这个 tool example 必须是 intuitive enough 就是说这个东西是大家认为是一个 meaningful 的 example 比如说你举一些 common sense 的 example 比如说推荐系统里面的 example 或者说你举一个现在的话你可以举一个小的 language model 的 example

然后在这个 example 里面你能明确看到别的技术方向做不了而你呢可以做到的那这个方向就已经有一个从某种意义上来说第一性原理上面的一个优势在里面就是说我能够判断在我所要解决的这个问题上面只有我的技术目前有这个领先地位而且他有 principly right solution for it 那我觉得就是值得可以追下去的

而如果你做了一个拖例 example 说一个简单 language model 的 example 或者推荐系统的 example 或者说 data system 的 example 然后发现说你的技术跟别人没什么太大区别这个时候你再有这个执念去追逐你自己的技术就没有什么太大意义就是如果别人已经有 scalable 的 solution 就应该就跟随别人的 solution 就可以了那如果按照这个思路会错过大圆模型吗比如说其实大圆模型就是在它的规模没有到一定程度的时候

它的效果是没有那么明显但是没有任何一个别的解决方案可以 even get close towhat they're doingOK 就说虽然那个时候的效果没有到可能给工业界或者说给用户一个经验的程度但是它是领先于其他的方法的就是在实验的结果上来看对因为我在 GPD-2 的时候就接触了语言模型因为当时有一个教授拉我去做蓝宫什么的事情

我当时是觉得这个东西方向是非常有意义的但是我当时就觉得说我要从零开始 catch up 这个 topic 确实是有点晚了就 GBTQ 的时候我已经基本上确定他一定会活了就等于是一个这个船上面已经盛满了人然后这些人已经知道自己要去哪了然后你一个半当中旁边一艘小船上面的人我这个小船驶向一个不一样的地方我非要跳到他的船上去去跟他凑这个热闹我觉得可能意义不是很大而且很有可能被人家淹没

所以我当时的决定就是说 OK 那东西是 interesting 我应该 catch up 我要 learn from it 就是这个技术和这个技能是我要的但是我真的要成为这个领域的可能是第一个落地者或者前第一批的落地者可能已经不太可能了

所以我就觉得说还是要专注自己最了解的方向明白你刚刚说的那个做一个最小的这个脱位 example 的这个思路其实还是一个科学验证的思路对不对就是做实验对就是你要先找到一个可以自洽就自圆其说的一个小的案例这个案例本身得是 general enough 然后在这个案例当中没有一个技术是目前可以解决你这个问题的

而你的技术本身又是 principle 解决这个问题你不能说我 hack 一个 solution 出来把这个问题解决了对吧你得说我的技术是普世于这种 example 的那你可能会有这个 confidence 说我的这个方向是正确的现在我知道的很多的 researcher 可能有一个问题就在于你如果发 paper 的 research 你可以说 hack 一遍 paper 出来也是可以的你可以找一个 corner case 别人解决不了你可以用你的技术解决得了但真的落地的话不存在这种 corner case

就你必须要找一个 minimal viable example 这个我一般来说叫做 minimal viable example 就是这个 example 里面它是一个不适性的 example 然后有你的技术可以解决掉它然后你也可以证明说这个技术是可以解决这一类 example 的然后别的技术解决不了它那你接下来就可以说 OK 我能不能把这个变成一个 large scale 的问题这

deploy 到现实系统里面有什么的 volumeck 有什么的 system integration 要做然后把这些东西打通了然后最后落地它也不是 100%会成的但是至少你第一步做成了以后你会有这个信心说至少这个技术方向有 80%的可行性的概率而不是我盲目的就去跑大型实验然后大型实验里面有各种各样的 complexity 它的 variable 太多没法控制变量导致我也不知道什么东西 work 什么东西不 work 你自己感觉到强化学习和大元模型结合会非常有潜力是在什么时候

那个时候我当时就觉得说 OK 如果可以在 token level 用 RL 去做那么复杂的 planning 那么长 horizon 的 planning 它都可以 work 的话我觉得说如果我们在更 abstract level 做 RL planning 它应该也会 work 因为它的整个复杂度可能并不比你每一个 step 都用 token 去做解析要难多少所以我当时觉得说可能这个方向是个大的趋势

所以当时我其实一直在推推荐系统的二楼落地然后当时也有很多的落地的成功案例当时核心原因就因为推荐系统里面其实你可以想象每一个文章或者每一个 article 或者每一个 recognition 就是抽象的一个 action 然后你要把它们 sequence 起来变成一个 planning 问题

去用 RL 去落地然后和我们现在 Azure 的落地其实有异曲同工之妙的一个东西所以从某种意义上来说我当时就觉得说这个东西一定是有 future 的就是用语言语言模型其实解构了很多原来用 RL 直接加现有推荐系统要解决的问题里面不可解的地方

因为语言是非常 flexible 的一个东西你可以把它结构成任何方式它的整个 sequential decision making 就变得更 natural 而不是说我做完一个 decision 以后当中有出现各种各样乱七八糟的事情然后我再做下一个 decision 然后再出现各种各样的事情然后再做下一个 decision 而是每个 decision 之间其实是非常连贯的当中出现的 noise 跟 partially observable 的东西就变少了

你自己什么时候特别明确的感觉到就是用强化学习来做 agent 肯定会是一个方向这肯定是在创业之前的某个时刻对吧就有这个感觉我觉得毕业的时候就在想这事但是我构思了很久我构思了快半年我才想到现在的这个解决方案就是我

当时十月份出来融资的时候才确定这个技术方向是这个样子的就之前我都没有确认这个技术方向当时都一直在摸索这个技术方向怎么样是最靠谱的因为当时有很多很多 nuance 在里面所以我当时也没有完全确定说我们现在的这个环境构造以及模型的建立和 self play 是不是真的能 work

我们只在我刚刚说的那个 tool example 上面就是在 travel 那个 tool example 上面跑通了但是真的要 scale 到无数个场景它是不是真的能够泛化这个东西是打巨大问号的但是后来验证下来是觉得它可以泛化的所以这件事情也是有一定冒险在里面的

就是我觉得有的人他创业的习惯是比如说在一些大公司的技术人员他会先跑一段时间就把想法验证得更清楚甚至他人可能都找好了甚至投资都找好了他才跳出来我感觉你是直接做了决定你就出来了当然我不知道北美是不是这样我可能说的是国内的情况我其实之前也有找自己认识的人聊聊

但也没有做的特别深跳出来会有就可以给到投资人觉得说你有 conviction 而且我当时也怎么说呢就是也没有必要一直待着就是你一直待着公司这个金手铐会永远靠在你手上因为 meta 也很忙嘛你如果真的在公司干着你也不可能说真的不管公司的事而且我手上的活当时很多都是 report 给整个 head of monetization 啊然后甚至于之前有 report 写给 cto 的那种所以这种活你也不能不干吧

这种活一定要干掉要花很多时间你也不能给这些大佬们留下坏的印象以后在这个圈子里面还得混呢对吧所以你要走的话就干脆一点就走了然后可能就给别人一个明确的 signal 而不是说一直拖着拖着反正对自己的 reputation 也不好对其实我觉得这是一个更好的状态只不过你自己就是承担更多的风险嘛 that's ok

好的好的那今天非常感谢比友做客晚点聊跟我们分享了他从本科时代就开始研究 AI 的规划然后到后面做强化学习一直在这个方向从冷门到热门见证了这个转变然后现在他开始创业从去年十月份的一个项目到现在不到半年做

我觉得这是一个非常新颖的方式或者说比较特别的方式来实现现在大家都很关注的 agent 领域的创新那今天非常感谢 Bill 好拜拜

本期节目就到这里感谢收听如果你对今天聊的话题有观察好奇或疑问欢迎在评论区分享想法这也会成为我们节目的一部分让整个讨论更加完整你也可以把我们的节目分享给对这个话题感兴趣的朋友们欢迎推荐更多你想听的主题和嘉宾你可以从小宇宙苹果 podcast 等渠道关注晚点聊也欢迎关注我们的公众号我们下期再见