作者：来自 Elastic Tinsae Erkailo 及 Shahar Glazner

Elastic Workflows 接受纯文本提示词，并生成你可以检查、版本控制和针对 Elasticsearch 数据运行的 YAML。现在已正式发布，支持 Slack 中的人机协同工作流、并行执行以及 10 个新的连接器。

Agent Builder 现在已经正式发布。开始使用 Elastic Cloud 试用版，并查看 Agent Builder 的文档。

---

一个提示词，一个完整工作流：Elastic 的 AI agent 为你编写自动化流程

Elastic Workflows 现在可以自动编写自己的 YAML。你只需要用自然语言描述希望自动化的内容，Elastic AI Agent 就会针对类型化 schema 生成完整工作流，并且在你阅读确认之前不会执行任何操作。YAML 是这一切能够实现的原因：它为模型提供了一个受约束、类型明确的目标，因此生成的内容是真正可以编辑和运行的构建模块。

Elastic Workflows 9.5 中的新功能：

• 自然语言编写 已正式发布并默认启用：描述一个自动化流程，Elastic AI Agent 会编写工作流，你进行审核并运行。

• 版本控制 已正式发布，支持差异比较和一键回滚。

• 三个新的实验性预览功能（需要通过高级设置启用）：将工作流渲染为图形的可视化模式、通过 Slack 联系人员以获取输入或审批的人机协同步骤，以及并行执行。

• 更多可构建能力：新增连接器、能够响应 Cases 活动的事件触发器、AI 步骤的 token 计量，以及用于并发控制的队列策略。

Workflows 是集成在 Elastic 平台中的自动化引擎。它已在 9.4 中正式发布，默认启用，并使用你现有的连接器和访问控制运行在你的 Elasticsearch 数据之上。这篇文章将介绍 9.5 带来的新增功能。

为什么 YAML 能让 AI 工作流自动化成为可能

YAML 是 Elastic Workflows 的编写语言，因为它具有声明式、可版本控制、可进行差异比较以及跨环境可移植的特点。它在拉取请求中的可读性与在编辑器中的可读性相同。

这也是一次技术选择。大型语言模型（LLMs）非常擅长生成结构化、类型明确的内容，而工作流语言几乎是其理想目标。要求生成一段描述文本，模型可能会偏离方向。要求生成一个基于类型化 schema、具有命名步骤类型和经过验证输入的工作流，答案就会有一个正确的结构。

在 9.5 中，这一选择取得了成果，并且已正式发布。在工作流编辑器中，你可以用自然语言描述你想要的内容：

当某个主机触发检测告警时，获取过去 24 小时内相关日志，让 AI 步骤总结发生了什么，并将总结发布到值班人员的 Slack 频道。

Elastic AI Agent 会生成该工作流：包括触发器、Elasticsearch 查询、AI 总结步骤、Slack 步骤，并使用正确的输入和输出将它们连接起来。你会获得可检查、可编辑的 YAML。只有在你阅读、调整并决定运行后，它才会执行。你也可以将它指向已有工作流，描述你希望进行的修改，它会直接在原位置进行编辑。

这个输出值得阅读，因为它背后有一个丰富、类型明确的语言。一个简短的提示词可以扩展为真正的构建模块：

• foreach 和 while 循环，并配有防止失控执行的保护机制。

• switch 用于清晰的多路分支。

• data.filter 和 data.aggregate 等数据步骤，用于执行过程中的数据转换。

• 每个步骤都支持 on-failure 处理，因此你可以重试、继续或终止。

• workflow.execute，使一个工作流可以调用另一个工作流，你可以使用已经测试过的组件组合构建新的自动化流程。

自然语言可以快速生成第一个版本；底层语言才是让这个版本真正可用的关键。

带有差异比较和一键回滚的工作流版本控制

版本控制已在 9.5 中正式发布。现在每个工作流都有版本历史：每次修改都会被记录并支持差异比较，你可以一键回滚到任意之前的版本。你可以查看谁在什么时候修改了什么，并排比较任意两个版本，在不需要手动重新构建的情况下撤销错误修改。这是团队在生产系统上运行自动化流程之前所要求的变更控制基础。

版本控制与现有的生产控制能力相结合：基于角色的细粒度访问控制（RBAC），用于管理谁可以创建、编辑、运行和查看工作流；每个管理操作都会写入安全审计日志；以及支持导入/导出，可在不同环境之间迁移工作流，同时保持其连接器引用完整。

产品中的版本控制是更长发展路线接近尾声的一部分。工作流是一个声明式 YAML 定义，是具有明确定义 schema 的纯文本，这意味着它天然适用于为代码构建的工具链：它可以进行差异比较、代码审查和版本控制。未来的发展方向是与现有版本控制系统进行完整的双向集成，让工作流可以存放在你的代码仓库中，经过审查流程，并像其他软件一样进行部署。这一能力即将推出，而让自然语言编写能够实现的同一个技术选择——声明式且类型明确的语言，也将让你能够像管理代码一样管理工作流。

