The Hand, Not the Mind

Hello 大家好，我是小珺。2025 年初，Manus 以通用 Agent 的身份引发了全球的关注，随后走过了惊心动魄的一年，2025 年也被认为是 Agent 的元年。过去一年，我们访谈了前 OpenAI、现腾讯的姚顺雨，Kimi 的杨植麟，Manus 的肖弘，Lovart 的陈冕等等。站在 2025 年的尾巴上，我邀请了 Manus 的联合创始人兼首席科学家季逸超，来和我们一起聊聊 Manus 的魔幻故事，以及 Agent 的进展与前瞻。

Hello Peak，先给大家打个招呼，并且做一个简单的自我介绍。

大家好，我叫季逸超，朋友叫我 Peak，我是 Manus 的 Co-founder and Chief Scientist。今天很荣幸能参与这个节目的录制。

你从小的经历感觉就很与众不同：四岁就去了美国，二年级又回国，高中开始创业，大学辍学了又创业，然后又读完了研究生。你讲讲你的这段经历吧。

首先得从我的家庭背景说起。我觉得我很幸运，我的父亲是北大物理系教授，是传统意义上的科学家；我母亲算是老一辈的中关村连续创业者，当然现在可能可以叫企业家。所以我从小就在这两种——怎么说，不叫文化——两种不同的风格中一块儿成长，我可能就在两者中取了一个中间点，就是所谓的科技创业者。

我从小其实就不是那种聪明孩子，学习也就一般，但是比较喜欢自己瞎琢磨。

有多一般？

就偏科吧。

偏科吧。

对。其实我不知道我学习到底好不好、聪明不聪明，因为我觉得我就没怎么学。

我比较幸运的是，很早就找到了自己喜欢做的事。那时候大概是 2009 年，是苹果出了 iPhone 之后的第二年。那时候对我来说有一个很大的改变，就是 App Store 出现了。App Store 我觉得对我来说是特别重要的一个转折点，因为在 App Store 之前，世界上其实很多人像我一样，喜欢自己捣鼓软件、做东西，但你其实缺乏一个很好的全球化变现的能力。而这时候对于一个高中生来说，如果你只是在瞎捣鼓一些课外的东西，这件事其实是比较离经叛道的，你知道吗？你没有一个很好的第三方指标来证明我的这个爱好其实是有价值的。而 App Store 当时的出现给了我一个契机，就是说我可以向我的父母、同学乃至于老师证明：我瞎搞的这个东西是能产生经济价值的。

所以我算是中国第一代软件出海的创业者，当时那时候还在上高中。我做了一个第三方的 iOS 浏览器，叫做 Mammoth Web Browser（猛犸浏览器），当年也稍稍火过一点吧。用的是最朴素的那种 buy a copy? 模式，就是每卖一份就赚一份固定的销售额的这种模式。所以很幸运，很早的时候就有了比较稳定的现金流。

这现金流有多稳定啊？

那个软件从第一个版本到最后，我大概赚了 30 多万美金。当时我觉得那个对于一个高二、高三的学生来说，已经算是挺开心的一件事。而且关键是它的销售模式很清晰嘛，对吧？我不需要去考虑太多，比如说 In-App Purchase，就是应用内付款，或者提供一些增值的这种模式；我只是非常老实地卖一份 copy，然后你给我一份钱。所以对我来说，怎么说呢，维护的成本是比较低的，是一个当时还成立的一种商业模式。

后来大家都知道，移动端软件已经不太再支持这样特别朴素的商业模式了，因为大家都要先免费获取客户。

对。或者说，当时是一个很好玩的情况：那时候从桌面互联网到移动互联网，我觉得是有一次平台的变化，简单来说就是有一个硬件媒介的变化。有一个新的媒介出来，即使你是传统的大厂，比如说国内当时的 BAT（百度、阿里、腾讯），还有海外这些公司，其实大家都跟开发者一样众生平等，都在做一个全新的尝试。那个时候在我看来可能是一个蛮荒期的阶段，所以你有很多机会去做这样的事，大家还没有反应过来后来的这诸多商业模式。

但你看反观现在的 AI——我可能就聊到哪说到哪——你就觉得很难的一点是，AI 虽然是一个新的技术突破，但实际上没有一个全新的平台出现。所以你看这回，我觉得不存在那个蛮荒期，无论是巨头、创业公司还是个人开发者，大家的反应都一样快，做得都非常干脆、利索。所以我觉得我当时算是赶上了一个好时代吧。

这段创业怎么结束的呀？

这段创业其实我觉得没有一个明确的结束的那一刻，它其实是我创业的一个起点。那时候我觉得它严格意义上来说还不能称为创业，因为我只是一个学生、个人开发者，用一个最朴素的商业模式去获得了一定的现金流。但当时你有一定的现金流，同时你要做一定的 marketing 对吧？可我也没有团队，就一个人，自己在比如说国内外的论坛上发帖。当时国内没有很成熟的那种支付渠道——因为你知道，现在 App Store 你可以用比如说支付宝、微信，或者那种 credit card 去付款，但当时我记得其实只能支持国际 credit card，所以中国国内基本是没有什么付费的。

这感觉现在 AI 也挺像的。

反正当时我就想：既然国内我很难去获得现金流，那我在国内就只能赚吆喝。所以我那时候会破解自己的软件，然后在国内论坛上发——就是你没钱，你就捧个人场。

然后你在这样做的同时，其实就获得了一些来自比如说资本界的关注。所以那时候也很好玩，我当时高二、高三的时候，参加了一个……当时感觉中关村还是比较有创业氛围的，我应该就是在中关村参加了一个创业的活动，但是想不起来是哪个了。当时就认识了真格基金。这个故事就非常简单，就是当时徐老师（真格基金创始人徐小平）……

徐老师。

对。徐老师问我：小伙不错，你想创业吗？我当然不想创业了，对吧？因为我既然有一个稳定的、可以边上学边躺着赚钱的现金流，那我何必要创业呢？但是我觉得，毕竟是徐老师，对吧，这个大家当时可能都是比较熟悉的，因为他应该也是北大那个体系出来的。

当时我回家跟我父母提了一下这个事，我这方面确实感谢我父母，他们就说这个你是值得去好好考虑一下的。我觉得那个时候对我来说也是陷入一个纠结：我可以有几个选择，对吧？也许我可以申请学校，去上一个好的大学，走跟现在大多数人一样的那条路；但另外一点，我觉得 App Store 给了我一个特别好的正反馈，就是你只要创新也许就能有回报。当时想得比较天真，就说我好像做出一个好东西，自然就会有一个好的结果。当时其实我也渐渐意识到，这不是一个常态，我是很幸运地踩中了一个时代的机遇。那好，其实我也许什么时候都能继续去读书，所以我就想，我现在优先考虑的应该是一个机会成本。

所以我当时就拿了 term sheet（投资意向书），然后决定这大学我不上了，我要去创业。对。但当时为什么接受真格的 offer？其实也是他们给了我一个承诺，而且我觉得这个承诺一直兑现至今：就是他们不会管我干什么，我爱干嘛干嘛。所以我觉得这个对于一个学生来说，是我能有的一个最好的选择。

所以当时我就拉上另外几个同学，他们比我大两届，已经保送去北大了，然后又被我忽悠出来。但当时我们其实已经意识到，你如果还在做这样朴素的、按每一个 copy 去赚钱的这个模式，已经不太 work 了。

那个时候已经感觉到不 work 了对吧？

很明显。因为当时的话已经又过了两年了，这个时候你会发现，无论是国内还是国外，尤其像第三方 iPhone 浏览器的这个市场里头，其实已经出现很多不同的玩家了，巨头已经回过味了。所以我们就觉得这个东西一定一定会走向一个免费，或者免费加增值的这条路。

但当时我们还做了一点最后的尝试，这也就是后面一切的起点：我们觉得既然要卖一款付费的软件，我们应该在功能上有比较大的一个跃进。首先一点，当时 Mammoth Browser 它的交互体验确实是比较好的。但当时其实还有另外一个背景，就是那时候无论是国内还是国外，都是 3G 初期的一个阶段，那时候移动互联网远远没有像现在这样这么流畅，那时候大家可能还会更多关注比如说网速慢的时候怎么办、弱网环境怎么办。

所以当时我就提出要解决一个问题：我们能不能去预测用户的下一次点击？比如说，那时候我还记得大家用 Facebook，国内应该是用人人网——校内的那个改名叫人人网，我记得。那时候大家很多人都觉得，好像 WAP 版、就是移动端的网页，似乎比当时那些比较初期的客户端要好用，所以很多人其实是在用移动浏览器去进行一些社交媒体的使用，所以你会经常有那种翻下一页的操作；后来也有更多人在手机上开始看新闻。其实我当时就觉得，如果我能准确预测用户的下一次点击的话，我可以进行 preloading，就是提前加载下一页的内容，让它的这个响应会更加得快。

然后这个其实就机缘巧合之下，让我进入了 NLP，就是 Natural Language Processing（自然语言处理）的这一个领域，就是自然语言处理。当然现在大家可能不太提这个词了，因为大模型已经把这一切给统一了。然后那时候大概 2011 年开始，就是我因为这个需求，所以开始研究这一个方向。然后当时做……

那真的是太早了，我觉得就很……

我很幸运的一点，就是我感觉我一直在学习的东西，都是因为具体的需求在牵引。

所以刚好也跟自己的兴趣比较 align，所以就接触了这个行当、开始做。

所以那个浏览器真正意义上，到后来它的结束是什么？是我发现了更好玩的东西，就是自然语言处理。因为它的模式一直是很单纯的——卖一份 copy——它就渐渐变成了一个没有人去维护的状态。随着比如说到最后 iOS 系统不断更新，它兼容的版本已经跟 iOS 不兼容了，所以你自然而然就被从 App Store 下架了。所以这是一个自然死亡的过程。

当然我觉得这还是很幸运的，就是让我人生的第一个产品同时满足了出海、加 AI、加上变现这件事，所以有一个很好的开始。

现在反过去说的话，浏览器这个事情当时怎么做，有可能后来摸到移动互联网的大牌吗？有这种可能性吗？

我觉得当时的话，我其实收到过一些收购的 offer，我觉得也许卖了也挺好的，因为我觉得其实浏览器……

谁的 offer？

这个就不要说了，不能点具体名。

但我觉得，浏览器可能从古至今，包括今天，包括很多团队也在做 AI 浏览器——待会也许我们会聊到——我觉得一直都有一个点，就是它其实不是特别适合以一个创业者、或者说一个颠覆者的形态来做。它其实更像是巨头你已经有了分发的渠道之后，去锦上添花的一件事。对，所以我如果回看当时的话，我不认为以现在的我的经验或者阅历，我能做出什么更好的选择。

第二段创业呢？第二段创业的方向？

第二段创业的方向，其实应该是刚才讲的第一次真正的创业。就是因为在做这个浏览器，所以我意识到 NLP 这个领域真的非常有意思。

但那时候其实也很有趣，就是 2011 年，距离一个石破天惊的 paper——我说的不是 Transformer——其实 2013 年，Tomas Mikolov 在 Google 推出了一篇 paper 叫 Word2vec，就是第一次能够把……也不是第一次，就是较为可靠且高效地，能够把自然语言文本、离散化的自然语言文本变成稠密向量。这个其实对我来说，是我认为我心中最石破天惊的一个转折点，因为它头一次能让我们比较方便地把一些源自其他机器学习和深度学习领域的方法，应用在自然语言处理领域。

像当时 2011 年前后，大家做自然语言处理可能关注几件事：比如说你要进行比较复杂的分析的话，可能会有一个技术叫做 dependency parsing，叫依存句法分析——当然现在这个词可能已经死透了，新一代做 AI 的人可能都不知道这个词了；中文的话，那时候我们还会关注额外的、所谓的 tokenization，当然跟现在大模型的 tokenize 相比可能会更原始一点，因为中文本身它会有切分这个问题，当然不止中文，中文、日语，还有德语叫 decomposition，就是拆词这个问题。所以那时候做的还是一些比较……怎么说呢，为了自然语言处理而做的比较专有的解决方案，按现在的话说是不太 scale 的，因为其实你需要很重的标注才能做好，而且你本身的模型也没有那么强大。

所以当时给我最大的一个触动，是 2013 年那个 Word2vec 的 paper 出来，我觉得这一下新世界的大门就打开了。这让我真正意识到，我的兴趣可能其实是在 NLP，而不是在继续做浏览器。也很感谢当时真格兑现它的承诺——我说我不想做浏览器了，然后真格说"随便"。

当时我就看中了 NLP，但其实也是看中另外一个市场机遇——当然回过头看我觉得是错的。这是怎么回事呢？就是当时 2013 年其实已经开始有传闻，说苹果在筹备一款可穿戴式设备，其实也就是后来的 Apple Watch。这个当时给了我特别大的想象空间，因为我当时觉得，那个时候的搜索还是你输入一个问题、一个 query，然后它给你 10 个蓝色的链接。这个东西能够 work 的根本原因是，我们在与电脑这样一个大屏幕进行交互。那假设未来比如可穿戴式设备，或者说语音的界面、voice interface 更加成熟的话，那这一个交互模式可能就不 work 了。

所以当时我想解决的一个问题是什么？就是说，我能不能以一种更结构化且更紧凑的形式，把知识跟用户之间的交互进行一次革命。这个当时就引向了一个方向，就是现在可能叫语义搜索、叫 semantic search。这个东西我当时会觉得，这就是下一代的 Google——我作为一个创业者，我会不会是当年的 Google，像当年的 Google 颠覆雅虎那样？所以我们团队大家都很兴奋。

然后我们想解决的这个问题，逐渐也就细化了下来，这其实是一个非常技术驱动的问题。我当时在想，如果你想用一个更紧凑的结构去回答用户的任意问题的话，那其实你需要的不能是网页的原始信息。因为大家都知道，搜索引擎的工作原理，当时可能就是使用倒排索引，就是说你输入一个关键词，它会把所有包含这个关键词的网页通过一些排序算法进行排序，把 top 10 给你。所以用户输入的问题，最后获得的东西仍然是原文，是自由文本。这个自由文本，你想象一下，如果你用 Apple Watch，你不可能在上面反复滚动去读完嘛，对吧？如果你是车机、或者像 Siri 这种 interface 的话，你也不能让它去朗诵那么长的文本，因为人的带宽、听力这种东西，其实你会很着急。

所以我们觉得，当时从技术层面来讲，它缺的是什么？是一个高效紧凑的 representation，就是表达形式。而那个时候，我们想到的一个概念其实是知识图谱。知识图谱现在也是一个半截身子埋在土里的概念。

老词。

老词，对。

但是当时我们也是有追求的团队，我们在知识图谱这件事上再往下下钻，看到底是什么限制了知识图谱这个概念真正落地。我们当时找到的一个切入点是：我们认为知识图谱其实完全都不够完备。因为那时候你能找到的知识图谱，无论是通用的，还是行业领域知识图谱——也是一个很久的一个词了——它其实大量地依赖人的编辑。

比如说，如果你要在一个行业内，比如当时有做工业领域的知识图谱、科学领域的知识图谱，其实都需要一些专家去进行标注，比如你要标注 SPO，就是三元组这样的形式去进行标注。而通用、或者说通识领域的知识图谱，当时世界上有几个比较大的平台，有一个叫做 Freebase，好像后来是被 Google 收购了，它们就以一种众包的形式让大家贡献这些知识；后来它应该演化成了 Wikimedia Foundation 下面的一个项目，叫做 Wikidata。它里头做的就是比如说，关于你张老师，你是一个实体、叫 entity，你下面有各种你的属性，比如说你的出生日期、你之前工作的机构?、你的节目是什么，这样你能形成各个实体之间的关系，这就是所谓的知识图谱。但很明显这个东西完全依赖于人类，这个我觉得是我们探测到的一个瓶颈。

所以我们想找到一种技术来把这件事自动化。当时的技术供给能做到什么呢？就是刚才讲到的那一个年代的 NLP，还在一个比较初期、比较混沌的阶段。当时要做这件事，可能已经有的方案是这样：你可以首先进行叫命名实体识别，叫 NER（Named Entity Recognition），就相当于你读一篇文章的时候，你把里头所有的实体，能够由一个 AI 模型来标记出来。但这样的话你其实只获得到了实体，比如说张小珺这是一个实体，然后这档节目是一个实体。但是所谓知识图谱，图谱之间是要有边的、edge，那这个边是怎么来的呢？当时有另外一项技术叫做关系提取，叫 relation extraction，就是对于两个实体之间我能探测到，比如说张小珺是这一档节目（张小珺商业访谈录）的主持人，那么"主持人"这其实就是一个边，或者叫 predicate、谓语。

然后这样的话，我们用这两套技术能构建怎样的一个知识图谱呢？就是说，我如果能限定领域，那么我能进行很好的实体识别；如果我能限定提取的关系的总类型，我也可以进行这个工作。比如说我提前知道这世界上有"什么节目的主持人是谁"这是一种关系、"人的出生日期是什么时候"这是一种关系。那很明显，这个东西好像不可枚举，对吧？因为任何两个实体之间的关系，它应该是一个无限集。

所以我们就意识到，当前的技术肯定是有局限性的。那么我们当时就投入到了一种新技术的研发。后来这个技术在学术界的定义应该叫做 open information extraction、openIE，开放式信息提取。它跟刚才这些技术的区别就是说，我不需要提前定义一套规则或者 schema，就是说我不用规定哪些东西是实体——因为传统意义上的命名实体识别可能关注几个，比如说人名、地名、然后组织名这些东西，你看这其实又是一个白名单机制，我们要避免这层面的白名单；同时在进行关系提取的时候，我们要避免提前预设了这些关系，而完全变成一个 schema-less、就是说无大纲形式的提取。

最后我们做到的一个技术是什么？就是说 AI 在阅读一篇文本的时候，它能够自己识别出这里头有哪些潜在的东西是实体，以及这些实体之间的关系是哪些，并把它们提取出三元组，并持续自动地构建一个知识图谱。所以这个在当时我觉得还是很重要的一个技术。而且我们选择了最苦的一条路，就是我们从零训的模型。而且你想，这件事是从 2013 年底、2014 年开始的，我非常幸运又不幸地赶上了 NLP 技术最跃进的那几年。

所以我们一开始的话，当时是一条……我们团队分两边，一边在做基于传统的依存句法分析的一个解决方案

同时我这边在做基于 Word2vec 向量化的一个解决方案。做了几年之后我们发现，这个东西好像可以去 scale up，就开始用 LSTM 去做，后来是 LSTM 加 attention。再到后来我们觉得，其实 Word2vec 或者 LSTM 加 attention，它在输入层的信息损失就很大。因为那个时候如果你用基于纯词向量的方法去做的话，它无法分清楚一个完全同名的词的不同含义。

我举个例子，比如孙悟空。孙悟空可能是咱们中国传统《西游记》中的孙悟空，也可能是像日本《七龙珠》里头那个孙悟空，再后来还有《王者荣耀》里的孙悟空。你如果完全基于 Word2vec 这种技术去做，你会发现同样一个词，它在不同上下文中的意义都被压缩在了同样的一个 512 维或 768 维的向量中。所以当时我们就很苦恼，说能不能再进一步——其实就需要有一个上下文相关的编码方式。

那时候我觉得那几年是非常幸福的。一方面是什么？就是你基本上想什么，这个世界上就发生什么。再后来 Transformer 出来了，BERT 出来了，它可能解决 contextual、就是上下文相关这个问题。但是不幸的就是，每一次这种技术的迭代，你可以发现我们过去几年的积累基本都白算了，不用去做了，所以很痛苦。

我们当时等于从 2014 年底一直做到 2018 年才把这事做完。我们当时所有的模型都是自己从预训练开始做起的，是非常痛苦的一件事。然后也很早就开始——

这是多大的模型？

总共加起来我们有两个模型，大概是两个 0.3B 的模型。那时候这叫大模型，但是现在这已经都不算什么了。对，然后也很早地遇见一些问题。比如当年像 BERT，默认情况下如果我没记错，它的 context length——不过那时候我们还叫 sequence length——是 512 个 token。

512？我的天呐。

你如果去掉比如说它一开始的 CLS 跟 SEP token，你这就 510 个 token。那这时候如果我要让 AI 去自动在互联网上读网页的话，这个是完全不够的。所以我们当时从 2018 年底就开始解决 long context（长文本）的问题。但是那时候我们解决的 long context，在今天看来很小儿科——我们解决的是 16K 长度。对，然后这个如果我没记错，那个模型后来我也开源了。

反正我们当时就一直在做这个事。当时做的一个产品叫做 Magi，Magi 是来自于我很喜欢的一部动画里的一个超级计算机。它做的事情就是如刚才所说，AI 能够自己到网络上去看各种各样类型的、不限领域的文章，并持续构建并更新一个知识图谱。我们当时做的这个事，现在的学术定义应该叫 lifelong learning 或者 continuous learning。反正就很好玩。

这个项目其实做得我们自己很嗨，我到今天觉得这是我智力、我的编程和 research 能力的巅峰。再后来人就已经逐渐老登化了，水准开始下降。但是那段时间，我们做到后面就会觉得很痛苦，就是外界的创新实在太多太快了。直到 2019 年的某一天，我拿到了 GPT-3 的 Early Access，我觉得天要塌了。

为什么？

因为是这样，就我刚才讲的，我们当时选择了很苦的一条路，就是一切我们要做垂直整合，对吧？模型自己做，产品自己做。那好，我其实每一次产品的迭代，都要等我底下的模型完成。那时候的模型跟现在比简直非常非常小，但是同样，evaluation 这事也很恶心，你的 Infra 也要自己去搞。所以我们当时迭代的周期基本是两到三周能有一个模型的迭代，但是两到三周在当时的外部，这简直是巨变了。

然后拿到 GPT-3 的时候我测了一下。我觉得天塌的原因是什么？我们把同样的任务，我拿 GPT、拿我随便写的一个 prompt——那时候大家没有什么 prompt 的艺术，对吧，都胡写——我发现它跟我们自己训练的端到端模型五五开，你知道吗？而且我当时就意识到一个问题：它虽然现在很贵，但是它是一个通解。

就是那个时候我们在比如 NLP 领域内，大家互相交流，你会有很明确的感觉。比如我跟别人自我介绍的时候说，你好，我是 Magi 团队的，我们是做信息抽取的；然后这边可能是做机器翻译的，这边是做客服系统的。大家泾渭分明，对吧？就互相握手，互相学习。但 GPT-3 出来之后，其实它印证了一件事：好像我们做的不同任务是能够大一统的。

其实它不是第一个工作，之前有 Google 一篇叫 Flan-T5 的 paper 出来，当时已经有这个苗头了。但是那时候大家还觉得，Google 土豪太厉害了，做出一个很好的 demonstration，但是你要垂直领域还得看我们。可是 GPT-3 出来之后，就彻底把我们的心给摁死了，你知道吧。所以当时我的第一反应就是赶紧卖掉公司。

卖了吗？卖给谁了？其实是变现了是吧。你好先进啊，我听下来。

不敢说。

你从 2011 年做的事情，感觉和现在大家做的事情差不多。我觉得就是顺着做了一遍。

我觉得不能这么说。应该说，大家在每一个阶段遇见的问题是类似的，但是你每一个阶段其实都未能解决未来大家再次遇到时的问题。比如我们当时说的 long context，是从 512 个 token 到 16K；现在的 long context 可能指的是比如说 200K 到 2 个 million，对吧？所以我只是说，历史它会押韵，但肯定不会重复。

你们当时做这些，你的目标是什么？因为我感觉你一直在顺着这个技术往上爬，但是你的目标是什么呢？

对，我觉得这是一个很好的问题，也是上一次创业中我觉得我没有想通的一件事。就是可能那个时候还很年轻——包括现在我看到很多跟那时候的我一样年轻的创业者，我觉得优点是什么？就是非常地遵循自己的本心：比如你喜欢什么事，你就先把这个事做下去。当然你也可以往好听了说，就是如果你看中了一个技术问题，且这个技术问题真的别人没解决的话，那它往往可能会是符合第一性原理的，就是说它是一个很重要的待解决的问题。

对，所以当时我们遇见的，如果你现在切到产品侧，可能会有几个问题。第一点，我们会觉得应该做一款很成功的搜索引擎来替换掉 Google。但实际上首先，我们低估了搜索引擎本身这件事。这个其实当时很多人不知道，就是 Magi 这个项目，我们没有使用任何第三方的搜索，我们从爬虫到索引引擎全是自己去建的，自己手写的。我觉得那是我工程能力的巅峰。

然后我们其实低估了一件事，就说你光有技术，其实你解决不了一些非技术问题。比如说现在我都不太看好你再做一个新的搜索引擎，因为比如很多的数据源跟 Google 已经形成了一种……它们之间也是一个互利互惠的、可循环的关系。你再以一个搅局者入场，其实你无法重复 Google 过去 20 年来积累的这些数据源这个事。

