Do Tool Calls Execute as Intended? Measuring and Repairing Intent-Execution Correspondence in LLM Agents

مسئله

ایجنت‌ها نرم‌افزار را با فراخوانی ابزار می‌سازند و اجرا می‌کنند. یک فراخوانی از چند گام عبور می‌کند تا به برنامه برسد و هر گام می‌تواند بی‌صدا آن را تغییر دهد؛ مثلاً یک بک‌اسلش در دستور شل در مسیر حذف شود و دستور دیگری اجرا شود. وقتی فراخوانی تغییرکرده شکست می‌خورد، ایجنت یک فراخوانی درست را دوباره تلاش می‌کند که وقت و پول کاربر را می‌گیرد. بنچمارک‌ها این تغییر را نمی‌بینند چون فقط فراخوانی و نتیجه را می‌خوانند.

روش

نویسنده‌ها «تطابق نیت و اجرا» را تعریف کردند: عمل اجراشده با عملی که فراخوانی طبق قرارداد ابزار نشان می‌دهد یکی باشد. پروتکلشان بدون اجرای فراخوانی می‌بیند هر گام چه دریافت کرده و اولین گامی را که تغییرش داده با تجزیه‌گر خود گیرنده مشخص می‌کند. ابزار IntAct فراخوانی را به شکلی می‌رساند که آن گام نتواند تغییرش دهد یا آن را رد می‌کند. بنچمارک IEC-Bench هم از تغییرات مشاهده‌شده در استفاده‌ی واقعی با مسیرهای اجرای ۴ هارنس پرکاربرد ساخته شد.

یافته‌ها

• در ۴۷٬۸۲۸ فراخوانی شل در جلسه‌های تولیدی، ابزار Bash در Claude Code ۱۲٫۰ درصد فراخوانی‌های حاوی کد، دنباله‌ی گریز یا متن طولانی را تغییر داد، و در ۸۰٫۷ درصد مواردی که بک‌اسلش تغییر کرده بود عمل نادرست بدون هیچ خطای گزارش‌شده‌ای اجرا شد.
• هر ۱۰ هارنس سنجیده‌شده فراخوانی را تغییر می‌دهند، و قضاوت مبتنی بر مسیر ۹۵٫۱ درصد شکست‌های تولیدی را به مدل نسبت داد، هرچند مسیر اجرا عامل بیش از نیمی از آن‌ها بود.
• در IEC-Bench مسیر اجرا هزینه‌ی توکن هر تسک موفق را ۲٫۴ برابر و تا ۱۲٫۳ برابر بالا برد.
• ابزار IntAct که در یک محصول تجاری مستقر شده، ۷۹٫۲ درصد شکست‌های دارای فراخوانی تغییرکرده را بازیابی کرد.

محدودیت‌ها

مقاله بخش جداگانه‌ای برای محدودیت‌ها ندارد؛ یک گام تغییردهنده تغییرات بعدی را پنهان می‌کند و ۵۵٫۱ درصد شکست‌ها در یک مسیر فقط پس از تعمیر گام اول ظاهر شدند، پس شمارش‌ها ممکن است کمتر از واقع باشند. وابستگی سازمانی نویسنده‌ها در نسخه‌ی HTML خوانا نیست.