这摘自 https://aws.amazon.com/bedrock/。

Bedrock和大语言模型（LLMs）是城里最火的家伙。我决定试试看用Bedrock代理通过OpenAPI触发API有多简单，Powertools for AWS现在也支持Bedrock了。

这篇帖子将教你如何使用Amazon Bedrock代理和Powertools for AWS以及CDK for Python来自动化通过Lambda函数的API调用。具体来说，我们将使用Powertools for AWS和CDK for Python来进行自动化。我们还会探讨使用Bedrock代理可能遇到的问题和限制。

免责声明：我不是AI方面的专家，所以如果你想了解更多内部工作原理，这可能不是你想找的内容。我将展示如何在5分钟内用您的API来设置Bedrock代理程序的实际代码。

https://www.ranthebuilder.cloud/

这篇博客文章最早发表在我的网站“Ran The Builder”上。“Ran The Builder.”

1. Bedrock简介
2. Bedrock代理
3. 支持AWS Bedrock的Powertools
4. 我们要构建什么
5. 基础设施
6. Lambda函数处理器——Bedrock的Powertools插件
7. 生成OpenAPI文件
8. Bedrock代理的实际操作
9. 限制与陷阱
10. 总结

Amazon Bedrock 是一项完全托管的服务，它提供了来自领先 AI 公司的高性能基础模型（FMs）选项 — https://aws.amazon.com/bedrock/

基石做出了一个大胆的声明。

利用基础模型来创建并扩展生成AI应用是最简单的方法

然而，我能在大约一小时内完成这样一个应用，这充分证明了这一点。不过，我确实得到了帮助；我使用了AWS Powertools Lambda的出色文档和新的支持功能。

在我看来，Bedrock 提供了 API 和代理，帮助您与第三方 LLMs 等进行交互，并根据 LLM 的专长，您可以利用它来完成任何任务——无论是通用助手、音乐创作、文字转图像，还是代表您调用 API。

Bedrock 不需要您部署或管理特定的基础设施（如 VPC 等）。它是一个完全托管的服务，您只需根据使用量付费，但费用可能会很高。其定价模式相当复杂且多变，并会根据您选择的模型和功能有很大不同。

虽然非常受欢迎的功能，如防护措施（干净的语言过滤器、个人身份信息扫描器等），会增加成本，但这些功能是完全由我们管理的。

代理程序使生成式AI应用能够在公司系统和数据源之间执行多步骤任务。

智能助手是你的友好聊天机器人，可以运行多步任务，它们会根据用户的输入调用API。

基岩代理包含几个组件：

1. 模型 — 你为代理选择的大型语言模型（LLM，Large Language Model）。
2. 指令 — 设置代理会话上下文的初始提示。这是一种经典的prompt工程实践，例如：‘你是一名销售代理，为客户提供X的销售’。
3. 行动组 — 你定义代理为用户的动作。提供一个OpenAPI模式以及实现该模式的Lambda函数。
4. 知识库 — 可选。代理查询知识库以获取额外的上下文，以增强响应生成并输入到编排步骤中。

想了解它们的工作方式，可以看看AWS 文档。

https://docs.aws.amazon.com/bedrock/latest/userguide/agents-how.html 了解更多详情。

Bedrock 的代理（简称“代理”）能够理解自由文本，找到正确的 API 并触发，根据 OpenAPI 规范构建请求体，并判断调用是否成功。

最初，我并没有意识到 Bedrock 期望你的 API 可以灵活调整。

通常，我通过API网关来提供我的API，这会触发我的Lambda函数。发送给函数的事件不仅包含API网关的元数据和信息，还包括一个作为JSON编码字符串的主体，使信息更加明确。

当使用代理时，他们不会通过API网关的URL进行交互。他们直接与一个或多个Lambda函数交互，每个函数都提供一个不同的OpenAPI文件。代理直接调用这些函数，发送不同于API网关的请求，并期望得到不同于常规API网关的回复。

Powertools 抽象了这些差异，使开发变得更加简单。我能够将一个在 API Gateway 后面工作的 Lambda 函数，使用 Powertools 提供的 API Gateway 事件处理程序，之后再将事件处理程序类型更改为 Bedrock，它就能正常工作，并且与代理配合得很好。真是太神奇了！

下面是你可以看到的事件流程：

1. 代理使用LLM和用户输入来理解需要调用哪个API（Lambda函数），并使用描述API的OpenAPI文件。
2. Powertools负责解析和验证Bedrock代理输入，并将其路由到正确的内部函数。每个内部函数处理不同的API路由，从而创建一个单体Lambda（如AWS Lambda单体）。
3. 您的自定义业务逻辑运行，然后返回符合OpenAPI模式的响应。
4. Powertools返回一个Bedrock格式的响应，其中包括第3部分的结果。

这带来第一个问题——你不能结合使用Lambda函数、Bedrock代理和API Gateway。你只能选择一个来使用。

这是一个主要问题。这意味着我需要为Bedrock用户和普通客户分别创建不同的API。输入和输出之间的差异太大。真的可惜Bedrock没有扩展API网关模型，增加Bedrock代理的上下文和头部信息。

https://docs.powertools.aws.dev/lambda/python/latest/core/event_handler/bedrock_agents/ （访问更多关于Bedrock Agent的信息）

如果你想看看没有Powertools的TypeScript版本，我非常推荐你看看Lee Gilmore写的文章这篇。

我们将创建一个Bedrock代理来代表卖家。我们将让这个代理为我们处理购买订单。我们将使用我的AWS Lambda Handler Cookbook开源模板项目，该项目代表一个订单服务。您可以通过POST ‘/api/orders’ API下单，并在JSON负载中提供客户姓名和商品数量。订单将通过Lambda函数被保存到DynamoDB表中。

