企业官网建设流程全解析

简介：面向希望借助RPA实现办公自动化的职场人群，这份docx文档详细梳理了UiPath的下载与安装全流程。文档先引导用户进入UiPath官网，根据个人或企业需求选择社区版或企业版，随后逐项说明个人信息填写环节的关键注意事项——尤其是社区版必须使用个人邮箱注册这一易错点。接着，文档清晰展示了如何查收官方下载邮件、安装软件，以及进入界面后如何在StudioX、Studio、Studio Pro之间选择或切换常用版本。资源为单份docx文件，大小约235KB，内容紧凑、步骤明确，适合零基础者按图索骥。已有464人学习/下载，可作为RPA入门或团队内部安装培训的参考。通过这份指南，读者不仅能顺利完成UiPath部署，还能理解不同版本之间的适用边界，少走弯路，为后续流程自动化开发打下扎实基础。

1. 先搞清楚这份 docx 到底在讲什么

第一次在交付群里看到 UiPath下载.docx 这个文件名时，我以为对方发错了对象——装 RPA 平台，给个 Word 文档做什么。打开才发现，这份文档不是说明文，而是一张离线部署地图：哪台机器负责哪个角色，安装包从哪台联网机器上取，依赖组件有哪些，校验值是多少。真正到了客户现场才反应过来，“下载”这步恰恰是最大的门槛：执行机在隔离网络里，没有外网访问权限，这时候手里那份 docx 就成了唯一的技术底稿。你得照着它把 UiPath Studio、Robot、Orchestrator 从零搭起来，还不能指望在线安装随时能拉包救场。

这篇文章想把这件事讲透：拿到这类清单式文档后，怎么选版本、怎么备包、怎么安静地装完一套可用的 UiPath 环境。读者大概是两类人：一类是要在项目现场做交付的 RPA 实施工程师，另一类是被临时拉来配环境的运维。你会看到可复制的命令、参数和排障顺序，也会看到文档里通常不会写的那几个坑。

2. 装之前先做好三件事：版本选型、环境盘点与离线包准备

2.1 选型先别拍脑袋：社区版、企业版与 Orchestrator 的适配范围

打开 docx 先别急着看安装命令，先确认它在讲哪个形态的 UiPath。只有一台开发机、跑几个自己用的自动化流程，社区版就够；要给一个部门做流程交付，流程要被人调度、日志要被审计，Orchestrator 几乎躲不开。离线环境里的区别很直接：社区版主要在激活环节依赖账号体系，企业版则通过许可文件或本地许可服务器完成授权，不要求每台机器都有外网。安装包方面，常见做法是准备可控的离线 msi 包，而不是到现场跑在线引导程序。

我一般会在 docx 里提取三张表：机器清单、包清单、License 清单。机器清单回答谁装什么；包清单回答每个角色的安装包在哪；License 清单回答装完用什么去激活。先把这三个问题对上了，再谈装法。若一开始就只盯安装命令，往往会在激活环节卡半天。选型时也别按“别人装了什么”来决定，先回答三个问题：数据必须留在本地吗？流程要不要被统一调度？同时跑多少个机器人？后两个答案只要有一个是“是”，这一版环境基本就要带 Orchestrator。

2.2 环境盘点：先把机器配置、数据库和系统功能列成核对表

离线安装最大的敌人不是安装包本身，而是环境准备不全。一台执行机配置不够，装完能开，但流程一跑就内存不足；一台应用服务器缺少 Windows 功能，Orchestrator 安装器走到一半会直接回滚。我的习惯是把 docx 里的机器配置要求转成一张现场核对表，落到每台机器上逐项打勾，再去执行安装动作。

环境核查可以用一段 PowerShell 快速抓出关键状态，不用一台台手工点“系统属性”。脚本逻辑是先看系统版本和内存，再看两个关键 Windows 功能是否启用，最后把结果直接输出到控制台，作为交付留痕的一部分。

# 一键盘点：OS 版本、内存、关键 Windows 功能状态 $os = Get-CimInstance Win32_OperatingSystem "OS: $($os.Caption) 内存: $([math]::Round($os.TotalVisibleMemorySize / 1MB, 1)) GB" Get-WindowsOptionalFeature -Online -FeatureName NetFx3 | Select-Object FeatureName, State Get-WindowsOptionalFeature -Online -FeatureName IIS-WebServerRole | Select-Object FeatureName, State

这里 FeatureName 用的是系统里的英文标识，中文系统也一样能匹配。NetFx3 是 .NET Framework 3.5 的功能名，IIS-WebServerRole 是 Web 服务器角色。State 返回 Enabled 才算通过。如果你打算在这台机器上只装 Robot，IIS 那行可以放过；但 NetFx3 是否启用要看安装包说明，UiPath 安装引导对 .NET 依赖比较敏感，离线环境又不能临时联网补功能，所以这一步宁可多查不可跳过。

2.3 联网机器上准备包：文档里那份清单怎么落地成离线仓库

拿到了 docx，里面最常见的东西是一串下载链接和文件名。很多时候链接有效，但现场没有外网，所以必须在联网机器上先把包备齐，再按角色分目录拷贝。我习惯建一个干净的目录结构，把安装包与依赖分开，避免到现场分不清哪个包属于哪个角色。

D:\uipath-offline\ packages\ # 存放 Studio、Robot 等安装包 dependencies\ # NuGet 依赖、运行库、证书 sources\sxs\ # 系统镜像里的 sxs 源，用于启用 .NET 3.5

目录确定后，下一步是照着 docx 的清单写一个小脚本，把链接一行行读完，自动下载并用 SHA256 校验。校验这一步看着多余，但在离线环境下非常关键：U 盘拷贝中途损坏是常态，等装到一半才报文件损坏，再回头重新拷贝成本极高。

# 按清单下载并校验：三列分别是 文件名、下载地址、期望SHA256 $listFile = "D:\uipath-offline\download-list.txt" $dest = "D:\uipath-offline\packages" Get-Content $listFile | ForEach-Object { if ($_ -match '^\s*$') { return } $name, $url, $expectedHash = $_ -split ' ', 3 Invoke-WebRequest -Uri $url -OutFile (Join-Path $dest $name) $actualHash = (Get-FileHash (Join-Path $dest $name) -Algorithm SHA256).Hash if ($actualHash -ne $expectedHash) { Write-Warning "$name 校验失败，请重新下载" } else { "OK: $name" } }

脚本的核心逻辑是对每一行做三列拆分，然后用 Invoke-WebRequest 下载，再用 Get-FileHash 算本地文件的 SHA256。参数 -Algorithm SHA256 指定哈希算法；-Uri 和 -OutFile 是下载的核心参数。注意-split ' ', 3里那个 3 是分割份数，防止下载地址里带空格被拆错。清单文件里最好去掉空行和注释，脚本里已经对空行做了跳过处理。下载完之后，把整个目录按执行机和应用服务器拆分好，别一个大文件夹全塞给对方。我在真实项目里吃过亏：把 Orchestrator 的安装包跟着执行机的包一起过了门禁，结果现场机器上多了一堆没人用、还占磁盘的依赖包。

3. 离线安装 Studio 与 Robot：静默参数与手动接线的完整过程

3.1 用命令行代替安装向导：msiexec 静默装 Studio

Studio 和 Robot 的安装看着是同一个向导，实际可走两条路：向导适合有显示器、能一步步点；隔离环境里我基本只用静默命令。原因很直白，免交互意味着不会因为缺某个依赖在中途弹出对话框，也不会因为现场没人盯着而卡在某个许可协议页。常见做法是拿到 UiPathStudio.msi 后先解包或直接执行，命令行里通过参数控制安装范围。

msiexec /i UiPathStudio.msi /quiet /norestart ` ADDLOCAL=DesktopFeature,StudioFeature,RobotFeature ` TRANSFORMS=UiPathStudio.mst

