تأییدیه‌های بولی؛ نقطهٔ شکست عامل‌های هوش مصنوعی در مقیاس صنعتی

تصور کنید یک کلیک ساده روی دکمه‌ی «تأیید»، باعث ورشکستگی یا یک خطای مالی فاجعه‌بار در سازمان شما شود؛ این اتفاق زمانی می‌افتد که یک عامل هوشمند، تسکی را ساعت‌ها پس از کسب اجازه، اجرا کند. در ۳ آگوست ۲۰۲۶، یک راهنمای فنی در وب‌سایت dev.to هشدار داد که در نظر گرفتن تأیید انسانی به عنوان یک پرچم بولی (Boolean) — یعنی فقط درست یا غلط — ساده‌انگاری خطرناکی برای عامل‌هایی است که در محیط عملیاتی واقعی فعالیت می‌کنند.

بیشتر نرم‌افزارهای اداری، تأیید و اجرا را تقریباً هم‌زمان می‌بینند. مدیر درخواست را تأیید می‌کند و سیستم فوراً آن را انجام می‌دهد. این روند باعث می‌شود یک مدل ذهنی ایجاد شود که در آن approved = true به معنای یک بیت اجازه دائمی است. اما عامل‌ها (Agents) — همان برنامه‌های هوشمندی که می‌توانند به‌طور مستقل ابزارها را اجرا کنند — در محیط‌هایی ناهمزمان فعالیت می‌کنند که ممکن است وقفه‌هایشان از چند دقیقه تا چند روز باشد.

به عنوان مثال، عاملی را تصور کنید که در حال آماده‌سازی بازپرداخت ۱۹۹ یوان برای سفارش SO-1001 است. انسان در ساعت ۱۰ صبح درخواست را تأیید می‌کند. اما تسک فوراً اجرا نمی‌شود؛ در صف منتظر می‌ماند، در یک صف انتظار توقف می‌کند و شاید حتی پس از ری‌استارت شدن سیستم هماهنگ‌کننده (Coordinator) زنده بماند. اگر این تسک در ساعت ۳ بعدازظهر بالاخره به مرحله ارسال (Dispatch) برسد، دنیا تغییر کرده است. در این پنج ساعت ممکن است چندین اتفاق افتاده باشد: سفارش ممکن است از طریق کانال دیگری بازپرداخت شده باشد، سیاست بازپرداخت اکنون نیاز به بررسی اضافی بخش مالی داشته باشد، تأییدکننده دیگر نقش مورد نیاز را نداشته باشد، یا فرد فعال در سیستم سازمان را ترک کرده باشد. در برخی موارد، مبلغ یا ارز در حین بازسازی تسک دچار تغییر (Drift) شده باشد، پیاده‌سازی ابزار تغییر کرده باشد یا تأییدیه تنها برای ۳۰ دقیقه اعتبار داشته است.

پنج ستون تأیید

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

طبق تحلیل dev.to، یک سیستم در سطح صنعتی برای جلوگیری از شکست باید بین پنج مفهوم متمایز تفکیک قائل شود:

• قصد تأیید (Approval Intent): آیا این نوع عملیات اصلاً به دخالت انسان نیاز دارد؟
• تصمیم تأیید (Approval Decision): آیا فرد واجد شرایط با این اقدام خاص موافقت کرد؟
• شواهد تأیید (Approval Evidence): این تصمیم را به کدام کاربر، قابلیت، آرگومان، سیاست و زمان متصل کرده است؟
• اعتبار تأیید (Approval Validity): آیا این شواهد در لحظه‌ی ارسال (Dispatch) هنوز کاربرد دارند؟
• مرجع نهایی تجاری (Final Business Authority): آیا سیستم تجاری در این لحظه واقعاً اجازه ایجاد این اثر را دارد؟

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

اتصال اقدام در برابر قصد مبهم

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

برای ارائه یک رکورد تأیید مفید، سیستم باید یک «پوشش اجرایی» (Execution Envelope) بتن و مشخص را متصل کند. بسته به سطح اطمینان مورد نیاز، این پوشش باید شامل موارد زیر باشد:

• اتصالات اصلی (Core Bindings): شناسه‌ی کاربر مورد اعتماد (trusted_subject)، قابلیت، آرگومان‌های استاندارد (canonical_arguments)، هویت تسک، نسخه‌ی سیاست، زمان تأیید، زمان انقضا و تأییدکننده.
• اتصالات سطح بالا (High-Assurance Bindings): مستاجر (Tenant)، نسخه‌ی شیء تجاری، آرتیفکت ابزار یا سرور، هدف درخواست و بستر تفویض اختیار.

فرقی نمی‌کند پیاده‌سازی از یک شیء امضا شده، رکورد پایگاه داده یا سیستم خارجی استفاده کند؛ اصل ثابت است: سیستم باید ثابت کند آنچه قرار است اجرا شود، دقیقاً همان اقدامی است که بازبینی شده است. این رویکرد سخت‌گیرانه برای کنترل خروجی‌ها، مشابه استراتژی Impri برای ایجاد گیت‌های تأیید انسانی در عامل‌های ارتباطی است تا ریسک‌های عملیاتی کاهش یابد.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اعتماد کورکورانه به خروجی‌های مدل در لایه‌های حساس می‌تواند منجر به آسیب‌های جبران‌ناپذیر شود. اینجا هم مشکل دقیقاً همین است؛ اعتماد به یک «بله» قدیمی در دنیای پویا خطرناک است.

حل رانش ساختاری در برابر رانش زمانی

بسیاری از توسعه‌دهندگان از هش پارامتر — مانند args_hash = SHA256(canonical_json(arguments)) — استفاده می‌کنند تا مطمئن شوند درخواست تغییر نکرده است. قبل از ارسال، محیط اجرا (Runtime) دوباره هش را محاسبه می‌کند. اگر مقدار متفاوت باشد، تأیید قبلی رد می‌شود. این روش از «رانش ساختاری» جلوگیری می‌کند؛ یعنی مثلاً مبلغ ۱۹۹.۰۰ را در لحظه اجرا به ۱۹,۹۰۰.۰۰ تغییر ندهد.

اما هش یکسان ثابت نمی‌کند که اجرا هنوز ایمن است. آرگومان‌ها ممکن است تغییر نکرده باشند، اما کاربر دسترسی‌اش را از دست داده، تأییدیه منقضی شده، سیاست‌های قابل اعمال عوض شده یا سفارش پیش‌تر بازپرداخت شده است. بنابراین، برابری آرگومان‌ها شرط لازم است، اما شرط کافی برای ایمنی نیست.

چهار نوع رانش در تأییدیه

تازگیِ تأییدیه یک چک ساده نیست، بلکه مجموعه‌ای از بررسی‌هاست که توسط بخش‌های مختلف مدیریت می‌شود. چهار نوع اصلی «رانش» (Drift) وجود دارد که می‌تواند تأییدیه را پیش از بازگشت عامل باطل کند:

• رانش درخواست (Request Drift): این حالت زمانی رخ می‌دهد که قابلیت، آرگومان‌های استاندارد، کاربر مورد اعتماد، مستاجر یا هویت تسک دیگر با پوشش تأییدشده مطابقت ندارند. رفتار مورد انتظار این است که سیستم ارسال نکند و تسک بادوام را به وضعیت «نیاز به تأیید» بازگرداند یا آن را رد کند.
• رانش کاربر و مرجعیت (Subject and Authority Drift): وقتی کاربر فعال یا تأییدکننده دیگر نقش، عضویت، تفویض اختیار یا صلاحیت لازم را طبق سیاست‌های فعلی ندارند. سیستم‌ها باید هویت مورد اعتماد را از یک سیستم مرجع بازخوانی کنند و هرگز به فیلدهای هویت تولیدشده توسط مدل اعتماد نکنند.
• رانش سیاست و قابلیت (Policy and Capability Drift): وقتی سیاست ریسک، حد نصاب تأیید، لیست سفید مسیرها، اعلان قابلیت یا پیاده‌سازی ابزار در زمان توقف تسک تغییر می‌کند. اگر تغییر مادی (Material) باشد، تصمیم جدید لازم است.
• رانش شیء تجاری (Business Object Drift): تغییرات در سفارش، فاکتور، حساب، موجودی کالا یا هدف استقرار پس از تأیید. سیستم تجاری یا یک API پیش‌پرواز (Preflight) تازه، باید وضعیت فعلی و اجازه نهایی را دوباره ارزیابی کند.

مالکیت حقیقت

چون هیچ سرویس واحدی نمی‌تواند تمام این حقایق را تولید کند، مسئولیت در معماری تقسیم شده است:

• زمان اجرای عامل (Agent Runtime) / کنترل اجرا: مالک آرگومان‌های استاندارد و هویت تسک است.
• سیستم‌های هویت و مجوز: مالک کاربران مورد اعتماد و تفویض اختیار هستند.
• مرجع تأیید / سیاست استقرار: مالک اعتبار تأییدیه و نسخه‌های سیاست است.
• کنترل اجرا و اپراتور ابزار: مالک مسیرهای قابلیت یا آرتیفکت‌های ابزار است.
• سیستم تجاری: مالک وضعیت اشیاء تجاری و مجوز نهایی است.

نقطه بازرسی اجرا

ایمنی زمانی رخ نمی‌کند که انسان دکمه‌ای را فشار می‌دهد؛ بلکه دقیقاً لحظه‌ای پیش از ارسال اقدام تجاری اتفاق می‌افتد. یک مسیر بازگشت محافظه‌کارانه نیازمند یک توالی سخت‌گیرانه ۹ مرحله‌ای است:

۱. بارگذاری همان هویت تسک بادوام.
۲. بازسازی پوشش اجرایی استاندارد.
۳. تأیید اینکه قابلیت و آرگومان‌ها هنوز با شواهد تأیید مطابقت دارند.
۴. بررسی انقضا یا ابطال تأییدیه.
۵. مقایسه بستر سیاست تأییدشده با بستر سیاست فعلی.
۶. بازخوانی کاربر مورد اعتماد در صورت نیاز.
۷. ارسال با یک شناسه‌ی Idempotency (تکرارناپذیر) پایدار.
۸. اجازه به سیستم تجاری برای بررسی مجدد وضعیت شیء و مرجعیت نهایی.
۹. ثبت نتیجه در همان تسک.

اگر هر یک از این پیوندها شکست بخورد، سیستم نباید به‌طور خاموش ادامه دهد. خروجی درست، انتقال تسک به وضعیت awaiting_reapproval (در انتظار تأیید مجدد) یا rejected_pre_dispatch (رد شده پیش از اجرا) است.

نکته حیاتی این است که انقضای تأییدیه هرگز نباید به عنوان یک خطای شبکه یا انتقال (Transport Failure) تلقی شود که بتوان آن را تکرار کرد. برخی پیاده‌سازی‌های ناامن سعی می‌کنند با ایجاد تسک جدید، تکرار خودکار یا استفاده مجدد از تأییدیه‌های قدیمی (چون آرگومان‌ها تغییری نکرده‌اند)، از انقضا فرار کنند. این اقدامات تداوم را از بین می‌برد و یک تصمیم زمان‌بند را به یک اجازه دائمی تبدیل می‌کند. قانون ساده است: تسک یکسان + تأییدیه منقضی‌شده = عدم اجرا.

نسخه‌بندی سیاست‌ها و مرزهای دامنه

تصمیمات تأیید از نسخه‌های خاصی از سیاست‌ها متولد می‌شوند (مثلاً refund-policy-2026-08-01). هنگام بازگشت تسک، سیستم باید نسخه تأییدشده را (approved_policy_version) با نسخه فعلی (current_policy_version) مقایسه کند. پاسخ بسته به نوع تغییر متفاوت است:

• تغییرات غیرمادی (Non-material): مثلاً تغییر در کلمات یا راهنمای رابط کاربری؛ سیستم می‌تواند با حفظ شواهد ادامه دهد.
• تغییرات سخت‌گیرانه‌تر (More restrictive): مثلاً اکنون تأیید بخش مالی لازم است؛ سیستم باید تأیید مجدد بگیرد.
• تغییرات تسهیل‌کننده (Less restrictive): مثلاً سقف عدم نیاز به تأیید افزایش یافته است؛ سیستم می‌تواند بر اساس سیاست استقرار، از تأیید قبلی استفاده کند یا دوباره ارزیابی کند.

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

اجرایی کردن مرزها

دیاگرام‌های معماری کافی نیستند؛ اعتبار تأییدیه باید به صورت سناریوهای شکست اجرایی بیان شود. یک مورد تست حیاتی، سناریویی است که در آن تأییدیه در حالی که تسک متوقف شده، منقضی می‌شود. در این حالت، سیستم باید ثابت کند که هنگام تلاش برای بازگشت، انقضا پیش از اجرا شناسایی شده، تعداد دفعات اجرا (dispatch_count) و تعداد اثرات تجاری (business_effect_count) صفر باقی مانده و تأییدیه قدیمی بازیافت نشده است.

