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

作者来自 Elastic Tinsae Erkailo 及 Shahar GlaznerElastic 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。只有在你阅读、调整并决定运行后它才会执行。你也可以将它指向已有工作流描述你希望进行的修改它会直接在原位置进行编辑。右侧是自然语言提示词左侧是生成的 YAML位于 9.5 工作流编辑器中。这个输出值得阅读因为它背后有一个丰富、类型明确的语言。一个简短的提示词可以扩展为真正的构建模块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 编写工作流而图形会随着你的编辑保持同步。这是迈向完整拖拽式构建器的第一步该功能将在后续推出。在 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 alerts file hash - name: ip_reputation steps: - name: check_ip type: abuseipdb.checkIp # ... pass the alerts 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 新增了以下原生连接器BigQuerySnowflakeBoxDropboxOneDriveOutlookAzure BlobGoogle Cloud FunctionsHubSpot用于安全自动化的 Cortex XSOAR 连接器更多连接器正在开发中。如果你需要的系统没有专用连接器http步骤可以作为备用方案它可以安全调用任何 APIendpoint凭据由连接器提供而不是直接写入 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已经正在执行的任务已经覆盖当前情况额外执行没有意义Queue9.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