مهندسی حلقه؛ جایگزینی برای پرامپت‌نویسی در مقیاس تولید

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

اکثر توسعه‌دهندگان به اشتباه تصور می‌کنند عامل‌ها محصول پرامپت هستند، اما محصول واقعی در واقع همان «حلقه» است. یک عامل در اصل یک LLM است که ابزارها را در یک حلقه به کار می‌گیرد: مشاهده می‌کند، تصمیم می‌گیرد، عمل می‌کند، تأیید می‌کند و این روند را تا رسیدن به یک شرط موفقیت یا توقف تکرار می‌کند. وقتی این حلقه مهندسی نشده باشد، عامل‌ها اغلب ساعت‌ها توکن می‌سوزانند، یک دستور اشتباه را هفت بار تکرار می‌کنند، هدف اصلی خود را فراموش می‌کنند و در نهایت با وجود شکست در تست‌ها، ادای موفقیت در می‌کنند.

با تکیه بر مفهوم «گردش‌کارهای عاملی» (Agentic Workflows)، صنعت در حال فاصله گرفتن از «برنامه‌نویسی با حس» (Vibe Coding) — جایی که توسعه‌دهنده به نبوغ ظاهری مدل تکیه می‌کند — و حرکت به سمت دیسیپلین مهندسی حلقه (Loop Engineering) است. این رویکرد جدید در واقع پاسخی به محدودیت‌های تعاملات سنتی است، مشابه آنچه در طراحی پروتکل‌های جدید برای جایگزینی لیست‌های ابزار ایستا مشاهده می‌کنیم تا انعطاف‌پذیری عامل‌ها افزایش یابد. طبق اجماع متخصصان تا ژوئیه ۲۰۲۶، خودمختاری یک ویژگی پیش‌فرض مدل نیست، بلکه امتیازی است که باید از طریق مهندسی به دست آورد. مهندسی حلقه، تفویض اختیار بالا را با تاییدیه بالا ترکیب می‌کند؛ به این معنا که عامل کار را انجام می‌دهد، اما بررسی‌های اجرایی (Executable Checks) تصمیم می‌گیرند که آیا نتیجه قابل قبول است یا خیر.

معماری دو-حلقه‌ای

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

• حلقه زمان-اجرا (سریع): این حلقه در بازه ثانیه‌ها تا ساعت‌ها رخ می‌دهد و بر چرخه «جمع‌آوری $\rightarrow$ اجرا $\rightarrow$ تأیید $\rightarrow$ ترمیم» تمرکز دارد. هدف آن بهبود خروجی یک تسک خاص است. چرخه ساده است: عامل وضعیت فعلی را می‌خواند، یک ابزار انتخاب می‌کند یا پاسخی تولید می‌کند، نتیجه را مشاهده می‌کند و تصمیم می‌گیرد که آیا هدف تکمیل شده است یا خیر. با این حال، وضعیت هارنس در اینجا عمدتاً ثابت می‌ماند، به این معنی که سیستم هیچ چیز پایداری برای اجرای بعدی یاد نمی‌گیرد.
• حلقه مهندسی (کند): این چرخه در بازه ساعت‌ها تا هفته‌هاست و شامل «اجرا $\rightarrow$ بررسی شکست‌ها $\rightarrow$ شناسایی قابلیت‌های مفقود $\rightarrow$ اصلاح هارنس $\rightarrow$ ارزیابی مجدد» است. این حلقه با تبدیل شکست‌های تکراری به بهبودهای دائمی در ابزارها، زمینه (Context)، قلاب‌ها (Hooks) و ارزیابی‌ها، توانمندی سیستم را در تمام تسک‌های آینده افزایش می‌دهد. اگر خطاهای تایپی (Type Failures) به طور مکرر ظاهر شوند، پاسخ این نیست که «از مدل بخواهیم دقیق‌تر باشد»، بلکه ایجاد یک سیگنال فشار معکوس از طریق چک کردن اجباری تایپ‌ها است.

چرا حلقه‌های خام فرو می‌پاشند؟

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