تست‌ها باید صراحتاً میان‌برها را ممنوع کنند: ارسال تحت تأییدیه منقضی، تلقی کردن انقضا به عنوان خطای انتقال، یا ایجاد تسک‌های بادوام جدید برای دور زدن انقضا. این نیاز به رویکردی فراتر از متدهای کلاسیک است، چرا که تست‌های نرم‌افزاری سنتی معمولاً در مواجهه با طبیعت غیرقطعی عامل‌های هوش مصنوعی شکست می‌خورند.

تعریف قرارداد قابل حمل

برای جلوگیری از تبدیل یک اعلان قابل حمل به یک زبان گردش‌کار سازمانی، باید مرز پاکی حفظ شود:

• اعلان قابلیت قابل حمل (Portable Capability Declaration): بیان می‌کند که یک عملیات دارای قصد تأیید و معناشناسی حاکمیتی پایدار است.
• زمان اجرا و مرجع تأیید: پیوند شواهد، متادیتای اعتبار، انقضا، ابطال و مدیریت نسخه سیاست را پیاده می‌کند.
• سیستم تجاری: دقیقاً پیش از ایجاد اثر، مرجعیت فعلی کاربر، مرزهای مستأجر و ناورداهای دامنه را دوباره چک می‌کند.

چک‌لیست پیاده‌سازی

برای عبور از توهم approved = true و رسیدن به یک سیستم امن، توسعه‌دهندگان باید مسیرهای خود را بر اساس این الزامات بازرسی کنند:

• آیا تأییدیه به قابلیت‌های دقیق و آرگومان‌های استاندارد متصل شده است؟
• آیا کاربر مورد اعتماد از منبعی خارج از ورودی‌های تولیدشده توسط مدل استخراج می‌شود؟
• آیا تأییدیه دارای معناشناسی اعتبار یا ابطال است؟
• آیا نسخه سیاست قابل اعمال حفظ شده و برای تغییرات مادی بررسی می‌شود؟
• آیا بازگشت به تسک، یک هویت بادوام واحد را حفظ می‌کند؟
• آیا تأییدیه منقضی‌شده به‌جای تکرار خودکار، به وضعیت تأیید مجدد باز می‌گردد؟
• آیا یک شناسه‌ی Idempotency پایدار تا مرز سیستم تجاری منتقل می‌شود؟
• آیا سیستم تجاری وضعیت شیء و مرجعیت نهایی را در لحظه اثرگذاری دوباره چک می‌کند؟
• آیا یک تست می‌تواند ثابت کند که یک تقریب نامعتبر، اثر تجاری صفر تولید می‌کند؟

این تغییر معماری تضمین می‌کند که «انسان در حلقه» (Human-in-the-loop) چیزی بیش از یک الگوی رابط کاربری باشد. این رویکرد آن را به یک تضمین حاکمیتی قابل راستی‌آزمایی تبدیل می‌کند که در برابر شکست‌های سیستمی و تأخیرها مقاوم است.

گام بعدی شما

• تمام نقاط تماس «تأیید» در سیستم‌های عامل‌محور خود را بررسی کنید و هر کجا که از متغیرهای Boolean استفاده شده، آن را با رکورد شواهدی جایگزین کنید.
• یک تست استرس برای «انقضای تأییدیه در زمان توقف» طراحی کنید تا مطمئن شوید سیستم شما دچار رانش زمانی نمی‌شود.
• لایه‌ی تأیید را از لایه‌ی منطق تجاری (Business Logic) جدا کنید تا حتی با تأیید انسانی، سیستم تجاری بتواند در لحظه آخر جلوی اجرای نادرست را بگیرد.
• بررسی کنید که آیا هر تسک بازگشتی، هویت بادوام خود را حفظ می‌کند یا خیر.
• مطمئن شوید که شناسه‌ی Idempotency تا مرز سیستم تجاری منتقل می‌شود.

اما این معماری تنها بخشی از چالش است؛ برای درک اینکه چگونه می‌توان این لایه‌ها را با هزینه کمتر پیاده کرد، به تحلیل ما درباره‌ی مدیریت هزینه استنتاج مراجعه کنید.