BruceSec 平台整合实践（三）：工作流编排实战
系列文章：把自建安全平台的功能版块，一期一期整理成技术博客，内容全部基于本机真实运行实例，附真实界面截图。
第 3 期：工作流编排实战 —— 用 DAG 把「信息收集 → 扫描 → 入库」串成自动化闭环。
0. 声明
本文是个人技术实践记录。平台基于开源项目CyberStrikeAI二次开发，上游项目版权归原作者所有；本文所有截图、数据均来自本人本机实例，内容聚焦个人化整合与使用实践，与上游官方文档、宣传材料无关，不构成对上游项目的替代性描述。文中出现的真实路径、密钥、公网资产均已做脱敏处理（截图中涉密列已遮挡）。
1. 为什么第三期写"工作流编排"
前两期把平台的总览生态和资产信息收集闭环讲完了。但"能跑通"和"能自动跑"是两回事：资产入库之后，谁去持续扫描？扫描结果谁来分析？分析完谁把资产写回库？总不能每次都手动点一遍。
平台内置的工作流编排引擎解决的就是这个问题：把「开始 → 工具执行 → Agent 分析 → 入库」串成一张可视化 DAG，跑一次就是一条完整链路，跑 N 次就是持续监控。本期基于本机真实数据，把工作流版块完整拆一遍。
2. 版块总览：工作流画布长什么样
进入侧边栏「工作流」，核心是左侧工作流列表 + 中间节点库 + 右侧可视化画布的三段式布局：
本机真实状态：
- 2 个工作流定义：
IP监控、内网资产信息搜集，各自带启用/禁用、编辑入口； - 7 类编排节点：开始 / 工具 / Agent / 条件 / 审批 / 输出 / 结束；
- 4 个特色入口：导入本地包（
.csapkg.zip）、用自然语言创建、试运行、生成草稿； - 画布支持「生成草稿 → 人工复核 → 保存」的半自动建流路径。
3. 真实案例一：内网资产信息搜集（5 节点 DAG）
这是平台里最有代表性的一条流：从 LLM 参数解析，到 nmap 扫描，再到资产入库，全部编排化。
3.1 节点链
start-1 (start) └─ 输入键：message / conversationId / projectId / target / ports / timing ↓ parse_params (agent) # 从用户输入提取 target/ports/timing 的 JSON ↓ nmap_scan (tool) # 调用 nmap，参数模板绑定上游 outputs 三字段 ↓ asset_extract (agent) # 解析扫描结果，调 create_asset 入库 ↓ output- 节点类型覆盖
start / agent / tool / output四类，汇聚策略均为all_merge； - 该工作流已迭代8 个版本（schema_version=1），说明是在真实使用中逐步打磨出来的。
3.2 三次真实运行：从翻车到稳定
数据库workflow_runs记录了 3 次完整运行，全部completed：
| 版本 | 开始时间 | 耗时 | 结果 |
|---|---|---|---|
| v1 | 08-14 16:38:35 | ~9.7s | 参数解析失败，0 hosts scanned，空汇总兜底 |
| v2 | 08-14 16:47:36 | ~39.8s | 参数解析成功，nmap 识别 8080/tcp，资产入库 1 条 |
| v7 | 08-14 16:55:06 | ~50.4s | 全链路成功，create_asset 入库成功 |
第 1 次运行的翻车现场值得单独说：parse_params没解析出 target，nmap 收到空参数（Failed to resolve ""）。但链路没有崩，asset_extract节点正确返回了空汇总——「未发现存活主机，未调用 create_asset，不要虚构结果」。
这正是编排引擎该有的容错素养：节点失败不中断整条流，下游 Agent 有"不虚构结果"的护栏。
第 2 次运行拿到真实数据：{"target":"127.0.0.1","ports":"8080","timing":""}，nmap 识别出8080/tcp上是 Golang net/http 服务、http-title: BruceSec，随后资产入库。14 条workflow_node_runs明细显示：nmap 工具节点耗时 26s+，agent 子图内部还会拆成 prepare → execute → finalize 三个阶段，可观测性很细。
4. 真实案例二：IP 监控（并行扇出 + 汇聚）
第二条流是典型的持续监控场景：一个开始节点，扇出两个并行 nmap 扫描，最后all_merge汇聚。
- 4 节点 4 边：
start-1→ 并行nmap-1/nmap-2（固定参数-sV）→output-1； - 这条流是LLM 生成草稿出来的（
generated_by=llm, needs_review=true），正好演示"自然语言建流 → 人工复核"的路径； - 两个扫描目标为外网 IP（已脱敏），配合
-sV做服务版本探测，适合周期性跑。
5. 编排配置侧：一条完整的链路
工作流不是孤岛，它挂在平台的多代理编排体系上。config.yaml 里这条链路真实可查：
| 层级 | 配置项 | 本机值 | 作用 |
|---|---|---|---|
| 总开关 | multi_agent.enabled | true | 多代理编排总开关 |
| 默认模式 | multi_agent.robot_default_agent_mode | eino_single | 机器人默认编排模式 |
| 模式族 | conversations表 | eino_single 11 / plan_execute 2 / deep 1 | 三种编排模式均有真实使用 |
| 角色绑定 | roles/内网资产搜集.yaml | workflow_id: intranet-asset-discovery+workflow_policy: auto | 角色与工作流自动绑定 |
| 工具白名单 | 常驻工具 | task、transfer_to_agent、write_todos、tool_search、TaskCreate/Get/Update/List、batch_task_*等 | 编排期可用工具 |
| 任务板 | plantask_rel_dir | .eino/plantask（13 个会话目录） | P0 结构化任务板持久化 |
| 崩溃恢复 | checkpoint_dir | data/eino-checkpoints（13 个会话目录） | ADK Resume 自动续跑 |
| 大输出截断 | reduction_enable | true（阈值 100000 字节） | 工具大结果落盘不撑爆上下文 |
编排相关 API
工作流 CRUD 共 17 个端点：/api/workflows、/validate、/dry-run、/generate-draft、/runs/:id/replay|resume、/workflow-package-*；另有/api/batch-tasks批量任务队列 13 个端点（start/rerun/pause/schedule 等），为批量编排预留。
常用工具配方
编排节点可引用的工具来自 tools 配方库（96 个配方、86 个 enabled），自动化相关主要有：exec.yaml（Shell 执行）、execute-python-script.yaml（Python 执行）、nmap.yaml（扫描）、query-execution-result.yaml（大结果查询）。平台整体工具执行记录 84 次，其中 nmap 19 次、create_asset 2 次、exec 32 次、rustscan 5 次——与工作流链路高度相关。
6. 本期结论
- 编排引擎真实可用：本机 2 个工作流定义、3 次完整运行、14 条节点明细，全部跑通，不是演示数据；
- 容错设计在实战里被验证：v1 参数解析失败时，下游 Agent 空汇总兜底、不虚构结果——这是自动化链路最容易被忽略的一环；
- 建流路径多样：可视化拖拽、LLM 生成草稿 + 人工复核、导入本地包（
.csapkg.zip）三条路都能到； - 可观测性够用：节点级运行明细、agent 子图三阶段拆分、
mcp_execution_ids全程留痕，排障有据可查。
