post cover

更好的模型，更烂的工具：Claude Opus 4.8 的「工具退化」谜题（2026-07-07）

本文为翻译/转载，原文使用 CC BY-NC-SA 4.0 协议发布。 原文作者：Simon Willison 原文标题：Better Models: Worse Tools 原文链接：https://simonwillison.net/2026/Jul/4/better-models-worse-tools/ 原文发布：2026-07-04 本博客不参与任何商业变现（含 ads / 付费 / affiliate），本译文遵循 CC BY-NC-SA 4.0 条款发布。

【译者按】

如果你正在用 Claude Code、Cursor 或任何第三方 AI agent 框架（比如 Pi、OpenHands、Continue.dev），并觉得「怎么新版模型有些地方反而变蠢了」——你不是一个人。

Flask 和 Click 的创造者 Armin Ronacher（活跃于 Python 生态的标志性人物）在 Pi 框架的开发过程中发现了一个令人不安的现象：Claude Opus 4.8 和 Sonnet 5 在调用自定义工具时，会在参数里塞入 schema 里根本不存在的字段，导致 Pi 拒绝执行并要求重试。更诡异的是，旧模型（Opus 3、Sonnet 4 等）反而没有这个问题。

Simon Willison 敏锐地指出了背后的可能原因：Anthropic 很可能通过强化学习（RL）让新模型在 Claude Code 内建的专有编辑工具上表现更好——但副作用是，当这些模型被用在别的 agent 框架里时，它们的「工具调用模式」已经学歪了。

这篇短文对中文圈的 AI 工具开发者和用户有三个特别的价值：①揭示了一个被忽视的问题——模型厂商对特定工具的过度优化可能损害通用性；②引发了一个核心争议——第三方 agent 框架是不是该为不同模型适配不同的工具接口？③对正在开发 agent 框架的团队（如字节的 Coze、阿里的百炼、各种开源 agent 项目）有直接的工程启示。

【正文】

Better Models: Worse Tools。Armin 报告了他在 Pi 框架上遇到的一个诡异问题：

简而言之，较新的 Claude 模型在调用 Pi 的编辑工具时，会在嵌套的 edits[] 数组里传入额外的不存在的字段。不是 Haiku 之类的小模型——是 Opus 4.8。编辑本身通常是正确的，但参数不符合 schema 定义，模型凭空发明了不存在的键名，Pi 因此拒绝该工具调用并要求重试。

这本身并不特别令人意外——模型偶尔会发出格式有问题的工具调用，尤其是小模型。真正让我吃惊的是，这个问题在更新的 Anthropic 模型上反而更严重：Opus 4.8 和 Sonnet 5 都有此现象，而旧模型却没有。换句话说，该系列的最先进模型在处理这个特定的工具 schema 时，表现得还不如它们的老版本。

Armin 推测，这是因为较新的 Anthropic 模型被专门训练（可能通过强化学习）以更好地使用 Claude Code 内建的编辑工具。这就产生了一个不幸的副作用：其他编码工具框架（比如 Pi）会发现，它们的自定义编辑工具反而更容易被错误地调用。

Claude 的编辑工具使用搜索替换（search-and-replace）机制。OpenAI 的 Codex 则使用 apply_patch 机制，OpenAI 也讨论过他们是怎样训练模型有效使用该工具的。

那么问题来了：像 Pi 这样的第三方编码工具框架，是不是应该实现多个编辑工具，根据用户选择的底层模型，选择性能最好的那个？

【译者注】

  1. 关于 Pi：Pi 是 Armin Ronacher（Flask、Click、Jinja2 的作者）正在开发的一款 Python AI 编码代理工具。它类似于 Claude Code 或 Codex Desktop，但完全基于开源模型和自定义工具链构建。Armin 在开发 Pi 的过程中发现了这个工具退化问题，促使他写了原始博文。

  2. 为什么新模型「越练越差」：传统上我们认为「模型越强，工具调用越准」。但这里的问题是模型厂商对特定工具的过度优化。Anthropic 为了让 Claude Code 中的 str_replace_editor 工具表现得更好，通过 RL 训练让模型学会了调用该工具的一些「隐含模式」——但这些模式可能并不符合第三方工具的 schema。这就好比一个人被训练得特别擅长用某个特定品牌的螺丝刀，结果拿到另一个品牌的螺丝刀时反而不知道怎么用了，还会往螺丝刀上绑一些原厂没有的附件。

  3. 工具接口「军备竞赛」的启示：这个现象可能不仅限于 Anthropic。如果每家模型厂商都在内部 RL 中针对自己的专属工具做了优化，那第三方 agent 框架就面临一个尴尬的选择：要么为每个模型厂商都实现一套仿真的「原生工具接口」，要么接受新模型在自己的框架上表现越来越差的现实。这实际上是在 agent 生态中制造了一种隐形的供应商锁定——即使模型本身是通用的 API，工具调用的「习惯」已经被定死了。

  4. 对中文圈 agent 开发者的意义：国内正在大量构建 agent 框架（Coze、百炼、Dify、FastGPT 等）。如果这些框架对接的是 Anthropic/OpenAI 的通用 API，但底层模型的工具调用行为在版本间发生变化，团队需要建立系统的工具调用回归测试机制——在升级模型版本时，不只是测回答质量，还要专门验证工具调用的 schema 合规性。

【延伸阅读】