kibana-workflows

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Author Elastic Workflows

编写Elastic Workflows

Create and iterate on Elastic Workflow YAML definitions. Workflows are declarative automations that run inside Kibana: they query Elasticsearch, set data, branch, loop, call connectors, create cases, notify external systems, and invoke AI steps.

创建并迭代Elastic Workflow YAML定义。工作流是运行在Kibana内部的声明式自动化程序：它们可以查询Elasticsearch、设置数据、分支、循环、调用连接器、创建案例、通知外部系统以及调用AI步骤。

Environment Configuration

环境配置

This skill executes Elasticsearch operations through the

elastic

CLI. Before running any other step, confirm the

elastic

CLI is installed and available. If it is not installed, ask the user:

"The
elastic
CLI is not available. You must install the
elastic
CLI before continuing?"

Wait for the user's response. Do not guess credentials, call the HTTP API directly, or attempt other workarounds.

This skill references operations in HTTP-shorthand form (e.g.,

GET /

GET /_cat/indices

GET /{index}/_mapping

GET /{index}/_settings/index.mode

POST /_query

). The Operations table at the end of this document maps each shorthand to the equivalent

elastic

CLI command — always use the CLI rather than calling the HTTP API directly.

Verify the connection by calling

GET /

. If verification fails, point the user to the CLI configuration instructions.

If the user asks only for a draft or explanation and explicitly forbids live access, skip connection verification and do not call the CLI or APIs. State that the draft was not validated against a target deployment.

If workflow APIs are unavailable, report the returned status and message. Common causes are an unsupported Kibana version, insufficient license or feature privileges, or Workflows not being offered on the target project. The

workflows:ui:enabled

setting controls the Kibana UI; it does not remove the public Workflows APIs.

该技能通过

elastic

CLI执行Elasticsearch操作。在运行任何其他步骤之前，请确认

elastic

CLI已安装且可用。如果未安装，请询问用户：

"
elastic
CLI不可用。您必须先安装
elastic
CLI才能继续？"

等待用户回复。请勿猜测凭据、直接调用HTTP API或尝试其他变通方法。

该技能以HTTP简写形式引用操作（例如

GET /

、

GET /_cat/indices

、

GET /{index}/_mapping

、

GET /{index}/_settings/index.mode

、

POST /_query

）。本文档末尾的操作表格将每个简写映射为等效的

elastic

CLI命令——请始终使用CLI而非直接调用HTTP API。

通过调用

GET /

验证连接。如果验证失败，请引导用户查看CLI配置说明。

如果用户仅要求草稿或解释，并明确禁止实时访问，请跳过连接验证，不要调用CLI或API。说明该草稿未针对目标部署进行验证。

如果工作流API不可用，请返回状态和消息。常见原因包括Kibana版本不支持、许可证或功能权限不足，或目标项目未提供Workflows功能。

workflows:ui:enabled

设置控制Kibana UI，但不会移除公开的Workflows API。

Pick the authoring path

选择编写路径

Default to the Discovery-tools path below — the

platform.workflows.*

tools are registered by default on Kibana 9.5+ and Serverless. Confirm with one probe:

GET kbn:/api/agent_builder/tools

returns

{ "results": [ { "id": ... } ] }

; save it to a file and grep for

"id": "platform.workflows."

. Two fallbacks, both loaded only when needed:

No
```
agent_builder
```
endpoint (404) or no
```
platform.workflows.*
```
ids (e.g. Kibana 9.4) → read references/schema-path.md and hand-author from the raw JSON Schema.
An LLM connector is wired into Agent Builder and the user prefers Kibana's own generator → read references/generator-path.md.

State which path you picked and why in one sentence before proceeding. Measured path benchmarks live in references/path-performance.md.

默认选择下方的Discovery-tools路径——

platform.workflows.*

工具默认在Kibana 9.5+和Serverless版本中注册。通过一次探测确认：

GET kbn:/api/agent_builder/tools

{ "results": [ { "id": ... } ] }

；将其保存到文件并搜索

"id": "platform.workflows."

