اگر در حال توسعه برنامههایی هستید که از مدلهای زبانی استفاده میکنند، احتمالاً با کابوس هزینههای پیشبینینشده و پاسخهای تکراری مدلها روبهرو شدهاید. توسعهدهندهای به نام ادوارد لازارو (Eduardo Lazaro) با معرفی Laragents، ابزاری را برای اکوسیستم لاراول عرضه کرد که لولهکشیهای پیچیده و اغلب نادیده گرفتهشده در ساخت عاملهای هوش مصنوعی را مدیریت میکند. لازارو این تصمیم را پس از آن گرفت که متوجه شد یک منطق مشابه را دو بار در دو برنامه مختلف نوشته است و تصمیم گرفت آن را به یک ابزار قابل استفاده مجدد تبدیل کند. او معتقد است ساخت یک دستیار هوش مصنوعی آماده برای محیط تولید (Production)، بسیار فراتر از ارسال یک درخواست JSON ساده به یک مدل زبانی (LLM) است. بنابراین، Laragents سیستمی را فراهم میکند تا عاملها بدانند چه زمانی باید صحبت کردن را متوقف کنند و چگونه اطلاعات را به خاطر بسپارند.
بسیاری از برنامهنویسان ابتدا فقط یک رابط کاربری را به مدل متصل میکنند. اما با مقیاسپذیری برنامه، به دیواری برخورد میکنند که در آن گفتگوها از پنجره زمینه (Context Window) — مثل میز کاری که جا برای چند ورق دارد، نه برای کل کتابخانه — فراتر میرود، هزینهها در حلقههای فراخوانی ابزار به شدت بالا میرود و کاربران مجبور میشوند ترجیحات خود را در هر جلسه گفتگو دوباره تکرار کنند. Laragents به عنوان یک راهکار ساختاری برای حل این شکستهای خاص در اکوسیستم PHP معرفی شده است. نصب آن از طریق composer و دستور composer require edulazaro/laragents انجام میشود و پس از آن، توسعهدهنده باید تنظیمات (config) و مایگریشنها را منتشر کند.
توقف مارپیچ فراخوانی ابزارها
طبق مستندات این بسته، مدلی که قادر به استفاده از ابزار است، در یک مرحله پاسخ نمیدهد؛ بلکه ابتدا ابزاری را درخواست میکند، سیستم آن را اجرا کرده و نتیجه را بازمیگرداند، و مدل ممکن است پیش از نوشتن متن نهایی، ابزار دیگری را درخواست کند. این چرخه هسته تجربه عاملمحور (Agentic) است، اما دقیقاً همان جایی است که هزینهها میتوانند از کنترل خارج شوند. این نیاز به ابزارهای زیرساختی دقیق، با روندی همسو است که در آن تقاضا برای ابزارهای کاربردی در بازار عاملها بیش از استدلالهای پیچیده هوش مصنوعی اهمیت یافته است.
یکی از گرانترین شکستها در هوش مصنوعی عاملمحور، «حلقه بینهایت» است؛ جایی که مدل مدام یک جستوجوی شکستخورده را با فرمولبندیهای مختلف تکرار میکند. Laragents برای توقف این وضعیت دو حفاظ (Guardrails) خاص را پیاده کرده است:
- سقف تکرار (Iteration Cap): یک محدودیت سختگیرانه برای تعداد دفعاتی که مدل میتواند در یک نوبت پاسخ دهد. بدون این محدودیت، مدل ممکن است تا زمان وقوع Timeout سیستم به چرخه ادامه دهد و هر نوبت از این چرخه برای توسعهدهنده هزینه داشته باشد.
- حفاظ توالی خالی (Empty-Streak Guard): اگر مدل دو بار متوالی نتیجه «خالی» از یک ابزار دریافت کند، سیستم یک راهنمایی (Hint) به مدل اضافه میکند و به او میگوید که به جای جستوجوی مجدد، پذیرفتن عدم یافتن پاسخ را اعلام کند.
برای تشخیص «خالی» بودن، این بسته ساختار دادههای بازگشتی را تحلیل میکند، زیرا یک بسته نرمافزاری نمیتواند بداند هر ابزار سفارشی چه چیزی برمیگرداند. اگر نتیجهای دارای کلیدهایی مثل 'items' یا 'results' یا 'matches' (یا هر چیزی که توسعهدهنده پیکربندی کرده باشد) باشد، به عنوان یک جستوجو قضاوت میشود. اما اگر ابزاری عملیاتی مثل ثبت یک سند را انجام دهد، چون چیزی را «پیدا» یا «پیدا نکرد» نکرده است، این توالی (Streak) را ریست نمیکند. این طراحی باعث میشود یک فراخوانی اداری ساده بین دو جستوجوی بینتیجه، باعث پنهان شدن یک حلقه تکراری نشود.
ابزارسازی متمرکز بر دامنه
برخلاف رابطهای عمومی، Laragents به جای ارائه ابزارهای پیشساخته، یک کلاس پایه Tool ارائه میدهد، زیرا ابزارها باید درباره دامنه خاص کسبوکار توسعهدهنده صحبت کنند. یک انتخاب معماری کلیدی در اینجا، جداسازی $args و $context در متد execute است:
- $args: اینها مواردی هستند که مدل درخواست کرده است. این دادهها متنی هستند که توسط مدل زبانی تولید شدهاند و احتمالاً توسط هر چیزی که کاربر در چت جایگذاری (Paste) کرده، هدایت شدهاند. بنابراین، این ورودیها ذاتاً غیرقابل اعتماد هستند.
- $context: اینها دادههایی هستند که خودِ برنامه فراهم میکند و برای مدیریت هویت و محدوده دسترسی (مثلاً کاربر فعلی یا سازمان مربوطه) استفاده میشود.
این جداسازی از حملات تزریق پرامپت (Prompt Injection) — شبیه به دادن دستورات مخفی به یک کارمند برای دور زدن قوانین شرکت — جلوگیری میکند. توسعهدهندگان تشویق میشوند که هویت و محدوده دسترسی را فقط از Context بگیرند و هرگز از آرگومانهای تولید شده توسط مدل استفاده نکنند. این طراحی مشکل «کیسه» را حل میکند؛ یعنی برای اضافه کردن یک زمینه جدید، نیازی به ویرایش تکتک ابزارها نیست (که در برنامه اولیه نویسنده، به معنای ویرایش ۹۵ ابزار مختلف بود).
علاوه بر این، این بسته بر اهمیت «توضیحات ابزار» تأکید دارد. برای مثال، در ابزار ListProperties (لیست املاک)، اضافه کردن جملهای مانند «این ابزار بازدیدها را رزرو نمیکند: برای آن از schedule_viewing استفاده کنید» حیاتی است، زیرا مدلها وقتی مرزها مشخص نباشند، اغلب ابزارهای مشابه و همسایه را به اشتباه انتخاب میکنند.
فشردهسازی هوشمند تاریخچه
در هر نوبت گفتگو، کل تاریخچه دوباره ارسال میشود. یک چت موفق، در هر نوبت گرانتر میشود تا زمانی که به محدودیت توکنها برسد و از کار بیفتد. Laragents این موضوع را از طریق یک فشردهساز (Compressor) که بودجه توکن را نظارت میکند، مدیریت میکند:
- فاز عیناً (Verbatim): تا زمانی که بودجه توکن اجازه دهد، همه چیز دقیقاً و بدون تغییر ارسال میشود.
- فاز خلاصهسازی: پس از عبور از بودجه، نوبتهای قدیمی یک بار توسط یک مدل ارزانقیمت خلاصهسازی شده و از آن پس همان خلاصه در تاریخچه استفاده میشود.
برای حفظ انسجام، سیستم دو مورد را هرگز فشرده نمیکند. اول، نوبتهای اخیر هرگز فشرده نمیشوند، زیرا رشته اصلی تبادل اطلاعات در آنجاست و خلاصهسازی «آنچه همین الان گفتیم» باعث مبهم شدن سیستم میشود. دوم، فراخوانی ابزارها و نتایج آنها هرگز لمس نمیشوند. این موارد متعلق به نوبتی هستند که آنها را تولید کرده است و بازپخش آنها در نوبتهای بعدی باعث میشود حلقه دوباره لولهکشیهای خود را بخواند و دچار تکرار شود.
حافظه بلندمدت و قوانین
Laragents بین «خاطرات» و «قوانین» در سه محور تفاوت قائل میشود: مستاجر (شرکت، فضای کاری یا حساب)، محدوده (یک پرونده یا پروژه) و موضوع (اینکه خاطره برای چه کسی اعمال شود).
- خاطرات (Memories): اینها واقعیتهای استخراجشده هستند (مثلاً «ماریا ترجیح میدهد پاسخها به صورت گلولهای/Bullet points باشند»). این خاطرات به صورت کارهای صفبندیشده (Queued Jobs) نوشته میشوند زیرا نیاز به یک فراخوانی مدل دیگر دارند؛ اگر هزینه این یادآوری به پاسخ کاربر اضافه شود، چت کند به نظر میرسد. این جابها در زمان فشردهسازی تاریخچه یا از طریق یک بررسی زمانبندی شده برای گفتگوهای کوتاهی که پیش از فشردهسازی به پایان رسیدهاند، اجرا میشوند.
- قوانین (Rules): اینها دستورات دستنویس انسانی هستند (مثلاً «شرکت ما همیشه X را انجام میدهد»). برخلاف خاطرات، قوانین عیناً در ابتدای پرامپت به عنوان دستورالعمل ارسال میشوند.
این تفکیک یک سوال رایج در طراحی محصول را حل میکند: منطق کلان شرکت کجا باید قرار بگیرد؟ این منطق نمیتواند در پرامپت سیستمی باشد (که یک رشته متنی واحد برای همه است)، یا در حافظه (که وزندهی میشود و ممکن است ظاهر نشود)، یا در یک ابزار (که یک اقدام است). قوانین بالای پرامپت و خاطرات پایین آن قرار میگیرند تا اطمینان حاصل شود که یک دستور مستقیم، زیر کوهی از زمینههای به خاطر سپرده شده دفن نمیشود.
عاملهای رویدادمحور
علاوه بر رابطهای چت، این بسته اجازه ساخت عاملهای «بدون سر» (Headless) را میدهد که با رویدادهای سیستم یا عبارتهای cron فعال میشوند. برای مثال، میتوان عاملی برای «تریاژ اسناد» ساخت که با پرامپت سیستمی برای طبقهبندی اسناد و علامتگذاری اطلاعات ناقص، توسط رویداد document.uploaded تحریک شود. این رویکرد خودکارسازی، مشابه تحولاتی است که در پلتفرمهای بزرگ دیده میشود؛ برای نمونه، احتمال تبدیل بازار نرمافزاری آمازون به یک سامانه خرید خودکار نشاندهنده گسترش همین مدلهای عاملمحور در مقیاس صنعتی است.
برای جلوگیری از فجایع مالی در این حالت، دو حفاظ پیشبینی شده است:
- Debounce: این قابلیت جلوگیری میکند که چندین ناظر (Observer)، یک عامل واحد را سه بار برای یک تغییر منطقی که در سه دستور مختلف نوشته شده، اجرا کنند.
- سقف روزانه (Daily Ceiling): حداکثر تعداد وظایف در روز (مثلاً ۲۰۰ مورد) برای جلوگیری از ورود عامل به حلقهای که در آن خروجیهای ابزارهای خودش، رویدادهای جدیدی را تحریک میکنند.
جایگاه در برابر Laravel AI
به نقل از مستندات edulazaro.com، Laragents قرار نیست یک Wrapper برای ارائهدهندگان باشد. در حالی که laravel/ai پاسخ فریمورک برای ارائه پانزده ارائهدهنده پشت یک رابط واحد است، اما فاقد منطق حافظه، قوانین، زمانبندیها و فشردهسازی است که در Laragents یافت میشود.
علاوه بر این، Laragents یک بسته اندازهگیری (Metering) نیست. اگرچه یک قرارداد UsageRecorder و یک آداپتور برای larameter ارائه میدهد، اما به صورت پیشفرض چیزی را ثبت نمیکند. نویسنده استدلال میکند که اندازهگیری نباید داخل یک بسته هوش مصنوعی باشد، زیرا کسی نباید برای اندازهگیری ارسال یک فرم، به یک کلاینت LLM نیاز داشته باشد.
در نهایت، این بسته شامل قابلیت ناشناسسازی دادههای حساس (PII) است. این سیستم دادههای حساس را در مسیر ارسال به LLM توکنسازی کرده و در مسیر بازگشت، آنها را بازیابی میکند (شامل آرگومانهای ابزار). این امر تضمین میکند که ابزارها همچنان بتوانند با مقادیر واقعی در دیتابیس جستوجو کنند، به جای اینکه به دنبال جایگذارهایی مثل «AP_1» بگردند و چیزی پیدا نکنند.
این تغییر در معماری به این معناست که توسعهدهندگان دیگر مجبور نیستند منطق «حلقه» و «حافظه» را برای هر ویژگی جدید هوش مصنوعی از صفر بسازند. تمرکز از «چگونه مدل را فراخوانی کنیم» به «چگونه عامل را مدیریت کنیم» تغییر مییابد.
گام بعدی شما
- اگر از لاراول استفاده میکنید، بسته Laragents را برای مدیریت حافظه و کاهش هزینههای API تست کنید.
- ساختار ابزارهای خود را بازبینی کنید و ورودیهای مدل را از زمینه (Context) برنامه جدا کنید تا امنیت سیستم بالا برود.
- برای کاهش هزینه استنتاج، استراتژی فشردهسازی تاریخچه را در برنامههای خود پیادهسازی کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما درباره تراشههای Blackwell مراجعه کنید.
گفتگو