TrajDebugがエージェントのエラーライフサイクルを追跡、失敗診断により再実行の成功率が平均10.8%向上

清華大学とTencent Hunyuanの研究チームは、長期ホライズンのエージェントにおける最も難しいデバッグ問題の解決を目指すTrajDebugを提案した。1回の実行失敗には複数の局所的なエラーが含まれる可能性があるが、最初に発生したエラー、最後に発生したエラー、あるいは最も目立つエラーが、必ずしもタスク失敗の決定的な原因とは限らない。チームが抽出調査した50件の失敗軌跡には計381件の局所的エラーがあり、1軌跡当たりの平均は7.62件だった。真に重要なエラーを除くと、61.9%はその後エージェントによって修正され、さらに6.6%は修正されなかったものの、後続の意思決定には影響していなかった。

TrajDebugはまず、軌跡を高・中・低の3段階の詳細度で整理する。現在のステップについては元の命令、アクション、観察を保持し、より遠い履歴は段階的に圧縮する。次に、タスクのルール、履歴情報、環境からの応答、または同一ステップ内の推論と矛盾する「誤ったコミットメント」を特定する。その際、エラーの内容と、違反した根拠の両方を原文中で逐語的に特定できなければならない。関連するトリガーポイントは共通のルールや観察に基づいて統合され、同じエラーが計画、アクション、検証の各段階で繰り返し現れた場合の重複カウントを防ぐ。

第2段階では、エラーを「クリーンな修復」「高コストな修復」「可視的な影響が残存」「未解決だが最終結果への影響なし」の4状態に分類する。修復に軌跡全体の半分を超える長さを費やした場合は、「予算負債」を残したと見なされる。最終的な因果帰属の対象となるのは、高コストな修復と、最終結果への影響が残っているエラーだけだ。新たに構築されたTrajErrBenchは、τ²-Benchのカスタマーサービス用ツール軌跡400件と、SWE-Bench Proのコーディング軌跡86件を収録しており、後者の平均長は119.7ステップだった。3人のアノテーターによる重要ステップの一致度は、それぞれFleissのκ係数で0.91と0.67に達した。

著者らの報告によると、1回の失敗に対する診断を対象を絞ったガイダンスへ変換したところ、同一タスクを再実行した際の成功率が平均10.8%向上した。また、少量の過去の診断を失敗メモリとして集約し、未見のタスクに適用した場合も、成功率が平均5.7%向上した。この結果は、TrajDebugが単なるオフライン評価器ではなく、エージェント追跡プラットフォームの根本原因分析レイヤーになり得ることを示している。ただし、最終的な原因帰属は依然としてLLMの判断に委ねられており、改善幅も著者独自の再実行設定に基づく。GitHubリポジトリにはすでにディレクトリ構成と説明が用意されているものの、コードとデータはまだ内部レビュー中であり、現時点では独立した再現はできない。