/quiet表示静默模式，全程不弹界面；/norestart避免装完自动重启系统，毕竟现场可能还有其他程序在跑。ADDLOCAL 是 msi 安装包的功能选择参数，这里列出三个常见功能：DesktopFeature 是桌面端基础能力，StudioFeature 是开发环境，RobotFeature 是机器人执行组件。如果你只是要一台执行机，可以不装 StudioFeature。TRANSFORMS 用来指定语言或组织定制配置，如果清单里没有 mst 文件，就把这段参数去掉。

这段命令看着简单，但有几个地方需要你根据手上的包版本做调整：ADDLOCAL 的功能名要以 msi 实际暴露的 feature 名为准，不同版本略有出入；TRANSFORMS 的文件名也千万不要照着文章抄，必须以解包后实际存在的 mst 文件名为准。命令执行完不会有任何窗口提示，判断是否成功要看系统和程序目录。装完别急着关命令行，下一步验证才刚开始。

3.2 Robot 怎么“接线”：机器密钥、服务与两处配置

如果只装 Studio 不连 Orchestrator，到上一步就结束了。但 docx 里既然给了完整方案，多数情况要接 Orchestrator。机器人连接服务器的核心凭证叫“机器密钥”，在 Orchestrator 后台的租户机器管理里添加一台标准机器时会生成。离线环境里通常由服务器管理员把密钥复制出来，实施人员再填到执行机上。

最常见的配置方式是打开 Robot 托盘界面，在设置里填 Orchestrator 地址和机器密钥。现场为避免输错，我一般先在执行机上用 PowerShell 把配置项读出来，确认当前机器已经注册了哪些密钥和地址，再决定要不要重配。

# 查看本机 UiPath Robot 的注册信息：机器密钥与服务器地址 $robotKeyPaths = Get-ChildItem "HKLM:\SOFTWARE\UiPath\Robot" -Recurse -ErrorAction SilentlyContinue foreach ($path in $robotKeyPaths) { Get-ItemProperty $path.PSPath | Select-Object MachineKey, OrchestratorUrl }

脚本先递归读取注册表里 UiPath Robot 节点下的所有子项，再把 MachineKey 与 OrchestratorUrl 两条属性打出来。不同版本注册表路径可能不同，所以用 Get-ChildItem 递归找比硬编码路径更稳妥。输出的 MachineKey 如果为空，说明机器人还没完成接线，需要在托盘里重新配置；OrchestratorUrl 也对不上，那就要检查是不是曾经连过测试服务器。

接线完成后要区分机器人的运行模式。Attended 模式必须有用户登录桌面，机器人托盘常驻，由人在适当时候触发流程；Unattended 模式则由 Orchestrator 在后台调度，不需要有人坐在机器前，但要给流程配置对应的 Windows 登录凭据。离线环境里常犯的错是：用户为了省事装了 Unattended，却忘了在 Orchestrator 里填 Windows 账号密码，导致任务一到时间就失败。装完后先想清楚这台机器给谁用，再决定模式，不要两台机器都默认选同一个。

3.3 装完也别急着验收：进程、服务与版本三项检查

命令执行完不等于安装成功。我见过最典型的情况是 msi 返回 0，但安装日志里其实有组件回滚，打开开始菜单找不到 UiPath，或者服务根本起不来。所以安装完成后要做三项检查：文件版本对不对、服务在不在、关键进程能不能起来。检查脚本可以一次跑完，输出直接留在交付记录里。

# 三项基础检查：文件版本、服务状态、可执行文件是否存在 $studioPath = "$env:ProgramFiles\UiPath\Studio\UiPath.Studio.exe" $robotPath = "$env:ProgramFiles\UiPath\Robot\UiPath.Executor.exe" if (Test-Path $studioPath) { "Studio 版本: $((Get-Item $studioPath).VersionInfo.FileVersion)" } if (Test-Path $robotPath) { "Robot 版本: $((Get-Item $robotPath).VersionInfo.FileVersion)" } Get-Service *UiPath* | Select-Object Name, Status, StartType

