OpenManus开源：能否超越Manus？ Manus现象背后：从爆火到被质疑，OpenManus的机遇

被称为“全球首个通用AI智能体”的Manus在国内媒体爆火，但试用需要邀请码且没有大规模公开测试和专家实名背书，其实力存疑。从产品体验看，其功能虽惊艳但创新性不足。随后MetaGPT团队花费3小时开发并开源了OpenManus，目前功能虽初级但有后续开发路线。文章还探讨了OpenManus开发中的技术挑战、期望等，最后对什么是好的Agent进行了思考，指出当前Agent存在的问题，强调应关注模型底层能力提升和开源社区新技术。

就在前两天，Manus在国内媒体界突然大火起来，它还号称自己是“全球首个通用AI智能体”呢。官方也很是大方，一下子就晒出了几十个Demo，供大家去体验和把玩。

网友们看到它的效果后，都特别心动，想要去试用一下，结果却发现需要邀请码才行。我们四处询问了一些AI专家，他们都说自己没用过，而且也没听说自己同行有用过的，“目前大概就只有媒体在用吧？”到了这个时候，我们就得小心谨慎了。那些没有经过大规模公开测试，也没有专家实名自发为其背书的技术或者产品（像ChatGPT、NotebookLM、DeepSeek等都是有公开测试和专家背书的），其真实实力是很值得怀疑的。从产品体验的角度来讲，Manus虽然展示出来的效果让人眼前一亮，可是很多人并不买账。因为像写PPT、写HTML、Python数据分析、生成Excel、搜索等功能，现在各个通用模型基本上都能做。即便Manus宣称自己比OpenAI的DeepResearch更厉害，可这就和Cursor说自己比Claude更厉害有什么本质区别呢？两者的比较其实是相对错位的。在功能方面，Manus是整合了Computer use、虚拟机、Multi - agent协同的套壳产品。从技术实现的角度看，它是基于Claude模型的生成能力，再加上开源模型经过后训练增强的规划能力，然后结合各种预制的Agent，按照设定好的工作流，也就是构建todo清单、新建虚拟机环境、调用工具、结果整合、自我检查、输出结果这样的流程来解决任务的。所以呢，Manus在技术上确实有它的复杂性，但并没有太多的创新之处。当然了，它功能的多样性也导致工程量非常大，业内专家认为很有可能是基于MCP协议的聚合模式。过去，Agent更多的是在专业领域深入发展，而Manus却想通过在工程上进行极致的整合，打造出酷炫且低门槛的UI交互套壳产品，让Agent直接走向大众。总有人说，套壳做到极致就是胜利，就是有价值的。确实，至少从Manus的演示视频来看，好像是这么回事。既然它有价值，那么很快就会有人跟上它的步伐。你看，MetaGPT团队为了实现Manus的价值，仅仅花费了3个小时就开发出了OpenManus，而且是开源的，不需要邀请码就能使用。

项目地址：https://github.com/mannaandpoem/OpenManus在这个项目的演示视频里，输入提示词：“对Karpathy的网站（https://karpathy.ai/）进行全面的SEO审核，并提供详细的优化报告，包括可操作的改进建议。”接下来，OpenManus就会开始思考，把执行步骤拆分出来：

• 检查网站，收集基本信息；
• 分析关键SEO要素；
• 检查SEO技术方面的问题；
• 整理优化建议；

然后就一步一步地去执行任务了。可以看到，演示视频展示出来的结果远远没有Manus那么细致和丰富，OpenManus目前的功能还处于非常初级的阶段，不过团队也公开了后续的开发路线，按照这个路线走的话，基本上全面复刻Manus是没有问题的：

• 更优的规划系统
• 实时演示功能
• 运行回放
• 强化学习微调模型
• 全面的性能基准测试

