新模型反不如旧模型：Claude 工具调用在第三方编码工具中表现变差

知名开发者 Armin Ronacher 近日在使用自研编码工具 Pi 时发现一个反常现象：Anthropic 最新的旗舰模型 Claude Opus 4.8 与 Sonnet 5 在调用 Pi 自定义的 edit 工具时，会在嵌套的 edits[] 数组中凭空「发明」一些并不存在的字段名，导致工具调用因不符合 schema 被直接拒绝、要求重试。令人意外的是，出问题的并非小模型，恰恰是 Anthropic 当前的 SOTA 模型——而更早版本的 Claude 反而没有这个问题。

问题并非偶发，而是新版模型普遍存在

Ronacher 表示，模型偶尔输出格式错误的工具调用并不稀奇，常见于参数规模较小的模型。但这次的反常之处在于，错误率随着模型迭代不降反升：Opus 4.8 和 Sonnet 5 都复现了同样的问题，旧版模型则一切正常。换言之，Claude 家族中最强的两个成员，在面对 Pi 这类第三方工具的 schema 时，表现反而不如自己的「前辈」。

原因推测：RL 训练过度偏向 Claude Code 内置工具

Ronacher 给出的假设是：Anthropic 很可能在新模型的强化学习阶段，专门针对 Claude Code 内置的 edit 工具做了训练与优化。Claude Code 使用的 edit 机制基于 search/replace 模式，而 OpenAI 的 Codex 则采用 apply_patch 机制——后者也曾公开讨论过模型针对自家工具的训练策略。这种「模型—宿主工具」紧绑定的优化，对第三方编码 Agent 来说是个坏消息：它们自定义的 edit 工具被错误调用的概率会显著上升。

对生态的启示

这一案例暴露出当前 LLM 工具调用层面的一个深层矛盾：模型厂商越来越倾向于把自家编码 Agent 的工具格式作为训练目标，这虽然能提升官方产品的体验，却可能牺牲第三方框架的兼容性。一个可能的解决方向是，让第三方编码工具同时实现多套 edit 方案（search/replace、apply_patch 等），并根据用户选择的底层模型自动切换到表现最佳的那一套。但这一方案本身也意味着重复造轮子和更高的维护成本。如何在模型优化与生态开放之间取得平衡，将是接下来一段时间编码 Agent 开发者必须面对的现实问题。