引言

传统可观测性往往意味着在仪表盘之间“东奔西跑”——收到告警后，你需要逐个打开日志、追踪和指标视图，手动关联信息，再凭借经验猜测根因。如今，Elastic Agent Builder 和 Workflows 将这一过程彻底改变：你只需用自然语言提出一个问题，AI 代理便会自动编写并执行 ES|QL 查询，在数周的数据中关联指标、定位根因，甚至估算业务影响；最后，工作流会自动创建工单，完成闭环。

本文将以物流公司 FastFreight Co 的真实场景为例，带你走一遍完整的端到端流程：从收到运单量告警，到使用一个专为运维团队定制的“领域代理”（OpsWatch）进行诊断，再到自动触发 Jira 工单——全程无需人工切换任何仪表盘。

---

第一章：AI 之前的可观测性——仪表盘、阈值与人工关联

在 AI 时代到来之前，典型的告警流程是这样的：

1. 配置阈值规则：在 Kibana 中设置 Alert 或 Watcher，例如“最近 10 分钟内错误率超过 5% 则触发告警”。
2. 收到告警：当某个指标（如运单量）跌破基线时，告警被触发。
3. 人工排查：你需要手动打开相关的仪表盘、日志视图、追踪视图，尝试将不同数据源的信息串连起来。
4. 寻找根因：依靠个人经验或团队 Wiki，在多个面板间反复比对，最终推测问题所在。

下图展示了一个典型的运单量仪表盘，可以看到运单量突然暴跌至每日基线以下：

这种方式的局限性非常明显：

• 仪表盘能告诉你“出事了”，但无法告诉你“为什么”——除非你本身非常熟悉该领域。
• 难以跨面板关联：一个面板反映的是 vendor A 的问题，另一个面板可能完全是 vendor B 的无关异常。
• 无法计算业务影响：例如，运单量下降究竟造成了多少营收损失？仪表盘不会给你答案。

例如，下面四个观测面板中，前三个都与 vendor 1 的运营故障相关，第四个却是 vendor 2 的费用异常。有经验的操作员能识别出这种模式：

信号模式	解读
运单量下降 + 配送时长上升 + 纠纷率上升	该供应商运营故障
所有指标正常，但成本飙升	计费异常

可以看出，理解每个仪表盘背后的含义需要大量学习和经验积累，这类知识通常“藏在人脑中”或散落在 Wiki 里。系统能检测和展示，却不具备推理能力——而 AI 代理恰恰填补了这个空白。

---

第二章：Elastic Agent Builder —— 提问即得答案

2.1 什么是 Agent Builder？

Elastic Agent Builder 是 Elastic 提供的 AI 对话平台，允许你用自然语言与数据交互。它不再把知识固化在硬编码的仪表盘中，而是将组织内专家掌握的经验转化为一个“可随时提问的智能代理”，任何团队成员都能通过对话探索数据、获得即时洞察。

2.2 配置与使用

你可以使用内置模型，也可以通过连接器接入第三方模型（甚至本地运行的 LLM）。本例中我们通过连接器使用 GPT-4o（任意受支持的模型均可）。配置完成后，进入 Agent Builder，向代理提问，它会立刻返回查询结果、表格和图表。

2.3 实战：从运单量告警到根因诊断

场景：我们收到一条活跃告警 —— FastFreight Co（vendor_id=1）最近 24 小时内运单量跌至 100 以下，而历史基线约为每天 229 单。

第一个问题（直接提问）：

“请确认 FastFreight 当前每日运单量，并展示过去 3 周的变化趋势。”

代理的回答直接给出了一张每日运单数表格，清晰地显示出运单量在持续下滑——一个问题就完成了数据拉取和初步可视化。

第二个问题（追问退化起始点）：

“运单量是从哪天开始低于基线的？”

代理自动编写并执行 ES|QL，精确定位出退化始于 3月1日，而从 3月11日起下降加剧。

第三个问题（关联其他指标）：

“同期配送时长和纠纷率如何？”

