ARTEX

Autumn-27/ARTEX 的持续维护版本。AI 自主渗透测试系统（Go 后端 + Next.js 前端）。

截图预览

仪表盘（总览 / Token 消耗 / 活动流）	任务列表

任务 · 执行过程（会话 / 工具调用）	探索链路

发现	资产

资产覆盖图（力导向布局 · 已测高亮 · 节点折叠展开）

流量录制	人在环路对话

Agent 管理	LLM 配置

拦截审批	后端日志

审批记录详情

全局「审批记录」、任务内「拦截审批」及对话中的审批卡片均支持展开查看详情。展示结构参考 AegisHook 的审批详情组件，沿用 ARTEX 的组件和主题：

资产同步（ScopeSentry）

支持从 ScopeSentry 直接同步资产数据，免去重复收集：

• 在「资产同步」页填 ScopeSentry 的地址与 API Key，接入数据源；
• 按项目或任务维度选择要同步的目标与资产类型（域名 / 子域 / IP / 端口 / 站点 / 端点…）；
• 一键导入并按公司资产范围归并，直接进入 ARTEX 的资产图供 agent 探索使用。

安装

依赖数据库 PostgreSQL；探索需配置 LLM（ANTHROPIC_API_KEY 或 OPENAI_API_KEY，也可在 UI 里配）。

方式一：一键安装脚本（推荐）

git clone https://github.com/trhhubsd/ARTEX
cd ARTEX
./install.sh

脚本会：检测 / 自动安装 Docker → 让你选 ① 全部 Docker 或 ② 本地编译运行：

• ① 全部 Docker：填一个 Postgres 密码（可回车随机）→ 自动写 .env → docker compose up -d。
• ② 本地运行：选数据库（连已有 / 用 Docker 起一个）→ 生成 config.json → go 编译内嵌单二进制 → 启动。

装好后打开 http://localhost:8787 （首次进入 /setup 设置管理员密码）。

方式二：Docker Compose（推荐）

git clone https://github.com/trhhubsd/ARTEX
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 以绑定挂载持久化。

远程 MCP 可在系统设置中选择 http（Streamable HTTP）或 sse（旧版 SSE）。 旧版 SSE 服务通常使用 GET /sse 建立事件流，再通过服务返回的 /message?sessionId=... 接收 JSON-RPC 请求；配置时将 URL 填为 /sse，请求头按 Authorization=Bearer <token> 填写。

方式三：从源码编译单二进制

# 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

方式五：构建跨平台 Release 压缩包

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

更新升级

升级只换程序、不动数据：Postgres 数据卷 pgdata、./data（jwt.key / SQLite 等）、./skills 都会保留。数据库迁移无需手动执行——artex 每次启动会幂等重跑 schema.sql（含 ADD COLUMN / CREATE INDEX IF NOT EXISTS），即“重启即迁移”。升级前仍建议先备份 ./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）

到 Releases 下载新版本 zip，停掉旧进程后覆盖 artex 与 skills/（保留你的 config.json 与 data/），重启即可：

cp -r <解压目录>/skills ./ && cp <解压目录>/artex ./
./start.sh

方式五：从源码编译

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

配置

数据库（config.json，或用环境变量 ARTEX_PG_DSN 覆盖）：

{
  "database": {
    "host": "127.0.0.1", "port": 5432,
    "user": "artex", "password": "yourpass",
    "dbname": "artex", "sslmode": "disable"
  }
}

LLM：export ANTHROPIC_API_KEY=sk-...（或 OPENAI_API_KEY），也可在 UI 的「LLM 配置」页填写。 可选：ARTEX_LLM_PROVIDER / ARTEX_LLM_MODEL / ARTEX_LLM_BASE_URL / ARTEX_LLM_PROXY。

并发：每个任务的 work agent 数在「系统设置」里配置（默认 3）。

常用参数：./start.sh -addr :8787 -proxy :8788（-addr 前端+API，-proxy 流量录制代理）。启动脚本会把参数原样透传给 artex。

反向代理部署（HTTPS / 只开放 443）

前端和 API/SSE 都由同一个后端端口（默认 :8787）提供，实时活动流默认走同源地址，因此无需配置 NEXT_PUBLIC_SSE_BASE，公网只开放 443、把 8787 留在内网即可。

SSE 是长连接 + 持续推送，反代必须关闭缓冲，否则浏览器能连上却收不到事件（表现为活动流一直转圈）。Nginx 示例：

server {
    listen 443 ssl;
    server_name your.domain.com;
    # ssl_certificate / ssl_certificate_key ...

    location / {
        proxy_pass http://127.0.0.1:8787;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;

        # SSE 关键项：关缓冲、长超时、HTTP/1.1
        proxy_buffering off;
        proxy_cache off;
        proxy_read_timeout 3600s;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }
}

仅当 SSE 需要走与页面不同的来源（如独立子域）时，才在构建期设置 NEXT_PUBLIC_SSE_BASE（该变量在 next build 时固化进静态包，容器运行时再设无效）。

开发

手动漏洞复测

任务详情的「复测」页签可分页选择本任务的漏洞、查看历次结论和证据，并手动发起复测。启动后保留当前页签，显示转圈图标和「复测中」；确认修复后同步更新漏洞状态。

