导语：市面上的 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 是流量录制代理。
先说清楚版本关系，这是本文最容易被误会的地方。
| 仓库 |
性质 |
最后提交 |
说明 |
| mssky9527/ARTEX |
原版（README 署名 Autumn-27） |
2026-10-07 |
持续迭代中的上游主线 |
| enwjx/ARTEX |
社区二次开发版（fork） |
2026-08-17 |
本文解析对象 |
二次开发版的代码是从原版 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 里配）。如果你还在为模型 API 的选择和成本发愁，可以看看 RouteFast 这类中转方案，按需切换 Claude、GPT 等模型，不必把 key 绑死在一家。安装有四种方式，最省事的是一键脚本。注意下面 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 社区二次开发版，非官方原版，资料来源如下：
发表于 7 小时前
|
查看: 11|
回复: 0
