تصور کنید هدفی مثل «رفع تمام خطاهای کد، حذف تمام هشدارهای lint و ادغام در شاخه اصلی» را تعریف کنید، لپ‌تاپتان را ببندید و صبح با یک درخواست ادغام (Pull Request) تکمیل‌شده بیدار شوید. این دیگر رویای آینده نیست، بلکه نتیجه‌ی گذار از مهندسی پرامپت به مهندسی حلقه (Loop Engineering) است. در دنیای سنتی، تعامل با هوش مصنوعی به این صورت بود که انسان برای هر گام باید دکمه‌ی «شروع» را فشار می‌داد. اما در مدل جدید، تغییر بنیادین این است که انسان دیگر مدیرِ پرامپت‌های دستی نیست، بلکه معمارِ سیستمی است که خودش به هوش مصنوعی دستور می‌دهد و آن را هدایت می‌کند.
برای اکثر کاربران، هوش مصنوعی تا امروز یک رابط چت بوده است؛ یعنی شما یک پرامپت (Prompt) — شبیه به سفارش دادن یک غذای خاص از منوی رستوران — می‌دهید و یک پاسخ می‌گیرید. اما برای توسعه‌دهندگان حرفه‌ای، این مدل به یک گلوگاه تبدیل شده است. صنعت اکنون به سمتی می‌رود که انسان «فرهنگ» پژوهش یا شرایط توقف یک وظیفه را تعریف می‌کند، در حالی که هوش مصنوعی خط لوله‌ی اجرا (Execution Pipeline) را مدیریت می‌کند. تفاوت اصلی در این است که یک پرامپت فقط یک‌بار اجرا می‌شود، اما یک «هدف» (Goal) تا زمانی که یک شرط قابل تایید برقرار نشود، تکرار می‌شود.
به نقل از گزارش Nokka، این تکامل در ژوئن ۲۰۲۶ به نقطه عطف رسید. این گذار در چهار مرحله رخ داد: ابتدا دستورات تک‌مرحله‌ای به پرامپت‌های طولانی و چندمرحله‌ای تبدیل شدند، سپس عامل‌هایی (Agents) آمدند که می‌توانستند گام بعدی خود را تصمیم بگیرند و در نهایت، نقش «انجام‌دهنده» (Doer) از «داور» (Judge) جدا شد. این رویکرد ساختاریافته به توسعه‌ی مدل‌های منعطف‌تر کمک کرده است، مشابه آنچه در رویکرد جدید DeepSeek برای توسعه‌ی عامل‌های هوشمند با پلاگین‌های قابل تعویض مشاهده می‌کنیم.
شخصیت‌های برجسته‌ای مثل ادی عثمانی از گوگل کروم و بوریس چرنی از آنتروپیک (Anthropic) پیشگام این طراحی شدند. چرنی افشا کرد که برای ۳۰ روز متوالی، بخش بزرگی از کدهای تولیدی Claude Code به‌طور خودکار توسط هوش مصنوعی نوشته شده است؛ نتیجه‌ی این روند ۲۵۹ درخواست ادغام (PR) موفق و نرخ موفقیت ۷۶ درصدی در وظایف باز (Open-ended tasks) بود.
برای اینکه یک حلقه موثر باشد و دچار توهم (Hallucination) — مثل دوستی که با اطمینان خاطره‌ای ساختگی را تعریف می‌کند — نشود، به ۶ رکن اصلی نیاز دارد تا از ادعای موفقیت کاذب توسط مدل جلوگیری کند:
- اتوماسیون‌ها: ضربان قلب سیستم. این‌ها سیستم‌های زمان‌بندی کامل (در جلسه، محلی یا ابری) هستند که اجازه می‌دهند عامل‌ها بر اساس رویدادها اجرا شوند. بدون این رکن، سیستم تنها یک اجرای دستی است.
- درخت‌های کاری (Worktrees): استفاده از git worktrees برای اطمینان از اینکه چندین عامل در یک دایرکتوری با هم برخورد نکنند. هر عامل روی شاخه خود در دایرکتوری مجزا کار می‌کند تا تداخلات فیزیکی فایل‌ها پیش نیاید.
- مهارت‌ها (Skills): پوشه‌های استاندارد شامل فایل
SKILL.md، اسکریپت‌ها و مراجع. این کار تضمین می‌کند که کنوانسیون‌ها و مراحل ساخت هر بار خوانده شوند تا مدل نیاز به توضیحات مکرر درباره پروژه نداشته باشد. - اتصال‌دهنده‌ها: ابزارهایی بر پایه پروتکل زمینه مدل (MCP) برای اینکه حلقه بتواند با ابزارهای دنیای واقعی تعامل کند؛ مانند کوئری زدن به دیتابیس‌ها، خواندن ردیاب‌های خطا (Issue Trackers) یا ارسال پیام در اسلک.
- عامل‌های فرعی: جداسازی حیاتی تولیدکننده (Generator) از ارزیاب (Evaluator). چون مدل‌های کدنویسی هنگام نمره دادن به خودشان «بیش از حد مهربان» هستند، یک عامل دوم با دستورالعمل‌های متفاوت (یا یک مدل متفاوت) باید به عنوان داور مستقل عمل کند.
- وضعیت خارجی: ذخیره حافظه روی دیسک از طریق فایل‌های markdown یا ردیاب‌های خطا، به‌جای تکیه بر پنجره متنی (Context Window) محدود؛ زیرا مدل‌ها بین هر بار اجرا، همه چیز را فراموش می‌کنند.
بر اساس مستندات پروژه autoresearch، آندری کارپاتی در مارس ۲۰۲۶ این رویکرد را به نمایش گذاشت. او با یک اسکریپت پایتون ۶۳۰ خطی، اجازه داد یک GPU شبانه‌روز آزمایش کند. سیستم او از سه فایل خاص استفاده می‌کرد: prepare.py برای زیرساخت‌های ثابت، train.py که توسط هوش مصنوعی قابل ویرایش بود، و program.md جایی که انسان متدولوژی را به زبان طبیعی تعریف می‌کرد.
سیستم کارپاتی از یک «حلقه جغدانه» (Ratchet Loop) ۹ مرحله‌ای پیروی می‌کرد: خواندن دستور، اکتشاف، فرضیه‌سازی، کدنویسی، ثبت وضعیت (Snapshot)، اجرای ۵ دقیقه‌ای، ارزیابی و در نهایت تایید یا بازگشت تغییرات. کارپاتی با اجرای تقریباً ۱۲ آزمایش در ساعت، حدود ۱۰۰ آزمایش را در ۸ ساعت به پایان رساند. از ۷۰۰ تلاش، ۲۰ بهبود قابل انباشت پیدا شد که زمان آموزش nanochat را ۱۱٪ کاهش داد.
با این حال، حلقه‌های تک‌بعدی شکست‌های ساختاری دارند. آن‌ها اغلب قربانی «قانون گودهارت» می‌شوند؛ یعنی عامل برای رسیدن به یک معیار تک‌بعدی (مثل بستن تیکت‌ها) بهینه می‌شود اما هدف واقعی (مثل کیفیت نرم‌افزار) را نادیده می‌گیرد. همچنین دچار «کوری رو به بالا» می‌شوند، به این معنا که یک حلقه نمی‌تواند بپرسد آیا هدف اولیه اصلاً درست بوده است یا خیر. علاوه بر این، وقتی چندین حلقه اهداف متضادی را دنبال می‌کنند، تداخل ایجاد می‌شود.
به همین دلیل، میدان در حال مهاجرت به مهندسی گراف (Graph Engineering) است. در حالی که حلقه یک چرخه منعطف اما مبهم است که در آن عامل همه چیز را مدیریت می‌کند، گراف یک نقشه پیش‌تعریف‌شده از گره‌ها و یال‌هاست. همان‌طور که لوئیس کاتاکورا اشاره کرد، حلقه‌ها فضای بزرگی برای بخشش دارند، اما گراف‌ها شما را مجبور می‌کنند بپذیرید که اکثر گردش‌های کاری هنوز قابل شبیه‌سازی نیستند.
در یک گراف، ساختار از پیش اعلام شده است: چه کسی مالک چه چیزی است، وظایف چه وابستگی‌هایی به هم دارند و بعد از شکست در یک مرحله، باید به کجا بازگردیم. این ساختار، قابلیت حسابرسی (Auditability) و بازیابی مورد نیاز برای محیط‌های عملیاتی (Production) را فراهم می‌کند. برای حل چالش‌های عملیاتی در این مسیر، ابزارهایی مانند LangGraph.js با نقاط بازرسی پایدار به توسعه‌دهندگان کمک می‌کنند تا مشکل توقف ناگهانی عامل‌ها را برطرف کنند. برخلاف یک گردش کار استاندارد، هر گره در گراف یک عامل کامل است (مثلاً «این مشکل را پژوهش کن») و نه یک تابع قطعی؛ و یال‌ها بر اساس خروجی مدل، مسیر را به‌صورت پویا تغییر می‌دهند.
برای متخصصان امروز، این یعنی تغییر شغل؛ شما دیگر مهندس پرامپتی نیستید که یک پاراگراف بی‌نقص می‌نویسد، بلکه معمار سیستمی هستید که حلقه‌ها و گراف‌هایی را طراحی می‌کند تا عامل‌های هوش مصنوعی با هم همکاری کنند و کار یکدیگر را بازبینی نمایند.
گام بعدی شما
- بررسی پروتکل MCP برای اتصال عامل‌های خود به ابزارهای داخلی شرکتتان.
- پیاده‌سازی ساختار «تولیدکننده-داور» در گردش‌های کاری برای کاهش نرخ توهم.
- مطالعه معماری گراف‌ها برای جایگزینی توالی‌های خطی در اتوماسیون‌های پیچیده.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو