作者：来自 Elastic Sri Kolagani 及 Ziyad Akmal

使用 Elastic Agent Builder 和 Workflows 创建一个可自动执行 IT 操作的 AI agent，例如笔记本电脑更新。

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

---

在 IT 运维领域，context switching 是生产力的敌人。对于内部团队来说，像笔记本电脑更新或员工入职这样的简单请求，往往需要在多个门户之间切换、填写僵化的表单，并手动更新诸如 ServiceNow 之类的信息技术服务管理（ ITSM ）工具。

在最近的一次 DevFest 上，我们展示了如何弥合自然语言请求与结构化 IT workflows 之间的差距。通过结合 Elastic Agent Builder 和 Elastic Workflows，我们可以创建不仅能回答问题、还能执行复杂操作的 AI agents。

在这篇文章中，我们将深入介绍该演讲中的架构，重点讲解我们是如何构建一个自动化的 “Laptop Refresh” workflow 的。我们将演示如何配置一个 agent，用于收集用户需求，并触发服务器端自动化，直接与 ServiceNow APIs 进行交互。

观看完整解析：本文基于我们在 Google DevFest 上的演讲。你可以在此观看完整会议，查看实际演示过程。

架构：从对话到交付

注意：本文档中描述的技术实现是完整生产环境的精简版本。虽然所提供的架构图可作为实际部署的准确结构参考，但配套的文字说明和代码片段为了示例目的进行了简化，可能与线上实现中使用的最终复杂配置有所不同。

目标是将一个手动、表单密集的流程转变为对话式接口。用户无需浏览目录，只需告诉 AI assistant 他们需要进行笔记本电脑升级。

如上所示，整体流程由三个不同的层组成：

1）交互层（ ElasticGPT / Agent Builder）：用户通过由 ElasticGPT 驱动的界面进行自然交互。在后台，Agent Builder 负责处理对话，执行意图识别和 slot 填充，以结构化数据并协调与其他内部 systems 的交互。

• 意图识别
  • 机制： system prompt 指令。
  • 实现： agent 在 MISSION 声明中被明确告知其唯一目的。由于其作用范围严格限定为 IT 资源配置，因此无需“检测”其他意图。
    • 代码参考： MISSION： You are a specialized agent designed to collect complete employee onboarding information...
  • 约束：如果用户询问非 IT 主题（例如 “What is the weather?” ），MISSION 意味着 agent 应根据 large language model（ LLM ）的默认安全对齐策略，将对话引导回数据收集或直接拒绝。
• Slot 填充（数据收集）
  • 机制：分阶段对话流程。
  • 实现： DATA COLLECTION STRATEGY 将 slots 拆分为五个逻辑阶段，而不是一次性询问所有 slots。这可以避免前面提到的 context switching 疲劳。
    • 代码参考： PHASE 1： Personal information， PHASE 2： Employment Details，等等。
  • 校验： prompt 强制立即校验输入（例如 Validate inputs immediately ），在进入下一个 slot 之前充当把关机制。

2）自动化层（ Workflows ）：当 agent 收集到数据后，会触发一个 workflow。该 workflow 负责处理业务逻辑：检查设备资格、执行策略（例如 “Is the laptop > 3 years old?” ），以及发起 API 调用。

3）记录系统（ ServiceNow ）： workflow 直接对 ITSM 工具进行读写，以维护审计记录并启动实际交付流程。

步骤 1：配置 agent

第一步是使用 Agent Builder 定义整个流程的 “大脑”。我们需要一个严格限定在 IT 资源配置范围内运行的 agent。我们不想要一个通用聊天 bot；我们想要的是一个像乐于助人的同事一样、专注于数据收集的机器。

我们通过一个强健的 system prompt 来实现这一点。这个 prompt 规定了 agent 的运行协议，强制执行逐步的数据收集策略。

下面是我们使用的 prompt 优化结构。注意它如何强制校验，并通过逻辑分组问题来避免让用户感到不堪重负：

MISSION: You are a specialized agent designed to collect complete employee onboarding information for IT equipment provisioning.

OPERATING PROTOCOL:
0. On every new chat, send a welcome message, and directly jump to data collection.

1. DATA COLLECTION STRATEGY:
   - Use a step-by-step approach across 5 clear phases
   - Validate inputs immediately

2. CONVERSATION FLOW:
   PHASE 1: Personal Information (Name, Email, Phone)
   PHASE 2: Employment Details (Job Title, Department, Manager)
   PHASE 3: Location & Shipping (Address, Country)
   PHASE 4: Technical Setup (Laptop Type, Accessories)
   PHASE 5: Confirmation