。有两个备用路径，仅在需要时加载：

无
```
agent_builder
```
端点（404）或无
```
platform.workflows.*
```
标识（例如Kibana 9.4）→ 阅读references/schema-path.md并根据原始JSON Schema手动编写。
Agent Builder中已连接LLM连接器且用户偏好Kibana自带的生成器→ 阅读references/generator-path.md。

在继续之前，用一句话说明你选择的路径及原因。路径性能基准见references/path-performance.md。

Guidelines (all paths)

通用准则（所有路径）

Treat tests as executions.
```
POST kbn:/api/workflows/test
```
runs the workflow graph, and
```
POST kbn:/api/workflows/step/test
```
runs the selected step. Test only when every executed action is read-only or the user authorized its effects. Otherwise test a copy whose writes, notifications, and external calls are replaced with
```
console
```
, then restore the real steps and save the workflow disabled.
Cite endpoints in HTTP shorthand, never raw transport. This skill's body refers to operations like
```
POST kbn:/api/workflows/test
```
. The Operations table is the single place where shorthand binds to a concrete CLI command.
Prefer purpose-built actions over generic
http
. For Slack/Jira/PagerDuty/etc., prefer the connector step type (e.g.
```
slack2.sendMessage
```
) over a raw
```
http
```
call. Discover the exact action type via
```
get_step_definitions
```
(or the strict schema on the fallback path).

Reference step outputs as
steps.<name>.output
, never
steps.<name>.with.*
. Trigger event data is

event

, never

trigger.event

triggers.event

Don't guess connector ids. Call
```
platform.workflows.get_connectors
```
(Discovery-tools path) or
```
GET kbn:/api/workflows/connectors
```
(Schema path), or ask the user. Placeholders should be obviously fake.
Handle failure deliberately. Add retry or fallback behavior where the user's requirements call for resilience. Do not add
```
continue: true
```
everywhere: it can hide a failed action and allow the workflow to report false success.
Surface gates, don't paper over them. If the API returns
```
403 ... not available
```
, report the required license or privileges; do not silently retry or blame the UI setting.

将测试视为执行。
```
POST kbn:/api/workflows/test
```
运行工作流图，
```
POST kbn:/api/workflows/step/test
```
运行选定步骤。仅当每个执行的操作为只读或用户已授权其影响时才进行测试。否则测试副本，将其写入、通知和外部调用替换为
```
console
```
，然后恢复真实步骤并保存禁用状态的工作流。
以HTTP简写形式引用端点，切勿使用原始传输方式。 本文档中的操作引用如
```
POST kbn:/api/workflows/test
```
。操作表格是简写与具体CLI命令绑定的唯一位置。
优先使用专用操作而非通用
http
。对于Slack/Jira/PagerDuty等，优先使用连接器步骤类型（例如
```
slack2.sendMessage
```
）而非原始
```
http
```
调用。通过
```
get_step_definitions
```
（或备用路径上的严格Schema）发现确切的操作类型。
将步骤输出引用为
steps.<name>.output
，切勿使用
steps.<name>.with.*
。触发事件数据为
```
event
```
，切勿使用
```
trigger.event
```
或
```
triggers.event
```
。
不要猜测连接器ID。 调用
```
platform.workflows.get_connectors
```
（Discovery-tools路径）或
```
GET kbn:/api/workflows/connectors
```
（Schema路径），或询问用户。占位符应明显为虚构值。
刻意处理失败。 在用户要求具备弹性的地方添加重试或回退行为。不要处处添加
```
continue: true
```
：这可能会隐藏失败的操作，导致工作流报告虚假成功。
明确限制条件，不要掩盖。 如果API返回
```
403 ... not available
```
，请报告所需的许可证或权限；不要静默重试或归咎于UI设置。

Discovery-tools path

Discovery-tools路径

Use when

platform.workflows.*

tools are registered on the target Kibana. All calls go through

POST kbn:/api/agent_builder/tools/_execute

with

{ "tool_id": "...", "tool_params": { ... } }

. Response shape:

{ "results": [ { "type": "other", "data": { ... }, "tool_result_id": "..." } ] }

— the payload you want is

.results[0].data

. Send the request body from a file and write the response to a file (see Operations), then jq against that file; do not inline

python3 -c

on multi-line JSON.

Keep context small; minimize round-trips. Do NOT front-load the whole step catalog — pull only the targeted details you need, keep large tool output in files (not the transcript), and author in as few turns as possible (measured rationale: references/path-performance.md).

Capture the user's intent before writing YAML. Identify, in order, the trigger (
```
manual
```
/
```
scheduled
```
/
```
alert
```
), the inputs the workflow will receive at runtime, the data sources it must read, the actions it must take, and the desired output. If a required dependency is unknown (e.g. a Slack connector id), ask the user or use a clearly-marked placeholder.
Look up only what you'll use. For the specific step types this workflow needs:
- ```
platform.workflows.get_step_definitions
```
  with an exact
```
stepType
```
  (e.g.
```
"http"
```
  ,
```
"elasticsearch.esql.query"
```
  ,
```
"slack2.sendMessage"
```
  ), or with
```
search
```
  to browse. The response includes input params, config params, an
```
outputSummary
```
  when you pass
```
includeOutputSummary: true
```
  , and usage examples. Pass
```
includeFullSchema: true
```
  only if the compact summary is insufficient.
- ```
platform.workflows.get_trigger_definitions
```
  for the trigger event schema.
- ```
platform.workflows.get_connectors
```
  to resolve real
```
connector-id
```
  values for connector actions.
- ```
platform.workflows.get_examples
```
  when you need a working YAML shape for a pattern.
Write each response to a file and jq the field you need — don't let full tool output land in the transcript.
Draft the whole workflow in one pass. A workflow requires
```
name
```
, at least one trigger, and a non-empty
```
steps
```
array. Use 2-space indentation. Reference outputs as
```
steps.<name>.output.*
```
. Build the complete YAML in a single edit rather than growing it across many turns.
Validate once. Call
```
platform.workflows.validate_workflow
```
with
```
{ "yaml": "..." }
```
. On failure it returns errors + step definitions for referenced step types automatically, so you rarely need a second
```
get_step_definitions
```
call. Fix all reported issues in a single edit, then re-validate.
Test, save, and run. See Test / save / run below. Use
```
platform.workflows.workflow_execute_step
```
to iterate on a single step (with
```
confirmation_body
```
for unsafe steps).

当目标Kibana上已注册

platform.workflows.*

工具时使用此路径。所有调用均通过

POST kbn:/api/agent_builder/tools/_execute

，参数为

{ "tool_id": "...", "tool_params": { ... } }

。响应格式为

{ "results": [ { "type": "other", "data": { ... }, "tool_result_id": "..." } ] }

——所需的负载为

.results[0].data

。从文件发送请求体并将响应写入文件（见操作），然后用jq处理该文件；不要在多行JSON中内联

python3 -c

。

保持上下文精简；减少往返次数。 不要预先加载整个步骤目录——仅提取所需的目标细节，将大型工具输出保存在文件中（而非转录内容中），并尽可能少地通过多轮交互完成编写（测量依据：references/path-performance.md）。

编写YAML前捕捉用户意图。 按顺序确定触发器（
```
manual
```
/
```
scheduled
```
/
```
alert
```
）、工作流运行时将接收的输入、必须读取的数据源、必须执行的操作以及期望的输出。如果存在未知的必需依赖项（例如Slack连接器ID），请询问用户或使用标记清晰的占位符。
仅查找将使用的内容。 对于此工作流所需的特定步骤类型：
- 使用精确的
```
stepType
```
  （例如
```
"http"
```
  、
```
"elasticsearch.esql.query"
```
  、
```
"slack2.sendMessage"
```
  ）调用
```
platform.workflows.get_step_definitions
```
  ，或使用
```
search
```
  进行浏览。响应包含输入参数、配置参数、传递
```
includeOutputSummary: true
```
  时的
