MCP 应用改变了答案的呈现形态。工具现在可以在返回文本摘要的同时提供交互式 UI，而宿主端（如 Claude Desktop、Claude.ai、VS Code Copilot、Cursor）则会直接在对话中进行内联渲染。模型利用保留的精炼文本进行逻辑推理。用户在聊天窗口旁就能获得一个实时可交互的界面。

三个特性让这种集成方式区别于“返回 URL 的 webhook”：

• 上下文保留。UI 就在对话中。无需切换标签页，无需切换上下文。

• 双向数据流。UI 可以调用 MCP 服务器上的工具以获取最新数据，宿主端也能将智能体的新结果推送回 UI，无需额外的 API 层或复杂的身份验证基础设施。

• 沙盒化的信任边界。MCP 应用在由宿主管控的 iframe 中运行。它们无法访问父页面、读取 Cookie，也无法逸出其容器。

安全运营依托于告警分类、调查图谱和 Attack Discovery，AI 智能体可将数百条告警关联为少数几条攻击链。可观测性意味着分布式链路追踪和时间序列下钻。在 Kibana 中构建意味着采用网格化的仪表板布局。如果将这些内容平铺成文字，就会失去其有用之处。我们为这三个平台都构建了 MCP 应用，并将它们一起开源，这样同一个对话就可以从分类队列转移到依赖关系图，再到实时仪表板，而无需离开聊天界面。

三个参考应用中的每一个都是一个为多个交互视图提供服务的 MCP 服务器，而不是一组独立的产品。仅安全应用就提供六个仪表板，它们共享同一个服务器框架、同一个工具可见性模型和同一个宿主桥接层。这种模式虽然轻量，但其提供的交互面正是价值倍增之处。

Elastic Security MCP 应用

为什么这对 SOC 很重要

当智能体告诉 SOC 分析师“主机 host-314 上有 47 条告警，这是摘要”时，它实际上并未开始实质性工作。它只是指出了工作的起点。真正的工作发生在告警列表、进程树、调查图谱和案例记录中。您无法仅凭一段文本就完成这些实际工作。

安全 MCP 应用程序返回了工作流本身。分析师提示代理，代理在聊天中返回了一个交互式仪表板，分析师可以在其中深入查看警报、运行威胁搜寻、关联攻击链并打开案例，所有这些操作都不会丢失对话的线索。由于所有发现、查询和案例都会回写到 Elasticsearch，同样的调查会在 Kibana 中等待，分析师可以在对话结束后接着处理。

六个交互式仪表板

Elastic Security MCP 应用提供了六个交互式组件，分别对应 SOC 的核心工作流。每个都是一个 React UI，当代理调用相应工具时，会在对话中以内联方式渲染：

工具

功能说明

交互式 UI

告警分类

获取、筛选和分类安全警报

严重程度分组、AI 判定卡、进程树、网络事件

Attack Discovery

基于 AI 关联的攻击链分析，支持按需生成

攻击叙事卡片，包含置信度评分、实体风险，MITRE 映射

案例管理

创建、搜索和管理调查案例

包含告警、可观测对象、评论选项卡和 AI 操作的案例列表

检测规则

浏览、调优和管理检测规则

带 KQL 搜索、查询验证和噪声规则分析的规则浏览器

威胁搜寻

支持实体调查的 ES|QL 工作台

查询编辑器、可点击实体和调查图表

样例数据

针对常见攻击场景生成 ECS 安全事件。

带有四条预设攻击链的场景选择器

每个工具都会返回一个紧凑的文本摘要，供模型进行推理，同时分析人员可以在交互式 UI 上操作。UI 还可以通过 MCP 主机桥在幕后获取最新数据。完整的工具模型和桥接 API 位于 代码库的架构文档。

该应用还随附 Claude Desktop 技能，以及 SKILL.md 文件，用于指导代理何时以及如何使用各个工具。从最新版本下载预构建的技能 zip 压缩包。

从告警到案例

四项技能覆盖了 SOC 的核心工作流。每个技能都会接收一个提示，调用一个工具，并返回一个交互式仪表板，以及供模型推理的文本摘要。分析师的一天通常从告警队列开始。

