GABench：强模型漏调弱模型乱调，顶尖Agent为何最高仅74.8%？

GuardianAgentBench: Where Agents Fail and How to Guard Them

论文原文 ↗ 论文发布 2026-07-23 解读发布 2026-10-03 解读：AI前沿分享

在大模型逐步走向自主智能体（Agent）的今天，行业对其安全性的评估长期存在一种脱节：绝大多数基准测试依然停留在理想化的单步执行或高度简化的合成环境里，而真正的开发者却在 LangChain、LlamaIndex 等工业级框架中与复杂的工具调用、多轮状态流转和不可预测的外部异常苦苦缠斗。许多人直觉地认为，只要底层基座模型的能力足够强大，或者在系统提示词（System Prompt）里塞入足够详尽的安全与工具规范，智能体就能安全稳定地运作。

ArXiv URL：https://arxiv.org/abs/2607.20982

全新基准 GuardianAgentBench（简称 GABench）打破了这一乐观假设。研究人员在 LangChain、LlamaIndex 以及 Vectara 三大主流生产框架下，构建了包含 580 个场景、跨越 6 大业务领域以及 5 种对抗扰动模式的严苛评测体系。对 Claude Opus 4.5、GPT-5.2 Pro、Gemini-3-Pro、DeepSeek-V3.2、Qwen3-Max 以及开源的 GPT-OSS-120B 等 6 款顶尖模型的测试表明：即便是在最强的模型与框架组合下，智能体的端到端整体准确率也仅达到 74.8%，意味着在真实的复杂业务环境中，哪怕最聪明的 Agent 依然会在约四分之一的任务中败下阵来。

更关键的发现不仅在于“准确率不高”，更在于模型翻车时呈现出两条截然相反的演化路径：能力最强的模型往往死于“漏调工具”（Missing Required Tool Call），表现出过度保守的惰性；而相对较弱的模型则死于“选错工具”与“胡乱重复调用”。与此同时，随着交互轮次的拉长，多步规划展现出比工具数量膨胀严峻得多的断崖式性能衰减。这项研究用扎实的实验证明，试图单纯依赖系统提示词为顶尖 Agent 构建安全防线已经行不通，只有深入到工具执行时刻的结构化护栏（Guardrails），才能在几乎不伤害原有正常任务的前提下挽救近 20% 的失败调用。

走出玩具环境：GABench 的生产级测试基线

传统的智能体评测大多依赖自定义的 Python 沙盒环境，工具往往被抽象为几个简单的假函数，既缺乏真实网络通信的异常反馈，也无法映射真实生产环境的中间件开销。GABench 的核心出发点正是消除这种“实验室表现优异，生产上线立刻崩溃”的能力落差。基准直接依托开发者日常接触最频繁的生产框架——LangChain、LlamaIndex 与 Vectara 展开，囊括了客服、电子邮件、日程管理、商业智能（BI）、金融分析以及内部知识库等 6 个高频企业应用场景，涉及 81 个功能各异的真实工具定义。

为了确保测试样本兼具真实性与可复现性，GABench 采用了一套端到端的自动化流水线与严密的人工校验机制。如图 1 所示，流水线从智能体的基础配置出发，依次推导用户意图、生成多样化的输入提示、模拟真实的工具环境响应、构建绝对无歧义的标准执行轨迹（Ground Truth Trace），并制定出细粒度的评测标准。值得注意的是，为了消除大模型在多路径规划时的评测分歧，研究团队在人工校验阶段果断剔除了所有存在多种合理工具调用顺序的模糊场景，确保每一个标准场景都有唯一的执行判定真值。

整个基准包含的 580 个场景中，有 398 个（占比 68.6%）属于遵循标准工作流的“理想路径”（Happy Path），另外 182 个（占比 31.4%）则被注入了 5 种不同的对抗扰动。这些扰动并非无意义的字符乱码，而是模拟了真实生产链路中最让人头疼的环境异常：

输入级与工具级提示注入：外部数据或用户指令中暗含越权指令，诱导模型偏离原定业务逻辑；
工具环境故障与部分数据：API 接口报错、返回空字段或仅返回被截断的不完整数据，考验 Agent 是否具备容错重试或异常处理能力；
海量数据泛滥与多重实体匹配冲突：工具返回了超出常规上下文长度的非结构化列表，或者检索到多个相似度极高但属性冲突的对象，迫使 Agent 必须自主进行实体对齐与二次筛选。

