مهندسی چرخه چیست؟ تعریف و تفاوت آن با prompt

مهندسی چرخه چیست

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

خلاصه این است: دیگر فقط دستورالعمل نمی‌نویسید؛ بلکه یک سیستم کنترل می‌نویسید. عامل همچنان به دستورالعمل‌های مناسب نیاز دارد، اما این دستورالعمل‌ها به یکی از اجزای چرخه‌ای تبدیل می‌شوند که طبق برنامه اجرا می‌شود، در یک کپی ایزوله از کد شما کار می‌کند، نتیجه خود را با یک test اثبات می‌کند و هنگام تمام شدن budget از ادامه کار صرف‌نظر می‌کند.

چرا این اصطلاح در 2026 مطرح شد

این نام همین حالا در فضای عمومی در حال تثبیت است. مخزن GitHub یعنی cobusgreyling/loop-engineering در فاصله 2 ماه پس از نخستین انتشار، به بیش از 9,600 ستاره رسید (تا ژوئیه 2026) و این عبارت را در توضیح خود داشت: «دیگر prompt ننویسید. حلقه را طراحی کنید. امتیاز بگیرید.» این رویکرد، این تغییر را در 6 جزء اصلی گردآوری می‌کند: زمان‌بندی، worktreeها، مهارت‌ها، pluginها و connectorها، زیرعامل‌ها، و حافظه پایدار که خارج از گفتگو نگهداری می‌شود.

در این مخزن به نقل از Boris Cherny، مدیر Claude Code در Anthropic، آمده است:

من دیگر برای Claude prompt نمی‌نویسم. حلقه‌هایی دارم که برای Claude prompt می‌نویسند.

مخزن دوم، یعنی AI-Builder-Club/skills، حدود 1,100 ستاره دارد (تا ژوئیه 2026) و این 2 نقش را مستقیماً نام‌گذاری می‌کند: یک «harness کدپایه» که مخزن را برای اجرای آزمایش‌ها و deployها توسط agent ایمن می‌کند، و یک «مهندس حلقه» که workflowهایی می‌سازد که با یک trigger فعال می‌شوند، کار را انجام می‌دهند و آموخته‌های خود را در یک فایل مشترک می‌نویسند تا حلقه بعدی بتواند آن را بخواند.

هیچ‌کدام از این 2 مخزن این روش را ابداع نکرده‌اند. هرکس که یک build شبانه، یک linter در continuous integration یا یک cron job برای باز کردن ticket اجرا کرده باشد، با ساختار آن آشناست. نکته جدید این است که worker داخل حلقه اکنون غیرقطعی است؛ بنابراین سازوکارهای پیرامونی باید وظایف متفاوتی انجام دهند.

چهار بخش یک حلقه

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

• محرک. رویدادی که اجرای یک نوبت را آغاز می‌کند: یک زمان‌سنج، یک webhook، یک pull request جدید یا یک هشدار.
• مرز. فایل‌ها، اعتبارنامه‌ها و شبکه‌ای که agent در طول آن نوبت می‌تواند به آن‌ها دسترسی داشته باشد.
• تأیید. بررسی‌ای همراه با exit code که تعیین می‌کند خروجی نوبت حفظ شود یا کنار گذاشته شود.
• سهمیه. محدودیت توکن، زمان و هزینه که اجرای یک نوبت را، چه موفق شده باشد و چه نشده باشد، پایان می‌دهد.

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

محرک: چه چیزی عامل را بیدار می‌کند

تایمر ساده‌ترین محرک است. در یک سرور Linux، برای این کار تایمر systemd از cron مناسب‌تر است، زیرا گزارش ثبت می‌کند، بر اساس تنظیمات شما دوباره تلاش می‌کند و نسخه دوم واحدی را که هنوز در حال اجراست، راه‌اندازی نمی‌کند. ویژگی آخر، رایج‌ترین خطای هم‌پوشانی در حلقه‌های عامل را حذف می‌کند: اجرای هم‌زمان دو نوبت که یک شاخه را ویرایش می‌کنند.

واحد را در /etc/systemd/system/agent-loop.service بنویسید:

[Unit]
Description=Agent loop: triage open issues
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
User=agent
WorkingDirectory=/srv/agent/repo
ExecStart=/srv/agent/bin/loop.sh
TimeoutStartSec=1800

تایمر را نیز در /etc/systemd/system/agent-loop.timer بنویسید:

[Unit]
Description=Run the triage loop every 30 minutes

[Timer]
OnBootSec=5min
OnUnitActiveSec=30min
Unit=agent-loop.service

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now agent-loop.timer
systemctl list-timers agent-loop.timer

systemctl list-timers باید ستونی با عنوان NEXT نشان دهد که زمانی در آینده را نمایش می‌دهد و ستونی با عنوان LEFT که شمارش معکوس را نشان می‌دهد. نتیجه خالی یعنی تایمر فعال نیست، زیرا enable بدون --now آن را فقط برای راه‌اندازی بعدی زمان‌بندی می‌کند. TimeoutStartSec=1800 مهم‌تر از چیزی است که به نظر می‌رسد: اگر عامل هنگام انتظار برای ورودی متوقف شود، در غیر این صورت واحد را برای همیشه فعال نگه می‌دارد و تایمر دیگر اجرا نمی‌شود. یک اجرا را با journalctl -u agent-loop.service -n 50 بخوانید.

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

*/30 * * * * /usr/bin/flock -n /tmp/agent-loop.lock /srv/agent/bin/loop.sh

flock -n زمانی که قفل در اختیار فرایند دیگری است، فوراً با وضعیت 1 خارج می‌شود. در نتیجه، اجرای دوم بدون ایجاد رقابت با اجرای اول، بی‌سروصدا پایان می‌یابد. همین راه‌اندازی سرویس و تایمر systemd برای هر کار طولانی‌مدت دیگری روی این سیستم، چه عامل باشد و چه نباشد، کاربرد دارد.

مرزبندی: برای هر اجرا یک کپی اختصاصی ایجاد کنید

عاملی که در درخت کاری شما ویرایش انجام می‌دهد، می‌تواند کارهای commit‌نشده شما را از بین ببرد. Git worktree این مشکل را با هزینه کمی حل می‌کند: هر اجرا دایرکتوری و branch اختصاصی خود را دارد و همه اجراها از یک object store مشترک استفاده می‌کنند.

cd /srv/agent/repo
git worktree add -b loop/triage-01 /srv/agent/work/triage-01 origin/main
git worktree list

git worktree list برای هر درخت، یک خط شامل مسیر، commit و branch آن چاپ می‌کند. با پایان اجرا، git worktree remove /srv/agent/work/triage-01 دایرکتوری را حذف می‌کند و git worktree prune ورودی‌هایی را پاک می‌کند که دایرکتوری آن‌ها دیگر وجود ندارد. از این مرحله به بعد، حلقه‌های موازی ایمن می‌شوند، زیرا دو agent در دو branch و دو دایرکتوری نمی‌توانند بازنویسی یکدیگر را انجام دهند.

این مرزبندی به اعتبارنامه‌ها نیز مربوط است. حلقه‌ای که بدون نظارت اجرا می‌شود، tokenهای بلندمدت را در اختیار دارد و هر اجرا می‌تواند باعث افشای آن در یک log، یک commit یا context مدل شود. token را فقط به همان repository که حلقه به آن دسترسی دارد محدود کنید. هرجا ممکن است، token را از محیطی که shell خود agent می‌بیند خارج نگه دارید. سپس پیش از اعطای دسترسی production به حلقه، روش خارج نگه داشتن اسرار از agentهای هوش مصنوعی را مطالعه کنید. برای ایجاد مرزی سخت‌تر، کل حلقه را روی یک VM موقتی که پس از هر اجرا می‌توانید نابود کنید قرار دهید.

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

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

#!/usr/bin/env bash
set -euo pipefail

repo=/srv/agent/repo
branch="loop/$(date -u +%Y%m%dT%H%M%SZ)"
tree="/srv/agent/work/$(basename "$branch")"

cd "$repo"
git fetch --quiet origin
git worktree add -b "$branch" "$tree" origin/main
cd "$tree"

# the agent's own command runs here, in non-interactive mode

if ! npm test; then
  echo "gate failed: discarding $branch" >&2
  cd "$repo"
  git worktree remove --force "$tree"
  exit 1
fi

git push origin "$branch"
cd "$repo"
git worktree remove "$tree"