这里的逻辑是先用 Test-Path 确认主程序文件存在，再用 VersionInfo.FileVersion 拿到实际文件版本号，用来跟 docx 里期望的版本做对比。最后 Get-Service 列出所有 UiPath 开头的服务，状态为 Running 且启动类型为 Automatic 才算正常。如果你的机器上什么 UiPath 服务都没列出来，别急着怀疑服务名，先去“服务”管理器里用关键词 rehost 或 robot 搜一下，不同版本的显示名有差别。

装完这轮你可能还会遇到一个问题：Studio 打开正常，但 Robot 托盘图标不出来。多数是因为当前 Windows 用户从没登录过托盘程序，或者用户策略禁止开机启动。执行机在交付后往往不会频繁有人登录，所以最好的验证不是肉眼看托盘，而是让 Orchestrator 给这台机器发一个测试作业，确认能跑通。手动点几下只能说明程序能打开，不能说明调度链路是通的。

4. 搭 Orchestrator：数据库、IIS 与消息队列的一次性配置

4.1 先搞清 Orchestrator 依赖了什么

Orchestrator 不是双击一个 exe 就能跑的独立软件，它的常见部署形态是若干服务组成。每个组成部分在隔离环境里都变成一次额外的安装动作，所以 docx 里通常会单独列出它们。我拿到清单后会先画一张依赖关系图：Web 应用负责管界面和 API，数据库负责存流程、日志、队列，消息队列负责维持服务器与机器人之间的长连接。三者缺哪一个，后台都能打开，但机器人永远连不上。

这四类依赖里，IIS 是最容易在现场被忽略的。Windows Server 默认不一定装了 Web 角色，装完 Orchestrator 才发现缺 IIS，安装器只能回滚。数据库和消息队列相对独立，只要机器配置够，提前装好不冲突。我一般会按表格顺序打勾，全部就绪后再跑 Orchestrator 安装程序，这样排障范围最小。

4.2 数据库准备：排序规则、账号与一条连接字符串

数据库是 Orchestrator 最持久的依赖，流程日志、队列状态、机器人状态全在里面。离线交付里最容易出问题的不是建库，而是排序规则和登录模式。排序规则不一致会导致查询时莫名报错，登录模式关闭会导致安装器无法连接。建议在安装 Orchestrator 之前先把数据库这一层处理完。

-- 创建 Orchestrator 数据库，固定排序规则 CREATE DATABASE UiPathOrchestrator COLLATE Latin1_General_CI_AS; -- 创建专用登录账号并授予该库权限 CREATE LOGIN uipath_svc WITH PASSWORD = 'your_strong_password'; USE UiPathOrchestrator; CREATE USER uipath_svc FOR LOGIN uipath_svc; EXEC sp_addrolemember 'db_owner', 'uipath_svc';

COLLATE 指定了数据库的排序规则，Latin1_General_CI_AS 是常见选择，大小写不敏感、重音敏感，能避免很多中文环境下的字符串比较问题。数据库创建后，新建的登录名只在实例级存在，必须再用 CREATE USER 映射到 UiPathOrchestrator 库里，最后用 sp_addrolemember 把该用户加入 db_owner 角色。这里给 db_owner 是交付阶段最省事的做法，生产环境可以后续再把权限收敛到更小范围。

密码字段不要用简单的演示密码，离线环境里数据库账号往往长期不动，泄露后影响面很大。我一般会生成一段 20 位以上的随机密码，存到交付文档里由现场保管。还要注意一点：数据库实例必须开启混合身份验证，否则即使账密正确，客户端也可能连不上。如果安装向导提供的测试连接报错，先不要怀疑 Orchestrator，直接用数据库客户端连一次，能定位问题到底在哪一层。

4.3 IIS 站点与 HTTPS 绑定：一次配置，防止机器人握手失败

数据库准备好后，要给 Orchestrator 准备 Web 运行环境。IIS 的安装不复杂，但必须在跑安装器之前完成。Windows 命令可以直接把 IIS 和 ASP.NET 功能一次性打开，避免去图形界面里逐项勾选。