那OpenManus是怎么来的呢？两个月前，在一次吃饭的时候进行头脑风暴，大家想到一个极简的Agent框架，应该是可插拔的Tools和System Prompt的组合。之后就沿着这个思路，写了一个完整的Agent迷你框架。前天晚上看到Manus的时候，凌晨就和同事商量，觉得下班后的晚上来搞一个，3个小时应该就够了。为什么要采用可插拔的Tools和System Prompt呢？因为决定一个ReAct Agent（一种结合了反应和行动规划能力的智能体）的效果的关键是Prompt（提示信息）和Action（行动），Prompt控制了Agent整体的行为逻辑，Tools给定了Agent的行动空间，二者被定义就能完整诠释一个ReAct Agent。可插拔的优点就是可组合，能够把几个不同场景下的Tools组合到一起来创造一个新的Agent，定义起来也很方便，不需要单独去写内部逻辑，只需要修改动作空间（Tools）就可以了。Tools本身就应该是可组合的，现在的工作就是把抽象做得更干净，目前HuggingFace的Smolagents也是类似的思路。Manus的效果让人感觉很新奇，实际上主要是因为Browser Use和Computer Use的使用，所以只要给Agent这两个工具，它就能做到这些。在OpenManus的实现中，有哪些关键技术挑战呢？在OpenManus的实现过程中，前端界面的实现是非常关键的。Manus出彩的地方在于产品展示非常漂亮，本来打算用Streamlit写前端，这样方便做类似的展示，可是Streamlit的底层和Browser Use冲突，后来就换成了Gradio，但是信息展示又有一些问题，当时没办法做到实时更新，最后还是改成了log，直接在命令行里做展示。如何有效地复现和优化PlanningTool的使用也是非常重要的一个环节，只有这样才能充分发挥Agent的规划和工具调用能力，探索其能力上限。Manus的用例展示了Agent在线性任务规划中的强大表现，而OpenManus需要解决如何设计更复杂的规划结构（比如使用DAG有向无环图表示任务依赖关系），以及如何让Agent动态更新规划以适应变化的需求，这不仅考验技术实现，还涉及算法设计和智能体的自适应能力。目前OpenManus的规划设计和Manus保持一致，都是线性的，而DAG规划对于处理现实世界中更复杂的任务，在一定程度上会更准确，Data Interpreter就是一个很好的例子。听起来OpenManus的规划已经有要超越Manus的苗头了，那对这个产品有什么期望吗？OpenManus前期的目标是打算达到原始Manus相同的效果，后续会不断优化Computer Use、Browser Use和Planning Use，以及工具调用的能力，从而超越Manus。Manus的产品交互做得挺好的，有很多技术也值得学习，比如对后训练技术的结合，流程设计上比如规划、Multi - Agent系统也是很优秀的，具体的细节还在研究当中。至于OpenManus，目前还没有单独去调整效果，现在达到的效果其实很一般。后续主要依靠开源社区的小伙伴来贡献，希望开源协作能带来更高的智能涌现。好了，知危编辑部与MetaGPT团队的沟通就到这里了，我们也可以期待一下OpenManus未来的效果。最后，或许我们可以探讨一下到底什么才应该是好的Agent呢？Manus有优点，也有亮点，但是有夸大的嫌疑。人们在试用的时候，还是能发现Manus有不少毛病，比如用错假数据、来源引用错误、表格读取错误等等，幻觉问题还是比较严重的。Agent应用的一个普遍问题是，自动化执行过程越复杂，发现错误和查找原因就越困难，而且Agent的执行需要经过多个LLM，每个LLM的幻觉一路累积下来的误差将会是非常巨大的，比如95%的准确率，连续经过10个LLM，最后准确率能直接降到约60%。在全面拥抱Agent之前，我们首先还是要多关注一下目前市面上的通用大模型，它们的幻觉率仍然是比较高的。所以，想要实现真正好用的Agent，我们仍然要攻克大模型底层能力的提升。里子不够好，套再多的壳也没有用。与此同时，我们还需要强调一点，在追求Agent的过程中，我们一定要回归实用主义：不是所有的问题都需要用Agent来做。Devin前不久还被爆出出错率极高并且出错方式没有规律可循，还不如用Cursor一步一步来，加上之前的演示造假事件，过于激进的Agent产品越来越受到质疑。与此同时，Agent的一个大问题是，步骤拆解越多，token消耗量越大，对所有任务一律无脑使用Agent，对于企业的成本控制来说是有极大风险的。Agent最关键的作用就是工作流编排，简单的任务其实并不需要Agent的参与，反而会导致客户等待时间过长。Anthropic就曾经分享过构建智能体的基本原则，那就是“简单为王，实用至上”，能用API就不要用工作流，能用工作流就不要用智能体。这些都是手段，哪个不能交付结果呢？Agent终究是一个产品概念，不像LLM有无法预测的潜在价值（比如推理能力的发现和增强）值得冒极大风险押注。所以回过头来看，我们应该更多关注开源社区的新技术，比如阿里在Manus发布同一天刚开源的QWQ - 32B模型，就像前文讲的那样，在追求Agent的路上，我们更应该关注模型的突破。

文章围绕Manus这一被称为“全球首个通用AI智能体”展开，阐述其爆火背后存在的实力存疑问题，如缺乏大规模公开测试和专家背书等。接着介绍了OpenManus的开发情况，包括其开发背景、目前功能状态、后续开发路线等，还探讨了开发中的技术挑战和期望。最后对好的Agent进行了深入思考，指出当前Agent存在的诸多问题，如误差累积、高幻觉率等，强调在追求Agent的过程中应关注模型底层能力提升和开源社区新技术，回归实用主义。