AI SDK 6 اواخر دسامبر ۲۰۲۵ برای من به خاطر فهرست قابلیت تازه مهم نبود. لحن انتشار مهم بود. کمتر عجله برای ثابت کردن اینکه ابزار AI همه‌چیز را می‌تواند، بیشتر از آن نوع تکرار که وقتی فریمورک به نحوه تحویل و نگهداری محصول توجه می‌کند دیده می‌شود. استریم تایپ‌دار، عوض کردن ارائه‌دهنده، و فراخوانی ابزار از قبل جدی شده بودند. نسخه ۶ بیشتر گفت این‌ها دیگر آزمایش کناری نیستند.
قبل از هیجان سه سؤال را جواب می‌دهم: چه چیزی آسان‌تر شد، چه چیزی امن‌تر شد، و چه چیزی هنوز سخت است. این قاب جلوی قاطی کردن شتاب پلتفرم با آمادگی محصول را می‌گیرد.
چه چیزی واقعاً قابل استفاده شد
انتزاع Agent این است که مدل، دستور، و ابزار را یک بار تعریف کنی و در اپ تکرار نکنی. ToolLoopAgent پیاده‌سازی آماده حلقه است: مدل را با پرامپت صدا می‌زند، ابزار خواسته‌شده را اجرا می‌کند، نتیجه را به گفتگو برمی‌گرداند، و تا شرط توقف ادامه می‌دهد. کلاس آزمایشی قبلی جایش را به همین داده. پارامتر system به instructions عوض شده. این‌ها جزئیات مهاجرت‌اند، ولی معنی محصولی دارند: ایجنت دیگر یک تابع گم در یک مسیر API نیست. واحدی است که می‌شود در چند سطح استفاده کرد، به شرطی که خودت مرزش را کوچک نگه داری.
تأیید اجرای ابزار، حالت strict روی ورودی، و مثال ورودی برای هم‌ترازی، همان جاهایی است که روز دوم می‌سوخت. قبلاً برای ترکیب ابزار و خروجی ساخت‌یافته باید generateText و generateObject را زنجیره می‌کردی. نسخه ۶ این دو را طوری جمع کرد که حلقه چندگامی ابزار بتواند آخرش خروجی ساخت‌یافته بدهد. MCP هم از «یکپارچه‌سازی جانبی» به سطح عادی SDK نزدیک‌تر شد. DevTools برای دیدن حلقه قبل از اینکه UI محصول را سیم کنی مفید است، نه به‌عنوان محصول.
پیش‌فرض توقف را جدی بگیر. در مهاجرت، stopWhen پیش‌فرض ToolLoopAgent از یک گام به stepCountIs(20) عوض شده. این ارتقای کیفیت نیست. اگر بی‌خبر ارث ببری، یک درخواست می‌تواند تا بیست دور ابزار برود. برای چت کوتاه این اغلب زیاد است. سقف را خودت بنویس، نه اینکه عدد مستندات را بودجه محصول بدانی.
چرا برای تیم محصول مهم است
سختی یکپارچه‌سازی اولیه نیست. سختی منسجم ماندن محصول است بین عوض شدن پرامپت، ارتقای مدل، جریان UI تازه، و کشمکش سرعت و کیفیت و هزینه. ارزش انتشار وقتی واقعی است که شکل اپ اطرافش عوض شود. شاید یک مسیر هم‌زمان بالاخره ناهم‌زمان شود. شاید گردش کار به گام قابل اتکای کوچک‌تر بشکند. شاید قابلیت گران را جراحی استفاده کنی، نه اینکه روی کل محصول بپاشی.
در کار روزانه این جابه‌جایی در جاهای کم‌زرق‌وبرق دیده می‌شود. تیکت را چطور محدوده می‌کنی، برای تأخیر چه بودجه‌ای می‌گذاری، چه چیزی را کش می‌کنی، کدام نقطه پایانی تعاملی می‌ماند، و کجا بالاخره جرئت می‌کنی راه‌حل موقتی چندماهه را برداری. وقتی قابلیت زیرین پایدارتر است، حرف محصول و مهندسی کمتر حدسی می‌شود. می‌شود درباره ترتیب انتشار، مسیر جایگزین، مشاهده، و پشتیبانی حرف زد، نه فقط اینکه تجربه اصلی اصلاً سر پا می‌ماند یا نه.
چطور در محصول زنده به کارش ببرم
انتشار بلوغ وقتی مفید است که چسب سفارشی را کم کند، نه اینکه لایه تازه اضافه کند. اگر به‌روزرسانی مسیریابی را تمیزتر، استریم را ساده‌تر، یا یکپارچه‌سازی ارائه‌دهنده را کم‌سروصداتر کرد، این استفاده واقعی است چون سطحی که باید در پروداکشن دفاع کنم کوچک‌تر شده.
همان هفته فقط یک گردش کار را دست می‌زنم که اصطکاکش با این به‌روزرسانی پایین می‌آید. همان مسیر را اول درست می‌کنم و می‌بینم تجربه کاربر، خطای قابل دیدن، صدای پشتیبانی، یا پیچیدگی مهندسی واقعاً عوض شد یا فقط دمو شلوغ‌تر شد. بعد اپ اطراف را وادار می‌کنم کار سنگین را بردارد: رابط تایپ‌دار، مرز روشن بین کار مدل و منطق اپ، و تحمل کمتر برای پرامپتی که نامرئی پهن شده.
اهرم تازه پلتفرم را اول خرج قابلیت اطمینان و وضوح و تناسب محصول کن، بعد خرج جاه‌طلبی. تیمی که این ترتیب را عوض می‌کند معمولاً سریع‌تر شلوغ می‌شود نه سریع‌تر تحویل.
اشتباهی که هنوز تکرار می‌شود
SDK می‌تواند در انتقال، وضعیت، و الگو کمک کند. مرز محصول، استراتژی ارزیابی، و حالت شکست را تعریف نمی‌کند. این‌ها کار خودت است. اگر گردش کار مبهم باشد، نرده ضعیف باشد، یا کسی نتواند بگوید صدا زدن گران کجاست و چرا، انتشار فقط راه سریع‌تری برای ادامه آشفتگی می‌دهد.
اعتماد کاربر اغلب از تکه‌های کسل دور فیچر ساخته می‌شود: حالت خطا، زمان پاسخ، تلاش دوباره، لاگ، قابلیت حسابرسی، و دست دادن به کد عادی اپ. این‌ها به‌اندازه قابلیتی که در اعلامیه وسط بود مهم‌اند.
یک مسیر موجود را انتخاب کن، نه بازطراحی کل محصول. مرز کار را تنگ کن تا بهبود داخل مسیر قابل اندازه‌گیری بنشیند، نه داخل پرامپت غول یا لایه ارکستراسیون پهن. تأخیر، شکست، و هزینه را قابل دیدن کن. فرض‌هایی که با این به‌روزرسانی عوض شدند را بنویس. همان عادت معمولاً بیشتر از یک هفته آزمایش هیجانی به بحث معماری کمک می‌کند.
نسخه ۶ سالم به نظر می‌رسید چون مسیر پیش‌فرض ساختن محصول را کمی قابل دفاع‌تر کرد. اکوسیستم هنوز قابلیت بیشتر می‌خواهد. چیزی که تیم تحویل لازم دارد مسیر پیش‌فرض بهتر برای چیزی است که باید ماه بعد هم نگه داشته شود. اگر تنها چیزی که از ارتقا مانده فهرست قابلیت در اسلاید است، شماره نسخه عوض شده و کار روز دوم همان‌جا مانده.
پیش‌فرض‌های تازه را بودجه بدان
ToolLoopAgent راحت است و راحتی خطر است. حلقه تا بیست گام، اگر ابزارها اثر جانبی داشته باشند، می‌تواند در یک درخواست چند بار بنویسد. stopWhen را برای هر ایجنت عمداً پایین بیاور و در ارزیابی همان عدد را قفل کن. عوض کردن بی‌سروصدای سقف، هم هزینه را عوض می‌کند هم معنایی که از «تمام شد» دارید.
تأیید ابزار در نسخه ۶ داخل چرخه همان درخواست معنی دارد. برای کاری که باید ساعت‌ها منتظر انسان بماند، این هنوز حلقه داخل حافظه است. آن نیاز را با این نسخه قاطی نکن. اگر محصولت فقط چت و ابزار کوتاه است، تأیید و خروجی ساخت‌یافته و MCP همان برد عملی‌اند. دوام بین استقرار داستان نسخه بعد است و نباید بهانه شود که امروز سقف و اسکیما را ول کنی.
یکپارچه شدن ابزار با خروجی ساخت‌یافته یعنی دیگر لازم نیست دو فراخوانی را با چسب به هم بدوزی. یعنی هم باید اسکیمای آخر را اعتبار کنی و هم ورودی هر ابزار را. یکی بدون دیگری حفره است. strict را روی ابزاری بگذار که اسکیمایش را خودت فهمیده‌ای. روشن کردنش روی اسکیمای شل فقط شکست را زودتر نشان می‌دهد، که مفید است، به شرطی که مسیر خطا در محصول باشد نه فقط در لاگ.
DevTools را برای دیدن مرز گام استفاده کن، نه برای اینکه تیم محصول از روی رد مدل تصمیم بگیرد. اگر بعد از ارتقا هنوز نمی‌توانی بگویی کدام مسیر تعاملی ماند و کدام به صف رفت، شماره نسخه بالا رفته و شکل اپ نه. یک گردش را انتخاب کن، چسب قدیمی generateText به‌اضافه generateObject را اگر دیگر لازم نیست بردار، و فرض جدید را در چند خط کنار کد بنویس.