使用Amazon Bedrock Agents实现人在环确认

代理正在彻底改变企业如何自动化复杂的工作流程和决策过程。Amazon Bedrock Agents通过编排多步骤任务来帮助您加速生成式AI应用程序开发。代理使用基础模型（FM）的推理能力将用户请求的任务分解为多个步骤。此外，他们使用开发人员提供的指令创建编排计划，然后通过调用公司API和使用检索增强生成（RAG）访问知识库来执行该计划，以对用户的请求提供答案。

构建有效处理用户查询的智能自主代理需要仔细的规划和强有力的保护措施。尽管FM不断改进，但它们仍然会产生不正确的输出，而且由于代理是复杂的系统，错误可能发生在多个阶段。例如，代理可能会选择错误的工具或使用参数不正确的正确工具。尽管亚马逊基岩代理可以通过其推理和行动（ReAct）策略进行自我纠正，但重复的工具执行对于非关键任务可能是可以接受的，但对于关键业务操作（如数据库修改）则有风险。

在这些敏感场景中，人在环（HITL）交互对于成功部署人工智能代理至关重要，包括人类和自动化系统之间的多个关键接触点。HITL可以采取多种形式，从最终用户批准行动和提供反馈，到主题专家离线审查回复，再到代理商与客户服务代表一起工作。共同点是保持人工监督，并利用人工智能来提高代理性能。这种人类参与有助于建立基本事实，在代理响应上线之前对其进行验证，并通过反馈循环实现持续学习。

在这篇文章中，我们特别关注使用内置的Amazon Bedrock agent功能，特别是HITL模式，使最终用户能够批准操作并提供反馈，以提供安全有效的代理操作。我们使用人力资源（HR）代理示例来探索可用的模式，该示例可以帮助员工申请休假。您可以手动重新创建该示例，也可以通过遵循我们的GitHub存储库使用AWS云开发工具包（AWS CDK）。我们从应用程序开发人员的角度向您展示这些方法的外观，同时为您提供概念背后的总体思路。对于该帖子，我们在Amazon Bedrock上应用用户确认和控制权返回，以实现人工确认。

Amazon Bedrock Agents用于人在环确认的框架

在Amazon Bedrock Agents中实现人工验证时，开发人员可以使用两个主要框架：用户确认和控制返回（ROC）。这些机制虽然服务于类似的监督目的，但解决了不同的验证需求，并在代理工作流程的不同级别上运行。

用户确认提供了一种在执行之前暂停和验证特定操作的简单方法。通过用户确认，开发人员接收代理想要用来完成特定任务的函数（或API）和参数值的信息。然后，开发人员可以在代理应用程序中向用户公开此信息，以收集在继续代理的编排过程之前应执行该功能的确认。

使用ROC，代理向开发人员提供有关它想要执行的任务的信息，并完全依赖开发人员执行任务。在这种方法中，开发人员不仅可以验证代理的决策，还可以在代理的执行过程中提供额外的上下文并修改参数。ROC也恰好在行动组级别配置，涵盖多个行动。

让我们探讨如何实现每个框架及其具体用例。

自主代理执行：循环中没有人

首先，让我们演示一下如果你的应用程序没有HITL，用户体验会是什么样子。为此，让我们考虑以下架构。

在上图中，员工与HR Assistant代理交互，然后该代理调用可以更改员工带薪休假（PTO）重要细节的操作。在这种情况下，当员工申请休假时，代理将在确认申请员工仍有足够的PTO天数后自动申请休假。

以下屏幕截图显示了Amazon Bedrock代理的前端UI示例，该代理具有检索PTO和请求新PTO的功能。

在这次交互中，PTO请求是在没有最终用户确认的情况下提交的。如果用户不想实际提交请求，而只是检查是否可以完成，该怎么办？如果他们提供的日期不正确并且有拼写错误怎么办？对于任何改变用户PTO状态的操作，如果系统在实际进行这些更改之前要求确认，它将提供更好的用户体验。

简单的人工验证：用户确认

在请求PTO时，员工希望能够确认他们的行为。这最大限度地减少了意外请求的执行，并有助于确认代理正确理解请求及其参数。

对于这种情况，布尔确认已经足以继续执行代理流。Amazon Bedrock Agents提供了一种开箱即用的用户确认功能，使开发人员能够在其AI驱动的工作流程中加入额外的安全和控制层。该机制通过确保关键操作在执行前得到用户的验证，在自动化和人工监督之间取得了平衡。通过用户确认，开发人员可以决定哪些工具可以自动执行，哪些工具应该首先确认。

对于我们的示例，读取可用PTO小时数的值并列出员工过去提出的PTO请求是可以自动执行的非关键操作。但是，预订、更新或取消PTO请求需要对数据库进行更改，这些操作应在执行前进行确认。让我们更改我们的代理架构，以包括用户确认，如下图所示。

