اگر ساعت‌ها وقت خود را صرف تغییر پرامپت‌ها برای بهبود جریان‌های کاری ایمیلی مبتنی بر LLM کرده‌اید و هنوز با خطا مواجه می‌شوید، احتمالاً مشکل از خود مدل نیست. باید بدانید که گلوگاه اصلی در بسیاری از سامانه‌ها، به‌ندرت خود مدل است، بلکه سیستم‌ها به‌دلیل وجود «صف‌های نامرئی» فرو می‌پاشند؛ جایی که پیام‌ها فاقد زمینه (Context) هستند، بازپخشی‌ها (Retries) وضعیت‌های قبلی را بازنویسی می‌کنند و تأییدیه‌های انسانی چنان دیر می‌رسند که دیگر کاربردی ندارند.
به گزارش یک توسعه‌دهنده در پلتفرم dev.to، تا ۱۸ جولای ۲۰۲۶ مشخص شده است که دلیل اصلی فروپاشی این سیستم‌ها ساده‌تر از این حرف‌هاست: سامانه نمی‌تواند توضیح دهد که هر پیام دقیقاً متعلق به کدام اجرای خاص (Specific Run) است. این وضعیت باعث می‌شود پاسخ‌های انسانی دیر برسند یا بازپخشی‌های خودکار، وضعیت‌های قبلی را بازنویسی کنند و در نهایت کل جریان عملیاتی مختل شود.
همان‌طور که در تحلیل قبلی ما درباره‌ی PromptOS و استفاده از مدل‌ها برای نقشه‌های سخت‌افزاری (Hardware-aware Blueprints) اشاره کردیم، اکنون شاهد چرخشی در اولویت‌های توسعه هستیم؛ گذار از مهندسی پرامپت به سمت معماری مستحکم عامل‌ها (Robust Agent Architecture). در محیط‌های ناهمگام (Asynchronous) مانند ایمیل — که ذاتاً کند و پرنویز است — نمی‌توان روی زمینه محلی (Local Context) حساب کرد. بنابراین هر پیام باید بخشی از «قرارداد ساختاری» جریان را با خود حمل کند تا قابل ردیابی باشد و پیوستگی عملیاتی حفظ شود.
کالبدشناسی شکست
طبق گزارش dev.to، یک طراحی شکننده زمانی رخ می‌دهد که یک انسان یا یک پردازشگر (Worker) نتواند تنها با نگاه کردن به موضوع ایمیل، برخی هدرها و یک run_id، یک اجرای خاص را شناسایی کند. شکست‌های رایج در این سیستم‌ها معمولاً spectacular یا spektakular نیستند، بلکه حاصل مجموعه‌ای از مشکلات کوچک و تکرار شونده‌اند:
- بازپخشی‌هایی (Retries) که یک درخواست قدیمی را مجدداً ارسال می‌کنند.
- پاسخ‌های انسانی که به اینباکس درست می‌رسند، اما به اجرای عملیاتی اشتباهی نسبت داده می‌شوند.
- عامل‌هایی که به‌دلیل فیلترهای بیش از حد گسترده، پیام‌های قبلی را دوباره می‌خوانند و در حلقه تکرار می‌افتند.
این مسائل توسط مدل‌های زبانی بزرگ (LLM) تشدید می‌شوند. مدل زبانی بزرگ — شبیه کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — تمایل دارد با هر زمینه‌ای که به‌نظر منطقی و محتمل برسد پیش برود، حتی اگر آن زمینه از نظر منطقی غلط باشد. این وضعیت دقیقاً بازتاب‌دهنده مشکلات عملیاتی در «دفترچه‌های راهنمای عملیاتی» (Runbooks) برای ایمیل‌های سازمانی است: دریافت سیگنال‌ها کافی نیست؛ شما باید بتوانید تصمیم را بدون هیچ ابهامی مسیریابی کنید.
قرارداد مشاهده‌پذیر حداقلی
برای حل این مشکل، نویسنده مقاله یک «قرارداد مشاهده‌پذیر حداقلی» (Minimum Observable Contract) را پیشنهاد می‌کند که باید به‌طور هم‌زمان در سه نقطه قرار گیرد: موضوع ایمیل، متادیتای داخلی و لاگ‌ها (Logs). اگر این قرارداد فقط در پایگاه‌داده باشد، عیب‌یابی بسیار دیر اتفاق می‌افتد و زمانی که متوجه خطا می‌شویم دیگر دیر شده است؛ و اگر این قرارداد فقط در متن ایمیل باشد، پردازشگرها (Workers) نسبت به وضعیت سیستم کور می‌مانند. این ساختار به اپراتور اجازه می‌دهد بدون نیاز به انجام «باستان‌شناسی عجیب» در دیتابیس، تاریخچه اجرای سیستم را بازسازی کند.
این قرارداد باید شامل موارد زیر باشد:
- run_id: یک شناسه‌ی کوتاه و پایدار برای هر اجرای خاص.
- step_id: نام مرحله فعلی، مانند 'approval' (تاییدیه)، 'fallback' (بازگشت/جایگزین) یا 'digest' (خلاصه).
- actor: پاسخ‌دهنده‌ی مورد انتظار، خواه یک انسان باشد، یک عامل (Agent) یا یک پردازشگر سیستم (Worker).
- expires_at: یک برچسب زمانی (Timestamp) برای تعیین اینکه آیا پاسخ دریافتی هنوز معتبر است یا منقضی شده است.
یک نمونه داده (Payload) ساده برای چنین سیستمی به این شکل خواهد بود: { "run_id": "a41f9c", "step_id": "approval", "actor": "human", "expires_at": "2026-07-18T15:00:00Z", "reply_token": "rt_7d92..." }.
این رویکرد جایگزین روش‌های شکست‌خورده‌ای می‌شود که به‌طور رایج برای وصله کردن سیستم‌ها استفاده می‌شوند، مانند «جست‌وجو برای آخرین ایمیل دریافت‌شده». نویسنده به بررسی اخیر جریانی اشاره می‌کند که برای تفکیک تست‌های داخلی از متون واقعی، بر یک برچسب دستی به نام «tem email» تکیه کرده بود؛ در حالی که این روش برای یک اجرای واحد جواب می‌داد، اما به‌محض اینکه سه پردازشگر به‌صورت هم‌زمان (Concurrent) وارد عمل شدند، سیستم بلافاصله با شکست مواجه شد.
تفکیک تحویل از تصمیم‌گیری
در این معماری، «تحویل» (Delivery) از «تصمیم‌گیری» (Decision) جدا می‌شود. جریان کاری از یک توالی مشخص پیروی می‌کند: ابتدا عامل LLM تصمیم می‌گیرد که ارسال یک ایمیل لازم است، سپس یک سرویس پیام‌رسان، پیام را همراه با قرارداد مشاهده‌پذیر تولید می‌کند، صف (Queue) پیام را تحویل داده و یک اجاره (Lease) کوتاه ذخیره می‌کند، و در نهایت یک مصرف‌کننده (Consumer) به‌صورت اختصاصی منتظر پاسخی می‌ماند که دقیقاً به آن run_id و مرحله (Stage) متصل است.
مکانیزم‌های کلیدی این ساختار عبارتند از:
- بازپخشی‌های Idempotent: یک بازپخشی در لایه انتقال (Transport Retry) می‌تواند یک تحویل جدید ایجاد کند، اما به‌هیچ‌وجه نباید باعث بازگشایش تصمیماتی شود که پیش‌تر منقضی شده‌اند.
- جایگزین‌های صریح (Explicit Fallbacks): مسیرهای جایگزین ایمیل باید یک لایه صریح باشند، نه یک خروجی بداهه و improvisه. اگر یک fallback دارای قرارداد باشد، سیستم با نظم کاهش کیفیت می‌یابد (Degrade)، اما بدون آن، فقط نویز اضافه می‌کند.
- پایان تعریف‌شده (Defined Termination): عامل‌ها باید منطق پیش‌فرضی برای عدم پاسخ داشته باشند؛ اقداماتی نظیر ارجاع به اینباکس پشتیبانی، بستن اجرا با وضعیت timeout، ادامه مسیر از طریق یک راه محافظه‌کارانه، یا درخواست تاییدیه جدید همراه با زمینه خلاصه شده.
برای متخصصان، این به معنای تغییر تمرکز از پرامپت به خط لوله (Pipeline) است. هدف نهایی این است که لاگ‌ها بتوانند تاریخچه یک تصمیم را به‌طور کامل بازسازی کنند. اگر یک عامل صرفاً تمام رشته ایمیل را بدون خلاصه کردن زمینه کپی کند، نویزی ایجاد می‌کند که عیب‌یابی را تقریباً غیرممکن می‌سازد.
چک‌لیست پیاده‌سازی
برای جلوگیری از مخلوط شدن اجراها (Mixing Runs)، نویسنده یک چک‌لیست مشخص برای حسابرسی سیستم‌ها ارائه می‌دهد:
- آیا هر ایمیل دارای یک run_id است که خارج از پایگاه‌داده قابل مشاهده باشد؟
- آیا فیلتر جست‌وجوی پاسخ، به جای تمرکز صرف روی فرستنده، بر اساس «اجرا» و «مرحله» فیلتر می‌کند؟
- آیا بازپخشی‌ها خاصیت Idempotency را حفظ کرده و تاییدیه های قدیمی را نادیده می‌گیرند؟
- آیا Time-out ها وضعیت جریان را به‌طور صریح تغییر می‌دهند؟
- آیا لاگ‌ها رابطه بین پیام، تصمیم و پردازشگر را به‌درستی نگاشت می‌کنند؟
- آیا عامل قبل از ارسال مجدد، زمینه را خلاصه می‌کند یا کل رشته ایمیل را کپی می‌کند؟
این رویکرد نه‌تنها برای عامل‌های پیچیده، بلکه برای اتوماسیون‌های ساده مانند خلاصه‌های روزانه، جریان‌های پذیرش کاربر (Onboarding) یا سیستم‌های تاییدیه نیز کاربرد دارد. صرف‌نظر از ابزار مورد استفاده — چه از صف‌های موجود استفاده کنید و چه از Jobهای بک‌اند — اولویت اصلی، جداسازی تحویل، انتظار و تصمیم‌گیری است.
در نهایت، قابلیت اطمینان یک عامل هوش مصنوعی به پیش‌بینی‌پذیری داده‌هایی بستگی دارد که مصرف می‌کند. توسعه‌دهندگان با استفاده از قراردادهای مشاهده‌پذیر، از بروز «باگ‌های زشت» که فقط در شرایط هم‌زمانی دنیای واقعی ظاهر می‌شوند، جلوگیری می‌کنند. اگر عامل‌های شما از ایمیل به عنوان بخشی از مدار تصمیم‌گیری استفاده می‌کنند، قرارداد مشاهده‌پذیر را بر پرامپت ترجیح دهید.
گفتگو