ARTEX：把 AI Agent 变成「自主渗透测试员」，Go 单体 + 双图架构是怎么让 LLM 自己走完一条攻击链的

在 GitHub 上，一个刚冒头没几天的项目又冲上了趋势榜：ARTEX——一套号称「AI 自主渗透测试系统」的开源项目，定位是「百度 agent+ 攻防挑战赛冠军项目」。截至发稿，它已经拿到 735 Star、1900+ Fork，用 Go 后端 + Next.js 前端写成，采用 AGPL-3.0 协议，仓库地址在 github.com/mhtsec/ARTEX。

它的看点不在「又一个 AI 扫描器」，而在于它认真回答了那个最难的工程问题：当 LLM 每一步都是无状态的一次会话时，怎么让它自主、稳定、不重复地走完一条有前后依赖的多步攻击链？ ARTEX 给出的答案是一套「双图架构 + 过程级信息交换 + 共享 todolist」的组合拳，值得一看。

ARTEX 是什么：Go 单体 + 内嵌 Next.js 的渗透 Agent 系统

按照官方 README 的描述，ARTEX 是一套 LLM 多 Agent 驱动的自主渗透系统：后端是 Go 单体服务，前端用 Next.js 静态导出后通过 go:embed 内嵌进同一个二进制，数据落在 PostgreSQL。也就是说，最终你拿到的是一个「单文件」的应用服务器，启动后打开 http://localhost:8787 就能用。

它依赖数据库 PostgreSQL，探索任务需要配置 LLM（ANTHROPIC_API_KEY 或 OPENAI_API_KEY，也可以直接在 UI 的「LLM 配置」页填）。官方提供了五种安装方式：一键安装脚本、Docker Compose、预编译二进制、源码编译单二进制、以及跨平台 Release 打包。最省事的是一键脚本：

git clone https://github.com/Autumn-27/ARTEX.git
cd ARTEX
./install.sh

脚本会自动检测/安装 Docker，然后让你选「全部 Docker」或「本地编译运行」两种路子。装好后浏览器打开 http://localhost:8787，首次进入 /setup 设置管理员密码即可。需要留意的是，仓库里也明确标注了：当前这份是「最后一版纯源码备份」，官方镜像的 docker 部署源已失效，必要时可让 AI 自行本地构建。

核心设计一：双图架构，把「目标」和「进度」拆开

ARTEX 最核心的设计，是把「目标是什么」和「测到了什么程度」拆成两张相互独立、又通过「锚点」相连的图。

• 资产图（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) 把意图/事实/漏洞锚定到具体资产上——于是既能从「探索方向」看它打的是哪些资产，也能从「某个资产」反查它在本次任务里被哪些意图测过、得出过哪些事实。这也正是「资产测试覆盖度」和「资产覆盖图」（范围内资产 + 已测高亮）的数据基础。

用作者的话说，分工是这样的：planner 读探索图态势、判目标，只有在发现「未覆盖的新方向」时才往 frontier 里派意图；worker 领一条意图、用真实工具执行、把新资产/事实/漏洞写回两张图后立刻停下。资产图是共享事实，探索图是每任务的推进链。

核心设计二：worker 之间的「过程级」信息交换

一次深入的探索里，很多有价值的观察——某个报错、某段响应、某个隐藏参数——出现在一个 worker 的执行过程中，却未必被写成正式 fact。如果后来的 worker 看不到，就会重复劳动。

ARTEX 的解法是给 worker 配一套「跨 work 检索过程」的工具：

search_all_worker_traces(q)        // 在本任务其他 work 的执行过程里按关键字检索，自动排除自己
list_worker_traces                 // 先看有哪些 work 跑过
get_worker_trace(intent_id, step_ids=[…])  // 再取某个 work 具体几步的完整内容做细节交换

这样一来，即便探索图上还没有对应的 fact，后续 worker 也能复用他人过程中的观察——信息在 worker 之间以「执行过程」为粒度流动，同时边界依旧清晰：每个 worker 仍然只做自己领到的那条意图。这个设计挺巧的，本质上是把「隐性的过程知识」也做成了可检索的一等公民。

核心设计三：planner 的共享 todolist，让攻击链不重复、不错序

真实攻击链往往是有前后依赖的多步序列——比如「发现注入点 → 拿到凭据 → 横向移动 → 提权」。如果一次性把这些步骤并行派下去，只会乱套。

但 ARTEX 的 engine 是事件驱动的：图一变就唤醒 planner，而 planner 每次唤醒都是全新会话——它是无状态的。为了让串行链路稳定推进，planner 持有一份按任务保留、跨唤醒共享的规划待办（todolist）：

• 每次唤醒是全新会话，但共享的 todolist 让它把一条串行利用链只记录一次；
• 之后每一轮，只对「前置步骤已完成、其依赖的 fact 已存在」的下一步派意图，并随进展更新清单（把已被 fact 满足的步骤标完成）。

于是攻击链在「事件驱动 + 无状态会话」的环境下依然能稳定推进、不重复、不错序。这正是 ARTEX 能自主走完多步利用链的关键所在。

一次探索的闭环：从图变更到意图生命周期

把上面几块拼起来，一次探索的闭环是这样的：图变更（debounce）→ 唤醒 planner → planner 派 0..N 个意图进 frontier → worker 领一条意图 → 取意图关联的原始资产作为初始信息 → 用真实工具执行（Kali / Bash / HTTP）→ 全程留痕 + CA 验证 → 写回 fact / asset / finding 与每步 activity → 图再次变更 → 唤醒 planner……

直到目标被证明（prove_goal）为止。值得注意的是，README 里特别提到：大多数唤醒其实派 0 个意图——没有新方向就结束。这种「不硬凑动作」的设计，是避免 Agent 空转狂烧 token 的关键。

关键能力一览

能力	说明
双图架构	资产图（全局共享真值库）+ 探索图（每任务血缘链），靠锚点相连
过程级信息交换	worker 可跨 work 检索彼此的执行过程，复用隐性观察
共享 todolist	planner 跨唤醒记忆串行链路，按依赖逐步派意图
流量记录代理	MITM + CA 留痕，worker 的 Bash/HTTP 全程可回溯
审批门（guard/intercept）	工具调用需人工审批，支持「人在环路」对话
漏洞复测	独立复测 Agent，结论分「仍可复现 / 已修复 / 无法确认」，自动同步状态
资产同步	支持从 ScopeSentry 直接导入域名/子域/IP/端口/站点/端点资产
MCP / Skills / Memory	agent 能力由 norma SDK 提供，支持 MCP、技能与记忆

其中「漏洞复测」是个很实用的功能：你可以在任务详情页手动发起复测，系统会创建一个独立的复测 Agent 会话，结论分为「仍可复现」「已修复」「无法确认」；当复测成功且结论为「已修复」时，系统会自动把漏洞处置状态改为「已修复」，原始证据和报告始终保留。演示模式下只生成明确标注的模拟记录，不请求真实目标。

架构分层与技术栈

从 README 给出的架构图看，ARTEX 的分层划分得相当清楚：

层	职责
前端	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/技能/记忆/报告

技术栈上，后端是 Go（内嵌前端、单二进制），前端 Next.js，数据库 PostgreSQL，Agent 能力来自 norma SDK（agentcore / tool / permission / harness / memory / transcript）。项目还参考了 oritera/Cairn。整个项目体积不小，代码树有近 700 个文件。

部署与反代：一个容易踩的 SSE 坑

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

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

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 "";
}

升级体验也做得比较讲究：支持「页面一键更新」——下载发布包 → 比对 SHA256SUMS → 用 -h 冒烟测试新二进制 → 暂存为 artex.new → 程序退出由 start.sh 换装重启。失败不会留下坏程序，新版连续 3 次启动失败会自动回滚到 artex.old。数据库迁移无需手动执行：程序每次启动会幂等重跑 schema.sql，即「重启即迁移」。

值得一看，但请务必合规使用

ARTEX 值得关注的地方，在于它把「多 Agent 自主编排」这个当下最热的命题，落到了一个工程约束极强的场景里——攻击链有依赖、Agent 无状态、还得控制成本。双图架构、过程级信息交换、共享 todolist 这三招，其实对任何「让 LLM 长期自主推进复杂任务」的系统都有借鉴意义，不只是安全领域。

不过必须强调：项目采用 AGPL-3.0，并在 README 里明确声明——仅供个人学习、代码研究与本地技术验证，严禁对任何线上系统或网站发起实际测试，严禁用于任何实际渗透、攻防对抗或生产环境。使用者须自行遵守所在国家/地区的网络安全、数据保护与计算机犯罪相关法律法规。请务必在合规的隔离环境中使用。

项目地址：github.com/mhtsec/ARTEX，在线 Demo：artex-demo.vercel.app，官方交流公众号：SecSentry。