تصور کنید یک عامل پرداخت، فاکتوری را پرداخت می‌کند اما در تلاش دوم برای اصلاح یک غلط املایی در یادداشت تراکنش، همان کلید شناسایی قبلی را می‌فرستد. سرور چون کلید را می‌شناسد، رسید تراکنش اول را برمی‌گرداند و عامل با اطمینان تصور می‌کند اصلاحیه اعمال شده است، در حالی که در واقعیت هیچ اتفاقی نیفتاد. این شکست فنی که در ۹ اکتبر ۲۰۲۶ توسط کریس (Chris)، بنیان‌گذار Agent Middleware، تشریح شد، یک نقص بحرانی در نحوه مدیریت تلاش‌های مجدد (Retries) توسط عامل‌های هوش مصنوعی است.
مشکل اینجاست که اکثر توسعه‌دهندگان با کلید Idempotency (تکرارناپذیری) — شبیه به شمارهٔ پیگیری یک سفارش که اجازه نمی‌دهد یک کالا دو بار فروخته شود — مانند یک مجوز برای بازپخش آخرین پاسخ ذخیره‌شده برخورد می‌کنند. در کلاینت‌های سنتی HTTP، بدنه درخواست در زمان تلاش مجدد به ندرت تغییر می‌کند. اما عامل‌های هوش مصنوعی (AI Agents) اغلب در حلقه‌های تکرار، فراخوانی ابزار را به‌طور کامل بازنویسی می‌کنند. ممکن است مبالغ دوباره تحلیل شوند، شناسه‌های گیرنده پس از کپی کردن از یک فایل PDF با یک رقم تغییر کنند یا متن یادداشت بازنویسی شود. اگر سرور فقط کلید را تطبیق دهد، یک رسید قدیمی را برای یک قصد جدید برمی‌گرداند و دفتری ایجاد می‌کند که ادعای موفقیت برای عملیاتی را دارد که هرگز رخ نداده است.
با تکیه بر ضرورت ضرب کردن کلیدهای پایدار برای اقدامات منطقی، اکنون تمرکز بر اعتبارسنجی سمت سرور است. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، ناپایداری خروجی مدل‌ها بزرگ‌ترین تهدید برای سیستم‌های تراکنشی است. خطر اینجا فقط پرداخت مضاعف نیست، بلکه یک «دروغ خاموش» است؛ وضعیتی که در آن سیستم نتیجه‌ای موفق را برای درخواستی ثبت می‌کند که در واقع تغییر یافته و نادیده گرفته شده است. این وضعیت بدتر از یک پرداخت مضاعف آشکار است، زیرا دفاتر حسابداری می‌گویند قصد جدید با موفقیت اجرا شده، در حالی که چنین نبوده است.
سازوکار اتصال درخواست (Request Binding)
به نقل از مستندات Agent Middleware، برای حل این مشکل، سرورها باید از تطبیق صرفاً بر اساس کلید فراتر روند. رفتار صحیح این است که سرور یک هش (Hash) — شبیه به اثر انگشت دیجیتالی که هر تغییر کوچک در متن را شناسایی می‌کند — از درخواست اثرگذار (Effectful Request) را در کنار پاسخ ذخیره کند. وقتی درخواستی با کلید موجود می‌رسد، سرور هش جدید را با هش ذخیره‌شده مقایسه می‌کند:
- کلید یکسان + هش یکسان: سرور نتیجه اصلی را برمی‌گرداند و از اجرای مجدد اثر جانبی جلوگیری می‌کند. این کار از پرداخت دوم جلوگیری می‌کند.
- کلید یکسان + هش متفاوت: سرور باید درخواست را با صدای بلند رد کند. در این حالت، سرور باید ترجیح دهد که رکورد قبلی را بازپخش یا بازنویسی نکند.
کریس الگوی خاصی را پیشنهاد می‌کند که در آن از هش SHA-256 روی JSON استانداردشده (Canonicalized) استفاده شود. با مرتب‌سازی کلیدها و حذف جداکننده‌ها، سرور تضمین می‌کند که تغییرات بی‌اهمیت در فرمت‌بندی، باعث خطای اشتباه و عدم تطابق کاذب نشود.
جزئیات پیاده‌سازی فنی
بر اساس بررسی‌های فنی، سرور در یک پیاده‌سازی عملی باید این قوانین خاص را اجرا کند:
- استانداردسازی (Canonicalization): استفاده از
json.dumpsباsort_keys=Trueو جداکننده‌های خاص (مثلاً(",", ":")) برای تضمین پایداری هش فارغ از ترتیب کلیدها. - هش‌کردن گزینشی: فقط فیلدهایی که اثر تجاری را تغییر می‌دهند — مانند نام ابزار، مبلغ، ارز و گیرنده — باید در هش گنجانده شوند. هدرهای صرفاً تزئینی معمولاً نباید در هش باشند؛ زیرا اگر هیچ مورد consequential (سرنوشت‌سازی) هش نشود، سیستم در واقع به همان تطبیق صرفاً بر اساس کلید بازمی‌گردد.
- منطق بسته‌شدن در خطا (Fail-Closed): اگر کلید وجود داشت اما هش متفاوت بود، سیستم باید یک تضاد (Conflict) صادر کند (مثلاً خطای
idempotency_key_reused)، به جای اینکه سعی کند قصد کاربر را حدس بزند.
مدیریت تضادها در حلقه‌های عامل
وقتی سرور تضاد را شناس می‌کند، باید خطای مشخصی مانند HTTP 409 Conflict یا کد اختصاصی idempotency_key_reused برگرداند. یک پاسخ 200 OK نرم همراه با یک هدر هشدار کافی نیست، چون اکثر حلقه‌های عامل به‌سادگی آن را نادیده می‌گیرند.
در این لحظه، کلاینت نباید صرفاً یک کلید جدید بسازد و دوباره تلاش کند. انجام این کار، تضاد شناسایی‌شده را به یک فراخوانی واقعی دوم تبدیل می‌کند و دقیقاً همان پرداخت مضاعفی را ایجاد می‌کند که سیستم قرار بود از آن جلوگیری کند. در عوض، عامل باید توقف تلاش مجدد خودکار را اجرا کند. تضاد، یک «تایم‌اوت» نیست، بلکه سیگنالی برای توقف است.
حل عدم تطابق قصد
عامل باید دو قصد را با هم مقایسه کند تا گام بعدی را تعیین کند:
- تغییرات تصادفی: اگر مدل صرفاً یک یادداشت را بازنویسی کرده است، عامل باید آرگومان‌های اصلی را تحت همان کلید مجدداً ارسال کند تا یک بازپخش (Replay) واقعی تحریک شود.
- تغییرات عمدی: اگر مبلغ پس از یک بازبینی اصلاح شده است، این یک اقدام منطقی جدید است. عامل باید پس از تصمیم‌گیری در مورد اینکه آیا اقدام اول لغو شده، جایگزین شده یا به همان شکل باقی می‌ماند، یک کلید جدید صادر کند.
- موارد مبهم: هرگونه عدم تطابق نامشخص باید به یک انسان یا یک مرحله برنامه‌ریز (Planner) اختصاصی ارجاع داده شود.
چارچوب‌های عاملی (Agent Frameworks) که به‌طور خودکار هر پاسخ غیر از 200 را دوباره تلاش می‌کنند، بدون اینکه این کلاس خاص از خطا به‌طور صریح شناسایی شود، تنها باعث عمیق‌تر شدن مشکل خواهند شد.
پیاده‌سازی در Agent Middleware (AMW)
این الگو در حال حاضر در Agent Middleware (AMW) پیاده می‌شود؛ گیت‌وی‌ای که طراحی شده تا یک مرز از مجوزها (Permit) و رسیدها (Receipt) در برابر فراخوانی‌های ابزار MCP (پروتکل زمینه مدل) ایجاد کند. در AMW، عامل‌ها تحت یک مجوز عمل می‌کنند؛ تکرار با کلید یکسان، رسید اصلی را برمی‌گرداند و تضمین می‌کند که هیچ فراخوانی یا پرداخت دومی رخ ندهد.
AMW اتصال سخت‌گیرانه درخواست را به شرح زیر اجرا می‌کند:
- اعتبارسنجی هش: درخواست همراه با فراخوانی هش می‌شود. هر تغییر در بدنه (Payload) یا مجوز متفاوت، منجر به خطای
idempotency_key_reusedمی‌شود. - کنترل هم‌زمانی: اگر تلاشی در حالی برسد که فراخوانی اول هنوز در حال اجراست، AMW وضعیت
idempotency_in_progressرا بازمی‌گرداند. - کلیدگذاری سخت‌گیرانه: هر کلید جدید همیشه به عنوان یک فراخوانی جدید تلقی می‌شود. هیچ حذف تکراری خاموشی بین کلیدهای مختلف رخ نمی‌دهد. اگر کاربر کلید را تغییر دهد تا از یک تضاد «عبور» کند، در واقع صراحتاً درخواست ارسال دوم را داده است.
نکته مهم این است که AMW محدوده سمت خود را مدیریت می‌کند: تضمین می‌کند که حداکثر یک ارسال، یک پرداخت و یک رسید برای هر کلید پذیرفته شده وجود داشته باشد. اینکه آیا خودِ ابزار راه دور (Remote Tool) تنها یک بار اجرا می‌شود یا خیر، همچنان به این بستگی دارد که آن ابزار کلید Idempotency خود را رعایت کند.
کاهش نرخ عدم تطابق
برای به حداقل رساندن این تضادها، توسعه‌دهندگان باید از پر کردن آرگومان‌های consequential (سرنوشت‌ساز) توسط متن آزاد مدل خودداری کنند. در عوض، باید از وضعیت وظیفه (Task State) استفاده کنند. در حالی که مدل تصمیم می‌گیرد «آیا» پرداخت شود، کد باید مبلغ، ارز و گیرنده دقیق را از یک رکورد تغییرناپذیر (Immutable) ذخیره‌شده تأمین کند.
این رویکرد مشابه الگوهای اتصال درخواست است که Stripe سال‌هاست استفاده می‌کند. اما چون عامل‌های هوش مصنوعی بیشتر از کلاینت‌های کدنویسی‌شده توسط انسان مستعد بازنویسی آرگومان‌ها هستند، این سطح از سخت‌گیری دیگر برای گردش‌کارهای تولیدی (Production-grade) اختیاری نیست.
این تغییر در رویکرد، این فرض را که Idempotency صرفاً یک جستجوی ساده کلید-مقدار است، تغییر می‌دهد. این فرآیند، تکرارناپذیری را به یک فرآیند اعتبارسنجی تبدیل می‌کند که از یکپارچگی دفتر کل تجاری در برابر ناپایداری ذاتی خروجی‌های LLM محافظت می‌کند.
گام بعدی شما
- اگر از سیستم‌های پرداخت یا تراکنشی در عامل‌های خود استفاده می‌کنید، بررسی کنید که آیا سرور شما فقط کلید Idempotency را چک می‌کند یا محتوای درخواست را نیز هش می‌کند.
- در پیاده‌سازی‌های خود، منطق Fail-Closed را جایگزین حدس زدن قصد مدل کنید تا از «دروغ‌های خاموش» در دفتر کل جلوگیری شود.
- آرگومان‌های حساس را از متغیرهای ثابت (Immutable) تغذیه کنید، نه از خروجی مستقیم مدل زبانی.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو