工具调用评测三分裂：准确率·合规·行为安全的生产账本

概述

2026 年的工具调用（Tool Use / Function Calling）评测正在经历一次结构性分裂。过去三年，行业用单一指标——「任务完成率」或「调用准确率」——衡量一个 Agent 能不能正确发函数；但 BFCL 跑到 V4、τ-bench 演进到 τ²、ToolEmu / SafeToolBench / ASB 等一批安全基准涌现之后，结论已经很清楚：完成率高的模型，照样能在生产里酿出事故。本文拆解工具调用评测已经分裂出的三个独立维度——准确率维（能不能调对）、政策合规维（该不该调）、行为安全维（调了会不会有不可逆副作用）——并给出三维组合的生产 CI 网关设计。核心发现：准确率维已被 BFCL V4 的 agentic 化（web search + memory + format sensitivity）逼近天花板，政策合规维由 τ²-bench 的双控对话范式重新定义，而行为安全维——一个被 80% 团队完全忽略的维度——恰恰是 KPI 翻车、资金损失、数据外泄的真实来源。ToolEmu 的人类评测显示，LM 自动检测器能识别 68.8% 的失败模式，这意味着「安全评测可自动化」的工程门已经打开。

三维评测对比总账

三者的关键区别在于可逆性：准确率维的错误通常可重试，政策合规维的错误可人工兜底，而行为安全维的错误——一旦邮件已发、转账已执行、数据库已删——没有 Ctrl+Z。这就是为什么三维必须独立评测、独立设阈，而不是合成一个分数。

深度剖析

一、准确率维的演进：从 AST 匹配到 BFCL V4 的 agentic 化

准确率维是工具调用评测的起点。Berkeley Function-Calling Leaderboard（BFCL）从 V1 的简单/并行/多重调用 AST 匹配，到 V3 引入多轮对话轨迹（multi-turn dialogue trajectories）和分布外（OOD）工具测试，再到 2025 年底的 V4 彻底 agentic 化——评测不再只看单次函数调用是否对，而是把 web search（实时检索）、memory（跨轮记忆）、format sensitivity（对工具描述微小改动的鲁棒性） 三类能力纳入同一个 agentic 框架。BFCL V4 官方博客明确指出，agentic 评测包含三个 building block：web search、memory、format sensitivity。这意味着过去那种「调一次函数对了就算过」的静态评测已经失效——同一个模型在单轮 AST 准确率上可能 95%+，但在需要跨 5 轮记忆 + 实时搜索 + 多工具组合的 agentic 轨迹上，分数可能腰斩。

一个关键工程教训：format sensitivity 是被严重低估的维度。它测的是当工具描述换个说法、参数顺序调整、加一句无关说明时，准确率掉多少。很多团队上线后发现模型对官方 SDK 的工具描述工作良好，但接入第三方/自研工具后准确率暴跌——根因不是模型差，而是工具描述没过 format sensitivity 这关。把 BFCL V4 的 format sensitivity 子集当作工具上线的回归门，能把这类问题前置。

# 准确率维：BFCL 风格的多轮 + format sensitivity 回归门
import bfcl_eval

def accuracy_gate(tools_v2, model):
    # 1. 标准轨迹准确率
    base = bfcl_eval.run(model, tools_v2, subset="multi_turn", strict=True)
    # 2. format sensitivity：对工具描述做扰动后再测
    perturbed = bfcl_eval.run(
        model, bfcl_eval.perturb(tools_v2, modes=["reorder", "paraphrase", "noise"]),
        subset="multi_turn", strict=True,
    )
    drop = base.accuracy - perturbed.accuracy
    # 3. 准入：基础≥0.85 且 扰动衰减≤8%
    return base.accuracy >= 0.85 and drop <= 0.08, drop

二、政策合规维：τ-bench 与 τ²-bench 的双控对话革命

准确率维回答「能不能调对」，政策合规维回答「该不该调」。τ-bench（Tool-Agent-User Interaction Benchmark，Sierra 团队，arXiv 2406.12045）是这个维度的奠基性工作：它在零售、航空等客服领域，给 Agent 一套工具 + 一份可执行的业务 policy（如「退款只能在下单 7 天内发起」「机票改签需要核对身份证号」），任务完成不仅要调对工具，还必须全程遵守 policy。τ-bench 的洞察是：任务完成 ≠ 正确完成。一个能成功帮用户退款的 Agent，可能在 30 天后退款、绕过身份核验、用了不允许的支付通道——任务完成了，但每一步都违反了 policy。

