作者：来自 Elastic Fredrick Kioko Elasticsearch Agent Builder Hackathon

在肯尼亚许多县级卫生部门中，监测与评估（M&E）人员可能会花上一整天运行 Excel 数据透视表、人工比对患者姓名、交叉核对样本 ID，但仍然只能识别大约 44% 的重复记录。剩下的 56% 会悄无声息地留在系统中，抬高美国总统艾滋病紧急救援计划（PEPFAR）仪表板的数据、浪费试剂，并削弱临床医生在治疗决策中所依赖的数据可信度。

我之所以知道这些，是因为我就在一线工作。我是一家位于内罗毕的 HealthTech 公司解决方案架构师。我们构建并维护部署在肯尼亚全部 47 个县的健康信息系统。患者重复记录这种问题，从来不会出现在汇报 PPT 里，但每一个一线工作人员都深有体会。

当 Elasticsearch Agent Builder Hackathon 宣布时，我甚至不需要去寻找问题——问题早就摆在我的桌面上好几个月了。

重复是如何产生的（以及为什么很难发现）

肯尼亚的 HIV 检测体系运行着两类关键实验室检测：用于 HIV 暴露婴儿的早期婴儿诊断（EID），以及用于正在接受抗逆转录病毒治疗（ART）成人的病毒载量（VL）监测。这些检测在 KenyaEMR 中开单，在实验室中处理，结果再通过肯尼亚的健康信息交换系统回传。

重复记录的产生场景既不 “戏剧化”，也非常昂贵 —— 一位母亲带着婴儿去 A 机构就诊，然后在 B 机构用略微不同的姓名再次检测；一位跨县流动的 ART 患者被重新注册；有人故意使用不一致的人口信息在多个站点获取服务。

每一种情况都会生成一个 “幽灵记录”。当这种情况在 500 多个医疗机构中累积时，数字就变得可观：每年大约造成 195,000 美元的重复检测、试剂浪费以及被放大的统计报表。人工检测每个案例大约需要两小时，在这种速度下，积压只会不断增长。

我希望构建一个系统，可以在几秒钟内扫描 1,000 条记录，并用医疗工作者能够理解并据此行动的语言解释其推理过程。

系统：3 个各司其职的 agent

我基于 Elasticsearch 8.11（Serverless）和 Elastic Agent Builder 构建了一个多 agent 系统，推理模型使用 Claude Sonnet 3.7。与其让一个单体 agent 试图完成所有任务，我将工作拆分为三个 agent —— 检测 agent、风险评估 agent 和行动推荐 agent。每个 agent 都有明确的职责范围、输入定义和输出格式。

检测 agent

检测 agent 在患者索引上运行 ES|QL 查询，从三个角度识别重复记录：跨机构模式匹配（同一患者出现在多个机构）、人口统计分析（例如姓名变体、性别标识不一致以及部分 ID 匹配）以及时间异常检测（例如同一天在距离较远的机构进行检测）。这是搜索层，它只负责提出候选，不做最终判断。

风险评估 agent

风险评估 agent 对这些候选进行打分，范围为 0–100，并使用加权信号：

• 跨机构就诊：最高 40 分
• 人口信息不一致：最高 30 分
• 地理不可能性：最高 20 分
• 时间异常：最高 10 分

案例被划分为四个等级：CRITICAL、HIGH、MEDIUM 或 LOW。稍后我会解释为什么没有使用二分类。

行动推荐 agent

行动推荐 agent 将评分转化为具体行动步骤，并根据肯尼亚医疗场景进行调整：CRITICAL 案例需要 M&E 官员立即复核，MEDIUM 案例在下一次机构访问时标记，而对于显示系统性模式的机构则建议进行员工培训。这个 agent 的存在是因为仅有风险分数对医疗工作者并没有意义，他们需要知道下一步该做什么。

为什么我使用多因素评分而不是二分类

在最初构建系统时，我也尝试过一个更简单的方法：重复或非重复。但它在真实数据面前很快就失效了。

问题在于，合法的随访检测和重复记录在行为上非常相似。正在接受 ART 治疗的患者本来就需要每隔几个月在同一家机构复诊；婴儿也可能需要多次检测。二分类会要么把大量正常就诊误判为重复（导致医疗人员逐渐忽略所有告警），要么遗漏那些细微但关键的情况 —— 例如同一天在不同机构、使用略微不同姓名进行检测的人。

分层评分的方法让医疗人员可以进行优先级排序。一个风险分数为 87 的 CRITICAL 案例（同一天检测、不同机构、性别信息不一致）会立即被处理；一个分数为 22 的 LOW 案例（同一机构、符合预期随访周期）则会归档。最终仍由 M&E 官员做判断，但他们是在证据基础上工作，而不是依赖直觉。

这些权重的校准需要在真实数据上进行多轮迭代。我仍然不能完全确定它们是最优的，但整体结构是正确的，而且随着更多现场数据的积累，这些权重是可以继续优化的。

Elasticsearch 帮助实现这一切的部分

我在整个系统中花在索引设计上的时间，比任何其他部分都要多，而这是我做过最值得的投入。

索引 mapping 包含在索引时计算的派生字段：cross_facility_flag、total_tests，以及每个患者的 facility_count。关键的人口统计字段同时包含 keyword（精确匹配）和 text（分词、模糊搜索）子字段，这样 detection agent 可以根据它正在寻找的信号在严格匹配和模糊匹配之间切换 —— 例如对 sample ID 使用严格匹配，而对患者姓名（比如 “Wanjiku” 和 “Wanjiku Mary” 可能是同一个人）使用模糊匹配。