Cookbook模板最近在一篇AWS博文中被介绍。

我调整了模板，并用Bedrock代理程序替换掉了API网关。我们将依次构建以下各部分：

1. 使用CDK基础设施即代码的代理
2. 生成OpenAPI模式定义文件
3. 支持Bedrock的Lambda函数处理代码

所有的代码示例代码都可以在 bedrock 代码库的分支中找到。

我们将从CDK代码着手，部署Lambda函数和代理程序。在这里，“CDK”指的是Cloud Development Kit。

您可以参照 Powertools 的 [文档](https://docs.powertools.aws.dev/lambda/python/latest/core/event_handler/bedrock_agents/#使用 AWS 无服务器应用程序模型 SAM) 使用 SAM 来。

首先，在您的诗文件中加入cdklabs构造。

诗歌依赖项

让我们再来看看 Bedrock（基岩）构造。

此结构几乎与Powertool出色的文档中展示的结构一模一样。

从第18行到第24行，我们创建了Bedrock代理程序。

在第21行中，我们选择要使用的模型。

在第22行，我们在那里提供提示工程的说明。

在第23行中，我们_准备\代理的使用，以便在部署后立即使用和测试该代理。

在第26到38行，我们准备操作组并连接Lambda功能。我们为OpenAPI文件准备输入。在这个例子中，OpenAPI文件位于‘docs/swagger/openapi.json’文件里。

我们来看看实现订单服务API接口的Lambda函数的代码是这样的。

在第17行中，我们初始化Bedrock Powertools事件处理器。默认情况下开启输入验证。

在第27至43行，我们定义了POST /API/orders接口。这些元数据有助于Powertools生成一个OpenAPI文件（请参见下文）。它定义了API描述、输入数据结构、HTTP响应及其响应格式。

在第59到62行，我们定义了函数的入口点。根据输入路径和POST命令，它会将Bedrock代理的请求路由到正确的内部函数。在这个例子中，只有在第20行存在这样的功能。

在第49到53行，我们处理经过Powertools自动验证的输入，并将输入传递给内部逻辑处理器来创建订单并保存订单至数据库。这遵循了六边形架构设计。您可以了解更多相关信息here。

在第56行，我们可以返回一个Pydantic响应对象，而Powertools会为我们处理Bedrock的响应格式。

在这里可以找到完整的代码[https://github.com/ran-isenberg/aws-lambda-handler-cookbook/blob/bedrock2/service/handlers/handle_create_order.py]。

AWS Lambda 的 Powertools（AWS Lambda 的 Powertools）帮助根据代码生成所需的 OpenAPI 文件。

我们来看看下面的简化版

你可以运行这段代码后，把输出文件移到在CDK构造第28行指定的文件夹。

服务部署完成后，我们可以在Bedrock控制台中看到新的代理已经在等我们了。

控制台代理程序

我们来试一下，在控制台里和它聊一聊。

测试代理

成功！它明白我们想要下单的意思；它构建了请求参数，成功执行了Lambda函数，甚至显示了结果。

（打印自Lambda日志）咱们来看看它给那个函数输入了啥。

你可以看到，这与API网关模式非常不同。第9行到第18行的数据负载在第8行包含了关于代理源、API路径以及HTTP请求的所有元数据，而第20行则显示了HTTP请求。

让我们检查成功保存的订单到DynamoDB表中，来验证函数的功能性以及智能代理的准确性。

新增了一项到DynamoDB表

你可以看到，订单编号与代理的回复及输入参数一致。

Powertools的文档和代码示例都非常到位，而且即插即用。

Powertools的表现非常出色。不过，我遇到了几个Bedrock代理的问题：

1. Bedrock代理当前支持OpenAPI模式3.0.0，但不支持3.1.0。我使用的Pydantic 2定义模型时生成了最新版本。我不得不手动将其版本号改为3.0.0，并希望我的API没有使用3.1.0版本的任何特殊功能。幸运的是，它没有使用，但在CloudFormation部署期间（'OpenAPI文件被拒绝'）因为它没有说明我的模式文件为什么不符合要求，所以很难找到错误。Powertool在他们的discord频道上的出色支持帮助了我。感谢Leandro！
2. 您的Lambda函数需要是单体式的，并包含您OpenAPI中的所有路由。另一种选择是创建具有多个OpenAPI文件的多个操作组，这可以实现，但在路由和API数量较多时无法很好地扩展。
3. 这是一个重大问题 — 您不能使用Lambda函数与代理和API网关一起使用。您需要做出选择。这意味着我需要复制API，一个是用于Bedrock的，另一个是用于普通客户的。输入和输出的差异太大。真的很遗憾Bedrock没有扩展API网关模型，以包含Bedrock代理的上下文和头部信息。
4. 我的代理发送了错误的载荷类型。它将载荷标记为整型，但实际发送的是字符串格式的JSON对象。我的API具有严格的验证，因此没有将字符串转换为数字，导致请求失败。我不得不调试这个问题，这比我预期的要复杂。使用不同的LLM时体验可能会有所不同；我选择了“最简单的”一个。

和一个“代理”聊天，聊着聊着一个 DynamoDB 条目就被创建出来了，这真的很神奇。更令人惊讶的是，我竟然这么快就搞定这事儿了。支持 CDK 的托管服务才是未来的趋势！

我希望Bedrock能根据我的反馈做出调整，改善用户体验。当前的实现不允许我在不复制大量代码的情况下将其用于生产环境中的API，这让我感到很困扰。