基于AWS HealthOmics与Amazon Bedrock AgentCore的智能体抗菌耐药性监测
内容提要
AWS推出基于HealthOmics与Bedrock AgentCore的抗菌耐药性监测架构。用户输入公共SRA编号后，系统自动完成质控、组装和耐药基因检测，结果标准化存入Iceberg表，再由AI代理以自然语言回答查询并附检测工具与置信度。方案通过CDK一键部署，无需生物信息学或SQL技能。
延伸解读
从原始测序数据到答案的自动化路径
传统抗菌耐药监测需手动下载公共测序数据、组装基因组、检测耐药基因并编写SQL查询，依赖生物信息学专家。该架构通过Step Functions工作流自动从SRA镜像获取数据，在HealthOmics上运行Nextflow流程完成质控、组装和基因检测，再经Lambda标准化和Glue作业存入Iceberg表，最终由AI代理以自然语言回答。这消除了对专业技能的依赖，让流行病学家能直接提问。
与变异解读方案的关键差异
该方案与AWS早前的变异解读方案共享S3 Tables、Athena和AgentCore查询模式，但起点不同：变异解读从已调用变异的VCF文件开始，而本方案从原始测序读段开始，增加了公共数据摄取、从头组装和幂等存储。这些差异意味着工程重点在于处理公共数据源、组装流程和确保重复处理不产生冗余数据，而非变异注释。
幂等存储对监测场景的重要性
监测中同一菌株的测序数据可能通过定期任务或手动提交重复到达。该架构通过DynamoDB记录已处理菌株避免重复计算，并在Glue作业中使用MERGE按菌株和基因键更新Iceberg表，确保重复处理时更新现有行而非追加重复。这保持了数据一致性，无需额外去重步骤，对长期趋势分析至关重要。
自然语言查询的接地与限制
AI代理通过四个工具将自然语言转为Athena查询，回答时强制引用基因ID、检测工具和置信度，并在无数据支持时明确说明。Bedrock Guardrails提供第二层保护，拒绝医疗建议。但需注意，这是演示架构而非临床系统，模型可用性因区域而异，运行成本取决于处理量和频率。
Q&A
这个抗菌耐药性监测方案能解决哪些实际问题？
该方案将公共测序数据转化为关于耐药基因的通俗语言答案，无需编写生物信息学代码或SQL。它解决了四个痛点：手动获取和组装公共测序数据、跨样本协调检测输出、需要SQL和生物信息学技能才能提问、以及在其他账户中复现环境。
用户如何用自然语言查询耐药基因信息？
用户通过Web应用提交公共SRA编号，流水线完成后，可以用自然语言提问，例如“在沙门氏菌中发现了哪些AMR基因？”。系统会回答检测到的基因、发现每个基因的工具以及来自数据的置信度值。
这个架构与之前的变异解读方案有什么不同？
变异解读方案从VCF文件开始，注释已调用的变异；本方案从原始测序读段开始，执行读段质控、从头组装和基因检测，然后才存储结果。它增加了从公共档案直接拉取读段并去重的摄取阶段，并以幂等方式将检测输出合并到Iceberg表中。
基因组处理阶段使用了哪些工具？
AWS HealthOmics运行一个托管的Nextflow工作流，依次使用fastp进行读段质控、SKESA进行从头组装、AMRFinderPlus进行耐药基因检测。容器镜像来自Amazon ECR，AMRFinderPlus参考数据库内置于镜像中，因为HealthOmics任务无互联网访问。
检测结果如何存储和查询？
Lambda函数将AMRFinderPlus输出标准化为hAMRonization模式，然后AWS Glue作业以幂等方式合并到Amazon S3 Tables上的Iceberg表中，分为amr_profiles和isolate_metadata两个表。Amazon Athena通过AWS Glue Data Catalog查询这些表，为代理提供快速SQL接口。
对话代理如何确保回答的可靠性？
系统提示要求代理为每个声明引用基因ID、检测工具和置信度值，并在无数据支持时明确说明而非猜测。Amazon Bedrock Guardrails添加了上下文接地检查和拒绝主题，确保响应与返回的行相关，并避免医疗或患者建议。
部署这个架构需要什么条件？
架构完全用AWS CDK定义，无需硬编码账户标识符或手动设置步骤，可通过单个命令部署到账户中。运行成本取决于处理的分离株数量和频率，因为HealthOmics运行、AWS Glue作业和代理调用按使用计费，空闲时成本很低。
