首页科技快讯 Manus的狂热和争议之后：这是智能体的胜利吗？

Manus的狂热和争议之后：这是智能体的胜利吗？

来源：晰数塔互联网快讯时间：2025年03月12日 18:33

自从发布以来，Manus经过了一个堪比过山车的传播历程。

从一开始的惊艳，到被加速捧至高点，再到遭受套壳、营销的批评，一切都发生在短短一周内。

在各种各样的声音当中，我们找到了和Manus最为相关的一群人：正在参与agent以及配套设施的开发者们，聊了聊他们眼中的Manus——不讨论营销和争议，仅仅是技术层面。

结论并不复杂：Manus无疑是一款优秀的产品。以“套壳”为理由来否定Manus，是它的无妄之灾。

同时，“缝合”一词，也并不公允。一个通用型agent的能力和潜力，不仅体现在链接了多少工具，更在于对于agent本身的认知。

那些围绕营销和套壳展开的争议，指向的是一个问题：Manus的价值到底是什么？

横空出世的“全球首个”

快忘了上周盛况的朋友们，这里有一个快速回顾：3月5号深夜，Manus上线内测，在官方展示的视频中，放出了好几个原本只在PPT中才会出现的精彩使用案例，无一不展现出Manus独特的任务理解和执行能力。

老实说Agent（智能体）并不新鲜，但Manus打出“全球首个通用型智能体”的说法，掀起了前所未有的讨论浪潮，也让“通用型agent”走到台前。

由于内测使用需要申请邀请码，且发放速度慢，一时间造成了哄抢的局面——用例有多惊艳，用不上的人就有多焦虑。

这种邀请码的机制，阴差阳错地把Manus推到一个近乎诡异的热度，甚至被称为“又一个DeepSeek时刻”。

DeepSeek是模型，Manus是智能体，是截然不同的两种产品。然而某种程度上，二者的历程，确实有相似之处。

DeepSeek做的是模型，但它并非是从零开始，而是在一系列已有的开源工作上，实现了工程上的胜利。

类似地，Manus实际上并非第一个做通用型agent产品，在2023年同类产品就涌现过一轮。Manus本身也从大量开源工作中获得帮助，团队此前曾经打造过monica，一款集成式AI助手，积累了丰富的agent工程经验。因此，Manus也同样被视为一种工程上的胜利。

工程上的胜利究竟是指什么？

这个问题必须回到“通用型agent”是什么这个根本源头上。

人跟动物之间的区别在于制造和使用工具，这句话，放在agent身上也成立——普通agent和通用型agent的区别在于，后者能够主动调用工具。

“很多人觉得agent就是原来的对话机器人，接上数据库，就叫做agent。实际上，一直以来agent的定义都是需要能使用工具，能真正的有所行动。”William Lee解释道，他从去年开始和创业团队一起开发针对agent的中台系统ACI.DEV，就是在为agent类产品提供尽可能便捷的API调用服务。

在具体的产品使用上，工具调用能够把agent的能力边界，再推得远一些。活跃在agent开发社区的坚白，见识过Manus在执行上的能力：剪视频。

“剪的效果怎么样另说，但是它可以去做到，可以完成，不会拒绝你。”

原理并不复杂：剪辑的动作，可以在一定程度上以代码的方式来实现。又或者，一些在线工具可以被调用出来，完成剪辑的动作。

这样完成的剪辑当然是粗放的，成品跟人工剪辑无法相提并论，但就像坚白所说，Manus不会拒绝这个要求，而是会主动寻找工具完成。“在过去的应用里，agent可能会推荐给你一个剪视频的网站或者工具，但没有这样端到端的结果。”

他认为这反映了Manus团队的认知，是在一种更有高度的位置上。“我认为他们把代码，包括整个代码的运行环境，更多作为工具，而不是目标。”

曾经一些类似的项目，给出一段代码或者设置虚拟机，就已经是最终目的。而Manus的理解是，设计虚拟机跑代码，只是实现方式，它们是为了完成某种目的而存在。

“我觉得是他们在认知上有领先”，坚白说，“大家都在说要把agent当成人看，但他们真的是认真思考了agent如何作为一个主体。”

Agent最重要的是“大脑”

那么，虚拟机是那个让Manus脱颖而出的设计吗？

“虚拟机不是一个creative的设计，”同样是在做通用型agent产品的郑浅解释。

郑浅所在的公司Convergence.ai，在1月时推出了同样属于通用型agent的产品Proxy，并且在webvoyage基准测试中险胜OpenAI。

不久前Proxy登上Product Hunt榜单，郑浅忙着带领工程团队应对突然涌来的流量。他们面对的是海外市场，可见通用型agent，在海内外都是被寄予厚望的agent形态。

“OpenAI Operator就是虚拟机，Manus是给browser use之后，加了一个coding execution，然后放到一个虚拟机里面去实现。”

