在 大模型 和 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 审批机制 注入到该工作流中，具体逻辑如下：
- 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?key=<Your-Key> - 在 Kibana 中配置 HTTP 连接器：
-
Method (方法) ：
POST -
Headers (请求头) ：
Content-Type: application/json -
Default Body (默认请求体)：
css` 1. { 2. "msgtype": "text", 3. "text": { 4. "content": "{{ This is SO COOL! }}", 5. "mentioned_list": ["张三", "李四", "@all"], 6. "mentioned_mobile_list": ["13800000000"] 7. } 8. } `AI写代码
-
第二步：编写包含 HITL 审批的 Workflow YAML
接下来，我们进入 Kibana 的 Workflows 界面，创建一个支持人工审批的工作流。
这里我们以 waitForInput 为例（这样不仅有同意/拒绝选项，还能让审批人填写修改意见或审批备注，最后一同记录到系统或发送至企业微信）：
yaml
`
1. version: "1"
2. name: Send Message to WeCom - with HITL Approval
3. enabled: true
5. triggers:
6. - type: manual
7. inputs:
8. properties:
9. message:
10. type: string
11. description: AI Agent 自动生成的企业微信待推消息
12. default: Hello from Elastic Workflow with HITL!
14. steps:
15. # 1. 注入 HITL 审批步骤，暂停工作流并呈递 AI 生成的草稿
16. - name: manager_review
17. type: waitForInput
18. timeout: 48h # 设置 48 小时超时
19. with:
20. message: |
21. ## 🔔 企业微信消息发布待审核提示
23. **AI 助手为您生成的待发布内容如下：**
24. > {{ inputs.message }}
26. 请您核对数据准确性。审核通过后，该内容将被正式推送到企业微信群。
27. schema:
28. type: object
29. properties:
30. approved:
31. type: boolean
32. title: "是否批准发布"
33. notes:
34. type: string
35. title: "审批备注 / 修改说明"
36. required: ["approved"]
38. # 2. HTTP 发送步骤（增加了 if 条件门槛，仅在 approved 属性为 true 时执行）
39. - name: send_message_to_wecom
40. type: http
41. if: "steps.manager_review.output.response.approved : true"
42. connector-id: wecom-http
43. with:
44. method: POST
45. body:
46. msgtype: text
47. text:
48. # 合并 AI 原信息与审批人的备注
49. content: |
50. 【审核通过】AI 助手分析报告：
51. {{ inputs.message }}
53. 审批备注：{{ steps.manager_review.output.response.notes }}
54. 审核人：{{ steps.manager_review.output.respondedBy }}
55. mentioned_list:
56. - "@all"
57. headers:
58. Content-Type: application/json
`AI写代码收起代码块关键代码解析：
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接口请求来异步恢复该执行分支：bash` 1. POST /api/workflows/executions/{executionId}/resume 2. Content-Type: application/json 4. { 5. "input": { 6. "approved": true, 7. "notes": "报告数据核对无误，准予发布。" 8. } 9. } `AI写代码
总结与设计最佳实践
根据 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 助理在业务层面的极高实用性，更在企业生产环境的安全治理上加上了一道牢固的 "黄金锁"。