View a markdown version of this page

开始使用 Amazon Bedrock AgentCore Runtime 直接部署代码 - Amazon Bedrock AgentCore

开始使用 Amazon Bedrock AgentCore Runtime 直接部署代码

直接部署代码使您只需将代理代码及其依赖项打包到.zip 文件存档中即可将代理引入 Amazon Bedrock Runt AgentCore ime。您的代理仍然需要遵守AgentCore 运行时要求

要将部署包创建为.zip 文件存档,可以使用 AgentCore CLI 或按照以下特定语言指南中的步骤进行操作,也可以使用任何其他.zip 文件实用工具,例如 7zip。以下各部分中显示的示例假设您在 Linux 或 macOS 环境中使用命令行 zip 工具。要在 Windows 中使用相同的命令,你可以安装适用于 Linux 的 Windows 子系统来获取 Ubuntu 和 Bash 的 Windows-integrated 版本。

请注意, AgentCore Runtime 使用 POSIX 文件权限,因此在创建.zip 文件存档之前,您可能需要为部署包文件夹设置权限

直接代码部署概念

了解在 Amazon Bedrock Runt AgentCore ime 中使用直接代码部署时的关键概念。

主题

    具有直接代码部署功能的 Amazon Bedrock AgentCore Runtime 使用类似于 Lamb AWS da 的分担责任模型。 AgentCore Runtime 管理语言运行时环境并自动应用安全补丁,而您则专注于代理代码和依赖关系。

    如果您使用容器镜像来部署代理,那么 AgentCore Runtime 只负责修补计算内核。在这种情况下,你负责从最新的安全镜像重建代理的容器镜像并重新部署容器镜像。

    下表对此进行了总结:

    Deployment mode (部署模式) AgentCore 运行时的责任 由您负责

    直接部署模式

    发布包含语言运行时最新补丁的新语言运行时版本。将语言运行时补丁应用于现有的 AgentCore Runtime 直接部署。

    更新您的代理代码,包括依赖关系,以解决所有安全漏洞。

    容器映像

    使用最新版本自动修补底层计算操作系统内核。

    更新您的代理代码,包括依赖关系,以解决所有安全漏洞。使用最新的基础映像定期重新构建和重新部署您的容器映像。

    有关与分担责任的更多信息 AWS,请参阅责任共担模型

    AgentCore Runtime 通过安全更新、错误修复、新功能、性能增强以及对次要版本版本的支持,使每个直接代码部署运行时保持最新状态。这些运行时更新作为运行时版本发布。 AgentCore Runtime 通过将代理从较早的运行时版本迁移到新的运行时版本,将直接代码部署运行时更新应用于代理。

    对于直接部署运行 AgentCore 时,运行时会自动应用运行时更新。通过自动运行时更新, AgentCore Runtime 承担了修补运行时版本的操作负担。对于大多数客户来说,这应该是一个安全的选择,因为只有语言运行时补丁会自动应用,并且客户有责任引入和管理其代码依赖关系。目前 AgentCore Runtime 不支持更改这种自动修补行为。

    AgentCore Runtime 努力提供与现有函数向后兼容的运行时更新。但是,与软件修补一样,在极少数情况下,运行时更新会对现有函数产生负面影响。例如,安全性补丁可能会暴露现有函数的潜在问题,而该问题取决于先前的不安全行为。如果在极少数情况下这种风险不可接受,请使用容器镜像部署代理

    比较的一些维度可以了解一个选项与另一个选项有何不同,因此选择正确的选项会有所帮助

    • 部署流程:直接代码部署使用 ZIP 文件而不是容器部署代理,从而可以更快地进行开发迭代。

    • 部署时间:尽管在首次部署代理期间没有太大区别,但通过直接部署代码,代理的后续更新速度要快得多。

    • 自定义:直接代码通过 ZIP-based 打包支持自定义依赖项,同时保持部署的简单性,而基于容器的依赖于 Docker 文件。

    • 软件包大小:直接代码部署将包大小限制为 250MB,而基于容器的软件包大小最多可达 2GB。

    • 会话创建率:直接代码部署允许更高的会话创建 25 个新会话, sessions/second 而基于容器的部署则为 1.6 sessions/second 个新会话。

    我们的总体指导是

    • 如果部署包的大小超过 250MB,并且您有现有的容器 CI/CD 管道,并且需要高度专业化的依赖项和打包,那么基于容器的部署是一个不错的选择。

    • 如果部署包的大小很小,代码和包构建起来并不复杂,并且使用常见的框架和语言,并且需要快速的原型设计和迭代,那么直接部署代码是可以选择的。

    还有一种混合选项,即开发人员使用直接代码部署来快速实验和制作代理原型,然后切换到基于容器的部署(出于上述原因)进行开发、测试和部署到生产环境。