AI Coding Agent چگونه کار می‌کند؟

بعد از اینکه فهمیدید Agent با Chatbot فرق دارد، سؤال بعدی این است: وقتی در IDE یا روی GitHub به یک Coding Agent کار می‌سپارید، پشت صحنه چه اتفاقی می‌افتد؟ بدون این تصویر، یا بیش از حد اعتماد می‌کنید یا از قابلیت‌های مفیدش استفاده نمی‌کنید.

مستندات Cursor می‌گوید عامل از سه جزء ساخته می‌شود: دستورالعمل و قواعد، ابزارها، و مدل. Anthropic در Agent SDK همان حلقهٔ برنامه‌ریزی و فراخوانی ابزار را به‌صورت کتابخانه می‌دهد. GitHub Copilot cloud agent در محیط ابری مبتنی بر Actions مخزن را بررسی می‌کند، برنامه می‌ریزد، تغییر می‌دهد و اغلب با تست و لینتر اعتبارسنجی می‌کند.

این مقاله حلقهٔ مشترک را بدون وابستگی به یک برند توضیح می‌دهد، بعد تفاوت‌های محصول را مختصر می‌گوید، و در پایان محدودیت‌های واقعی را متعادل می‌آورد — نه ترس بی‌مورد، نه وعدهٔ جادو.

پاسخ کوتاه

AI Coding Agent معمولاً در یک حلقه کار می‌کند: زمینه را از مخزن و دستور شما جمع می‌کند، برنامه‌ای برای تغییر می‌چیند، فایل‌ها را ویرایش می‌کند، تست یا lint را اجرا می‌کند، خروجی را مشاهده می‌کند و یا تمام می‌کند یا اصلاح بعدی را شروع می‌کند. انسان با قواعد، محدودهٔ هدف، بازبینی Diff و تأیید فرمان‌ها کنترل را نگه می‌دارد. Agent جایگزین مالکیت کد نیست؛ یک حلقهٔ ابزاردار برای کارهای چندمرحله‌ای است.

حلقه را بفهمید تا بدانید کجا باید بایستید و کجا بگذارید ادامه دهد.

حلقهٔ اصلی: context → plan → edit → run → observe

۱) Context: آگاهی از مخزن و درخواست

Agent قبل از نوشتن کد باید بداند کجاست. ابزارهای جست‌وجوی فایل، خواندن محتوا، ایندکس معنایی مخزن، و گاهی قواعد پروژه همین کار را می‌کنند. Cursor از جست‌وجوی codebase، خواندن فایل و دریافت قواعد حرف می‌زند. بدون زمینهٔ خوب، مدل حدس می‌زند؛ با زمینهٔ بیش از حد نامرتبط، نویز و هزینه بالا می‌رود.

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

۲) Plan: شکستن کار قبل یا حین اجرا

بعضی محصولات حالت برنامهٔ جدا دارند. در مستندات Cursor، Plan Mode ابتدا سؤال شفاف‌ساز می‌پرسد، مخزن را بررسی می‌کند، برنامهٔ قابل‌ویرایش می‌سازد و بعد از تأیید شما اجرا را شروع می‌کند — مناسب فیچرهای چندفایلی یا وقتی رویکرد مبهم است. در Copilot cloud agent هم مسیر پژوهش، برنامهٔ پیاده‌سازی و تغییر کد رسمی است.

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

۳) Edit: اعمال تغییر روی فایل‌ها

ابزار ویرایش پیشنهاد تغییر می‌دهد و آن را روی فایل اعمال می‌کند. Cursor از نقاط بازرسی محلی قبل از تغییرات مهم حرف می‌زند تا بتوانید به وضعیت قبلی فایل‌ها برگردید — جدا از Git. این برگشت سریع برای اکتشاف مفید است؛ برای تاریخچهٔ دائمی همچنان Git معیار است.

ویرایش خوب معمولاً کوچک و هم‌راستا با قرارداد پروژه است. ویرایش بد کل ماژول را بدون درک قیود بازنویسی می‌کند. اینجا نقش قواعد و مثال‌های داخل پرامپت (موضوع مقالهٔ ۱۰۳) دیده می‌شود.

۴) Run: اجرای ابزارهای تأیید