每一个测试场景在框架中执行完毕后，都会交由评估裁判从两个正交维度进行打分：一是回复正确性（Response Correctness），即最终输出给用户的答案是否准确整合了工具返回的信息，杜绝幻觉捏造；二是动作正确性（Action Correctness），即模型在执行链路上调用的工具类别、传入的参数名与参数值、以及工具执行的先后顺序，是否与标准执行图严格一致。只有两者同时达标，才被计为整体成功（Overall）。评测裁判与人工判定的对齐率达到了 93.3%，足以支撑高可信度的量化剖析。

顶尖模型最高仅 74.8 分：框架不是借口，瓶颈全在模型

当 6 款前沿模型被推上生产框架的真实考场时，暴露出的差距远比学术榜单上的细微百分比更加刺眼。在所有测试矩阵中，表现最好的配置是搭载在 Vectara 框架上的 Claude Opus 4.5，其综合平均得分仅为 74.8；紧随其后的是 Gemini-3-Pro，整体得分维持在 71 至 73 之间；GPT-5.2 Pro 与 Qwen3-Max 位于第二梯队，得分区间在 68 到 72；而 DeepSeek-V3.2 与 GPT-OSS-120B 则落在 63 到 68 的区间内。

这意味着，无论采用闭源商业旗舰还是开源头部模型，在真实、带干扰的企业级业务中，智能体都有 25% 到 37% 的概率无法正确完成任务。从领域分布来看，日程管理（Calendar）是所有模型的绝对重灾区，没有任何一款模型在该领域的综合得分能超过 62.0，原因在于日程场景充斥着隐式的相对时间换算、时间冲突检测以及多方参与者的约束求解；相比之下，输入输出结构相对规整的金融与客服领域，模型的应对表现则从容得多。

更有启发性的是框架层面的对比。许多应用开发者在选型时常常纠结于 LangChain 和 LlamaIndex 的编排开销，怀疑框架的设计缺陷会导致模型性能滑坡。但 GABench 的控制变量实验给出了清晰的结论：同一款模型在 LangChain、LlamaIndex 和 Vectara 之间的综合得分波动通常不超过 2 到 3 分。这一微小差距说明，智能体在真实场景中频发的调用失误、逻辑卡死和幻觉生成，其根本根源在于大模型自身的规划与推理能力，当前流行框架的编排逻辑并没有为模型凭空制造额外的安全性陷阱。

强弱模型的两极分化：漏调工具与胡乱调用的双重困境

深入分析失败样本的执行轨迹后，研究人员梳理出了 5 种典型的失败类型：错误选择工具（ITS）、无效或缺失关键参数（IMP）、遗漏必要工具调用（MTC）、重复调用同一工具（RTC）以及工具调用顺序颠倒（ITO）。通过对各模型在不同框架下的错误分布进行统计，一项此前未被系统性揭示的现象浮出水面：高能力模型与低能力模型在走向失败时，呈现出完全不同的病理特征。

对于 Claude Opus 4.5 和 Gemini-3-Pro 这样的顶级能力模型，其失败原因具有高度的一致性——遗漏必要工具调用（MTC）占据了所有失败案例的 52% 到 57%。强模型在语义理解和单步推理上极为敏锐，极少出现“张冠李戴”选错工具的低级错误（其 ITS 错误率通常被压制在 10% 以下），但它们表现出了一种隐蔽的认知自负或多步退缩：在面对需要多步链式调用的长任务时，强模型常常在完成前置查询后，自作主张地跳过后续必要的验证或写入操作，倾向于直接凭借前几步的信息“脑补”生成最终答案。

