2026年ChatBI产品推荐：问数与协同能力对比
2026/7/30 10:31:05
前言
在AI渗透测试工具层出不穷的今天，大多数项目给人的感觉是“在聊天框里接了个能执行命令的Agent”——对话一长，模型忘了自己扫到哪了；页面一刷新，执行状态全丢了；想复盘的时候，只能翻聊天记录。
今天给大伙分享渗透测试智能体开源项目——ARTEX。
项目地址：GitHub - Autumn-27/ARTEX: AI 自主渗透测试系统 · GitHub
在线Demo：http://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 Agent | agent/ |
| 编排层 | 派生子任务、管理目标、处理触发器 | 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、hint）exploration_edges：探索边（spawns、derived_from、yields、proves）exploration_anchors：节点-资产关联表
前端用@antv/graphin渲染图，后端从PostgreSQL查询组装成nodes+edges 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_finding |
| Chat 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专注执行具体动作并写回结果。分工明确，上下文不打架。流量录制是真香：跑完一轮测试后直接去查流量记录，请求响应一目了然，复盘效率翻倍。
部署简单：只需要一个PostgreSQL+Docker，不需要折腾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真正融为了一体。
双图模型解决了状态持久化和上下文管理的问题
Planner+Worker分工解决了规划和执行抢上下文的问题
流量录制代理解决了执行留痕和可复盘的问题
ScopeSentry同步解决了目标资产从哪来的问题