具有增强型基础架构的 Agent Builder

这不是空谈。我们正在付诸实践。

我们都见证了 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 对结果作出回应，然后我们开始了！

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

代理会将所有这些 JSON 直接注入到与用户的对话中。
通过对话 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 索引。

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

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

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

将所有内容整合到一起

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

增强型基础架构运行器：我们在目标环境（服务器、Kubernetes 集群、云账户）中部署了轻量级运行器。这些运行器直接连接到 Elastic，使用受保护的终端和仅每个运行器可用的密钥。
ES|QL 检索：该协同助手使用 Elastic 的 ES|QL 执行混合搜索。它不仅搜索知识，还会搜索功能。它查询已连接的运行器，查看哪些工具可用（例如list_ec2_instances、install_helm_chart)。
工作流执行：一旦智能体决定行动方案，就会创建一个结构化的工作流。
反馈循环：运行器在本地执行命令并将结果报告到 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 资产和资源得到了保护，实现了完整的运行时安全。