τ²-bench（arXiv 2506.07982）把这个范式推向新阶段：它引入第二个 LM 扮演真实用户，形成「双控」（dual-control）对话环境。过去客服评测是静态的——用户输入固定、Agent 自说自话；τ² 里用户会根据 Agent 的回复动态追问、改主意、提供错误信息。这暴露出一批静态评测看不到的失败模式：Agent 在用户反复改需求时丢失 policy 约束、在用户施压「我不管我就要退」时妥协越权。双控范式本质上是把 policy 当作一种压力测试——测的是 policy 在对抗性对话下的鲁棒性，而不是 Agent 在顺境下的完成率。

# 政策合规维：τ² 风格的双控 + 可执行 policy 检查
def policy_gate(domain_tools, policy_rules):
    user_sim = LLM(role="adversarial_customer")     # τ² 的第二个 agent
    agent = build_agent(domain_tools)
    violations = []
    for task in tau2_tasks("retail"):
        traj = run_dialogue(user_sim, agent, task)  # 双控对话
        for step in traj:
            # 用可执行 policy 而非自然语言判读
            if not policy_rules.check(step.tool, step.args, step.context):
                violations.append((step, policy_rules.last_reason))
    return len(violations) == 0, violations

三、行为安全维（上）：ToolEmu 与 68.8% 的自动检测上限

行为安全维回答最致命的问题：「调了会不会有不可逆副作用」。ToolEmu（ICLR 2024 Spotlight，Ruan et al.）是这个维度的开创者。它的核心 trick 是用一个 LM 模拟工具执行——不真的发邮件、不真的转账、不真的删数据库，而是让一个 emulator LM 假装执行并返回结果，从而能在几万种工具 × 场景组合上大规模跑安全测试。配合一个 evaluator LM 自动判定 Agent 的行为是否引入风险（数据泄露、未授权访问、资金损失、系统损坏），ToolEmu 建立了「安全评测可大规模自动化」的范式。

ToolEmu 论文里最关键的一个数字是：人类评测显示，LM 自动 evaluator 能正确识别 68.8% 的 Agent 失败模式。这个数字的两面性决定了它的工程定位——一方面，68.8% 意味着自动化安全评测已经「能用」，可以作为 CI 里的粗筛层；另一方面，剩下的 31.2% 漏检意味着它只能做第一道闸门，不能做唯一闸门。生产实践的正确姿势是：ToolEmu 风格的 LM 沙箱做 100× 规模的广度扫描，人类/红队做关键路径的深度审计。把 ToolEmu 当成「安全维的单元测试」——它跑得快、覆盖广，但通过它不等于上线安全。

行为安全维和准确率维的深刻区别在于失败的可逆性结构。准确率维的错误是「调用失败」，失败通常返回错误码、可重试；行为安全维的错误是「调用成功但本不该执行」——邮件发出去了、钱扣了、表删了。前者是 type-I（漏调/错调），后者是 type-II（误调/滥调）。两个维度几乎正交：一个准确率 99% 的模型，行为安全分可能只有 60%，因为它「太积极」地完成了不该完成的副作用操作。

四、行为安全维（下）：SafeToolBench 的「前置拒绝」与 ASB 的评分量规

SafeToolBench（arXiv 2509.07315）把行为安全维推进了一步——它强调前瞻性安全意识（prospective safety）。过去的工具安全评测是「后置」的：已经拿到了工具、已经在执行，看 Agent 会不会在执行中识别风险。SafeToolBench 测的是更早的一刻：当 Agent 面对一个工具集合和一个请求时，它能否在调用前就判断『这个组合不该执行』并主动拒绝？ 这模拟的是生产里最危险的一类场景——用户（或上游 prompt）请求一个看起来合理、实则越权的操作，模型如果不具备前置拒绝能力，就会一路绿灯走到事故。

