Natera用Bedrock AgentCore构建实验室运维智能体

摘要：Natera 与 AWS 联合推出实验室运维智能体 SWARM，以 Amazon Bedrock AgentCore 运行两套智能体运行时：swarm-agent 面向批量工单自动诊断，swarm-hive 服务工程师交互式排障。系统通过版本化技能库、设备级 RAG 知识库、事件驱动 Jira 集成及逐次调用追踪，把平均首次响应从 17.4 小时降至约 8 分钟，96.2% 的工单获得自动首响。524 张工单评测显示，高置信度答案准确率为 74%，但诊断正确率和低置信度样本规模仍不足以证明完全自动化。

---

Natera 已将实验室运维智能体 SWARM（Systematic Workflow Analytics and Resolutions Manager） 部署到 Amazon Bedrock AgentCore。系统不把设备排障完全交给模型，而是将 33 个可测试技能、设备知识检索、人工交互和逐次审计组合成双运行时架构，在约 90 天生产评测中把平均首次响应从 17.4 小时压到约 8 分钟，96.2% 的工单在工程师介入前收到自动诊断报告。

双运行时拆分吞吐与交互

SWARM 将同一种运维任务拆成两个执行路径：

• swarm-agent：面向后台批处理。它根据设备类型和故障症状选择技能，查询知识库，生成包含首要原因假设、排序后的排障步骤和置信度标签的 HTML 报告。报告写入 S3 后链接回 Jira 工单。
• swarm-hive：面向工程师实时协作。支持自由文本、图片上传和替代排障路径，并通过 AgentCore Memory 保存按工程师隔离的跨会话上下文。

这一拆分针对两类截然不同的约束。自动化路径需要高并发、低单位成本和可预测的结构化输出；交互路径则更看重长上下文、工具反馈和人工接管。强行合并成一个智能体，通常意味着批量任务被交互式状态管理拖累，或人工会话被批处理模板限制。

工程上的代价是两个运行面需要共同维护技能接口、权限模型和评测集，但换来更清晰的故障定位与更独立的伸缩策略。

四层架构与事件驱动接入

整体架构分为四层：

1. 事件层：Jira 工单经 EventBridge Scheduler 和 Lambda 轮询进入 SQS。
2. 智能体层：运行 swarm-agent、swarm-hive 及共享技能库。
3. 上下文层：汇集厂商手册、历史工单与设备运行数据。
4. 可观测性与交付层：记录日志、追踪和指标，并把诊断报告写回工单。

Jira 与智能体之间没有直接同步耦合。EventBridge、SQS 和 Lambda 承接接入，DynamoDB 以 ticket ID 为分区键执行去重，并保存状态、成本、Token 用量等运行元数据；TTL 用于清理过期记录。这样，即使 Jira 暂时不可用，任务仍可由队列可靠承载。不过，该架构也会引入重复投递、状态机和死信队列方面的额外复杂度，原文没有披露端到端失败率或重试成本。

版本化技能库如何约束模型行为

Natera 没有把全部排障逻辑塞进 Prompt，而是建立了包含 33 个技能的独立库：24 个针对特定仪器系列，9 个覆盖跨设备工作流。每个技能都有明确接口，可以单独测试，也能以统一标准参与回归评测。

技能内部进一步采用确定性代码与模型推理分工：

• Python 负责解析 Jira 字段、格式化 HTML、执行结构化数据处理等确定性任务。
• LLM 负责理解症状、匹配文档、生成诊断假设和自然语言解释。

这不是“代码比模型更先进”，而是把可验证的变换留在代码中，把真正需要语义归纳的部分交给模型。版本化还让错误归因从“调优整个 Prompt”变成“定位并修复某个技能”，代价是技能接口、依赖关系和组合测试都需要长期维护。

设备级 RAG：分块只是起点

SWARM 使用 Amazon Titan Text Embeddings 和 Bedrock Knowledge Bases 构建 RAG 管线。示例配置采用 1,000 Token 分块、150 Token 重叠，并以 100 份文档为一批调用嵌入 API，以平衡索引吞吐和服务端速率限制。Natera 还使用 cl100k_base tokenizer 测量边界。

