GitHub Repo
Dify、ReAct解析器を修正するパッチを提案—文字列内の波括弧によるツール呼び出しのスキップを防止
Difyコミュニティは11月6日、ReActストリームパーサーがJSON文字列内の波括弧を構造上の境界と誤認する問題への修正を提案した。報告者によると、新たな回帰テストは通過したが、提案はまだマージされておらず、正式版で修正済みとはいえない。

Difyコミュニティは11月6日、ReActエージェントのストリーム出力パーサーを修正するPR #45741を提出した。問題報告では、当時のメインブランチで直接再現できたとしている。モデルが有効なツール指示を生成しても、引数の文字列に波括弧が含まれると、パーサーが内容を途中で切り詰める可能性がある。その結果、実行器がツール呼び出しをスキップし、元のJSONを回答としてユーザーに返すことがあった。再現にはモデルの出力テキストを与えるだけでよく、特定のプロバイダーには依存しない。問題報告
たとえば、検索引数に close } brace が含まれると、従来のロジックは文字列中の右波括弧も構造の深さに数え、指示が終わったと早まって判定していた。文字列内に対応する右波括弧のない左波括弧があると、その後の回答がペイロードに取り込まれる可能性もあった。別の失敗経路では、指示より前の通常テキストに右波括弧が含まれることでキャッシュが汚染され、次の有効な指示を解析できなくなっていた。こうした状況では明確なエラーメッセージが出ないこともあり、エージェントが処理を実行しなかった原因の調査が難しくなる。再現手順と実行経路
JSON仕様では、文字列内に波括弧を含めることが認められている。オブジェクトの境界を判断するには、文字列の内容、引用符、エスケープ文字を区別しなければならない。そのため、このような有効な引数を括弧の数だけで切り分けることはできない。RFC 8259の文字列規則
提案では従来のカウンターを、構造の深さ、文字列状態、エスケープ状態を組み合わせて管理する方式に変更する。深さを更新するのは文字列の外側に限り、ペイロード完了後のキャッシュ処理も調整する。報告者によると、追加した5つのケースは修正前にはすべて失敗し、修正後は既存ケースを含む計70件が通過した。テストにはエスケープされた引用符、ネストした入力、対応する括弧のない括弧が含まれる。ただし、これは報告者が公表した範囲での検証だ。修正内容とテスト
エンジニアリングチームにとって、この問題はエージェントの信頼性がモデル出力からツール実行に至るまでの解析層にも左右されることを示している。上記の失敗の仕組みから、検証では元の出力、解析されたアクション、実際のツール実行記録を照合するとよい。今後はレビュー、マージ、リリースへの取り込み状況を追う必要がある。また、この提案は他の不正なアクション形式を対象としていないため、影響範囲をすべてのエージェント経路に広げて解釈すべきではない。提案の状況と範囲