可视化模式、人机协同工作流和并行执行

9.5 中最新的三个功能以实验性功能形式发布。要尝试这些功能，请在 Stack Management → Advanced Settings 中开启 Elastic Workflows: Experimental Features（需要重新加载页面）。以下是每个功能的作用。

可视化工作流编辑器：以图形方式查看逻辑

现在你可以在 YAML 编辑器和可视化模式之间切换，后者会将工作流渲染为图形。该图形会展示你的步骤、分支和流程控制，让你可以一眼查看逻辑以及一次运行可能经过的路径，同时旁边保留 YAML。9.5 中该功能为只读模式：你仍然通过 YAML 编写工作流，而图形会随着你的编辑保持同步。这是迈向完整拖拽式构建器的第一步，该功能将在后续推出。

在 Slack 中通过审批步骤实现人机协同工作流

在 9.4 中，工作流已经可以通过 waitForInput 暂停并等待人员操作，它会展示一个基于 schema 定义的表单，并让响应内容决定后续执行流程。9.5 新增了 waitForApproval，用于最常见的场景：通过你选择的标签进行二选一的批准或拒绝，同时将这两个步骤扩展到了第一个外部交互界面：Slack。两者都会暂停运行，直到有人作出响应，并且支持超时设置，因此工作流永远不会无限期挂起。并不是每个决策都应该完全自动化，这正是将人工参与放在确实需要人工判断的步骤上的方式。

waitForInput 是更灵活的方式：定义你希望获取的输入 schema，响应内容会以类型化形式返回。当选择不只是简单的“是”或“否”时，可以使用它。这里，一个 Observability 工作流捕获到了 payment-service 的服务级目标（SLO）消耗速率告警，并询问值班工程师应该运行哪种缓解措施：

- name: ask_sre
  type: waitForInput
  with:
    message: "payment-service is burning its error budget. Which mitigation should we run?"
    schema:
      type: object
      properties:
        mitigation:
          type: string
          enum: [restart, scale_up, monitor]
        reason:
          type: string
      required: [mitigation]
    channels:
      slack_api:
        connector-id: my-slack-connector
        channels: ["sre-oncall"]

waitForApproval 是 9.5 中新增的功能，用于直接进行批准或拒绝操作。这里，一个安全工作流判断某个主机应该被隔离，但在执行这一破坏性操作之前，通过人工审批进行控制：

- name: request_containment_approval
  type: waitForApproval
  timeout: 24h
  with:
    message: >
      Isolate {{ event.alerts[0].host.name }}? This will cut the host off from
      the network until it is manually released.
    approveLabel: Isolate host
    rejectLabel: Leave connected
    channels:
      slack_api:
        connector-id: my-slack-connector
        channels: ["soc-response"]
- name: act_on_decision
  type: switch
  expression: "{{ steps.request_containment_approval.output.response.approved }}"
  cases:
    - match: "true"
      steps:
        - name: isolate_host
          # ... run the containment action
    - match: "false"
      steps:
        - name: keep_monitoring
          # ... skip containment, keep watching

新增的部分是 channels 块。现在，等待步骤可以将请求发送到人员已经使用的地方，而在 9.5 中这意味着 Slack：工作流会将请求发布到 Slack 频道，人员从 Slack 中响应，工作流会携带他们的回答继续执行。没有人需要一直停留在 Kibana 中，自动化流程才能继续运行。Slack 是第一个外部交互界面，未来还会支持更多频道以及更丰富的消息传递体验。

并行执行：同时运行独立的工作流步骤

默认情况下，工作流会一个步骤接一个步骤地运行，这适用于每个步骤都依赖上一步结果的情况。但很多工作并非如此：从三个来源丰富告警信息、使用多个信誉服务检查文件、调查多个线索。如果按顺序运行这些任务，工作流速度就只能等于各个步骤耗时之和，而实际上它本可以达到最慢步骤的耗时速度。新增的 parallel 步骤可以让独立任务同时运行。它有两种使用方式。

第一种情况是你提前知道需要执行哪些任务。你定义一组固定任务，它们会同时运行，因此你可以在一个步骤中收集所有结果，而不必逐个等待。一次从两个来源丰富安全告警信息就是典型案例：

- name: enrich
  type: parallel
  branches:
    - name: virustotal
      steps:
        - name: scan_hash
          type: virustotal.scanFileHash
          # ... pass the alert's file hash
    - name: ip_reputation
      steps:
        - name: check_ip
          type: abuseipdb.checkIp
          # ... pass the alert's source IP

