Agent Builder，超越聊天框：推出增强型基础设施

作者：来自 Elastic Alexander Wert, Bill Easton, Gil Raphaelli 及 2 more

了解 Elastic Agent Builder 与增强型基础设施，这是一款 AI agent，可实现增强操作、增强开发和增强合成。

Agent Builder 现已正式发布。通过 Elastic Cloud Trial开始使用，并在此查看 Agent Builder 的文档。

这不是空谈，我们在实践中做到了。

我们都见证了 AI agents 的崛起。它们非常擅长总结文本、编写代码片段，并根据文档回答问题。但对于我们从事 DevOps 和站点可靠性工程（SRE）的人员来说，这存在一个令人沮丧的限制。大多数 agents 都被困在呼叫中心范式中，这意味着它们可以读取、思考和对话，但无法操作它们本应管理的基础设施。

在我们最近的黑客松项目中，我们决定打破这个限制。

我们构建了增强型基础设施（Augmented Infrastructure）：一款基础设施副驾驶 agent，它不仅能提供建议，还能创建、部署、监控和修复你的实时环境。

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

标准 agents 在真空中操作。如果你的应用宕机并给公司造成 500 万美元损失，标准 agent 可以告诉你如何修复的操作手册。但你仍然需要自己动手。你必须复制代码、为你的环境重新格式化，然后粘贴到终端。

我们想要一个能够理解谈论 Kubernetes 与配置 Kubernetes 之间区别的 agent。

引擎：什么是 Elastic Agent Builder？

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

Agent Builder 可用于基于内部数据（如文档或日志）的对话式 AI。但其最强大的功能是能够分配工具。这些工具允许 LLM 超出聊天界面执行特定任务。我们意识到，如果将这个功能发挥到极限，就能将 Agent Builder 转变为一个自动化的强大平台。

让它工作：构建第一个版本

在项目开始时，我们就知道希望让 agents 能够改变外部世界。我们有了一个想法：如果我们构建一些 "runner" 软件（在主机上运行 agent 能想到的任何命令）会怎么样？然后：如果 runner、Elastic Agent Builder 和用户在一个三方通话中，会怎样？

我们首先构建了一个 Python 项目，Augmented Infrastructure Runners，本质上是一个 while(true) 循环，每秒查询一次 Elastic Agent Builder conversations API，并检查我们创建的特殊语法：

复制代码

{
	"tool_name": "my_tool",
       "tool_arguments": "\{stringified json arguments\}"
}

然后，我们更新了 prompt，以教它我们的新工具调用语法。Bill 是 FastMCP 的维护者，这是 Python 中最流行的用于构建 Model Context Protocol（MCP）服务器的框架。他开始使用 FastMCP 客户端配合这个新的 runner 软件来挂载 MCP 服务器，并让它们的工具可供 runner 使用。当 agent 看到这些时，它会运行工具调用，并将结果 POST 回对话，就好像用户发送了结果一样。这会触发 LLM 对结果作出响应，然后流程开始运行！

这非常棒，但存在两个主要问题：

Agent 会将所有 JSON 直接输出到用户对话中。
通过 conversations API 能看到消息的最早时间点是在一次对话轮次完成时（也就是 LLM 回复时）。

于是我们开始研究如何将这个过程移到后台运行。

然后，我们改为给 agent 一个名为 call_external_tool 的工具，带两个参数：tool_name 和字符串化的 JSON 工具参数。这个外部工具调用不会返回任何内容，但重要的是，它会在对 conversations API 的 GET 请求中可见。接着，我们允许 runners 直接向 Elasticsearch 写入文档，Elastic Agent Builder agent 可以根据需要检索这些文档。Agent 总是在响应用户消息时运行，所以我们需要用一条用户消息启动 agent，让它去查找结果并继续处理。因此，我们让 agents 在聊天中插入一条小消息以恢复对话：

于是我们有了外部工具调用。然而，由于前面提到的第二个问题，我们不得不去掉最后的启动部分。否则，每次外部工具调用都需要完整的一轮对话才能获取结果！

让它更强大：推出 workflows

除了 Elasticsearch Query Language（ES|QL）和索引搜索工具调用外，Agent Builder agents 还可以调用基于 Elastic workflow 的工具。Elastic workflows 提供了一种灵活且易于管理的方式来执行任意顺序和逻辑的操作。对于我们的场景，我们只需要 workflow 做一件事：将外部工具请求存储到 Elasticsearch，并返回一个 ID 用于轮询结果。这样就得到了如下简单的 workflow 定义：

复制代码

name: ai-tool-call
enabled: true
triggers:
  - type: manual
inputs:
  - name: runner_id
    type: string
  - name: tool_calls
    type: string

