作者来自 Elastic Alec Carpenter了解当飓风来袭时Kibana 检测规则、工作流以及 AI 智能体如何自动协同在无需调度员介入的情况下将分布在七个基地的 13.7 万名人员完成重新部署与转移。Agent Builder 现已正式发布。立即开始你的 Elastic Cloud 试用并查看 Agent Builder 文档。Elastic 刚刚完成了一次自动化协调行动在没有任何人工参与决策的情况下自动完成了 13.7 万名人员在七个基地之间的疏散与重新部署。一场四级飓风袭击 Hampton Roads 海岸线。Elasticsearch 的地理空间富化功能在索引阶段识别出处于影响区域内的所有设施。Kibana 检测规则被触发。一个工作流启动与 AI 智能体的对话。智能体基于容量、距离以及军种兼容性进行推理然后一次性发出 16 份疏散和接收通知。从原始 GDACS 事件到协调行动全程自动完成。每年自然灾害都会迫使应急管理人员、指挥官和公共安全官员在极短时间内做出高风险决策。传统上这些决策依赖于电话通知链、电子表格以及分散在数十人之间的机构知识。仅协调过程本身就会消耗宝贵时间。本文展示了 Elastic 如何构建一个响应式、智能体驱动的灾害响应协调系统。该系统能够自动检测威胁、推理物流方案并自动执行行动。为了使示例更加具体我们构建了一个模拟场景一场虚构的四级飓风威胁 Hampton Roads 海岸线触发了超过 13.7 万名人员在七个基地之间的自动迁移与重新部署。免责声明本案例完全是为了演示目的而构建的虚构场景。飓风 ELARA-26 并不存在。基地位置基于公开可获取的真实地理数据美国国防部设施、靶场与训练区域 MIRTA 数据集但所有运营数据包括人员数量、住宿容量、资产情况、联系邮箱以及任务配置文件等均为虚构内容。本演示中的任何内容均不代表真实的战备状态、能力水平或实际作战程序。为什么自动化灾害响应需要地理空间能力与智能体协同当自然灾害威胁关键基础设施时协调挑战会立即出现哪些设施位于受影响区域有多少人员需要转移他们应该转移到哪里这些设施是否有足够容量哪些人需要立即收到通知这些问题不会等待。答案也不应该等待。部署流水线前置条件与环境搭建请按照示例仓库中的说明通过 Cloud Connect 部署一个启用了 Elastic Inference ServiceEIS的本地 Elastic 集群。Elasticsearch 智能体驱动灾害响应流水线如何工作整个流水线由七个层级组成它们端到端协同工作数据摄取将全球灾害预警与协调系统GDACS的灾害事件发送到 Elasticsearch。摄取流水线将 GeoJSON 数据摄取并标准化为 Elastic 通用模式ECS。地理空间富化将事件受影响区域的多边形与已索引的基地边界进行匹配。告警当灾害区域与任意基地发生空间相交时Kibana 检测规则被触发。工作流自动化告警触发 Kibana 工作流并启动 AI 智能体会话。AI 推理智能体根据受影响设施、其资产情况以及最近的支援设施进行推理确定所有资产和人员的重新部署方案。电子邮件通知智能体向所有相关接收人发送电子邮件包括人员和资产的迁出方与接收方。下面我们逐层进行介绍。第一步使用地理边界索引基地整个方案的基础是来自 source.coop/seerai/hifld 的 DoD MIRTA国防部设施、靶场与训练区域数据集。该数据集为每个基地提供一个geo_shape字段其类型为Point表示基地的质心坐标而非完整的边界多边形。在mitra-facilities索引中每个基地文档都会进一步补充运营画像数据全部为虚构数据这些内容超出了 MIRTA 原始数据集所提供的信息{ entity_name: Naval Station Norfolk, branch_of_service: Navy, mission_function_type: fleet_support, personnel_count: 50000, housing_capacity: 55000, temporary_housing_capacity: 10000, logistics_capabilities: [fuel, airlift, sealift, medical], available_assets: [ { type: helicopters, count: 24 }, { type: transport_vehicles, count: 150 } ], contact_email: norfolk.opsnavy.mil.gov.fake, operational_status: act, is_joint_base: false, entity_geo_location: { type: polygon, coordinates: [...] } }这种丰富的索引结构使 AI 智能体能够做出智能化资源分配决策。它不仅能够回答“附近有哪些基地”还能够进一步回答“哪些基地拥有可用住宿容量、兼容的任务类型以及接收新增人员和资产所需的后勤保障能力。”第二步摄取并标准化 GDACS 事件GDACS 会发布地震、热带气旋、洪水、野火、火山喷发和干旱等灾害的实时 GeoJSON 数据。我们使用自定义摄取流水线将这些数据导入数据流logs-gdacs.events-*并将原始 GeoJSON 标准化为 ECS 字段。GDACS 摄取流水线中有几个值得关注的处理步骤几何信息提取事件中心点被存储为geo_point用于地图展示。影响区域多边形被存储为gdacs.affected_area中的geo_shape字段。后续的空间相交查询正是基于这个字段完成的。严重程度标准化不同灾害类型使用不同的严重程度衡量标准热带气旋使用风速km/h衡量地震使用里氏震级衡量其他灾害则采用各自不同的指标。该流水线会将所有灾害统一映射到 0–100 的标准化评分体系// Painless snippet from the ingest pipeline if (type TC) { norm Math.min(100.0, Math.max(0.0, (val - 40.0) / 2.6)); } else if (type EQ) { norm Math.min(100.0, Math.max(0.0, (val - 4.0) * 20.0)); }标准化后的严重程度评分会进一步映射为severity_level标签low、medium、high、critical并用于检测规则中的告警严重级别映射。ECS 对齐event.kind设置为alertevent.category设置为threat时间字段映射到event.start和event.end使用基于指纹计算的稳定_id实现去重第三步地理空间富化 —— 在索引阶段发现受影响设施Elasticsearch 的 geo_match 富化策略能够在索引阶段将灾害影响区域多边形与所有基地边界进行匹配而无需在查询阶段执行关联操作。换句话说我们不是在搜索时执行空间关联而是在文档写入时通过摄取流水线中的丰富处理器enrich processor将灾害影响区域多边形与所有基地边界进行匹配。该富化策略是一个geo_match类型的策略{ geo_match: { indices: mitra-facilities, match_field: entity_geo_location, enrich_fields: [ entity_name, entity_type, entity_station_number, entity_geo_city_name, entity_geo_region_name ] } }该处理器在摄取流水线的最后阶段执行{ enrich: { policy_name: facilities-geo, field: gdacs.affected_area, target_field: affected_facilities, shape_relation: INTERSECTS, max_matches: 128 } }INTERSECTS会匹配所有与灾害影响区域多边形发生接触、重叠或部分相交的基地边界。最终结果是每个 GDACS 事件文档都会带有一个名为affected_facilities的嵌套数组其中准确记录了哪些基地位于受影响区域内。因此无需执行任何关联查询。第四步检测规则——对受影响设施触发告警Kibana 检测规则持续监控logs-gdacs.events-*数据流。当某个 GDACS 事件经过富化处理后包含至少一个受影响设施时规则便会触发Query: affected_facilities: { entity_name: * }该规则按小时调度运行时间窗口为now-1h到now并使用动态严重程度映射摄取流水线计算出的gdacs.severity_level字段会自动驱动告警严重级别。告警严重级别也会通过字段映射进一步影响风险评分risk scorerisk_score_mapping: [ { field: gdacs.normalized_severity, operator: equals, value: } ]triggers: - type: alert steps: - name: start_convo type: kibana.request with: method: POST path: /api/agent_builder/converse body: agent_id: mitra.response input: New Natural Disaster Alert: {{ event.alerts | json }}整个告警负载灾害类型、严重程度、受影响区域以及受影响设施列表会作为初始上下文传递给 AI 智能体。智能体随后接管整个流程。第六步AI 智能体——从数据到协调行动mitra.response智能体接收完整告警负载并在单次智能体循环中完成评估范围、查找接收设施、分配人员以及发送疏散与接收通知全程无需人工介入。该智能体具备两个工具mitra.nearest_facility使用 geo_shape 查询mitra-facilities索引并按距离排序返回最多 50 个具备可用容量的附近活跃设施。mitra.notify遍历 JSON 格式的设施对象数组并发送格式化的疏散或接收通知。智能体的指令集定义了清晰的工作流程评估情况解析告警信息识别受影响设施并确定灾害范围。盘点迁移需求统计人员数量、关键资产以及每个设施的住宿需求。寻找目标设施为每个受影响基地调用mitra.nearest_facility并过滤仍处于危险区域的设施。做出分配决策基于单点或多点迁移方案进行推理同时考虑军种兼容性、住宿容量与资产支持能力。发送协调邮件向源设施发送撤离指令向接收设施发送接收通知。生成汇总报告向对话返回简短总结包括受影响设施、总人员数、迁移资产、目标设施以及潜在风险。该智能体的分配逻辑遵循真实世界约束不得超过住宿容量优先同军种迁移多军种溢出优先使用联合基地优先选择距离更近的设施以减少运输时间。最近设施工具底层工作流查询使用geo_shape并结合圆形过滤器以及_geo_distance排序query: { bool: { filter: [ { geo_shape: { entity_geo_location: { shape: { type: circle, coordinates: [{{ inputs.lon }}, {{ inputs.lat }}], radius: 5000km }, relation: intersects } } }, { term: { operational_status.keyword: act } } ] } }, sort: [ { _geo_distance: { entity_geo_point: { lat: {{ inputs.lat }}, lon: {{ inputs.lon }} }, order: asc, unit: km } } ], script_fields: { available_capacity: { script: { source: Math.max(0, doc[housing_capacity].value - doc[personnel_count].value) } } }可用容量是在查询时通过脚本字段计算得出的该字段用“住房容量减去当前人员数量”来表示剩余容量。智能体利用这一计算结果进行跨目标分配确保不会超出容量上限。飓风 ELARA-2613.7万人智能体端到端协调行动飓风 ELARA-26 是一场四级风暴最大风速 213 km/h预计将在弗吉尼亚州 Hampton Roads 地区登陆。当 GDACS 事件被摄取后其影响区域多边形与该地区的七个主要基地发生空间相交。检测规则被触发工作流启动并发起一次智能体对话。在单次智能体循环中智能体完成了以下操作识别出位于影响区域内的 7 个设施总计 137,372 名人员。调用mitra.nearest_facility查找风暴路径之外的接收设施。根据可用住房容量与距离将人员分配到 9 个接收设施。向所有 7 个受影响基地生成并发送撤离指令。向所有 9 个接收设施生成并发送接收通知。生成完整协调摘要如下所示已撤离设施设施距离接收人员Fort Gregg-Adams97 公里~40,000Marine Corps Base Quantico148 公里~30,000Naval Support Facility Indian Head151 公里~30,000Joint Base Andrews180 公里~30,000Naval Air Station Patuxent River141 公里~10,000NG MTA Camp Butner174 公里~5,000NG Bethany Beach Training Site209 公里~4,707Rivanna Station140 公里~7,500Defense General Supply Center22 公里~6,000受调配的资产包括运输车辆、直升机、巡逻艇、医疗单位、工程车辆、发电机、水车、宿营套件以及通信系统。自动化邮件通知一旦智能体完成分配方案它会调用mitra.send_email并在一次执行中发送 16 封邮件其中包括发往 7 个受影响设施的撤离指令以及发往 9 个接收设施的接收通知。每封邮件都包含目标设施、迁入人员数量、需要转移的资产以及协调联系人。原本需要数小时通过电话树逐级传达的协调流程在智能体完成推理后被自动完成。通过 RAG 与策略约束扩展智能体灾害响应能力该演示目前仅基于结构化数据如容量、距离和运行状态。Elastic 的语义搜索与检索增强生成RAG能力可以通过两个方向显著增强智能体能力历史响应检索将历史事后报告、美国联邦紧急事务管理局FEMA事件总结以及灾害响应记录以向量嵌入方式进行索引。当新事件发生时智能体可以语义检索类似历史事件的处理方式从而基于既往经验而不仅仅是容量计算来指导分配决策。策略与作战原则约束将国防部应急管理指令、基地持续运营计划以及指挥官指导原则进行索引。智能体可以检索并引用真实的政策依据使所有决策基于作战条令而非推理结果。两者都遵循相同的 Elastic 原生方法由推理管道在索引阶段生成向量嵌入并向智能体暴露语义搜索工具。协调流水线保持不变智能体只是变得更智能。为什么 Elasticsearch 是智能体驱动公共部门响应的理想平台这不是聊天机器人也不是仪表板而是一个响应式的智能体工作流系统它能够检测威胁、推理复杂的物流问题并在没有人工参与的情况下协调 13.7 万人的迁移。这一结果之所以可能实现是因为其依赖的所有能力都存在于同一个统一平台中。Elasticsearch 的地理空间能力geo_point、geo_shape、富化策略以及基于距离的排序支持大规模空间推理与设施匹配。语义搜索与向量嵌入确保智能体基于真实数据进行推理而不是基于幻觉信息。Kibana 的检测引擎、工作流系统、Agent Builder 以及相关工具将整个流程串联起来实现从原始事件到协调行动的端到端自动化无需额外的外部胶水代码。没有其他平台能够以这种方式整合这些能力。实时索引、地理空间精度、语义检索以及智能体编排的结合再加上企业级安全与可观测性使 Elasticsearch 与那些只能做好其中一部分、却需要用户自行拼接其余能力的工具形成明显区别。面向应急管理、消防、执法与公共卫生的智能体地理响应系统同样的架构适用于任何涉及人员、设施与实时事件交互的场景变化的只是数据本质流程保持一致。应急管理FEMA 和各州应急管理部门可以将避难所、前置集结点与脆弱人群映射到国家气象局NWS极端天气多边形上在风暴登陆前自动触发资源预置。消防与急救服务消防部门可以将单位位置与响应区域叠加到野火或建筑火灾范围上自动将增援请求路由到装备最合适且最近的单位。执法机构可以将实时事件位置与学校区域、关键基础设施以及警员位置进行关联在无需人工分流的情况下触发基于地理位置的封锁或资源调度。校园安全学区可以监控实时威胁与校园边界的空间关系。当威胁进入校园范围时智能体可以立即通知管理层、启动封锁通信并协调执法响应甚至早于调度中心人工接听电话。公共卫生卫生部门可以将疾病监测数据或环境风险区域与诊所位置、人口密度层以及物资库存进行匹配将资源精准调度到最需要的地方。领域用例Elastic 能力应急管理将避难所位置与 NWS 极端天气多边形匹配geo_shape富化 Kibana 工作流消防与急救服务将单位位置叠加到野火边界地理空间路由 最近设施查询执法将事件与学校区域及警员位置关联地理感知告警规则 智能体调度校园安全监控威胁数据流与校园边界检测规则 自动化通知公共卫生将风险区域与诊所及物资仓库匹配语义搜索 地理空间富化数据在每一种场景中都不同但底层模式是一致的数据摄取、在索引时进行富化、检测相交关系、触发智能体响应并执行行动。Elastic 为公共部门组织提供了一个可以一次构建、随处适配的平台。本文中描述的任何功能或发布时间均由 Elastic 全权决定。任何当前不可用的功能或能力可能无法按时交付甚至可能不会交付。这篇内容有多大帮助原文Automated disaster response with Elastic: 137,000 personnel - Elasticsearch Labs