我还大量使用 Elasticsearch aggregations 做候选预过滤。系统会先按机构、检测类型和时间范围进行分桶，然后再进行成对比较。这一步让大规模数据上的检测变得可控。如果你能先缩小候选空间，就不需要让每条记录和所有其他记录逐一比较。

ES|QL 对我来说是新的。我是在 hackathon 期间才开始学习的，但它在大规模实时分析上非常强大。最终最有效的架构是：用 ES|QL 做模式检测和聚合，用 Python 处理应用逻辑。考虑到我也是新手，这种分层让整个系统更容易理解。

agents 实际发现了什么

我在 1,010 条来自肯尼亚 59 个医疗机构的匿名患者记录上测试了这个系统。扫描在 10 秒内完成。

系统识别出 131 个重复患者案例，包括 5 起同一天跨机构检测，以及 4 个在不同机构使用不一致性别标识的患者。

同一天跨机构的案例最让我惊讶。人工审核最终可以通过姓名重复发现一些案例，但要发现“同一个患者在同一天、在地理上相距较远的两个机构检测，并且人口信息略有差异”的模式，是一种只有在你专门去找时才会显现的隐性结构。M&E 官员告诉我，如果没有系统，这些案例可能需要几周甚至更久才能被发现。

我没想到的一个关键结论：可解释性就是产品本身

早期原型只返回风险分数和建议。我把它展示给 M&E 官员，但他们并不信任结果。

这不是技术失败 —— 评分本身是准确的。但在医疗环境中，一个被标记的患者记录，必须先让使用者理解“为什么被标记”，他们才会采取行动。如果没有上下文，它就是一个黑盒，而黑盒在临床环境中往往会被忽略。

让 action recommender 输出带证据引用的具体解释，是这个原型真正变成可用系统的关键。内罗毕的一位 M&E 官员在演示后说：“这能帮我省下上周的三天工作。”

这个经验并不只属于医疗领域：如果你的 AI 系统需要人去采取行动，那么“解释”本身就是产品的一部分。

如何写好 agent 指令

每个 agent 都是在 Elastic Agent Builder 中构建的，并配有自定义 instructions，用于定义其领域知识、推理步骤和输出格式。我低估了这些指令的重要性。

早期版本由于指令过于模糊，输出非常不稳定。detection agent 有时会解释推理，有时不会；risk assessor 有时会跳过某些评分因素。要获得可靠、基于证据的输出，必须明确要求证据字段，并清晰定义推理链条。自定义指令应该像代码一样对待：要精确、要测试边界情况、要持续迭代。

下一步是什么？

这不是一个会被归档的 hackathon demo。接下来的计划是在未来 2–3 个月内在内罗毕的 5 个县级医疗机构进行试点，培训 M&E 官员，并收集真实世界数据来优化风险权重。

之后的路线图包括生物特征匹配集成，以及斯瓦希里语发音级别的姓名模糊匹配（这是当前系统中的一个真实缺口——“Wanjiku” 和 “Wanjiku” 很容易处理，但 “Njeri” 和 “Njery” 需要语音感知能力，而标准模糊匹配无法覆盖）。

更长期的目标，是在患者注册阶段就实时运行这个系统，在 HMIS 中就捕捉重复记录，而不是事后处理。

再往后，希望将系统接入肯尼亚国家级 Health Information Exchange，扩展到全部 47 个县。Elasticsearch 的水平扩展能力和模块化 agent 设计意味着核心系统不需要重写，只需要扩展。全国规模下的预期影响是：每年节省约 195,000 美元，并减少 70% 的重复检测。更重要的是，临床医生在做治疗决策时可以信任他们看到的数据。

总结

如果你在一个数据质量是“隐性但昂贵的人力问题”的领域工作，Elastic Agent Builder 让你可以构建的不只是查询工具，而是能够解释问题的系统——结合 ES|QL 做模式检测、多 agent 编排做分层分析，以及自定义 instructions 做领域推理。整个系统比我预期的更快成型。

这个项目最令人满意的部分不是部署成功，而是看到一个每天做这项工作的人，在十秒内意识到：这个工具真的理解了他们的问题。

Fredrick Kioko

解决方案架构师，

Fredrick Kioko 是一名位于肯尼亚内罗毕的解决方案架构师，致力于构建健康信息系统，并推动 Jamii Health Innovations 的启动。

GitHub · 演示· LinkedIn

本文中所描述的任何功能或特性的发布与时间安排，均由 Elastic 全权决定。任何当前尚不可用的功能或特性，可能无法按时交付，甚至可能不会发布。

在本文中，我们可能使用或提及了第三方生成式 AI 工具，这些工具由各自的所有者拥有并运营。Elastic 不控制这些第三方工具，对其内容、运行或使用不承担任何责任或法律义务，也不对因使用这些工具而可能产生的任何损失或损害负责。请在使用 AI 工具处理个人、敏感或机密信息时保持谨慎。你提交的任何数据可能会被用于 AI 训练或其他用途，无法保证你提供的信息会被安全或保密地存储或处理。在使用任何生成式 AI 工具之前，你应当了解其隐私政策与使用条款。

Elastic、Elasticsearch 以及相关标识均为 elasticsearch B.V. 在美国及其他国家/地区的商标、标志或注册商标。所有其他公司与产品名称均为其各自所有者的商标、标志或注册商标。

原文：https://www.elastic.co/blog/agent-builder-hackathon-catching-invisible-errors