تصور کنید یک عامل فروشگاه آنلاین دارید که فراتر از پاسخ به سوالات ساده، واقعاً تراکنش‌های تجاری را اجرا می‌کند. در ۲۷ سپتامبر ۲۰۲۶، یک راهنمای فنی افشا کرد که چگونه می‌توان با استفاده از NanoAgent و پیاده‌سازی ابزارهای حالت‌دار (Stateful Tools) در زبان PHP، عاملی ساخت که ابتدا موجودی کالا را بررسی کرده و سپس با ثبت سفارش، وضعیت پایگاه‌داده را تغییر دهد.
بیشتر پیاده‌سازی‌های اولیه در زمینه استفاده از ابزار توسط هوش مصنوعی، «فقط خواندنی» هستند؛ مثل گرفتن وضعیت آب‌وهوا یا جست‌وجو در یک سند. اما اتوماسیون واقعی در دنیای کسب‌وکار نیازمند آن است که عامل‌ها بتوانند رکوردها را تغییر دهند، عملیاتی را فعال کنند یا پایگاه‌داده را به‌روزرسانی کنند. این چرخش راهبردی، عامل را از یک رابط جست‌وجوی پیشرفته به یک لایه تصمیم‌گیر تبدیل می‌کند که در واقع «مغز» سیستم است و توابع PHP نقش «دست‌های» اجرایی آن را ایفا می‌کنند.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی معماری‌های عامل‌محور اشاره کردیم، جداسازی لایه تصمیم از لایه اجرا، کلید پایداری سیستم‌های خودکار است. برای نمایش این سازوکار، این راهنما از یک کلاس PHP به نام ProductDatabase استفاده می‌کند. این کلاس با استفاده از یک آرایه در حافظه، نقش یک پایگاه‌داده واقعی را ایفا می‌کند تا مثال بدون نیاز به نصب پیچیده، دقیقاً مشابه یک فروشگاه واقعی عمل کند. موجودی شبیه‌سازی شده شامل موارد زیر است:
- لپ‌تاپ کوانتوم (p1): قیمت ۱۵۰۰، موجودی ۵
- نانو فون (p2): قیمت ۸۰۰، موجودی ۰
- هدست هوش مصنوعی (p3): قیمت ۳۰۰، موجودی ۱۲
به نقل از آموزش منتشر شده در dev.to، این سیستم برای مدیریت منطق جست‌وجو و تغییر وضعیت به این کلاس متکی است. متد order() بخش تغییردهنده (Mutating) است؛ این متد ابتدا بررسی می‌کند که محصول وجود داشته باشد و موجودی کافی باشد و سپس تعداد را کم کرده و نتیجه را برمی‌گرداند.
برای اتصال مدل زبانی بزرگ (LLM) — که شبیه کتابخانه‌داری است که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — به کلاس PHP، از دو پوشش FunctionTool مجزا استفاده شده است:
- search_products: ابزاری فقط خواندنی که متد
searchرا فراخوانی می‌کند و برای جست‌وجوی نام محصول در موجودی، به یک رشته متنی (query) نیاز دارد. - place_order: ابزاری تغییردهنده که به متد
orderمتصل است و برای اجرا به شناسه محصول (product_id) و تعداد (quantity) نیاز دارد. در اینجا تغییر واقعی در کلاسProductDatabaseرخ می‌دهد، نه در خودِ ابزار.
برای جلوگیری از توهم (Hallucination) — یعنی وقتی مدل با اطمینان چیزی می‌گوید که اصلاً وجود ندارد، مثل دوستی که خاطره‌ای را اشتباه تعریف می‌کند — در مورد سطح موجودی، سیستم از یک پرامپت سیستمی (System Prompt) سخت‌گیرانه استفاده می‌کند: «موجودی کالا را حدس نزن». این دستور عامل را مجبور می‌کند تا ابتدا ابزار جست‌وجو را فراخوانی کند تا تصمیمش بر اساس داده‌های لحظه‌ای مبنی‌سازی (Grounding) شود. برای مثال، اگر کاربر بخواهد ۲ لپ‌تاپ کوانتوم بخرد، عامل باید ابتدا وضعیت را استعلام کند، تصمیم بگیرد و سپس در یک نوبت، تغییر را اعمال کند.
بر اساس مستندات این راهنما، چهار الگوی حیاتی برای ایمن‌سازی ابزارهای حالت‌دار تعریف شده است:
- ابتدا بخوان، سپس بنویس: عامل ابتدا موجودی را چک می‌کند تا تغییرات بر اساس واقعیت باشد، نه فرض.
- نتایج خوانا برای انسان: ابزارها به‌جای آرایه‌های خام، رشته‌هایی مثل «موفقیت: ۲ عدد سفارش داده شد... موجودی جدید: ۳» برمی‌گردانند تا مدل بتواند درباره نتیجه استدلال کند.
- خطا به عنوان نتیجه، نه استثنا: به‌جای خطای ۵۰۰، سیستم پیام «خطا: موجودی ناکافی» را برمی‌گرداند تا مدل آن را به زبانی کاربرپسند ترجمه کند.
- سخت‌گیرانه کردن طرح‌واره (Schema): تنظیم
additionalProperties => falseدر JSON Schema مانع از ارسال فیلدهای اضافی و نامرتبط توسط مدل به توابع PHP می‌شود.
برای توسعه‌دهندگان، این بدان معناست که هسته اتوماسیون عامل‌محور در کسب‌وکارها، خودِ مدل زبانی نیست، بلکه پوشش‌های ایمنی (Safety Wrappers) اطراف پایگاه‌داده است. با جایگزینی آرایه شبیه‌سازی شده با یک لایه ذخیره‌سازی واقعی، این الگو امکان مدیریت تیکت‌ها، رزروها و موجودی‌های پیچیده را فراهم می‌کند. یک دستور ساده var_dump پس از تراکنش ثابت می‌کند که موجودی واقعاً کاهش یافته است (مثلاً از ۵ به ۳)، که تایید می‌کند عامل واقعاً کد را اجرا کرده است.
در این معماری، ثبت وقایع (Logging) غیرقابل مذاکره است. متد enableActivityLogging() به توسعه‌دهندگان اجازه می‌دهد دقیقاً بررسی کنند کدام ابزارها و با چه ترتیبی اجرا شده‌اند؛ این یک ردپای ضروری برای هر عاملی است که اجازه نوشتن در پایگاه‌داده عملیاتی را دارد.
توسعه‌دهندگانی که به دنبال مقیاس‌پذیری هستند، اکنون می‌توانند منطق تجاری موجود در PHP خود را به عنوان مجموعه‌ای از ابزارها برای لایه تصمیم‌گیر LLM در نظر بگیرند.
گام بعدی شما
- منطق‌های تجاری فعلی PHP خود را به توابع کوچک و مستقل تبدیل کنید تا برای فراخوانی توسط عامل آماده شوند.
- برای جلوگیری از خطاهای بحرانی، لایه اعتبارسنجی ورودی‌ها را در JSON Schema به شدت محدود کنید.
- سیستم ثبت وقایع (Logging) را برای تمام ابزارهای تغییردهنده فعال کنید تا هر تراکنش قابل بازبینی باشد.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو