langchain-fireworks 1.6.3、履歴の不正な引数をラップしてエージェントの対話継続を修正

LangChainは9月25日、エージェントが不正なツール呼び出しを含む履歴で対話を続けた際、Fireworksに履歴メッセージを拒否されることがある問題を修正した `langchain-fireworks` 1.6.3をリリースした。修正はGitHubのリリースノートに記載され、同日公開のパッケージがPyPIからも入手できる。[リリースノート](https://github.com/langchain-ai/langchain/releases/tag/langchain-fireworks==1.6.3)、[PyPI](https://pypi.org/project/langchain-fireworks/)

問題はツール実行後の応答処理で起きる。Fireworksの公式サンプルでは、モデルが最初に行ったツール呼び出しと、対応する識別子を持つツールの結果を、次のリクエストにまとめて追加する。そのため、アプリケーションが引数の解析エラーを捕捉していても、履歴に形式が不正な内容が残ることがある。メンテナーによると、不正な形式またはオブジェクト以外のツール引数JSONが履歴に含まれていると、次のリクエストが拒否され、エージェントがエラー処理を続けられなくなる。[ツール呼び出しのドキュメント](https://docs.fireworks.ai/guides/function-calling)、[修正の説明](https://github.com/langchain-ai/langchain/pull/40818)

新バージョンでは、履歴メッセージをシリアライズする際、該当する引数を `__invalid_tool_call_arguments` というJSONオブジェクトのフィールドに格納する。これにより、元の内容、呼び出し識別子、ツール結果との対応関係を保持する。対象には、解析済み形式と生の形式のツール呼び出し履歴が含まれる。有効なオブジェクト文字列はそのまま送信され、元のメッセージオブジェクトも変更されない。[マージ提案](https://github.com/langchain-ai/langchain/pull/40818)

この設計から、直接恩恵を受けるのは、ツールのエラーをモデルに返し、再試行を求めるエージェントの処理フローだと考えられる。ラップ後もエラー内容は診断の手がかりとして残り、アプリケーションは呼び出しと結果の関係を維持できる。メンテナーは、この処理で正しい引数を推測したり、修正したとされる引数を実行したりするわけではなく、履歴データの伝送形式を扱うものだと明記している。[設計の説明](https://github.com/langchain-ai/langchain/pull/40818)

導入時には、「リクエストを送信できること」と「タスクを復旧できること」を区別する必要がある。次のターンでモデルが正しい呼び出しを生成するかどうかは、モデル、ツールの説明、エラーのフィードバックに左右される。公開リリースノートには、復旧成功率やエンドツーエンドのレイテンシーに関するテスト結果は示されておらず、信頼性の向上を定量化することはできない。

エンジニアリングチームは、既存の失敗記録を使って回帰テストを行い、途中で切れた引数テキスト、構文上は有効だがオブジェクトではないJSON、複数のツール結果の対応付けを確認するとよい。履歴のクリーンアップや再試行のロジックが別にある場合は、ラップ後の内容がログや後続のプロンプトにどう渡されるかも調べる必要がある。検証ではAPIがリクエストを受け付けたかだけでなく、次のターンで出力されたツール名、引数の型、必須フィールドも確認し、エージェントが実行可能な状態まで復旧したことを確かめる。