📢 【前排高能预警：代码还没更新完！】

本文分享的是最新架构设计理念。目前 GitHub 仓库的代码仍在集中测试中，插件加载、全平台兼容等新功能尚未合并进主干。

当前克隆仓库获取的仍是此前稳定的“纯三阶漏斗”版本。 建议先使用该版本，最新代码更新完毕后我会在仓库和 CSDN 同步通知。欢迎 Star ⭐️ 以便及时获取更新！

上一篇《受够了 AI 的废话和无脑拒答？开源一套基于“三阶漏斗”的 Agent 审计工作流》发出去之后，不少读者反馈：三阶漏斗确实有效控制了 Token 消耗和幻觉问题，AI 不再输出冗长内容。但也有不少红队与安全从业者询问：“这套方案能否直接接入我自己的破甲/越狱工具？”

⚡ TL;DR

• 骨架中立 + 插件化解耦：三阶漏斗只负责「怎么读代码」，载荷从哪来交给外部 adversarial_provider 插件，两者通过固定的 generate_and_test 入口彻底解耦，接 Garak、PAIR 都不用改主干。
• 插件异常三级回退：插件抛异常、返回格式不合法、返回空列表三种情况全部捕获，自动回退内置检查项，做到「插件可以坏，审计不能停」。
• 大文件先大纲后分片：超过 32KB 或 800 行就切分，单片 200~400 行、片间重叠 20~40 行（代码默认取区间中值 300 行 / 30 行重叠），扫描结果去重合并并计算 coverage，从源头绕开 Lost in the Middle。
• 代码仍在开发中：GitHub 主干目前还是老版本的纯三阶漏斗，插件化与兼容修复尚未合并，建议先克隆老版本体验流程，Star ⭐️ 蹲更新。

  📖 目录- 🤔 痛点：为什么我们不把破甲逻辑写死？

• 🧠 大文件怎么喂：先大纲、再分片，绕开 Lost in the Middle
• 🚀 再次提醒：代码仍在开发中## 🤔 痛点：为什么我们不把破甲逻辑写死？？如果你看过上一版，应该知道三阶漏斗的核心是：阶段一轻量侦察 -> 阶段二降维固化证据 -> 阶段三深度攻坚。但这套流程存在一个隐含边界：它只约束「AI 如何读取代码」，而不负责「攻击载荷从何而来」。市面上大部分安全审计工具的实现方式较为粗放：硬编码测试用例，并固化若干越狱规则。问题在于，红队技术迭代太快了——你今天写进代码里的破甲逻辑，下个月可能就失效了。想接 Garak？想用 PAIR 迭代？此时就得改动底层代码，而改完之后往往会发现，原本的三阶漏斗逻辑与这些工具的数据结构并不兼容，导致整体架构难以复用。

所以这次升级的核心思路只有一句话：审计骨架保持中立，破甲插件（adversarial_provider，即外部插件）交给你自己选。 后文统一称它为「adversarial_provider 插件」。 ```mermaid
flowchart TD
A["阶段一：轻量侦察"] --> B["阶段二：降维固化证据"]
B --> C["阶段三：深度攻坚"]
P["外部 adversarial_provider 插件"] -->|"注入载荷 / 测试用例"| B
B -->|"固化后的证据与载荷"| C
C --> R["输出审计报告 + compliance_ref"]

几个要点说明：

- **阶段一轻量侦察**：只做低成本的结构扫描，快速圈出可疑代码区域，不消耗大量 token。
- **阶段二降维固化证据**：把侦察结果压缩成结构化证据，同时由外部 `adversarial_provider` 插件在此注入载荷与测试用例。
- **阶段三深度攻坚**：拿着固化后的证据与载荷做深度验证，最终输出审计报告与 `compliance_ref`。
- **插件只挂在阶段二**：载荷来源与审计骨架彻底解耦，插件换掉也不影响阶段一、阶段三的流程。

调用时先 `dedup_findings()` 去重，再把结果交给 `calc_coverage()`，就能得到「去重后的证据 + 覆盖率」这一份可直接回流阶段二的汇总结果。这样，大文件在阶段二就被拆成「大纲 + 分片证据 + 覆盖率」三件套，阶段三拿到的仍是结构化、可追溯的输入，Lost in the Middle 的问题也就从源头被绕开了。}

2）非 UTF-8 编码导致读取异常：不要用 errors="ignore" 一把梭，那会静默吞掉字符、让行号错位。改成多编码回退，全部失败才跳过：

# scripts/outline.py（补充）
ENCODINGS = ("utf-8", "utf-8-sig", "gbk", "latin-1")


def read_with_fallback(path: Path) -> List[str]:
    """按候选编码依次尝试读取，全部失败则返回空列表并记录告警。"""
    for enc in ENCODINGS:
        try:
            with open(path, "r", encoding=enc) as f:
                return f.readlines()
        except UnicodeDecodeError:
            continue
        except OSError as exc:
            logger.warning("读取文件失败 %s: %s", path, exc)
            return []
    logger.warning("无法识别文件编码，跳过：%s", path)
    return []

3）大纲切分点落在函数体中间：轻量规则只看 def/class 前缀，遇到装饰器、多行签名或缩进块时容易切歪。加一道「回退到最近顶层行」```python

scripts/outline.py（补充）

def _is_top_level(line: str) -> bool:
"""顶层定义：无缩进且以 def/class/@ 开头。"""
return bool(line) and not line[0].isspace() and line.startswith(("def ", "class ", "@"))

