文章总结： CyberStrikeAI新增图编排功能，允许用户在画布上拖拽节点和连线，将渗透测试步骤固化为可保存、可绑角色、可重复执行的流程图。该功能适合固定流水线、条件分支确定、人机协同卡点等规程型任务，与适合探索型任务的Agent编排互补。技术实现基于工作流引擎，支持节点类型包括Start、Agent、Tool、Condition、HITL等，并具备Checkpoint和审计记录。用户可通过角色绑定workflow_id实现自动执行，并利用模板传参确保数据流正确。 综合评分： 85 文章分类： 渗透测试,安全工具,红队,内网渗透,解决方案

当安全测试需要一张图：CyberStrikeAI 图编排全新上线

原创

低调学安全 低调学安全

低调学安全

2026年7月3日 20:58 北京

在小说阅读器读本章

去阅读

有些任务，交给 Agent 自己摸索就够了；有些任务，你必须先画好路线图。CyberStrikeAI 本次新增图编排（Graph Orchestration），就是为后者准备的。

一、这次新增了什么？

CyberStrikeAI 的核心能力是：用 AI + MCP 把 100+ 安全工具串起来，让渗透测试像对话一样发生。

此前，平台已具备基于 Eino 的Agent 编排——单代理、Deep、Plan-Execute、Supervisor 等模式，让模型在运行时自主决策。这一次，我们新增图编排：在 Web 端用画布拖拽节点、连线，把步骤、分支、审批点固化成可保存、可绑角色、可重复执行的流程图。

两种编排方式，对应两种不同的工作方式：

| 路径 | 代表能力 | 本质 | | — | — | — | | Agent 编排 | Eino 单代理 / Deep / Plan-Execute / Supervisor | 模型在运行时决定下一步做什么 | | 图编排 | 画布上的 Start → Agent → Tool → Condition → HITL → Output | 人在运行前把步骤、分支、审批点画清楚 |

• 探索型任务：目标模糊、攻击面未知、需要临场换招——协调主代理带着子代理和 MCP 工具自由发挥，往往更合适。你描述意图，它拆任务、派单、汇总。
• 规程型任务：SOP 已定、合规要留痕、高危步骤必须卡点、多角色要按固定顺序接力——你需要一张可审计、可复现、可版本化的流程图，而不是每次对话都重新「即兴演出」。

安全行业对此并不陌生：红队有 playbook，蓝队有 runbook，合规审计要的是「你按什么顺序做了什么」，而不只是「AI 最后说了什么」。

图编排承载的，是显式流程契约：步骤、分支、传参、审批点，全部落在一张图上。左侧导航图编排 入口、角色绑定workflow_id、完整使用文档，均已随本次更新一并提供。

二、什么时候该画图，什么时候别画？

适合图编排的场景

1. 固定流水线 例如：子域枚举 → 端口扫描 → Web 指纹 → 按结果分支到 nuclei / sqlmap。步骤稳定，只是目标参数在变。
2. 条件分支必须确定 「扫到 443 且证书含某 SAN → 走路径 A，否则走路径 B。」这类逻辑写在图里，比写在 prompt 里可靠一个数量级。
3. 人机协同（HITL）卡点 利用链、C2 下发、批量 exploit 之前，流程必须在指定节点暂停等人点头。图编排把 HITL 嵌进拓扑，而不是靠模型「记得问一下」。
4. 多 Agent 分工但顺序固定 侦察 Agent 的输出命名写入outputs.recon_summary，验证 Agent 只读这个变量继续——角色分工仍用 Agent，交接规则由图保证。
5. 交付给团队的可复用资产 画布保存为workflow_id，绑到角色上，新人选角色即跑同一套流程。这是组织知识，不是个人聊天记录。

不必图编排的场景

1. 开放式渗透 / CTF 路径未知，强行画图会束缚模型；用 Deep 或多代理模式更合适。
2. 一次性 ad-hoc 查询 「帮我用 fofa 查一下这个域」——单轮工具调用，图为它建流程是过度设计。
3. 强依赖上下文的连续博弈 与目标多轮交互、根据每一轮响应即时改策略——这恰恰是 Agent 编排的主场。

一句话：图编排适合「我知道该怎么做」；Agent 编排适合「我不知道会碰到什么，但要做到底」。按场景选即可。

三、技术实现：画布之下发生了什么？

图编排不是前端花架子，背后是一套完整的工作流引擎。保存时，画布上的 JSON 会经校验、编译，再交给CloudWeGo Eino Compose 执行。

3.1 从graph_json 到可运行图

用户在 Web 端拖拽的节点与边，持久化为graph_json。保存时引擎会：

• 解析图结构，检查至少一个Start、一个Output，禁止 Start 有入边、Output 有出边；
• 试编译（trial-compile）：编译不过则无法保存，把配置错误拦在运行前；
• 编译结果按workflow_id + version 缓存，图未变则复用，减少重复编译开销。

核心编译逻辑在internal/workflow/engine.go：每个画布节点映射为 EinoWorkflow 上的一个节点——普通节点是LambdaNode，Agent 节点则编译为子图（GraphNode），内部仍可走eino_single 或deep /plan_execute /supervisor 等模式。图是外层调度骨架，Agent 是节点内的执行单元，二者可以嵌套使用。

