Agentic antimicrobial resistance surveillance with AWS HealthOmics and Amazon Bedrock AgentCore

基于智能体的抗菌药物耐药性监测：AWS HealthOmics 与 Amazon Bedrock AgentCore | AWS 架构博客

基于智能体的抗菌药物耐药性监测：AWS HealthOmics 与 Amazon Bedrock AgentCore

无需编写生物信息学代码或 SQL，即可将公开的测序数据转化为关于耐药基因的通俗语言答案。

细菌抗菌药物耐药性（AMR）是当今最严重的公共卫生威胁之一。《柳叶刀》上发表的一项系统性分析估计，2019 年 AMR 直接导致 127 万人死亡，并与 495 万人的死亡相关（Murray 等人，2022 年）。监测计划通过追踪耐药基因的传播情况、涉及的生物体以及随时间推移的变化趋势，来减缓这一趋势。

这项工作的原始材料早已公开。NCBI 测序读取档案（SRA）等测序档案库中存储了数十万条细菌全基因组测序记录，这些数据在 AWS 上的开放数据注册表中也有镜像。制约因素不是数据的获取，而是如何将原始测序结果转化为答案。通常的路径包括：组装基因组、使用专用工具筛查耐药基因、将结果加载到分析存储中，并编写 SQL 进行探索。每一步都需要生物信息学技能，因此提出流行病学问题的人往往需要依赖专家来回答。

在本文中，我们介绍了一种缩短这一路径的参考架构。研究人员登录一个 Web 应用程序，提交一个公开的 SRA 访问号，当流水线完成后，用自然语言提问：“沙门氏菌中发现了哪些 AMR 基因？”系统会用检测到的基因、发现每个基因的工具以及从数据中提取的置信度值进行回答。该架构完全通过 AWS 云开发工具包（AWS CDK）定义，并可通过单条命令部署到一个账户中。这是一个演示架构而非临床系统，配套代码可供您部署和调整。

该架构与变异解读的差异

此前的 AWS 博客文章《使用 AWS HealthOmics 和 Amazon Bedrock AgentCore 加速基因组变异解读》建立了一种模式，该解决方案与此共享：基因组流水线将数据写入 Amazon S3 Tables（Amazon Simple Storage Service 的一项功能，采用 Apache Iceberg 格式），Amazon Athena 查询这些表，Amazon Bedrock AgentCore 上的 Strands 代理将问题转换为 SQL。我们复用了这一查询模式，而非重新发明轮子。不同之处在于基因组问题本身以及围绕它的流水线结构。

变异解读解决方案从变异调用格式（VCF）文件开始，其中变异已被调用并进行注释。而该解决方案从更早的阶段开始，从原始测序读取数据出发，执行读取质量控制、从头组装和基因检测，这些步骤在结果存储之前完成。它增加了一个数据摄入阶段，直接从公共存档中提取读取数据，并在不同运行之间去重，同时将检测输出合并到 Iceberg 中，确保重新处理一个分离株时能原地更新其行。这些差异——公共数据摄入、基于组装的检测和幂等存储——构成了该架构的工程重点。

解决方案由一组松耦合的阶段组成，数据从摄入阶段经过处理和存储，单向流动至对话式查询层。以下阶段与图2中的编号区域相对应。

图2：解决方案架构，按数据经过的五个阶段组织

• 数据摄入：Amazon EventBridge 调度器规则或按需REST调用启动AWS Step Functions工作流。AWS Fargate上的Amazon Elastic Container Service（Amazon ECS）任务从Registry of Open Data的NCBI SRA镜像中获取并转换请求的访问号的测序运行，Amazon DynamoDB记录已处理的分离株，使重复运行跳过已完成的工作。

• 基因组处理：AWS HealthOmics运行一个托管的Nextflow工作流，将读取质量控制（fastp）、从头组装（SKESA）和抗性基因检测（AMRFinderPlus）串联处理。容器镜像来自Amazon Elastic Container Registry（Amazon ECR），AMRFinderPlus参考数据库已内置镜像中，因为HealthOmics任务在无互联网连接环境下运行。

