# 111: Pokee.ai 朱哲清的 Agent 造法：强化学习作后端，语言模型作前端|Agent#3 晚点聊 LateTalk · 2025-04-22 本期嘉宾是 Pokee.ai 创始人朱哲清（Bill），他在《晚点聊》中提出一种与主流不同的 Agent 造法：大语言模型（LLM）只是 Agent 与人类交互的“前端”，后端决策与执行应由不依赖自然语言的强化学习（RL）模型完成。他批评以 LLM 为大脑的做法，称其上下文长度有限，调用工具超过 50 个就会产生幻觉，难以支撑复杂多步任务；而 Pokee.ai 用 RL 模型驱动，已打通几十个平台的上千个 API，单次任务成本约为同类产品的十分之一，执行一项任务只需数十秒。朱哲清还总结了优秀通用 Agent 的四要素：比人快、无需人工干预、能读能写、成本低，并认为技术本身不是护城河，真正的壁垒在于与用户工作流深度绑定。他分享了自己的创业历程：从斯坦福读博与 Meta 全职并行，到早期做旅行规划 demo、Shopify 垂直 Agent，直到 DeepSeek R1 带火强化学习后回归通用 Agent 方向；团队只有四人，却吸引了大量投资人和客户。关于行业竞争，他判断未来会存留三到五家公司，接下来各家将走向差异化；此外，他还给出了判断技术潜力的方法论——先构建一个极简的 ‘Toy Example’，证明只有你的技术能普适性地解决它，再投入规模化。 ## Questions this episode answers ### 为什么用强化学习做 Agent 的核心，而不是让大语言模型当“大脑”？ 朱哲清认为，LLM 当决策中枢时，调用工具要把工具描述、输入输出放进上下文，而上下文长度有限；工具用到 50 个左右就开始产生幻觉，多步任务更可能膨胀到上百万个 token。所以 Pokee.ai 用强化学习训练的非语言模型做后端决策和规划，LLM 只承担理解用户需求、返回结果的前端角色。 [19:26](https://latetalk.podhood.com/064088bd-6c58-45c5-b921-81ca18ee7248?t=1166000) ### 为什么 DeepSeek R1 带火了强化学习，而 O1 没有？ 朱哲清解释，O1 虽然声称 RL 驱动，但外界看不到它的 RL 逻辑，更像是推理时做链式思维加蒙特卡洛树搜索；DeepSeek R1 则展示了可以用接近 rule 的奖励来判断一次序列决策的好坏，不再需要大量人工标注 reward model，训练速度也快，因此让投资人和市场真正形成“强化学习重要”的共识。 [16:52](https://latetalk.podhood.com/064088bd-6c58-45c5-b921-81ca18ee7248?t=1012000) ### 一个好的通用 Agent 需要具备哪些要素？ 朱哲清总结四点：一，完成任务比人快，否则用户没耐心等；二，整个任务链条尽量无需人工干预，避免复制粘贴式的上下文切换；三，不仅要能读信息，还要能写入互联网、个人或工作账户；四，成本要低，与廉价劳动力的价格差至少到 1/10 甚至 1%，使用频率才可能大幅增加。 [50:00](https://latetalk.podhood.com/064088bd-6c58-45c5-b921-81ca18ee7248?t=3000000) ### 如何判断一项技术有没有潜力？ 朱哲清说，他从 Rich Sutton 和博士导师那里学到“Toy Example”思维：用极少计算量做一个直观、有意义的最小可行例子，证明某个问题其他技术做不了、而自己的技术能做。先在 toy example 上自洽跑通，再考虑规模化落地；如果和其他方案没差别，就不必执着。 [1:26:04](https://latetalk.podhood.com/064088bd-6c58-45c5-b921-81ca18ee7248?t=5164000) ## Key moments - **[0:00] 开场** - **[2:15] 十年RL** - [2:15] 朱哲清介绍自己在Meta的经历：前3年从零搭建B2B推荐系统，后3年多带领应用强化学习团队，开源框架Pro，每年带来约5亿美元收入 - [4:10] Q: 一边在Meta全职工作一边在斯坦福读博常见吗？朱哲清：基本不存在，他每周工作量约110小时，除了睡觉都在研究 - [5:48] 朱哲清：边工作边读博最大的收获是时间管理——多数事情花20%精力做到80分即可，关键事情才需要100分 - [6:49] 朱哲清接手险些被Meta关掉的强化学习应用组：团队从20多人裁到3人，他接手后重新扩充到十多人 - [7:46] 朱哲清曾被人拉去做早期语言模型和聊天机器人，试了一小段时间后停掉，坚持认为那不是RL落地的核心路径 - [9:36] 朱哲清：'如果你自己的思维框架认为某一个方向是正确的，你可能就得坚持下去了' - **[10:18] RL 翻身** - [10:27] 朱哲清回顾RL学界沉浮：deep RL到2016年AlphaGo/AlphaZero才火，他去斯坦福读博时已形成气候 - [12:21] 朱哲清博士研究强化学习样本效率：通过有效探索把数据需求从线性降到平方根级，同样结果只需原来1/10甚至1%的数据 - [16:52] 朱哲清：RL是DeepSeek R1带火的不是O1——O1更多是在推理端做思维链搜索，R1用规则奖励免去大量人工标注 - [18:48] 朱哲清：DeepSeek R1纯强化学习输出的内容经常是gibberish，需要再加一层RLHF让人类可读 - **[19:26] Agent 内核** - [19:42] 朱哲清：RL Agent把规划、推理和工具调用抽象为决策，不依赖自然语言输出；现有Manus/Deep Research本质仍是LLM核心 - [20:39] 朱哲清：Manus和Deep Research只能读取互联网，Pokee.ai能写入互联网——直接发布帖子、招聘信息和产品评论 - [21:39] 朱哲清：LLM调用50个以上工具就开始幻觉，十几步工具调用会累积上百万token，所以无法作为Agent决策核心 - [23:07] 朱哲清对比Operator和Manus：Operator执行能力更强但没有深度研究，Manus信息整合更强，二者互补 - [23:51] 朱哲清预测：长期来看互联网UI会消失，LLM只是Agent与人类的交互前端，后端工具交互由RL模型和协议完成 - [26:10] 朱哲清举例未来买菜流程：用户端RL模型理解意图后传给B端Agent，数据库和线下配送完成后只把结果转成文字给用户 - **[31:03] 产品设计** - [31:03] Pokee.ai与多数Agent不同的交互：执行前让用户确认规划和每一步输入，可手动修改，避免无法干预的失控感 - [33:15] 朱哲清：Pokee.ai的审批按钮收到两极反馈——商务用户强烈需要，开发者讨厌，因此产品同时支持两种模式 - [34:31] Q: Pokee.ai为什么不展示虚拟机执行画面？朱哲清：多数任务走官方API而非浏览器，涉及平台隐私；深度研究会显示每步状态 - [35:14] 朱哲清：Pokee.ai已打通几十个互联网大平台、1000多个API接口，能用代码和官方接口就避免用浏览器，这是与市面Agent的最大差异 - [36:44] 朱哲清：Pokee.ai核心用户是开发者和专业用户，定位是to B场景的to C+to B产品，未来会进入企业私有化部署 - [38:18] 朱哲清早期与社媒营销从业者沟通发现：最大痛点不是生成内容，而是跨平台分发和回复几十条评论；Pokee.ai可自动个性化回复 - **[39:09] 企业路径** - [39:15] 朱哲清：他试过让Operator安排会议、让Manus发Facebook帖，成功率约0%，所以纯消费者通用Agent容易被期待压垮 - [40:46] 朱哲清：Salesforce拖拽式Agent太僵化，工作流稍变就失败；需要更上层的规划器和无限工具调用能力 - [41:58] 朱哲清：改变大公司工作流很难，所以Pokee.ai先服务中小公司和专业用户，再自下而上影响大公司采用 - [43:40] 朱哲清：Pokee.ai子任务失败不会中断整体任务，RL会判断与上下文无关的动作并跳过，先尽可能完成能完成的 - [44:31] 朱哲清：Pokee.ai暂未开放自动debug，因为Agent可能擅自改写内容——比如把重复LinkedIn帖改成不重复再发，但不总是用户想要的 - **[45:33] 速度与协议** - [45:33] 朱哲清：Pokee.ai demo含审批约60秒，免审批十几二十秒完成，因为不用browser-use，大量操作靠与公司的官方集成 - [46:54] 朱哲清：Pokee.ai完全没用MCP，自建更简单的协议——JSON文件写input、output和endpoint即可调用，未来也会兼容MCP - [48:11] 朱哲清：Pokee.ai首轮发布约1000个子工具、几十个平台，会建开发者社群，让SaaS工具只需提供输入输出端点就能接入 - [49:06] 朱哲清：市面上多数Agent仍以LLM为核心；contrastive learning方案因上万工具中负样本噪声太高，效果不理想 - **[50:00] 四要素** - [50:00] 朱哲清：优秀通用Agent四要素是——比人完成任务快、无需人工干预串联、既能读也能写、成本足够低 - [52:11] 朱哲清：大多数Agent只会读不会写，Pokee.ai强调写的能力——直接写入互联网和工作账户，避免人复制粘贴做串联 - [53:27] 朱哲清：Agent单次任务若2-3美元，每月100次就是300-600美元，接近实习生工资；必须压到人的成本1/10甚至1%才能普及 - [54:25] 朱哲清：Pokee.ai成本低不是因为RL本身，而是用了RL训练的非LLM架构模型，更小更快 - [55:12] Q: 工具不断增加，Pokee.ai需要重新训练吗？朱哲清：已用1.5万个工具训练，通用工具无需重训，只有小众垂类才需微调 - [56:16] 朱哲清：创业初期唯一清晰的要素是跨平台多工具，价格优势不宣传，其他要素在产品和测试中逐步总结 - **[59:31] 早期试错** - [59:44] 朱哲清早期用几百万参数模型做了跨城市Google Maps行程规划demo，以此展示RL Agent的工具调用能力 - [1:01:02] 朱哲清团队花两个月把Shopify的API、SDK、GraphQL全部接入Agent，验证了其架构能把一两年的集成工作压缩到两个月 - [1:02:35] DeepSeek带火RL后，朱哲清决定暂停Shopify垂直产品，回到原始愿景做横向通用Agent - **[1:03:22] 市场反响** - [1:03:26] RL大火后朱哲清称上百投资人、几十个大客户主动找来；Pokee.ai demo发布一周800人waitlist，没推广转化率8%-9% - [1:04:57] 朱哲清复盘创业：去年10月融资时被说'you are like six months ahead of the curve'，没人投；12月RL火后形势逆转 - [1:07:34] 朱哲清：Manus爆火不意外，它营销和工程衔接做得好，但仍是浏览器和生成式路线、速度慢，与Pokee.ai互补 - [1:09:12] 朱哲清：Pokee.ai用户学习曲线比Manus深，因为需要说清工作流和账户；但它做的是真正写入账户完成任务 - [1:10:53] 朱哲清：Pokee.ai单次任务成本约为市面同类产品的几十分之一 - **[1:10:59] 护城河** - [1:11:12] 朱哲清：技术不是Agent护城河，工作流绑定才是——用户文件、素材和流程沉淀在平台后不会轻易迁移 - [1:13:07] 朱哲清：Agent不一定是速度游戏，就像Facebook不是第一家社交网络却活下来；关键是市场迁移中的策略和用户绑定 - [1:14:22] 朱哲清预测：北美商业生态最开放，通用Agent爆发大概率先发生在北美；国内百度腾讯生态封闭，合作是巨大问号 - [1:17:42] 朱哲清：目前没有第二家团队在做完全通用、无限扩展的RL Agent框架，多数是用GPT-4套工具的垂直小公司 - [1:19:11] 朱哲清：通用RL Agent难做是因为需要基础研究突破，接下来各大学院和巨头可能会投入这个方向 - [1:20:28] 朱哲清：垂直Agent和通用Agent共存，Pokee.ai想做通用底座，让垂直公司专注10个核心工具就能调用上千工具 - **[1:22:15] 终局** - [1:22:25] 朱哲清预测：通用Agent行业最终会存留三到五家公司，随后像Claude/ChatGPT一样按能力差异化分工 - [1:23:30] Q: 通用和差异化是否矛盾？朱哲清：就像Android和iOS并存；Agent架构复杂度高于纯语言模型，开源难度也更高 - [1:26:14] 朱哲清：判断技术潜力用Toy Example——用极少计算量构造别的技术做不了、你的技术能做的直觉案例，再考虑规模化 - [1:27:36] Q: 这个方法会错过LLM吗？朱哲清：不会，GPT-2时他确定LLM会火，因为当时没有别的方案能接近它的效果 - [1:30:28] 朱哲清：推荐系统中每个推荐是一个抽象action，用RL做序列规划成功后，他相信同样方法也能驱动Agent - [1:32:06] 朱哲清：创业方案构思近半年，融资时才确认技术方向，当时只在Toy Example跑通，泛化能力后来才验证 ## Speakers - **孙海宁** (host) - **曼祺** (host) - **朱哲清** (guest) ## Topics AI模型团队动态, 模型自进化 ## Mentioned Anthropic (company), DeepSeek (company), Meta (company), OpenAI (company), Pokee.ai (company), Salesforce (company), Shopify (company), Stanford (company), Facebook (product), Google Maps (product), Instagram (product), LinkedIn (product), MCP (product), Manus (product), browser-use (product) ## Transcript ### 开场 **孙海宁** [0:05] 欢迎收听本期 《 晚点聊 》。 我是 《 晚点 》 的作者孙海宁 ， 今天很开心能和曼祺一起录制本期节目 。 几乎所有主流 AI Agent 的产品 ， 都把大语言模型或者它的多模态升级版当作决策中枢 。在用户使用界面下， 是一个或几个大语言模型为句中心编排工作 、 调用工具 ，但也有不同的路 。 我们今天的嘉宾 ，Pokee.ai 的创始人朱哲清 ，Bill， 认为大语言模型只是 Agent 理解人类需求 、 向人类递交产出的前端 ； 后端决策 、 完成任务则可以靠用强化学习方法训练的 、 不依赖自然语言的模型完成 。Bill 提到 ， 把大语言模型当作 " 大脑 " 时，Agent 调用工具的能力有限 。 这是因为大语言模型使用工具时， 需要先把工具描述 、 输入输出等相关信息作为上下文输入模型 ，而大语言模型支持的上下文长度有限 。 把 Agent 决策中枢换成另一个由强化学习方法训练的模型 ， 可以解决这个问题 。 本期播客中，Bill 还提到优秀的通用 Agent 需要具备四个要素 ： 实现任务比人快 、 无需人工干预 、 能读取信息也能写入信息 、 成本低 。Agent 产品的壁垒不在技术 ，而在于和用户的工作流深度绑定 。此外， 我们还和 Bill 聊了他对通用 Agent 接下来竞争态势的判断 ，以及他在强化学习还没有 成为显学时便相信强化学习潜力的原因 。 我们的对话将从 Bill 一边读强化学习方向的博士 ， 一边在 Meta 工作的经历聊起 。 最后说一些声音上的注释 ：Bill 本科就开始在海外留学 ，不太熟悉常用部分专业名词的中文表达 ； 本期多次提到的 RL 是 Reinforcement Learning 的缩写 ， 即强化学习 ； 和强化学习相关的表述还有 ：policy 即策略 ， 指强化学习模型完成任务的方式 ；reward model 即奖励模型 ， 用于评价某个决策的好坏 ；ground truth 即真值 ， 指训练模型时使用的标准答案 ；exploration 即探索 ， 探索可能完成任务的新路径 ，是强 化学习模型的一类动作 ； 和 exploration 相对的概念是 exploitation， 即利用 ， 利用已知信息 ， 选择最优的动作 。此外， 对话中提到的 prosumer 即 professional consumer，是指专业用户 ；context length 是指大模型的上下文长度 。 这些注释也能在本期的 Shownotes 中看到 。 下面我们就正式开启本期节目吧 。 那先请哲清 、Bill 为听众简单介绍一下自己的经历可以吗 ？ ### 十年RL **朱哲清** [2:19] 我先讲讲我自己过去 7 年的事情吧 。 就是我 2014 年来了美国 ， 然后是在 Duke 这边完成的 CS 的本科 ， 然后后面就立刻加入了 Meta。在 Meta 的话 ， 前 3 年多的时间是在 TOB 的推荐系统的业务这边 。 我们当时是从零开始搭建了一整套 B2B 的推荐系统 ， 包括正常的商业增长和广告增长的推荐系统业务 。 当时也是刚开始有基于深度学习的推荐系统 ， 然后我们等于是带团队把一整套的推荐系统给做出来 。 后面的 3 年多转到了 AI 这边做 Applied Reinforcement Learning， 就是应用强化学习这个团队的负责人。 然后主要负责的业务就是把强化学习落地到整个 Meta 内部所有的产品线上面 ， 包括广告 、 推荐系统 、Reels 短视频 、Data Infra 这一系列的这些产品上面 。 然后与此同时， 我们也开源了 Meta 的一个核心的强化学习框架 ， 叫 Pro， 这也是我们落地所有产品的一个核心机制 。 当时就是发出来以后呢 ， 还是非常火的 ， 大家都觉得这个方向和 virtualization 做得特别好 。 然后与此同时， 我们也发了一些 paper。 所以我们其实后面 3 年在强化学习方面 ，在强化学习火之前 ，其实已经做出了很大的 impact。其实估算下来 ， 每年将近有 5 亿美金的年收入是由强化学习算法带来的 ，在广告上面的 impact 尤其突出 。 然后在推荐系统和短期视频这边 ，也有很大的业务的贡献 。 所以其实我们在强化学习由 DeepSeek 带火之前 ，其实就已经有很大的一个 impact，由强化学习带来的 。 然后在 Meta 工作的同时呢 ， 我也在 Stanford 把强化学习的 PhD 读了 ， 这个两个是并行的一个时间状态 。 **孙海宁** [4:03] 像你这样 ， 就是一边在 Meta 其实你是全职工作嘛 ， 然后一边读博士 ， 这种在同学同事之间常见吗 ？ **朱哲清** [4:10] 应该是不存在的 。 **孙海宁** [4:11] 那你当时是怎么达成这种安排 ？ 你怎么说服公司和你学校的老板 ， 就是导师 ， 都接受这样一个状态了 ？ **朱哲清** [4:17] 这个是比较机缘巧合的东西 ， 就是你可遇不可求的 。 我所知道 Berkeley 好像有一个学生是这样的 ， 然后 NYU 哎 ，其实那个 Perplexity 的那个 CTO，他也干了一件类似的事情 ，但是他在公司属于不算完全全职吧 ， 就是他的工作跟他的 PhD 是非常强相关的 ，因为他的导师是同一个 。 所以他基本上他做 research 就只 focus 上 PhD 的那个东西 。 所以还是有一些这样的 。 我有很多的 alignment 是我跟我在公司的老板 、 跟我自己的 PhD 导师 align 的 ， 就是说这个方向是不是大家都感兴趣 、 大家都想落地 、 公司也同意这个事情 ， 然后学校也觉得这个事可行 ， 然后才能做这件事情 。 但是工作量非常大 ， 一个礼拜大概 110 个小时的工作量 。 所以就是基本上除了睡觉以外， 就是在做 research 工作吧 。 **孙海宁** [5:08] 所以就是你这 5 年选了一个 hard 的模式 ， 对吧 ？ 一边上班一边读博 。 **朱哲清** [5:13] 对 ，6 年多 。 这段时间可能工作量就跟创业没什么太大区别 ， 甚至于比创业还艰辛一点 。 因为创业你至少还能 delegate 给别人， 对吧 ？ 那段时间你早期特别 PhD 的活 ， 你没有任何人可以 delegate， 你就自己干 。 然后公司我升那个 TL 和 manager 之前 ，也不能 delegate 给任何人， 也得自己做 。 所以有很多事情就只能自己苦干 ，也没有任何的巧劲可以使 。 创业嘛 ， 至少还有点巧劲可以使 ， 你花点钱雇个人是吧 ， 那也能把一些活给干了 。 **孙海宁** [5:44] 那你觉得这个过程 ，因为他是个比较特殊的经历嘛 ， 你觉得给你带来什么呀 ？ **朱哲清** [5:48] 我觉得一个很重要的点是时间管理 。 这个其实跟我们现在创业的 idea 很相关 。 就当年就 hope like wish I had this。 因为当年如果很多这种莫名其妙的事可以由 AI 帮我做了的话 ， 我其实觉得会省下很多很多的时间 。 时间管理的一个核心点就在于说 ， 你要知道你的 priority 是什么 。 比如说你什么时候应该摒弃一些东西 ， 什么东西是值得花时间做的 。 这个事情是非常重要的一个 career lesson。 就是说很多时候 ，有些事情你花 20% 的精力做到 80 分就可以了 ，而不用去 100% 的精力做到 100 分 。 而有些事情是非常非常关键的 ， 你就需要花 100% 的精力做到 100 分 。 然后有些事情你可能觉得可有可无的 ， 你甚至用 0% 的精力把它给抛弃掉 。 那怎么去取舍这件事情其实非常重要 。 如果每件事情都想要拿到的话 ， 我觉得我可能读不下来这个 PhD。 然后第二个事情可能就是说要找准方向 。其实我在 PhD 当中走了很多弯路 ， 就因为 RL 落地这件事情在当年不是一个很火的话题 ，而且很多人都不看好这个方向 。 甚至于我们当时的 director 有一阵子 ， 就我加入 Meta Apply RL 组之前 ， 我们的 director 是要把这个组给关掉的 。 就是我看到这个组要被关掉了 ， 然后原来带这个组的老板走了以后， 我去找那个 director 说你别关这个组 ， 我来带 。 这个组原来有 20 多号人， 减到最后只剩 3 个人， 然后我去带这个组以后再回到十几个人的这么一个 turn around。 所以当中其实有很多很多弯路 ，但是你要找准方向以后， 你得坚持下去 。 就是说你不停地换方向这件事情 ，是有很大的就是沉没成本的 。 **孙海宁** [7:20] 你是中间试过想换方向是吗 ？ **朱哲清** [7:22] 我倒没有试过换方向 。 我没有想过换方向 ， 就从来没有想过这件事情 。 就一定是 RL 落地为核心的这个目标 ， 就一直走了 10 年了快 。 **孙海宁** [7:32] 那你说的弯路是指什么了 ？ 你说 PhD 中间有很多弯路 。 **朱哲清** [7:35] 哦 ， 就是会有很多的诱惑 。 比如说我当时有人拉我去做 ， 比如说早期的 language model， 做 chatbot 那种 。 然后也有人去找我做 3D 的 vision model。 当时还有人找我做那种 safety 的 model。 那这些东西我当时到最后就做了一小段时间就停下来了 ，因为我觉得跟我的核心路径没什么太大关系 。 就你要知道这个东西什么时候要把它 cut off， 你不能说让它这个沉没成本无限地去增加 。 **孙海宁** [8:02] 嗯 ，因为回头看的话 ， 现在大语言模型其实是一个 ， 你可以叫它显学吧 ， 反正就是很多人做的一个方向 。 然后你也说当时有人找你去做早期的大语言模型 ， 还有 chatbot 这些事情 ， 你不觉得那是个好机会吗 ？ **朱哲清** [8:15] 人总不能这样回头去看这种事情的 。 比如说我当时做了 ， 然后我变成了第一个做出比如说 instructGPT 的人， 那我肯定觉得说那可能是比现在更牛的一个路径了 ， 对吧 ？ 但是你永远不能假设 。 但是我当时也不了解语言模型 ， 我当时最了解的还是 RL 这条路 。 那我就是把这条路做好 ， 做精 ， 真的能落地 ， 能在业界有 reputation， 真的有些 work 是大家所熟知的东西 。 这个我觉得是更重要的事情 。 **孙海宁** [8:43] 嗯 ， 我觉得学术研究有一点确实挺有意思 ， 就是你怎么选方向 ，因为每个方向都会经历沉浮 ， 就起起落落嘛 。 然后你怎么在这个过程中间一直往下走 。 比如说你之前跟就是那个图灵奖得主 、 强化学习之父 Rich Sutton， 你们也交流比较多嘛 ， 然后你也觉得就是他给你很多启发啊 。 **朱哲清** [9:02] 对 ，他早年其实是非常不顺利的 。他早年有将近 4 年时间是整个 research 无人问津的一个状态 。 你能想象现在图灵奖得主 ， 当年没有人理他的 research，有 4 年时间连没有一个教职愿意找他 ， 就类似于这种状态 。 当年没有人认为 RL 这个东西是 useful 的 ， 到今天所有人都觉得 RL 是个就是 must have。 那这个过程的转变其实是非常 inspiring 的 。其实当年 Hinton 有遇到过类似的情况 ， 当年他早期推 deep neural network 的时候 ，也是所有人都觉得说 this is bullshit， 没有人会觉得说这个东西有未来嘛 。 所以我觉得最大的 inspiration 就是说 ， 如果你自己的思维框架认为某一个方向是正确的 ， 你可能就得坚持下去 。 然后你可能有时候也会认为说很多人都可以跟你做一样的事情 ， 然后他们也能够做得很好 ， 你觉得你可能没有优势 ，但是别人可能就没有坚持下来做你这个方向 ， 你可能最后还是成功了 。 就是说很多时候可能还是得轴一点的 。 你如果自己有坚持很坚信的东西 ， 至少得把它走通了 ， 或者说你真的证明了说别人已经做出来 ， 你没有办法去 take over 了 ， 可能你才能去说 okay what's my next step。 而在半当中不停地去 question 自己 ， 可能只会给自己带来过多的 noise， 然后去阻碍自己的发展 。 **孙海宁** [10:18] 所以 Bill 你刚开始研究 RL 的时候 ，RL 已经是一门显学了吗 ？ 就 Bill 可以给听众讲讲你在念书的时候学界对 RL 态度的变化 。 ### RL 翻身 **朱哲清** [10:27] 就是最早期的时候 ， 我是跟 Rompard 做的 RL， 然后最早就是做 planning， 就是规划的一些 research。 当时的话其实 deep RL 还没有那么火 。deep RL 是 2016 年的时候 ，因为 AlphaGo、AlphaZero， 然后这一套东西变火的 。 从 AlphaGo 到 AlphaGo、AlphaZero 到 AlphaZero， 这三个迭代其实花了蛮久时间的 。 当时 deep RL 这件东西本身是不是有完全形成共识 ，其实还是在一个发酵的过程当中 。 所以当时我还是跟 fundamental 的去学了一下 planning 的整个 landscape，是在做什么 ， 就是现在的规划能力的这个 ， 跟 tree search 更相关 ， 就 Monte-Carlo Tree Search 这一段比较相关的一些研究 。 然后到了 Stanford 以后呢 ， 发现就当时其实 deep RL 已经形成气候了 。 所以 Monte-Carlo Tree Search 这一套的 planning 能力 ， 从某种意义上来说 ，在新的 deep RL 的这个时代呢 ， 没有那么重要 。 当然了 ， 后面又证明它还是蛮重要的一个能力 。 然后我就去找 Ben & Roy 读 RL 的 PhD， 然后 Ben & Roy 可能做的东西跟 Rompard 就没有什么太大关系了 ，但是他俩呢是很好的朋友 。 所以当时我去 Ben 这边读 PhD 是 Rompard 推荐的 。 然后在 Ben 这边读 PhD 的时候 ，是更多的做 sample efficiency， 就当时我们主要研究的是如何把那个 reverse scaling law， 就是把数据需求从最早的很高的数据需求不停地往下拉 ， 就是拉到现在可以完全 trackable 的一个数据需求的状态 ， 让 RL 算法真正可以落地 。 因为 RL 算法的一个核心的痛点就在于是说 ， 你所需要的交互数据量是非常非常大的 ，因为你所规划的并不止一个单步的事情 ，而是一个非常非常多步的一个事情 。 所以它所需要的数据量跟你的整个规划的整个 steps 的数量 ，以及你有多少个 action、 多少个 state 都正相关的一个东西 。 所以问题更复杂的情况下， 你所需要的数据量就无限地在往上涨 。 所以从这个角度来说 ， 你如何从一个比如说 linear scaling 变成一个 square root scaling， 这就变得非常非常重要 。 比如说你有 1 万个工具可以调用 ， 每个工具你要用 100 个数据点可以学会这个工具 ， 然后你要 1 万个工具要学会的话 ， 你要 100 万个 。 那有几个 step， 第一个是你能不能泛化 ， 就是从工具到工具的泛化 ， 你可能可以比如说 1 万个缩小到比如说 5,000 个 ， 或者说 1,000 个 。 然后你是不是可以把泛化完的数据再不只是直接 scale 到比如说 1,000 个 ，而是说 square root it， 比如说变成根号 1,000。 就是说你的所有的理解这些 1,000 个或者 1 万个 action 的数据量 ，并不跟它本身的工具的数量成正比 ，而是说跟它的开根号的这个工具数量成正比 。 那这个东西的做法呢 ， 就是说怎么去有效探索 ， 就是说我每去找这个工具本身去用一次 ， 我都是有的放失地去用这个工具 。 就是说我已经知道这个工具对于这件事情肯定不好用的情况下， 我不要再去用它了嘛 ， 对吧 ？ 那你所需要的数据量 ，因为这样更 intelligent 的这种我们叫 exploration， 就会使它的所需要的数据量就大幅地去压缩了 。 那这件事情不只是对于工具本身 ， 对于这个步数也是一样的 。 当你的步数越长的时候 ， 你探索就变得更重要了 。 比如说有两条路径是很相近的 ， 然后有一条路径已经证明肯定不可行了 ， 那这条相近的路径 ，而且我们所知道它的 nature 也相近的情况下， 你是不是就不用去探索它了 ？ 那你就可以去省掉探索一条路径的这个事情了 。 所以我们要做的事情就是说 ， 能不能从现有的数据和现有的知识和现有的 knowledge 上面去对于这个解决的问题这个 knowledge 上面去 distill 说哪些东西是已经探索过的 ， 哪些东西是没有任何价值去探索的 ， 哪些东西是值得去探索去解决我们未知的 ， 只去探索那些解决未知的东西 ，而摒弃去探索那些 重复性劳动 ， 使得我们所需要训练的总数据量大幅地缩减 。 能达到同样结果的情况下， 用的数据量可以比如说原来的 1/10 甚至 1%。 **孙海宁** [14:25] 嗯 ， 这个就是你在本科然后到博士的时候主要去研究的方向 。 **朱哲清** [14:29] 对 ， 博士的时候主要做的就是这件事情 ， 然后同时把这个技术想办法落地到实际环境当中去 。 强化学习这个领域 ， 很长一段时间都是被大家诟病为说可能所有的研究员自己在自己玩的一个 ， 就强化学习这个 community 这个社区内部在那自嗨的一个 field。 但是大家也看到了 ， 就最近几年确实强化学习开始 take off。 那我们当时其实核心就是找到说怎么落地是最 robust， 真的能找到落地路径这么一件事情 。 所以在 Meta 在读博的时候 ， 主要关注的都是这一点 。 然后在这个过程当中呢 ，其实我就发现强化学习的可能 potential， 就它所带来的潜力远不止于说只是帮 Meta 的广告带来个 1%、2% 的 revenue 的提升 。 它核心可能能够更大的幅度能驱动的可能是一个新的 AI Agent 或者说 AI 技术的一个井喷 。 因为我们都说强化学习是 superintelligence 的一个核心驱动力 ， 所以从我们的角度来说 ， 就特别是从我个人角度来说 ， 强化学习的 impact 肯定不止于在公司内部这么一亩三分地 。 所以当时我们其实我跟我的朋友啊 、 投资人啊 ， 然后和我自己的导师其实都有简单聊过我自己的想法 。其实我一直都思考说 ， 既然强化学习能够帮助 AI 带来这种非常强的推理和规划能力 ， 那能不能真的就用强化学习为核心 ， 就不依赖语言模型的情况下， 做出一个有强规划和推理能力以及工具调用能力的 Agent。 当时我跟我的导师和那些投资人聊完以后， 大家都觉得这个 idea 比较 exciting。 投资人这边当时我聊的时候是去年 9、10 月份的时候 ， 那时候其实 Agent 还不火 ，RL 也不火 。 那当时大家可能就觉得说这个事 make sense 的 ，但是大多数 VC 可能都不能理解说 RL 是什么或者 Agent 是什么 ， 只有少数的 VC 可能理解了说 okay 这个东西可能有一些 potential 在里面 。 可能学界和业界的人听到我这个想法以后都觉得非常的 promising， 甚至有很多人我 10 月份出来了以后都直接 reach out 给我说能不能加入这家公司 。 当时我还没有透露我们融资的各种情况的情况下， 大家都非常有加入的倾向 。 所以我觉得这个大方向还是非常有潜力的 。 总体来说 ， 可能整个创业的驱动力 ， 就在 DeepSeek 火之前 ， 我们就看到了 RL 在整个业界落地以及 Agent 方向的一个巨大的潜力吧 。 **孙海宁** [16:52] 嗯 ， 为什么你觉得 RL 是 DeepSeek 带火的 ，不是 O1 带火的呀 ？ **朱哲清** [16:56] O1 其实他说了他是 RL 驱动的 ，但是大家都不知道他背后的 RL 逻辑是什么 。 大多数的猜测呢是在于 O1 可能用的是一个叫 inference time reinforcement learning， 就是说他可能在训练的时候做的还是 RLHF，但在 inference time 的时候做了一个 chain of thought， 就是思维链的 Monte-Carlo Tree Search style 的一个做法 。 这个其实到目前为止都没有任何定论啊 ， 就是因为 OpenAI 自己的人也从来没说过这事 。 但是从他的推理速度各方面来看 ， 确实大概率他们在训练的时候应该没有做太多的优化 ， 更多的是所有的 effort 都放在了就是 inference 就推理端 。 然后 DeepSeek 为什么火的原因 ，是因为它其实核心就回到了可能当年 AlphaGo 到 AlphaZero 之间的一个状态 ， 就是说我不需要在非常复杂的人为去标注每一个点的 performance， 用一个像 rule 一样的一个东西 ， 就可以帮助你去判断说这个 Agent 在某一次 sequential 的 action taking 的这个过程当中， 你做的是不是好 。 那它就解决了两个问题吧 ， 一个是在 RLHF 这个过程当中， 你需要大量的人为标注去训练一个 reward model。 那第二呢 ， 就是你的整个训练速度会变得非常快 ， 就是说我每次 sequential action take 完了以后所得到的结果 ， 可以立刻被一个几乎可以是 ground truth 的一个 reward 去 validate， 然后再去训练这么一个 Agent。 所以它几乎就回到了当年 AlphaGo 和 AlphaZero 这个中间带 ， 我还没有到 self-play 的阶段 ，但是我可以在没有外界干预的情况下， 就能够训练出一个超过现有最好模型的一个模型了 。 当然了 ， 它有自己的问题在啊 ， 比如说 DeepSeek R1.0 这个模型 ， 它是纯靠 RL 的 robust reward model， 这个模型本身呢 ， 从某种意义上来说是人类不可读的一个东西 。 就很多时候它 output 的东西就是 gibberish， 就它可能从 rule-based reward 的这个系统里面可以 score 一直在往上涨 ，但是你真的把那个 output 拿出来给人读 ， 人可能就读不懂他在说什么了 。 **孙海宁** [19:01] 对 ， 所以他后面又做了 。 **朱哲清** [19:02] 从某种意义上来 。 **孙海宁** [19:03] 他又包了一层吗 ？ **朱哲清** [19:04] 就 RLHF 的那一层 。 所以我为什么说它还没有完全到 AlphaZero 的那个状态的原因 ， 它需要大量的 human 的 heuristics， 就是人类的一些经验化的东西在里面去帮助它去找到一个人类比较喜欢的一个状态 。 所以我为什么会把它放在这个阶段的原因 。 当然这个类比也不是 100% 准确 。 ### Agent 内核 **孙海宁** [19:26] 嗯 ， 你可以和我们的听友简单解释一下用 RL 来作为 Agent 的核心 ， 它大概是个什么概念 ， 然后包括也可以对比一下就我们的听友可能知道的一些 Agent， 比如像 Deep Research， 或者说大家最近讨论比较多的 Manus， 就这些 Agent 它又可能是以什么为核心的 ？ **朱哲清** [19:42] 我觉得这个又牵扯回 Agent 本质是什么 ， 就是大家把很多不同的东西都称之为 Agent 嘛 。 那从我的概念上来说 ， 我们设想的 RL Agent 是以 RL 为核心做所有决策驱动的一个 Agent， 它不再是说我只是输出一段文字 ， 然后这段文字当中有一部分是工具调用 ， 然后这段工具调用是嵌套在整个文字当中的一件事情 。 而我们会认为说所有的 planning 和 reasoning 以及工具调用的过程是一个抽象化的过程 ， 就是说它可能有一个 concept after 一个 concept 规划的能力 ，在完成这个规划以后 ，其中有一部分是某种工具 ，其中有一部分可能就是 information retrieval， 就是它的整个构想方式和现有的 Agent 都不太一样 。 这也是为什么 Agent 的核心模型都不是一个语言模型的原因 。 **孙海宁** [20:34] 那这个从用户角度怎么定义了 ？ 因为可能对大部分人来说 ，他其实不在意怎么实现嘛 。 **朱哲清** [20:39] 所以我刚刚说的是偏技术层面的 。 那偏用户层面的话 ， 我个人认为很重要的一点就在于说 ，不管是 Deep Research 还是 Manus 也好 ， 它仍然是一个 surf the internet 的一个状态 。 那它没有一个写入 internet 的能力 ， 比如说你有 Facebook 账户 ， 或者说你有你微信 ， 那你所要的结果不只是说它可以从某一个人的 Facebook 主页 ， 或者说从某一个人的某一个页面上去抓取一些信息 ， 然后总结一下， 或者写入一个网页 。 而是说你可能想要在 Facebook 上面直接发个帖子 ， 或者说你要在 LinkedIn 上面发一个招聘帖 ， 或者说你要去 Amazon 上面拉一个产品的 review，并且把它 post 到某一个地方去 ， 或者放到你自己的 Shopify 网站上 。 那像这种内容的 action 都是真正要写入互联网的这种 action， 那这种能力是目前大多数 Agent 都不具有的 。 **曼祺** [21:32] 这个和 LLM 您觉得是矛盾的吗 ？ 因为如果我给它多一个 function， 那好像它也可以完成写入功能 。 **朱哲清** [21:39] LLM 你可以试一下 。 一般来说 ， 你如果看市面上， 如果你要横跨互联网大多数工具的话 ， 可能有上千个工具 ， 几千个工具 。 那其实我们在用最好的 language model 上 100 个 ， 甚至上 50 个工具的时候 ， 它就开始 hallucinate， 就开始产生幻觉了 。 因为它的 context length 和 attention 就那么长 ， 你需要比如说 50 个工具 ， 每个工具有比如说 1,000 个 token 去描述它 ， 那就是 5 万个 token， 光工具描述就是 5 万个 token。 然后你还有上下文 ， 你还有 agent 的 memory， 然后后面还有用户的给你的 prompt， 这些东西全夹在一块 ， 放进你的整个给到 LLM 的 prompt 里面 ， 让它去选择一个工具并去调用它 ， 这是非常难的 。 更别说我们做的不是一个单一工具调用 ， 我们是一个比如十步 、 十几步的工具调用 。 那你想想啊 ， 你完成一步工具 ， 然后你把这个工具调用做完了以后， 你再把剩下已经出来的结果 ， 可能说你拉了一篇文章出来 ， 然后这篇文章再放回你的 prompt 里面 ， 可能这篇文章本身又有 1 万个 token， 然后再放回去 ， 然后再去执行下一步 。 你想想如果是十几步下来 ， 那就是上百万个 token 一次任务 ，100% 的所有的 LLM 都会产生幻觉 。 所以一个核心点就是为什么我不用语言模型作为核心决策点的原因 ， 就是因为想要规避掉这种问题 。 **孙海宁** [22:59] OpenAI 的 operator 在功能上它是希望能写入互联网的 ， 对不对 ？ 它是希望能做一些操作的 。 **朱哲清** [23:05] 对对对 ，但是 operator 成功率非常低 。 **孙海宁** [23:07] 对 ， 它不是很好用目前 。 **朱哲清** [23:09] 其实从某种意义上它比 Manus 要强一点 。 就 Manus 写入的能力其实没有 operator 强 ，但是 Manus 的 Deep Research 和整合信息的功能更强一些 ， 所以它可以做到生成网页 、 生成内容的基于大量的搜索和 factual information， 然后最后生成的内容相对比较好 。 然后 operator 呢 ， 它执行能力其实要比 Manus 更强一点 ， 你让它做一些比较基础的操作它也能做 ，但是呢它又没有 Deep Research 的功能 。 所以 Manus 等于是把两个功能嵌套在一块了 ， 就是说它的一部分执行功能和检索功能是由网页带来的 ， 然后另一部分信息抓取的功能是一部分网页和一部分现成工具嵌套 Deep Research 的工具嵌套在一块做到的 。 所以它是一个非常好的工程产品 ，但我们要想要解决的一是更长期的问题 ， 就是说如果长期以往互联网不再是互联网 ， 它没有任何的用户前端了 ， 你要怎么去解决这个问题 ？ 就是人跟互联网的交互不再由一个非常漂亮的前端完成 ，而是你直接跟一个 Agent 接口说我要干这么 12344 件事情 ， 你帮我做了 。 那怎么样去能够帮助用户在没有任何前端的情况下完成任务 ， 同时能够让用户理解这个 Agent 干了些什么 ，而且 Agent 和人类可以更可能有高效的去交互 ， 这个是我们想解决的问题 。 就是说从第一性原理来说 ， 如果 Agent 可以代替所有人类完成所有的这种操作型的事情的话 ， 那 UI 的存在其实并不是很重要 。 今天的 UI 是帮助人类去理解这些信息和信息流的 ，而 Agent 所要去理解这些信息流 ， 你就给它完全 raw 的文字和图片就好了 。 它根本就不需要有一个非常 fancy 的前端 ， 弄一大堆 JavaScript， 然后只会 confuse Agent， 对吧 ？ 它也不需要看这些东西 。 所以这是我们想解决的问题 。 **孙海宁** [24:58] 嗯 ， 就是你觉得应对未来你刚刚说的那个比较终局的环境 ，其实 RL 你觉得是一个长期更有潜力的方向 。 **朱哲清** [25:05] 我需要 step back， 就是 RL 是一个通用的工具 ， 它在应对任何环境下， 它都有它自己的优势在 。 而 LLM 本身是为了帮助你去理解文字来进行操作的 ，但是文字的长度总有它自己的限制 ， 就是它的整个 context length， 你的 attention 的机制 ， 总和你的模型大小是有正相关的 。 当你的信息量无穷大 ，以及你有大量的 memory 的储存的时候 ， 那你就需要想办法在一个相对比较抽象的环境当中去做决策 。 我们希望说能够通过 RL 的方式去把整个决策层给抽象出来 ， 然后把工具的规划以及调用完全由 RL 单一模型来完成 ， 然后语言层留着单纯作为理解和交互的功能 。 就相当于我们认为长期来说 LLM 可能会是一个 UI， 它可能是互联网的 front end，但是互联网的 back end， 所有的工具的交互以及 connection 是由某种 protocol 加上某种决策机制来完成的 。 比如说你告诉 Agent 说我今天是早上要去买个菜 ， 然后它可能它把这个语义理解下来以后去 pass 给一个 RL 模型 ，RL 模型说哦这个用户想要做的是买菜 ，并在这个服务提供商这边去买 ， 然后它就通过某一个机制把这个信息传达给对方的某一个 Agent， 就可能是 B 端的 Agent， 这个 B 端 Agent 收到这个信息以后， 再把它从他们的某个库里面 、 数据库里面去拉出来说 ， 如 果这个用户要在这个地方买这样的菜 ， 需要在哪里可以买到 ， 然后把这个信息抓取回来以后， 发一个 request 给比如说可能线下的某一个人， 然后这个人收到这个 request 以后， 就把东西送到了这个人的家里 。 而这个过程当中是不一定要用文字信息来传输的 ， 就这个过程当中完全可以是由数据库 operation 加上你可能后端的一些信息的流动来完成的 ， 然后完成了这些所有的操作 ， 回给用户端的可能是一个偏文字的东西 ， 再转化成文字说 OK， 我已经帮你叫了这个人， 把你的菜送到了这个地点 ， 然后你自己去取 。 所以我们可能长期以往比较相信的是未来的后端的所有东西都会相对比较黑盒化 ，而不是全部由文字的形式来输出 。 **曼祺** [27:26] Bill 你的意思其实是像大语言模型 ， 它更像一个翻译器 ， 或者说人和机器交互界面 ，RL 更像一个规划器一样的东西 ，是这个意思吗 ？ **朱哲清** [27:35] 你可以这么理解 ，但是我需要解释的一件事情就是 RL 跟语言模型本身是不冲突的 。 你可以用 RL 来训练语言模型 ，但是你也可以用 RL 来训练一个非语言模型来解决更抽象的环境里面的任务 ， 就像你用 RL 去做机器人一样 。 比如说你把 VLM 里面的规划过程变成一个 RL 的一个决策 ， 一个 policy， 那在这个过程当中其实它也不是个语言模型 。RL 是一个通用的工具 ， 它在规划和推理能力上面很强 ， 所以你可以用它来做任何的抽象的规划以及决策的这个事情 。 这也是为什么我们决定说前端仍然由 LLM 来完成 ，但是后端就完完全全就不用 LLM 了 。 **曼祺** [28:14] 刚才提到一个很好的问题 ， 就是那个 LLM 它其实没有办法承载太多的工具 ， 就比如说 Bill 你提到的 50 个以上 ， 它可能就记不清或者说产生幻觉了 。 那这个是可以解决的吗 ？ 你觉得还是说这个长期来看也是不能解决的呢 ？ **朱哲清** [28:28] 就是这个事情你要说我有无限的计算量 ， 然后我永远可以去 scale 我的模型大小 ， 那 eventually 当然是可以的 ，因为就是 attention 的复杂度基本上跟你的模型大小基本上是可以成正比的 。 就是说你需要关注的点的数量和你的模型大小基本上是可以同比例去 scale 的 。 那在这种情况下， 如果我们假设有无限的计算资源以及无限的 scaling， 那确实是可以做到这一点 ，但是前提就是我们没有 。 就是说你不能假设说永远的我们就不停地去扔计算资源去完成更复杂的任务 ，因为大多数情况下未来的复杂任务可能变得更抽象 ， 或者说你的工具都不停地几何级数地在往上涨 。 那 LLM 只能比如说 linearly 去增长它的 context length， 所以它不可能说永远无止境地去把世界上所有的工具都包进来 。 就你可以想象一下未来你可能平时想到的所有的工具 ， 包括垂直领域的所有的工具 ， 都能够被集成在一个系统里面 。 那在这种情况下， 它可能就并不是一个非常 linear scale 的东西 ， 它可能是个信息爆炸式的一个工具的使用的一个事情 。 **曼祺** [29:41] 那刚刚的假设其实是工具是无限多的 ， 会不会有另外一种场景 ， 就是说其实 LLM 它不需要掌握 50 个 、100 个工具 ，而是说我掌握 10 个能造工具的工具 ， 比如说我会 Python 代码写得非常好 ， 我就可以自己造工具 。 **朱哲清** [29:53] 这个事是个很好的问题 。 那其实有一个非常简单的 counter argument， 就是你可以想象一下说它可以写 Python， 写 common sense 的一个 tool 写得很好 ，但是比如说你要让 LLM 去写一个工具 ， 能够直接去帮你去 schedule 一个 Zoom meeting， 或者帮你去 schedule 一个腾讯会议 ， 那它根本就没有见过腾讯会议的 documentation， 它怎么能够写好这个任务呢 ？ 所以它这个东西除非你用 browser 是一个 common sense 的东西可以做 ， 那用 browser 又回到了原来的问题 ， 就是它变得非常复杂 ， 然后 token 数量非常高 ， 操作的速度还比人都慢 ， 那何必要用 browser 呢 ？ 那如果是让它自己写代码去完成这件事情 ， 它没有见过这种 documentation， 那它如何又能够把这个代码写好呢 ？ 你等于说我要重新再去训练一整遍 language model， 只为了去调用一些新的工具而已 。 所以这个逻辑上面就是说如何能够保证语言模型作为一个基座 ， 或者说用户交流的一个媒介的情况下 ，在不重新训练它的情况下， 我已有工具是不是能够完全自主调用 ， 我甚至有成千上万个工具都会无限地去 scale， 这可能是我们的目标 。 **曼祺** [31:03] 那接下来可以请 Bill 给听众讲讲 Pokee.ai 具体的 Agent 产品 。 我最近试了一下， 感觉它的交互界面和其他的 Agent 长得差不多 ， 就是屏幕分两半 ， 左边是和 Agent 交互的聊天界面 ， 右边是呈现 Agent 执行任务的结果 。Pokee.ai 和人类交互的方式在设计方面有什么不一样吗 ？ ### 产品设计 **朱哲清** [31:20] 我们的目标还是能够以非常简单的方式让用户能够体验到说什么任务已经被完成了 ， 什么任务没有被完成 。 那可能有一些不太一样的一点是说我们是会在执行之前询问用户整个任务的完成情况和整个任务的规划情况是否是用户满意的 ， 然后再执行 。 目前大多数的 Agent 的体验方式呢 ， 都是我们叫类似于 free flow 的体验方式 ， 就是说你不知道 Agent 每一步会干什么 ，而是它自己就会慢慢 rollout 一步一步一步一步地往外打开 ， 做各种样的 function call， 或者说执行各种各样的生成式的任务 。 而由于我们的任务都会直接写入用户的互联网账户和他们自己生活和工作当中的各种各样的平台 ， 所以我们希望说我们所执行的操作的规划是用户所满意的 。 所以有了这么一个设计 ， 就是多了一步用户的 approval 的过程 。 那与此同时的话 ， 还有一点不知道海宁你有没有试过 ， 就是其实在整个流程当中， 如果说当中是有一个叫 step by step 的一个 execution，也就是说如果你点那个 ， 它每一步有很多步 ， 如果不是搜索的话 ， 它都会让你去点是否同意执行 。 所以你可以看到说这个执行的 input 是什么 ， 如果这个输入你不满意 ， 你是可以手动修改的 。 这样的话你对于整个产品的 flow 是有更多的控制的 ，而不是说你点了一个键 ， 然后 there's nothing you can do 这种状态 ， 这是非常无助的 。 因为如果它真的卡那卡半个多小时， 然后最后说它不行了 ， 那你其实觉得说这是完全在浪费时间 。 所以我们有这么一个设计 。 那有一个非常重要的点 ， 就是我们其实收到过非常两极分化的反馈 ， 就偏 business 的那些人呢 ，他们会觉得说如果没有这个同意按钮 ，他们会觉得疯了 ， 就是这个东西它就自己在那执行 ， 然后写入我各种 Facebook 和 Instagram 账户和 LinkedIn 账户 ， 然后也没有我的同意 ， 这个我会非常没有安全感 。 但是开发者这一端 ， 就是真正的 AI 发烧友 ， 或者说 researcher， 或者说开发者 ，他们会觉得说为什么要给我去点那个同意按钮 ， 就直接一下子全部拉完 ， 越快越好就好了 。 所以在用户体验方面其实有很两极分化的这么一个情况出现 ， 所以我们支持了两种模式 。 **曼祺** [33:33] 你刚才提到就是说一开始会把那个流程给用户看 ， 然后让用户去决定这个任务完成流程是不是合理 ， 这个是不是很常见吗 ？Manus 也会做类似的这个功能 ？ **朱哲清** [33:44] 如果是用 operator 的话 ， 很多时候它是不给你的 ，Anthropic 也是不给你的 。OK，Manus 它是会给你看 ， 然后看完了以后它就自己去执行了 ， 它也不会说你可以去改那个执行界面 ， 然后你就一个个去把它改完了 ， 然后让它就根据这个去执行 ， 它应该也是不支持的 。 所以它就是会自己手 ， 它会有一个 doc writer， 然后这个 doc writer 是一个 LLM， 然后这个 LLM 它会写一些 bullet points， 然后就放进一个 txt file， 然后它在执行的过程当中会让你看一眼 ，但你并不能说哦我要把这个暂停下来 ， 然后真的跑到那个 txt file， 然后把它全删了 ， 然后重新改一遍 ， 然后它基于这个再去执行 ， 这个我记得是不支持的 。 **曼祺** [34:19] 我自己用的时候发现一个挺显著的区别 ，Pokee.ai 它没有一个虚拟机 ， 一个页面展示说这个机器具体在做什么 ， 比如说它是不是打开网页 ， 然后是不是在写文档之类的 ， 这个是为什么不加这样一个页面展示它呢 ？ **朱哲清** [34:31] 首先我们其实大多数任务都不用 browser-based， 所以我们的特别是写入互联网账户的这些 ， 都是跟那些公司有官方的接口和官方的 ，不说合作吧 ， 就是官方的这个 access 的 。 所以从我们的角度来说 ， 这些内部的信息就跟那个公司的 privacy 有关 ， 跟公司的章程有关 ， 我们不能一直去不停地去 ping 它的那个 status， 然后把那个 status 告诉你 ， 这个可能不是特别好 。 然后我们后面在一些 deep research 方面的这些任务呢 ， 我们不会给你们虚拟机吧 ，但是会告诉你每一步在干什么 ， 这个会做到 。 **曼祺** [35:09] 在交互页面之下，Pokee.ai 它完成任务和其他的 Agent 产品有哪些差异呢 ？ **朱哲清** [35:14] 首先最大的差异一定就是在执行侧 ， 就是和几十个互联网大公司和大平台的接口 ，以及这些平台接口背后那数千个 ， 目前可能有 1,000 多个 API 的接口的打通 ， 这个是目前市面上没有任何人可以做到的 。 然后一个核心的难点就在于每个互联网大平台背后的接口本身是非常非常相似的 ， 然后有很多很多 API 互相之间都是几乎长得一样的 。 那这些东西你是怎么能够让它更好地去区分开 ， 让一个 Agent 可以完全能够使用这 1,000 多个接口 ， 然后能把它做好 ， 这是市面上没有的 。 第二是我们尽可能避免了对网页端的依赖 ， 就是说有很多东西你其实还是不得不用网页 ， 然后你很多东西还是不得不说我要做一个 search， 那这些东西我们还是仍然在做 search。 但是除此以外， 我们如果能够用代码来解决 ， 就写代码去解决一个问题 ， 我们就写代码 。 如果说能够用接口来解决就用接口 ， 我们未来也会接 MCP 跟 Agent to Agent， 如果能把现有的 MCP 跟 Agent to Agent 接进来 ， 我们也会用它们 。 但是我们一定会避免用 browser 来解决问题 ，因为 browser 在我们眼里不是未来 ，因为如果未来世界上都是 Agent to Agent 的话 ， 那 browser 的存在只会是一个中间态 。 所以我们尽可能去避免这样的一个形态出现 。 **曼祺** [36:37] 为什么要把能接入各个平台的 API 作为核心卖点呢 ？ 它对应 Pokee.ai 核心用户的什么需求 ？ **朱哲清** [36:44] Pokee.ai 的核心用户一定是开发者和 professionals， 就是他们是我们可以被理解成一个 to B 业内的一个 to C + to B 产品 ， 就是它的用户场景一定是 to B 的 ， 就是说它是一个在工作流当中要完成一些任务 ， 来用这种方式 ， 就是用 Pokee.ai 来完成它工作流当中的所有的自动化 。 但是使用者呢 ， 很有可能是一个个人开发者 ， 就是它是某家公司的一个个人的开发者 ， 它有可能是某家社媒平台的某一个做市场营销的职员 ， 它有可能是个某个广告平台的广告投放员 ， 它有可能是某一家公司的法务 ，也有可能是某一家公司的财务 。 那他们做的事情仍然是一个 B 端的事情 ，但是它使用的人可能是个 C 端的人。 然后在这之上， 我们未来会往更多的 enterprise 去走 ， 就是跟某些公司内部的 infra 去打通 。 那这里面其实有很多很多的问题在 ， 就是为什么大多数公司 ， 特别是大的公司 ，以及对数据有很多的 sensitivity 的公司 ， 它没有跟 OpenAI 打通或者 Anthropic 打通的一个核心原因就在于这里面有很多的 privacy 的问题在里面 。 所以你能不能做到 private cloud， 你的模型是不是足够小 ，是不是足够 scalable， 能够做到这一点 ， 这个是非常非常重要的 。 所以我们之后也会花力气在这个方向 ，但目前我们的主要受众还是个人的开发者和 professionals。 **曼祺** [38:07] 这个我觉得还蛮有意思的 ，因为可能更多的 Agent 产品 ， 它的目标受众就是最广大那些消费者 ，但是 Pokee.ai 的定位是找那些专业的消费者 ， 这个定位是怎么找到的呢 ？ **朱哲清** [38:18] 因为我们最早有了这个 idea 的构想的时候呢 ，其实就跟好几家我自己认识的广告 、 社媒 、 营销一些业内的人士就有沟通 ， 然后他们听到我这个想法以后 ，他们就觉得这不可思议 ，因为他们的最大的痛点不在于生成内容了 ， 现在因为生成内容真的很容易了 ，但他们的问题是即便你能生成这些内容 ， 我还是要花 3 个小时 、4 个小时在各个平台 上面去进行传播 ， 进行推广 。 那更麻烦的是 ， 如果你是个社媒平台 ， 运营管理更麻烦 ，因为比如说你这个帖子发出去了 ， 肯定有几十个回复出来了 ， 你难道手动一个个去点它 ， 然后去回复它吗 ？ 嗯 ， 现在 Pokee.ai 的话 ， 你就可以直接说找到这个帖子 ， 把下面所有的回复用个性化的方式每一个回出去 ， 它就可以帮你回完了 。 所以它可以省下大量大量的时间 ， 帮你做各种各样的事情 。 **曼祺** [39:09] 理解 ，但这之后拓展的方向为什么又是在到企业端用户 ，而不是说更广大一些更普通的消费者呢 ？ ### 企业路径 **朱哲清** [39:15] 消费者我们要看情况 ，但是我们目前对于非常非常 general 的纯 general agent 的观感是 ， 用户很有可能会被你能做的事情给 overwhelm，而去执行一些跟你能力范围不匹配的事情 。 就比如说像 operator 这样的一个 to C 产品 ， 对吧 ？ 然后我和我身边朋友第一反应是做我现在说的这件事情 ，不是去搜索内容 ，而是去真的是执行 ， 帮你去比如说安排个会议 ， 发个邮件 ， 类似于这种 。 我第一反应是想做这件事情 ， 然后我试了以后发现一个都不行 ， 就是 0% 的成功率 。 然后当时我拿到 Manus 的邀请码以后， 我也干过一样的事情 ， 比如说你帮我 Facebook 发个帖 ， 它也是几乎 0% 的成功率 。 那当然了 ， 跟我们一样做一些简单搜索啊 ， 做一些内容的收集啊 ， 生成一些代码什么的 ， 它都没有问题 ， 对吧 ？ 那这个是我们可能还没有做那么深 ，但是在执行侧 ， 目前是没有人可以跟我们做的一样深的 。 所以我们的目标群体更多的是说 OK， 那工作流在哪里 ， 对吧 ？ 我们现在有个人开发者跟那些 prosumer 这些人群 ，他们有大量的非常繁杂的工作流 ，但真正的工作流还是在企业内部 ， 就企业内部会有几十步 、 上百步的工作流需要去解决 。 所以我们需要解决的是说 OK， 那未来这 100 步工作流是不是能够直接被 Agent 取代了 ？ 里面有些需要人在的地方 ，Agent 去主动找人完成 ，而不是人做半天 ， 然后每一步当中去找一个 LLM 去解决那个内容生成的问题 。 所以这是我们最终想要走的一个方向吧 。 **曼祺** [40:46] 能进入一个大公司的工作流 ， 然后让它取代几百步的可能是之前的自动化流程 ， 这个你觉得 Pokee.ai 它和已经在提供这样服务的 ， 比如说 Salesforce 这样的公司是竞争关系吗 ？ 还是 ？ **朱哲清** [40:58] 我觉得不会 ， 就是像大公司的工作流是足够复杂的 。 当然我不觉得 Salesforce 的 Agent 做得很好 ，因为好多人都跟我吐槽它 ， 主要是这种拖拽流的 Agent 无可避免 ， 就是它有一个 rigidness， 就是你除了这个工作流稍微变一变 ， 它就又不行了的这个问题在 。 所以我倾向于把 Agent 或者工具 ， 就是那种拖拽流 Agent 工具 ， 还有那些 LLM 的 AI 工具全都包成一样的态度 ， 就是说它们都是某种工具而已 。 然后你需要的是一个更上层的 ， 能够更好地规划以及知道无限调用的这样的一个功能 ， 这个可能是我们最后的使命所在 。 **曼祺** [41:37] 拖拽这样的一个 ， 就是相当于是人工编排一个工作流 ， 然后让 Agent 按照这个工作流严丝合缝地执行 ， 这个可能就是大公司最重要的需求 ，因为他们的工作流可能是更加僵硬或者固定的 ，而且变化比较少 。 那就当有一个有自己生成工作流的能力的 Agent 出现之后 ，他们就真的会有这样的需求吗 ？ **朱哲清** [41:58] 这是个特别特别好的问题 ， 这是为什么我们会从小的 prosumer、developer 往上走的原因 。 原因是在于你要去改变大公司的工作流的走法 ，其实是非常难的 。 但是我其实有很多的观察 ， 就是很多大公司的工作流是大家希望它改变的 ，而不是说大家都觉得按部就班就很好 。 所以需要做的事情是一个 bottom up 的一个 influence， 就是说你可能很多原来二三十步的工作流 ， 可能就只需要七八步就可以搞定 ， 可能并不需要那真正二三十步的那种工作流当中的很多内容或者很多的步骤都是多余的 。 所以如果你有一个 AI 自动生成的工作流的模型 ， 可以把工作流所对应的所有工具 ，以及给人派遣任务的这个事情都可以做完的话 ， 那 eventually 当这些我们在共同成长的这些小的公司 ， 或者说个人的开发者一起成长以后呢 ，他们会去 influence 那些更大的公司 ， 说哎 ，他们已经做到那么有效率了 ，而且做事情做得那么好了 ， 那这些大的公司也会想办法来 adopt 你的 solution。 这个 sell cycle 是非常难的 ，因为没有人去希望做那种打破原有界限的这种改变嘛 。 所以我们可能会先 focus on 中小型公司 ， 加上个人开发者和 prosumer， 然后慢慢地再去 influence enterprise， 可能需要一些你自己的 trust 在里面 ， 就是你认识的人， 然后他们知道你的 Agent 能力边界在哪里 ，他们才会去 deploy。 但是我们已经看到一个比较好的 sign 了 ， 就是我们一些湾区的朋友 ，他们把我们的 Agent 的 demo 和一些简单的尝试的一些用例发给他们的老板以后 ，他们老板其实很想买我们的产品 。 所以在执行侧大家还是会有这个需求在里面 。 **曼祺** [43:40] 另一个比较好玩的点是 ，Pokee.ai 如果有一个子任务没有完成的话 ，其实不妨碍它继续执行后面的任务 。 **朱哲清** [43:46] 我们有 ，因为是 RL 生成的整个规划以及执行嘛 ， 就是说它会知道说我的这个 action 之前的 context 是什么 ， 然后这个 RL agent 会说这个 action 可能跟之前的 context 没什么关系 ， 所以它就会跳过某一些内容 ， 然后去完成下一步 。 就是说我尽可能地把你整个任务都完成掉 ， 能完成多少完成多少 ， 然后下一步你可以再跟我交互说哎 ， 这几步没有完成 ， 然后怎么去根据现有的信息再去完成下一次 。 我们是这样去思考这个问题的 ，因为你的目标不是让用户被卡住 ，而是说能完成多少尽可能去把它完成好 。 **曼祺** [44:23] 理解理解 。 那如果 Pokee.ai 整体任务失败的话 ， 它可以继续自己 debug 重新尝试吗 ？ 因为我自己在试的时候 ， 它好像还没有这个功能 。 **朱哲清** [44:31] 对 ， 它现在我们没有打开 ，因为我还在测试这个东西 ， 还是跟原来那个情况很类似 ， 就是说我们希望能够让它非常 stable 去 debug，因为如果说它 debug 完了以后， 它自动执行了 ，而它可能把你的 input 的那些内容给改掉了 。 比如说你想发布一个文章 ， 然后它 debug 的时候发现你这个文章内部有什么问题 ， 然后它就直接给你改完了以后给你发出去了 。 比如说我有一个非常 classic 的问题 ， 就是 LinkedIn。LinkedIn 如果你连续发两篇一模一样的文章 ， 它会把你 block 掉 ， 那即便你用的是我们的官方接口 ， 它还是会有这问题 。 那如果说一个足够聪明狡猾的 Agent， 比如说 Pokee.ai， 我们已经见过它干这个事情了 ， 它就会直接给你绕开 ， 它说哎 ， 我把你那个内容稍微改一改 ， 然后再给你发出去 ，但这不一定是你想要的这个体验 ， 对吧 ？ 所以我们要去找一些 case， 可能说有些是可以绕过 ，有些是就应该让它直接 fail， 然后告诉用户的 。 当然 LinkedIn 这个 case 你可能是希望 Agent 是 smart 一点 ， 就真的把它绕过的 ，但是有一些 case 就是你不希望它绕过的 。 ### 速度与协议 **曼祺** [45:33] 我自己试的时候发现 Pokee.ai 完成任务的速度非常快 ， 大概 1 分钟左右就能完成一项任务 ， 这个是怎么做到的呢 ？ **朱哲清** [45:40] 对 ， 就你看我们的 demo 那个视频里面 ， 从不管是什么社媒账号运营 ， 还是 meeting， 还是我们之前做分析这三个例子里面 ， 所有东西我们都没有加过速度 ， 就是原始速度 ， 就是当中包括了所有的 approval， 就你可能来来回回再点那些 ， 加起来是 60 秒 。 如果那些 approval 全都不要 ， 就让它自己转的话 ， 可能就十几二十秒就搞定了 。 这个就不能细讲了 ， 我们的做法不是 browser use， 我们也有 browser 的部分 ，但是呢 ，有很多 action taking 的地方 ， 我们和很多公司是有合作和集成的 ， 所以很多 action taking 的地方是有极大程度的压缩的 。 我们可能最后会有一个 ， 你们会看到一个对比图 ， 就是说我们和 browser use 的这些 Agent 相比 ， 速度和准确率可以极大幅度地提升 ， 然后在大多数的任务场景下面 ， 我们都可以 autonomous，但那些非常 niche 的那些场景下面呢 ，他们其实也做不好 ， 所以我们也就不做那些场景 ， 我们会告诉用户怎么去做 。 然后在对于那些 MCP 和 Agent SDK 的这种竞品上面呢 ， 我们所可以覆盖的产品和工具列表或者平台列表要远高于他们 ， 就是我们和两种竞争者对比起来 ， 我们都有很大的优势 。 **曼祺** [46:54] 所以你们去调工具 ， 你们不是用到 MCP 这个协议是吗 ？ 或者说你们只用了一部分 ？ **朱哲清** [46:59] 不是 。 **曼祺** [46:59] 你们不是啊 ？ **朱哲清** [47:00] 我们完全没有用 ，但是我们后面会支持 MCP，因为有很多人已经建了 MCP 了 ，why not？ 但是我们之后会有个协议会更简单 ， 你就告诉一个 JSON file 把 input、output 和你的 endpoint， 就比如说你是个不管是什么样的 API 或者说工具 ， 你把 endpoint 告诉我们 ， 我们就可以直接调用了 ， 你也不用 host。 **曼祺** [47:18] 嗯 ， 那你们现在能调这么多工具 ， 相当于是就是你把你刚才说的那个更简单的协议 ，在那些你们想用的软件和工具上， 你们自己加了一层 。 **朱哲清** [47:27] 对对对 ，但是并不只是就正常的 API 或者 browser， 还有很多很多别的工具在里面 。 嗯 ， 所以就不能非常的笼统地告诉你们说工具都是怎么生成的 ，因为有很多很多工具是以不同的形态呈现的 。 **曼祺** [47:44] 嗯 ， 那听起来感觉这个好像还是一个挺重人力的过程 ，因为当时提出 MCP 的想法就是说所有人能群策群力 ， 你做好一个工具 ， 别人就不用再发明一次 ， 这个你怎么看呢 ？ **朱哲清** [47:55] 目前来说我们还没有遇到这个问题 ， 后面肯定会遇到这个问题 ， 我们也会做开发者社群 。 我们现在预估第一轮 release 也就是 1,000 个工具左右 ， 就 1,000 个可以调用的子工具 ， 可能平台可能几十个 ， 然后子工具加起来有上千个这样子而已 。 然后我们会做开发者社群 ， 让所有的人使得他们的 SaaS 软件或者他们的工具能够非常轻易地被使用 ， 然后他们只需要告诉我们他们工具长什么样 ，他也不需要告诉我上下文 ，他也不需要告诉我任何的什么东西 ， 就是直接告诉我 input、output 和他们 endpoint 怎么 call 他们就结束了 。 然后我们就可以把他们的工具直接吸纳进我们的整个 ecosystem 里面 。 **曼祺** [48:35] 所以你们这个属于 MCP 的竞品吗 ？ **朱哲清** [48:38] 我们也会用 MCP， 所以不算竞品 ， 就是人家如果说想要更简单一点 ，不需要安装 ，也不需要做什么 JavaScript server， 那他们就可以用我们 ， 这个就日子好过多了 。 **曼祺** [48:47] 有一个比较无限扩展的这种工具调用的能力 ， 肯定是很多做 Agent 的人都想实现的一个东西 ，也能很自然地看到这个东西是有价值的 。 那实际上大家的实现方式主流的来说有哪些了 ？ 比如说你们的这种尝试可能是一种 ， 你有看到市场上其他人有一些其他的你觉得比较有潜力的实现方式吗 ？ **朱哲清** [49:06] 大多数还是以 LLM 为核心吧 ， 就是还不太能见到非 LLM 模型在这个方面的应用的 。 有几家公司在做一些跟 contrastive learning 相关的一些 approach，但我们试用下来可能也不是效果特别好 ，他们可能就偏传统的那种带 a ding supervision 的那种模型 ， 就这种模型在我们现在试用下来可能效果并不是特别好 。 嗯 ，因为它的 negative 的那个 noise 太高了 ， 比如说你有上万个工具 ， 然后这上万个工具当中只有一个是正确的 ， 那你得到的 negative signal 就太高了 ， 比如说你随便去调用里面任何一个工具 ， 它大概率都是错的 。 嗯 ， 那你等于说这个工具可能你被 sample 了无数次 ， 人为帮它标注了也无数次 ， 然后到最后连一个正确的解都没有找到 ， 那这样的话你训练起来就难度非常大 。 嗯 ， 所以从这个角度来说 ， 你需要一个非常 smart 的一个机制去完成这个训练 ， 这是我们的一个 secret sauce 吧 。 **曼祺** [50:00] 嗯 ， 你可以讲讲就是从 24 年 10 月 ， 你当时比较明确地要出来创业 ， 然后到你开始构建 Pokee.ai 这个产品 ， 你中间关于一个好的 Agent 应该怎么构建 ， 应该具备什么样的要素 ， 包括你们做了什么事 ， 你一步一步大概是怎么想的吗 ？ ### 四要素 **朱哲清** [50:15] 对 ，有几个问题 。 第一个要对比的就是人为操作时间跟机器操作时间的对比 。 如果一个 Agent 做出来以后， 人为自己去做某件事情 ， 比机器做某件事情时间还短 ，不管你是有人 involve 没有人 involve， 这 Agent 一定都不会成功 。 因为人的一个惯性思维就是我如果要做这件事情 ，他就会在旁边盯着 ，他不会说啊我要做这件事情 ， 然后我就走开了 ， 然后等 30 分钟回来以后发现这东西还是没有完成 ， 然后他改来改去又走开了 ， 然后又回来他也没完成 。 大多数人， 甚至于你们在下载文件的时候 ， 你们都会在旁边去盯着他 ， 就是因为人大概率都会想说这个东西是不是会 fail， 对吧 ？ 每 10 分钟就会去 check 一下哎这东西是不是有问题 ， 对吧 ？ 这是一个人的常态的一个思维惯式 。 所以从这个角度来说 ， 如果说一个 Agent 的执行速度比人做还慢 ， 那这个 Agent 就基本上不太可能成 ，因为人不太可能脱离那个什么都要管一下的思维惯式 。 这是第一点 。 **曼祺** [51:14] 这个假设好像有些强啊 ， 就是比如说虽然可能大家都会盯着一个任务过程看 ，但是你可以一边看一边刷手机和一边你得全人关注地看 ， 似乎还是有些区别的 ， 你不觉得吗 ？ **朱哲清** [51:26] 是 ， 你是可以这么说 ，但如果有这样的场景的例子的话 ， 就那么简单的场景都需要比人的速度都要慢 ， 那我觉得这个 Agent 本身的实现就很有问题 。 我们希望可能能够达到的效果就是说你完成一个任务就是个二三十秒甚至一分钟的事情 ，不可能说你要等半个小时， 然后回来以后他发现还是 fail 的一个状态 。 这是我们当时的第一个 assumption， 就是说你不管完成什么任务 ， 肯定要比人的速度要快 。 然后第二点呢 ， 就是整个任务本身它的串联是基本上 minimize 所有 human input 的 ， 就不能说 OK， 我完成了第一个任务 ， 然后拿到了一些信息 ， 还需要人去复制粘贴放到第二个任务里面去 ， 然后再去做第二个任务的执行 ， 这个是一定要避免的 。 如果说他只是帮你完成单一任务 ， 然后你还要去拿那个结果 ， 然后再复制粘贴到下一个任务当中， 然后再让下一个任务的 Agent 去完成下一步的任务 ， 那你还不如就让人去做 。 因为很多时候整个 context switch 的过程比人的 cost 还要高 ， 所以我们希望能够把整个工作流上面的所有的任务全部都衔接好 ， 你不再需要说从第一步到第二步当中还需要有人去 involve 了 。 这是第二个点 。 然后第三个就是不能只有读 ， 必须要有写 。 大多数现在 Agent 都只有读 ， 就是说我可以从互联网上抓取各种各样的信息 ， 然后帮你做 deep research， 能够做一些分析 ，但是你能不能去写入互联网 ， 或者写入你自己的个人账户 ， 或者你的工作账户 ， 或者你的公司账户 ， 这个是目前缺乏的一个能力 ， 这是我们想要做到的一件事情 。 嗯 ， 最后就是 efficiency， 它的算力不能够太高 。 对 ， 如果说算力太高的情况下， 举个例子啊 ， 如果说一个任务平均的 cost 是 2-3 美金 ， 比如说你就简简单单写一个网页的 summary， 或者帮你去建立一个单一的网页是 2-3 美金的话 ， 那你其实可以想象说你一个月如果说去采取比如说 100 次任务 ， 那就是可能 3-5、6 百美金 。 那比如说一家公司 ， 它可能一共比如说三个人共用这么一个 intern， 可能一个 intern 的价格也就是这个价格 。 也就是说它的价格 ， 所有工具所执行的总的数量和人的 cost 几乎可以相当的情况下， 那这个也很难去 scale。 所以我们就是希望说它跟人， 就是廉价劳动力本身的整个价格差距至少要比如 1/10 甚至 1% 的状态 ， 这个才能够真正的让 AI 的这个使用频率会大幅增加 。 因为如果说它的价格很高的情况下， 你其实用一两次 ， 如果有一次 fail 了 ， 你可能就觉得我还不如去雇个人去干这件事情 。 所以从我们的角度来说 ， 它的成功率高的同时， 价格必须要压得很低 ， 才能够使得这个东西真正去普及 。 **曼祺** [54:13] 就是刚也提到了哈 ， 一个是 RL 它速度很快 ， 另外一个就是好像之前你也提到说 RL 在一个 CPU 上面跑 ， 为什么它的成本会比 LLM 低这么多呢 ？ 不管是时间成本还是算力成本 。 **朱哲清** [54:25] 不是 LLM。 嗯哼 ， 就是我们要把模型跟算法拆开看 ， 就是算法是 RL，但是 LLM 也可以用 RL 来训练 ，但是我们只是用了一个别的模型 ，但不是 LLM 的模型用 RL 来训练 。 **曼祺** [54:38] 就是你们是用 RL 训练了一个不是 transformer 架构的语言模型的一个别的架构的 ， 就可以这么说吧 ， 就一种别的模型反正 。 **朱哲清** [54:45] 具体是什么架构我就不能说了 ，但是就是它有个别的架构的模型在里面 ， 就是这个模型本身要便宜很多 ， 跟 RL 本身没什么太大关系 ， 它会快很多也会小一些 。 **曼祺** [54:55] 然后刚就还提到 ，其实就是一个很理想场景下， 就是模型能使用的工具会不断增加 ，而且有一群这个生态内的 developer 会不断地提供这个工具库 。 工具增加之后， 模型需要重新去训练吗 ？ 因为在 LLM 的场景下 ，其实你给工具加一个描述就可以了嘛 。 **朱哲清** [55:12] 我们也是一个完全泛化的模型 ，因为我们训练的时候有见过 15,000 个工具 ，但这 15,000 个工具并不是每一个都可我们可以直接使用 ， 这些工具都是从互联网上抓下来的一些工具 ， 还有我们自己构建的一些工具 。 所以这些工具本身就给了我们 Agent 很强的泛化能力 。 所以从这个角度来说 ，Agent 本身可能不会需要再因为加了工具以后去重新训练 。 但是如果出现了很多非常 niche 的垂类工具的介入的话 ， 我认为可能会需要做一些 fine tune。 原因在于即便你把这些垂类工具给到 LLM， 估计 LLM 也 handle 不了 。 那 LLM 如果要重新训练一次 ， 那成本就比我们高多了 。 所以我们应该就是在通用工具上面是不需要重新训练的 。 但是如果未来有一些非常小众的一些垂类的工具进来了 ， 我们会考虑重新训练这个模型 。 **曼祺** [56:02] 嗯 ， 就你刚刚说那四点啊 ， 就是你想到用这是几个构建 Agent 的要素 ，是你创业一开始就想得比较清楚吗 ？ 还是有一个逐渐清晰的过程啊 ， 包括你们的团队是怎么来组建的 ， 就可以讲讲大家第一个 Pokee.ai 的过程吗 ？ 这个产品 。 **朱哲清** [56:16] 嗯 ，其实一开始的时候并没有那么清晰说这四个点必须都要完成 ， 只有一个点是很清晰的 ， 就是要跨平台 。 就是说我们一定是大量的不同的工具串在一块来完成一个人类任务 ，因为人平时就是这么去干活的 。 所以我们认为说如果一个 Agent 真的能替人去干活 ， 那它一定是跨平台多工具去完成一个非常复杂的任务 。 这是我们一开始的构想就有的 。 那价格是我们当时也确实就是在融资的时候也 emphasize 的一个点 ， 就是说我们这个模型架构所带来的价格优势是非常大的 ，但我从来不会真的去因为这个去打广告 ，因为价格这东西真的不是一个非常长期的 ，不能说不是长期优势吧 ， 就是说 eventually 总会有人想办法把就是 computational cost 给压下来的 。 所以你价格很低并不代表说你有永久无限的价格优势或者资源优势 。 所以我一般不会去 advertise 这个 ，但是多工具多平台无限 scale 和 easy to use 这个是我们一直都觉得这是核心要素 。 嗯 ， 剩下两个点是我们目前后面在慢慢慢慢摸索当中总结出来的 。 嗯 ， 就是说从某种意义上来说要比人快 ，而且你的 scaling 要非常好 ， 这些事情都是我们在后面在摸索 ， 就是整个产品慢慢在构建过程当中总结出来的事情 。 嗯 ，因为我们一开始也用 operator 跟 computer use 去做很多的 ， 比如说 tasks 去体验嘛 ， 然后其实有 6%-70% 的这种任务啊 ， 就是我们自己内部在使用的时候 ，在测试的时候 ， 我们都不等它做完 ， 就没有耐心去等它做下去了 。 就是觉得说这个东西就那么简单一件事 ， 我还等你可能两三个小时去跑一个这个东西 ， 真的是没有什么太大必要 。 所以我们一般情况下总结下来 ， 就是人没有那么长的耐心等你去完成那么复杂的任务 ， 然后花那么多时间 。 就很多这种东西都是在我们自己试用和自己的这个摸索的过程当中总结出来的 。 整个团队的构建其实跟这些摸索没有太大的关系 ， 主要还是一开始的时候 ， 我在构建整家公司的时候 ， 还是一个端到端的这么一个架构 ， 就是从 fundamental research 到 production engineering 到产品的 experience 的 engineering， 这个都需要有最专业的人来做 。 所以我们的团队有一个 research scientist，是我之前 Meta 的一个下属 ， 然后是做 reinforcement research 的 ，也是 Risk Sutton 的学生 ， 然后有 ML engineering 是之前我做 B2B recommender system 的一个下属 ，也是做 production 非常好的 ， 然后还有个 product engineering 的一个 partner， 这个是我很多年的一个朋友了 ， 然后也是之前 Meta 的同事 ，他是做 product engineering 有非常有经验的一个人。 所以我们就是端到端 ， 每一个关键点上都有一个很有经验的人来带这个事情 。 当然我们现在团队一共全职员工就四个人， 然后很多活都是靠 AI 来帮忙的 ， 然后我们自己也写了一些 AI tools， 内部很多的 scaling 啊什么的 ， 都是靠我们自己写的一些 AI tool 来完成的 。 然后呢 ，有一些 contracting 的 contractor 的 help， 那就是亚洲这边会有一些 contractor 在帮我们忙 ， 做一些相对比较杂的事情 。 **曼祺** [59:31] 回到就是这个产品形态 ， 我知道就是在你们现在这个产品形态之前 ，因为我跟一些早期跟你见过的投资人聊过 ， 你们早期还有一个方向是做旅游路线规划什么 ，但我不知道这是你的一个方向还是个 demo。 ### 早期试错 **朱哲清** [59:44] 就是个 demo， 就是我当时花了可能一两个礼拜的时间 ， 然后就告诉他们说 ， 如果你用我们这个架构去做一个规划能力和工具调取能力的这么一个 Agent， 它能够有多 powerful。 就是我们当时用了一个可能就几百万个 parameter 的一个模型 ， 就做了一个可以横跨很多个城市的 Google Maps 调用的一个功能 ， 就是一个垂类的 Agent 的功能 ， 然后 Google Maps 下面所有的工具 SDK 的集成什么的都可以全部集成进来 。 当时就想 showcase 一下说 ， 如果你想做一个工具调用的 Agent， 我们的这个方案可能是非常 scalable 和非常快速的 ， 你也不需要等 ， 就是去拔网页啊或者怎么样 。 对 。 **曼祺** [1:00:28] 哦 ， 那这个 showcase 里面它还是不涉及到多平台的 ， 对不对 ？ 它主要就是在 Google Maps。 **朱哲清** [1:00:32] 对 ， 当时还不涉及多平台 。 当时其实都是在 Google 内部了 ， 就是 Google Maps 加 Docs 加 Calendar 这种 ， 这个其实也算多平台了 ，但就可能从当时的角度来说 ， 已经算是相对就是工具调用上面已经是非常强的一个 Agent 了 。 但是当时可能从投资人这边来说 ， 没有一个共识说工具调用是未来的一个 future。 **曼祺** [1:00:56] 那所以接下来做了一个帮 Shopify 商家做推荐做客服 ， 这个产品当时是怎么想的呢 ？ **朱哲清** [1:01:02] 核心还是一样的 ， 就是当时通用 Agent 并没有一个共识 ， 大家也不觉得说这个东西能卖钱或者怎么样 ， 所以所有人都说要不你们先找一个落地点 。 那我们当时就说 ， 那我们这个 Agent 能力很强 ， 我们就直接把 Shopify 底下的所有工具 ，不不管是他们的 command line 啊 ， 还是他们的 graphQL 啊 ， 还是他们的 API 啊 ， 还是 SDK 啊 ， 全部集成进来 ， 然后变成一个面向商家和面向客户全功能的一个 Agent。 嗯 ， 我们花两个月就做完了 ， 等于是说你平时要把这个逻辑全捏在一块 ， 你可能花一两年时间才能把这个逻辑全捏完 ， 我们就花两个月就把整个背后所有的逻辑全都捏完了 ， 就是完全都靠我们现有技术能力就可以完成 。 所以这个就是一个类似于像技术测试一样的东西 ， 就是说是不是真的能够通过这种方式使得整个开发速度和 robustness 都有很大幅度提升的一件事情 。 当时我们就通过这个项目 ， 后面觉得说这个东西确实是有很大前景 ， 然后与此同时呢 ， 我们当时还想说 OK， 我们是不是要 expand 这个东西 ， 然后去卖或者怎么样 ， 然后 RL 就突然火了 ， 然后火了以后呢 ， 就所有人都来找我们了 ， 就说那你一开始那个 vision 怎么样 ， 然后我就说那我们就回到原来的原始 vision， 就从零就把横向那个平台给打通 ， 把 这个技术给做出来 。 所以这是为什么从 12 月份的时候开始 ， 我们就开始回到原始 vision， 说 OK， 我们就把这个最核心的这个技术把它给铺开做好 。 **曼祺** [1:02:35] 所以差不多是从 24 年 10 月到 24 年底 ， 你们是在做就是跟这个电商场景有关的 ， 更垂直一些的一个应用 ，而且有考虑过去落地 ，但后面因为市场环境的变化 ， 你就可以回到你觉得你本来最开始更想做的这个事情 。 **朱哲清** [1:02:49] 你的核心问题是要卖嘛 ， 就是你要去卖 。 那如果没有人去意识到通用 Agent 的核心能力和工具相关和规划相关和 RL 相关的话 ， 那很难拿到市场共识 。 那 DeepSeek 跟 Anthropic 两家的过去的这 effort 使得这件事情形成共识了 ， 那就很非常有利于我们 ， 就是我们没有做任何 marketing effort 的情况下， 流量就自然的有很多偏向于了我们 ， 就是因为有很多别的公司来帮我们做了这个 education 的过程 ， 所以我们就认为这个时机到了 ， 可以回到我们的原始 vision 了 。 ### 市场反响 **曼祺** [1:03:22] 这个流量是说投资人的流量吗 ？ 还是 。 应该是吧 。 **朱哲清** [1:03:26] 投资人， 然后客户 ， 还有很多 developer 的关注 ， 全都可能就是 12 月份 、1 月份 、2 月份 ， 几乎就是以一个几何级数的增加 ， 就是一开始就是非常平的一个状态 ， 就是我们自己在开发 ， 没人管我们 ， 然后突然今天 12 月份就是所有人都来找我们了 ， 就是说几乎有上百个投资人来找过我们 ， 然后客户的话也有几十个客户 ， 就大型客户来找过我们 ， 然后小的 developer 就不计其数了 。 就我们上那个 demo 当天 ， 一个礼拜内有 800 多个 waitlist 的 sign up， 后来 3 月份上线以后有 800 多个人 sign up，而且我们没有做任何 ， 就连朋友都没让他们帮我们分享 。 当时我们就觉得说 OK， 这个确实是这个流量比我们想象中要大很多 ，因为一般来说 product launch 当天 ， 你会让很多很多朋友帮你分享 ， 然后把那个流量给顶上去嘛 ， 然后我们发现转化率特别特别高 ， 就是当时可能 view 量可能也就才 1 万左右 ， 然后有差不多 8%-9% 的 conversion rate， 这个就有点非常离谱了 ， 就是说你一个网上的某一个帖子的到 waitlist 的转化率有将近 8%-9%， 这 个就是比我们任何一个之前甚至在 Meta 见到的产品的转化率都要高的一个状态 。 **曼祺** [1:04:43] 嗯 ， 那如果总结一下， 你就是从去年 10 月到现在没有半年的这个创业历程里面 。 **朱哲清** [1:04:49] 没有 ， 四个多月吧 。 **曼祺** [1:04:50] 你觉得几个比较重要的里程碑 ， 或者说几个比较高兴或者比较 down 的点都是些什么呀 ？ 当时发生了什么事 ？ **朱哲清** [1:04:57] 首先第一件事情就是我们开始融资的时候 ， 没有人理解说 RL 加 Agent 是个什么东西 。其实今年我们有跟 ， 就我这次 GTC 这段时间 ，因为很多人请我去一些 event， 然后做一些 panel 嘛 ， 然后其实有聊很多投资人， 投资人就说 you are like six months ahead of the curve， 所以 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， 然后有好几个我比较熟悉的投资人其实有告诉我说 ，他们觉得这个时机可能开始慢慢变成熟 ， 你可以回到你的 brand vision 跟 platformization 上面去 。 所以当时听到了好多次这种 feedback， 当时那个产品也做完了嘛 ， 所以我们就觉得说 OK，是时候把那个产品就放在那边 ， 该卖就卖 ， 然后我们这边就回到一个通用化的一个状态 。 然后这是第二个点 ， 这个时候我们整个团队的心路历程就是说 OK， 我们本来就是非常脚踏实地在做一个产品 ， 然后现在突然间可能甚至有一个 J-curve， 或者说 。 **曼祺** [1:06:37] 有一个势能 。 **朱哲清** [1:06:37] 有一个 potential curve 的可能 ， 对 ，有一个势能出现了 ， 就是我们开始发现这个机会 ， 然后我们到了那个点以后， 我们就开始说我们去怎么去架构整个 Agent 的整个 backend 和 infrastructure， 然后一直到了 3 月份的时候 ， 我们把一开始这个 demo 做出来了 ， 然后这个 demo release 以后呢 ， 我们发现说这个兴趣量真的很高 。 这个事情非常巧合 ，因为我们的 release 是 Manus 的 release 前两天 ， 我们 release 的我们的那个视频 。 **曼祺** [1:07:05] 3 月 4 号 。 **朱哲清** [1:07:06] 对 ， 我们 3 月 3 号的早上 release 的 ， 然后国内 3 月 4 号看到的这个事情 ， 然后两天以后 Manus 就 release 了 。Manus release 以后， 我们一开始还觉得说会不会已经有一家竞品已经在做这件事情了 ， 然后看完了以后发现不是 ，他们还是在做一个偏生成式的一个功能性的东西 ， 然后速度还是以 browser 为主 ， 所以速度还比较慢 。 所以我觉得说这个东西完全可以互补的一个状态 ， 就是我们这个领域还目前没有太多人去碰 ， 所以是一个相对比较蓝海的状态 。 **曼祺** [1:07:34] Manus 的爆火出乎你的意料吗 ？ **朱哲清** [1:07:36] 不出乎我意料 。 首先他们的市场做得很好 ， 这个是值得我们学习的 ， 就是说如何使得一个非常 technical 的产品看起来甚至对于就他们偏 consumer 嘛 ， 对于 consumer 来说非常 boring 的一个产品 ， 让大家觉得非常 exciting， 这个是就像艺术一样的一个事情 ， 就是你需要有有经验的 marketer 去帮你做这件事情 ，他们 marketing 做得非常好 ， 所以这个是必须要给 kudos 的 。他们的整个产品设计和就 是 engineering 的整个套用都是做得很好的 ，因为它几乎把里面非常复杂的多步的 ， 就是从这个 Python 写作到下一个 browser 使用 ， 这些东西的工具的嵌套都嵌套得几乎没有什么缝隙 ， 就你不会出现说第一个工具弄完了以后， 第二个工具完全卡在那 ， 就完全做不下去的这种情况是不会出现的 。 虽然它还是很慢啊 ，但是至少它是一个相对 streamline 的一个过程吧 。 所以我认为说因为第一次有这么一个完全 TOC 的产品出现 ，是会给市场一个震撼 ， 同时 marketing 又做得很好 ， 所以它的爆火是有它自己的原因在那的 。 我们可能不会做那么 pool 的这个事情 ，因为我们还是偏 to developer 为主嘛 ，但是我们应该也会尝试说找一些人分享啊之类的 ， 去想办法让大家更多地知道我们这个产品的存在 。 我们产品的用户的可能是 learning 的 curve 还是要比他们的要稍微的 deep 一些 ，因为从某种意义上来说 ， 用户需要知道一定程度他们的工作流是什么 ，而他们就告诉他说我要建一个网站 ， 可能就一句话就搞定了 。 我们这个可能还是需要说我要做这么一件事情 ， 这个事情要完成这几个东西的 delivery， 那这几个东西是在什么平台上面的 delivery， 这个事情可能是需要用户告诉我们的 。 **曼祺** [1:09:24] 嗯嗯 ，但用户也是用自然语言告诉你就可以了 ， 只不过他要说得更清楚一些 。 **朱哲清** [1:09:28] 用自然语言告诉我们 。 嗯 ，也不是要说得更清楚一些 ，因为我们要真的去写入你的互联网账户 ， 或者写入你的工作账户嘛 。 如果你都不告诉我你的工作账户在哪 ， 那我也没地方可以去帮你写 。 那这就是跟 consumer 最大的区别在那 ，因为如果我真正的去帮你去某一个账户里面去执行的时候 ， 我真的需要知道这个账户在哪 ， 或者这个平台在哪 ， 你也不能就告诉我说哦建立个网站就好了 ，因为建立个网站我们也可以做嘛 ，但是真的有价值的还是帮你把工作给完成了 。 **曼祺** [1:09:54] 因为你刚刚讲到就是 3 月 3 号你们开始发这个 demo， 你们下一个节点或者说接下来的一个重要节点是什么 ？ **朱哲清** [1:10:00] 应该会是我们的 beta launch。 **曼祺** [1:10:02] 你们到时候是会给邀请码的那种形式 ， 还是大家直接可以用 ？ **朱哲清** [1:10:06] 大家应该直接可以用 ，但是会限制流量 ，因为一开始我们也不知道有多火 ， 万一直接把就是我们这边 competition 可能还好 ，但是因为我们有很多很多的 rate limit， 我们自己设置了很多的 rate limit， 我们不希望说直接把某些网站给冲垮了 ， 比如说去某个网页上抓信息 ， 然后很多人都说我要去这个网页上面抓信息 ， 然后那个网页企业就说这 Pokee.ai 是什么 DDoS 或者怎么 样 ， 把我们给封了就不行 。 所以我们还是要稍微小心一点 。 所以当天我们应该有用户会看到说有一些的工具可能用不了 ， 说今天的 rate 已经到上限了 ， 我们不能再继续开放了 ， 明天可以继续 。 邀请码的出现唯一的原因就是因为有 competition limit， 我们完全可以 competition scalable， 所以我们不会有这个问题 。 **曼祺** [1:10:53] Pokee.ai 单次任务成本大概在多少呢 ？ **朱哲清** [1:10:56] 就是目前市面上所有的产品的可能几十分之一 。 ### 护城河 **曼祺** [1:11:00] 因为你刚才说其实有一个比较重要的节点 ， 就是你们在 24 年 12 月 RL 又火了之后， 市场有了更多共识之后， 你们回到你们最初的那个愿景 ， 就是变得更通用 ， 就是想去做更通用的 Agent。 另一方面就是你会不会担心做更通用的东西 ， 它的竞争压力也更大呀 ？ 比如说 GPT-4o 释放了文生图功能之后， 也是有很多人在讨论 ， 当大模型本身的基础能力提升之后， 跟这个能力重合的那些方向上的一些 Agent， 比如说生图其实也是有一些 Agent， 它可能融合了一些工作流 ， 让你的效果可以提升 ， 然后这些产品可能就会受到一些冲击 。 然后另一方面我觉得就是更通用的 Agent 肯定也是各大模型公司 ， 包括像 OpenAI 这种创业公司里的巨头 ， 包括像 Meta、Google， 还有像字节 、 阿里这种中美的大科技公司都会做的方向 。 就你们的特别是在什么地方 ？ **朱哲清** [1:11:49] 我们肯定是以商业模式上， 未来就是就形成我们护城河的一个主要方面 ，因为如果你纯靠技术 ， 我其实觉得纯生成式的模型就有这个问题 ， 就是你没有任何的 integration， 没有挂靠 ， 没有粘度 ， 所有的东西都是靠你生成东西的质量 。 那生成东西的质量纯粹的 backend 就只有一件东西 ， 就是你的技术 。 除了技术以外， 没有任何的额外的护城河 ， 没有用户的粘度 ， 没有用户对你这边的绑定 ， 对吧 ？ 我们要形成的是一个工作流绑定式的东西 ， 比如说从此以后你有大量的文件 ， 过往的视频 ， 比如说你是一个社媒的博主啊 ， 你有大量的视频文件 ， 还有你的图片什么都已经存在 Pokee.ai 上面了 ， 你只要告诉 Pokee.ai 从我过往文件当中挑出三张我过去的年度的 summary， 然后帮我发到 Instagram 和 TikTok 上面 ， 就可以完成你的任务的情况下， 就没有办法直接就跳到别的平台上面 去了 。 就我们需要有个工作流上面的深绑定 ， 这是我们要做到的一件事情 。 **曼祺** [1:12:49] 我不知道我理解对不对啊 ， 它可能就逻辑是我为用户 ，也不能说创造啊 ， 就是让用户有一个迁移成本在 。 那如果是这样的话 ，是不是因为它其实是个速度游戏呢 ？ 就是如果同时有 ABCDE 五个产品都能提供同样的服务 ， 用户只用选一个和它绑定的话 ，其实做得最快那个人可能就最后越容易活下来 ？ **朱哲清** [1:13:07] 不一定 ， 这还真不一定 ，因为这就跟早年互联网游戏一样 ， 就是 Facebook 不是第一家 ，但它活下来了 。MySpace 当年其实有很多人跟它深绑定 ，但是仍然 Facebook 最后活下来了 ， 还是跟市场迁移的过程有关 。 就是当市场在不停的 shift 的情况下， 你是不是能够更快速地去进行你的策略的转变 ， 然后能不能抓到一些用户群体和这些用户群体所相关的 ，不管是你自己做 service 也好 ， 还是跟 vertical 公司做合作做 service 也好 ， 和这些用户进行更深度的绑定 ， 把一些市场先占下来 ， 把这个用户粘度拉起来 ， 然后才能够去扩张 。 就是说这个东西到最后还是个商业的东西 ，不是一个纯技术上面的东西 。 技术上面我觉得 eventually 肯定有人能够做跟我们类似的东西 ，但是我们希望说我们有个先发优势 ， 然后同时又有更强的集成用户粘度和绑定在里面 ， 可以给我们带来更长时间的一个护城河 。 **曼祺** [1:14:05] 就是你觉得这个中美商业环境会有差异吗 ？ 比如说你在中国 ， 如果你做写操作 ， 甚至就是你刚才举的例子 ，有些是跟线下的服务有关的 ， 我让他去帮我点个外卖什么的 ， 那如果在中国的话 ， 可能美团他就不想跟一个创业公司去做这种合作 ，是不是有可能 ？ 他觉得我可以自己做一个这样的事 ？ **朱哲清** [1:14:22] 当然 ，其实国内的几家大厂商都有来找过我 ， 就说要有没有什么业务合作的可能性 。 我觉得我们还是 focus on 能够把这个集成 ， 或者说能够把一体化的这个通用 Agent 的最快速能够接出来的这些工具先全都接进来 ， 然后把不管是各种形态的工具全都接进来以后， 我们再去考虑说我们作为一个平台给到比如说各个大公司去提供服务的方式去做这些事情 。 因为你要打通国内的市场实在太难了 。 我其实当年融资的时候有回国待过一小段时间 。 **曼祺** [1:14:59] 嗯 ， 来讲讲你的感受啊 。 **朱哲清** [1:15:02] 总结下来就是国内的生态大多数情况下是相对比较封闭的一个生态 ， 模型的生态是非常开放的 ，但是商业的生态是相对比较封闭的 ， 和欧美的生态环境很不一样 。 美国可能是最开放 ， 就北美是最开放的 ， 然后欧洲是居中的 。 欧洲其实有很多大公司也没有那么开放 ， 比如说 Booking.com，他们的整个生态也是有自己的护城河在里面的 ，他们也没有完全的开放这件事情 。 所以这个事情在北美肯定会第一个先做出来 ，不管是我们还是别的哪家公司 ， 一定是整个通用 Agent 的能力的爆发 ， 我猜大概率会在北美 ，因为商业的整个环境更开放 。 国内的话就看各大巨头愿不愿意帮忙了 ， 就是互相之间愿不愿意协作了 。 因为从某种意义上来说 ， 比如说我们就已经把 Google 跟 Meta 的整个 ecosystem 全接完了 ， 那就相当于在国内你需要把百度跟腾讯的所有的 ecosystem 全接在一块 。 我其实在这个地方就打巨大问号 ， 这两家公司愿不愿意合作在一块去完成这样一件事情 ， 对吧 ？ **曼祺** [1:16:05] 请你解释一下就是所谓的开放 ， 具体是什么 ？ 比如说是什么在国内做不了 ，但国外是可以做的呢 ？ **朱哲清** [1:16:11] 比如说你要去 Facebook 上面去写一个 post， 那你要去微信上面去发个朋友圈 ， 你肯定不能代替别人去发朋友圈 ， 就不算微信发朋友圈吧 。 你就说微信的企业端的账号 ， 你要去帮人家发一个什么视频号 ， 目前也没有结构让你做这件事情 。 但是在美国是可以做这件事情 ， 它有各种各样的东西可以让你做到这件事情 。 它有第三方的集成 ， 它有可以下载 SDK， 它有 REST API， 甚至有第三方的工具可以帮你去做这件事情 。 所以各种各样的生态来帮你完成这种事情 ，但国内这个生态就完全是封死了的 ， 就是只有腾讯自己可以做这件事情 ， 然后它可能有一些自己的 trusted partner 可以帮助它去做一些工具 ，但这些工具本身都是一家的 ， 就是只给腾讯单家做的 。 所以它不会说哦我同时可以接入腾讯 ， 又可以同时接入比如说阿里之类的 ， 这个很少见 ， 非常少见 。 **曼祺** [1:17:03] 对 ， 所以你刚才设想的这个就是我在商业模式上建立的壁垒 ， 你可能还是要先在北美市场跑通 。 **朱哲清** [1:17:10] 对 ， 对 ， 北美市场可能是我们的最重要的一个 first milestone。 然后后面当我们的 SDK 跟 API 的整个能力出来了以后， 我们会找各大公司看看有没有协作的可能性吧 。 **曼祺** [1:17:24] 你刚才说了很多次 ， 就是现在大家觉得 Agent， 然后强化学习 ， 然后 Agent 要去调用工具等等 ， 是一个共识 。 我想知道就是在实际的落地和实践上， 就像你们这样以 RL 为核心 ， 用这种通用的方法来做 Agent 的团队到底有多少啊 ？ **朱哲清** [1:17:42] 目前不是很多 ， 就是大家还是以快速落地为核心的 ，以套件为主的比较多 ， 比如说就套一个 cloud， 然后自己写一些工具 ， 然后直接套进去用一下， 或者直接套 GPT-4， 然后用有限的工具去套一下， 这个比较多 。 就很多雨过春水一般的公司都在尝试做这件事情 ，但是真的要做一个完全通用的无限 scale 的框架 ， 目前市面上我还没有看到第二家公司在做这件事情 。 有很多的小公司 startup 他们在尝试用 cloud 或者用 GPT-4o 去套 MCP 或者套现有工具来完成一个小规模的我们要做的事情 。 然后它基本上大都是以 to see 为主的 ， 就比如说最近你们看到那种 Blender 很火的那种 cloud 插件 ， 或者说你们看到的那种文生图的那种插件 ， 或者甚至有一些做一些 MCP server 是给比如 Cloudflare 的那种插件 ， 它都是偏有些是直接即插即用的 ， 给比如说 Cloudflare 的用户用的 ，有一些呢可能是说 Blender 给 Blender 小白用的 。 那这些东西呢可能都是就是想要快速获得流量 ， 快速落地 ， 然后拿一些 traction 的这种小公司做垂直领域的很多 ， 然后做完全横向的无视 vertical， 然后可以横跨很多很多领域的这种公司 ， 目前我还没有看到第二家 。 我们可能还是在这个方面比较执着的一家公司 。 **曼祺** [1:19:07] 为什么它是共识但做的人又很少了 ？ 是因为它比较难做 ， 比较难实现还是因为什么 ？ **朱哲清** [1:19:11] 就这个事是个技术壁垒 ， 就是目前你除非想花时间花精力去做研究 ， 从 fundamental 去解决这个问题 ， 目前还没有什么特别特别好的解决方案 。 我觉得可能会从 research 上面会有一些突破吧 。 接下来可能各大院校或者说几家巨头他们也可能会花时间去做这件事情 。 我们做的解决方案是目前我们觉得比较领先的 ，但未来会不会有更好的解决方案和合作 ， 或者说有别的集成方案很难说 。 但是我们希望能够通过我们现在的优势来完成就是第一波的市场的 integration 和市场的可能 scale。 **曼祺** [1:19:47] 我有一个很好奇的问题啊 ， 就是你们现在的这些做法在你们之前开源过的那个 pro 的那个项目里 ， 就是它有什么一脉相承的思路吗 ？ 还是其实已经进化了很多了 ？ **朱哲清** [1:19:56] 进化了非常非常多了 ， 就是那个是一个更 fundamental 的框架 。 我们确实有用 pro， 就我自己写的 library 里面的一部分来写我们现在的这一部分 ，因为它是 MICP license 嘛 ， 所以我们也可以用一些 。 确实我自己个人还是觉得很好用 ， 我们自己用下来是觉得很快速的加快了我们的整个开发进程 。 但是那个 library 里面确实只有非常 fundamental 的一些 components， 它没有一个算法层面的逻辑 ， 或者算法层面的一个精髓并不在那个 library 里面 。 **曼祺** [1:20:24] 垂直 Agent 和通用 Agent 他们是相互取代的吗 ？ 还是说其实他们可以共存 ？ **朱哲清** [1:20:28] 我并不觉得他们相互取代 ， 比如说像我们的核心长期的目的是我们想 power vertical AI agent 公司 ， 就是世界上有很多工具和很多的任务 ， 它里面所需要做到的事情其实是通用的 。 比如说你要写文件 ， 写 slides， 或者说你要去建个网页 ， 或者说你要去抓取一些比如说社媒的信息啊 ， 热点啊什么的 ， 这些东西都是通用的 。 但是只是你落在某一个落地的垂直领域上面 ， 它有些特殊的工具要做 。 我举个例子啊 ， 比如说你把社媒跟电商全绑一块 ， 那电商它可能要做一些 Shopify 的事情 ， 那 Shopify 里面有各种各样莫名其妙的工具在里面 ，但是跟社媒相关的那一大块东西并不区别于说你就是一个博主 。 所以不管你是个博主还是你一个社媒去卖电商 retail 的 business，他们俩所需要用的社媒工具都是一样的 。 所以我们已经把你这边最痛苦集成的那些东西都解决掉了 ， 你就告诉我你在 Shopify 上面要干点啥 ， 或者说你自己的这个博主平台 ， 或者说你自己有个博主网站 ， 这个网站上你要干点啥 ， 你把它集成起来 ， 我就可以把你整个工作流做完了 。 那我们其实可以 power 很多很多 vertical AI 公司 ， 说你不再需要去集成那 1,000 个工具了 ， 你只需要告诉我说你们这个 vertical 里面最重要的那 10 个工具是什么 ， 你就可以直接调用 1,010 个工具来完成你的任务了 。 **曼祺** [1:21:48] 你们这个产品最初肯定是应该在云端 ，在电脑端用的 ， 对吧 ？ 那比如说未来它有可能是需要拓展到更多终端吗 ？ 就比如手机移动什么的 。 **朱哲清** [1:21:57] 我们手机端应该也会做一下 ，但是感觉手机端做只是为了让更多人可以体验到这个功能 。 我们核心的突破点还是会在 developer 端 ， 就是以比如工具调用的数量 、 工具调用的成果来完成我们的收费的这个 。 ### 终局 **曼祺** [1:22:16] 你觉得像这个通用 Agent 的框架这一层 ， 就这个市场 ， 它可以容纳多少公司呀 ？ 因为现在做这个方向的创业公司肯定是不少了啊 。 **朱哲清** [1:22:25] 对 ， 做的公司肯定不少 ， 少说至少我觉得未来一年之内你能看到不小于 10 家公司的 。 那我觉得最后一定会存留可能四五家 、 三四家公司 ，因为它就跟很多像在 LLM 的这个领域一样 ， 就是你可能会有大量大量的不同的公司非常同质化的涌现出来 。在涌现出来之后呢 ，他们就会开始进行怎么说 ， 怎么去 differentiate themselves， 就是说这些公司本身可能会去更注重某些 vertical 或更注 重某些能力 ， 然后使得它自己的能力区分于别的公司 。 比如说 Claude 跟 OpenAI，ChatGPT 一开始出来的这个产品几乎是一模一样的 ， 然后 Claude 就更偏向于 coding 了 ，而 GPT 更偏向于 to see 了 ， 所以它自己的能力就被拉开了 。他们用这种方式去区分于对方 ， 然后使得自己的市占率仍然能保持某一个状态 。 之后 Agent 领域也会出现一个类似状态 。 **曼祺** [1:23:21] 但通用这个词语似乎和差异化本身就是矛盾的 ， 你怎么看这个问题呢 ？ 就是如果到达一个非常高境界的通用的话 ， 好像那就变成一个标准产品了 。 **朱哲清** [1:23:30] 那就跟你问 Android 跟 iOS 为什么还存在两个系统一样的道理 。 **曼祺** [1:23:35] 所以它只有两个吗 ？ **朱哲清** [1:23:36] 对对对 ，但是 Android 跟 iOS 这种操作系统的东西 ， 它的整个背后的逻辑框架非常非常复杂 ， 所以它的整个 replication 的成本很高 。 为什么会有人去想要去 replicate 它也是个大问题 。 而且 Android 是开源的 ，by the way， 如果 Android 当年没有开源 ， 可能就不止两家了 ， 肯定会有第三家出现的 。 那 macOS 跟 Windows 然后还有 Linux 三个东西不都还存在吗 ？ 而且因为 Linux 存在 ， 所以没有第四家出现了 ，在想要去打 Windows 跟 macOS 的市场 。 就一旦开源的东西出现了 ， 那就很难说我有很多很多很多家出现 ， 一定都会被开源的那个系统给统一化 ，因为很多后来的人都会用开源的那个系统 ， 它就变成标准化的东西了 。Agent 这个市场后面也会出现一些可能偏开源的东西 ，但是我觉得 Agent 这个架构可能就偏向于 OS 一些 ， 它的复杂度要高于纯 language model， 所以它的开源的难度要高于纯 language model 的开源 。 这个我觉得后面可以再去看一下会有什么样的开源市场出来 。 **曼祺** [1:24:41] 对 ， 像 OWL 和 OpenMiles 是不是也算是开源的 Agent 的框架 ？ **朱哲清** [1:24:46] 它不算一个框架吧 ， 就是它并不是一个调用工具非常复杂的一个框架吧 。 **曼祺** [1:24:52] 因为我跟那个 OpenMiles 的团队聊过 ，其实他们本来那个项目的名字是叫 Agent Hub 的 ，他们之前没有上线 ， 就是他们在开发但是没有放到社区里 ， 就其实也是几个个人开发者的工作 ， 就也不完全是公司的工作 。 但是因为当时 Miles 就是刚好在那个时间点嘛 ， 然后他们也用他们以前已经开发了一段时间的这个 Agent Hub 很快的做了这个 OpenMiles， 所以后来这个名字就改成 OpenMiles 了 。 就他们还是想做的是一个框架 ， 就是它有这种调用工具的潜质 ， 就是可以让别的开发者在这个基础上再做你想做的 Agent。 **朱哲清** [1:25:23] 明白 ， 这个我倒还没有跟他们了解过这个 ，因为我确实没有跟他们去交流过 ，但具体看他们想做的未来的这个框架的愿景是什么 ，因为我也不是很确定他们最后的 vision 是一个什么样的 vision。 它是一个偏 deep research 的 Agent 还是说它是一个生成式的 Agent， 还是说我要去真的去 platform 去写入的那种 Agent， 都不太一样 。 像最后那种 Agent 它的整个 integration 难度是最高的 ， 那前面那种就是开源比较好做 ， 后面那个是最难做开源的一件事情 。 所以我对于最后那种 version 的开源 ， 可能我认为难度会大一点 ， 整个 lifecycle 会长一些 ，但是一定会有某种形式的开源出现 。 **曼祺** [1:26:04] 最后想问问 Bill 如何判断一项技术的潜力 ，因为之前你也提到自己一直坚信 RL 能做很多事情 ， 之后 DeepSeek R1 出来之后也验证了你的判断 ， 就想问你的信念是怎么来的 ？ **朱哲清** [1:26:14] 我其实跟 Rhea Sutton 很多时候聊 ， 还有跟我自己的老板聊 ， 就我自己 PhD visor 聊 ，有一个很好的思维模式 ， 就是 Toy Examples。 就说比如说你看好一个技术方向 ， 你能不能构建一个 Toy Example， 用极少的计算量就可以证明说这个问题是别的技术方向做不了的 ， 然后你的技术方向可以做的 。 然后这个 Toy Example 必须是 intuitive enough， 就是说这个东西是大家认为是一个 meaningful 的 example， 比如说你举一些 common sense 的 example， 比如说推荐系统里面的 example， 或者说你举一个现在的话可以举一个小的 language model example， 然后在这个 example 里面你能明确看到别的技术方向做不了 ，而你能可以做到的 ， 那这个方向就已经有一个从某种意义上来说第一性原理上面的一个优势在里面了 。 就是说我能够判断在我所要解决的这个问题上面 ， 只有我的技术目前有这个领先地位 ，而且它有 principallyright solution for it， 那我觉得就是值得可以追下去的 。 而如果你做了一个 Toy Example， 说一个简单的 language model example， 或者推荐系统的 example， 或者说 data system example， 然后发现说哎你的技术跟别人没什么太大区别 ， 这个时候你再有这个执念去追逐你自己的技术就没有什么太大意义 。 就是如果别人已经 scalable solution， 就应该就跟随别人的 solution 就可以了 。 **曼祺** [1:27:36] 那如果按照这个思路会错过大语言模型吗 ？ 比如说其实大语言模型就是在它的规模没有到一定程度的时候 ， 它的效果是没有那么明显 。 **朱哲清** [1:27:45] 但是没有任何一个别的解决方案可以 even get close to what they're doing。 **曼祺** [1:27:49] OK， 就是说虽然那个时候的效果没有到可能给工业界或者说给用户一个惊艳的程度 ，但是它是领先于其他的方法的 ， 就是在实验的结果上来看 。 **朱哲清** [1:27:59] 对 ，因为我在 GPT-2 的时候就接触了语言模型 ，因为当时有一个教授拉我去做 language model 的事情 ， 我当时是觉得这个东西方向是非常有意义的 ，但是我当时就觉得说我要从零开始 catch up 这个 topic 确实是有点晚了 。 就 GPT-2 的时候我已经基本上确定它一定会火了 ， 就等于是一个这个船上面已经盛满了人， 然后这些人已经知道自己要去哪了 ， 然后你一个半当中旁边一艘小船上面的人， 哎我这个小船驶向一个不一样的地方 ， 我非要跳到他的船上去去跟他凑这个热闹 ， 我觉得可能意义不是很大 ，而且很有可能被人家淹没 。 所以我当时的决定就是说 OK 那个东西是 interesting， 我应该 catch up， 我要 learn from it， 就是这个技术和这个技能是我要的 ，但是我真的要成为这个领域的可能是第一个落地者 ， 或者前第一批的落地者可能已经不太可能了 。 所以我就觉得说还是要专注你自己最了解的方向 。 **曼祺** [1:28:52] 嗯明白 ， 你刚刚说的那个做一个最小的这个 Toy Example 的这个思路 ，其实还是一个科学验证的思路 ， 对不对 ？ 就就是做实验 。 **朱哲清** [1:28:59] 对 ， 就是你要先找到一个可以自洽 ， 就自圆其说的一个小的案例 ， 这个案例本身得是 genuine enough， 然后在这个案例当中， 没有一个技术是目前可以解决你这个问题的 ，而你的技术本身又是 principally 解决这个问题的 。 你不能说我 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 到现实系统里面有什么样的 bottleneck，有什么样的 system integration 要做 ， 然后把这些东西都打通了 ， 然后最后落地 。 它也不是 100% 会成的 ，但是至少你第一步做成了以后， 你会有这个信心说至少这个技术方向有 80% 的可行性的概率 ，而不是我盲目的就去跑大型实验 ， 然后大型实验里面有各种各样的 complexity， 它的 variable 太多 ， 没法控制变量 ， 导致我也不知道什么东西 work， 什么东西不 work。 **曼祺** [1:30:23] 你自己感觉到强化学习和大语言模型结合会非常有潜力是在什么时候 ？ **朱哲清** [1:30:28] 那那个时候我当时就觉得说 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 跟 partial observable 的东西就变少了 。 **曼祺** [1:31:49] 嗯 ， 你自己什么时候特别明确的感觉到就是用强化学习来做 Agent 肯定会是一个方向 ， 就这个你是在创业之前的某个时刻 ， 对吧 ？ 就有这个感觉 。 **朱哲清** [1:31:59] 我其实毕业的时候就在想这事 ，但是我构思了很久 ， 我构思了快半年， 我才想到现在的这个解决方案 。 嗯 ， 就是我当时 10 月份出来融资的时候才确定这个技术方向是这个样子的 ， 就之前我都没有确认这个技术方向 ， 当时都一直在摸索这个技术方向怎么样是最靠谱的 ，因为当中有很多很多 nuance 在里面 。 所以我当时也没有完全确定说我们现在的这个环境构造以及模型的建立和 self-play 是不是真的能 work， 我们只在就我刚刚说的那个 Toy Example 上面 ， 就是在 Toy 那个 Toy Example 上面跑通了 ，但是真的要 scale 到无数个场景 ， 它是不是真的能够泛化 ， 这个东西是打巨大问号的 。 但是后来验证下来是觉得它可以泛化的 ， 所以这件事情也是有一定冒险在里面的 。 **曼祺** [1:32:46] 就是我觉得有的人他创业的习惯是 ， 比如说在一些大公司的技术人员 ，他会先跑一段时间 ， 就把想法验证的更清楚 ， 甚至他人可能都找好了 ， 甚至投资都找好了 ，他才跳出来 。 啊 ， 我感觉你是直接做了决定你就出来了 。 啊 ，但是我不知道北美是不是这样 ， 我可能说的是国内的情况 。 **朱哲清** [1:33:02] 我其实之前也有找自己认识的人聊聊嘛 ，但也没有做的特别深 。 跳出来会有就可以给到投资人觉得说你有 conviction，而且我当时也怎么说呢 ， 就是也没有必要一直待着 ， 就你一直待着 ， 公司这个金手铐会永远靠在你手上 ，因为 Meta 也很忙嘛 ， 你如果真的在公司干着 ， 你也不可能说真的不管公司里的事 。 而且我手上的活当时很多都是 report 给整个 head of monetization 啊 ， 然后甚至于之前有 report 写给 CTO 的那种 ， 所以这种活你也不能不干吧 ， 这种活一旦要干就要花很多时间 ， 你也不能给这些大佬们留下坏的印象 ，以后在这个圈子里面还得混呢 ， 对吧 ？ 所以你要走的话就干脆一点就走了 ， 然后可能就给别人一个明确的 signal，而不是说一直拖着 ， 拖着反而对自己的 reputation 也不好 。 **曼祺** [1:33:50] 对 ，其实我觉得这是一个更好的状态 ， 只不过你自己就是承担更多的风险嘛 。 **朱哲清** [1:33:54] That's okay。 **曼祺** [1:33:55] 好的好的 ， 那今天非常感谢 Bill 做客晚点聊 ， 跟我们分享了他从本科时代就开始研究 AI 的规划 ， 然后到后面做强化学习 ， 一直在这个方向从冷门到热门见证了这个转变 ， 然后现在他开始创业 ， 从去年 10 月份的一个项目到现在不到半年做 RL 的 Agent。 我觉得这是一个非常新颖的方式 ， 或者说比较特别的方式来实现现在大家都很关注的 Agent 领域的创新 。 那今天非常感谢 Bill。 嗯 ， 好 ， 拜拜 。 本期节目就到这里 ， 感谢收听 。 如果你对今天聊的话题有观察 、 好奇或疑问 ， 欢迎在评论区分享想法 ， 这也会成为我们节目的一部分 ， 让整个讨论更加完整 。 你也可以把我们的节目分享给对这个话题感兴趣的朋友们 ， 欢迎推荐更多你想听的主题和嘉宾 。 你可以从小宇宙 、 苹果 Podcast 等渠道关注晚点聊 LateTalk，也欢迎关注我们的公众号晚点 late post。 我们下期再见 。 --- 本节目库由 PodHood（https://podhood.com）提供支持——播客网站平台。