set -euo pipefail در آن اسکریپت کار واقعی انجام می‌دهد. بدون -e، خطای git fetch نادیده گرفته می‌شود و اجرا با origin/main قدیمی ادامه پیدا می‌کند. بدون -u، اشتباه تایپی در نام متغیر به یک رشته خالی گسترش می‌یابد و عملیات پاک‌سازی به‌جای اینکه با خطای آشکار متوقف شود، روی مسیر نادرست اجرا می‌شود.

بلوک if ! npm test تمام ایده را در بر می‌گیرد. کد خروجی یک بررسی قابل‌اعتماد، مانند مجموعه‌آزمون یا بررسی‌کننده نوع، تعیین می‌کند که شاخه ارسال شود یا از بین برود. حلقه‌ای که دروازه ندارد، کاری تولید می‌کند که هیچ‌کس زمان بازبینی آن را ندارد؛ این وضعیت از انجام ندادن کار هم بدتر است. حلقه‌ای که دروازه دارد، شاخه‌ای تولید می‌کند که از همان معیارهایی عبور کرده است که شاخه یک مشارکت‌کننده انسانی باید رعایت کند.

دروازه‌ای انتخاب کنید که صادقانه شکست بخورد. مجموعه‌آزمونی که روی یک diff خالی موفق می‌شود، به حلقه می‌آموزد که انجام ندادن کار موفقیت محسوب می‌شود. مخزن‌هایی با آزمون‌های ضعیف، حلقه‌های ضعیف ایجاد می‌کنند؛ به همین دلیل مخزن‌های پرطرف‌دار، «آماده‌سازی codebase برای agent» را پیش از «نوشتن حلقه» قرار می‌دهند.

بودجه: چه چیزی اجرای برنامه را متوقف می‌کند

عاملی که بی‌نهایت تلاش مجدد می‌کند، هزینه‌ای بدون سقف ایجاد می‌کند. برای هر حلقه، یک سقف زمانی واقعی تعیین کنید که توسط TimeoutStartSec در بخش بالاتر اعمال شود؛ داخل اسکریپت خود تعداد تلاش‌های مجدد را محدود کنید؛ و سقف هزینه را از طریق حساب ارائه‌دهنده اعمال کنید. سپس هزینه هر اجرا را ثبت کنید تا پیش از صدور صورت‌حساب، انحراف هزینه حلقه را شناسایی کنید. کنترل هزینه برای VPS عامل همیشه‌فعال جنبه حسابداری را پوشش می‌دهد و مدیریت contextای که عامل بین نوبت‌ها نگه می‌دارد بزرگ‌ترین اهرم منفرد برای کاهش هزینه هر اجرا را توضیح می‌دهد؛ زیرا حلقه‌ای که هر 30 دقیقه همان repository را دوباره می‌خواند، هر 30 دقیقه هزینه آن را پرداخت می‌کند.

هزینه یکی از دلایلی است که حلقه‌ها معمولاً از یک session طولانی بهتر هستند. اجرایی که از ابتدا شروع می‌شود، یک کار محدود را انجام می‌دهد و خارج می‌شود، context خود را کوچک نگه می‌دارد. sessionی که به‌مدت 8 ساعت باز می‌ماند، همه خطاهای قبلی را در تاریخچه خود نگه می‌دارد و در هر نوبت، هزینه کل transcript را پرداخت می‌کند.

مخزن‌های شاخص چه الگوهایی را مدون کرده‌اند

مخزن loop-engineering هفت الگوی production را فهرست می‌کند. بهتر است این الگوها را مانند یک فهرست پیشنهادی بخوانید، نه یک بیانیه. بررسی روزانه. عاملی برای پیگیری pull request که دیدگاه‌های بازبینی را رصد می‌کند و به آن‌ها پاسخ می‌دهد. عامل پاک‌سازی continuous integration که buildهای ناموفق را شناسایی می‌کند. پاک‌سازی وابستگی‌ها. تهیه پیش‌نویس changelog. پاک‌سازی پس از ادغام. بررسی و دسته‌بندی issueها.

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

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

حلقه‌ها کجا شکست می‌خورند

این شکست‌ها خسته‌کننده‌اند و در تیم‌های مختلف تکرار می‌شوند.

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

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

شروع کار بدون اصطلاحات تخصصی