与 SafeToolBench 互补的是 ASB（Agent Safety Benchmark v1.0，15 Research Lab）。ASB 把自己定位为「动作型 AI 系统」的评分量规（scoring rubric）——不只是给一个 pass/fail，而是按风险类别（越权、数据外泄、资源滥用、不可逆操作、社会工程沦陷）打分，输出一张可读的安全画像。这种 rubric 化的方法对生产治理极有价值：它让安全从「模型是否安全」的二元判断，变成「模型在哪个风险类别上有多少暴露面」的可运营指标，安全团队可以据此排修复优先级。

# 行为安全维：前置拒绝 + 副作用分级 rubric
SIDE_EFFECT = {"read_db": "pure", "send_email": "irreversible",
               "refund": "irreversible", "delete_record": "irreversible_dangerous"}

def safety_gate(agent, toolset, risky_requests):
    for req in risky_requests:
        calls = agent.plan(req, toolset)          # 不执行，只看计划
        max_sev = max(SIDE_EFFECT.get(c.tool, "unknown") for c in calls)
        # 前置拒绝：纯函数才允许，副作用操作必须先要二次确认
        if max_sev in ("irreversible", "irreversible_dangerous"):
            if not agent.requests_confirmation(calls):
                return False, f"未对 {max_sev} 操作要求确认"
    return True, "passed"

五、双控对话如何把 policy 维和安全维焊在一起

值得单独拎出来的是 τ²-bench 的双控范式对政策维 + 安全维联合测试的价值。真实事故几乎从不是单维度触发，而是 policy 违规叠加副作用操作：一个客服 Agent 被用户施压后，不仅违反了退款 policy（合规维），还真的把钱退了出去（安全维，不可逆）。静态评测把这两件事分开测，得到两个「各自都还行」的分数；双控评测让对抗性用户同时压这两根弦，于是复合失败暴露无遗。

工程上的启示是：不要把三维评测设计成三条独立流水线。准确率维可以独立、可以高频（每次构建跑）；政策维和安全维应该共用一个双控对话 harness——同一个对抗性用户轨迹，policy checker 检查合规、safety evaluator 检查副作用，一次跑两份报告。这既省了对话生成的成本（对话是最贵的部分），又让两个维度的失败能在同一条轨迹上关联分析。

六、生产组合：用三维评测搭一个 CI 安全网关

把三维拼成一个生产 CI 网关，关键是分频、分阈、分层。分频：准确率维每次构建跑（便宜、AST 匹配快）；政策维 nightly 跑（双控对话贵）；安全维 weekly + release 前跑（ToolEmu 广度扫描 + 红队深度审计）。分阈：三维各自有独立阈值，任何一维触红即阻断发布，不合成总分——合成分会让安全维的低分被准确率维的高分稀释，这是治理大忌。分层：LM 自动评测做粗筛（ToolEmu 的 68.8%），关键路径（涉及资金、数据外发、删除的 tool）再过人工/红队。

def release_gate(model, tools):
    a, _      = accuracy_gate(tools, model)          # 每次构建
    p, _      = policy_gate(tools, policy_rules)     # nightly
    s, _      = safety_gate(model, tools, risky)     # release 前
    if not (a and p and s):
        block_release(reason={"accuracy": a, "policy": p, "safety": s})

七、变现与训练营评估

三维评测本身就是一个高价值训练营选题。准确率维门槛低、易上手，适合做「5 分钟第一个 Agent」的引流课；但真正的溢价在政策维和安全维——这是企业付费意愿最强、且市面课程最稀缺的部分。一个可落地的产品形态是「工具调用安全评测 SaaS」：用户接入自己的工具集 + 业务 policy，平台自动跑三维报告 + 副作用热力图，按工具数/评测频次收费。对标 BFCL leaderboard 的公开榜 + 私有评测的混合模式，既能做品牌（公开榜引流）又能做收入（私有评测收费）。训练营侧，可设计「从准确率到安全的三阶证书」——准确率阶（大众）、政策合规阶（B 端）、行为安全阶（高客单），逐级抬升毛利。

三维评测与 CI 网关架构图

