Manus为何由他们团队成功研发

故事要从一个引人深思的巧合说起。去年10月26日，Arc浏览器的创始人Josh Miller正式宣布战略性放弃Arc，转而全力开发全新的AI Agent浏览器Dia。几乎在同一时间，HideCloud和Peak刚从武汉飞回北京，落地后看到这条消息，感到非常震惊——因为就在两天前，他们在武汉刚刚决定终止AI浏览器的研发工作。中美两支团队，在同一时刻，毫无预兆地达成了共识。这并非偶然，而是整个行业对AI浏览器这一赛道，给出了相同的判断。

为何选择放弃AI浏览器？这个方向在去年看起来还十分合理——Arc曾获得2023年Product Hunt年度产品第二名，势头正盛。但经过实践，问题很快暴露：浏览器是为单用户设计的，一旦AI开始执行任务，用户就只能被动观看，相当于AI在与用户争夺浏览器的使用权限。这显然不是正确的方向。合理的思路应该是：AI需要用到浏览器，但并非在浏览器内部运行。AI should use the browser, not be confined within it. 那么在哪里使用？在云端。The browser should be in the cloud. 所以现在观察Manus，你会发现它的右侧，AI正在自主操控一个云端浏览器，一个在云上工作，一个在本地使用，各司其职，互不干扰。

更关键的是，在开发AI浏览器的过程中，团队发现了一个核心信号：Less structure, more intelligence。这句话对内凝聚了整个团队，支撑Manus团队挺过了过去三个月的攻坚期，最终把产品成功做出来。这也是Manus区别于其他产品的根本所在——尽量降低对模型的过度干预，只需做好底层铺垫，让AI自主发挥，反过来让AI教会我们做事。这非常反直觉。初期很多投资人看完演示后会问：“你们团队有多少人负责workflow？” Manus团队回答：“没有人，是模型自己完成的。” 结果投资人都难以置信。但这就是Manus的底层信仰，也是AI Agent Manus诞生的核心契机。

（这句话在Manus官网的底部）

在这个信仰之上，开发Manus需要赋予它三样东西。首先，Give it a computer——就像招聘一个员工需要配备电脑，否则无法开展工作，有了设备，权限也必须充分授予。其次，Give it data access——让它能够访问互联网、查阅知识库，通过大量私有API获取权威的结构化数据，这是后续任务处理的基础。第三，Give it some training——进行入职培训，有导师带领，对Manus来说，用户就是它的导师，需要时不时给予反馈。拥有这三样东西，Manus就可以开始执行任务，并且在持续使用与反馈中不断进化。

那么，为什么是Manus这个团队率先做出来了？天时、地利、人和。天时：模型的智能水平进化到了可以支撑Agent的阶段，技术成熟度与市场需求终于达到交汇点。地利：此前开发AI浏览器积累了大量的前置探索经验，公司架构扁平，决策能够快速贯彻，资源协调高效。人和：HideCloud和Peak两人配合默契，能力互补，实现了1+1大于2的效果。这种拥有共同目标、并肩冲刺的团队氛围，确实令人印象深刻。

当然，现在的Manus仍是preview版本，远谈不上完美。它有令人惊艳的高光表现——比如利用多模态能力看完视频后，基于画面分析给出正确答案；或者在查找转绘教程时，浏览网页后直接点击举报；深度搜索还能直接生成可交互的网页。但失败案例也同样存在——例如需要登录YouTube时，用户接管操作后被提示更换浏览器，Manus无法完成该操作，最终只能使用视频描述文字进行总结来变通实现；也有生成文字游戏无法达成预期目标，多次修复后陷入死循环的情况。在底模能力没有显著突破的前提下，Agent类产品能够达到的边界依然可以预见。Manus距离真正的通用Agent还有一定距离，但已经足够惊艳。

顺便说一个趣事。在北京一场极小型的交流会上，创始团队分享了产品发布前后的状态：当晚凌晨3点半才回到酒店，早上醒来手机已经被消息震到没电。当被问及发布后是否兴奋时，他们的回答是——比起兴奋，更多的是疲惫。确实，这段时间太辛苦了。

2025年，值得期待。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：Manus为何由他们团队成功研发要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题