# 启用 IIS Web 服务器与 ASP.NET 功能 Install-WindowsFeature Web-Server, Web-Asp-Net45 -IncludeManagementTools

Web-Server 是 IIS 主角色，Web-Asp-Net45 是运行 Web 应用必需的 .NET 扩展，-IncludeManagementTools 会带出管理控制台。这一步要联网访问 Windows 功能源，离线环境需配合系统镜像里的 sxs 源，否则会提示找不到源文件。装完后在浏览器里访问本机地址，能看到 IIS 默认页面，说明 Web 服务器已经就绪。

接下来是端口和防火墙。Orchestrator 默认会用到多个端口，其中给机器人通信的端口尤其关键。为了让服务账号能监听端口，需要添加 URL 保留项，否则 IIS 应用池重启后端口可能被占用或拒绝访问。

# 为 Orchestrator 端口添加 URL 保留 netsh http add urlacl url=http://+:8181/ user=Everyone # 放行防火墙端口 netsh advfirewall firewall add rule name="UiPath Orchestrator 8181" dir=in action=allow protocol=TCP localport=8181

urlacl 的作用是允许非管理员账号绑定该 URL 前缀，user=Everyone 表示所有本地账号都能监听，适合统一管理的内部环境；如果安全策略不允许 Everyone，可以换成运行 Orchestrator 应用池的专用账号。netsh advfirewall 这一条是防火墙入站规则，只放行 TCP 8181，与机器人通信相关的端口是否要开，要以安装文档实际部署的端口为准，不要把所有端口一排全开。

最后是 HTTPS。机器人连服务器时如果地址是 https，执行机必须信任对应的服务器证书。内部环境最省事的方式是在应用服务器上生成一张自签证书，然后把公钥导出到每台执行机的受信任根证书目录。证书生成工具在不同系统上命令不一样，我习惯用 Windows 自带的 New-SelfSignedCertificate 生成，再在 IIS 管理器里给站点做绑定，绑定信息里填主机名与证书。这样机器人握手时才不会出现“证书链信任”的报错，这类问题在下一章的离线排障里也是最常见的。

5. 离线安装排障现场：五种翻车现象与对应处理

5.1 现象：安装向导走到一半提示找不到 .NET Framework 3.5

离线环境里装 UiPath 相关组件，经常在第一步就碰到这个提示。现场一排查，系统功能列表里 .NET Framework 3.5 就是灰色的，Windows Update 又连不上，于是安装只能中断。这不是 UiPath 的问题，是很多业务软件在 Windows Server 上都会撞到的公共依赖坑。

原因很明确：Windows Server 默认不启用 .NET 3.5，在线环境会从 Windows Update 拉取功能文件，离线环境没有这个通道。解决方式不是联网装，而是准备同一版本系统镜像里的 sxs 源，用 DISM 让系统从本地源启用功能。

# 从本地 sxs 源启用 .NET Framework 3.5 DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /LimitAccess /Source:D:\sources\sxs

/LimitAccess 告诉 DISM 不要访问 Windows Update，只从 /Source 指定的路径找功能文件。Source 必须指向与当前系统同版本、同架构的镜像解压目录，版本不匹配时命令会报 0x800f081e。执行成功后，再去看系统功能里的 .NET 3.5，状态会变为已启用。这条命令跑完通常不需要重启，但若安装器已经回滚，最好重启一次再重新跑安装。

5.2 现象：Orchestrator 一直连不上数据库实例

安装 Orchestrator 时填了数据库地址和账号，测试连接就是不通过。我把这类问题归成三类：登录模式没开、排序规则不一致、密码在连接串里被特殊字符干扰。第三种最隐蔽，密码里有分号或尖括号时，连接字符串可能被错误解析，报错看起来像登录失败。

先确认实例允许混合身份验证。数据库安装时的默认模式可能是“仅 Windows 身份验证”，Orchestrator 用 SQL 账号登录必然失败。先注册表层面改登录模式，再重启实例。

-- 允许 SQL 身份验证（Mixed Mode） EXEC xp_instance_regwrite N'HKEY_LOCAL_MACHINE', N'Software\Microsoft\MSSQLServer\MSSQLServer', N'LoginMode', REG_DWORD, 2;