对告警进行分类。让代理按主机、规则、用户或时间窗口进行分类。Alert Triage 技能会返回一个 AI 判定仪表板，位于原始警报列表上方。每个检测规则都有一个判定，将该规则的活动分类为良性、可疑或恶意，并附有置信度分数和推荐操作。点击任意警报即可打开包含进程树、网络事件、相关警报和 MITRE ATT&CK 标签的详细视图。无需在 AI 会话与 Kibana 告警仪表板之间反复来回，一切操作都在对话中实时完成。

开展威胁搜寻。让代理在您的索引中执行威胁搜寻。Threat Hunt 技能会返回一个 ES|QL 工作台，该工作台预先填充并自动执行了查询，结果中的每个实体均可点击进行深入查看。模型在表格下方写了一个简短的读数：哪些地方异常、哪些内容彼此关联、哪些值得进一步查看。然后，它会给出下一步切入点：要么更深入地研究威胁，要么在 MCP 应用中开始一项新技能，以补充迄今为止所做的工作。与之完美契合的是启动 Attack Discovery，从而为您已深入探究的告警和目前搜寻到的威胁收集更多上下文信息。

运行 Attack Discovery。Attack Discovery 技能会触发 Attack Discovery API，并返回按优先级排序的发现列表。每个发现都是一组相互关联的警报，这些警报会被串联成一条攻击链，并会在前面优先展示 MITRE 策略、风险评分、置信度标签，以及受影响的主机和用户。智能体的摘要会按相同的排名顺序显示在发现下方，而对话现在已包含采取行动所需的一切：搜寻查询、分类决策、关联的链条，均已为下一步做好准备。

无需离开聊天窗口即可创建案例。批量批准发现项，或让代理为特定告警创建案例。案例管理技能会根据批准的发现项创建一个案例（附带源告警，继承自攻击链的 MITRE 策略），并以内联方式渲染实时案例列表。点击案例以查看其详细视图，其中包含一行 AI 操作按钮：总结案例、建议下一步、提取 IOC 和生成时间线。每个按钮都会将一个结构化的提示放回聊天中，这样代理就能获取案例上下文，无需重新说明上下文。代理的摘要位于案例列表下方，涵盖了完整的事件响应队列，包括刚创建的案例和仍需处理的早期发现。

本演练中的每一步都运行相同的循环：收到提示后，技能接收提示，工具返回一个简洁的文本摘要供模型进行推理，同时返回一个交互式用户界面（UI）供分析师操作。形成端到端的 SOC 流程——搜寻、分类、关联、创建案例，并推动下一步。模型会在每一步中保留会话上下文。单独调用其中任何一个，它仍然是完整的仪表板，指向您指定的数据切片。无论哪种方式，工作都会在对话中积累；没有标签切换，没有复制粘贴，没有交接。

另外两项技能补全了这个应用：检测规则浏览器，用于调整噪声较高的规则；样本数据生成器，用于在新集群上生成逼真的 ECS 事件。后续文章将深入探讨全部六个方面：调查图谱、攻击流程画布和端到端演练。

运作方式

每个 MCP 应用都是一个小型 Node.js 服务器，其工具会返回供模型推理的精炼文本摘要，以及由宿主内联渲染的 React UI。由于它是基于开放的 MCP 应用程序规范构建的，因此同一服务器可在任何兼容主机上运行——有关完整设计，请参阅软件仓库的架构文档。

试用

需要启用 Security 的 Elasticsearch 9.x，以及用于案例、规则和攻击发现的 Kibana。最快的方式是使用最新版本中的一键式 .mcpb 安装包——在 Claude Desktop 中双击它，系统会提示您输入 Elasticsearch URL 和 API 密钥。Cursor、VS Code、Claude Code、Claude.ai 和从源代码构建的设置指南都在软件仓库中。

Elastic Search MCP 应用程序：通过对话构建的仪表板

Kibana 用户都深知创建仪表板的繁琐：必须停下工作，打开 Kibana，选择索引、字段和可视化效果，最后再调整保存。一个图表还没显示出来，就已经经历了五次上下文切换。

新的 example-mcp-dashbuilder 参考应用将其简化为一个提示。要求代理“为我构建一个包含收入指标、订单趋势和类别细分的仪表板”，而且仪表板会在对话中返回，无需切换标签。

在该提示后，代理通过 ES|QL 探索您的 Elasticsearch 数据，并选择与数据相匹配的图表类型：用于比较的条形图、用于趋势的折线图、用于 KPI 的指标卡，以及用于二维模式的热力图。它在 Kibana 的 48 列网格上布置面板，使用 Elastic UI Borealis 主题，结果是完全交互式的：您可以直接在聊天中拖动、调整大小和将面板分组到可折叠的部分中。当仪表板看起来合适时，只需一次工具调用即可将其导出到 Kibana，同时保留 ES|QL 查询和自定义颜色。您还可以将现有的 Kibana 仪表板导入到聊天中，以便进行 AI 辅助编辑。

其原理与 Security 应用相同：当产物本身就是产品时，在对话中直接返回它，就能打通从描述需求到看到结果之间的闭环。

在底层，它遵循相同的 MCP 应用模式。Node.js 服务器注册一个面向模型的 view_dashboard 工具，以及一组仅供应用内部调用、由 UI 直接调用的工具（数据获取、布局持久性、时间字段检测、导出/导入）。仪表板视图本身是一个单一的独立 HTML 文件，与 vite-plugin-singlefile 捆绑在一起，并作为 MCP 应用资源提供。开发者复刻（fork）该代码库后，会获得与 Security 应用中相同的服务器 shell 和主机桥，但面向不同的任务场景。example-mcp-dashbuilder README 文件包含了完整的架构和图表类型参考。

Elastic Observability MCP 应用

第三个参考应用 Elastic Observability MCP 应用则是针对 SRE 场景解决这一“交互形态”问题的对应版本。当生产环境中出现故障时，值班工程师需要的答案不是一张图表，而是由 K8s 指标、APM 拓扑、ML 异常、风险评估等信息拼接而成的诊断。答案的形式是一个因果故事：什么失败了，为什么，什么取决于它，以及下一步该怎么做。

六种支持可观测调查工作流的工具

工具

依赖关系

它的功能是什么

观测

通用

瞬时 ES|QL + ML 异常访问原语——执行一次查询、实时采样指标，或一直等待直到阈值触发或异常出现。

管理警报

通用

创建、列出、获取和删除 Kibana 自定义阈值告警规则。省略 Kibana URL 以运行为只读模式。

ML 异常

ML 作业

查询 ML 异常记录，并打开内联的异常说明视图。

apm-health-summary

Elastic APM

基于 APM 遥测的集群级健康汇总；在可用时还会纳入 K8s 和 ML 上下文的各层信息。

apm-service-dependencies

Elastic APM

服务依赖图——上游/下游、协议、调用量。

k8s-blast-radius

Kubernetes 指标

节点故障影响——完全中断、性能降级、不受影响、重调度可行性。

集群健康状况汇总

询问“哪里出故障了？”或“给我一份状态报告”，即可一目了然地掌握全局：包括整体健康状态标识、性能下降的服务及其原因、内存占用最高的 pod、异常严重程度分解，以及服务吞吐量——全部在一个内联视图中。这是当您感觉有些不对劲，但又不知道该从哪里入手的时候的起点。视图会根据您的部署支持的内容进行调整。APM 为您提供服务运行状况。Kubernetes 指标添加了 pod 和 Node 上下文。ML 作业也会将异常纳入其中。

服务依赖关系图表

问“哪些服务会调用 checkout？”或者“显示拓扑结构”并获取分层依赖图表——上游调用者、下游依赖项、协议、每条边的调用量和延迟。让我们让 Claude “给我看看前端的服务依赖关系”：

缩放、平移和悬停以获取理解复杂服务关系所需的所有详细信息：

利用影响半径评估风险

询问“如果我的 k8s Node 宕机会发生什么？”并获取一个辐射状影响图：目标 Node 位于中心，完全中断的部署用红色表示，性能下降的用琥珀色表示，未受影响的用灰色表示。浮动摘要卡显示有风险的 pod 和重新调度的可行性。单副本部署被标记为单点故障。

观测

代理访问 Elastic 的主要方式——一个工具，三种模式，满足三种不同需求。说“CPU 当前情况如何？”，它会运行一次 ES|QL 查询并返回一个表。说“显示我接下来 60 秒的前端延迟”，它会实时采样该指标，并原地更新图表。说“当内存降到 80MB 以下时告诉我”或“在接下来 10 分钟内留意任何异常”，它会一直等待，直到条件触发或时间窗口结束。视图可根据模式进行调整：用于单次查询的结果表、用于采样和阈值条件的带当前/峰值/基线统计数据的实时趋势图，以及用于异常模式的按严重程度评分的触发卡。