而以 DeepSeek-V3.2 和开源的 GPT-OSS-120B 为代表的模型，其失败图谱则呈现出截然不同的混乱形态。这类模型的遗漏调用比例大幅下降，取而代之的是严重的“工具误选”（ITS 占比高达 20% 至 25%）以及停不下来的“重复无效调用”（RTC 占比达到 29% 至 33%）。两者相加，直接构成了弱模型近 60% 的翻车现场。弱模型对工具的功能边界与参数 Schema 缺乏精细把控，面对多个功能相似的工具时极易发生摇摆；一旦外部工具返回了非预期的空数据或错误信息，弱模型往往缺乏重构反思能力，而是像陷入无限循环一样，使用相同或微调后的无效参数机械地重复发起调用，直到耗尽上下文或步数配额。

这一两极分化的错误图谱为大模型落地提供了极其重要的警示：针对不同级别的模型，智能体系统的治理重点必须因地制宜。治理弱模型的核心是遏制其“多动症”，通过强化语义路由和调用去重机制避免其滥用工具；而治理强模型的核心则是对抗其“懒惰症”，必须通过强状态校验防止其在长流程任务中私自截断工作流。

复杂度杀手：为什么长程规划比海量工具更致命？

在构建企业级 Agent 时，架构师通常面临两类复杂度扩张：一是随着系统对接的业务系统越来越多，挂载给智能体的候选工具集（Tool-set Size）不断膨胀；二是随着业务流程纵深推进，智能体需要执行的连续调用轮次（Sequential Turns）不断加深。究竟哪一种复杂度对智能体可靠性的杀伤力更大？

GABench 针对 Claude Opus 4.5 在不同复杂度阶梯上的表现进行了严谨的消融统计。结果表明，两类复杂度都会导致模型性能单调下降，但衰减的斜率却有着天壤之别：

当系统挂载的候选工具数量从 1 个逐步增加到 7 个时，Claude Opus 4.5 的平均整体得分从 78.2 分平缓下降至 62.3 分，总计滑落 15.9 分。这说明，尽管大模型在候选工具增多时会面临检索干扰和注意力稀释，但凭借强大的上下文感知能力，顶尖模型依然能在大规模工具集合中维持相对体面的辨识度。

然而，当交互轮次深度从 1 轮逐步推进到 7 轮时，模型的平均整体得分从 82.3 分一路暴跌至 51.2 分，跌幅高达惊人的 31.1 分！随着执行步数的累积，任务状态的转移变得极为脆弱。在 5 轮以上的深度规划场景中，智能体不仅要记住用户最开始的核心诉求，还要正确维护中间每一步工具返回的数据状态，并动态决定下一步的分支逻辑。一旦中间某一步遭遇对抗扰动（例如返回了部分缺失的数据），模型在前一步积累的认知偏置就会在后续步骤中呈指数级放大，最终导致整条执行轨迹彻底偏航。这一实验确凿地证明：当前大语言模型在多工具选择上的抗压韧性尚可，但在处理长程依赖与多步复杂规划时，其底层能力依然存在严重的代际短板。

提示词防线的失效与运行时护栏的破局

为了对抗这些频发的失败，业界目前最常用的手段是强化系统提示词（System Prompt），即在系统设定中巨细靡遗地罗列各种工具调用纪律与安全约束。GABench 将这种源自 AgentSafetyBench 的经典提示词防御策略与一套全新的运行时结构化护栏（Execution-time Structural Guardrails）进行了严格的同台竞技。

研究团队在 LlamaIndex 的 FunctionAgent 核心中扩展了一套非侵入式的拦截中间件。如图所示，系统并不去改变底层模型的权重，而是在模型生成工具调用建议（Proposed Tool Calls）、真正发往底层系统执行之前，对其进行同步前置拦截。护栏体系由三个并行触发的轻量级检查模块构成：

参数验证模块（Argument Validation）：严格校验模型传入的参数是否符合工具接口规范，是否存在缺失必填项、类型错位或虚构参数等硬伤；
工具覆盖度检查模块（Tool Coverage Check）：根据上下文意图与已生成的轨迹，反向推演当前步骤是否遗漏了前置依赖工具或关键核验工具，专门针对强模型的“偷懒漏调”行为进行纠偏；
相关性与成本检查模块（Relevance and Cost Check）：审视本次调用是否与用户终极目标高度相关，判断是否存在无效轮询或非必要的重复调用，强力封堵弱模型的“死循环”倾向。

