一个第三方编程工具的开发者最近碰上一件怪事:他给自己的项目 Pi 接入 Claude,结果发现越新的模型反而越不会用他写的编辑工具。Opus 4.8 和 Sonnet 5 会在调用编辑指令时,给嵌套的参数数组里塞进一堆 schema 里根本没定义的字段,工具校验不通过,只能打回去让模型重试。奇怪的是,更早期的模型,包括参数更小的 Haiku,都没这个毛病。
这条信息来自开发者 Armin Ronacher,他在博客里把这事记了下来,Simon Willison 转述并追问了一句:第三方工具是不是得为每个模型家族单独准备一套编辑工具?这问题问得比现象本身更扎心。
新旗舰,老问题,方向反了
模型偶尔生成格式不对的工具调用,不是新鲜事,小模型尤其容易。但这次反常的地方在于:出问题的不是弱模型,是 Anthropic 自家最新的旗舰。Opus 4.8 和 Sonnet 5 双双中招,老版本反而没事——性能曲线本该只往上走,这里却在“听不听话”这件小事上拐了个弯。
Armin 给出的猜测是,新一代 Claude 很可能专门针对 Claude Code 内置的编辑工具做过强化学习式的训练优化,练得又快又准。副作用是模型对“自己没见过的工具长什么样”这件事,泛化能力反而下降了——它太熟悉自家那套字段,一旦碰到别人写的 schema,就开始按记忆里的模板往外掏字段,掏出来的东西自然对不上。
这个解释目前只是 Armin 的个人推测,没有 Anthropic 官方文档或声明证实具体训练机制,姑且当作一种有逻辑但未经证实的猜测来看。
编辑工具这门手艺,厂商都在偷偷开小灶
要理解这事为什么可信,得先知道编辑工具本身不是一件简单的东西。Claude 官方的 edit 工具走的是 search-and-replace(str_replace)路线,而且是带版本号迭代的:针对 Sonnet 3.5、Sonnet 3.7、Claude 4 分别有不同版本的工具定义,说明 Anthropic 一直在打磨这套机制。官方定价文档里还提到,这类文本编辑工具会额外增加约 700 个输入 token 的开销——这不是一个轻量摆设,是被认真投入、认真计费的核心组件。
OpenAI 走的是另一条路:Codex 用的是 apply_patch,一种补丁式机制,官方也公开谈过如何专门训练模型去用好它。两家公司都在往自己的旗舰工具里砸训练资源,这恰恰给 Armin 的猜测提供了背景支撑——如果厂商真的把编辑工具练到滚瓜烂熟,那这份熟练很可能是排他的。
两种路线各有取舍,没有谁天生更优。这也说明第三方工具想要“换一套模型更喜欢的工具”,不是简单抄作业,而是要在精确度和容错率之间重新做一次工程选择。
一个循环,道尽了问题所在
这个循环本身不复杂,但它每多转一圈,就是第三方工具要多吞下的一笔调用成本和一次交互延迟。用户感受到的是“这个模型怎么老出错”,买单的却是 Pi 这样的工具开发者。
真正让人不舒服的,不是 Opus 4.8 偶尔犯傻,是这犯傻背后的方向感。厂商为了让自己的旗舰产品——Claude Code 也好,Codex 也好——用起来顺滑,把训练资源精准砸向自家工具,这本是再正常不过的商业逻辑。孔子讲“工欲善其事,必先利其器”,可这把器磨得越快,握柄却越来越只贴合一只手。第三方开发者拿到的不是一把通用的刀,是一把认主的刀。
这不是说 Anthropic 或 OpenAI 存心构筑壁垒,更像是训练目标的自然外溢:优化“在 Claude Code 里表现好”这一个具体指标,顺带牺牲了“在任意 schema 上表现稳”这个更泛的能力。对模型厂商是免费的正向反馈,对开放生态却是一笔隐性成本,而且这笔成本会随着每次模型升级重新算一遍——旧版本调好的适配,新版本说不定又得推倒重来。
现在还看不清的是,这到底是 Pi 一个项目的个案,还是所有第三方编程工具都在悄悄承受的普遍摩擦。如果更多独立开发者报告类似现象,或者 Anthropic 就训练方法给出正式回应,这件事的分量会完全不一样。在那之前,选编程 agent 的人得多一个心眼:模型版本新,不等于在你手里的工具链里就更好用。