• 数据标准化与存储：AWS Lambda函数将检测输出标准化为社区hAMRonization模式（PHA4GE为AMR检测结果报告制定的标准），AWS Glue作业将其合并到Amazon S3上的Iceberg表中。合并操作具有幂等性，因此重新运行分离株会更新现有行而非生成重复数据。

• 分析存储：Amazon Athena通过AWS Glue Data Catalog查询Iceberg表，使代理能够快速访问标准化结果的SQL接口。

• 对话代理与Web应用：托管在AgentCore运行时的Strands代理通过一组Athena支持的工具回答问题，Amazon Bedrock Guardrails确保响应内容准确。Amazon S3和Amazon CloudFront上的React单页应用作为前端入口，通过AWS WAF保护并使用Amazon Cognito进行身份验证。Amazon API Gateway提供REST调用并通过WebSocket流式传输聊天内容。

公共测序数据摄入

数据摄入只有一个目标：给定访问号，无需手动下载或凭据即可将读取数据导入账户。由于SRA镜像属于Registry of Open Data的一部分，匿名Amazon S3读取已足够。Step Functions工作流驱动整个流程，启动Fargate任务从公共存储桶下载访问号的测序运行，并将其转换为配对末端FASTQ格式存储到暂存存储桶，然后传递给基因组处理阶段。

两个设计选择使该阶段更可预测。DynamoDB表记录所有已处理的分离株，因此每周计划运行或重复手动提交不会重复处理相同访问号。Fargate将复制操作作为长期运行任务执行，因为获取和转换大型测序运行可能需要远超几分钟的时间。最终形成一个可在计划时间或通过Web应用按需触发的循环，整个过程无需人工干预。

使用AWS HealthOmics检测抗性基因

将读取数据转换为抗性基因列表是流程中最耗费计算资源的部分。AWS HealthOmics无需配置或扩展集群即可运行Nextflow工作流，这对没有运行自有生物信息学系统的团队来说非常适用。

工作流程是一个 HealthOmics 运行实例，包含三个通过 Nextflow 通道连接的任务。fastp 从原始读取数据中修剪接头和低质量碱基。SKESA 将修剪后的读取数据组装成 contigs。AMRFinderPlus 在这些 contigs 中筛查已知的耐药基因。将组装和筛查整合到一次运行中，可以避免两个独立运行之间脆弱的手动交接，并与社区 AMR 管道的结构保持一致。

在 HealthOmics 上运行第三方生物信息学工具需要一些适应性调整，值得明确说明：

• HealthOmics 任务没有互联网访问权限，因此 AMRFinderPlus 数据库直接构建到容器镜像中，而不是在运行时下载。

• 容器镜像 URI 作为工作流参数传递，而不是硬编码，这使工作流独立于账户和 AWS 区域，并让 HealthOmics 在运行开始前验证镜像访问权限。

• 任务输出发布到 HealthOmics 导出到 Amazon S3 的运行输出路径，而不是任意位置。

每个容器镜像都基于官方工具发布的固定版本构建，并通过 Amazon ECR 镜像扫描进行检查，因此管道不依赖于浮动的最新标签。

协调和存储结果

AMRFinderPlus 每个分离株生成一个制表符分隔的文件，这在分析多个样本时很不方便。一个 Lambda 函数首先将该输出标准化为 hAMRonization 模式。然后，一个 AWS Glue 作业将协调后的数据重塑为 Amazon S3 表上的两个 Iceberg 表：amr_profiles（每行对应一个检测到的基因）和 isolate_metadata（每行对应一个携带其来源和许可证的分离株）。

AWS Glue 作业使用以分离株和基因为键的 MERGE 操作进行写入，因此处理相同分离株两次时会更新现有行而不是追加重复数据。这种幂等性对监测非常重要，因为相同的 accession 可能通过计划运行再次到达，它可以在不进行单独去重步骤的情况下保持表的一致性。将结果存储为 Iceberg 为代理提供了列式、事务性的查询表面，延迟较低。由于 Amazon S3 表在 AWS Glue 数据目录中注册了模式，Athena 可以在不进行额外设置的情况下读取相同表。将每个样本文件转换为结构化存储，使得在整个语料库中进行对话式查询成为可能。

用自然语言提问