flowchart TB
    Req[工具调用请求 / 对话轨迹] --> Decide{Agent 决策}

    subgraph D1[准确率维 Accuracy]
        A1[工具选择是否正确]
        A2[参数 AST/语义匹配]
        A3[Format Sensitivity 扰动]
    end

    subgraph D2[政策合规维 Policy]
        P1[可执行 Policy Checker]
        P2[τ² 对抗性双控用户]
        P3[越权/绕规则检测]
    end

    subgraph D3[行为安全维 Safety]
        S1[ToolEmu LM 沙箱广扫]
        S2[SafeToolBench 前置拒绝]
        S3[ASB 副作用 Rubric 打分]
    end

    Decide --> D1
    Decide --> D2
    Decide --> D3

    D1 -->|可重试错误| Retry[重试/降级]
    D2 -->|合规| Pass1[通过]
    D2 -->|违规| Block1[阻断·人工兜底]
    D3 -->|pure 只读| Pass2[通过]
    D3 -->|irreversible 副作用| Confirm[二次确认/审批]
    D3 -->|危险操作| Block2[阻断·红队审计]

    Pass1 --> Exec[执行工具]
    Pass2 --> Exec
    Confirm --> Exec
    Exec --> Side{副作用类型}
    Side -->|不可逆| Audit[不可抵赖审计日志]

推荐方案（按场景）

• 内部工具 / 纯只读 Agent：只配准确率维（BFCL multi-turn + format sensitivity）。只读操作可逆，政策与安全维收益有限，把精力放在准确率回归上即可。
• 电商 / 客服 / 金融 Agent：准确率维 + 政策合规维（τ²-bench 双控范式 + 可执行 policy）。这类场景的翻车点 90% 在政策违规（越权退款、绕过核验），双控对话 + policy checker 是 ROI 最高的组合。
• 能发邮件 / 转账 / 删数据的 Agent：三维全配，且安全维必须是第一闸门。强制副作用分级 + 前置拒绝 + 二次确认，ToolEmu 广扫 + 红队深审。安全维触红即阻断，不与准确率合成。
• 面向 C 端、对抗性强（社交/UGC 驱动）的 Agent：加重 τ² 的对抗性双控用户权重，并加入 SafeToolBench 的前置拒绝测试——用户会主动构造越权请求，前置拒绝是唯一防线。
• 多 Agent 系统：三维评测要在系统级而非单 Agent 级跑——单个 Agent 各维度都达标，但多 Agent 协作链路仍可能放大副作用（一个 Agent 的输出喂给另一个 Agent 触发越权）。把审计点放在 Agent 间交接处的 tool call 上。

一句话收束：工具调用评测的 2026 答案不是「分数更高」，而是「三个分数各自达标、互不稀释」。完成率堆到 99% 而安全维裸奔的 Agent，是定时炸弹；反过来，安全维严密而准确率维不过线的 Agent，是没用的炸弹拆除器。三维都硬，才是生产能用的 Agent。

参考来源

1. τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains (arXiv 2406.12045) — 政策合规维奠基性工作，引入可执行 policy 的客服域评测。
2. τ²-Bench: Evaluating Conversational Agents in a Dual-Control Setting (arXiv 2506.07982) — 双控对话范式，对抗性用户动态测试 policy 鲁棒性。
3. sierra-research/tau2-bench (GitHub) — τ²-bench 官方代码与多域 task 集。
4. BFCL V4 • Web Search — Berkeley Function-Calling Leaderboard — BFCL V4 agentic 化（web search + memory + format sensitivity）官方说明。
5. ToolEmu: Identifying the Risks of LM Agents with an LM-Emulated Sandbox (ICLR 2024) — 行为安全维开创者，LM 模拟工具执行 + 自动 evaluator，68.8% 失败模式可自动检测。
6. SafeToolBench: Pioneering a Prospective Benchmark for Tool-Use Safety (arXiv 2509.07315) — 前瞻性安全意识评测，测调用前的主动拒绝能力。
7. ASB Benchmark v1.0 — Agent Safety Benchmark (15 Research Lab) — 动作型 AI 系统的多类别安全评分量规。
8. Tool-Use Benchmarks 2026: BFCL V3, Tau-Bench, and the State of Function Calling — 2026 工具调用基准横向对比与排行榜解读。

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。