تصور کنید برنامهنویسی هستید و دیگر نمیتوانید به کلمه «COMPLETE» در پاسخ یک مدل زبانی اعتماد کنید تا بفهمید کد واقعاً کار میکند یا نه. Loop Engine — یک ابزار خط فرمان (CLI) متنباز نوشتهشده با زبان Rust — این مشکل را با تحمیل یک گردشکار مهندسی سختگیرانه حل میکند که در آن کد تولیدشده توسط هوش مصنوعی باید حتماً در مخزن نوشته، کامپایل و تأیید شود.
بیشتر ابزارهای کدنویسی فعلی پس از مرحله تولید متوقف میشوند و کارهای خستهکننده ادغام و تست را به دوش انسان میاندازند. این شکاف باعث ایجاد مشکلی به نام «مایل آخر» میشود؛ جایی که کد در ظاهر درست است اما در محیط واقعی شکست میخورد. Loop Engine با تغییر نگاه به هوش مصنوعی، آن را نه به عنوان یک نویسنده، بلکه به عنوان یک عامل (Agent) — شبیه به کارمندی که دسترسی به ابزارهای شرکت دارد و تا نتیجه نگیرد تسلیم نمیشود — در یک سیستم حلقه-بسته مدیریت میکند. این رویکرد پاسخی به چالشهای بنیادین در مقیاسپذیری است، چرا که بسیاری از عاملهای هوش مصنوعی بدون معماری حلقوی در ابعاد بزرگ با شکست مواجه میشوند.
همانطور که در تحلیلهای قبلی ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، کنترل دقیق روی دسترسیهای مدل برای جلوگیری از خطاهای سیستمی حیاتی است. در این راستا، طبق مستندات فنی این پروژه، موتور اجرایی بر اساس یک چرخه پنجمرحلهای عمل میکند: برنامهریزی $\rightarrow$ ویرایش $\rightarrow$ تأیید $\rightarrow$ بازبینی $\rightarrow$ بازاندیشی. این فرآیند تضمین میکند هیچ تغییری بدون شواهد تجربی از موفقیت، نهایی نشود.
جزئیات این گردشکار به شرح زیر است:
- برنامهریزی (Planning): عامل ابتدا مخزن هدف را بازرسی کرده و یک استراتژی دقیق برای پیادهسازی ایجاد میکند.
- پیادهسازی (Implementation): مدل با استفاده از مجموعهای از ابزارهای محدودشده، فایلها را میخواند و تغییر میدهد.
- تأیید (Verification): موتور دستورات ساخت (Build) و تست محلی را اجرا میکند تا اطمینان حاصل شود که کد در عمل کار میکند.
- بازبینی (Review): یک مدل مجزا، تغییرات واقعی اعمالشده و خروجی تستها را بررسی میکند. این مرحله یادآور تفاوتهای ساختاری میان بررسی Diff و مدیریت جلسات کامل برای جلوگیری از انحراف هدف AI است.
- بازاندیشی (Reflection): سیستم شکستها را تحلیل کرده و حلقه را تا زمان برآورده شدن تمام قوانین تکمیل تکرار میکند.
به نقل از توسعهدهنده، این حلقه تنها زمانی گزارش تکمیل میدهد که مجموعهای خاص از شرایط سختگیرانه برقرار باشد. ادعای عامل مبنی بر اتمام کار کافی نیست؛ بلکه الزامات زیر باید محقق شوند:
- مخزن باید حاوی تغییرات واقعی در فایلها باشد.
- عامل پیادهساز باید صراحتاً اعلام کند که کار را به پایان رسانده است.
- هیچ خطای ابزاری (Tool Error) بدون حل باقی نمانده باشد.
- هر دستور تأیید (Verification Command) که پیکربندی شده است، باید با موفقیت پاس شود.
- مدل بازبین باید پیادهسازی را تأیید کند.
- مدل بازاندیشی باید موافقت کند که هدف نهایی محقق شده است.
انتخاب زبان Rust برای هسته این موتور، پیشبینیپذیری لازم برای عملیات سیستم فایل را فراهم کرده است. توسعهدهنده از تایپهای قوی Rust برای مدیریت وضعیت حلقه و اقدامات ابزاری، مدیریت خطاهای صریح و اعتبارسنجی امن مسیرها استفاده کرده است. همچنین، پشتیبانی قوی Rust از عملیات ناهمگام (Asynchronous) برای درخواستهای HTTP و اجرای زیرفرآیندها (Subprocess)، اجازه میدهد این ابزار به صورت یک فایل باینری واحد و قابل نصب توزیع شود.
برای جلوگیری از بازنویسی ناگهانی تغییرات انسانی توسط AI، Loop Engine از مکانیزم «همروندی خوشبینانه» (Optimistic Concurrency) استفاده میکند. سیستم ابتدا فایل را میخواند و درست پیش از نوشتن، تأیید میکند که نسخه فایل هنوز با آخرین نسخه خواندهشده توسط عامل یکی است. این رویکرد از مشکل «بهروزرسانیهای گمشده» (Lost Update) که در بسیاری از عوامل خودمختار رایج است، جلوگیری میکند.
این ابزار از طریق OpenRouter با مدلهای مختلف یکپارچه میشود و کاربران میتوانند در فایل loop-engine.json برای هر مرحله مدل متفاوتی تعیین کنند. برای مثال، یک کاربر ممکن است از GPT-5.1-Codex برای پیادهسازی و از GPT-4.1-mini برای برنامهریزی، بازبینی و بازاندیشی استفاده کند.
برای کسانی که به دنبال آزمایشهای رایگان هستند، این موتور از مدلهایی مانند Qwen3-Coder:free پشتیبانی میکند. با این حال، در راهنمای فنی اشاره شده است که مدلهای رایگان محدودیتهای نرخ درخواست (Rate Limit) سختگیرانهتری دارند و ممکن است قابلیت اطمینان کمتری داشته باشند. کاربران میتوانند محدودیتهای اجرا را پیکربندی کنند؛ مثلاً محدودیت max_tool_calls را روی ۳۰ و timeout_seconds را بسته به مرحله درخواست، روی ۱۲۰ یا ۶۰۰ ثانیه تنظیم کنند.
پیش از ارسال محتوای مخزن به مدل، کاربران میتوانند دستور loop-engine --repo "C:\projects\my-app" --inspect را اجرا کنند. این دستور کلیدهای API را بارگذاری نمیکند و هیچ درخواستی به سرور نمیفرستد، بلکه یک اسنپشات محدود ایجاد میکند که موارد زیر را حذف میکند:
- ورودیهای مخفی (Hidden) و پیوندهای نمادین (Symlinks).
- دایرکتوریهای متداول وابستگیها (Dependencies) و خروجیهای تولید شده.
- فایلهای باینری و نامفایلهایی که شبیه به اطلاعات حساس (Credentials) هستند.
با وجود این فیلترها، توسعهدهنده هشدار میدهد که این اسنپشات نمیتواند نبود مقادیر حساس در داخل فایلهای سورس را تضمین کند، بنابراین بازبینی دستی همچنان اهمیت دارد.
امنیت در این سیستم از طریق یک «لیست سفید» (Whitelist) سختگیرانه از دستورات مدیریت میشود. مدل نمیتواند دستورات دلخواه در شل (Shell) ابداع کند و تنها میتواند از طریق پیکربندیهای مورد اعتماد یا قوانین شناسایی ثابت برای سیستمهای ساخت متداول، درخواست تأیید دهد:
- وجود Cargo.toml باعث اجرای
cargo testمیشود. - وجود go.mod باعث اجرای
go test ./...میشود. - وجود package.json باعث اجرای اسکریپتهای تست، Typecheck و Build موجود میشود.
- پیکربندیهای Pytest باعث اجرای
python -m pytestمیشوند.
کاربران میتوانند این بررسیهای شناساییشده را با استفاده از فلگ --inspect-checks پیشنمایش کنند. اگرچه شناسایی خودکار است، اما بررسیهای صریح تعریف شده در فایل JSON اولویت دارند و جایگزین شناسایی خودکار میشوند.
از نظر قابلیت مشاهده (Observability)، هر اجرا یک پوشه .loop-engine در داخل مخزن هدف ایجاد میکند. این دایرکتوری شامل یک فایل run-<id>.jsonl و زیرپوشههایی برای هر تکرار (مثلاً iteration-001/) است. این لاگها موارد زیر را ثبت میکنند:
- شماره تکرار، مرحله و مدل انتخاب شده.
- پرامپتهای سیستمی و کاربر.
- پاسخ، خطا و زمانبندی درخواست.
- نتایج ابزارهای مرتبط با هر پرامپت.
درخواستها پیش از شروع فراخوانی API نوشته میشوند تا اگر ارائهدهنده دچار Timeout شد یا فرآیند متوقف گشت، ورودی برای تشخیص خطا در دسترس باشد. «ژورنال بازیابی» (Recovery Journal) در اینجا بسیار حیاتی است، زیرا محتوای اصلی و جایگزین فایل را پیش از هر عملیات نوشتن ذخیره میکند. این قابلیت یک مسیر دستی برای بازگرداندن تغییرات در صورت شکست اجرا فراهم میکند. از آنجایی که این لاگها حاوی کد منبع هستند، پوشه .loop-engine/ باید از کنترل نسخه (Git) مستثنی شود.
اگر یک اجرا با شکست مواجه شود، موتور یک stop_reason ارائه میدهد. دلایل رایج عبارتند از: verification_failed (شکست تأیید)، tool_budget_exhausted (اتمام بودجه ابزار)، unresolved_tool_error (خطای ابزاری حل نشده)، no_changes (عدم تغییر)، invalid_review_response (پاسخ نامعتبر بازبینی) یا review_requires_changes (بازبینی نیازمند تغییرات است).
نتایج ناقص همچنان شامل لیست فایلهای تغییر یافته، خروجی تأیید، آخرین اسنپشات مخزن و مسیرهای مربوط به لاگهای پرامپت و ژورنال بازیابی است. چون ویرایشها پس از یک اجرای ناقص در مخزن باقی میمانند، توصیه میشود از این ابزار در یک برنچ (Branch) تمیز یا یک کپی موقت (Disposable Checkout) استفاده کنید.
با این حال، این ابزار هنوز در مرحله آزمایشی است و محدودیتهای مهندسی فعلی دارد:
- به جای اعمال پچهای ساختاریافته، محتوای کامل فایل را جایگزین میکند.
- قابلیت حذف یا تغییر نام فایلها را ندارد.
- به طور خودکار اجراهای شکستخورده را باز نمیگرداند یا پرامپتهای متوقف شده را از سر نمیگیرد.
- سیستمهای ساخت را تنها از ریشه (Root) مخزن انتخاب شده شناسایی میکند.
- به رعایت پروتکل اکشنهای JSON توسط مدل وابسته است.
علاوه بر این، فرآیند تأیید با دسترسیهای سیستمعامل کاربر اجرا میشود و نه در یک محیط ایزوله (Sandbox). این بدان معناست که اسکریپتهای ساخت پروژه میتوانند به شبکه، متغیرهای محیطی و هر فایلی که کاربر به آن دسترسی دارد، دسترسی داشته باشند.
این تغییر رویکرد نشان میدهد ارزش واقعی کدنویسی با هوش مصنوعی در پاسخ اولیه نیست، بلکه در حلقه کنترلی پیرامون آن است. با محدود کردن ابزارها و الزام به تأیید مستند، AI از یک ابزار «پیشنهاددهنده» به یک ابزار «تحویلدهنده» تبدیل میشود.
گام بعدی شما
- اگر از زبان Rust استفاده میکنید، مخزن پروژه را از گیتهاب کلون کرده و با دستور
cargo install --path . --lockedآن را نصب کنید. - یک فایل
.envبسازید و کلید API مربوط به OpenRouter را در آن قرار دهید. - فایل
loop-engine.jsonرا برای شروع اجرای اهداف خود پیکربندی کنید. - برای شروع، ابتدا با دستور
--inspectمخزن خود را بررسی کنید تا مطمئن شوید فایلهای حساس به مدل ارسال نمیشوند.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو