13.7万人，零人工决策：基于Elasticsearch的代理式灾害响应

13.7万人，零人工决策：基于Elasticsearch的代理式灾害响应

Agent Builder 现已正式发布 (GA)。立即开始 Elastic Cloud 试用，并在此处查看 Agent Builder 的文档。

Elastic 刚刚协调完成了对七个军事设施中 13.7 万名军事人员的自动化疏散，整个过程无需任何人工干预。当一场四级飓风袭击汉普顿路海岸线时，Elasticsearch 的地理空间富化功能在索引时识别出影响区域内的所有设施。Kibana 检测规则被触发，随之启动了一个 AI 代理对话工作流。该代理会综合考虑容量、距离和兵种兼容性，然后一次性发出 16 条疏散和接收通知。从原始的 GDACS 事件到协调行动，全程自动化。

每年，自然灾害都迫使应急管理者、军事指挥官和公共安全官员在极短的时间内做出高风险决策。这些决策传统上依赖于电话树、电子表格以及分散在数十人之间的机构知识。仅协调开销就会耗费宝贵的时间。

本文将展示 Elastic 如何为灾害响应提供一个响应迅速的代理式协调系统，该系统能够检测威胁、推断物流并自动采取行动。为了具体说明，我们构建了一个模拟场景：一场虚构的四级飓风威胁汉普顿路海岸线，触发了七个军事设施中超过 13.7 万名人员的自动化转移。

免责声明：这是一个完全虚构的场景，仅用于演示目的。 飓风 ELARA-26 并不存在。设施位置基于真实、公开的地理数据（美国国防部 [DoD] 军事设施、靶场和训练区 [MIRTA] 数据集），但所有作战数据，如人员数量、住房容量、资产、联系电子邮件和任务概况，均完全虚构。本演示中的任何内容均不反映实际的军事战备状态、能力或作战程序。

为什么自动化灾害响应需要地理空间和代理式协调

当自然灾害威胁关键基础设施时，协调挑战会立即出现：

• • 哪些设施位于受影响区域？
• • 有多少人员需要转移？
• • 他们可以去哪里？这些设施是否有能力接收？
• • 现在需要通知谁？

这些问题刻不容缓，答案也应如此。

部署管线：前提条件和设置

请遵循示例仓库中的说明，通过 Cloud Connect 部署一个带有 Elastic Inference Service (EIS) 的本地 Elastic 集群。

Elasticsearch 代理式灾害响应管线的工作原理

该管线有七个层，它们协同工作，实现端到端响应：

Pipeline flowchart Alt text: Horizontal flowchart with seven labeled boxes connected by arrows: GDACS feed, ingest pipeline, enrich (geo_shape), detection rule, workflow, AI agent, and email.

Pipeline flowchart Alt text: Horizontal flowchart with seven labeled boxes connected by arrows: GDACS feed, ingest pipeline, enrich (geo_shape), detection rule, workflow, AI agent, and email.

1. 1. 数据摄入： 将全球灾害预警和协调系统 (GDACS) 的灾害事件发送到 Elasticsearch。
2. 2. 摄入管线： GeoJSON 被摄入并标准化为 Elastic Common Schema (ECS)。
3. 3. 地理空间富化： 事件的受影响区域多边形与已索引的军事设施边界进行匹配。
4. 4. 告警： 当灾害与任何设施发生交叉时，Kibana 检测规则会触发。
5. 5. 工作流自动化： 告警触发 Kibana 工作流，启动 AI 代理对话。
6. 6. AI 推理： 代理通过受影响的设施、其资产以及最近的支持设施进行推理，以确定所有资产和人员的重新安置。
7. 7. 电子邮件通知： 代理向所有接收者发送人员和/或资产的入站和出站电子邮件通知。

让我们逐层深入了解。

第 1 步：用地理边界索引军事设施

基础数据是来自 source.coop/seerai/hifld 的 DoD MIRTA 数据集。该数据集为每个设施提供一个 Point 类型的 geo_shape，即中心点坐标而非完整的边界多边形。

mitra-facilities 索引中的每个设施文档都用操作概况数据（全部虚构）进行富化，超出了 MIRTA 提供的内容：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

{
  "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.ops@navy.mil.gov.fake",
  "operational_status": "act",
  "is_joint_base": false,
  "entity_geo_location": {
    "type": "polygon",
    "coordinates": [...]
  }
}

正是这个丰富的索引使 AI 代理能够做出智能的分配决策；不仅仅是“这里是附近的基地”，而是“这里有可用的住房容量、兼容的任务类型以及接收入站资产的物流能力的基地”。

第 2 步：摄入和标准化 GDACS 事件

GDACS 发布地震、热带气旋、洪水、野火、火山和干旱的实时 GeoJSON。我们使用自定义摄入管线将此数据流摄入到数据流 (logs-gdacs.events-*) 中，该管线将原始 GeoJSON 标准化为 ECS 字段。