```
outputSummary
```
  以及使用示例。仅当精简摘要不足时才传递
```
includeFullSchema: true
```
  。
- 使用
```
platform.workflows.get_trigger_definitions
```
  获取触发器事件Schema。
- 使用
```
platform.workflows.get_connectors
```
  解析连接器操作的真实
```
connector-id
```
  值。
- 需要模式的可用YAML格式时使用
```
platform.workflows.get_examples
```
  。
将每个响应写入文件并用jq提取所需字段——不要让完整的工具输出出现在转录内容中。
一次性完成整个工作流的草稿。 工作流需要
```
name
```
、至少一个触发器和非空的
```
steps
```
数组。使用2空格缩进。将输出引用为
```
steps.<name>.output.*
```
。在单次编辑中构建完整的YAML，而非通过多轮交互逐步完善。
验证一次。 使用
```
{ "yaml": "..." }
```
调用
```
platform.workflows.validate_workflow
```
。失败时会自动返回错误及引用步骤类型的步骤定义，因此很少需要再次调用
```
get_step_definitions
```
。在单次编辑中修复所有报告的问题，然后重新验证。
测试、保存和运行。 见下方的测试/保存/运行。使用
```
platform.workflows.workflow_execute_step
```
迭代单个步骤（不安全步骤需提供
```
confirmation_body
```
）。

Schema path (last resort)

Schema路径（最后手段）

Only for Kibanas without the

platform.workflows.*

tools (see the probe above). Full recipe: references/schema-path.md.

仅适用于没有

platform.workflows.*

工具的Kibana（见上方的探测）。完整步骤见references/schema-path.md。

Test / save / run

测试/保存/运行

Shared final phase for both paths.

Test only an execution-safe draft. Call
```
POST kbn:/api/workflows/test
```
with the YAML inline as
```
workflowYaml
```
and the run-time
```
inputs
```
. For any workflow that writes / notifies / calls external services, replace those steps with
```
console
```
in the tested copy first, then restore them and save the workflow disabled.

Poll the execution. The response carries a

workflowExecutionId

. Poll

GET kbn:/api/workflows/executions/{executionId}

until

status

is one of

completed

failed

cancelled

, or

timed_out

; then fetch

GET kbn:/api/workflows/executions/{executionId}/logs

for step-by-step output. Only treat

status: completed

as success.

Save.
```
POST kbn:/api/workflows/workflow
```
with
```
{ yaml, id? }
```
. Save side-effecting workflows with
```
enabled: false
```
until the user has authorized a real run. Subsequent edits use
```
PUT kbn:/api/workflows/workflow/{id}
```
and may update
```
yaml
```
,
```
enabled
```
,
```
name
```
,
```
tags
```
, or
```
description
```
(partial updates supported).
Run only when authorized. Enable the workflow, then call
```
POST kbn:/api/workflows/workflow/{id}/run
```
with the same
```
inputs
```
shape used at test time. Inspect via the execution + logs endpoints.

两个路径共享的最终阶段。

仅测试执行安全的草稿。 使用内联的YAML作为
```
workflowYaml
```
和运行时
```
inputs
```
调用
```
POST kbn:/api/workflows/test
```
。对于任何涉及写入/通知/调用外部服务的工作流，请先在测试副本中将这些步骤替换为
```
console
```
，然后恢复这些步骤并保存禁用状态的工作流。

轮询执行状态。 响应包含

workflowExecutionId

。轮询

GET kbn:/api/workflows/executions/{executionId}

直到

status

为

completed

、

failed

、

cancelled

或

timed_out

之一；然后获取

GET kbn:/api/workflows/executions/{executionId}/logs

以查看分步输出。仅将

status: completed

视为成功。

保存。 使用
```
{ yaml, id? }
```
调用
```
POST kbn:/api/workflows/workflow
```
。保存有副作用的工作流时设置
```
enabled: false
```
，直到用户授权真实运行。后续编辑使用
```
PUT kbn:/api/workflows/workflow/{id}
```
，可更新
```
yaml
```
、
```
enabled
```
、
```
name
```
、
```
tags
```
或
```
description
```
（支持部分更新）。
仅在授权后运行。 启用工作流，然后使用测试时相同的
```
inputs
```
格式调用
```
POST kbn:/api/workflows/workflow/{id}/run
```
。通过执行和日志端点查看状态。

Workflow YAML Quick Reference

Workflow YAML快速参考

yaml

version: "1"
name: Manual Hello Workflow
description: Logs a hello message from a manual workflow
enabled: true
tags: ["demo", "workflow"]

triggers:
  - type: manual
    inputs:
      properties:
        name:
          type: string
          description: Name to greet
          default: "world"

steps:
  - name: log_hello
    type: console
    with:
      message: "Hello {{ inputs.name }}"

An ordinary action step can use fields like these when its strict schema allows them:

yaml

- name: unique_step_name
  type: step_type
  with:
    param: value
  connector-id: connector-id-for-connector-actions # connector actions only
  if: "steps.previous.output.ok: true"
  timeout: "30s"
  on-failure:
    retry:
      max-attempts: 3
      delay: "5s"
    fallback:
      - name: handle_error
        type: console
        with:
          message: "Step failed"

Use

{{ ... }}

when rendering text. Use

${{ ... }}

when an entire value must retain its native type, for example

documents: "${{ steps.search.output.hits.hits }}"

Common step types include:

Step type	Use for
`console`	Debug logging during tests
`elasticsearch.search`	Query Elasticsearch with Query DSL
`elasticsearch.esql.query`	Query Elasticsearch with ES\|QL
`elasticsearch.bulk`	Bulk indexing
`kibana.request`	Call a Kibana API
`data.set`	Set values under `variables`
`if`	Branch on a KQL-style condition
`foreach`	Loop over a collection
`wait`	Pause execution
`http`	Generic HTTP requests
`workflow.execute`	Run another saved workflow

This is not an exhaustive compatibility list. On the Discovery-tools path,

platform.workflows.get_step_definitions

answers "does step X exist and what does it take". On the schema path,

GET kbn:/api/workflows/schema?loose=false

is the source of truth, and

GET kbn:/api/workflows/connectors

lists configured connector instances.

data.set

stores variables for the current execution; it does not persist durable data. Use an Elasticsearch or Kibana write action when the user asks to retain data after the execution.

yaml

version: "1"
name: Manual Hello Workflow
description: Logs a hello message from a manual workflow
enabled: true
tags: ["demo", "workflow"]

triggers:
  - type: manual
    inputs:
      properties:
        name:
          type: string
          description: Name to greet
          default: "world"

steps:
  - name: log_hello
    type: console
    with:
      message: "Hello {{ inputs.name }}"

当严格Schema允许时，普通操作步骤可使用以下字段：

yaml

- name: unique_step_name
  type: step_type
  with:
    param: value
  connector-id: connector-id-for-connector-actions # connector actions only
  if: "steps.previous.output.ok: true"
  timeout: "30s"
  on-failure:
    retry:
      max-attempts: 3
      delay: "5s"
    fallback:
      - name: handle_error
        type: console
        with:
          message: "Step failed"

渲染文本时使用

{{ ... }}

。当整个值必须保留其原生类型时使用

${{ ... }}

，例如

documents: "${{ steps.search.output.hits.hits }}"

。

常见步骤类型包括：

步骤类型	用途
`console`	测试期间的调试日志
`elasticsearch.search`	使用Query DSL查询Elasticsearch
`elasticsearch.esql.query`	使用ES\|QL查询Elasticsearch
`elasticsearch.bulk`	批量索引
`kibana.request`	调用Kibana API
`data.set`	在 `variables` 下设置值
`if`	根据KQL风格的条件分支
`foreach`	遍历集合
`wait`	暂停执行
`http`	通用HTTP请求
`workflow.execute`	运行另一个已保存的工作流

这并非详尽的兼容性列表。在Discovery-tools路径中，

platform.workflows.get_step_definitions

可回答"步骤X是否存在以及需要哪些参数"。在Schema路径中，

