Workflow 工作流
Workflow 承载的是"把动作组织成稳定流程"的能力。它以剧本的形式完成网安中固定流程的任务，面向结构清晰、步骤稳定、需要重复或长期运行的场景，例如固定类型告警的标准化研判处置、周期巡检、日报生成、批量资产核查等。
与传统剧本或拖拽式工作流产品最大的差异是，Flocks 的编排过程不需要手工拖拽节点。用户只需要用语言描述任务流程，Rex 会自动完成编排，并逐个节点进行测试运行，最终交付一个可以立即使用的工作流。
1. 功能定位
1.1 Workflow 解决什么问题
Workflow 回答的是"这件事应该按什么流程稳定执行"。当任务步骤明确、输入输出清晰、需要复用或定时运行时，应优先沉淀为 Workflow。
在 Flocks 中，Workflow 不只是一个静态流程图，而是一份可运行、可测试、可发布的安全运营剧本。Rex 会把自然语言需求转化为节点、数据流和运行配置，并通过单节点测试与全流程集成测试验证可用性。
一个典型 Workflow 包含：
- 流程描述文档：用
.md说明流程目标、节点职责、输入输出和运行方式。 - 结构化定义：用
workflow.json描述节点、边、数据流、schema 和运行配置，支持导入导出。 - 节点定义：每个节点可以是工具调用、Agent 委派、模型推理、条件判断、人工确认等。
- 数据流：节点之间通过明确的输入输出 schema 传递数据。
- 测试数据与产物：单节点测试、集成测试和正式运行的中间结果通常落到 Workspace
outputs/。
1.2 Workflow 与其他模块的关系
| 模块 | 关系 |
|---|---|
| 对话管理 | Rex 可以在会话中创建、运行、调试或修改 Workflow。 |
| Agent 智能体 | Workflow 节点可以委派给专家 Agent；Agent 也可以在执行中触发 Workflow。 |
| Skills 技能库 | Skill 提供方法论，Workflow 固化稳定流程；二者可以配合使用。 |
| 工具清单 | 工具节点的执行能力来源，包括 API、MCP、Python、本地命令等。 |
| 任务中心 | 通过任务中心把 Workflow 固化成周期运行能力。 |
| Workspace | Workflow 定义、测试数据和运行产物按用户级 / 项目级归属管理。 |
2. 适用场景
2.1 适合使用 Workflow 的情况
- 任务会重复执行：每天、每周、每小时或按事件触发。
- 步骤高度一致：每次都按相同顺序取数、判断、生成结果、外发通知。
- 需要稳定输入输出：下游任务、报表或通道依赖结构化 JSON / Markdown 报告。
- 需要测试和审计：希望每个节点可验证、可定位、可回归。
- 需要批量处理：例如批量告警研判、批量 IOC 查询、批量资产核查。
2.2 不适合使用 Workflow 的情况
如果任务是一次性的、探索性的，或执行路径需要根据大量上下文动态变化，直接放在会话里交给 Rex 或专家 Agent 处理通常更划算。
简单判断原则：
- 下次还要按同一套步骤跑，做 Workflow。
- 下次只是参考这次判断方法，做 Skill。
- 需要一个专业角色长期处理一类任务，做 Agent。
3. WebUI 操作入口
3.1 进入 Workflow 页面
在侧栏进入 Agent 工作室 → Workflow 工作流。页面标题为"工作流"，用于管理和执行工作流。
列表页会按来源展示工作流，并提供 全部 / 内置 / 自定义 筛选：
- 自定义工作流：用户或当前 Workspace 中创建、修改、安装的工作流。
- 内置工作流：随系统或插件提供的工作流模板与示例。
- 每张工作流卡片会展示名称、来源、状态、节点数、描述、调用次数、成功率和平均耗时。
点击工作流卡片会进入详情页；点击 创建工作流 会进入新建工作流页面。
3.2 创建、修改与发布
Workflow 的日常操作可以拆成三类：
- 创建工作流：从入口、AI 引导、内置案例、
workflow.md复核到生成workflow.json。 - 修改工作流：从流程图点击 Rex 引导，或直接进入工作台，用自然语言调整
workflow.md、节点和workflow.json。 - 调用工作流：校验完成后，可以直接测试运行，也可以发布为 API、Webhook、Syslog、Kafka 或定时触发。
创建和修改都建议以 workflow.md 作为人类可读的需求契约，再由 Rex 基于已确认的 workflow.md 生成或更新 workflow.json。这样能减少"界面看起来改了，但真实机器定义没有同步"的问题。
3.3 自动校验和测试
生成后，Rex 会继续执行验证流程：
- 结构校验：检查节点、边、起始节点、schema 和必要字段是否完整。
- 单节点测试：每个节点使用测试数据独立运行，确认输入输出格式和工具调用可用。
- 全流程集成测试：用完整测试数据走一遍端到端流程。
- 失败自动调试：如果测试失败，Rex 会根据错误信息修改节点配置、数据映射或提示词，并重新测试。
3.4 正式运行
校验完成后，可以先在 Workflow 页面直接运行，也可以在会话里自然语言触发做一次试运行：
帮我用 NDR 告警研判工作流跑一下这批告警。
进入正式运行阶段后，Workflow 通常有五种调用或触发方式：
- 发布为 API：接收 JSON 输入，对外提供稳定的流程调用入口，适合被安全平台、工单系统或内部业务系统主动调用。
- Webhook 接入：接收第三方系统推送的事件，适合告警回调、扫描结果推送和系统通知。
- Syslog 接入：监听安全设备或日志平台发送的 Syslog 数据，适合日志到达即触发的实时处理场景。
- Kafka 接入：消费 topic 中的消息并自动触发工作流，适合事件流、异步处理和高频数据接入。
- 定时触发：按固定周期主动运行，适合日报、周报、周期巡检、定时拉取告警等场景。
发布页会提供 Rex 辅助发布，可围绕 发布为 API、Syslog 接入、Kafka 接入、Webhook 接入、定时触发 等方式引导确认运行方式、鉴权、字段映射、样例和启停动作。
发布为 API 时，页面会生成专属调用地址和 API Key，并提供调用示例。发布为事件触发时，可以配置 Webhook、Syslog 或 Kafka 输入；Syslog 场景通常需要填写监听协议、地址、端口、解析格式和写入 Workflow inputs 的字段名。更多说明见 调用工作流。无论采用哪种方式，建议先用样例数据完成一次页面运行，再进入长期运行。
4. Workflow 的文件结构与安装
4.1 存储位置
Workflow 支持用户级和项目级两类存储：
| 类型 | 存储位置 | 说明 |
|---|---|---|
| 项目级 Workflow | 当前项目或 Workspace 下的 .flocks/plugins/workflows/ | 只在当前项目 / Workspace 中可见。 |
| 用户级 Workflow | 用户目录下的 ~/.flocks/plugins/workflows/ | 当前用户的多个 Workspace 可复用。 |
4.2 目录结构
每个 Workflow 通常是一个独立文件夹：
workflows/
└── ndr-alert-triage/
├── workflow.json
├── workflow.md
├── testdata/
└── README.md其中：
workflow.json存储结构化工作流定义，包括节点、边、schema 和运行配置。workflow.md或其他.md文件存储人类可读的流程说明、节点职责、使用方式和验收标准。testdata/可以存储用于单节点测试和集成测试的样例数据。- 其他脚本或模板文件可根据节点需要补充。
4.3 安装新的 Workflow
把一个新的 Workflow 文件夹放到 .flocks/plugins/workflows/ 或 ~/.flocks/plugins/workflows/ 下，即可完成安装。系统会识别其中的 workflow.json，并在工作流列表或运行时加载。
安装后建议立即执行一次测试，确认当前环境中的模型、工具、MCP、凭据和输出路径都可用。
5. 运行、验证与调整
5.1 查看执行产出
Workflow 执行结束后，可以查看：
- 会话或 Workflow 页面里的运行摘要。
- 每个节点的输入输出和执行状态。
- 结构化结果、Markdown 报告和外发结果。
- Workspace
outputs/中的测试数据、中间数据和最终产物。
5.2 验证 Workflow 是否符合预期
重点检查：
- 输入输出 schema 是否稳定。
- 每个节点是否可重复执行。
- 外部工具、API、MCP 和凭据是否可用。
- 分支条件和失败路径是否符合业务预期。
- 最终报告是否满足团队格式和审计要求。
5.3 调整 Workflow
如果 Workflow 运行结果不理想，可以在 Rex 对话中明确说明要优化哪个工作流、哪个节点或哪个数据流。
例如：
帮我优化 NDR 告警研判工作流。
当前情报补充节点返回字段太少，请增加 IOC 背景、历史关联、信誉评分和证据来源，
并同步调整后续研判节点的输入 schema。Rex 可以基于反馈调整节点配置、数据映射、提示词、工具选择或输出格式。调整后应重新执行单节点测试和集成测试。
6. 核心概念
6.1 节点类型
常见节点类型包括：
- 工具节点（Tool）：调用 API、MCP、本地 Python、Bash 或其他工具。
- HTTP 请求节点（HTTP Request）：直接调用外部 HTTP 接口，适合简单 API 请求或临时集成。
- Python 节点（Python）：执行 Python 逻辑，适合字段转换、数据清洗、离线计算等。
- 模型节点（LLM）：直接执行一次模型推理，适合摘要、分类、结构化抽取等。
- Agent 节点（Agent）：委派专家 Agent 处理一段子任务。
- 分支节点（Branch）：根据条件把流程分发到不同路径。
- 逻辑节点（Logic）：执行轻量逻辑判断、字段加工或流程控制。
- 循环节点（Loop）：对数组、批量告警、批量 IOC 等数据逐项处理。
- 子工作流节点（Subworkflow）：调用另一个 Workflow，适合复用已验证的流程片段。
- 人工确认节点：在关键环节暂停，等待用户确认。
- 汇合节点：把多个分支结果合并后继续执行。
实际创建时不需要手动记住所有节点类型。用户只要描述目标流程，Rex 会根据任务需要选择节点，并在生成后逐个节点测试。
6.2 数据 schema
每个节点都应定义输入输出 schema。schema 是 Workflow 稳定运行的关键，它决定上游输出能否被下游节点正确消费。
单节点测试主要验证节点本身是否可运行，集成测试主要验证数据能否沿着整条链路正确流转。
6.3 导入导出
workflow.json 支持导入导出，便于版本备份、跨 Workspace 迁移和团队共享。导出前建议确保已经通过集成测试；导入后也应在目标环境重新测试。
6.4 输入与发布形态
Workflow 可以接收结构化 JSON 数据作为输入，并发布成 API，对外提供稳定的流程调用入口。适合把告警研判、资产核查、IOC 批量查询、报告生成等能力封装成可被其他系统调用的服务。
Workflow 也可以接收 syslog、Kafka 等流式输入，并发布成流式任务。适合持续处理安全设备日志、告警流、资产变更事件或其他实时数据源。
选择发布形态时可以这样判断：
- JSON 输入 / API 发布：适合按需调用、批量提交、由外部系统主动触发的流程。
- syslog / Kafka 流式任务：适合持续监听、实时处理、事件到达即触发的流程。
- 任务中心周期运行：适合按固定时间窗口汇总、巡检或生成报告的流程。
6.5 与会话的关系
Workflow 页面内的对话和 对话管理 内的对话共享同一套 Agent 运行时。区别在于 Workflow 页面会额外提供"正在设计或调试某个工作流"这个上下文，因此 Rex 会主动参考当前节点图和工作流定义。
6.6 Workflow 的能力边界
Workflow 适合稳定、可重复、可测试的流程，不适合把所有临场判断都写死。实践中建议：
- 节点职责清晰，避免一个节点承担太多逻辑。
- schema 尽量稳定，减少隐式字段和自由文本传递。
- 外部 API 和工具调用集中封装，便于失败定位。
- 复杂判断可以委派给 Agent 节点，但不要让工作流层级过深。
- 每次修改后都重新运行测试。
6.7 运行时与调试细节
Workflow 运行前会进行结构检查，确认节点、连线、起始节点和必要字段完整。运行时会保留节点输入输出、执行日志和运行历史，便于定位失败原因。
部分节点可以带自己的运行依赖、超时配置或运行环境要求。涉及 Python、外部命令、API、MCP 的节点，建议在生成后先做单节点测试，再跑全流程集成测试。这样可以快速区分是工具不可用、凭证错误、schema 不匹配，还是模型节点输出不稳定。
7. 真实案例：NDR 告警研判工作流
7.1 案例背景
需要把 NDR 告警研判流程沉淀为可重复运行的工作流。输入是一条或一批告警，输出是结构化研判结论和可外发报告。
7.2 创建过程
用户可以向 Rex 提供目标、告警样例、处置规范和输出模板。Rex 会生成初始节点图，例如：
- 解析告警原文。
- 补充 IOC 情报。
- 查询资产和历史告警上下文。
- 委派告警研判 Agent 给出判断。
- 生成 JSON 和 Markdown 报告。
- 根据风险等级决定是否外发。
7.3 验证过程
Rex 会继续执行：
- 单节点测试，每个节点用样例数据跑通。
- 集成测试，用完整告警数据走全流程。
- 失败调试，根据错误信息修正 schema、节点配置或工具参数。
7.4 产出结果
典型产出包括：
workflow.json：结构化工作流配置，可导入导出。workflow.md：人类可读的流程说明。- 测试数据和中间结果。
- 最终 JSON 结论和 Markdown 报告。
- 外发到通道或任务中心的运行结果。
8. 常见问题
8.1 生成的 Workflow 跑不起来怎么办？
先看单节点测试失败还是集成测试失败。常见原因包括：所需工具或 MCP 未接入、模型能力不足、schema 缺少字段、凭据不可用、外部 API 响应变化等。
8.2 Workflow 执行太慢怎么办？
可以合并可批处理节点、减少不必要的模型节点、缓存重复查询结果、优化外部 API 调用，或为关键节点选择更快的模型和工具。
8.3 能不能手工改 workflow.json？
可以。workflow.json 是结构化定义文件，支持直接编辑和重新导入。但改完后一定要重新运行单节点测试和集成测试。
8.4 Workflow 和 Skill 有什么区别？
| 维度 | Workflow | Skill |
|---|---|---|
| 是什么 | 可执行流程 / 节点图 | 方法论 / 规范 / 任务模板 |
| 能独立执行吗 | 能，平台按图运行 | 不能，需要被 Agent 加载 |
| 适合 | 稳定步骤、批量处理、定时运行 | 判断方法、检查清单、经验复用 |
8.5 Workflow 和任务中心是什么关系？
Workflow 解决"流程怎么定义"，任务中心解决"什么时候、按什么频率运行"。典型链路是：Workflow 定义好并测试通过，然后在任务中心配置周期运行和结果通知。
9. 相关模块
- 创建工作流：创建入口、AI 引导、内置案例和
workflow.md复核。 - 修改工作流：通过流程图 Rex 引导或工作台自然语言修改工作流。
- 调用工作流：将工作流发布为 API、Webhook、Syslog、Kafka 或定时触发。
- 对话管理：通过 Rex 创建、运行和调整 Workflow。
- Agent 智能体：Workflow 节点可以委派给专家 Agent。
- Skills 技能库：为 Agent 节点提供方法论。
- 工具清单：Workflow 节点的执行工具来源。
- 任务中心：把 Workflow 固化成周期运行。
- Workspace：Workflow 定义、测试数据与产物的存放位置。
- 场景实践 · 告警研判：典型 NDR 工作流走读。
- 场景实践 · 威胁情报与 IOC 研判：批量 IOC 研判工作流。
操作演示视频将在发布物料稳定后补充到本页。