جایگزینی پرامپت با ماشین حالت: روشی برای توقف خطاهای ابزاری در عامل‌های AI

اگر در حال توسعه‌ی عامل‌های هوش مصنوعی برای محیط‌های عملیاتی هستید، احتمالاً با این کابوس روبرو شده‌اید که مدل ابزاری را اجرا کند که صراحتاً از آن منع شده بود. در ۱۱ ژوئن ۲۰۲۶، یک توسعه‌دهنده کتابخانه‌ی reactive-fsm را منتشر کرد؛ یک ابزار بدون وابستگی در TypeScript که دسترسی به ابزارها را از حالت متنی به حالت ساختاری تغییر می‌دهد تا دقیقاً همین شکست‌های عملیاتی را حل کند.

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

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های زبانی اشاره کردیم، تکیه بر دستورات متنی برای کنترل رفتار مدل، ریسک بالایی دارد. reactive-fsm معماری را تغییر می‌دهد و یک ماشین حالت (State Machine) اعلامی پیاده می‌کند. در این روش، به جای اینکه از مدل بخواهیم در برابر یک ابزار مقاومت کند، کتابخانه تضمین می‌کند که آن ابزار تا زمانی که سیستم به حالت صحیح منتقل نشود، اصلاً در کانتکست مدل وجود نداشته باشد. مدل به زبان ساده «ممنوع» نمی‌شود، بلکه ابزار مورد نظر فیزیکی و عملاً از آرایه‌ی ابزارهایی که به مدل زبانی بزرگ (LLM) ارسال می‌شود، حذف می‌گردد.

زمینه و معماری

ایده‌ی اصلی این کتابخانه، تعریف حالت‌ها به صورت اعلامی (Declarative) است. شما حالت‌ها را تعریف می‌کنید، ابزارهای خاصی را به هر حالت اختصاص می‌دهید و تعیین می‌کنید که انتقال بین حالت‌ها چگونه رخ دهد. مدل در هر لحظه درون یک حالت قرار دارد و نمی‌تواند از آن فرار کند.

به نقل از مستندات پروژه، برای مثال در حالت «TRIAGE»، مدل فقط ابزارهایی مثل check_service و check_availability را می‌بیند. ابزارهای confirm و invoice در این مرحله در درخواست API غایب هستند. تنها زمانی که اجرای یک ابزار، هویت کاربر را تأیید کند و سیستم دستور transitionTo("BOOKING") را صادر کند، ابزارهای رزرو ظاهر و ابزارهای بررسی اولیه حذف می‌شوند. این ساختار تضمین می‌کند که حصار محافظتی، ساختاری است و نه متنی.

مشخصات فنی و قابلیت‌ها

بر اساس بررسی مستندات، این کتابخانه ویژگی‌های زیر را ارائه می‌دهد:

• آداپتورهای ارائه‌دهنده: این کتابخانه شامل Wrapperهای داخلی است که فرمت‌های خاص هر ارائه‌دهنده را مدیریت می‌کنند. پنج آداپتور در دسترس است: Vercel AI SDK، OpenAI، Anthropic، LangChain و Google Gemini.
• سپر حلقه (Loop Shield): برای جلوگیری از گران‌ترین باگ محیط تولید — یعنی حلقه‌های بی‌نهایت — یک مدارشکن (Circuit Breaker) تعبیه شده است. این سیستم مانع از آن می‌شود که مدل ابزاری را فراخوانی کند، نتیجه‌ای که نمی‌پسندد را دریافت کند و دوباره همان ابزار را با پارامترهای اندکی متفاوت فراخوانی نماید. این سپر دو حالت دارد:
  • consecutive: زمانی فعال می‌شود که هر N ابزار به صورت متوالی فراخوانی شوند.
  • repeated: زمانی فعال می‌شود که یک ابزار خاص N بار تکرار شود.
  • این سیستم می‌تواند انتقال خودکار به یک fallbackState (مانند «ESCALATION» یا ارجاع به اپراتور) را اجبار کند و یک کال‌بک onLoop را همراه با متادیتا برای ثبت لاگ و هشدارها اجرا نماید.
• محافظ‌های ناهمگام (Async Guards): انتقال بین حالت‌ها اغلب به وضعیت‌های خارجی وابسته است. کتابخانه از transitionToAsync() برای بررسی‌های ناهمگام دیتابیس پشتیبانی می‌کند. برای مثال، انتقال به حالت «CONFIRMED» می‌تواند مسدود شود اگر یک محافظ ناهمگام در دیتابیس استعلام کند و بفهمد که slotId دیگر در دسترس نیست.
• پنجره متنی مشترک: سیستم از یک شیء context تغییرپذیر به عنوان یک تخته‌سیاه (Scratchpad) برای وضعیت جلسه استفاده می‌کند. ابزارها در هنگام اجرا روی این کانتکست می‌نویسند و محافظ‌ها در هنگام انتقال، اطلاعات را از آن می‌خوانند.
• پایداری بدون سرور (Serverless Persistence): این ابزار برای محیط‌های تولید سال ۲۰۲۶ طراحی شده که در آن هر درخواست به یک نمونه‌ی متفاوت از Lambda می‌رسد. با استفاده از متد snapshot() که خروجی { state: string } دارد، توسعه‌دهندگان می‌توانند وضعیت را در دیتابیس ذخیره کرده و در یک نمونه‌ی جدید بازیابی کنند. این قابلیت نیاز به Redis یا نشست‌های چسبنده (Sticky Sessions) را از بین می‌برد.

این پروژه بسیار سبک است و هسته‌ی آن تنها از سه فایل machine.ts ،tool-gating.ts و loop-shield.ts تشکیل شده است. همچنین شامل ۹۶ تست برای پوشش لبه‌های عملیاتی (Edge Cases) است؛ مواردی نظیر اعتبارسنجی حالت هنگام بازیابی snapshot، سازگاری خروجی Valibot و بازنشانی‌های سازگار Loop Shield در هر پنج آداپتور.

این تغییر، گذاری از «مهندسی پرامپت» به «مهندسی عامل» (Agent Engineering) است. با تبدیل LLM به یک پردازشگر و ماشین حالت به کنترل‌کننده، توسعه‌دهندگان کنترل قطعی (Deterministic) روی مدل‌های غیرقطعی به دست می‌آورند. این امر ریسک «تزریق پرامپت» (Prompt Injection) برای فراخوانی ابزارها را حذف می‌کند، زیرا مدل نمی‌تواند چیزی را که نمی‌بیند، فراخوانی کند.

برای کسانی که گردش‌های کاری پیچیده را مدیریت می‌کنند، این یعنی کاهش هزینه‌ی استنتاج (Inference) — لحظه‌ای که مدل واقعاً جواب تولید می‌کند، شبیه خودِ آشپزی و نه دوره‌ی آموزش آشپز — و حذف هزینه‌های تجاری ناشی از توهمات مدل یا تأخیرهای ناشی از حلقه‌های بی‌نهایت.

گام بعدی شما

• اگر با عدم پایداری عامل‌های خود در محیط Production دست‌وپنجه نرم می‌کنید، کتابخانه را با دستور pnpm add reactive-fsm نصب کنید.
• کد منبع این پروژه تحت لایسنس MIT است؛ آن را بررسی کنید تا متوجه شوید چگونه حصارهای ساختاری جایگزین پرامپت‌های طولانی می‌شوند.
• معماری خود را از حالت «دستور دادن به مدل» به «مدیریت دسترسی مدل» تغییر دهید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.