ایجنت هوش مصنوعی چیست و چگونه کار می‌کند؟

آقای Thorsten Ball، سازنده Ampcode، درباره ایجنت‌ها گفته: «پشت هیاهوی ایجنت‌ها یک ساختار ثابت وجود دارد: یک LLM، یک حلقه (Loop) و مقدار کافی توکن.» احتمالا شما کارکرد LLM و توکن را می‌دانید؛ اما، آیا می‌دانید نقش حلقه چیست؟ ساده بگویم، حلقه موجودی است که یک LLM را به Agent تبدیل می‌کند. آقای Boris Cherny، کسی که Claude Code را ساخته، گفته: «من دیگر به Claude پرامپت نمی‌دهم. من حلقه‌هایی دارم که در حال اجرا هستند. وظیفه من نوشتن حلقه‌هاست.» کسی که یکی از محبوب‌ترین عامل‌های کدنویسی دنیا را ساخته، دیگر به آن پرامپت نمی‌دهد. اگر شما هم مثل من به پشت صحنه ایجنت هوش مصنوعی و نحوه کار آن علاقه‌مند هستید، این مقاله مخصوص شماست…

حلقه در ایجنت

ایجنت (Agent) یک جعبه جادویی نیست. در هسته خود، فقط یک حلقه ساده است. فرآیند به این شکل آغاز می‌شود که پرامپت کاربر به LLM داده شده و یک خروجی دریافت می‌شود. در این مرحله یک شرط منطقی بررسی می‌شود: آیا خروجی تولید شده شامل درخواست فراخوانی ابزار (Tool Call) است یا خیر؟

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

جالب است بدانید که بعضی افراد نام این حلقه را حلفه احمق (The Dumb Loop) نامیده‌اند! چون این حلقه از خود هیچ هوشمندی مستقلی ندارد و تمام تصمیمات (ورود به حلقه، تکرار یا شکستن آن) صرفا به هوشمندی بلوک LLM وابسته است. پیاده‌سازی مینیمال این معماری در پایتون تنها به ۶ خط کد نیاز دارد:

messages = [system_prompt, user_task]
while True:
    response = llm.call(messages, tools)
    if not response.tool_calls: 
        return response.content
    messages.append(response)
    messages.append(execute_tools(response.tool_calls))

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

شکست ایجنت: از کانتکست مدل تا ریسک امنیتی

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

• آشوب در اثر خطای ابزارها: در این معماری ساده، اگر تنها یکی از ابزارهای در دسترس LLM هنگام اجرا با خطا (Error) مواجه شود، کل اپلیکیشن متوقف (Crash) می‌شود.
• حلقه بی‌نهایت (Infinite Loop): مسئولیت شکستن حلقه بر عهده LLM است. در صورت بروز توهم (Hallucination) یا گیر کردن مدل در یک چرخه تصمیمی باطل، حلقه تا ابد تکرار شده و منجر به مصرف شدید توکن و هزینه‌های API می‌شود، بدون آنکه پاسخی تولید کند.
• ریسک‌های امنیتی سطح سیستم: اگر ایجنت به محیط سیستمی دسترسی داشته باشد و محدودیتی اعمال نشده باشد، می‌تواند دستورات مخربی (مانند حذف دایرکتوری‌ها با دستوراتی مشابه rm -rf) را کورکورانه اجرا کند.
• رشد نمایی کانتکست (Context Drift): در هر تکرار حلقه، خروجی مدل و خروجی ابزارها به متغیر messages اضافه می‌شود. این انباشت داده به سرعت پنجره کانتکست (Context Window) مدل را پر کرده و موجب افت شدید عملکرد و دقت مدل می‌شود.
• عدم مشاهده‌پذیری (Black Box): کل فرآیند دریافت پرامپت و اجرای ابزار در اختیار LLM است. در صورت شکست ایجنت، توسعه‌دهنده هیچ دیدی (Visibility) نسبت به روند تصمیم‌گیری مدل ندارد.

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

Harness Engineering

مهندسی هارنس (Harness Engineering)

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

