مایکروسافت در Visual Studio Code 1.136 قابلیت تازه‌ای به نام Agent Merge را به‌صورت آزمایشی اضافه کرده است؛ قابلیتی که مرحله پایانی یک درخواست ادغام را از مجموعه‌ای از پیگیری‌های دستی به یک چرخه پیوسته برای عامل تبدیل می‌کند. این ویژگی می‌تواند درخواست ادغام مرتبط با یک نشست عامل را زیر نظر بگیرد، از عامل بخواهد بازخوردهای بازبینی را اعمال کند، خطاهای بررسی‌های الزامی را برطرف کند، شاخه را به‌روز کند، تعارض‌های ادغام را حل کند، روندهای CI را دوباره اجرا کند و این کار را تا آماده شدن درخواست برای ادغام ادامه دهد.

این قابلیت همراه با نسخه 1.136 در ۲ سپتامبر ۲۰۲۶ منتشر شد. Agent Merge به‌طور پیش‌فرض غیرفعال است و با تنظیم chat.agentMerge.enabled فعال می‌شود. کاربر همچنین تعیین می‌کند عامل اجازه رسیدگی به کدام نوع مانع را داشته باشد. ادغام خودکار گزینه‌ای جداگانه است و در حالت پیش‌فرض خاموش می‌ماند.

تغییر اصلی، تولید کد بیشتر نیست

عامل‌های برنامه‌نویسی پیش از این هم می‌توانستند کد بنویسند، آزمون اجرا کنند و به نظرهای بازبینی پاسخ دهند. تفاوت Agent Merge در نحوه هدایت فرایند است. در الگوی معمول، هر بار که نظر تازه‌ای ثبت می‌شود یا یکی از بررسی‌ها شکست می‌خورد، توسعه‌دهنده باید دوباره وارد عمل شود و اجرای بعدی عامل را آغاز کند. اکنون خود وضعیت درخواست ادغام می‌تواند باعث شروع مرحله بعدی کار عامل شود.

طبق مستندات مایکروسافت، Agent Merge می‌تواند نظرهای حل‌نشده و درخواست تغییر از سوی بازبین‌ها را پیگیری کند، خطاهای بررسی‌های الزامی CI را برطرف کند، شاخه عقب‌مانده را با شاخه پایه همگام سازد، تعارض‌ها را حل کند و در صورت انتخاب کاربر، پس از رفع موانع درخواست را ادغام کند یا آن را وارد صف ادغام کند.

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

فعال کردن این چرخه، سطح اختیار را هم تغییر می‌دهد

اهمیت فنی ماجرا دقیقاً از همین‌جا شروع می‌شود. مایکروسافت صریحاً هشدار می‌دهد که با فعال شدن Agent Merge، نشست وارد حالت Autopilot با سطح دسترسی Assisted می‌شود. این قابلیت می‌تواند بدون آنکه توسعه‌دهنده هر بار فرمان تازه‌ای صادر کند، اجرای جدید عامل را آغاز کند، شاخه درخواست ادغام را تغییر دهد و همگام کند و مصرف مدل را ادامه دهد.

این اختیارات همچنان به محدودیت‌های مخزن و تنظیمات VS Code وابسته‌اند، اما مرز عملیاتی عوض شده است. تیمی که قبلاً یک وصله تولیدشده توسط عامل را بازبینی می‌کرد، اکنون باید با فرایندی روبه‌رو شود که ممکن است در واکنش به تغییر وضعیت مخزن چندین وصله پیاپی ایجاد کند.

ادغام خودکار نیز پیش‌فرض نیست. مقدار اولیه chat.agentMerge.mergePullRequest برابر never است. کاربر می‌تواند اجازه ادغام خودکار را همیشه فعال کند یا آن را فقط تا زمانی مجاز بداند که عامل در جریان تعمیر، درخواست را تغییر نداده باشد. پیش از ادغام یا ورود به صف ادغام، وضعیت آماده بودن درخواست نیز دوباره بررسی می‌شود.

سبز شدن CI لازم است، اما تأیید مستقل محسوب نمی‌شود

برداشت مهندسی Aipolix این است که تیم‌ها باید اختیار عامل برای اصلاح کد را از کنترل‌هایی که قابل قبول بودن تغییر را ثابت می‌کنند جدا نگه دارند.

Agent Merge برای این ساخته شده که شاخه را آن‌قدر اصلاح کند تا بررسی‌های الزامی عبور کنند. این کار مفید است، اما نتیجه سبز CI فقط نشان می‌دهد کنترل‌های تعریف‌شده، نسخه نهایی شاخه را پذیرفته‌اند؛ به‌تنهایی ثابت نمی‌کند تغییرات عامل کامل یا درست بوده‌اند. هرچه دامنه نوشتن عامل گسترده‌تر باشد، اهمیت نگه داشتن کنترل‌های حساس بیرون از همان مرز اختیار بیشتر می‌شود.

در عمل می‌توان این جدایی را با شاخه‌های محافظت‌شده، بازبینی اجباری، قواعد CODEOWNERS، اعتبارنامه‌های محدود، حفاظت از پیکربندی CI و تأیید انسانی برای مخزن‌های حساس حفظ کرد. جزئیات در هر سازمان متفاوت است، اما اصل طراحی روشن است: سامانه‌ای که کد را تغییر می‌دهد نباید تنها مرجعی باشد که درباره آماده بودن همان تغییر برای انتشار تصمیم می‌گیرد.

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

نسخه آزمایشی، یک مسیر استقرار قابل اندازه‌گیری می‌دهد

کنترل‌های Agent Merge نسبتاً شفاف طراحی شده‌اند. رسیدگی به نظرهای بازبینی، اصلاح CI و حل تعارض را می‌توان جداگانه فعال یا غیرفعال کرد. ادغام خودکار تصمیم مستقلی است. اگر نشست عامل به شاخه یا درخواست ادغام دیگری منتقل شود، پایش متوقف می‌شود و باید دوباره فعال شود.

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

پرسش اصلی این نیست که Agent Merge چند درخواست ادغام بیشتری را سبز می‌کند. پرسش بهتر این است که آیا سازمان می‌تواند نشان دهد عامل چه اقدام‌هایی انجام داده، کدام کنترل‌ها مستقل باقی مانده‌اند و اختیار ادغام نهایی در دست چه کسی بوده است.

عامل پیوسته به حاکمیت پیوسته نیاز دارد

VS Code 1.136 عامل برنامه‌نویسی را یک گام به نیروی عملیاتی نزدیک‌تر می‌کند؛ عاملی که تا برآورده شدن شرایط پذیرش یک تغییر، همراه آن می‌ماند. این رویکرد می‌تواند بخش زیادی از هماهنگی تکراری درباره نظرهای ساده بازبینی، خطاهای معمول و عقب ماندن شاخه‌ها را از دوش توسعه‌دهندگان بردارد.

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

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

Sources
- https://code.visualstudio.com/updates/v1_136
- https://code.visualstudio.com/docs/agents/run/agents-window
- https://visualstudiomagazine.com/articles/2026/09/02/vs-code-1-136-pushes-agents-deeper-into-the-development-workflow.aspx