在大模型和 AI Agent 飞速发展的今天，我们见证了智能体自主推理、自动调用工具和协同工作的强大能力。然而，在企业级生产环境中，全自动化也伴随着显著的风险。无论是执行一些高风险操作（例如隔离主机、禁用账号、删除数据），还是向企业微信、Slack 等全员大群广播汇总报告或系统告警，如果任由 AI 自由发挥、闭环执行，任何一次轻微的幻觉或逻辑偏差，都可能导致生产事故或信息泄露。

为了解决这一痛点，Elastic Stack 引入了 Human-in-the-Loop (HITL，人机协同) 工作流设计模式。本文将结合 Elastic 官方文档中关于 HITL 的设计规范，以及社区优秀的企业微信（WeCom）消息发送工作流实例，为您详细拆解如何在 Elastic Workflows 中设计一个带人工审批的智能通知系统，让您的 AI Agent 既拥有自动化执行的效率，又具备人机协同的安全性。

什么是 Human-in-the-Loop (HITL) 工作流？

根据 Elastic 官方文档 (Human-in-the-Loop workflows) 的定义，HITL 是一种在工作流执行到关键决策点时自动暂停、将结构化证据呈现给响应人员、等待人工输入，并在获取人工决策后恢复执行的设计模式。

1. 什么时候该使用 HITL？

• 有高负面影响的自动化纠偏 (Remediation with potential impact)：如隔离网络主机、阻断异常用户或删除存储数据。在这些高危操作执行前，必须暂停等待分析师确认。
• 消除分类歧义 (Ambiguous classifications)：当 AI 判定或安全规则的置信度不确定时，在下一步执行前询问人类的判断。
• 升级决策网关 (Escalation gates)：呼叫值班人员、等待确认和决策，然后进行动态路由。
• 渐进式自动化过渡 (Approval for automation)：新上线的工作流在测试阶段可以开启人工逐项审批，待运行稳定、信任度建立后，再一键切换至完全自动化。

2. 核心机制：waitForInput 与 waitForApproval

Elastic Workflows 提供了两种专门用来暂停执行并等待人工响应的内置步骤类型：

步骤类型	适用场景	响应数据结构
waitForInput	需要自定义输入表单（例如让审批人填写原因备注、调整严重级别等）	根据定义的 JSON Schema 格式，返回自定义的表单载荷
waitForApproval	简单的“同意”或“拒绝”判定	返回布尔值：approved: true 或 false

当工作流执行到这些步骤时，其状态将被标记为 WAITING_FOR_INPUT。此时，Kibana 会在执行历史中呈现恢复操作（Resume Action）。如果超时（waitForInput 默认 72 小时，waitForApproval 默认 24 小时）未响应，工作流步骤默认将宣告失败。

业务场景：带有人工审批的企业微信 AI 通知助手

在社区博客 《如何在 Workflow 里发送企业微信信息 - WeCom》 中，博主刘晓国老师展示了如何使用 Elastic 9.5 强大的 AI Agent 框架，通过自定义的 Send Message to WeCom 工作流，让 AI 自动分析 Elasticsearch 中的用户数据（例如查询男女人数、平均年龄等），并将结果直接推送到企业微信。

在这个基础上，如果我们想进行合规性把关——即不希望 AI Agent 绕过人工干预直接向全员群发送数据分析结果，应该如何实现？

我们可以将 Elastic HITL 审批机制 注入到该工作流中，具体逻辑如下：

1. AI Agent 接收到用户的自然语言指令（如 “请分析数据并发送结果到企业微信”）。
2. Agent 自动在后台生成分析结果，并将其作为参数调用 send_message_to_wecom_with_approval 工具。
3. 工作流被唤起，但并不会直接调用 WeCom Webhook，而是先执行一个 waitForApproval（或者带备注框的 waitForInput）审批步骤。
4. Kibana 页面弹出审批提示，并展示 AI 生成的通知草稿。
5. 管理员/分析师审核无误后点击 “Approve (同意)”，工作流恢复运行，正式调用 HTTP Connector 将信息发送至企业微信。

代码与配置实战

第一步：创建企业微信 HTTP Connector

首先，我们需要在 Kibana 中创建一个名为 wecom-http 的 HTTP 连接器，用于向企业微信群机器人发送 Webhook 请求。

1. 获取您的企业微信群机器人 Webhook 地址，格式一般为： https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=<Your-Key>
2. 在 Kibana 中配置 HTTP 连接器：
   • Method (方法)：POST
   • Headers (请求头)：Content-Type: application/json
   • Default Body (默认请求体)：

     {
       "msgtype": "text",
       "text": {
         "content": "{{ This is SO COOL! }}",
         "mentioned_list": ["张三", "李四", "@all"],
         "mentioned_mobile_list": ["13800000000"]
       }
     }
     

第二步：编写包含 HITL 审批的 Workflow YAML

接下来，我们进入 Kibana 的 Workflows 界面，创建一个支持人工审批的工作流。

这里我们以 waitForInput 为例（这样不仅有同意/拒绝选项，还能让审批人填写修改意见或审批备注，最后一同记录到系统或发送至企业微信）：

