AI News
中文资讯 掘金 AI Thu, 09 Jul 2026 正文 ok 1635 words

【GitHub】Strix 深度解析：开源 AI 渗透测试工具的架构、原理与实战

英文标题：【GitHub】Strix 深度解析：开源 AI 渗透测试工具的架构、原理与实战

一、引言：安全测试的「自动驾驶」时代 传统的渗透测试（Pentest）面临着几个无解的痛点：周期长（动辄数周）、成本高（资深白帽人才稀缺）、误报多（静态扫描工具缺乏上下文理解）、覆盖窄（人为测试难以穷
打开原文相关 2 · 机会 2
media3.2 KB media589 B media22.4 KB

中文

当 AI 学会了黑客技能，安全测试的范式正在被彻底改写。

一、引言：安全测试的「自动驾驶」时代

传统的渗透测试（Pentest）面临着几个无解的痛点：周期长 （动辄数周）、成本高 （资深白帽人才稀缺）、误报多 （静态扫描工具缺乏上下文理解）、覆盖窄 （人为测试难以穷举攻击面）。一款名为 Strix 的开源项目正试图用 AI 多智能体协作的方式，把渗透测试带入"自动驾驶"时代。

Strix 在 GitHub 开源不到一年，已经斩获大量关注。它的核心理念非常直白：用 AI 代理（Agent）模拟真实黑客的攻击行为 ——不止是静态分析代码，而是真正运行你的应用、发起攻击、验证漏洞、生成 PoC，最后还能给出修复方案。

核心理念：

  传统 SAST ──→ 发现可疑代码片段（高误报）
  传统 DAST ──→ 发现已知漏洞模式（无上下文）
  
  Strix  ──→ AI 代理动态运行 + 攻击验证 + 生成 PoC（低误报 + 有证据）

二、核心原理：AI 红队是如何工作的？

2.1 整体流程

Strix 的工作流程可以分为以下几个阶段：

                    ┌──────────────┐
                    │  用户输入目标  │ (代码库 / URL / GitHub仓库)
                    └──────┬───────┘
                           │
                           ▼
                  ┌────────────────┐
                  │   编排器(Orchestrator)  │
                  │   解析目标 + 创建任务    │
                  └───────┬────────┘
                          │
            ┌─────────────┼─────────────┐
            ▼             ▼             ▼
     ┌──────────┐  ┌──────────┐  ┌──────────┐
     │ 侦察Agent │  │ 利用Agent │  │ 后渗透Agent│
     │ 攻击面映射 │  │ 漏洞利用  │  │ 权限提升  │
     └─────┬────┘  └─────┬────┘  └─────┬────┘
           │             │             │
           └─────────────┼─────────────┘
                         │ 共享发现 + 协作
                         ▼
                  ┌────────────────┐
                  │   沙箱执行环境   │
                  │ (Docker容器)    │
                  │  ┌───────────┐  │
                  │  │ HTTP代理   │  │
                  │  │ 浏览器引擎  │  │
                  │  │ Shell环境  │  │
                  │  │ Python运行时│  │
                  │  │ 安全工具集  │  │
                  │  └───────────┘  │
                  └───────┬────────┘
                          │
                          ▼
                  ┌────────────────┐
                  │  结果输出       │
                  │  PoC + 报告 + 修复建议 │
                  └────────────────┘

2.2 Agent 之图（Graph of Agents）

Strix 最核心的创新在于其 多智能体协作架构 。它不是一个单体 AI 在跑全场，而是多个专业化的子代理各司其职：

  • Orchestrator Agent（编排器） ：解析用户目标，拆分任务，协调子代理
  • Recon Agent（侦察代理） ：攻击面映射、子域名枚举、信息收集
  • Exploit Agent（利用代理） ：针对具体漏洞类别的攻击验证
  • Post-Exploit Agent（后渗透代理） ：横向移动、权限提升、数据提取

每个 Agent 创建时可以加载最多 5 个专业技能包（Skills） ：

create_agent(
    task="Test authentication mechanisms in API",
    name="Auth Specialist",
    skills="authentication_jwt,business_logic"
)

Skills 会在 Agent 启动时被动态注入到 System Prompt 中，使每个子代理像该领域的专家一样思考 。

2.3 沙箱隔离机制

所有攻击操作都在 Docker 沙箱 中执行，沙箱预装了 15 个专业安全工具：

工具 用途 攻防阶段
jwt_tool JWT Token 攻击 认证绕过
interactsh-client OAST 带外测试 SSRF/XXE/RCE 验证
arjun HTTP 参数发现 IDOR 侦察
dirsearch 目录/文件枚举 信息收集
gospider Web 爬虫 攻击面映射
wafw00f WAF 检测 防御识别
retire JS 库漏洞扫描 依赖检查
vulnx CVE 漏洞检测 深度扫描
ncat 网络连接工具 RCE 验证
nuclei 漏洞模板匹配 自动化扫描
eslint/jshint JS 静态分析 代码审查
playwright 浏览器自动化 XSS/CSRF 测试

2.4 工具调用架构

Strix 的工具体系分为几个层次：

┌─────────────────────────────────────────────┐
│              LLM (GPT/Claude/Gemini)          │
│                                               │
│  解析任务 → 规划攻击路径 → 选择工具 → 分析结果  │
└───────────────────┬─────────────────────────┘
                    │ Tool Call
                    ▼
