冠军 AI 渗透工具 ARTEX 架构拆解

冠军 AI 渗透工具ARTEX架构拆解

它在百度「Agent+」攻防赛拿了第一，一个月后出现在韩国金融机构的入侵案里，随后作者宣布闭源。这篇不聊立场，只拆它到底是怎么搭起来的。

百度「Agent+」攻防挑战赛冠军项目

ARTEX 把自己定义为「AI 自主渗透测试系统」，Go 后端 + Next.js 前端，作者是 GitHub 上的 Autumn-27（公众号「知白守黑1024」），采用 AGPL-3.0 协议开源。它参加百度 BSRC 的「Agent+」攻防能力挑战赛，拿到了第一名——这一点后来成了它所有镜像仓库标题栏上的第一句话。

时间线值得完整摆出来，因为它同时说明了这类工具的能力和风险：

一个容易被忽略的事实：agent 不是「自主」的

这轮报道里最需要澄清的一点是：整个过程仍然有人在驾驶。CrowdStrike 的描述是人主导操作、ARTEX 承担自动化执行；多家调查也指出攻击来源 IP 横跨十余个国家、伴有大量代理跳板。也就是说，它降低的是「执行成本」，而不是「意图门槛」——想干这件事的人，仍然是那个想干这件事的人。

现在还能找到的，是「最后一份源码备份」

需要说明仓库现状，避免读者找错地方：

本文分析基于odin1024/ARTEX的公开源码备份，并结合 CrowdStrike 与韩方调查的公开结论。数据来自仓库文件与公开报道，不臆测。

先说技术栈，因为它决定了很多后续设计。ARTEX 用的是单体后端 + 内嵌前端的路子：Go 写的net/http服务和 REST API，前端是 Next.js 静态导出后通过go:embed编进同一个二进制。数据库是 PostgreSQL（驱动用 pgx），schema 以go:embed方式随程序每次启动幂等执行——官方叫「重启即迁移」，不需要手动跑 migration。

agent 的底层能力不是自己造轮子，而是来自作者另一套 SDKnorma：涵盖agentcore（运行时）、tool（工具装配）、permission（权限门）、harness（编排外壳）、memory、transcript。这一点很关键：ARTEX 更像是把这套 SDK「产品化」之后的样子。

那个 48% 是最容易被忽略、也最能说明工程态度的数字。一个「聪明但脆」的 agent 项目，通常测试很少；而 ARTEX 的更新日志里反复出现「先复现、再修、再补回归测试」的表述——这说明作者是按生产系统的标准在做它。

界面上一眼能看出它的定位：不是扫描器，而是一个红队作战控制台。左侧导航分「功能」和「系统」两栏，功能里有仪表盘、对话、任务、发现、流量、资产、资产同步；系统里有 LLM、Agent、MCP、Skill、工具、拦截规则、审批记录、日志、系统配置。

图1 ｜ 仪表盘：活跃任务、确认发现、资产节点、流量交互、Token 用量五个指标卡，下面是 LLM Token 消耗趋势与实时活动流，右侧直接列出最近的发现（含严重度）。

注意上图右侧的「发现」列表——它把漏洞按严重度着色直接推到首页，这是「以结果为中心」而不是「以扫描进度为中心」的信息设计。

默认端口是8787（前端 + API + SSE 同源），流量录制代理单独占8788。首次访问走/setup设置管理员密码，鉴权用 JWT。

这是 ARTEX 整个设计里最值得学的一处。它没有把资产信息和探索进度塞进一张图里，而是拆成了两张：

•资产图（Asset Graph）：全局共享，跨任务是同一份「资产真值库」。节点是root_domain / subdomain / ip / service / app / endpoint，按公司归属。

•探索图（Exploration Graph）：每个任务独立。节点是goal（目标）/ intent（意图）/ fact（事实）/ finding（漏洞）/ hint（提示），靠spawns / derived_from / yields / proves这些边连成血缘链。

图2 ｜ 双图架构：上方探索图记录「谁派生了谁、产出了什么、证明了什么」；下方资产图是全局共享、去重后的资产树；中间靠锚点表相连。

为什么非要拆开？因为这两类数据的「所有权的粒度」根本不同。资产是客观存在、跨任务复用的事实——同一台服务器在十个任务里就是同一个节点，重复收录会让「覆盖率」彻底算不清。而探索路径是主观的、一次性的思考过程——A 任务里那条「为什么想到去试这个参数」的推理，对 B 任务没有复用价值。

拆开之后，用一张只有两列的锚点表把两者缝上：

exploration_anchors(node_id, asset_id)—— 把意图、事实、漏洞锚定到具体资产上。于是两种查询都成立：从「探索方向」看它打的是哪些资产；从「某个资产」反查它在本任务里被哪些意图测过、得出过哪些事实。