GDACS 摄入管线完成了几项值得注意的工作：

几何提取： 中心点存储为 geo_point 用于地图显示，影响多边形存储为 gdacs.affected_area 中的 geo_shape，该字段用于后续的交叉查询。

严重性标准化： 每种灾害类型都有不同的严重性等级。热带气旋以千米/小时风速衡量；地震以里氏震级衡量。管线将它们全部映射到 0-100 的标准化分数：

1
2
3
4
5
6

// 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: alert、event.category: threat，时间戳映射到 event.start/event.end，以及用于去重（deduplication）的基于稳定指纹的 _id。

第 3 步：地理空间富化：在索引时查找受影响的设施

Elasticsearch 的 geo_match 富化策略在索引时将灾害多边形与每个设施边界进行匹配，无需查询时连接。我们不是在搜索时查询，而是在摄入管线中使用一个富化处理器，在文档被索引时，将灾害的影响多边形与每个设施边界进行匹配。

富化策略是一个 geo_match 策略：

1
2
3
4
5
6
7
8
9
10
11
12
13

{
  "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"
    ]
  }
}

该处理器在摄入管线的末尾运行：

1
2
3
4
5
6
7
8
9

{
  "enrich": {
    "policy_name": "facilities-geo",
    "field": "gdacs.affected_area",
    "target_field": "affected_facilities",
    "shape_relation": "INTERSECTS",
    "max_matches": 128
  }
}

INTERSECTS 会捕获任何边界接触或与灾害多边形重叠的设施，甚至是部分交叉。结果是，每个 GDACS 事件文档都存储了一个 affected_facilities 嵌套数组，它准确地告诉我们哪些设施位于影响区域内。无需连接查询。

第 4 步：检测规则：对设施影响进行告警

Kibana 检测规则监视 logs-gdacs.events-* 数据流，并在 GDACS 事件至少被一个受影响设施富化时触发：

1

Query: affected_facilities: { entity_name: * }

该规则按小时计划运行（覆盖 now-1h 到 now 的时间窗口），并使用动态严重性映射；摄入管线计算的 gdacs.severity_level 字段自动驱动告警严重性。

告警严重性还通过字段映射驱动风险分数：

1
2
3
4
5
6
7

"risk_score_mapping": [
  {
    "field": "gdacs.normalized_severity",
    "operator": "equals",
    "value": ""
  }
]

当规则触发时，它会将完整的告警上下文，包括富化后的 affected_facilities 数组（包含设施名称、类型和位置），向下游传递给 Kibana 工作流。

第 5 步：工作流自动化：连接告警与代理

Kibana Workflows 处理从检测到响应的交接。自然灾害响应工作流由告警触发：

1
2
3
4
5
6
7
8
9
10
11

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 代理。代理将从那里接管。

第 6 步：AI 代理：从数据到协调行动

mitra.response 代理接收完整的告警负载，并在一个代理式循环中，评估范围、查找接收设施、分配人员并发送疏散和接收通知，所有这些都无需人工干预。

该代理有两个可用工具：

• • mitra.nearest_facility 使用 geo_shape 查询 mitra-facilities 索引，按距给定坐标的距离排序，返回最多 50 个附近有可用容量的活跃设施。
• • mitra.send_email 遍历设施对象的 JSON 数组，并发送格式化的疏散或接收通知。

代理的指令集定义了一个清晰的工作流：

1. 1. 评估情况。 解析告警，识别受影响的设施，并确定灾害范围。
2. 2. 清点需要转移的物品。 各设施的人员数量、关键资产、住房需求。
3. 3. 查找目的地设施。 为每个受影响的设施调用 mitra.nearest_facility，过滤掉仍在危险区域内的设施。
4. 4. 做出分配决策。 推理单一设施与多设施解决方案、兵种兼容性、住房容量、资产支持。
5. 5. 发送协调电子邮件。 向源设施发送疏散命令，向接收设施发送接收通知。
6. 6. 生成摘要报告。 生成一份简短的摘要，包含所有受影响设施、总人员、转移资产、目的地设施以及任何需要注意的问题，发送到聊天中供审查。

代理的分配逻辑遵循现实世界的约束：不超出住房容量，尽可能优先考虑同兵种的重新安置，使用联合基地处理多兵种溢出，并优先考虑距离以最大程度减少运输时间。

最近设施工具

底层工作流查询使用带有圆形过滤器和 _geo_distance 排序的 geo_shape：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

"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-26：13.7万人员的代理式端到端协调

飓风 ELARA-26 是一场四级风暴（最大风速 213 公里/小时），预计将在弗吉尼亚州的汉普顿路地区登陆。当 GDACS 事件被摄入时，受影响区域的多边形与该地区的七个主要军事设施相交。检测规则被触发。工作流启动了一个代理对话。