تمرکزم را روی همان پنج شکست حلقه ساده ایجنت می‌گذارم؛ می‌خواهم، به زبانی ساده نشان دهم که هارنس چگونه این پنج شکست را مدیریت می‌کند:

• مدیریت خطا (Error Handling): کنترل خطاهای ابزارها و جلوگیری از Crash شدن کل سیستم.
• کنترل حلقه: تعریف سقف تکرار (Max Iterations) برای جلوگیری از حلقه‌های بی‌نهایت.
• سندباکس (Sandboxing): اجرای کدها و ابزارها در محیط‌های ایزوله برای جلوگیری از آسیب به سیستم میزبان.
• مدیریت کانتکست: استفاده از تکنیک‌های خلاصه‌سازی (Summarization) و مدیریت حافظه برای جلوگیری از پر شدن پنجره کانتکست.
• افزایش مشاهده‌پذیری: پیاده‌سازی سیستم‌های لاگ‌گیری دقیق (Telemetry) برای بررسی مراحل تصمیم‌گیری ایجنت.

LangChain این موضوع را خیلی ساده بیان می‌کند:

Agent = Model + Harness

یعنی، اگر شما خود مدل نیستید، پس شما همان Harness هستید. به عبارت دیگر، در نگاه LangChain، حتی همان حلقه جز هارنس محسوب می‌شود. این نکته باید اولویت‌های شما را کاملا تغییر دهد. چون، امروزه Harness از خود مدل مهم‌تر شده است. تیم‌هایی بوده‌اند که مدل را کاملا ثابت نگه داشته‌اند، فقط کد اطراف آن را تغییر داده‌اند و از میانه جدول یک بنچمارک به جمع پنج رتبه برتر رسیده‌اند. همان مغز، اما با حلقه‌ای متفاوت.

چه زمانی ایجنت باید متوقف شود؟

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

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

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

• حداکثر تعداد تکرارها (Max iterations): یک سقف قطعی تا ایجنتی که گیر کرده، برای همیشه اجرا نشود.
• محدودیت بودجه و زمان: سقفی برای تعداد توکن‌ها، هزینه و مدت اجرا.
• تشخیص عدم پیشرفت (No-progress detection): اگر ایجنت همان فراخوانی را با همان آرگومان‌ها تکرار کند، یعنی در حال دور زدن درجا است.
• بررسی واقعی اتمام کار (Completion check): یک شرط خودکار که ثابت کند کار واقعا تمام شده است.

مورد آخر، مهم‌ترین بخش است.

«تمام شد» یعنی تست‌ها با موفقیت پاس شده‌اند، نه اینکه ایجنت صرفا نسبت به کاری که انجام داده احساس خوبی داشته.

تمیز نگه داشتن کانتکست ایجنت

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

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

برای مقابله با این وضعیت، باید با کانتکست مثل یک بودجه رفتار کنید، نه مثل یک سطل.

• Compaction: وقتی مکالمه طولانی شد، آن را خلاصه کنید و ادامه کار را بر اساس همان خلاصه انجام دهید.
• Offloading: خروجی‌های بسیار بزرگ را داخل یک فایل ذخیره کنید و فقط بخشی را که لازم است در کانتکست نگه دارید.
• Sub-agents: یک زیروظیفه‌ شلوغ و پیچیده را به یک ایجنت جداگانه بسپارید و فقط نتیجه‌ تمیز آن را به حلقه‌ اصلی برگردانید.

غریزه‌ طبیعی این است که همه‌چیز را نگه دارید، چون شاید بعدا لازم شود. مهارت واقعی این است که بدانید چه چیزهایی را باید دور بریزید.

ابزار (Tools) در ایجنت

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

دو نکته، بیش از چیزی که مردم تصور می‌کنند اهمیت دارند:

• نوشتن (Write) را طوری طراحی کنید که تکرار آن بی‌خطر باشد. حلقه‌ها دوباره تلاش می‌کنند. اگر یک فراخوانی مجدد برای ایجاد مشتری باعث ایجاد یک مشتری دوم شود، صبح که بیدار شوید با رکوردهای تکراری و صورتحساب‌های دوبرابری مواجه خواهید شد. هر عملی که وضعیت سیستم را تغییر می‌دهد باید در برابر اجرای دوباره ایمن باشد.
• پیام‌های خطا را برای ایجنت بنویسید، نه برای انسان. یک پیام خطای خوب، به ایجنت می‌گوید قدم بعدی چیست. قبل از انتشار هر ابزار، از خودتان بپرسید: «اگر یک مدل زبانی این پیام خطا را بخواند، آیا می‌داند باید چه کاری انجام دهد؟» در یک حلقه، خطا پایان راه نیست؛ بلکه دستورالعمل بعدی است.

ایجنت باید بتواند نه بگوید!

حلقه‌های خودکار یک حالت شکست پنهان دارند. ایجنتی که تنها رها شود، معمولا با خودش موافقت می‌کند. دقیق‌ترین جمله‌ای که در تمام این بحث گفته شده این است: طراحی حلقه فقط نیمی از کار است؛ نیمه دیگر این است که چیزی داخل حلقه قرار دهید که بتواند «نه» بگوید؛ مثل یک تست، یک بررسی نوع (Type Check)، یا یک خطای واقعی. حلقه‌ای که منتقد نداشته باشد، فقط عاملی است که مدام کار خودش را تایید می‌کند. راه‌حل این است که سازنده (Maker) را از ارزیاب (Checker) جدا کنید.

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

تغییر واقعی درباره ایجنت‌ها

حالا جمله آقای چرنی معنا پیدا می‌کند:

پرامپت دادن یعنی شما حرکت به حرکت ایجنت را هدایت می‌کنید.
مهندسی حلقه یعنی سیستمی را می‌سازید که خودش ایجنت را هدایت کند و بعد یک قدم به عقب برمی‌دارید.

در این حالت، وظیفه شما از دادن دستورها به طراحی سه چیز تغییر می‌کند:

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

آندری کارپاتی (Andrej Karpathy) این طرز فکر را به‌خوبی توصیف می‌کند:

به مدل نگویید چه کاری انجام دهد؛ معیارهای موفقیت را به آن بدهید و تماشایش کنید.

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

برای ساخت ایجنت هوش مصنوعی از کجا شروع کنیم؟

لازم نیست از روز اول یک ایجنت کاملا خودکار داشته باشید. قدم‌به‌قدم پیش بروید:

• با همان حلقه پایه شروع کنید، اما از همان ابتدا یک سقف برای تعداد تکرارها، یک محدودیت زمانی و یک سقف هزینه اضافه کنید.
• قبل از شروع، تعریف کنید که تمام شدن دقیقا چه بررسی خودکاری است؛ نه اینکه بعدا صرفا بر اساس حس و حال تصمیم بگیرید.
• از کانتکست محافظت کنید. اجراهای طولانی را خلاصه کنید، خروجی‌های بزرگ را منتقل کنید و زیروظیفه‌های شلوغ را جدا نگه دارید.
• ابزارهای خود را بازبینی کنید. تعدادشان کم و هدفمند باشد، عملیات نوشتن در آن‌ها در برابر اجرای مجدد ایمن باشد و پیام‌های خطا طوری بازنویسی شوند که ایجنت بتواند بر اساس آن‌ها اقدام کند.
• یک منتقد (Critic) داخل حلقه قرار دهید. سعی کنید به شکلی پیاده‌سازی کنید که به «نه» گفتنش اعتماد داشته باشید.

جمع‌بندی ایجنت هوش مصنوعی

مهندسی هارنس یک فریم‌ورک یا ابزاری نیست که نصبش کنید. مدل، به‌تدریج در حال تبدیل شدن به یک کالای عمومی (Commodity) است. حلقه‌ای که دور آن ساخته می‌شود، جایی است که مهندسی واقعی امروز در آن اتفاق می‌افتد. بهترین سازندگان دیگر نمی‌پرسند: «به ایجنت بگویم چه کاری و چگونه انجام دهد؟» آن‌ها می‌پرسند: «چه سیستمی می‌تواند این کار را بدون حضور من انجام دهد؟»  اگر به این سوال پاسخ خوبی بدهید، شما هم دیگر به عامل‌ها پرامپت نخواهید داد.