模型越强，工具调用越差？Anthropic新模型的诡异退化

当更好的模型变成更差的工具问题可能出在训练本身。一、一个让人抓狂的Bug想象一下你让一个AI编辑文件它完美地找到了要替换的文本精准地写入了新内容——然后在JSON末尾多塞了一个莫名其妙的字段。不是偶尔出错而是越新的模型犯这种低级错误的概率越高。这不是什么小模型的胡闹。Opus 4.8Anthropic最强的模型在调用Pi一个开源AI编码工具的编辑工具时经常在edits[]数组里的对象末尾凭空编造字段。requireUnique、oldText2、matchCase、in_file……仿佛一个喝醉了的数据工程师在键盘上胡乱敲击。更诡异的是这些字段里的实际内容完全正确——oldText和newText字节级精确。模型明明知道要做什么只是在结束之前忍不住添了一句废话。这就像是一个满分作文选手在交卷前非要画个涂鸦。二、工具调用其实很糙要理解这个bug有多奇怪得先看看LLM是怎么调用工具的。你可能以为模型内部有个优雅的JSON解析器——定义好Schema模型生成合法JSON然后执行。但现实要粗糙得多工具调用是在文本流中通过特殊标记完成的。Anthropic模型的内部工作方式大致是这样的模型收到系统提示、对话历史和工具列表服务器把这些揉成一个巨大的提示里面塞满了特殊标记token。模型在生成文本的过程中在某个时刻输出类似antml:invoke nameedit的东西然后API或客户端解析这个标记把它解释为调用这个工具。对于复杂参数比如嵌套数组模型实际上是在XML标签内部手写JSON字符串antml:parameternameedits[ { oldText: text to replace, newText: replacement text } ]/antml:parameter也就是说一个包含多行文件内容的编辑操作本质上是让模型在XML里写JSONJSON里又嵌套转义字符串。一个几百个token的newText字符串结束后模型需要在闭合括号和逗号之间做出决定——而这正是出错的高熵点。有两种方式能让模型输出符合Schema靠模型自觉让模型学习生成正确格式然后验证约束采样用语法感知解码屏蔽掉非法tokenArmin的发现表明Anthropic在新模型上可能正在从第二种退化到第一种。三、一个关于滑点的训练ArminFlask和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 RonacherFlask创始人、Sentry联合创始人