对，所以当时我们就觉得，产品一方面是我们的技术和非技术原因没做好；另外一点，是我们当时很期望发生的，就是说有一个新一代的可穿戴式设备，或者全新的人机界面的出现。这个东西可能到今天为止，也许可穿戴没有充分地落地，同时新的人机界面也许是直到 ChatGPT 才真的落地。所以我觉得产品层面的错误，一个是技术，一个是可能确实是早了。但是创业就是这样，你早一步就是先烈，对吧？不对，早一步是先驱，早十步就是先烈。所以当时我们就先烈了。

然后第三个，我们当时商业上也没有想得特别清楚。一开始想的是做一款完全 ToC 的产品，把这事做大；但后来其实因为做了很多年，技术不断迭代，你也会慌，所以又想能不能直接做一些 ToB，但明显团队的基因不是这样。所以我觉得那一段创业经历其实让我学到了很多。当然特别爽，特别爽，就是因为那是一个我觉得很多创业者梦寐以求的状态——我就想把我人生的夙愿给做完。

夙愿是啥？人生的夙愿——人生的夙愿是啥？

就是我想自己从头、基于一切都是自己写的：自己写的 Infra，自己做的模型，去解决一个别人没有解决好的问题。

可是 Google 这个事已经解决好了。

Google 没有解决好。

你觉得它哪里没有解决好？

它是这样。首先 Google 是通过收购 Freebase，对吧？它其实获得这个之后，只获得了一个很好的社区。然后它当时又有一个并行的项目叫 Knowledge Vault 还是什么东西。我们跟他们做了个 head-to-head 的对比，就是头对头的对比：我们当时在最高置信度下的准确度能达到 89% 点几，所以我们的准确度是比它高的。同时我们不仅支持中文，还支持别的一些语言，包括反向书写的阿拉伯语。这个现在可能大家不觉得是什么，但当年这还是比较厉害的一件事。

同时我们还自己去研发?了向量搜索，那个现在可能也是比较常态了。我们当时为了解决 scale 的问题，我记得是跟英特尔合作，找了一个新的方案：他们当时有一套技术叫做 PMEM，就是持久化内存，我们自己写了一套向量索引，基于 HNSW 算法，然后去搭建了整套这个东西。就是我把我这辈子想试的技术，都以合理的方式花投资人的钱给搞定了。

所以我觉得在那个项目做完的那一刻，我的人生已经圆满了，你知道吧。所以再后来，包括现在做 Manus 这些事，我心里已经没有什么那种"我要证明自己"、或者"我要做什么这个才能死而无憾"——我早就无憾了。所以现在我就可以以一个很轻松的状态来做很多事。

所以你（卖掉公司以后）还去工作了？

对，我工作了一年半，那段工作经历其实非常开心。

非常开心？为什么？是个大公司吗？

当时还是一个独角兽状态，相当于在临上市前的一年多。但当时又刚好赶上 GPT——我是因为 GPT-3 的出现，意识到危险了。所以相当于我是在 ChatGPT 出来之前进去，一直干到了 ChatGPT 出来之后那一段，相当于我在那家公司从零做起了 LLM（大语言模型）的业务。

那段期间怎么说呢，这个公司的一个工作模式，当时很多人不喜欢，就是所有的 Research 或者算法岗位，大家都在公司内部打榜。因为那是一家 To B 的公司，B to B，做 AI To B。那 AI To B 的一个经典问题就是：你如何去量化用户的收益？除了一些比如说最终的经营指标以外，其实也需要一些过程指标。当时有一部分团队的任务就是，把所有用户的需求转换为可量化的 benchmark。而这个恰恰是 Researcher 和算法岗最喜欢的事情——打榜。所以那时候我的主要工作就是打榜。

打榜又很开心，因为当时公司内部的激励方案很有趣：公司内部有一个类似 Kaggle 那样的榜单系统，你赢得越多，你的奖品是什么呢？你能获得更多的显卡。所以你会进入一种强者恒强的状态。我当时一个人能囤好几十张卡，一堆卡的资源闲置，但是我就可以去捣鼓很多我想试的东西——因为总有客户会需要嘛。所以我可以做很多的实验，同时我的算力又是最充裕的，我能 scale up。所以我在那一年半里头，一直霸榜在第一名。我觉得那段经历特别开心。

你以前上学的时候好像没有这个劲头是吧？你以前上学的时候是那种特别喜欢比分数的学霸类型吗？好像不是吧？

不是，因为我好多课我都没上。我特别感谢我的高中，当时在北大附中读书，我觉得我特别幸运，遇见了一群超级开明的老师。开明到什么程度？有的课我不想上，老师说那你就不上了。后来学校还给了我一个——也不叫一个小屋，我们有一个计算机社团，就像我在学校里头有一个不上课都可以去的办公室，有空调有电脑，让我好好地捣鼓我喜欢的东西。我觉得太幸运了。

你第二段创业终止的那一刻，你在做什么？你在想什么？

我当时的想法是这样：我知道有一个新技术出现，可能要杀死我，那这时候我的选择是什么呢？当然是选择加入了。

然后我们当时的想法是这样：我刚刚经历上一次创业的一个创伤，就是你自己要做垂直整合真的很痛苦。我常说一个比喻——每天醒了之后，你都感觉海水在上涨，但是你不知道会涨到什么程度，也许你第二天醒了之后就已经到鼻子这儿了，很恐怖的感觉。所以当时我的想法还是：我喜欢创业，但是我不想做垂直整合了。

所以当时会有一个比较天然的想法。那时候大家会把 AI 创业分为几个层，比如说模型层、Infra 层（就是基础设施层）以及应用层。当时我就想，OK，那我面前其实也就三条路。那时候其实到了 2022 年底、2023 年初，大家看了 ChatGPT 之后，国内很多基座模型公司开始动起来，当然我也跟所有人都聊过，但是没人能说服我这个东西到底该怎么办。因为我觉得我不太想再体验那种特别难受的状态，所以我更多的目光是看向了所谓的基础设施层跟应用层。

但这时候其实也有一个问题：大家倒是一直在说这个事，但是没人知道真正的 AI 应用该长什么样。尤其你想 2023 年年中的时候，真正有 PMF 或者说有一定声量的产品可能就两个，一个 ChatGPT，一个 Character.AI。而 Character.AI 这种东西，我非常清晰——我不懂这个东西，因为我用了以后用不进去。

你不是它用户？

不是，不是它用户，那我肯定做不好这样的产品。而 ChatGPT 其实是一个天时地利人和的状态，我至今也觉得，ChatGPT 出来一瞬间，Chatbot 的这个赛场已经结束了。所以我明白我想做应用或者做 Infra 层的东西，但我没想好我做什么。所以我就看一些机会，同时也去看一些相关的项目。

然后在真格待了一段时间？

对，在真格待了一段时间，也算是跟更年轻的创业者一起交流，把我过去的比如说悲惨经历跟教训，可以提前告诉大家。

所以今天这节目，我也想跟大家分享悲惨经历。

然后再到后来，其实也是当时认识了肖弘（Manus 创始人兼 CEO 肖弘），就是我们现在 Manus 的 CEO。他是怎么说服我加入的，或者说为什么我要从第二段创业之后去开始这个事……

你中间隔了多久？

当时就是那一年半的时间嘛，在真格待了一年半。

然后那段时间你就明确不想做大模型，不想去任何一个大模型公司？

我几乎跟所有的大模型公司聊过。

你有喜欢的吗？

嗯……Google。

Google？海内外的都聊了是吧？

海外聊的是……当时海外也没几家，海外也基本都聊了，然后国内的话也都聊了，包括当时那个……

为什么是 Google？你不是要干掉人家的吗？

就是你没干掉它，你才会格外尊敬它呀。

然后当时我的那个想法就是：我想找一款 AI 产品，不是我自己去主导，而是一个很空的画布，大概是这样的一个感觉。因为其实上一次创业到最后，我还学会了一个很重要的事，就是我意识到，我根本不是做 CEO 的那块料——我既不喜欢商业化，我也很讨厌管人。所以我觉得这是交了一个学费，就是我知道我不该做 CEO，我应该找一个比我适合做 CEO 的人。

那你觉得你是哪些方面不适合做 CEO 呢？

我觉得完全就是情绪上很抵触。

情绪上就很抵触？为什么呀？CEO 哪些比较反你的人性？

首先有一点就是，我很喜欢跟电脑打交道，但我觉得人太复杂了。你的组织随着变大的时候，你能发现这个复杂度其实是指数级增长的。我觉得我不是那块料，我搞不定太多人与人之间更微妙的这些事情。

你看起来比肖弘要 E（外向）很多。

不不不，其实我们公司除了张涛以外全都是 I 人。

你是 I 人？

对，我只是开朗的内向，你知道吗？

被你欺骗了。

我在跟你聊具体的业务的时候，我能讲很多，但是其实我……

你是 I（内向）什么？

INTJ。

INTJ 感觉都烂大街了，大家都差不多。

对。所以我觉得首先，管人我不太行；第二点就是，我有时候会陷入一种特别追求正道的思路。

什么叫正道？正道？

就是说，你有一个能够赚钱的方向，和一个能够把一个特别有趣的技术走到底的方向，我会毫不犹豫地油门踩死往右走。但是我知道这已经是错的，所以我需要有一个人把我给管住，就是在我又想发癫的时候给我摁死。

所以也是经过创业之后，你会充分意识到自己的不足。

对。所以我当时讲得也非常清晰：第一，不想当 CEO，不想当一号位；第二，我想找一个能够探索的画布——注意我说的是画布，而不是一个已经成形的产品，然后去迭代它。因为我觉得，当时所有人不过都是在下注，没有谁真正有一个非常系统性的、Systematic 的方法去知道接下来 AI 产品要做什么。

什么叫所有人都在下注？

就是当时大家都在基于自己的一个直觉判断去说：我要做一个什么东西，我要做一个什么东西。但其实我已经经历过几次这样的创业，我就想，我能不能这回做得正规一点？就是我能不能像字节跳动一样，有一点数据思维。

所以当时我就觉得，我不应该自己在丛林里以一种"因为相信所以去做"的方式做事，我应该有一个过程去更多地观察。那观察用户最好的方法是什么呢？就是有一个初步 PMF、但又非常空的画布。

所以当时我跟肖弘——当然因为他也是真格投的，也算是我们的老一辈创业者，现在都已经是中登的年纪了——当时他做一款产品叫 Monica，Monica 现在也有很多人用，我们现在都在同一个实体下面。Monica 这款产品其实是一个 Chrome 的插件。Chrome 插件，我当时觉得这个产品的形态非常戳我，是为什么呢？

因为首先，它其实没有改变任何用户的习惯：你在浏览器中，仍然在使用你所熟悉的 Gmail，你还在看 YouTube，没有因为是 AI 侵入你的生活而改变什么。所以用户原本的轨迹不是被强行改的，你的观测是一个无偏的观测。

第二点是什么？当时很多人要做 AI 的话，可能都要先下注去做一个方向，因为你不能在一个界面中无限地叠加不同的元素，你产品的复杂度会变得很高。像我很喜欢 GitHub 的一句话叫 "Anything added dilutes everything else"，就是你每增加一个东西都会稀释所有的价值。但浏览器插件的绝妙之处是什么？它的功能触发其实是基于 context：比如说跟视频理解相关的东西，只会在你看 YouTube 的时候出现；跟自动编写或者文章改动相关的这些功能，只会在比如说 Gmail 或者 Google Docs 里出现。所以它其实消解了功能增加带来的复杂度爆炸问题。

所以我觉得浏览器插件是一个绝妙的、观察用户到底在怎么用 AI 的窗口。它甚至不能叫一个产品形态，它是一个空的 container，一个空的画布。所以我觉得这款产品作为进入 AI 应用时代的门槛是绝佳的。

观察到了什么？

观察到了一些非常有趣的东西，待会儿再讲，为什么做 Manus 的时候可能都会讲到。

这块我觉得是非常值得做的，但是我其实也没想好——就是其实也有别的插件，那为什么要跟肖弘合伙呢？

首先，我很幸运，跟他交流之后，我发现他太适合当 CEO 了。

怎么说？

就是他擅长所有我不擅长的东西。而且其实如果你反过来说，你看当今国内外 AI 创始人一号位的整体这个 landscape、这个版图的话，你会发现肖弘有一个非常稀缺的特质。

什么？

他很正常，他身心健全，没有任何不良嗜好，没有任何极端的思想。这不是一个正常的指标，这已经很难得了，你知道吗？我觉得现在整个行业有很多人比较偏执或者怎么样，但是讲真，其实你没有乔布斯的命，却得了乔布斯的病。

你在说你自己吗？

对。而且我经过惨痛的失败之后，我意识到这一点，但是他们还没有意识到。所以我觉得肖弘身上最可贵的品质，就是他特别正常。

相信常识是吗？

对，还是你会说话。相信常识，且相信团队。而且好多事情的判断，他会更加的——怎么说，你既可以说是数据驱动，也可以说是直觉驱动。但他是一个真正能把公司从一个阶段持续带到下一个阶段的人。而我如果自己从头做的话，我只会在我喜欢的那一个阶段很爽。所以我觉得太难得了。

哪些细节能让你见他第一次就觉得他很正常？

我觉得不是见第一次。

你们见了几次？

其实很多次。包括后来，其实也是一起吃了两三次饭，然后也长谈了很久。最后他怎么打动我加入呢？还是因为一句话。他说：「Peak，我知道你做过浏览器，你做过搜索引擎，你做过语言模型，你想不想在一个产品里把这三件事都重新做一遍？」我觉得好呀，这个好，听起来挺吸引人的，然后当时就加入了。

当然，加入之后也非常清晰的一点：这次创业其实我不是来做 Monica 的。Monica 是我们大家的一个学费，也是整个公司的一个 cash cow，它产生现金流。但我们加入，一定是要把这个团队团结起来——包括后来张涛还有更多的合伙人加入——我们是要一起搞一个全新的事情的。

在你们多次的长谈和聊天中，你觉得哪些细节让你觉得他非常正常？

我觉得还是对比出来的。因为同一个阶段，我一定不止跟肖弘有所接触。

对，你肯定全见了嘛。

对，是的。

怎么正常呢？

我觉得别的创始人都太艺术家了。

太艺术家了。

是的，是的。

你就比较艺术家是吧？

你如果这么划分的话……我不敢说，我不配，我不配这个词。

太艺术家了。

对，别的创始人我觉得太艺术家了。肖弘非常现实。或者说，包括我们公司现在整个的运行，其实我觉得都是很稳健的，甚至有时候我们内部反思会觉得有点保守。但这才是一个——叫什么——就是更尊重常识。

我觉得你这个词说得很好。你说谁是艺术家？我们可以哔掉。

太多了。我举个例子，比如说，你知道 XX 那个产品吗？

哦，知道。

然后你知道 XX 吗？

嗯，我见过他。

然后像那个 XX，还有做那个……

哦，你都见了。

大家都会找我来聊一聊。我是觉得大家都太艺术家了，太艺术家了。

身心不够健康是吗？

就很偏执，多少有点抑郁。

多少有点抑郁。

其实肖弘有时候也会抑郁，我就一直……

他有时候就比较 EMO。

对对对。

但他不属于抑郁对吗？

他不抑郁，整体是比较阳光的。而且他不会那么深夜发癫。

现在这些对于创业者来说，你觉得不是优点了是吗？

我觉得不是优点，绝对不是优点。这我觉得是很大的一个变化。以前移动互联网时代，我还挺喜欢这类人的，因为你的边际成本很低，你可以去比如说赌一把，搞一个大的，看用户是否能找到一群跟你共振的人，再逐渐去做大。

但其实我们觉得现在 AI 这个行业，首先，当然 LLM 的 inference cost 一直在下降，但其实我们心中隐隐觉得它更像传统的制造业：它一直有一个固定的成本在那，你如果没有任何的优化的话，其实随着你用户量的增加，你的成本是线性去提升的。所以这整个事对经营的操作能力的要求，是比上一代移动互联网创业又高很多的。

这个有趣。

我觉得是高很多的。

移动互联网更喜欢艺术家。

对，移动互联网时代喜欢艺术家，而且其实你能很低成本地获得一批初始的用户。但是 AI 我觉得不是，AI 不是这样。

但是你从一开始就 pass 了大模型这几家公司。

是的。

你也都聊了。

我基本上都聊了。但这个原因完全是因为 PTSD。

对。但是大家会觉得 AI 时代不一样的是，可能大模型和产品是一体化的，所以说拥有大模型的公司更有可能做出好的产品，就是他们那个「沿途下蛋」的理论。你从一开始就不认可吗？

我认可这件事，但是我认为有一个时间先后问题。我现在的一个观点其实是：可能都不用太久吧，也许比如说六个月之后，其实你不用再分所谓的模型公司跟应用公司，基本上每一家头部应用公司都有做模型的能力。其实这个事已经被 Cursor 给跳出来了。我觉得之前大家还有一种秘而不谈、泾渭分明的状态，但你看 Cursor 已经跳出来，他们搞了他们新的那个模型——叫什么来着，Composer One 对吧。

其实我觉得，首先，做模型、或者说做垂直整合这件事，它其实最影响的是你初期的迭代速度。我上一次创业最惨痛的一个教训就是：你在不确定的时候，你开始做 bottom up、就是自下而上的迭代的话，你会被你的模型迭代所影响。其实这不仅是创业公司的问题，哪怕你强如 OpenAI——OpenAI 我非常尊敬他们的一点，是他们一直非常尊重这种自下而上的模式，所以他们产生很多新的创新——但是如果你以一个产品引领的思路来看的话，你某种意义上来说，第一，你在买模型彩票。因为即使你有一个比较好的 roadmap，其实你在最后完成 post-training 那一刻之前，你都不知道这个模型到底能不能达到你想象中的这样一个需求。所以很多时候你是因为有些突破，所以反向在引导产品的走向。这个我觉得我之前已经吃过这个亏，这是第一点。

第二点就是我刚才讲的：模型你即使能通过很多办法——比如说优化你的 pipeline、增加你的人手，或者让你整个这个链条更加的流畅——来增加你的迭代的速度，但其实这个世界上只要有产品经理存在，你一定是追不上产品经理脑思维的这个活跃度的。

所以我觉得比较健康的做法应该是：当你的产品已经初具 PMF、且已经到了一个比较稳定的状态下之后，你以一种增加稳定性、或降本、或突破天花板的思路，再去做模型。这是一个先后的问题。

你当过 CEO，然后也当过旁观 CEO 的人。你觉得身心健康对于现在 AI 的 founder 来说，价值大吗？有意义吗？

我觉得非常大。因为你很有可能会受挫，或者说你必然受挫，但是身心健康的人是打不死的。你能够一次一次很谦卑地重新站起来，再去很冷静地看待外界的变化，来回馈到你的一个决策的思路上。

这其实我觉得在我加入蝴蝶效应——我们这个母公司——之后，我们看见无数次这样的事：大家没有那种「因为我是一个身心不健康的人，或者我有过度的一种执念，而选择一种蛮干的思路」。我觉得整体就非常理智。

你们从几月聊到几月份，然后你加入了 Manus？其实中间隔了很久。

我有点记不清了，但我觉得前前后后应该有四个多月。

四个多月。我记得我第一次跟肖弘见面的时候，是在北京环宇荟，下楼的时候他说他刚跟你在这儿见了。你是在那里答应了他加入 Manus？

有可能。哎呀，这一年过得太快了，好多细节都想不起来了。我最后正式加入应该是 2024 年的 3 月。

年初加入的，所以 2023 年底开始聊的。

对，是的。

然后同期你也聊了很多那个时候出来做应用的 founder。

是的，对。也不仅是应用，就是刚才讲那三层嘛，其实都聊了。

大模型公司你有喜欢的公司吗？

大模型的话，肯定都聊了。反正当时其实可能比现在看起来更欣欣向荣一点。当时我比较喜欢两家——我不是马后炮，我觉得确实也是当时判断比较好——应该三家吧，我比较喜欢千问、DeepSeek 和 Kimi。

DeepSeek 当时也是因为很好玩，其实很早就跟他们有接触。是因为那时候我之前的一次创业是在做知识图谱构建，且同时我们自己从零搭建整个搜索引擎的 infra，所以其实我们有很大的预训练数据集，所以当时很早就跟 DeepSeek 的朋友认识了。但后来我没有把数据单独卖给他们，我直接把我们当时做的那个数据集开源了，但是也算是给大家留下一点遗产。

然后千问的话也是，因为跟他们那个团队的很多人都比较熟，然后当时就觉得千问做得非常扎实，而且它是真正第一个非常宽松的开源的模型，我觉得这个尊敬的程度是非常高的。而且另外一点就是，它让我看到了大厂里头一群年轻人能干出来的事情的一个表现，我觉得非常非常难得。

然后 Kimi 的话，一方面也是真格投资的嘛。甚至当时投 Kimi 的时候，因为我在真格，所以交流会比较多。然后我觉得首先这个公司是比较有品味的。

品味。

是的，taste 这个还是很重要。

技术品味吗？

我觉得「品味」这个词现在大家经常说，我可能会关注一个非常具体的一个指标——对不起，不该叫指标，不应该这样去 judge。就说大家常说品味，我觉得该怎么体现出来呢？品味可能体现在你的 evaluation，或者你内部的 benchmark 上。甚至我觉得这可能是创业公司——对不起，不是创业公司，是所有 AI 公司唯一的护城河。就是因为你自己内部的衡量指标，无论是对于模型的 benchmark，还是对于你人的激励，其实决定了你这家公司和产品该走的这个方向。所以我觉得这个还是很不错的。

那个时候也觉得自己不应该去大模型公司、而应该去应用公司的人，非常少吧？

是，我觉得这就是我刚才说我特别幸运的一点：我提前吃了很多大家后来才吃的亏。

他们今天开始吃了没？

我觉得很多人已经在吃了,且付出了更惨痛的教训。比如说,我觉得现在其实很多之前讲的一些国内大模型公司,可能从最开始不就是百模大战嘛,其实当然99个都已经先死掉了,最被大家提起的那几家,其实也有一些已经渐渐退出了这个赛道。我觉得这是挺正常的。

而且自从DeepSeek出来之后,我觉得还是对大家产生了很大的、很客观的冲击,就是它让一个模型的保质期变短了特别多。训大模型我觉得最痛苦的是什么?如果说我以前的痛苦是来自于我要做垂直整合、我要快速迭代,那现在就变成了另一种:如果你只做模型,你不是SOTA(State-of-the-Art)就没有意义;但一个SOTA模型,你的保质期其实只有1到1个半月。这是一种非常激烈的、不进则退的状态。

而且大模型,就像我刚才讲的,以前我们做NLP的时候,其实你能有很多不同的、你可以叫"赛道"的东西,比如我做信息抽取、你做别的东西,你所谓的"好"的指标是多元的;而大语言模型,或者说你这种Next Token Prediction范式的模型,它其实统一了各种任务的建模。虽然大家也说我要做coding、我要做多模态怎么样,但是世界上能够衡量的指标的维度其实非常清晰,你几乎没有多少腾挪的空间。但做产品稍微美妙的一点就是,你起码能够自己定义什么是好,所以你起码能在一个错位的赛道上去跟别人竞争,你有更多发挥的空间。

今天追求SOTA还有价值吗?

我觉得一定是有价值的。这个我觉得无论是模型公司,还是甚至是做Agent的公司,我觉得都要追求SOTA,这是一定的。因为还是刚才讲的那句话:你的evaluation,或者说你关注的那些、你选择的benchmark,决定了你的taste能否落地。

你从第一天就pass了这些大模型公司,你觉得他们的未来会怎么样?

我觉得其实是这样:大模型公司一定最后都会变成同时做模型、同时做应用的公司。其实你看美国现在这个版图,基本已经是这个方向了。OpenAI我认为它现在更像是两家公司,一个产品公司,和一个跟它有强关联、但并不绑定的research lab;而Google的话,始终它就是一个双向都很强的公司;而Anthropic,它可能之前还一直会比较关注说它做一个B To B market,比如它做它的Claude API,但其实Claude Code的巨大成功给了他们很多正向的激励。像他们自从Mike Krieger、就是他们现在的CPO加入之后,其实他们对产品的打磨也做得非常好。而且Mike Krieger他不仅是在做大家广义上来说的面向用户的产品,他对很多面向开发者的产品的把控也非常好,比如说大家对于像Claude Skills都给出很高的评价,这也是一种产品能力。

但是我觉得,这可能就是大家都会走向的那条路。反过来说,我觉得如果最后不再分大模型公司跟应用公司的话,那我认为其实做出一款好的、且被大家喜欢的应用,比做出一款够好的模型难得多。因为训模型这个东西,它的知识在业内的流通是非常非常快速的,尤其在硅谷没有壁垒?,你可能一个老公在OpenAI、他的老婆在Google,没有什么秘密,你知道吧。所以这个东西一定会流通的。所以我觉得到最后其实会变成一个应用之争,然后每个应用背后会绑一些模型。

所以未来模型公司和应用公司是没有那么泾渭分明的。

对,我觉得不会那么泾渭分明。