正是这张锚点表，支撑起了「资产测试覆盖度」，还有那张很好看的资产覆盖图：范围内资产全部铺开（力导向布局），已测的高亮、未测的灰显，节点可折叠展开。

图3 ｜ 资产覆盖图：公司 → IP → 域名 → 子域 → 端点逐层展开，已测节点高亮、未测置灰。一眼就能看出「哪些资产还没被碰过」。

还有一处工程细节做得比大多数同类项目干净：agent 只提交原始信息，父子关系和去重 key 全部由程序计算。也就是说，让 LLM 负责「我看到这个主机开放了 443」，而不让它负责「这个主机在资产树里应该挂在哪」。把容易出错、需要确定性的活儿从模型手里拿走，这是很清醒的分工。

图4 ｜ 探索链路图：起点、目标、意图、事实、漏洞、提示六类节点，用「派生 / 意图链 / 产出 / 证明」四种边连起来。点开任一节点能看到它引用了哪些事实、产出了什么结论。

双图是「数据结构」，调度是「行为」。ARTEX 的引擎是一个事件驱动的闭环：图一变就唤醒 planner，planner 派意图，worker 领意图执行并写回，写回又触发下一轮——直到目标被证明（prove_goal）。

角色分工只有两条，但边界划得很死：

•planner 是唯一的意图生成者。它读探索图态势（一次预取graph_overview，加上 coverage / scope），判断还有没有未覆盖的新方向，然后派 0..N 条意图进 frontier。

•worker 只领一条意图。用真实工具执行，把新资产 / 事实 / 漏洞写回两张图，然后即停。默认 3 个 worker 并发，数量可在系统设置里改。

图5 ｜ 引擎闭环与两条自主性机制：上面是事件驱动的六步循环，下面左是 worker 间的过程级信息交换，右是 planner 跨唤醒共享的 todolist。

这里有个反直觉但很重要的细节：大多数唤醒派 0 个意图。图变了不等于有新方向——没有新方向，planner 就什么都不派，这一轮就结束了。这个「允许什么都不做」的设计，是自主 agent 能不能收敛、而不是无限空转的关键。

难点一：无状态会话，怎么保持长链稳定？

planner 是事件驱动的，图一变就被唤醒，但每次唤醒都是一次全新的会话——它不记得上一轮想过什么。真实攻击链却往往是有前后依赖的多步序列（发现注入点 → 拿到凭据 → 横向 → 提权），一次性把这些并行派下去，只会乱套。

ARTEX 的解法是给 planner 一份按任务保留、跨唤醒共享的规划待办（todolist）：把一条串行利用链记录一次，之后每轮只派「前置步骤已完成、其依赖的 fact 已存在」的那一步，并随着进展把已被 fact 满足的步骤标完成。于是这条链在「事件驱动 + 无状态会话」的环境下依然能稳定推进、不重复、不错序。

难点二：执行过程里的观察，怎么不浪费？

一次深入的探索里，很多有价值的观察（某个报错、某段响应、某个隐藏参数）出现在某个 worker 的执行过程中，却未必被总结成一条正式 fact。如果只有「事实」能在 agent 之间传递，这些中间观察就随会话一起消失了，后面的 worker 只能重复踩一遍。

ARTEX 让 worker 具备跨 work 检索过程的能力：

•search_all_worker_traces(q)：在本任务其他 work 的执行过程里按关键字检索（自动排除自己这条意图的步骤），命中项带intent_id，可回溯；

•list_worker_traces/get_worker_trace(intent_id, step_ids=[…])：先看有哪些 work 跑过，再取某个 work 具体几步的完整内容做细节交换。

于是信息在 worker 之间以「执行过程」为粒度流动，而边界不变——每个 worker 仍然只做自己领到的那条意图。这一点很值得抄：给 agent 加信息通道的时候，别顺手把职责边界也一起放宽了。

落到界面上，这套机制表现得相当直观：一个任务下会同时存在主 Agent（编排会话）、规划 Planner（态势研判）和若干 Workers，每个 worker 是一条意图，运行状态实时刷新。

图6 ｜ 任务执行过程：左侧是会话列表（主 Agent / 规划 Planner / Workers #1–#5 各自的意图），右侧是会话内的完整工具输入输出。顶部给出该任务的 Token 输入 / 缓存 / 输出与耗时。

一个能自主执行 Bash 和 HTTP 请求的 agent，如果不加约束，最大的风险不是「打不穿」，而是「打过头」——误删、外发数据、对非授权目标动手。ARTEX 在这上面做了四层防护，这部分的工程量其实比调度还大。

