Jesse Donkervliet、Junhao Li · Ubicloud · 阅读原文
原始来源：Jesse Donkervliet、Junhao Li · Ubicloud
发现渠道：Hacker News · LLM
Agent 调用工具时，除了选对动作，还要按接口约定写出工具名、参数类型和必填字段。Ubicloud 在 Kimi K2.6、vLLM 0.28 的部署中测得约92%的工具调用符合 schema，也就是参数结构规范。一次格式错误会带来重试和错误消息，后续对话还可能继续受这些消息影响。
团队采用约束解码：在每一步生成前，根据当前所在的工具调用阶段和结构规范，屏蔽不合法的下一个 token。例如工具名只能从已声明工具中选择，整数参数不能直接写成任意字符串。实现依靠 XGrammar 的结构标签，将普通语言生成和受约束的调用部分区分开；它限制输出形状，不负责判断用户真正想做什么。
这个能力曾在版本升级后“失效”，符合结构的比例回落到约91%。作者排查后认为，并非约束算法坏了，而是上游改变了未明确启用约束时的默认行为。vLLM 面向很多模型，强制套用不匹配的语法可能损害生成；后来提供服务端严格程度选项，让运营者明确控制。
Ubicloud 在启用约束后，用 K2VV 的2,000条请求重新检查所服务的 Kimi、DeepSeek 版本，报告100%的结构合规率。这个数字限于其测试与配置，不是100%的工具选择正确率，更不是所有 JSON Schema 条件都已被所有解析器支持。文章发布于10月20日，本期由近期讨论重新发现。
可信度 65 · 重要性 86 · 新颖度 75
技术与主题
Agent 系统 · AI 编程 · 系统与效率 · Tool Calling · Constrained Decoding · JSON Schema
BugenZhao
vLLM维护讨论，区分调用格式与参数约束。
忠实转述（非原句）：他指出严格程度有不同含义：工具调用的外层格式与每个工具的参数规范不能混为一谈。如果只给一个工具开启strict，就连带约束另一个未设置的工具，会造成意外行为；他要求把各工具的规则与服务端最低严格程度分别定义。
Aurornis
文章HN讨论；针对标题与修复范围的批评。
忠实转述（非原句）：他提醒，vLLM早已有约束解码能力，标题容易让人误以为是新发明；本次更值得肯定的是持续测试及时发现默认行为变化。
jesdo
作者在同一讨论中的回应，与Ubicloud原文同组。
忠实转述（非原句）：他认可这一澄清，同时补充历史阶段确实需要改代码才能让Kimi正确工作；上游后来加入能力后，当前版本才可通过把tool-strict-level设为parameter解决。
编辑评读
这里值得改变的判断，是不要把接口失败自动归因于模型能力不足。输出由权重、聊天模板、解析器和解码策略共同产生；升级其中一层，就可能让相同模型看起来退步。先按错误类型拆分日志：不能解析、字段不符、参数值不合理和动作选择错误，应分别寻找原因。只有前两类才直接对应本次改法。例如，调用没有被触发和调用被触发但参数不合规，分母不同；只看后者达到100%，仍可能漏掉应该调用却没调用的情况。
vLLM 维护者在相关讨论中强调模型兼容性与多轮测试，Ubicloud 则可以针对有限模型明确启用约束。两种选择服务不同范围，没有必要把默认宽松简单视为疏忽。迁移时可固定模型、请求样本与版本，比较结构合规、实际任务完成和首轮语法编译等待；工具执行端仍要校验参数与权限。本期只读代码讨论与测试说明，没有运行这些服务测试。
需要留意
- 100%指作者在特定K2VV样本上的结构合规，不表示语义或权限正确；上游兼容性讨论解释默认值取舍。