作者：来自 Elastic Teresa Alvarez Soler 及 Robert Jaszczurek

Kibana 中的 Elastic AI Chat 现在可以通过自然语言构建仪表板，将你的可视化内容与分析保留在同一个线程中，并允许你将它们保存为可复用的 Kibana 对象。

使用单一解决方案即可对你的数据进行观测、防护与搜索。从应用监控到威胁检测，Kibana 是你应对关键使用场景的多功能平台。立即开始你的 14 天免费试用。

---

Kibana 中的 Elastic AI Chat 现在可以直接在对话中，将自然语言问题转换为基于 ES|QL 的可视化内容或完整仪表板。描述你需要的指标，边使用边调整，直到分析结果完整成型后再保存。所有内容都会保留在对话中，直到你准备保存它们；保存后，它们将成为一等 Kibana 对象，团队成员可以打开、编辑并重复使用。该功能已作为技术预览版在 Elastic 9.4 中提供。

该 agent 可以从零开始构建仪表板，但它同样能够基于你已有的内容工作。当你在查看某个仪表板时打开 AI Chat 侧边栏，它会自动附加到当前仪表板。你可以询问某个指标为何激增、按区域进行拆解，或者添加一个对比面板。你现有的仪表板会成为新的起点，而不只是最终产物。

幕后原理：我们如何在 AI Chat 中构建仪表板

我们通过 skills 来教会 agent 执行特定任务 —— 即针对某类问题如何操作的结构化描述。但构建仪表板 skill 意味着需要教 LLM 生成合法的 Kibana 仪表板，而传统的 Saved Object API 在这方面非常痛苦：深度嵌套的 JSON、版本之间细微变化、脆弱的引用关系。我们需要一种不同的方法。

为程序化仪表板专门打造的 API

新的 Dashboards API 正是为这种场景而构建的。它不再暴露原始内部状态，而是为每种面板类型提供类型化、经过验证的 schema。API 会负责在清晰的外部结构与 Kibana 内部表示之间进行转换，因此 agent 可以专注于仪表板“应该包含什么”，而不是“该如何格式化”。

一个 skill，一个 tool，多种操作

dashboard-management skill 暴露了一个统一的 manage_dashboard tool，它接收一个有序的操作数组。每个操作都是一个独立动作：设置元数据、添加 markdown 面板、通过自然语言创建基于 ES|QL 的可视化内容、编辑已有面板、将面板分组到可折叠 section 中，或者在网格上重新排列项目。

agent 可以在一次调用中描述整个仪表板：标题、描述、section，以及其中的每一个面板：

{
 "operations": [
   { "operation": "set_metadata", "title": "Checkout latency investigation" },
   {
     "operation": "add_section",
     "title": "Overview",
     "panels": [
       { "query": "p95 checkout latency over the last 24h", "chartType": "xy" },
       { "query": "checkout error rate by region", "chartType": "metric" }
     ]
   }
 ]
}

操作会按顺序执行，因此后续步骤可以引用并基于前面的步骤继续构建。这种设计让对话始终聚焦于用户意图，而不是实现细节。

可视化流水线：从自然语言到 ES|QL 再到可视化内容

当你请求构建仪表板时，agent 会先探索你的数据 —— 包括索引、字段映射、字段类型 —— 然后规划可视化内容并调用 manage_dashboard。

每个面板都会经过独立流水线：图表类型选择、ES|QL 生成、可视化配置以及验证。我们将这一流程从主 agent 线程中隔离出来 —— 因为每个面板的可视化构建都需要多次模型调用，如果将这些内容混入主上下文，会导致上下文窗口膨胀并干扰推理过程。

在 manage_dashboard 内部，所有面板会并发构建，然后按顺序重新组装。最终结果是一个包含嵌入式面板的完整仪表板 —— 不会出现孤立的可视化内容，也不会有同步问题。

为什么我们将可视化创建移入 dashboard tool 内部

我们最初的方法是使用单独的 create_visualization tool —— 每个面板调用一次，然后再将每个 attachment 交给 dashboard tool。它确实能工作，但每个可视化都需要单独的 tool 调用、独立生命周期以及显式交接。更糟糕的是，在对话中编辑某个可视化后，并不会同步更新仪表板中的面板，这让用户感到困惑。

后来我们将可视化创建直接整合进 manage_dashboard。相同的并行工作流依然存在，但面板会直接组装进仪表板结构中，而不再需要中间 attachment。调用次数更少，没有同步问题，也只有一个统一生命周期。

独立可视化依然可以正常工作 —— 你仍然可以通过 attachment 引用将已有图表加入仪表板 —— 但对于从零开始构建而言，内联创建是更简洁的路径。

对于安全团队

SOC 分析师和检测工程师在调查过程中无法承受来回切换到仪表板编辑器所带来的时间成本。借助 AI Chat，你可以请求按规则类型、主机或 MITRE tactic 统计告警数量，并在大约一分钟内直接在当前线程中看到结果。随着威胁狩猎的深入，你还可以继续叠加更多面板 —— 例如进程执行异常、网络连接、时间线对比 —— 而无需中断上下文。

完成后直接保存即可。这个仪表板会成为事后事件复盘的参考资料、下一位分析师的起点，或者每周威胁简报的基础 —— 无需再次解释背景。

想了解安全团队如何利用仪表板创建功能以及其他最近发布的 AI Chat 能力，请阅读这篇博客文章。

对于可观测性与站点可靠性工程师（SRE）

当某个服务在凌晨 2 点发生性能下降时，没有时间从零开始搭建仪表板。借助 AI Chat，SRE 可以直接描述所需指标（例如按服务划分的 p99 延迟、与部署事件对比的错误率、最近一小时的 Pod 重启情况），并在大约一分钟内于调查线程中获得完整仪表板。随着问题逐渐明朗，agent 还可以逐步优化它：添加面板、调整时间窗口、按区域拆分。

保存仪表板后，它会立即在 war room 中可用 —— 所有参与 incident bridge 的成员都能看到相同的面板与分析视角。事件结束后，它还会成为 postmortem 的基础。

接下来会有什么

我们正在持续优化 token 使用效率、增强全屏交互体验、扩展更多面板支持，并不断提升整体质量。技术预览阶段正是确定产品优先级的最佳时机 —— 如果你发现缺少某些功能，请通过顶部菜单中的 “Submit feedback” 图标告诉我们。

立即体验

升级到 Elastic 9.4（或开始试用），以全屏模式打开 AI Chat，并在真实调查场景中体验它。让 agent 绘制你当前关注的指标图表，然后继续请求下一层拆解分析。当整个分析链路完整成立后，即可保存并分享 —— 相同的面板、相同的分析框架，无需重复解释。该功能需要 enterprise license（立即开始）。

本文中描述的任何功能或特性的发布时间与交付安排，均由 Elastic 自行决定。当前尚未可用的功能或特性，可能无法按时交付，甚至可能不会发布。

这篇内容对你有多大帮助？

原文：https://www.elastic.co/search-labs/blog/ai-dashboard-generation-elastic-agent-kibana