在新的或现有的用户界面自动化工作流中采用 ScreenPlay 的推荐方法，以及保持这些工作流快速且经济地大规模运行的实践。
采用 ScreenPlay 的方法（无论是将其集成到现有的用户界面自动化工作流中还是构建新的智能体驱动的自动化），以及用于在这些自动化大规模运行后保持这些自动化快速且经济运行的方法。
ScreenPlay 在自动化中的位置
ScreenPlay 专为处理特定高摩擦点而设计，这些高摩擦点也称为“受控自主性场景” ，是指传统工具最难处理的关键自动化小区域。ScreenPlay 不会取代整个工作流，而是为最需要它的部分提供智能体执行：
- 容易损坏的脆弱选取器。
- 复杂的用户界面结构和动态元素。
- 难以访问的用户界面元素，例如弹出窗口、虚拟化列表、嵌入式表格或自定义控件。
这个推导出来也同样重要。在 Unattended 自动化中，您必须信任您未在监督的运行，并且工作流的确定性部分是唯一每次行为相同的部分。它们的执行速度最快、成本最低，这使其经过数千次运行仍然可行。
其目标是实现最大程度的确定性、最低代理性工作流：界面稳定且步骤已知的传统 UI Automation，以及只有智能体执行是可靠满足业务需求的唯一方法的 ScreenPlay。
入门指南
根据您的上下文，以下路径可用。
正在升级存在问题的自动化
您可以使用 ScreenPlay 活动修复当前 UIAutomation 中存在问题的步骤，例如：
- 反复失效的选取器。
- 用户界面更改后中断的自动化。
- 为简单任务编写过于复杂的逻辑。
您可以通过自然语言提示定义使用的操作，而非脆弱的选择器或冗长的自定义逻辑。 这有助于简化开发，并使您的自动化随时间推移更具弹性。
从头开始构建细粒度自动化
如果您从头开始使用 UIAutomation，则可以完全使用 ScreenPlay 以细粒度方式进行构建。
每个 ScreenPlay 活动都应当与流程中范围明确的小步骤相对应，最好是两三个自然衔接的步骤。
这种细粒度方法具有以下优势：
- 最大限度地提高准确性。
- 让智能体专注于特定任务。
- 避免使模型过度加载上下文。
根据每个步骤的复杂性，您可以选择适当的 AI 模型，在成本效率与功能之间取得平衡。
使用编码智能体构建
您还可以使用 UiPath 智能体技能，通过 AI 编码智能体构建自动化，指导智能体如何在您的开发环境中创作、运行、测试和部署 UiPath 自动化。有关目录和安装说明，请参阅UiPath 智能体技能存储库。
创作技能专注于生成 RPA，因此默认情况下编码智能体生成的结果是确定性的，这就是您想要的基线。推荐的方法是查看生成的工作流，并在需要智能体方法的点上添加 ScreenPlay 活动。
应谨慎添加这些内容，并尽量减少添加内容。在每一处，行为都无法得到保证，执行时间和令牌消耗都会增加。
大规模针对速度和成本进行设计
每天运行几次的自动化与运行数千次的自动化具有非常不同的经济性。以下做法可在不放弃可靠性的情况下减少延迟和令牌消耗。
保持智能体表面小
这是影响最大的决策，在设计时做出，而不是在之后进行调整。每个可以确定性表示的步骤都是不消耗模型调用时间、不增加延迟、不会因运行而异的步骤。
首先确定性基线，只有在合适的位置才会添加智能体步骤。
为每个步骤选择正确的模型
同时， “模型”下拉列表中可用的模型的运行速度越来越快、功能越来越强大，因此与以前相比，速度和质量之间的取舍要小得多。
由于每个 ScreenPlay 活动都具有自己的模型选择功能，因此您可以将模型与步骤的难度进行匹配：快速基础层模型用于常规交互，标准层模型用于真正需要更多推理的步骤。有关可用模型的完整列表，请参阅ScreenPlay 。
如果您的自动化是针对旧模型构建的，则重新访问选择是可用的成本最低的速度改进之一。
在同一屏幕上批处理多个操作
ScreenPlay 智能体工具可以在同一屏幕上分批执行多个操作，而不是每次模型调用执行一个操作。模型往返次数越少意味着端到端延迟就越低，这种差异在操作密集的屏幕（例如长表单）上最为明显。
这不是默认行为。默认情况下，线束一次执行一个操作，只有在任务提示明确要求时才会进行批处理。当操作针对同一屏幕时，线束将遵循这些指示。
例如，而不是：
Fill in the customer details form.
Fill in the customer details form.
请使用：
Fill in the customer details form. Fill in all the fields visible on the screen in one go, then submit.
Fill in the customer details form. Fill in all the fields visible on the screen in one go, then submit.
批处理仅适用于可以在当前可见屏幕上执行的操作。需要导航、页面转换或更改应用程序的步骤仍会按顺序执行，因为模型需要观察新的屏幕，然后再决定下一步操作。
何时停止优化
完全针对执行时间和令牌消耗进行优化可能会将您推向确定性的实现，这种实现方式很脆弱，而且保持活动状态的成本高昂。如果每次较小的用户界面更改都会中断一次选取器繁重的工作流，则该工作流在其生命周期内的消耗可能比其节省的令牌更高。
Healing Agent 缩小了这一差距，但并没有缩小这一差距。其恢复策略是一个已定义的有限集合，并且它们都会在为已存在的活动重新识别目标元素的级别上起作用：
- 更改了选取器属性。
- 计时。
- 锚点位置。
- AppCard 标题。
- 设计时语义选取器回退。
Healing Agent 还会将基于 AI 的策略应用于：
- 弹出窗口阻碍了目标元素。
- 按语义重新表述的标签。
- 计算机视觉。
这涵盖了大部分日常用户界面偏移，但无法吸收交互本身的更改，例如出现新的确认对话框、一组重新排序的屏幕、移到另一个步骤的字段或现在需要不同序列的流操作数量。
启用 Healing Agent 不能替代良好的工作流设计，也无法使脆弱的确定性实施无限期保持活动状态。
对于您预计会进行此类更改的应用程序部分，ScreenPlay 是更好的答案。用自然语言描述结果并让智能体在运行时计算交互结果，可消除这些步骤的维护负担，但会增加模型调用次数。随着目标应用程序的发展，需要重新考虑哪些步骤值得进行那样的处理。