在具体运转时，这三个模块通过异步并发（asyncio.gather）同时对调用上下文展开诊断，并返回布尔标志与结构化的错误反馈字典。一旦任一护栏亮起红灯，系统并不会直接粗暴终止流程，而是将结构化的拦截反馈打包为一条精确的修正指令，在运行时直接反馈给智能体，触发其反思并重新规划；这种重试循环最多允许迭代两次，如果两次重试后依然违规，系统才会彻底阻断执行并上报人工介入。

实验对比揭示了一个发人深省的事实：系统提示词防御在面对高水平模型时几乎已经全面失效。测试数据显示，在加入详尽的安全提示词后，Gemini-3-Pro 的整体表现仅微增 0.3 分，Claude Opus 4.5 仅提升 0.4 分，而 GPT-5.2 Pro 甚至出现了 0.3 分的轻微负增长。这是因为强大的前沿模型本身在预训练和对齐阶段就已经内化了大部分常见的指令意图，在系统提示词中继续堆叠冗长的规则描述，不仅无法纠正深层次的多步逻辑缺陷，反而可能在上下文头部引入语义噪声，分散模型的注意力焦点。唯独表现较弱的 DeepSeek-V3.2 在提示词策略下获得了 5.5 分的明显提升，因为显式的工具规则刚好弥补了它在工具理解上的先天气虚。

相比之下，运行时护栏在所有 6 款模型上无一例外地取得了立竿见影的显著提升。护栏机制为各类模型带来的性能增益在 +2.8 分至 +7.7 分之间。最值得注意的是，护栏与提示词防御之间的效能剪刀差，在最强的模型身上体现得最为夸张：在 Claude Opus 4.5 上，护栏带来的提分比提示词高出 5.3 分；在 Gemini-3-Pro 上高出 2.6 分。这直接打破了“模型越聪明，越不需要外部框架约束”的迷思。

对于工程落地而言，任何防御机制都必须在“拦截成功率”与“业务误伤率”之间做权衡。如果一套安全机制为了堵住漏洞而频繁打断原本正常的业务流，那么它在生产环境中就是不可接受的。GABench 对护栏精度的微观审计给出了令人振奋的指标：在针对 Claude Opus 4.5 的实际验证中，运行时护栏成功修复并挽救了原本必败场景中的 19.9%，而在所有原本就能顺利跑通的正常场景中，护栏带来的假阳性误报率（False Positive Rate）仅仅只有 0.5%。

这种以极小误伤代价换取高额缺陷纠正的优异表现，彻底证实了执行时介入路线的优越性：与其在任务启动前苦口婆心地用自然语言提示词去规范模型那充满不确定性的思维链，不如在执行动作落地前的那一毫秒，用严谨的结构化协议进行物理把关与即时纠偏。

对智能体工程落地的启示

GABench 的诞生，标志着智能体评测从虚幻的概念验证迈向了残酷的生产工程实践。综合全篇数据与结论，这项工作为当前大模型应用开发者提供了三条清晰的现实坐标：

其一，必须彻底抛弃对“大模型原生多步可靠性”的盲目崇拜。即便选用当前行业最顶尖的闭源旗舰，也不要在生产环境中放任 Agent 开展毫无约束的深层自由探索。长程任务的失误率会以远超预期的速度恶化，将单一大任务拆解为多阶段确定性状态机、限制单次自治的轮次深度，是当前不可逾越的工程底线。

其二，认清模型能力的“偏科真相”。如果团队使用的是开源或参数量适中的模型，工程设计的重中之重是收紧工具路由权限，严防幻觉选错和重复刷接口带来的雪崩效应；而如果团队不惜成本采购了顶尖旗舰大模型，则要警惕其自作聪明省略工具验证步骤，必须在流程规范中设定刚性的检查点。

其三，防御范式的战略迁移。依靠系统提示词来控制 Agent 安全与可靠性的时代正在过去。随着大模型能力逼近平台期，单纯依靠 Prompt Engineering 能挤出的边际效用正在迅速归零。未来的企业级智能体架构，必然属于“模型思考推理 + 运行时结构化护栏拦截”的混合范式——把语义交给模型，把纪律交还给护栏。只有在执行时刻建立起类似操作系统的指令拦截机制，自主智能体才能真正走出玩具箱，成为企业敢于托付核心资产与关键流程的可靠基础设施。