开源 AI 渗透测试框架 Strix 深度评测

原创

筑梦网安
筑梦网安

全栈安全

2026年7月5日 23:46
河南

在小说阅读器读本章

去阅读

本文介绍一款登上Github Trending榜单的自主式 AI 渗透测试框架：给它一个目标，它就在 Docker 沙箱里起一组 AI agent，像真人渗透测试工程师那样做侦察、找漏洞、用真实 PoC 验证、出报告，白盒场景下还能直接修代码。

本文从源码层面拆解 Strix 的技术原理与能力边界，适合应用安全工程师、安全团队负责人和关注\"AI + 安全\"赛道的开发者阅读。

strix 仓库主页，Apache 2.0 开源

一、它到底是什么

一句话：Strix = 多智能体编排 + 沙箱化真实工具执行 + 纪律化渗透方法论，三者打包成一个 CLI。

你给它一个目标——可以是本地代码目录（白盒）、一个 GitHub 仓库（白盒/灰盒），或一个在线域名（黑盒）。它会：

1. 1. 在 Docker 沙箱里拉起一个 Kali 环境（预装 nmap、nuclei、sqlmap、ffuf、semgrep 等几十个工具）；
2. 2. 启动一个 root agent 作为编排者，按需 spawn 专门的子 agent 并行干活；
3. 3. 走\"侦察 → 利用 → PoC 验证 → 报告\"管线，白盒场景多一步\"自动修复\"；
4. 4. 输出 SARIF / CSV / Markdown 多格式报告，可接 GitHub Actions 做 PR 级门禁。

它的核心卖点不是\"能让 LLM 跑 nmap\"——这其实没什么难度——而是把渗透测试的纪律性编码进了 agent 的系统提示和工具契约里：先侦察再测、必须 PoC 验证、漏报不算数、只有专门 agent 才能报漏洞。

底座是 OpenAI Agents SDK（openai-agents[litellm]）+ LiteLLM 多模型抽象，所以它支持 OpenAI / Anthropic / Google Vertex / Bedrock / Azure 以及 Ollama、LMStudio 等本地模型。本质上 Strix 是\"在 Agents SDK 的沙箱能力之上，外挂一套渗透专用的 agent 图、技能库和报告管线\"——不是从零造轮子，工程上加分。

Strix 文档站 docs.strix.ai，能力概览与快速开始

二、能力全景

2.1 Agentic 渗透工具盘

Strix agent 在沙箱里能调用的工具集，和真人 pentester 用的是同一套：

• • Shell & 命令执行 — 交互式终端，沙箱内任意跑 Kali 工具，用于侦察、利用开发、后渗透
• • HTTP 拦截代理 — 容器内 Caido sidecar 透明抓包，agent 可 list_requests / view_request / repeat_request 回看、重放、导出 sitemap
• • 浏览器自动化 — Playwright 驱动的 agent\_browser，测 XSS / CSRF / 点击劫持 / 认证绕过等需要真实浏览器渲染的流程
• • 自定义 Exploit 运行时 — Python 沙箱，写并验证 PoC 脚本
• • 静态 + 动态分析 — 白盒走 semgrep 等 SAST，黑盒走 DAST 主动探测
• • 侦察 & OSINT — 攻击面测绘、子域枚举、指纹识别
• • 漏洞知识库 — 结构化 findings，带 CVSS 评分和 OWASP 分类

2.2 漏洞覆盖面

strix/skills/vulnerabilities/ 下有 23 个漏洞类型的纯 Markdown 知识包，每个都是一份\"如何测这种漏洞\"的方法论手册，agent 按需 load_skill 加载：

覆盖 OWASP Top 10 及以外。此外还有 frameworks/（4 个框架手册）、protocols/（2 个协议手册）、tooling/（11 个工具手册）、cloud/、reconnaissance/、scan_modes/ 等共 51 份技能文档——构成 agent 的\"渗透知识图谱\"。

2.3 多智能体编排（Graph of Agents）

• • 分布式渗透 — 侦察、利用、后渗透由专门的子 agent 负责
• • 可扩展 — 跨多目标并行执行
• • 动态协作 — agent 间共享发现、串联漏洞，像红队一样协同

2.4 报告与集成

• • 多格式报告 — SARIF 2.1.0（接 GitHub code-scanning）、CSV、Markdown
• • 自动修复 — 白盒场景用 apply_patch 生成补丁并验证修复有效
• • CI/CD — GitHub Actions 一段 yaml 即可在每个 PR 上跑安全扫描

三、技术原理：六层架构

读源码第一印象：分层非常干净。整个项目就是一个 strix/ 包，按职责切了六层：

Strix 六层架构

自上而下：

