Nebula 3 预览版：把 AI 辅助收敛进带审批闸门的渗透工作台

它要解决的是一份渗透记录在多个工具之间被拆散的问题

一次安全评估的产出很少只是一份报告。终端里的命令输出、浏览器里查到的 CVE 页面、随手记下的端口清单、最后写进报告的结论，通常散落在五六个互不相通的工具里。Nebula 的定位是把这些部分放进同一个桌面界面：终端、代码、浏览器、助手、文件、笔记、missions、findings、reports。README 的原话是「Nebula brings the working parts of a security engagement into one desktop surface」。

目标用户写得很清楚，是操作者而不是全自动扫描器。README 里有一句判断值得单独拎出来：「AI can investigate, organize, and write. The operator defines the scope, grants authority, and decides what runs.」也就是说，模型负责调查、整理和撰写，范围由人划定，授权由人给出，执行由人决定。这个分工如果你不接受，Nebula 的整套设计对你就是负担而不是帮助。

它不适合的场景同样明显。批量扫资产、跑完就出报告的流水线式扫描，用现成的扫描器更快；Nebula 的价值在于把「为什么得出这个结论」这条链路保留下来，而不是提高单位时间内的目标覆盖数。

审批闸门与内容寻址产物：链路里真正起作用的两段

README 给出的数据流是一行：intent → assistance → approval → execution → evidence。这五个环节里，前两个是常规的 AI 交互，后三个才是 Nebula 区别于普通聊天式助手的地方。

approval 这一段，文档描述为「Scope enforcement, approval pauses, hard budgets, and isolated OCI execution sit between AI assistance and the systems under test」。四道约束并排放在模型与目标系统之间：范围强制、批准暂停、硬性预算、隔离的 OCI 执行。注意这里说的是 OCI 隔离，也就是容器运行时级别的边界，而不是在进程里做参数过滤。对渗透工具来说，这个选择意味着一次越界请求最多污染一个容器，而不是操作者的宿主环境。

evidence 这一段依赖两类结构：内容寻址产物（content-addressed artifacts）与只追加事件（append-only events）。内容寻址意味着产物按内容哈希定位，改动即产生新地址，旧地址仍可追溯；只追加意味着事件记录不能被就地改写。README 还提到执行来源（execution provenance）与带完整性清单的导出（integrity-manifested exports）。这套组合的实际用途是回答一个审计问题：报告里这条结论，当时是基于哪次执行、哪份输出得出的。

需要说清楚的是，README 没有给出这些产物的具体存储格式、哈希算法或导出文件的结构，仓库里也没有在本文可见的材料中说明哈希碰撞或存储膨胀如何处理。如果你要把这套证据链用于正式的合规交付，这些细节需要自己在 docs/NEBULA3.md 和 docs/AUTOMATION-RUNTIME.md 里确认。

安装路径：签名 APT 源、手动 DEB 与 AppImage 三条路

当前发布候选是 Nebula 3.0.0-alpha.5，仅面向 Linux x86_64，终端与自动化功能需要 Docker 或 Podman。README 明确写了 macOS、Windows 和 Linux arm64 安装包不在当前发布矩阵内。

首选方式是签名 APT 仓库。README 给出的公钥指纹是 1D90 1EB3 4C8C 1065 F118 680D 1C5C 924C B4B5 823D，安装前应当核对。完整流程如下：

sudo apt update sudo apt install -y ca-certificates curl gnupg curl -fsSL https://berylliumsec.github.io/nebula-apt/nebula-archive-keyring.asc | gpg --show-keys --fingerprint curl -fsSL https://berylliumsec.github.io/nebula-apt/nebula-archive-keyring.asc | sudo gpg --dearmor --batch --yes -o /usr/share/keyrings/nebula-archive-keyring.gpg echo "deb [arch=amd64 signed-by=/usr/share/keyrings/nebula-archive-keyring.gpg] https://berylliumsec.github.io/nebula-apt prerelease main" | sudo tee /etc/apt/sources.list.d/nebula.list >/dev/null sudo apt update sudo apt install nebula nebula

注意源里写的是 prerelease 频道，README 说明这是 Nebula 3 处于预览期时的有意选择。DEB 支持 Debian、Ubuntu、Kali 及兼容系统，后续更新仍走常规 APT 流程，由管理员控制。

第二条路是手动下载 DEB。从 GitHub Releases 取 DEB 和 SHA256SUMS-linux-x64.txt，先校验再安装：

sha256sum --check --ignore-missing SHA256SUMS-linux-x64.txt sudo apt install ./Nebula-3.0.0-alpha.5-linux-x86_64.deb

第三条路是免安装的 AppImage，同样先校验，再赋可执行权限运行，走 Nebula 自己的签名直更通道。

README 里有一条容易踩的坑：不要用 pip install nebula-ai 安装 Nebula 3。另外首次启动时，Nebula 可能需要下载、准备并验证官方 Kali 镜像，终端与自动化功能在此之前不可用，视网络与容器运行时不同可能耗时数分钟。启动后可以运行 nebula-core doctor --json 检查 Core 与本地运行时的边界。

从源码运行需要凑齐四套工具链

源码路径的门槛不低。README 要求 Python 3.11 到 3.13、Poetry 2.1.3、Node.js 20 与 npm、稳定的 Rust 工具链，以及对应操作系统的 Tauri 前置依赖。命令序列是：

git clone https://github.com/BerylliumSec/nebula.git cd nebula poetry install --with dev poetry run playwright install chromium npm --prefix ui ci npm --prefix ui run dev:desktop

