你理所当然地认为一个更新、更强的模型应该在所有方面都比旧模型更好。

毕竟 SOTA 模型在 Frontier-Bench 上刷了新高，在 CursorBench 上逼近 Fable 5，你花更贵的 API 费用，理所应当得到更好的 tool calling 能力。

然后你发现 Opus 4.8 调用你的编辑工具时，凭空发明了 schema 里不存在的字段。

不是 Haiku，不是 Sonnet 3.5，是最新最强的 Opus 4.8 和 Sonnet 5。旧模型反而没问题。

这就是 Armin Ronacher 在开发 Pi 编辑器时撞上的反直觉 bug——一个足以让所有第三方 Coding Harness 重新审视自己工具设计的工程陷阱。

〇、元问题：模型的目标函数不是你的目标函数

Armin 的发现过程极其简单。Pi 有一个 edit 工具，schema 定义得清清楚楚。旧模型——Claude 3.5 Sonnet、更早的 Opus——调用这个工具时规规矩矩，字段名、类型、结构都按 schema 来。

到了 Opus 4.8 和 Sonnet 5，开始出问题。

模型在 edits[] 数组里凭空加入 schema 中不存在的字段。编辑本身是对的，但参数不匹配 schema，Pi 只能拒绝请求，让模型重试。

Armin 的原话是：

“What surprised me is that this is getting worse with newer Anthropic models.”

翻译过来就是：让我震惊的不是模型会生成格式错误的 tool call，而是这件事在新模型上变得比旧模型更差。

这是一个非常不正常的退化方向。

一、退化链条：RL 训练如何产生"工具偏好"

Armin 给出了一个假设，这个假设目前没有被 Anthropic 官方证实，但从工程逻辑上完全说得通。

新模型经过了针对 Claude Code 内置工具的强化学习训练。

Claude Code 的 edit 工具使用的是 search_and_replace 模式：找到旧文本，替换为新文本。这是 Claude Code 内部的一种特定工具协议。

而 Pi 使用的是自己的 edit 工具，虽然功能类似，但 schema 结构不同。新模型在 RL 训练中被反复奖励"正确使用 Claude Code 的 edit 工具"的行为，导致它在面对其他编辑工具时，也倾向于往 Claude Code 那套 schema 上靠。

经验一：RL 训练越聚焦于某个特定工具集，模型在第三方工具上的泛化能力就越差。这不是 bug，是 feature——只是这个 feature 对 Anthropic 有利，对你没利。

Simon Willison 在转发 Armin 的博客时补充了一个尖锐的观察：

“Does this mean third-party coding harnesses like Pi should implement multiple edit tools just so they can use the one with the best performance for the underlying model the user has selected?”

翻译：第三方工具是不是要同时实现多套编辑工具，只为适配不同模型对不同工具 schema 的偏好？

这听起来荒谬，但它正在变成工程现实。

二、同样的故事，不同的玩家

这不是 Anthropic 独有的问题。OpenAI 的 Codex 使用 apply_patch 机制来做编辑，而 OpenAI 同样在训练中优化模型对这个工具的使用。

所以同样的退化链条也在发生：GPT-5 在 Codex 的 apply_patch 上表现完美，但如果你给它一个自定义的 edit 工具，它可能会在边缘情况下产生不符合 schema 的输出。

每一个模型厂商都在为自己的旗舰产品优化 tool calling，而优化方向天然地和第三方工具的兼容性冲突。

经验二：Tool Calling 不是标准件。它正在变成一个厂商锁定手段——你用我的工具协议，就有最好的体验；你自己设计协议，就要忍受退化。

更扎心的是，这个问题不会因为模型"变聪明"而自动解决。恰恰相反——模型越强，RL 训练越聚焦，对特定工具协议的偏好越深。

三、如果你也在开发自己的 Coding Harness

Armin 和 Simon 的讨论揭示了几个应对策略。

策略一：检测模型版本，动态切换工具 schema。

如果你的 harness 支持多个模型，为不同的模型家族准备不同的工具定义。给 Claude 系列的工具定义尽量接近 Claude Code 的内置工具 schema；给 OpenAI 系列的尽量接近 Codex 的工具 schema。

这本质上是把兼容性成本从模型侧转移到了 harness 侧。 短期可行，长期维护负担不小。

策略二：在 tool call 校验层加入模糊匹配。

当模型返回的 tool call 包含未知字段时，不是直接拒绝，而是尝试判断"模型是不是在套用其他工具的 schema"。如果是，忽略多余字段，只取匹配的部分。

这个策略的 tradeoff 很明显：你在用容忍度换取成功率，但容忍度本身就是精度损失。

策略三：接受重试成本。

让模型第一次调用失败后被拒绝，然后在错误消息中明确告知 schema 的正确格式。这个策略看起来笨拙，但反而是目前最稳定的方案。

Claude 和 GPT 在收到明确的 schema 错误后，通常能在 1-2 次重试内修正。代价是多一次 API 调用，但至少不会引入额外的复杂度。

经验三：在 Agent 工程中，「重试」不是一个 workaround，而是一个被低估的架构模式。模型不是确定性系统，给它一次修正的机会往往比事前预防更经济。

四、这个问题的深层含义

回到元问题：Tool Calling 正在从开放标准退化为平台专属协议

模型的目标函数不是你的目标函数。

Anthropic 优化 Claude 的目标是让它在 Claude Code 里表现好。OpenAI 优化 GPT 的目标是让它在 Codex 里表现好。

你的 Coding Harness 是第三方的。从厂商的角度看，你的工具 schema 对齐问题不是他们的优先级——除非你有足够的用户量，让这个问题变成他们的商业顾虑。

Simon 问的那个问题——“第三方 harness 是不是应该实现多套编辑工具”——其实已经暗示了一个更大的趋势：

Tool Calling 协议正在从开放标准退化为平台专属协议。

就像 iOS 的 UIKit 和 Android 的 Material Design——不是你不能跨平台，但"最优体验"永远是绑定在特定平台上的。

同理，Claude Code 的 edit 工具 = Anthropic 的 UIKit。你不会指望一个 iOS app 在 Android 上跑得一样好。

总结

决策回答的根本问题
动态切换工具 schema兼容性成本谁来承担？
模糊匹配校验容忍度和成功率怎么平衡？
接受重试成本哪种架构复杂度更值得？
接受平台分化这是一个能解决的问题还是该适应的事实？

Armin 的这个发现值得每一个做 Agent 工具链的人停下来想一想：你花在调 tool schema 上的时间，到底是在解决一个技术问题，还是在对抗一个商业决策？

如果你是一个人或者一个小团队在做 Coding Harness，最务实的答案是：别对抗。让自己兼容，接受重试，把精力花在工具本身的价值上。

🎯 正在用 Claude / GPT 搭建自己的 Agent 系统？

  • 📬 关注「全栈之巅 - 梦兽编程」，获取 Agent 工程实践第一手经验
  • 🔧 访问 Rex 工具集 发现更多 AI 开发工具

参考来源：