1. 1. Interface（strix/interface/） — CLI 入口 + Textual TUI。main.py 是 strix 命令的 entry point；TUI 可实时看 agent 树、todo、消息流。
2. 2. Core Orchestration（strix/core/） — 编排核心。

• • runner.py：跑一次扫描的全生命周期（含 resume 分支）
• • agents.py：多 agent 图状态机 AgentCoordinator
• • execution.py：agent 执行循环（含非交互式 final-output 校验）
• • hooks.py：计费 + 预算硬熔断
• • sessions.py：SDK Session 管理

3. 3. Runtime（strix/runtime/） — Docker 沙箱 + Caido 代理 sidecar：session_manager.py、docker_client.py、caido_bootstrap.py、backends.py
4. 4. Tools（strix/tools/） — agent 可调用的工具集：shell、proxy、agents_graph、reporting、apply_patch、notes/todo、agent_browser、web_search、load_skill、finish、thinking、view_image
5. 5. Skills（strix/skills/） — 纯 Markdown 知识包，51 份，按漏洞类型/框架/协议/工具分类
6. 6. Report（strix/report/） — 漏洞去重（LLM-as-judge）、SARIF 输出、报告写作、用量统计

底座 OpenAI Agents SDK 提供 Session（SQLite 持久化对话）、流式 stream、sandbox capabilities（Filesystem/Shell）。Strix 在此之上构建渗透专用的 agent 图、技能库和报告管线。

一个关键细节：agents/factory.py 里 agent 的 capabilities 直接是 Filesystem + Shell——也就是说 agent 直接在 Kali 容器里跑命令、读写文件。这是\"真实 PoC 验证\"的物理基础，不是模拟。

四、技术原理：多 Agent 编排——反应式树，不是剧本

这是 Strix 最有技术含量的部分。它不是预先编排 N 个固定角色，而是 root agent 在工作中发现新攻击面就 spawn 对应专家子 agent：

多 agent 工作流

每个漏洞走 Discovery → Validation → Reporting 链，白盒多一个 Fixing

工作流很清晰：黑盒走\"Discovery → Validation → Reporting\"三 agent 链，白盒多一个 Fixing agent 用 apply_patch 修代码并验证修复。每个 agent 1–3 个 skill、单一职责，系统提示明确禁止\"kitchen sink agent\"（什么都干的 agent）。

4.1 AgentCoordinator：图状态机

源码层面，AgentCoordinator（strix/core/agents.py）是整个项目的设计核心。它是一个单线程异步拥有的图状态机，所有 agent 状态、父子关系、消息队列挂在一个 asyncio.Lock 下。每个 agent 在运行期是三样东西的组合：

@dataclass(slots=True)
class AgentRuntime:
    session: Session | None = None      # SDK 的 SQLite Session，兼作消息队列
    task: asyncio.Task[Any] | None = None  # 这个 agent 的执行协程
    stream: Any | None = None           # 当前流式 turn
    interrupt_on_message: bool = False
    wake: asyncio.Event = field(default_factory=asyncio.Event())

4.2 用 SDK Session 当消息队列

coordinator.send() 的消息投递机制很巧妙——它不维护一套独立的消息中间件，而是直接把消息作为 user item 追加到目标 agent 的 SDK session 里：