قدرت Coding Agent در اجرای کارهای تأیید است: تست، typecheck، لینتر، بیلد، یا اسکریپت محلی. Cursor اجرای ترمینال را جزو ابزارها می‌آورد. Claude Code و Agent SDK هم ابزار فایل و ترمینال را در حلقه دارند. Copilot cloud agent در محیط Actions می‌تواند با تست‌ها و لینترهای مخزن کار را اعتبارسنجی کند.

اجرای فرمان همان جایی است که تأیید انسان معنا پیدا می‌کند: بعضی کارها کم‌ریسک‌اند مثل تست واحد؛ بعضی پرریسک‌اند مثل تغییر دادهٔ production یا فراخوانی شبکهٔ باز. سیاست تیم باید این مرز را از قبل بکشد.

۵) Observe: خواندن خروجی و تصمیم بعدی

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

ابزارها؛ دست‌های عامل

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

هر ابزاری که اضافه می‌کنید قدرت و ریسک را با هم بالا می‌برد. مقاله‌های ۱۰۰ و ۰۹۹ همین منطق را از زاویهٔ امنیتی باز می‌کنند.

دستورالعمل‌ها و قواعد: نرم‌افزار رفتار

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

اگر قاعده مبهم بنویسید، رفتار مبهم می‌گیرید.

تأیید انسان در حلقه

محصولات جدی چند لایهٔ دخالت انسان دارند: تأیید برنامه قبل از پیاده‌سازی گسترده، تأیید فرمان‌های حساس، بازبینی Diff قبل از پذیرش یا ادغام، نقطهٔ بازرسی برای برگشت سریع، و هدایت نشست وقتی مسیر منحرف می‌شود.

عامل ابری Copilot در پس‌زمینه روی شاخه کار می‌کند و شما را برای بازبینی صدا می‌زند. عامل داخل IDE معمولاً تعاملی‌تر است. مهم این است که ادغام به شاخهٔ اصلی بدون چشم انسان نباشد — هم‌راستا با مقالهٔ ۰۹۸.

تفاوت کوتاه محصولات (بدون رتبه‌بندی مطلق)

Cursor: حلقهٔ محلی قوی با Plan Mode و نقاط بازرسی و امکان عامل ابری. Claude Code و Agent SDK: حلقه قابل برنامه‌نویسی با سامانهٔ مجوز. Copilot cloud agent: واگذاری وظیفه روی شاخه با بازبینی بعدی.

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

محدودیت‌های واقعی — متعادل

زمینهٔ ناقص باعث راه‌حل موضعی می‌شود. تست ضعیف ممکن است باگ را قفل کند. حلقه‌های طولانی هزینهٔ توکن و CI دارند. بدون معیار پذیرش روشن، خروجی فقط شبیه کار می‌شود. مسیرهای امنیتی و داده بدون بازبینی متخصص خطرناکند. مخزن بدون تست، مشاهدهٔ مفیدی به حلقه نمی‌دهد.

این محدودیت‌ها دلیل کنار گذاشتن عامل نیستند؛ دلیل تعریف محدوده و Definition of Done هستند — موضوع مقالهٔ ۱۰۴.

چرا مشاهده قلب حلقه است؟

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

بعد از هر دور ویرایش و اجرا سه چیز را چک کنید: آیا کار درست اجرا شد، آیا خروجی با هدف هم‌خوان است، و آیا تغییر جانبی ناخواسته در Diff هست. اگر مبهم است، دور بعد را تنگ‌تر شروع کنید نه با «ادامه بده».

الگوی کار پیشنهادی برای یک تسک

1. هدف را در یک جمله با معیار پذیرش بنویسید.
2. اگر کار چندفایلی یا مبهم است اول برنامه بگیرید.
3. روی شاخهٔ جدا یا فضای ایزوله کار کنید.
4. بعد از ویرایش و اجرا خودتان Diff و تست را ببینید.
5. اگر منحرف شد مسیر را اصلاح کنید یا به برنامه برگردید.

اشتباه‌های رایج در استفاده از حلقه

• شروع با ساخت کل فیچر بدون برش قابل بازبینی.
• خاموش کردن تأیید در مسیرهای پرریسک.
• ادغام چند موضوع نامرتبط در یک نشست.
• اتکا به نقطهٔ بازرسی به‌جای commit معنادار.
• نادیده گرفتن قواعد تیمی.

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

پیوند با مقالات هم‌خانواده