不过，真正影响诊断质量的不是默认分块参数，而是文档解析。通用检索原型在设备识别和故障上下文上表现不稳定，因此团队为含表格、示意图的厂商手册构建了自定义解析流程。缺失手册也能直接拖低结果：补齐表现最差的设备系列资料后，准确率从 71% 提升至 75%，期间没有调整模型。

这说明 RAG 的上限首先由语料覆盖率与结构保真度决定，而不是一味扩大模型或增加检索轮数。其代价是结构化解析器、更新管道和逐设备回归测试的长期维护成本，而且文中的文档批次设置与准确率增益不能直接推导为通用最佳参数。

安全与合规边界

临床环境中的关键约束是不能依赖长期静态密钥。SWARM 使用 GitLab CI OIDC 与 AWS STS 获取按部署角色授权的短期凭证，IAM 实施最小权限，VPC 私有子网和 VPC Endpoint 避免流量经过公网，Secrets Manager 对少量残留凭证执行 30 天轮换。

系统运行于 HIPAA 适用的 AWS 服务之上，每次智能体调用都会留下可检索审计记录。文章称，患者可识别信息不会进入向量索引或语言模型，工单只包含设备和流程元数据。这项边界比笼统的“数据已匿名化”更具体，但实际部署仍需验证元数据是否可能间接重新识别患者，以及模型服务调用链是否全部落入约定的 BAA 范围。

可观测性与持续评测

CloudWatch 保存每次运行日志，X-Ray 记录从工单接入到报告生成的完整链路，并跟踪每次工具调用的时间和成本。SNS 与 Slack 提供失败通知。生产智能体如果只有最终答案而没有逐次 Trace，错误诊断只能靠猜测；按调用追踪也是临床审计和成本控制的基础设施，而非附加功能。

评测闭环以工程师实际发现和修复的结果为标签，将每次回答标记为 Accurate、Partial 或 Wrong，并按仪器系列聚合。269 张带有工程师核验结果的工单中：

• High Confidence：154 例，准确率 74%；
• Moderate Confidence：78 例，准确率 65%；
• Low Confidence：37 例，准确率 65%。

高置信度确实提供了有限的风险分层信号，但 Low Confidence 只有 37 例，无法据此证明中、低置信度应合并或继续区分。另一个限制是模型自报置信度并非校准概率，不能直接当作“74% 正确率”的个体承诺。

指标应如何解读

524 张工单构成了总体评测集，其中269 张具有置信度标签和可核验解决结果；其余工单被标记为无置信度，或在分析时尚无可核验结果。96.2% 衡量的是“工程师开始诊断前是否生成报告”，不是诊断正确率。

首次响应从 17.4 小时降到约 8 分钟，约等于 130 倍加速，主要价值是把隐性的专家知识提前暴露给值班工程师。它可以减少等待和重复收集信息，但不等于完全无人值守：报告仍需验证，涉及高风险设备决策时也不应自动执行。

落地建议

对类似工业运维、医疗检验或现场服务团队，这套案例提供四个可直接复用的工程原则：

• 先修知识覆盖，再调模型：按设备系列定位缺失文档，常比扩大模型更有效。
• 把确定性工作移出 Prompt：解析、格式化和校验由代码完成，模型负责语义推理。
• 分开批处理与交互运行时：避免用一种上下文模型承担完全不同的延迟和并发需求。
• 从第一天建立追踪和评测：记录知识来源、技能选择、Token、成本与工程师最终修复结果，否则无法建立可信回归。

落地时应额外压测队列积压、重复投递、故障恢复、单次调用成本和并发隔离，并按设备系列报告准确率及置信区间。只有把响应速度、覆盖率、诊断正确率和人工接管率放在同一张运营看板中，才能判断智能体是否真正改善了设备可用性，而不是只把问题更早地交给工程师。

---

消息来源：AWS Machine Learning Blog (2026-11-12)

—— 完 ——

主题标签： #Natera SWARM 关注 #Amazon Bedrock AgentCore 关注 #智能体运维 关注 #RAG 关注 #临床实验室 关注