Thank you.欢迎收听本期晚点聊，我是晚点的作者孙海宁，今天很开心能和曼琪一起录制本期节目。几乎所有主流 AI Agent 的产品都把大语言模型或者它的多模态升级版当做决策中枢，在用户使用界面下是一个或几个大语言模型位居中心，编排工作、调用工具。但也有不同的路，我们今天的嘉宾 Poke 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 是指大模。行的上下文长度，这些注释也能在本期的 show notes 中看到。下面我们就正式开启本期节目吧。
孙海宁
那先请哲清（Bill）为听众简单介绍一下自己的经历，可以吗？
朱哲清（Bill）
我先讲讲自己过去7年的经历。我2014年来到美国，在 Duke 完成了计算机科学本科，之后立刻加入了 Meta。在 Meta 的前3年多，我负责 B2B 推荐系统业务。当时我们从零开始搭建了一整套 B2B 推荐系统，包括商业增长和广告增长等业务。当时也正好是基于深度学习的推荐系统刚刚开始发展的阶段，我们带着团队把整套推荐系统做了出来。
后面的3年多，我转到了 AI 方向，负责 Applied Reinforcement Learning，也就是应用强化学习团队。主要工作是把强化学习落地到 Meta 内部的各条产品线上，包括广告、推荐系统、Reels 短视频和数据基础设施等产品。
与此同时，我们也开源了 Meta 的一个核心强化学习框架，叫 Pro。这也是我们落地所有产品的核心机制。发布之后反响很大，大家都觉得这个方向以及它的模块化做得特别好。我们当时也发表了一些论文，所以在强化学习真正火起来之前，我们在这个方向上已经做出了很大的 impact。
粗略估算下来，每年将近有5亿美元的收入是由强化学习算法带来的，尤其是在广告业务上。在推荐系统和短视频这边，强化学习也有很大的业务贡献。所以在强化学习被 DeepSeek 带火之前，已经有很大的 impact 来自强化学习。
在 Meta 工作的同时，我也在 Stanford 读强化学习方向的博士，这两件事是并行进行的。
程曼祺 Manqi Cheng
像你这样一边在 Meta 全职工作，一边读博士，在同学和同事之间常见吗？
朱哲清（Bill）
应该是不存在的。
程曼祺 Manqi Cheng
那你当时是怎么达成这种安排的？你怎么说服公司、学校和导师接受这样的状态？
朱哲清（Bill）
这件事比较机缘巧合，可遇不可求。我所知道的，伯克利好像有一个学生是这样的。纽约大学的 Perplexity CTO 也做过类似的事情，不过他在公司不算完全全职，而且他的工作和 PhD 强相关，因为他的导师就是公司的老板，所以他基本上是在做和博士研究相关的事情。
我和公司的老板、自己的 PhD 导师之间，有很多 alignment。大家需要确认这个方向是不是都感兴趣、是不是都希望把它落地，公司是否同意，学校是否觉得可行，满足这些条件以后才能做。
但是工作量非常大，一个星期大概有110个小时，基本上除了睡觉以外都在做 research。
孙海宁
所以你这5年选择了一个 hard mode，对吧？
朱哲清（Bill）
对，而且实际上是6年多。这段时间的工作量可能和创业没什么太大区别，甚至比创业还要艰辛一点。创业至少还可以 delegate 给别人，但博士早期的很多工作没有任何人可以 delegate，只能自己做。公司这边，在我成为 TL 和 manager 之前，很多事情也不能 delegate 给任何人，也得自己完成。
所以有很多事情只能自己苦干，没有什么巧劲可以使。创业至少还有一点巧劲可以使，花钱雇个人就能把一些事情做了。
程曼祺 Manqi Cheng
那你觉得这个过程给你带来了什么？毕竟这是一个比较特殊的经历。
1. 时间管理决定取舍
朱哲清（Bill）
我觉得一个很重要的收获是时间管理，这和我们现在创业的想法很相关。我经常想，如果当年有很多莫名其妙的事情可以由 AI 帮我完成，我应该能省下很多时间。
时间管理的核心，是要知道自己的 priority 是什么，什么时候应该放弃一些东西，什么事情值得花时间做。这是一个非常重要的 career lesson。很多时候，有些事情花20%的精力做到80分就可以了，不需要花100%的精力做到100分。有些事情非常关键，就需要花100%的精力做到100分。还有些事情可有可无，甚至可以用0%的精力，直接把它抛弃掉。
怎么取舍非常重要。如果每件事都想做好，我可能根本读不下来这个 PhD。
2. 强化学习值得坚持
第二件事，是要找准方向。我在 PhD 期间走过很多弯路，因为强化学习落地在当时并不是一个很热门的话题，很多人也不看好这个方向。甚至在我加入 Meta 的强化学习组之前，我们的 director 一度想把这个组关掉。
我看到这个组要被关掉，原来带这个组的老板也离开以后，就去找 director，说你不要关这个组，我来带。这个组原来有20多个人，最后只剩下3个人。后来我接手以后，又把团队带回到了十几个人，完成了一次 turnaround。
中间有很多弯路，但找到方向以后要坚持下去。不断换方向的沉没成本很高。
孙海宁
你中间有试过想换方向吗？
朱哲清（Bill）
我没有试过，也从来没有想过换方向。从一开始，我的核心目标就是让强化学习落地，这条路已经走了快10年。
孙海宁
那你说的弯路具体是指什么？
朱哲清（Bill）
会遇到很多诱惑。比如当时有人找我做早期的 language model 和 chatbot，也有人找我做 3D vision model，还有人找我做 safety model。这些事情我最后都只做了一小段时间就停下来了，因为我觉得它们和自己的核心路径没有太大关系。
你要知道什么时候把一件事情 cut off，不能让沉没成本无限增加。
孙海宁
现在回头看，大语言模型已经是显学，是很多人都在做的方向。当时有人找你做早期的大语言模型和 chatbot，你不觉得那是一个好机会吗？
朱哲清（Bill）
人不能这样回头看。如果我当时做了，然后成为第一个做出 InstructGPT 的人，我当然会觉得那可能是一条比现在更好的路径。但你永远不能这样假设。
当时我并不了解语言模型，最了解的还是强化学习这条路。所以我选择把这条路做好、做精，真正落地，在业界建立 reputation，做出一些大家熟知的工作。我觉得这更重要。
程曼祺 Manqi Cheng
学术研究有一点很有意思，就是怎么选择方向。每个方向都会经历起起落落，你怎么在这个过程中一直往下走？你之前也和图灵奖得主、强化学习之父 Rich Sutton 有很多交流，他应该给过你很多启发。
朱哲清（Bill）
Rich Sutton 早年其实非常不顺利。他有将近4年的时间，整个 research 都处于无人问津的状态。你很难想象，一个今天的图灵奖得主，当年没有人理他的 research，连续4年甚至没有一个教职愿意招他。
当时没有人认为强化学习是 useful 的。到了今天，所有人都觉得强化学习是 must-have。这个过程的转变非常 inspiring。
Hinton 早年也遇到过类似的情况。他早期推动 deep neural network 的时候，所有人都觉得这是一派胡言，没有人认为它有未来。
所以我最大的 inspiration 是，如果你自己的思维框架认为某个方向是正确的，就可能需要坚持下去。有时候你会觉得很多人都可以做同样的事情，而且做得很好，你可能没有优势。但别人可能没有坚持下来，而你坚持做这个方向，最后可能还是会成功。
很多时候可能还是要轴一点。如果你非常坚信一件事情，至少要把它走通，或者真正证明别人已经做出来、你没有办法 take over 了，才能说：“OK，what’s my next step?”
在这个过程中不断 question 自己，可能只会带来过多 noise，阻碍自己的发展。
孙海宁
所以 Bill，你刚开始研究强化学习的时候，强化学习已经是一门显学了吗？可以给听众讲讲你读书时学界对强化学习态度的变化吗？
3. 强化学习走向真实落地
朱哲清（Bill）
最早的时候，我是跟 Ron Parr 做强化学习，主要做 planning，也就是规划方面的 research。
当时 Deep RL 还没有那么火。Deep RL 是在2016年因为 AlphaGo、AlphaGo Zero 和 AlphaZero 这一系列成果而变火的。从 AlphaGo 到 AlphaGo Zero，再到 AlphaZero，这几个迭代其实花了很长时间。当时 Deep RL 还没有完全形成共识，仍然处于发酵过程中。
所以我当时还是比较 fundamental 地学习了 planning 的整个 landscape，研究当时的规划能力在做什么。那一部分研究和 Tree Search 更相关，尤其是 Monte Carlo Tree Search。
到了 Stanford 以后，我发现 Deep RL 已经形成气候。从某种意义上说，Monte Carlo Tree Search 这一套 planning 能力，在新的 Deep RL 时代没有那么重要了。当然，后来又证明它仍然是很重要的能力。
之后我去找 Benjamin Van Roy 读 RL 的 PhD。Benjamin Van Roy 做的东西和 Ron Parr 没有太大关系，但他们是很好的朋友，所以当时是 Ron 推荐我去 Ben 那里读 PhD。
在 Ben 那里读博士时，我更多研究的是 sample efficiency。当时主要研究如何实现 reverse scaling law，把最初非常高的数据需求不断降下来，降到一个完全 tractable 的状态，让强化学习算法真正能够落地。
强化学习的核心痛点，是所需要的交互数据量非常大。因为你规划的不是一个单步动作，而是一个非常多步的过程。它所需要的数据量，和整个规划的 steps 数量，以及 action 和 state 的数量都正相关。问题越复杂，所需要的数据量就会不断上升。
所以，如何从 linear scaling 变成 square-root scaling，就变得非常重要。
比如你有1万个工具，每个工具需要100个数据点才能学会，那么学会1万个工具就需要100万个数据点。第一步是能不能泛化，从一个工具泛化到另一个工具，把1万个工具减少到5000个，甚至1000个。
进一步，你能不能把泛化后的数据量从和工具数量成正比，变成和工具数量的平方根成正比。也就是说，对1000个或者1万个 action 的理解，所需要的数据量不再和工具数量线性相关，而是和工具数量的平方根相关。
这件事的关键，是如何有效探索。每次使用一个工具，都要有的放矢。如果已经知道某个工具对当前任务肯定不好用，就不要再用它了。更 intelligent 的 exploration，会大幅压缩所需的数据量。
这不仅适用于工具，也适用于步骤。步骤越长，探索就越重要。比如有两条路径非常接近，其中一条已经被证明不可行，那么另一条路径如果和它性质相近，是不是就不需要再探索了？这样就能省掉探索一条路径的成本。
我们要做的，就是从现有数据、现有知识，以及解决问题时积累的 knowledge 中进行 distill，判断哪些东西已经探索过，哪些没有价值再探索，哪些值得探索。只探索能够解决未知的问题，放弃重复性劳动，让训练所需的数据总量大幅缩减。
在达到同样结果的情况下，所需要的数据可能只要原来的十分之一，甚至百分之一。
孙海宁
这就是你本科到博士期间主要研究的方向？
朱哲清（Bill）
对，博士阶段主要做这件事情，同时想办法把技术落地到实际环境中。
强化学习很长一段时间都被大家诟病，很多人觉得强化学习社区只是在内部自嗨，是研究员自己和自己玩的东西。但最近几年大家也看到了，强化学习确实开始 take off。
我们当时的核心目标，就是找到最 robust 的落地方式，真正找到一条能落地的路径。所以无论是在 Meta 还是读博士时，主要关注的都是这一点。
4. RL 走向 Agent 创业
在这个过程中，我发现强化学习的 potential 远不止于帮助 Meta 的广告业务提升1%或2%的 revenue。它更大的驱动力，可能是新一轮 AI agent 或 AI 技术的井喷。我们都说强化学习是 superintelligence 的核心驱动力，所以从我的角度来说，它的 impact 肯定不止于公司内部这一亩三分地。
当时我和朋友、投资人以及自己的导师都简单聊过这个想法。我一直在思考，既然强化学习能够帮助 AI 获得很强的推理和规划能力，那能不能以强化学习为核心，在不依赖语言模型的情况下，做出一个具有强规划、推理和工具调用能力的 agent？
我和导师、投资人聊完以后，大家都觉得这个 idea 很 exciting。当时是去年9月或10月，Agent 还没有火，RL 也没有火。很多 VC 甚至无法理解 RL 和 Agent 是什么，只有少数 VC 能够理解这里面可能有 potential。
但学界和业界的人听到这个想法以后，普遍觉得非常 promising。甚至我在10月份离开以后，还没有透露融资情况，就有很多人直接 reach out，问能不能加入这家公司。
所以我觉得这个大方向非常有潜力。总体来说，创业的驱动力就在于，在 DeepSeek 火起来之前，我们已经看到了 RL 在业界落地，以及 Agent 方向的巨大潜力。
程曼祺 Manqi Cheng
为什么你觉得 RL 是被 DeepSeek 带火的，而不是被 o1 带火的？
朱哲清（Bill）
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 后，得到的结果可以立刻由一个接近 ground truth 的 reward 来验证，然后继续训练 agent。
它还没有完全达到 AlphaZero 的状态，因为还没有进入 self-play 阶段，但已经可以在没有外界干预的情况下，训练出超过现有最好模型的模型。
当然，它也有自己的问题。比如 DeepSeek-R1-Zero 主要依靠 robust、rule-based 的 reward model。这个模型从某种意义上说是人类不可读的，很多时候输出的内容是 gibberish。它可能在 rule-based 系统中的分数一直上升，但把 output 拿给人看，人可能根本读不懂它在说什么。
所以后来它又包了一层 RLHF。之所以还没有完全达到 AlphaZero 的状态，是因为它还需要大量 human heuristics，也就是人类经验，帮助它找到一个人类更喜欢的状态。当然，这个类比并不是百分之百准确。
程曼祺 Manqi Cheng
可以给听众简单解释一下，以 RL 作为 Agent 的核心，大概是什么概念？也可以对比一下大家比较熟悉的 Agent，比如 Deep Research 或者最近讨论比较多的 Manus，它们可能是以什么为核心的？
5. Agent 不只是语言模型
朱哲清（Bill）
这首先涉及 Agent 的本质是什么。大家把很多不同的东西都称为 Agent。
从我的概念来说，我们设想的 RL Agent，是以 RL 为核心，驱动所有决策的 Agent。它不再只是输出一段文字，然后在文字中嵌套一部分工具调用，而是把 planning、reasoning 和工具调用的过程抽象出来。
它可能先形成一个 concept，再形成下一个 concept，并完成规划。在规划完成后，其中一部分可能是工具调用，另一部分可能是 information retrieval。它的整体构想方式和现有 Agent 很不一样，这也是为什么 Agent 的核心模型都不是语言模型。
孙海宁
那从用户角度应该怎么定义？大多数人其实并不在意底层是怎么实现的。
朱哲清（Bill）
从用户层面，我认为很重要的一点是，无论 Deep Research 还是 Manus，它们仍然主要是 surf the internet，也就是浏览互联网。它们没有写入互联网的能力。
比如你有 Facebook 账户或者微信账户，你想要的结果不只是让 Agent 从某个人的 Facebook 主页或某个网页上抓取信息、总结一下，或者写入一个网页。你可能希望它直接在 Facebook 上发一条帖子，在 LinkedIn 上发布招聘信息，或者去 Amazon 抓取产品 review，再把它发布到某个地方，比如你自己的 Shopify 网站。
这些都是写入互联网的 action，而目前大多数 Agent 都不具备这种能力。
程曼祺 Manqi Cheng
这和语言模型是矛盾的吗？如果我给它多一个 function，好像它也可以完成写入功能。
朱哲清（Bill）
你可以试一下。一般来说，如果要横跨互联网的大多数工具，可能会有上千甚至几千个工具。最好的 language model 在使用100个、甚至50个工具时，就开始 hallucinate，也就是产生幻觉。
因为它的 context length 和 attention 都是有限的。比如有50个工具，每个工具用1000个 token 描述，光工具描述就有5万个 token。除此之外，还有上下文、agent memory，以及用户给的 prompt，所有东西都要放进给语言模型的 prompt 里，让它选择并调用工具，这非常困难。
更不用说我们做的不是单一工具调用，而是10步、十几步的工具调用。你完成第1步以后，要把已经得到的结果放回 prompt。比如你拉出一篇文章，这篇文章本身可能有1万个 token，再放回 prompt，然后执行下一步。
如果连续执行十几步，就可能是上百万个 token 的一次任务。所有 LLM 都会产生幻觉。
所以我不用语言模型作为核心决策点，一个核心原因就是想规避这个问题。
孙海宁
OpenAI Operator 在功能上也希望写入互联网，对不对？它希望完成一些操作。
朱哲清（Bill）
对，但 Operator 目前的成功率非常低，还不是很好用。
它在执行层面可能比 Manus 强一点。Manus 的写入能力没有 Operator 强，但 Manus 的 Deep Research 和信息整合能力更强。Manus 可以基于大量搜索和 fetch information，生成网页和内容，最后产出的内容相对更好。
Operator 的执行能力比 Manus 强一些，让它做比较基础的操作是可以的，但它没有 Deep Research 功能。Manus 等于把两个功能嵌套在一起：一部分执行和检索功能由网页完成，另一部分信息抓取由网页和现成工具完成，再和 Deep Research 工具组合起来。
所以 Manus 是一个非常好的工程产品。但我们想解决的是一个更长期的问题：如果互联网最终不再是今天的互联网，不再有用户前端，该怎么解决？
人与互联网的交互不再由一个漂亮的前端完成，而是直接对一个 Agent 接口说：“我要做这几件事，请你帮我完成。”如何在没有前端的情况下帮助用户完成任务，同时让用户理解 Agent 做了什么，并且让 Agent 和人类能够高效交互，这是我们想解决的问题。
从第一性原理来说，如果 Agent 可以代替人类完成所有操作型的事情，UI 的存在就没有那么重要。今天的 UI 是帮助人类理解信息和信息流的，而 Agent 只需要理解 raw 的文字和图片，不需要一个 fancy 的前端。前端里的大量 JavaScript 对 Agent 来说可能只会造成混淆。
程曼祺 Manqi Cheng
也就是说，面对未来你刚才说的那个终局环境，RL 可能是一个长期更有潜力的方向？
朱哲清（Bill）
我需要先 step back。RL 是一个通用工具，在任何环境下都有自己的优势。LM 本身是帮助你理解文字并进行操作的，但文字长度有自己的限制，也就是 context length。它的 attention 机制和模型大小也存在正相关。
当信息量无限大，而且有大量 memory 存储时，就需要在一个相对抽象的环境中做决策。我们希望通过 RL 把整个决策层抽象出来，由单一的 RL 模型完成工具规划和调用，而语言层只负责理解和交互。
长期来看，LM 可能会成为一种 UI，或者说互联网的 frontend。互联网 backend 中所有工具的交互和连接，则由某种 protocol 加上某种决策机制完成。
比如你告诉 Agent：“我今天早上想去买菜。”它把这个语义理解之后，传给 RL 模型。RL 模型判断出用户想做的是买菜，并且想在某个服务提供商那里购买。然后它通过某种机制，把信息传给对方的 Agent，可能是 B 端 Agent。
B 端 Agent 收到信息后，从自己的数据库中提取出：如果用户想在这里买这些菜，应该去哪里购买。然后它抓取这些信息，再向线下某个人发出 request。这个人收到 request 后，把东西送到用户家里。
这个过程中不一定需要使用文字信息传输，完全可以通过数据库操作和后端信息流动来完成。最后返回给用户的，可能是偏文字的信息，再转化成：“我已经帮你叫了人，把菜送到了这个地点，你可以去取了。”
所以我们长期比较相信，未来后端的所有东西都会相对黑盒化，而不是全部以文字形式输出。
孙海宁
你的意思是，大语言模型更像一个翻译器，或者人和机器之间的交互界面，而 RL 更像一个规划器？
朱哲清（Bill）
可以这么理解，但需要解释一点：RL 和语言模型本身并不冲突。你可以用 RL 训练语言模型，也可以用 RL 训练一个非语言模型，去解决更抽象环境中的任务。
就像你可以用 RL 做机器人。或者把 domain 中的规划过程变成 RL 的一个决策 policy。这个过程中它不一定是语言模型，RL 是一个通用工具，在规划和推理方面很强，可以用来完成各种抽象规划和决策。
所以我们决定让前端仍然由 LM 完成，但后端完全不用 LM。
孙海宁
刚才提到，LM 没有办法承载太多工具，比如超过50个就可能记不清或者产生幻觉。这个问题可以解决吗？还是长期来看也解决不了？
朱哲清（Bill）
如果你有无限的计算量，并且永远可以 scale 模型大小，eventually 当然可以解决。Attention 的复杂度基本上和模型大小成正比，需要关注的点的数量也可以和模型大小同比例 scale。
如果假设有无限的计算资源和无限 scaling，确实可以做到。但前提是我们没有无限资源。不能假设未来永远可以不断投入计算资源，去完成越来越复杂的任务。
未来的复杂任务可能变得更抽象，工具数量也可能以几何级数增长，而 LLM 只能相对线性地增长 context length，所以不可能永无止境地把全世界所有工具都包进来。
你可以想象，未来所有常用工具和垂直领域工具都被集成进一个系统。那就不再是一个线性扩展的问题，而是一个信息爆炸式的工具使用问题。
程曼祺 Manqi Cheng
刚才的假设是工具无限多。有没有另一种场景：LM 不需要掌握50个、100个工具，而是掌握10个能够制造工具的工具？比如它非常擅长写 Python，就可以自己制造工具。
朱哲清（Bill）
这是个很好的问题。一个简单的 counterargument 是，你可以想象它能够写 Python，也能把 common-sense tool 写得很好。但如果让它写一个工具，直接帮你安排 Zoom 会议，或者安排腾讯会议，它根本没有见过腾讯会议的 documentation，怎么可能把这个任务做好？
除非使用 browser，而 browser 又回到了原来的问题：过程会变得非常复杂，token 数量非常高，操作速度还比人慢。那为什么要用 browser？
如果让它自己写代码完成任务，它没有见过 documentation，又怎么能把代码写好？这等于要重新训练一遍 language model，只为了调用一些新的工具。
所以问题是：如何在让语言模型作为基座、作为用户交流媒介的情况下，不重新训练它，就能让它自主调用已有工具，甚至让它的工具数量扩展到成千上万个。这可能是我们的目标。
孙海宁
接下来请 Bill 给听众讲讲 Poke AI 具体的 Agent 产品。我最近试了一下，感觉它的交互界面和其他 Agent 差不多：屏幕分成两半，左边是和 Agent 交互的聊天界面，右边呈现 Agent 执行任务的结果。Poke AI 和人类交互的方式，在设计上有什么不一样吗？
6. Poke 让执行保持可控
朱哲清（Bill）
我们的目标，是用非常简单的方式让用户知道哪些任务已经完成，哪些任务没有完成。
有一个比较不一样的地方，是我们会在执行之前询问用户：整个任务的规划和完成方式是否符合预期，用户是否满意，然后再执行。
目前大多数 Agent 的体验方式，都是类似 free-flow 的体验。用户不知道 Agent 每一步会做什么，它会自己一步一步 roll out，打开各种 function 或 call，执行各种生成式任务。
因为我们的任务会直接写入用户的互联网账户，以及生活和工作中的各种平台，所以我们希望执行规划是用户满意的，因此增加了一步用户 approval。
另外，在整个流程中，如果是 step-by-step execution，除了搜索以外，很多步骤都会让用户点击是否同意执行。用户可以看到这一步的 input，如果不满意，还可以手动修改。这样用户对整个产品 flow 有更多控制，而不是点一下按钮以后就无事可做。
如果它卡在那里半个多小时，最后告诉你做不到，用户会觉得时间完全被浪费了，所以我们才有这个设计。
还有一个很重要的点，是我们收到过非常两极分化的反馈。偏 business 的用户会觉得，如果没有同意按钮，Agent 自己在 Facebook、Instagram 和 LinkedIn 账户里执行，他们会非常没有安全感。
但开发者、AI 发烧友和 researcher 会觉得，为什么要让他们点击同意？直接全部执行、越快越好就行。
所以在用户体验上有两种非常不同的需求，我们支持两种模式。
程曼祺 Manqi Cheng
你刚才提到，一开始会把执行流程给用户看，让用户决定这个流程是否合理。这个功能常见吗？Manus 也会做类似的事情。
朱哲清（Bill）
如果用 Operator，很多时候它不会给你。Anthropic 的产品也不会给你。Manus 会把流程展示出来，但看完以后就自己执行了，用户不能真正修改执行流程。
它应该有一个 doc writer，由一个 LLM 写一些 bullet points，放进一个 txt file。执行过程中它会让你看一眼，但你不能暂停，进入那个 txt file，把内容全部删掉、重新改一遍，再让它基于修改后的内容执行。我记得它不支持这种操作。
孙海宁
我自己用的时候，发现一个比较显著的区别：Poke 没有一个虚拟机页面，展示机器具体在做什么，比如有没有打开网页、有没有在写文档。为什么不加这样一个页面？
朱哲清（Bill）
首先，我们大多数任务都不是 browser-based。尤其是写入互联网账户的任务，通常是通过那些公司的官方接口完成的。我们使用的是官方 access，不一定能称为官方合作。
这些内部信息和公司的 privacy、公司章程有关。我们不能一直不停地 ping 对方的 status，再把 status 告诉用户，这可能不太合适。
后面在一些 Deep Research 任务中，我们不会给用户虚拟机，但会告诉用户每一步在做什么，这个功能会做到。
程曼祺 Manqi Cheng
在交互页面之下，Poke 完成任务的方式和其他 Agent 产品有哪些差异？
7. Poke 打通平台接口
朱哲清（Bill）
最大的差异一定在执行侧，也就是和几十个互联网大公司、大平台的接口，以及这些平台接口背后数千个、目前可能一千多个 API 的打通。这是目前市面上没有任何人做到的事情。
一个核心难点是，每个互联网大平台背后的接口都非常相似，很多 API 几乎长得一样。如何让 Agent 区分这些接口，并且完全使用这上千个接口，是目前市面上没有解决的问题。
第二，我们尽可能避免依赖网页端。很多事情确实不得不通过网页完成，也有一些任务必须 search，但除此以外，如果能用代码解决，我们就写代码；如果能用接口解决，就用接口。
未来我们也会接入 MCP 和 Agent-to-Agent。如果现有的 MCP 和 Agent-to-Agent 能接进来，我们也会使用。但我们一定会避免用 browser 解决问题，因为 browser 在我们看来不是未来。
如果未来世界都是 Agent-to-Agent，browser 只会是一个中间态，所以我们尽可能避免这种形态。
孙海宁
为什么要把接入各个平台的 API 作为核心卖点？它对应 Poke AI 核心用户的什么需求？
8. Poke 瞄准专业工作流
朱哲清（Bill）
Poke AI 的核心用户一定是开发者和 professionals。它可以被理解成一个面向 B 端场景、但同时具有 B2C 和 B2B 属性的产品。
用户场景一定是工作流中的任务自动化。使用者可能是某家公司的个人开发者，也可能是社交媒体平台的市场营销人员、广告平台的投放员、公司的法务或财务人员。他们做的是 B 端的事情，但使用者可能是一个 C 端用户。
在此基础上，我们未来会更多进入 enterprise，和一些公司内部的 infrastructure 打通。
这里有很多问题。大多数公司，尤其是大公司，以及对数据敏感的公司，没有和 OpenAI 或 Anthropic 打通，核心原因就是 privacy。你能不能提供 private cloud，模型是否足够小，是否足够 scalable，都是非常重要的问题。
我们之后也会在这个方向投入，但目前主要受众还是个人开发者和 professionals。
程曼祺 Manqi Cheng
很多 Agent 产品的目标受众是最广泛的消费者，而 Poke 的定位是专业消费者。这个定位是怎么找到的？
朱哲清（Bill）
最早有这个想法时，我和几位认识的广告、社交媒体营销从业者沟通过。他们听到以后觉得不可思议，因为他们现在最大的痛点已经不是生成内容，生成内容变得很容易了。
他们的问题是，即便内容生成出来了，仍然要花3、4个小时，在不同平台上进行传播和推广。更麻烦的是，如果你是社交媒体运营人员，一条帖子发出去以后可能有几十个回复，难道要手动一个个点击、一个个回复吗？
现在用 Poke，你可以直接说：“找到这条帖子，把下面所有回复用个性化的方式逐一回复。”它就能帮你完成，节省大量时间。
孙海宁
那为什么之后拓展的方向是企业用户，而不是更广泛、更普通的消费者？
朱哲清（Bill）
消费者要看情况。但我们目前对非常 general 的纯通用 Agent 的看法是，用户很可能会被它能做的事情 overwhelm，进而执行一些和它能力范围不匹配的事情。
比如 Operator 这样的 To C 产品，我和身边朋友的第一反应，不是让它搜索内容，而是真正执行任务，帮我安排会议、发邮件之类的。但试过以后发现一个都做不到，成功率接近0。
我拿到 Manus 邀请码以后也做过类似的事情，比如让它在 Facebook 发帖，成功率也接近0。做简单搜索、收集内容、生成代码，它当然没问题，但在执行侧，目前没有人能像我们一样做得深入。
我们的目标人群更多是：工作流在哪里？现在我们有个人开发者和 prosumer 用户，他们有大量复杂的工作流，但真正的工作流还是在企业内部。企业内部可能有几十步、上百步的工作流需要解决。
我们要解决的是，未来这100步工作流能不能直接被 Agent 取代。需要人的地方，就让 Agent 主动找人完成，而不是让人做半天，然后每一步再找一个 LLM 去解决内容生成问题。这是我们最终想走的方向。
孙海宁
进入大公司的工作流，取代几百步的自动化流程，你觉得 Poke 和已经提供类似服务的 Salesforce 是竞争关系吗？
朱哲清（Bill）
我觉得不会。大公司的工作流足够复杂。当然，我不觉得 Salesforce 的 Agent 做得很好，很多人都跟我吐槽过。
主要问题是，拖拽式工作流的 Agent 不可避免地具有 rigidness。工作流稍微变化一点，它就不行了。
所以我倾向于把 Agent、工具、拖拽式工作流工具和 LLM AI 工具都看作同一种东西：它们都只是工具。真正需要的是一个更上层、能够更好规划，并且可以无限调用工具的功能。这可能是我们最终的使命。
程曼祺 Manqi Cheng
拖拽式工作流相当于人工编排一个流程，让 Agent 严丝合缝地执行。大公司的工作流可能更加僵硬、固定，变化也比较少。那当一个能够自己生成工作流的 Agent 出现以后，大公司真的会有这样的需求吗？
朱哲清（Bill）
这是为什么我们会从小的 consumer 和 developer 往上走。
改变大公司的工作流方式非常难，但我观察到，很多大公司的工作流其实是大家希望它改变，而不是认为按部就班就很好。
所以需要 bottom-up 的 influence。原来20、30步的工作流，可能只需要7、8步就能完成，真正的工作流里有很多内容和步骤其实是多余的。
如果有一个 AI 自动生成工作流的模型，能够完成工作流对应工具的调用，也能完成向人派遣任务的事情，那么 eventually，当和我们共同成长的小公司和个人开发者成长起来以后，他们就会去 influence 更大的公司。
这些公司会看到：“他们已经做得这么高效，而且效果这么好。”然后大公司也会想办法 adopt 你的 solution。
这个 sales cycle 非常难，因为没有人希望主动打破原有边界。所以我们可能会先 focus on 中小型公司、个人开发者和消费者，再慢慢 influence enterprise。
孙海宁
这可能需要一定的 trust。用户认识你，知道 Agent 的能力边界，才会愿意 deploy。但你们现在已经看到一些比较好的 sign 了？
朱哲清（Bill）
对。我们湾区的一些朋友，把 Agent demo 和简单尝试的用例发给他们的老板以后，老板其实很想买我们的产品。可见在执行侧，大家确实有这个需求。
另一个比较有意思的点是，Poke 如果有一个子任务没有完成，也不妨碍它继续执行后面的任务。
因为整个规划和执行是由 RL 生成的，它会知道某个 action 之前的 context。RL Agent 可能判断出，这个 action 和之前的 context 没有关系，就会跳过某些内容，完成下一步。
我们的想法是尽可能完成整个任务，能完成多少就完成多少。之后用户可以继续交互，说：“这几步没有完成，请根据现有信息再完成一次。”
我们的目标不是让用户被卡住，而是尽可能把能完成的事情完成好。
程曼祺 Manqi Cheng
如果 Poke 的整体任务失败了，它可以继续自己 debug、重新尝试吗？我自己试的时候，好像还没有这个功能。
朱哲清（Bill）
现在还没有打开，因为我还在测试。这个问题和之前很类似：我们希望它能够非常稳定地 debug。
如果它 debug 完以后自动执行，可能会把用户的 input 改掉。比如你想发布一篇文章，它 debug 时发现文章内部有问题，就直接改完以后发出去了，这不一定是你想要的体验。
我有一个很典型的问题。LinkedIn 如果你连续发布两篇一模一样的文章，会把你 block。即便使用官方接口，也会有这个问题。
如果一个足够聪明、足够狡猾的 Agent，比如 Poke，发现这个问题以后，可能会直接绕过去，说：“我把你的内容稍微改一改，再发出去。”但这不一定是用户想要的体验。
所以我们要找到不同 case：有些问题可以绕过，有些问题应该直接 fail，然后告诉用户。LinkedIn 这个 case，用户可能确实希望 Agent smart 一点，把它绕过去；但有些 case 就不希望它绕过。
孙海宁
我自己试的时候发现，Poke 完成任务的速度非常快，大概1分钟就能完成一项任务。这是怎么做到的？
朱哲清（Bill）
你看我们的 demo 视频，不管是社交媒体账号运营、会议安排，还是之前做的分析，所有内容都没有加速，都是原始速度。其中包括所有 approval，来回点击加起来可能是60秒。如果不要 approval，让它自己执行，可能十几到20秒就能完成。
具体做法不能细讲。我们的做法不是 Browser Use，虽然也有 browser 的部分，但很多 action-taking 的地方和很多公司进行了合作与集成，所以执行速度得到了极大压缩。
之后你们可能会看到一个对比图：和基于 Browser Use 的 Agent 相比，我们的速度和准确率都有大幅提升。大多数任务场景下我们都可以 autonomous，但特别 niche 的场景它们也做不好，所以我们也不做，并且会告诉用户应该怎么做。
和 MCP、Agent SDK 这类竞品相比，我们能覆盖的产品、工具和平台列表远高于它们。和这两类竞争者相比，我们都有很大的优势。
孙海宁
所以你们调用工具时不是用 MCP 协议，或者只用了一部分？
朱哲清（Bill）
我们目前完全没有使用 MCP，但之后会支持。既然很多人已经建立了 MCP，why not？
不过我们之后会有一个更简单的协议。你只要给我们一个 JSON file，告诉我们 input、output 和 endpoint。不管是 API 还是工具，只要把 endpoint 告诉我们，我们就可以直接调用，也不需要 host。
孙海宁
那你们现在能调用这么多工具，相当于是在你们想使用的软件和工具上，自己加了一层你刚才说的更简单的协议？
朱哲清（Bill）
对，但不只是普通 API 或 browser，还有很多其他类型的工具。所以不能笼统地说工具都是怎么生成的，因为不同工具以不同形态存在。
程曼祺 Manqi Cheng
听起来这还是一个很重人力的过程。MCP 当初提出的想法，是让所有人群策群力：你做好一个工具，别人就不用再发明一次。你怎么看？
朱哲清（Bill）
目前我们还没有遇到这个问题，后面肯定会遇到，我们也会做开发者社群。
我们预计第一轮 release 大概有1000个工具，也就是1000个可以调用的子工具，可能涉及几十个平台，子工具加起来上千个。
我们会做开发者社群，让大家的 SaaS 软件和工具能够很容易被使用。开发者只需要告诉我们工具是什么样的，甚至不需要提供上下文，只要告诉我们 input、output，以及 endpoint 怎么调用，就可以结束。我们会把工具直接吸纳进整个 ecosystem。
孙海宁
所以你们这个属于 MCP 的竞品吗？
朱哲清（Bill）
我们也会用 MCP，所以不算竞品。如果有人希望更简单，不需要安装，也不需要写 JavaScript server，就可以使用我们的协议。这样会方便很多。
孙海宁
具备无限扩展的工具调用能力，肯定是很多 Agent 公司都想实现的目标，也很容易看出它的价值。现在主流的实现方式有哪些？除了你们的尝试，市场上还有没有其他比较有潜力的实现方式？
朱哲清（Bill）
大多数还是以 LLM 为核心。目前还不太能看到非 LLM 模型在这个方向上的应用。
有几家公司在做和 contrastive learning 相关的 approach，但我们试用下来效果不是特别好。他们可能更偏传统的、带一定 supervision 的模型，但这种模型在我们目前的试用中效果并不好，因为 negative signal 太高。
比如你有上万个工具，其中只有一个是正确的，那负信号就太强了。随便调用其中任何一个工具，大概率都是错的。这个工具可能被 sample 无数次，也被人工标注无数次，但最后连一个正确答案都找不到，训练难度非常大。
所以需要一个非常 smart 的机制来完成训练，这算是我们的 secret sauce。
程曼祺 Manqi Cheng
从2024年10月你比较明确地决定出来创业，到开始构建 Poke 这个产品，中间你对一个好的 Agent 应该怎么构建、应该具备哪些要素，有没有一个逐步思考的过程？包括你们做了什么，也可以讲讲搭建第一个 Poke 的过程。
9. Poke 从原型走向市场
朱哲清（Bill）
一开始并没有那么清晰地认为这4个点必须全部完成。最清晰的一点是要跨平台，也就是一定要把大量不同工具串起来，完成一个人类任务。
人平时就是这么工作的。所以我们认为，如果 Agent 真要替人干活，一定是跨平台、多工具，完成一个非常复杂的任务。这是我们一开始就有的构想。
价格也是我们融资时强调的一点：我们的模型架构带来了很大的价格优势。但我不会真的因为这个去打广告，因为价格不是一个非常长期的优势。Eventually 总会有人想办法把 computational cost 压下来。
价格低不代表有永久的价格优势或资源优势。我们一直认为核心要素是多工具、多平台、无限 scale 和 easy to use。
剩下两个点，是我们后来逐渐摸索总结出来的。一个是要比人快，另一个是 scale 要非常好。
我们一开始用 Operator 和 computer use 做了很多任务测试。内部测试时，大概60%到70%的任务我们都等不到它完成，就没有耐心继续等了。
很多事情明明很简单，却要等两三个小时才能完成，确实没有必要。所以我们总结下来，人没有那么长的耐心，去等待一个 Agent 完成复杂任务并花费那么长时间。这些都是我们自己试用、摸索以后总结出来的。
团队构建和这些摸索没有太大关系。最初搭建公司时，我还是按照端到端的架构来组建团队，从 fundamental research 到 production engineering，再到产品 experience engineering，每个环节都需要最专业的人。
我们的团队有一位 research scientist，是我之前在 Meta 的下属，做 reinforcement learning research，也是 Rice University 的学生。还有一位 ML engineer，是我过去做 B2B recommender system 时的下属，production 能力非常强。
另外还有一位 product engineering 的 partner，是我多年的朋友，也是之前的 Meta 同事，在 product engineering 方面非常有经验。我们在每个关键环节都有一个经验丰富的人来负责。
现在团队一共只有4名全职员工，很多事情靠 AI 帮忙。我们自己也写了一些 AI tools，很多 scaling 工作都是靠内部工具完成的。另外还有一些 contractor，亚洲这边有一些 contractor 帮忙处理相对杂的事情。
孙海宁
回到产品形态。在现在这个产品形态之前，我和一些早期见过你的投资人聊过，听说你们早期还有一个方向是做旅游路线规划。那是你的一个方向，还是只是一个 demo？
朱哲清（Bill）
只是一个 demo。当时我花了1、2个星期，想向投资人展示：如果用我们的架构去做一个兼具规划能力和工具调用能力的 Agent，它可以有多 powerful。
我们当时用了一个只有几百万参数的模型，实现了一个可以横跨多个城市、调用 Google Maps 的功能，也就是一个垂类 Agent。Google Maps 下面所有工具和 SDK 都可以集成进来。
当时主要是想 showcase：如果要做一个工具调用 Agent，我们的方案可以非常 scalable、非常快速，不需要等着去扒网页。
程曼祺 Manqi Cheng
这个 showcase 主要是在 Google Maps 内部，对吧？还不涉及多平台？
朱哲清（Bill）
当时主要是在 Google 体系内部，包括 Google Maps、Docs 和 Calendar，这其实也算多平台。但从当时的角度来说，它已经是工具调用能力很强的 Agent。
那时候投资人还没有形成“工具调用是未来”的共识。
孙海宁
之后你们做了一个帮 Shopify 商家做推荐和客服的产品，当时是怎么想的？
朱哲清（Bill）
核心想法还是一样。当时通用 Agent 还没有形成共识，大家也不认为它能卖钱，所以都说：“要不先找一个落地点。”
我们当时想，既然 Agent 能力很强，就把 Shopify 下面的所有工具集成进来，不管是 command line、GraphQL、API 还是 SDK，全部集成进来，做一个面向商家和客户的全功能 Agent。
我们花了2个月就做完了。平时如果要把这些逻辑全部捏在一起，可能要花1、2年，但我们用2个月就把背后的逻辑全部完成了。
这相当于一次技术测试，验证能不能通过这种方式，大幅提升开发速度和 robustness。通过这个项目，我们觉得这件事确实有很大前景。
当时我们也想过要不要扩展、销售这个产品。然后 DeepSeek 突然火了，所有人都来找我们，问最开始的 vision 是什么。
于是我决定回到原始 vision，从零开始打通横向平台，把技术做出来。这就是为什么从12月份开始，我们又回到最初的 vision，把最核心的技术铺开做好。
孙海宁
所以从2024年10月到年底，你们做的是一个和电商相关的垂直应用，也考虑过把它落地。后来因为市场环境变化，你回到了原本更想做的事情。
朱哲清（Bill）
核心问题是要卖产品。如果没有人意识到通用 Agent 的核心能力和工具、规划、RL 相关，市场就很难形成共识。
DeepSeek 和 Anthropic 过去做的 effort，让这件事形成了共识，这对我们非常有利。我们没有做任何 marketing effort，流量就自然地向我们聚集，因为有其他公司帮我们完成了市场教育。
所以我们认为时机到了，可以回到原始 vision。
程曼祺 Manqi Cheng
这个流量主要是投资人的流量，还是客户和开发者的流量？
朱哲清（Bill）
都有。投资人、客户，以及很多 developer 的关注，几乎是在12月、1月、2月以几何级数增加。
一开始是非常平的状态，我们自己开发，没人关注。然后突然之间所有人都来找我们。几乎有上百个投资人联系过我们，也有几十个大型客户来找过我们，小的 developer 更是不计其数。
我们发布 demo 当天，一个星期内有800多个 waitlist sign-up。后来3月份上线以后，又有800多人 sign up，而且我们没有做任何推广，甚至没有请朋友帮忙分享。
我们当时觉得，这个流量比想象中大很多。一般 product launch 当天，会请很多朋友帮忙分享，把流量顶起来。但我们发现转化率特别高，浏览量大概只有1万左右，waitlist 的 conversion rate 却有8%到9%。
网上一个帖子到 waitlist 的转化率接近8%到9%，比我们以前在 Meta 见过的任何产品转化率都高。
孙海宁
如果总结一下，从去年10月到现在还不到半年，在这段创业历程里，有哪些重要的里程碑，或者让你比较高兴、比较振奋的时刻？
朱哲清（Bill）
第一件事，是我开始融资时，没有人理解 RL 加 Agent 是什么。
今年 GTC 期间，我参加了一些访谈和 panel，也和很多投资人聊过。有投资人说：“You are like six months ahead of the curve, so no one’s gonna invest in you because it’s too early。”
当时是一个非常 down 的过程。我们原本有一个非常宏大的 vision，后来把它缩小成一个需要落地的事情。现在回头看，我也不觉得这是错误的决定。
如果没有人帮你做市场教育，市场就不会认为工具调用、RL 和 Agent 放在一起，推理、规划和工具调用是核心 Agent 能力。如果大家认为 Agent 只是生成内容，即使你想做这件事，也会遇到很大阻力，因为所有人都不认为你做的是正确的事情。
第二个节点是12月。DeepSeek 出来、RL 突然变火以后，我们一下子得到很多投资人和客户的关注。他们问：“你们是不是具备做通用 Agent 的能力？”
我们说，这确实是 initial plan。之后有很多 brainstorm，也有几个熟悉的投资人告诉我，他们觉得时机开始成熟，可以回到 grand vision 和 platformization。
当时产品已经做完了，所以我们觉得，是时候把那个产品放在那里，该卖就卖，然后回到通用化的状态。
那时整个团队的心路历程是：我们原本非常脚踏实地地做一个产品，现在突然可能出现一条 J-curve，或者说出现了势能。
发现这个机会以后，我们开始思考如何架构 Agent 的 backend 和 infrastructure。到了3月份，我们把最初的 demo 做出来。demo release 以后，发现市场兴趣真的很高。
这件事也非常巧合，因为我们的 release 比 Manus 早两天。我们在3月3日早上发布视频，国内是3月4日看到。两天以后，Manus 就发布了。
Manus 发布以后，我们一开始还担心是不是已经有竞品在做同样的事情。看完以后发现不是，它仍然是偏生成式、偏功能性的产品，速度也主要依赖 browser，所以速度比较慢。
因此我觉得双方是互补的。目前这个领域还没有太多人真正进入，还是一个相对蓝海的状态。
程曼祺 Manqi Cheng
Manus 的爆火出乎你的意料吗？
朱哲清（Bill）
不出乎意料。
首先，他们的市场营销做得很好，这是值得我们学习的。如何让一个非常 technical 的产品，甚至对消费者来说很 boring 的产品，看起来非常 exciting，是一件像艺术一样的事情，需要有经验的 marketer 来完成。他们的 marketing 做得非常好，这一点必须给 kudos。
他们的产品设计和 engineering 体系也做得很好。它把复杂的多步工具嵌套起来，从 Python 写作到 browser 使用，几乎没有缝隙，不会出现第一个工具完成以后，第二个工具卡在那里完全无法继续的情况。
它虽然很慢，但至少是一个相对 streamline 的过程。第一次出现这样一个完全 To C 的产品，本身就会给市场带来震撼，再加上 marketing 做得好，所以它爆火有自己的原因。
我们不会做得那么粗，因为我们还是偏 developer 为主。但我们也会尝试找一些人分享，让更多人知道我们的产品。
我们的用户 learning curve 可能会比 Manus 稍微深一些。用户需要知道自己的工作流是什么，而 Manus 可能只需要一句“帮我建一个网站”。
我们可能需要用户说清楚：“我要做什么事情，这件事要完成哪些 deliverables，这些 deliverables 要在哪些平台上完成。”
孙海宁
但用户也是用自然语言告诉你，只是需要说得更清楚一些？
朱哲清（Bill）
不完全是说得更清楚，而是因为我们真的要写入用户的互联网账户或工作账户。如果你不告诉我工作账户在哪里，我也没有地方可以写入。
这就是我们和 consumer Agent 最大的区别。如果真的要帮用户在某个账户里执行，就必须知道账户或平台在哪里。你不能只说“建立一个网站”，因为建立网站我们也可以做，但真正有价值的是帮你把工作完成。
孙海宁
你刚才提到3月3日发布 demo。下一个重要节点是什么？
朱哲清（Bill）
应该是 beta launch。
孙海宁
到时候会通过邀请码，还是大家都可以直接使用？
朱哲清（Bill）
大家应该可以直接使用，但会限制流量。一开始我们也不知道会有多火。我们的 computation 可能还好，但有很多 rate limit 是我们自己设置的，不希望直接把某些网站冲垮。
比如很多人同时去某个网页抓信息，网站可能会觉得 Poke AI 在 DDoS，然后把我们封掉，这就不行了。所以我们还是会小心一点。
当天用户可能会看到，有一些工具暂时不能用，因为当天的 rate 已经到上限，第二天可以继续使用。
邀请码唯一可能出现的原因是 computation limit。但我们完全可以做到 computationally scalable，所以不会有这个问题。
程曼祺 Manqi Cheng
Poke 单次任务的成本大概是多少？
朱哲清（Bill）
目前大概是市面上同类产品的几十分之一。
程曼祺 Manqi Cheng
你刚才提到，2024年12月 RL 又火起来以后，市场形成了更多共识，你们就回到了最初的愿景，去做更通用的 Agent。另一方面，你会不会担心，越通用，竞争压力也越大？
比如 GPT-4o 发布文生图功能以后，很多人讨论，当大模型基础能力提升，和基础模型能力重合的 Agent 方向可能会受到冲击。通用 Agent 肯定也是 OpenAI 这样的模型公司，以及 Meta、Google、字节、阿里等中美科技公司都会做的方向。你们的特别之处在哪里？
10. 通用 Agent 争夺平台层
朱哲清（Bill）
商业模式会是我们未来形成护城河的主要方面。
纯生成式模型有一个问题：没有 integration，没有挂靠，所有东西都靠生成质量。生成质量的 backend 归根结底只有技术。除了技术，没有额外护城河，没有用户粘度，也没有用户绑定。
我们要形成的是工作流绑定。
比如你有大量文件和过去的视频。你是一个社交媒体博主，过去的视频、图片都已经存在 Poke 上。你只需要告诉 Poke：“从我过去的文件里挑出3张年度总结图片，发到 Instagram 和 TikTok 上。”如果这样就能完成任务，用户就无法轻易跳到别的平台。
我们需要和用户形成深度工作流绑定。
孙海宁
我不知道理解得对不对。这个逻辑可能是你为用户创造，或者说让用户形成了迁移成本。如果这样，是不是一个速度游戏？
如果同时有 A、B、C、D、E 5个产品都能提供同样的服务，用户只能选一个绑定，那做得最快的产品是不是更容易活下来？
朱哲清（Bill）
不一定，这还真不一定。
这和早期互联网游戏一样。Facebook 不是第一家，但它活下来了。MySpace 当年有很多用户和它深度绑定，但最后还是 Facebook 活了下来。
关键在于市场迁移的过程。市场不断 shift 时，你能不能快速转变策略，能不能抓住一些用户群体，并围绕这些用户群体做更深绑定。
不管是自己提供 service，还是和垂直公司合作提供 service，都要先占据一部分市场，把用户粘度拉起来，然后再扩张。
所以这最终还是一个商业问题，不是纯技术问题。技术上 eventually 肯定有人能做出类似的东西，但我们希望有先发优势，同时拥有更强的集成、用户粘度和绑定，形成更长期的护城河。
程曼祺 Manqi Cheng
中美商业环境会有差异吗？
比如在中国，如果你要做写入操作，甚至是你刚才举的线下服务例子，让 Agent 帮我点个外卖，美团可能不愿意和一家创业公司合作，而是觉得自己可以做这样一个产品。
朱哲清（Bill）
国内几家大厂其实都来找过我，问有没有业务合作的可能性。
我们目前还是 focus on 尽快把不同形态的工具集成进来，先把通用 Agent 的能力接出来。等 SDK 和 API 能力成熟以后，再考虑作为平台给各大公司提供服务。
因为打通国内市场实在太难了。我当年融资时回国待过一段时间，最后总结下来，国内生态大多数时候是相对封闭的。
模型生态非常开放，但商业生态相对封闭，和欧美很不一样。北美可能是最开放的，欧洲居中。欧洲也有很多大公司不那么开放，比如 Booking.com，它们自己的生态也有护城河，并没有完全开放。
所以通用 Agent 的能力大概率会最先在北美爆发。不管是我们还是别的公司，北美商业环境更开放。国内则要看各大巨头是否愿意互相协作。
比如我们已经把 Google 和 Meta 的整个 ecosystem 接完了。换到国内，就相当于要把百度和腾讯的 ecosystem 全部接在一起。我对这两家公司是否愿意合作完成这件事，打一个很大的问号。
孙海宁
你能具体解释一下所谓的“开放”吗？比如在国内做不了什么，而在国外可以做什么？
朱哲清（Bill）
比如你要去 Facebook 发一条 post，或者去微信发一条朋友圈。你不能代替别人发朋友圈，也没有办法代表用户去企业微信账号发视频号内容，因为目前没有这样的接口。
但在美国可以做到。有各种生态支持你完成这件事：第三方集成、可下载的 SDK、REST API，以及各种第三方工具。
国内的生态基本是封闭的，只有腾讯自己可以做。它可能有一些 trusted partner 帮忙开发工具，但这些工具一般只为腾讯一家服务，不会同时接入腾讯和阿里。这样的情况非常少见。
孙海宁
所以你刚才设想的商业壁垒，可能要先在北美市场跑通。
朱哲清（Bill）
对，北美市场是我们最重要的 first milestone。后面当 SDK 和 API 的能力成熟以后，我们会和各大公司看看有没有协作的可能性。
程曼祺 Manqi Cheng
你刚才提到很多次，现在大家已经形成了 Agent、强化学习和工具调用的共识。我想知道，在实际落地和实践中，像你们这样以 RL 为核心、用通用方法做 Agent 的团队到底有多少？
朱哲清（Bill）
目前不多。大家还是以快速落地为核心，以套件为主。比如套一个 Claude，自己写一些工具，或者直接套 GPT-4o，再接有限的工具。
很多公司像雨后春笋一样在尝试，但真正做完全通用、能够无限 scale 的框架，目前我还没有看到第二家公司。
有很多小型 startup 在尝试用 Claude 或 GPT-4o，接 MCP 或现有工具，完成小规模的任务。它们大多以 To C 为主，比如最近很火的 Blender 插件、文生图插件，或者给 Cloudflare 用户使用的 MCP server。
有些插件是给 Cloudflare 用户即插即用的，有些是给 Blender 小白用的。它们希望快速获得流量、快速落地、获得 traction，所以垂直领域的公司很多。
但完全横向、无视 vertical、可以横跨很多领域的公司，目前我还没有看到第二家。我们可能是目前最执着于这件事的公司。
孙海宁
为什么这已经是共识，但做的人又很少？是因为难做、难实现，还是有其他原因？
朱哲清（Bill）
这是一个技术壁垒。除非愿意花时间和精力，从 fundamental research 出发解决问题，否则目前没有特别好的方案。
我觉得接下来 research 领域可能会有突破，各大院校和几家巨头肯定也会投入时间做这件事。
我们目前的方案自认为比较领先，但未来会不会有更好的方案、合作方式或者集成方案，很难说。我们希望利用现有优势，完成第一波市场 integration 和市场 scale。
程曼祺 Manqi Cheng
你们现在的做法，和之前开源的 Pro 项目有没有一脉相承的思路？还是已经进化了很多？
朱哲清（Bill）
进化了非常多。Pro 是一个更 fundamental 的框架。
我们确实使用了 Pro。我自己写的 library 中，有一部分就是基于它来写现在的系统，因为它是 MIT license。就我个人使用感受来说，它非常好用，确实加快了开发进程。
但那个 library 里只有非常 fundamental 的 components，没有算法层面的逻辑，真正的算法精髓并不在那个 library 里。
孙海宁
垂直 Agent 和通用 Agent 是相互取代，还是可以共存？
朱哲清（Bill）
我不认为它们会相互取代。
我们长期的目标，是 power vertical AI agent 公司。世界上有很多工具和任务，其中很多能力是通用的，比如写文件、写 slides、建立网页、抓取社交媒体信息和热点。
这些能力落在某个垂直领域以后，可能只需要增加一些特殊工具。比如把社交媒体和电商绑定，电商可能需要完成 Shopify 的操作。Shopify 里面有各种各样的工具，但和社交媒体相关的那一大块能力，和一个普通博主需要的能力并没有太大区别。
无论你是博主，还是用社交媒体做电商零售的 business，它们需要的社交媒体工具都是一样的。我们已经把最痛苦的集成解决掉了。你只需要告诉我，你要在 Shopify 上做什么，或者要在自己的博客平台和网站上做什么，我就可以完成整个工作流。
所以我们可以 power 很多 vertical AI 公司。你不再需要自己集成1000个工具，只需要告诉我，你们这个 vertical 最重要的10个工具是什么，就可以直接调用1000多个工具完成任务。
程曼祺 Manqi Cheng
你们的产品最初应该是在云端、电脑端使用。未来会不会拓展到更多终端，比如手机？
朱哲清（Bill）
手机端应该也会做，但主要是让更多人体验这个功能。
我们的核心突破点仍然在 developer 端，比如根据工具调用的数量、工具调用的结果来收费。
孙海宁
你觉得通用 Agent 框架这一层的市场可以容纳多少家公司？现在做这个方向的创业公司肯定已经不少了。
朱哲清（Bill）
做这个方向的公司肯定不少。少说，未来一年内会看到不少于10家公司。
但最后可能只会留下4、5家，甚至3、4家。这和 LLM 领域很像：大量同质化公司涌现，然后开始 differentiate themselves。
有些公司会更关注某些 vertical，有些更关注某种能力，让自己的能力和其他公司区分开。
比如 Claude 和 ChatGPT 一开始的产品几乎一模一样，后来 Claude 更偏 coding，GPT 更偏 To C，于是两者的能力和市场定位逐渐拉开。
Agent 领域也会出现类似的状态。
程曼祺 Manqi Cheng
但“通用”这个词似乎和差异化本身矛盾。如果达到非常高的通用程度，好像就会变成标准产品。
朱哲清（Bill）
这就像你问 Android 和 iOS 为什么还存在两个系统。
对，但 Android 和 iOS 这种操作系统背后的逻辑框架非常复杂，replication 成本很高。为什么还会有人想 replicate 也是一个问题。
而且 Android 是开源的。顺便说一句，如果 Android 当年没有开源，可能不止两家，肯定还会有第三家。
macOS、Windows 和 Linux 不也都存在吗？因为 Linux 存在，所以没有第四家去打 Windows 和 macOS 的市场。
一旦开源系统出现，后来者就很难有很多家同时出现，最后往往会被开源系统统一，因为很多人都会使用它，它就变成标准化的东西。
Agent 市场后面也会出现偏开源的产品。但 Agent 的架构可能更接近 OS，复杂度高于纯 language model，所以开源难度也高于纯 language model。之后会出现什么样的开源市场，还要继续观察。
孙海宁
像 OWL 和 Open Malice，是不是也算开源 Agent 框架？
朱哲清（Bill）
它们不算严格意义上的框架，至少不是调用工具非常复杂的框架。
我和 Open Malice 团队聊过。他们最开始的项目叫 Agent Hub，当时还没有上线，只是在开发，也没有放到社区里。它原本就是几个个人开发者的工作，并不完全是公司的项目。
后来因为 Manus 正好在那个时间点火了，他们用之前已经开发了一段时间的 Agent Hub，很快做出了 Open Miles，后来项目名称也改成了 Open Miles。
他们想做的确实是一个框架，让其他开发者可以基于它构建自己的 Agent。但具体未来的框架愿景是什么，我并不确定。
它可能是偏 Deep Research 的 Agent，也可能是生成式 Agent，或者是真正能够写入各种平台的 Agent。这几类产品非常不一样。
最后一种 Agent 的 integration 难度最高，前两种开源相对容易，最后一种最难开源。所以我认为，最后一种版本的开源难度会更大，lifecycle 也会更长，但一定会以某种形式出现。
程曼祺 Manqi Cheng
最后想问问 Bill，你如何判断一项技术的潜力？你之前一直坚信 RL 能做很多事情，后来 DeepSeek-R1 出来，也验证了你的判断。你的信念是怎么来的？
11. 用最小例子验证技术
朱哲清（Bill）
我经常和 Rich Sutton、自己的老板以及 PhD advisor 聊这些问题。一个很好的思维模式是 toy examples。
如果你看好一个技术方向，能不能用极少的计算量构建一个 toy example，证明其他技术方向做不到，而你的技术可以做到？这个 toy example 还必须 intuitive enough，也就是大家都认为它是一个 meaningful example。
比如推荐系统中的例子，或者现在可以用一个小 language model 的例子。在这个例子里，你能够明确看到其他技术方向做不到，而你的技术可以做到，那么这个方向至少在第一性原理上具备优势。
也就是说，在我要解决的问题上，只有我的技术目前有领先地位，而且它是一个 principally right solution，那就值得继续追。
如果你做了一个简单的 language model、推荐系统或者 data system 的 toy example，发现自己的技术和别人没有太大区别，那继续执着于自己的技术就没有意义。如果别人已经有 scalable solution，就应该跟随别人的 solution。
孙海宁
如果按照这个思路，会不会错过大语言模型？
朱哲清（Bill）
大语言模型在规模没有达到一定程度时，效果确实没有那么明显。但没有其他解决方案能够 get close to what they’re doing。
也就是说，虽然当时的效果还没有达到足以让工业界和用户感知的程度，但从实验结果看，它已经领先于其他方法。
我在 GPT-2 时期就接触到语言模型。当时有一位教授找我做语言模型相关的事情，我觉得这个方向非常有意义，但如果从零开始追赶这个 topic，确实已经有点晚了。
GPT-2 的时候，我基本确定它一定会火。但当时已经像一艘船，船上坐满了人，而且大家知道要去哪里。你在旁边一艘小船上，看到那艘船要驶向一个不同的方向，再跳过去和大家凑热闹，意义可能不大，而且很可能被淹没。
所以我的决定是：这个方向很 interesting，我应该 catch up，也要 learn from it。但要成为这个领域第一个落地的人，或者第一批落地的人，可能已经不太可能了。因此我还是专注于自己最了解的方向。
程曼祺 Manqi Cheng
你刚才说的，用最小 toy example 验证方向，其实还是一种科学验证的思路，对不对？
朱哲清（Bill）
对。你要先找到一个自洽的小案例。这个案例本身要 general enough，在这个案例中，没有其他技术能够解决问题，而你的技术能够从 principle 上解决。
你不能只是 hack 一个 solution 把问题解决掉，而要证明你的技术普适于这一类 example。这样你才会对方向有信心。
很多 researcher 发 paper 时，也可以 hack 出一篇 paper，找一个别人解决不了、自己能解决的 corner case。但真正落地时不存在这种 corner case。
你必须找到一个 minimal viable example。这个 example 要具有普适性，你的技术能解决它，而其他技术解决不了。接下来才能问：能不能把它变成 large-scale 问题，部署到现实系统后有什么 bottleneck，需要什么 system integration，然后把这些都打通，最终实现落地。
这也不是百分之百会成功，但至少第一步做成以后，你会有信心认为这个方向有80%的可行性，而不是盲目跑大型实验。
大型实验里有各种复杂性，变量太多，无法控制变量，最后你也不知道什么东西 work、什么东西不 work。
孙海宁
你是什么时候感觉到强化学习和大语言模型结合会非常有潜力的？
朱哲清（Bill）
当时我想，如果可以在 token level 用 RL 做非常复杂、非常长 horizon 的 planning，而且它能够 work，那么在更 abstract level 做 RL planning，应该也会 work。
它的整体复杂度可能并不会比每一步都用 token 做解析难多少。所以我当时觉得，这可能是一个大趋势。
当时我一直在推动推荐系统中的 RL 落地，也有很多成功案例。推荐系统里，每一篇文章、每一个 article、每一次 recommendation，都可以看作一个抽象 action。把它们 sequence 起来，就是一个 planning 问题，可以用 RL 来解决。
这和我们现在落地 Agent 很相似。从某种意义上说，我当时就觉得这件事一定有 future。
语言模型把原来直接用 RL 加推荐系统难以解决的问题拆解了很多。语言非常 flexible，可以被结构化成各种形式，sequential decision-making 变得更自然。
以前可能是做完一个 decision，遇到各种复杂情况，再做下一个 decision；但语言模型让 decision 之间更连贯，noise 和 partial observability 也减少了。
程曼祺 Manqi Cheng
你是什么时候特别明确地感觉到，用强化学习做 Agent 肯定会是一个方向？这应该是在创业之前就有这种感觉了吧？
朱哲清（Bill）
我毕业时就在想这些事，但构思了很久，差不多半年才想到现在的解决方案。
我在去年10月出来融资时，才确定技术方向应该是现在这个样子。在此之前，我一直在摸索，想找到最靠谱的技术方案。
当时有很多 nuance，我也不能完全确定现在的环境构造、模型建立和 self-play 是否真的能 work。我们只在刚才说的 toy example，也就是 travel 这个 toy example 上跑通了。
但能不能 scale 到无数个场景，能不能真正泛化，当时是一个很大的问号。后来验证下来，发现它可以泛化，所以这件事本身也有一定冒险。
孙海宁
有些大公司的技术人员创业，会先跑一段时间，把想法验证得更清楚，甚至把团队和投资都准备好再出来。我感觉你是直接做了决定就出来了。我不知道北美是不是普遍这样，可能和国内情况不太一样。
朱哲清（Bill）
我之前也找认识的人聊过，但没有做得特别深。早点出来，可以让投资人看到你的 conviction。
而且一直待在公司，公司的金手铐会永远铐在你手上。Meta 的工作很忙，如果你还在公司，就不可能真的不管公司的事情。
我当时手上的工作很多都要向整个 monetization 负责人汇报，甚至有些报告要写给 CTO。这样的工作不能不做，一旦要做就要花很多时间。
你也不能给这些大佬留下坏印象，以后还要在这个圈子里继续工作。所以如果要走，就应该干脆一点，给别人一个明确的 signal，而不是一直拖着。一直拖着对自己的 reputation 也不好。
孙海宁
我觉得这确实是一种更好的状态，只是你自己承担了更多风险。
朱哲清（Bill）
That’s OK。
孙海宁
好的好的，那今天非常感谢必友做客晚点聊，跟我们分享了他从本科时代就开始研究 AI 的规划，然后到后面做强化学习，一直在这个方向从冷门到热门见证了这个转变，然后现在他开始创业，从去年十月份的一个项目到现在不到半年做 RL 的 agent，我觉得这是一个非常。非常新颖的方式，或者说比较特别的方式，来实现现在大家都很关注的 agent 领域的创新。那今天非常感谢 Bill，嗯，好，拜拜。本期节目就到这里，感谢收听。如果你对今天聊的话题有观察、好奇或疑问，欢迎在评论区分享想法，这也会成为我们节目的一部分，让整个讨论更加完整。你也可以把我们的节目分享给对这个话题感兴趣的朋友们，欢迎推荐更多你想听的主题和嘉宾。你可以从小宇宙、苹果 Podcast 等渠道关注晚点聊 Late Talk，也欢迎关注我们的公众号晚点 Late Post，我们下期再见。