تصور کنید ساعتها وقت خود را صرف تغییر کلمات یک پرامپت میکنید و امیدوارید جواب بهتری بگیرید، اما هیچکس نمیداند چرا نتیجه بهتر شد یا آیا واقعاً بهتر شده است یا خیر. اگر شما یک توسعهدهنده هستید که با عاملهای هوش مصنوعی سروکار دارید، احتمالاً میدانید که تنظیم این سیستمها فعلاً بیشتر شبیه به حدس زدن است تا مهندسی.
به نقل از راهنمای منتشرشده در ۳۰ جولای ۲۰۲۶ در وبسایت dev.to، روشی برای پایان دادن به این مدل توسعه «حسی» (Vibe-based) پیشنهاد شده است. راهکار اصلی این است که تعریف عامل را بهجای کد، به عنوان «داده» مدیریت کنیم.
در پوشش پیشین ما از امنیت مدلهای بازمتن، دیدیم که چگونه نبودِ ساختارهای سختگیرانه منجر به نتایج غیرقابلپیشبینی میشود؛ در اینجا نیز مشکل مشابه است. این رویکرد بر اساس تفکیک معماری بین «کلاسهای عامل» و «وقوعات اجرایی» بنا شده است و عامل را به عنوان مجموعهای از تصمیمات میبیند. اکثر توسعهدهندگان انتخابهایی مثل مدل مورد استفاده یا پرامپتهای سیستمی را بهصورت غیررسمی انجام میدهند و هرگز به آنها بازنمیگردند. این تصمیمات شامل این است که از کدام مدل استفاده شود، پرامپت سیستمی چه باشد، عامل به کدام ابزارها دسترسی داشته باشد و چند مرحله فرصت داشته باشد تا پاسخ را پیدا کند پیش از آنکه سیستم تسلیم شود. در نتیجه، یک نقطه کور ایجاد میشود که در آن تغییرات در کد رخ میدهند، فراموش میشوند و فهم این موضوع که چرا یک تغییر خاص باعث بهبود نتیجه شده، غیرممکن میشود.
تفکیک مفهومی
برای حل این مشکل، این چارچوب فرآیند را به دو دسته مجزا تقسیم میکند: پارامترهای قابلتنظیم و پارامترهای خروجی. دسته اول «تعریف عامل» (Agent Definition) — شبیه به دستور پخت یک غذا یا همان کلاس — و دسته دوم «نمونه عامل» (Agent Instance) — یعنی همان غذایی که در هر بار پخت تولید میشود یا یک وقوع اجرایی — است. این تفکیک حیاتی است زیرا مردم معمولاً این دو نوع پارامتر را که در زمان تنظیم با هم اشتباه میگیرند، در دو طرف مخالف این مرز میبینند: شما «تعریف» را تنظیم میکنید، اما «نمونهها» را اندازه میگیرید.
بر اساس مستندات dev.to، این موارد باید در یک فایل پیکربندی مانند agents.json مدیریت شوند، نه اینکه در متن کد جای بگیرند. این کار تضمین میکند که هدف عامل، پنجره متنی (Context Window) — مثل میز کاری که جا برای چند ورق دارد، نه برای کل کتابخانه — اعتبارنامهها و بودجه مصرفشده به عنوان بخشی از یک نمونه خاص ردیابی شوند.
پارامترهای قابلتنظیم (اهرمها)
اینها فیلدهایی در تعریف عامل هستند که با تغییر آنها، رفتار مدل عوض میشود. تغییر هر یک از اینها، حتی اگر بقیه ثابت بمانند، یک عامل جدید میسازد:
- بستر سیستمی: نحوه دستور دادن به عامل و توصیفات مربوط به نقش آن.
- انتخاب مدل زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب میدهد — و قیمت استنتاج آن.
- مجموعه سرور MCP و مرز قابلیتها: منابع ابزاری موجود و ابزارهای خاصی که این عامل مجاز است برای رسیدن به هدف از آنها استفاده کند.
- حلقه میزبان: استراتژی اجرای ابزار (متوالی در مقابل موازی) و رفتار مربوط به تلاش مجدد (Retry).
- محدودیتهای توقف: تعداد تکرارها و توکنها (Tokens) — تکههای کوچکی از متن شبیه برشهای کیک — پیش از آنکه اتصال عامل قطع شود.
- استراتژی اندازه زمینه: نحوه مدیریت تاریخچه رو به رشد گفتگو در حالی که یک تکلیف طولانیتر میشود.
نکته مهم این است که «قرارداد تکلیف» (Task Contract) تنها فیلدی است که اهرم تنظیم نیست. شما قرارداد را تغییر نمیدهید؛ در عوض، تمام پارامترهای دیگر را در تقابل با آن قرارداد تنظیم میکنید.
پارامترهای خروجی (معیارها)
اینها اندازهگیریهایی هستند که از نمونههای اجرایی گرفته میشوند تا مشخص شود آیا تغییرات اثر داشته است یا خیر. یک عامل بهصورت انتزاعی «خوب» نیست؛ کیفیت آن بر اساس معیارهای مشخص سنجیده میشود:
- صحت: تبدیل قرارداد تکلیف به یک آزمون قابلاندازهگیری. صحت لزوماً صفر و یک (باینری) نیست؛ ممکن است به معنای «شامل بودن واقعیت درست» باشد یا نیاز به یک دستورالعمل (Rubric) و یک مدل دوم برای قضاوت داشته باشد.
- تأخیر (Latency): کل زمان سپریشده بر روی ساعت (Wall-clock time)، شامل تمام فراخوانیهای ابزار، نه فقط زمان «تفکر» مدل.
- نرخ مصرف: مجموع توکنهای ورودی و خروجی در هر رفتوبرگشت که نشاندهنده بودجه مصرفی آن نمونه خاص است.
- بهرهوری ابزار: بررسی اینکه کدام ابزارها و با چه تکراری استفاده شدهاند. این موضوع حیاتی است زیرا برخی ابزارها به دلیل محدودیتهای API، سرویسهای خارجی کند یا هزینه دلاری واقعی برای هر فراخوانی، گران هستند. عاملی که با پنج فراخوانی ارزان به جواب برسد، برتر از عاملی است که از یک ابزار بسیار گران استفاده کند.
این تغییر دیدگاه، تنظیم عامل را از یک «هنر» به یک «علم» تبدیل میکند. با تبدیل تعریف عامل به پیکربندی، مقایسه دو نسخه به یک عملیات سادهٔ 'diff' تبدیل میشود. شما میتوانید یک مجموعه سؤال آزمایشی یکسان را به دو تعریف بدهید که دقیقاً در یک فیلد با هم تفاوت دارند، دستهای از نمونهها را برای هرکدام اجرا کنید و هرگونه تفاوت در نتایج اندازهگیری شده را مستقیماً به همان یک فیلد تغییر یافته نسبت دهید. این رویکرد در واقع پیشنیازی برای درک مفاهیمی نظیر همگرایی عاملها است که به عنوان یک معیار جدید برای افزایش بهرهوری در محیطهای عملیاتی معرفی شده است.
برای متخصصان، ترتیب عملیات حیاتی است: شما باید پیش از شروع تغییر در اهرمهای قابلتنظیم، پارامترهای خروجی را تعریف کنید. ابتدا باید تصمیم بگیرید که یک پاسخ صحیح چگونه است، چه میزان تأخیر قابل پذیرش است و چه بودجه توکنی را حاضرید هزینه کنید. بدون یک دستورالعمل (Rubric) پیشتعریفشده، «تنظیم» همچنان یک بازی حسی باقی میماند که در آن یک پرامپت در سه مثال بهتر به نظر میرسد، اما توسعهدهنده هیچ ایدهای ندارد که آیا واقعاً بهتر شده یا فقط متفاوت است.
این رویکرد سیستماتیک بهویژه برای مقیاسدهی به عاملهای پروتکل زمینه مدل (MCP) ضروری است، جایی که هزینه ابزار و تأخیر در صورت عدم نظارت دقیق، میتواند بهسرعت خارج از کنترل شود. با جداسازی «کلاس» از «نمونه»، هر تغییر به یک فرضیه قابلآزمایش تبدیل میشود: آیا تغییر خاص در یک فیلدِ تعریف، اعداد مورد نظر را در جهت درست حرکت میدهد بدون اینکه روی معیارهایی که دست نخوردهاند تأثیر بگذارد؟
گام بعدی شما
برای پیادهسازی این روش، این مسیر را دنبال کنید:
- ابتدا پرامپتهای سیستمی و شناسههای مدل خود را از کد خارج کرده و به یک فایل پیکربندی JSON منتقل کنید.
- سپس یک مجموعه آزمایشی شامل ۱۰ تا ۲۰ سؤال ایستا (Static) طراحی کنید.
- برای هر تغییر کوچک در پرامپت، پارامترهای خروجی (صحت، تأخیر و هزینه) را برای تکتک تغییرات اندازهگیری و ثبت کنید.
اما تأثیر این تفکیک بر مدیریت حافظه در سیستمهای چندعاملی حتی پیچیدهتر است — در تحلیل ما درباره معماریهای حافظه بلندمدت بخوانید.
گفتگو