version: "1"
name: Send Message to WeCom - with HITL Approval
enabled: true

triggers:
  - type: manual
    inputs:
      properties:
        message:
          type: string
          description: AI Agent 自动生成的企业微信待推消息
          default: Hello from Elastic Workflow with HITL!

steps:
  # 1. 注入 HITL 审批步骤，暂停工作流并呈递 AI 生成的草稿
  - name: manager_review
    type: waitForInput
    timeout: 48h # 设置 48 小时超时
    with:
      message: |
        ## 🔔 企业微信消息发布待审核提示

        **AI 助手为您生成的待发布内容如下：**
        > {{ inputs.message }}

        请您核对数据准确性。审核通过后，该内容将被正式推送到企业微信群。
      schema:
        type: object
        properties:
          approved:
            type: boolean
            title: "是否批准发布"
          notes:
            type: string
            title: "审批备注 / 修改说明"
        required: ["approved"]

  # 2. HTTP 发送步骤（增加了 if 条件门槛，仅在 approved 属性为 true 时执行）
  - name: send_message_to_wecom
    type: http
    if: "steps.manager_review.output.response.approved : true"
    connector-id: wecom-http
    with:
      method: POST
      body:
        msgtype: text
        text:
          # 合并 AI 原信息与审批人的备注
          content: |
            【审核通过】AI 助手分析报告：
            {{ inputs.message }}
            
            审批备注：{{ steps.manager_review.output.response.notes }}
            审核人：{{ steps.manager_review.output.respondedBy }}
        mentioned_list:
          - "@all"
      headers:
        Content-Type: application/json

关键代码解析：

1. manager_review 步骤：其类型为 waitForInput。它使用 Markdown 格式渲染了一个对人类友好的交互卡片，并定义了一个极简的 JSON Schema，要求审批人必须勾选一个布尔值 approved，同时可以选择填写 notes。
2. send_message_to_wecom 步骤：使用 if 守卫进行条件分支过滤。只有当上一步的输出结果 steps.manager_review.output.response.approved（根据 9.5 的 Output shape）值为 true 时，此 HTTP 发送步骤才会被触发。
3. 变量动态感知：最终发出的消息体中，我们通过 {{ steps.manager_review.output.respondedBy }} 动态捕获了执行审批动作的具体 Kibana 用户账号，确保了企业内部操作的审计完整性。

审批响应与恢复（Resume）方式

当工作流因 manager_review 暂停时，审批响应人可以通过以下三种方式来恢复工作流的执行：

1. Kibana 监控运行界面（Kibana Execution View） 响应人员打开 Kibana 的工作流运行历史视图，找到当前挂起的工作流实例，Kibana 会根据 YAML 中定义的 Schema 自动渲染出一个表单。审批人勾选 “是否批准发布”，填写审批备注，然后点击“提交”，工作流便会瞬间恢复运行。
2. 企业外部频道（如 Slack 通知链接） 如果结合了 Elastic Workflows 的 with.channels（目前内置支持 Slack），审批人会在 Slack 渠道收到包含短效、单次使用的凭证（token）的表单链接，无需登录 Kibana 系统即可通过移动端链接完成快捷审批（注：出于安全考虑，高度敏感和破坏性的工作流建议在 kibana.yml 中将 hitlExternalResume.enabled 设为 false，强制要求登录 Kibana 进行审批）。
3. 通过 Kibana API 异步恢复 若需与第三方审批系统（如飞书审批、OA 系统）联动，可由第三方系统审批完毕后，向 Kibana 发送 POST 接口请求来异步恢复该执行分支：

   POST /api/workflows/executions/{executionId}/resume
   Content-Type: application/json
   
   {
     "input": {
       "approved": true,
       "notes": "报告数据核对无误，准予发布。"
     }
   }
   

总结与设计最佳实践

根据 Elastic 官方的最佳设计指南，我们在为 AI Agent 和自动化规则编写 HITL 表单时，应该遵循以下几点：

• 决策前置 (Lead with the decision)：卡片的第一行应使用显著标题（如 Markdown ##），直接明了地告诉响应人需要做出什么决策（例如：“Isolate this host?” 或 “是否同意发布此报告？”）。
• 证据汇总 (Include the evidence)：将做出决策所需的全部关键证据（AI 分类结果、推理依据、关键统计指标、受影响的主机名等）以直观的列表或引用块嵌入在消息内容中，避免让审批人再次跳转或登录其他系统四处搜寻证据。
• 表单极简化 (Keep the schema small)：由于审批多发生于紧急排障或碎片化的移动端场景，表单字段不宜超过 3 个。一般建议只使用 1 个布尔值（是否通过）+ 1 个可选字符输入框（审批备注）。

通过在 Elastic Workflows 中结合 WeCom 连接器 与 Human-in-the-Loop 审批机制，我们可以将 AI 强大的数据提炼能力与人类坚实的经验决策完美融合。这不仅赋予了 AI 助理在业务层面的极高实用性，更在企业生产环境的安全治理上加上了一道牢固的 “黄金锁”。

原文：Human-in-the-loop workflows | Elastic Docs