معماری جدید: انتقال چک‌لیست‌ها به بیرون، دقت عامل‌ها را تضمین می‌کند

تصور کنید یک عامل هوش مصنوعی فرمی را با ظاهری کاملاً حرفه‌ای و بدون نقص پر می‌کند، اما تمام داده‌های درون آن از فضای تخیل مدل بیرون آمده‌اند. این خطرناک‌ترین نوع شکست در سیستم‌های عامل‌محور است؛ نه یک پاسخ اشتباه ساده، بلکه یک فرم «تمیز» که درست به نظر می‌رسد اما حاوی داده‌های اختراعی است. جایی که مدل به جای پذیرش نادانی، شکاف‌های اطلاعاتی را با توهم (Hallucination) — شبیه دوستی که خاطره‌ای را اشتباه تعریف می‌کند اما با اطمینان کامل می‌گوید — پر می‌کند.

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

این نقص سیستماتیک، محوریت یک چارچوب فنی است که در ۲۴ اوت ۲۰۲۶ توسط Jang-woo-AnnaSoft از طریق گیت‌هاب منتشر شد. استدلال اصلی این است که مرحله «طراحی پیش‌نویس» (Drafting) در اجرای ابزارها باید از اختیارات مدل سلب شده و به یک لیست سخت‌افزاری (Hard-coded) خارجی منتقل شود. این تغییر، نقش انسان را از قضاوت درباره اینکه «آیا این درست است؟» به تصمیم‌گیری ساده درباره اینکه «آیا پیش برویم؟» تغییر می‌دهد.

توهم تاییدیه

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

در الگوهای فعلی عامل‌های هوش مصنوعی، مدل فرم را پر می‌کند و انسان آن را امضا می‌کند. تاییدیه از بین نرفته است، اما مرحله پیش‌نویس جابه‌جا شده است. این وضعیت منجر به «فرهنگ کلیک سریع» (Click-through culture) شده است؛ جایی که کاربر فیلدی را تایید می‌کند که هرگز واقعاً آن را بررسی نکرده است، زیرا فرم از نظر بصری کامل به نظر می‌رسد. ماهیت بررسی از یک قضاوت درباره دقت («آیا این درست است؟») به یک عبور ساده («آیا پیش برویم؟») تغییر می‌کند. اگر از کسی بخواهید آنچه را که به او نشان داده‌اید تایید کند، به جای بررسی دقیق، با کلیک سریع مواجه می‌شوید. این چالش با خطرات تاییدیه های بولی در مقیاس صنعتی همسو است که در آن تاییدهای ساده جایگزین بررسی‌های عمیق می‌شوند.

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

مکانیسم: اسلات‌ها و ناشناخته‌ها

برای حل این بحران، Jang-woo-AnnaSoft سیستمی را بر اساس دو تعریف سخت‌گیرانه پیشنهاد می‌کند:

• اسلات (Slot): یک مورد خطی مشخص که باید برای این اجرا تایید شود.
• ناشناس (Unknown): اسلاتی که پس از بررسی تمام منابع تعیین‌شده، همچنان خالی مانده است.

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

این رویکرد بسیار کارآمدتر از پرامپت‌نویسی‌های تکراری است. جست‌وجوها به جای فراخوانی‌های اضافی استنتاج (Inference)، به صورت مقایسه‌های حافظه‌ای موازی اجرا می‌شوند. رفت‌وبرگشت‌هایی که برای پرسیدن تک‌تک جای خالی‌ها صرف می‌شد، به یک دسته (Batch) واحد تبدیل می‌شود. اگر هدف «لیست» باشد، اسلات‌ها دیگر به یکدیگر وابسته نیستند و اصلاح یک پاسخ اشتباه به سادگی پر کردن یک اسلات است. اگر هدف «اجرا» بود، یک ترتیب بین اسلات‌ها ایجاد می‌شد؛ اما با هدف قرار دادن لیست، این وابستگی حذف می‌شود.

سازماندهی لیست اجرا

شکست‌های اجرایی عموماً به سه دسته تقسیم می‌شوند:
۱. اجرای اشتباه: مقدار غلط بود (مثلاً یک شناسه یا شماره حساب اختراعی).
۲. اجرای بدون دستور: هیچ شرطی وجود نداشت؛ ابزار بدون بررسی زمان‌بندی یا صلاحیت اجرا شد.
۳. اجرای خارج از هدف: قصد کاربر درک نشد؛ ابزار تغییری در وضعیت ایجاد نکرد که کاربر می‌خواست.