In the updated architecture, when the employee interacts with the HR Assistant agent and the create_pto_request() action needs to be invoked, the agent will first request user confirmation before execution.

To enable user confirmation, agent developers can use the AWS Management Console, an SDK such as Boto3, or infrastructure as code (IaC) with AWS CloudFormation (see AWS::Bedrock::Agent Function). The user experience with user confirmation will look like the following screenshot.

In this interaction, the agent requests a confirmation from the end-user in order to execute. The user can then choose if they want to proceed with the time off request or not. Choosing Confirm will let the agent execute the action based on the parameter displayed.

The following diagram illustrates the workflow for confirming the action.

在这种情况下，开发人员在客户端UI中映射向用户显示确认的方式，代理在执行操作之前验证确认状态。

定制化人工输入：控制权的回归

用户确认提供了一个简单的是/否验证，但有些场景需要更细致的人工输入。这就是ROC发挥作用的地方。ROC允许更深层次的人为干预，使用户能够在执行操作之前修改参数或提供额外的上下文。

让我们考虑一下我们的人力资源代理示例。在请求PTO时，一个常见的业务要求是员工在提交之前审查并可能编辑他们的请求。这扩展了简单的确认用例，允许用户在向后端发送请求之前更改其原始输入。Amazon Bedrock Agents提供了一种开箱即用的解决方案，可以有效地解析用户输入，并使用ROC以结构化格式将其发送回来。

为了实现ROC，我们需要稍微修改我们的代理架构，如下图所示。

In this architecture, ROC is implemented at the action group level. When an employee interacts with the HR Assistant agent, the system requires explicit confirmation of all function parameters under the “Request PTO Action Group” before executing actions within the action group.

With ROC, the user experience becomes more interactive and flexible. The following screenshot shows an example with our HR agent application.

Instead of executing the action automatically or just having a confirm/deny option, users are presented with a form to edit their intentions directly before processing. In this case, our user can realize they accidentally started their time off request on a Sunday and can edit this information before submission.

After the user reviews and potentially modifies the request, they can approve the parameters.

在实施ROC时，了解参数验证发生在两个不同的点至关重要。代理在将控制权返回给用户之前执行初始验证（例如，检查可用的PTO余额），最终执行依赖于应用程序的API验证层。

例如，如果用户最初请求3天的PTO，代理将根据其5天的余额进行验证并返回控制权。但是，如果用户在ROC期间将请求修改为100天，则最终验证和实施将在API级别进行，而不是通过代理。这与代理直接执行API调用的确认流不同。在ROC中，代理的作用是促进交互并返回API响应，并且应用程序保持对参数验证和执行的最终控制。

ROC方法的核心区别在于，处理休假请求的责任现在由应用程序本身处理，而不是由代理自动处理。这允许更复杂的工作流程和更大的人工监督。

为了更好地理解ROC场景中的信息流，让我们检查以下序列图。

在此工作流中，代理准备操作但不执行。相反，它将控制权返回给应用程序，然后应用程序将可编辑信息呈现给用户。在用户审查并可能修改请求后，应用程序负责使用最终的用户批准的参数执行操作。

这种方法有几个好处：

• 提高准确性——用户可以纠正代理对其请求的解释中的误解或错误
• 灵活性——它允许在最后一刻对请求进行更改或添加
• 用户授权——它使用户对最终操作有更多的控制权，增加了对系统的信任
• 合规性——在受监管的行业中，这种程度的人为监督对于遵守法律或政策要求至关重要

与用户确认相比，实现ROC需要更多的开发工作，因为它涉及创建UI来编辑和处理应用程序中操作的执行。然而，对于精度和用户控制至关重要的场景，额外的复杂性通常是合理的。

结论

在这篇文章中，我们探讨了在Amazon Bedrock Agents中实现人工验证的两个主要框架：用户确认和控制权返回。尽管这些机制具有类似的监督目的，但它们满足了不同的验证需求，并在代理工作流程的不同级别上运行。用户确认提供了一个简单的布尔验证，允许用户在执行之前批准或拒绝特定的操作。这种方法非常适合简单的是/否决定足以提高安全性和准确性的情况。

ROC提供了一种更细致的方法，使用户能够在执行操作之前修改参数并提供额外的上下文。此框架在需要更改代理决策的复杂场景中特别有用。

这两种方法都有助于实现稳健的HITL方法，为代理应用程序提供了一个基本的人工验证层。

用户确认和ROC只是AI代理部署中更广泛的HITL范式的两个方面。在未来的文章中，我们将讨论HITL与代理交互的其他关键用例。

为了开始使用HITL验证创建自己的代理应用程序，我们鼓励您探索本文中讨论的人力资源示例。您可以在我们的GitHub存储库中找到完整的代码和实现细节。