...

6. SUCCESS COMPLETION:
   After all data is collected and validated, invoke the tool "laptoprefreshworkflow" with the JSON payload.

有关示例 system prompt 或指令，请参考此处。

通过明确指示 agent 在对话结束时以特定的 JSON 格式发送数据，我们可以确保输入内容与自动化层所期望的内容完全匹配。

第 2 步：自动化层（ Workflows ）

agent 提供意图和数据，而 Workflows 提供执行能力。

我们使用 YAML 配置来定义一个 workflow。这个 workflow 充当 AI agent 与 ServiceNow REST API 之间的桥梁，负责处理身份验证、数据获取以及下单流程。

下面是 workflow 的定义。我们已将代码优化为使用安全的变量来处理凭证，而不是将它们硬编码在代码中。

Workflow 输入

首先，我们定义 workflow 期望从 agent 接收的输入：

YAML
version: "1"
name: Submit Laptop Refresh Request
enabled: true
triggers:
  - type: manual
inputs:
  - name: userid
    type: string
  - name: preferred-address
    type: string
  - name: laptop-choice
    default: Macbook latest
    type: string
  - name: laptop-keep-or-return
    default: return
    type: string

与 ServiceNow 交互

workflow 会执行一系列 HTTP 步骤。关键是，我们首先需要识别用户当前的资产，以便正确关联设备更新请求。

1）获取电脑数据

我们查询 ServiceNow 中的 cmdb_ci_computer 表，来找到当前分配给该用户的资产。

YAML
steps:
  - name: snow_get_computer_data
    type: http
    with:
      url: https://elasticdev.service-now.com/api/now/table/ci_computer?assigned_to={{ inputs.userid }}
      method: GET
      headers:
        Accept: application/json
        Content-Type: application/json
        # Best Practice: Use secrets for authorization headers
        Authorization: Basic {{ secrets.servicenow_creds }}
      timeout: 30s

2）加入购物车

一旦获取到资产详情和用户偏好，我们不会仅仅创建一个通用工单。我们使用 ServiceNow Service Catalog API，以编程方式将特定物品添加到购物车中。

YAML
  - name: snow_post_add_item_to_cart
    type: http
    with:
      url: https://elasticdev.service-now.com/example
      method: POST
      headers:
        Accept: application/json
        Content-Type: application/json
        Authorization: Basic {{ secrets.servicenow_creds }}
      body: |
        {
            "sysparm_quantity": 1,
            "variables": {
              "caller_id_common": "{{ inputs.userid }}",
              "current_device": "{{ steps.snow_get_asset.output.data.result.sys_id }}",
              "laptop_keep_or_return": "{{ inputs.laptop-keep-or-return }}",
              "choose_your_laptop": "{{ inputs.laptop-choice }}",
              "shipping_address": "{{ inputs.preferred-address }}"
            }
        }

3）交易索引

最后，我们希望在 Elasticsearch 中保存此次交易记录，以便进行分析和未来参考。我们使用 elasticsearch.index 步骤在提交请求后立即存储请求详情。

YAML

  - name: index-submission-record
    type: elasticsearch.index
    with:
      index: laptop-refresh-submission-data
      id: "{{ steps.snow_post_submit_order.output.data.result.request_id }}"
      document:
        request-id: "{{ steps.snow_post_submit_order.output.data.result.request_id }}"
        user-id: "{{ inputs.userid }}"
        configuration-item: "{{ steps.snow_get_computer_data.output.data.result[0].sys_id }}"
        laptop-choice: "{{ inputs.laptop-choice }}"
        timestamp: "{{ steps.snow_post_submit_order.output.data.result.sys_created_on }}"

详细的 workflow YAML，请参考此处。

结果

通过将这些组件组合在一起，我们创建了一个无缝体验：

• 用户通过自然对话与 agent 提供详细信息。

• Agent 将这些非结构化对话整理为 JSON 对象。

• Workflow 接收 JSON，验证用户当前硬件（通过 ServiceNow）、创建订单，并索引结果。

这种方法将传统需要用户 5–10 分钟填写表单的流程缩短为一次快速对话，同时确保 IT 运维保持完全可视性和控制。

视频演示：

准备好开始构建了吗？

这种模式使用 agent 作为界面，Workflows 负责执行，几乎可以应用于任何 ITSM 任务，从密码重置到软件配置。

如果你想尝试，请务必观看 DevFest 演讲以获取完整背景，并查看 Elastic AI Agent Builder 文档，开始构建你自己的 agent。

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