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. 创建 Workflow 的方式

3.1 方式一：直接描述要创建的 Workflow

在会话或 Workflow 页面中向 Rex 描述目标，例如：

帮我创建一个研判 NDR 告警的工作流。

输入：一条或一批 NDR 告警原文
步骤：
- 解析告警字段
- 补充情报、资产和历史告警上下文
- 委派告警研判 Agent 给出结论
- 生成结构化 JSON 和 Markdown 报告
- 通过通道外发高危结果

要求：
- 每个节点都要有输入输出 schema
- 生成后执行单节点测试和全流程集成测试
- 测试数据和报告落到 Workspace outputs 目录

需求描述越清晰，生成的 Workflow 越贴近实际业务。建议同时说明输入数据、关键判断逻辑、输出格式、失败处理方式和外发规则。

Tip：最好给 Rex 提供一条样例数据。这样在生成 Workflow 后，Rex 可以立刻使用样例数据进行单节点测试和全流程集成测试。

3.2 方式二：先和 Rex 讨论方案，再生成 Workflow

针对一个还没有完全想清楚的任务，可以先和 Rex 进行讨论，让 Rex 帮你分析最佳流程方案，再基于建议直接生成 Workflow。

例如：

我想把漏洞资产排查做成一个 Workflow。
请先帮我分析这个任务应该拆成哪些步骤、每一步需要什么输入输出、是否需要调用 Agent 或工具。
确认方案后，再帮我生成工作流并执行测试。

这种方式适合任务目标明确，但流程边界、节点拆分、工具选择或输出结构还需要一起梳理的场景。

3.3 方式三：从一次成功任务中沉淀 Workflow

如果 Rex 已经在会话里跑通了一次完整流程，可以继续让 Rex 把这次过程沉淀为 Workflow：

基于刚才的告警研判过程，帮我创建一个可复用的 Workflow。
请保留关键步骤、节点输入输出、工具选择、Agent 委派和最终报告格式。

这种方式适合把一次已经验证过的流程变成可测试、可复用、可定时运行的自动化剧本。

3.4 方式四：导入已有 workflow.json 或外部剧本

Workflow 的结构化定义可以导入导出。团队成员可以把已经验证过的 workflow.json 分享给其他 Workspace 使用；导入后建议立即执行一次单节点测试和集成测试，确认工具、模型和数据源在当前环境中可用。

如果已有 Dify 或 n8n 的剧本配置文件，也可以直接交给 Rex。Rex 会读取原始剧本的节点、连线、输入输出和工具调用逻辑，并尽量生成一套等价的 Flocks Workflow。

例如：

这是一个 n8n 告警处置剧本配置文件。
请帮我转换成 Flocks Workflow，保持原有流程逻辑，并补充节点测试数据。

转换完成后仍建议执行完整测试，因为外部剧本中的凭据、接口、节点类型和运行环境可能与 Flocks 当前 Workspace 不完全一致。

4. WebUI 操作流程

4.1 进入 Workflow 页面

在侧栏进入 Agent 工作室 → Workflow 工作流。页面通常会显示：

• 工作流列表与启用状态。
• 每个工作流的描述文档和结构化定义。
• 可视化节点图。
• 单节点测试和运行历史。
• 导入、导出、运行、调试等操作入口。

4.2 在工作流上下文中生成

Workflow 页面中的对话与 对话管理 共享同一套 Agent 运行时。区别在于，Workflow 页面会提供当前工作流上下文和可视化节点信息，便于 Rex 在生成、修改和调试过程中引用节点结构。

4.3 Rex 生成节点和数据流

Rex 通常会完成这些动作：

1. 解析需求，识别需要的节点类型。
2. 设计节点顺序和分支逻辑。
3. 生成 Workflow 描述文档。
4. 生成 workflow.json 结构化定义。
5. 配置节点输入输出 schema。
6. 生成或准备测试数据。
7. 在页面中呈现可视化节点图。

此时工作流的架子已经搭好，但还需要通过验证后才适合正式使用。

4.4 自动校验和测试

生成后，Rex 会继续执行验证流程：

1. 结构校验：检查节点、边、起始节点、schema 和必要字段是否完整。
2. 单节点测试：每个节点使用测试数据独立运行，确认输入输出格式和工具调用可用。
3. 全流程集成测试：用完整测试数据走一遍端到端流程。
4. 失败自动调试：如果测试失败，Rex 会根据错误信息修改节点配置、数据映射或提示词，并重新测试。

4.5 正式运行

