AI SDK 6 برای خیلی از چت‌های محصول دیگر به اندازه کافی خوب بود. استریم تایپ‌دار، عوض کردن ارائه‌دهنده، و فراخوانی ابزار که شبیه پروژه آزمایشگاهی نباشد. نسخه ۷، حوالی اواخر ژوئن ۲۰۲۶، حرف دیگری می‌زند: ایجنت را حلقه داخل حافظه ندان که با هر استقرار می‌میرد. چیزی بدان که بتواند برای تأیید بایستد و ساعت‌ها بعد بیدار شود.
بحث ارزشمند همین است. نه اینکه نقشه راه از این به بعد در هر اسلاید کلمه agents داشته باشد.
چه چیزی برای پروداکشن عوض شد
واحد اصلی WorkflowAgent از بسته @ai-sdk/workflow است. ایده حلقه ابزار همان ایجنت سبک داخل حافظه است، با این فرق که هر اجرای ابزار داخل یک گام workflow می‌نشیند. وضعیت بین گام‌ها می‌ماند. ری‌استارت، مهلت، و تأییدی که دیر می‌رسد دیگر معنی‌اش این نیست که کل اجرا را از نو شروع کنی و امیدوار باشی اثر جانبی را دو بار نزده باشی.
تأیید ابزار درجه اول است. ابزار را با needsApproval علامت بزن، اجرا معلق می‌شود، کاربر یا بازبین داخلی بعداً تأیید یا رد می‌کند، و workflow ادامه می‌دهد. جریان پرریسک می‌تواند ورودی را دوباره اعتبار کند و تأیید را محکم‌تر به آرگومان ببندد، تا چیزی اجرا شود که واقعاً تأیید شده، نه نسخه‌ای که بعد از مکث عوض شده. این فرق چک‌باکس HITL در دمو با چیزی است که کنار استقرار یا تغییر صورتحساب می‌گذارم.
سطح پلتفرم هم هست: زمینه اجرای تایپ‌دار، مهلت به‌عنوان بودجه واقعی، قلاب تله‌متری، MCP Apps، یک رابط ترمینال برای دست زدن به ایجنت قبل از UI محصول، و استدلال مستقل از ارائه‌دهنده روی generateText و streamText. مفیدند. فرعی‌اند نسبت به این سؤال که حلقه از چرخه عمر پروسه پروداکشن جان به در می‌برد یا نه.
مالیات مهاجرت نظری نیست
حداقل Node 22. ESM لازم است؛ import یا فایل .mjs، نه require راحت CommonJS برای همیشه. کدمد و مهارت مهاجرت وجود دارد. سیاست ران‌تایم را به‌جایت تصمیم نمی‌گیرند. شکل دستور و پیام عوض می‌شود. زمینه اجرا و زمینه ابزار از هم جدا می‌شوند. کمک‌کننده‌های استریم و شکل نتیجه چندگامی آن‌قدر عوض می‌شوند که «تایپ‌چک شد» تعریف ضعیفی از تمام شدن است.
اگر روی AI SDK 6 یک ویجت چت کوتاه داری، جهش سبز به نسخه ۷ می‌تواند صبر کند. اگر دوام را خودت با جدول ردیف اجرا و مسیر ازسرگیری شکننده ساخته‌ای، مالیات ممکن است ارزان‌تر از نگهداری همان WorkflowAgent خصوصی باشد.
مونوریپو را «چون ایجنت» ارتقا نمی‌دهم. بسته‌ای را ارتقا می‌دهم که مالک حلقه ابزار طولانی با اثر جانبی است. چت‌بات بازاریابی را تا وقتی دود بنشیند تنها می‌گذارم. دو سطح در یک ریپو قابل دفاع است، به شرطی که مرزشان در کد معلوم باشد نه در یادداشت جلسه.
کی WorkflowAgent دلیل درست پذیرش است
وقتی ایجنت باید از یک فراخوانی serverless بیشتر عمر کند: پژوهش چندگامی که ابزار می‌زند، منتظر انسان می‌ماند، بعد ادامه می‌دهد؛ ایجنت عملیات که PR باز می‌کند و برای بازبینی می‌ایستد؛ هر چیزی که اگر استقرار وسط اجرا اثر جانبی را تکرار کند حادثه است.
مسیر تأیید را وقتی بگذار که ابزار پول خرج می‌کند، اسکیما را عوض می‌کند، به سیستم نزدیک پروداکشن دست می‌زند، یا کد منتشر می‌کند. needsApproval را روی خواندن یک فایل ریپو نگذار و بعد تعجب نکن چرا کسی محصول را دوست ندارد. تأیید باید کمیاب و گران باشد، وگرنه تبدیل به کلیک عادت می‌شود و کسی آرگومان را نمی‌خواند.
استدلال مستقل از ارائه‌دهنده را وقتی استفاده کن که واقعاً ارائه‌دهنده عوض می‌کنی و از سه لهجه پیکربندی موازی خسته شده‌ای. آن را به‌خودی‌خود ارتقای کیفیت ندان. ارائه‌دهنده‌ها هنوز روی معنی «بالا» توافق ندارند. اگر فقط یک مدل داری، این سطح را دلیل مهاجرت نکن.
کی صبر می‌کنم
اگر فیچر یک generate تک‌نوبتی با یک ابزار و بدون داستان ازسرگیری است، سر جایت بمان. اگر ران‌تایم هنوز Node 20 است و بقیه ناوگان تکان نخورده، AI SDK را دلیل دوشاخه کردن پلتفرم نکن. اگر شناسه نشست، بودجه، و نقطه تأیید را تعریف نکرده‌ای، فریمورک پایدار فقط آشوب را طولانی‌تر ذخیره می‌کند.
بلوغ نسخه ۶ این بود که SDK برای کار جدی اپ آماده است یا نه. سؤال نسخه ۷ باریک‌تر است: حلقه ایجنت پایدار و قابل تأیید را آن‌قدر لازم داری که هزینه Node 22، ESM، و یک گذر مهاجرت واقعی را بدهی؟
هویت نشست را قبل از اولین گام بنویس. اگر بعد از استقرار نتوانی بگویی این ادامه همان اجراست، دوام فقط لاگ قشنگ‌تر است. بودجه را هم به همان هویت گره بزن. اجرای ازسرگرفته‌شده که سقف را از نو می‌شمارد، صورتحساب را دور می‌زند.
میله من برای ادغام ارتقا
یک اجرا بتواند روی ابزار تغییردهنده بایستد، از استقرار جان به در ببرد، و با همان هویت نشست ادامه دهد. تأیید به آرگومان‌هایی که برایت مهم است بسته شود. مهلت بلند سروصدا شکست بخورد، نه اینکه کارگر صف را آویزان کند. تله‌متری مرز گام را طوری نشان دهد که انسان وسط حادثه بتواند استفاده کند. پوشش ارزیابی حداقل یک مسیر قطع‌شده و ازسرگرفته‌شده را داشته باشد.
اگر به این میله برسی، WorkflowAgent خرجش را درمی‌آورد. اگر نرسی، حلقه چت را اسم عوض کرده‌ای، خط Node را بالا برده‌ای، و «پلتفرم ایجنت» را به README اضافه کرده‌ای بدون اینکه حالت شکستی که فصل قبل سوزاند عوض شود. برای حلقه قابل ازسرگیری و تأیید بگیرش. واژه مد را روی بلاگ انتشار بگذار.
ابزار فقط‌خواندنی را داخل همان حلقه پایدار قاطی ابزار نوشتنی نکن، مگر اینکه دلیل عملیاتی داشته باشی. دوام برای اثری است که تکرارش گران است. برای پرس‌وجویی که می‌شود دوباره زد، پیچیدگی ازسرگیری معمولاً بیشتر از سودش است. همان‌جا AI SDK 6 را نگه دار تا درد واقعی بیاید.
استقرار وسط اجرا را سناریو بدان، نه استثنا
بیشتر تیم‌ها دوام را با جمله «اگر پروسه مرد» طراحی می‌کنند. در پلتفرم ابری پروسه وسط کار سالم هم عوض می‌شود. استقرار، مقیاس به صفر، و مهلت دروازه، حلقه داخل حافظه را بی‌سروصدا می‌کشند. اگر ابزار قبلاً یک بار اثر گذاشته و گام دوم هنوز نوشته نشده، ازسرگیری خام همان اثر را تکرار می‌کند. WorkflowAgent این را جادویی حل نمی‌کند. فقط مرز گام را جایی می‌گذارد که یکبارمصرف بودن را بشود به همان گام بست.
شناسه اجرا باید قبل از اولین اثر جانبی وجود داشته باشد و در لاگ فروشنده، صف، و جدول خودت یکی باشد. تأیید هم باید به همان شناسه و به همان آرگومان برگردد. اگر کاربر ساعت‌ها بعد تأیید کند و ورودی زیرش عوض شده باشد، ادامه دادن با آرگومان کهنه یا با آرگومان تازه هر دو خطرناکند. خطر کمتر این است که اجرا را باطل کنی و از نو، با بودجه تازه، اجازه بدهی. خطر بیشتر این است که «همان نشست» را بهانه کنی و عمل دیگری انجام شود.
تله‌متری را برای انسان حادثه بنویس نه برای نمودار. نام گام، دلیل توقف، و اینکه تأیید منتظر کیست، باید در یک نگاه پیدا شود. اگر برای فهمیدن وضعیت باید رد مدل را بخوانی، دوام را به تیم عملیات تحویل نداده‌ای. فقط ذخیره را پیچیده‌تر کرده‌ای.
این میله را روی چت بازاریابی پیاده نکن. همان‌جا هزینه مهاجرت Node 22 و ESM هیچ دردی را کم نمی‌کند. میله را روی جریانی بگذار که تکرار اثر جانبی‌اش حادثه است. اگر چنین جریانی نداری، نسخه ۷ را در سند تصمیم بنویس و در پروداکشن باز نکن.