GET kbn:/api/workflows/schema?loose=false

是权威来源，

GET kbn:/api/workflows/connectors

列出已配置的连接器实例。

data.set

为当前执行存储变量；它不会持久化数据。当用户要求在执行后保留数据时，请使用Elasticsearch或Kibana写入操作。

Examples

示例

Manual hello (smallest possible draft): "Make a workflow that logs hello." → manual trigger + one

console

step that prints

Hello {{ inputs.name | default: "world" }}

. Test with

POST kbn:/api/workflows/test

. See Demo Test Loop.

Scheduled health check: "Every 5 minutes, ping

https://api.example.com/health

and log the response." →

scheduled

trigger (

every: 5m

) +

http

step +

console

. Look up the exact

with

shape with

get_step_definitions("http")

. Add bounded retry if requested.

Alert-triggered case + Slack notify: "When a Security alert fires, create a case and post to #soc-incidents." →

alert

trigger +

foreach

over

event.alerts

+ connector actions. Use

get_step_definitions("cases.createCase")

and

get_step_definitions(search: "slack")

(current fixtures use

cases.createCase

and

slack2.sendMessage

), then

get_connectors

for the real

connector-id

s. See Workflow Patterns.

For unfamiliar shapes on the schema path, read Workflow Patterns and Generation Tips before drafting.

手动问候（最小草稿）： "创建一个记录问候语的工作流。" → 手动触发器 + 一个打印

Hello {{ inputs.name | default: "world" }}

的

console

步骤。使用

POST kbn:/api/workflows/test

测试。见演示测试循环。

定时健康检查： "每5分钟ping

https://api.example.com/health

并记录响应。" →

scheduled

触发器（

every: 5m

） +

http

步骤 +

console

。使用

get_step_definitions("http")

查找确切的

with

格式。如果有要求，添加有限次数的重试。

警报触发的案例+Slack通知： "当安全警报触发时，创建案例并发布到#soc-incidents频道。" →

alert

触发器 + 遍历

event.alerts

的

foreach

+ 连接器操作。使用

get_step_definitions("cases.createCase")

和

get_step_definitions(search: "slack")

（当前示例使用

cases.createCase

和

slack2.sendMessage

），然后使用

get_connectors

获取真实的

connector-id

。见工作流模式。

在Schema路径中遇到不熟悉的格式时，请先阅读工作流模式和生成技巧再起草。

Operations

操作

The HTTP-shorthand references in the body above bind to the

elastic

CLI commands below. Multi-line YAML and JSON payloads are easier to pass via

--input-file <path>

than as inline flags.

Workflows API (both paths).

HTTP API (shorthand)	`elastic` CLI command
`GET /`	`elastic es info`
`GET kbn:/api/workflows`	`elastic stack kb workflows get-workflows`
`GET kbn:/api/workflows/workflow/{id}`	`elastic stack kb workflows get-workflows-workflow-id --id <id>`
`POST kbn:/api/workflows/workflow`	`elastic stack kb workflows post-workflows-workflow --input-file <path>`
`PUT kbn:/api/workflows/workflow/{id}`	`elastic stack kb workflows put-workflows-workflow-id --id <id> --input-file <path>`
`DELETE kbn:/api/workflows/workflow/{id}`	`elastic stack kb workflows delete-workflows-workflow-id --id <id>`
`DELETE kbn:/api/workflows/workflow/{id}?force=true`	`elastic stack kb workflows delete-workflows-workflow-id --id <id> --force true`
`POST kbn:/api/workflows/test`	`elastic stack kb workflows post-workflows-test --input-file <path>`
`POST kbn:/api/workflows/workflow/{id}/run`	`elastic stack kb workflows post-workflows-workflow-id-run --id <id> --inputs <json>`
`POST kbn:/api/workflows/step/test`	`elastic stack kb workflows post-workflows-step-test --input-file <path>`
`GET kbn:/api/workflows/executions/{executionId}`	`elastic stack kb workflows get-workflows-executions-executionid --execution-id <id>`
`GET kbn:/api/workflows/executions/{executionId}/logs`	`elastic stack kb workflows get-workflows-executions-executionid-logs --execution-id <id>`
`POST kbn:/api/workflows/executions/{executionId}/cancel`	`elastic stack kb workflows post-workflows-executions-executionid-cancel --execution-id <id>`
`POST kbn:/api/workflows/executions/{executionId}/resume`	`elastic stack kb workflows post-workflows-executions-executionid-resume --execution-id <id>`
`GET kbn:/api/workflows/workflow/{workflowId}/executions`	`elastic stack kb workflows get-workflows-workflow-workflowid-executions --workflow-id <id>`
`GET kbn:/api/workflows/schema?loose=false`	`elastic stack kb workflows get-workflows-schema --loose false`
`GET kbn:/api/workflows/connectors`	`elastic stack kb workflows get-workflows-connectors`

