۴ الگوی معماری برای تبدیل مدل‌های زبانی به عامل‌های عملیاتی

تصور کنید یک برنامه‌نویس می‌خواهد سیستمی بسازد که نه‌تنها درباره وضعیت بازار حرف بزند، بلکه بتواند سفارشات را مستقیماً در پایگاه‌داده ثبت کند. بدون قابلیت دقیق فراخوانی تابع (Function Calling)، یک مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — تنها یک سیستم بسته است که نمی‌تواند با دنیای بیرون تعامل داشته باشد. در واقع، تنها با افزودن چند خط کد ساده می‌توان مرز میان یک مدل چت ساده و یک عامل هوشمند عملیاتی را تغییر داد.

بسیاری از توسعه‌دهندگان امروز با مشکل «توهم» در فراخوانی ابزارها دست‌وپنجه نرم می‌کنند؛ وضعیتی که مدل سعی می‌کند تابعی را اجرا کند که اصلاً وجود ندارد. به نقل از راهنمای منتشرشده در dev.to در ۵ اکتبر ۲۰۲۶، کلید پایداری در «توصیف ابزار» نهفته است؛ اگر توصیف تابع مبهم باشد، عامل نمی‌تواند گزینه درست را برای اجرا شناسایی کند. برای مقابله با این چالش، راهکارهایی مانند لایه‌های ترجمه قطعی در Vinkius معرفی شده‌اند تا توهمات ابزاری را به‌طور کامل حذف کنند.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، دسترسی مدل به ابزارهای خارجی، سطح جدیدی از ریسک را ایجاد می‌کند. به‌طور کلی، فراخوانی ابزار در چهار الگوی معماری اصلی رخ می‌دهد:

۱. حلقه‌های تابع دستی

توسعه‌دهندگان ابزارها را با استفاده از تابع bind_tools به مدل متصل می‌کنند و نام، توصیف و طرح JSON را ارائه می‌دهند. سیستم پاسخ مدل را برای وجود ویژگی tool_calls بررسی می‌کند؛ اگر این ویژگی باشد، کد ابزار را اجرا کرده و نتیجه را در یک حلقه به مدل بازمی‌گرداند تا پاسخ نهایی تولید شود.

۲. ابزارسازی سفارشی

ساخت ابزارهای داخلی معمولاً از سه مسیر دنبال می‌شود:

• دکوراتورها (Decorators): پوشش‌های ساده برای فراخوانی توابع.
• Pydantic: برای اعتبارسنجی سخت‌گیرانه ورودی‌ها تا آرگومان‌ها دقیقاً با نیازهای سیستم مطابقت داشته باشند.
• ابزارهای ساختاریافته: تبدیل کدهای قدیمی به فرمت ابزاری برای حفظ پارامترهای موجود.

۳. یکپارچه‌سازی با APIهای خارجی

عامل‌ها برای دریافت داده‌های لحظه‌ای از URLهای API استفاده می‌کنند. طبق گزارش منابع فنی، یک درخواست ساده برای وضعیت آب‌وهوای شهر چنای به یک زنجیره دو مرحله‌ای نیاز دارد: ابتدا فراخوانی API تبدیل مکان برای یافتن مختصات و سپس فراخوانی API هواشناسی با همان مختصات.

۴. ابزارهای پایگاه‌داده (DB)

عامل‌ها با استفاده از ابزارهایی مثل list_tables برای خواندن ساختار و run_sql_query برای دریافت نتایج، با داده‌های ساختاریافته تعامل می‌کنند. این قابلیت اجازه می‌دهد عامل به پرسش‌های پیچیده‌ای مثل «بیشترین مشتری از نظر هزینه در یک شهر خاص کیست؟» پاسخ دهد.

این چرخش به سمت عامل‌های ابزارمحور، نقش توسعه‌دهنده را از مهندسی پرامپت (Prompt Engineering) — هنر سؤال درست پرسیدن برای گرفتن بهترین جواب — به «مهندسی طرح» (Schema Engineering) تغییر می‌دهد. در اینجا ریسک دیگر فقط یک پاسخ اشتباه نیست، بلکه یک اقدام خطرناک است؛ مثلاً دادن اجازه اجرای دستور DELETE به یک عامل می‌تواند منجر به پاک شدن فاجعه‌بار داده‌ها شود.

گام بعدی شما

• برای ابزارهای پایگاه‌داده، حتماً دسترسی‌های «فقط خواندنی» (Read-only) را پیاده‌سازی کنید.
• برای تمام ورودی‌های خارجی از اعتبارسنجی سخت‌گیرانه Pydantic استفاده کنید تا از تزریق داده‌های مخرب جلوگیری شود.
• منتظر ظهور پروتکل‌های استاندارد «کشف ابزار» باشید که به عامل‌ها اجازه می‌دهد بدون اتصال دستی، ابزارهای مورد نیاز خود را پیدا کنند.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.