更强的模型 更糟的工具：Claude工具调用异常分析

开源工具Pi近期收到一组与Claude调用相关的失败报告,知名开发者Armin Ronacher对此做了深度排查。他发现新版Claude模型,包括Opus 4.8与Sonnet 5,在调用Pi编辑工具时会在嵌套edits数组里追加额外字段,例如in_file、type、requireUnique、oldText2等。Pi的schema只接受严格oldText与newText组合,任何多余字段都会被结构校验拒绝,模型于是收到错误反馈并重试,进入反复循环。更糟糕的是,这种现象并非偶发,而是可以稳定复现的失败模式。

有趣的现象在于实际编辑内容,即模型要替换的旧文本与新文本,始终字节级正确,问题仅出现在对象末尾被追加的乱码字段。这意味着模型准确理解了任务,但在序列化工具调用时偏离了schema约束。更值得警觉的是失败高度依赖上下文:用户单独发出编辑这个文件这类单轮指令时,问题不重现;一旦进入读取文件、诊断问题、组合多行编辑这类Agent历史,失败率显著上升。Ronacher借助Petr Baudis的会话历史复现,发现持续会话时Opus 4.8的失败率约为百分之二十。

通过进一步实验,他总结两条可立即落地的缓解措施:其一剔除历史中的thinking blocks,失败率立即下降一半;其二开启严格工具调用,失败彻底归零。Ronacher给出的最强假设是,这不是随机退化,而是Claude Code内部强化学习环境留下的训练产物。Anthropic的Claude Code并非开源,RL环境的真实分布外界无法验证,但可以推断下游工具schema与训练分布的偏离会直接转化为失败率。训练分布越专属,模型对通用工具的容忍度就越低。

对工程团队而言,这次事件是一记警钟:模型效果与harness严谨度不能划等号。当模型能力快速提升时,harness必须用语法感知解码、严格约束解码等手段给schema兜底,把模型与工具之间那层隐性契约重新写进代码。这也意味着依赖第三方闭源Agent的企业,不能再假设工具调用永远稳定,必须自行编写测试用例覆盖典型工作流。更强模型的副作用之一,是把工具可靠性问题从内部隐患推到外部事故,而代价由工程团队承担。