校验完成后，可以先在 Workflow 页面直接运行，也可以在会话里自然语言触发做一次试运行：

帮我用 NDR 告警研判工作流跑一下这批告警。

进入正式运行阶段后，Workflow 通常有三种发布方式：

1. 发布 API：接收 JSON 输入，对外提供稳定的流程调用入口，适合被安全平台、工单系统或内部业务系统主动调用。
2. 发布流式任务：对接 syslog / Kafka 等输入源，持续接收告警、日志或事件流，适合事件到达即触发的实时处理场景。
3. 配置定时任务：在 任务中心 中配置周期运行，适合日报、周报、周期巡检、定时拉取告警等场景。

发布为 API 时，页面会生成专属调用地址和 API Key，并提供调用示例。发布为流式任务时，可以配置 syslog 或 Kafka 输入；syslog 场景通常需要填写监听协议、地址、端口、解析格式和写入 Workflow inputs 的字段名。无论采用哪种发布方式，建议先用样例数据完成一次页面运行，再进入长期运行。

5. Workflow 的文件结构与安装

5.1 存储位置

Workflow 支持用户级和项目级两类存储：

类型	存储位置	说明
项目级 Workflow	当前项目或 Workspace 下的 .flocks/plugins/workflows/	只在当前项目 / Workspace 中可见。
用户级 Workflow	用户目录下的 ~/.flocks/plugins/workflows/	当前用户的多个 Workspace 可复用。

5.2 目录结构

每个 Workflow 通常是一个独立文件夹：

workflows/
└── ndr-alert-triage/
    ├── workflow.json
    ├── workflow.md
    ├── testdata/
    └── README.md

其中：

• workflow.json 存储结构化工作流定义，包括节点、边、schema 和运行配置。
• workflow.md 或其他 .md 文件存储人类可读的流程说明、节点职责、使用方式和验收标准。
• testdata/ 可以存储用于单节点测试和集成测试的样例数据。
• 其他脚本或模板文件可根据节点需要补充。

5.3 安装新的 Workflow

把一个新的 Workflow 文件夹放到 .flocks/plugins/workflows/ 或 ~/.flocks/plugins/workflows/ 下，即可完成安装。系统会识别其中的 workflow.json，并在工作流列表或运行时加载。

安装后建议立即执行一次测试，确认当前环境中的模型、工具、MCP、凭据和输出路径都可用。

6. 运行、验证与调整

6.1 查看执行产出

Workflow 执行结束后，可以查看：

• 会话或 Workflow 页面里的运行摘要。
• 每个节点的输入输出和执行状态。
• 结构化结果、Markdown 报告和外发结果。
• Workspace outputs/ 中的测试数据、中间数据和最终产物。

6.2 验证 Workflow 是否符合预期

重点检查：

• 输入输出 schema 是否稳定。
• 每个节点是否可重复执行。
• 外部工具、API、MCP 和凭据是否可用。
• 分支条件和失败路径是否符合业务预期。
• 最终报告是否满足团队格式和审计要求。

6.3 调整 Workflow

如果 Workflow 运行结果不理想，可以在 Rex 对话中明确说明要优化哪个工作流、哪个节点或哪个数据流。

例如：

帮我优化 NDR 告警研判工作流。
当前情报补充节点返回字段太少，请增加 IOC 背景、历史关联、信誉评分和证据来源，
并同步调整后续研判节点的输入 schema。

Rex 可以基于反馈调整节点配置、数据映射、提示词、工具选择或输出格式。调整后应重新执行单节点测试和集成测试。

7. 核心概念

7.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 会根据任务需要选择节点，并在生成后逐个节点测试。

7.2 数据 schema

每个节点都应定义输入输出 schema。schema 是 Workflow 稳定运行的关键，它决定上游输出能否被下游节点正确消费。

单节点测试主要验证节点本身是否可运行，集成测试主要验证数据能否沿着整条链路正确流转。

7.3 导入导出

workflow.json 支持导入导出，便于版本备份、跨 Workspace 迁移和团队共享。导出前建议确保已经通过集成测试；导入后也应在目标环境重新测试。

7.4 输入与发布形态

Workflow 可以接收结构化 JSON 数据作为输入，并发布成 API，对外提供稳定的流程调用入口。适合把告警研判、资产核查、IOC 批量查询、报告生成等能力封装成可被其他系统调用的服务。

Workflow 也可以接收 syslog、Kafka 等流式输入，并发布成流式任务。适合持续处理安全设备日志、告警流、资产变更事件或其他实时数据源。

选择发布形态时可以这样判断：

