اگر هنوز فکر می‌کنید ساخت یک عامل هوش مصنوعی تنها به نوشتن یک پرامپت طولانی و دقیق بستگی دارد، احتمالاً در مقیاس واقعی با شکست مواجه خواهید شد. تفاوت میان یک دستورالعمل ساده و یک سیستم خودمختار، در همان تفاوتی است که میان «دادن یک لیست دستورات به کارمند» و «تعریف شرح شغلی، ابزار کار و حافظه تجربی برای او» وجود دارد. این رویکرد در واقع تکامل همان گذار از دستورالعمل‌های صلب به سامانه‌های هدف‌گرا است که پیش‌تر به آن پرداخته بودیم.
به نقل از راهنمای منتشر شده در dev.to در ۱۶ اکتبر ۲۰۲۶، تکیه بر واژه کلی «عامل‌محور» (Agentic) به عنوان یک اصطلاح تبلیغاتی، منجر به تصمیمات طراحی مبهم در توسعه AI شده است. همان‌طور که در تحلیل‌های پیشین ما درباره امنیت مدل‌های بازمتن اشاره کردیم، نبودِ واژگان دقیق، بزرگ‌ترین مانع در مسیر ساخت سیستم‌های قابل‌اعتماد است.
طبق این گزارش، برای خروج از بن‌بست پرامپت‌ها، توسعه‌دهندگان باید مدل زبانی بزرگ (LLM) — که شبیه کتابخانه‌داری است که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — را تنها به عنوان موتور محرک ببینند و هفت مؤلفه کلیدی را از هم تفکیک کنند:
- مدل (Model): موتور اصلی LLM.
- ابزار (Tool): توابع خارجی که مدل می‌تواند فراخوانی کند.
- مهارت (Skill): توانایی استفاده از ابزارها برای رسیدن به هدف.
- عامل (Agent): موجودیتی که تمام این عناصر را هماهنگ می‌کند.
- زمینه (Context): داده‌های در دسترس مدل در لحظه.
- حافظه (Memory): وضعیت ذخیره‌شده در طول جلسات مختلف.
- دسترسی (Access): مجوزهای اعطایی به عامل.
این چارچوب که هسته اصلی کتاب Claude Code Beyond the Prompt (منتشر شده توسط Packt Publishing) است، بر جداسازی «مهارت‌ها» از «ابزارها» تأکید دارد. این تفکیک باعث می‌شود عامل‌ها ماژولار شوند و عیب‌یابی آن‌ها در مقیاس بالا ساده‌تر شود.
برای یک توسعه‌دهنده، این تغییر به معنای گذار از مهندسی پرامپت (Prompt Engineering) — که هنر سؤال درست پرسیدن است، مثل کسی که می‌داند چطور از یک مشاور باتجربه بهترین جواب را بگیرد — به سمت «معماری سیستم» است. در این رویکرد، شما دیگر یک رشته متن را بهینه نمی‌کنید، بلکه چرخه حیات وضعیت، دسترسی و اجرای ابزارها را مدیریت می‌کنید.
به باور نویسندگان این راهنما، اولین قدم برای پیاده‌سازی این مدل، بازبینی گردش‌کارهای فعلی است. باید شناسایی کنید کدام بخش‌های پرامپت شما در واقع «مهارت» هستند و آن‌ها را به یک چارچوب ساختاریافته برای فراخوانی ابزارها منتقل کنید تا نرخ توهم (Hallucination) — یعنی وقتی مدل با اطمینان چیزی می‌گوید که وجود ندارد، شبیه دوستی که خاطره‌ای را اشتباه تعریف می‌کند — کاهش یابد.
گام بعدی شما
- پرامپت‌های فعلی خود را تحلیل کنید و بخش‌های «دستوری» را به «مهارت‌های» مجزا تبدیل کنید.
- برای هر عامل، یک ماتریس دسترسی (Access Matrix) تعریف کنید تا محدوده عملیاتی آن مشخص شود.
- حافظه کوتاه-مدت (Context) را از حافظه بلند-مدت (Persistent Memory) در معماری خود تفکیک کنید.
اما مدیریت این حافظه‌ها در مدل‌های مختلف، چالش‌های فنی پیچیده‌تری دارد — به بررسی ما درباره پروتکل MCP برای مدیریت زمینه مدل‌ها مراجعه کنید.
گفتگو