def fix_split_point(lines: List[str], idx: int) -> int:
"""若切分点落在函数体中间，向前回退到最近的顶层定义行。"""
while idx > 0 and not _is_top_level(lines[idx]):
idx -= 1
return idx

**4）单片行数超过模型上下文上限**：`CHUNK_LINES` 只是目标值，遇到超长函数仍可能超限。扫描前先按字节数做一次硬校验，超限就对半拆：

```python
# scripts/chunk_scan.py（补充）
MAX_CHUNK_BYTES = 16 * 1024  # 单片字节上限，约 4K~5K token


def split_oversize(chunk: str) -> List[str]:
    """单片超字节上限时递归对半拆分，直到每片都低于阈值。"""
    if len(chunk.encode("utf-8")) <= MAX_CHUNK_BYTES:
        return [chunk]
    mid = len(chunk) // 2
    # 尽量在换行处切，避免把一行代码劈成两半
    cut = chunk.rfind("\n", 0, mid) or mid
    return split_oversize(chunk[:cut]) + split_oversize(chunk[cut:])
```)

5）coverage 低于阈值时的告警：覆盖率是「有没有漏扫」的唯一凭证，低于阈值必须显式告警，而不是静默出一份看起来完整```python

scripts/coverage.py（补充）

COVERAGE_THRESHOLD = 0.9

def check_coverage(coverage: float, file_path: str) -> Dict:
"""覆盖率低于阈值时输出告警，并在结果里标记 partial_scan。"""
if coverage < COVERAGE_THRESHOLD:
logger.warning(
"覆盖率不足：%s coverage=%.4f < %.2f，存在漏扫风险",
file_path, coverage, COVERAGE_THRESHOLD,
)
return {"partial_scan": True, "coverage": coverage, "threshold": COVERAGE_THRESHOLD}
return {"partial_scan": False, "coverage": coverage, "threshold": COVERAGE_THRES一句话原则：空文件短路、编码多级回退、切分点回退到顶层、超限对半拆、覆盖率不足必告警——把这五道闸门补上，分片流程才算真正能跑在生产仓库上。

图中三组柱子依次是「整段喂入」「大纲分片（串行）」「大纲分片（并发 4 片）」：输入 token 只涨到 1.52 倍，调用次数涨到 15 倍，串行耗时涨到 5.33 倍，但并发后回落到 1.78 倍；而真正有价值的去重后 finding 数量涨到 3.42 倍。也就是说，分片方案多付出的主要是「调用次数」这一项，耗时可以靠并发摊平，收益却落在有效发现上。

结论：分片方案在绝对 token 和调用次数上确实更贵，但把成本摊到「每条有效 finding」上反而更划算——多花约 50% 的输入 token，换来 3 倍以上的有效发现和可回溯的行号定位，这笔账对 40KB+ 的大文件完全成立；小文件仍走整段喂入，只有超阈值时才启用分片，才是真正的性价比最优解。t支持 Claude Code / Cursor / WorkBuddy，也保留了 prompt/system_prompt.txt 给网页版大模型使用。

⚠️ 免责声明（比啥都重要）：本项目只提供中立的编排骨架，不内置任何攻击性载荷。你通过外部脚本接进来的破甲工具，出了问题请自行承担，仅限用于合法的企业级安全审计和已授权的红队演练。红GitHub 传送门：Trace520/ultimate-security-audit

如果你觉得这个「骨架 + 可插拔」的思路有点意思，点个 Star ⭐️ 蹲更新，也欢迎在评论区聊聊你平时都是怎么接破甲工具的。甲## 本文的核心只有一句话

审计骨架保持中立，破甲插件交给你自己选。己三阶漏斗只负责「怎么读代码」，载荷从哪来由外部 adversarial_provider 插件决定，两者通过一个固定的 generate_and_test 入口彻底解耦。相比把破甲逻辑硬编码进源码，插件化在迭代成本上只需改脚本、无需发版，在兼容性上也不会因为接入 Garak、PAIR 而破坏原有数据结构，插件失效时骨架还能自动回退内置检查项兜底。针对 40KB+ 的大文件，则用「先大纲、再分片」绕开 Lost in the Middle：超过 32KB 或 800 行就切分，单片 200~400 行、片间重叠 20~40 行（代码默认取区间中值 300 行 / 30 行重叠），扫描结果再按统一 finding 结构回流到阶段二固化证据。如果你也在为红队工具的接入方式头疼，不妨先 Star ⭐️ 蹲一波更新，再到评论区聊聊你平时是怎么接破甲工具的。甲工具的。

📚 参考资料与延伸阅读

• Lost in the Middle 原始论文：Liu et al., 2023，《Lost in the Middle: How Language Models Use Long Contexts》——arXiv:2307.03172。本文「先大纲、再分片」的思路正是对这篇论文所揭示的长上下文衰减问题的工程化应对。
• Garak：LLM 漏洞扫描与红队测试框架，内置大量探针与检测器，适合做系统化的模型对抗评估——NVIDIA/garak。
• PAIR：基于「攻击者模型 + 目标模型」迭代对话自动生成越狱提示词的算法实现，适合做持续对抗与载荷迭代——patrickrchao/JailbreakingLLMs。
• 本项目仓库：Trace520/ultimate-security-audit。如果这套「骨架中立 + 插件化解耦」的思路对你有帮助，欢迎点个 Star ⭐️，更新会第一时间在仓库同步。
• 上一篇回顾：《受够了 AI 的废话和无脑拒答？开源一套基于“三阶漏斗”的 Agent 审计工作流》——CSDN 链接占位（发布后替换为实际文章地址）。