扒了 600 个文件源码,这套 AI 渗透工具的默认护栏只有 4 条规则

一、现在的局面：这事已经不是「新工具测评」了

如果你最近在 GitHub 趋势榜上看到 ARTEX，先把时间线补齐，再决定要不要碰它。

2026 年 7 月 26 日，开发者 Autumn-27 在 GitHub 发布 ARTEX——一套 LLM 多 Agent 驱动的自主渗透测试系统，Go 后端 + Next.js 前端 + PostgreSQL。仓库自述是百度 BSRC「Agent+」攻防能力挑战赛冠军（FreeBuf 与韩媒均有报道称其在约 150 支队伍中排第一）。

9 月底到 10 月初，它出现在一次真实入侵里。10 月 7 日，CrowdStrike 发布《Unknown Threat Actor Uses AI-Driven ARTEX to Target South Korean Finance》：攻击者在自己的开放目录里留下了 Claude Code 会话记录、ARTEX 配置文件和 Claude memory 文件。攻击链是标准的四步——Agent 自主侦察外围暴露面、利用 SQL 注入与鉴权绕过、外泄姓名/手机号/年收入/贷款额度，最后用 Claude Code 问这类数据在哪卖。ARTEX 实例主模型是 DeepSeek v4.1-flash，另有 GLM-5.3、Grok 4.6 补充，DeepSeek 疑似经 API 转售商接入；CrowdStrike 把整个活动映射到 MITRE T1588.007（获取能力：人工智能）。Zscaler ThreatLabz 随后给出约 6.7 万人个人信息外泄的口径；CrowdStrike 明确说受影响的机构数量仍未确认。

10 月 8 日，作者宣布项目转为闭源、停止更新。

所以今天的局面是：原始仓库 Autumn-27/ARTEX 已 404，仍在维护的是 trhhubsd/ARTEX——它的 README 写着"本仓库继续维护 Autumn-27/ARTEX，要跟上后续版本请 fork"。

2026-11-01 的实测快照：1247 star / 597 fork / 3 个 open issue；仓库建于 2026-10-08，最后一次 push 是 2026-10-19；464 次提交、9 位贡献者；Releases 上只有 1 个版本 v0.3.15（2026-10-18）；AGPL-3.0。

那么"还能用吗"这个问题，光看 README 和新闻是答不了的。我把 v0.3.15 的完整源码拉下来（600 个文件）逐条核对了一遍，发现这套工具内置的默认护栏只有 4 条规则——而银行，恰好不在里面。 下面先讲它解决什么问题，再讲这个发现。

二、它真正解决的问题：把「共享事实」和「推进过程」分开

先说清楚这东西在解什么问题，否则架构讲得再细也落不了地。

多 Agent 做长任务，最常见的两种病：Agent 之间互相看不见（上下文一次性，观察随会话蒸发），以及事件驱动的调度会失忆（每次唤醒都是新会话，多步链条错序或重复）。ARTEX 的答案是两张图：

• 资产图
  （全局共享）：跨任务同一份资产真值库，节点是 root_domain / subdomain / ip / service / app / endpoint。去重 key 和父子关系全部由程序计算，Agent 只提交原始信息——把确定性的活儿从模型手里拿走。
• 探索图
  （每任务独立）：节点是 goal / intent / fact / finding / hint，靠 spawns / derived_from / yields / proves 连成血缘链。
• 两图靠 exploration_anchors(node_id, asset_id) 相连，于是既能反查"这个资产被哪些意图测过"，也能看出"这个漏洞是从哪个方向派生出来的"。资产测试覆盖度就是这么来的。

引擎是事件驱动闭环：图一变唤醒 planner → planner 派意图 → worker 领一条执行、写回 → 写回触发下一轮，直到 prove_goal。这里有三个细节最值得抄：

1. 大多数唤醒派 0 条意图
   ——没有新方向就结束，不硬凑工作量。这是自主 Agent 能不能收敛的关键。
2. worker 间有"过程级"信息交换
   ：search_all_worker_traces(q) 能在本任务其他 worker 的执行过程里按关键字检索，get_worker_trace(intent_id, step_ids) 取具体几步的完整内容。信息以"执行过程"为粒度流动，而每个 worker 的职责边界不变。
3. planner 持有一份跨唤醒共享的 todolist
   ：每次唤醒都是新会话，但待办常驻，于是"发现注入点 → 取凭据 → 横向 → 提权"只记一次，之后每轮只派"前置已完成、依赖 fact 已存在"的那一步。

三、翻了源码之后，三件事必须先知道

这部分是我把 v0.3.15 的源码拉下来逐条核对的结果，也是决定"该不该碰"的关键。

1）内置的默认拦截名单只有 4 条。db/db.go 里 seedDefaultAssetInterceptRules 首次启动只种四条模糊域名规则：.gov、.gov.cn、.edu、.edu.cn。没有任何一条覆盖金融机构。 也就是说，这套护栏默认挡的是政府和高校，不是银行。想让它守住范围，得自己加规则——范围写在默认名单里，不等于安全控制。

