学霸把 Manus 扒个底朝天,手把手教你搭建 Lazy Manus!
时间穿越回 2025 年 1 月 31 日,那个红红火火的大年初三
小编在老家同学聚会的饭桌上与朋友们侃天侃地,由于 LLM 的浪潮自 2023 年起就没有平息过,便有一个老哥突然问到:“诶?小 C,你觉得今年 AI 的发展会是什么样子?”,小编推了推眼镜,沉稳说到:“前年文字生成,去年多模态,2025 年必定是属于智能体应用的一年~Let's see.”节后回到公司便被哐哐打脸,DeepSeek-R1 又一次卷起了千层浪,这浪更比 Sora 那浪凶。难道 2025 年要被推理大模型拿捏了吗?
时间又旋转跳跃到 2025 年 3 月 6 日,一个普通的工作日
“通用 AI 智能体应用” Manus 突然发布,宣称其与传统的 AI 助手不一样,它针对的是各种应用场景下的复杂任务,比如撰写报告、编写网页、复杂数据分析以及其他各式各样的与“生产力”挂钩的任务。

这一发布可不得了,其展示出的任务回放中,大模型自主执行网页搜索、代码编写,经过各种花里胡哨的操作后竟真能给用户交出“实实在在的东西”,这样一来,媒体们瞬间坐不住了——这是 DeepSeek 之后,又一个科技圈的不眠之夜。
这 Manus 到底是怎么一回事?一起来看!
1.什么是 Manus
Manus 是由 Monica.im 团队开发的全球首个自主通用 AI Agent。据 Manus 官方介绍:“Manus 是一款通用型 AI 助手,能将想法转化为行动:不止于思考,更注重成果。Manus 擅长处理工作与生活中的各类任务,在你安心休息的同时,一切都能妥善完成。”
为什么
Manus 一经发布便引起了这么多的关注?
我们不妨回顾一下先前的智能体应用都是怎样的
👇
在 Manus 发布之前,市面上存在多种多样的 AI 助手:代码助手、旅行规划助手、公文写作助手......然而这些智能助手有一些共性上的不足——他们都专注于各自的“一亩三分地”,只在各自的垂直领域发光发热。这就导致了我们存在不同的需求时,需要寻找不同领域的 AI Agent 应用,找到的还不一定能保证效果。
另外,先前的 Agent 智能助手较为擅长的是“收集数据-分析问题-输出结论或建议”,这种工作模式实际上是指导人更好的完成工作,最终还是要落实到“让人做某事”上,但实际上明明有些任务使用简单的 workflow 即可完成,而有时我们还要花费额外的时间将 AI 提供的信息二次处理,最终才能转化为我们想要的结果,工作效率反而高不起来,还有可能因为 AI 的能力有限被拖后腿。
😏
而 Manus 呢?作为一种“自主智能体”,它不仅会思考,还能直接执行任务并交付结果。“All-in-one”的属性瞬间让我感觉,其他的都可以不需要了,有任何需求使用 Manus 就好了嘛~
接下来让我们来看一下使用 Manus 都能够干些什么,并看看它是如何完成任务的。从官方提供的一些使用案例中我们可以发现,这个东西不得了——旅行规划、股票分析、页面编写、音频剪辑...大大小小的活它全包了。Manus 不仅可以高效检索、数据分析,还可以主动操作系统、编写代码、给出实际的交付物,且交付物质量还挺不错,很多情况下不需要人进行二次修改了!

Manus 官网中提供了海量用例展示




Manus 使用了网络搜索、网页操作、文件编写工具完成本次任务