运作方式

与 Security 和 Search 应用相同的 MCP 应用模式：一个 Node.js 服务器，六个面向模型的工具，对应六个单文件视图资源。工具按部署后端（通用、APM 依赖、K8s 依赖、ML 依赖）进行分组，因此代理和用户都可以提前知道哪些工具适用于特定部署，而不是在调用时发现功能缺口。MCP 应用还包含一个示例的 Agent Builder 工作流：k8s-crashloop-investigation-otel 可以在 Kubernetes 告警触发时启动，并在您打开任何仪表板前返回结构化的根因摘要。

代理化技术栈，交互式

关于此模式的三个属性值得直接说明。首先，工具结果不再是工作的终点，而是工作的起点：对话返回的是您可以采取行动的接口，而不是您必须采取行动的摘要。其次，同一个智能体、同一个模型上下文和同一个对话线程，现在可以在 Security、Search 和 Observability 界面之间顺畅切换，而无需离开对话。第三，这之所以可行，是因为 Elasticsearch 和 Kibana 已经公开了 API。MCP 应用程序是我们已提供的产品功能之上的一个轻量级的交互层。

Attack Discovery 已经为该应用内的关联发现视图提供支持。在堆栈内部，同样的代理模式进一步延伸：Elastic 工作流自动执行确定性步骤（丰富实体、创建案例、隔离主机），而 Agent Builder 则对数据进行推理并调用这些工作流作为工具。MCP 应用将同一套安全界面引入外部对话；工作流和 Agent Builder 则在技术栈内部对其进行扩展。不同的入口点，底层是相同的 Elastic API。

试用：

• 安全性：example-mcp-app-security

• 搜索与仪表板： example-mcp-dashbuilder

• 可观测性：example-mcp-observability

还没有 Elasticsearch 集群吗？开始免费试用 Elastic Cloud。如需进一步了解安全应用背后的构建模块，请参阅相关 Security Labs 文章：Elastic 工作流和 Agent Builder、Agent 技能，以及攻击发现。

这就是为什么我们要开源 Elastic Agent Skills，即 Elasticsearch、Kibana、Elastic Observability 和 Elastic Security 方面的原生平台专业知识。您可以把它们添加到您已经使用的智能体运行时，把您的智能体从那种只会猜大量语法的“通才”提升成为一个具有专业知识的智能体，比如能像 Elastic 自己的工程团队一样使用许多架构标准。最初的技术预览版本侧重于与 Elastic Cloud Serverless 具有最大兼容性的技能，但后续版本将迅速发展，以包含对旧堆栈版本的更好支持。

此外，Elastic 正在从两头解决这个问题。对于 Elastic 平台上的智能体，Elastic Agent Builder（现已正式发布）允许您创建和交互那些继承了您的数据访问控制的 AI 智能体，使用内置的搜索和分析工具，并结合上下文协同仪表板、警报和调查开展工作。我们正在努力确保在 Elastic 平台上提供卓越的智能体体验。但并非每个智能体都与 Elastic 兼容。您的团队可能已经在使用 Cursor、Claude Code 或其他运行时，这些智能体也需要正确理解 Elastic。这时 Agent Skills 就派上用场了。

智能体在专业平台上为何面临重重困难

大语言模型 (LLM) 是非常强大的通才。由于其训练数据包含丰富的示例，它们可以编写 Python 代码、解释 Kubernetes 清单，并重构 React 组件。但是，当涉及到平台特定的工作时，例如涉及专有查询语言、深度 API 接口和特定领域的最佳实践，它们的不足之处是可以预见的。

对于 Elasticsearch 来说，差距具体体现出来：

• Elasticsearch 查询语言 (ES|QL) 是一个新领域。LLM 主要使用 SQL 进行训练，但 ES|QL 是一种管道化查询语言，具有不同的语法、不同的函数和不同的语义。智能体经常编写看似合理但无法解析的查询。它们会混淆 WHERE 和 | WHERE，编造不存在的函数，并完全忽略了基于管道的组合模型。