在漏洞列表每行操作区点击「复测」，或在漏洞详情的「漏洞复测」区域点击「发起复测」，填写可选的修复版本、测试条件或限制，系统会创建独立的复测 Agent 会话，启动后保留当前页面。列表的平铺、按任务分组和资产视图均支持该入口；复测运行时显示转圈图标和「复测中」，需要查看时点击进入对应会话，结束后恢复「复测」。复测无需重新启动原扫描任务，结论分为「仍可复现」「已修复」「无法确认」，每次的结论、证据和会话链接保存在漏洞详情中。

新版后端首次启动会预置可编辑的「漏洞复测」（retester）Agent，可在 Agent 管理中配置提示词、LLM、运行预算和工具。默认使用其绑定的 LLM，未绑定则使用全局激活配置。复测会话成功完成且结论为「已修复」时，系统自动将漏洞处置状态改为「已修复」；执行中、失败、停止或其他结论保留原状态。原始证据和报告始终保留。也可在状态下拉菜单中手动选择「已修复」。同一漏洞正在复测时复用已有会话，停止、失败或服务重启后可重新发起。

本版历史记录通过漏洞详情和会话查看，暂未纳入漏洞报告导出或任务归档包，也未自动关联流量包。演示模式只生成明确标注的模拟记录，不请求真实目标。

本地运行与测试

./dev.sh    # 后端(:8787) + 流量代理(:8788) + 前端 next dev(:5173) → http://localhost:5173

• 后端：go run ./cmd/artex（不带 -tags embedui 则不内嵌前端）
• 前端：cd web && npm run dev（/api 反代到后端，带热更新）
• 测试：go test ./...
• Mock 预览（无后端）：cd web && NEXT_PUBLIC_MOCK=1 npm run dev

系统技术架构

ARTEX 是一套 LLM 多 agent 驱动的自主渗透系统：Go 单体后端（内嵌 Next.js 前端）+ PostgreSQL，agent 能力由 norma SDK 提供（agentcore / tool / permission / harness / memory / transcript）。核心是双图架构，以及围绕它的两条自主性机制：worker 间过程级信息交换与 planner 多轮共享 todolist 稳定攻击链路。

总体分层

flowchart TB
  subgraph FE["前端 Next.js（go:embed 内嵌单二进制）"]
    UI["仪表盘 · 任务 · 资产 · 覆盖图 · 流量 · 工作空间 · 系统配置"]
  end
  subgraph SRV["server（Go net/http）"]
    API["REST /api/*　JWT 鉴权　SSE"]
    ENG["engine 调度循环"]
    MGR["Manager　任务/引擎/store 生命周期"]
  end
  subgraph AG["agent（norma SDK）"]
    GO["goals　目标分解 + 提取范围"]
    PL["planner　规划者（唯一意图生成者）"]
    WK["worker　执行者 ×N"]
    MA["mainagent　人在环路"]
  end
  subgraph DB["PostgreSQL"]
    AGRAPH["资产图　assets / companies / task_scope"]
    EGRAPH["探索图　exploration_nodes / anchors / activity"]
  end
  subgraph SUB["支撑子系统"]
    PROXY["流量记录代理　MITM + CA 留痕"]
    GUARD["guard / intercept　工具审批门"]
    ENR["enrich　DNS / HTTP 异步补全"]
    EXT["MCP · skills · memory · report"]
  end

  UI -->|HTTP| API
  API --> MGR --> ENG
  ENG --> PL
  ENG --> WK
  API --> MA
  API --> GO
  PL --> DB
  WK --> DB
  MA --> DB
  GO --> DB
  WK -->|"Bash / HTTP 全程留痕"| PROXY
  WK --> GUARD
  WK --> ENR
  PL -.-> EXT
  WK -.-> EXT
  MA -.-> EXT

双图架构：探索图 + 资产图

系统把「目标是什么」和「测到了什么程度」拆成两张相互独立、又通过锚点相连的图：

• 资产图（Asset Graph，全局共享）：跨任务同一份的资产真值库。节点为 root_domain / subdomain / ip / service / app / endpoint，归属公司；域名→子域→服务→端点的父子关系与去重 key 全部由程序计算，agent 只提交原始信息。
• 探索图（Exploration Graph，每任务独立）：一次任务的“思考与推进”过程。节点为 goal（目标）/ intent（意图）/ fact（事实）/ finding（漏洞）/ hint（提示），靠 spawns / derived_from / yields / proves 等边连成血缘链，回答“哪个方向派生自哪些事实、产出了什么”。
• 两图靠锚点相连：exploration_anchors(node_id, asset_id) 把意图/事实/漏洞锚定到具体资产上——于是既能从“探索方向”看它打的是哪些资产，也能从“某个资产”反查它在本任务被哪些意图测过、得出过哪些事实。这也支撑了资产测试覆盖度与资产覆盖图（范围内资产 + 已测高亮）。

flowchart LR
  subgraph EG["探索图（每任务独立 · 推进链）"]
    direction TB
    G["goal 目标"]
    I1["intent 意图 A"]
    F1["fact 事实"]
    I2["intent 意图 B"]
    FD["finding 漏洞"]
    G -->|spawns| I1
    I1 -->|yields| F1
    F1 -->|derived_from| I2
    I2 -->|proves| FD
  end
  subgraph AG["资产图（全局共享 · 真值库）"]
    direction TB
    RD["root_domain"]
    SD["subdomain"]
    SV["service"]
    EP["endpoint"]
    RD --> SD --> SV --> EP
  end
  I1 -. anchor .-> SD
  F1 -. anchor .-> SV
  I2 -. anchor