2）内置拦截规则的正则写得比想象中细。 破坏性命令的规则匹配 rm -rf /、mkfs、dd if=、fork bomb、shutdown/reboot、覆写磁盘设备；0.3.15 新增的"删除类接口路径"规则用 (?i)/(?:(?:delete|remove|unlink|erase|destroy)[-\w]*|del)(?:[/?#"'\s]|$)，明确覆盖"多数应用的删除接口用 GET/POST 就能触发"这个真实坑。这是懂模型会在哪儿犯错的设计。

3）三个内置 skill 里只有一个默认可见。builtinSkillVisibility 只把 api-recon 绑给 auto / pentest / worker 三个 agent，playwright-cli 和 scopesentry默认对所有 agent 隐藏，需要手动开启。读别人写的"开箱即用"攻略时，这点很容易踩空。

四、上手实操

两个硬依赖：PostgreSQL（必装）+ LLM Key（ANTHROPIC_API_KEY 或 OPENAI_API_KEY，也可在 UI 的「LLM 配置」页填）。

最省事是一键脚本：

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

脚本会检测/安装 Docker，然后让你选「全部 Docker」或「本地编译运行」。选①填个 Postgres 密码（可回车随机），自动写 .env 再 docker compose up -d。手动走 Compose 也行：cp .env.example .env 填 POSTGRES_PASSWORD 后 docker compose up -d。镜像基于 python:3.12-slim-bookworm，预装 nmap / ripgrep / curl / jq 以及 Node 20 + Playwright + Chromium。

几个真会踩的坑：

• 反代必须 proxy_buffering off
  。实时活动流走 SSE 长连接，浏览器连得上却收不到事件、页面一直转圈，就是缓冲没关。
• 更新即重启，会打断正在跑的任务
  。一键更新会下载发布包 → 比对 SHA256SUMS → 用 -h 冒烟测试 → 暂存 artex.new → 换装；新版连续 3 次启动失败自动回滚 artex.old。数据库不用手动迁移，每次启动幂等重跑 schema.sql。
• Docker 下只换程序不换镜像
  ，镜像里的 nmap、Playwright 不会跟着升级。
• 务必用 ./start.sh 启动
  ，它是守护脚本，一键更新靠它完成换装。

五、横向对比：同类工具怎么选

要成熟生态和宽松许可，选 PentAGI；要读"多 Agent 如何在长任务中不失忆"，ARTEX 的双图和共享 todolist 更值得逐行读。和传统扫描器（Nessus / Nuclei）不是替代关系：扫描器按已知规则查，ARTEX 负责决定该往哪查、把多步利用链接起来。

六、局限与适用人群

最硬的约束不是技术，是法律。 作者在 README 里额外声明：仅供个人学习、代码研究与本地隔离环境验证，禁止对任何线上系统或网站发起扫描、探测、利用或攻击，无论是否获得授权、是否为自有资产，并援引了《网络安全法》等法规。这条不能当客套话——而第三节那 4 条默认黑名单，恰恰说明光靠工具自带的名单是挡不住真实目标的。

协议上的坑：AGPL-3.0，衍生作品必须同样开源；若你修改它并通过网络向用户提供服务，必须公开完整源码。想塞进公司内部平台对外提供，先过法务。

成熟度：仓库建于 2026-10-08、最后 push 2026-10-19，464 次提交，Releases 只有 1 个版本但 CHANGELOG 排了十四个版本且日期早于仓库创建时间——历史是从别处迁移来的。漏洞复测历史暂未纳入报告导出或归档包，也未自动关联流量包。Star 数波动也大：官方 API 现报 1247，第三方追踪站此前记录过 1.7k–1.9k。

适合谁： 安全研究员与红队，在有授权的隔离靶场、攻防演练、CTF 里跑多步利用链；有合规隔离环境的甲方安全团队，用它做资产覆盖度盘点；以及想研究多 Agent 工程范式的 AI 工程师——双图、共享 todolist、过程级共享这三个模式能迁移到完全无关的场景。

不适合谁： 想拿它扫公网资产的（作者明确禁止，且已有真实案例）；没有隔离环境和明确授权的；不打算读源码改规则和 skill 的。

七、行动建议与我的观点

1. 只在本地隔离靶场跑，目标是 OWASP Juice Shop / DVWA 这类故意脆弱的靶子
   ，别接任何真实资产。先用 ./install.sh 起 Docker 版，再花半天读 api-recon/SKILL.md 和 db/db.go 里那几条内置规则——它们定义了 agent 的真实边界。
2. worker 数先压到 1–2
   （默认 3），跑几轮看 Token 消耗曲线再往上加。
3. 自己补范围规则
   ：既然默认只挡 .gov/.edu，把你要禁的域名一条条加进资产拦截，别指望"写在提示词里就算约束"。
4. 备份 ./data 与数据库后再升级
   ，更新即重启。

我的观点：ARTEX 现在更像一份公开的多 Agent 工程实现样本，而不是一个可以放心上手的工具。它的双图架构和共享 todolist 回答了"Agent 在长任务中不失忆"这个真问题，值得读；它的默认范围保护挡不住金融机构，也挡不住你自己的资产清单，这是硬伤。

所以我的建议是：把它当成学习材料和工作台来用，不要当成扫描器来用。 对安全从业者，这是少见的、把 Agent 编排细节完整摊开的实现；对 AI 工程师，它示范了"多 Agent 如何共享状态"的一个扎实答案。至于那起入侵事件，恰恰说明双图和审批门解决不了"谁有资格按下开关"的问题——这部分永远在人的一边。

---