ARTEX 二次开发版解析：从外网突破到内网纵深的自主渗透平台

原创

Red Hunter
Red Hunter

黑白之道

2026年10月21日 09:07
韩国

去阅读

导语：市面上的 AI 渗透工具大多停在单点——帮你跑扫描、帮你写 payload、再帮你整理报告。真要拿它打一条完整链路，就发现每一步都得人来接。ARTEX 换了个思路：把外网突破到内网纵深的整段过程交给多智能体自己往前推，靠双图架构记住\"打到了什么\"和\"想到了什么\"，让攻击链不重复、不乱序。

⚠️ 版本说明：本文解析的是 enwjx/ARTEX —— 社区二次开发版（fork），不是官方原版仓库。原版是 mssky9527/ARTEX（README 署名 Autumn-27），二次开发版在其基础上另开分支。两者架构相同，但版本进度已经拉开差距，具体差别见下文第二节。

一、背景：AI 渗透测试卡在哪

先说清楚问题在哪。

早期的自动化渗透工具解决的是\"重复劳动\"：端口扫描、目录爆破、SQL 注入尝试。这些活儿规则清晰、结果确定，交给脚本很合适。但真实的攻击链不是这样的——发现注入点、拿到凭据、横向进内网、提权，每一步都依赖上一步的产出，而且中间随时可能冒出新线索。

大模型出来之后，很多工具开始让 AI 来做决策。方向对了，但两个问题一直没解决。

第一个是记忆。上下文窗口就那么大，探索了几十上百步之后，早期发现的资产、验证过的假设、失败过的路径，要么被挤出上下文，要么被压缩成一句模糊的总结。智能体开始重复劳动，甚至推翻自己刚建立的结论。

第二个是节奏。真正有价值的利用链是有先后依赖的。如果把所有可能的方向一次性并行铺开，智能体会乱套——它可能在还没拿到凭据的时候就去跑提权，也可能在两个 worker 之间反复试探同一条路。

ARTEX 针对的就是这两个问题。

二、ARTEX 是什么

ARTEX 是一套 AI 自主渗透测试系统，技术栈是 Go 单体后端（前端用 go:embed 内嵌进同一个二进制）加 PostgreSQL，前端是 Next.js，agent 能力由 norma SDK 提供。装好之后监听 8787 端口，前端和 API 都在这一个口上；8788 是流量录制代理。

先说清楚版本关系，这是本文最容易被误会的地方。

二次开发版的代码是从原版 fork 出来另做修改的，架构主体一致，但版本进度已经拉开：上游后来新增的 evidence 证据链、notify 通知、sidequestion 追问、llmpool 多模型池，还有 LICENSE、CHANGELOG 这些文件，二开版本里都没有。它停留在 8 月中旬的快照。

所以想追新功能、想看完整能力清单，直接去上游原版；要研究二次开发版改了什么，就对着 fork 看。

四个 agent 角色分工很清晰：

• goals 负责目标分解，把一句模糊的需求拆成可执行的范围
• planner 是唯一的意图生成者，读全局态势，判断还有哪些方向没覆盖
• worker 是干活的，领一条意图、用真实工具执行、把结果写回，然后停下
• mainagent 负责人在环路，随时可以对话干预

三、双图架构：整个系统的地基

ARTEX 最核心的设计是把\"目标是什么\"和\"测到了什么程度\"拆成两张互不相干的图，再用锚点连起来。

资产图是全局共享的资产真值库，跨任务共用一份。节点包括根域名、子域名、IP、服务、应用、端点，父子关系和去重逻辑全部由程序算，智能体只负责提交原始信息。

探索图是每个任务独立的一份，记录这次任务的思考和推进过程。节点分五种：目标（goal）、意图（intent）、事实（fact）、漏洞（finding）、提示（hint），靠 spawns、derived\_from、yields、proves 这些边连成血缘链——谁派生自谁、产出了什么，一目了然。

两图通过 exploration_anchors 表相连，把意图、事实、漏洞锚定到具体资产上。这一下就带来了两种视角：你可以从一个探索方向看它打了哪些资产，也可以反过来从某个资产查它在本次任务里被哪些意图测过、得出过什么结论。资产测试覆盖度和覆盖图就是靠这个撑起来的。

引擎本身是个事件驱动的闭环：图一变就唤醒 planner，planner 派意图进队列，worker 领一条执行完写回两图，写回又触发下一轮，直到目标被证明完成。多数唤醒时 planner 会派 0 条意图——没有新方向了就结束，不硬凑。

四、两条机制撑起长链路

worker 之间的过程级信息交换。

一次深入的探索里，很多有价值的观察出现在某个 worker 的执行过程中，未必被写成正式事实。为避免重复劳动，worker 具备跨 work 检索过程的能力：search_all_worker_traces(q) 在本任务其他 work 的执行过程里按关键字搜，命中项带着 intent\_id；再配合 get_worker_trace 取具体几步的完整内容。

说白了，信息在 worker 之间是以\"执行过程\"为粒度流动的，但边界不变——每个 worker 仍然只做自己领到的那条意图。

planner 的共享待办清单。

这条更关键。planner 是事件驱动的，每次唤醒都是全新会话，但它持有一份按任务保留、跨唤醒共享的 todolist。一条串行利用链只记录一次，然后后续多轮里按依赖逐步派意图，而不是一轮里全铺开。每轮只对\"前置步骤已完成、依赖的 fact 已存在\"的下一步派意图。

这就是 ARTEX 能自主走完多步利用链的关键——在事件驱动加无状态会话的环境下，攻击链依然稳定推进。

五、安装与护栏

依赖只有两个：PostgreSQL 和 LLM key（ANTHROPIC_API_KEY 或 OPENAI_API_KEY，也能在 UI 里配）。安装有四种方式，最省事的是一键脚本。注意下面 clone 的地址是二次开发版仓库，要用原版请把地址换成 mssky9527/ARTEX：

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

脚本会检测 Docker，让你在\"全 Docker\"和\"本地编译\"之间选。之后访问 http://localhost:8787，首次进 /setup 设管理员密码。每个任务的 worker 并发数在系统设置里配，默认 3 个。

还可以直接从 ScopeSentry 同步资产数据，省掉重复收集。

安全护栏这块做得比较到位：流量录制代理会对 worker 的 Bash 和 HTTP 请求全程留痕并做 CA 验证；guard/intercept 是工具审批门，敏感操作要过人工确认。

顺带提醒一句：项目仓库里写得很清楚，仅供授权测试与研究使用。有授权再上手，没授权那就是另一回事了。

素材出处

本文为原创技术整理，解析对象为 ARTEX 社区二次开发版，非官方原版，资料来源如下：

• 二次开发版仓库（本文对象）：https://github.com/enwjx/ARTEX
• 原版仓库（上游主线）：https://github.com/mssky9527/ARTEX
• 官方在线 Demo：https://artex-demo.vercel.app/
• agent SDK norma：https://github.com/Autumn-27/norma
• 资产同步 ScopeSentry：https://github.com/Autumn-27/ScopeSentry
• 参考项目 Cairn：https://github.com/oritera/Cairn
• 界面截图取自项目仓库 screenshots 目录，版权归原作者所有

👇 点击阅读原文，访问我的网站

---