现代 agent 系统有两大核心能力经常被同时用到：工具调用（tool calling，让模型决定调用哪个外部工具、传什么参数）和结构化输出（structured output，强制模型按指定的 JSON Schema 格式输出）。前者让 agent 能行动，后者让 agent 的输出能被下游程序稳定解析。在真实系统里，这两者经常需要一起开——既要 agent 调工具，又要它的输出严格符合 schema。 但这篇论文指出，这两个能力'同时启用'时的相互作用，此前一直研究不足。大家分别研究过工具调用、也分别研究过结构化输出，却很少有人系统地问：把它们叠在一起会发生什么？论文报告了一个在生产 agent 系统里观察到的、可复现的现象，并给它起了个贴切的名字——'约束税'（constraint tax）。 现象本身很具体：当工具调用和 JSON Schema 约束被同时开启时，多个开源权重（open-weight）LLM 的工具调用能力会被抑制（suppressed）。也就是说，本来能正常调工具的模型，一旦再叠加上'输出必须符合某个 JSON schema'的约束，它调用工具的行为就变差了——该调的工具不调了，或者调用质量下降。结构化输出这个约束，仿佛对工具调用能力征了一笔'税'。 一个合理的直觉解释是：结构化输出约束会通过约束解码（constrained decoding）等机制，强行把模型的输出限制在符合 schema 的 token 空间里；而工具调用本身也依赖模型生成特定结构的输出。当两套结构化约束叠加、相互打架时，约束解码可能压制了模型本来想发起工具调用的倾向。论文强调这不是个例，而是跨多个开源模型可复现的现象——这把它从'某个模型的怪癖'升格成了一个值得正视的系统性交互问题。 为什么值得关注：工具调用 + 结构化输出几乎是生产级 agent 的标配组合，而这篇说明这个标配组合本身藏着一个不显眼的坑。很多团队可能正在不知情地为它付'约束税'——以为是模型工具调用能力不行，实际上是被同时开启的 schema 约束拖累了。把这个因果关系点破，本身就有直接的排障价值。 影响层面，对做 agent 工程、同时依赖 function calling 和结构化输出的人，这是一个实用的预警：如果你的 agent 在开了 JSON schema 约束后工具调用变得不靠谱，问题可能不在模型本身，而在两个约束的冲突。解法方向可能是分阶段处理（先让模型自由决定工具调用，再单独施加格式约束），而不是一股脑同时开。 局限要标注：现象主要在开源权重模型上观察到，闭源模型（其工具调用和结构化输出可能有不同实现）是否同样受影响、受影响程度如何，需要看完整论文；'抑制'的量级有多大、在不同 schema 复杂度下如何变化，也决定了这笔'税'在你的场景里到底重不重。