更好的模型：更差的工具
Armin Ronacher 報告了一個奇怪的問題：較新的 Claude 模型（如 Opus 4.8 和 Sonnet 5）在呼叫 Pi 的編輯工具時會憑空新增額外欄位，導致工具呼叫失敗。而較舊的模型卻沒有這個問題。他推測，這是因為 Anthropic 透過強化學習讓新模型更擅長使用 Claude Code 內建的編輯工具，但副作用是其他程式碼框架（如 Pi）的自定義工具被誤用的機率增加了。這引發了疑問：第三方程式碼框架是否應該針對不同模型實現多種編輯工具？
在最新的部落格文章中，Armin Ronacher 分享了一個他在開發 Pi（一個 AI 程式設計助手）時遇到的令人困惑的問題。他發現，較新的 Claude 模型（包括強大的 Opus 4.8 和 Sonnet 5）在呼叫 Pi 的編輯工具時，會在巢狀的 edits[] 陣列中憑空新增一些不存在的欄位。儘管編輯操作本身通常是正確的，但由於附加了模式中未定義的鍵，Pi 會拒絕該工具呼叫，並要求模型重試。
這本身並不罕見——模型有時確實會輸出格式錯誤的工具呼叫，尤其是小型模型。但令人驚訝的是，這個問題在較新的模型中反而更頻繁地出現。Opus 4.8 和 Sonnet 5 都表現出這種傾向，而較舊的模型（如 Opus 3 和 Sonnet 4）則沒有。換言之，Anthropic 系列中最先進的模型在遵循特定工具模式方面的表現反而不如它們的“前輩”。
Armin 推測，這種反常現象是由於 Anthropic 透過強化學習（Reinforcement Learning, RL）對較新模型進行了專門訓練，使其更擅長使用 Claude Code 中內建的編輯工具（基於搜尋和替換）。這種訓練雖然提高了模型在 Claude Code 中的表現，但也產生了負面效應——模型開始將類似的行為“推廣”到其他程式碼框架的自定義工具上，導致 Pi 等工具收到不符合預期的呼叫。
這一觀察引出了更廣泛的問題：如果模型供應商繼續針對自家工具最佳化模型，第三方框架是否被迫需要實現多種編輯工具？例如，OpenAI 的 Codex 使用 apply_patch 機制，並且 OpenAI 也公開討論過如何訓練模型有效使用該工具。那麼，Pi 是否應該同時支援搜尋-替換和 apply_patch 等多種編輯工具，以便根據底層模型選擇最相容的一種？
目前，這個問題還沒有簡單的答案。但它凸顯了 AI 工具生態中一個潛在的分裂趨勢：隨著模型越來越針對特定平臺最佳化，跨框架的通用性可能會下降。開發者可能需要考慮如何在保持靈活性的同時，應對模型行為的非預期變化。