你刚才说你当时还聊了一些海外的公司,包括Google,你还聊哪些公司?当时对他们怎么看?在2023年,对吧?

对。其实当时的话,几乎所有在做模型的公司我都聊了。然后当时其实23年初我也录了一个podcast,当时还是以真格的那个EIR的身份去录的,说了些暴论,现在来看还都对,太幸运了。

对,然后当时我其实比较看重几点,这个都是有史可查的,不是事后诸葛亮。第一个是23年初我说我关注long context——当然这个待会可能聊到,我觉得这个错了。第二点当时比较关注的,就是在自然语言和系统的边界,你可以说是function calling,或者说跟environment的互动,其实就是现在Agent这些东西,这是我当时比较关注的一点。然后第三点,这个其实当时那个分享中没提,但我其实还挺信scale up这个事的,因为这也是大家常说的那个Bitter Lesson、就是苦涩的教训这件事:人类历史上AI的进步基本全是用通用方法加投入更大的算力,而不是增加人为的专家知识的注入。所以当时对于scaling这个事,一方面是很看好,然后很早买了英伟达股票。对,然后这是……

谁的股票?

NVIDIA。

好。

然后当时我心里会觉得,Google最后一定会很厉害。对,但是它确实用了很久才很厉害。(笑)

你加入Manus是2024年的3月份,那到24年10月份,你在做什么?

对,这个其实也是——我忘了肖弘之前有没有跟大家分享过一件事,就是他为什么叫我加入,且用那句话说服我,就说:想不想把浏览器、搜索引擎和大语言模型再做一次?

因为当时我觉得我们大家整体做了一个错误判断。当时Monica已经有了一定的用户量,我们会觉得,也许我们可能是当前世界上最懂用户怎么在浏览器里用AI的团队,那么我们一个直觉的、惯性的外推就是:我们要不要做一款浏览器?这个想法其实是比较有数据支撑的,就是刚才讲的比较理性地去看这个事,因为Monica当时已经是资金流正向的,且增长还不错。

但其实有一点很好玩:如果你去看Chrome的那个插件商店的话,你能看见所有别的产品的活跃和下载量,因为它这是一个很透明的生态。当时你看整个插件生态里头的头两名,分别是AdBlock、就是去广告的,和Grammarly、就是帮大家改语法的。其实他们做了很多年,对吧,他们产品力绝对没有问题,是非常polished的产品,但他们最后都停留在大概5000万左右的量级。5000万对于一家创业公司来说确实是很大,但如果你跟整体Chrome这个浏览器的日活比的话——Chrome的日活我记得能有20亿吧,如果没有记错,因为我也没有准备,可能数据有错——我们当时觉得,好像我们做到底也只能渗透到比如不到1%的Chrome用户,因为插件真的是一个形态比较高阶的模式,好多普通用户其实甚至不知道Chrome能装浏览器插件。

所以我们当时第一直觉是:也许我们被插件这个东西给约束住了。而我们当时想得也比较天真,我们想的是,我们能不能跳出插件,变成一款独立的、原生的浏览器,装在用户的电脑上;同时这样的话还能做一些别的事情,比如说我们可以做端侧的模型——当然这个其实就是一个坑,待会儿我会讲的。

然后我们当时就开始做浏览器,大家都很兴奋,从我加入之后马上就快马加鞭开始搞,一直从4月份搞到了大概9月份。我们大家做事还挺快的,其实内部已经早就有一个能用的浏览器产品。然后我们内部摸了一圈之后,意识到这事有问题。

怎么有问题?

对,这个有问题的点非常好玩,就是我们当时做的……

当时张涛加入了吗?

加入了。

他是几月份?

我是4月份加入,涛哥应该在一两个月之后就加入了。

你给大家来介绍一下你们这几个co-founder吧,因为大家都分不清楚你们这几个人。

对,我觉得这是一件特别棒的事。为什么呢?我先开个玩笑:为什么我觉得不当CEO很好?因为虽然Manus的宣传片基本是我出镜——

为什么是你出镜?

因为要说英语。然后这时候自然有人支持、有人骂,对吧,他们看着宣传片骂的都是"这肖弘太坏了",所以感谢肖弘帮我挡了很多枪。

然后是这样的:整个Manus这个团队,或者说蝴蝶效应这家公司,其实我们有六位合伙人。

我都不知道。

对对对。其实主要就是,平时在外面可能露脸稍微多一些的是张涛,我们的CPO,他会负责很多,无论是产品,以及其实更多的比如说与外部的对接,包括一些对外的宣讲,这是张涛。张涛之前也是一个非常非常senior的连续创业者,他经历了豌豆荚、神策、后来光年之外都做过。然后这是张涛。

他负责产品。

对,他负责产品以及对外的这些合作。然后是肖弘Red,他是我们的CEO;然后还有我们的CTO潘潘,以及我们的CMO慧杰。他们三个其实是之前就一直在一起创业,做过两三家公司了,他们其实是Monica最原始的三位创始人。对。然后再之后就是我,还有我们的COO CZ(陈哲),她一直负责比如说公司运营、财务相关的工作。所以其实我们是有六位同事是合伙人。

现在创业公司团队会变得更大是吗?

对,因为它需要能力更复合。我觉得其实是这样的:首先,现在可能有一个外界的观点,说在AI时代团队会变得更小。我们觉得这个东西,首先你不应该把它作为一个指标,或者说它应该是一个被动的指标——我们绝对不会为了团队规模而进行任何特殊的优化,我们只会自然而然地去观察团队规模的变化。但我觉得确实如你所说,有一点就是:现在你很难去分清各个能力项,因为你很难做到完全正交。像比如我们做Agent这个行业的话,其实你的research跟engineering是很深地耦合的,而产品你又在同时引导你到底这个系统架构该怎么做。所以确实,我们这六个人基本全都是连续创业者。

而且之前大家可能都扮演过不止一个岗位，所以我觉得这也是大家合作比较好的一个点。但与此同时，你又很难得能找到一些在自己领域做得很深、却又能听得进去别人话的人。这就是我说，我们是一个非常难得的团队，因为我们六个人都身心健康、无不良嗜好，而且观念不极端。

你讲的不良嗜好，都是什么样的不良嗜好？

我开玩笑的。至少烟酒我们都不太沾。

你们的决策机制是什么样的？

我觉得这是我们一直在持续改进的一件事。创业公司其实在不同阶段、或者说你在解决不同的事情的时候，需要不同的决策模式。我们认为，虽然我们是连续创业者，但其实我们也都不成熟，最近在逐渐走向一个更理智的方式。

我们可能这样总结：你要把管理分成几种不同的类型。一种是专制的，英文有个词叫 BDFL，就是 Benevolent Dictator for Life，仁慈的终身独裁者，这我们叫集权式的；还有一种就是民主式的。

我们觉得，如果你把整个决策?分为三个阶段的话，可能叫 GPA：G 就是 Goal，你在定目标；P 就是你要定优先级 Priority；A 就是 Alternatives，就是有不同的选项。在决定这三件事的时候，你要用不同的模式。

你在定 Goal 的时候，应该是一个比较专制的模式，相当于比如 Red 作为 CEO，他应该把大家的目标给定死。而在决定 Priority 的时候，应该是一个专制加民主的决策形式，比如说首先有一个人能拍板，但是大家能充分发挥自己的意见，因为这块会涉及更多不同的专业 expertise 这些东西。而在大家提供方案、就是 Alternatives 的时候，是一个充分民主的阶段，因为在这个阶段，也许我们觉得可选方案的数量甚至比质量更重要——很多时候如果你没有足够多的数量，你的决策空间其实一直是非最优的。就好比你训练了一个模型，但你的 action space 本身就有问题，那你挑什么呢？对吧。

所以我觉得这是一个混合的模式。但我觉得我们还都非常业余，最近也在不断学习这些事。

有什么样的事是肖弘会拍的吗？有什么事情是他一个人会拍的吗？

会的。我觉得肖弘还是作为产品方面最终的决策者，我们觉得这是非常重要的一点。包括我自己都比较相信的一件事，就是与其悬而未决，不如赶紧试试。因为好多时候我们在做一个新的领域的时候，第一，你过往的经验不一定有用；第二点，你现在想得更多，其实你并没有额外的信息输入，对吧？你仍然是基于你模型内部的参数化知识，没有做 RAG（检索增强生成），对吧？你也没有一个检验的结果。那你与其想太多，不如先把这个事干了，拿到你的 reward 再去做。这一直是我们核心的一个指导思想。

所以他做 CEO 和你做 CEO 的区别，你可能是技术驱动，他可能是产品驱动的。

对。

这会导致你们公司的基因是一个产品驱动的基因。

是的。但是我觉得肖弘我非常尊敬他的点，就是他也充分尊重我。比如说对于一些技术方面的决策，我也是可以做技术领域的 BDFL，就是我可以当技术方面的独裁者，这也是可以的。

所以整体是自上而下还是自下而上？

我觉得我们在逐渐从一个自上而下的体系，尽量去变成自下而上。因为随着团队的扩张和团队成员质量的不断提升，我们觉得自下而上会有更大的动力。像之前的话，比如我们在一个纯粹快节奏的过程中，自上而下可能是一个更稳健的做法；但现在我们在逐渐地变得更成熟。

我们刚才在聊 4 月到 10 月份你在做什么。

对。对不起，我都已经聊远了。当时我们做了其实很多事情，但其实围绕的一个目的，就是如何做一款 AI native 的浏览器，就是所谓的 AI 原生浏览器。当时做出来的产品形态，其实跟现在的 ChatGPT Atlas、还有像 Dia 也已经很像了。

当时我们想的这个切入点有几个。第一，就是说我们要训练一个端侧的模型，来让一些操作能够在用户的电脑上去完成，既不产生 API 消耗，同时也是充分尊重用户的隐私。这里就埋了第一个很傻的坑：拜托，你做的是一款浏览器，浏览器本身就是联网的，你为什么要追求一个离线的端侧运行？现在想起来可能有点傻。第二点，用户其实大部分时候不会关注你到底是离线的还是怎样的，他们要的是最好的效果。而当时你其实在电脑上，比如说即使你只做苹果 Apple Silicon 芯片，你其实也就跑一个 3B 左右的模型，就已经差不多是极限了。那用户会拿你跟云端的旗舰模型去对比，你的效果一定会差一些。这是我们想的第一点，现在觉得很可笑。

第二点，其实之前有很多人在做的事情，就是想让 AI 接管用户的浏览器，来完成一些自动化的工作流。这个事我们当然也做了，但这就是我刚才讲的为什么不对劲，我可以展开讲一下。我们觉得有几点吧，可以细数一下。

第一点，如果你让 AI 接管用户的电脑的话，你会发现一种很奇怪的使用体验。比如说我让 AI 去帮我在一个网页上完成填表，那这个时候，比如 AI 当它填了一个字段之后，我一滚屏幕——比如我想看看下面——我其实打破了 AI 的 observation（观察），这可能待会儿再解释吧，就是 Agent 工作的一个流程。那这时候 Agent 可能会把这个网页又拉了回来，那这个体验很奇怪。就好比你有一个特别聪明的实习生，但你好像非要把你跟实习生一起共用一台电脑，这个体验就很怪，就是两个人在一起抢一个系统。而实际上，我们现在用的所有的操作系统和软件，本质上来说还是为一个人同时使用设计的，所以这个体验就不好。

第二点我们发现，什么样的任务真正是有价值的？因为包括现在也有很多人在做所谓的 GUI agent，就是用户界面自动控制的 Agent。你会发现，如果你让它去完成一些你通过简单几次点击就能完成的任务的话，你觉得是很亏的，因为你的迅速的决策其实比 AI 还要快。而即使让它比如很简单地帮我点一个外卖，它可能每两步之间的推理也会 5 秒、10 秒这样的一个时间——当然现在会更快——但你会觉得这好像没有产生多大的价值，对吧？我干更快。这是我们常见的一个想法。

那 AI 真正有价值的，应该是那种长任务，就是 Long Horizon Task：它的范围很广，它也许超过了我的能力，或者说它要运行很长时间，且运行很长时间或者多步几乎是一个必然的事。因为这种任务我才不愿意做，我才想交给 AI 去做。但这个时候会有一个问题：因为你做的是一款原生的 AI 浏览器，那这时候 AI 其实是在你的电脑上运行的。虽然我不说模型在你电脑上，但是它在持续操纵你的电脑，那就很尴尬——我不能把我的电脑盖上，我电脑盖上之后我的电脑就休眠了、就卡死了。那怎么样在 AI 在持续进行长时任务的时候，我还要一直盯着它们、保证我电脑不睡眠吗？我自己又不好干别的。

所以我觉得这两种体验，我们用的都觉得非常的奇怪。当然这只是一个模模糊糊觉得奇怪的点。其实更大的一个问题是，我们觉得团队没能回答一个核心拷问：到底做了这样一款原生的 AI 浏览器之后，有什么是我们本来的 Chrome 加 Monica 做不到的吗？好像没有。

然后我们就开始逐渐变得理智。我觉得这个过程也很重要：当你做完一个产品的时候，你会站在一个想说服自己的立场上，即使我们都是中登连续创业者，大家还是会有这样的惯性——我刚做完一个东西，我起码自己还是偏心于自己一点的。但当你逐渐发现更多这些问题暴露出来之后，你会更趋向于一个冷静的判断。

然后我们越想越觉得这事不对。人类历史上浏览器的迁移其实有几次，好像也就两次吧：一次是从网景（Netscape）到 IE，还有一次是从 IE 到 Chrome。这两次变革的根本原因其实还是 Distribution，就是你的渠道分发能力所决定的。IE 是通过预装；而 Chrome 它可能稍微复杂一点，一方面当时 Google 已经成为事实上大家的首页，且同时 IE 遇见了一些非常严重的技术问题，包括安全问题，这是一个历史机遇。但是如果我们现在是在一个 Chrome 运行已经很好、且有 Monica 这样优秀的插件在的一个生态里头，用户有多大的动力会愿意因为 AI 而把自己的浏览器换成一个新的呢？

所以当时我们就开始思考这个问题，但是心里还是没有最终下决定要怎么办。直到又是后来这个老天帮忙：我们有一天上网看推特，发现我们很尊敬的一家美国创业公司，叫做 The Browser Company，它做的一款浏览器可能很多朋友用过，叫做 Arc。Arc 是一款主打设计感、以及后来也有些 AI 功能的浏览器，它很受一些小众的极客的喜欢，比如它率先做了那种竖排的 Tab 边栏。然后突然创始人 Josh Miller 说，我决定 discontinue Arc，就是我不做 Arc 了。这是一个很大的决定。然后他说的原因一下就跟我们共鸣了：他说我做 Arc 这么久，我甚至无法说服我的亲戚朋友从 Chrome 换成 Arc。所以我们觉得，好吧，他已经把我们心里的担忧黑纸白字地写出来了。我们就觉得，可能真的浏览器不适合创业公司去做颠覆。

做了两遍浏览器，对吧？

对，这是我的第二遍浏览器，然后又得到了相同的结论。当然可能之前我没有这么系统性地想过这个问题，因为那时候还是像我刚才讲的，凭爱好在往前冲的这样一个状态；而这次我们其实很理智地想了这件事，觉得这个不太对。但是也是比较幸运，当时看到一些别的、就是一些苗头。

几月份停的这个项目？

当时是这样。我们从我加入，2024 年 4 月，浏览器其实到 8 月就可用了，但是 8 月、9 月，甚至一直快到 10 月的时候，其实心里还是有些波动。所以真正停掉，应该算是 9 月底吧。

Red?说他当时就觉得浏览器有点不对，但是不敢跟团队说，原因是你们都是被他用浏览器忽悠进团队的，所以觉得——特别是你吧？

其实我觉得，应该说是我跟张涛。

对，你和张涛。

对对对，他肯定是这样。这也是 Red 比较好的一点，就是他非常会考虑大家的感受，而不是以艺术家的方式去解决一些问题。但是那段时间，其实反过来看，我们觉得特别宝贵：大家在一个很自然而然地形成共识的过程中，逐渐放下了浏览器这件事，处于一种几乎无所事事的状态。而当一群不太笨的人无所事事的时候，就会产生很多很好的想法。

所以你们是怎么达成这个"要放弃浏览器"的共识的？是他来找你说的吗？

其实每个人心里都会提前感觉到一些不对。我觉得一个最典型的点，就是当你一款产品你觉得已经打磨好之后，你突然觉得它不是特别酷。这个产品就……如果按今天的话，我可以断言：如果一个产品做完，你觉得不太酷，就别发。你都觉得不酷，没人会觉得酷。

"不是特别酷"——这个表达很艺术家。

对，这是非常艺术家的一件事。因为我此刻是站在用户的立场上：如果你本该最喜欢这个产品的人，你都不觉得喜欢，那你怎么奢望用户会喜欢你呢？对吧。我不是以一个决策者的角度在说这个，我是站在用户的身份去想。

在一个新的时代，把上一个时代的产品重新做一遍，你觉得是一个好的创业思路吗？

我觉得这个话不能非常一概而论地去判断。首先，我有一句特别喜欢的名言，叫做"For Every Complex Problem, There is an Answer that is Clear, Simple, and Wrong."，就是说，对任何一个复杂问题，总能有一个简单、清晰但错误的回答。我觉得我们很多时候都在过度总结一些事情。所以这件事我不能二元地直接就去切分它。

但我觉得这确实是值得警醒的，因为很多时候大家选择这种做法，是基于一种思维的惰性：你在参考过去一个时代成功的因素，并想要用一种新的技术去把它再做一遍，但其实你要考虑到环境、一个外部环境的变化。所以我觉得这不能二元地去切分。

你们放下了 AI 浏览器这个产品，但是其他团队还有在探索的。你觉得 AI 浏览器的未来会怎么样？

我觉得我不能替别的浏览器做主，而且我不是说因为我们放弃这事，这事就一定不对。是因为我们团队自己达成的共识是：我们做这个东西的收益可能不是特别明显。因为你想，如果我们选择另一种心态，就是说这个产品好像不是特别酷，但既然已经做完了，我们就发出来看看——这时候会把你带入到一个比较不好的漩涡中：当你发了一款产品之后，一个负责任的团队会持续维护它，但这会带来很大的机会成本，我们可能因为要不断进入一种自证的循环中，去错失明明更有价值的新机会。

而如果有一个团队现在已经把 AI 浏览器做到一个他们已经比较满意的程度的话，那我觉得你进入一个自证的循环应该是对的。因为你可能今天是一款所谓的 AI 浏览器，但沿着你自己选择的这条路，你也许会发展出一个完全不一样的产品形态，没人知道会怎么样。所以我觉得我不能替别人做这个决定。

你看，Red 说服你加入，说的是"在一个产品里把浏览器、搜索引擎和大语言模型全部重做一次"。然后到了 2024 年的 9 月、10 月，你们决定放弃浏览器这个项目，当时心里有波动吧？你的真实想法是啥？你会觉得被他骗了吗？

我觉得其实不会。我刚才讲到的一点就是，他只是最后用这句话说服我加入，但我肯定不会只因为一句话就被说服，对吧？

所以我觉得我非常珍惜的一段，还是首先我们通过 Monica 真正拿到了一张理智的 AI 应用的船票，这是非常重要的一点。就是 Monica，我觉得这个产品的意义是非常大的。第一，它是一个正向现金流的产品——这个词我们可能会说很多很多遍，正向现金流的产品。一个团队如果有一个正向现金流的产品，你在做第二曲线的决策的时候，你会变得非常理智，或者说你既大胆也理智。我们之所以后面敢豪赌很多的东西，是因为我们知道 Monica 一直在帮我们赚钱，所以我们会有一个非常客观又大胆的方式去做决策。

第二点，就是 Monica 真的让我们知道用户在如何用 AI，让我们理解了 context 的重要性。或者说，Monica 这款产品其实跟 chatbot 最大的区别是什么？就是如果你在用 chatbot 的话，你一定要做的一件事，是把你要看的网页的内容复制粘贴进 chatbot 的对话框中；而 Monica 它本身就是一个主动地去观测你的 context 的东西，对吧？你只要在用浏览器，浏览器插件就在看着，它其实就把 context 的传递变得非常通畅。这其实给我们很大的启发。

以及更具体的，就是我们知道一些用户整体的行为习惯。当然我们会非常尊重用户的隐私，我们不会去窥探你具体的 session，但你其实通过一些宏观的脱敏统计数据，能看出很多 pattern——很多模式，对不起。

为什么这些产品都是 M 开头？还包括你之前的公司。

对，这个我觉得是很好玩。我第一个产品叫猛犸浏览器（Mammoth），M 开头；第二款产品叫 Magi，M 开头；然后 Monica，M 开头；Manus 也是 M 开头。然后我觉得这完全就是一个巧合，可能 M 开头的产品运气都不会太差。当然 Manus 可能有一点私心，因为名字是我起的。

怎么取的这名字？

这个名字其实当时我们纠结过很多名字，但是后来真正让我们想通这件事的一个点，是我们想明白了自己该做什么。就是当时，其实做浏览器的时候我们已经依稀有一个感觉：模型在解决的是智力，但是再强的智能，你也不能把环境给内化掉，所以你一定是需要一只手，来去触及到现实世界中；否则你再强的思维，你也只是一个理论物理学家，或者说甚至你可以说是一个缸中之脑。所以我们想做的，是让智能真正去触及现实世界。

所以这让我想到了 MIT 的校训，叫 Mens et Manus，是一个拉丁语，翻译成中文叫"心与手"，或者"心手合一"。我们觉得别人都已经在"心"、或者说心智这件事上做了很远的探索——所有的基座模型公司使命如此——而我们要做的其实是那个"手"。所以 Manus 就是拉丁语"手"的意思。

说说你们在那段闲散的、无所事事的时间里，怎么产生 Manus 这个 idea 吧。

对，这个其实是一个……

这是到 10 月，对吧？

对，其实是一个渐进的过程。然后我觉得又一次是上天赏饭吃。当时大家还在正常地运营 Monica，同时也会做一些别的实验。但是当时我们会发现，那个阶段下已经有一些 AI 产品受欢迎，尤其是 coding 领域的，那时候像 Cursor、Windsurf，包括后来的 Devin，其实有很多用户。然后我们作为工程师，我们肯定会用，对吧？然后我们发现，其实公司里头很多非工程师都在用 Cursor，这个就让我们很意外。因为 Cursor 它的产品形态仍然是一个 IDE，就是集成式开发环境，写代码的人才用的一个东西。然后我们发现，比如公司的运营同事，他居然在用 Cursor 去写博客；我们的数据分析同事，在用 Cursor 进行数据分析和可视化。这个就让我们非常意外：它本来是一个最专业的产品形态，却有很多它非原始设定的目标用户群在用。

然后我们就会去站在他们身后，去观察他们到底在怎么用 Cursor。很好玩，就是因为左边都是代码，右边是它那个跟 AI 聊天的窗口，很多这些同事他们也不会写代码，他们根本不看左边的东西，他们就是在不断地跟 AI 去交流，让它去把一个事情完成——AI 通过编程的方式，以编程或者代码为媒介，去完成一些非编码任务。那我们觉得这其实是非常重要的一点，就是让我们意识到：编程不是一个垂直能力，编程其实是一个通用能力，它是解决通用任务的一个媒介。

那这时候我们要想的，就是 Cursor 这个形态其实对他们来说不是最优的，有几点。一个是我们刚才做浏览器那个尝试的时候学到的，就是说，它不应该跑在你的电脑上，要不然它不能解放你在长程任务中的注意力问题。其实老说 Attention is All You Need，我们希望解脱用户的 attention，让模型能在——对不起，让 Agent 在云端去运行，去异步地执行。有异步之后，其实还带来另外一件事，就是并发：如果你能让很多不同的任务在同时去跑的话，这才是真正的成倍提升你的效率。所以这是第一点，我们认为 Cursor 这种产品，它应该换一种产品形态，跑在云上。

第二点，就是代码这件事应该作为一个工具，而不是它一个主要的呈现。因为对于很多人来说，看见代码是有一点天然的紧张感的，对吧？尤其它跑在你的电脑上，Cursor 会经常问你一些权限，就是说"我想安装这个软件"、"我能不能把这个文件删掉"。其实这个对于很多用户来说，你看不懂技术名词之后，你唯一的选择就是"好，接受、接受"，但这个很恐怖。我们有一个朋友，他当时就用 Cursor，他也不懂技术，就瞎用，结果 Cursor 把他的网卡驱动给卸了，然后电脑就上不了网。所以我们觉得不行，应该就是用同样的技术，但把技术复杂度包装起来。

然后第三点就是，这个产品面向的人是谁？其实不应该是专业的工程师。专业工程师这个领域的卷度已经几乎饱和，它是一个绝对的主航道。所以我们应该面向的用户，按我们的话说叫 prosumers。

或者说所有的脑力工作者，但你却不是程序员。因此我们就觉得，应该改变一种产品形态。很幸运的是，当时在浏览器上我们已经做了很多技术积累，比如说我们对 Chromium 内核非常了解，我们自己也做了整套 agentic 的调度系统，所以对我们来说好像这个事也没有那么难——我们要做的就是把整体 AI 浏览器这个东西搬到云上。