对话层使用 Strands Agents SDK，并在 Amazon Bedrock AgentCore 上运行，这是一个用于大规模构建、连接和优化代理的平台，支持任何框架或模型。该解决方案使用 AgentCore 运行时及其无服务器代理托管环境。它为每个用户会话提供隔离的环境，与 AWS 身份和访问管理 (IAM) 集成，并追踪代理的推理和工具调用。团队在不管理服务器或扩展逻辑的情况下运行代理。

代理基于四个工具进行推理，每个工具都将自然语言请求转换为针对 Iceberg 表的定向 Athena 查询：

• query_amr_profiles 在可选的日期范围内查找某个生物体的耐药基因。

• get_resistance_trends 总结基因检测的月度趋势。

• compare_isolates 比较不同分离株的耐药谱。

• lookup_gene_info 返回特定耐药基因的详细信息。

Grounding 在两个地方得到强制执行。系统提示要求代理在每个声明中引用基因 ID、检测工具和置信度值。当没有数据支持答案时，必须明确说明而不是猜测。Amazon Bedrock Guardrails 增加了第二层防护，通过上下文 grounding 检查和禁止主题，确保响应始终与返回的行相关，并避免提供医疗或患者建议。代理使用 Amazon Bedrock 上的 Anthropic Claude Opus 4.7（通过跨区域推理配置文件调用），用于推理和合成这些规则所依赖的逻辑。模型的可用性因 AWS 区域而异。请参阅 Amazon Bedrock 按区域划分的模型支持文档以获取最新可用性信息。

在隔离株处理完成后，研究人员通过对话而非 SQL 探索数据。当被问及“沙门氏菌中发现了哪些 AMR 基因？”时，代理会调用 query_amr_profiles，通过 Athena 从 Iceberg 中检索匹配行，并回复检测到的基因。每个基因都会标注检测工具及其置信度值，以及基因功能的简要说明。后续问题如“请告诉我更多关于 mdsB 的信息”会触发 lookup_gene_info，而无需用户考虑表格或查询。

优势

该架构将四个常见痛点转化为可管理、可重复的步骤。

| 挑战 | 架构如何解决 | |------|--------------| | 手动获取和组装公共测序数据 | Step Functions 工作流从 AWS Open Data SRA 镜像中提取 reads，并在托管的 HealthOmics 计算资源上运行组装和筛查 | | 跨多个样本协调检测结果 | Lambda 函数统一结果，AWS Glue 以幂等方式将结果合并到 Amazon S3 上的 Iceberg 表中 | | 需要 SQL 和生物信息学技能提问 | AgentCore 上的 Strands 代理将自然语言问题转换为 Athena 查询，并通过引用证据进行回答 | | 在其他账户中重现环境 | 解决方案通过 AWS CDK 定义，不包含硬编码标识符，因此可以通过单条命令部署 |

由于这是一个参考架构而非客户部署，其证明价值在于任何人都可以快速搭建。CDK 应用程序会部署此处描述的所有组件，从摄入工作流到 Iceberg 表、代理运行时和网页前端。它不需要硬编码账户标识符或手动设置步骤。运行成本取决于处理的隔离株数量和频率，因为 HealthOmics 运行、AWS Glue 作业和代理调用均按使用次数计费。当处于空闲状态时，架构始终保持低成本。

结论

将 AWS HealthOmics 的托管基因组学处理与 Amazon Bedrock AgentCore 的 grounded 解释相结合，使监测团队能够从公共访问编号直接流畅地获得关于耐药基因的答案。组装、基因检测、协调和存储均无需人工操作，分析层通过对话而非查询控制台实现。该模式复用了早期工作中 S3 表和代理查询方法，并将其应用于不同的基因组学问题。该问题始于原始 reads，依赖于公共数据摄入和幂等存储。

如需深入了解，请查看 AWS HealthOmics 和 Amazon Bedrock AgentCore 产品页面，以及相关文章《使用 AWS HealthOmics 和 Amazon Bedrock AgentCore 加速基因组变异解释》。

该解决方案完全基于 AWS CDK 定义，并部署到您的账户中。在 GitHub 上查看配套的代码仓库，并将该模式应用于您自己的监控和生命科学场景。

About the authors

'