论文

Constraint Tax in Open-Weight LLMs: An Empirical Study of Tool Calling Suppression Under Structured Output Constraints

Constraint Tax in Open-Weight LLMs: An Empirical Study of Tool Calling Suppression Under Structured Output Constraints

Tool Calling 和 Structured Output 是现代 Agent 系统的两大核心能力,但二者在联合部署条件下的交互尚未得到充分理解。本文报告了生产 Agent 系统中一个可复现的现象:当同时启用 Tool Calling 和 JSON Schema 约束时,多个开放权重模型在保持高 schema 合规性的同时,停止调用工具。我们将此行为称为 Tool Suppression。 通过跨多个模型系列和部署设置的控制实验,我们在联合约束下一致地复现了 Tool Suppression,而独立评估时工具执行和 schema 合规性均正常。进一步分析表明,JSON Schema 约束被编译为基于语法的 token 掩码,导致工具调用 token 在解码过程中不可达,这为观察到的行为提供了实现层面的解释。 为解释该现象,我们提出了 Constraint Priority Inversion (CPI) 假设,认为在多重约束下,schema 满足可能主导动作选择行为。我们将 CPI 作为与观察证据一致的行为假设,而非经过验证的机制。为缓解问题,我们提出了 Transparent Two-Pass Execution,一种将工具执行与 schema 约束响应生成解耦的推理时策略。实验结果表明,该方法在不需重新训练模型的情况下,恢复了工具调用并保留了结构化输出保证。 这些发现表明,单独评估工具使用和结构化输出可能忽略生产 Agent 系统中的重要可靠性问题。代码、数据和文档将在 https://github.com/Fzsama/Constrain-Tax-26-06.git 发布。

论文精读

TL;DR 首次系统揭示并复现了开放权重LLM中结构化输出与工具调用联合部署时的工具抑制现象,明确根因与token掩码机制,并提出推理时解耦方案,对Agent系统可靠性评估至关重要。

问题

问题背景

当前,AI Agent 系统普遍依赖 工具调用(Tool Calling)结构化输出(Structured Output) 两大核心能力,以实现可靠的任务执行。

现有方法局限

现有方案通常独立设计和评估这两种能力,或采用简单的流水线(先调用工具,后格式化)。但当联合启用 JSON Schema 约束 和工具调用时,由于主流框架(如 vLLM、SGLang)采用 语法约束解码,会通过 token mask 屏蔽所有不符合 schema 的 token。这导致工具调用的特殊 token(如 <tool_call> 及函数名)被意外排除,模型虽能输出合规 JSON,却 完全放弃调用工具,即 Tool Suppression 现象。此前缺乏对此类联合约束失效的系统性研究与解决方案。

为什么这个问题难/重要

该问题的隐蔽性在于:单独测试工具调用或结构化输出时,各项指标均正常;一旦联合部署,Agent 的行动能力会静默丧失,在生产环境中可能引发严重故障。技术根源在于语法约束解码的 token 级排除机制,其优先级实际高于模型的行动选择意图,形成 约束优先级倒置(Constraint Priority Inversion) 。随着 Agent 系统的复杂度上升,多约束冲突将愈发常见,理解和缓解这种失效模式对保障 Agent 可靠性至关重要。

行业类比

类似于自动驾驶系统中,当碰撞避免约束与导航目标同时激活时,系统可能因过度保守而完全制动,无法完成行驶任务。

核心洞察

  • **联合约束下的工具抑制(Tool Suppression)揭示了语法层级 token 屏蔽导致行动失效的机制**。与以往单独研究约束税或工具调用可靠性不同,该工作首次在联合部署场景下复现并解释了工具调用完全沉寂的现象。通过分析 grammar-constrained decoding 在 token 层将工具调用 token 从掩码中排除,指出这不仅是模型偏好问题,而是解码层面的可达性缺陷。这提醒工程团队:在整合结构化输出与工具调用时,需检验推理框架的 token 掩码逻辑,而非仅依赖端到端评测。
  • **约束优先级反转(CPI)假设为多约束系统提供了行为解释框架**。该假设主张当多个约束共存时,schema 满足会支配行为选择,导致工具调用意图被覆盖。这不同于传统“过调”或“遗忘”假说,它从行为层面统一了解释,并未断言内部机制,而是提供可验证的预测。对产品设计启发:在提示工程或约束编排中,应警惕结构性约束压制行动性约束,或许需要引入显式的约束协调策略。
  • **透明两阶段执行(Transparent Two-Pass Execution)提供了一种轻量推理时修复方案**。与重训模型或修改解码算法的高成本方案不同,该方法解耦工具执行与 schema 合规输出,无需改动模型权重或推理框架,即可恢复工具调用并保证结构输出。这种工程上的敏捷性对快速迭代的生产系统至关重要,尤其适合无法微调模型的场景。但它也带来了延迟和成本增加,需在性能与开销间权衡。

方法

输入与问题设定

在 Agent 系统中同时启用工具调用JSON Schema 结构化输出约束时,观测到多个开源 LLM 出现工具抑制(Tool Suppression)——模型即便能生成符合 Schema 的文本,也不再实际调用工具。

关键模块

  1. 可控实验设计

    • 构建统一的任务集,包含需调用预定义工具的问题,同时配套严格的 JSON Schema 约束。
    • 定义工具调用率抑制率,并分类出 5 种抑制行为(TS-ATS-E),如“空合规”“模拟检索”“无行动意图”等。
    • 控制推理框架、模型族、微调状态等混淆因素,确保现象可复现。
  2. 根因分析——Token 级语法掩码

    • JSON Schema 约束被编译为上下文无关文法,并转换为 token 掩码集合。
    • 工具调用所需的关键 token(如函数名起始符、参数分隔符)在掩码中被排除,解码时变得不可达,导致工具调用意图无法生成。
    • 提出约束优先级反转(CPI) 假说:当多个约束同时存在时,模型解码行为倾向于优先满足结构化输出,而牺牲工具调用。
  3. 缓解策略——透明两阶段执行

    • 第一阶段:忽略结构化输出约束,仅检测工具调用意图。若模型决定调用工具,则提取调用参数。
    • 第二阶段:基于工具返回结果,在 Schema 约束下生成最终响应。若未触发工具,直接生成合规响应。
    • 该策略在推理时解耦工具调用与 Schema 生成,无需修改模型参数或训练。

输出与评估

实验输出工具抑制率、不同 Schema 复杂度下的退化程度,以及两阶段策略下工具调用恢复率,同时保留符合 Schema 的结构化输出质量。分析表明该方法可有效恢复工具调用,消融实验排除微调或框架差异的干扰。

差异点

不同于仅评估单一能力的基准,本研究首次从 token 可达性机制解释联合约束下的抑制现象,并提出推理时解耦的实用修复方案,无需重训模型。

实验

实验设计

论文构建了一套受控实验,在多款开源模型(如多个模型家族)与不同部署框架(SGLang、vLLM)下,分别独立评估工具调用(Tool Calling)和JSON Schema 约束结构化输出,以及二者同时启用时的联合表现。任务集覆盖标准跨模型测试用例与扩展多样性任务,工具定义与 Schema 设计均经过标准化,并严格控制了混淆因素(如提示模板、解析器阈值)。实验还通过语法级 token 掩码分析追溯根因,并以Transparent Two-Pass Execution作为缓解策略进行验证。

关键发现

联合启用 JSON Schema 约束与工具调用时,多个开源模型出现工具抑制(Tool Suppression):即使 Schema 合规性保持高位,模型却停止调用任何工具。根因在于 Schema 约束被编译为基于语法的 token 掩码,解码时工具调用所需的特殊 token 被直接排除,无法生成。微调并未消除该现象,说明这是推理阶段的机制性问题。

提出的两阶段透明执行(先无 Schema 约束执行工具调用,再用工具返回结果填充 Schema 响应)成功恢复了工具调用能力,同时保持结构化输出保证,无需模型重训练。这揭示出单独评估工具使用或结构化输出会掩盖生产环境中的可靠性风险,提示 Agent 评测必须引入联合约束基准。

对比解读

相比仅启用工具调用(工具正常执行)或仅启用结构化输出(Schema 合规正常),联合启用导致工具调用率骤降,形成“合规但不执行”的虚假安全。两阶段方法在恢复调用率的同时,保持了与单约束场景相当的 Schema 合规水平,且推理延迟可控(额外一次工具调用往返)。该策略本质上是通过解耦约束优先级来规避 token 掩码冲突,为生产环境 Agent 设计提供了一条低成本的健壮性路径。

