超越成功率：攻击性与防御性安全 Agent 的成本感知评估

  • 关联论文：2607.15263
  • 作者：Tom
  • 更新：2026-07-21

一句话结论

现有安全 Agent 评估只问"能不能成功"，而这篇论文认为真正重要的是"花多少钱能成功"——提出成本-成功率联合评估框架，对攻击（CTF）和防御（SOC 调查）两种场景分别发现截然不同的 scaling 规律：攻击任务靠加大推理预算就能显著提升，防御任务的成功率更多取决于工具使用的纪律性，而非砸更多算力。

解决什么真问题

当前安全 Agent 评估的根本缺陷：只测峰值性能，不测经济效率。

现行的安全 Agent 评测（如 CTF benchmark、SOC 仿真）通常： - 给模型近乎无限的 token 预算； - 允许无限次工具调用； - 只报告"最终是否拿下 flag / 找到漏洞"

这套做法的意义在于追踪能力上限，但对实际部署几乎没有参考价值——因为在真实 SOC 环境中： - 每次 Splunk 查询都要花钱； - 每次 WHOIS 历史查询要 $1.29； - 每次 VirusTotal 枚举要付费； - LLM 推理成本随 token 量线性增长。

一个花了 $50 但成功溯源的 Agent，可能比花了 $5 但失败的 Agent 更糟糕——在真实运维中预算是刚性的。

核心方法

成本-成功率评估框架

论文定义了总成本 C_total 作为核心指标：

C_total = C_tokens + C_tools
  • C_tokens：LLM 输入+输出 token 的推理成本；
  • C_tools：外部工具调用的费用（Brave Search $0.005/次，WHOIS 历史 $1.29/次 等）。

在此基础上，以固定预算上限为横轴，成功率/分数为纵轴，绘制 cost-success 曲线，而非单点成功率报告。

双 benchmark 设计

攻击场景：Cybench - "Hard" 子集，39 道 CTF 题，涵盖 web 漏洞利用、密码学、逆向工程、取证； - 沙箱环境，允许 shell 和 Python 访问； - 目标：在给定预算内提交正确 flag。

防御场景：Splunk BOSS of the SOC (BOTS) v1 - 真实 Splunk 遥测数据 + 官方竞赛题目； - 模拟真实 SOC 调查：web 篡改、勒索软件感染等场景； - 评分按官方 BOTS 积分制（答对得分，使用提示扣分）。

Agent 架构：ReAct Style + Inspect 框架

Thought → Action → Observation → ... → Final Answer
  • Auto-Compaction：上下文达到 90% 上限时自动压缩历史，防止超出 context window；
  • 零成本工具：bash / python / 本地 Splunk 查询（无直接费用）；
  • 付费工具：Brave Search、WHOIS History 等，明码标价计入成本。

关键：不是单点成功率，而是 operating points 曲线

传统报告：模型X成功率 80%（隐含了极高/无限预算）

新框架报告：给定 $0.5、$1、$5、$10 的 per-sample 预算，同一个模型有不同的"在预算内完成"成功率——这才是运营者真正需要的信息。

关键实验与数据

以下数字来自论文摘要、alphaXiv 及 Moonlight review 总结。具体实验配置和完整模型列表请参考原文 Table。

攻击场景（Cybench）— 推理预算 scaling

  • GPT-5.5：最高成功率 94.1%，per-solve 成本 $1.16
  • 领先模型的 budget-response 曲线显示：加预算后成功率提升高达 18.8 个百分点
  • Claude Opus 4.8 和 DeepSeek v4 Flash 在高预算端仍有明显 headroom（说明资源未饱和）
  • 核心结论：攻击 CTF 类任务随推理预算明显 scaling，且开源大模型（DeepSeek v4 Flash）可以接近前沿闭源模型，同时保持成本竞争力

防御场景（BOTS v1）— 截然不同的 scaling 规律

  • 加大 per-sample 推理预算对 BOTS 分数的直接提升远不如 Cybench；
  • 高频工具调用往往伴随低分（说明工具使用缺乏纪律性）：
  • 直接提高 DeepSeek v4 Flash 的工具调用预算上限，几乎没有分数增益
  • 成功更多来自选择正确的工具、精准导航 telemetry、选择性 enrichment，而非砸推理预算
  • 防御成功的核心信号：工具使用的质量 > 推理 token 量

SOC Benchmark 污染警告

论文特别指出：BOTS v1 是公开数据集，存在严重数据污染风险——模型可能通过记忆公开 write-up 和解题思路来"作弊"。论文给出了 no-tools control 实验来揭示这一点，建议对所有公开 SOC benchmark 的绝对分数保持审慎。

交互式网站

作者提供了 https://evals.frontier.security 展示成本-成功率曲线，支持按模型、按预算、按任务类型筛选。

亮点与局限

亮点

  • 提出根本性评估范式转变：从"能力上限"到"经济效率"，这才是运营者关心的；
  • 揭示两种安全场景截然不同的 scaling 规律：对红队（攻击）和蓝队（防御）给出了截然不同的实践建议；
  • 工具成本明细：第一个将工具调用成本纳入安全 Agent 评测的工作；
  • 揭示 benchmark 污染问题：no-tools control 设计非常关键，对整个社区有警示作用；
  • 工程可复现性强：Inspect 框架 + 明确的成本定价，Others 可以复现。

局限

  • BOTS v1 数据集较旧（2017 年发布），与当前真实 SOC 环境存在差距；
  • 成本模型简化：内部 API 价格 vs 公开 API 价格差异显著，$0.005/Brave Search 可能不代表所有组织的实际成本；
  • Auto-Compaction 策略细节未充分披露：压缩粒度、摘要质量对实验结果的影响未知；
  • ReAct agent 架构偏简单：未使用更复杂的 agent 框架（如 Plan-and-Execute、Self-Ask），可能低估了结构化推理的价值；
  • 未见多轮协作场景：真实 SOC 通常需要多个 Agent 协作，当前评测是单 Agent 模式。

对工程落地的启发

  1. 采购安全 Agent 前先问成本：用固定预算而非成功率来筛选模型；GPT-5.5 虽然强，但 $1.16/solve 在大规模部署时可能过于昂贵；
  2. 红队任务可以靠算力换效果：CTF 类任务增加推理预算投入产出比明确，可以优先考虑大预算场景；
  3. 蓝队任务重工具纪律：选模型时应评估其在 SOC 场景下的工具使用效率，而非仅看原始推理能力；精调模型的 tool-calling 纪律可能比换更大的 LLM 更有效；
  4. Benchmark 污染必须审查：如果评估数据来自公开 CTF write-up 或 BOTS 公开解答，需要做 no-tools control 来校准；
  5. 成本监控是 SOC Agent 的标配：Agent 系统应内置 per-sample 成本追踪，在超预算时主动放弃或切换策略。

与同方向工作的关系

工作 核心贡献 与本文的关系
Cybench (Zhang et al., 2024) CTF 安全 Agent benchmark 本文采用 Cybench 作为攻击场景，但引入成本维度
Splunk BOTS v1 (2017) SOC 调查数据集 本文采用 BOTS v1 作为防御场景，但指出数据污染问题
Claude Mythos Preview (Anthropic, 2026) 高预算 CTF + 渗透测试评估 典型"峰值性能"评估范式；本文批评的就是这种
UK AISI Agent Evaluation (2026) 百万 token 预算的 agent 评测 极端高预算评测；本文的对比基准
ReAct (Yao et al., 2022) Reasoning + Acting 范式 本文 agent 架构基础
Auto-Compaction 相关工作 长 context 压缩 本文对 context 管理的处理方式（具体方法引用待确认）

适合谁读

  • 安全 Agent 开发者：在真实环境中部署 AI 安全工具，需要评估 ROI；
  • SOC 运营者：考虑引入 AI Agent 辅助调查，想知道"花多少钱能提升多少效率"；
  • AI 安全评测研究者：对 benchmark 设计、成本建模、agent 评估框架感兴趣；
  • 红蓝对抗团队：想客观评估 AI 工具在实际任务中的可用性；
  • LLM 应用工程师：关心 cost-efficiency 而非单纯 SOTA 性能的场景。

信息来源

  • arXiv abstract：https://arxiv.org/abs/2607.15263
  • arXiv HTML 全文 v2：https://arxiv.org/html/2607.15263v2
  • alphaXiv 详解页：https://www.alphaxiv.org/overview/2607.15263
  • Moonlight review：https://www.themoonlight.io/en/review/beyond-success-rate-cost-aware-evaluation-of-offensive-and-defensive-security-agents
  • Tavily web search：Cost-Aware Evaluation security agents Cybench BOTS Kassianik 2026
  • paper card（paper_cards/482-2607-15263.md）

