論文の概要: Do Tool Calls Execute as Intended? Measuring and Repairing Intent-Execution Correspondence in LLM Agents

• arxiv url: http://arxiv.org/abs/2610.04375v1
• Date: Sat, 03 Oct 2026 08:38:35 GMT
• ステータス: 翻訳完了
• システム内更新日: 2026-10-12 11:02:27.668903
• Title: Do Tool Calls Execute as Intended? Measuring and Repairing Intent-Execution Correspondence in LLM Agents
• Title（参考訳）: エクササイズは意図的か? : LLMエージェントのインテント実行対応の測定と修復
• Abstract要約: 大きな言語モデル(LLM)上に構築されたエージェントは、ツールコールを通じてソフトウェアを構築し、実行する。 呼び出しはいくつかのホップを通じてプログラムに到達し、いかなるホップでも通知なしでその呼び出しを変更することができる。 変更された呼び出しが失敗した場合、エージェントは正しい呼び出しをリトライする。
• 参考スコア（独自算出の注目度）: 3.8542321849457495
• License: http://arxiv.org/licenses/nonexclusive-distrib/1.0/
• Abstract: Agents built on large language models (LLMs) build and run software through tool calls. A call reaches its program through several hops, and any hop can change the call without notice. When the changed call fails, the agent retries a correct call, which costs users time and money. Benchmarks and failure analyses do not see the change, because they read the call and its result but not what a hop received. We define intent-execution correspondence (IEC) as the property that the executed action matches the action the emitted call denotes under the tool contract. Our protocol observes what each hop received without executing the call, and names the first hop that changed it by the receiver's own parser. IntAct then delivers the call in a form that this hop cannot alter, or refuses the call. We build IEC-Bench from the changes observed in real-world use, with chains of dependent calls under the execution paths of 4 widely-used harnesses. In 47,828 shell calls within production sessions, Claude Code's Bash tool changes 12.0% of the calls that carry code, escape sequences, or long text. For 80.7% of the calls whose backslashes are changed, the wrong action runs without any reported error. All 10 measured harnesses change a call. Trajectory-based judgment attributes 95.1% of the production failures to the LLM, although the path caused more than half of them. On IEC-Bench, the path raises the token cost per passed task 2.4 times (up to 12.3 times). A hop that changes a call also hides the changes after it, so 55.1% of the failures on one path appear only after its first hop is repaired. IntAct, deployed in a commercial product, recovers 79.2% of the failures with a changed call. Harnesses should therefore be designed and tested hop-by-hop to ensure a correct call executes as intended or is refused.
• Abstract（参考訳）: 大きな言語モデル(LLM)上に構築されたエージェントは、ツールコールを通じてソフトウェアを構築し、実行する。 呼び出しはいくつかのホップを通じてプログラムに到達し、いかなるホップでも通知なしでその呼び出しを変更することができる。 変更された呼び出しが失敗した場合、エージェントは正しい呼び出しをリトライする。 ベンチマークとフェール分析は、呼び出しとその結果を読み取るが、ホップが受け取ったものではないため、変更を見ることができない。 我々は、IEC(Itent-execution correspondence)を、実行されたアクションがツールコントラクトの下で出力された呼び出しが示すアクションと一致する性質として定義する。 我々のプロトコルは、呼び出しを実行せずに各ホップが受信したものを観察し、レシーバ自身のパーサによって変更した最初のホップを名付ける。 その後、IntActは、このホップが変更できないか、呼び出しを拒否する形で呼び出しを配信する。 IEC-Benchは4つの広く使われているハーネスの実行経路の下で、実世界の利用で見られる変化から構築する。 運用セッション中の47,828回のシェルコールでは、Claude CodeのBashツールが、コード、エスケープシーケンス、あるいは長いテキストを運ぶ呼び出しの12.0%を変更している。 バックスラッシュが変更された呼び出しの80.7%では、間違ったアクションは報告されたエラーなしに実行される。 計10台がコールを切り替える。 軌道に基づく判断は生産失敗の95.1%をLCMが占めるが、その半分以上が原因である。 IEC-Benchでは、パスされたタスクあたりのトークンコストが2.4倍(最大12.3倍)上昇する。 呼び出しを変更するホップも後から変更を隠すため、最初のホップが修理された後にのみ、一方の経路上の障害の55.1%が現れる。 商用製品にデプロイされたIntActは、コール変更によって障害の79.2%を回復する。 したがって、正しい呼び出しが意図されたり拒否されたりすることを確実にするために、ハーネスはホップバイホップで設計およびテストされるべきである。

関連論文リスト

• VAmoS Part Deux: Harder, More Realistic Voice-Agent Simulation [8.26112859764927]
  VAmoS Energyは、これらの課題を100件のコールで組み合わせたベンチマークだ。 エージェントには16のツールがあり、ステートフルなStripe請求双子とApache Fineractローンエンジンによって支えられている。 この仕事は、ペンシルバニア州の住宅料金規則に基づく公共の家庭電気データと政策を使用する。
  論文  参考訳（メタデータ） (2026-09-29T20:33:57Z)
• MCP Error Messages Written for Developers Hurt the Most Capable Agents Most [1.6787220460106658]
  150の広く使われているMPPサーバでは、3,001のエラーメッセージのうち949が呼び出し元に次に何をすべきかを伝える。 私たちは5つのOpenAIモデルをテストしました。
  論文  参考訳（メタデータ） (2026-09-28T15:14:46Z)
• Tunable Tool-Call Rates in LLM Agents via Representation Steering [45.332672398938136]
  本研究では,モデル自身のツール使用嗜好信号からトレーニングを受けずに抽出した残ストリーム内の1つの直線方向でツールを制御できることを示す。 また、その方向は、特定のツールの選択を好まずに、各ツール自身の方向と同等の強度で、見えないツールに一般化されていることも示しています。
  論文  参考訳（メタデータ） (2026-08-25T22:35:18Z)
• Feedback That Backfires: Why Small Language Model Agents Repeat the Call They Just Watched Fail [0.0]
  障害レコードの修正的なゲインを、失敗するアクションを再発光するログ確率の変化として定義すると、そのゲインは、命令チューニングされたモデル毎に負であることが分かります。 問題は、モデルのエラーメッセージの把握ではなく、ハーネスにある。
  論文  参考訳（メタデータ） (2026-08-24T10:19:17Z)
• The Recall Trap: A Recall-Maximizing Retriever Configuration Reduces Issue Resolution in Fixed-Budget Code Context [45.88028371034407]
  コード修復における制御ケーススタディを報告し,新しい現象ではない。 私たちは、同じスタック上の1つのフラグ(1チャンク毎の重複)を切り替えます。 BM25(3.2pp、重要なパラダイム間相互作用)を逆転させる。 厳格な固定予算では、ファイルごとのハードダイドプリケートや、タスクに対するA/Bパッケージングポリシは、メトリックフラグを調整しないことが示されます。
  論文  参考訳（メタデータ） (2026-08-14T19:22:50Z)
• Look Before You Leap: Pre-Action Verification for LLM Agents [0.0]
  我々は、アクションが有効になる前に実行される安価な決定論的チェックは、効果的で過小評価されたエージェント監視の形式であると主張している。 シェルコマンドでは、9930以上の静的検証と482のツールが95.8%の無効なコマンドを10.0%の偽陽性率でキャッチする。 コード編集では、640のベンチマークが224ファイル以上を編集し、applyステップを分離すると、シャープな分割が公開される。
  論文  参考訳（メタデータ） (2026-08-09T20:05:03Z)
• Turning Interaction History into Execution State: A Runtime Layer for Long-Horizon Coding Agents [48.967927222079965]
  Ledgerは、エージェントの完了したインタラクションを明示的な実行状態に蒸留するランタイム層である。 Ledgerはこの状態をオンライン実行台帳に保持し、各ステップの2つのバウンダリに適用される。 500のSWE-bench検証インスタンス全体で、LedgerはPass@1を56.2%から64.2%に、GPT-5 miniを75.8%から81.0%に、MiniMax M2.5を81.0%に引き上げている。
  論文  参考訳（メタデータ） (2026-08-01T18:25:00Z)
• PhoneHarness: Harnessing Phone-Use Agents through Mixed GUI, CLI, and Tool Actions [73.69976712292683]
  PhoneHarnessは、検証可能なモバイル上で電話使用エージェントを研究するための混合アクションベンチマークと実行ハーネスである。 そのベンチマークであるPhoneHarness Benchは、エージェントが観測可能な副作用を持つタスクを完了したかどうかを評価する。 この結果から,信頼度の高い電話の自動化は,視覚的GUI制御だけでなく,動作面のルーティングと検証可能な実行に依存することが示唆された。
  論文  参考訳（メタデータ） (2026-06-12T15:01:32Z)
• To Call or Not to Call: Diagnosing Intrinsic Over-Calling Bias in LLM Agents [43.812977635599374]
  LLMエージェントは、必要のない状況でも、オーバーコール、呼び出しツールに一貫した傾向を示す。 我々はこれを本態性バイアス仮説(IBH)に辿る。 我々の研究は、経験的現象から因果的補正が可能な機械的対象への過度な呼び出しをリキャストする。
  論文  参考訳（メタデータ） (2026-05-16T04:18:30Z)
• SemGuard: Real-Time Semantic Evaluator for Correcting LLM-Generated Code [46.20378145112059]
  ポストホック修復パイプラインは、実行後にのみそのような障害を検出する。 本稿では,実時間で行レベルのセマンティック監視を行うセマンティック評価フレームワークSemGuardを紹介する。
  論文  参考訳（メタデータ） (2025-09-29T09:21:32Z)

関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。

指定された論文の情報です。
本サイトの運営者は本サイト（すべての情報・翻訳含む）の品質を保証せず、本サイト（すべての情報・翻訳含む）を使用して発生したあらゆる結果について一切の責任を負いません。