ARTEX 是一个面向安全测试团队的 AI 自主渗透测试系统，后端使用 Go，前端使用 Next.js，依赖 PostgreSQL，并通过 LLM 多 Agent 架构自动完成目标分解、资产探索、漏洞发现、人工审批、流量留痕和复测。项目定位偏攻防自动化平台，强调“探索图 + 资产图”的双图架构、Planner/Worker 多 Agent 协作、人在环路审批以及可视化任务管理。README 标注该仓库为最后版本源码备份，Docker 部署源可能失效，需要具备本地构建和排障能力。
适用领域
网络安全 / 渗透测试 / 漏洞扫描与复测 / 攻击面管理 / AI Agent / LLM 安全自动化 / 资产测绘 / 红队工具链 / 安全运营
配置难度
中高。若仅本地体验 UI 和 Demo，难度较低；若要部署可用的自主渗透测试环境，需要配置 PostgreSQL、LLM、代理、反向代理、审批策略和工具链，并理解安全边界。若 Docker 镜像不可用，则需要具备 Go/Node.js 源码构建和排障能力。
商业价值
对安全团队具有较高试验和平台化价值，可用于提升资产探索、漏洞验证、复测和证据留存效率，也适合作为企业内部 AI 安全测试平台或攻防演练辅助系统的基础。但其商业落地受许可证、项目维护状态、LLM 成本、合规授权和安全风控约束较大，更适合作为自研参考、PoC 或内部授权场景工具，而非直接无改造地用于生产级自动化攻击。
01
技术亮点
- AI 多 Agent 自主渗透测试：包含 goals、planner、worker、mainagent 等角色分工。
- 双图架构清晰：资产图用于全局资产真值，探索图用于任务内攻击链路与事实血缘追踪。
- 支持人在环路：高风险工具调用可通过审批、拦截、对话方式控制。
- 可视化能力较完整：仪表盘、任务、会话、探索链路、发现、资产、覆盖图、流量、Agent 管理、LLM 配置等页面。
- 支持漏洞复测流程：可为漏洞创建独立复测 Agent 会话并保留结论和证据。
- 支持流量录制代理：有助于安全测试证据留存和行为追溯。
- 支持 ScopeSentry 资产同步，适合与现有资产测绘平台联动。
- Go 单体后端可内嵌前端，部署形态相对简单。
- 支持 Docker、预编译二进制、源码编译、本地开发等多种运行方式。
- 提供系统更新、回滚、数据库幂等迁移等运维设计。
02
目标用户
- 企业安全团队
- 红队与渗透测试工程师
- 安全研究员
- 攻防演练团队
- 安全服务公司
- 需要自动化资产探索和漏洞验证的平台开发者
- 学习 AI Agent 安全应用的开发者
03
配置要求
- 必须配置 PostgreSQL 数据库，可通过 config.json 或环境变量 ARTEX_PG_DSN 指定连接信息。
- 探索功能需要配置 LLM，可使用 ANTHROPIC_API_KEY 或 OPENAI_API_KEY，也可在 UI 的 LLM 配置页填写。
- 可选 LLM 环境变量包括 ARTEX_LLM_PROVIDER、ARTEX_LLM_MODEL、ARTEX_LLM_BASE_URL、ARTEX_LLM_PROXY。
- 默认 Web/API 端口为 :8787，流量录制代理端口可通过 ./start.sh -proxy :8788 设置。
- 首次部署需要设置管理员密码，系统使用 JWT 鉴权。
- 如通过 HTTPS 反向代理部署，需要对 SSE 长连接关闭缓冲，设置较长 proxy_read_timeout，并使用 HTTP/1.1。
- 如需同步 ScopeSentry，需要在资产同步页配置 ScopeSentry 地址和 API Key。
- 如运行真实渗透测试工具，需要容器或宿主机具备 nmap、curl、ripgrep 等常用工具；Docker 镜像中据称已包含部分常用工具，但 README 提到 Docker 部署源可能失效。
04
适用场景
- 对授权范围内目标进行自动化渗透测试探索
- 从 ScopeSentry 同步资产并进行进一步安全验证
- 通过多 Agent 自动拆解目标、生成测试意图并调度执行
- 记录 HTTP/HTTPS 流量并形成可追溯证据
- 对发现的漏洞进行人工或 Agent 辅助复测
- 在任务维度查看探索链路、资产覆盖度和漏洞发现
- 通过审批机制控制高风险工具调用
- 构建企业内部 AI 安全测试平台原型
05
部署与配置
- 准备 Docker、Go、Node.js/npm、PostgreSQL 等基础环境，推荐优先使用脚本或 Docker Compose。
- 克隆仓库：git clone https://github.com/Autumn-27/ARTEX.git && cd ARTEX。注意用户提供的仓库名为 mhtsec/ARTEX，但 README 中安装地址指向 Autumn-27/ARTEX，实际使用前需确认仓库来源和代码一致性。
- 推荐方式：运行 ./install.sh，根据提示选择全部 Docker 部署或本地编译运行。
- Docker Compose 手动方式：cp .env.example .env，填写 POSTGRES_PASSWORD 以及可选的 ANTHROPIC_API_KEY 或 OPENAI_API_KEY，然后执行 docker compose up -d。
- 源码编译方式：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 启动。
- 启动后访问 http://localhost:8787，首次进入 /setup 设置管理员密码。
- 开发模式可运行 ./dev.sh，后端默认 :8787，流量代理默认 :8788，前端开发服务默认 http://localhost:5173。
06
风险与注意事项
- AGPL-3.0 许可证具有强 copyleft 要求，企业二次开发、SaaS 化或闭源集成前需进行合规评估。
- 项目描述和 README 均涉及自主渗透测试，必须仅用于授权目标，否则存在法律和合规风险。
- README 明确提示该仓库为最后版本纯源码备份，Docker 部署源失效需自行本地构建，维护连续性存在不确定性。
- 仓库信息显示 forks 数远高于 stars，且 README 中仓库地址与用户给定 full_name 不一致，建议核验项目来源、镜像、Release 和代码可信度。
- 依赖 LLM，测试质量、成本、稳定性和误报漏报会受模型能力、提示词、上下文长度、API 限流影响。
- 自主 Agent 调用工具具有破坏性风险，需要严格配置 scope、审批和隔离环境。
- MITM 流量代理和 CA 证书能力如果管理不当，可能带来内部安全风险。
- 部署暴露到公网时需重点保护管理员账号、JWT 密钥、LLM Key、数据库凭据和审批接口。
- 源码构建涉及 Go、Node.js、Next.js、PostgreSQL、Docker 等多组件，对普通用户有一定门槛。
- 自动化渗透结果不能替代人工安全审计，关键结论仍需人工复核。
2026-10-09
第19名
新收录 · github_search