xp_instance_regwrite 直接写实例的注册表配置，最后一项 2 表示混合模式。执行后重启数据库服务，让配置生效。改完登录模式，用一段 PowerShell 测试连接，比反复在安装向导里点测试按钮更快定位问题。

# 用 SQL 客户端连接串做连通性测试 $conn = New-Object System.Data.SqlClient.SqlConnection( "Server=tcp:db_host,1433;Database=UiPathOrchestrator;User Id=uipath_svc;Password=your_strong_password;TrustServerCertificate=True;") $conn.Open() "连接成功"

连接串里的 Server 要换成实际主机名或 IP，端口 1433 是数据库实例常见监听端口。TrustServerCertificate=True 避免证书校验干扰排查，正式配置时再按策略决定是否保留。如果这里仍然报错，就去看错误文本里的关键词：网络相关多半是防火墙或端口没通，登录相关多半是账号密码或登录模式，数据库相关多半是库里权限没给。

5.3 现象：Robot 能装能登录，但 Orchestrator 里机器人一直“未连接”

Studio 和 Robot 都装好了，后台也建了机器，密钥也贴进去了，但机器人状态始终灰着。我见过很多实施人员卡在这，甚至开始反复重装 Robot。实际上机器人连不上服务器，九成不是安装问题，而是链路里某一环配置不一致。

排查有固定顺序，简历里先看证书，再看时间，最后看机器密钥。前两个最容易被忽略：自签证书没有导入执行机，执行机的时钟与服务器偏差超过几分钟，TLS 握手都会失败；机器密钥只是最后一道身份关卡，但它最长被怀疑。

# 导出服务器自签证书到文件 Export-Certificate -Cert (Get-ChildItem Cert:\LocalMachine\My\<thumbprint>) -FilePath D:\orchestrator.cer # 在每台执行机上导入到受信任根目录 Import-Certificate -FilePath D:\orchestrator.cer -CertStoreLocation Cert:\LocalMachine\Root

第一个命令里的 thumbprint 要替换成服务器证书实际的指纹，可以在“证书管理器”里查看。导出后拿着 cer 文件到每台执行机执行第二条命令，导入位置是 LocalMachine\Root，也就是“受信任的根证书颁发机构”。导入后重启 Robot 服务，状态一般会很快恢复。时间同步不必用命令硬推，先在执行机上打开日期时间设置，看与服务器时间差是否超过 5 分钟；如果差得远，修正后再重试连接。顺序别反，证书和时钟不对，密钥填得再准也是白填。

5.4 现象：从 U 盘拷到执行机的安装包双击就报“程序无法验证”

隔离环境里安装包绝大多数是靠 U 盘或内部共享目录传过去的。于是另一种翻车现场出现了：同一个包在联网机上能正常打开，拷到执行机后双击，安装器提示不能验证或文件已损坏。有人马上怀疑拷贝过程损坏，重新拷了一遍还是同样报错。

实际原因很可能是 Windows 的附件标记机制在起作用。从网络或 U 盘拷入的文件会带上 Zone.Identifier 区域信息，安装器看到这个标记后拒绝执行，报错非常像文件损坏。解决方式不是关闭安全策略，而是把文件的区域标记清除掉。

# 清除从外部介质拷入的安装包区域标记 Get-ChildItem D:\packages\*.msi | Unblock-File

Unblock-File 是 PowerShell 自带的 cmdlet，作用是把文件的 Zone.Identifier 删除，让安装器认为文件来自可信位置。执行后不需要重启，重新双击安装包即可。清掉标记之后，建议顺手用之前下载时保留的 SHA256 清单再核对一遍哈希，确认文件本身没损坏。这样做把“文件坏了”和“文件被标记了”两个可能性同时排除，不留隐患。

5.5 现象：流程发布到 Orchestrator 后，机器人执行时报缺依赖