• API 接口表面范围广且具有专业深度。Elasticsearch、Kibana 和 Elastic Security 在搜索、摄取、告警、检测规则、案例管理、仪表板等多个领域有数百个 API。一个只配备一般训练数据的智能体必须猜测要调用哪个终端、请求正文是什么样子，以及如何处理响应。它经常会猜错，削弱了人们对它的信任。

• 最佳实践不在训练数据中。何时应该使用 semantic_text 而不是自定义嵌入管道？如何构建 10GB CSV 的摄取管道？MITRE ATT&CK 技术的正确检测规则语法是什么？通用智能体在默认情况下不会加载经过整理、结构可靠的 Elastic 特定知识。它们需要查找这些知识，即使找到了，原始文档也并不总是包含熟练从业人员所具备的判断和最佳实践。

结果就是，开发人员花在修复智能体输出上的时间比他们自己编写代码所需的时间还多。这不是任何人愿意接受的体验。

代理技能：Platform 知识，专为代理人员量身定制

Agent Skills 是包含指令、脚本和参考资料的独立目录，智能体运行时可以动态加载这些目录。当技能处于活动状态时，智能体可在正确的时间获得正确的上下文：查询语法、API 模式、验证逻辑、实例，因此它可以在第一次尝试时正确完成任务。

每个技能都遵循开放的 agentskills.io 规范：一个文件夹中包含一个 SKILL.md 文件，其中包含元数据和结构化说明。无专有格式，无锁定。技能可在智能体运行时中使用，包括 Cursor、Claude Code、GitHub Copilot、Windsurf、Gemini CLI、Cline 和 Codex 等。

v0.1.0 初始版本包含什么内容

Elastic Stack 的第一组技能跨越五个领域：

• 与 Elasticsearch API 交互（搜索、索引、集群管理）

• 构建和管理 Kibana 内容，例如仪表板、警报、连接器等

• Elastic Observability 的领域专业知识

• Elastic Security 的领域专业知识

• 在 Agent Builder 中创建高效的智能体

技能可组合

技能不是单一的。它们采用的是模块化设计。您的智能体仅加载与当前任务相关的技能。正在编写 ES|QL 查询？ES|QL 技能将激活。需要从这些结果构建仪表板？仪表板技能将激活。要评估应用程序的健康状况？服务健康技能将发挥作用。要调查安全警报？随着调查的深入，分流技能将逐步衔接到案件管理和响应技能。

这种可组合性意味着您不需要一个庞大的、试图涵盖一切的单一提示。每种技能都完全符合其领域所需的语境，不多也不少。

适用于构建搜索和 AI 应用程序的开发人员

如果您正在将数据加载到 Elasticsearch、编写查询或迁移索引，技能可以缩短生成代码、遇到错误和搜索文档以查明问题所在的周期。

让您的智能体加载一个 CSV 文件，它会使用流式摄取工具来处理背压并从数据中推断映射。它不是那种手动编写的 _bulk 循环，不会在处理第一个大文件时就耗尽内存。让它使用 ES|QL 进行查询，它会发现您的实际索引名称和字段模式，然后编写具有正确语法、适当聚合和版本感知功能选择的有效管道查询，而不是需要三轮调试的 SQL 风格猜测。让它跨集群重新索引，它会遵循完整的操作工作流：用显式映射创建目的地，调整吞吐量设置，异步运行作业，完成后恢复生产设置，而不是简单地调用 _reindex，跳过有经验的操作员会遵循的一半步骤。

您得到的不是一个给您一个似是而非的起点，让您不得不去解决的智能体，而是一个编码了操作规范，让输出真正有效的智能体。

使用 Elastic Agent Skills 的影响示例

Eval

技能引发了哪些改变

es-audit-query-failed-logins

使用技能中的审计日志查询模式，而不是通用搜索

es-authz-role-mapping-ldap

输出正确的角色映射 API 调用结构

esql-basic-query

编写了 ES|QL 管道语法以替代查询 DSL

esql-error-handling

先确定模式，而不是猜测字段名称

esql-schema-discovery

从未猜测过索引名称

es-ingest-csv-with-infer

单独使用 --infer-mappings，避免与 --source-format csv 组合使用，因为后者会导致索引为空

es-ingest-json-file

采用了稳健的摄取方法，能够处理大文件

es-reindex-local-async

