عامل‌های فرعی؛ ابزارهای گران‌قیمتی که پنجرهٔ زمینه را آلوده می‌کنند

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

به نقل از گابریل (xgabriel.com)، توسعه‌دهنده Hermes IDE برای کسانی که از Claude Code استفاده می‌کنند، بسیاری از عامل‌های فرعی (Sub-agents) در واقع همان فراخوانی ابزارها هستند که لباس مبدل پوشیده‌اند. او در راهنمای فنی خود توضیح می‌دهد که توسعه‌دهندگان اغلب نیاز به یک تابع ساده را با نیاز به یک حلقه کامل مدل اشتباه می‌گیرند.

در فضای فعلی توسعه عامل‌محور (Agentic)، غریزه برنامه‌نویسان این است که برای هر نقش — مثل پژوهشگر، نویسنده یا بازبین — یک عامل متخصص با پرامپت و ابزارهای خاص بسازند. این رویکرد اغلب به «آلودگی زمینه» (Context Pollution) منجر می‌شود؛ وضعیتی که در آن پنجرهٔ زمینه (Context Window) مدل والد — شبیه به میز کاری که فقط جای چند ورق کاغذ دارد و نه کل کتابخانه — با مراحل میانی بی‌ربط پر می‌شود. این ناکارآمدی باعث می‌شود در هر نوبت بعدی گفتگو، هزینه توکن‌های بیشتری برای هر پیام پرداخت کنید.

همان‌طور که در تحلیل‌های قبلی ما درباره امنیت مدل‌های بازمتن اشاره کردیم، مدیریت منابع در مقیاس واقعی، مرز بین یک محصول تجاری و یک پروژه آزمایشی است. در کنار مدیریت منابع، تأمین امنیت این ساختارها نیز حیاتی است؛ به‌ویژه در محیط‌های TypeScript که پیاده‌سازی لایه‌های دفاعی برای مهار تزریق پرامپت برای جلوگیری از دستکاری عامل‌ها ضروری است.

ارزش اصلی: جداسازی زمینه

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

• متون میانی حجیم که در حین تولید پاسخ ایجاد می‌شوند، مدل والد را آلوده نمی‌کنند.
• مدل والد به‌جای دریافت تمام متن‌های خام و رونوشت‌های کامل، تنها یک خلاصه موجز دریافت می‌کند.
• عامل فرعی با یک پرامپت سیستمی (System Prompt) متمرکز و لیست ابزارهای محدودتر عمل می‌کند.

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

تصور کنید یک عامل پژوهشگر ۱۲ سند را می‌خواند تا یک پاسخ پیدا کند. اگر این کار با یک فراخوانی ابزار استاندارد انجام شود، تمام ۱۲ سند وارد پنجرهٔ زمینه مدل والد می‌شوند. در این حالت، توسعه‌دهنده برای هزاران توکن در هر بار ارسال پیام توسط کاربر هزینه می‌پردازد.

چه زمانی عامل فرعی بسازیم؟

گابریل سه سناریوی مشخص را معرفی می‌کند که در آن‌ها ایجاد یک عامل فرعی یک ضرورت فنی است:

• جست‌وجو و تقطیر (Search-and-Distil): وقتی فرآیند شامل خواندن حجم عظیمی از داده‌ها (مثلاً ۱۲ سند) برای برگرداندن یک خلاصه بسیار کوچک (مثلاً یک پاراگراف) است. جداسازی تضمین می‌کند که مدل والد فقط نتیجه را ببیند، نه تمام رونوشت‌های میانی.
• کارهای موازی مستقل: وقتی چندین تحقیق به‌طور هم‌زمان اجرا می‌شوند. زمینه‌های مجزا از تداخل تاریخچه‌ها و گیج شدن مدل جلوگیری می‌کنند و اجازه می‌دهند تحقیقات بدون به اشتراک گذاشتن وضعیت‌های میانی پیش بروند.
• تغییر جایگاه واقعی (Genuine Posture Shifts): وقتی یک عامل «منتقد» باید نسبت به استدلال‌های نویسنده کور باشد، یا یک بازبین به‌طور عمدی فقط ادعا و منبع را دریافت کند. در اینجا، جداسازی همان ویژگی است که باعث می‌شود نظر دوم واقعاً مستقل باشد.

چه زمانی از ابزار استفاده کنیم؟

در مقابل، این راهنما در چهار مورد خاص نسبت به استفاده از عامل‌های فرعی هشدار می‌دهد:

• کارهای قطعی: وظایفی مثل تجزیه متن (Parsing)، فرمت‌بندی، اعتبارسنجی یا فراخوانی API با پارامترهای مشخص. استفاده از مدل در اینجا فقط باعث افزایش تأخیر، هزینه و تغییرات پیش‌بینی‌نشده (Variance) می‌شود.
• نام‌های مستعار گران‌قیمت: یک فراخوانی ابزار ساده که فقط با یک پرامپت پوشانده شده است. اگر وظیفه صرفاً این است که «تابع get_order را صدا بزن و وضعیت را بگو»، یک عامل فرعی هزینه‌ای غیرضروری است.
• کارهای وابسته به زمینه: اگر متوجه شدید که بیشتر تاریخچه گفتگوی والد را به عامل فرعی پاس می‌دهید، جداسازی رخ نداده است و شما برای توکن‌های یکسان دوبار هزینه می‌پردازید.
• مسیرهای حساس به تأخیر: هر عامل فرعی یک حلقه کامل است که شامل چندین فراخوانی متوالی مدل می‌شود. برای ویژگی‌های تعاملی، این چند ثانیه تأخیر را نمی‌توان پنهان کرد.