到了这一步，安装链路全通，但流程一跑就失败，报错指向某个程序集找不到或包解压失败。这个问题在离线环境里格外常见，原因是执行机没有外网 NuGet 源，而流程包在 Studio 打包时引用的依赖项并没有全部打进去。在线环境里，Robot 启动流程时会自动去公共源拉依赖；离线环境里没有这个源，机器人只能干瞪眼。

解决方向是把依赖预先放到执行机本地。常见做法是在每台执行机建一个本地 NuGet 包目录，把流程依赖的 nupkg 文件放进去，并将该目录配置为本地包源。配置命令类似下面这样，具体命令名以你手上的包管理工具为准。

# 添加本地包源，并推送离线流程包 nuget sources add -Name "UiPathLocal" -Source "D:\NuGetCache" nuget push your.package.nupkg -Source "D:\NuGetCache"

第一行把 D:\NuGetCache 注册为一个名为 UiPathLocal 的本地源，第二行把 nupkg 包推到这个目录。Robot 启动流程时如果配置了从本地源加载，就不再请求外网。做完之后再从 Orchestrator 触发一次测试作业，确认报错消失。还有一种变体是流程包本身没把自定义程序集封装好，那就要回到 Studio 里修改打包配置，而不是继续在运行环境折腾。缺依赖类报错的关键是先看清错的是“下载依赖”还是“加载程序集”，两者处理入口完全不同。

6. 一个能提前发现问题的体检脚本：版本核对与端口自检

装完一个环境，交付文档里总得有个验收依据。与其靠人肉点界面，我习惯写一个一体化的体检脚本，把版本、服务、端口、服务器连通性一次性跑出来。这个脚本也能在日后升级或巡检时直接复用，省掉反复登录机器确认的时间。

# 一键体检：版本、服务、端口、Orchestrator 连通性 $errors = @() $studioPath = "$env:ProgramFiles\UiPath\Studio\UiPath.Studio.exe" $robotPath = "$env:ProgramFiles\UiPath\Robot\UiPath.Executor.exe" if (Test-Path $studioPath) { "Studio 版本: $((Get-Item $studioPath).VersionInfo.FileVersion)" } else { $errors += "未发现 Studio 主程序" } if (Test-Path $robotPath) { "Robot 版本: $((Get-Item $robotPath).VersionInfo.FileVersion)" } else { $errors += "未发现 Robot 主程序" } Get-Service *UiPath* | Select-Object Name, Status, StartType foreach ($port in 443, 8181, 8883) { if (Get-NetTCPConnection -LocalPort $port -State Listen -ErrorAction SilentlyContinue) { "端口 $port 正常监听" } else { $errors += "端口 $port 未监听" } } $orchUrl = "http://localhost:8181" try { $resp = Invoke-WebRequest -Uri $orchUrl -UseBasicParsing -TimeoutSec 5 "Orchestrator HTTP 状态码: $($resp.StatusCode)" } catch { $errors += "Orchestrator 不可达: $($_.Exception.Message)" } if ($errors.Count -gt 0) { "发现问题:" $errors | ForEach-Object { Write-Warning $_ } } else { "体检通过" }

脚本的运行逻辑是逐步判定，最终把错误汇总到 $errors 列表里再统一输出。端口 8181 对应本地 Orchestrator 站点，8883 常用于机器人连接通道，如果你的环境用了不同端口，改 foreach 那一行的数字即可。Invoke-WebRequest 探测返回 200 或 302 都说明站点在响应，不需要访问具体业务页面。每次装完新机器，我把脚本输出直接粘回当天的交付记录，后面真出了问题，别人也能从这份记录里看出哪一步已经验证过。

这套流程跑多了，我养成了一个固定习惯：先把环境盘点做成核对表，再准备离线包，装完立刻体检并留日志。看起来比直接双击安装包多花十几分钟，但能少掉几轮半夜被叫起来排查的时间。文档里那些步骤并不是一“下载”就能结束的，后续的检验和记录同样重要。把这些细节都做到位，现场交付的 UiPath 环境才真的能放心交给使用方。希望帮到你。

本文还有配套的精品资源，点击获取