۱. گسترش زمینه (Context Growth): هر فراخوانی ابزار، متنی تولید می‌کند؛ نتایج جستجو، لاگ‌ها، ردپاهای خطا (Stack Traces) و برنامه‌ها. این امر یک «لندفیل» اطلاعاتی ایجاد می‌کند. شرکت Anthropic زمینه را به عنوان یک بودجه توجه محدود توصیف می‌کند. پژوهش‌ها روی «پوسیدگی زمینه» (Context Rot) نشان می‌دهد که با انباشت داده‌های نامرتبط، استدلال مدل تضعیف می‌شود، حتی اگر مدل هنوز در محدوده پنجره متنی باشد. وقتی محدودیت‌های مهم با هزاران توکن قدیمی رقابت کنند، دقت مدل از دست می‌رود.
۲. انتشار خطا (Error Propagation): یک پاسخ نادرست از API یا یک فرض اشتباه می‌تواند در گام بعدی به عنوان «واقعیت» پذیرفته شود. سپس عامل بر اساس این وضعیت فاسد برنامه‌ریزی می‌کند و اثر ضرب‌الضرب ایجاد می‌کند، به طوری که یک مشاهده بد، تمام کارهای پایین‌دستی را خراب می‌کند.
۳. عدم توقف (Non-termination): عامل‌ها ممکن است وارد یک حلقه بی‌نهایت شوند. جمله‌ای مثل «رویکرد دیگری را امتحان می‌کنم» یک مدار-شکن (Circuit Breaker) نیست. این چالش دقیقاً همان چیزی است که ابزارهای تخصصی مانند ai-loopguard برای متوقف کردن چرخه‌های مرگبار عامل‌ها توسعه داده‌اند تا از اتلاف منابع جلوگیری کنند. بدون مکانیسم‌هایی برای تشخیص اینکه وضعیت تغییر نکرده است، عامل برای همیشه همان دستورات شکست‌خورده را تکرار می‌کند.
۴. انحراف از هدف (Goal Drift): پس از ده‌ها گام، عامل‌ها اغلب روی یک زیر-مسئله محلی بهینه‌سازی می‌کنند. ممکن است یک بازسازی کد (Refactor) ظریف ارائه دهند در حالی که فقط یک اصلاح تک‌خطی درخواست شده بود، یا پیشرفت جزئی (مثلاً انتقال ۳۵ مورد از ۵۰ مورد) را به عنوان تکمیل کامل تلقی کنند. عامل‌های طولانی‌مدت نیاز دارند که هدفشان دوباره لنگر انداخته شود، نه اینکه فقط در تاریخچه یادآوری شود.

پنج الگوی ضروری برای عامل‌ها

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

• ReAct: تناوب بین استدلال، عمل ابزاری و مشاهده. برای پژوهش‌های باز عالی است اما ریسک سردرگمی یا انباشت زمینه نویزی دارد.
• Reflexion / Self-Critique: تولید خروجی، بازرسی شکست، تأمل و تلاش مجدد. ایده‌آل برای کدهایی که می‌توانند تست شوند یا پیش‌نویس‌هایی با بازخورد واضح. ریسک اصلی این است که تولیدکننده ممکن است خروجی بد خود را توجیه کند.
• Plan-and-Execute: ایجاد یک نقشه، اجرای گام‌ها و برنامه‌ریزی مجدد در صورت تفاوت واقعیت با نقشه. برای تسک‌های طولانی و مرحله‌بندی شده بهترین است، اگرچه یک نقشه اولیه بد می‌تواند تمام گام‌های بعدی را منحرف کند.
• Evaluator-Optimizer: یک جزء تولید می‌کند و جزء دیگر امتیاز می‌دهد و بازخورد می‌سازد. این الگو با یک روباریک (Rubric) کیفی پایدار بهترین عمل می‌کند، به شرطی که ارزیاب ضعیف یا دارای سوگیری نباشد.
• Human-in-the-Loop: توقف در نقاط بررسی صریح برای تایید انسانی. این یک الزام معماری برای پرداخت‌ها، حذف داده‌ها، انتشار محتوا یا ارتباطات حساس با مشتری است. با این حال، دروازه‌های زیاد، خودمختاری مفید را نابود می‌کنند.

