گردش کار AI به وضعیت پایدار نیاز دارد، نه پرامپت بلندتر
بیشتر قابلیت‌های AI در دمو قابل اعتماد به نظر می‌رسند چون مسیر خوش کوتاه است. یک پرامپت می‌آید، یک جواب می‌رود، و کسی نمی‌پرسد اگر فراخوانی ابزار مهلتش تمام شد، کاربر وسط کار صفحه را تازه کرد، یا خروجی مدل باید به‌جای درخواست بعدی برود زیر بازبینی انسان، چه می‌شود.
برای همین تیم‌ها کیفیت مدل را مقصر شکستی می‌کنند که در واقع طراحی گردش کار است. مدل فقط یک قطعه متحرک است. قطعه شکننده معمولاً اطرافش است: بدون وضعیت پایدار، بدون ازسرگیری، بدون idempotency، بدون رد حسابرسی، و بدون مرز تمیز بین کار سریع درخواست و کار کند پس‌زمینه.
اگر الان قابلیت AI در Next.js می‌سازی، ارتقایی که من برمی‌دارم پرامپت سیستمی بلندتر نیست. یک لایه گردش کار پایدار است که پشت Postgres نشسته.
حالت خرابی واقعی فراموشی گردش کار است
در پروداکشن به‌ندرت این است که مدل اصلاً جواب ندهد. حالت رایج این است که اپ اطرافش یادش نیست چه تلاش شد، چه موفق شد، چه نیمه‌کاره شکست، و قدم بعد چیست.
تیم‌ها اغلب با یک handler شروع می‌کنند که مدل را صدا می‌زند، شاید یک ابزار، شاید دو تا، و بعد نتیجه نهایی را می‌نویسد. برای پیش‌نویس کم‌ارزش یا دستیار دورریختنی کافی است. لحظه‌ای که گردش کار به پول، اعتماد کاربر، یا اثر جانبی وصل است می‌شکند.
همان لحظه که ایمیل می‌فرستی، در CRM می‌نویسی، تیکت را عوض می‌کنی، گزارش می‌سازی، یا غنی‌سازی چندمرحله‌ای را راه می‌اندازی، دیگر چت نمی‌سازی. سیستم عملیاتی می‌سازی. سیستم عملیاتی وضعیتی می‌خواهد که بشود دید و بازیابی کرد.
پایدار یعنی قابل بازرسی، نه پیچیده
پایدار یعنی پیچیده به‌خاطر خودش نیست. یعنی هر اجرای معنادار هویت، وضعیت، تاریخچه قدم، و جایی برای ادامه دارد. اگر فرایند وسط کار بمیرد، باید با یک ردیف یا یک رد بفهمی چه شد، بدون اینکه داستان را از لاگ و حدس بازسازی کنی.
برای بیشتر تیم‌های JavaScript، Postgres کسل‌کننده‌ترین جا برای این وضعیت است و کسل دقیقاً همان چیزی است که این‌جا می‌خواهی. قبل از لایه ارکستراسیون مرموز، یک جدول می‌خواهی که بگوید کدام کار منتظر است، در حال اجراست، مسدود است، شکست خورده، یا تمام شده.
شکلی که دوست دارم ساده است: یک رکورد اجرا، یک رکورد قدم، و یک worker صف که ماشین وضعیت را جلو می‌برد. درخواست وب اجرا را می‌سازد و زود برمی‌گردد. worker کار کند یا شکست‌پذیر را انجام می‌دهد. UI پیشرفت را از دیتابیس می‌خواند، به‌جای اینکه وانمود کند درخواست اصلی می‌تواند کل چرخه را مال خودش کند.
شکلی که ارزش انتشار دارد
طراحی حداقلی معمولاً جدول `workflow_runs` دارد با کلید کسب‌وکار، وضعیت جاری، محموله ورودی، محموله خروجی، تعداد تلاش، زمان‌ها، و در صورت نیاز یک نشانه ازسرگیری. بعد `workflow_steps` برای بازیابی، فراخوانی مدل، اعتبارسنجی، تأیید انسان، و اثر جانبی بیرونی.
این شکاف چیزی است که بیشتر محصول‌های AI ندارند: یک قرارداد قابل دیدن. می‌توانی فوری جواب بدهی کدام اجرا گیر کرده، کدام قدم بیشتر می‌شکند، کدام شکست امن است که دوباره زده شود، کدام به انسان نیاز دارد. بدون این ساختار هر حادثه تبدیل به باستان‌شناسی می‌شود.
کلید کسب‌وکار را از شناسه مدل جدا کن. کاربر و سیستم باید اجرا را با چیزی بشناسند که به کار محصول وصل است، نه با شناسه پاسخ یک ارائه‌دهنده که فردا عوض می‌شود. idempotency را روی همان کلید بگذار تا تازه کردن صفحه و retry صف، اثر جانبی را دو بار انجام ندهد.
مسیر درخواست را کسل نگه دار
مسیر درخواست در Next.js باید کسل بماند. یک action یا route handler ورودی را اعتبار می‌کند، ردیف اجرا می‌سازد، کار را در صف می‌گذارد، و شناسه اجرا را برمی‌گرداند. کلاینت با همان شناسه می‌تواند poll کند، مشترک شود، یا وضعیت رندرشده سرور را تازه کند. هیچ‌کدام از این‌ها لازم ندارد فراخوانی مدل داخل درخواست اصلی کاربر زنده بماند.
این جداسازی بیشتر از قابلیت اطمینان را درست می‌کند. تأخیر را هم درست می‌کند. کاربر نباید داخل یک درخواست طولانی بنشیند تا اپ زمینه بیاورد، چند ابزار را صدا بزند، خروجی ساخت‌یافته را اعتبار کند، و تغییر پایین‌دست بنویسد. تأیید سریع به‌علاوه پیشرفت پایدار محصول بهتری است از جادوی هم‌زمان دروغین.
مرز سالم‌تری هم بین طرح و اجرا می‌گذارد. مدل می‌تواند عمل بعدی را پیشنهاد کند، ولی اپ تصمیم می‌گیرد آن عمل مجاز است یا نه، پیش‌نیاز برقرار است یا نه، و اثر جانبی باید حالا باشد، بعداً، یا فقط بعد از بازبینی.
جایی که تیم‌ها اشتباه می‌کنند
اشتباه رایج این است که چون اول ظریف به نظر می‌رسد، کنترل جریان زیادی را به مدل بسپاری. در پروداکشن آن ظرافت ابهام می‌شود. اگر مدل عملاً با دلالت تصمیم retry، اثر جانبی، و معیار تمام شدن را می‌گیرد، گردش کار محکم نداری. یک مولد رشته متقاعدکننده داری که عملیات را می‌راند.
Postgres را برای وضعیت گردش کار بگذار، نه برای هر توکن. ورودی، خروجی نرمال‌شده، نتیجه ساخت‌یافته ابزار، فراداده قدم، و ایست بازرسی تصمیم را ذخیره کن. هر تکه گذرا را در هسته رابطه‌ای نریز مگر ارزش دیباگ یا انطباق داشته باشد. پایدار یعنی انبار کردن نیست.
برای تجربه استریم هنوز می‌توانی خروجی جزئی مدل را وقتی مفید است نشان بدهی. متن استریم‌شده را با تمام شدن پایدار عوض نکن. اجرا وقتی تمام است که وضعیت گردش کار بگوید تمام است، نه وقتی اولین جواب روی صفحه ظاهر شد.
همین قاعده برای ایجنت هم هست. حلقه ایجنت می‌تواند مفید باشد، ولی افسار می‌خواهد. سقف بودجه ابزار، تعداد قدم، اثر جانبی مجاز، و نقطه تشدید را صریح کن. اگر سیستم نمی‌تواند توضیح دهد چرا ایستاد، چرا دوباره زد، یا چرا ورودی انسان خواست، برای کاری که مهم است آماده نیست.
کی این مهندسی اضافه می‌ارزد
زود جواب می‌دهد در گردش کار با ارزش تأخیردار: خط لوله تحقیق، دسته‌بندی پشتیبانی، آنبوردینگ، غنی‌سازی CRM، بازبینی محتوا، تولید دسته‌ای، و دستیار داخلی که بیشتر از تکمیل خودکار کار می‌کند. همه این‌ها از قابلیت ازسرگیری و حسابرسی بیشتر سود می‌برند تا از یک درجه زیرکی اضافه مدل.
البته بده‌بستان دارد. لایه گردش کار پایدار از یک route handler تنها مهندسی بیشتری می‌خواهد. طرح، گذار وضعیت، سیاست retry، عقب‌نشینی، و مشاهده‌پذیری لازم است. آن هزینه چیز واقعی می‌خرد: حادثه قابل تشخیص می‌شود، اثر جانبی امن‌تر می‌شود، و رفتار محصول دیگر وابسته نیست به اینکه یک درخواست بلند اتفاقی از شبکه جان سالم به در برده یا نه.
اگر قابلیت AI جعبه پیش‌نویس کم‌خطر است، بیش از حد نساز. اگر داده مشتری، محاسبه گران، عمل کسب‌وکار، یا منطق چندمرحله‌ای را لمس می‌کند، نسخه پایدار معمولاً وقتی کشش عملیاتی را حساب کنی ارزان‌تر است.
سیستم AI خوب پروداکشن از داخل جادویی حس نمی‌شود. صریح حس می‌شود. می‌شود بازرسی کرد، دوباره پخش کرد، مکث کرد، و زیر فشار درباره‌اش استدلال کرد. همان چیزی است که قابل اعتمادش می‌کند.
اگر دنبال ارتقای معنادار بعدی در اپ فول‌استک سنگین AI هستی، یک روز دست از جلا دادن پرامپت بردار و چرخه اجرا را طراحی کن. پرامپت هنوز مهم است. گردش کار مهم‌تر است.
پرسش‌های کوتاه
**هر چت را ببرم داخل صف؟** نه. پیش‌نویس کم‌خطر می‌تواند هم‌زمان بماند. صف برای اثر جانبی، کار طولانی، و هر چیزی است که باید بعد از قطع اتصال هنوز وجود داشته باشد.
**وضعیت را در Redis نگه دارم؟** برای قفل و صف کوتاه شاید. منبع حقیقت اجرا را جایی بگذار که بشود با کوئری دید و بعد از ری‌استارت سرور هنوز داستان را داشته باشد. برای بیشتر تیم‌ها این Postgres است.
**استریم را کنار بگذارم؟** نه. استریم را پیشرفت UI حساب کن. تمام شدن را فقط از وضعیت اجرا بخوان.