Agent Builder tools (Discovery-tools path).

Every tool below is invoked through the same execute endpoint. Pass

--input-file

a JSON file with

{ "tool_id": "...", "tool_params": { ... } }

HTTP API (shorthand)

HTTP API (shorthand)	`elastic` CLI command
`GET kbn:/api/agent_builder/tools`	`elastic stack kb agent-builder get-agent-builder-tools`
`POST kbn:/api/agent_builder/tools/_execute`	`elastic stack kb agent-builder post-agent-builder-tools-execute --input-file <path>`

elastic

CLI command

GET kbn:/api/agent_builder/tools

elastic stack kb agent-builder get-agent-builder-tools

POST kbn:/api/agent_builder/tools/_execute

elastic stack kb agent-builder post-agent-builder-tools-execute --input-file <path>

Workflow-relevant

tool_id

`tool_id`	Purpose
`platform.workflows.validate_workflow`	Validate a YAML string; failure response includes step definitions for referenced step types.
`platform.workflows.workflow_execute_step`	Execute one step against the real environment (with user confirmation for unsafe steps).
`platform.workflows.get_step_definitions`	Look up step type params, outputs, examples. `stepType` for exact match, `search` for keyword.
`platform.workflows.get_trigger_definitions`	Look up a trigger's full event schema.
`platform.workflows.get_connectors`	List connector instances configured on the target.
`platform.workflows.get_examples`	Search the bundled example library for working YAML patterns.

Notes.

For

post-workflows-test

, the input file is JSON of the form

{ "workflowYaml": "...", "inputs": {} }

(or

workflowId

in place of

workflowYaml

). For

post-workflows-workflow

, use

{ "yaml": "...", "id": "..." }

—

id

is optional. For

put-workflows-workflow-id

, include only the fields to update from

name

enabled

tags

yaml

, and

description

. Deletion is soft by default. Use

force=true

only when permanent deletion and immediate ID reuse are intended. The Kibana API version is

2023-10-31

; the CLI sets it automatically.

When invoking read-only

get-

commands from a shell that leaves stdin open (some terminals and agent runtimes do this), append

</dev/null

to avoid an

EAGAIN: resource temporarily unavailable

crash — e.g.

elastic stack kb workflows get-workflows-executions-executionid --execution-id "{id}" </dev/null

本文档中引用的HTTP简写形式对应下方的

elastic

CLI命令。多行YAML和JSON负载通过

--input-file <path>

传递比内联标志更简便。

Workflows API（所有路径）。