在一个代理式循环中，代理：

• • 识别了影响区域内的七个设施，总计 137,372 名人员。
• • 调用 mitra.nearest_facility 查找风暴路径之外的接收设施。
• • 根据可用住房容量和距离，将人员分配到九个接收设施。
• • 生成并向所有七个受影响设施发送疏散命令。
• • 生成并向所有九个接收设施发送接收通知。
• • 生成了完整的协调摘要，类似于下表：

已疏散设施：

接收设施：

重新安置的资产包括运输车辆、直升机、巡逻艇、医疗部队、工程车辆、发电机、水拖车、避难工具包和通信系统。

自动化电子邮件通知

代理最终确定分配计划后，调用 mitra.send_email 并一次性发送了 16 封电子邮件；即向所有七个受影响设施发送了疏散命令，并向所有九个接收设施发送了接收通知。每条消息都包含目的地设施、接收人员数量、要转移的资产以及协调联系人。原本需要数小时电话协调的工作，在代理完成推理的那一刻便自动完成了。

通过 RAG 和政策依据扩展代理式灾害响应

本演示纯粹基于结构化数据，例如容量数字、距离和操作状态。Elastic 的语义搜索和检索增强生成 (RAG) 功能可以通过两项附加功能显著提高代理的智能化水平：

历史响应检索： 将过去的行动后报告、联邦应急管理局 (FEMA) 事件摘要和灾害响应记录索引为向量 embeddings。当新事件发生时，代理可以语义检索类似事件的处理方式，用机构知识而非仅仅是容量计算来指导分配决策。

政策和原则依据： 索引 DoD 应急管理指令、设施持续运行计划和指挥官指南。代理可以检索并引用管理响应的实际政策，确保每个决策都基于原则而非推断。

这两者都遵循相同的 Elastic 原生方法：推理管线在索引时生成 embeddings，并将语义搜索工具暴露给代理。协调管线保持不变，代理只会变得更智能。

为什么 Elasticsearch 是公共部门代理式响应的理想平台

这不是一个聊天机器人，也不是一个仪表板。它是一个响应迅速的代理式工作流系统，能够检测威胁、推断复杂的物流问题，并在没有人工干预的情况下协调 13.7 万人的重新安置。这种结果之所以可能，是因为它所依赖的每项功能都存在于一个统一的平台中。

Elasticsearch 的地理空间支持（geo_point、geo_shape、富化策略和基于距离的排序）处理空间推理，从而实现大规模的交叉检测和设施查找。语义搜索和向量 embeddings 使代理基于事实，确保 AI 推理基于数据中实际存在的内容，而不是凭空臆想。Kibana 的检测引擎、Workflows、Agent Builder 和 Agent Builder 工具将所有这些连接成一个管线，从原始事件到协调行动，无需任何外部粘合代码。

没有其他平台能像 Elastic 这样将所有这些功能整合在一起。实时索引、地理空间精度、语义检索和代理式编排的结合，所有这些都在一个堆栈中，并内置了企业级安全性和可观测性，这就是 Elastic 与那些只擅长其中一项但需要你自己将其他部分拼凑起来的工具的区别。

应急管理、消防、执法和公共卫生领域的代理式地理空间响应

同样的架构适用于人员、设施和实时事件相互交叉的任何场景。具体数据会变化，但管线不会。

应急管理： FEMA 和州应急管理办公室可以将避难所位置、集结区和脆弱人群与传入的国家气象局 (NWS) 恶劣天气多边形进行匹配，在风暴登陆前自动预先部署资源。

消防和紧急医疗服务： 消防部门可以将单位位置和响应区域叠加到野火边界或结构火灾群组上，自动将互助请求路由到最近且配备正确设备的可用单位。

执法： 机构可以将活跃事件位置与学区、关键基础设施和警官位置关联起来，触发地理感知的封锁通知或资源调度，而无需等待人工分流。

公共学校安全： 学区可以监控针对校园边界的实时威胁源。当威胁与学校周边相交时，代理可以立即通知管理部门，启动封锁通信，并协调执法响应，所有这些都在调度员接听电话之前完成。

公共卫生： 卫生部门可以将疾病监测数据或环境危险区域与诊所位置、人口密度图层和物资仓库库存进行匹配，从而将资源分配到最需要的地方。

在每种场景中，数据都是不同的。但摄入、在索引时富化、检测交叉、触发代理式响应并采取行动的基本模式都是相同的。Elastic 为公共部门组织提供了一个平台，可以构建一次并在任何地方进行适应。

本帖中描述的任何功能或特性的发布和时间安排由 Elastic 自行决定。任何目前不可用的功能或特性可能无法按时或根本无法交付。