最终给出交付物(html 网页)
看来这家伙确实有两下子,既可以进行缜密思考,规划任务流程,又可以通过调用多种工具,一步一步把任务完成,并最终提供文件给用户。
所以这么好用的东西,从哪里获得呢?当前 Manus 并没有正式开放使用,而是采用邀请制,用户可以凭邀请码注册体验。而这个邀请码并不是很好拿到,甚至一度炒到几万元一个... 最近 Manus 也是公布了初步的付费方案:ManusStarter 每月收费 39 美元,可获得 3900 积分,最多可以同时运行 2 个任务。ManusPro 每月收费 199 美元,可获得 19900 积分最多可以同时运行 5 个任务,同时支持使用高投入模式和其他测试功能。
好家伙,虽然看上去很牛很有吸引力,但是开个会员一个月动辄成百上千,邀请码被炒至成千上万...想使用超级 AI,我们穷哥们儿还不配了?不行,我要白嫖一切!今天就帮大家拆解 Manus 的技术架构,梳理技术要点,并尝试使用 LazyLLM 框架对 Manus 进行复现,帮助大家在本地部署一个属于自己的“Lazy Manus”。
2.Manus 技术架构拆解
通过观察 Manus 的运行机制我们可以发现,Manus 其实就是结合了 Plan-and-Solve 原理的多智能体应用框架:创建好工程目录后,Manus 首先会进行充分的规划(Plan),然后针对规划中的每一环节调用工具执行,直到当前环节完成后进入下一环节(Solve,Tool call Circle),循环往复直到 todo list 中的每一项完成目标。
我们再结合市面上较为成熟的智能体应用框架梳理一下,其本身可以分为三大模块:
规划模块(Planning Module)
规划模块充当了智能体应用中大脑的角色,主要用于识别用户意图、拆解复杂任务、规划执行方案等,以 DeepSeek-R1 为例,当前推理大模型的能力已经达到了不错的水平,优秀的推理和规划能力能够助力 Manus 轻松驾驭各式各样的复杂场景,任何复杂任务都能得到清晰靠谱的行动规划。
工具调用模块(Tool call Module)
一个优秀的智能体应用不仅需要聪明的大脑,还需要丰富的工具支撑,工具调用模块就像 Manus 的手,主要负责调用各种工具,完成具体的操作,这里的操作在整个任务流程中往往只体现了一小步,但正是每一次高效稳定的工具调用,促成了任务最终的高质量完成。在 Manus 中,比较典型的工具如下:
🔨网络搜索工具(Web Search)
🔨浏览器操作工具(Browser-use)
🔨代码执行工具(Code Executor)
🔨文件管理工具(File Manager)
🔨命令行执行工具(Terminal)
记忆模块(Memory Module)
经典智能体框架中,Agent 存在着两种记忆——短时记忆与长期记忆,其中短时记忆即大模型的 history,赋予 Agent 单次任务中感知中间结果和临时数据,方便一步步完成任务,而长期记忆负责记录与用户相关的偏好数据和历史对话,方便应用在后续的工具当中更好的便是用户意图,有针对性的优化用户体验。对于一个智能体应用来说,记忆模块是必不可少的。
根据以上梳理,小编帮大家整理了一份 Manus 工作流程图:

Manus 工作流程图
观察这个流程图,小编发现 Manus 的结构并不复杂,但看着这琳琅满目的示例,内心不由得思考:严谨的规划、丝滑的工具调用、多种多样的内容呈现,这绝对不是仅仅靠着上面那坨流程图就能实现的,其背后一定还存在着大量的工程与模型优化。还没缓过神,Manus 的主理人已经在 Twitter 上给到了答案:



从其介绍中我们可以知道,Manus 是一个多智能体框架系统,且内部进行了大量的模型微调、提示词优化以适配多种多样的工具、场景。并且 Manus 没有使用 MCP(后面介绍)。正如 Manus 的主理人所说,简洁高效的框架仅仅是优秀应用的一部分,Manus 让人感到其无所不能的原因还在于团队使用了大量的模型微调和工具调用优化来提升系统整体的性能。也就是说,Manus 是一个集虚拟机机制、Prompt 调优、模型微调、多样工具集于一身的究极结合体。
3.开源版的 Manus
就在我沉浸在观察 Manus,梳理其技术流程时,Manus 的开源版本——Open Manus 与 OWL 强势来袭。
Open Manus(https://github.com/mannaandpoem/OpenManus)由国内专注于多智能体系统的技术公司 DeepWisdom 旗下的 MetaGPT 团队研发,团队号称“只用了 3 个小时,把团队先前的浏览器操作插件集成进来就差不多完成了”。雄厚的技术沉淀以及强大的执行力让小编佩服。观察其开源出的代码,我们可以发现:
📌Open Manus 本身是一个拥有丰富工具链的 ReactAgent
📌其工作过程中每个 Step 始终遵循了“Think-Act”步骤,即思考-工具调用,直到任务完成或达到最大迭代次数:
-Think(思考):观测当前任务状态,决定是否要调用工具、调用什么工具,可供使用的工具由搜索、浏览器、代码执行、命令行、文件管理。
-Act(演绎):调用工具集中对应的工具,完成单个 step 的任务。

Open Manus 工作流程示意图
OWL(https://github.com/camel-ai/owl)是由 Camel-AI 基于自家大模型应用开发框架研发的多智能体应用,与 Open Manus 不同,从其官方的系统架构图上来看,系统结构则是与 Manus 相似的多 Agent 结构,其中的智能体被分为通用 Agent 和工具类 Agent 两大类,通用 Agent 负责同用户交互、调度各工具类 Agent 执行不同的工作,工具类 agent 则是结合自身特定的能力,使用各种工具完成给定任务。这种多智能体协作完成任务的架构层次清晰,很大程度上增强了系统的可扩展性。

OWL 官方系统架构示意图
虽说各家都推出了自己的开源 Manus,从小编的实际使用体验下来,效果只能说“还可以”:
在执行一些简单的任务时,比如搜索信息、总结报告场景,效果都还不错,都可以正常执行搜索、网页浏览等工具。但到了一些需要十几步才能完成的复杂任务场景中,系统在很多时候会出现“运行完没有给出交付物、给出的代码没办法正常运行”的尴尬现象,有时直接进入死循环出不来了(大概是因为搜索得到的有些网页在浏览过程中无法正常提取信息造成的)。
即使效果没有 Manus 那么好,但这么多 Manus 的开源版本相继发布,这一现象非常振奋人心(瞬间又增加了小编白嫖的决心)——眼看着小编已经有些落后大部队了,赶紧搞一下(LazyLLM,启动!)。由于 Manus 这类应用除了强大的 LLM 支撑外,还需要各种好用的工具支持,这就需要开发者在“工具开发”环节下很大的功夫。我们实现相关功能具体需要哪些工具呢?
🔨网络搜索功能:网络搜索工具、网页浏览工具
🔨代码执行功能:Python 代码执行工具
🔨文件管理功能:文件系统管理工具:文件和目录的增删改查
小编看着这份工具清单,不禁打了个寒战——考虑到开发、适配、调试的成本,即使有这么多开源项目可以参考,这开发量还是有点多,不符合一个 Lazy Boy 的风格。就在这时,小编想起了最近一个因为 Manus 而引发热议的工具——MCP。
4.Agent 时代的究极武器——MCP

MCP(Model Context Protocol,模型上下文协议)是一种开放标准协议,其由 Anthropic 公司于 2024 年 11 月推出,旨在让大语言模型能够“无缝连接”外部工具和数据源。MCP 类似于我们电脑的扩展坞,充当一个“双向翻译官”的角色,让 LLM 能够安全、可控的调用各种工具来访问你的文件、应用以及其他网络服务,并执行对应的任务。以下是官方给出的 MCP Client-Server 架构示意图:

可以看到,MCP 主要由三大核心组件构成:Host、Server、Client:
-Host 即与用户交互的主机(类似 Cursor、Claude Desktop、我们所创建的应用等等)。
-Server 即服务提供商,提供特定的功能、工具、资源等。
-Client 即主机与服务器中间的桥梁,确保中间通信,每个 Client 与 Server 保持着 1:1 的连接。
对于一个接入 MCP 的 Agent 应用来说,其工具调用从简单的调用函数,变成了以下流程:
1️⃣首先 AI Agent 通过 MCP Client 获取对应 MCP Server 提供的工具列表,其中每一个工具都包含了详细的功能和请求参数描述。
2️⃣随后的工作当中 AI Agent 便可根据上下文和模型的推理,判断出是否需要调用某个工具。
3️⃣当 AI Agent 判断需要进行工具调用时,系统会发出调用特定工具的请求给到对应 MCP Client,随后被其转发至对应 MCP Server。
4️⃣MCP Server 收到并处理请求后,将对应的结果发送给 MCP Client,随后响应被发送回 AI Agent。
MCP 的出现反而使 Tool call 本身流程变复杂了
那这件事的意义是什么呢?
👇
随着模型能力的进一步提升,模型能力目前出现了一些边际效应,你会发现继续卷模型的玩家越来越少,AI 发展逐渐从卷模型转移到卷应用方向。
而研究过许许多多 agent 产品之后,我们发现每次我们重新研究某一个 agent 应用/框架的时候,其往往是一个全新的服务,内部使用的 tools 往往都是自研的,换个地方就没法用了,因此 MCP 出现之前,所有人都在重复造轮子——执行机制不统一、接口标准不统一、数据处理方式不统一... 这种现象就好像在说:你用我就完事儿了,别用其他的了。然而,当前应用和框架并没有到某一个超级巨头占领市场的阶段,因此我们并没有选择一个树吊死的理由。
MCP 的出现就是为了解决这一窘境——通过这一协议维护一个工具社区生态,让想要使用这些优秀工具的应用只需要关注协议本身就好了。通过建立通用标准,服务商可以基于协议来推出它们自己服务的 AI 能力,从而支持开发者更快的构建更强大的 AI 应用。开发者也不需要重复造轮子,通过开源项目可以建立强大的 AI Agent 生态。
许多人可能会把 MCP 误解为一个工具,就和其他可调用工具一样,其实不然,Tool call、AI Agent、MCP 这三者之间有着本质的区别:
-Tool call 指的是 LLM 根据上下文自动执行函数的机制,其充当了 AI 模型与外部系统之间的桥梁,不同的模型有不同的工具调用实现,代码集成的方式也不一样。
-MCP 是一个标准协议,可以在不同的应用/服务之间保持上下文,从而增强整体自主执行任务的能力。如同电子设备的 Type C 协议(可以充电也可以传输数据),只要有这个协议在,所有人都可以基于这个协议进行自己的开发,并将成果提供给他人使用, AI 模型便能够与不同的 API 和数据源无缝交互。MCP 旨在替换碎片化的 Agent 工具代码集成,从而使 AI 系统更可靠,更有效。
-AI Agent 是一个智能系统,它可以自主运行以实现特定目标。传统的 AI 聊天仅提供建议或者需要手动执行任务,AI Agent 则可以分析具体情况,做出决策,并自行采取行动。AI Agent 可以利用 MCP 提供的功能描述来理解更多的上下文,并在各种平台/服务自动执行任务。
聪明的你可能会问
说了这么多 MCP 的好处
我能在 LazyLLM 中使用它吗?
问的好 问的妙
❗❗❗
小编观察到,就在前几天,LazyLLM 官方仓库中已经合入了兼容 MCP 的 PR(https://github.com/LazyAGI/LazyLLM/pull/469),根据官方提供的示例,一行代码便可将 MCP Server 接入 LazyLLM 应用中,使用起来也是非常的方便。
那岂不是只要找一些非常牛的工具,结合多智能体框架就可以实现 Manus 自由了?简直是天助我也,下面就让我们一同开启使用 LazyLLM 复现 Manus 的丝滑奇幻冒险!
5.Lazy Manus
接下来,小编将给大家详细介绍如何使用 LazyLLM 复现一个 Manus 类型的应用。复现主要分为四部分:环境准备、MCP 工具集成、多智能体框架实现、应用组装。
环境准备
本次复现中,Python 版本使用 3.11(MCP 支持的最低版本),LazyLLM 使用 github 仓库中的最新版本(具体的安装方式和环境配置可以参考官网文档https://docs.lazyllm.ai/zh-cn/latest/ ,采用手动配置的方式,从 github 拉取代码并进行安装)。
配置大模型这里我们采用线上的 DeepSeek-V3 大模型,其强大的性能能够确保 Lazy Manus 有一个出色稳定的“大脑”,DeepSeek 模型的 API Key 可以在其官方接口平台获取(https://platform.deepseek.com)。获取 API KEY 并充值成功后,在系统中配置对应的环境变量:
随后测试模型配置是否成功:
由于要使用 MCP 提供的工具能力,我们需要在环境中安装 Node.js(具体的安装流程见https://nodejs.org/en/download)。安装后我们通过 node 和 npm 命令行来验证安装是否成功:
到这里,相关的开发和运行环境就准备好了。
MCP 工具集成
我们可以找到了一些比较好用的 MCP 工具网站:https://mcp.so/,https://github.com/punkpeye/awesome-mcp-servers ,依托于 MCP 优秀的社区生态,在这些网站中我们可以轻松发现很多好用的 MCP Server。基于本次复现的需求和实验,我们最终选择了以下 MCP Servers 作为目标工具集:

列表中的每个 MCP Server 都内置了丰富的工具可供大模型进行调用,这里以 filesystem MCP Server 为例,介绍一下如何使用 LazyLLM 接入 MCP,并把工具提供给 Agent。
首先,MCP Server 的启动方式有两种:本地启动和 SSE 远程连接,本地启动时需要掌握每个 server 的启动命令,而远程连接需要获取对应的 url 以获取连接。我们可以在对应的链接中找到对于的启动命令,比如 filesystem 的启动命令如下所示,其实就是命令行。
需要注意的是,如果你是 Windows 环境,对于使用 npx 启动的 server,需要对以上命令做一些修改:command 改为“cmd”,args 则在最开始加入“/c”,“npx”,即以下形式:
有了以上配置信息,只需几行代码,便可将 MCP 接入到 LazyLLM 中,创建一个能够使用 MCP 的智能体。
以下代码中,我们只用了一行代码便完成了 MCP Server 的接入,随后又用了一行代码便创建出一个 LazyLLM 中的 ReactAgent:
对于一些功能较为简单,不那么消耗系统资源的 MCP Server,我们可以使用以上方式接入到系统。如果遇到一些功能复杂、计算量较大的 MCP Server,比如浏览器工具集,LazyLLM 支持将其一键部署至单独的机器当中,并通过 ip+port 的方式给出地址以供我们在应用中使用 sse 的方式接入工具。具体使用方式如下:
启动命令
Linux:
Windows:

MCP Server 独立部署成功
运行以上命令行,配置好具体的启动命令、接口信息等,使用“lazyllm deploy”命令便可以实现 MCP Server 的一键部署!随后我们以 sse 的方式接入 Agent 应用:
另外,由于 MCP 仍处于起步阶段,不是所有的功能都可以找到一个很好用的开源 MCP Server 与之匹配,除了使用 MCP Server 外,我们还复用了此前复现 Lazy DeepResearch 时的一些已有工具:系统反问工具(get_more_info_from_user)、基于博查 AI 搜索 API(https://open.bochaai.com/)开发的网络搜索工具(web_search)以及执行 Python 代码的工具(python_executor)。如果你感兴趣,可以从“阅读原文”获取相关代码。
至此,我们整个系统中需要用到的工具便集成完毕了。MCP 的出现直接改变了我们的开发方式,相比之前写代码、不断调试自研各种工具,现在我们能够像刷某宝一样,在海量的开源 MCP Server 中挑选我们所需的强力工具,并且很多工具出自各种官方之手,比我们自己开发适配方便多了~

像刷某宝一样畅游 MCP Server“市场”
应用框架
准备好工具集后,我们基于调研中的已知内容,设计了 Lazy Manus 的多智能体应用框架,本次复现省略了记忆模块,感兴趣的小伙伴可以自行设计。

Lazy Manus 框架展示
流程描述
📌系统接收到用户的任务描述后,首先使用规划模块,该模块会将任务拆解为多个步骤,确保顺序执行这些步骤可以完成任务,并给出规定格式的 Todo List,并将其传给任务管理智能体(Solver)。
📌任务管理智能体是一个 ReactAgent,其主要有两大功能:寻求用户建议和分发任务给具体的工具智能体。任务管理智能体在执行每一步时,都会动态更新 Todo List 中任务的状态,并根据 Todo List 的状态决策下一步需要执行的任务,决策是否给特定的工具智能体发送任务,亦或是描述当前的任务状态给用户并寻求意见。
📌工具智能体同样是 ReactAgent,其接收到任务描述后,便会根据任务自动调用必要的工具,并在当前任务完成将任务的完成情况、关键信息反馈给任务管理智能体。
📌任务管理智能体接收到工具智能体的任务完成信息后,会结合信息动态的更新 Todo List,并进入下一次循环,直到任务完成。
📌任务完成后,用户便可以获得具体的任务交付物。
考考你
这样设计的多智能体框架有啥优势
❓❓❓
主要优势
📌“用户输入--任务规划--分布完成--任务交付”的流程清晰,逻辑缜密。
📌任务管理智能体掌控全局,各工具智能体只关注当前任务,有效减少了大模型上下文的数据量,提高系统稳定性。
📌多智能体框架下,每个智能体仅被分配了少量的工具,负责特定领域的部分任务,有效避免了因工具过多造成的工具错用现象,提高系统的可靠性。
📌仅需要做少量修改,便可将包含新功能的工具智能体接入至系统当中,系统可扩展性较高。
以下是上述框架对应的代码设计,在这里我们定义了 Manus 类,并在其中传入了相关的模型、提示词以及工具,并依托于 LazyLLM 灵活的 Flow 模块,实现了 Plan-and-Slove Agent 的核心流程。
其中 CustomReactAgent 是为了自定义提示词,基于 LazyLLM ReactAgent 继承实现的子类,任务分配则是封装成了工具函数(set_task_to_worker),其中规定了可选工具智能体的类型,能够通过输入类型动态构建工具智能体,并完成本次任务。(完整的工程代码将在附录中给出,在这里我们仅展示核心模块):
应用组装
实现以上工具集接入和核心组件 Manus 后,我们简单实现一下入口,即可运行我们的 Lazy Manus 啦:
另外,也可以使用 LazyLLM 提供的 WebModule,在基于 gradio 的图形界面上测试我们的 Lazy Manus。你只需要执行以下代码:
效果测试
我们尝试运行 Lazy Manus,并执行以下两个测试任务,实际测试效果如下:
测试任务 1
输入指令“清明假期就要到了,我打算从北京出发去阿那亚玩,请你帮我做一个三天两晚的旅行规划,并做一个 html 页面展示行程。”
Lazy Manus 通过任务规划、网页搜索与浏览成功搜集到信息,并生成了旅行计划页面。
(视频见原文)
测试任务 2
输入指令“写一个打砖块游戏,要求体现出模拟碰撞的效果,且我能够使用方向键控制挡板的移动。游戏需要有前端界面供用户试玩。”
经过游戏设计、代码编写、功能调试等步骤后,Lazy Manus 成功编写打砖块游戏,游戏能够正常运行。
(视频见原文)
从以上两个视频中我们可以观察到,Lazy Manus 能够根据用户的输入进行任务规划,并在一次次的工具调用中自己完成搜索、网页浏览、信息汇总、调试程序,并把中间文件和最终生成的内容保存至本地目录。
🚨调试智能体应用的过程中非常消耗 token,盯紧你的账户余额!!!
6.总结与展望
以上便是小编使用 LazyLLM 复现 Manus 的全过程,我们从学习 Manus 的技术框架展开,并通过使用 MCP 大幅提高了 AI Agent 的开发效率,最终一个会思考、能交付的 Lazy Manus 就这么水灵灵的被小编实现了~我也太厉害了吧哈哈哈!
当然,小编的 Lazy Manus 与 Manus 本尊相比还有着不小的差距,具体表现在:
🎯系统稳定性
虽然还没真正使用过 Manus,但相信其是一个经过精心打磨过后的产品。得益于 LazyLLM 强大的灵活性和可扩展性,小编的快速复现很高效,但实际运行时的工具调用以及模型回复有时存在一定的稳定性问题,且由于未经过微调,即使是极为强大的 DeepSeek 模型,在这种较为复杂的任务执行场景中也有些吃力,由此看来,后续的维护工作必不可少~
🎯工具的多样性
本次复现只是对于一些常用场景的针对性复现,更高级的功能比如沙盒环境、命令行环境交互等因为环境安全问题并没有实现,依托于 MCP 活跃的社区氛围,相信不久的将来会出现越来越多好用的工具,后续小编也会持续跟进,让 Lazy Manus 更加强大!
🎯视觉呈现
当前的 Lazy Manus 从视觉呈现上略显粗糙,而 Manus 的回放功能让更多的人以简单的方式了解到其强大之处,这体现了一个优秀的界面设计和回放功能的重要性。
还是开头那句话,2025 年必然是 AI Agent 类应用持续爆发的一年,未来也会有越来越多有趣的应用出现在我们的面前。小编也会持续使用 LazyLLM 复现更多有趣的应用,给大家带来更多干货满满的内容!
版权声明: 本文为 InfoQ 作者【商汤万象开发者】的原创文章。
原文链接:【http://xie.infoq.cn/article/0bc884bba073d77ea195f26d0】。文章转载请联系作者。
评论