HTTP API（简写）	`elastic` CLI命令
`GET /`	`elastic es info`
`GET kbn:/api/workflows`	`elastic stack kb workflows get-workflows`
`GET kbn:/api/workflows/workflow/{id}`	`elastic stack kb workflows get-workflows-workflow-id --id <id>`
`POST kbn:/api/workflows/workflow`	`elastic stack kb workflows post-workflows-workflow --input-file <path>`
`PUT kbn:/api/workflows/workflow/{id}`	`elastic stack kb workflows put-workflows-workflow-id --id <id> --input-file <path>`
`DELETE kbn:/api/workflows/workflow/{id}`	`elastic stack kb workflows delete-workflows-workflow-id --id <id>`
`DELETE kbn:/api/workflows/workflow/{id}?force=true`	`elastic stack kb workflows delete-workflows-workflow-id --id <id> --force true`
`POST kbn:/api/workflows/test`	`elastic stack kb workflows post-workflows-test --input-file <path>`
`POST kbn:/api/workflows/workflow/{id}/run`	`elastic stack kb workflows post-workflows-workflow-id-run --id <id> --inputs <json>`
`POST kbn:/api/workflows/step/test`	`elastic stack kb workflows post-workflows-step-test --input-file <path>`
`GET kbn:/api/workflows/executions/{executionId}`	`elastic stack kb workflows get-workflows-executions-executionid --execution-id <id>`
`GET kbn:/api/workflows/executions/{executionId}/logs`	`elastic stack kb workflows get-workflows-executions-executionid-logs --execution-id <id>`
`POST kbn:/api/workflows/executions/{executionId}/cancel`	`elastic stack kb workflows post-workflows-executions-executionid-cancel --execution-id <id>`
`POST kbn:/api/workflows/executions/{executionId}/resume`	`elastic stack kb workflows post-workflows-executions-executionid-resume --execution-id <id>`
`GET kbn:/api/workflows/workflow/{workflowId}/executions`	`elastic stack kb workflows get-workflows-workflow-workflowid-executions --workflow-id <id>`
`GET kbn:/api/workflows/schema?loose=false`	`elastic stack kb workflows get-workflows-schema --loose false`
`GET kbn:/api/workflows/connectors`	`elastic stack kb workflows get-workflows-connectors`

Agent Builder工具（Discovery-tools路径）。

下方所有工具均通过同一个执行端点调用。通过

--input-file

传递包含

{ "tool_id": "...", "tool_params": { ... } }

的JSON文件。

HTTP API（简写）

HTTP API（简写）	`elastic` CLI命令
`GET kbn:/api/agent_builder/tools`	`elastic stack kb agent-builder get-agent-builder-tools`
`POST kbn:/api/agent_builder/tools/_execute`	`elastic stack kb agent-builder post-agent-builder-tools-execute --input-file <path>`

elastic

CLI命令

GET kbn:/api/agent_builder/tools

elastic stack kb agent-builder get-agent-builder-tools

POST kbn:/api/agent_builder/tools/_execute

elastic stack kb agent-builder post-agent-builder-tools-execute --input-file <path>

与工作流相关的

tool_id

：

`tool_id`	用途
`platform.workflows.validate_workflow`	验证YAML字符串；失败响应包含引用步骤类型的步骤定义。
`platform.workflows.workflow_execute_step`	在真实环境中执行单个步骤（不安全步骤需用户确认）。
`platform.workflows.get_step_definitions`	查找步骤类型的参数、输出和示例。 `stepType` 用于精确匹配， `search` 用于关键字搜索。
`platform.workflows.get_trigger_definitions`	查找触发器的完整事件Schema。
`platform.workflows.get_connectors`	列出目标上已配置的连接器实例。
`platform.workflows.get_examples`	在捆绑的示例库中搜索可用的YAML模式。

注意事项。

对于

post-workflows-test

，输入文件为JSON格式，例如

{ "workflowYaml": "...", "inputs": {} }

（或用

workflowId

替代

workflowYaml

）。对于

post-workflows-workflow

，使用

{ "yaml": "...", "id": "..." }

——

id

为可选。对于

put-workflows-workflow-id

，仅包含要更新的字段：

name

、

enabled

、

tags

、

yaml

和

description

。默认情况下为软删除。仅当需要永久删除并立即重用ID时才使用

force=true

。Kibana API版本为

2023-10-31

；CLI会自动设置该版本。

当从保持stdin打开的shell调用只读

get-

命令时（某些终端和代理运行时会这样做），请追加

</dev/null

以避免

EAGAIN: resource temporarily unavailable

崩溃——例如

elastic stack kb workflows get-workflows-executions-executionid --execution-id "{id}" </dev/null

。