企业官网建设流程全解析

AI安全流水线的三层评估策略：Mantis式Tiered Evals、代理指标与Shadow Eval实战

【免费下载链接】mantisA modular, stack-agnostic toolkit for AI coding agents to autonomously find, reproduce, and patch vulnerabilities.项目地址: https://gitcode.com/gh_mirrors/mantis17/mantis

Mantis 是一个模块化、技术栈无关的工具集，让 AI 编码代理自主发现、复现并修复代码漏洞。本文带你完整看懂 Mantis 的三层评估策略（Tiered Evals）：如何用零成本的静态检查、单阶段隔离测试与黄金数据集端到端评估，配合代理指标（Proxy Metrics）和 Shadow Eval 方法，低成本地验证你的 AI 安全流水线是否真的在变强。

为什么 AI 安全流水线需要分层评估？

多代理安全流水线（比如 Mantis 的「调查 → 去重 → 评审 → 复现 → 修复」全链路）评估起来非常昂贵：每微调一次提示词，如果都要跑完整流水线，时间和 API Token 成本都会爆炸。

Mantis 的核心思路只有一句话：

只运行能证伪（falsify）当前改动的最便宜的那一层测试。

👉 排名逻辑改了？跑零 Token 的 Tier 1 就够了；研究员工具或模型换了？跑 Tier 2；只有大版本发布或换基座模型时，才值得花大钱跑端到端。完整策略见 README_AGENTS.md。

Mantis式 Tiered Evals：三层从便宜到昂贵的评估金字塔

Tier 1：零 Token 的静态与确定性检查

第一层完全不调用大模型，速度快到可以"每次提交都跑"。在 Mantis 中它有两类内容：

• 格式校验：SKILL.md能否解析、YAML frontmatter 是否正确、系统提示词是否超出上下文窗口；
• 确定性排名基准：surveyor_benchmark.py 对"调查员"（Surveyor）的文件排名打分——用 recall@k、nDCG@k、MRR 衡量已知漏洞文件被排得多靠前，并用 coverage ceiling 区分"排名靠后"和"根本没被切片"。

它的基准目标是 synthetic_repo.py 生成的合成 Web 应用（植入漏洞文件 + 同模式的诱饵文件），属性被 tests/test_surveyor_benchmark.py 钉死，保证自检可复现。

📌 一个细节：外部靶场（如 ground_truth/juice_shop.json 中固定的 v20.2.0 版本）只用于零 LLM 层级——因为它的漏洞是公开写满博客的，直接拿去跑 LLM 阶段测试会被预训练"污染"而虚高分数。

Tier 2：把单个阶段放进"真空"里测

第二层把某一个技能从流水线中完全拆出来，喂给它静态、硬编码的输入，只看它的输出。Mantis 为下游各阶段都准备了固定数据集的"单元测试"（run_eval.py）：

• Dedupe：给一批 findings，看它是否合并了真重复、且没有误并不同漏洞（precision/recall/safety 四项打分，见 run_eval.py）；
• Reviewer / Critic：用固定数据集检验每条判定的路由（confirmed / false_positive）是否合理；
• Researcher：research_eval.py 把带漏洞的 research_target/ 语料复制进一次性"隔离 jail"（答案文件 ground_truth.json 被排除在外，防止模型偷看），测量检测召回率、跨文件召回率、精确率，以及每个真实发现的 Token 成本。

这里还有一个漂亮的 A/B 设计：工具集是唯一的自变量。--toolset baseline（纯文件读写）对比--toolset structural（增加find_symbol、find_callers等结构导航工具），同一模型、同一提示、同一目标。实测结果（见 evals/README.md）：structural 组 75% 精确率 vs baseline 组 22%，且 Token 花费减半——但两组各发现了对方找不到的真实 bug，说明工具是互补而非替代关系。

阶段配置与生产流水线完全一致（同一工具列表、同一指令），确保测的就是线上行为，定义见 stage_agents.py。

Tier 3：黄金数据集端到端评估

第三层是"大考"，只在重大发布或更换基座模型时运行：

1. 精选 3~5 个真实、有代表性的漏洞仓库（golden dataset）；
2. 跑完整流水线，只看二元结果：最终测试套件是否通过？/mantis-reproduce是否生成了可运行的 PoC？
3. 可辅以人工评审，看是否发现了新颖漏洞。

💡 Mantis 团队刻意暂时不设固定的端到端层级：全流水线分数会把每个阶段的方差揉进一个数字，只能告诉你"变差了"，却说不出"哪里变差"。等语料库大到能区分真实波动与运行噪声时，端到端测试才值得花那份钱——现在这层职责由 Tier 2 的各阶段基准承担（evals/README.md）。

关键原则：通过不能"向上传递"

排名提升（Tier 1）不是检测能力提升（Tier 2）的证据；单阶段胜出也不是端到端胜出的证据。

每一层只独立回答一个问题，避免"局部优化感动自己"。

代理指标：如何衡量"无法直接衡量"的中间阶段？

像/mantis-researcher这样的中间阶段，"成功"很难用二元定义。Mantis 建议追踪三类**代理指标（Proxy Metrics）**来感知技能退化（README_AGENTS.md）：

Shadow Eval：从真实失败中"白嫖"评测数据集

第一天不要搭宏大的评测框架。Shadow Eval 的精髓是让数据集有机生长（README_AGENTS.md）：

1. 手动运行流水线，等代理在某个具体任务上失败；
2. 保存那个确切的起始状态（用户提示词、工作区文件、JSON 状态）；
3. 修复技能提示词，直到代理成功；
4. 把这个孤立状态变成你的第一个自动化测试。

只从真实失败构建评测集，意味着你只在真正重要的回归上花 Token——每一行测试都来自一次真刀真枪的翻车。

快速上手：跑一遍 Mantis 参考实现

cd reference && ./install.sh python3 scripts/configure.py --auto # Tier 1：零 Token 自检 python3 evals/surveyor_benchmark.py --synthetic # Tier 2：Researcher 模型扫描（3 次运行看分布） python3 evals/run_eval.py --stage research --runs 3 # Tier 2：下游阶段基准（dedupe/review/critic/calibrate） python3 evals/run_eval.py --stage all --runs 3

🎯 进阶玩法：用 Tier 2 验证"把旗舰模型换成更便宜的模型是否降低成功率"，再决定是否滚动上线；做并行轨迹搜索时，测试 2/3/5 个并发代理——如果并行研究员总找同一批漏洞，那只是烧钱，没有独特价值。

总结：三层策略的落地清单

• ✅先拆后测：能用最便宜层级证伪的改动，绝不上昂贵层级；
• ✅单变量 A/B：一次只变一个东西（模型、工具集、提示词），其余全部固定；
• ✅用代理指标盯中间阶段：工具错误率、轨迹效率、放弃率是三种最灵敏的"听诊器"；
• ✅Shadow Eval 攒数据集：每次真实失败都值得固化成一个回归测试。

这套「Tiered Evals + Proxy Metrics + Shadow Eval」的组合拳，本质上是一套评估经济学：把最贵的端到端测试留给最值得的时刻，让日常的每次迭代都快、便宜、可归因。完整评估文档可参考 reference/evals/README.md 与 README_AGENTS.md。

【免费下载链接】mantisA modular, stack-agnostic toolkit for AI coding agents to autonomously find, reproduce, and patch vulnerabilities.项目地址: https://gitcode.com/gh_mirrors/mantis17/mantis