所以我们当时内部立了一个项，也是我瞎拍脑袋起的一个项目代号，叫 AirBnB。是什么意思呢？叫 Browser in Browser in the Air，就是浏览器里面运行的浏览器，且跑在云上。所以也比较幸运，就是我们并没有浪费太多当时做浏览器期间的技术积累。

所以当时从 9 月底、10 月开始正式搞，其实也就 6 个月就把 Manus 做成了。实际上 Manus 不是 3 月做完的，Manus 其实 1 月就做完了。

从几月开始搞？

我们从 9 月底开始搞，到 2025 年的 1 月中，其实 Manus 基本就做完了。但当时我是决定说，我们不该马上就发。

为什么呀？

因为是这样：当时我们能拿到最好的模型是 Claude 3.5 Sonnet v2，就是 Claude 3.5 的第二次迭代。它初步具备了一些 agentic 能力，但是它其实会有一些问题。比如说从技术角度来讲，它缺乏一个真正的 reasoning 能力。另外一点就是，我当时也听到了一些 rumor，就是他们应该在两个月后会有一次模型发布。当然我也不知道最后 Claude 3.7 会有多好，但是我觉得我们最好能把我们发布的时间点跟下一次模型迭代对齐，这样其实我们的产品发布的一瞬间，就能享受到最大的一个代际的提升——模型的溢出。

所以我们应该再多花一个半月的时间去打磨这款产品，然后跟下一次模型的迭代对齐，再一起发布。

那你们从放弃浏览器那个项目，到想到 Manus 这个 idea，中间是很短的时间。

其实你可以说短，也不短。我觉得当时真正意义上可以堪称无所事事的时间有两周半。

这么短？那很短啊。

是。其实那段时间也不能说无所事事，我们都很积极地做很多不同的实验。

那时候焦虑吗？

我不焦虑，一点不焦虑。这就是为什么我们说，有一款正向现金流的产品很重要。当时我们的想法就是：大家想想吧，虽然可能烧了一些钱……

烧了多少钱做那个浏览器？

浏览器其实还好，因为我们当时投入的人力可能也就十几个人，除了人力以外其实没有太多别的成本。

Monica 当时能给你们赚多少钱？

Monica 其实在 Manus 上线之后，我们的投入可能少了，当然现在可能又抓起来了。但当时 Monica 已经有接近 12 个 million、就是 1200 万美金的 ARR，而且它是一个盈利的产品。跟现在的 Manus 相比，1200 万美金 ARR 不算什么，但是在那个时候，对一款 AI 产品来说，我觉得是很棒的一个成绩。

这是 Vibe ARR（氛围年化经常性收入）吗？

当然不是 Vibe ARR。我们非常看重这点，就是我们一直在强调什么是 ARR。ARR 是 MRR 乘以 12，那 MRR 是什么东西？你不能把你一个月内获得的年付算在当月之内，你必须得除到每一个月。所以我们内部看 ARR 或者 MRR，我们就一个口径：就是你看你 Stripe 上面给你的 MRR 数据，以及你移动端的 MRR 数据。要不然的话，你有太多种方法去把这个 MRR 数字造得很大，但这个就是你自己骗自己。

刚才我说的，这也是一种 benchmark。对于产品来说，这可能是你要优化的一个指标；对于模型来说，你要选一些 benchmark 作为你优化的方向。这两个都会共同决定你的 taste。所以我觉得这是非常重要的一点，我们非常抵制 Vibe ARR 这个事。

Manus 现在有多少 ARR？

Manus 现在 1 亿，已经超过了，1 亿美金。

然后是这样：我们之前还有一种比较复合的收费模式，就是说你除了订阅以外，你还会有 top-up，就是你可以额外去增加一些单次的充值。但是我们觉得这样虽然确实给用户很大的灵活度，其实也给用户造成了很多困扰。所以我们现在不断去简化定价方案。目前基本就是，你可以很简单地理解为：你有一个免费的方案，以及一个你可以自由选择订阅金额的方案，默认是 40 美金一个月。

你从 3 月到 9 月，加入这家公司以后这半年，你对它的感受有什么变化吗？

我觉得有一些变化吧。首先就是，它跟我之前所在的创业模式特别不一样。之前有可能是一种非常……较为慢节奏、其实比较谨慎的一个状态，一旦你要做一些技术层面的决定或者赌注，你会比较慎重。但是如果你是一家完全以产品驱动的公司，你会发现整体的节奏会快特别多。甚至一开始说实话我是有些不适应的，我会觉得好多事为什么这么草率。

为什么产品会更快？

产品一定更快。因为产品的话，你迭代的成本首先会更低一点——因为刚才讲了，你首先没有垂直整合模型这个问题。第二点就是，你如果一切都以敏捷开发的方式来做，甚至很多时候你可以说，我先发了再看看有没有什么问题，我再修。

但是你知道，如果你自己训过模型，在进行数据清洗的时候，那个代码你最好别让 AI 写。因为你洗好那个数据，你按下回车之后，你可能会有一个几十万美金的 training run，你的心理压力程度是不一样的。就是经常你要做技术或者模型层面的工作的时候，你很多做的事情是有后效性的——你做了这件事，做完之后很难被轻易地纠正，或者说它就会在历史长河中留下一些问题。但产品的话，你的掉头会非常快。

所以我觉得这个团队很好地践行了这一点，而我可能花了一两个月时间才逐渐适应。

很多研究员或者技术风格的人不喜欢这种方式，他就会觉得这个技术文化比较差，他觉得太快了，他觉得没有真正的技术 Bet。对你来说没有这种问题吗？

我觉得是这样：技术 Bet 这个东西是听起来非常好的一件事。如果你是家硬科技公司，你该做这个 Bet，因为这可能是你最终的差异化所在。但如果你是一家产品公司，那么你就不该有 Bet 这个概念，或者说你会进行一些轻量级的、可逆的 Bet——大家不是经常说双向门决策、单向门决策吗？如果你做一家产品公司，你还在天天想着你要不要 Bet 什么东西，那我觉得你们是处于一个比较拧巴的状态，这个还是要调整一下。

所以你们没有 Bet？

其实这么说吧，就是我们所有的 Bet 都不会是那么重的 Bet。

没有技术 Bet？

技术 Bet 也有，但是所有的技术 Bet 都不会是那种——比如说我需要两个月的时间，去看到下一个预训练 checkpoint 之后，我再决定怎么样——就是这个"皇国兴衰在此一役"这种事不会有。比如说一些模型公司的话，我觉得你还是要有一些 Bet 的。这就是我觉得两种 mindset 的不同。

那你们的 Bet 是什么呢？

产品形态，一个产品形态。其实你可以说，一开始不训模型这件事也是一个 Bet。因为那时候我们开始做这个决定，可能现在大家逐渐——也许是在我到处游说之下——大家接受了这件事，但是那时候其实很多人还是不太看好所谓的 context engineering 这件事。尤其是我们当时开始做……

壳。

对，"壳"这个词其实我挺喜欢的。因为"壳"这个词，它严格意义上来说，你可以从操作系统的概念叫 shell，shell 可不是一个低技术门槛的事。而且壳跟壳也有高低，这我可以举一个比喻：如果 Monica 它明显是个套壳，它其实像生鱼片。就是说生鱼片的好坏基本完全取决于原材料，就是你从海里捞出的那个鱼怎么样，你几乎是一个没太加工的状态就给用户了，所以你的价值增加是很浅的。

但是像 Manus 这种东西，它仍然是一个壳，但是它不是生鱼片，它也许是什么水煮鱼或者什么——因为海鲜过敏没有吃过，可能不知道它是不是很复杂的东西——什么四川水煮鱼这种东西。

Agent 跟 Chatbot 最大区别是什么？

就是 chatbot 这整个系统里只有两个元素：人、用户，以及模型。你们两个之间以往复的形式去交互。但其实 agent 有第三个元素，是环境或者叫 runtime，这个东西其实是很重的一个事。所以你 agent 这个壳，跟 chatbot 相比，完全就不是一个厚度的壳，它是地壳一样厚的一个壳。

所以 Manus 做出来最难的是什么呀？

Manus 我觉得有几个非常难的点。第一个就是，你启动越早你越难。首先你能相信 Manus 这个东西能够做出来，这个是我认为第一个很难的事情。

第一个 idea 是什么？

第一个 idea 其实就是从浏览器的自动化放上云端去。

这是你想的吗？

这个我觉得是大家都会看到的一个点，就是我刚才讲的，大家一起商量。但是我觉得我们看到 Cursor 之后，其实 Cursor 帮我们把很多事情理清了，所以我们一直都非常尊重且欣赏 Cursor 这个公司，它给我们很多的 idea。

然后我觉得这就是第一个点。其实好多人说，造出原子弹没那么难，但相信原子弹能被造出来才是最难的。而当时我们相当于定义了所谓"通用 Agent"这个词，在这个时候我们觉得，首先我们能够相信 Manus 能造出来。

这就是一个 Bet。

对。因为它需要我们……也没有举公司之力，当时也没有那么多人在这个项目，那时候非常少。我们一开始从五个人开始做实验，然后每遇见一点好的苗头，我们就会从 Monica 里面调动更多的同学进来。

所以 Monica 当时有多少人运营？

Monica 当时团队应该有几十个人。

几十个人，然后你这边五个，大概公司就是这个架构，对吧？

对。而且当时我们还是分两边……

我跟涛哥在北京,而肖弘、也就是 Monica 团队主要在武汉。所以当时北京这边,你基本可以理解成一个创新业务事业部,这样的一个——

寻找第二曲线。

对,寻找第二曲线。所以这是一个渐进加码的过程。

所以你看,这也是一个比较理智的做法,对吧?没有那种旧的不做了、全都去搞新的。

对,逐步去做。

我觉得这是第一个 bet:Manus 这种产品形态的东西是能够被制造出来的。这是第一个 bet。

第二点,其实开始做之后我们也确实犹豫过,要不要开始训模型。因为当时你能拿到的基座模型,用起来真的是很难受的。Claude 3.5 Sonnet v2 也许算是一个里程碑吧,但按今天的眼光看,它的稳定性、可靠性和泛化性其实还差非常非常多。而且直到今天,很多模型都还没有解决一个问题:现在大部分模型,我认为仍然是为 chatbot 场景而进行后训练的,这就存在一个 alignment 问题,待会可能会进一步去讲这个问题。所以当时遇见了一个客观的挑战:我们要不要通过自己做模型这件事,来弥补这个模型的不足?但我觉得,我们又是在一个技术快速上升的阶段——因为你刚刚看到 Claude 3.5 的 v1 跟 v2 之间的进步有多大——所以我觉得我不该 bet 在这个方向上,而应该 bet 另外一件事,一个很轻量的 bet:当时还没有 context engineering 这个词,我们应该充分相信,做 agent 框架是能够带来很大提升的。这是当时做的第二个 bet。

然后第三个 bet 是什么呢?就是我们已经看见 Cursor 获得很大的成功,而且很多人心里其实也会有一种想法:我们是不是该做和 Cursor 类似的事,做一个中国版 Cursor?很多人可能现在也在做这个事情。但这件事当时至少我心里还是比较坚持的,因为可能一直以来,我创业获得的正反馈都来自于创新,所以我觉得这还是挺开心的一件事——我们应该去做一些有差异化的事情,去服务好那些 prosumers,而不是跟他们挤在一起去卷。

反正这是当时做的三个判断,然后比较幸运,好像都对了。

这些判断好像很多都是"我不做什么"——想了、思考很长时间,决定我不做什么。

对,是的。我觉得"不做什么"真的特别重要。因为 AI 我觉得最大的一点,就是它让创业公司的产能变得很大。以前,比如我们之前做移动互联网创业的时候,大家可能没有那种"我不做什么"的自由:我在做某一个领域,我要做一个新的领域或者业务的时候,我受很多的约束,外部的因素会阻止你一些过于天马行空的想法。但 AI 时代,大家眼中的机会好像很多,AI 又充分解放了生产力,所以我觉得每天都要回答"不做什么"。

Manus 到现在我觉得都是一款相对克制的产品。像有一些别的 agent 公司,他可能会觉得我要增加很多不同的 tool,给 AI、给 Agent 增加很多不同的工具;而我们每个月都在想:我能删掉什么。所以"不做什么"仍然是我们始终要想的一个命题,即使是通用 agent。

Manus 是不是有一个很重要的点,是在那个时候没有做一个"中国版的谁谁谁"?Manus 那时候是没有一个对标的。

是的。我觉得至少我自己的几次创业,我从来没有想过对标这个事。

为什么你们要做一个通用的 agent?

对,这也是一个特别好的问题。按照传统的创业理念,大家可能应该是这样:选中一个利基市场(Niche Market),或者找见一个垂直领域,扎进去做深,这可能是更正常的一个做法。但实际上,我是有几个不同角度的观察,既有技术、又有产品形态的思考。

首先一点是技术层面。我上一次创业其实就经历了一种专有模型被一个大一统模型吃掉的体验。所以在现在这套技术体系之下,即使你在做一个垂直的 agent,你背后用的是什么?无非还是通用基座。你可以做一些 specialization,但是你可能会遇见模型坍缩这些事,待会可以再讲。另外一方面,Manus 本质上是什么?它其实是一个通用的模型,加上一台计算机。因为每个 Manus 的 session、每个会话背后,都会有一个单独隔离的虚拟机沙盒;而虚拟机这个东西学名叫做图灵机——不是有个词叫图灵完备嘛——理论上来说,它是能够去模拟或者运行任何算法的。首先这样我们就看到,Manus 底层的两个技术供给其实都是通用的,那么走垂直,其实是在上面加约束。这是第一个技术判断。

第二点,就是我们一开始就像做 Monica 一样,好像没有做特别大的使用场景上的 bet,而是用一种类似于达尔文的心态在观察。就是说,如果我给用户提供的是一套通用的技术架构的话,我获得的优势是什么?就是用户可以按他的想象力去使用这个产品;同时我们作为创建这个产品的人,我们的使命是通过观察用户整体的 collective、集体的一个行为模式,去捕获到头部的场景,再让我们的产品团队去做最后一公里的优化。就像我们一开始,Manus 拿出来之后,我们在宣传中和我们所有网页的 case 中,都是天南海北,什么类型的东西都有——我们不要提前把用户做一个引导,让他用什么。逐渐逐渐我们发现,用户好像很喜欢做 slides、做 PPT,用户很喜欢做网页,用户很喜欢做批量的文件处理。然后我们发现,这些可能是值得我们的产品团队介入去做一些定向优化的。所以 Manus 是一个完全由用户所塑造的产品,且同时又保留了极强的通用能力。

而通用能力就带来了我要说的产品方面的第二个点:我认为很多能力最后会收敛。比如说当时,deep research、就深度研究这个领域,可能还是比较新的一个概念;但实际上你看,现在所有不同产品的深度研究的能力基本比较收敛了,尤其像 Gemini 也有 deep research、OpenAI 也有 deep research。当然确实还会有一些差异,但这个能力已经逐渐在所有产品中都具备了。那这又让我想起以前做搜索引擎的一个体验——或者这么说,你为什么用 Google 而不是用 Bing?如果你每天只查那些最头部的 query、最头部的那些查询词的话,你会发现你几乎用哪一个主流的搜索引擎,它的第一页结果都是质量接近的。那为什么还得用 Google 呢?因为 Google 永远能在你的长尾 query 中给你惊喜。那这样解决的一个问题是什么?就是说,如果你能够让这些长尾用户获得满意,他其实能够更容易地获得我们叫做 aha moment(顿悟时刻)的东西——就好像这个事情只有在这里才能被解决。

我举个例子。当时其实有一个分子生物学家用 Manus,他觉得非常惊喜的是什么呢?他想用 deep research 这个功能,但是他的这个实验仪器导出的是一个非常小众的数据格式,他用别的产品是做不了这件事的。而他把这个文件上传给 Manus 之后,Manus 说:这是一个很奇怪的文件格式,我先去研究一下。研究好之后,Manus 自己去 GitHub 下载了一个开源项目,来解析这个数据格式,然后再继续去完成分析。所以就是这种长尾的、没有人会专门为它做的场景,有一款通用产品能够解决,这个用户会获得极大的一个满足感。而且这些长尾不等于低频,因为这是这个人他每天的工作,所以对于单个人来说,这是一个 recurring 的、持续的一个任务。这是产品层面的第二点。

产品层面第三点,其实也解决了一个频次问题。就好比你如果要做一个垂直的 agent,你在用户心中建立心智其实比较难的,讲真。比如说如果你是 ToB 还好,因为 ToB 可能是很多人每天的事情;但是就像你在每一个 hackathon 都会遇见一个团队要做一个旅行规划 agent 一样,旅行规划这个东西,其实对于普通老百姓来说,可能一年就两三次、三四次,频次太低。对,你让用户记住你,是很难很难的一件事情。而如果你做一个通用的产品的话,其实你有更大的概率来服务用户的方方面面,这样的话你能有更好的一个频次。

但同时,你要做通用的 agent,你有不同的技术方案的选择。比如说有一些产品它可能也追求通用,但实际上它可能只是把不同的功能放在了同一个界面下,它本质是多个产品,只不过共享一个域名而已。而 Manus 我们会非常非常坚持的一件事,就是说 Manus 是一个单独的、unified 的、统一的 agent 框架。所以用户在 Manus 中进行不同任务的时候,它的上下文、它的记忆是可以自由流转的。所以我们能做到的事情就是:跟垂直的功能相比,我们永远能多做一步。

我举一个例子。世界上其实有很多能做网页的 AI agent,或者说 website builder、网页构建器。但实际上,对于 AI 来说,做一个好看的网页没有那么难,真正难的是如何让这个网页的内容言之有物。那这样,Manus 它可以同时先完成 deep research,然后再基于获得的 research 去做出一个网页;与此同时,这个网页还有真正的、实际的后台,有数据库。如果这个用户把他的网页分享到互联网上,有更多别人在用他这个网页的话,Manus 还能再继续在一个 session 内帮你去分析这个网页的流量,甚至能帮你做出一个 slide、做出 PPT,再给你发邮件、发给你的潜在的投资人。所以其实 Manus 能够做到的,是所有的垂直场景之后再多加一步,且能产生一个内部的网络效应。

所以我觉得这是通用所带来的很重要的一个点。

它的边界会在哪里？

我觉得它的边界其实取决于几个不同的维度。首先就是刚才讲到的 Agent 这个系统中，它分为三个元素：用户、环境和模型，其实这三个东西都有边界。用户的边界最有趣，我先不说用户，先说第一点——环境。

环境我觉得是 Agent 最重要的一个东西，因为环境其实决定了 Agent 跟外界所能接触的边界。比如现在 Manus 选择了一个最为通用的环境，就是一台虚拟机，一台 Ubuntu（Linux）系统。但这块我们现在在做很多的投入，我们有一个内部的虚拟化团队。

这里可能有些朋友有一个误区，好像 Manus 给每一个用户分配了一台电脑，其实不是的。每一个 Manus 会话背后是一个独立的、一次性的沙盒。所以其实我们的 Sandbox scaling 是非常大的。有时候我们内部开玩笑说，Manus 其实是一款个人云计算产品，因为你真的是让不会编程的人也能去操作云计算，并享受云计算带来的算力，用在日常生活中。

但这块其实会有很多的边界要解决，比如说如何 scale 到更多的沙盒。这个我们最近——也不是最近吧——几个月前我们推出一个功能叫 Wide Research，就是它不是深度研究，是广域研究。比如说你在别的 AI 中去尝试完成这样一个任务：帮我去找一找 YC 过去一批中所有 AI 营销公司的 CEO，并把他的 email 找到发给我。你会发现你给 Manus 之外的任何 AI，他们都会失败。因为既受限于 context window，也受限于模型本身的一些懒惰这些问题——待会儿会聊到。他们可能在找比如 10 个、15 个 CEO 之后，质量会急剧下降，然后模型会放弃。

但是因为我们能够去不断 scale out，就是不仅是 scale up 而是 scale out，这样的话 Manus 其实能说：这个任务很难，我可能要找 100 多个，那我现在能启动 100 多个 Sandbox，然后并行去完成这件事，最后再进行汇总。所以其实我们在虚拟化这块的边界是在扩宽的，这是第一层。

同时我们在不断地去增加能够使用的虚拟机的形态。比如一开始我们只是有一个基于 Linux 内核的虚拟机，但是我们没有选择像用 Docker 这样的一种 container 容器技术，因为容器技术它其实基于 Linux kernel 的叫 Cgroup 的技术。我们认为如果你选择这条路，它确实更简单，但是它会绑定于 Linux 系统，而很多专业的软件其实只在 Windows 生态里有。所以其实我们选择的是比较重的一条路，就是我们基于 Firecracker，它是一个轻量级但是全虚拟化的方式去做。所以现在 Manus 其实同时还能用 Windows。所以这块也是我们在不断推的一个边界。

与此同时，除了 function calling 这一种形式——就是模型跟外界沟通，可能常见的叫 function calling、叫工具调用——但实际上如果你给了模型一个完整的虚拟机的话，虚拟机内的预装软件也是很有趣的一件事。就好比如果你的 Windows 系统自带了很多专业软件的话，那其实你可选的范围、你的动作空间又会变得更广。所以实际上我们还自己——你可以说我们在维护一个专门为 Agent 设计的 Linux 发行版本，里头内部有很多只有 Manus 才知道怎么用的工具，来完成一些事情。这是我们在环境这方面在探索的东西。

在模型方面，其实这时候也可以讲一讲。虽然我们不自己训模型，但我们一直在作为无形的大手在干预着这个事。这个很好玩，因为当你有足够的影响力之后，你的一些需求其实是能够影响模型的发展的。这也是我们最近获得非常大正反馈的一件事：因为 Manus 的 token 消耗量巨大，所以我们自然是几乎所有模型厂商的头几名的客户，所以我们跟 Google DeepMind 都有很深的合作。

你们 token 消耗量有多大？

这个数据我可能不太好透露，但可以讲的一点就是，我们在各个模型厂商基本应该都是 top 2 到 top 5 的消耗量，全球范围。

你们怎么 cover 这个成本？

这就是为什么要做一款能够赚钱的产品——用户的钱变成了 token 的消耗量。

这个你们现在就可以 cover 吗？

我们现在几乎能 cover，而且这个优化的曲线其实非常快。今年 3 月发布的时候我们确实是 negative，就是负的利润，但现在我们很快就要打平甚至打正了。

这么快就打正了？

是的。我觉得这一方面是技术演进带来的，同时你也不能被动地接受着，你一定要去影响模型厂商的决策，这就回到我刚才讲的这个事。

这个 token 消耗量大概是 chatbot 的多少倍？

这个 chatbot 你看怎么算。我可以给你一个这样的对比：因为以前我们做过 Monica，大家在做 chatbot 一定会进行一个估价，估价就是你得基于 input token 跟 output token 的成本去计算。这两个差很多的，因为对于 Transformer 结构来说，你的 input 其实是 prefilling，这是可以并行计算的，它是 compute-bound 的；但是你在输出 token 时它是 decoding，这是 bandwidth-bound 的。它的定价是不一样的，一般来说你的 output token 会比 input token 贵很多。

所以在 chatbot 中进行价格的估算，你一般按 3 比 1，3 是 input，1 是 output。但其实在 Manus 这样的 Agent 中，input 跟 output 的比例是 100:1 到 1000:1，根据你的 task type 去对比。所以其实你可以想象一下，output 的长度如果差不多的话，那 input 的长度就是你能估算的。所以你可以说是一个几十倍甚至上百倍的 token 消耗量的差距。

而且我们其实一直比较贯彻到底的一点，就是我们不会为了成本或者速度去缩减 token 的消耗量，我们一定是以质量为先的，所以甚至我们以消耗更多的 token 为荣。涛哥有一个梦想，就是他想造一个 7×24 小时烧 token 的机器。对。

所以这是我们讲的，就是消耗很多 token 之后，你会获得很大的影响力。同时因为包括我在内，团队很多人以前都是做过模型的，我们知道这个东西该怎么改进，但我们自己不弄——我们把这个东西能不能外包出去呢？比如说我们跟 Google DeepMind 有很深的合作，我们就可以直接提需求。不仅提需求，我们会帮他们构建 evaluation，甚至包括一些功能。比如说我记得两个月前，Gemini 新出了一个叫做可控的 parallel function calling，那个定义和 proposal，以及它对应的实现 schema 是我写的。所以就是我们能够让它去帮我们实现一些东西。

这里其实有很多要去探索的东西。比如说我刚才提到了一嘴，我认为现在大部分的模型仍然是为 chatbot 去做的 alignment，这是一个很有趣的观察。大家知道其实从 GPT-3 到 InstructGPT，它发生了很大的变化不是在基座，而是在于你的后训练是怎么去决定这个模型输出的风格或者形态的。比如说如果你用最早的 GPT-3 的 API，你问它说"北京天气如何"，它其实不是回答你，而是在尝试补全甚至复读——就是你问它北京天气怎么样，它会说东京天气怎么样、纽约天气怎么样，它其实在模仿你的这样一个 pattern，但不在回答你。而 InstructGPT 和后来的 ChatGPT，它其实通过后训练所实现的是让模型知道我应该去回答这个问题。