不确定处

  • 具体模型列表（除了 GPT-5.5、Claude Opus 4.8、DeepSeek v4 Flash 外的其他模型）和完整 cost-success 表格数字原文未在公开摘要中给出；
  • Auto-Compaction 的具体算法实现（是否用 provider-native compaction？还是自研摘要？）未披露；
  • BOTS v1 数据污染程度的具体量化（no-tools control 的绝对分数与有-tools 分数的差值）未给出；
  • 不同任务类型（web 取证 vs 密码学 vs 取证）在成本-成功率曲线上的差异未展开；
  • BOTS 2026 年新版 vs v1 对比结论未涉及。

工程落地与核查（Jay）

1. 事实核查

核查项 结论 存疑级别
arXiv ID 2607.15263 ✅ 核实，v3 2026-08-13；标题吻合 —
"Beyond Success Rate" 标题 ✅ 来自 arXiv —
GPT-5.5 94.1% / $1.16 ⚠️ ⚠️ 原文摘要未直接给此数字；来自 Moonlight review 或 alphaXiv 页面 极高
18.8 个百分点 scaling ⚠️ abstract 未直接给具体数字；"budget-response 曲线"概念来自 abstract，数字需正文 Table 1 确认 高
Claude Opus 4.8 / DeepSeek v4 Flash ⚠️ abstract 未列具体模型；Moonlight review 有，但非原始论文来源 高
BOTS v1 = 2017 发布 ✅ abstract 原文确认 —
WHOIS History $1.29/次 ✅ 来自原文方法节（工具成本明码标价） —
Brave Search $0.005/次 ✅ 来自原文方法节 —
攻击任务 scaling with 推理预算 ✅ abstract 原文确认 —
防御任务 scaling 与工具纪律 ✅ abstract 原文确认 —
evals.frontier.security 网站 ⚠️ 域名格式可信，但未 fetch 核实；需访问确认活跃状态 中
Auto-Compaction 无引用 ⚠️ 解读已注明"具体方法引用待确认"，但 W32 lessons 将 Auto-Compaction 无引用列为风险 高
Cybench 39 道 CTF 题 ⚠️ abstract 未给；来自 Moonlight review 或 paper_card 高

最高风险核查项： 1. GPT-5.5 94.1% / $1.16 是最强数字但来源最不确定。这是全文最吸引眼球的数字，但并不来自 abstract；需读正文 Table 1 确认。若正文无此数字，则属于第三方引用失实。 2. Claude Opus 4.8 / DeepSeek v4 Flash 模型名称需正文核实。Opus 4.8 和 DeepSeek v4 Flash 的命名方式（4.8 / v4 Flash）在当时是否属实，需查原文；若正文发布于 2026-07-17，这些模型可能尚不存在（属于 AI 补全）。 3. Auto-Compaction 无引用。W32 lessons 第 3 条红线："v2 元层压过内容密度"。Auto-Compaction 作为论文提出的机制若无引用，则属于无源信源。

2. 可读性精修意见

  • GPT-5.5 / $1.16 数字来源应显式标注：当前脚注写"来自 Moonlight review 和 alphaXiv"，建议改为"来自 Moonlight review（第三方），原文 Table 1 发布后需核实"；若正文无此数字，需删除并注明"待原文发布后补全"。
  • Claude Opus 4.8 / DeepSeek v4 Flash 命名存疑：Anthropic 模型通常不以".8"为副版本号；DeepSeek 最新系列命名方式也存疑；建议加 ⚠️ 标注"模型名称来自第三方，需正文核实"。
  • Auto-Compaction 无引用：解读已注明，但建议在原文发布后优先补全引用；若原文未给引用，应降为"机制名称已提出，具体实现待查"。
  • "BOTS 2017 数据集"表述明确，但可补充"BOTS v2（2023 年发布）是否被使用"以防误导读者以为评测用的是最新版本。

3. 工程落地：实际系统怎么用、坑在哪

适用场景判断：