Browser use，是一个在Github上获得了4万星的开源项目，它相当于把网页浏览器放在了agent“眼”前，结合了大语言模型以及视觉识别。用户只需要通过自然语言，就能让智能体对网页上的元素进行实际操作。

早期Proxy也尝试过类似browser use的路线。“通过这种方式帮用户做点击、拖动等等的动作。整体是比较简单直接的，只需要用户给一个任务，它一步一步去执行。”

这个形态比较线性，无法胜任更复杂的任务。或者说，当任务的复杂程度上升，需要用户给出更有细节的指令，反而成了对用户的挑战。

“我们公司算开始得比较早，跟OpenAI和H Company他们也比较多交流，后来OpenAI Operator出来，agent一下就变火了。大家很快就往一个新的东西上面去靠拢，就是agent orchestrator。”郑浅非常明确，“可以说general agent真正的区别，不在于缝合了多少工具。”

建设一个普通的agent，可以用“缝合”简单粗暴地概括。但是要建设一个general agent，必须是一个系统工程。

“你可以把agent想象成一个人，最复杂的部分在于核心决策系统——就是大脑和神经传输。其次复杂的是执行构建，比如说相当于人类的四肢与末端。至于你刚才提到的生成报告、浏览器交互、代码执行等功能模块，本质上属于工具链层面的能力。”

人并不是生下来就会走路的，婴儿只会胡乱挥舞手脚，然后会爬、会站，磕磕绊绊地学会走路，最后学会精准地控制自己的四肢。

整个学习的过程，也是大脑逐渐成熟的过程。Proxy的绝大多数工作都在围绕这个“大脑”展开，具体而言，是planner agent所负责的动态规划。

“有一个调侃是，规划不能预测未来：规划可以做的很好，但你不知道未来会发生什么。放在agent上面也是一样的，比如说它浏览某个网站，碰到无法打开的情况，比如改版啊或者域名过期，或者直接关停等等，那这时候agent该怎么做，这就需要动态规划。”

Manus实测中，碰到网站登录及验证问题

一个典型场景是验证码，Proxy和Manus可以解决一些简单的验证码，但太复杂的还是需要交回给用户，也可能被直接跳过。

郑浅解释难度藏在细节里，“都是细节，而且情况非常多样。如何在规划上去实现复杂任务，同时又能回传——用户基数一大，做什么千奇百怪的事情都有，如何覆盖各种各样的场景是很大的难点。”

现阶段Manus并非尽善尽美，但它足以作为一个工程启示录。“它主要的成功之处，确实就是在工程上面”Wiilliam非常认同这一点，“它结合了市场上已有的模型，很好的跟工具做了对接，然后让用户第一次看到，真正可以调用工具的agent到底能做出什么样的效果。这样子我觉得百分之百是工程上的胜利。”

真正的胜利属于生态

Manus正像是那个正在学走路的幼儿，它能够造成巨大的讨论，并不在于它已经能走多远、跳多高，而在于展示出了足够的潜力。

这或许才是它最大的贡献：Manus的走红，让一系列与general agent类的应用，乃至基础建设的工作，都渐渐浮出水面。

最新的进展是OpenAI推出了Responses API，这是一个面向开发者，而且就是agent开发者的新发布。

在开发者社群里，Manus激发了更多想法。坚白正在做和agent记忆相关的项目，Manus的出现让他开始重新思考记忆储存相关的范式。

记忆储存对于agent的实际工作至关重要，这不仅影响着agent能否从过往任务里学习到经验并沿用，也影响着能否形成关于用户使用习惯的记忆，真正做到个性化。

另外，通用型agent在理论上有着最大的自由度，可以链接和调用任何工具——在延迟、接口标准化等方面足够好的前提下。这正是ACI这类中台型产品，所想要提供的服务。

这可能是Manus最成功的一点：它作为现阶段通用型agent最出圈的案例，为一系列配套设施打开了想象和探索的空间。

“其实通过Manus可以看到，现在模型已经跑在工程的前面很多了。”William认为工程方面还有很多可以探索的空间，“我们还可以在工程上面继续做点什么，来拉高这种AI agent产品的效能。我个人的看法是现在agent infrastructure这一端的话都还是挺不成熟的，包括像我们这种工具调用平台，或者是说这种memory layer，这些在工程方面都还有很多方向是可以优化的。”

这也是我们跟开发者社群接触下来最大的感受：他们感到兴奋与跃跃欲试。“通用”两个字所包含的可能性，前所未有的生动。

Proxy马上要基于新的parallel agent思路，推出迭代的版本。郑浅一直在观察社群的反馈，他看到许多用户把Proxy用出了自己根本没过的方式，不断被挖掘出新的可能。

“大多数产品最后的使用目的，都不太会是一开始开发的目的，可能后面是由用户来发现我们没有发现的用途，我们也在等待那一个moment的到来。”

本文来自微信公众号：APPSO （ID：appsolution），作者：appso