首先创建目标索引，副本数为 0，刷新间隔为 “-1”，然后异步重建索引。基线跳过了任何准备工作

es-security-403-privileges

按照技能诊断工作流程，而不是通用建议，处理特权错误

面向安全团队

安全团队每天都重复相同的操作工作流：对警报进行分流、调整检测规则、管理案例。Agent Skills 可对程序知识进行编码，让您的 AI 智能体能够正确执行这些工作流，以正确的顺序调用正确的 API，并使用正确的字段名称。如需通过实践操作指南，在不离开 IDE 的情况下从零开始构建一个完整的 Elastic Security 环境，请参阅 从您的 AI 智能体开始使用 Elastic Security。

面向可观测与运维团队

针对 Elastic Observability 的全新 Agent Skills 可以减轻对复杂系统进行检测、管理 SLO、筛选复杂数据以及评估服务健康状况的操作难度。将 Elastic 原生专业知识直接嵌入 AI 智能体中，可以让团队通过简单的自然语言执行复杂的可观测工作流。这使 SRE 和运营团队能够更快地解决事件，并更轻松地维护可靠的系统。阅读这篇博文了解详情。

开源、开放规范、社区驱动

我们根据 Apache 2.0 许可协议发布 Agent Skills，因为我们认为智能体知识应该是开放的。技能所遵循的 agentskills.io 规范是一项开放标准，不是 Elastic 的专有格式。我们希望这些技能成为社区共同努力的成果，而不是封闭的生态系统。

大局的一部分

Agent Skills 是旨在使 Elasticsearch 成为最适合智能体使用的数据平台的更广泛计划的一部分。对于在 Elasticsearch 平台上运行的智能体，Agent Builder 还能更进一步，继承数据的访问控制和权限，提供用于搜索和分析的内置和自定义工具，并让用户在仪表板、警报和调查的上下文中与智能体进行交互。最后，Agent Builder 即将推出对技能的支持，允许开发者灵活地利用 Elastic Agent Skills 以及来自任何其他来源的技能，在 Elasticsearch 平台上实现安全、上下文增强的聊天和自动化。

对于部署在其他地方的智能体，我们正投入努力，建设开放的生态系统：

• 模型上下文协议 (MCP) 服务器扩展：扩展 Agent Builder 中的 MCP 终端，在当前搜索、ES|QL 和索引操作之外提供更多工具。

• 身份验证改进：使代理能够更轻松地安全连接，目标是消除手动复制粘贴 API 密钥的操作。

• LLM 可读文档：发布 llms.txt 和 AGENTS.md 文件，让智能体能够自行发现和理解 Elastic API。

• 用于智能体工作流的命令行接口 (CLI)：命令行工具，使连接管理和常见操作更适合智能体使用。

技能是您今天能使用的层面。其余的功能即将到来。

开始使用

开始之前：AI 编码智能体使用真实凭证、真实 shell 访问权限进行操作，通常还拥有运行它们的用户的全部权限。当这些智能体用于安全工作流时，风险会更高：您相当于是将检测逻辑、响应操作和敏感遥测数据的访问权限交给了一个自动化系统。每个组织的风险状况都是不同的。在启用 AI 驱动的安全工作流之前，请评估智能体可以访问哪些数据、可以采取哪些操作以及如果出现意外行为会如何。

将 Elastic Agent Skills 安装到您的智能体运行时：

npx skills add elastic/agent-skills

这会自动检测您已安装的智能体运行时，并将技能放置在正确的配置目录中。之后，您的智能体会自动获取这些技能。

您还可以直接浏览技能目录，然后将技能文件夹复制到智能体的配置目录中，从而手动安装各个技能。

还没有 Elasticsearch 集群吗？开始免费试用 Elastic Cloud。您只需一分钟就能获得一个完全配置的环境。

探索项目：

• Agent Skills 存储库

• agentskills.io 规格

• Elasticsearch 文档

• Elastic Cloud 免费试用

我们都见证了 AI 智能体的兴起。它们在总结文本、编写代码片段以及基于文档回答问题方面表现出色。但对于我们从事 DevOps 和网站可靠性工程 (SRE) 的人来说，一直存在一个令人沮丧的限制。大多数智能体都困于呼叫中心模式，这意味着它们可以阅读、思考和聊天，但无法触及它们本该管理的基础架构。