但这里你看，chatbot 会存在一个天然的问题，叫做无论用户的问题有多么复杂，它都会倾向于在一轮回答中回答完毕。但这个其实跟 Agent 的一个基础假设是不一样的。Agent 的基础假设其实就是姚顺雨的那篇 paper ReAct，我每次都跟别人讲这个，我觉得这个抽象非常好：就是 Agent 做的事情就是在一个循环中，基于用户的输入，或者来自环境里的一个观察——叫做 observation——去在你的动作空间中选择最有可能的下一个 action，去选择下一个动作。

所以很明显，对于 Agent 来说，接到用户的一个复杂输入之后，它正确的做法不是急于在一轮内回答全部，而是很有耐心地逐步尝试，且基于上一步的观测去调整自己的方案、去预测下一步。所以如果你仔细去想的话，其实 Agent 的工况跟 chatbot 是不 align 的。

而这里头会带来很多细节问题。比如说很多现代的模型会有一个耐心问题，就是为什么会说模型比如去回答问题，尤其你强行用 chat 模型完成长链路的 long-horizon 的 Agent 任务之后，你发现模型干的事的质量越来越低。一定程度上来说，就是它缺乏这样一个真正在现实的 agent trajectory、就是 Agent 轨迹中进行训练的过程；或者说它的 data mixture，就是它训练用的这个数据混合中，是有 Agent 这样的 task?，但实际上它的 data mixture 被 dominated，其实还是为 chatbot 而设计的数据。

模型的学习能力是极强的，你数据的 distribution 其实会影响模型的风格。就比如说模型在输出到一定长度，或者说看见它的输入 token 长度到某一范围之内，它会感受到一种无形的、叫 context pressure。

就是上下文压力,它会影响你输出下一个 token 为 EOS 的概率。EOS 就是 End of Sequence Token,就是模型当它认为该输出这个 token 的时候,其实整个任务就结束了。模型其实是能感觉到这种压力的,所以这块其实是一件很不好的事情:它让我们用 chatbot 模型、为 chatbot 设计的模型在 agent 任务上工作的时候,会非常着急。一个常见的现象就是,你会发现它到后面开始疯狂用 bullet point,就写那种很总结式的关键点,写得很短。对,这是一件很常见的事。

另外一点就是,这些模型其实没有为现代的 context engineering 做过一些专门的训练。我举个例子,刚才我提了一嘴,说 2023 年初我就一直到处忽悠 Long context,但我现在有新的想法,我现在有一个暴论:我觉得 200K 以上的 context 就不重要了。为什么呢?因为比起更长的 context,我觉得更重要的应该是让模型具备 compression awareness,就是对压缩这件事的意识——对压缩这件事的意识。对,这个怎么解释呢?就是如果你让你的 context、你的上下文长度无限单调递增的话,即使有 KV Cache 存在,它能让你的 latency(你的延迟)和成本降低,但其实即使你有一些 efficient attention,它仍然是一个增长的过程,而这是不值得的。

其实更重要的应该是什么?让模型知道说,我现在 context 已经很长了,我看我能不能把我 context 中的一些信息去 offload,就是把它外化到比如说文件系统中。就像我有一部分记忆,就像人一样,我这个东西不用脑子里一直装着。人的记忆也挺差的,就是我的工作内存很差,但是我会知道这个事,我可以整理成一个文档,放在我的 Notion 里头,我下次我知道我该什么时候去拿回来。或者说,我知道我过去做了很多的事情,但是其实有一段东西它不重要,它只是一个过程,那这时候我可以进行一个压缩,叫 compaction,或者叫 compression,就是说我把我中间的一段历史变成一个很紧凑的表达。但是模型要能够明白说,这段东西不是凭空消失了,它是被压缩了。而让模型意识到"被压缩"这件事,是需要专门训练的,这个是为 chatbot 训练的模型其实没有很好地训练过的一个点。

另外其实还有刚才讲到的,就是像 Claude 3.5 V2,它还没有很强的 reasoning 能力。但 reasoning 这个词是非常大的一个词,怎么说呢,最表面的 reasoning 现象可能是像 o 系列的 reasoning model,就是说当用户问一个问题之后,它在输出最终答案之前,会有很长的 internal long CoT,就是内部的长思维链。但这个东西你如果盲目地用于 agent,你会发现一些问题。比如说你会发现它的 instruction following 能力,就是它遵循指令的能力,其实是下降的;另外一点就是,它出现幻觉和幻觉工具调用的概率是提升的。所以如果你直接把一个为了解决比如说竞赛编程或者数学而设计的 reasoning model,平移到 agent 场景下之后,你会发现其实它的效果是下降的。

那这时候我们应该去改变这块训练的模式。比如说你可能更关注一种叫 interleaved thinking,就是交错式思考。刚才讲的,按照顺雨的 ReAct 来说,就是你获得一个 observation 之后,你不要立即着急去预测下一个 action,而是在这块进行一个中间的、但是相对较为短暂的 reasoning,去想想我之前做了这些事情,那下一步我该做什么,我该做这个——是类似这样的一个结构。而不是说像比如说你让 o 系列模型去解决一个数学题一样,用户给了一个很短的问题,它哗一下想了几千个 token,全在脑内。这是不对的,这个在 Agent 上还会产生一些负面效果。

但是比较不幸的就是,这个事其实可能说起来简单,但是大家做的,说实话都不是特别好,就是目前。

你说模型公司做得不好?

做得不是特别好。对,这时候还有很大的改进空间。对,所以我很期待接下来的这个进展。

然后比较幸运的就是,因为我们影响力会比较大,所以我可以天天给这些模型公司洗脑,说这个很重要、这个很重要,然后他们也确实很积极地对待改进这些事。所以其实包括 Gemini 3 出来之后,我们也很兴奋,就是他们能以非常快的节奏,去把我们之前遇见的问题实实在在地变成模型。而又很开心的是,头部旗舰模型的成果会逐渐影响所有开源的模型,大家也会跟进。

所以我很开心的一点就是,好像全世界都在帮我们一起训模型,但我们却没有自己掏出很多钱去砸进去,而是说我们让用户使用了一个很好的产品,用户付了我们的钱,我们为用户创造了价值,同时我们通过这个获得了影响力,来影响别人、来帮我们训练很好的模型。这样其实节省了很多我们内部的 research 的带宽,我们可以真正去投入一些非共识或者小众的事情去做。

你们沟通最多的模型厂商是谁?

这个其实都是非常均匀的。因为我觉得现在不同的模型厂商之间其实是比较分化的——我不是说他们技术路线的分化,应该说他们关注的点是很分化的,这可能也是被动的选择。

就比如说你要讨论真正的 agentic coding,我不是说竞赛编程,就是这种偏现实工程的多轮的编程,那确实 Anthropic 还是最好的。包括其实 Claude Opus 4.5,我觉得可能很多人对它有点低估了,这个我觉得是一个非常大的演进,所以 Anthropic 他们在 coding 方面是非常领先的。

然后像 Gemini,很明显它在多模态领域,尤其是多模态的理解,就是多模态输入方面是非常非常强的,是一个断层级别的强。而且 Google 又有一些比较独有的资源,比如说通过 Gemini 可能是你唯一能够使用到 Google 的索引的方式;与此同时,如果你想让 agent 具备比如视频理解能力,尤其是 YouTube 的视频理解的能力的话,那你一定要选择 Gemini。

而 OpenAI 的话,它在 reasoning,或者说这种偏纯推理方面的 reasoning 的投入是非常大的,它是有比较强的一个领先。而有的时候你要刷榜,其实 OpenAI 模型是一个很好的选择。然后其实别的这些,像什么 Grok,还有一些开源模型,都各有特色。所以我觉得现在对我们做应用的人来说,真是很幸福的一个时间点。

谁对你们的反馈改进得最多?

我觉得看效率吧。其实目前头部的几家,我感觉像 Google、就是 DeepMind,跟 Anthropic,其实大家的响应都会非常快。当然,因为我们不同的场景会使用不同的模型,所以大家解决问题的效率,客观程度上来说也受限于这个问题本身的难度。

你教会了他们,他们可以反过来抄你们的产品,但是你们没有那么快能抄他们的模型,怎么办呢?你们的壁垒是什么?

对,我觉得就是快。首先有一点,就是你会发现比如说一些模型公司,他们偶尔会发布一些 research blog,我们读到这些 blog 的时候,心里也是又开心又无语,因为基本就是我们之前在讲的这个东西,他们直接写成了一个 blog 出来。比如说什么 Thinking Tool,也是我们上线一个月之后他们写了一篇 blog;像最近用代码方式调用 MCP、progressive disclosure 这些东西,也是我们一直都在做的东西。

但我觉得这个是没有关系的,因为这就是一个竞合关系。而对我们来说真正的优势是什么?有两点。第一点,因为我们对于不同的场景使用不同的模型,所以没有关系,我们永远能够为用户提供所有人中最好的一个体验,这是第一点。第二点是什么?就是他们的速度,一旦是垂直整合,其实你一定是没有我们快的,因为产品方面的迭代还是太快了。

他们变成分化的,你们变成综合的。

对,是的。所以刚好反过来了。

这很有意思,这个很反直觉。

是的。如果是都符合直觉的事,我觉得也轮不到我们做。

为什么会这样?为什么会一个应用公司开始做一个综合的事情,而模型公司变成垂直整合,他们越走越窄?

我觉得这就是这个公司一开始的根是什么。其实我觉得我们可以拿 OpenAI 作为一个案例吧。就是我刚才一直在讲,我非常尊重 OpenAI,它是真正很尊重 bottom-up 这一种模式的,我有很多朋友在 OpenAI,它是真的能够通过一小群人的一个创新,逐渐往上走变成一个产品。但实际上我认为,这就是我刚才讲的那个叫"买模型彩票"这件事,你实现的方式是基于一个突破来做一个场景。但是对于我们来说,所有外部的创新对我们都是一种养料、都是一种供给,那我们就不用做选择,我们不用买这个模型大乐透。

作为应用公司来说,其实跟模型公司相比,我觉得还有另外一个优势,就是大家常常觉得好像智能的提升不需要用户——这个至少从今年年初来看,比如 DeepSeek,在 R1 出来之前其实 DeepSeek 也没有很多的用户,对吧?但是你其实通过比如 RLVR 这些方式,你其实能获得一些提升。但我觉得对于 Agent 这种特别长链路、跟环境强相关的场景下,其实用户是非常关键的。而用户的使用轨迹以及 feedback 是留存于应用层,而不是流动到模型层的。所以其实现在应用公司有非常独特的数据飞轮,这就是为什么像 Windsurf 跟 Cursor

他们可以以一个较低的成本，在一个预训练基座之上，开发出一个基本是 frontier-level、但是成本很低且专门适配自己的模型。所以我觉得这是未来可能半年的一个很重要的变化：会看见更多的应用层公司利用自己的数据飞轮，变成以模型的形式来体现出"产品可以持续迭代"这件事。

你们的用户画像是什么样的？

我们的用户画像是这样。我刚才讲了一个最笼统的定义，叫做 prosumer（生产型消费者／专业消费者），但可以切几个比较常见的画像来讲。

第一类，我们叫做在互联网公司或者技术公司里、但不是程序员的这一类人，广义来说就是白领或者远程工作者。第二类是我们叫做 freelancer（自由职业者）或者 solopreneur（独立创业者）。美国其实有很多那种独立、自负盈亏的人：你可能在做外包，也可能自己有一个很小的生意，这些人是一类用户。第三类比较大的用户，就是所谓的金融和 consulting，就是咨询行业的这些人。

我觉得他们都有一个比较大的共性，就是有比较强的自驱力，且与此同时他们的任务是高价值的。

这个是很好玩的。我们发现做 Agent 很有意思的一点，就是它不是在做工具——至少对于我们来说，如果你做的是这种通用的 Agent 的话，你不是在做工具，你其实在做一个类似于人的东西。如果你做的是一个垂直 Agent，你可能还是在做一种新的工具；但如果你在做一个通用 Agent，你其实在做一个人。做一个垂直工具，比如说汽车公司做的是司机，像 Lovart 做的是设计师——对，但它其实是设计师用的一个工具。而 Manus 作为一个通用 Agent，我甚至可以用 Lovart。

因为 Manus 的抽象层级是什么？就是我们在设计"让 Agent 能使用哪些工具"，或者说"你跟外部交互的边界是什么"。我们一直是这样一个类比：我是一个人，一个普普通通的人，我能做很多事，是因为我有一台电脑。我跟电脑之间的 interface、就是界面是什么？我的右手能够用鼠标，我的左手能够用键盘，我的眼睛能看见屏幕上的内容，我的耳朵能听见它的声音，没了。就是一个远程工作者，用这样简单的、标准的接口，其实就能完成几乎无穷无尽种类的任务。

所以最近我们也看到一个比较欣喜的结果：Scale AI 最近发布了一个新的 benchmark，叫 RLI，叫 Remote Labor Index，远程劳动力指标。这个 benchmark 里头，当然 Manus 又是 SOTA，肯定第一名，我们战胜了像 Claude、Gemini 这些所有的竞争对手。

但为什么我们非常看重这个 benchmark？因为它的评判标准是非常有意思的。它的评判标准是说：这个 AI 系统完成的工作，能否让一个现实的客户愿意为之付款，且无法区分是人类还是 AI 去完成的。虽然我们现在是 SOTA，但实际上我们完成的也只有 2.5%，所以其实离百分之百还有很远的距离。但这个 benchmark 我们看重的原因就是，它完美契合了我们想象的这一点：对于通用 Agent 的衡量指标，就是它能完成多少远程工作者能够完成的事。

因为这个解读空间就很大：我现在在 benchmark 上可能虽然只有 2.5%，但那是不是说，我们也许能够让全世界 2.5% 的 GDP 获得加速呢？所以这是一个很好的梦想。而且大家都知道，进展仍然是存在的。虽然很多人说 AI 的进展速度好像变慢了，但实际上我觉得 evaluation 是最重要的事，因为它能指引我们去往的方向，它既是 taste，也是方向。所以我觉得也许到了 2026 年，我们乐观一点，2.5% 可能能刷到 20% 到 30%，那这样其实就能占相当大的一个经济生产的规模了。

你们现在的数据飞轮是什么样的？

数据飞轮是这样，可以跟 chatbot 相比，我讲几个非常好玩的点。

如果你在用 chatbot 的话，当 AI 输出了你不满意的东西的时候，你的第一反应可能有两种：第一种是简单点一下那个重试键 retry，它就重新再输出一个，你相当于在 roll 一次，看会不会好一点；或者说你就直接去改你输入的那个原始的 prompt。

但是我们发现在 Agent 的场景下，用户他会这样：他会教这个 Agent。我举一个例子，比如说我经常让 Manus 帮我去筛简历，然后他筛出来的标准跟我想要的不太一样，我就跟 Manus 说，你这不对，这个才是我喜欢的，你要注意下次是不是给我 Excel 或者怎么样的。其实我一直在教 Agent，这是"教"，这是第一种。

第二种是什么？就是如果有一些任务，即使不涉及我的个人偏好，但 Agent 很可能就是做不对，这时候我会去 fix 它，我会帮它修。比如我跟 Manus 说你这个不对，我已经?帮你把这个文件改成了正确的格式。

而获得这两个数据其实是非常困难的，在以前 chatbot 的时代。而当你有很大的用户量之后，其实你能够进行一件事，说大一点，叫做基于 collective feedback 做到一种在线学习——但我很不喜欢"在线学习"这个词，待会说。它其实能达到的一点就是，我们即使不碰模型，你也能够获得一种叫做 self-evolving 的能力。它是 parameter-free 的，不涉及参数化，但是有更多的用户使用之后，我们能够将更多通用的、公用的 failure pattern，就是失败模式，以及用户共识性的东西，变成系统原生的一部分。整体上来说就变成：用的人越多，我的失败率越低，我完成同样任务的轮次开销越小。这是第一种数据飞轮。

第二种是什么？第二种就是说，我们仍然会拿用户最朴素的反馈，比如打一星到五星，作为一个指导。因为这个东西能回到我们刚刚讲的——evaluation 很重要，但实际上 Agent 的自动化 evaluation，我认为现在还是非常亟待改善的。因为即使你有一些自动化的 auto-verifiable benchmark，比如我们一开始就会很关注 GAIA、SWE-Bench 这些东西，但实际上我们发现，真正上线之后，我们在这方面表现好的架构和模型，用户的真实评分不一定高。因为用户关注的点，跟你这些理想化的 benchmark 还挺不一样的。

举例子，比如说用户更关注的是：你做的这个 size、你的长宽比是否超过了 16 比 9？你这个网站是否属于比较易用且好看的？刚讲的 16 比 9 你还可以自动 verify，对吧。但什么叫网站好用且易用？这东西你很难通过一个完全自动的 reward model 去实现。所以我们非常依赖于用户给的这个直接的反馈，而且有一个固定的团队就做 evaluation，而且是主观 evaluation。所以这块是真正能够通过用户的反馈来指导我们迭代的一个方式。

这是多少人的团队？

我们是这样：我们有一个专门的 evaluation 团队，evaluation 团队现在不到 10 个人，但是他们会同时负责系统的搭建，我们内部有很完善的 evaluation 体系，以及自动化的部分。同时我们从产品团队会有一些比较 junior 的同事，其实专门就是负责主观 evaluation。所以它是技术和产品团队的一个交集，加起来大概有 10 多个人，再加上不断轮转的很多实习生。

你们现在核心关注的几个指标会是什么呢？

我觉得有几个。第一个就是说，我们从 interface、还是刚才讲的这个界面角度、接口层面来说，你可以抽象成几个不同的维度。

首先我一直在说 coding，coding 一定是非常重要的点。虽然 Manus 不是一个 coding agent，但其实 coding 是 Manus 的一个灵魂，所以我们当然对 SWE-Bench 还是非常关注的，但是 SWE-Bench 就快被刷爆了。这是编程，是一个维度。

第二点，就是 Manus 虽然没有直接进行 computer use——就是说我们不是通过 GUI 去完成很多事——但实际上我们用了很多的 browser use，所以这块我们以后也会很关注这种 GUI 的理解能力。这是一个维度，但这也就是所谓的多模态输入的一部分。

第三类是什么？就是广义的 Tool Call 能力。Tool Call 能力，怎么说呢，大家非常关注，但实际上到了 Manus 这个复杂度的并不多。因为 Manus 的复杂度非常高，它有多种不同的 action space：它不仅有原生的这种 function calling 的 function，其实你在使用我们自己自定义的这版 Linux 发行版的时候，它有很多命令行工具，它不是以模型原生的这种 schema 去存在的，而是存在于系统中。就是让模型能够基于一些使用文档，来学会使用特定软件的这个能力，这是非常关键的。

所以从模型的原子能力的情况下，我们会最关注这三点。但其实还有一些非常难量化的东西，就是我们刚才讲的比如说美学性，和对错误的自我意识。这个错误的自我意识其实我觉得也是很重要的，它有低维度和高维度两种。低维度的一种就是说，你在看很多 benchmark 的时候，你能看见的是，无论你是 pass@1 还是 pass@k，你看到的其实都是模型在 one shot 过程中去完成的一个状态。

但很多时候,有的时候模型需要自己意识到这个错误该怎么修复——当然这是最理想的;更常见的情况是用户先发现了一个错误并指正它。如果你经常用 AI coding,你可能会有一个很沮丧的体验:无论是 Claude Code 还是 Codex,你发现了一个问题,你让 AI 修,AI 说"太棒了,我已经完美修复了这个 bug",其实不仅没修好,还引入了另一个 bug。这个指标是很难去追踪的,因为它中间可能涉及真人的 feedback。

这是低维度的。更高维度的一种错误是指:它做出了一个能用的东西,但是它无法很好地把这个东西推到下一个 level,就是从"可用"到"好用"的这种错误。我们还是愿意把它定义为一种错误,因为我们觉得它是能够解决的。比如说 Manus 跟很多别的 coding agent,即使都能做网页,Manus 也能再往前做一步——基于我们的通用能力,Manus 每做完一个网页,它可以选择说,我自己用我的浏览器去把这个网页玩一圈,然后看看我的数据库里的记录是否都对上了。所以这个我觉得是能够弥合这个错误的一个途径。

刚才有一些表达,比如说模型的懒惰、模型比较没有耐心、模型感到压力、模型比较着急,还包括杨植麟以前说的长文本影响智商——模型的状态好像跟人还比较像。这是为什么?

我觉得我们只是在用人习惯的词来描述这个东西。我觉得模型跟人一点都不像,或者说,强行把模型或者 Agent 与人常用的思维体系去对齐,这事是不对的。

你刚才不是说你们做的是一个"人"吗?

对,但我们做的是能完成人做的事情的一种系统。但你不该用人的分工或者特化去要求模型。我举一个更具体的例子:比如说很多做 Agent 的公司,或者一些开发者,他们有种惯性思维,就说我要让我的 Agent 在 multi-agent 系统中分为设计师 designer、programmer、manager 这些东西,就是你在给模型增加很多不同的角色。我们觉得这个其实不太对。

因为回想一下,为什么人类社会会有这个问题呢?是因为很可惜,我们每个人都不太全能,所以你在一个组织架构下,必须要有这样的一个分工。但其实我们在组织架构下,又有多少信息在我们通信之间损失了?又有多少在合作中增加了很多的摩擦?实际上模型是比人更加全能的一个东西,所以你应该充分利用模型的优势,而不要生搬硬套人带来的这套约束。我是想表达这个意思。

那模型该怎么分类?Agent 应该怎么分类?

Agent 分类这个话题,我觉得你只能从输入和输出的角度来看。

你觉得不用分类?

我觉得不用分类。

所以你们做的是通用 Agent?

不是。我想说的输入输出的意思是什么呢?就是通用 Agent 是把更多输入的责任交给了用户。而你做垂直 Agent,其实在输入这一侧,你会做很多比我们要多的事情。比如说如果你要做一个垂直领域,你输入的数据可能就来自于一个用户不太可能自主产生、或者说自主提供的过程,比如它一定得深入结合到某一个已经在运行的业务系统,来获得这个输入;同时它的输出也不是以一个标准化的形式给出的,可能它是无缝就传递给了另外一个系统中。所以我觉得它一定是输入输出跟通用 Agent 有不同,这决定了哪一个是哪一种 vertical agent。但是讲中间的技术方案,我相信会是趋同的。

你们为什么做通用 Agent,而不是做一个 agent OS?

我觉得首先,作为一个有职业素养的程序员,我们会尽量回避 OS 这个词。

为什么?

这是一个圣杯,我不配,这是第一点。第二点就是,我们觉得 OS 这个东西,如果严格定义来说,它是一个中间层。当然你也可以说 Agent 是很多东西的中间层,但实际上我认为现在 Agent 还没有到这一步——用户的文件、用户的软件其实不在你这儿,这是一个客观的现象,对吧?所以在你没有获得这些东西之前,你不要称自己为一个 OS。

谁适合做这个?会有这个生态位吗?

我觉得是这样。比如我们跟微软有很深的合作,就像前一阵 Ignite 大会上,大家看到 Manus 跟 Windows 都会有直接的合作,比如说你以后在 Windows 右键菜单里就可以用 Manus。我认为不是说有谁做了一款开天辟地的 agent OS,而是现在所有的操作系统都会逐渐具备 agentic 能力。且很开心的一点是,我们发现现有的操作系统厂商是用一个相当开放的心态在做这件事,比如说接下来大家可以关注 Microsoft Agent 365,你也可以看到 Manus 也在里面。所以我觉得这个东西就像我们之前做浏览器一样,我更相信的不是突然出现了一个全新的 agentic browser,而是所有的 browser 都在变得 agentic。

你觉得 Agent 最后的生态会是什么样一个格局?

Agent 最后的生态,是吧?我觉得是这样:垂直领域的 Agent 最后应该是一个百花齐放的状态。当然也许还是 ToB 方面会多一些,ToB 的垂直 Agent 会多一些。

为什么呀?

我指的是海外市场。因为首先有一点,目前——因为我们现在只做海外——我们觉得可能尤其……我不敢说海外这么大,就说美国市场。美国市场我感觉现在大部分创业者都在想一件事:我要做一家给另外一家创业公司使用的产品,并卖给另外一家公司。就是我觉得很多美国创业者已经失去了做 ToC 的勇气和心气。

你说的是美国华人创业者,还是美国创业者?

所有,甚至华人还好一点,华人还有梦。我觉得像我们比较勇的这种,我们还敢做这个事。

为什么?为什么丧失了这种……不过过去 10 年美国 ToB 确实更好一些。