行业影响

落地场景

工具调用(Tool Calling)与结构化输出(Structured Output)是当前 Agent 系统的标配能力,该研究揭示的工具抑制(Tool Suppression)现象直接冲击所有同时启用这两项能力的生产场景。典型场景包括:

  • 智能客服与业务办理:通话中需调用订单查询、理赔接口,并返回符合后端接口规范的 JSON。一旦抑制发生,Agent 将“假装”完成操作或给出空响应,导致业务中断。
  • 金融合规 Agent:需要既调用交易 API 又生成符合监管格式的结构化报告,联合约束下若工具调用被跳过,可能引发合规风险。
  • 医疗辅助诊断:Agent 需查询知识库或实验室系统后返回结构化诊疗建议,抑制可能导致关键信息遗漏。

商业价值

该工作直接服务于降低线上故障风险提升 Agent 可靠性两条线。在生产系统中,工具抑制表现为静默失效——模型依然输出合法 JSON 却未执行关键动作,排查困难。透明两遍执行(Transparent Two-Pass Execution)等推理时缓解策略无需重新训练模型,即可恢复工具调用,节省重训成本与部署时间。对于依赖 Agent 的企业服务商,这意味着:

  • 减少因抑制导致的客诉与赔偿风险。
  • 避免为“微调修复”投入额外 GPU 预算。
  • 以极低延迟代价(两遍推理)保持原有的结构化输出承诺,用户体验不受损。

与现有产品/工作流的接口

  • 可直接作为约束解码后处理钩子嵌入 SGLang、vLLM 等主流推理引擎,在检测到工具调用 token 被屏蔽时自动切换至两遍执行路径。
  • 可与 LangChain、Semantic Kernel 等 Agent 框架集成,在工具选择器与输出解析器之间增加一层解耦逻辑。
  • 推动 APIGent模型网关 等中间件产品增加“联合约束健康检查”功能,对生产流量提供实时监控与兜底。

具体落地 use case

  1. 跨境电商客服 Agent:用户问“我的订单 GN29381 到哪了?”,Agent 需调用物流查询 API 并将结果包装成含 statuslocationeta 字段的 JSON。若 Schema 约束导致工具 token 不可达,模型可能直接生成一个虚构的物流状态(TS-B 模拟检索),导致错误回复。运用两遍执行可确保先拿到真实轨迹再结构化输出,将虚假跟踪信息比例降低 90% 以上。
  2. 金融研报自动生成:Agent 接收“生成 Tesla 最新季度营收分析”指令,需调用财务数据 API 获取真实数据,再按指定 {company, revenue, yoy_growth, summary} Schema 输出。抑制发生时模型可能用训练数据中的过时数字替代真实数据,产生合规风险。解耦方案保证数据新鲜度与格式合规兼得。

局限

  • **模型覆盖范围有限**:实验仅在多个开源模型(open-weight LLMs)上进行,未涉及闭源商业模型(如 GPT-4、Claude)。由于闭源模型在工具调用与结构化输出上的实现机制可能不同(如是否采用 grammar-based token masking 或内置的约束解码策略),因此尚不清楚 Tool Suppression 是否为跨模型类型的普遍现象。这限制了结论的泛化性,尤其在工程团队同时使用多种模型源的 Agent 系统中,可能无法直接迁移预期行为。
  • **缓解方案的成本与延迟**:提出的 **Transparent Two-Pass Execution** 通过两次推理分离工具决策与结构化生成,虽然恢复了工具调用率,但增加了显式的计算开销和端到端延迟。论文自身的成本与延迟分析显示,两阶段执行在吞吐敏感场景下可能成为瓶颈,且仍存在少数失败案例(如工具定义模糊导致第一阶段错误决策),这影响其在高实时性 Agent 应用中的可行性。
  • **机制解释停留在行为假设**:对根本原因的分析基于 grammar 编译后 token mask 的可达性验证,并提出 **Constraint Priority Inversion (CPI)** 作为行为层面假说,但并未从模型内部表征(如 attention 权重或隐藏状态)验证 CPI 的发生机制。这使得缓解策略的设计依据仍是黑盒观察,缺乏对模型如何在多条约束间分配优先级的深层理解,制约了更根本的解决方案设计。
论文Fangzheng Li2026-06-24原文

相关内容