برای مقابله با این موارد، لیست پیشنهادی بر اساس اینکه چه کسی می‌تواند به اسلات پاسخ دهد، تقسیم می‌شود:

چک‌لیست ثابت (Fixed Checklist)
این لیست به هر اجرا پیوست می‌شود و موارد زیر را پوشش می‌دهد:

• انتخاب ابزار مناسب.
• بررسی اینکه آیا شرایط اجرا (زمان‌بندی و شرایط محیطی) برآورده شده است یا خیر.
• نامی که کاربر برای این اقدام برگزیده است.

چک‌لیست ارائه‌دهنده (Provider Checklist)
این لیست برای هر ابزار متفاوت است و شامل موارد زیر است:

• فیلدهای ضروری، انواع داده‌ها و فرمت‌ها.
• تاییدیه پیش از اجرا و شرایط ممنوع‌کننده.
• شرایط نیاز به تاییدیه اضافی.
• تغییراتی که در صورت اجرا رخ می‌دهد (تغییر وضعیتی که این ابزار می‌تواند ایجاد کند).

چک‌لیست کاربر (User Checklist)
این لیست بسته به کاربر و محیط متفاوت است و موارد زیر را پوشش می‌دهد:

• قصد (Intent) و بستر (Context) فعلی.
• محدودیت‌های اجرایی و ترجیحات کاربر.
• تاییدیه نهایی پیش از اجرا.

مقادیر و شرایط

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

با قرار دادن مقادیر و شرایط در یک لیست واحد، هر دو به عنوان اسلات‌هایی در نظر گرفته می‌شوند که یا پر شده‌اند یا خیر. دیگر نیازی به مکانیسم جداگانه‌ای برای شرایط نیست. ارائه‌دهندگان ابزارها در حال حاضر این موارد را در توضیحات ابزار می‌نویسند؛ سیستم صرفاً تضمین می‌کند که مدل متوجه متن آزاد (Free text) شود و بر اساس آن عمل کند. بدون این ساختار، هیچ راهی برای تایید اینکه مدل متن آزاد را تشخیص داده و بر اساس آن عمل کرده است، وجود ندارد.

«قصد» (Intent) نیز به یک اسلات تبدیل می‌شود. از آنجایی که ارائه‌دهندگان مختلف نام‌های متفاوتی برای یک اقدام مشابه به کار می‌برند (مثلاً turn_off_light در مقابل set_device_power در حالی که light_control ممکن است فقط روشنایی را تنظیم کند)، تطبیق باید بر اساس این باشد که آیا ابزار می‌تواند «تغییر وضعیت» مورد نظر را ایجاد کند یا خیر، نه بر اساس تطبیق برچسب‌ها. اگر ابزاری انتخاب شود در حالی که اسلات‌های قصد هنوز خالی هستند، نتیجه یک «اجرای خارج از هدف» خواهد بود.

سلسله‌مراتب جست‌وجو

به جای اینکه از مدل بخواهیم مقادیر را «استنتاج نکند» — دستوری که معمولاً شکست می‌خورد چون مدل نمی‌تواند خروجی خود را پس از تولید طبقه‌بندی کند — سیستم از یک ترتیب جست‌وجوی سخت‌گیرانه استفاده می‌کند. مدل مقدار را در این توالی جست‌وجو می‌کند:

پاسخ کاربر $
ightarrow$ دستورالعمل $
ightarrow$ مقادیر پیش‌فرض $
ightarrow$ مقادیر مشاهده‌شده $
ightarrow$ وضعیت قبلی

این یک «ترتیب جست‌وجو» است، نه یک «رتبه‌بندی اعتماد». به این معنا نیست که منابع اولیه قابل اعتمادتر هستند؛ بلکه به این معناست که وقتی پاسخی یافت شد، جست‌وجو متوقف می‌شود. اگر جست‌وجو به پایان برسد و اسلات همچنان خالی باشد، به عنوان «ناشناس» علامت‌گذاری می‌شود.

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

انتقال اصول به کد

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

محدودیت‌های کد-محور (Code-Enforced Constraints)