مقالهٔ ۱۰۱ تعریف عامل در برابر Chatbot را می‌دهد. ۰۹۷ نقشهٔ ابزارهای ۲۰۲۶ است. ۰۹۸ کیفیت را قفل می‌کند. ۱۰۳ پرامپت عملی را آموزش می‌دهد. ۱۰۴ چارچوب تفویض است. ۰۲۷ و ۰۸۱ و ۰۹۹ لایهٔ امنیت و Secret را یادآوری می‌کنند.

جزئیات بیشتر دربارهٔ زمینه و هزینه

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

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

اندازه‌گیری ارزش حلقه

بعد از دو هفته استفاده، این‌ها را مقایسه کنید: نرخ شکست CI روی PRهای تولیدشده با عامل، تعداد برگشت‌ها، زمان متوسط بازبینی Diff، و تعداد نشست‌هایی که بدون معیار پذیرش شروع شده‌اند. اگر فقط «حس سرعت» دارید و متریک ندارید، تصمیم‌گیری روی هوا است.

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

ارتباط با کیفیت و امنیت

حلقهٔ عامل بدون لایهٔ کیفیت مقالهٔ ۰۹۸ و لایهٔ Secret مقالهٔ ۰۹۹ ناقص است. مشاهدهٔ خروجی تست جای بازبینی امنیتی مسیرهای auth و پرداخت را نمی‌گیرد. همچنین vibe coding بدون کنترل — موضوع ۰۲۷ — وقتی با اجرای فرمان ترکیب شود، شعاع انفجار بزرگ‌تر می‌شود.

اگر فقط یک عادت از این مقاله بردارید: بعد از هر دور اجرا، خودتان خروجی را ببینید و Diff را خط‌به‌خط بخوانید؛ خلاصهٔ زبانی مدل را سند نهایی ندانید.

جمع‌بندی برای تصمیم

نمونهٔ سناریوی کامل روی یک باگ

فرض کنید یک تست واحد قرمز است. هدف را می‌نویسید: «این تست را سبز کن بدون تغییر قرارداد عمومی API». عامل زمینه را از فایل تست و پیاده‌سازی می‌خواند، برنامهٔ کوتاهی پیشنهاد می‌دهد، وصله می‌زند، تست را اجرا می‌کند، خروجی را می‌بیند و اگر لازم باشد دور دوم اصلاح می‌کند. شما Diff را می‌خوانید، مطمئن می‌شوید که فقط همان مسیر لمس شده، و Merge می‌کنید.

حالا همان سناریو را بدون معیار پذیرش تصور کنید: عامل ممکن است API را عوض کند تا تست سبز شود، یا تست را سست کند. حلقه از نظر مکانیکی موفق به نظر می‌رسد، اما کیفیت سیستم پایین آمده است. تفاوت در تعریف هدف است نه در قدرت مدل.

چه زمانی اصلاً به حلقهٔ کامل نیاز ندارید؟

برای توضیح یک تابع، پیشنهاد نام متغیر، یا پیش‌نویس پیام کوتاه، چت ساده یا تکمیل‌کننده کافی است. روشن کردن حلقهٔ کامل برای کارهای تک‌گامی فقط اصطکاک و هزینه اضافه می‌کند. مقالهٔ ۱۰۱ همین مرز را از زاویهٔ تعریف مفهومی روشن می‌کند.

برعکس، برای تغییرات چندفایلی با وابستگی به تست و لینتر، حلقهٔ کامل ارزش دارد — به شرط کنترل. اگر تیم هنوز Rules و شاخهٔ محافظت‌شده ندارد، اول همان زیرساخت را بگذارید بعد دامنهٔ عامل را باز کنید.

Coding Agent یک حلقهٔ ابزاردار است نه یک دکمهٔ جادویی. زمینهٔ درست، برنامهٔ قابل‌بازبینی، ویرایش محدود، اجرای کنترل‌شده و مشاهدهٔ صادقانه — با تأیید انسانی — موتور بهره‌وری است. وقتی observe یا review حذف شود، سرعت کاذب می‌خرید.

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

منابع و مراجع

• Cursor Docs — Agent overview — https://cursor.com/docs/agent/overview
• Cursor Help — Agent mode — https://cursor.com/help/ai-features/agent
• Cursor Docs — Plan Mode — https://cursor.com/docs/agent/plan-mode
• Anthropic — Agent SDK overview — https://platform.claude.com/docs/en/agent-sdk/overview
• GitHub Docs — About Copilot cloud agent — https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent

حلقه را در تیم رسم کنید؛ بعد تنظیمات محصول را روی همان نقشه بچینید.