代理在一个回答中同时展示了两个关联指标：平均配送时长从 12.6 分钟飙升至 46 分钟，纠纷率从 0.3% 升至 20%。跨指标关联瞬间完成。

业务影响计算（关键一步）：

“这次下降造成了多少营收损失？”

代理计算得出：

• 预期运单量（3月1日~19日，日均 228）：约 4,328 单
• 实际运单量：1,884 单
• 缺失运单：约 2,444 单
• 每单平均金额：约 15 美元
• 预估损失：约 36,669 美元

至此，仅通过几次自然语言提问，我们就得到了根因时间线、关联指标和业务影响金额——这在以前需要借助外部工具和大量手工计算才能完成。

2.4 扩展：RAG 与私有数据

Agent Builder 还支持连接私有数据源，通过 RAG（检索增强生成）让代理基于企业自有知识库给出更精准的答案，而非泛泛的通用回复。

---

第三章：从通用代理到领域专家——自定义代理与领域记忆

3.1 为什么需要自定义代理？

通用代理每次对话都从零开始，你不得不反复解释数据含义、阈值和检查项；而且它无法限定作用域，也不能在 Kibana 外部使用。Agent Builder 允许你创建基于特定领域的专属代理，不同团队可以使用各自定制的代理，从自己的视角出发进行诊断。

3.2 自定义代理的构成

自定义代理通过 “定制指令”（Custom Instructions） 来定义其角色，例如：

“你是高级车队运营分析师……”

同时配合 ES|QL 引用 提供细粒度的查询控制和安全性保障。你还可以通过 MCP 服务器连接外部工具，或将自己的代理暴露为外部资源。

3.3 实例：OpsWatch —— 运维团队的专属代理

我们创建了一个名为 OpsWatch 的自定义代理，它的知识范围限定在运营领域：了解运单量、配送时长、人员配置等，但不涉及费用、SLA 等内容。

当用户问及运营状况时，OpsWatch 会基于实时数据给出结论和建议，整个过程仅需数秒：

例如，它会回答：“运单量下降与 vendor 1 的配送时长上升高度相关，建议立即联系该供应商核实。”

更重要的是领域边界：当用户询问成本相关问题时，OpsWatch 会礼貌地拒绝回答，并建议转向另一个自定义代理 CostGuard（费用领域代理）。这种有边界的代理设计使得每个代理更加专注、准确，也更容易维护。

---

第四章：闭环行动——Elastic Workflows 从诊断到自动化

4.1 从“推荐”到“执行”

AI 代理擅长诊断和推荐，但通常不会主动执行操作。为了真正实现“告警→诊断→行动”的自动化闭环，Elastic 提供了 Workflows（工作流）。

4.2 Workflow 的运作机制

一个 Workflow 是由规则触发的自动化流程，它可以：

• 调用外部 API（Jira、Slack、Teams 等）
• 执行后续 Elasticsearch 查询

当某个告警触发时，Workflow 会主动调用 Agent Builder 中的代理，代理完成诊断后返回结果，然后 Workflow 根据预定义的动作自动创建 Jira 工单、在 Slack 的 #ops-alerts 频道发送摘要，或两者同时执行——全程无需人工干预。

4.3 整体架构图

下面的架构图展示了从告警到动作的完整数据流：

---

总结与展望

通过本文的旅程，我们清楚地看到可观测性的未来方向：

• 从“盯仪表盘”到“提问”：你不再需要记住每个面板的位置和含义，只需要用自然语言描述你想知道什么。
• 从“知识在人脑”到“知识在代理指令中”：新员工也能像资深专家一样提问，代理会执行正确的查询，甚至发现新洞察。
• 从“推荐”到“行动”：Workflows 让诊断结果自动转化为工单或通知，真正实现“告警即处理”。

Elastic Agent Builder 和 Workflows 并不是要取代仪表盘——它们依然有用——但排查的起点将永远变为“向代理提问”。这就是 AI 赋能的下一代可观测性：更快、更准、更自动化。

---