پیاده‌سازی فنی و کنترل بودجه

برای جلوگیری از تبدیل شدن عامل‌ها به راه فراری برای طراحی ضعیف، گابریل استفاده از Zod برای ایجاد مرزهای تایپ‌شده را پیشنهاد می‌کند. یک عامل فرعی باید برای مدل والد شبیه یک ابزار باشد اما ساختار خروجی سخت‌گیرانه‌ای (Strict Output Schema) داشته باشد.

با استفاده از SubAgentSpec می‌توان قراردادها را تعریف کرد. مثلاً یک عامل research_topic را می‌توان طوری محدود کرد که حداکثر ۶ یافته (.max(6)) و حداکثر ۳۰۰ کاراکتر برای طول هر ادعا (.max(300)) برگرداند. این‌ها تزئین نیستند، بلکه اجرای این قانون هستند که مدل والد باید خلاصه دریافت کند، نه متونی با طول دلخواه.

مدیریت بودجه نیز یک نقطه شکست بحرانی است. بودجه عامل فرعی باید فرزند بودجه مدل والد باشد. اگر مدل والد بودجه کلی دارد و یک عامل فرعی ۲۰ سنت هزینه می‌کند، مدل والد باید ۲۰ سنت فقیرتر شود. این مورد با اطمینان از اینکه هزینه‌ها به سمت رکورد والد جریان می‌یابند، پیاده‌سازی می‌شود. بدون این ارث‌بری، سه عامل فرعی که هر کدام «بودجه کمی» دارند، می‌توانند اجرایی بدون سقف مالی ایجاد کنند.

مدیریت عمق و مشاهده‌پذیری

برای جلوگیری از حلقه‌های بی‌نهایت، سیستم باید یک سقف عمق (Depth Cap) پیاده کند. گابریل اشاره می‌کند که دو سطح تو در تو برای تقریباً تمام کاربردهای مشروع کافی است؛ هر چیزی عمیق‌تر از آن، معمولاً نشانه نبود یک ابزار مناسب است. اگر parent.depth >= 2 شد، سیستم باید خطای TooDeep بدهد.

در اجرای موازی، او توصیه می‌کند به‌جای Promise.all از Promise.allSettled استفاده شود. این کار تضمین می‌کند که اگر یک عامل فرعی به سقف نوبت‌های خود رسید، نتایج سایر تحقیقات موفق دور ریخته نشوند. مدل والد باید از تعداد تحقیقات شکست‌خورده مطلع شود تا پاسخی ناقص را به‌عنوان پاسخ کامل ارائه نکند.

برای مشاهده‌پذیری، او یک لاگر درختی پیشنهاد می‌دهد که در آن runId به‌صورت parent.child ترکیب شود. این به توسعه‌دهندگان اجازه می‌دهد درخت اجرا را بازسازی کنند و بفهمند چرا یک درخواست خاص هزینه مشخصی داشته است. او پیشنهاد می‌کند نسبت هزینه عامل فرعی به کل هزینه اجرا را مانیتور کنید؛ اگر این نسبت از ۵۰٪ فراتر رفت، احتمالاً مدل والد شما تبدیل به یک مسیریاب (Router) ساده شده است.

این تغییر رویکرد، توسعه هوش مصنوعی را از «بر اساس حس» (Vibe-based) به یک نظم مهندسی دقیق می‌برد. با نگاه به پنجرهٔ زمینه به‌عنوان یک منبع محدود، می‌توان سیستم‌هایی ارزان‌تر و قابل‌اعتمادتر ساخت.

گام بعدی شما

• وظیفه هر عامل فرعی را ابتدا به‌عنوان یک امضای تابع (Function Signature) بنویسید؛ مثلاً: research(question: string): Promise<{ findings: Finding[]; gaps: string[] }>. اگر با یک فراخوانی جست‌وجو و یک فیلتر ساده قابل پیاده‌سازی است، حلقه مدل را کاملاً حذف کنید.
• سقف عمق تو در تو را روی عدد ۲ تنظیم کنید تا از هزینه‌های پیش‌بینی‌نشده و حلقه‌های بی‌نهایت جلوگیری کنید.
• ساختار بودجه ارث‌بری (Inheritance) را پیاده کنید تا هر عامل فرعی مستقیماً از سهم مدل والد هزینه کند.

برای کسانی که می‌خواهند عمیق‌تر شوند، کتاب AI That Plans و سری AI in TypeScript (در xgabriel.com/ai-in-typescript) توپولوژی‌های ناظر-کارگر (Supervisor-Worker) و ارث‌بری بودجه را با جزئیات پوشش می‌دهند.

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