对话OpenManus团队：他们是如何3小时复刻Manus的？

就在昨天，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的演示视频来看，是这样。

既然有价值，那么很快就会有人跟上，这不，为了实现Manus的价值，MetaGPT团队花费了3小时开发了OpenManus并开源，无需邀请码就能使用。

项目地址：https://github.com/mannaandpoem/OpenManus

在项目的演示视频中，输入提示词：“对Karpathy的网站（https://karpathy.ai/）进行全面的SEO审核，并提供详细的优化报告，包括可操作的改进建议。”

接下来，OpenManus会展开思考，拆分执行步骤：

•检查网站，收集基本信息；

•分析关键SEO要素；

•检查SEO技术方面的问题；

•整理优化建议；

接下来就是一步一步地执行任务了。

可以看到，演示视频展示的结果远不如Manus那么细致和丰富，OpenManus目前功能还很初级，但团队还公开了后续的开发路线，照这个路线，基本上全面复刻Manus不是问题：

•更优的规划系统

•实时演示功能

•运行回放

•强化学习微调模型

•全面的性能基准测试

知危：OpenManus是怎么来的？

MetaGPT：两个月前的一次边吃饭边头脑风暴的过程中，我们想到，一个极简的Agent框架，应该是可插拔的Tools和System Prompt的组合，之后我们沿着这个思路，写了一个完整的Agent迷你框架。

前天晚上看到Manus时，凌晨就和同事商量，下班后的晚上就可以搞一个，应该3小时够了。

知危：为什么要采用可插拔的Tools和System Prompt？

MetaGPT：决定一个ReAct Agent（Reasoning and Action Agent，一种结合了反应和行动规划能力的智能体）的效果的关键是Prompt（提示信息）和Action（行动），Prompt控制了Agent整体的行为逻辑，Tools给定了Agent的行动空间，二者被定义就能完整诠释一个ReAct Agent。

可插拔的优点是可组合，我可以把几个不同场景下的Tools组合到一起来创造一个新的Agent，定义也很方便，不需要单独写内部逻辑，只需要修改动作空间（Tools）。Tools本身就该是可组合的，我们的工作是把抽象做得更干净，目前HuggingFace的Smolagents也是类似的思路了。

Manus效果上让大家觉得很新奇，实际上主要是由于Browser Use和Computer Use的使用，所以只要给了Agent这两个工具，那它就都能做到。

知危：​OpenManus 在实现中，有哪些关键技术挑战？

MetaGPT：在OpenManus的实现中，前端界面的实现很关键。Manus很出彩的地方是产品展示很漂亮，我当时打算用Streamlit写前端，方便做类似的展示，但Streamlit的底层和Browser Use冲突，后来就换了Gradio，但信息展示有一些问题，当时没办法做到实时更新，最后还是改成了log，直接在命令行里做展示。

如何有效复现和优化PlanningTool的使用也是非常重要的一环，这样才能充分发挥Agent的规划和工具调用能力，探索其能力上限。Manus的用例展示了Agent在线性任务规划中的强大表现，而OpenManus需要解决如何设计更复杂的规划结构（如使用DAG有向无环图表示任务依赖关系），以及如何让Agent动态更新规划以适应变化的需求，这不仅考验技术实现，还涉及算法设计和智能体的自适应能力。

目前OpenManus的规划设计与Manus保持一致，都是线性的，而DAG规划对于处理现实世界中更复杂的任务，在一定程度上会更准确，Data Interpreter就是一个很好的例子。

知危：听起来OpenManus的规划已经有要超越Manus的苗头了，你们对这个产品有什么期望吗？

MetaGPT：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的路上，我们更应该关注模型的突破。

以上就是关于【对话OpenManus团队：他们是如何3小时复刻Manus的？】的相关消息了，希望对大家有所帮助！