成本-成功率评估框架适合： - 安全 Agent 采购评估：先用固定预算测试集筛选模型，而非仅看 SOTA 榜单； - SOC 运营成本规划：评估引入 AI Agent 后 per-incident 成本变化； - 红队预算规划：确定 CTF 类任务的合理 per-sample 预算阈值。

成本-成功率评估框架不适合或需谨慎： - 零预算安全任务（成本不是约束条件，成功率才是）； - 实时入侵检测（延迟敏感，预算-成功率曲线在低延迟区域可能不适用）； - 多阶段长程攻击（分段成本难以归因）。

实测部署关键步骤：

# 成本-成功率评测框架实现（核心伪代码）
def cost_aware_eval(model, benchmark, budget_levels=[0.5, 1.0, 5.0, 10.0]):
    """
    对安全 Agent 做成本-成功率评测
    Returns: dict of {budget: (success_rate, avg_cost)}
    """
    results = {}
    for budget in budget_levels:
        successes = 0
        total_cost = 0
        for task in benchmark.tasks:
            agent = SecurityAgent(model)
            agent.set_max_cost(budget)
            try:
                result = agent.run(task)
                successes += result.success
                total_cost += result.total_cost
            except BudgetExceeded:
                pass  # 预算内未完成算失败
        results[budget] = {
            'success_rate': successes / len(benchmark.tasks),
            'avg_cost': total_cost / successes if successes > 0 else None
        }
    return results

# ⚠️ 关键工程问题：
# 1. 模型名称（GPT-5.5 / Claude Opus 4.8 / DeepSeek v4 Flash）需与实际 API 对齐
# 2. 工具成本随时间变化（VirusTotal 等商业 API 价格会调整），需要动态更新
# 3. BOTS v1 数据污染：no-tools control 实验必须做，否则绝对分数不可信

主要工程坑：

  1. GPT-5.5 / $1.16 数字是最关键风险。若正文 Table 1 中无此数字，则最强结论来自第三方而非原始论文，属于引述失实。原文发布后第一件事：核查正文是否有 94.1% / $1.16。

  2. 模型名称可能 AI 幻觉。Claude Opus 4.8（Anthropic 副版本号通常为整数）和 DeepSeek v4 Flash（DeepSeek 最新一代命名）的真实性存疑。若正文（2026-07-17 提交）无这些模型，则属于真实 ID + 伪造细节（W32 lessons 红线第 2 位）。

  3. BOTS v1 数据污染需实测验证。即使论文做了 no-tools control，部署团队在用自己的数据集评估时仍需做同样控制。真实 SOC 场景（2017 年数据 vs 2026 年威胁 landscape）本身就存在分布漂移。

  4. 工具成本价格随时间波动。WHOIS History $1.29/次（可能来自 Namecheap 或类似服务）价格可能已调整；部署时应使用当前实际价格表而非论文中的固定数字。

  5. Auto-Compaction 实现细节缺失。若部署团队想复现论文的 agent 架构，Auto-Compaction 是关键组件；但其算法细节（压缩粒度、摘要方法）未公开，可能需要自行设计等效实现。

  6. ReAct 架构偏简单。论文用 ReAct 而非 Plan-and-Execute 或 Tree-of-Thought，可能低估了复杂 agent 架构在防御任务中的价值。工程团队若想提升 SOC Agent 能力，不应仅复现 ReAct 基线。

4. 关联工程主线简图

安全 Agent 工程主线
├── 成本感知评测（本篇，2607-15263）
│   ├── cost-success 曲线 → 评估范式从峰值→经济效率
│   ├── Cybench 攻击 scaling → 推理预算有效
│   └── BOTS 防御不 scaling → 工具纪律 > 算力
└── 安全 Agent 工具使用研究
    ├── 工具调用纪律 → 蓝队成功关键
    ├── ReAct / Plan-and-Execute → agent 架构选择
    └── Auto-Compaction → context 管理（⚠️ 实现细节未公开）

LLM 评测工程主线
├── 峰值性能评测 → AISI / Claude Mythos（典型）
├── 成本感知评测（本篇）→ 新维度：经济效率
└── 统计自一致性（2607-15277）→ 参考无关内部一致性

⚠️ 风险红线
├── GPT-5.5 / $1.16 数字来源待正文核实
├── Claude Opus 4.8 / DeepSeek v4 Flash 命名真实性存疑
└── Auto-Compaction 无原文引用，实现者需自行填补