第二种情况是你事先不知道需要执行哪些任务。你向该步骤提供一个列表，它会针对每个项目执行一次相同的任务，并且同时运行，最多达到你设置的并发限制。根因分析就是一个很好的例子。之前的 AI 步骤会生成一组关于某个服务为什么出现性能下降的假设，而你事先并不知道会有多少个假设，或者具体是什么假设。与其逐个调查这些假设，不如将列表传递给并行步骤，让它同时调查所有假设：

- name: investigate_hypotheses
  type: parallel
  foreach: "{{ steps.generate_hypotheses.output.hypotheses }}"
  concurrency:
    max: 5
  steps:
    - name: investigate_hypothesis
      type: ai.agent
      # runs once per hypothesis, up to 5 at a time
      # the agent gathers evidence for {{ foreach.item }} and scores it

你可以通过 concurrency 控制同时运行的任务数量，执行引擎会限制并发数以及并行任务总数，因此工作流不会生成无限数量的任务。所有结果都会提供给下一步骤，因此工作流会先运行并行任务，然后在所有任务完成后继续执行。

Elastic Workflows 的更多功能：连接器、触发器、token 计量和并发控制

除了主要功能之外，9.5 还扩展了工作流可以连接和响应的范围。

新连接器：BigQuery、Snowflake、HubSpot、Cortex XSOAR 等

连接器目录持续增长，9.5 新增了以下原生连接器：

• BigQuery

• Snowflake

• Box

• Dropbox

• OneDrive

• Outlook

• Azure Blob

• Google Cloud Functions

• HubSpot

• 用于安全自动化的 Cortex XSOAR 连接器

更多连接器正在开发中。如果你需要的系统没有专用连接器，http 步骤可以作为备用方案：它可以安全调用任何 API endpoint，凭据由连接器提供，而不是直接写入 YAML 中。

面向 Elastic Cases 的事件驱动触发器

工作流从触发器开始，而 9.5 扩展了工作流可以响应的范围。现在 Cases 会产生工作流可以订阅的事件：

• 创建了一个 case。

• 更新了一个 case。

• 它的状态发生变化。

• 添加了一条评论。

• 添加了一个附件。

因此，工作流可以在 case 打开时立即运行，用于丰富信息、添加标签或通知正确的频道；也可以在状态切换到你关注的状态时运行，而不需要通过轮询来检测变化。由告警触发的工作流现在也会接收到更丰富的规则上下文，包括规则的标签、类型和参数，因此工作流在执行操作之前有更多信息可以使用。

AI 工作流步骤的 token 使用量和成本跟踪

工作流可以调用 AI 步骤：ai.prompt 用于自由格式提示词，ai.classify 用于将内容分类，ai.agent 用于将任务交给一个 Agent Builder agent。在每天运行数千次的自动化流程中，这些调用会累积。9.5 现在会报告每个 AI 步骤的 token 使用量，包括输入、输出、缓存和总量，同时支持按步骤统计和按整个运行统计。你可以准确查看工作流中的 AI 消耗情况，随时间跟踪使用情况，并根据这些数据调整提示词或模型选择。

工作流并发控制：取消、丢弃或排队

工作流的并发设置决定了当新的执行在上一次执行完成之前启动时会发生什么。9.5 新增了第三种策略，因此你可以选择最适合该工作流的行为：

策略	适用场景
Cancel-in-progress	只有最新一次执行重要，例如重新计算当前状态
Drop	已经正在执行的任务已经覆盖当前情况，额外执行没有意义
Queue（9.5 新增）	每次执行都很重要，并且需要保持顺序，因此它们会排队并依次运行，同时支持你控制队列大小和存活时间

当执行会访问相同资源，或者不应该同时运行时，可以使用 Queue。9.5 中安全审计日志也覆盖了更多生命周期操作，包括从版本历史中恢复工作流。

开始使用 Elastic Workflows

最快了解这一功能的方法是描述你希望自动化的内容。打开 9.5 中的工作流编辑器，用自然语言输入你的需求，然后查看生成的 YAML。自然语言编写功能默认开启。要尝试可视化模式、人机协同步骤和并行执行，请在 Stack Management → Advanced Settings 中开启 Elastic Workflows: Experimental Features。

9.5 的核心主题是缩短从想法到运行自动化流程之间的路径。你描述想要实现的内容，AI 会生成初稿；你可以将其查看为图形并持续进行版本控制；当某个步骤需要人工判断时，可以在 Slack 中暂停并等待人员参与；还可以并行运行独立任务。有关完整详情，请查看 Workflows 文档。

本文中描述的任何功能或功能发布时间均由 Elastic 自行决定。当前尚未提供的任何功能或功能可能不会按计划交付，或者可能完全不会交付。

原文：AI workflow automation from plain English to complete Workflow (YAML) - Elasticsearch Labs