在最新的黑客马拉松项目中，我们决定打破这一限制。

我们构建了增强型基础架构：这是一个基础架构协同助手，它不仅能为您提供建议，还能创建、部署、监测和修复您的实时环境。

问题：复制、重新格式化、粘贴

标准智能体在孤立状态下运行。如果您的应用宕机，给公司造成 500 万美元的损失，标准智能体可以为您朗读如何修复的应急预案手册。但您仍然需要亲自动手。您只能复制代码，根据环境重新格式化，然后粘贴到终端中。

我们需要一个能理解谈论 Kubernetes 和配置 Kubernetes 之间区别的智能体。

引擎：什么是 Elastic Agent Builder？

我们并不是从零开始构建的。我们是基于 Elastic Agent Builder 进行构建。对于不熟悉的人来说，Elastic Agent Builder 是一个旨在快速开发智能体的框架，它充当大型语言模型 (LLM)（在我们的演示中，我们使用了 Google Gemini）与存储在 Elasticsearch 中的私有数据之间的桥梁。

Agent Builder 可以通过将 AI 与内部数据（如文档或日志）相结合，用于对话式 AI。但它最强大的功能是能够分配工具。这些工具允许 LLM 跳出聊天接口，执行特定任务。我们意识到，如果将此功能发挥到极致，我们可以将 Agent Builder 转变为一个自动化引擎。

使其运行：构建第一个版本

在项目启动之初，我们就知道要让智能体能够改变外部世界。我们当时有个想法：如果我们开发一些“运行器”软件（在主机上运行智能体能想到的任何命令）会怎样？然后：如果运行器、Elastic Agent Builder 和用户进行三方通话会怎样？

我们首先构建了一个 Python 项目“增强型基础架构运行器”，其本质是一个 while(true) 循环，每秒查询 Elastic Agent Builder 对话 API，并检查我们创建的特殊语法：

然后我们更新了提示，以教会它我们新的工具调用语法。Bill 是 FastMCP 的维护者，FastMCP 是在 Python 中构建模型上下文协议 (MCP) 服务器的最常用框架。他开始尝试使用 FastMCP 客户端配合这个新的运行器软件，来挂载 MCP 服务器并使其工具对运行器可用。当智能体看到这个时，它会执行工具调用，并将结果 POST 返回到对话中，就像用户发送了结果一样。这会触发 LLM 对结果作出回应，然后我们开始了！

这很好，但存在两个主要问题：

1. 代理会将所有这些 JSON 直接注入到与用户的对话中。

2. 通过对话 API 能看到消息的最早时间点是一个对话轮次完成时（即 LLM 回复时）。

因此，我们着手研究如何将其移至后台。

然后我们切换到为智能体提供一个名为 call_external_tool 的工具，该工具有两个参数：tool_name 和字符串化的 JSON 工具参数。这个外部工具调用不会返回任何内容，但重要的是，它会在对对话 API 的 GET 请求中可见。然后，我们授予运行器直接将文档写入 Elasticsearch 的权限，Elastic Agent Builder 智能体可以根据需要检索这些文档。智能体总是在响应用户消息的情况下运行，所以我们需要用一个用户消息来启动智能体，这样它才会去查找结果并继续处理。因此，我们让智能体在聊天记录中插入一条简短的消息，以继续对话：

所以现在我们有了外部工具调用。然而，由于上面提到的第二个问题，我们不得不去掉最后的启动部分。否则，每个外部工具调用都需要一个完整的对话轮次来检索结果！

让它变得更好：介绍工作流

除了 Elasticsearch 查询语言 (ES|QL) 和索引搜索工具调用之外，Agent Builder 智能体还可以调用 Elastic 基于工作流的工具。Elastic 工作流提供了一种灵活且易于管理的方式来执行任意顺序和逻辑的操作。就我们的目的而言，我们只需要工作流做两件事：将外部工具请求存储到 Elasticsearch，并返回一个用于轮询结果的 ID。这产生了以下简单的工作流定义：

这样，运行器不再依赖将工具调用请求写入对话，而只需轮询 Elasticsearch distributed-tool-requests 索引中的新外部工具请求，并使用提供的 execution.id 将结果报告回另一个 Elasticsearch 索引。

这消除了上述两个主要问题：

