Natera实验室工程负责人Ariel Jirau：诊断准确率停滞时，先检查数据覆盖而非调模型

Natera是一家专注无细胞DNA检测的临床实验室公司，其实验室运营依赖大量精密仪器，每台设备都有各自的故障模式、供应商文档和解决路径。负责维护这些基础设施的服务工程团队长期围绕个人深度专长组织，而非标准化操作手册。当一位资深技师离职时，他多年积累的诊断知识随之消失——没有系统能够捕获、组织或规模化部署这些经验。每天超过65张工单、平均17.4小时的首次响应时间，意味着仪器停机直接延迟样本处理和患者报告。

Natera实验室工程负责人Ariel Jirau带领团队与AWS合作构建了SWARM系统。在回顾这个项目的架构决策时，Jirau给出了一个对从业者颇具启发的判断：诊断准确率本质上首先是数据质量问题。团队发现，当准确率进入平台期时，最常见的原因不是模型能力不足，而是知识库中缺少特定仪器家族的供应商手册。为得分最低的仪器家族补充缺失文档后，准确率从71%升至75%，而模型本身没有任何改动。

这个判断背后是一套具体的架构选择。SWARM的核心组件是一个包含33项技能的版本化技能库：24项仪器专属技能覆盖Natera支持的全部设备家族，另外9项跨领域工作流技能适用于所有工单类型。每项技能都有明确接口、可独立测试，并按与整体系统相同的标准进行评审——被当作生产软件对待，而非嵌入提示词中的逻辑片段。Jirau解释这一选择的原因：当诊断出错时，团队需要指向一个具体技能来定位问题，而不是调试整个系统。

技能库内部遵循一条清晰的分工线：Python处理确定性任务，例如解析Jira字段或格式化HTML报告；大语言模型技能处理语言推理，例如解读症状描述、匹配供应商文档、生成诊断叙述。这条分界线本身是Jirau认为构建多技能代理时影响最大的决策之一——它决定了哪些环节可以被精确测试和审计，哪些环节必然带有概率性。

SWARM将诊断工作拆分为两个独立运行时，共享同一个技能库。swarm-agent面向吞吐量设计：它根据设备类型和症状选择技能、查询知识库，生成包含首要原因假设、排序后的排查步骤和自评置信度标签的结构化HTML报告，在几分钟内交付到工单中。swarm-hive面向深度设计：工程师可以交互式追问、上传图片、探索替代排查路径，AgentCore记忆功能保留每位工程师的跨会话上下文。这种分离的理由是自主后台分析和交互式工程协作对延迟和上下文的需求根本不同。

持续评估机制是这套架构能够运转的闭环。每张工单处理后，工程师记录实际发现和修复内容，评估者将代理回复按仪器家族分级为准确、部分准确或错误。结果被审阅以定位代理表现不佳的环节，修复通常通过更新知识库完成，然后重跑评估集确认改进。在524张工单的评估中，269张有对应的工程师验证结果可供比较。高置信度标签的工单在154个案例中达到74%准确率，中等和低置信度在78和37个案例中均为65%——但低置信度样本量太小，尚不足以得出统计结论。

需要指出的是，这些性能数据来自Natera自报并由AWS平台发布，评估期为90天生产运行，覆盖524张工单。文章未披露同期工单总量变化、是否存在选择效应（复杂事件是否仍依赖人工介入），也未提供迁移前后的对照实验设计。74%的高置信度准确率意味着即使代理最有把握的诊断，仍有约四分之一的案例需要工程师独立验证。

对正在构建agentic系统的团队而言，SWARM案例中最可迁移的认识有两点。第一，将技能视为版本化生产软件而非提示词逻辑，使系统在出错时可审计、可局部修复。第二，当准确率停滞时，优先检查数据覆盖而非调整模型——团队发现，供应商文档缺口是漏诊最常见的原因，因此将数据覆盖检查置于模型调优之前。Jirau的原话概括了这个优先级：诊断准确率是数据质量问题在先。