تصور کنید یک عامل هوش مصنوعی باید مسئولیت یک سفارش مشتری را از لحظه ثبت تا تحویل نهایی بر عهده بگیرد، بدون اینکه تمام مدت در حال پردازش باشد. اگر هنوز از مدل‌های ساده‌ای استفاده می‌کنید که پس از هر پاسخ فراموش می‌کنند در کجای مسیر هستند، باید بدانید که معماری‌های جدید در حال حذف این نقطه ضعف هستند. یک عامل هوش مصنوعی که مسئولیت یک سفارش مشتری را از ایجاد تا تحویل بر عهده می‌گیرد، به معماری متفاوتی نسبت به یک چت‌بات استاندارد نیاز دارد. اکثر عامل‌ها پس از یک پاسخ متوقف می‌شوند، اما پروژه Order Supervisor (ناظر سفارش) که جزئیات آن در ۲۲ جولای ۲۰۲۶ منتشر شد، ثابت می‌کند که یک عامل (Agent) می‌تواند از پردازش فعال به حالت خروشی (Dormant) برود و تنها زمانی «بیدار» شود که یک رویداد مشخص رخ دهد.
عامل‌های هوش مصنوعی سنتی اغلب زمانی که یک جلسه (Session) به پایان می‌رسد یا یک سرور ری‌استارت می‌شود، جایگاه خود را در فرآیند گم می‌کنند. برای یک فرآیند واقعی مانند تکمیل سفارش که می‌تواند ساعت‌ها یا حتی روزها طول بکشد، این شکاف یک نقطه شکست بحرانی است. پیاده‌سازی فعلی این شکاف را با تبدیل LLM به یک «تصمیم‌گیرنده» به جای «ارکستراتور اصلی فرآیند» پر می‌کند. طبق گزارش‌های فنی، این رویکرد اجازه می‌دهد تا سیستم بدون از دست دادن پیشینه، در حالت انتظار باقی بماند.
همان‌طور که در تحلیل‌های پیشین ما درباره امنیت مدل‌های بازمتن و مدیریت وضعیت اشاره کردیم، تکیه بر حافظه کوتاه‌مدت مدل‌ها برای عملیات‌های طولانی‌مدت یک ریسک بزرگ است. این سیستم با استفاده از یک زیرساخت سخت‌گیرانه، این ریسک را حذف می‌کند. چنین رویکردی در واقع پاسخی به چالش‌های رایج در مدیریت چرخه حیات عامل‌هاست؛ چرا که ناپایداری در اجرای زمان-اجرا می‌تواند منجر به ایجاد حلقه‌های تکرار هزینه‌بر در مدل‌ها شود که در اینجا با استفاده از Temporal کنترل شده است.
به نقل از راهنمای فنی dev.to، این سامانه بر ترکیبی از ابزارهای با قابلیت اطمینان بالا استوار است تا تضمین شود هیچ وضعیتی (State) از دست نمی‌رود:
- Temporal: مدیریت گردش‌های کاری طولانی (Long-running workflows) و ارائه قابلیت ماندگاری وضعیت. این ابزار تضمین می‌کند که سیستم پس از یک ری‌استارت، دقیقاً از جایی که متوقف شده بود ادامه دهد.
- FastAPI: به عنوان لایه API پشتیبان (Backend) عمل می‌کند.
- PostgreSQL: برای ذخیره داده‌های دائمی برنامه استفاده می‌شود.
- Ollama: میزبان مدل زبانی کوچک (SLM) — مثل یک دستیار متخصص که روی یک موضوع خاص آموزش دیده تا سریع‌تر و ارزان‌تر جواب دهد — که در اینجا مدل Phi-3 Mini برای تصمیم‌گیری استفاده شده است.
- Next.js: رابط کاربری را برای ایجاد سفارش‌ها، ارسال رویدادها و نظارت بر فعالیت‌های ناظر فراهم می‌کند.
در قلب این سیستم، هر سفارش یک گردش کار مستقل در Temporal دارد. این یعنی برای هر سفارش، یک instance جداگانه ایجاد می‌شود. گردش کار با ثبت سفارش آغاز می‌شود و تا زمان تکمیل یا خاتمه (Termination) سفارش فعال می‌ماند.
وقتی یک اجرای جدید ایجاد می‌شود، بک‌اند ابتدا یک رکورد در دیتابیس می‌سازد و سپس یک گردش کار را با استفاده از یک شناسه منحصربه‌فرد، مانند order-supervisor-{run.id}، آغاز می‌کند. این فرآیند با یک توالی مشخص اجرا می‌شود: ابتدا بک‌اند رکورد را می‌سازد، سپس گردش کار را روی صف order-supervisor-queue اجرا کرده و در نهایت یک سیگنال اولیه به نام run_created حاوی run_id ارسال می‌کند.
این ساختار تضمین می‌کند که عامل برای رسیدگی به یک به‌روزرسانی، نیازی به بارگذاری مجدد تاریخچه هزاران سفارش دیگر ندارد و فشار حافظه روی مدل کاهش می‌یابد. هر گردش کار مستقیماً از طریق شناسه گردش کار به اجرای خود متصل است و به هر سفارش، ناظر مستقل خود را می‌دهد.
به جای اینکه مدل زبانی به‌طور مداوم مورد بازجویی (Polling) قرار بگیرد، ناظر بیشتر زمان خود را منتظر «سیگنال‌ها» می‌گذراند. سیستم از ۱۰ نوع رویداد خاص پشتیبانی می‌کند که می‌تواند باعث بیداری مدل و تحریک یک تصمیم جدید شود، از جمله:
- شکست در پرداخت (
payment_failed) - تاخیر در ارسال (
shipment_delayed) - درخواست بازگشت وجه (
refund_requested) - دریافت پیام مشتری (
customer_message_received)
وقتی یک سیگنال می‌رسد، از طریق یک هندلر Temporal به گردش کار موجود ارسال می‌شود. در این لحظه، گردش کار بیدار شده، زمینه (Context) فعلی را بازیابی می‌کند و از مدل زبانی درخواست تصمیم می‌گیرد. این مکانیسم اجازه می‌دهد تا اطلاعات جدید به همان ناظری برسد که پیش از این با سفارش درگیر بوده است، بدون اینکه نیاز باشد فرآیند از نقطه صفر شروع شود؛ زیرا گردش کار تمام پیشینه اتفاقات قبلی را حفظ کرده است.
هر بار که ناظر بیدار می‌شود، یک پرامپت (Prompt) مفصل و غنی از زمینه می‌سازد تا مدل مسیر سفارش را گم نکند و دچار توهم نشود. این پرامپت شامل ۶ رکن حیاتی است:
۱. شناسه سفارش (Order ID) و وضعیت فعلی (Status)
۲. آخرین رویداد: رویداد JSON مشخصی که باعث اجرای این مرحله شده است (یا عبارت «Workflow started» در صورت شروع).
۳. خط زمانی (Timeline): لیستی فرمت شده از تمام رویدادهای پیشین.
۴. خلاصه‌ی حافظه: یک تاریخچه فشرده و تلخیص شده از سفارش.
۵. دستورالعمل‌های اضافی: یادداشت‌های سفارشی که کاربران در حین اجرای ناظر اضافه کرده‌اند.
۶. ابزارهای موجود: لیستی از اقدامات مجاز به صورت JSON.
کاربران می‌توانند در میانه مسیر، دستوراتی مانند درخواست برای «مدیریت ویژه» یا «تغییر اولویت» را اضافه کنند. این یادداشت‌ها در بخش «دستورالعمل‌های اضافی» در پرامپت بعدی قرار می‌گیرند. این بدان معناست که برای به‌روزرسانی رفتار عامل، نیازی به ری‌استارت کردن یا بازسازی گردش کار نیست.
بر اساس مستندات این پروژه، مدل زبانی تنها به مجموعه‌ای محدود و پیش‌تعریف شده از ابزارها دسترسی دارد. مدل نمی‌تواند اقدامات جدیدی ابداع کند؛ او فقط باید از لیست ابزارهای ارائه شده یکی را انتخاب کند یا تصمیم بگیرد که هیچ اقدامی نیاز نیست. توسعه‌دهنده پنج اقدام مشخص را برای ارتباط با مشتریان و تیم‌های پرداخت، تکمیل سفارش و لجستیک تعریف کرده است و همچنین گزینه‌ای برای ایجاد یک یادداشت داخلی (Internal Note) در نظر گرفته است.
پس از اینکه مدل تصمیم خود را بازگرداند، برنامه اقدام انتخاب شده را بررسی کرده و منطق متناظر با آن را اجرا می‌کند. این طراحی تضمین می‌کند که در حالی که مدل تصمیم می‌گیرد «چه کاری» انجام شود، این برنامه است که کنترل می‌کند مدل «واقعاً اجازه انجام چه کاری را دارد». برای جلوگیری از بروز خطاهای ساختاری در خروجی‌ها، این محدودیت‌ها ضروری هستند، چرا که عدم پایبندی مدل‌ها به استانداردهای تعریف‌شده در طول زمان یکی از چالش‌های اصلی در توسعه سیستم‌های مبتنی بر کد و ابزار است.
مهم‌ترین مکانیسم این سیستم، منطق sleep_until یا خواب هوشمند است. اگر مدل تشخیص دهد که سفارش طبق روال طبیعی پیش می‌رود، هیچ دلیلی وجود ندارد که مدل به‌طور مداوم فراخوانی شود. در این حالت، گردش کار یک زمان بیداری محاسبه می‌کند یا صرفاً منتظر رویداد بعدی می‌ماند.
در کد برنامه، این موضوع توسط یک wait_condition مدیریت می‌شود. سیستم چندین محرک را برای بیداری نظارت می‌کند: رویدادهای در انتظار، پرچم force_complete (تکمیل اجباری)، تغییر در وضعیت سفارش، یا رسیدن به یک وضعیت نهایی (Terminal Status). برای اینکه در نسخه دمو، سیستم پاسخگو باقی بماند، هر مدت‌زمان خواب محاسبه شده حداکثر به ۲ دقیقه محدود شده است.
به دلیل اینکه ارکستراسیون و مدیریت وضعیت توسط Temporal انجام می‌شود و نه توسط مدل، لایه هوش مصنوعی کاملاً جایگزین‌پذیر (Model Agnostic) است. توسعه‌دهنده برای تست‌های محلی از Phi-3 Mini از طریق Ollama استفاده کرد. هرچند این مدل برای گردش کار کافی بود، اما مدل‌های کوچک‌تر گاهی در انتخاب سازگار ابزارها و فرمت‌بندی پاسخ‌ها دچار مشکل می‌شدند.
از آنجایی که یکپارچه‌سازی LLM از یک API سازگار با OpenAI استفاده می‌کند، می‌توان لایه مدل را به هر ارائه‌دهنده دیگری (مانند GPT-4 یا Claude) تغییر داد بدون اینکه نیازی به تغییر در گردش کار Temporal باشد. این جداسازی ثابت می‌کند که اثربخشی یک عامل، تنها به توان استدلالی مدل نیست، بلکه به زیرساختی وابسته است که وضعیت (State) آن را مدیریت می‌کند.
با جداسازی تصمیم‌گیری از مدیریت فرآیند، سیستم به قابلیت اطمینانی دست می‌یابد که LLM به تنهایی قادر به فراهم کردن آن نیست. درس اصلی این است: یک عامل برای مسئولیت‌پذیر بودن نیاز نیست همیشه در حال اجرا باشد؛ او فقط باید بداند چه زمانی بیدار شود.
برای کسانی که در حال ساخت عامل‌های سطح تولید (Production) هستند، این رویکرد یک تغییر پارادایم را پیشنهاد می‌کند: تلاش برای اینکه LLMها همه چیز را به خاطر بسپارند متوقف کنید و در عوض، یک «اسکلت» بادوام بسازید که دقیقاً به LLM بگوید چه زمانی بیدار شود و به چه چیزی نگاه کند.
برای پیاده‌سازی این مدل، توسعه‌دهندگان باید مکانیسم‌های سیگنال (Signal) و پرس‌وجو (Query) در Temporal را برای مدیریت رویدادهای نامتقارن (Asynchronous) دنیای واقعی بررسی کنند.
گام بعدی شما
- بررسی مکانیسم‌های Signal و Query در Temporal برای مدیریت رویدادهای نامتقارن.
- جایگزینی مدل‌های کوچک با مدل‌های استدلالی پیشرفته‌تر برای تست دقت در انتخاب ابزار.
- پیاده‌سازی لایه «دستورالعمل‌های پویا» برای تغییر رفتار عامل بدون توقف فرآیند.
اما اثر این معماری بر کاهش هزینه‌های استنتاج در مقیاس میلیونی شگفت‌انگیز است — به تحلیل ما درباره بهینه‌سازی هزینه GPU مراجعه کنید.
گفتگو