Loop Engineering واقعاً چیست؟

این روزها همه‌جا اسم Loop Engineering را می‌شنوی؛ توییتر، لینکدین، مقاله‌ها. و شاید حس کنی یک اصطلاح توخالی دیگر است. ولی این‌طور نیست. Loop Engineering دقیقاً همان چیزی است که پشت‌صحنه‌ی هر ایجنت هوش مصنوعی واقعی — از Claude Code گرفته تا دستیارهایی که با n8n می‌سازیم — در حال اجراست.

ساده‌ترین تعریف این است: یک ایجنت هوش مصنوعی مثل یک کارمند جدید است. به او می‌گویی «برو این سفارش را چک کن ببین کجاست». او می‌رود، چک می‌کند، برمی‌گردد و می‌گوید چه دید، و بعد تصمیم می‌گیرد قدم بعدی چیست. این چرخه‌ی «کاری کن، نتیجه را ببین، تصمیم بگیر، دوباره کاری کن» را حلقه (Loop) می‌گوییم. و طراحیِ آگاهانه‌ی همین حلقه، همان چیزی است که به آن Loop Engineering می‌گویند.

نکته‌ی کلیدی این است که امروز، مهارت کمیاب دیگر نوشتن یک پرامپت خوب نیست — بلکه طراحی درست این حلقه است. اینکه ایجنت کِی متوقف شود، بین هر قدم چه کند، و وقتی چیزی خراب شد چه اتفاقی بیفتد.

از Prompt تا Context تا Loop

برای اینکه بفهمی چرا Loop Engineering مهم شده، باید مسیرش را بشناسی. این حوزه سه دوره را پشت سر گذاشته است.

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

آناتومی یک حلقه (Loop)

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

while not done:
    action = model.decide(history)   # تصمیم: چه کاری کنم؟
    result = execute(action)         # اجرا: ابزار را صدا بزن
    history.append(result)         # مشاهده را به تاریخچه اضافه کن
    done = check_stop(history)      # آیا باید متوقف شویم؟

اگر اسم الگوی ReAct به گوشت خورده، دقیقاً همین است: استدلال کن (Reason)، اقدام کن (Act)، مشاهده کن (Observe)، تکرار کن. کل ماجرا همین چند خط است — و بقیه‌ی این مقاله درباره‌ی جزئیاتی است که این چند خط را از یک نمونه‌ی اسباب‌بازی به یک ایجنت واقعی و پایدار تبدیل می‌کنند.

مثال کاربردی: ایجنت پشتیبانی «سارا»

برای اینکه همه‌چیز ملموس بماند، یک مثال می‌سازیم و تا آخر مقاله با آن پیش می‌رویم. فرض کن یک ایجنت پشتیبانی برای فروشگاه اینترنتی ساخته‌ای. اسمش را می‌گذاریم سارا. یک مشتری به سارا پیام می‌دهد: «سفارشم کجاست؟»

• سارا اول تشخیص می‌دهد که این یک سوال درباره‌ی وضعیت سفارش است.
• بعد می‌رود سفارش را با شماره‌اش پیدا می‌کند.
• بعد جواب را می‌نویسد و می‌فرستد.

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

شرط توقف — مهم‌ترین بخش نادیده‌گرفته‌شده

پرتکرارترین دلیل شکست ایجنت‌ها همین است: مشخص‌نکردنِ اینکه حلقه کِی باید تمام شود. اگر این را از قبل و آگاهانه تعیین نکنی، سارا ممکن است گیر کند؛ مثلاً شماره‌ی سفارش را پیدا نکند، دوباره جست‌وجو کند، دوباره جست‌وجو کند، و ده‌ها بار این کار را تکرار کند بدون آنکه هرگز جواب بدهد. این یعنی سارا افتاده در یک حلقه‌ی بی‌پایان — هم مشتری منتظر می‌ماند، هم هزینه بالا می‌رود.

def check_stop(history):
    if history.answer_sent:        # جواب فرستاده شد → تمام
        return True
    if history.attempts >= 3:      # ۳ بار تلاش ناموفق → به انسان بسپار
        escalate_to_human()
        return True
    return False

می‌بینی؟ این دو شرط ساده، همان چیزی است که به آن «شرط توقف» می‌گویند. در محیط واقعی معمولاً چند شرط را با هم لازم داری: تشخیص خودِ مدل که «تمام شد»، یک سقف برای تعداد مراحل، یک بودجه‌ی هزینه/توکن، یا یک ارزیاب که وقتی تایید کرد کار تمام است. چون تشخیص خودِ مدل از «کارم تمام شده» همیشه قابل‌اعتماد نیست.

هزینه و طول حلقه

یک نکته‌ی مهم درباره‌ی هزینه: هر مرحله از حلقه یعنی یک فراخوانی کامل مدل. یعنی زمان و هزینه مستقیماً با طول حلقه بالا می‌رود. ایجنتی که برای یک کار دو مرحله‌ای، ۱۰ مرحله طول می‌کشد، نه‌تنها کندتر است، بلکه چند برابر هزینه و چند برابر احتمال خطا دارد.

برای همین بخش بزرگی از Loop Engineering این است که مراحل غیرضروری را حذف کنی: ابزار درست را از اول بده، و اطلاعات کافی را از همان ابتدا در اختیارش بگذار تا مجبور نشود چند دور اضافه بچرخد تا چیزی که لازم داشت را خودش کشف کند. کوتاه‌ترین مسیری که کار را درست انجام می‌دهد، بهترین مسیر است.

Context Rot — چرا ایجنت‌ها گیج می‌شوند

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

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

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

سه راه‌حل برای Context Rot

خوشبختانه این مشکل راه‌حل‌های عملی روشنی دارد. هر سه دور همان ایده می‌چرخند: اتاق را مرتب نگه دار.

۱. خلاصه‌سازی دوره‌ای

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

summary = "مشتری سفارش ۱۲۳ را دارد، درخواست بازگشت داده، منتظر تایید است."

۲. فقط چیزی که الان لازم است

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

۳. مدیریت نتیجه‌ی ابزارها

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

Harness Engineering — مهم‌تر از خود مدل

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

def search_order(order_id, retries=3):
    for attempt in range(retries):
        try:
            return db_lookup(order_id)
        except TimeoutError:
            wait(1)                  # کمی صبر کن و دوباره تلاش کن
    return "مشکل فنی؛ چند لحظه صبر کنید"  # پاسخ جایگزین امن

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

راستی‌آزمایی و انسان در حلقه

بعضی خروجی‌ها راستی‌آزمایی‌شان ارزان و مطمئن است، بعضی‌ها نه — و همین تفاوت تعیین می‌کند چطور حلقه را طراحی کنی. مثلاً چک‌کردن اینکه «آیا این شماره سفارش در سیستم وجود دارد؟» یک راستی‌آزمایی ارزان و قطعی است؛ یا هست یا نیست. در این موارد، بگذار خود سارا این چک را انجام دهد و اگر اشتباه بود دوباره تلاش کند.

اما بعضی تصمیم‌ها قضاوتی‌اند؛ مثلاً «آیا این عودت وجه منطقی است یا مشتری دارد سوءاستفاده می‌کند؟» اینجا هیچ چک ساده‌ای وجود ندارد که درست‌بودنش را صد در صد مشخص کند. اینجا دقیقاً جای یک انسان است.

حلقه‌ی نسخه‌ی Production

تا اینجا حلقه‌ی ساده را دیدیم: Act → Observe → Decide → Act. این برای یادگیری عالی است. اما در سیستم‌های واقعی و production، معمولاً دو قدم دیگر هم اضافه می‌شود که ارزش دانستن دارند.

# ساده (برای فهمیدن):
Act → Observe → Decide → Act

# واقعی (برای production):
Act → Observe → Verify → Decide → Continue / Stop / Recover

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

چک‌لیست ساخت ایجنت پایدار

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

1. اول یک پرامپت ساده و یک جریان ساده. پیام می‌آید، ایجنت جواب می‌دهد. بگذار این تا انتها کار کند.
2. بعد صدازدن ابزار را اضافه کن تا به‌جای حدس‌زدن، داده‌ی واقعی را ببیند.
3. بعد یک سیستم ارزیابی اضافه کن تا بفهمی واقعاً مشکل را حل می‌کند یا ساکت شکست می‌خورد.
4. بعد حافظه و State اضافه کن تا مشتری را در طول مکالمه به‌خاطر بسپارد.
5. بعد جریان‌های تخصصی (مثل عودت وجه یا ارجاع) را اضافه کن.
6. و فقط وقتی نیاز واقعیِ اثبات‌شده دیدی، انسان یا سیستم چندایجنتی را وارد کن.

جمع‌بندی و قدم بعدی

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

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

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