强烈建议二开！ARTEX深度拆解：从PostgreSQL“黑板”到Planner-Worker调度优化

前言在AI渗透测试工具层出不穷的今天大多数项目给人的感觉是“在聊天框里接了个能执行命令的Agent”——对话一长模型忘了自己扫到哪了页面一刷新执行状态全丢了想复盘的时候只能翻聊天记录。今天给大伙分享渗透测试智能体开源项目——ARTEX。项目地址GitHub - Autumn-27/ARTEX: AI 自主渗透测试系统 · GitHub在线Demohttp://artex-demo.vercel.app/简述ARTEX是一个把AI Agent、资产图谱、流量录制和任务编排放进同一套工作台的自主渗透测试系统后端用Go前端用Next.js开箱就带Web UI。这篇文章会从技术原理、架构设计、使用体验到二开建议带你完整认识这个项目。快速部署方式git clone https://github.com/Autumn-27/ARTEX.git cd ARTEX ./install.sh脚本会引导你选择两种模式模式适合谁特点全部Docker想快速跑起来自动拉起ARTEX和PostgreSQL本地编译运行想改代码或二开可自定义数据库和构建方式一、解决了什么问题先问一个问题你用过的AI渗透工具是不是都长这样一个聊天窗口你跟AI说“扫一下这个站点”AI开始调用工具、输出结果对话越来越长AI开始“失忆”你刷新页面一切归零想复盘只能从头翻聊天记录ARTEX的核心设计理念是不要把所有上下文都堆在聊天记录里。它把渗透流程拆成几层稳定的运行单元再让Agent在这套约束里工作。层级作用对应实现数据层保存资产图、探索图、任务状态、流量记录PostgreSQL data/traffic执行层跑Planner、Worker、Chat Agentagent/编排层派生子任务、管理目标、处理触发器server/orchestration.go、server/scheduler.go安全控制层对高风险工具调用做拦截和审批guard/guard.go、intercept/接入层MCP、Web UI、录制代理、资产同步mcphttp/、server/、sync_scopesentry.go二、核心架构双图模型2.1 资产图与探索图分离ARTEX最核心的设计是两张图资产图存域名、站点、接口、参数、指纹、服务这些结构化对象探索图存目标、意图、事实、发现和执行链路这两个东西分开意义很大。普通Agent工作流的问题是“把所有上下文都堆在聊天记录里”。轮数一长模型只知道自己说过什么却很难稳定回答三个问题现在已经摸到了哪些入口哪些方向已经证伪哪些目标还没完成ARTEX的做法是把结构化信息写回图里。graph_overview、list_assets、list_findings这些工具不是装饰它们是Agent每轮重新建立态势感知的入口。任务暂停、页面刷新、甚至换一轮执行都还能回到同一份状态。2.2 存储实现PostgreSQL就够了有意思的是ARTEX没有使用Neo4j等独立图数据库。所有图数据都在PostgreSQL中以关系表的方式存储exploration_nodes探索节点goal、intent、finding、hintexploration_edges探索边spawns、derived_from、yields、provesexploration_anchors节点-资产关联表前端用antv/graphin渲染图后端从PostgreSQL查询组装成nodesedges JSON直接返回。部署只需要一个PostgreSQL大大降低了上手门槛。三、Planner Worker像“黑板架构”一样协作3.1 什么是黑板架构如果你接触过AI多智能体系统可能听说过黑板架构Blackboard Architecture——这是一种经典的多智能体协作模式所有智能体共享一个全局黑板共享内存/数据库各自独立读取黑板上的信息、做出决策、把结果写回黑板。没有中心化的“总指挥”每个智能体各司其职通过黑板间接协作。ARTEX的设计哲学与黑板架构高度相似PostgreSQL就是那块“黑板”——所有状态都持久化在这里Planner是“全局规划者”——盯着黑板上的全局态势拆解目标Worker是“具体执行者”——执行动作、把发现写回黑板Chat Agent是“对外接口”——解释当前进展、回答人的问题3.2 Planner和Worker的分工ARTEX没有把一个大模型当万能执行器而是把任务拆成Planner和Worker两类角色角色主要职责典型行为Planner看全局态势、拆目标、决定下一步意图读取graph_overview创建或收束任务Worker执行具体测试动作、写回事实和资产调工具、跑命令、登记insert_assets、report_findingChat Agent处理人机对话、解释当前进展回答“现在做到哪了”这类问题这种拆法的好处是规划和执行不抢同一段上下文。执行Agent可以把注意力放在当前意图上比如枚举接口、验证参数、读流量记录。规划Agent则盯住整场任务状态负责避免重复探索也负责在足够证据出现时推进目标完成。总结Planner是“项目经理”负责看全局、派活Worker是“一线工程师”负责干活、汇报。各干各的互不干扰。四、不得不提的几个亮点4.1 流量录制代理把“可回放”当一等公民ARTEX有一个很实用的设计把录制代理直接放进运行时。流量捕获开启后系统会把代理地址和CA证书注入到WebFetch、Bash子命令以及浏览器MCP里。结果就是Agent发起的HTTP请求能自动被录下来Playwright这类浏览器动作也能走同一条代理后续回看时可以优先查traffic_search/traffic_get不用重复打目标很多“AI渗透”项目只强调自动化执行但不太处理留痕问题。ARTEX反过来把“可回放、可复查、可检索”当成一等公民。对团队协作来说这比单次跑出一个PoC更值钱。4.2 MCP和平台工具直接进系统ARTEX不只是调用外部工具还把工具管理本身做进了平台。它内置了创建和更新Skill、自定义Tool、MCP服务的能力。这个平台不仅让Agent使用工具还想让Agent参与“扩工具”这件事。能力方向常见平台ARTEX任务执行扫描器或脚本为主Agent Tool协作资产管理多为结果列表资产图 探索图流量复盘常依赖外部代理内建录制代理和检索工具工具扩展人工接脚本Skill / Custom Tool / MCP一起管理自动编排通常较弱有子任务、触发器、调度器4.3 ScopeSentry同步解决“目标从哪来”很多自主测试平台最开始就卡在资产喂给谁、怎么喂。ARTEX补了ScopeSentry同步它可以按项目或任务维度把域名、子域、IP、端口、站点、端点这类资产导进来再归并到平台内部的资产图。这意味着它不只适合“我手工输一个URL让Agent跑起来”的场景更适合接到已有ASM或资产测绘链路后面。五、使用场景场景1内网或私有化测试环境给一组内部站点做持续探索把接口、参数和指纹自动沉淀到资产图里。PostgreSQL持久化了状态任务不会因为聊天窗口关闭直接丢掉。场景2接在ASM平台后面做二次探索先由ScopeSentry这类平台测绘资产再把结果同步进ARTEX让Agent继续按站点和端点深挖。对大型目标来说比纯手工喂URL更稳。场景3多Agent协作排查一个Agent做信息收集、另一个做漏洞验证、Planner负责全局协调——全部通过“黑板”PostgreSQL进行状态同步。六、使用心得✅ 值得肯定靶场验证能力不错在Vulhub、DVWA等靶场环境测试时Worker能按Planner的意图有序执行不会出现“扫到一半跑去干别的”的情况。攻击图和探索图清晰简洁前端用antv/graphin渲染的图非常直观节点和边的颜色、类型区分明确一眼就能看出当前探索到了哪一步、哪些方向已经走通、哪些还在进行中。主Agent和Worker调度清晰Planner读取graph_overview做全局决策Worker专注执行具体动作并写回结果。分工明确上下文不打架。流量录制是真香跑完一轮测试后直接去查流量记录请求响应一目了然复盘效率翻倍。部署简单只需要一个PostgreSQLDocker不需要折腾Neo4j、Redis、消息队列这些额外组件。七、二开建议ARTEX是一个值得深度二开的项目。以下是几个我认为有价值的优化方向1. Planner并发瓶颈当前架构是单Planner 多Worker所有意图生成都走同一个Planner loop。当多个Worker同时完成各自意图时Planner只能串行处理。建议将通知机制改为事件驱动用Channel直接触发而非Timer debounce并考虑按探索子方向分片让多个Planner并行规划不同分支。2. 图查询性能优化探索图用PostgreSQL关系表存储边的遍历依赖多次SQL JOIN。当探索链路很深时几十个节点串联递归查询会变重。建议对需要递归遍历的场景用PostgreSQL递归CTE一次查询替代多次JOIN为频繁的图遍历路径加物化缓存3. Worker超时回收机制Worker对于大工具输出采用了写入磁盘文件的方式防止内存膨胀但超时后的收尾机制可能出现“已拿到关键结果却被超时切断”的情况。建议在Bash工具层面做“最后N行”的增量截断超时时把已有的有价值输出先写回探索图再终止LLM调用而不是一刀切。4. 资产图关联索引assets表依赖task_ids[]数组做任务归属exploration_anchors做节点-资产关联但资产之间的关联如子域名→IP→服务只能在应用层靠多次查询拼出来。建议加一张轻量的asset_edges表表达资产间拓扑domain→resolves_to→ip、ip→hosts→service让资产图真正可高效遍历。5. 拦截规则优先级缓存拦截规则每次变更需要手动Invalidate()重载。若规则数量增多每次Match()逐条遍历会有性能损耗。建议按工具名分组建立二级索引toolName → []compiledRule匹配时只遍历目标工具对应的规则子集。八、总结ARTEX不是一个“在聊天框里接个LLM”的玩具项目。它把资产图谱、探索图、流量录制、任务编排和AI Agent真正融为了一体。双图模型解决了状态持久化和上下文管理的问题PlannerWorker分工解决了规划和执行抢上下文的问题流量录制代理解决了执行留痕和可复盘的问题ScopeSentry同步解决了目标资产从哪来的问题