Elastic Workflows 正式发布后，自动化流程的入口从“手写 YAML”扩展到了“描述你想完成什么”。你可以用纯文本提示词说明目标，让 Elastic 的 AI agent 生成针对 Elasticsearch 数据运行的 YAML，然后检查内容、纳入版本控制，并根据团队流程继续修改。
这件事的价值不只是少写几行配置。更重要的是，工作流仍然是可读、可审查、可追踪的文本资产，而不是藏在某个对话窗口里的不可见自动化逻辑。
从自然语言到 YAML
一个典型需求可能是：
每 15 分钟检查过去一小时内的高严重性安全告警，将结果发送到 Slack；如果告警数量超过阈值，等待值班工程师确认后再创建工单。
过去，工程师需要自己拼接定时触发器、Elasticsearch 查询、Slack 通知和人工确认步骤。现在可以先把这段需求交给 Workflows 的 AI agent，再对生成结果进行工程化处理。
生成后的 YAML 具备几个实际优势：
- 可以检查：团队能够逐步审阅查询、条件、通知对象和人工审批点。
- 可以版本控制：工作流可以和代码一起进入 Git，保留变更历史。
- 可以针对真实数据运行：流程的输入和判断可以直接来自 Elasticsearch 数据。
- 可以继续改造：生成结果是起点，工程师仍然可以补充权限、错误处理、重试和幂等逻辑。
AI agent 负责减少起草成本，但并不替代上线前的审查。尤其要检查查询范围、时间窗口、敏感字段是否会被发送到 Slack，以及重复执行时是否会重复创建工单。
人机协同不再是例外路径
正式发布的 Workflows 支持 Slack 中的人机协同工作流。自动化流程可以把上下文发送给 Slack，让值班人员在熟悉的协作环境中确认、拒绝或补充信息，再继续执行后续步骤。
这适合以下场景：
- 安全告警需要人工确认后才能隔离主机。
- 生产变更需要值班工程师批准。
- 异常数据需要业务人员判断是否升级为事件。
- 自动化动作存在较高误报成本，不能完全无人值守。
人工步骤应该放在风险边界上，而不是把整条流程变成手工操作。例如，查询和聚合可以自动并行执行，只有“封禁 IP”“重启服务”或“创建高优先级事件”之前需要确认。这样既保留自动化速度，也给高风险动作留下明确的责任节点。
并行执行让流程更贴近真实运维
很多运维流程并不是线性链条。一次告警处理往往需要同时查询日志、检查指标、读取资产信息，并向不同渠道发送通知。支持并行执行后，这些互不依赖的步骤可以同时开始，减少整体等待时间。
并行并不意味着所有步骤都应该同时运行。可以按依赖关系拆分：
- 查询 Elasticsearch 日志、指标和资产信息可以并行。
- 汇总结果和风险评分需要等待这些查询完成。
- Slack 审批必须等待汇总结果生成。
- 执行隔离或工单创建只能在审批通过后运行。
这种结构也更容易测试。每个并行分支可以单独验证数据是否完整，汇总步骤则负责处理缺失结果、超时和部分失败。
一个可改造的 YAML 工作流草案
下面的示例展示一种工作流设计方式：定时查询 Elasticsearch，准备 Slack 审批，并在确认后执行后续动作。由于连接器名称和字段会随具体 Elastic Workflows 环境的 schema 变化，示例中的 connector 与步骤字段应以工作区提供的连接器定义为准；整体结构可以直接作为生成提示词后的审查模板。
name: security-alert-review
version: 1
trigger:
type: schedule
every: 15m
steps:
- id: find_alerts
connector: elasticsearch
action: search
with:
index: ".alerts-security-*"
query:
bool:
filter:
- range:
"@timestamp":
gte: "now-1h"
- term:
"kibana.alert.severity": "high"
size: 50
- id: collect_context
connector: elasticsearch
action: search
with:
index: "logs-*"
query:
match:
event.category: "authentication"
size: 20
- id: request_review
connector: slack
action: approval
with:
channel: "#security-operations"
message: "发现高严重性安全告警，请确认是否继续处理。"
context:
alerts: "{{ steps.find_alerts.results }}"
related_logs: "{{ steps.collect_context.results }}"
- id: create_case
connector: elasticsearch
action: index
when: "{{ steps.request_review.approved == true }}"
with:
index: "security-cases"
document:
source: "security-alert-review"
status: "open"
alerts: "{{ steps.find_alerts.results }}"
可以把下面的提示词交给 AI agent，让它生成接近上述目标的工作流：
Create a reviewable YAML workflow for Elastic Workflows.
Every 15 minutes, search the last hour of high-severity security alerts.
In parallel, collect related authentication logs.
Send both results to the #security-operations Slack channel for human approval.
Only after approval, create one security case in Elasticsearch.
Include explicit time bounds, a maximum result size, and a condition that prevents
case creation when approval is denied. Do not expose secrets or raw credentials.
落地时建议逐项核对：
- 查询是否使用了明确的时间范围和结果上限。
- Slack 消息是否包含不应离开 Elasticsearch 的敏感字段。
- 审批超时、拒绝和连接器失败时，流程是否会安全停止。
- 重复触发时，是否会创建重复事件或重复工单。
- 每个连接器使用的身份是否遵循最小权限原则。
新连接器带来的实际变化
此次发布还加入了 10 个新的连接器。连接器数量增加的意义，在于工作流可以覆盖更多外部系统，而不必为每个动作单独编写胶水代码。一个从 Elasticsearch 数据出发的流程，可以把分析结果传给协作、工单、通知或业务系统。
但连接器越多，权限和失败处理越重要。建议为每个连接器建立清晰的边界：谁可以调用、能够读取或写入什么、失败后是否重试、重复调用是否会产生副作用。对于创建工单、修改生产配置等写操作，最好加入人工审批或幂等键。
如何开始采用
可以从低风险、只读的流程开始，例如定时查询告警并发送 Slack 摘要。确认生成的 YAML 能被团队理解和维护后，再逐步加入人工审批、并行分支和外部写操作。
一份实用的上线检查清单如下：
- 用自然语言明确触发条件、输入数据和完成标准。
- 让 AI agent 生成初版 YAML，并将其视为待审代码。
- 在测试数据或低风险索引上验证查询与分支逻辑。
- 为 Slack 审批设置超时、拒绝和升级路径。
- 将工作流纳入版本控制，记录连接器和权限变更。
- 对所有有副作用的步骤增加幂等、审计和人工确认。
Elastic Workflows 最适合承担“把意图快速变成可维护自动化”的工作。最终的可靠性仍然来自明确的查询、受控的权限、可观察的执行记录，以及上线前认真审阅生成的 YAML。