Natera 如何用 Amazon Bedrock AgentCore 构建实验室运维智能体系统 SWARM
How Natera designed an agentic AI system for lab ops with Amazon Bedrock AgentCore
Natera 基于 Amazon Bedrock AgentCore 构建了实验室运维智能体系统 SWARM，将首次响应时间缩短约 130 倍，并对 96.2% 的支持工单实现自动化覆盖。该系统由 swarm-agent 与 swarm-hive 两个运行时共享同一技能库，接入 Jira 与 Confluence，此前团队每天需处理超 65 张工单、平均首次响应 17.4 小时。
在Natera，作为游离DNA（cfDNA）检测领域的领导者，保持实验室仪器持续运行至关重要，因为设备停机中断样本处理。由Ariel Jirau领导的Natera实验室工程团队与AWS合作构建了SWARM（系统化工作流分析与解决管理器），这是一个用于实验室运营的智能体AI系统。
本文介绍Natera团队如何使用Amazon Bedrock AgentCore构建用于实验室运营的智能体AI系统，从而大规模捕获和部署机构知识。文中描述了从知识库构建到自动化系统部署与评估的完整架构，以便您能将相同的模式应用于自己的运营工作流。
SWARM将首次响应时间缩短约130倍，并在支持工单上实现96.2%的自动化覆盖率，使工程师在工单到达的那一刻即可立即获取机构知识。
挑战：知识连续性
Natera的实验室运营依赖跨多个设备系列的各类精密仪器，每种仪器都有各自的故障模式、供应商文档和解决模式。负责维护这一基础设施的服务工程团队围绕深厚的个人专业知识而非标准化操作手册来组织。当一位花费数年诊断特定仪器系列的高级技术员离职时，其所承载的机构知识实际上就丢失了。当时不存在任何系统来大规模捕获、组织或部署这些专业知识。
每天在三个Jira队列中处理超过65张工单，平均首次响应时间为17.4小时，仪器停机延误了实验室样本和患者报告。招聘更多工程师无法跟上节奏。SWARM必须在几分钟内响应，在广泛的设备类型中提供准确的诊断，并通过结构化评估循环持续改进。
Natera为何选择Amazon Bedrock AgentCore
Natera团队选择在Amazon Bedrock AgentCore上构建SWARM，这是AWS提供的一项完全托管、可扩展的服务，旨在大规模构建、部署、连接、保护和运营AI智能体。三个核心需求推动了这一决定：
- 无需人工干预即可自主处理大量支持工单。
- 与Jira和Confluence等现有运营工具深度集成。
- 内置安全性和可观测性（加密、AWS Identity and Access Management（IAM）集成和分布式追踪），无需团队构建和维护自定义基础设施。
“我们需要一个托管运行时，让我们能将工程精力集中在诊断准确性上，而不是基础设施管道上——AgentCore给了我们这一点，还提供了内置身份管理以及无需重写智能体逻辑即可更换模型的灵活性，”Jirau说。
AgentCore提供与多项服务的原生集成，包括完全托管的NoSQL数据库服务Amazon DynamoDB、Amazon Simple Queue Service（Amazon SQS）以及Amazon CloudWatch的一项功能AWS X-Ray。
SWARM如何工作：两个智能体，一个技能库
SWARM使用两个互补的运行时，共享一个技能库。swarm-agent在工程师打开工单之前自主生成结构化诊断报告，而工程师使用swarm-hive进行实时交互、上传图像并探索替代故障排除路径。
“系统不会取代工程师——它让工程师在工单到达的那一刻就能获取完整的机构知识深度，”Jirau 说。
四层架构相互连接：
- 事件层通过 Amazon EventBridge 和 Amazon SQS 路由 Jira 工单。
- 代理层托管 swarm-agent、swarm-hive 和技能库，并将诊断报告回传给工程师。
- 上下文层依托供应商手册、历史工单和运营数据。
- 可观测性与交付层捕获追踪、日志和指标。
图 1：Natera 的 SWARM 在 Amazon Bedrock AgentCore 上的架构
安全架构
Natera 团队的首要架构决策是代理的运行位置。团队需要一个托管运行时来处理容器编排、扩缩容和安全，而无需维护自定义基础设施。他们选择了 AgentCore runtime——Amazon Bedrock AgentCore 的一项能力——因为它能在安全、托管的环境中托管 swarm-agent 和 swarm-hive，并内置身份管理和监控，从而避免构建和运营自定义的代理执行层。无论你选择哪种框架，都可以采用这一模式。
团队选择了无密钥部署模型，因为 SWARM 运行在临床环境中，凭据暴露是不可接受的。OpenID Connect (OIDC) 和 AWS Security Token Service (AWS STS) 生成按部署范围限定的临时凭据，管道中不存在长期密钥。AWS Identity and Access Management (IAM) 在组件级别强制执行最小权限。Amazon Virtual Private Cloud (Amazon VPC) 配合私有子网和 VPC 端点使流量不经过公共互联网。AWS Secrets Manager 以 30 天为周期自动轮换少数存在的凭据。
GitLab CI runner 通过向账户中配置的 IAM 身份提供商出示 OIDC 令牌来向 AWS 进行身份验证。AWS STS 将该令牌交换为限定于部署角色的短期凭据（管道中不存储长期访问密钥）。有关设置详情，请参阅 IAM OIDC 提供商文档。
以下示例说明了该模式：GitLab CI 的 IAM OIDC 信任策略遵循以下结构：
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::ACCOUNT_ID:oidc-provider/gitlab.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"gitlab.com:sub": "project_path:YOUR_PROJECT:ref_type:branch:ref:main"
}
}
}
]
}这些基础设施级安全控制与 SWARM 的数据治理策略协同工作。它们共同构成了在受监管的临床环境中运行 AI 系统所需的完整合规态势。
合规与数据治理
SWARM 在业务伙伴协议（BAA）下运行于符合 HIPAA 要求的 AWS 服务上，这体现了 Natera 作为临床实验室运营商的义务。每次代理调用都会进行审计日志记录（可搜索的记录，满足数据访问可追溯性要求）。任何患者可识别信息都不会接触向量索引或语言模型。工单仅包含设备和流程元数据。在 HIPAA 或类似监管框架下构建的团队应在设计知识库管道之前确认 BAA 覆盖范围和数据分离要求。
知识库与文档管道构建
早期使用通用检索而未结合设备特定元数据的原型产生了不一致的结果，因此 Natera 团队构建了一套针对技术设备文档定制的文档处理流水线。Amazon Titan Text Embeddings 为语义搜索生成向量表示，Amazon Bedrock Knowledge Bases 提供全托管的检索增强生成（RAG），将文档转换为嵌入向量并以每批 100 个的规模存储，这一批量大小是在索引吞吐量与 API 速率限制之间权衡后选定的。对于包含表格和图表的强结构化源文档，投入构建自定义解析流水线而非依赖默认分块方式，会在每一次诊断中叠加准确率收益。
Amazon Bedrock 服务（包括 Amazon Titan Text Embeddings）和 Amazon Bedrock AgentCore 已在多个 AWS 区域推出。如需了解最新信息，请参阅 Amazon Bedrock 支持的区域 和 Amazon Bedrock AgentCore 支持的区域。
Natera 团队使用 tiktoken 分词器及 cl100k_base 编码来测量分块边界。以下示例展示了该模式，分块配置遵循标准结构：
# Document chunking configuration
chunk_size = 1000 # tokens
chunk_overlap = 150 # tokens
encoding = tiktoken.get_encoding("cl100k_base")
batch_size = 100 # documents per embedding API call有关批量摄取模式的更多信息，请参阅 Amazon Bedrock Knowledge Bases 文档。
“诊断准确率首先是一个数据质量问题，”Jirau 说。“为得分最低的仪器系列补充缺失的厂商手册后，准确率从 71% 提升到 75%，且未做任何模型更改。”
这塑造了 Natera 团队的改进方法：当准确率停滞时，团队会先检查数据覆盖情况，再进行模型调优，因为厂商文档的缺失是导致漏诊的最常见原因。该流水线会重新处理新增或更新的文档，并刷新向量索引，而不会中断正在进行的操作。
技能库架构
Natera 团队面临一个关键的架构选择：将逻辑直接嵌入智能体提示词中，还是构建一个独立的、带版本管理的技能库。Natera 选择了技能库方案，因为它使 SWARM 可审计且可改进。
“当诊断出错时，我们需要指向某个具体的技能，而不是调试整个系统——这就是我们一开始就构建带版本管理的技能库的原因，”Jirau 说。
该技能库包含 33 项技能：24 项仪器特定技能，覆盖 Natera 支持的全部设备系列，另有 9 项跨领域工作流技能，广泛适用于各类工单类型。每项技能都有定义的接口，可独立测试，并按照与整个系统相同的标准进行评估，被视为生产软件，而非嵌入的提示词逻辑。
技能架构遵循明确的分工：Python 负责确定性任务，例如解析 Jira 字段或格式化 HTML 报告；而大语言模型（LLM）技能负责语言推理，例如解读症状、匹配厂商文档以及生成诊断叙述。对于构建多技能智能体的团队而言，确定性 Python 技能与由 LLM 驱动的推理技能之间的这种分工，是最具影响力的决策之一。
智能体运行时部署
Natera 将诊断工作拆分为两个独立的运行时，因为自主后台分析与交互式工程协作在延迟和上下文需求上存在根本差异。swarm-agent 专为吞吐量而构建。它根据设备类型和症状选择技能，查询知识库，并生成结构化 HTML 报告，其中包含主要成因假设、按优先级排序的故障排查步骤和置信度标签。报告会传送到 Amazon Simple Storage Service（Amazon S3），并在几分钟内关联到 Jira 工单。swarm-hive 则专为深度而设计：工程师可以进行交互式跟进、上传图片并探索替代路径，AgentCore memory（Amazon Bedrock AgentCore 的一项能力）会跨会话保留每位工程师的对话上下文。
由于 swarm-hive 接受工程师的自由格式输入，提示词会经由 Amazon Bedrock Guardrails 进行内容过滤。
事件驱动的 Jira 集成
SWARM 通过 Amazon EventBridge Scheduler 和轮询式 AWS Lambda 函数（一种响应事件运行代码的无服务器计算服务）与 Jira 集成，从而避免配置 webhook。已验证的工单进入 Amazon SQS 队列以实现可靠投递。DynamoDB 使用工单 ID 作为分区键并基于生存时间（TTL）过期来处理去重，同时存储每次运行的元数据（如状态、成本和 token 用量）以供给评估循环。这种 EventBridge-to-SQS 模式将代理运行时与工单系统的可用性解耦。
以下示例说明了该模式。去重表使用基于 TTL 过期的最小化 schema：
dynamodb.create_table(
TableName='swarm-deduplication',
KeySchema=[
{'AttributeName': 'ticket_id', 'KeyType': 'HASH'}
],
AttributeDefinitions=[
{'AttributeName': 'ticket_id', 'AttributeType': 'S'}
],
TimeToLiveSpecification={
'Enabled': True,
'AttributeName': 'ttl'
}
)可观测性设计
具有许多交互组件的代理式系统如果没有逐次调用追踪，就很难调试，因此 Natera 团队在首次生产部署之前就将可观测性构建到 SWARM 中。如果你在生产环境中运行代理，逐次调用追踪是不可或缺的：没有它，调试糟糕的诊断就意味着要猜测哪个技能出了问题。
在临床实验室环境中，仪器停机直接影响患者报告，因此追踪、告警和审计每个代理操作的能力并非“锦上添花”。这是监管和运营要求。
SWARM 的可观测性技术栈使用 Amazon CloudWatch 为每次运行捕获可搜索日志，提供清晰的运行健康记录。AWS X-Ray 追踪从工单接收到诊断报告的每次运行，记录每次工具调用的时间和成本，使团队在出现缓慢或昂贵问题时能够精确定位具体的技能，而不是靠猜测。Amazon Simple Notification Service 通过电子邮件发送失败告警，而 Slack 跟踪器则为整个团队提供代理活动的实时可见性。
持续评估方法
SWARM 采用持续评估循环，而不是在部署时只测试一次，这对于处理不断变化的文档或不断演进的工作流的系统尤为关键。在处理每一张工单时，智能体都会给出一个主要原因假设、按优先级排序的排查步骤，以及一个自评置信度标签。工程师记录他们发现和修复的问题，评估员则将每个回答评为准确、部分准确或错误，并按仪器类别细分。团队会审查结果，找出智能体表现不佳的环节，实施修复（通常通过更新知识库），然后重新运行评估集以确认改进效果。
SWARM 的自评置信度标签与实际准确率之间呈现出方向性关系。在 154 个已评估案例中，标记为高置信度的工单准确率达到 74%；而中等置信度和低置信度的工单在分别为 78 个和 37 个案例中，准确率均为 65%。需要注意的是，中等置信度和低置信度目前准确率相同。低置信度样本量仅为 37 个案例，不足以得出具有统计意义的结论，Natera 团队预计随着评估数据集扩大，这两个层级会逐渐分化。
高置信度与其余层级之间的区分，为工程师在阅读诊断报告时提供了一个有用的信号，帮助他们判断应对每个诊断给予多大权重。
SWARM 性能
Natera 团队在 524 张支持工单上评估了 SWARM，以建立性能基线。在评估集的 524 张工单中，有 269 张获得了高、中或低置信度标签，并且有相应的工程师验证解决方案可供比较。其余工单要么未标注置信度，要么在分析时缺少已验证的解决方案。
平均首次响应时间从 17.4 小时降至约 8 分钟（约快 130 倍）。这些测量数据来自 90 天生产评估期内 Jira 工单元数据。覆盖率同样重要：96.2% 的工单无需工程师启动诊断流程即可获得自动首次响应。覆盖率按在工程师审核前收到 SWARM 生成诊断报告的传入工单百分比来衡量。
在生产环境中构建智能体 AI 的经验教训
SWARM 中的若干架构决策可直接为构建类似系统的团队提供借鉴。
- 将分块大小和重叠量视为可调参数。合适的取值取决于源文档的结构方式。
- 从一开始就在技能库中构建可追溯性。当诊断出错时，你希望能指向某个具体技能，而不是调试整个系统。
- 如果你的工作负载混合了批处理和交互式查询，请将它们分离到不同的运行时中。
入门
你可以通过 AgentCore 示例仓库、在 AWS 上构建智能体系统 或 Amazon Bedrock AgentCore 入门指南 亲自尝试这些模式，以安全地大规模部署智能体。面临机构知识流失、高流量运营工作流或临床合规要求等类似挑战的医疗健康和生命科学组织会发现，Natera 与 SWARM 共同开发的架构模式为在 AWS 上构建智能体 AI 系统提供了可复制、经过生产验证的基础。
关于作者
Ariel Jirau
Ariel 是 Natera 的首席软件工程师。他负责企业就绪方面的技术实施与基础设施决策，监督 SWARM 的系统架构和生产部署。
Veronica Rule
Veronica 是 AWS 的高级客户解决方案经理，拥有超过 10 年支持医疗保健和生命科学客户上云的经验。她专注于引导组织完成 AI/ML 采用、智能体 AI 战略和云转型计划。她热衷于弥合先进 AI 能力与真实医疗保健和生命科学成果之间的差距。
Tamara Gagliardi
Tamara 是 AWS 的高级解决方案架构师，在技术领域拥有超过 15 年的经验，涵盖金融服务、零售和制造业等多个行业。过去几年，她将专业能力聚焦于医疗保健和生命科学领域，与医疗设备和生物诊断客户紧密合作，加速他们的上云之旅。作为值得信赖的技术顾问，Tamara 帮助组织将复杂的业务挑战转化为可扩展、安全的技术解决方案，尤其侧重于生成式 AI，指导客户识别高影响力用例并设计智能工作流。
来源：AWS Machine Learning Blog · aws.amazon.com