 审批工作流实战)
在大模型和 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 与 waitForApprovalElastic 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 审批机制注入到该工作流中具体逻辑如下AI Agent接收到用户的自然语言指令如 “请分析数据并发送结果到企业微信”。Agent 自动在后台生成分析结果并将其作为参数调用send_message_to_wecom_with_approval工具。工作流被唤起但并不会直接调用 WeCom Webhook而是先执行一个waitForApproval或者带备注框的waitForInput审批步骤。Kibana 页面弹出审批提示并展示 AI 生成的通知草稿。管理员/分析师审核无误后点击“Approve (同意)”工作流恢复运行正式调用 HTTP Connector 将信息发送至企业微信。代码与配置实战第一步创建企业微信 HTTP Connector首先我们需要在 Kibana 中创建一个名为wecom-http的 HTTP 连接器用于向企业微信群机器人发送 Webhook 请求。获取您的企业微信群机器人 Webhook 地址格式一般为https://qyapi.weixin.qq.com/cgi-bin/webhook/send?keyYour-Key在 Kibana 中配置 HTTP 连接器Method (方法)POSTHeaders (请求头)Content-Type: application/jsonDefault 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关键代码解析manager_review步骤其类型为waitForInput。它使用 Markdown 格式渲染了一个对人类友好的交互卡片并定义了一个极简的 JSON Schema要求审批人必须勾选一个布尔值approved同时可以选择填写notes。send_message_to_wecom步骤使用if守卫进行条件分支过滤。只有当上一步的输出结果steps.manager_review.output.response.approved根据 9.5 的 Output shape值为true时此 HTTP 发送步骤才会被触发。变量动态感知最终发出的消息体中我们通过{{ steps.manager_review.output.respondedBy }}动态捕获了执行审批动作的具体 Kibana 用户账号确保了企业内部操作的审计完整性。审批响应与恢复Resume方式当工作流因manager_review暂停时审批响应人可以通过以下三种方式来恢复工作流的执行Kibana 监控运行界面Kibana Execution View响应人员打开 Kibana 的工作流运行历史视图找到当前挂起的工作流实例Kibana 会根据 YAML 中定义的 Schema 自动渲染出一个表单。审批人勾选 “是否批准发布”填写审批备注然后点击“提交”工作流便会瞬间恢复运行。企业外部频道如 Slack 通知链接如果结合了 Elastic Workflows 的with.channels目前内置支持 Slack审批人会在 Slack 渠道收到包含短效、单次使用的凭证token的表单链接无需登录 Kibana 系统即可通过移动端链接完成快捷审批注出于安全考虑高度敏感和破坏性的工作流建议在kibana.yml中将hitlExternalResume.enabled设为false强制要求登录 Kibana 进行审批。通过 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
在大模型和 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 与 waitForApprovalElastic 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 审批机制注入到该工作流中具体逻辑如下AI Agent接收到用户的自然语言指令如 “请分析数据并发送结果到企业微信”。Agent 自动在后台生成分析结果并将其作为参数调用send_message_to_wecom_with_approval工具。工作流被唤起但并不会直接调用 WeCom Webhook而是先执行一个waitForApproval或者带备注框的waitForInput审批步骤。Kibana 页面弹出审批提示并展示 AI 生成的通知草稿。管理员/分析师审核无误后点击“Approve (同意)”工作流恢复运行正式调用 HTTP Connector 将信息发送至企业微信。代码与配置实战第一步创建企业微信 HTTP Connector首先我们需要在 Kibana 中创建一个名为wecom-http的 HTTP 连接器用于向企业微信群机器人发送 Webhook 请求。获取您的企业微信群机器人 Webhook 地址格式一般为https://qyapi.weixin.qq.com/cgi-bin/webhook/send?keyYour-Key在 Kibana 中配置 HTTP 连接器Method (方法)POSTHeaders (请求头)Content-Type: application/jsonDefault 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关键代码解析manager_review步骤其类型为waitForInput。它使用 Markdown 格式渲染了一个对人类友好的交互卡片并定义了一个极简的 JSON Schema要求审批人必须勾选一个布尔值approved同时可以选择填写notes。send_message_to_wecom步骤使用if守卫进行条件分支过滤。只有当上一步的输出结果steps.manager_review.output.response.approved根据 9.5 的 Output shape值为true时此 HTTP 发送步骤才会被触发。变量动态感知最终发出的消息体中我们通过{{ steps.manager_review.output.respondedBy }}动态捕获了执行审批动作的具体 Kibana 用户账号确保了企业内部操作的审计完整性。审批响应与恢复Resume方式当工作流因manager_review暂停时审批响应人可以通过以下三种方式来恢复工作流的执行Kibana 监控运行界面Kibana Execution View响应人员打开 Kibana 的工作流运行历史视图找到当前挂起的工作流实例Kibana 会根据 YAML 中定义的 Schema 自动渲染出一个表单。审批人勾选 “是否批准发布”填写审批备注然后点击“提交”工作流便会瞬间恢复运行。企业外部频道如 Slack 通知链接如果结合了 Elastic Workflows 的with.channels目前内置支持 Slack审批人会在 Slack 渠道收到包含短效、单次使用的凭证token的表单链接无需登录 Kibana 系统即可通过移动端链接完成快捷审批注出于安全考虑高度敏感和破坏性的工作流建议在kibana.yml中将hitlExternalResume.enabled设为false强制要求登录 Kibana 进行审批。通过 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
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