steps:
  - name: store_request
    type: elasticsearch.create
    with:
      index: distributed-tool-requests
      id: "{{inputs.runner_id}}_{{ execution.id }}"
      document:
        request_id: "{{ execution.id }}"
        runner_id: "{{inputs.runner_id}}"
        tool_call: "{{inputs.tool_calls}}"
        status: "unhandled"

  - name: output_result
    type: console
    with:
      message: "Called tool, with execution id: {{ execution.id }}. Use this ID to poll the results."

有了这个机制，runners 不再依赖将工具调用请求写入对话，而是可以直接轮询 Elasticsearch 的 distributed-tool-requests 索引以获取新的外部工具请求，并将结果报告到另一个 Elasticsearch 索引中，使用提供的 execution.id。

这解决了前面提到的两个主要问题：

对话历史不再被外部工具调用的 payload 混乱。
由于 runners 轮询的是 Elasticsearch 索引而非对话历史，它们不会因为需要完成一轮对话才能看到外部工具请求而被阻塞。

第二点的优势在于，外部工具调用的处理可以在 agent 的思考阶段开始（而不是等对话轮次完成后）。这允许我们在 system prompt 中指示 LLM 轮询外部工具结果直到可用，从而无需启动消息。总体效果是对话更自然：LLM 可以在单轮对话中处理多个外部工具请求（而不是每个请求需要一轮对话），因此能够一次性完成更复杂的用户请求。

整合全局

为了弥合 LLM 与服务器机架之间的差距，我们使用 Agent Builder 的工具能力开发了一个特定架构：

增强型基础设施 runners：我们在目标环境（服务器、Kubernetes 集群、云账户）内部署了轻量级 runners。这些 runners 直接连接到 Elastic，使用仅对各自 runner 可用的安全端点和 secret。
ES|QL 检索：copilot 使用 Elastic 的 ES|QL 执行混合搜索。它不仅搜索知识，还搜索能力。它会查询已连接的 runners，查看哪些工具可用（例如 list_ec2_instances、install_helm_chart）。
工作流执行：一旦 agent 决定行动方案，它会创建一个结构化 workflow。
反馈循环：runners 在本地执行命令，并将结果报告回 Elasticsearch。副驾驶从索引读取结果并决定下一步操作。

演示：从宕机到可观测性

https://www.bilibili.com/video/BV14azPBsEQD/

在视频中，我们展示了两个不同的场景，演示了该架构的强大能力。

场景 1：DevOps 救援

起因：用户因 Kubernetes 集群的盲点导致 500 万美元的宕机而惊慌失措。

请求："我如何确保这种情况不再发生？"
操作：agent 不仅提供教程，它还识别了集群、创建必要的 namespace、生成 Kubernetes secret、安装 OpenTelemetry Operator，并即时提供指向实时 APM 仪表板的链接。
结果：用户无需编写任何 YAML，就实现了完整的 Kubernetes 可观测性和应用洞察。

场景 2：安全交接

基础设施安全的基本规则是：看不到的无法保护。在执行 DevOps 救援时，agent 发现了提升环境安全的机会。

通过来自之前 Elastic Observability 调查的警报，我们演示了安全人员如何直接与基础设施对话：首先，枚举云环境中的资产和资源；其次，部署必要的工具以确保环境安全。

发现：Copilot 为安全人员枚举了 AWS 资源，并发现一个关键漏洞：一台 Amazon Elastic Compute Cloud（EC2）实例和一个 Amazon Elastic Kubernetes Service（EKS）集群的公共端点缺少端点保护。
修复：经过简单批准，副驾驶为易受攻击的资产部署了 Elastic Security 扩展检测与响应（XDR）和云检测与响应（CDR），实时保障环境安全。
结果：已部署的 AWS 资产和资源获得完整运行时安全保护。

未来：增强一切

该项目证明，Elastic Agent Builder 可以成为分布式操作的核心大脑。我们不仅限于基础设施。我们的 runner 技术还可以支持：

增强合成（Augmented synthetics）：诊断全球 runner 的 TLS 错误。
增强开发（Augmented development）：创建 pull request 并在前端服务上实现 CAPTCHA。
增强操作（Augmented operations）：在宕机期间自动重新配置 DNS 解析器。

亲自尝试

我们相信 AI 的未来不仅仅是聊天支持，而是增强型基础设施。它意味着拥有一个可以与你并肩部署、修复、监控和保护的伙伴。

查看代码并亲自尝试分布式 runner（GitHub）以及 Elastic Cloud Serverless 上的 Elastic Agent Builder：

在 Elastic Cloud 上创建一个 serverless 项目。
将代码部署到 runner。
设置 runner。
配置你的 mcp.json。
启动 runner，它将自动创建你的 agent 及其工具。
与一个能够推理、规划并在分布式 runner 上执行操作的 agent 对话！

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

原文：https://www.elastic.co/search-labs/blog/agent-builder-augmented-infrastructure