事件与背景

2026 年 7 月 4 日，Python 生态知名开发者、Flask / Jinja2 / Click 的创建者 Armin Ronacher 在其博客上发表了一篇题为 《Better Models: Worse Tools》 的深度技术分析，记录了他连续两天追踪的一个令人不安的发现：Anthropic 最新的旗舰模型（Opus 4.8 和 Sonnet 5）在调用非 Claude Code 的工具 schema 时，表现出明显的退化——发明额外字段、伪造参数名，而较早的模型反而表现正常。

这一发现迅速在 HackerNews 上引发广泛讨论（90+ points，30+ 评论），并触动了当前 AI 编码工具生态中最敏感的一个核心问题：当基础模型的后训练过程被”锁定”在某一个具体的工具框架（Claude Code）上时，所有第三方工具和替代 harness 的兼容性是否会系统性退化？

相关来源：

• Better Models: Worse Tools — Armin Ronacher’s Thoughts and Writings
• Pi issue #6278 — 原始触发问题的报告
• HackerNews 讨论
• Anthropic 文本编辑工具文档（不同于 Claude Code 实际使用的 schema）

为什么现在重要

1. 这是”开源工具兼容性”的预警信号

Armin 的实验非常清晰：在 Pi（他所在的团队开发的代码编辑工具）中，Claude Opus 4.8 / Sonnet 5 在调用 edit 工具时，会在 edits[] 数组的每个条目末端凭空添加如 requireUnique、matchCase、oldText2、newText2、type、id、in_file、forceMatchCount 等根本不在 schema 内的字段。Pi 的验证器拒绝了这些调用，导致反复重试。这些模型的”前代”版本（如 Opus 4.5）却能完美适配。

影响判断：如果你的 AI 工具不兼容 Claude Code 的默认 schema，你在使用最新 Anthropic 模型时可能反而会遭遇更高的失败率。

2. 后训练的”隐形成本”暴露了

Armin 提出了一个强有力的假设：Anthropic 在 RLHF/强化学习阶段，模型是通过 Claude Code harness 的反馈信号进行训练的。而 Claude Code 的 harness 极其宽容——它会自动过滤未知 key、建立参数别名（如同时接受 old_str 和 old_string）、修复 Unicode 转义、甚至从明文文本中嗅探工具调用标记。这意味着模型在训练过程中几乎从来不会因为发明额外字段而受到负向奖励。

影响判断：RL 优化如果在一个过于”宽容”的环境中进行，模型会学到”多写几个字段没关系”，却学不会”严格按照 schema 执行”。这种”宽容训练”导致工具调用松垮化（slop），而并非模型变聪明了。

3. 不是随机噪声，而是系统性退化

Armin 特别强调：这不是偶发错误。在合适的上下文（多轮对话后，模型已经读取文件并设计了多行编辑），Opus 4.8 的失败率高达 20%。即便去除 thinking block 也仅能降低一半。而开启 Anthropic 的 strict 模式可以消除问题——但 strict 模式自身对工具定义的复杂度有限制，Claude Code 甚至因为 API 请求会超限而放弃使用它。

影响判断：这揭示了一个讽刺现实——Anthropic 的”严格约束”功能其实能解决问题，但因为它对工具 schema 有复杂度限制，导致 Anthropic 自己的产品（Claude Code）都没有启用它。闭环自洽，但对外部开发者极不友好。

4. 工具 schema 不再是”中立接口”

Armin 的结论尖锐但客观：“工具 schema 存在一个分布——有些形状靠近模型在后训练中看到的分布中心，有些远离。Claude Code 的平铺式编辑接口（file_path + old_string + new_string + replace_all）是训练分布的中心。任何偏离这个形状的 schema 都可能遭受带惩罚。”

影响判断：这意味着第三方 AI 开发工具的 API 设计正在被上游模型提供商的产品话语权所绑架。如果你设计的工具参数结构不”像”Claude Code 的接口，你的工具在最新模型上表现会更差。

5. Codex 方面也出现了类似问题

同日，HackerNews 上另一条热门帖子涉及 OpenAI Codex 的 GPT-5.5 模型——用户报告”推理 token 聚类可能导致性能退化”。虽然 Armin 在文章中提到 Codex 模型（截至 5.5）尚未出现类似的 schema 退化问题，但这依然表明前沿模型在工具调用一致性上的挑战是普遍存在的。

影响判断：模型越强大、训练流程越复杂，工具调用的精确性反而可能成为一个被低估的瓶颈。

工程师/产品人今天能做什么

1. 检查你的工具 schema 是否偏离了”主流形状”

如果你的 AI Agent 需要调用自定义工具（尤其是编辑/文件操作类），请审视其参数结构：

• 是否使用了嵌套数组/对象？（如 Pi 的 edits[] 数组）
• 参数是否全部扁平化？（如 Claude Code 的 old_string + new_string）
• 是否有 replace_all 这样的可选标志位？

操作：如果你的工具 schema 远离 Claude Code 的形状，建议在 Anthropic 模型上做压力测试——特别是多轮对话后，看模型是否会产出 schema 外的字段。

2. 在你的 Harness 中加入”宽容层”

Armin 的文章揭示了一个重要工程实践：你的 AI 工具客户端应该对模型输出的工具调用做出宽容处理。Claude Code 的做法包括：

• 自动过滤未知 key
• 参数别名映射（old_str → old_string）
• Unicode 修复（broken \uXXXX sequences）
• 从文本中嗅探工具调用标记

操作：如果你在构建 Agent 工具链，花一天时间实现这些”slop repair”逻辑。这不仅仅是防错，而是对抗模型后训练偏差的唯一工程手段。

3. 启用 Strict Mode 并测试复杂度边界

Anthropic 提供 strict 模式（语法约束解码），它能在 token 采样层面防止模型输出 schema 外的字段。但由于复杂度限制，很多工具无法启用它。

操作：在你当前用的 Anthropic 模型上测试 strict 模式是否可行——简化你的工具定义直到通过。如果可行，务必启用。这是目前已知消除该问题的最可靠方式。

4. 不要假设”更好的模型自动适配更好的工具”

Armin 的亲身经历说明：最新模型不一定是你工具的最佳后端。如果你在维护一个 AI 编码工具（如 Pi、Aider、Continue 等），应该建立一个模型回归测试矩阵，主要测试工具调用模式兼容性，而不仅仅是代码生成质量。

操作：在你的 CI 中加入自动化的多模型工具调用测试——发送预先构建的多轮对话上下文，验证返回的工具调用是否符合 schema，而不只是单轮调用。

5. 关注 Anthropic 的开源动向（或缺乏）

文章中反复提及的一个痛点：Claude Code 是闭源的。我们无法知道它的 RL 环境具体做了什么，也无法了解它的工具调用容错策略的全部细节。OpenAI 在这方面有所改善（发布了 gpt-oss 和 harmony 格式），但 Anthropic 仍然是一个黑箱。

操作：如果你的产品重度依赖 Anthropic 模型，请密切追踪 Claude Code 的更新和逆向分析。每一次 Claude Code 的更新都可能改变模型的工具调用行为，影响你产品的可靠性。

待观察

1. GPT-5.5 Codex 的”推理 token 聚类”问题：同日 HN 上出现了 Codex 类似问题的报告（来自用户 maille），值得关注是否与工具调用退化有关，或是一个独立的推理效率问题。

2. 其他 harness（Aider、Continue）是否会遇到类似退化：如果 Armin 的分析是正确的，那么所有使用非 Claude Code 工具 schema 的 AI 编码工具都应该检查自己是否受到影响。这可能是一个系统性、全行业的问题。

3. Anthropic 是否会调整后训练方法：如果这个问题在整个开发者社区获得足够关注，Anthropic 可能会在后续版本的 RL 训练中引入 schema 多样性——即让模型在多个不同的工具框架上进行训练，而非仅针对 Claude Code。但以当前产品优先的战略来看，短期内主动改变的可能性不大。