137,000 人，零人工决策：依托 Elasticsearch 实现智能体灾害应急响应

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

Elastic 刚刚协调完成了七处设施中 137,000 名军事人员的自动化疏散，全程无需人工干预。当 4 级飓风袭击汉普顿锚地海岸线时，Elasticsearch 的地理空间数据富化功能在索引数据入库时便已识别出受影响区域内的每一处设施。一条 Kibana 检测规则被触发。工作流启动了 AI 智能体对话。智能体根据容量、距离和分支兼容性进行了推理，然后一次性发送了 16 条疏散和接收通知。从接收原始 GDACS 事件到生成协同动作，全程自动完成。

每年，自然灾害都迫使应急管理人员、军事指挥官和公共安全官员在紧迫的时间内做出关乎重大利益的高风险决策。在传统模式下，这些决策依赖于电话联络网、电子表格以及散落分布在数十人脑海中的机构知识。单单是多头协调带来的沟通成本就会白白消耗掉极其宝贵的黄金救援时间。

本文旨在展示 Elastic 如何驱动一套具备敏捷响应能力的智能体灾害应急协调系统，该系统能够检测威胁、推理后勤逻辑并自动采取行动。为了具体说明，我们构建了一个模拟：一场虚构的 4 级飓风威胁着汉普顿锚地海岸线，触发了七个军事设施中超过 137,000 多名人员的自动转移。

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

为什么自动化灾害应急响应需要地理空间与智能体协调

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

• 哪些设施位于受影响区域内？

• 需要转移多少人员？

• 人员可以转移到哪里，那里的设施是否具有容载能力？

• 目前需要通知哪些人？

这些问题刻不容缓，获取答案也不能有片刻拖延。

部署管道：准备工作和设置

请按照此处示例存储库中的说明，通过 Cloud Connect 部署带有 Elastic 推理服务 (EIS) 的本地 Elastic 集群。

Elasticsearch 智能体灾害响应管道如何运作

该管道包含七个端到端协同工作层：

1. 数据摄取：全球灾害警报与协调系统 (GDACS) 灾害事件发送至 Elasticsearch

2. 摄取管道：GeoJSON 被摄取并规范化为 Elastic Common Schema (ECS)。

3. 地理空间富化：事件的受影响区域多边形与已建索引的军事设施边界进行匹配。

4. 警报通知：当灾害与任何设施交叉重合时，Kibana 检测规则将触发。

5. 工作流自动化：警报会触发一个 Kibana 工作流，从而启动 AI 智能体对话。

6. AI 推理：智能体对受影响的设施、其资产以及最近的支持设施进行推理，以确定所有资产和人员的转移方案。

7. 电子邮件通知：智能体会针对进出人员和/或资产向所有收件人发送电子邮件。

让我们逐层进行分析。

第 1 步：为具有地理边界的军事设施编制索引

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

在 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.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 存储以用于地图显示，而影响范围多边形则作为 geo_shape 存储在 gdacs.affected_area 中，该字段后续将用于相交查询。

严重性归一化：每种灾害类型都有不同的严重性等级。例如热带气旋按风速 (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 标签（低、中、高、极高），该标签用于检测规则中的警报严重性映射。

ECS 对齐：event.kind 设为 alert，event.category 设为 threat，时间戳映射到 event.start/event.end，并使用基于指纹的稳定 _id 实现去重。

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

Elasticsearch 的 geo_match 富化策略会在索引阶段将灾害影响区域多边形与各个设施边界进行匹配，无需在查询时执行连接操作。我们无需在搜索时进行查询，而是在采集管道中利用富化处理器，在文档被索引时将灾害影响区域多边形与各个设施的边界进行匹配。

该富化策略属于一种 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 嵌套数组，该数组会准确告诉我们哪些设施位于影响区域内。这个过程无需进行连接查询。

第 4 步：检测规则：针对设施受影响情况发出警报

Kibana 检测规则会监测 logs-gdacs.events-* 数据流，当某个 GDACS 事件包含至少一个受影响设施的信息时，该规则即触发警报：

查询条件：affected_facilities: { entity_name: * }

该规则按小时运行（覆盖从 now-1h 到 now 的时间窗口），并使用动态严重性映射机制；由采集管道计算得出的 gdacs.severity_level 字段会自动决定警报的严重性。

此外，警报严重性还会通过字段映射影响风险评分：

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

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

第 5 步：工作流自动化：连接警报与智能体

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

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. 评估状况。解析警报，识别受影响的设施，并确定灾难范围。

2. 盘点需要迁移的人员与资产。统计各设施的人员数量、关键资产及安置需求。

3. 查找目标设施。针对每个受影响设施调用 mitra.nearest_facility，并排除仍处于危险区域的设施。

4. 制定分配决策。权衡单一设施与多设施安置方案，考量所属分支兼容性、安置容量及资产支持能力。

5. 发送协调电子邮件。向源设施发送疏散指令，向接收设施发送接收通知。

6. 生成摘要报告。生成简要报告，汇总受影响设施、总人数、转移资产、目标设施及相关注意事项，并发送至聊天中以供审查。

智能体的分配逻辑遵循现实世界的约束条件：不超过安置容量，尽可能优先进行同分支转移，使用联合基地应对多分支溢出需求，并优先考虑距离以尽量缩短运输时间。

最近设施工具

底层工作流查询使用带有圆形过滤器的 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-26：137,000 名人员的端到端智能体协同

飓风 ELARA-26 是一场 4 级风暴（最大风速 213 公里/小时），预计将在弗吉尼亚州的汉普顿锚地区域登陆。当系统接收到 GDACS 事件数据时，受影响区域的多边形与该地区的七个主要军事设施发生重叠。检测规则随之触发。工作流随即启动了智能体对话。

在单次智能体循环中，智能体执行了以下操作：

• 识别出受影响区域内的七处设施，共涉及 137,372 名人员。

• 调用 mitra.nearest_facility 查找风暴路径之外的接收设施。

• 根据可用安置容量和距离，将人员分配到九个接收设施。

• 生成并向所有七个受影响的设施发送疏散命令。

• 生成并向所有九个接收设施发送接收通知。

• 生成完整的协调摘要（如下所示）：

已疏散设施：

接收设施：

转移的资产包括运输车辆、直升机、巡逻艇、医疗单元、工程车辆、发电机、拖挂式水罐车、避难所套件以及通信系统。

自动化电子邮件通知

智能体确定分配方案后，便调用 mitra.send_email 并一次性发送了 16 封电子邮件；即向所有七个受影响设施发送疏散指令，向所有九个接收设施发送接收通知。每封邮件均包含目标设施、迁入人员数量、待转移资产以及协调联系人。原本需要耗费数小时通过电话逐级通知才能完成的工作，在智能体完成推理的那一刻便已自动处理完毕。

借助 RAG 和策略锚定增强智能体灾害应急响应

此演示纯粹基于结构化数据构建，例如容量数值、距离和运行状态。Elastic 的语义搜索和检索增强生成 (RAG) 功能可以通过两项新增功能使智能体变得更加智能：

历史响应检索：将以往的行动后报告、联邦紧急事务管理局 (FEMA) 事件摘要以及灾害响应记录作为向量嵌入编入索引。当新事件触发时，智能体能够从语义层面检索类似事件的处置方式，从而利用积累的机构经验（而非仅仅依赖容量计算）来指导分配决策。

策略与条令依据：索引 DoD 应急管理指令、设施业务连续性计划以及指挥官指导。智能体可以检索并引用指导响应的实际策略，确保每项决策都基于条令而非推断。

这两项功能都遵循相同的 Elastic 原生方法：推理管道会在索引时生成嵌入向量，并向智能体提供语义搜索工具。协调管道保持不变，智能体则变得更智能。

为什么 Elasticsearch 是公共部门智能体响应的理想平台

Elasticsearch 不是聊天机器人，也不是仪表板。它是具备响应能力的智能体工作流系统：它能够自主检测威胁、分析复杂的物流难题，并协调 137,000 人的转移工作，全程无需人工干预。之所以能实现这样的结果，是因为它所依赖的每项功能都集中在一个统一的平台中。

Elasticsearch 的地理空间支持功能（geo_point、geo_shape、富化策略以及基于距离的排序）能够处理空间推理，使大规模的相交检测和设施查询成为可能。语义搜索和向量嵌入技术确保了智能体的决策基于事实，即 AI 的推理建立在实际数据之上，而非凭空产生的“幻觉”假设。Kibana 的检测引擎、工作流、Agent Builder 以及 Agent Builder 工具将这一切无缝连接成一条管道，实现从原始事件到协同行动的完整流程，且无需任何外部粘合代码。

没有其他平台能像 Elastic 这样将这一切整合在一起。将实时索引、地理空间精度、语义检索和智能体编排全部集于单一堆栈中，并内置企业级安全和可观测性，这正是 Elastic 与其他工具的区别所在——那些工具或许在单一领域表现出色，但需要用户自行拼凑其余功能。

面向应急管理、消防、执法和公共卫生的智能体地理空间响应

凡是人员、设施和实时事件发生交集的场景，都可以应用同样的架构。具体的数据会发生变化，但处理流程不变。

应急管理：FEMA 和各州应急管理部门可以将避难所位置、集结区域和脆弱人群分布与美国国家气象局 (NWS) 发布的恶劣天气影响区域多边形进行对照映射，从而在风暴登陆前自动触发资源预置。

消防与紧急医疗服务：消防部门可以将救援力量位置和响应辖区叠加到野火蔓延范围或建筑火灾密集区，自动将互助请求指派给配备合适设备且距离最近的可用救援力量。

执法部门：执法机构可以将正在发生的事件位置与学校区域、关键基础设施和警员位置相关联，从而触发基于地理位置的封锁通知或资源调度，无需等待人工分类。

公立学校安全：学校区域可以监测校园边界内的实时威胁源。当威胁越过学校边界时，智能体立即通知管理部门、启动封锁通讯并协调执法部门响应，这一切均可以在调度员接听电话之前完成。

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

尽管不同场景中的数据各不相同，但其底层模式——即数据采集、索引时富化、检测交集、触发智能体响应以及执行操作——是一样的。Elastic 为公共部门组织提供了一个平台，使其能够一次构建，多处适配。

本文中描述的任何功能或功能性的发布和时间均由 Elastic 自行决定。当前尚未发布的任何功能或功能性可能无法按时提供或根本无法提供。