对。我觉得其实与其说丧失,应该说他们这边的环境更形成了这样一种正反馈:他们的退出机制非常好、很成熟——卖公司嘛,你可以卖公司;或者说你自己做 ToB,你有一个稳定的收入,你自己独立上市、独立发展都没有问题。所以这是他们这种成功的路径决定了美国资本市场的一个倾向,对吧?所以在美国,像我们那种跳出来做 ToC,那确实是一个很异类的东西。当然,这也就是有人愿意下大注,对吧?

谁愿意下大注?下了什么大注?

就像我们现在就获得了一些押注,我只能这么说了。但像国内的话,我觉得上一代创业者,就是我这一代创业者,我们在这个移动互联网时代,其实很多人都是做 ToC 的,其实获得了很多的正反馈,也更勇一些。所以我觉得这确实是两边的环境和持续的反馈带来的一个结果。

所以你觉得没有垂直 ToC 的 Agent 的生态位吗?

我觉得一定会有,一定会有,但是这块其实会比较微妙。我们团队有另外一个同学,他之前是做一款剪辑软件,后来也是被腾讯收购了。他其实跟我说了一个很好玩的观点:做垂直 ToC 的应用,很难的一种模式是什么?就是比如说你要给剪辑师做一款更好的剪辑 Agent,他说这是非常非常难的,因为专业人士会对这有极高的要求,这个用户会从风险控制的角度来看待这个事。比如说你一个工作流很复杂,你但凡有一个环节没做好,那对这个专业人士来说,这个东西就是零分,因为它是一个乘法关系,对吧?你就不能用。

但是你应该做一种什么样的 Agent 呢?是做一个给非剪辑师用、但是却有剪辑需求的人做的 Agent,比如说自媒体。这样的话,其实你会变成给原本就有这个需求、却做不了的人提供服务,它是一个净增益。这个我觉得是非常重要的一点,这句话其实影响我们很深。

我们现在经常跟我们的用户或者别人交流,我们常说:Manus 虽然我们做的是一款通用 Agent,它很像人,但是我们从来不以替换人的思路来想这个事。因为如果你要给别人"我要替换人"这样一个心智的话,所有人都会从一个 risk control 的想法去想——就我刚才讲的,你但凡一个环节不通,就是不通。但是其实你应该用一种提升人、enhance people 的思路去想:让你现在已经最高效的雇员,或者说你是一个自驱的人,你获得了这个工具之后,你能让你的产能提升。那这是一个更良性且更现实的做法。

所以这个生态还会怎么样?除了有通用的 Agent,然后有垂直的 ToB 的 Agent,还有呢?

我觉得会有很多偏娱乐的 Agent 出现,当然也就是 ToC、广义的 ToC。当然这可能就是接下来看怎么走。现在我也看了一些比较有趣的尝试,比如说那个——我就不说具体名字了——他们做的可能就是给每一个人做一个虚拟的 Agent,然后让 Agent 以代理的形式之间进行社交。我觉得这都挺好玩的,但我觉得我实在是没有这方面的 insight,所以……

这种产品感觉适合 OpenAI 做。

你说 OpenAI 吗?我觉得 OpenAI 适合做所有产品。

你觉得 OpenAI 会抢夺你们的生态位吗?

我觉得一定是会有竞争的。但是我们现在观察到的现象是什么?首先,在 ChatGPT Agent 出来之前,我们可能要经常回答的一个问题就是:OpenAI 做了,你们怎么办?他们做了,他们确实做了,但是很明显,效果是不如 Manus。为什么呢?就我刚才讲的,我们其实是能用市面上所有最好的选择,而 OpenAI 它仍然是在它的领域有所专长,这是第一点。第二点是什么?其实跟他们的一个用户心智有关:ChatGPT Agent 仍然是 ChatGPT 的一部分,而 ChatGPT 我觉得它是一个打透了的产品,就是 Chatbot 的战争已经结束了,所有的用户都在使用 ChatGPT。但实际上,有 Agent 需求的人……

客观来说是少了一个量级的。所以我们其实一直是自上而下去做的。我们一开始触达的用户——你想 Manus 在美国是怎么火起来的？一开始都是像 Patrick Collison、Jack Dorsey 这些硅谷精英，他们发现这个东西真的好用，能给自己提效。所以我们一直都是在服务一个相对 ChatGPT 单价更高的用户群。对于那种快速的问答或者一些低价任务，包括我自己，我也是不用 Manus 的，我用 ChatGPT。所以我觉得这是一个分层的市场，我们会长期专注于为真正有高价值需求的人提供他能找到的最好的 AI，而不是跟 ChatGPT 去抢夺最广的、底层的那个用户群。

所以 Chatbot 和 Agent 的用户不完全是一波人，是不完全重合的。

它不完全重合。

他们包括你们。

对，他们包括我们。但是实际上我们一定要去满足的，是那些有最高质量需求的用户。这些人肯定用过 ChatGPT，但是他们仍然会选择 Manus，是这样的一群人。

其实是 ChatGPT 没有把这部分的用户需求满足好。

是的。或者说，我们得保证我们永远能提供比 ChatGPT 的 Agent 更好的体验。

那这是现阶段，未来呢？未来他们会赶上来吗？

那我们也会赶上。我常说，小公司怎么跟大厂竞争？赶紧成为大厂。

你们现在距离大厂还有多远？

还很远，但是在做了。

在做。长期来看，理想状态的 Manus 应该是什么样的？

理想状态的 Manus……其实我想回到刚才我们谈的一个问题，但没说完，就是边界是什么这三件事。刚才讲到其实有三个系统元素：一个是模型，一个是环境，一个是用户。我们觉得接下来我们更关注的——我不敢说是未来形态，因为对于创业公司来说，我们聊三个月后的事都很慌。

你就聊接下来这三个月内。

我们会关注一点：其实用户也是一种边界，也是一种瓶颈。

是什么？

就是现在无论 Agent 多么智能，或者说 Manus 跟 Chatbot 相比有一个最大的变化，就是它的输出不是简单的一段话，而是一个 action、一系列 action，或者不同的产物。但实际上它的起点到目前为止，大家看到的好像还是一个 prompt。而实际上对于用户来说，输入 prompt 是很闹心的一件事，而且更多的问题是，很多 context 没能带入进来。所以我们一直在想，如何去优化这样一件事。

然后刚才还提到张涛、涛哥的一个梦想，是做一个 7×24 小时推理的机器。所以我们接下来会比较投入的一个方向，也可能代表未来一段时间的 Manus，就是我们在做 proactiveness，就是主动性。

这个词其实我觉得是 OpenAI 带火的。

不是。这个词其实应该是 Agent 这个词的本意，Agent 的本意来自于 agency，就是能动性、主动性。但是之前，因为大家可能更关注的是一个结果的呈现；而其实现在又到了该关注 context 这个问题的时候了。就好比 OpenAI 先做出了 ChatGPT，但 Monica 关注到了输入 context 这个点，现在我们也要把这件事做得更好。

但是我们觉得不应该做成像 ChatGPT 那个叫 Pulse 的东西，对吧？那种就是它每天推很多东西，这其实是在占用户的时间。而真正现在能够为 Manus 付钱、真正获得价值的用户，他其实需要的是生产力效率的提升。所以我们更关注的应该是如何让 Agent 主动去完成更多的事。这个东西现在我们内部已经有 proactiveness 了，我们自己用得很爽。

怎么主动完成？

这个可能我先不方便透露太多，但我们可以举一个场景的例子。比如说我们自己每天面试完之后，可能会用一些第三方的 SaaS 服务，比如像 Ashby 之类的东西，我们需要去写 review、写评价。评价当然是我们自己评，但你要写很多描述这些东西。而其实我们在面试的过程中，用的可能是 Notion、Granola 来做记录。那我们自己要干的事，就是假如没有这套新的 AI 的话，我们就得自己基于我昨天的 interview 记录去填写这些评价。实际上有了 proactiveness 之后，Manus 其实可以每天早上在我醒来之前，先自己去看我的 Notion，帮我直接把记录填到 Ashby 里头，然后只问我接受与否。

所以其实应该解放出来的就是用户的这层瓶颈，让 Agent 的能动性逐渐去发挥出来。这我觉得是一个短期未来关注的点。

一开始我觉得是你们想让大家能够更方便地去理解你们，所以你们用了一个"通用 agent"的概念。你觉得通用 agent 长期来看是最合适的、描述 Manus 的名词吗？

我觉得不一定，甚至说它不是为了让用户更好理解。你知道我们那个视频做得非常草台，整个工期大概就三天。就是那块因为……

还自己剪的是吧？

自己录、自己剪。为什么那块要有一个黑屏，写着 the World's First General Agent？因为中间那块其实发生了一件很傻的事：当时我们是在办公室一楼录的，背后一个保洁阿姨走进来了，所以我们必须在那掐一下，得剪一帧，得有一个黑屏。完了，那这只能给一个定义了。

然后大家一想，就像刚才一开始说的，Manus 我们也没想好这玩意到底是什么，你怎么定义它，对吧？它到底是为谁去服务的？因为我们想的是去观察、去做达尔文，就想有一个壳，然后大家进来——不是一个壳，它是一个 playground。然后呢，那好，责任就到了我，因为我得写那个视频的稿。我想，那我们管它叫什么？所以整个这个概念就是我拍脑袋想的，是临时想的，然后就被大家采纳了。所以我觉得特别对不起大家。

但是我们觉得这个词其实偏技术了，因为它来自于所谓的 general purpose agent 这个概念，看上去好像是为了占一个位置而设计的这个词。

就是为了占。因为都说 2025 年是 agent 元年，看来你们想占那个最大的生态位，然后取的这个词。

其实不是，是因为……其实是因为挡住保洁阿姨才讲的这个词。这从市场角度来说，我觉得不是一个很好的选择，因为对于不了解技术的人来说，这是什么东西？这是一个很奇怪的东西。所以我们现在更想强调的一点是：做通用的 agent 是因为我们的一个技术选择。刚才我解释了很多，对吧？就是你有一个更好的技术架构，其实你可以让不同的场景之间有很好的协同性，并且互相增强那个网络效应。

比如说我们新的 Manus 1.5 里头，我们一直在强调 Website Building 这个能力，但实际上这个功能我们只开发了不到一个月，它的效果目前绝对是 SOTA 的。这就是因为我们其实是在一套统一的 agent 架构之上长出来的那个最后一公里。

但是这个对用户来说，其实我们没必要解释这么多。我们未来对用户的沟通，其实完全就根据客群去讲。比如说你是一个企业，那你可能更关注 Internal Tools、内部工具的构建，那我们就跟他讲：Manus 是一个非常好的内部构建的工具，同时它能帮你把各个环节串接起来。所以跟所有垂直的产品相比，我还想强调那一点——Manus 能做所有的事，做得一样甚至更好，且能多做一步，是这样的一个定义。

我觉得 agent 这个词，未来大家其实也不用太在意这个东西，它就是一种新的东西。那比如说大家需要一个负责设计的 agent 吗？我觉得也许是需要的，因为它会融入你特定的工作流。就好比在设计领域，如果没有 AI，你往回看也会同时存在 Final Cut Pro 跟剪映，就是这样的一个情况。

你觉得 Manus 会收敛吗？

你说收敛是指？

收敛到某几个更垂直的领域。

不会。我们会是这样：我们会做很多我们叫做"场景"的东西。比如说现在我们头部的几个场景来讲，批量文件处理、网站生成、slides 生成，但我们从来没有单独做过一款产品叫 Manus Slides，或者 Manus Website Builder。它仍然是在这样一个统一的 agent 架构之下，由我们的产品团队去优化最后一公里的体验。所以 Manus 永远是一个不断优化头部场景、且保持很强长尾能力的系统。

这是一个选择。

对，这是一个选择，刻意的选择。

Manus 这样的 agent，和像比如说 Lovart 这种设计类的 agent，你觉得它们长期来看关系是什么样的？

我觉得是这样：Lovart 一定会越做越专业，Manus 可能会有一定的设计能力，但是就像我刚才讲的，Lovart 是给设计师用的，Manus 是给有设计需求的非设计师用的。

且同时还存在另外一种关系，就是为什么我们非常强调我们现在有一个概念叫 connector，或者叫 integration，就是连接与集成。其实 Manus 之所以是一个通用 agent，是因为它能模仿一个人，它能模仿人去用各种工具。比如说我们自己内部就经常拿 Manus 调试 Manus。

那实际上如果你是一个设计师，你的工作每天其实也不是百分之百都在设计，对吧？比如说有的时候你需要基于一个设计稿，或者基于一个产品需求去做出一个设计。那你甚至也许有一个用法：比如说你们在用 Lark 或者 Slack 来讨论一个产品，你可以让 Manus 去帮你盯着这个 Slack，然后让 Manus 去用 Lovart 去完成这件事。所以 Manus 跟所有人，我觉得都不是一个竞争的关系，我们是一个网络中的节点。但很多时候价值其实不是在网络节点，而是在网络的边上。

你怎么看 Cursor 和 Claude Code 现在的关系？

我觉得这个是比较尴尬一点的，就是他们选择了一个最激烈的点。怎么说呢，AI coding 它不是一个垂域，它是一个通用能力。但是我觉得 Cursor 的加工非常厉害，所以它一方面启发了 Manus 很多；另外一点，我觉得 Cursor 的人才储备是不逊于这些头部公司的，或者说，头部公司中跟 Cursor 直接竞争的那个团队的实力，跟 Cursor 是可比的。

这就是我刚才讲的一点：创业公司跟大厂对比的方法，就是成为大厂。我不是说在规模上超越它——因为大厂不会倾注其所有资源与你一个人打——我们现在要做到的就是，我们在做 Manus 这件事的人、这个团队，比如说比某些大厂想做 Manus 的人、那个团队强得多，这就可以了。所以我们现在有将近 100 人。

Cursor 和 Claude Code，我觉得还有一个点，就是 Cursor 的选择空间还是比 Claude Code 要多一些的。Claude Code 仍然是 Claude 的一个延伸。当然我现在还在说，大家在分化，Claude 在 coding 方面有一些独有的优势；但实际上正因为 coding 是主赛道，所以大家追得也都非常快。比如说 Gemini 3 出来之后，大家会发现，可能 Gemini 在 agentic coding 方面还没有完全追上，但在比如说静态前端的美学方面会非常领先。

所以我觉得对于 Cursor 来说，有点类似于我们现在的一个状态，就是大家都在盯着这一个方向打，所以它有一定的灵活度。我觉得这个战争还没有结束。

那你怎么看你们——像比如说 Kimi 做了 agentic 的 model，他们就想走 Claude Code 这条路。那你们作为一个应用型的 Agent 公司，跟他们长期关系会是什么样的？然后你觉得谁能赢？

我觉得首先我们跟 Kimi 从来没有任何的竞争，因为我们没有国内业务。

国外的公司呢？就是你们应该也在国外的模型公司的主赛道上，对不对？主航道上。

我觉得是的。所以我认为最终一定是一个竞合关系，其实不觉得我们会输。就像我们已经跟 ChatGPT 打了第一仗，我们从效果上至少还是赢的。

你们中间慌过没？

其实基本就没有。

焦虑没？

我们肯定会焦虑，但焦虑不是源于这个。我觉得 Manus 整个从一开始就莫名其妙火了，到后来有太多事值得我们焦虑，所以其实竞争是一种最常态化的焦虑，它不会占你生活中大部分的焦虑。

好吧，你们焦虑的是什么？

每个不同阶段当然就不一样了。

我们刚才说到了 2024 年的 9、10 月份，后面每个时期焦虑的是什么？

2024 年的 9、10 月份，其实在 Manus 做完到发布前那段时间，是没有任何焦虑的，因为很享受。

对吧，很快乐。

很享受。而且我们也都是所谓的中登型连续创业者，我们去做完 Manus 之后，我们知道最终一定会火，是一个极有信心的状态，所以就一定会成，所以并没有太多的焦虑。

你做的过程中哪个时候觉得一定会成？

其实就是当我们跑完了几个例子之后。我们当时自己内部也没想好做什么，当时我记得是涛哥跑了一个例子，是找办公室，然后 Manus 自己去找资料、查地图、写程序，然后做出交互式网站，还提供一堆选项。之后我们觉得这个太酷了，一定能成。但后来一次次跑不同 case 之后，信心越来越强，当时是觉得一定没问题。

那段时间你们办公室的状态是什么样的？

就很嗨。当时我们是在北京的 E-Park，是一个共享办公室，而且很小。我记得刚开始的时候，我们那个工位只有 6 个。

就北京这边。我去过那个地方。但是那个地方我觉得特别棒，就是他们的一楼环境特别好。

就我们拍最早视频那个点。对。

然后当时那个状态是什么？

就是我们都特别对不起周围的邻居，他们经常就听见有一个奇怪的办公室突然爆发出声音——全都是我跟涛哥跟几个同事在嚎叫。

我去的时候那天没人。

好，有可能。

整个工区都没有人。

对。所以那一块就是完全不焦虑的那段时间，发布后就开始焦虑。

说说你们发布的时候的考虑吧。你知道外部对你们最大的几个质疑之一，就是为什么要弄邀请码，以及是不是过度营销。

好，这两个问题我终于可以回答了。我们其实很早就想去公开回应这个事，但我们觉得你瞎回应也没意义。我们当时内部就说，你没做到 1 亿美金 ARR 之前，就不用回应这个事。现在当然我们可以回答这个问题了。

到了是吧？

早到了。对。所以我们想说——

啥时候到的？

其实一个月以前应该是。对。然后现在的话，我们就可以正式地回应这个事。

首先我觉得邀请码这个东西，是我们为所有人趟了一条很重要的河。当然我不是说创造了邀请码这个概念。当时我们以前不是做 chatbot 吗？chatbot 当时讲到了，它的消耗量可能是 Agent 这个形态消耗量的几十、几百分之一。然后当时 Manus 我们做完之后，我们为什么要用邀请码这个机制？没上线前我们就决定了用这个东西。是因为我们在最后决定发布之前，跟所有的云厂商和我们的 Inference Provider——就是推理供应商——聊了之后，我们惊讶地发现了一个事实：世界上能够在第二天立即到位的算力，比想象中少太多了。

所以当时的情况是，所有我们使用的这些云和模型厂商没法提供这个量。比如我们用 Claude，Claude 说你们千万别放开，你如果放开我们会挂。所以对我们来说，唯一选择的方法就是去控量。那控量的方法是什么？那你就只能选一个类似邀请码这种机制。当然确实我觉得有别的更好的做法，比如说不应该有明确的一个码这样的一个东西，比如我们给定向邀请这些东西。对，但是我们当时其实没有想太多，我们就去把这个东西给做了。

但实际上我们后来在跟所有的合作伙伴一起不断迭代的过程中，大家意识到了：哦，原来 Agent 消耗算力的模式跟 chatbot 是不一样的——就刚才讲的 prefilling 跟 decoding 从三比一变成比如一百比一。所以逐渐逐渐地，因为 Manus 的出现，大家去适应 agent workload 这样的一个工作负载。

然后再后来，我觉得再用邀请码，我就觉得有点奇怪了。就是我们已经帮大家趟出了这样的一条路，云厂商也已经准备好了，你还何必去这样做呢？你想，如果当时我们能直接放开，那其实我觉得可能体验会比现在还要好。因为如果有充足的算力，大家不会遇见那么多问题——比如说当时我还记得，三月份用着用着可能就崩了，对吧，因为你真的没有那么多算力，然后我们的 scaling 也没有那么好，就会崩掉。如果我们把这些事情提前搞好，那我们何必用邀请码这个机制。

所以你觉得当时是因为云厂商没有准备好？

云和模型都没有准备好。就是那句话，就是——

但如果他们准备好了，你们的成本是能够 handle 住的吗？

handle 不住。但是因为我们对产品极有信心，我们当时一天烧几十万美金，我们觉得没关系，因为绝对——就是这个产品一定能成。

你们当时账上多少钱？

当时也没太多吧。之前还有融资额，反正钱是够花的，但是其实也很紧张。但是我们觉得这东西一定能成，根本不慌，就是绝对没问题，使劲烧。

所以很野的。

但是当时那个情况我给你描述一下。当时比如我们跟云厂商打电话，我们说我们现在需要加到多少多少 TPM。

上线前是吧？

上线当天。

OK。

我们说我们能不能临时加这么多，然后他们说没问题，你们是要下个月还是下下个月要？我们说今天下午要。然后他们大概是没办法。所以真的，那头一段时间，真的是他们在物理层面上去搬卡、插到机柜上给我们用。

搬卡插到机柜上给我们用。

我们当时就是——为什么后来跟 Google 的关系这么铁？就真的，我觉得 GCP 在这个过程中，当然包括后来 Azure 跟 AWS 都非常支持我们，真的对我们来说是雪中送炭级别的支持，甚至从别的项目、别的可用区把资源临时调给我们，然后这才让 Manus 撑过了第一个月。

2025 年初大家都没有预料到，今年的 token 消耗会指数级地增长。

对，因为它的输入输出比例变了，失调了。这就是为什么我说 chatbot 它的消耗量其实你是可以预测的，因为人参与的频率太高了，你得人触发才会有下一次的行动。而 Agent 首先它会持续自我工作，而且如果你还用 ReAct 这个模式去看的话，它的 Context 其实是一个 append only、只增的状态。如果你从模型视角看，每一轮迭代的时候，你需要重新 prefill 前面所有的输入——当然你会有 KV Cache 在这——但是它的输入量是非常大的，其实每一轮会越来越大。所以当时就是，在没有这样一款真正的 Agent 出来之前，云厂商没有准备好，这是第一点。

但是你说的是你们上线当天给你们打电话，那这个邀请码决策是在这之前就发生了，你们这个决策是怎么下来的呢？

就是我们需要一个控量的方法，但是因为我们也没有更好的办法，就只能选择用邀请码或者定向邀请。当然我们觉得现在冷静下来，可能定向邀请会是一个更好的做法。为什么呢？因为邀请码这个东西，我们没有意识到——我们知道产品一定会火，但没想到会被炒，这我觉得是非常不好的。定向邀请你不能炒，但是如果没有炒的话，可能烘托不出来这种氛围。

但问题是我们在国内火没有意义。就是包括 Manus 跟 Monica——就我们上一款产品——其实我们都一直是做出海的。这个其实也是当时我们觉得非常冤的一件事：你想，中国有这么多的企业在响应号召进行出海，无论是 AI，或者比如说 Shein 像这种做衣服的，对吧——

你选择不同的 market，我觉得是很正常的一件事。我们其实在中国比如突然火起来，对我们没有一个直接的作用，反而会让我们承受很大的压力。所以这也是为什么 Manus 当时上线选择的是晚上 10 点多，因为那是北美市场的早晨，我们是为了北美市场选的时间。对，是的是的。

这个是邀请码。对，这是邀请码。炒作呢？

炒作好，这个问题要非常郑重地回答一下。我可以直接这么说：如果我们在三月份发布的时候，如果我们有任何付费的宣传，我死全家。对，这个我可以说到这个程度。你想我们为什么要宣传？有必要吗？因为我们要做的是什么？我们要做的是海外的 prosumer 的市场，对吧。那我们该做的是什么？应该是去让那些真正我们要用的用户用起来，对吧。而如果我们在国内，比如说有人觉得我们买这些自媒体，其实对我们来说没有任何的好处。

那有人就问，那这些文章到底是哪来的？我觉得有两点回答很重要。第一点，我们自己都觉得很酷的东西，我相信大家一定会觉得很酷，对他们来说这是一个内容，他们值得去写。第二点是什么？我觉得可以套用涛哥?的一句话说，这是我们多年广结善缘的结果。我们都不是第一次创业了，我们这么多年一直比较积极、无私地去分享我们很多东西，我们也会上比如一些播客，或者经常写一些文章，去跟大家分享我们的一些见解。渐渐地，以前可能跟我们一起成长的很多小伙伴，他也许成为了很厉害的投资人，他也许成为了一个自媒体人，那这时候他看见你的朋友在做一款产品的时候，你是不是很自然，哪怕出于一个朋友的支持，你也愿意去写一下。所以我觉得大家把创业和媒体之间这些关系想得有点太复杂了。可能也许我是一个偏见，我觉得好像整个这个市场挺单纯的：你做出一个好的东西，且刚好是你的朋友，大家就会愿意帮你一下，因为这是一个广结善缘的结果。

但是我觉得 Manus 火了一天，它的热度好像迅速就降低了，你觉得为什么？

因为我们在国内没有任何持续的这个……我们其实在国内是处于一个可以叫灭火的状态。因为我们觉得，如果你把我们这个东西过度地进行一些曲解，对我们来说没有好处。我们只是一款 AI 产品出海的应用，不要给我们赋予太多的这些东西。所以你看我们当时在国内，我们所有团队没有任何类似于对外的这种发声，其实都是别人在一个第三方的角度来阐述我们。所以我们觉得在国内的热度降下来其实是好的。

那在海外呢？