┌─────────────────────────────────────────────┐
│           Tool Interface Layer                │
│                                               │
│  ┌──────────┐ ┌──────────┐ ┌──────────────┐ │
│  │ HTTP代理  │ │ 浏览器   │ │ Shell执行     │ │
│  │ (Caido)  │ │(Playwright)│ │ (Bash)       │ │
│  └──────────┘ └──────────┘ └──────────────┘ │
│  ┌──────────┐ ┌──────────┐ ┌──────────────┐ │
│  │Python沙箱 │ │ 侦察工具  │ │ 报告工具      │ │
│  │ (uv)     │ │ (nuclei等)│ │ (CVSS评分)   │ │
│  └──────────┘ └──────────┘ └──────────────┘ │
└───────────────────┬─────────────────────────┘
                    │
                    ▼
┌─────────────────────────────────────────────┐
│           Docker Sandbox Container           │
│         (隔离网络 + 读写限制 + 资源配额)        │
└─────────────────────────────────────────────┘

三、架构设计：深入源码组织

3.1 技术栈全貌

Strix 基于 Python 3.12+ 构建，核心依赖如下：

层级 技术选型 作用
AI 框架 openai-agents[litellm] v0.14.6 Agent 编排 + 100+ LLM 提供商适配
数据验证 pydantic v2.11+ 配置/结果/状态模型
TUI textual v6.0+ 终端交互界面
容器 docker-py v7.1+ 沙箱生命周期管理
HTTP 代理 caido-sdk-client v0.2+ 请求拦截与分析
浏览器 playwright 客户端攻击自动化
漏洞评分 cvss v3.2 CVSS 标准化评分
代码质量 ruff + mypy + pyright + bandit 三重类型检查 + 安全 Lint

3.2 项目目录结构

strix/
├── strix/                      
│   ├── agents/                 
│   │   ├── factory.py          
│   │   └── memory/             
│   ├── config/                 
│   │   └── models.py           
│   ├── core/                   
│   │   └── runner.py           
│   ├── interface/              
│   │   ├── main.py             
│   │   ├── cli.py              
│   │   ├── tui/                
│   │   └── utils.py            
│   ├── runtime/                
│   │   ├── docker_client.py    
│   │   └── backends.py         
│   ├── tools/                  
│   │   ├── agents_graph/       
│   │   ├── finish/             
│   │   ├── notes/              
│   │   ├── proxy/              
│   │   ├── reporting/          
│   │   ├── thinking/           
│   │   ├── todo/               
│   │   └── web_search/         
│   ├── skills/                 
│   │   ├── vulnerabilities/    
│   │   ├── frameworks/         
│   │   ├── technologies/       
│   │   ├── protocols/          
│   │   ├── tooling/            
│   │   ├── cloud/              
│   │   └── reconnaissance/     
│   └── report/                 
│       ├── state.py            
│       └── usage.py            
├── containers/                 
├── docs/                       
├── scripts/                    
├── pyproject.toml              
└── Makefile

3.3 会话持久化与恢复

Strix 使用 SQLite 存储 Agent 的会话历史，支持断点续扫：

strix_runs/
└── <scan_id>/
    ├── session.db       
    ├── findings/        
    └── report.json

使用相同的 scan_id 重新调用即可从上次中断处恢复，无需手动管理状态。这对于长时间运行的大型目标扫描尤为重要。

3.4 遥测与可观测性

经过 2026 年 4 月的架构重构，Strix 移除了 OTEL/Traceloop 依赖，转而使用 OpenAI Agents SDK 原生的 agents.tracing 管道：

  • Agent 树追踪 ：通过 tracer.agents 记录每个 Agent 的 id/name/parent_id/status
  • JSONL 输出 ：遥测数据以 JSONL 格式输出，便于后续分析
  • 可配置开关 ：is_telemetry_enabled 控制是否输出监控数据

四、核心技术：Agent 编排与 Skills 系统

4.1 Agent 编排流程

class StrixOrchestrator:
    """主编排器：解析目标 → 创建子代理 → 协调执行 → 汇总结果"""
    
    def run(self, target: str, instruction: str | None = None):
        
        target_type = self._classify_target(target)
        
        
        if scan_mode == "quick":
            
            scope = self._get_diff_scope(diff_base)
        else:
            
            scope = "full"
        
        
        recon_agent = create_agent(
            task=f"Map attack surface of {target}",
            name="Recon Specialist",
            skills=["reconnaissance_web", "source_aware_whitebox"]
        )
        
        
        exploit_agents = self._create_exploit_agents(recon_results)
        
        
        findings = self._coordinate_agents(exploit_agents)
        
        
        return self._generate_report(findings)

4.2 Skills 知识包系统

Skills 是 Strix 的知识灵魂——每个 Skill 是一个 Markdown 文件，包含特定领域的深度技术知识：

Skill 目录结构：

strix/skills/
├── vulnerabilities/           
│   ├── authentication_jwt.md  
│   ├── business_logic.md      
│   └── race_conditions.md     
├── frameworks/                
│   ├── django.md
│   ├── express.md
│   ├── fastapi.md
│   └── nextjs.md
├── technologies/              
│   ├── supabase.md
│   ├── firebase.md
│   └── auth0.md
├── protocols/                 
│   ├── graphql.md
│   ├── websocket.md
│   └── oauth.md
├── cloud/                     
│   ├── aws.md
│   ├── azure.md
│   └── kubernetes.md
└── custom/                    
    ├── source_aware_whitebox.md   
    └── source_aware_sast.md

Skill 文件格式：

---
name: jwt_authentication_attacks
description: Advanced JWT attack techniques
---

# JWT Authentication Attacks