3.2 执行模型：有向图 + 运行时状态机

执行从Start 出发，沿边遍历。引擎维护一份WorkflowLocalState，其中三块状态决定模板变量如何取值：

| 状态 | 模板前缀 | 含义 | | — | — | — | | inputs | {{inputs.message}} 等 | 用户消息、会话 ID、项目 ID | | lastOutput | {{previous.xxx}} | 执行顺序上 上一节点的输出（不是画布上的「上游」） | | outputs | {{outputs.变量名}} | 全局命名变量池，由节点的output_key 写入 |

这里有一个容易踩坑、但恰恰体现设计深度的点：

{{previous.output}} 是「链式上一步」，不是「连线上游」。

若路径是Agent A → 条件 → Agent B，则 B 的previous 是条件节点的true/false，不是 A 的扫描结果。跨条件、跨工具节点传参，应使用{{outputs.agent_result1}} 这类命名变量。

这是图编排与「简单管道」的本质区别：拓扑是拓扑，数据流是数据流；用outputs 注册表把二者解耦，才能画分支而不丢上下文。

3.3 节点类型与能力边界

| 节点 | 作用 | | — | — | | Start | 注入inputs，流程入口 | | Agent | 调用 Eino 单代理或多代理，支持节点级instruction 与input_source 模板 | | Tool | 直接调 MCP 工具，参数 JSON 支持{{...}} 模板 | | Condition | 表达式求值，驱动是/否分支 | | HITL | 人工审批检查点；编译时注册InterruptBeforeNodes，配合 checkpoint 可暂停恢复 | | Output | 写入最终outputs，供对话摘要展示 | | End | 可选结束摘要模板 |

工具节点走ExecuteMCPToolForConversation，与聊天里调工具同一套 MCP 桥接。

3.4 可靠性与审计

• Checkpoint：运行状态落盘data/workflow-checkpoints，长流程与 HITL 中断后可恢复。
• 运行记录：workflow_runs 表记录每次执行的输入、输出、状态、pending HITL 节点，与平台审计日志、对话历史同轨。
• 进度事件：对话页可订阅workflow_start、workflow_node_start、workflow_tool_start 等，图执行过程对用户可见，而非黑盒跑完才给结果。

四、怎么用：从画布到角色对话

4.1 搭建流程

1. 登录 Web 控制台 → 左侧图编排
2. 新建或选择流程，在画布添加节点、连线
3. 填写流程ID、名称、描述 →保存（触发校验与编译）

画布操作：添加节点、连线模式、右侧属性面板、自动布局、删除选中。建议每个需被下游引用的 Agent/工具节点都设好output_key（如scan_result、parsed_targets）。

4.2 绑定角色

角色管理 中为角色选择绑定的workflow_id，策略设为auto：

name: 外网资产巡检
workflow_id: asset-scan-v1
workflow_version: latest
workflow_policy: auto

用户选择该角色发消息后，对话入口会加载对应图并自动执行。

4.3 模板传参口诀

• 直连两步：{{previous.output}} 最简
• 中间有条件/工具/审批：上游写output_key，下游用{{outputs.xxx}}
• 读用户原始输入：{{inputs.message}}
• 条件判断：优先基于{{outputs.xxx}}，避免误用previous 拿到true/false

4.4 示例：跨条件传递 Agent 结果

开始 → Agent（侦察，output_key: recon）→ 条件（{{outputs.recon}} != ""） ├─ 是 → Agent（验证，输入: {{outputs.recon}}）→ 输出 └─ 否 → 输出（静态说明「无结果」）

若 Agent（验证）误写{{previous.output}}，拿到的是条件的布尔值——这是文档里最高频的排错点，也是理解执行模型的钥匙。

更完整的节点字段说明、连线条件、排错表，见项目内文档：docs/workflow-graph.md

五、一张图背后的设计取舍

这次做图编排，背后有几条清晰的产品判断：

1. 模型的不确定性在探索任务里是优势——开放场景应交给 Agent 编排。
2. 规程与合规需要确定性——关键路径可以外置为人可读的图。
3. 图与 Agent 可以组合——图里的 Agent 节点照样可以 Deep 编排；图管调度，节点管智能。
4. 安全测试的可复现性——同一workflow_id、同一版本，团队得到的是同一拓扑；这比「上次 prompt 大概这么写的」更接近工程实践。

如果你手头有一份跑过无数次的巡检 SOP、一份必须留痕的授权测试检查表、一条「扫到高危必须先审批再继续」的纪律——值得画一张图。

六、快速上手清单

• [ ] 拉取 / 升级到最新 CyberStrikeAI，在左侧导航找到图编排
• [ ] 图编排页：Start + Output 各至少一个，试跑一条线性流程
• [ ] 为一个 Agent 节点配置output_key，下游用{{outputs.xxx}} 验证跨节点传参
• [ ] 角色管理绑定workflow_id，workflow_policy: auto
• [ ] 用该角色发一条测试消息，在对话页观察 workflow 进度事件
• [ ] 阅读 图编排使用说明 中的条件分支与 HITL 章节

欢迎在社区交流你的 playbook 是怎么画成图的。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：低调学安全 低调学安全 低调学安全《当安全测试需要一张图：CyberStrikeAI 图编排全新上线》