• تایید متصل (Binding Approval): تاییدیه باید به جفت {اسلات، مقدار} خاص متصل باشد. اگر مقدار تغییر کند، تاییدیه باطل می‌شود.
• ثبت حکم (Verdict Recording): اجرا باید تنها یک حکم ثبت‌شده را به عنوان مبنا بپذیرد. سیستم همچنین باید ثبت کند چه چیزی مسدود شده است، زیرا نگه داشتن تنها موارد اجرا شده، علت مسدود شدن را از لاگ‌ها پاک می‌کند.
• دسته‌بندی سوالات (Batching Questions): به جای پرامپت‌های تک‌تک، سیستم تمام ناشناخته‌ها را شناسایی کرده و آن‌ها را در یک دسته واحد از کاربر می‌پرسد.
• تایید منبع (Source Verification): کد مکان اشاره‌شده را بررسی می‌کند تا تایید کند مقدار واقعاً در آنجا وجود دارد، به جای اینکه به حافظه مدل اعتماد کند.
• اجرای برچسب‌ها (Label Enforcement): سیستم برچسب‌ها را می‌خواند و آن‌ها را به طور سخت‌گیرانه اجرا می‌کند.

اصول باقی‌مانده (Residual Principles)
برخی عناصر توسط کد قابل شناسایی نیستند و به عنوان اصول باقی می‌مانند:

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

نقش مدل

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

این کار «جعبه سیاه» انتخاب ابزار را حذف می‌کند. در حالی که مدل همچنان ابزار را از لیستی از کاندیدها انتخاب می‌کند، ورودی‌های این تصمیم اکنون قابل مشاهده هستند. وقتی یک عامل شکست می‌خورد، توسعه‌دهندگان دیگر نمی‌پرسند «چرا مدل این کار را کرد؟»، بلکه می‌پرسند «کدام اسلات خالی بود؟» یا «کدام منبع در تولید پاسخ شکست خورد؟». این شفافیت در مقابل شکاف موجود بین بنچمارک‌ها و ارزیابی انسانی قرار می‌گیرد، جایی که معیارهای استاندارد لزوماً شکست‌های عملیاتی را پیش‌بینی نمی‌کنند.

قوانین داخلی و شرایط ارائه‌دهنده

در حال حاضر، قوانین داخلی در پرامپت‌ها، رپرهای ابزار یا به صورت قراردادهای ضمنی زندگی می‌کنند و تایید یا توضیح آن‌ها را غیرممکن می‌سازند. تغییر یک قانون مستلزم استقرار (Deployment) مجدد است. شما نمی‌توانید بپرسید کدام قوانین برای یک اجرای خاص اعمال شده‌اند یا توضیح دهید چرا یک مورد در صف تایید قرار گرفته است. با ساختاردهی قوانین به صورت خطوطی در همان لیست، دیگر نیازی به کد جداگانه برای اجرای آن‌ها نیست. نهادهای سیاست‌گذار، شرکت‌ها و رگولاتورها می‌توانند به عنوان «شرایط» در لیست ارائه‌دهنده اضافه شوند.

برای ارائه‌دهندگان، یک پیاده‌سازی حداقلی از سه برچسب در توضیحات ابزار استفاده می‌کند:

• [required]: مشمول بررسی منبع؛ اگر در وضعیت نباشد، به لیست ناشناخته‌ها می‌رود.
• [confirm]: اسلاتی که بدون تایید کاربر پر نمی‌شود.
• [notice]: اطلاعاتی که کاربر باید پیش از گفتگو بداند.

از آنجایی که واژگان ثابت هستند، استخراج این برچسب‌ها یک تجزیه رشته‌ای (String parsing) ساده است. پس از تثبیت، این مورد می‌تواند به عنوان فرمتی در اسکیمای ورودی اضافه شود تا دقیقاً اعلام کند کدام وضعیت جست‌وجو و مقایسه می‌شود.

ادغام با چارچوب‌های مدرن

این رویکرد بر اساس پیشرفت‌های اخیر در ارکستراسیون عامل‌ها، مانند LangGraph و پروتکل زمینه مدل (MCP) بنا شده است. این چارچوب‌ها در حال حاضر جداسازی ابزارها و متصل کردن خروجی‌ها به اسکیماها را آغاز کرده‌اند. سیستم چک‌لیست پیشنهادی، لایه‌ای از تایید را اضافه می‌کند که تضمین می‌کند هیچ مسیر اجرایی بدون یک رکورد تکمیل‌شده وجود نداشته باشد.

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