عامل‌های هوش مصنوعی بدون فریم‌ورک؛ پیاده‌سازی یک بازبین کد در ۸۰ خط

تصور کنید یک عامل هوش مصنوعی کاملاً کاربردی را تنها با ۸۰ خط کد Node.js و بدون هیچ کتابخانه سنگین مدیریت‌کننده‌ای بسازید. این ادعای سیلویا لسک (Sylwia Lask) در ۲۳ ژوئیه ۲۰۲۶ است که باور رایج صنعت مبنی بر ضروری بودن ابزارهایی مثل LangChain یا CrewAI برای رفتارهای عامل‌محور را به چالش می‌کشد.

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

افسانه فریم‌ورک‌ها

به نقل از مستندات این پروژه، فریم‌ورک‌هایی مثل LangChain یا CrewAI جادوی خاصی نمی‌کنند، بلکه فقط چند وظیفه عملیاتی را ساده می‌کنند:

• مدیریت حافظه گفتگوها
• اجرای ابزارها
• منطق تلاش مجدد (Retry)
• مکانیزم‌های جایگزین (Fallback)

وقتی توسعه‌دهنده این سازوکارها را بفهمد، راحت‌تر تصمیم می‌گیرد که آیا هزینه اضافه کردن یک کتابخانه سنگین به پروژه می‌ارزد یا خیر.

پروژه تولد و خلق «استیو»

لسک این پروژه را در هفته‌ای پراسترس، هم‌زمان با دریافت یک ایمیل رد درخواست (CFP) برای کنفرانسی که پیش‌تر دعوت شده بود، توسعه داد. او از این فرصت و مناسبت تولدش استفاده کرد تا جزئیات فنی ساخت یک عامل را با جامعه برنامه‌نویسان به اشتراک بگذارد.

او برای اثبات ادعای خود، استیو (Steve) را ساخت؛ یک عامل مهندس نرم‌افزار ارشد برای بازبینی کدهای Git. استیو به عنوان یک متخصص با ۱۵ سال تجربه تعریف شده که سخت‌گیر است و گاهی لحنی کنایه‌آمیز دارد.

استیو از هیچ فریم‌ورکی استفاده نمی‌کند. او بر اساس یک حلقه for ساده کار می‌کند. لسک راه‌حل for را به while ترجیح داد تا از ایجاد حلقه‌های بی‌نهایت و هزینه اضافی توکن (Token) — تکه‌های کوچکی از متن، مثل برش‌های یک کیک طولانی که مدل تکه‌تکه می‌خورد — جلوگیری کند. این حلقه حداکثر ۱۰ تکرار دارد تا فرآیند حتماً پایان یابد.

این عامل از Gemini API (نسخه gemini-2.5-flash) استفاده می‌کند چون هزینه استنتاج (Inference) — لحظه‌ای که مدل واقعاً جواب تولید می‌کند، مثل خودِ آشپزی و نه دوره‌ی آموزش آشپز — در این مدل‌ها بسیار ارزان است. اگرچه هسته اصلی ۸۰ خط است، اما پروژه کامل شامل تعریف ابزارها و منطق‌های جانبی است و در مخزن code-review-agent در گیت‌هاب موجود است.

در حال حاضر استیو تغییرات (diff) محلی گیت را بررسی می‌کند. لسک اشاره می‌کند که این یک نمونه اولیه از «عامل‌های خود-ترمیم‌گر» است؛ مفهومی که می‌تواند در آینده اتوماسیون کدنویسی را به سطحی برساند که نیاز به برنامه‌نویس انسانی را به شدت کاهش دهد.

چرخه چهار مرحله‌ای اجرا

طبق گزارش لسک، فرآیند استیو از یک چرخه سخت‌گیرانه پیروی می‌کند:

• مرحله ۱: پرامپت و تعریف ابزارها: برنامه پیام کاربر و فهرستی از ابزارهای مجاز را می‌فرستد. این درخواست شامل یک systemInstruction برای تعریف شخصیت استیو و آرایه‌ای از functionDeclarations است. ابزارهای این دمو شامل getDiff برای گرفتن تغییرات گیت، getFile برای خواندن فایل و listFiles برای لیست کردن دایرکتوری‌هاست.
• مرحله ۲: تصمیم مدل: مدل زبانی یا متن ساده برمی‌گرداند، یا درخواست فراخوانی تابع (Function Calling) می‌کند. اگر مدل فقط متن بفرستد، کار تمام است. اما اگر درخواستی برای اجرای ابزاری (مثلاً getDiff) بفرستد، برنامه به مرحله بعد می‌رود.
• مرحله ۳: اجرای محلی: برنامه Node.js ابزار درخواستی را روی سیستم اجرا می‌کند (مثلاً دستور git diff را می‌زند) و نتیجه را به عنوان functionResponse به مدل برمی‌گرداند.
• مرحله ۴: تکرار و تاریخچه: برنامه به مرحله ۲ برمی‌گردد، اما این بار کل تاریخچه گفتگو، درخواست‌های قبلی و نتایج ابزارها را می‌فرستد تا مدل تصمیم بگیرد آیا اطلاعات کافی برای پاسخ نهایی را دارد یا به ابزار دیگری نیاز دارد.

مواجهه با واقعیت‌های عملیاتی

حتی در این پیاده‌سازی مینیمال، لسک با مشکلاتی روبرو شد که فریم‌ورک‌ها معمولاً پنهان می‌کنند. مدل‌های Gemini گاهی خطای ۵۰۳ (Overloaded) می‌دادند. این موضوع او را مجبور کرد یک مکانیزم ساده برای تلاش مجدد (Retry) بنویسد.

در حالی که فریم‌ورک‌های صنعتی قابلیت‌های پیشرفته‌تری مثل Exponential Backoff یا جابه‌جایی خودکار بین مدل‌ها دارند، یک حلقه ساده برای این دمو کافی بود تا پایداری سیستم حفظ شود.

قدرت بومی فراخوانی ابزار

یک نکته کلیدی این است که مدل‌ها مانند Gemini و GPT پشتیبانی بومی از فراخوانی ابزار دارند. آن‌ها آموزش دیده‌اند که تعاریف ابزار را بفهمند و در صورت نیاز، درخواست تابع تولید کنند.

در مقابل، استفاده از مدل‌های قدیمی‌تر Llama نیازمند روشی دستی است: توسعه‌دهنده باید در پرامپت توضیح دهد که مدل باید خروجی را در قالب JSON بفرستد و سپس از JSON.parse() استفاده کند. این روش ریسکی است چون مدل‌های قدیمی اغلب متن‌های اضافی یا توضیحات «کمکی» را در کنار JSON می‌فرستند و باعث شکست برنامه می‌شوند.

بازگشت AI: وقتی عامل، عامل می‌سازد

جالب است بدانید که خودِ این عامل تا حد زیادی توسط یک هوش مصنوعی دیگر نوشته شده است. لسک از Kiro استفاده کرد؛ یک IDE هوشمند که مدل‌های Claude، GPT و Gemini را یک‌جا جمع کرده است. این یک حلقه بازگشتی ایجاد می‌کند: استفاده از عامل‌ها برای ساده‌سازی ساخت عامل‌های جدید.

گام بعدی شما

• اگر در حال ساخت عامل هستید، ابتدا از قابلیت‌های بومی Tool Calling مدل استفاده کنید و از افزودن فریم‌ورک‌های سنگین در ابتدای پروژه بپرهیزید.
• برای کاهش هزینه‌ها، مدل‌های Flash (مانند Gemini Flash) را برای حلقه‌های تکرار شونده به کار ببرید.
• ساختار حلقه for را برای جلوگیری از مصرف بی‌رویه توکن‌ها در عامل‌های خود جایگزین while کنید.

اما داستان اتصال این عامل‌ها به پروتکل‌های استاندارد حتی جذاب‌تر است — به تحلیل ما درباره‌ی پروتکل MCP مراجعه کنید.