AutoHunter 是一个 LLM 驱动的自动化多 Agent 挖洞框架，专攻中国教育网的 SRC 生态。想法不错，Demo级别，不指望开箱即用。
亮点
多 Agent 架构设计对路
Collector → Worker × N → Reviewer → 人工复审
这条链路是对的。真正能用的自动化挖洞系统就该这么搭——采集、执行、初审、人工确认，四层分离。比那些一把梭的扫描器强多了。
FOFA 集成 + 高校资产标记
edu_ip.db 离线库做高校归属标注，这一手很实用。国内 EduSRC 最大的痛点就是资产归属模糊，谁家 IP
是哪个学校的不清楚，这个数据库能省不少事。
LLM 驱动不是噱头
它不是简单调 nuclei 跑扫描，而是让 LLM 自主决策：选什么工具、分析返回、决定下一步。这才是 LLM
在挖洞里的正确用法——当决策大脑，不是当报告生成器。
Tech Stack 选型务实
Python + FastAPI + Vue3 + Docker，工具链全塞容器里（nmap/nuclei/sqlmap/httpx）。部署简单，依赖干净。
问题
LLM 的幻觉问题没人解决
框架让 LLM 做决策，但没看到对 LLM 幻觉的处理机制。Worker 跑偏了、误解了工具输出、产生了错误的下一步判断——这些在 Demo
阶段无所谓，真要用起来就是大坑。挖洞要的是精确性，LLM 天生不擅长这个。
SQLite 做持久化
Demo 可以，但凡任务多点就撑不住。多 Agent 并发写 SQLite 的锁竞争够喝一壶。
没有真正的 bypass 能力
这个框架做的是表面扫描。遇到 WAF、复杂认证、JS 解密的 SPA——基本歇菜。真实挖洞遇到的大部分场景它都处理不了。
Agent 间协调太简单
不是说多 Agent 就牛逼了。它的 Agent 之间基本没有信息共享机制。Worker A 发现了一个入口，Worker B 不知道；nuclei
扫出了路径，sqlmap 没利用上。真正的多 Agent 协同需要共享上下文，这个没有。
对于挖 EduSRC 的实用性
适合的场景：
- 快速资产收集 + 批量初筛
- 捡漏低 hanging fruit（nuclei 模板能命中的常见漏洞）
- 高校 IP 归属识别（这个 edu_ip.db 确实有用）
- 学习自动化挖洞框架的设计思路
不适合的场景：
- 需要深入利用的复杂漏洞
- 有 WAF/IDS 的目标
- 需要人工分析业务逻辑的漏洞
- 高并发大规模任务
- 任何需要稳定产出的场景
AutoHunter 是一个 LLM 驱动的自动化多 Agent 挖洞框架，专攻中国教育网的 SRC 生态。想法不错，Demo级别，不指望开箱即用。
亮点
多 Agent 架构设计对路
Collector → Worker × N → Reviewer → 人工复审
这条链路是对的。真正能用的自动化挖洞系统就该这么搭——采集、执行、初审、人工确认，四层分离。比那些一把梭的扫描器强多了。
FOFA 集成 + 高校资产标记
edu_ip.db 离线库做高校归属标注，这一手很实用。国内 EduSRC 最大的痛点就是资产归属模糊，谁家 IP
是哪个学校的不清楚，这个数据库能省不少事。
LLM 驱动不是噱头
它不是简单调 nuclei 跑扫描，而是让 LLM 自主决策：选什么工具、分析返回、决定下一步。这才是 LLM
在挖洞里的正确用法——当决策大脑，不是当报告生成器。
Tech Stack 选型务实
Python + FastAPI + Vue3 + Docker，工具链全塞容器里（nmap/nuclei/sqlmap/httpx）。部署简单，依赖干净。
问题
LLM 的幻觉问题没人解决
框架让 LLM 做决策，但没看到对 LLM 幻觉的处理机制。Worker 跑偏了、误解了工具输出、产生了错误的下一步判断——这些在 Demo
阶段无所谓，真要用起来就是大坑。挖洞要的是精确性，LLM 天生不擅长这个。
SQLite 做持久化
Demo 可以，但凡任务多点就撑不住。多 Agent 并发写 SQLite 的锁竞争够喝一壶。
没有真正的 bypass 能力
这个框架做的是表面扫描。遇到 WAF、复杂认证、JS 解密的 SPA——基本歇菜。真实挖洞遇到的大部分场景它都处理不了。
Agent 间协调太简单
不是说多 Agent 就牛逼了。它的 Agent 之间基本没有信息共享机制。Worker A 发现了一个入口，Worker B 不知道；nuclei
扫出了路径，sqlmap 没利用上。真正的多 Agent 协同需要共享上下文，这个没有。
对于挖 EduSRC 的实用性
适合的场景：
不适合的场景：