在海外的话，我觉得这就是我们想要看到的。当时有人说我们在海外做营销——我拜托，Andrej Karpathy 你能买吗？对吧。这些东西你不可能买到的，对吧。我们首先让我们的用户群，就是最 pro 的这些人，看到这个产品的价值，他们先用起来，然后他们自上而下地去影响更多人去使用 Manus，这是我们希望看到的。所以这个流程肯定没有国内那种突然火得那么快，但其实也没有多少的时差。基本就是当时国内好像 3 月 5 号，当天晚上莫名其妙就火了，但其实美国基本就在三天之后，就开始自下而上火起来了。而且我们去看了，这两边链路基本完全不重叠。链路不重叠，对，是的。海外火起来完全就是靠比如像 Andrej Karpathy、Patrick Collison，还有 Garry Tan 这些人，他们先用起来，然后他们的影响力再去自上而下地影响；而国内可能确实是比如自媒体，还有一些朋友，他们写了很多的内容。

你们当时准备的邀请码有多少个？

邀请码其实是动态地加的。就是说我们跟云厂商打电话，我们说现在比如说能加到 20M TPS（token per second），我们算一下，那好，那大家能加出这么多码。然后后来更多的码就已经变成，除了给朋友以外，变成那种找过来我们就不好意思拒绝，所以就变成了谁跟我们比较熟我们就给谁。因为在国内我们知道，我们也不指望它在国内能比如说很大规模地靠邀请码传播或者怎么样，其实只是出于一种礼节性，他要我们就给了。

这个会让网络上很多用户的感受不好。因为你们说你们有邀请码，这好像也是一种承诺，但是后来这件事情就不了了之了。

我觉得邀请码不是不了了之，是后来我们用了极快的速度，大概不到一个月我们就把邀请码去掉了，就可以随便用了。所以我觉得这不是不了了之，这是最负责任的一个做法：我们在云厂商、模型厂商的支持下终于不用邀请码了。

但是你们很贵。

贵我觉得不是我们的问题。因为真的，当时可以说一个实话，Manus 是亏的，因为当时的 token 还非常非常贵，我们其实已经是在补贴用户，让他们来体验 Agent 这个形态的产品。

你们当时的定价逻辑是什么？

拍（脑袋）拍的。

拍的。

对，这个是我们觉得我们非常有问题的地方：第一，商业化能力其实还是比较有限的；第二，我们的 PR，或者说 marketing 能力其实也很差。我们当时定价的逻辑特别简单，就是 ChatGPT 好像是 20 美金一个月——而且我们死活想不通为什么是 20 美金一个月，后来当然也跟别人聊了一下，他们觉得 ChatGPT 好像也是拍脑袋拍的，但是没办法，直接就有一个锚在这。所以当时我们想，我们就从 20 跟 40 开始，然后就延续至今。因为这东西会有一个很大的惯性，你最好不要太随意地去调整你的价格，让已有用户、你最真实的用户可能体感不好。所以这方面我们就没有太大的一个变化。

定价没有什么逻辑是吗？

定价没有什么逻辑。

为什么不选择比它便宜呢？

因为是这样，其实这个定价没太所谓。因为 Manus 其实你无论给多少钱，你获得的是一个 credits 的数量，它本质上其实是一个按量付费的东西，所以只是保证一个基础订阅的价格在那。

那现在你们已经跑正了？

马上跑正。马上跑正。因为其实你要区分不同的 tier，我们还是有很多的免费用户。我们认为免费用户也是——你可以说这是一种我们的社会责任，或者怎么样——我们希望有更多的人能够体验 Agent 这个形态。

在 Manus 整个从做出来到火的这个过程中，肖弘的角色是什么呢？

我觉得几乎所有决策的最终决策人都是他。

嗯。比如说？

太多了吧，这你让我如何去枚举。你说火的过程中，还是说……

就是从做到火。

从做到火，那几乎所有产品的决策最终都是他了。

有什么是你们之间有一些争论的？然后最后谁听了谁的？

我觉得我们之间的争论都会非常务实地讨论。比如说一些关于到底要不要做一个单独的 chat mode（聊天模式）这些东西，最后的结论其实都是我们赶紧做一个试试。所以其实到现在为止，不同的用户用的 Manus 可能完全不一样，因为我们可能有海量的 A/B Test 在跑。当然，最终我们觉得最好的决策就是你限制一下时间，别为这个事一天一天反复、一直犹豫。一直犹豫，赶紧做就好，再去市场上去找反馈。对，是的。

你觉得你们今天的生态位是稳固的吗？

我觉得不是稳固的。或者说对于大部分创业公司，包括我们在内，其实我们都没有活着的权利。

你们都没有活着的权利。

活着的权利是自己持续跑才能争取来的。

嗯。火了之后生活发生变化没有？

有啊，就非常忙。尤其是就是……

就那几天，那几天是什么状态？

那几天其实就是颠倒黑白。因为我们其实非常理智，国内骂我们也好，称赞我们也好，我们怎么说呢，没有办法，我们也不想回应什么东西。但真正我们的客户在哪里、我们要关注什么？所以那段时间真正的痛苦来自于颠倒黑白。（笑）因为我们要支持比如说各个时区，现在 Manus 的用户其实遍布世界各地，真的是每一个大洲上都有很多我们的用户。所以那段时间我们团队没有现在这么大，大家可能真的就是在不断地救火，因为今天可能这个系统挂了，明天那个系统挂了，所以天天就是在救火，所以非常疲惫。

能睡几个小时啊那段时间？

那段时间我记得从第一周到第二周，基本每天就是零散的，可能加起来睡个三四个小时，都是那种间断性的睡。

间断性的睡。每天还是每周？

每天。

每天。每周这就死了。（笑）这个……办公室状态有更嗨了是吗？

还在那个小办公室。还在那小办公室。然后当时是这样，我们武汉有很大的一个团队，然后大家……这也是我们经常反思的一点，就是我们好像跨区协作能力蛮差的。所以当时大家想那算了，大家赶紧出差吧，我们赶紧在楼上租了一个更大的办公室，然后武汉的同事赶紧能飞过来就飞过来，大家不要做什么线上的工作，赶紧线下一起来讨论方案吧。然后那时候其实办公室氛围没有更嗨，真的就是非常非常疲惫，甚至当时我们那个书架上摆的更多的就是什么补剂、营养品。补剂，对，就是那段时间真的就是大家精神状态都很差。

我听说你们那段时间融资给投资人开会……

对，那段时间很有趣，跟投资人 pitch 我们都是站着开。对对对。其实是这样，当时我们还挺感谢投资人的，你知道吗。因为确实每天白天的时候，我们看见的网上大多是一些比如骂我们的东西，而真的跟投资人好好讲的时候，得到正反馈是我们一天中最温暖的一个时候，你知道吗。

懂得还是懂得。你怎么看待你为什么被骂？

我觉得有几点。首先一点是我最近意识到的一个事，这是我觉得最惨的一个点：很多国内用户骂我们的根本原因，是你用的根本不是 Manus。然后借这个机会，我一定要非常非常郑重地强调一下：你在国区 App Store 上搜到的所有 Manus 都是假的，那都不是 Manus。

那都是来蹭我们的人。所以我们有一部分被骂的原因是，你用的那个东西就是一个山寨品。另外一点其实我也能理解，因为一个产品如果突然火了，大家天然会觉得你是一个比如说很营销、或者怎么样的东西。但这个我刚才也回应了，如果我们当时有这种行为的话，我先死全家——这是一个很关键的点。

但是我其实站在用户角度也能理解，因为你听说了有一个很新奇的东西，但是它没有提供服务，大家的这种愤怒我也是能够理解的。我觉得这是一个 gap，对，这是一个 gap，是可以理解的。

但是现在对我们来说，我们的团队能力是有限的，我们很难说去服务于所有的用户。比如说我们甚至为了让大家能在一起——因为我们的沟通能力很差，那就大家都在一起。因为我们团队带宽有限，那么就先盯着有限的市场去做。所以这个东西我觉得不是一个……虽然可能让一些用户没能用到，但这就是我们能力所限，只能尽力。

中国市场未来会好好做吗？

我觉得这个比较难。对于我们来说，我们也没有那么多的资金去进行一些补贴性的东西。我们之所以一开始选择出海，其实原因也非常非常简单，就是因为海外的用户对于生产力工具的付费意愿更强。而 Agent 真的是非常贵的一个东西，像我们刚刚讲的，Agent 可能有点像工业生产，而不是传统互联网这种边际为零的东西。所以我们会非常非常慎重地去做这件事，我们要先保证自己能活下去，再去讨论这件事。目前我们还在活着的边缘。

那中国这部分的功能由谁提供，你觉得？

我觉得这个功能其实还是比较充裕的。在 Manus 出来之后，接下来几个月中，我看见有大量类似于 Manus 的产品出现，而且很多也是我们国内团队去做的，所以我觉得这个挺好的。但真用起来，我觉得难点就是，他们会跟我们遇见一样的问题：你到底要补贴到什么时候？你如何去把你这个产品的商业化跑通？这决定了能走多远。

见了什么有趣的人？

我其实见人非常少。因为我们现在分工是这样，可能涛哥——就是张涛——跟肖弘会去见更多的外部合作，但是像我跟潘潘，我们还是要保证这个产品的持续迭代，所以我应该刻意去少见一些人。

为什么海外很多巨头都愿意见你们？

我觉得有几方面吧。一方面是这样，很多时候他们是同时有云和模型业务的，比如说像 Google，比如像 Microsoft，那自然就是一个非常好的合作，相当于我们是他们非常大的客户。但与此同时，他们其实也在探索新的机会在哪。比如说我们前一阵跟微软一块发布了新的 Agent 365 这个东西，这样的话你就能把所有的电脑从一个 PC 变成 AI PC，那我们可能是这样生态版图中的一部分。

然后更多的一些是，因为我们作为 Agent 整个行业的一个代表，其实我们能给他们的一些东西，是影响未来他能服务更多人的一个范式的。像刚才讲到，比如说我们跟 DeepMind 这些合作、跟微软这些合作，其实我们也主动把很多我们在构建 Manus 过程中学到的东西，以标准化的 API 的形式提供给更多的开发者。比如前一阵 Google Cloud 开发者大会上，Google Cloud 的 CEO Thomas 直接就当着全场所有用户、所有开发者面说：之前有一些只给 Manus 用的 feature，现在你们都可以用。所以我觉得这还是让我们挺有成就感的，我们不仅做了一款很好的产品，其实我们的技术也在帮助更多人更好地构建 Agent。

Manus 1.5 中间有什么 Know-How 吗？

我觉得这有一个最大的 Know-How，就是通过一个新的版本号，是最好的让用户理解有更新的一个方式。对，这个很好玩。大家可能已经习惯了像基座模型以版本来断代，比如说 GPT-3、GPT-4 对吧。但实际上我们做 Agent 或者做系统的时候，你很多时候还是在于一个 feature，来不断去强调说这一个更新、这些更新，但用户的实感可能没有那么强。

所以 Manus 1.5 其实不是一个突变，它很好玩，它只是把我们过去一系列的东西以 1.5 的形式打包了。其实很多新的 feature 都是在过去几个月中迭代上线的，但这个过程用户就能直接体感到好像非常不一样。但说实话，其实 1.5 发布那一刻的更新没有那么大。这是很好玩的一个发现：你得让用户意识到你有变化，用户才能真的去感受到变化。对，这是第一点。

然后第二点，就是 Manus 1.5 非常大的一个技术演进，是我们把任务完成的速度进一步提升了，而且这个是一个无损的提升。简单点说，就是 Manus 1.5 能够用更快的速度完成简单的任务，但在更复杂的任务上去投入更多的 inference-time compute。这方面也是比较大的一个差别。但是放到平均体感上来说，应该快了 3 到 5 倍。

你那天还发朋友圈说，今天 Manus 有两件大事，一个是 1.5 发布了，另一个恐怕要老了写回忆录再说了。是什么事？

老了写回忆录再说。

通用 Agent 和 chatbot 的未来会是什么关系？因为所有的 chatbot 也会变成 Agent。

是这样的。但是实际上这个不是能力所决定的，chatbot 跟 Agent 绝对是用户群决定的。比如说对于所有人来说，他可能都有 chat 这个需求，但并不一定所有人都需要高价值脑力劳动的任务。但是我会自然地想通过它去做点啥，它就变成了一个可能在 AI 时代最大的入口。

这是 OpenAI 的故事吧。

对，这是 OpenAI 的故事。但我觉得这仍然是一个传播链路的问题。首先你在打的这个用户群、你所瞄的这个点，跟 OpenAI 就不一样。同时我们要保证的就是，对于这个用户群我们能永远提供最好的体验，他们的需求跟 chatbot 用户是不一样的。

chatbot 可能很多人其实心里知道，ChatGPT 也许此刻不是最好的 chatbot，比如实际上大家知道 Gemini 3 可能在某些场景下比 ChatGPT 还要好，但是对我来说无所谓，因为我只是拿它完成一些 quick and easy 的 task。但是对于 Manus 要打的这些人，他们对质量的敏感程度极高。我们做过一些双盲测试，比如说我们抽 5% 的用户，悄悄换用另外一个模型，然后就发现那批用户的满意度直接就下降了。所以我们其实在服务最挑剔的一群人，而他们永远要的就是此刻这一个时间点上 AI 能提供的最高的水平。

Manus 火了以后飘过没有？

什么叫飘？

飘过没有？飘，就是人飘了。

不会。因为我们其实每天收到的负面反馈会比正面反馈更多。

那会很悲伤吗？

也不会，因为我们都是老登、中登。其实怎么说呢，就是心理有点憋着一口气，为什么现在我们可以站出来说这些事？我们之前觉得说什么也没用，你还是得打铁还需自身硬。

你觉得 Manus 未来会有多大？它能服务多少用户？

我觉得不想用服务多少用户来说，而是我们还要讲，到底对于每个用户能为他产生多少的 agentic hours。对于一个高价值的用户，他可能把 Manus 用的用量是一个普通用户的 1000 倍，这实际每天都在发生。我们经常有一个用户一个月能付我们几千美金，为什么？因为他不断有很多的高价值任务要跑。

所以我觉得 Manus 追求的不是 DAU，这个是我们很早就想清楚的一件事，而是把最有高要求的用户、高价值用户的高价值 task 做到最好。体现在的可能更多的是我们的营收，而不是 DAU 上。

这个是肖弘的想法吗？

这个我觉得就是大家 align 后的一个想法。

所以你们的公司指标是营收，不是 DAU？

不是 DAU。

这个有趣。你觉得这个创业逻辑跟互联网时代是不是不一样？

我觉得完全不一样。

原因是因为公司有 token 消耗？

不是，就是两点，可能刚才我们都多少 cover 到了。第一点，AI 其实不是一个平台变化，AI 是一个技术增量，所以以前的优势是能够惯性发挥的。所以其实很多场景下是传统的强者加上 AI，强者恒强，强者更强了。虽然这话听起来比较悲观，但是应该说强者具有先发优势，且较好地利用了这一点。对，这是第一点。

然后第二点是什么？就是刚才讲到的边际成本问题，就是目前为止 AI 还是更像制造业，而不是像互联网。

这个还挺理智的。

是，不理智早死了。

所以你们没有试图去讲一个"我要做全球第一的通用 Agent"，或者是"全球最重要的入口"的这样的一个故事？

这是两个命题。我们一定要做全球最好的通用 Agent，这是一定要做的——最好的通用 Agent、最高质量。就是在当今这一刻，如果你抛弃一切成本或者什么东西，我们永远提供最高的质量。这是第一点。

但是如果有一个人来用低价打你们呢？因为你们要……

那我们用更低的价格打死他。

那他们可以不要啊，有大厂就可以不要营收。

大厂就不要营收，你说来卷，是吧？对。但这个东西其实是这样，我觉得对于一些用户来说，他们其实价格不是那么敏感。包括现在的 Manus 用户，其实我们也觉得 Manus 确实是挺贵的一个产品，但是我们用户问我的问题，你知道是什么？是说 Manus 现在你收了 40 美金一个月，你能不能让我看看，如果我愿意付 200 美金，它效果能变好多少。所以我觉得这个 mindset 是完全不一样的。所以这种定价的优化，基本不在我们的路线图里。

你们没有想要做最重要的那个 AI 入口之一吧？这是一个目标吗？

我觉得首先一点就是，可能不存在单一的 AI 入口吧。就好比说，现在移动互联网的入口是什么

好像确实存在一些。但我觉得，对于我们所服务的这个客群——就以我们自己为例，我们自己一定是 Manus 用户，我们自己手机上也有 ChatGPT——当你足够是一个 prosumer 市场的时候，这些人会自己知道什么时候用什么产品。之前 a16z 有一个很好玩的调查，说的是：如果你的手机上装有某一个软件，那么这个用户的手机上安装另外一个软件的概率，最大异常值是什么。这个说起来可能有点绕，就是说，对于一般人来说，你安装某个软件的概率是怎样的；但如果一个用户他手机上先装了一个软件，那另外哪个软件的安装概率会突然提升。你会发现，装了 ChatGPT、Claude、DeepSeek 的所有这些用户，他们的最大异常值全是 Manus。所以 Manus 几乎是在跟所有这些 chatbot 并存的一个状态。

当然这其实是好的解读。坏的解读就是，我们觉得目前 Manus 其实还远远没有渗透到所有我们想服务的用户，因为目前还是最业内的、或者相对来说比较科技圈的人充分了解了 Manus。这就是我们觉得我们在 marketing 方面还有很长的路要走，这方面我们得学习。

AI 产品有垄断效应吗？

我觉得有。但是怎么说呢，AI 产品的垄断，是你能垄断一个类型，但是这个类型可能也在不断地产生。像比如 ChatGPT，我觉得 ChatGPT 也许也真算不上垄断，因为 Gemini 最近势头也很好。但你能垄断一种心智，或者一个类型的心智，它能建立一个品牌。它能像比如说 Google 这种搜索引擎这种，可能一家统治 90% 的市场，或者像百度在国内。

Chatbot 会不会成为这样的市场格局，我不敢说。因为我对搜索引擎市场的认知，可能还停留在我还在做搜索的那个阶段。我觉得搜索引擎市场是非常特殊的，因为搜索引擎其实一半是在内容里头，就是说你的数据供给是无法因为技术的迭代而被颠覆的，所以搜索引擎是一个非常容易强者恒强的领域。对，因为你已经跟太多人产生了利益的关联，包括你的广告商、你的内容商。但是 chatbot 目前为止，可能还是因为到现在 ChatGPT 也才刚好三年，我觉得还是一个比较早的状态。比如说，如果你现在只是 2002 年的 Google 的话，现在一切还不好说。

而且好像还没有产生网络效应。

对，AI 产品的网络效应，我觉得是个好问题。我觉得没有看到任何一个真正有网络效应的 AI 产品。

这是为什么？

因为所谓的网络效应，我觉得更多是——你能有两种：一种叫 Build on Someone Else's Work，就是说你能基于其他人的产出进一步地去贡献，这是一类；另外一类，可能就完全是由于用户关系所带来的网络效应。

但这些东西其实在这两个场景里，AI 似乎都是附加值，对不对？

AI 是附加值，对，附加值。不知道加了它为什么就能进一步地连接人了。或者说，AI 不是产生这两个要素的关键点。AI 是能够帮你提效，能够帮你完成任务，能够给你产生结果、产生交付。

那可能新的网络不是人和人的，是 AI 和 AI 的，或者人和 AI 的。

要这么说的话，我觉得是有的。包括我刚才一直在强调一个词，比如说基础能力、或者原子能力的网络效应。我们讲过 Manus 其实增加能力是非常谨慎的，但是我们每次都要保证，这个能力能跟别的能力形成组合拳。用了组合拳这个词，是什么意思呢？就比如说，最早我们给 Manus 加入了一个看图的能力。看图能力其实一开始想法很简单，只不过是说希望 Manus 能看一看它生成的图好不好。但后来我们发现，加了看图、或者说多模态输入能力之后，Manus 开始自己学会去检查自己做的网页是否能玩得通。所以你增加一个技术能力的同时，它能跟你通用 Agent 这个层面上所有别的能力之间产生交互——这不就叫做原子能力的网络效应吗？这是我们已经观察到的：你可以让你的 Agent 能力以一个指数形式提升。这是第一点。

然后第二点，如果你说 Agent 跟 Agent 之间的网络效应的话，那看怎么解读。像比如说我觉得 Manus 的 wide research，就是我们这个广域搜索的能力，其实也是一种，也许是 Agent 之间的网络效应——一个 Agent 可以调度很多别的 Agent，它们之间还能互相通信，去共同完成一个单独的 Agent 无法完成的任务。

然后另外，当然也有些人在尝试，就是说让 Agent 加入到人的协作的上下文中。这我们也在做一些测试，比如说 Manus 现在能跟 Slack 打通。它能带来一个比较好的点，就是很多时候我们的讨论是不带 AI 的，但实际上更多的讨论都是在人与人之间无形中产生的。这块可能就是 Agent 跟很多人之间的网络效应。但目前来看，这可能还是因为偏专业，没有大家想象中那种爆发式的网络效应。

然后如果你说，像比如说 Agent 之间社交的这个形态的话，那我觉得这可能不像是我们这种做 prosumer 市场的人所能看到的，那可能更多是偏娱乐这个领域。像我刚才讲的，就是让 Agent 代替人去社交，这可能也是一种网络效应。

如果一个公司要做某一种 Agent，他可能希望被 Manus 调用，你对他有什么建议？

我觉得这个东西其实你不需要为 Manus 做任何的优化，这是我们非常坚持的一点。其实是这样：你看，现在我们觉得做 Agent 最大的难点是什么？我们可以反向来思考这个问题。是因为就像自动驾驶一样——自动驾驶面对的是物理世界所有的基础设施都是为人而设计的；而现在赛博世界所有的这些基础设施，包括网站、网页，或者各种 APP、API，都是为人而设计的。所以 Manus 的想法是，我们不能指望一夜之间世界就为 Agent 做好了准备，而实际上我们应该去不断地让两侧相向而行。

比如说最简单的一点，就是现在大家有了 MCP（Model Context Protocol）这个概念，但实际上 MCP 面临诸多的问题：比如说生态不成熟，很多开发者提供的 MCP 服务本身质量就参差不齐，且大部分的服务其实是没有 MCP 的。所以 Manus 的选择是说，如果有 MCP 当然很好，我可以用 MCP；但是别忘了 Manus 是一个通用 Agent，如果一个程序能通过 API 的形式去调用一个服务的话，Manus 可以自己去学习这个 API 文档，然后自己通过 API 来使用。如果再不济，你这个服务连 API 都没有，那你总是给人用的吧？那你大概率有个网页，那 Manus 会再一次降级，通过浏览器去模拟人的方式来使用这个东西。

所以我觉得对于第三方的 Agent 来说，你不用为 Manus、或者说未来的通用 Agent 做任何的适配，应该是我们去适配你。

Agent 的网络可能会形成什么样？

Agent 的网络，我觉得这个词很大。我知道 OpenAI 有一个它的 L1 到 L5 的那个图，但我觉得这可能只是 OpenAI 的观点，可能不算是一个非常共识的事。我们可能还是从更务实的一个角度去出发。

我觉得，如果你考虑 Agent 有更多的 proactiveness，就是它的主动性的话，那 Agent 的网络可能会形成这样：相对于有一部分垂直 Agent，它其实掌握一部分数据性的差异，比如说有些数据只能在某一个垂直 Agent 那里获取，那我觉得它的网络与其说是一个全联通的网络，更像一个星型的。就是说星型，就是 Star。对，就是说它有一个调度者。

有点像你刚才说的入口那个概念，它在利用不同的 Agent。

对，但是它可能难以形成一种完全互通的、全联通的网络。

所以通用 Agent 会成为那个入口？

我想是的。

为什么会是这种结构，你觉得？

因为还是刚才那点：如果你做的是垂直 Agent，你在做一个工具；如果你在做一个通用 Agent，你在模拟一个人。

所以做垂直 Agent 应该是为像 Manus 这样的公司做？为 Agent 做，还是为人做？

我刚讲的这就是两条路。如果你想做一个给专业人士的东西——刚讲了，你如果想做一个剪辑 Agent，且为现有的剪辑师去做的话，那你做得非常垂、非常专，这是给人用的。但是如果你想做一个为非剪辑师、但有剪辑需求的人做的产品，那你可以考虑做一个非常简单易用的界面，同时也暴露出足够多的 API，然后我们一起把这个生态给做好。对不起，是 API 或 MCP。

你说你坚信纯血派 Agent，什么叫纯血派 Agent？

对，Agent 这个词的定义其实是一件很含糊的事。我觉得大部分人会把两个概念混在一起谈：一个叫做 Agentic Workflow，一个叫做 Agent。这方面 Anthropic 有一个 blog 写得比较清晰。就说很多人说 Agent 要追求一个稳定性的话，那你可能更多的是在用一个 workflow 的方式去做 Agent，但在我们眼中这个不叫 Agent，这个就是 workflow。

