企业官网建设流程全解析

作者：来自 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 Service（EIS）的本地 Elastic 集群。

Elasticsearch 智能体驱动灾害响应流水线如何工作

整个流水线由七个层级组成，它们端到端协同工作：

1. 数据摄取：将全球灾害预警与协调系统（GDACS）的灾害事件发送到 Elasticsearch。

2. 摄取流水线：将 GeoJSON 数据摄取并标准化为 Elastic 通用模式（ECS）。

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

4. 告警：当灾害区域与任意基地发生空间相交时，Kibana 检测规则被触发。

5. 工作流自动化：告警触发 Kibana 工作流，并启动 AI 智能体会话。

6. AI 推理：智能体根据受影响设施、其资产情况以及最近的支援设施进行推理，确定所有资产和人员的重新部署方案。

7. 电子邮件通知：智能体向所有相关接收人发送电子邮件，包括人员和资产的迁出方与接收方。

下面我们逐层进行介绍。

第一步：使用地理边界索引基地

整个方案的基础是来自 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.ops@navy.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设置为alert

• event.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 score）：

"risk_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 格式的设施对象数组，并发送格式化的疏散或接收通知。

智能体的指令集定义了清晰的工作流程：

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：13.7万人智能体端到端协调行动

飓风 ELARA-26 是一场四级风暴（最大风速 213 km/h），预计将在弗吉尼亚州 Hampton Roads 地区登陆。当 GDACS 事件被摄取后，其影响区域多边形与该地区的七个主要基地发生空间相交。检测规则被触发，工作流启动并发起一次智能体对话。

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

• 识别出位于影响区域内的 7 个设施，总计 137,372 名人员。

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

• 根据可用住房容量与距离，将人员分配到 9 个接收设施。

• 向所有 7 个受影响基地生成并发送撤离指令。

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

• 生成完整协调摘要，如下所示：

已撤离设施：

受调配的资产包括运输车辆、直升机、巡逻艇、医疗单位、工程车辆、发电机、水车、宿营套件以及通信系统。

自动化邮件通知

一旦智能体完成分配方案，它会调用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 为公共部门组织提供了一个可以一次构建、随处适配的平台。

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

这篇内容有多大帮助？

原文：Automated disaster response with Elastic: 137,000 personnel - Elasticsearch Labs