这次我们来看一个叫 Ottermind AI 的安全方向项目。它的核心定位是用 4 个 AI Agent 自动完成漏洞赏金侦察Bug Bounty Recon把侦察阶段最耗时、最重复的信息收集、目标分析、风险初筛和报告整理交给 Agent 协作完成。如果你平时做 SRC、漏洞赏金或授权渗透测试大部分时间都花在子域名枚举、端口扫描、指纹识别这些基础工作上那这类工具可以帮你把流程标准化、自动化。先说这个项目值得关注的几个点第一它不是一个单点扫描器而是 Agent 编排框架强调多个 AI Agent 分工协作第二它会自动把侦察结果汇总成结构化报告省去手动整理第三如果它支持接入大模型 API那么 Agent 还会根据中间结果自动调整后续动作不是死板地执行固定脚本第四它通常支持批量任务一次可以处理多个授权域名第五从这类项目的常见设计看它是命令行工具也可以通过 API 对外提供服务。这篇文章会带大家从零过一遍先了解 4 个 Agent 分别承担什么工作再讲环境准备和部署启动然后做一轮功能测试最后给出 API 调用和批量任务的通用接入方式。因为不同版本的 Ottermind AI 具体命令可能不同文章里会保留通用模板实际使用时以你克隆到的项目 README 为准。1. 核心能力速览能力项说明项目类型基于 AI Agent 的漏洞赏金侦察自动化工具Agent 数量4 个分工覆盖侦察流程关键环节主要功能子域名收集、端口/服务识别、指纹与漏洞初筛、报告生成运行环境Linux / macOS / Windows WSL具体以官方文档为准硬件要求通常 CPU 即可运行如果集成本地模型做智能分析则需按模型测试显存启动方式命令行启动 / 一键脚本 / API 服务是否支持 API一般会提供 HTTP 接口字段以项目文档为准是否支持批量任务支持可对多个授权目标批量下发任务适合场景授权范围内的 SRC 测试、漏洞赏金侦察、资产梳理使用边界必须获得授权禁止未授权扫描从材料看Ottermind AI 的关键词是“自动完成漏洞赏金侦察”。漏洞赏金侦察的核心动作并不是直接打点拿权限而是先搞清楚目标暴露面有哪些子域名、哪些端口开放、跑着什么服务、有没有已知漏洞的指纹。这个过程重复性高非常适合交给 Agent 自动化。2. 适用场景与使用边界先泼一盆冷水。任何漏洞赏金侦察工具都必须在授权范围内使用。Ottermind AI 再自动也只是把你的指令变成流量和请求目标方收不收得到这些请求才是关键。未授权扫描在大多数地区是违法的也会违反漏洞赏金平台的规则轻则封号重则承担法律责任。所以下面所有操作场景都有一个前提目标是你自己的资产或者你已经拿到书面授权且授权范围明确包含该域名/IP。适合用这类工具的人有三类。第一类SRC 漏洞报送者手上有几十个授权域名要定期巡检人工跑一遍子域名收集和指纹识别非常累。第二类企业安全团队需要快速梳理互联网暴露面把新上线资产和已知漏洞指纹定期喂给 Agent 做增量扫描。第三类研究 AI Agent 与安全自动化结合的技术人员想看看多 Agent 协作到底能把侦察流程自动化到什么程度。不适合用这类工具的场景也要说清楚。如果你只是想对单个站点快速看一遍直接手动跑 nmap whatweb 可能更快上 Agent 反而多了一层配置成本。如果目标有严格 WAF或者平台明确禁止主动扫描那么这种方式依然不合适。AI Agent 不会帮你绕过规则它只是把流程自动化了是否合规仍然由你判断。隐私和数据边界也要注意。侦察过程会收集大量 DNS 解析记录、HTTP 响应头、证书信息、目录路径等这些数据可能包含内部主机名、云资源 ID、员工邮箱。工具会把这些数据写入本地数据库或生成报告那么这些报告就不能随意公开。漏洞赏金平台通常要求漏洞细节保密报告里如果包含敏感信息只能发给授权方。使用过程中要注意日志脱敏不要把你的 API 密钥、代理凭证、目标平台账号信息写进自动生成的报告。3. 环境准备与前置条件在部署 Ottermind AI 之前先把环境检查一遍。这类基于 Python 的工具最常见的问题是依赖版本冲突。建议直接用虚拟环境隔离不要污染系统 Python。3.1 操作系统与基础软件推荐使用 Linux 或 macOS。如果你在 Windows 上优先用 WSL2因为很多安全工具在原生 Windows 上的兼容性会让人崩溃。基础软件清单大致如下Git用于拉取项目代码。Python 3.9 或更高版本推荐 3.10/3.11。pip 和 venv用于安装依赖和隔离环境。curl用于测试 API 接口。网络能正常访问目标域名和漏洞情报源。某些依赖组件可能需要编译工具比如 libffi、libpcap、openssl。如果你在 Ubuntu/Debian 上可以提前安装sudo apt update sudo apt install -y git python3 python3-venv python3-pip \ build-essential libssl-dev libffi-dev libpcap-devmacOS 上可以用 Homebrew 安装类似组件brew install git python libpcap openssl这里只是通用准备具体依赖以项目 requirements.txt 为准。3.2 大模型 API 密钥Ottermind AI 的 Agent 行为可能依赖大模型来理解目标和生成决策。常见的大模型接入方式有两种调用云端 API或者连接本地模型。如果你使用云端 API那么需要准备对应的 API 密钥并把它配置到环境变量或配置文件中。以 OpenAI 兼容接口为例通常需要两个变量export OPENAI_API_KEYsk-xxxxx export OPENAI_BASE_URLhttps://api.openai.com/v1如果项目支持本地模型则可能需要启动一个本地推理服务比如 vLLM、Ollama 等。这种情况下要关注推理服务的显存占用。一般信息收集场景不需要 GPU但如果 Agent 要实时分析大量 HTTP 页面内容本地 7B 模型也需要 4G 到 8G 显存实际以模型配置为准。3.3 目标范围文件建议不要直接在命令行里写长串目标。创建一个 targets.txt每行一个授权目标例如example.com scanme.example.org 192.168.1.0/24这样既方便批量任务也能避免 shell 历史记录泄露完整目标范围。目标写入文件之前反复确认这些都在授权范围内。4. 安装部署与启动方式4.1 拉取项目代码先从远程仓库拉取代码然后进入项目目录git clone https://github.com/your-org/ottermind-ai.git cd ottermind-ai上面仓库地址只是示例实际以你获取到的项目地址为准。如果项目是私有仓库需要先配置 SSH key 或访问令牌。4.2 创建虚拟环境并安装依赖python3 -m venv .venv source .venv/bin/activate pip install --upgrade pip pip install -r requirements.txt如果你的网络环境安装慢可以使用国内镜像比如清华源pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple安装过程如果报错优先检查编译工具是否完整再检查 Python 版本是否满足要求。4.3 初始化配置文件多数项目会提供一个配置模板比如 config.example.yaml 或 config.example.json。复制一份为真实配置cp config.example.yaml config.yaml然后编辑 config.yaml把 API 密钥、目标文件路径、输出目录填好。配置内容大概长这样# 这是一个示例配置实际字段以项目为准 agent: recon: enabled: true fingerprint: enabled: true vuln_check: enabled: true report: enabled: true api: provider: openai api_key_env: OPENAI_API_KEY targets_file: ./targets.txt output_dir: ./output这里只是展示了这类项目常见的配置结构四个 Agent 开关分别对应侦察、指纹、漏洞初筛、报告四个环节。你可以按需关闭某个 Agent比如只需要子域名收集就只保留 recon。4.4 启动侦察任务配置完成后以命令行方式运行一次侦察python main.py --config config.yaml --targets targets.txt如果没有 main.py查看 README 里的入口文件名可能是 run.py 或 ottermind.py。启动后应该能在终端看到 Agent 的状态输出一般是分阶段显示的比如Recon Agent 开始收集子域名Fingerprint Agent 开始识别服务Vuln Check Agent 开始匹配已知指纹Report Agent 正在生成报告如果你看到 Invalid API key 或 Connection error说明大模型 API 这边没配好先回到上一步检查环境变量。4.5 一键脚本与 Docker 方式如果项目提供了一键启动脚本比如 start.sh那么更省事chmod x start.sh ./start.sh部分项目也会提供 Dockerfile用 Docker 可以减少环境冲突docker build -t ottermind-ai . docker run --rm -v $PWD/output:/output \ -e OPENAI_API_KEY$OPENAI_API_KEY \ ottermind-ai --targets /output/targets.txtDocker 方式的好处是依赖隔离彻底坏处是网络代理和 DNS 解析可能受影响。如果扫描目标有特殊网络要求建议优先用原生方式运行。5. 功能测试与效果验证部署成功只是第一步关键是验证 4 个 AI Agent 是否真的按照预期工作。下面给出一套通用验证流程每个功能点都可以单独测试。5.1 子域名收集测试测试目的确认 Recon Agent 能自动发现目标子域名。输入一个你拥有授权的域名比如 example.com。运行采集后检查输出目录下的 subdomains.txtcat output/subdomains.txt预期结果文件里列出解析到公网的子域名。判断标准是域名数量大于 0并且至少包含几个真实存在的子域名。常见失败原因目标 DNS 存在泛解析工具误把泛解析结果全部收集进来DNS 服务器限速导致部分字典被丢弃API 密钥过期导致被动收集源返回空。5.2 端口扫描与服务识别测试测试目的确认 Fingerprint Agent 能对存活主机做端口扫描并识别服务类型。一般工具会直接用 nmap 或 masscan 作为底层引擎。运行后检查服务识别结果文件例如 services.json。每一条记录应该包含 IP、端口、协议、服务名、产品名和版本信息。{ host: 203.0.113.10, port: 443, service: https, product: nginx, version: 1.18.0 }这里只是展示返回结构的一种常见形式。判断成功标准至少能识别到开放端口并能给出常见服务的产品指纹。失败时先看底层扫描器是否正常比如用 nmap 手动扫一次对比结果。5.3 指纹与漏洞初筛测试测试目的确认 Vuln Check Agent 能结合指纹判断是否存在已知风险。这个环节一般不会直接打 POC而是根据产品版本匹配漏洞库。比如 Fingerprint Agent 识别出目标跑着 Apache Shiro 某个版本Vuln Check Agent 会标记为“疑似受影响”并在风险列表里给出 CVE 编号和参考链接。判断标准报告里能出现风险条目并且风险条目与真实指纹对应而不是所有目标都报同一个风险。如果所有目标都报同样风险大概率是指纹识别模块没有正确读取到目标信息或者规则匹配写得过于宽松。5.4 报告生成测试测试目的确认 Report Agent 能把前三个 Agent 的输出汇总成可读报告。运行完成后检查 output 目录下是否生成 markdown 或 html 报告。报告结构一般包含目标概览、子域名列表、开放端口、服务指纹、风险列表、附录数据。打开报告检查是否包含实际的数据而不是空模板。这里要留意报告里是否出现了误报比如某些子域名明明已经下线报告还标记为存活。这类误报通常是因为缓存了历史 DNS 记录。5.5 多轮协作观察既然叫 AI Agent那就得观察它有没有“根据中间结果调整行为”的能力。比如 Recon Agent 发现一个子域名解析到内网 IP如果配置了判断规则后续 Agent 应该自动跳过这个内网目标避免向非授权地址发起扫描。运行过程中留意日志里有没有类似这样的自动决策[Recon Agent] Found internal IP 10.0.0.5 for staging.example.com, skip. [Vuln Check Agent] Target not in scope, skip vulnerability check. [Report Agent] Filtered out out-of-scope data.如果所有 Agent 只是按固定脚本跑没有这种动态判断那只能算“自动化脚本”还不能叫真正的 Agent。这一点也是测试时最值得关注的差异化能力。6. 接口 API 与批量任务对于工程化使用命令行跑一次可能不够。很多场景需要把 Ottermind AI 集成到自己的漏洞管理平台或 CI/CD 流程里这时候就要用到 API。6.1 启动 API 服务项目一般会提供一个服务模式入口例如python server.py --config config.yaml --host 127.0.0.1 --port 8080启动后可以用 curl 检查服务状态curl http://127.0.0.1:8080/health如果返回{status: ok}之类的内容说明服务正常。这里注意服务地址如果只想本机访问就绑定 127.0.0.1不要绑定 0.0.0.0防止未授权访问。6.2 发起侦察任务以下是一个通用的 API 请求模板实际字段名需要按项目文档调整curl -X POST http://127.0.0.1:8080/tasks \ -H Content-Type: application/json \ -d { target: example.com, agents: [recon, fingerprint, vuln_check, report], callback_url: }接口收到任务后一般会返回一个 task_id用于后续查询状态{ task_id: b7e1a3f2-1a2b-4c3d-9e8f-6a5b4c3d2e1f }这里 task_id 是随机生成的示例不要当作真实格式。6.3 查询任务状态异步任务通常需要轮询状态。可以使用下面的 Python 模板import requests import time base_url http://127.0.0.1:8080 task_id b7e1a3f2-1a2b-4c3d-9e8f-6a5b4c3d2e1f while True: resp requests.get(f{base_url}/tasks/{task_id}, timeout10) data resp.json() status data.get(status) print(ftask status: {status}) if status in (completed, failed, canceled): break time.sleep(5) if status completed: result requests.get(f{base_url}/tasks/{task_id}/report, timeout30) with open(report.json, wb) as f: f.write(result.content)这个轮询逻辑在批量任务中很常见。注意每个请求都加了 timeout防止服务挂起导致客户端无限等待。6.4 批量任务设计批量任务的关键是目标文件。假设你有 50 个授权域名可以在 API 里逐个提交也可以看看项目是否支持“目标列表”批量提交curl -X POST http://127.0.0.1:8080/batch_tasks \ -H Content-Type: application/json \ -d { targets_file: /path/to/targets.txt, concurrency: 5 }批量任务执行时要注意三点并发数不要设置太大避免对目标服务器造成过大压力也可能让本地扫描器崩溃。每个任务都要记录开始时间、结束时间、状态、输出文件路径方便失败重跑。如果中间某个目标扫描失败不要整个批次重跑最好能单独重试这个任务。7. 资源占用与性能观察这类侦察工具的资源占用主要不在 GPU而在网络连接数、内存和磁盘 I/O。7.1 观察方法运行任务时可以用 htop 看 CPU 和内存用 nethogs 或 iftop 看网络流量。如果是容器环境用 docker stats 查看实时占用。日志里也会打印每个 Agent 的耗时。以子域名收集为例如果使用大字典内存会明显上升。一个 10 万条记录的字典文件加载到内存大概要占用几十 MB 到上百 MB具体取决于工具实现。端口扫描阶段masscan 可以打到很高的包速率但并发太高会影响本机网络和上游网络。7.2 CPU 与 GPU 差异从这类 Agent 编排工具的定位来看主要运行逻辑都是 Python 脚本和外部扫描器对 GPU 没有强依赖。CPU 就能胜任绝大多数工作。如果项目接了本地大语言模型用于报告总结、目标优先级评分那么 GPU 会显存占用会随模型规模增加。7B 模型量化后可能需要 4G 到 6G 显存具体要看量化位数。如果只是调用云端 API本地资源占用保持在较低水平。7.3 降低资源占用的方法先小范围跑通用 10 个域名、3 个 Agent 跑一遍确认功能和输出没问题再放大规模。降低并发调整扫描并发数避免流量过大导致目标 WAF 封禁你的出口 IP。分批处理把 1000 个域名分成 10 批每批 100 个减少峰值压力。及时清理历史数据侦察过程会生成大量临时文件比如原始 HTTP 响应、DNS 缓存任务完成后按需清理。8. 常见问题与排查方法问题现象可能原因排查方式解决方案启动时报 ModuleNotFoundError依赖未安装完整检查 pip list重新执行 pip install -r requirements.txtAPI 请求返回 401API Key 错误或过期检查环境变量和配置文件更新 API Key确认 BASE_URL 正确子域名收集结果为空DNS 服务器不可达或字典太小手动执行 dig 测试更换 DNS 服务器扩大字典端口扫描阶段卡住底层 nmap 需要 sudo 权限查看日志是否显示 permission denied给扫描器配置 root 权限或使用非特权扫描模式报告里出现大量相同风险指纹匹配规则过宽人工抽查目标指纹调整指纹规则优先匹配精确版本API 提交任务后长时间 Pending任务队列未启动检查 server 日志确认 worker 进程已启动批量任务跑到一半失败网络波动或目标超时查看失败任务日志增加超时时间对失败任务单独重试目标出现内网 IP配置了泛解析或 DNS 劫持对比权威 DNS 解析结果在配置中过滤私有网段日志显示 Internal Server Error后端程序异常查看完整堆栈反馈给项目维护者或回滚到稳定版本这里的排查思路都是通用的。因为 Ottermind AI 的具体版本和底层实现未知遇到问题最直接的办法是看日志。日志里一般会标明是哪个 Agent、哪个模块出错再根据错误关键字去项目 issue 区搜索。9. 最佳实践与使用建议把 Ottermind AI 用起来不难但要用得稳、用得合规建议按照下面这套思路来。第一第一次先拿完全可控的实验目标测试。比如你在自己的云服务器上跑一个 Nginx、一个 Tomcat再用工具去侦察。这样即使 Agent 行为不符合预期也不会造成越权风险。等确认工具不会乱跳内网、不会扫到非授权 IP再往真实授权目标上放。第二配置里把内网段和保留 IP 段全部列入黑名单。很多工具会解析出 CNAME 或 MX 记录指向一些内部域名。为了避免 Agent 顺着 DNS 记录跑到内网地址一定要在配置里加上类似下面这样的过滤filters: exclude_ip_ranges: - 10.0.0.0/8 - 172.16.0.0/12 - 192.168.0.0/16 - 169.254.0.0/16 - 127.0.0.0/8第三把 API 密钥和报告分开管理。API 密钥放在环境变量里不要写进报告文件或日志。报告文件最好是按日期分目录并且设置访问权限避免别人通过你分享的链接看到完整内网资产和漏洞列表。第四批量任务一定要设计好中断恢复。最简单的方法是每个目标一个 task跑完的标记完成失败的重试。别把所有目标塞进一个大任务否则一个目标卡住会影响整批。第五关注大模型输出可能带来的误判。AI Agent 的价值是帮你生成预测和决策但它的判断不一定是对的。漏洞赏金报告提交前至少要人工复核风险条目是否真实存在不要直接拿 AI 生成的报告去提交避免平台把重复无效报告判定为垃圾报告。第六定期更新漏洞指纹库。很多已知漏洞指纹规则是静态的如果工具集成了第三方漏洞库要定期拉取更新。否则 Agent 扫描到的指纹再准确匹配不到新漏洞也白搭。10. 总结与下一步Ottermind AI 最值得尝试的一点是把漏洞赏金侦察从“手动敲命令 手动整理报告”变成“4 个 Agent 协作完成任务”。它能省下来的时间主要在信息收集和报告整理两个环节风险判断环节仍然需要你作为人来兜底。如果你准备试一下第一步不需要跑完整个流程先验证 Recon Agent。给一个授权域名看它能不能完整收集子域名并把结果输出成结构化文件。然后逐个打开 Fingerprint Agent、Vuln Check Agent、Report Agent每加一个都观察输出和资源消耗。最后再尝试 API 批量任务把 10 个授权域名放进去跑。最容易踩的坑是前期配置里没定义清楚范围导致 Agent 跑到授权范围之外。所以任何跑批之前先在配置里把过滤规则写好把目标文件里的每一行都确认一遍。后续可以从两个方向继续扩展一是把 Ottermind AI 接进自己的漏洞管理平台让每次扫描结果自动建单二是基于它的 Agent 框架调整提示词和工具调用流程让它更适合自己团队的侦察规范。总之工具只是把流程自动化最后做决定和承担责任的人还是你。建议收藏备用部署时对照文章里的环境准备和排查清单能少踩不少坑。