به framework نیاز ندارید. یک سرور کوچک Linux که همیشه روشن باشد، یک مخزن git که مجموعه‌آزمون آن در شرایطی که باید شکست بخورد، واقعاً شکست بخورد، یک systemd timer و یک shell script که درون آن if قرار دارد، یک چرخه کامل ایجاد می‌کنند. بیشتر افراد واقعاً باید از همین‌جا شروع کنند، زیرا پاسخ پرسش‌های طراحی با اجرای سیستم به دست می‌آید، نه با انتخاب یک ابزار. پس از پایدار شدن یک چرخه، اجرای چرخه دوم عمدتاً به یک timer دیگر و یک worktree دیگر نیاز دارد. برای راه‌اندازی پایه، به نحوه اجرای یک عامل هوش مصنوعی کدنویسی روی VPS مراجعه کنید و اگر می‌خواهید خود عامل روی سخت‌افزاری اجرا شود که آن را کنترل می‌کنید، گزینه‌های فعلی عامل هوش مصنوعی خودمیزبان را ببینید.

FAQ

آیا مهندسی حلقه با مهندسی prompt تفاوت دارد؟

مهندسی prompt یک پیام را بهینه می‌کند: عبارت‌بندی، مثال‌ها و قالب خروجی. مهندسی حلقه چرخه پیرامون پیام را بهینه می‌کند: محرکی که اجرا را آغاز می‌کند، sandboxی که اجرا در آن انجام می‌شود، بررسی‌ای که خروجی را می‌پذیرد یا رد می‌کند، و بودجه‌ای که اجرا را پایان می‌دهد. همچنان به یک prompt مناسب درون حلقه نیاز دارید. prompt دیگر چیزی نیست که هر روز تنظیم می‌کنید، زیرا gate و trigger تأثیر بیشتری بر نتیجه دارند.

آیا برای ساختن یک حلقه agent به framework نیاز دارم؟

خیر. یک timer در systemd، یک git worktree برای هر اجرا، یک shell script که با یک دستور test پایان می‌یابد، و یک سقف هزینه در حساب provider، همه بخش‌های این تعریف را پوشش می‌دهند. Frameworkها رابط‌های زمان‌بندی، قالب‌های حافظه مشترک و مسیریابی چند agent را اضافه می‌کنند. این قابلیت‌ها زمانی مفید هستند که چند حلقه را اجرا کنید. اما برای شروع نخستین حلقه، الزامی نیستند.

codebase harness چیست؟

مجموعه قابلیت‌هایی است که به یک agent اجازه می‌دهد بدون حضور انسان در یک repository کار کند: راه‌اندازی با یک دستور، testهایی که به‌صورت غیرتعاملی اجرا می‌شوند و خطا را به‌وضوح اعلام می‌کنند، یک linter، و روشی برای deploy یا preview کردن تغییر. این اصطلاح از همان موج repositoryها در سال 2026 پدید آمد که مهندسی حلقه نیز از آن شکل گرفت. آزمون عملی ساده است: اگر یک مشارکت‌کننده انسانی جدید نتواند با یک دستور از clone کردن تا اجرای testهای موفق پیش برود، agent نیز نمی‌تواند.

چگونه مانع شَدن هزینه زیاد توسط یک حلقه agent شوم؟

در 3 محل برای آن سقف تعیین کنید. TimeoutStartSec را روی واحد systemd تنظیم کنید تا اجرای متوقف‌شده پس از یک زمان مشخص پایان یابد. تعداد retryها را داخل script محدود کنید، نه اینکه تا موفقیت به حلقه ادامه دهید. یک محدودیت سخت برای هزینه در حساب API تعیین کنید، زیرا این تنها سقفی است که agent نمی‌تواند با استدلال از آن عبور کند. سپس هزینه هر اجرا را log کنید، زیرا حلقه‌ای که هزینه‌اش 2 برابر می‌شود، معمولاً حلقه‌ای است که دامنه کارش بی‌سروصدا گسترش یافته است.

ابتدا کدام کارها ارزش تبدیل شدن به حلقه را دارند؟

کاری را انتخاب کنید که شرط قبولی آن برای ماشین قابل خواندن باشد و دامنه پیامد محدودی داشته باشد. رفع یک build ناموفق، به‌روزرسانی یک dependency و تولید دوباره changelog همگی مناسب هستند، زیرا یک test suite یا diff می‌تواند نتیجه را اثبات کند. کارهای باز مانند refactoring یا طراحی هنوز مناسب نیستند، زیرا چیزی برای بررسی gate وجود ندارد و حلقه‌ای بدون gate روشی پرهزینه برای تولید بدهی بازبینی است.