第一层：拦截规则与审批门

工具执行前会先过一遍规则表，按优先级（数字越大越优先）逐条匹配，命中第一条即生效。每条规则有目标、类型（正则 / 字符串）、模式、策略（申请/禁止）和启停开关。

图7 ｜ 拦截规则：内置「破坏性命令需审批」（匹配 rm -rf、mkfs、dd 等）与「外发流量直接拒绝」，前者走人工审批，后者直接拦截。

值得留意 v0.3.15 新增的一条规则：「删除类接口路径」。这背后的观察很扎实——此前内置的 HTTP 破坏性规则只认 DELETE方法，但现实里大量应用的删除接口用 GET / POST 就能触发，curl 'http://t/api/user/delete?id=1'这类调用会真实删掉目标数据。新规则覆盖/delete /del /remove /unlink /erase /destroy，并且要求动词后必须跟分隔符，所以/delivery、/details、/delta不会误拦。这种「知道模型会在哪里犯错」的规则设计，比堆一百条泛规则有用。

第二层：全链路流量留痕

所有工具执行的网络行为都经过一个记录型 MITM 代理（自签 CA 留痕），Bash 和 HTTP 请求全程落库，可检索、可筛选、可回放。

图8 ｜ 流量录制：请求 / 响应成对入库，支持按响应内容、路径、状态码、长度范围筛选，表头可按时间与长度排序。

第三层：证据哈希与版本

这是我认为全部设计里最「较真」的一处。漏洞报告要引用流量作为证据，而流量是可以被清理的——如果只是存个 ID，原流量一删，报告就成了空口无凭。

ARTEX 的做法是把证据快照化：traffic_evidence_snapshots保存原流量 ID、采集时间、URL、方法、状态、请求 / 响应头、正文长度和SHA-256；正文按哈希存放在<data>/evidence/blobs/<前两位>/<hash>.bin，与可清理的data/traffic目录完全独立，多个漏洞可以共享同一份快照。校验不一致时，读取和导出直接失败——不会给你一份「看起来对」的报告。

同时引入证据版本：报告里记录它实际读取的evidence_version，如果生成期间证据发生变化，旧版本写入会被拒绝，必须重新读取再生成。这条规则堵住的是「报告说 A、证据已经变成 B」这种最难查的错位。

第四层：漏洞复测的状态机

漏洞被报告后，处置状态不是靠人手动改的（虽然也支持手动）。系统预置了一个可编辑的「漏洞复测」agent（retester），结论分三态：仍可复现 / 已修复 / 无法确认。只有当复测会话成功完成、且结论为「已修复」时，系统才自动把漏洞处置状态改为「已修复」；执行中、失败、停止或其他结论都保留原状态——原始证据和报告始终保留。这种「默认不乐观」的状态机设计，方向是对的。

再补一个界面侧的细节。漏洞汇总页不只是把结果列出来，而是按严重度分档统计，并把「所属任务」作为一列——多任务并行时，判断「这批洞是哪个任务打出来的」非常重要。

图9 ｜ 发现汇总：总数 / 高危 / 中危 / 低危 / 涉及任务五个统计卡，下方按严重度、漏洞类型、摘要、所属任务、时间列出明细。

别忘了「人在环路」

自主不等于放手。任务里有一个主 Agent 会话，人可以随时发消息引导探索方向，也可以暂停任务、在审批卡片上点击放行或拒绝。

图10 ｜ 人在环路对话：在任务上下文中直接与主 Agent 交流，引导探索方向或追问某个结论的依据。

此外它还有一套 skill 机制把侦察经验固化下来。仓库里自带三个：api-recon（前端接口侦察——静态解析 JS bundle + 运行时 hook / mock 撑开 SPA 路由，把后端 API 面尽可能枚举出来）、playwright-cli（浏览器操作）、scopesentry（资产同步）。其中api-recon的 SKILL.md 写得极其克制：明确划定「只录 outbound 请求、不做漏洞测试」「禁止猜测或索要账号密码、只用 mock 绕过客户端登录门」，把「侦察」和「利用」两个阶段用文档硬隔开。这种自我设限，在同类项目里不多见。

前置条件只有两样：PostgreSQL，以及一个 LLM 的凭据（ANTHROPIC_API_KEY或OPENAI_API_KEY，也可以留空，装好后在 UI 的「LLM 配置」页里填）。官方给了五条安装路径，实际常用的有三条。

路径一：一键安装脚本（推荐）

脚本会先检测 / 自动安装 Docker，然后让你选「全部 Docker」还是「本地编译运行」。选 Docker 时填一个 Postgres 密码（回车可随机），它会自动写.env并拉起 compose；选本地运行时，它生成config.json、编译内嵌单二进制并启动。