而我们认为什么叫纯血的 Agent？就是说它其实没有人为加的约束，而是说完成一个任务的所有的过程和方式，是由智能本身决定的。这个我觉得它的天花板会非常非常高。当然你跟现在此刻来对比的话，可能 Agentic Workflow 的可复现性会好一些，但是我觉得这是一个可以解决的问题。所以我们非常坚信就是要做纯血的、由智能主导的 Agent，而不是以规则主导的 Agentic Workflow。这才是更符合我们刚才讲的 The Bitter Lesson 的这一件事：用通用的方法、投入更大的算力去解决问题，而不是加入更多的人为的知识。

这在你的实际工作中有做过这样类似的选择吗？

有的有的。这是我们每天都要讨论的一件事，就是可能比如说——

比如说舍弃过什么？

其实舍弃的东西非常多。我举一个比较简单的例子：你要让一个 Agent 做数据可视化的工作。那么比较简单的、纯产品驱动的做法应该是说：好，那我要保证所有语言下的数据可视化效果都非常非常好，你不能因为有不同的语言而产生比如字体乱码这些问题。那之后它可能把这块写成一个叫 Agent、Sub-Agent 之类的模块?，或者说你写很多单独的 Prompt——比如说当你要做数据可视化的时候，你应该注意什么东西，写一大堆的 Guardrails。

而你每增加一条约束，其实你都在减小模型的 Diversity，减少模型的多样性。

那我们的做法是什么呢？其实就是刚才讲的，我们只不过是加入了一条查看图片的能力。这样的话我们期望的是什么？是智能能够通过自己查看这张图，自己发现说：哦，我原来有字体选择的错误，导致中文渲染失败，而去修改这张图。这样我其实解决的不是一个问题——比如说它还能检查到：哦不行，我画的这个图表其实有两个元素重叠了，那它也能够去修复它。

所以这样的话，你就能从打地鼠?那种在那儿堵所有漏洞的模式，变成让智能的泛化性在帮你解决更多你还未发现的问题。所以我觉得这是纯血派 Agent 的一种思维方式。

当然，你做这种直接去修补的事，永远是很有吸引力的，而且这更符合传统软件工程和产品经理的直觉。那这时候就是我要站出来的职责，就是拦住所有人：不要这么干。

你还说市场上关于 Agent 的做法都是错的，展开讲讲。

没有都是错的。刚才我讲了一点，就是很多人过于执着于让 Agent 模仿人类的分工这件事，我是非常不认同这一点的。对，我就是说，不要把人因为生而为人的限制搬给 Agent，你应该站在模型的角度去思考问题。

或者说，我们在做产品的时候经常说一句话：如果你真的是在做 Agent，你同时在做两个产品，一个是给人用的，一个是给 Agent 用的，而这两个东西的思维模式是不一样的，但需要一个很好的技术架构把两者融合在一起。

给 Agent 用会是什么样的？对不起，是给模型用的——给模型用的话是什么样的？

就这么说吧，模型其实它的思维模式跟人是不一样的，或者说它根本就不是人。而人的话，你是因为有些先天的训练，所以说我是一个设计师，我更懂什么；我是一个程序员，我更懂什么。但讲真，大家用的模型现在其实都是一个通用的 LLM，那这个假设其实就是错的，对吧？

那其实你应该做的事情是减小它犯糊涂的概率。而这块你的做法不应该是说「我赋予你一个人格，你怎么怎么样」，而是通过一些 context engineering 的技巧，比如说约束解码、action space 的设计这些技术，来让它更好地去完成它自己份内的事，但又不让它丧失全能性。

这我说的可能有一点空泛，但是可以参考我之前发的各种文章。

所以把 Agent 人格化是一种人的自恋。

对，是。这是 The Bitter Lesson 说的。

是吗？

The Bitter Lesson 有这句话。

好的，我得再去读一下这个。那我太同意了。

你们的组织有发生过变化吗？Manus 出来之后。

有的。而且我觉得这其实不该说叫变化，就是我们也在探索一种新的可能性，因为在此之前也没有所谓真正的、纯粹的 Agent 公司。

我们觉得现在我们的结构可能有几个比较有特色的点可以分享一下。比如我们现在还是大部分人都是研发，但是团队会比以前那种软件开发更奇怪一点。当然，传统的比如说移动端、前端都在，然后后端、商业化这些也都有，但是我们会有两个很好玩的团队。

一个团队叫做 Sandbox Team，其实就是负责虚拟化跟运行环境的团队，他们要维护的是一套给 Agent 使用的操作系统——这就是刚才讲的，负责给 Agent 做产品的一群人。

另外还有一个我们就叫做 Agent Team。Agent Team 由所谓的 Agent 工程师组成，他可能负责的就是整体架构的开发；然后还有一部分是 evaluation，就是评估团队；还有一个很小的 research team。这三部分人共同组成 Agent Team，大概有十几二十个人。

我觉得 Agent Team 和 Sandbox Team，在传统意义上来说可能会被融入比如广义的后端研发当中，但我们还发现它其实比较不一样，因为它在做的这个事情不是面向人的，是面向模型的一个工作。

他们的工作主要会包括哪些我们意想不到的？

意想不到的……我觉得对我来说当然都是意想得到的事情，但是我觉得有几点。

就是好像 Sandbox 团队在做的事情，更像是在教一个不会用电脑的人如何更好地用电脑。而 Agent Team 在做的事情，其实是如何设计一套稳健但统一的架构，让我们能够持续地跟上模型的进步。

这其实是很有意思的一个话题，因为模型进步的速度真的非常快。如果你考虑到不同厂家都在迭代，基本是以周为单位的一个变化。

Agent Team 他主要的工作既然是 Agent 的框架，我们如何去保证能跟上呢？我们自己有一套比较好玩的方法，我们叫做「弱到强的衡量」。

这是什么意思呢？就是整个 Agent 里你有两个外部变量——对不起，不叫外部变量，就是你有两个重要的变量影响你的质量：一个是模型，一个是 Agent 框架。这块你要做消融对比，就是 ablation study。

这块的做法是什么？因为面对模型未来的变化，我们要保证每一次模型迭代，我们的框架能够受益最多。那我们的做法就是：我们先把一个当前版本的 Agent 框架锁死，然后选一个同源的模型家族，比如说同样都选择 Gemini 或者 Claude，你拿它的弱版本跟它的强版本进行对比，跑同样的 benchmark，然后你不断调整你的 Agent 框架，来让它们之间的 delta 最大。这样我们能够期望，当下一代模型变强的时候，我获得的增幅是最大的。这就是我们 Agent Team 和 eval team 要经常关注的一点。

文化有变化吗？

文化的话我觉得有一些。就是可能从 Monica 那款产品——它是一个非常大而全的产品，当然 Manus 也很全，但做法不是在单点击破。之前可能更多是觉得：用户有需求我就要去做，我的做法是用一个最快的路径，点到点最短的一条路去实现。

而 Manus 的话，其实我们会有非常多的考虑：你这样一条路你是能走通，但你有没有跟别的原子能力产生网络效应？所以现在我们做每一个新功能前都会非常慎重，而是要保证每新增的一个单点的能力都不是一个单点——这句话说得好绕——就是每增加的一个新能力，都让系统整体获得一个收益。

所以是一个非常节制的状态，这跟以前的心态很不同。

你们放弃过什么 feature 没有？

放弃的 feature 我觉得非常多。比如说像很多语音相关的事，我们其实都放弃了。

为什么？

语音输入当然我觉得很有用，但是比如说这种语音的输出，或者主动去调用一些东西，我们觉得首先这类东西不一定要由我们第一方来全部做完，因为我们跟大家不是竞争的关系。比如说我自己，我会直接让 Manus 连接我的 Granola 跟 Notion，我去使用，这没有问题。

然后还有一些功能，比如说像生图跟生视频，虽然我们有这个功能，但我们也没有非常非常大力地去优化它，因为我觉得这个东西是一定会做得很好的一个基建之上的事情。我们没有特别多差异性的时候，我们没必要非常深入地去做。

然后更多的这些事情，其实我们都是以一种非常开放的心态去做：如果这个通用 Agent 靠自己的泛化能力就能解决的话，那我们没必要专门去做这件事。因为我们很可能投入不够，却给用户做了一个次选，这个是不好的。因为别忘了，我们的用户是最高价值、有最高要求的用户，他们值得最好的。

为什么你一直在强调你们跟所有人都不是竞争关系？

因为我觉得这是事实。这就是我们做海外市场之后发现的很好玩的一点：他们可能因为之前 SaaS 领域做得实在是太成熟了，所以不同服务之间的互联互通，既是一个技术层面的事，其实也是一个——你可以想到——涉及到 branding 的概念。

比如说我们经常会跟像 Notion、Microsoft，还有别的这些创业公司，一起做联合的发布。因为很多时候都是这样：当我有一个能力、你有一个能力，当这条边联通的时候，它产生的价值是非常非常大的。而且 Manus 作为一个通用 Agent，我们一次甚至能串接多个服务。像我们刚才讲到的，我自己的使用场景是 Notion、Granola 和 Ashby 三个服务之间，Manus 把它们都串在一起。

所以我觉得，与其跟每一个都竞争，你去做一个比不过别人的东西，你为什么不让大家一起去做呢？这个我觉得就是我们从 Monica 学到的一个很大的经验：如果你要做很多单独的 feature，做起来一时爽，但是你要维护它，并保证功能是长期有竞争力的，是很累很累的，那可能会导致你的团队无限膨胀，所以这是一个不好的事情。应该去充分利用别人做得好的东西，并产生一个 synergy，而不是去跟别人直接硬碰硬。

你过去这大半年做的最重要的几个技术决策是什么？

你作为首席科学家，做过的最重要的技术决策是什么？

我觉得有几个。第一个就是，我们没有盲目地去追 reasoning 这条路。就是刚才讲到的，其实你按现在比较朴素意义上的 reasoning model 去做，会导致 instruction following 跟 tool call hallucination 的增加。所以这是我们当时做的比较重要的一点，我们用了一个比较另类的方法，用一个单独的 planning stage 来做这件事。

然后还有一个比较大的点是，我们对于 MCP 的决策是非常保守的。MCP 出来之后，业界整体都非常 high，很多人就开始去接入。但实际上我们当时觉得，这会严重污染你的 action space，而且会导致你的缓存命中率下降——因为你每次动态发现工具、卸载工具，都会导致缓存命中率下降，而缓存命中率下降会严重影响你的成本。所以当时我们也花了一些精力，去研究了一套不在原生 action space 内的 MCP 调用方法，这个后来当然也被 Anthropic 写成了博客。

然后还有一些，像我们其实整体对 context engineering 做了非常多的工作，而且这块我基本全都共享出来了，比如说对于文件系统的使用之类的这些东西。我觉得这就是一些连续的技术方面的决策，没有哪一个是最重要的一点。因为我觉得做 agent 其实跟训模型很像，你更重要的是做对1000 件小事，而不是做对三件大事。

你有后悔的决策吗？

肯定也有。但我觉得后悔的可能都是更细微的一些事，因为我们调整得非常快，所以很难形成真正后悔的东西。

对模型呢？就是在模型决策上，你有什么后悔的决策没有？

是在用模型，还是训模型？

训模型。

是有一些。比如说一开始有点太盲信小模型了，其实参数量还是很重要。

还会盲信小模型？

对。因为当时其实有这样一个假设——待会可以换一个方法来回答这个，我先说完这个吧。当时的想法是：agent 其实能更高频地与外界进行数据和环境反馈的获取。那我们当时想，是不是有一种可能性，就是小模型跟大模型里头，一部分参数量都用在了参数化的记忆或者知识上，那对于 agent 来说，是不是参数化知识没有那么重要？如果你的小模型有足够强的工具使用能力的话，知识是可以动态弥补的。

但后来发现——怎么说呢，实验结果是否定的。我们的反思是，为什么也许是这样：你很难去完全分离什么是知识、什么是记忆，哪些是泛化能力、哪些是参数化的背板。后来发现这是不现实去区分的，所以大参数量还是有用。

我听过一种说法，他们觉得 Manus 只有你一个是研究员，或者说你的研究工作是独立于所有人的。他们觉得这种研究员的配置和管理方式，或者说组织方式，跟不上现在全球 frontier lab 的竞争。

我觉得这个问题首先它的一个基础假设是错的：不止我一个人，我们是正常招 researcher 的。

另外一点就是说，我觉得首先有一点是，"跟上所有 frontier lab"这件事是不成立的。就是我们的目标不是说要跟上所有 frontier lab 在模型方面的工作。我刚才一直在强调一点，就是说我们至少现阶段，跟所有 frontier lab 还是一个共建的关系。或者用一个更功利的角度来说，是我们成功地把模型训练这件事外包了出去。那么这样其实就是用户给我们的钱，同时服务了用户，且让我们有影响力，让别人帮我们训模型。

那我们内部 research 团队更关注的，其实是一些非共识性的东西，包括其实很多 context engineering 方面的工作是要做大量实验的，这些东西不是纯靠工程能解决的事。

你前段时间在做 online learning（在线学习），这个有没有什么可以分享的？

是的。首先 online learning 这个词，它现在的解读有狭义和广义的。狭义上的 online learning，大家可能会比较关注说，到底能不能通过持续地改变参数而获得一些改变，这是一个严格上的定义。但实际上我发现，现在大家把三件事混在了一起：第一种就是刚才讲的，这是狭义的 online learning；第二种应该是 mass personalization，就是大规模个性化；第三种其实不是 online learning，而是更像我上一代创业做 Magi 时我们做的那些，应该叫 continuous learning，或者叫 lifelong learning。

这三件事解决的问题是不一样的。比如说你如果要做 mass personalization，就是大规模个性化的话，其实你并不一定非要用一个参数化的方式去做。比如说你可以像我们刚才讲的那种，基于用户的协同的一些行为模式，甚至以 prompt 的形式去动态注入一些东西，通过 in-context learning 的方式让模型的行为发生改变，这样其实是更高效的。因为如果你为每个用户——即使很小，像 multi-LoRA 的解决方案——其实你也让每个用户有一个不可复用的参数在那里头，那么你的推理效率可能会变得更低。虽然也有一些解决方案，像 S-LoRA、Punica 是吧，还是什么东西，我有点记不清了，是比较老的一些工作，他们号称能够解决 batch size 的这个问题，但实际上你的推理效率其实还是降低了的。因为很多时候你需要规模效应才能降低成本、降低 latency。所以我认为，mass personalization、就是大规模个性化，你不一定要以 online learning 或者参数化的形式去完成。这是第一点。

第二点就是说，到底是要持续学习，还是在线学习，这个我觉得是一个非常大的区别。这更多是看你的目标是什么。如果你要建模的任务，它的理想分布是随着时间而改变的，那你是要做持续学习的。比如说——我很难想象哪些领域是这样，可能像金融市场也许是这样的，就是今天的正确答案不一定是明天的正确答案，那我觉得真正的 online learning 是很有价值的。

但实际上你看现在一些所谓的 online learning 的 practice，其实我觉得它只能称为一个 on-policy 的持续学习。比如说，举例有一些 coding agent 的公司，他们在说我能通过持续在线去收集用户的一些接受和拒绝率，来优化比如说 Tab 补全的准确率。但你看这一个任务，其实并不会因为时间的改变而影响它的理想分布。那这样的话，我觉得你其实只是一个 on-policy 的数据收集，并周期性地在优化你的模型，这个更像我们之前做 Magi 时候做的这个事情。

但你会发现，如果你的任务本身不具备这种动态性，其实你很快就会把这个 benchmark 打透、把它 saturate 掉，所以它不是一个有持续提升空间的事情。所以我觉得这个东西还需要持续去看，我没有看到一个非常值得我们在 agent 领域立即下注的应用。

你觉得 agentic 的模型应该怎么训？你觉得给这些模型厂商有什么建议？

对，我觉得刚才已经提了几个了。

第一个就是，与其无限地去扩展 context window，不如让模型学会 compaction awareness，就刚才讲的，让模型意识到自己的上下文可能会被压缩，并做出更好的选择，更好地了解文件系统该如何去 offload 和 retrieve。这是第一点。

第二点就是刚才讲的，关于 reasoning 的优化目标，不要以这种纯"缸中之脑"的形式去做，你应该去考虑如何更好地去结合 observation。或者有个词叫 TIR，叫 tool-integrated reasoning，就是有工具集成的推理。对，这是一个非常重要的方向，它跟那种完全靠 RLVR 去解竞赛编程和数学，是完全不一样的一个思路。

第三点其实可能跟 agent 的工况有关。就是在 chatbot 场景下，永远是用户跟模型交替执行，用户跟 agent 应该是"你等我、我等你，你等我、我等你"。而 Manus 其实刚出来的时候，有一个让大家觉得非常新奇的体验，就是 agent 在持续工作的过程中，用户可以随时插嘴，要么是改变目标，要么是补充信息，甚至去终结它。这个其实很多模型还没有完全掌握这样的一个交互模式——它可能跟用户处于一个异步的空间中。对，这个也是我觉得非常值得去做的。

第四点，我觉得模型应该更关注一些 error resilience，就是说对于错误的处理和恢复能力。对，这个东西我知道在 agentic coding 领域其实已经有了更多的关注。因为如果你把 agent 部署在真实环境中，错误其实是一个常态。可能来自于比如环境的报错、系统一定会有问题、资源受限，或者你写的代码会报错；但实际上有很多是非代码性的错误，比如说你在做一份 slides，或者在做批量的文件处理过程中，你一定会遇见很多意料之外的事情发生。而你发现有一些模型，它可能要么会放弃掉，要么甚至会陷入一种类似于死循环的状态。但最好的模型应该是，它永远能找到一条别的路去尝试，这是需要专门去训练的一件事。

目前我比较想强调的就是这几点。

你的微信为什么一直叫"微信小助手"?

我觉得就是一个娱乐精神,而且很早的时候就叫了这个名字。当时就想看一看,有哪些跟微信官方很像、但仍然能被使用的 ID。最早想叫"文件传输助手",但意料之中都不能用;后来因为微博的官方号叫"微博小秘书",所以我就试试叫"微信小秘书",后来腾讯也果然禁止别人再叫这个名了,那我觉得很好,就保留了。

这次创业跟你之前两次有什么不一样的地方?

我觉得首先现在创业的成本,比以前还是要高不少的。

高多少?直观感觉。

因为刚才讲的,你如果做移动互联网的话,其实你的边际成本很低;但现在的话,其实上来就是挺重资产的一个投入。比如从 Manus 上线第一天起,那基本就是几十万美金、几十万美金在烧。对,所以这是第一点。

然后第二点就是,我觉得这是一次让我们充分参与全球竞争的创业。我们甚至经常内部开玩笑说,有一种从 CBA 打到了 NBA 的感觉。确实感觉可能我们之前哪怕在做 Monica 的阶段,经常会觉得好像我们做得还不错了;到现在的话,虽然我们经常说 Manus 现在可能已经有 100 million ARR 了,但如果你横向去看同样这些各行各业的头部选手,我们好像又不算什么,可能这就是一个 NBA 的平均水平。所以就觉得还是在学习中。

过去一年对 Red 有什么新的认识吗?

对 Red 的新的认识——对,肖弘。我觉得是比较符合预期的,就刚才讲到的,情绪依然很稳定。当然我觉得可能更多的了解是,即使像他这样、可能比我经验更丰富的连续创业者,其实在很多时候依然会有很多人性的脆弱。

对,就比如说我们经常讲好像我们不在意或者怎么样,但其实有时候听到一些东西,大家心里还是觉得挺尖锐的。肖弘可能比我……他没有我那么没心没肺,他很多时候还是比较容易受到这些事的影响,他会不开心,甚至就是很着急。

对,我觉得这也就是团队在一起的好处,我们可以互相分担一下痛苦。虽然肖弘经常说一句话,说接下来一段时间我可能很抑郁,你们不用帮我——然后谁会真的就放他不管呢,对吧。

他反而情绪不稳定是吧?

不是不稳定,他的情绪是稳定的,但他很容易低落。他不会那种很忽然怎么样,他没有我刚讲的那个艺术家的问题。对,但他也是比较容易受伤的一个人,更感性一点。对,是的。

团队其他几个成员呢?我觉得你们之前是什么样的协作关系?

我觉得是这样,大家其实在共同的话题上讨论得非常多,因为刚才讲的,每个人其实都有很综合的经验。但实际上现在的话,大家因为术业有专攻。

比如说跟涛哥的合作就会非常有意思。涛哥其实真的现在是——我们觉得他是"出差圣体",经常要去全世界各地参加一些比如跟合作伙伴的活动这种东西。所以涛哥更多是给我们带回一些比较新的、方向性的内容。我觉得这其实可能是做 CPO 这个角色的最高境界:他不仅是一个对内的产品的指导,更多的其实是对整体行业有产品洞察的输出,并把交叉的观点带回给我们。所以涛哥很多时候给我们的是一些非常宏观的建议,但是很快都能落下去。比如刚刚讲的 Wide Research,也是涛哥在飞机上综合了很多不同的想法之后,我们一起讨论出来的。

对,然后像 marketing 这边,我们可能觉得我们正在有一个比较大的思想的转变。之前或者过去一年中,我们经常觉得 Manus 的增长——我们内部开玩笑叫"踩着西瓜皮",就是其实我们几乎没有什么定向的增长动作。这可能也是我们刚才讲的、让用户自发选择的一个负面作用:我们从没有引导过,或者说我们想获取哪一类的用户,完全就是什么用户用,我们就服务他们。但实际上如果你从一个获客和增长的角度来看的话,这样好像不是非常主动,或者说不是非常可控。所以我们觉得接下来有一个转变,就是可能更多地由产品驱动的"踩西瓜皮",变成我们服务于我们的增长,去做很多功能性质的东西,这是一个比较大的变化。

然后像内部运营的话,这一直都是贯穿始终的,没有什么跟别的公司特别不一样的点。

产品和模型谁的话语权更大?产品和技术在你们公司。

产品跟技术,我觉得是这样:我们首先明白技术是要服务于产品的,但是技术基本对很多事是有一票否决权的。比如说刚才讲到的,产品可能会有一些非常诱人的、快糙猛的做法,像刚才讲到的一些事情——你是否要放弃"纯血 agent"这个想法,而采用一种快速的 fix?但这种情况无论是我还是技术,都会站出来直接阻止这件事发生。

那你们大概是产品两票,就是 Red 和张涛;然后你和潘潘是技术两票?

不,我们非常反对投票这个概念。因为我觉得投票这件事其实是在异化团队:如果有不同的观点,大家可能会为自己的观点去服务。你应该看着目标,而不是投票这个手段。大家如果目标是一致的,那你一定能去达成一个共识,而不是通过明确地站队去投票。所以我们几乎不会搞投票这个事。

你们就是讨论?谁会更强势一些呢?

对。其实讨论的过程中没有人强势,但我们会期待 Red 来做一个最终的拍板。

所以讨论的价值,我觉得不是说讨论出一个结果,而是说更多的人提供出更多的方案,就刚才讲的 Alternatives。就是一件事,如果目标是确定的,你有越多的可选方案越好,不一定是你要想出一个最高质量的;要不然的话,你供给大家做决策的选项都不够多。

现在这个公司是 100 人,之前两家公司的团队大概规模多大?

我以前带过最大的团队也就 10 个人左右。第二家公司是 10 个人,是的。

你觉得 AI 时代公司的组织方式和协作方式发生变化了吗?组织有没有变化?

我觉得组织的话,变化其实可能没有大家想象中那么大,但反而组织中多了很多的 AI。这其实也是我们比较主动在引导的一件事。就是像我们公司有一个很优厚的条件:如果你使用任何 AI 产品,不只是 Manus,比如说你使用别的第三方的 AI 产品,我们都尽量全都报销。我们非常鼓励程序员比如用各种 coding 的 Agent;对于非程序员的话,你有各种能提效的工具,你都全都可以使用。因为我们觉得作为一个 AI 公司,你首先得让员工去了解现在到底发生了什么,业界的前沿是什么东西。

所以我们觉得,与其说是整体的组织结构变化,不如说是发现更多的人可能让他自己有了两倍、十倍的生产力提升,但他并没有、还没有到一种 AI 能够替代哪些岗位的状态。

你是不是不喜欢管人?

我非常不喜欢管人,我一开始就说了这一点,我觉得管人很痛苦。

你为什么不喜欢管人?

就是人的复杂度比 AI 还要高。而且人的复杂度其实是——怎么说——会随着人数增加,还是指数级增长的一个复杂网络。但其实程序你写得好了,你有足够好的设计模式的话,整体的复杂性的增长是可控的。

我觉得你性格很开朗,你为什么不喜欢管人?你除了觉得人复杂,还有什么原因吗?

我觉得它是很占用我的带宽的,因为我觉得我的体力其实挺差的。

没看出来。

我只是跟你聊的时候能聊得比较多,但其实我的体力是挺差的。就是如果我一天把更多的时间花在了管人,或者说广义的非技术层面的事上,我每天有效的输出就会变得少很多。

而现在的话,我认清了一件事:与其去弥补自己、或者去补强自己哪方面的能力,不如把这方面的能力外包出去,还是自己做最擅长的事。