1. 对话历史记录不再被外部工具调用的负载所充斥。

2. 由于运行器轮询的是 Elasticsearch 索引而非对话历史记录，它们不会因需要等待对话轮次完成以使外部工具请求可见而被阻塞。

第二点有一个巨大优势：外部工具调用的处理在智能体的思考阶段就开始了（而不是在对话轮次完成之后）。这允许我们在系统提示中指示 LLM 轮询外部工具结果，直到结果可用，从而消除了启动消息的需要。总的来说，这样做的好处是对话感觉更加自然：LLM 可以在单个对话轮次中处理多个外部工具请求（而不是每个工具请求需要一个对话轮次），因此可以一次性完成更复杂的用户请求。

将所有内容整合到一起

为了弥合 LLM 与服务器机架之间的鸿沟，我们利用 Agent Builder 的工具功能开发了一种特定的架构：

1. 增强型基础架构运行器：我们在目标环境（服务器、Kubernetes 集群、云账户）中部署了轻量级运行器。这些运行器直接连接到 Elastic，使用受保护的终端和仅每个运行器可用的密钥。

2. ES|QL 检索：该协同助手使用 Elastic 的 ES|QL 执行混合搜索。它不仅搜索知识，还会搜索功能。它查询已连接的运行器，查看哪些工具可用（例如 list_ec2_instances、install_helm_chart）。

3. 工作流执行：一旦智能体决定行动方案，就会创建一个结构化的工作流。

4. 反馈循环：运行器在本地执行命令并将结果报告到 Elasticsearch。协同助手从索引中读取结果，并决定下一步。

演示：从故障到可观测性

在视频中，我们展示了两个不同的场景，彰显了该架构的支持。

场景 1：DevOps 开发运维救援

我们从一位用户因 Kubernetes 集群中的盲点导致 500 万美元宕机而惊慌失措的场景开始。

• 请求：“如何确保这种情况不再发生？”

• 行动：该智能体不只是提供了教程。它识别了集群，创建了必要的命名空间，生成了 Kubernetes 密钥，安装了 OpenTelemetry Operator，并立即提供了一个指向实时 APM 仪表板的链接。

• 结果：用户无需编写一行 YAML，即可获得完整的 Kubernetes 可观测和应用见解。

场景 2：安全交接

基础架构安全的一条基本规则是，您无法保护看不到的东西。在执行我们的 DevOps 开发运维救援时，智能体看到了改善环境安全的机会。

借助之前一次与 Elastic Observability 相关调查触发的警报，我们展示了安全从业者如何直接与其基础架构聊天：首先，列举云环境中的资产和资源；其次，部署确保环境安全的必要工具。

• 发现：协同助手为安全从业者列举了 AWS 资源，并识别出一个关键缺口：一个 Amazon Elastic Compute Cloud (EC2) 实例和一个 Amazon Elastic Kubernetes Service (EKS) 集群的公共终端缺少终端保护。

• 修复：只需简单批准，协同助手就将 Elastic Security 扩展检测与响应 (XDR) 和云检测与响应 (CDR) 部署到了易受攻击的资产上，实时保护了环境。

• 结果：已部署的 AWS 资产和资源得到了保护，实现了完整的运行时安全。

未来：增强一切

这个项目证明 Elastic Agent Builder 可以成为分布式运维的中心大脑。我们不仅限于基础架构。我们的运行器技术可以驱动：

• 增强型合成：诊断全球运行器中的 TLS 错误。

• 增强型开发：创建拉取请求并在前端服务上实现验证码。

• 增强型运维：在宕机期间自动重新配置 DNS 解析器。

亲自试用

我们认为，AI 的未来不仅仅是聊天支持，而是增强型基础架构。它关乎拥有一个可以与您并肩部署、修复、观测和保护的合作伙伴。

立即查看代码，并通过分布式运行器 (GitHub) 加上 Elastic Cloud Serverless 上的 Elastic Agent Builder 亲自尝试吧！

• 在 Elastic Cloud 上创建一个无服务器项目。

• 请将代码部署到运行器。

• 设置运行器。

• 配置您的 mcp.json。

• 启动运行器，它会自动创建您的智能体及其工具。

• 与能够进行推理、规划并在您的分布式运行器上执行操作的智能体聊天！

团队：Alex、Bill、Gil、Graham 和 Norrie