## Advanced Techniques
- Algorithm confusion (RS256 → HS256)
- Key ID (kid) injection
- JWK header injection
- ...

## Practical Examples
\`\`\`bash
# Algorithm confusion attack
jwt_tool <token> -X a
\`\`\`

## Validation Methods
- Check if server accepts "none" algorithm
- Test signature verification bypass
- ...

## Edge Cases
- Some libraries ignore `alg` when `jwk` is present
- ...

Agent 启动时，Skills 内容会被动态拼接到 System Prompt 中，使 AI 获得该领域的专家级知识。

4.3 LLM 后端适配

Strix 通过 LiteLLM 实现了一套统一的 LLM 后端抽象：

                    ┌─────────────────────┐
                    │   Strix Agent        │
                    │   统一的工具调用接口   │
                    └─────────┬───────────┘
                              │
                    ┌─────────▼───────────┐
                    │     LiteLLM 适配层    │
                    │   provider/model-id  │
                    └─────────┬───────────┘
                              │
        ┌──────────┬──────────┼──────────┬──────────┐
        ▼          ▼          ▼          ▼          ▼
    ┌───────┐ ┌───────┐ ┌────────┐ ┌────────┐ ┌────────┐
    │OpenAI │ │Anthropic│ │Google │ │AWS     │ │Ollama  │
    │GPT-5.4│ │Claude  │ │Gemini  │ │Bedrock │ │本地模型 │
    └───────┘ └───────┘ └────────┘ └────────┘ └────────┘

后端工厂采用懒加载 模式——只有在实际使用时才导入特定后端的依赖。例如 vertex 后端的 google-auth 和 bedrock 后端的 boto3 都作为可选依赖：

pipx install "strix-agent[vertex]"


pipx install "strix-agent[bedrock]"

五、漏洞覆盖全景

Strix 覆盖了 OWASP Top 10 及更广泛的漏洞类别，并按照攻击面进行了系统化分类：

5.1 服务端漏洞

类别 具体漏洞 验证方式
注入攻击 SQL注入、NoSQL注入、命令注入、SSTI 注入 payload → 观察响应/带外回连
SSRF 服务端请求伪造 interactsh-client 带外验证
XXE XML 外部实体注入 文件读取 + 带外验证
反序列化 Java/Python/PHP 反序列化 反序列化 Gadget Chain 利用
RCE 远程代码执行 Shell 执行 + 反向连接验证

5.2 客户端漏洞

类别 具体漏洞 验证方式
XSS 存储型/反射型/DOM型 Playwright 浏览器自动化注入
原型污染 JavaScript Prototype Pollution 运行时对象检查
CSRF 跨站请求伪造 自动化表单提交验证

5.3 认证与授权

类别 具体漏洞 验证方式
IDOR 不安全的直接对象引用 参数枚举 + 权限对比
JWT攻击 算法混淆/kid注入/JWK注入 jwt_tool 自动化测试
会话固定 Session Fixation Cookie 操作 + 状态验证
OAuth绕过 Redirect URI 操纵/state 缺失 协议流重放测试

5.4 业务逻辑

类别 具体漏洞 验证方式
竞态条件 Race Condition 并发请求 + 状态不一致检测
支付操纵 价格参数篡改/数量溢出 负值/零值注入
工作流绕过 跳过必须步骤 状态机遍历测试

六、实战指南

6.1 环境搭建

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


export STRIX_LLM="anthropic/claude-sonnet-4-6"
export LLM_API_KEY="sk-..."


export STRIX_LLM="ollama/llama4"
export LLM_API_BASE="http://localhost:11434"


export PERPLEXITY_API_KEY="pplx-..."

6.2 常见使用场景

场景一：本地代码库安全审计（白盒）

strix --target ./my-web-app --scan-mode standard

场景二：线上应用黑盒测试

strix --target https://api.myapp.com --scan-mode standard

场景三：PR 级别的快速安全审查（CI/CD）

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

场景四：认证后灰盒测试

strix --target https://app.example.com \
  --instruction "Perform authenticated testing. Login credentials:
  Email: test@example.com
  Password: TestPass123!
  Focus on privilege escalation and IDOR after authentication."

场景五：多目标联合测试

strix -t https://github.com/org/app -t https://app.example.com

场景六：无头模式（自动化 CI）

strix -n --target https://api.example.com

6.3 扫描模式对比

模式 适用场景 推理强度 耗时
quick PR review / CI medium 分钟级
standard 完整安全审计 high 小时级

6.4 结果解读

扫描结果保存在 strix_runs/<run-name>/ 目录下：

strix_runs/
└── 2026-07-09_myapp_scan/
    ├── session.db          
    ├── findings/
    │   ├── finding_001.json  
    │   ├── finding_002.json  
    │   └── ...
    └── report.md

每个 Finding 包含：

  • CVSS 3.1 评分 + 向量
  • OWASP 分类
  • 可复现的 PoC （curl/python 脚本）
  • 代码位置 （精确到文件和行号）
  • 修复建议 （代码级修复方案）

七、踩坑点与注意事项

7.1 CI/CD 集成中的 fetch-depth

问题 ：在 GitHub Actions 中使用 strix --scan-mode quick 时，如果 checkout 没有设置 fetch-depth: 0，Strix 无法获取完整的 git 历史来计算 diff 范围。

解决 ：

- uses: actions/checkout@v6
  with:
    fetch-depth: 0

或者显式指定基准分支：

strix -n -t ./ --scan-mode quick --scope-mode diff --diff-base origin/main

7.2 LLM Token 消耗

问题 ：一次完整的 standard 模式扫描可能消耗数十万到数百万 token，尤其是对大中型项目。

建议 ：

  • 在 CI/CD 中使用 quick 模式（低推理强度 + diff 范围限定）
  • 对完整的代码库审计使用 standard 模式，但要做好心理准备和预算
  • 关注 strix_runs/<id>/ 中的 usage.json 了解实际消耗

7.3 Docker 沙箱权限

问题 ：部分攻击工具（如端口扫描、流量拦截）可能需要 Docker 的特定网络权限。

建议 ：

  • 确保 Docker 守护进程运行正常
  • 检查 Docker 网络配置（特别是使用了代理或 VPN 的环境）
  • 首次运行会自动拉取沙箱镜像，网络不好的环境建议提前 docker pull

7.4 多次扫描的状态管理

问题 ：使用相同 scan_id 的多次扫描会追加到同一个 SQLite 会话文件，可能导致上下文膨胀。

建议 ：

  • 不同目标的扫描使用不同的 scan_id
  • 定期清理 strix_runs/ 目录
  • 断点续扫是特性不是 Bug——但不要滥用

7.5 本地模型的性能局限

问题 ：使用 Ollama/LMStudio 运行本地模型时，Strix 的工具调用能力会显著下降。

建议 ：

  • Quick 扫描可尝试本地模型
  • Standard 扫描强烈建议使用云端高性能模型 （GPT-5.4 / Claude Sonnet 4.6 / Gemini 3 Pro）
  • 本地模型适合用于理解 Strix 的工作原理和学习，不适合生产级安全审计

7.6 超时与长时间运行

问题 ：大项目的 Standard 扫描可能需要数小时，TUI 模式下的长时间运行可能触发超时。

建议 ：

  • 对于长时间扫描，优先使用 -n 无头模式
  • 使用 tmux / screen 保持会话
  • 利用断点续扫机制分段执行

八、效果对比：Strix vs 传统工具

8.1 与 SAST 工具对比

维度 传统 SAST (Semgrep/CodeQL) Strix
分析方式 静态语法树/数据流分析 AI 语义理解 + 动态验证
误报率 高（缺乏运行时上下文） 低（实际执行验证）
PoC 生成 ❌ 不支持 ✅ 自动生成可执行 PoC
修复建议 通用建议 代码级具体修复
扫描速度 快（秒~分钟） 较慢（分钟~小时）
覆盖深度 模式匹配 理解业务逻辑

8.2 与 DAST 工具对比

维度 传统 DAST (Burp/ZAP) Strix
配置复杂度 高（需要手动配置代理/爬虫） 低（一句话命令）
上下文理解 无（基于请求/响应模式） 有（AI 理解应用逻辑）
攻击链 手动构建 AI 自动串联漏洞
适配性 需要手动调整 AI 自适应

8.3 与人工渗透测试对比

维度 人工渗透测试 Strix
周期 2~4 周 数小时
成本 5K 5K~5K 50K+ API 费用（10 10~10 100）
覆盖率 依赖测试人员经验 系统化枚举 + AI 创造力
可复现性 低（依赖人的状态） 高（Agent 可重复执行）
深度 创意性攻击更强 系统性覆盖更全

结论 ：Strix 不是要取代人工渗透测试，而是提供了 自动化第一道防线 。理想的使用方式是将 Strix 集成到 CI/CD 流水线中做持续的安全扫描，而把人工渗透测试留给更复杂、需要创造性的攻击场景。

九、社区与生态

9.1 项目健康度

  • 许可证 ：Apache 2.0（商业友好）
  • Python 版本要求 ：3.12+（充分利用新语法特性）
  • 代码质量 ：mypy strict + pyright strict + ruff 全规则集 + bandit
  • 包发布 ：PyPI 上以 strix-agent 发布
  • 版本迭代 ：从 2025 年 8 月 Alpha 开源至今，已迭代至 v1.0.4

9.2 开发者体验

git clone https://github.com/usestrix/strix.git
cd strix
make setup-dev          
uv run strix --target ./your-app


make check-all

项目的 pyproject.toml 包含了极为严格的类型检查配置，体现了项目维护者对代码质量的追求。

9.3 Skills 贡献

Strix 的 Skills 系统设计为社区可扩展的：

十、总结与展望

Strix 的颠覆性价值

  1. 范式迁移 ：从"模式匹配"到"AI Agent 自主决策"，安全测试的智能水平发生质变
  2. 降本增效 ：将渗透测试成本从万美元级降到 API 费用级，周期从周降到小时
  3. CI/CD 原生 ：开箱即用的流水线集成，左移安全到 PR 评审阶段
  4. 可验证性 ：每个发现都附带 PoC，告别"狼来了"式的虚假告警

当前局限

  1. 强依赖 LLM 质量 ：工具调用能力、推理深度高度依赖底层模型
  2. Token 消耗可观 ：完整扫描的 API 费用不容忽视
  3. 本地模型支持有限 ：Ollama 等本地模型在复杂工具编排场景下表现不佳
  4. 社区尚在早期 ：Skills 生态还不够丰富，测试套件在 2026 年 4 月被移除

展望

随着 Codex/GPT-5/Claude 等模型的持续进化，AI Agent 的安全测试能力将以指数级增长。Strix 的架构设计——多 Agent 协作 + Skills 知识注入 + 沙箱隔离——为这个趋势提供了坚实的基础。可以预见，未来 2~3 年内，AI 驱动的自动化渗透测试将成为 DevSecOps 流水线的标配组件。

项目地址 ：github.com/usestrix/st… 官方文档 ：docs.strix.ai 在线平台 ：app.strix.ai（商业版，支持持续渗透测试与一键自动修复）

⚠️ 伦理声明 ：Strix 是一款合法安全测试工具，仅可用于测试您拥有或已获授权的应用程序。滥用此工具进行未授权渗透测试属于违法行为。请负责任地使用。

English / 原文

当 AI 学会了黑客技能，安全测试的范式正在被彻底改写。

一、引言：安全测试的「自动驾驶」时代

传统的渗透测试（Pentest）面临着几个无解的痛点：周期长 （动辄数周）、成本高 （资深白帽人才稀缺）、误报多 （静态扫描工具缺乏上下文理解）、覆盖窄 （人为测试难以穷举攻击面）。一款名为 Strix 的开源项目正试图用 AI 多智能体协作的方式，把渗透测试带入"自动驾驶"时代。

Strix 在 GitHub 开源不到一年，已经斩获大量关注。它的核心理念非常直白：用 AI 代理（Agent）模拟真实黑客的攻击行为 ——不止是静态分析代码，而是真正运行你的应用、发起攻击、验证漏洞、生成 PoC，最后还能给出修复方案。

核心理念：

  传统 SAST ──→ 发现可疑代码片段（高误报）
  传统 DAST ──→ 发现已知漏洞模式（无上下文）
  
  Strix  ──→ AI 代理动态运行 + 攻击验证 + 生成 PoC（低误报 + 有证据）

二、核心原理：AI 红队是如何工作的？

2.1 整体流程

Strix 的工作流程可以分为以下几个阶段：

                    ┌──────────────┐
                    │  用户输入目标  │ (代码库 / URL / GitHub仓库)
                    └──────┬───────┘
                           │
                           ▼
                  ┌────────────────┐
                  │   编排器(Orchestrator)  │
                  │   解析目标 + 创建任务    │
                  └───────┬────────┘
                          │
            ┌─────────────┼─────────────┐
            ▼             ▼             ▼
     ┌──────────┐  ┌──────────┐  ┌──────────┐
     │ 侦察Agent │  │ 利用Agent │  │ 后渗透Agent│
     │ 攻击面映射 │  │ 漏洞利用  │  │ 权限提升  │
     └─────┬────┘  └─────┬────┘  └─────┬────┘
           │             │             │
           └─────────────┼─────────────┘
                         │ 共享发现 + 协作
                         ▼
                  ┌────────────────┐
                  │   沙箱执行环境   │
                  │ (Docker容器)    │
                  │  ┌───────────┐  │
                  │  │ HTTP代理   │  │
                  │  │ 浏览器引擎  │  │
                  │  │ Shell环境  │  │
                  │  │ Python运行时│  │
                  │  │ 安全工具集  │  │
                  │  └───────────┘  │
                  └───────┬────────┘
                          │
                          ▼
                  ┌────────────────┐
                  │  结果输出       │
                  │  PoC + 报告 + 修复建议 │
                  └────────────────┘

2.2 Agent 之图（Graph of Agents）

Strix 最核心的创新在于其 多智能体协作架构 。它不是一个单体 AI 在跑全场，而是多个专业化的子代理各司其职：

  • Orchestrator Agent（编排器） ：解析用户目标，拆分任务，协调子代理
  • Recon Agent（侦察代理） ：攻击面映射、子域名枚举、信息收集
  • Exploit Agent（利用代理） ：针对具体漏洞类别的攻击验证
  • Post-Exploit Agent（后渗透代理） ：横向移动、权限提升、数据提取

每个 Agent 创建时可以加载最多 5 个专业技能包（Skills） ：

create_agent(
    task="Test authentication mechanisms in API",
    name="Auth Specialist",
    skills="authentication_jwt,business_logic"
)

Skills 会在 Agent 启动时被动态注入到 System Prompt 中，使每个子代理像该领域的专家一样思考 。

2.3 沙箱隔离机制

所有攻击操作都在 Docker 沙箱 中执行，沙箱预装了 15 个专业安全工具：

工具 用途 攻防阶段
jwt_tool JWT Token 攻击 认证绕过
interactsh-client OAST 带外测试 SSRF/XXE/RCE 验证
arjun HTTP 参数发现 IDOR 侦察
dirsearch 目录/文件枚举 信息收集
gospider Web 爬虫 攻击面映射
wafw00f WAF 检测 防御识别
retire JS 库漏洞扫描 依赖检查
vulnx CVE 漏洞检测 深度扫描
ncat 网络连接工具 RCE 验证
nuclei 漏洞模板匹配 自动化扫描
eslint/jshint JS 静态分析 代码审查
playwright 浏览器自动化 XSS/CSRF 测试

2.4 工具调用架构

Strix 的工具体系分为几个层次：

┌─────────────────────────────────────────────┐
│              LLM (GPT/Claude/Gemini)          │
│                                               │
│  解析任务 → 规划攻击路径 → 选择工具 → 分析结果  │
└───────────────────┬─────────────────────────┘
                    │ Tool Call
                    ▼
┌─────────────────────────────────────────────┐
│           Tool Interface Layer                │
│                                               │
│  ┌──────────┐ ┌──────────┐ ┌──────────────┐ │
│  │ HTTP代理  │ │ 浏览器   │ │ Shell执行     │ │
│  │ (Caido)  │ │(Playwright)│ │ (Bash)       │ │
│  └──────────┘ └──────────┘ └──────────────┘ │
│  ┌──────────┐ ┌──────────┐ ┌──────────────┐ │
│  │Python沙箱 │ │ 侦察工具  │ │ 报告工具      │ │
│  │ (uv)     │ │ (nuclei等)│ │ (CVSS评分)   │ │
│  └──────────┘ └──────────┘ └──────────────┘ │
└───────────────────┬─────────────────────────┘
                    │
                    ▼
┌─────────────────────────────────────────────┐
│           Docker Sandbox Container           │
│         (隔离网络 + 读写限制 + 资源配额)        │
└─────────────────────────────────────────────┘

三、架构设计：深入源码组织

3.1 技术栈全貌

Strix 基于 Python 3.12+ 构建，核心依赖如下：

层级 技术选型 作用
AI 框架 openai-agents[litellm] v0.14.6 Agent 编排 + 100+ LLM 提供商适配
数据验证 pydantic v2.11+ 配置/结果/状态模型
TUI textual v6.0+ 终端交互界面
容器 docker-py v7.1+ 沙箱生命周期管理
HTTP 代理 caido-sdk-client v0.2+ 请求拦截与分析
浏览器 playwright 客户端攻击自动化
漏洞评分 cvss v3.2 CVSS 标准化评分
代码质量 ruff + mypy + pyright + bandit 三重类型检查 + 安全 Lint

3.2 项目目录结构

strix/
├── strix/                      
│   ├── agents/                 
│   │   ├── factory.py          
│   │   └── memory/             
│   ├── config/                 
│   │   └── models.py           
│   ├── core/                   
│   │   └── runner.py           
│   ├── interface/              
│   │   ├── main.py             
│   │   ├── cli.py              
│   │   ├── tui/                
│   │   └── utils.py            
│   ├── runtime/                
│   │   ├── docker_client.py    
│   │   └── backends.py         
│   ├── tools/                  
│   │   ├── agents_graph/       
│   │   ├── finish/             
│   │   ├── notes/              
│   │   ├── proxy/              
│   │   ├── reporting/          
│   │   ├── thinking/           
│   │   ├── todo/               
│   │   └── web_search/         
│   ├── skills/                 
│   │   ├── vulnerabilities/    
│   │   ├── frameworks/         
│   │   ├── technologies/       
│   │   ├── protocols/          
│   │   ├── tooling/            
│   │   ├── cloud/              
│   │   └── reconnaissance/     
│   └── report/                 
│       ├── state.py            
│       └── usage.py            
├── containers/                 
├── docs/                       
├── scripts/                    
├── pyproject.toml              
└── Makefile

3.3 会话持久化与恢复

Strix 使用 SQLite 存储 Agent 的会话历史，支持断点续扫：

strix_runs/
└── <scan_id>/
    ├── session.db       
    ├── findings/        
    └── report.json

使用相同的 scan_id 重新调用即可从上次中断处恢复，无需手动管理状态。这对于长时间运行的大型目标扫描尤为重要。

3.4 遥测与可观测性

经过 2026 年 4 月的架构重构，Strix 移除了 OTEL/Traceloop 依赖，转而使用 OpenAI Agents SDK 原生的 agents.tracing 管道：

  • Agent 树追踪 ：通过 tracer.agents 记录每个 Agent 的 id/name/parent_id/status
  • JSONL 输出 ：遥测数据以 JSONL 格式输出，便于后续分析
  • 可配置开关 ：is_telemetry_enabled 控制是否输出监控数据

四、核心技术：Agent 编排与 Skills 系统

4.1 Agent 编排流程

class StrixOrchestrator:
    """主编排器：解析目标 → 创建子代理 → 协调执行 → 汇总结果"""
    
    def run(self, target: str, instruction: str | None = None):
        
        target_type = self._classify_target(target)
        
        
        if scan_mode == "quick":
            
            scope = self._get_diff_scope(diff_base)
        else:
            
            scope = "full"
        
        
        recon_agent = create_agent(
            task=f"Map attack surface of {target}",
            name="Recon Specialist",
            skills=["reconnaissance_web", "source_aware_whitebox"]
        )
        
        
        exploit_agents = self._create_exploit_agents(recon_results)
        
        
        findings = self._coordinate_agents(exploit_agents)
        
        
        return self._generate_report(findings)

4.2 Skills 知识包系统

Skills 是 Strix 的知识灵魂——每个 Skill 是一个 Markdown 文件，包含特定领域的深度技术知识：

Skill 目录结构：

strix/skills/
├── vulnerabilities/           
│   ├── authentication_jwt.md  
│   ├── business_logic.md      
│   └── race_conditions.md     
├── frameworks/                
│   ├── django.md
│   ├── express.md
│   ├── fastapi.md
│   └── nextjs.md
├── technologies/              
│   ├── supabase.md
│   ├── firebase.md
│   └── auth0.md
├── protocols/                 
│   ├── graphql.md
│   ├── websocket.md
│   └── oauth.md
├── cloud/                     
│   ├── aws.md
│   ├── azure.md
│   └── kubernetes.md
└── custom/                    
    ├── source_aware_whitebox.md   
    └── source_aware_sast.md

Skill 文件格式：

---
name: jwt_authentication_attacks
description: Advanced JWT attack techniques
---

# JWT Authentication Attacks

## Advanced Techniques
- Algorithm confusion (RS256 → HS256)
- Key ID (kid) injection
- JWK header injection
- ...

## Practical Examples
\`\`\`bash
# Algorithm confusion attack
jwt_tool <token> -X a
\`\`\`

## Validation Methods
- Check if server accepts "none" algorithm
- Test signature verification bypass
- ...

## Edge Cases
- Some libraries ignore `alg` when `jwk` is present
- ...

Agent 启动时，Skills 内容会被动态拼接到 System Prompt 中，使 AI 获得该领域的专家级知识。

4.3 LLM 后端适配

Strix 通过 LiteLLM 实现了一套统一的 LLM 后端抽象：

                    ┌─────────────────────┐
                    │   Strix Agent        │
                    │   统一的工具调用接口   │
                    └─────────┬───────────┘
                              │
                    ┌─────────▼───────────┐
                    │     LiteLLM 适配层    │
                    │   provider/model-id  │
                    └─────────┬───────────┘
                              │
        ┌──────────┬──────────┼──────────┬──────────┐
        ▼          ▼          ▼          ▼          ▼
    ┌───────┐ ┌───────┐ ┌────────┐ ┌────────┐ ┌────────┐
    │OpenAI │ │Anthropic│ │Google │ │AWS     │ │Ollama  │
    │GPT-5.4│ │Claude  │ │Gemini  │ │Bedrock │ │本地模型 │
    └───────┘ └───────┘ └────────┘ └────────┘ └────────┘

后端工厂采用懒加载 模式——只有在实际使用时才导入特定后端的依赖。例如 vertex 后端的 google-auth 和 bedrock 后端的 boto3 都作为可选依赖：

pipx install "strix-agent[vertex]"


pipx install "strix-agent[bedrock]"

五、漏洞覆盖全景

Strix 覆盖了 OWASP Top 10 及更广泛的漏洞类别，并按照攻击面进行了系统化分类：

5.1 服务端漏洞

类别 具体漏洞 验证方式
注入攻击 SQL注入、NoSQL注入、命令注入、SSTI 注入 payload → 观察响应/带外回连
SSRF 服务端请求伪造 interactsh-client 带外验证
XXE XML 外部实体注入 文件读取 + 带外验证
反序列化 Java/Python/PHP 反序列化 反序列化 Gadget Chain 利用
RCE 远程代码执行 Shell 执行 + 反向连接验证

5.2 客户端漏洞

类别 具体漏洞 验证方式
XSS 存储型/反射型/DOM型 Playwright 浏览器自动化注入
原型污染 JavaScript Prototype Pollution 运行时对象检查
CSRF 跨站请求伪造 自动化表单提交验证

5.3 认证与授权

类别 具体漏洞 验证方式
IDOR 不安全的直接对象引用 参数枚举 + 权限对比
JWT攻击 算法混淆/kid注入/JWK注入 jwt_tool 自动化测试
会话固定 Session Fixation Cookie 操作 + 状态验证
OAuth绕过 Redirect URI 操纵/state 缺失 协议流重放测试

5.4 业务逻辑

类别 具体漏洞 验证方式
竞态条件 Race Condition 并发请求 + 状态不一致检测
支付操纵 价格参数篡改/数量溢出 负值/零值注入
工作流绕过 跳过必须步骤 状态机遍历测试

六、实战指南

6.1 环境搭建

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


export STRIX_LLM="anthropic/claude-sonnet-4-6"
export LLM_API_KEY="sk-..."


export STRIX_LLM="ollama/llama4"
export LLM_API_BASE="http://localhost:11434"


export PERPLEXITY_API_KEY="pplx-..."

6.2 常见使用场景

场景一：本地代码库安全审计（白盒）

strix --target ./my-web-app --scan-mode standard

场景二：线上应用黑盒测试

strix --target https://api.myapp.com --scan-mode standard

场景三：PR 级别的快速安全审查（CI/CD）

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

场景四：认证后灰盒测试

strix --target https://app.example.com \
  --instruction "Perform authenticated testing. Login credentials:
  Email: test@example.com
  Password: TestPass123!
  Focus on privilege escalation and IDOR after authentication."

场景五：多目标联合测试

strix -t https://github.com/org/app -t https://app.example.com

场景六：无头模式（自动化 CI）

strix -n --target https://api.example.com

6.3 扫描模式对比

模式 适用场景 推理强度 耗时
quick PR review / CI medium 分钟级
standard 完整安全审计 high 小时级

6.4 结果解读

扫描结果保存在 strix_runs/<run-name>/ 目录下：

strix_runs/
└── 2026-07-09_myapp_scan/
    ├── session.db          
    ├── findings/
    │   ├── finding_001.json  
    │   ├── finding_002.json  
    │   └── ...
    └── report.md

每个 Finding 包含：

  • CVSS 3.1 评分 + 向量
  • OWASP 分类
  • 可复现的 PoC （curl/python 脚本）
  • 代码位置 （精确到文件和行号）
  • 修复建议 （代码级修复方案）

七、踩坑点与注意事项

7.1 CI/CD 集成中的 fetch-depth

问题 ：在 GitHub Actions 中使用 strix --scan-mode quick 时，如果 checkout 没有设置 fetch-depth: 0，Strix 无法获取完整的 git 历史来计算 diff 范围。

解决 ：

- uses: actions/checkout@v6
  with:
    fetch-depth: 0

或者显式指定基准分支：

strix -n -t ./ --scan-mode quick --scope-mode diff --diff-base origin/main

7.2 LLM Token 消耗

问题 ：一次完整的 standard 模式扫描可能消耗数十万到数百万 token，尤其是对大中型项目。

建议 ：

  • 在 CI/CD 中使用 quick 模式（低推理强度 + diff 范围限定）
  • 对完整的代码库审计使用 standard 模式，但要做好心理准备和预算
  • 关注 strix_runs/<id>/ 中的 usage.json 了解实际消耗

7.3 Docker 沙箱权限

问题 ：部分攻击工具（如端口扫描、流量拦截）可能需要 Docker 的特定网络权限。

建议 ：

  • 确保 Docker 守护进程运行正常
  • 检查 Docker 网络配置（特别是使用了代理或 VPN 的环境）
  • 首次运行会自动拉取沙箱镜像，网络不好的环境建议提前 docker pull

7.4 多次扫描的状态管理

问题 ：使用相同 scan_id 的多次扫描会追加到同一个 SQLite 会话文件，可能导致上下文膨胀。

建议 ：

  • 不同目标的扫描使用不同的 scan_id
  • 定期清理 strix_runs/ 目录
  • 断点续扫是特性不是 Bug——但不要滥用

7.5 本地模型的性能局限

问题 ：使用 Ollama/LMStudio 运行本地模型时，Strix 的工具调用能力会显著下降。

建议 ：

  • Quick 扫描可尝试本地模型
  • Standard 扫描强烈建议使用云端高性能模型 （GPT-5.4 / Claude Sonnet 4.6 / Gemini 3 Pro）
  • 本地模型适合用于理解 Strix 的工作原理和学习，不适合生产级安全审计

7.6 超时与长时间运行

问题 ：大项目的 Standard 扫描可能需要数小时，TUI 模式下的长时间运行可能触发超时。

建议 ：

  • 对于长时间扫描，优先使用 -n 无头模式
  • 使用 tmux / screen 保持会话
  • 利用断点续扫机制分段执行

八、效果对比：Strix vs 传统工具

8.1 与 SAST 工具对比

维度 传统 SAST (Semgrep/CodeQL) Strix
分析方式 静态语法树/数据流分析 AI 语义理解 + 动态验证
误报率 高（缺乏运行时上下文） 低（实际执行验证）
PoC 生成 ❌ 不支持 ✅ 自动生成可执行 PoC
修复建议 通用建议 代码级具体修复
扫描速度 快（秒~分钟） 较慢（分钟~小时）
覆盖深度 模式匹配 理解业务逻辑

8.2 与 DAST 工具对比

维度 传统 DAST (Burp/ZAP) Strix
配置复杂度 高（需要手动配置代理/爬虫） 低（一句话命令）
上下文理解 无（基于请求/响应模式） 有（AI 理解应用逻辑）
攻击链 手动构建 AI 自动串联漏洞
适配性 需要手动调整 AI 自适应

8.3 与人工渗透测试对比

维度 人工渗透测试 Strix
周期 2~4 周 数小时
成本 5K 5K~5K 50K+ API 费用（10 10~10 100）
覆盖率 依赖测试人员经验 系统化枚举 + AI 创造力
可复现性 低（依赖人的状态） 高（Agent 可重复执行）
深度 创意性攻击更强 系统性覆盖更全

结论 ：Strix 不是要取代人工渗透测试，而是提供了 自动化第一道防线 。理想的使用方式是将 Strix 集成到 CI/CD 流水线中做持续的安全扫描，而把人工渗透测试留给更复杂、需要创造性的攻击场景。

九、社区与生态

9.1 项目健康度

  • 许可证 ：Apache 2.0（商业友好）
  • Python 版本要求 ：3.12+（充分利用新语法特性）
  • 代码质量 ：mypy strict + pyright strict + ruff 全规则集 + bandit
  • 包发布 ：PyPI 上以 strix-agent 发布
  • 版本迭代 ：从 2025 年 8 月 Alpha 开源至今，已迭代至 v1.0.4

9.2 开发者体验

git clone https://github.com/usestrix/strix.git
cd strix
make setup-dev          
uv run strix --target ./your-app


make check-all

项目的 pyproject.toml 包含了极为严格的类型检查配置，体现了项目维护者对代码质量的追求。

9.3 Skills 贡献

Strix 的 Skills 系统设计为社区可扩展的：

十、总结与展望

Strix 的颠覆性价值

  1. 范式迁移 ：从"模式匹配"到"AI Agent 自主决策"，安全测试的智能水平发生质变
  2. 降本增效 ：将渗透测试成本从万美元级降到 API 费用级，周期从周降到小时
  3. CI/CD 原生 ：开箱即用的流水线集成，左移安全到 PR 评审阶段
  4. 可验证性 ：每个发现都附带 PoC，告别"狼来了"式的虚假告警

当前局限

  1. 强依赖 LLM 质量 ：工具调用能力、推理深度高度依赖底层模型
  2. Token 消耗可观 ：完整扫描的 API 费用不容忽视
  3. 本地模型支持有限 ：Ollama 等本地模型在复杂工具编排场景下表现不佳
  4. 社区尚在早期 ：Skills 生态还不够丰富，测试套件在 2026 年 4 月被移除

展望

随着 Codex/GPT-5/Claude 等模型的持续进化，AI Agent 的安全测试能力将以指数级增长。Strix 的架构设计——多 Agent 协作 + Skills 知识注入 + 沙箱隔离——为这个趋势提供了坚实的基础。可以预见，未来 2~3 年内，AI 驱动的自动化渗透测试将成为 DevSecOps 流水线的标配组件。

项目地址 ：github.com/usestrix/st… 官方文档 ：docs.strix.ai 在线平台 ：app.strix.ai（商业版，支持持续渗透测试与一键自动修复）

⚠️ 伦理声明 ：Strix 是一款合法安全测试工具，仅可用于测试您拥有或已获授权的应用程序。滥用此工具进行未授权渗透测试属于违法行为。请负责任地使用。