路径二：Docker Compose 手动部署

想自己控制细节就走这条。镜像里已经装了常用工具（ripgrep / curl / nmap / npm 等），./skills与./data以绑定挂载持久化。

.env里相关的键如下。除了数据库密码，其余都可以后续在界面上补。

路径三：从源码编译单二进制

想改前端或自己打包发行版，走这条。注意-tags embedui才会把前端嵌进去，不加的话后端不带界面。

两个部署坑，提前说

•反向代理必须关掉 SSE 缓冲。实时活动流走 Server-Sent Events，如果 Nginx 没关proxy_buffering，浏览器能连上却收不到事件——表现是活动流一直转圈。同时要把proxy_http_version设为 1.1、超时拉长。

•数据库迁移不用管。artex 每次启动会幂等重跑 schema（ADD COLUMN/CREATE INDEX IF NOT EXISTS），「重启即迁移」。升级只换程序、不动数据，但升级前仍建议备份./data与数据库。

顺带一提它的更新回滚做得挺完整：校验或冒烟不通过就丢弃暂存件、继续跑当前版本；换装后的新版若连续 3 次启动失败，自动回滚到artex.old，失败的那个留作artex.failed供排查。开发构建（版本号为dev）不给更新，避免正式版覆盖掉本地调试的二进制。

作者的声明说得很清楚：鉴于工具被滥用，ARTEX 不再更新、转为闭源。这件事本身没有太多争论空间——但作为一个工程案例，它给出了三条相当硬的教训。

教训一：能力与边界是两件事，而开源只交付能力

ARTEX 的 README 里有大段免责声明，明确写了「严禁使用本工具对任何网站、线上服务或联网系统发起扫描、探测、利用或攻击」「无论是否获得授权、是否为自有资产」。写得很到位，但文档不构成技术约束。代码一旦公开，作者就无法决定它被谁、用在什么目标上。这不是 ARTEX 独有的问题，是所有「双用途」安全工具的固有属性。

教训二：护栏要在设计期做，不能只写在文档里

对比来看，ARTEX 其实做了不少技术性限制：拦截规则可以直接拒绝外发流量、破坏性命令强制走人工审批、复测状态机默认不乐观、api-reconskill 明确把自己限制在「侦察」而不进入「利用」。这些约束在正常使用路径上是有效的。

但问题在于：一个已经打定主意要打别人的人，可以直接改代码。AGPL-3.0 允许修改和分发，禁用一条规则、删掉审批门，成本几乎为零。这也解释了为什么作者最终选择了闭源——当「技术护栏」对恶意使用者无效时，能减少的只剩「获取成本」。

教训三：agent 真正改变的是成本曲线

这次事件里最需要被产业记住的一点：攻击者并不需要很熟练。CrowdStrike 的描述是人主导 + agent 自动化执行，也就是说，一个能规划、能执行、能写回、能自我推进的 agent，把过去需要一名熟练渗透测试人员才能完成的多步操作，压缩成了「给出目标」这个动作。

把这件事放到防守视角，结论很直接：攻击的频率会上升。当一次完整的渗透尝试从「几周」变成「几小时」，一年做一次的安全评估，覆盖的只是那一年里的一瞬间。

工具没有立场，用的人有

ARTEX 这个名字，最后留在了韩国的调查卷宗里，也留在了它自己的源码里——这两件事同时成立，而且不矛盾。

对做安全的人：它的双图数据模型、事件驱动的 planner/worker 闭环、跨唤醒共享的 todolist、过程级信息交换、证据哈希与版本，这几处设计值得逐个抄进自己的项目。尤其是那张把「客观资产」和「主观探索」拆开的表结构，解决的是自主 agent 里最普遍的一类混乱。

对做 agent 产品的人：它的护栏层次（规则拦截 → 人工审批 → 流量留痕 → 证据校验 → 默认不乐观的状态机）比它的调度算法更值得学。因为让 agent 动起来很容易，让它在该停的时候停才是难点。

对写工具的人：这件事没有标准答案。你能做的是把边界写清楚、把护栏做实、把日志留全，然后接受一个事实——你无法控制谁捡起你放进世界里的东西。

最后补一句：本文分析的所有代码都来自公开仓库，所有事件结论均引自 CrowdStrike 与韩方调查的公开信息。任何试图把这类工具用在自己没有书面授权的目标上的人，后果自担——这句话不是免责声明，是提醒。

数据来源：ARTEX 公开仓库源码与文档（README / CHANGELOG / docs / skills）、CrowdStrike Intelligence 分析报告、The Hacker News 报道、韩国金融安全院调查结论、GitHub 仓库页公开计数。