当更好的模型变成更差的工具，问题可能出在训练本身。
一、一个让人抓狂的Bug
想象一下：你让一个AI编辑文件，它完美地找到了要替换的文本，精准地写入了新内容——然后在JSON末尾多塞了一个莫名其妙的字段。不是偶尔出错，而是越新的模型，犯这种低级错误的概率越高。
这不是什么小模型的胡闹。Opus 4.8，Anthropic最强的模型，在调用Pi（一个开源AI编码工具）的编辑工具时，经常在edits[]数组里的对象末尾凭空编造字段。requireUnique、oldText2、matchCase、in_file……仿佛一个喝醉了的数据工程师在键盘上胡乱敲击。
更诡异的是，这些字段里的实际内容完全正确——oldText和newText字节级精确。模型明明知道要做什么，只是在结束之前忍不住添了一句废话。
这就像是，一个满分作文选手在交卷前非要画个涂鸦。
二、工具调用，其实很"糙"
要理解这个bug有多奇怪，得先看看LLM是怎么调用工具的。
你可能以为模型内部有个优雅的JSON解析器——定义好Schema，模型生成合法JSON，然后执行。但现实要粗糙得多：
工具调用是在文本流中通过特殊标记完成的。
Anthropic模型的内部工作方式大致是这样的：模型收到系统提示、对话历史和工具列表，服务器把这些揉成一个巨大的提示，里面塞满了特殊标记token。模型在生成文本的过程中，在某个时刻输出类似<antml:invoke name="edit">的东西，然后API或客户端解析这个标记，把它解释为"调用这个工具"。
对于复杂参数（比如嵌套数组），模型实际上是在XML标签内部手写JSON字符串：
<antml:parametername="edits">[ { "oldText": "text to replace", "newText": "replacement text" } ]</antml:parameter>也就是说，一个包含多行文件内容的编辑操作，本质上是让模型在XML里写JSON，JSON里又嵌套转义字符串。一个几百个token的newText字符串结束后，模型需要在闭合括号和逗号之间做出决定——而这正是出错的高熵点。
有两种方式能让模型输出符合Schema：
- 靠模型自觉：让模型学习生成正确格式，然后验证
- 约束采样：用语法感知解码屏蔽掉非法token
Armin的发现表明，Anthropic在新模型上，可能正在从第二种退化到第一种。
三、一个关于"滑点"的训练
Armin（Flask和Sentry的作者，也是Pi的开发者）追查了两天，给出了一个让人不安的结论：
这不是随机退化，而是RL训练的副产品。
当旧模型（如Opus 4.5）训练时，它们的后训练数据里还没有Claude Code这样一个大规模、用户级的编程助手。新模型不同——Anthropic的RL训练很可能包含了Claude Code或非常类似的工具调用环境。
问题就在这里：
Claude Code的工具调用非常宽容。
分析Claude Code的压缩代码可以发现，它有一个完整的"擦屁股"体系：
- 参数别名：
old_str、old_string、path、file_path统统接受 - Unicode修复：修复损坏的
\uXXXX序列和孤立代理对 - 静默过滤：直接扔掉未知字段
- 重试状态机：遇到坏调用推回给模型重试
在这样一个宽容的环境里，模型就算多写了几个字段，任务也能完成，奖励信号依然为正。RL梯度几乎没有理由惩罚"添加多余字段"这种行为。
更糟的是，模型被高度适配到了Claude Code的特定工具形状。Claude Code的编辑工具是扁平的：file_path、old_string、new_string，加上一个可选的replace_all。而Pi的编辑工具是嵌套的edits[]数组。两者语义相同，Schema不同。
模型学得越好，对Claude Code形状的"先验"就越强，在面对不同Schema时就越容易产生幻觉。它知道"编辑操作可能有一个额外可选字段"，但在Pi的Schema里找不到对应名字，于是每次随机采样一个听起来合理的词。
所以不是requireUnique和matchCase有什么含义——它们只是模型在高熵点上瞎猜的结果。
四、更广泛的启示
这个bug揭示的问题远不止于Pi这一个工具。
4.1 封闭的生态系统
Anthropic的模型是闭源的，Claude Code也是闭源的。我们无法知道RL环境里到底发生了什么。OpenAI至少开源了gpt-oss和harmony响应格式，让外部开发者能了解模型训练时的工具调用格式。但Anthropic这一端是黑箱。
4.2 Schema不是中立的
我们过去假设Schema是抽象的契约，模型是通用的推理器，给它什么Schema它就遵守什么。但新模型的表现为我们敲响了警钟：
Tool Schema在模型训练分布中有远近之分。
有些形状（顶层属性在ANTML中）是模型熟悉的，有些形状（嵌套数组中的长JSON）是模型不熟悉的。模型可以"理解"Schema但仍然在采样时出错——因为在高熵区域，先验压过了推理。
4.3 一个不愉快的未来
如果这种趋势继续下去，会有什么后果？
- 每个非Claude Code的工具调用框架都需要复制Claude Code的"宽容层"
- 第三方工具框架需要逆向工程Claude Code的工具形状来保持兼容
- 模型厂商的RL训练方向（在一个闭源工具上优化）实际上在定义一个隐性的行业标准
Armin自己说：“过去我对严格语法约束的工具调用持怀疑态度，因为这个bug，我的先验发生了显著偏移。”
五、我们能做什么？
这个问题没有简单的答案，但有几个值得关注的思路：
1. 严格模式是当前最直接的解决方案
Anthropic提供了strict模式，能在服务端拒绝不符合Schema的token采样。Armin的测试中，开启严格模式后问题消失。但严格模式对工具定义有复杂度限制，Claude Code自己都不用它。
2. 工具开发者需要更谨慎
如果你在构建基于Anthropic模型的工具框架，需要预期到新模型可能在某些Schema上表现得更差。加入宽容层（参数别名、字段过滤）可能不是"优雅"的解决方案，但在当前生态中是务实的。
3. 行业需要更多开放
一个健康的AI开发工具生态，需要模型厂商的RL训练方向更加透明。当RL在一个闭源工具上优化，其他工具被迫继承它的"怪癖"——这对生态多样性不利。
4. 也许我们需要接受"模型不是通用的"
这可能是一个让人不舒服但必要的认知转变：最强大的模型不一定在所有维度上都是最好的。它们在某些维度上的优化，可能会在其他维度产生意想不到的退化。
写在最后
Armin的这个发现，表面上是一个技术bug的分析，实际上指向了一个更深层的结构性问题：当AI训练越来越围绕一个封闭的产品优化，整个生态的其他部分就会被迫适应那个产品的"基因"。
Opus 4.8在推理能力上无疑比旧模型更强。但它在工具调用上确实更"差"了——不是因为它笨了，而是因为它被训练得太"专"了。
这是一个值得我们所有工具构建者和AI从业者认真思考的警示。
原文：Better Models: Worse Tools | 作者：Armin Ronacher（Flask创始人、Sentry联合创始人）