机器人
UiPath 机器人是运行 UiPath Studio 中设计的流程的执行主机。在 Orchestrator 中，机器人对象表示 UiPath 机器人的图像，并帮助定义其功能和对 Orchestrator 资源的访问权限。
本指南旨在提供与 Orchestrator 对象相关的上下文和说明。有关如何安装和配置 UiPath 机器人的更多详细信息，请访问机器人指南。
|
常用术语 |
意义 |
|---|---|
|
UiPath 机器人 |
运行 UiPath Studio 中设计的流程的执行主机。 |
|
机器人（Orchestrator 对象） |
Orchestrator 对象用于定义 UiPath 机器人的功能和权限，例如访问文件夹资源、计算机登录凭据等。在本指南中，通常将其称为机器人、机器人对象、机器人实体。 |
|
计算机（主机） |
用于托管和部署 UiPath 机器人的物理机或虚拟机。在本指南中，将其称为主机、工作站或服务器，以使其与 Orchestrator 中的计算机对象区分开。 |
|
计算机（Orchestrator 对象） |
充当 API 密钥生成器的 Orchestrator 对象，用于授权在主机上使用 UiPath 机器人。对于 Unattended 用例，它还允许管理员为关联的主机配置执行能力。 |
有人值守的机器人充当最终用户的个人助理，例如人力资源人员、呼叫中心接线员等。由于有人值守的自动化必须在人的监督下运行，因此，最适合用于更小、更分散的任务。例如，费用报告的提交是一项适合有人值守的自动化的任务，在该任务中，用户提供登录系统的凭据，然后自动化填写必要的信息，附加任何需要的项目，并代表用户提交报告。
由于始终有人类用户在场，因此不得创建具有用户本身无法执行的任务的权限的有人值守自动化，也不得授予相应的权限。在执行有人值守流程期间所需的任何凭据都应始终是触发自动化的用户知道并提供给自己的凭据。
这是因为无法确保正在运行的自动化与计算机用户之间的安全隔离。如果自动化本身执行用户无权访问的操作，则系统将允许该用户访问未获得这些权限的操作。以上面的费用报告为例，如果批准费用报告的流程也捆绑到该自动化中，则用户只需在登录到批准系统后暂停或停止该自动化，即可批准任何金额的任何报告，而用户使用自己的凭据无法执行该操作。
有人值守的机器人模拟了真实的个人，因此它们应以用户帐户运行。
Assistant 在执行流程时充当用户的助手，让值守用户只需单击几下即可管理和运行自动化。从技术角度来看，Assistant 是用户模式机器人服务的客户端，该服务是自动化执行期间执行的所有操作的大脑。
用户模式机器人最适用于有人值守的自动化场景，因为此机器人会在启动它的用户下运行，并拥有与该特定用户完全相同的权限。
默认情况下，当服务设置为在登录时运行时，机器人服务的启动由用户登录触发。如果未将其设置为在登录时运行，则打开 UiPath Assistant 会自动启动它。
要执行 Attended 的操作，必须为运行机器人的用户分配一个许可证，该许可证可为该用户提供使用 Attended Robot 的权限，或者您可以从命令行本地许可机器人。有关可用 SKU 的详细信息，请参阅 UiPath 许可门户。
无人值守的机器人属于自主机器人，不需要人工监督即可执行作业。无人值守的自动化主要用于更复杂、高度重复的任务，这些任务通常需要分批执行，并且可以根据预定义的规则来决定。此外，无人值守的自动化适合执行特权操作的流程，这些流程需要提升的权限和凭据。
费用报告的批准就是这样的任务。在没有人类用户在场的情况下，该自动化将登录到必要的系统，然后处理任何已提交的费用报告，如果这些报告与已定义的规则匹配（例如，不超出指定的金额），则系统会自动批准这些报告。
在此示例中，无人值守流程将获得通过管理员配置的凭据资产批准费用报告的权限。这提供了安全隔离，因为 Automation Developer 仅引用要提供的凭据，因为清晰明了的审核链记录了有关谁获取和管理自动化使用的凭据之记录。
无人值守的机器人可以在没有人为干预的情况下运行，因为它们在基于触发器的逻辑上运行，这意味着端到端无人值守流程执行是完全自动化的，并在流程流中定义的某些事件触发时展开，与此相反，有人值守的机器人无法自始至终实现自动化，因此需要人工指导来执行某些活动。
无人值守机器人应在机器人帐户、专用于应用程序或虚拟机的特殊帐户（而不是人员）下运行。
Orchestrator 是无人值守自动化的中心枢纽，因为它允许当场启动无人值守执行，或通过使用触发器以预先计划的方式进行设置。它还管理要在自动化项目中使用并由机器人使用的资源，并通过支持分层结构并结合精细的角色分配来访问这些资源。
Orchestrator 还可以将工作负载分配给无人值守机器人，当允许动态分配工作负载时（无限制），可以最大限度地提高效率并优化机器人的使用。
UiPath Assistant 用于帮助用户实现有人值守的自动化。在无人值守方案中，Assistant 仅用于调试目的，当用户登录到无人值守计算机以查找和修复潜在问题时。换句话说，无人值守机器人可以在生产环境中以有人值守模式使用，以进行日志记录/测试/调试。
服务模式机器人最适合 Unattended 自动化场景和大规模平台部署。执行流程时，机器人执行程序会使用与注册它的用户相同的权限运行。
机器人服务是执行期间执行的所有操作的大脑，而对于无人值守执行，则在本地系统下启动。该管理器可打开交互式 Windows 会话，并且拥有计算机管理员的所有权限。正因如此，它可以为无人值守作业启用自动会话管理（例如登录和注销）。
UiPathStudio.msi 安装机器人会部署服务模式机器人。您也可以通过命令提示符安装该机器人。
该计算机装有面向所有用户的服务模式机器人。在 Windows Server 计算机上安装服务模式机器人后，您可以利用自动会话管理功能来运行并发的无人值守作业。这展示了一种无缝的无人值守自动化场景。您可以使用 Windows Server 上的用户模式机器人执行并发作业，但不能执行自动会话管理。
如需了解有关高密度机器人的更多信息，请参阅机器人指南。
对于无人值守机器人，许可是按分配的运行时（插槽）实体而不是按用户执行的。这就是在计算机对象级别分配无人值守、非生产、测试运行时的原因。
假设您有一个定义了 10 个无人值守运行时的计算机模板。对于使用该模板生成的密钥连接的每个工作站，将从租户级别的许可证总数中保留一个包含 10 个许可证的池。运行时仅在作业执行期间从保留的许可证池中使用。如果使用该模板将 4 台计算机连接到 Orchestrator，则需要 40 个租户级别的无人值守运行时许可证。有 25 个作业正在运行，仍有 15 个插槽可供执行。
机器人在特定帐户（用户帐户或机器人帐户）下运行，这意味着机器人在相应身份的上下文中运行。这些身份及其与角色的关联允许对 Orchestrator 中的资源进行一定程度的访问。
要为无人值守的机器人提供对文件夹中资源的访问权限，管理员必须将基础帐户添加到该文件夹中。还必须向该帐户授予执行该文件夹中包含的流程，或者至少是它们将要执行的流程（例如，如果某些流程仅在特定帐户下运行）所需操作的权限。此外，必须为文件夹分配具有足够运行时的计算机模板。此操作允许您指定可用于在这些文件夹中执行自动化的基础架构（主机），并确保它们具有可用于执行的插槽。
A. 具有凭据
由于无人值守自动化意味着缺少人工代理，因此通常需要为无人值守机器人提供登录主机的凭据，例如与用户界面交互的自动化项目。UiPath 支持多种凭据类型：
- 用户名/密码凭据 - 这是默认方法。
- 智能卡身份验证
-
备注：
用于身份验证的用户名和密码仅在心跳上传输，从而使其能够登录并执行流程。
除非您提供了正确的计算机登录凭据，否则您无法执行与用户界面交互的无人值守流程。
B. 没有凭据 无人值守机器人在NT AUTHORITY\LOCAL SERVICE下的会话 0 中处理后台流程，该帐户没有用户界面且无法与用户会话交互。因此，您不需要凭据即可执行后台流程。但是，您确实需要凭据才能执行前台流程。流程类型
凭据注意事项
最低为 2021.8 的计算机
后台
有凭据的机器人
任何
前台
有凭据的机器人
任何
后台
没有凭据的机器人
2021.10 及更高版本
前台
没有凭据的机器人
无效配置！无法执行作业。
浮动机器人使用户可以在多个工作站上使用 UiPath 机器人，因为该机器人没有绑定到特定的计算机。新式文件夹中的所有机器人均为浮动机器人。拥有一个 Named User 许可证，一个用户最多可以同时在三台计算机上使用 UiPath 机器人。
要在三个工作站之间更改其正在使用的工作站，用户需要从先前使用的计算机上注销并登录到新计算机。
标准机器人是浮动机器人的前身，只有在使用传统文件夹时才能找到它们。标准机器人限制用户在单个工作站上使用 UiPath 机器人，因为机器人绑定到特定计算机，即在 Orchestrator 中创建标准机器人时设置的计算机。标准机器人仅适用于始终在同一台计算机上工作的用户，或者每次连接到计算机时名称都保持不变的用户。
更改工作站需要删除初始的标准机器人，并使用新的标准计算机的名称重新创建。