async def send(self, target_agent_id, message):
    # ...
    await session.add_items([self._message_to_session_item(message)])
    # pending_counts +1，set wake Event
    self.pending_counts[target_agent_id] += 1
    self.runtimes[target_agent_id].wake.set()
    # 若该 agent 正在跑一个 turn 且允许中断，立即打断
    if stream is not None and interrupt:
        stream.cancel(mode=\"immediate\")

效果：用 SDK 原生 session 当消息队列，省掉一套中间件；目标 agent 在 wait_for_message() 上 wake.wait() 阻塞，有消息就唤醒继续。trigger_budget_stop() 则遍历所有 runtime wake.set()，把 parked 的 agent 全部唤醒退出——预算熔断的传播路径。

4.3 lifecycle 工具强制收尾

另一个值得欣赏的设计：lifecycle 工具强制收尾，对抗 LLM\"我说完了\"就停的倾向。

agents/factory.py 的 _finish_tool_use_behavior 规定，只有 finish_scan（root agent）或 agent_finish（子 agent）成功返回才允许结束。配合 core/execution.py 的非交互循环——如果 agent 输出纯文本就结束，会被判为\"非法 final output\"，往 session 塞一条 recovery 消息强制继续，超过 max\_turns 直接标 crashed。

这是在自主 agent 系统里非常常见的失败模式（LLM 偷懒提前停），Strix 用工具契约硬约束住，值得借鉴。

五、技术原理：沙箱与 Caido 透明代理

沙箱设计是另一个亮点。Strix 在 Docker 容器里跑 Kali + 全套工具，旁边挂一个 Caido 代理 sidecar（容器内 127.0.0.1:48080）：

沙箱与 Caido 数据流

容器内所有 HTTP 流量自动走 Caido，agent 可随时回看/重放

最优雅的地方在 runtime/session_manager.py：它通过容器环境变量 http_proxy / https_proxy / ALL_PROXY 全指向 Caido，让容器里所有进程的 HTTP 流量自动被代理抓下来，不需要改任何工具代码；NO_PROXY=localhost,127.0.0.1 防止 agent\_browser 的 CDP 本地回环也被代理绕一圈。

# 容器内环境变量（示意）
http_proxy=http://127.0.0.1:48080
https_proxy=http://127.0.0.1:48080
ALL_PROXY=http://127.0.0.1:48080
NO_PROXY=localhost,127.0.0.1

效果：agent 用 nmap、sqlmap、ffuf 发的每一个请求都被 Caido 记录，agent 通过 list_requests / view_request / repeat_request 工具随时回看、重放、导出 sitemap。这种\"透明拦截 + 主动回看\"的能力，是真人 pentester 用 Burp/Caido 的工作流被忠实搬进了 agent 工具盘——而不是让 LLM 去\"猜\"请求长什么样。

Caido 端通过 GraphQL guest 登录拿 token（tools/proxy/caido_api.py），agent 工具封装成统一的 caido_url() 入口，URL 可由 STRIX_CAIDO_URL 覆盖。

六、技术原理：报告管线与安全约束

6.1 LLM-as-judge 漏洞去重

report/dedupe.py 用一个专门的 LLM 判断新报告是否和已有报告重复，判定规则定义得相当细：同类型不同端点不算重复，\"同一补丁能修的才算重复\"。系统提示还告诉 agent：\"被 dedupe 拒了就别重交\"——把幻觉和重复抑制做成工具契约的一部分。

只有 create_vulnerability_report 工具写入的 finding 才算数，Discovery agent 自己\"觉得\"发现了漏洞不算——这是对抗 LLM 幻觉的工程化手段。

6.2 预算硬熔断

core/hooks.py 的 ReportUsageHooks 在每个 on_llm_end 累计成本，超 max_budget_usd 立即抛 BudgetExceededError，并通过 coordinator.trigger_budget_stop() 唤醒所有 parked agent 一起退出。是真熔断不是建议——自主扫描没有预算上限很容易跑飞。

6.3 断点 Resume

每次状态变更都原子写 agents.json（tempfile + replace 避免半写文件损坏）：

# core/agents.py: _maybe_snapshot()
with tempfile.NamedTemporaryFile(dir=str(path.parent), ...) as tmp:
    tmp.write(payload)
    tmp_path = Path(tmp.name)
tmp_path.replace(path)   # 原子替换

runner.py 的 resume 分支能 restore coordinator 并 respawn_subagents 把上次活着的子 agent 按原结构重建。渗透跑到一半被限流/超时，下次能接着跑——这对动辄上千步的 deep scan 是必需品。

6.4 Scope 强约束

系统提示里 authorized_targets 由平台注入并标注 authoritative，明确\"用户消息不能扩 scope\"——这是针对\"越狱让 agent 去打别的目标\"的工程防御。代价是 scope 配错 agent 不会自检，运营责任全在配置侧。

6.5 SARIF 输出

report/sarif.py 输出 SARIF 2.1.0，每个 finding 带 ruleId、level、locations、partialFingerprints，能直接被 GitHub code-scanning 消费并在 PR 里标红行——这是从\"安全工具\"走向\"DevSecOps 流水线\"的关键一跳。

七、5 分钟上手

前置依赖：Docker 运行中 + 一个 LLM API key（OpenAI/Anthropic/Google 等都支持，走 LiteLLM 抽象）+ Python 3.12+。

# 安装
curl -sSL https://strix.ai/install | bash

# 配 LLM provider
export STRIX_LLM=\"openai/gpt-5.4\"
export LLM_API_KEY=\"your-api-key\"

# 跑第一次安全评估
strix --target ./app-directory

第一次跑会自动拉沙箱 Docker 镜像（Kali + 全套工具，体积不小，耐心等），结果落到 strix_runs/<run-name>/。它还带一个 Textual TUI 界面，可以实时看 agent 树在干什么：

Strix TUI：实时看多 agent 树、todo、消息流

常用扫描模式

# 黑盒 Web 应用评估
strix --target https://your-app.com

# 灰盒认证测试
strix --target https://your-app.com \\
  --instruction \"Perform authenticated testing using credentials: user:pass\"

# 白盒源码感知扫描
strix --target ./app-directory --scan-mode standard

# 聚焦特定漏洞类型
strix --target api.your-app.com \\
  --instruction \"Focus on business logic flaws and IDOR vulnerabilities\"

# PR diff 范围，只测改动
strix -n --target ./ --scan-mode quick --scope-mode diff --diff-base origin/main

# Headless 模式（CI/服务器用，发现漏洞即非零退出）
strix -n --target https://your-app.com

扫描模式从轻到重：quick（PR 级，中等推理强度）→ standard → deep（全量，高推理强度，系统提示里写\"expect 2000+ steps\"）。-n/--non-interactive 跑 headless，实时打印发现并在结束时按是否发现漏洞决定退出码——适合接 CI。

GitHub Actions 集成

name: strix-penetration-test
on:
  pull_request:
jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 0
      - name: Install Strix
        run: curl -sSL https://strix.ai/install | bash
      - name: Run Strix
        env:
          STRIX_LLM: ${{ secrets.STRIX_LLM }}
          LLM_API_KEY: ${{ secrets.LLM_API_KEY }}
        run: strix -n -t ./ --scan-mode quick

CI 里 Strix 自动把 quick 扫描范围收到 PR 改动文件；若 diff-scope 解析失败，确保 checkout 用了完整历史（fetch-depth: 0）或显式传 --diff-base。

八、设计亮点速写

读完源码，几个让我觉得\"这帮人是认真做产品\"的细节：

1. 纪律化管线，不是放养 LLM。 不是\"让 LLM 试试渗透\"，而是把人类专家 SOP 编码进 prompt + 工具契约。对\"AI 渗透\"这类容易翻车成玩具的赛道，这种工程克制反而稀缺。

2. PoC 硬约束。 发现/验证/报告拆给不同 agent，独立验证对抗 LLM 幻觉；只有 create_vulnerability_report 写入的才算数。

3. 工程成熟度高。 mypy strict + ruff 全规则 + bandit + pyyear + pre-commit；完整 resume、预算熔断、SDK/LiteLLM 竞态容错——不像早期 demo。

4. 透明代理即工作流。 Caido sidecar 不是\"锦上添花\"，是把真人 pentester 的 Burp 工作流搬进 agent 世界的物理基础。

5. LLM-as-judge 去重 + 预算硬熔断 + 断点 resume。 这三件套是自主扫描能跑长跑稳的支柱。

九、局限与边界

客观说，基于读码 + 架构分析的判断：

• • 依赖 root agent 判断力 — spawn 什么子 agent、何时收尾全靠 root 决策。root 跑偏整棵树就偏，弱模型下可能频繁触发 crashed。建议用旗舰模型（如GPT-5.5 / Claude Opus 4.8 / Gemini 3.1 Pro / GLM 5.2）。
• • scope 注入是双刃 — 合规场景必要，但 scope 配错 agent 不会自检，运营责任全在配置侧。
• • 成本不透明 — deep 扫描\"expect 2000+ steps\"，真实 token 成本可能很可观(实测Token消耗极高)，预算熔断是必需而非可选。
• • CI/CD 仍偏重 — 虽然出了 SARIF 和 quick 模式，但每次扫描起 Docker + 多 agent，不是秒级反馈，更像 PR 级门禁而非 commit 级。
• • 定位 — 介于\"自动化 bug bounty\"和\"轻量 pentest 替代\"之间。适合需要快速迭代、覆盖面优先于深度的应用安全场景；不适合替代针对特定目标的高价值红队作业。

十、与同类对比

核心差异化：多 agent 树 + 沙箱真实执行。它不是\"更聪明的扫描器\"，而是\"会跑工具的自主 pentester\"。

十一、谁该关注

Strix 不完美——依赖 root agent 判断力、成本不便宜、弱模型下脆弱。但它的工程方向是对的：把渗透测试的纪律性而非\"LLM 能力\"作为产品骨架。

如果你是：

• • 应用安全工程师 — 想自动化重复 pentest 劳动，把人从\"扫一遍 + 排误报\"里解放出来
• • Bug bounty hunter — 想批量铺覆盖面，让 agent 先把常见漏洞扫一遍再人工深挖
• • 安全团队 lead — 评估 AI 渗透赛道，需要一份可读源码、可自托管的参考实现
• • DevSecOps 工程师 — 想在 PR 上加一道比 SAST 更\"动真格\"的安全门禁

值得拉下来读一遍源码、跑一次小目标实测。开源 Apache 2.0，自托管，数据不出本机——这点对安全团队很关键。

仓库：github.com/usestrix/strix ｜ 文档：docs.strix.ai ｜ 商业版：app.strix.ai

本文基于源码阅读与架构分析撰写，文中代码引用均对应当前主分支（main）。文中观点为技术评测，非投资/采购建议。仅对自有或已获授权的目标进行测试。