最后一条命令会构建本地 Nebula Core sidecar、启动 UI 开发服务器，并从检出目录直接打开原生桌面。

这里有一个细节值得展开。Playwright 那一步不是可选项：README 说明 Playwright 浏览器用于渲染 JavaScript 驱动的 URL 知识源，签名的 Linux 安装包里已经内置了锁定的 Chromium headless 运行时，而源码检出需要显式安装。Nebula 也可以使用系统已有的 Chrome 或 Chromium。换句话说，URL 知识源这个功能依赖真实浏览器渲染，而不是简单的 HTTP 抓取，这在面对前端渲染的漏洞公告页面时有实际意义，代价是多一个浏览器运行时依赖。

纯浏览器开发和合入前检查走另一组命令：npm --prefix ui run build 加 poetry run nebula-core ui，让 Core 自行选择可用的回环端口。主要检查项是 python scripts/nebula3_version.py check、poetry run pytest -q tests/v3、npm --prefix ui test、npm --prefix ui run build。

模型提供方是可选的，这决定了它和纯 AI 工具的分界线

README 里有一句容易被忽略但影响部署决策的话：Nebula 支持托管、本地和 OpenAI 兼容的模型运行时，模型提供方是可选的；没有模型时，人类终端、证据工作流、笔记、findings 和报告仍然可用。

这条设计把 Nebula 和那些离开 API key 就完全不能用的 AI 安全工具区分开了。对处理敏感目标的团队来说，可选意味着两件事：一是不必把目标信息送到第三方模型服务，二是模型服务中断或额度耗尽时工作台不会整体失效。本地运行时这一项也解释了为什么安装包体积和首次启动准备时间会偏大。

反过来看，这也说明 Nebula 的核心不是模型本身。模型只是 intent 和 assistance 两段，approval、execution、evidence 三段与模型无关。如果你的需求主要是「让大模型帮我写报告」，这套审批与证据机制的复杂度可能超出收益。

alpha 预览版的真实约束与 Nebula 2 迁移的不可逆风险

版本号里的 alpha 不是装饰。当前发布候选是 3.0.0-alpha.5，同期的 2.0.1b1 和 2.0.1b2 也都是 beta。README 对预览构建给了一条判定规则：只有当 GitHub Releases 上出现 nebula-v3.* 条目及其原生产物时，构建才算存在。

README 同时要求：使用前备份 engagement 数据，并查看发布说明与校验和。这句话放在预览版的语境里分量不轻，因为证据链是只追加的，一旦写入就难以回退。

从 Nebula 2 迁移的命令是：

nebula-core import-2x "/path/to/nebula-2-engagement"

README 的表述是导入过程不修改源目录，并要求在删除原始数据之前先验证导入的项目及其证据。完整的完整性与恢复流程在 docs/MIGRATING-2-TO-3.md 里。这里的顺序不能颠倒：导入、验证、确认无误，才谈得上删除源数据。

许可证方面，仓库采用 BSD-2-Clause，属于宽松型许可，通常允许修改与再分发，义务集中在保留版权声明与免责条款。README 里还有一条使用边界值得原样对待：「Use Nebula only on systems and networks you own or are explicitly authorized to test.」这不是法律建议，具体条款适用请咨询专业人士。

维护成本上，仓库最近一次推送是 2026-09-09，预览期版本迭代频繁，同时维护 Python、Node 与 Rust 三套工具链意味着升级时可能出现依赖冲突。README 提到未来更新通过常规 APT 工作流进行，由管理员控制，这一点对生产环境是有利的。

和纯扫描器相比，差别在链路而不在扫描能力

把 Nebula 和传统漏洞扫描器放在一起比较，容易得出错误结论。扫描器的产出是漏洞列表加严重级别，工作流是配置目标、运行、导出报告。Nebula 的产出是执行来源与内容寻址证据，工作流是 intent 到 evidence 的五段链路。

真正的差别在于谁来承担判断责任。扫描器把判断封装在规则库里，你接受它的误报率；Nebula 把判断交回操作者，模型只做调查、整理和撰写，范围、授权、执行决定权都在人手里。前者的瓶颈是规则覆盖，后者的瓶颈是操作者的时间。

这也解释了 approval pauses 和 hard budgets 为什么必须存在。如果模型可以直接执行，Nebula 就退化成一个有终端权限的聊天机器人，而它相对扫描器的唯一优势，也就是可追溯的判断链路，会立刻消失。

代价是速度。每一步执行前的人工批准会显著降低自动化程度，这是设计取舍而不是缺陷。如果你的评估目标是尽可能多地覆盖资产，扫描器更合适；如果你需要向客户或审计方解释每条结论的来源，Nebula 的链路设计才对得上需求。

编辑结论

如果你在 Linux x86_64 上做授权范围内的渗透测试，并且希望 AI 的每一步动作都留下可审计的证据链，Nebula 3 的审批暂停、范围约束和内容寻址产物值得按预览版试用；如果你需要 macOS、Windows 或 arm64 原生安装包，或者不愿意在主力工作机上跑 Docker 容器，当前发布矩阵里没有你的位置，应继续留在 Nebula 2。动手前先做两件事：核对 APT 源公钥指纹 1D90 1EB3 4C8C 1065 F118 680D 1C5C 924C B4B5 823D，再在首次启动后运行 nebula-core doctor --json 确认 Core 与本地运行时的边界符合预期。

官方来源

1. berylliumsec/nebula on GitHub
2. License: BSD-2-Clause
3. Project website
4. README
5. Releases