ARTEX 开源 AI 自主渗透测试系统:LLM 多代理自动化攻防平台部署实战
当 AI 大模型遇上渗透测试,会发生什么?传统渗透测试高度依赖人工经验,一次完整的外网攻防往往需要数天甚至更久。而 ARTEX 的出现正在改变这一局面——它是一款开源的 AI 自主渗透测试系统,由 LLM 多代理(Multi-Agent)驱动,能够自主完成资产探索、漏洞挖掘、多步利用链推进,甚至漏洞修复后的自动复测。整套系统基于 Go 构建并内嵌 Next.js 前端,配合 PostgreSQL 数据库,单二进制即可运行。
如果你正在寻找一款真正意义上的自动化渗透测试工具,或者想研究 LLM 代理(Agent)在攻防领域的工程化落地方式,ARTEX 值得花半小时部署体验。项目提供了在线 Demo(https://artex-demo.vercel.app/ ),也可以按本文教程在本地快速跑起来。

产品介绍:什么是 ARTEX
ARTEX 是一套 LLM 多代理驱动的自动化入侵与渗透测试系统,核心定位是"给目标,出结果":安全工程师只需划定测试范围,剩下的信息收集、攻击面分析、漏洞验证、利用链推进,由系统中的多个 AI 代理协作完成。
技术栈上,后端采用 Go 编写(通过 go:embed 将 Next.js 静态导出的前端内嵌进单二进制),数据层使用 PostgreSQL,代理能力由 Norma SDK 提供(涵盖 agentcore、tool、permission、harness、memory、transcript 等模块)。这种设计带来的直接好处是部署极简——一个可执行文件加一个数据库,就能撑起完整的自动化渗透测试平台。
核心功能:从任务下发到漏洞复测的完整闭环
任务管理与执行过程可视化
所有渗透测试任务在「任务」页集中管理,每个任务卡片可以实时查看执行状态。点击进入任务详情后,「执行过程」页签以会话 / 工具调用的粒度还原 AI 代理的每一步操作,安全人员可以像翻看聊天记录一样审查 AI 的完整攻击思路。


漏洞发现与资产管理
「发现」页汇总跨任务的漏洞结果,支持按严重度(严重 / 高危 / 中危 / 低危)、状态、任务、资产等多维度筛选与导出;「资产」页则沉淀了全量资产数据,域名、子域、IP、端口、站点、端点层层归并,形成企业级的资产台账。


资产覆盖图与 ScopeSentry 资产同步
资产覆盖图采用力导向布局,把"范围内资产 + 已测高亮 + 节点折叠展开"画在一张图上,哪些资产被测过、哪些还是盲区一目了然,这直接支撑了渗透测试的覆盖度评估。

对于已经在使用 ScopeSentry 做资产测绘的团队,ARTEX 支持直接同步资产数据,省去重复收集的环节:
- 在「资产同步」页填入 ScopeSentry 的地址与 API Key,接入数据源;
- 按项目或任务维度选择同步目标与资产类型(域名 / 子域 / IP / 端口 / 站点 / 端点等);
- 一键导入后按公司资产范围自动归并,直接进入 ARTEX 的资产图,供代理探索使用。
流量录制、人在环路与拦截审批
系统内置记录型 MITM 代理,所有代理发起的请求流量都会被录制下来,方便事后审计与问题定位。遇到高风险操作时,「人在环路(Human-in-the-loop)」机制会暂停执行并等待人工确认,安全工程师可以在对话窗口中直接介入 AI 的决策过程。


拦截审批支持全局「第三方记录」和任务内「拦截记录」两个入口,点击行或展开按钮即可查看详情:
- 工具请求与裁决左右分栏展示(移动端自动上下排列),待审批记录可在详情中直接允许或拒绝;
- 展开后可查看当前轮输入、会话记录片段、模型或规则初判、执行输出、调用 ID,以及参数 / 审查配置的 SHA-256 指纹;
- 模型直接允许的历史记录不占用审批队列;重复提交已处理的渠道会返回 HTTP 409;
- 详情通过
GET /api/intercept/history/{id}读取,列表接口不返回上下文和输出,保证列表性能。

几个细节值得留意:上下文是工具请求产生时保存的会话记录片段,最多 24 条、每条 8 KiB;当前轮输入上限 32 KiB,执行输出上限 64 KiB,截断会明确注明。当前裁判模型仍只接收工具名称和参数,展示的会话上下文不代表模型据此决策。由于 Norma SDK 的中断钩子内容不包含引用 ID,结果关联仅在当前运行内能唯一匹配工具请求事件时成立;相同参数调用无法唯一匹配时会显示"未关联",避免错误归属。数据库启动迁移会自动补列,旧记录显示"未记录",旧任务归档可正常恢复。
代理管理与 LLM 配置
「Agent 管理」页可以查看和管理系统内各类代理,「LLM 配置」页则支持配置多个大模型供应商:Anthropic、OpenAI 或任何兼容 OpenAI 协议的端点,还能设置代理与故障转移策略。


远程 MCP 服务在系统设置中选择 http(Streamable HTTP)或 sse(旧版 SSE)。旧版 SSE 服务通常通过 GET /sse 创建事件流,再经由服务返回的 /message?sessionId=... 接收 JSON-RPC 请求;配置时 URL 填为 /sse,请求头按 Authorization=Bearer <token> 格式填写。
漏洞复测(Retest):修复验证自动化
漏洞修复后是否真正修好了?ARTEX 内置了独立的复测能力。任务详情的「复测」页签可分页选择本任务的漏洞、查看历次结论和证据,并手动发起复测。在漏洞列表行操作区或漏洞详情的「漏洞复测」区域点击「发起复测」,填写修复版本、测试条件或限制(均为选填),系统会创建一个独立的复测 Agent 会话;列表的平铺、按任务分组、按资产视图都提供该入口。复测运行时显示转圈图标和「复测中」,结束后恢复入口状态,并不会重启原扫描任务。
结论分为「仍可复现」「已修复」「确认无法」三种,每次的结论、证据和链路都会在漏洞详情中留档。系统预置了可编辑的「漏洞复测」(retester)Agent,可在 Agent 管理中配置提示词、LLM、运行预算和工具:默认使用其绑定的 LLM,未绑定则回退到全局激活配置。当复测会话成功完成且结论为「已修复」时,系统自动将漏洞状态改为「修复已确认」;执行中、失败、停止或其他结论则保留原状态,原始证据和报告始终保留,也可以在状态下拉菜单中手动标记。同一漏洞正在复测时会复用已有会话,停止、失败或服务重启后可重新发起。
技术优势:双图架构驱动的自主攻击链
市面上宣称"AI 渗透"的工具不少,真正能自主走完多步利用链的并不多。ARTEX 的核心竞争力在于它的双图架构与围绕双图设计的一整套自主推进机制。

探索图 + 资产图:把"目标是什么"和"测到什么程度"拆开
系统维护两张相互独立、又通过锚点连通的图:
| 图 | 作用域 | 节点 | 回答的问题 |
|---|---|---|---|
| 资产图(Asset Graph) | 全局共享,跨任务同一份 | root_domain / subdomain / ip / service / app / endpoint | 企业到底有哪些资产、父子关系与权重 |
| 探索图(Exploration Graph) | 每个任务独立 | goal / intent / fact / finding / hint | 这次任务从哪些事实派生了什么方向、算出了什么 |
两张图通过 exploration_anchors(node_id, asset_id) 锚点关联:意图、事实、漏洞都被定位到具体资产上。于是既能从"探索方向"看它打了哪些资产,也能从"某个资产"反查它被哪些意图测过、产出过哪些事实——这正是资产测试覆盖度和资产覆盖图的数据基础。资产图中的域名层级、父子关系与权重全部由程序计算,代理只提交原始信息,保证了资产数据的准确性。
事件驱动引擎与意图生命周期
引擎是事件驱动的闭环:图一变就唤醒 planner,planner 派生意图(intent),worker 领走意图、用真实工具执行,把新资产 / 事实 / 漏洞写回两图,写回又触发下一轮——直到目标被证明(prove_goal)。planner 读探索图态势、判目标、只在出现未覆盖的新方向时才派意图进前沿队列;worker 每次只领一条意图,执行完即停。这种"规划与执行解耦"的结构让攻击流程图在多代理并行下依然稳定。
Worker 间过程级信息交换:让代理站在彼此的肩膀上
深入的渗透过程中,大量有价值的观察(某个报错、某段响应、某个参数)出现在 worker 的执行过程里,却还没资格写成正式事实。为避免重复劳动,worker 具备跨工作搜索过程的能力:
search_all_worker_traces(q):在本任务其他 worker 的执行过程中按关键字搜索(自动排除自己),命中项带intent_id;list_worker_traces/get_worker_trace(intent_id, step_ids=[...]):先看有哪些 worker 跑过,再取其中某个执行过程的完整内容。
信息以"执行过程"为粒度在 worker 之间流动,而边界不变——每个 worker 仍然只做自己领到的那条意图。
Planner 多轮共享 Todolist:多步利用链稳定推进
真实的攻击链往往是有相互依赖的多步序列(发现注入点 → 获取凭据 → 横向移动 → 提权),把整条链一口气派下去必然乱套。ARTEX 的做法是 planner 持有一份按任务保留、跨唤醒共享的规划待办(todolist):
- planner 是事件驱动的——图一变就被唤醒,但每次都是全新会话;共享的 todolist 让一条利用链只需记录一次,然后在后续多轮里按序派生,而不是在单次会话里前置展开整条链;
- 每轮只针对"前置步骤已完成、其依赖的事实已存在"的下一步派生意图,并随进度把已被事实满足的步骤标记完成。
攻击链在"事件驱动 + 无状态会话"的环境下依然稳定推进、不重复、不错序——这是 ARTEX 能自主走完多步利用链的关键。
工程化细节:单二进制、内嵌前端、重启即迁移
- 单二进制交付:Next.js 前端静态导出后通过
go:embed内嵌进 Go 二进制,部署只需一个可执行文件; - 幂等迁移:数据库 schema 随
go:embed的schema.sql在每次启动时幂等执行(ADD COLUMN/CREATE INDEX IF NOT EXISTS),即"重启即迁移"; - 守护脚本:
start.sh/start.bat负责拉起程序,页面上一键更新依赖它完成换装; - 失败自动回滚:更新校验或冒烟不通过就丢弃暂存件;新版连续 3 次启动失败自动回滚到
artex.old。
系统整体分层如下:
| 层 | 职责 |
|---|---|
| 前端 | Next.js 静态导出,go:embed 内嵌进单二进制;可视化任务 / 资产 / 探索链路 / 覆盖图,人在环路对话 |
| server | net/http 路由 + JWT 鉴权 + SSE;Manager 托管任务、引擎、DB store 的生命周期 |
| engine | 每任务一个 plannerLoop + N 个 worker goroutine;意图领取、超时 / 暂停 / drain |
| agent | goals / planner / worker / mainagent,ToolSet 把双图暴露成 LLM 工具 |
| db | 双图的 Postgres 落地(pgx);schema 随 go:embed 每次启动幂等建表 |
| 支撑 | 记录型 MITM 代理、审批门、异步补全、MCP / 技能 / 记忆 / 报告 |

安装部署教程:五种方式总有一种适合你
前置依赖:数据库 PostgreSQL;探索功能需配置 LLM(ANTHROPIC_API_KEY 或 OPENAI_API_KEY,也可以在 UI 里配置)。
方式一:一键安装脚本(推荐)
git clone https://github.com/Autumn-27/ARTEX.git
cd ARTEX
./install.sh
脚本会检测并自动安装 Docker,随后让你在两种模式中二选一:
- ① 全部 Docker:填一个 Postgres 密码(可回车随机生成)→ 自动写
.env→docker compose up -d; - ② 本地运行:选择数据库(连接已有实例 / 用 Docker 起一个)→ 生成
config.json→ Go 编译内嵌单二进制 → 启动。
安装完成后打开 http://localhost:8787 (首次进入 /setup 设置管理员密码)。
方式二:Docker Compose(手动)
git clone https://github.com/Autumn-27/ARTEX.git
cd ARTEX
cp .env.example .env # 填 POSTGRES_PASSWORD、可选 ANTHROPIC_API_KEY
docker compose up -d # 拉取 autumn27/artex 镜像 + postgres
# → http://localhost:8787
镜像已内置常用工具链(ripgrep / curl / vim / npm / nmap 等);./skills 与 ./data 以绑定挂载方式持久化,重建容器不丢数据。
方式三:下载预编译二进制(Releases)
到 Releases 页面下载对应平台的 zip,解压后得到 artex + start.sh(Windows 为 start.bat)+ skills/ + config.example.json:
cp config.example.json config.json # 填好 database 连接
./start.sh # → http://localhost:8787
务必通过 start.sh / start.bat 启动,而不是直接运行 ./artex。它是守护脚本:程序退出后按退出码决定是否重新拉起,页面上的一键更新依赖它完成换装;直接运行 ./artex 时,更新完成后进程不会被重新拉起。后台常驻方式:
nohup ./start.sh >artex.log 2>&1 &
方式四:从源码编译单二进制
# 1) 前端静态导出
cd web && npm ci && npm run build:static && cd ..
# 2) 拷进内嵌目录
cp -r web/out server/webui/dist
# 3) 编译(-tags embedui 才内嵌前端)
CGO_ENABLED=0 go build -tags embedui -o artex ./cmd/artex
./start.sh
方式五:构建跨平台发布包
build.sh 会先构建并嵌入前端,再通过 Go linker 去除调试信息,最后把发布文件压缩为 zip。Release 模式默认生成 Linux amd64/arm64、macOS amd64/arm64 和 Windows amd64 的 zip 包:
./build.sh --release
# 产物:dist/artex-0.3.3-*.zip
UPX 自解压二进制可能与部分 Linux 内核、虚拟化环境或安全策略不兼容,因此默认不启用。可用 ARTEX_TARGETS 自定义目标;确认目标运行环境兼容时,可加 --upx 进一步缩小二进制:
ARTEX_TARGETS=linux/amd64,windows/amd64 ./build.sh --release
./build.sh --target linux/amd64 --upx
配置说明
数据库连接在 config.json 中配置(也可用环境变量 ARTEX_PG_DSN 覆盖):
{
"database": {
"host": "127.0.0.1", "port": 5432,
"user": "artex", "password": "yourpass",
"dbname": "artex", "sslmode": "disable"
}
}
LLM 密钥通过环境变量注入(二选一),也可以在 UI 的「LLM 配置」页填写:
export ANTHROPIC_API_KEY=sk-...
# 或
export OPENAI_API_KEY=sk-...
进阶可选环境变量:ARTEX_LLM_PROVIDER / ARTEX_LLM_MODEL / ARTEX_LLM_BASE_URL / ARTEX_LLM_PROXY。每个任务的 worker 代理数在「系统设置」里配置,默认 3 个。
常用启动参数(start.sh 参数原样透传给 artex):
./start.sh -addr :8787 -proxy :8788
# -addr 前端 + API 端口
# -proxy 流量代理端口
本地开发环境一条命令起全栈:
./dev.sh # 后端(:8787) + 流量代理(:8788) + 前端 next dev(:5173) → http://localhost:5173
仅后端:go run ./cmd/artex(不带 -tags embedui 则不内嵌前端);仅前端:cd web && npm run dev(/api 反代到后端,带热更新);跑测试:go test ./...;无 LLM 的模拟预览:cd web && NEXT_PUBLIC_MOCK=1 npm run dev。
更新升级:只换程序、不动数据
升级只会替换程序,数据全部保留:Postgres 数据卷 pgdata、./data(jwt.key / SQLite 等)、./skills 都不会动。数据库迁移由程序在每次启动时幂等执行,即"重启即迁移";升级前仍建议先备份 ./data 与数据库。
页面一键更新(推荐)
在系统配置页(侧边栏「系统配置」→ /system/settings)的「版本与更新」卡片里,可以直接检查并安装新版本,无需登录服务器。点「更新」后的流程:下载当前平台的发布包 → 比对 Release 的 SHA256SUMS → 用 -h 冒烟测试新二进制 → 暂存为 artex.new → 程序退出,由 start.sh / start.bat 重新拉起并完成换装,页面自动等待新版本上线后刷新。
这套机制对失败场景做了充分防护:
- 失败不留坏程序:校验或冒烟不通过就丢弃暂存件,继续运行当前版本;换装后的新版若连续 3 次启动失败,自动回滚到
artex.old(失败版本留作artex.failed供排查); - 随时可回退:上一版本保留为
artex.old,卡片上有「回滚到上一版本」按钮(注意数据库结构不会回退); - 更新即重启,会中断正在运行的任务,请在空闲时段操作;
- 开发构建不给更新:版本号是
dev或git describe带后缀时禁用更新,避免正式版覆盖本地调试二进制; - Docker 下只换程序、不换镜像:镜像里的 playwright / nmap 等工具链不会跟着升级,
docker compose up -d重建容器后会退回镜像自带版本;要连镜像一起升级,执行docker compose pull artex && docker compose up -d artex; - 访问 GitHub 需要代理时,在同一页面配置全局代理即可,更新链路会走代理;更新只从 GitHub 域名下载并强制 HTTPS。
其他更新方式
一键更新脚本:
cd ARTEX
./update.sh
脚本先可选 git pull 拉取最新代码,再选择 ① Docker 更新或 ② 本地编译更新(与 install.sh 对应)。Docker 方式可指定目标镜像 tag(回车沿用 .env 的 ARTEX_TAG,缺省 latest),执行 docker compose pull → docker compose up -d 即完成;本地方式重建前端静态产物并重新编译 ./artex,完成后重启进程生效。
Docker Compose(手动):
cd ARTEX
git pull # 更新 compose / 脚本(可选)
# 指定版本:在 .env 设 ARTEX_TAG=v0.2.0;不设则用 latest
docker compose pull artex
docker compose up -d artex # 换新镜像重启 → 自动迁移 schema
docker image prune -f # 清理旧镜像(可选)
预编译二进制(Releases):
cp -r <解压目录>/skills ./ && cp <解压目录>/artex ./
./start.sh
下载新版本 zip 后,停掉旧进程,覆盖 artex 与 skills/(保留你的 config.json 与 data/),重启即可。
从源码编译:
git pull
cd web && npm ci && npm run build:static && cd ..
cp -r web/out server/webui/dist
CGO_ENABLED=0 go build -tags embedui -o artex ./cmd/artex
# 重启 ./start.sh
应用场景:谁适合用 ARTEX
- 企业安全团队:对内网、外网资产做周期性的自动化渗透测试,用资产覆盖图量化测试盲区,用复测功能闭环修复验证;
- 红队 / 攻防演练:快速完成资产测绘与攻击面梳理,多代理并行探索,人在环路机制保证高危动作可控;
- SRC 挖掘 / 独立安全研究员:对授权目标做持续深度的漏洞挖掘,过程级信息交换减少重复劳动,多步利用链自动推进;
- 安全产品开发者:研究 LLM 多代理在攻防场景的工程化范式——双图架构、意图生命周期、过程级信息共享,都是可直接借鉴的设计。
总结
ARTEX 把 LLM 多代理、双图架构、事件驱动引擎这套组合真正落地到了渗透测试场景:资产归并与探索解耦,planner 与 worker 分工协作,多步利用链能在无状态会话间稳定推进,再配上覆盖图、拦截审批、漏洞复测和一键更新等工程化能力,已经超越"AI 辅助工具"的范畴,更接近一个可交付的AI 自主渗透测试平台。
项目完全开源(GitHub: https://github.com/Autumn-27/ARTEX ),建议先在在线 Demo(https://artex-demo.vercel.app/ )里逛一圈界面,再挑一种部署方式在本地跑一个授权目标,亲身体验 AI 代理自主攻防的过程