• JSON 输入 / API 发布：适合按需调用、批量提交、由外部系统主动触发的流程。
• syslog / Kafka 流式任务：适合持续监听、实时处理、事件到达即触发的流程。
• 任务中心周期运行：适合按固定时间窗口汇总、巡检或生成报告的流程。

7.5 与会话的关系

Workflow 页面内的对话和 对话管理 内的对话共享同一套 Agent 运行时。区别在于 Workflow 页面会额外提供"正在设计或调试某个工作流"这个上下文，因此 Rex 会主动参考当前节点图和工作流定义。

7.6 Workflow 的能力边界

Workflow 适合稳定、可重复、可测试的流程，不适合把所有临场判断都写死。实践中建议：

• 节点职责清晰，避免一个节点承担太多逻辑。
• schema 尽量稳定，减少隐式字段和自由文本传递。
• 外部 API 和工具调用集中封装，便于失败定位。
• 复杂判断可以委派给 Agent 节点，但不要让工作流层级过深。
• 每次修改后都重新运行测试。

7.7 运行时与调试细节

Workflow 运行前会进行结构检查，确认节点、连线、起始节点和必要字段完整。运行时会保留节点输入输出、执行日志和运行历史，便于定位失败原因。

部分节点可以带自己的运行依赖、超时配置或运行环境要求。涉及 Python、外部命令、API、MCP 的节点，建议在生成后先做单节点测试，再跑全流程集成测试。这样可以快速区分是工具不可用、凭证错误、schema 不匹配，还是模型节点输出不稳定。

8. 真实案例：NDR 告警研判工作流

8.1 案例背景

需要把 NDR 告警研判流程沉淀为可重复运行的工作流。输入是一条或一批告警，输出是结构化研判结论和可外发报告。

8.2 创建过程

用户可以向 Rex 提供目标、告警样例、处置规范和输出模板。Rex 会生成初始节点图，例如：

1. 解析告警原文。
2. 补充 IOC 情报。
3. 查询资产和历史告警上下文。
4. 委派告警研判 Agent 给出判断。
5. 生成 JSON 和 Markdown 报告。
6. 根据风险等级决定是否外发。

8.3 验证过程

Rex 会继续执行：

1. 单节点测试，每个节点用样例数据跑通。
2. 集成测试，用完整告警数据走全流程。
3. 失败调试，根据错误信息修正 schema、节点配置或工具参数。

8.4 产出结果

典型产出包括：

• workflow.json：结构化工作流配置，可导入导出。
• workflow.md：人类可读的流程说明。
• 测试数据和中间结果。
• 最终 JSON 结论和 Markdown 报告。
• 外发到通道或任务中心的运行结果。

9. 常见问题

9.1 生成的 Workflow 跑不起来怎么办？

先看单节点测试失败还是集成测试失败。常见原因包括：所需工具或 MCP 未接入、模型能力不足、schema 缺少字段、凭据不可用、外部 API 响应变化等。

9.2 Workflow 执行太慢怎么办？

可以合并可批处理节点、减少不必要的模型节点、缓存重复查询结果、优化外部 API 调用，或为关键节点选择更快的模型和工具。

9.3 能不能手工改 workflow.json？

可以。workflow.json 是结构化定义文件，支持直接编辑和重新导入。但改完后一定要重新运行单节点测试和集成测试。

9.4 Workflow 和 Skill 有什么区别？

维度	Workflow	Skill
是什么	可执行流程 / 节点图	方法论 / 规范 / 任务模板
能独立执行吗	能，平台按图运行	不能，需要被 Agent 加载
适合	稳定步骤、批量处理、定时运行	判断方法、检查清单、经验复用

9.5 Workflow 和任务中心是什么关系？

Workflow 解决"流程怎么定义"，任务中心解决"什么时候、按什么频率运行"。典型链路是：Workflow 定义好并测试通过，然后在任务中心配置周期运行和结果通知。

10. 相关模块

• 对话管理：通过 Rex 创建、运行和调整 Workflow。
• Agent 智能体：Workflow 节点可以委派给专家 Agent。
• Skills 技能库：为 Agent 节点提供方法论。
• 工具清单：Workflow 节点的执行工具来源。
• 任务中心：把 Workflow 固化成周期运行。
• Workspace：Workflow 定义、测试数据与产物的存放位置。
• 场景实践 · 告警研判：典型 NDR 工作流走读。
• 场景实践 · 威胁情报与 IOC 研判：批量 IOC 研判工作流。

操作演示视频将在发布物料稳定后补充到本页。