به نقل از راهنمای Building Effective Agents از شرکت Anthropic، پیشنهاد می‌شود با ساده‌ترین الگو شروع کنید و پیچیدگی عاملی را تنها زمانی اضافه کنید که بهبود خروجی به صورت عددی قابل اندازه‌گیری باشد. یک گردش‌کار قطعی (Deterministic) با اجازه دادن به LLM برای بداهه پردازی بهبود نمی‌یابد؛ گاهی یک فراخوانی ساده بازیابی (Retrieval) می‌تواند یک عامل پیچیده را شکست دهد اگر نیازی به تکرار نباشد.

لایه‌های پنج‌گانه هارنس تولید

برای عبور از مرحله دمو به تولید، یک حلقه سطح تولید به پنج لایه عملیاتی نیاز دارد تا یک چرخه ساده ReAct را به یک سیستم کنترل تبدیل کند:

• مهندسی زمینه (Context Engineering): انتخاب، فشرده‌سازی و جداسازی اطلاعات. هدف این است که کوچک‌ترین زمینه با بیشترین سیگنال فراهم شود که از تصمیم درست بعدی پشتیبانی کند، به جای اینکه همه چیز به مدل داده شود.
• اجرای محدود (Bounded Execution): کنترل‌های سخت در کد (نه پیشنهادات در پرامپت) که سقف تعداد گام‌ها، بودجه توکن/هزینه، ضرب‌الاجل‌های زمانی، تایم‌اوت‌های ابزارهای خاص و تشخیص تکرار را اعمال می‌کنند.
• حفاظ‌های لایه‌ای (Layered Guardrails): کنترل‌هایی که محتوای ورودی، فراخوانی‌های پیشنهادی ابزار، پاسخ‌های ابزار، گذارهای وضعیت و خروجی‌های نهایی را بازرسی می‌کنند تا از آلودگی اجرا با داده‌های ناامن جلوگیری کنند.
• دروازه‌های انسانی (Human Gates): یک ماتریس تصاعد که تعریف می‌کند کدام اقدامات نیاز به تایید انسان دارند. مثال‌ها: بازپرداخت مبلغ بالای یک حد مشخص، حذف داده‌های محیط Production، تغییر سیاست‌های IAM یا ارسال ایمیل‌های خارجی.
• مشاهده‌پذیری و ارزیابی (Observability and Evaluation): ثبت هر گذار — اقدام انتخاب شده، تأخیر، هزینه، تعداد تلاش مجدد و دلیل توقف — برای ارزیابی کامل ردپاها (Traces) در برابر تسک‌های نماینده با استفاده از ابزارهایی مثل Langfuse، LangSmith یا OpenTelemetry.

مکانیسم قرقره در عمل

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

OpenAI در گزارش مهندسی هارنس سال ۲۰۲۶ این مورد را توصیف کرد. یک تیم سه نفره با استفاده از Codex موفق شد در پنج ماه، ۱,۵۰۰ PR را ادغام و تقریباً یک میلیون خط کد تولید شده توسط عامل را مدیریت کند. آن‌ها این موفقیت را با ثبت یک‌باره‌ی قضاوت انسانی و در دسترس قرار دادن آن برای عامل در تمام دفعات بعدی به دست آوردند. درس این است که محیط باید به گونه‌ای کدگذاری شود که قابلیت مفقود را پوشش دهد.

تفکیک ترمیم Runtime و اصلاح Harness

هر شکستی نیاز به قانون جدید ندارد. کدگذاری هر اشتباه تک‌موردی باعث می‌شود هارنس شکننده شود و دچار Overfit گردد. مهندسان باید بپرسند: «آیا این اصلاح به بسیاری از اجراهای آینده کمک می‌کند یا فقط همین یک‌بار است؟»

ترمیم در Runtime زمانی کافی است که:

• یک تست شکست می‌خورد و عامل به درستی آن را وصله (Patch) می‌کند.
• یک درخواست API گذرا پس از تلاش مجدد با فاصله زمانی (Backoff) موفق می‌شود.
• فرضیه اول اشتباه است، اما شواهد مدل را به فرضیه بهتری می‌رساند.
• عامل به یک حقیقت مفقود نیاز دارد و می‌تواند آن را بازیابی کند.
• مسئله مختص به همان تسک است و احتمال تکرار ندارد.

ارتقاء به اصلاح هارنس زمانی لازم است که:

• یک اشتباه مشابه در تسک‌های مختلف ظاهر شود.
• عامل نتواند سیگنال لازم برای بازیابی را مشاهده کند.
• شکست دارای «شعاع تخریب» خطرناک باشد (مثلاً اجرای SQLهای مخرب).
• عامل مکرراً وضعیت «پایان» را اعلام کند در حالی که یک بررسی مکانیکی هنوز قرمز (ناپذیرفتنی) است.
• تسک از ساختار برنامه‌ریزی یک تک-عامل فراتر رود.
• انسان‌ها مدام یک کامنت مشابه را روی تمام PRها بنویسند.

مثال‌های خاص از مکانیسم قرقره:

• ویرایش ماژول اشتباه: اضافه کردن یک نقشه موجز از مخزن کد با لینک به مستندات معماری (مثلاً در AGENTS.md یا CLAUDE.md).
• پیشنهاد SQL مخرب: اضافه کردن یک قلاب (Hook) پیش از اجرا برای مسدود کردن عملیات‌های ناامن.
• ارسال خطاهای تایپی: تبدیل چک کردن تایپ به یک دروازه تکمیل اجباری که خطاهای ساختاریافته را بازمی‌گرداند.
• از دست دادن رشته افکار در مهاجرت ۴۰ مرحله‌ای کد: اضافه کردن یک برنامه اجرای نسخه‌بندی شده و جداسازی نقش‌های برنامه‌ریز (Planner) و اجراکننده (Executor).
• ورودی‌های مبهم ابزار: بازطراحی قرارداد ابزار با پارامترهای تایپ شده و اعتبارسنج شده.
• ایرادات معماری تکراری: تبدیل اصل معماری به یک قانون Lint سفارشی یا یک مورد ارزیابی.

مهندسی زمینه: عبور از مه

حلقه‌های طولانی در نهایت به سیستم‌های مدیریت زمینه تبدیل می‌شوند. برای جلوگیری از «مه»، سه تکنیک حیاتی است:

۱. فشرده‌سازی (Compaction): خلاصه‌سازی ردپاهای قدیمی. حفظ وضعیت‌های بحرانی (تصمیمات، مسائل حل‌نشده، فایل‌های تغییر یافته) اما حذف خروجی‌های خام ابزار پس از ادغام نتیجه. فشرده‌سازی دارای فقدان داده است؛ بنابراین باید برای «فراخوانی» (Recall) بهینه شود تا تصمیمات ظریف معماری حذف نشوند.
۲. یادداشت‌برداری ساختاریافته: ثبت پیشرفت در خارج از پنجره متنی با استفاده از لیست‌های TODO، منطق تصمیمات و لاگ‌های پیشرفت. این کار با فایل‌سیستم به عنوان حافظه بلندمدت و پنجره متنی به عنوان حافظه فعال برخورد می‌کند.
۳. جداسازی زیر-عامل‌ها (Subagent Isolation): سپردن تسک‌های متمرکز به عامل‌هایی با زمینه‌های پاک. کارگرها می‌توانند هزاران توکن جزئیات را بررسی کنند اما تنها نتایج تقطیرشده را به هماهنگ‌کننده (Coordinator) بازگردانند.

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

تاییدکننده به مثابه مشخصات اجرایی

در مهندسی حلقه، تاییدکننده (Verifier) تبدیل به سند مشخصات (Specification) پروژه می‌شود. خطر اصلی «قانون گودهارت در مقیاس کوچک» است: عاملی که یک معیار را سبز می‌کند در حالی که نیاز واقعی همچنان خراب است. مثال‌ها:

• بالا رفتن پوشش تست (Coverage) از طریق Assertionهای بی‌ارزش.
• بستن سریع تیکت‌های دشوار برای علامت‌گذاری به عنوان «حل شده».
• داورهای LLM که مطالب پوچ اما صیقل‌خورده را تایید می‌کنند.
• بهبود زمان پاسخ در حالی که درستی (Correctness) کاهش می‌یابد.

یک تاییدکننده قوی باید ترکیبی از این سیگنال‌ها باشد:

• بررسی‌های قطعی: سینتکس، تایپ‌ها، شِماها (Schemas) و سیاست‌ها.
• بررسی‌های رفتاری: سناریوهای پذیرش و تست‌های رگرسیون برای شکست‌های پیشین.
• ارزیاب‌های مستقل: داورهای LLM کالیبره شده برای ویژگی‌های کیفی، که در برابر مثال‌های برچسب‌خورده توسط انسان ردیابی می‌شوند.
• قضاوت انسانی: برای موارد حساس یا مبهم.

اسکلت حلقه تولید

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

• بررسی بودجه/ضرب‌الاجل: توقف در صورت اتمام توکن‌ها، هزینه یا زمان واقعی.
• تایید نهایی: گام verify_goal که وضعیت را با معیارهای پذیرش مقایسه کرده و در صورت شکست، بازخورد بازمی‌گرداند.
• تشخیص حلقه: شناسایی وضعیت repeated_without_progress برای فعال کردن تصاعد به انسان.
• اعتبارسنجی ابزار: اطمینان از اینکه raw_result پیش از تبدیل به وضعیت جدید، اعتبارسنجی و نرمال‌سازی شده است.
• تخریب پاک (Clean Degradation): توانایی بازگرداندن یک «نتیجه جزئی» (مثلاً: «نتوانست در محدوده بودجه به طور ایمن تکمیل شود») به جای جعل موفقیت.

تحلیل: تغییر در نیروی کار AI

این تحول، نقش مهندس هوش مصنوعی را دگرگون می‌کند. ارزش اصلی دیگر در نوشتن یک «مگا-پرامپت» نیست، بلکه در طراحی سیستمی است که مدل را به موفقیت ناچار کند. تفویض اختیار و سخت‌گیری (Rigor) دو محور مستقل هستند؛ مهندسی حلقه تعمداً گوشه «تفویض اختیار بالا و تاییدیه بالا» را اشغال می‌کند. تفویض اختیار بدون تایید، صرفاً پذیرش ریسک مشاهده‌نشده است.

با تمرکز بر حلقه مهندسی، تیم‌ها با شکست‌ها به عنوان داده‌های تشخیص (Diagnostic) برخورد می‌کنند. این امر منجر به ایجاد یک «حلقه سوم» می‌شود که در آن مدل‌ها و هارنس‌ها با هم تکامل می‌یابند. همان‌طور که هارنس‌ها قابلیت‌هایی مثل ویرایش‌های ساختاریافته یا کنترل مرورگر را فراهم می‌کنند، مدل‌های آینده روی این قابلیت‌ها آموزش می‌بینند. این جفت‌شدگی به این معناست که مدل و هارنس باید با هم ارزیابی شوند، زیرا عملکرد مدل اغلب بازتابی از کیفیت داربست (Scaffold) آن است. یک قانون تجاری که به عنوان تست یا شما کدگذاری شده، بسیار راحت‌تر از ترفندی که در پرامپت پنهان است، در برابر تغییر مدل‌ها حفظ می‌شود.

قوانین نهایی برای پروژه‌های عاملی

برای تضمین پایداری در تولید، این محدودیت‌های اصلی را دنبال کنید:
۱. موفقیت را مکانیکی قابل‌بررسی کنید: عبارت «خوب به نظر می‌رسد» یک شرط توقف نیست. از تست‌ها، شماها یا تاییدات انسانی استفاده کنید.
۲. با زمینه به عنوان حافظه فعال برخورد کنید: جزئیات را دقیقاً در لحظه نیاز بازیابی کنید و برای کارهای عمیق از زمینه‌های ایزوله استفاده کنید.
۳. محدودیت‌های سخت را خارج از مدل قرار دهید: سقف گام‌ها و بودجه‌ها متعلق به کد هستند، نه پرامپت‌ها.
۴. شکست‌های تکراری را به بهبودهای هارنس تبدیل کنید: یک اشتباه مکرر، نشانه یک قانون مفقود یا رابط کاربری شکسته است.
۵. مرز انسان-AI را پیش از اجرا رسم کنید: در زمانی که آرام هستید، درباره دروازه‌های تایید برای اقدامات بازگشت‌ناپذیر تصمیم بگیرید.
۶. پیش از مقیاس‌بندی، ابزارگذاری کنید: ردپاها را حفظ کرده و مجموعه‌ای از ارزیابی‌ها بسازید تا هزینه به ازای هر موفقیت تایید شده را اندازه بگیرید.

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