Article · AI translation
在无细胞 DNA（cfDNA）检测领域处于领先地位的 Natera，保持实验室仪器正常运行至关重要，因为设备停机会干扰样本处理。由 Ariel Jirau 领导的 Natera 实验室工程团队与 AWS 合作，构建了 SWARM（Systematic Workflow Analytics and Resolutions Manager，系统化工作流分析与解决方案管理器），这是一个用于实验室运营的智能体式 AI 系统。本文介绍 Natera 团队如何使用 Amazon Bedrock AgentCore 构建这一系统，以大规模捕获和运用机构知识。文章描述了从知识库构建到系统自动部署与评估的完整架构，供您将相同模式应用于自己的运营工作流。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）集成及分布式追踪），无需团队构建和维护定制基础设施。Jirau 说：“我们需要一个托管式运行环境，让我们能够将工程精力集中在诊断准确性上，而不是基础设施的繁杂工作上。AgentCore 满足了这一需求，还提供内置身份管理，并允许我们在不重写智能体逻辑的情况下灵活更换模型。”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：基于 Amazon Bedrock AgentCore 的 Natera SWARM 架构 安全架构 Natera 团队的第一个架构决策是在哪里运行智能体。团队需要一个托管式运行环境，在无需维护定制基础设施的情况下处理容器编排、扩缩容和安全事务。他们选择了 Amazon Bedrock AgentCore 的一项功能 AgentCore Runtime，因为它能在具备内置身份管理和监控的安全托管环境中同时托管 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 运行器向账户中配置的 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 Titan Text Embeddings 在内的 Amazon Bedrock 服务以及 Amazon Bedrock AgentCore 已在多个 AWS 区域提供。有关最新信息，请参阅 Amazon Bedrock 支持的区域和 Amazon Bedrock AgentCore 支持的区域。Natera 团队使用采用 cl100k_base 编码的 tiktoken 分词器来测量分块边界。以下示例说明了这一模式，分块配置采用标准结构：# 文档分块配置 chunk_size = 1000 # 词元 chunk_overlap = 150 # 词元 encoding = tiktoken.get_encoding("cl100k_base") batch_size = 100 # 每次嵌入 API 调用处理的文档数 有关批量导入模式的更多信息，请参阅 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 则着重于深入分析：工程师可以进行交互式追问、上传图像并探索其他路径；Amazon Bedrock AgentCore 的一项功能 AgentCore Memory 会跨会话保留每位工程师的对话上下文。由于 swarm-hive 接受工程师的自由格式输入，提示词会经过 Amazon Bedrock Guardrails 进行内容过滤。事件驱动的 Jira 集成 SWARM 通过 Amazon EventBridge Scheduler 和轮询式 AWS Lambda 函数与 Jira 集成；AWS Lambda 是一种响应事件运行代码的无服务器计算服务，这种方式避免了配置 Webhook。经过验证的工单进入 Amazon SQS 队列，以确保可靠交付。DynamoDB 以工单 ID 为分区键，结合基于生存时间（TTL）的过期机制进行去重，并存储状态、成本和词元用量等每次运行的元数据，为评估循环提供数据。这种从 EventBridge 到 SQS 的模式使智能体运行环境与工单系统的可用性解耦。以下示例说明了这一模式。去重表采用具有 TTL 过期机制的最简模式：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；在这一领域，她指导客户识别影响较大的应用场景并设计智能工作流。