Agent Mode ve Cloud Coding Agent

Copilot'a gerçek kodlama işi devretmenin iki yolunu öğrenin. Editörünüzde senkron çalışan yerel agent ile bulutta asenkron çalışan agent'ı tanıyın ve ikisini de güvenli tutan inceleme disiplinini uygulayın.


Bu derste neler öğreneceksiniz?

  • Bir görevi Ask, Plan ve Agent modlarından doğru sırayla geçirin
  • Agent işlemlerini dar kapsamlı onaylayın ve kapsam kaymasını reddedin
  • Ne zaman yerelde, ne zaman cloud coding agent'a devredeceğinize karar verin
  • Bir agent sonucunu birleştirmeden önce başarılı, başarısız ya da doğrulanmamış olarak inceleyin
Bu sayfada

Ticket, komut satırı aracına --verbose bayrağı eklenmesini istiyor. Değişikliği kendiniz yapabilirsiniz. İsterseniz görevi Copilot'a verip argüman parser'ını incelemesini, düzenleme önermesini, testleri çalıştırmasını ve onayınıza bir diff sunmasını da sağlayabilirsiniz.

Agentic kodlamada iki çalışma biçimi var. Yerel agent yanınızda çalışır, uzaktaki agent ise daha sonra bir branch ile döner. İkisi de zaman kazandırabilir ve ticket'ın izin verdiğinden fazlasına dokunabilir. Çalıştırma sonrasında inceleyebileceğiniz diff'i, test çıktısını ve olgusal iddiaların kaynağını elinizde tutun.

Agent mode sınırlı bir döngüyle çalışır

Yerel agent mode, chat'i gözetimli bir kontrol döngüsüne çevirir. Hedefi ve sınırlarını belirtirsiniz. Agent ilgili dosyaları inceler, bir işlem önerir veya araç kullanmak ister. Siz işlemi onaylar, reddeder veya düzeltirsiniz. Ardından ortaya çıkan sonucu incelersiniz. Agent'ın açıklaması kanıt değildir. Kanıt, okunan dosyalar, oluşan diff ve gerçek test çıktısıdır.

VS Code bu döngüye üç başlangıç modu verir ve bunlar aynı görevin üç aşamasına karşılık gelir. Ask, tanımak içindir: hiçbir şeyi değiştirmeden kodu açıklamak ve repository içinde yolunuzu bulmak. Plan, istenen bir sonucu incelenebilir bir uygulama taslağına çevirir. Agent, uygulamayı bir dizi araç çağrısıyla yürütür. Denetimli bir workflow genellikle Ask ile başlar, Plan'a geçer ve ancak önerilen kapsamı inceledikten sonra Agent'a girer.

Agent mode dosya okuyabilir, dosya düzenleyebilir ve terminal komutu çalıştırabilir. GitHub rehberinde read_file, edit_file ve run_in_terminal gibi örnek araçlar yer alır. MCP ise bu araç setini harici sistemlerle genişletebilir. MCP'yi modülün ilerleyen derslerinde ele alacaksınız. Araç adları ve ekrandaki görünümleri sürümler arasında değişebilir. Etikete değil, istenen işleme bakın. Tek kaynak dosyasını okumak ile dosya silmek, migration çalıştırmak veya yayımlamak aynı risk düzeyinde değildir.

İstek belirsizken Agent ile başlamak kapsamın tahmin edilmesine ve erken düzenlemelere yol açar. Ask önce repository kanıtını gösterir. Plan ise dosyalar değişmeden önce yapılacak işi sabitler. Bu iki adım, uygulama aşamasını incelenebilir hale getirir.

Agent'tan önce Ask'i kullanın

Bir istek biraz bile belirsizse Agent yerine Ask kullanın. "Testleri hangi dosyalar çalıştırıyor, bu değişiklik nereye dokunuyor?" sorusuyla yapılan bir dakikalık salt okunur inceleme, tahmini incelenebilir plana çevirir ve fazla hevesli bir agent'ın yanlış dosyalarda yaptığı düzenlemeleri çözmekten çok daha ucuza gelir.

Bir şeye dokunmadan önce tanıyın· github-copilot
Zayıf örnek

Test komutunu ve bu değişiklikle ilgili dosyaları bul.

İyi örnek

Bu repository'yi dosyaları düzenlemeden veya komut çalıştırmadan incele. Mevcut testleri çalıştıran komutu ve onu tanımlayan dosyayı, yapmak üzere olduğum değişiklikle ilgili kaynak dosyaları ve bulduğun her belirsizlik. Yalnızca geçerli çalışma alanında görünen kanıtları kullan.

Bu prompt neden daha iyi? Test komutunu, ilgili dosyaları ve açık kalan noktaları içeren kısa bir repository haritası elde edersiniz. Agent'ın düzenleme yapmasına izin vermeden önce bu bilgileri gerçek dosyalarla karşılaştırabilirsiniz.

Onaylarla çalışma sınırını görünür tutun

Onay, önerilen tek bir işleme yetki verir. Kabul etmeden önce işlemi, dosya yolunu veya çalışma dizinini, komutu bütün argümanlarıyla ve bu adımın görevdeki yerini okuyun. Silme, üzerine yazma, yayımlama veya bilgi açığa çıkarma ihtimalini kontrol edin. Anladığınız en küçük eylemi onaylayın. Mevcut işin dışına taşan adımı reddedin ya da düzelttirin.

Sonucu yine incelemeniz gerekir. Planlar da izin belgesi değil, inceleme çıktısıdır. Kullanışlı bir plan dosyaları, korunacak davranışı, çalışma sırasını, doğrulama komutlarını ve açık soruları gösterir. Var olmayan dosya uyduruyorsa, ilgisiz refactor ekliyorsa, doğrulamayı atlıyorsa veya varsayımı olgu gibi sunuyorsa geri gönderin. Kabul edilen plan geçerli çalışma sınırını belirler. Bu sınırın dışındaki iş için yeni açıklama gerekir.

Subagent ve bellek için de aynı dikkat geçerlidir. Subagent, "Bu parser'ın kapsamadığı sınır durumlarını listele" gibi dar ve salt okunur bir soruyu alabilir. Yanıtı yine gerçek kodla kontrol edeceğiniz bulgular kümesidir. Bellek, test komutu gibi tekrar kullanılan bağlamı tutabilir, ancak repository değişir. Hatırlanan ayrıntıları kullanmadan önce doğrulayın. Kalıcı kuralları ekibin inceleyebileceği repository talimat dosyalarında saklayın.

Kapsam kayması durma işaretidir. Agent kabul edilen planın dışına çıkarsa devam etmeden önce her dosya için gerekçe isteyin. Akıcı bir özet kolay üretilir. Kod ve kontroller daha güçlü kanıttır.

Plan incelenecek bir çıktıdır, yeşil ışık değil

Herhangi bir uygulamayı onaylamadan önce planı okuyun ve her dosyasını gerçek repository ile karşılaştırın. Var olmayan bir dosya adı veriyorsa, istenmeyen bir refactor ekliyorsa ya da doğrulama adımını atlıyorsa geri gönderin. Kabul ettiğiniz plan, agent'ı bağlı tutacağınız kapsam olur.

Bir isteği incelenebilir bir plana çevirin· github-copilot
Zayıf örnek

CLI'a --verbose seçeneği eklemek için bir plan hazırla.

İyi örnek

Mevcut CLI'a bir --verbose seçeneği eklemek için küçük bir değişiklik planla. Önce mevcut argüman parser'ını ve testleri incele. Dosyaları düzenleme veya komut çalıştırma. --verbose yokken varsayılan davranışı koru. Şunları döndür: değişecek dosyalar, önerilen davranış, geçersiz argüman durumu dâhil test durumları, doğrulama komutları ve varsayımlar.

Bu prompt neden daha iyi? Tek satır değişmeden önce kabul veya reddedebileceğiniz bir ön çalışma taslağı elde edersiniz. Dosyalar, korunacak varsayılan davranış ve testler açıkça belirtilir.

Yalnızca onaylanan planı uygula· github-copilot
Zayıf örnek

--verbose seçeneğini uygula ve çalıştığından emin ol.

İyi örnek

Yalnızca onaylanan --verbose değişikliğini uygula. Her işlemden önce ne yapmak üzere olduğunu, ilgili dosyayı veya komutu ve bunun planı nasıl desteklediğini belirt. İlgisiz dosyaları değiştirme, dosya silme, commit ve push etme. Değiştirilen dosyalar, eklenen davranış, eklenen testler ve doğrulanmayan noktaların özetinden sonra dur.

Bu prompt neden daha iyi? Her okuma, düzenleme ve komutun onayınıza sunulduğu bir uygulama ile diff üzerinden kontrol edeceğiniz kapanış özeti elde edersiniz.

Ne zaman bunun yerine buluta devretmelisiniz?

Yerel agent mode sizi gerçek zamanlı olarak döngüde tutar. Cloud coding agent ise görevi GitHub Actions destekli bir ortamda yürütür ve değişiklikleri copilot/* branch'i ile pull request olarak gönderir. Bir oturumun kesin sınırı 59 dakikadır. Bu nedenle iş tek oturuma sığmalıdır. Akışı issue sözleşmesi, bulutta yürütme, copilot/* branch'i, pull request ve bağımsız insan incelemesi olarak düşünün. Pull request bir öneridir, kanıt değildir.

İkisi arasında işin biçimine göre seçim yapın. Görev commit edilmemiş dosyalara, yerel kimlik bilgilerine, bir masaüstü aracına ya da hızlı gidip gelen kararlara bağlıysa yerel agent mode'a uzanın. Görev kararlı bir repository sözleşmesi olarak yazılabiliyorsa, sıradan proje komutlarıyla doğrulanabiliyorsa ve her tuş vuruşunu denetlemektense bitmiş bir branch'i incelemeyi tercih ediyorsanız cloud agent'a uzanın.

Cloud agent için issue'nun kendisi sözleşmedir. "API'yi düzelt" gibi belirsiz bir issue, hedefin ve bitmişlik ölçütünün tahmin edilmesine yol açar. Devretmeye hazır issue altı soruyu yanıtlar: hangi tek sonuç isteniyor, hangi repository bağlamı gerekli, hangi gözlemlenebilir koşullar başarıyı tanımlıyor, hangi komutlar sonucu doğruluyor, ne değişmeden kalmalı ve pull request hangi kanıtı bildirmeli? Bulut ortamı dizüstünüzden ayrıdır. Önbellekleriniz, config'iniz, gizli bilgileriniz veya araç sürümleriniz orada bulunmayabilir. Gerçek kurulum ve doğrulama komutlarını belirtin. Gerekli ortam değişkenlerinin yalnızca adlarını yazın. Kullanılamayan altyapı nedeniyle çalışmayan kontrolü başarılı değil doğrulanmamış olarak kaydedin.

Birçok görevin paylaştığı kalıcı rehberlik AGENTS.md dosyasına aittir. Coding agent bu repository talimat dosyasını destekler ve GitHub bu desteği 28 Ağustos 2025'te eklemiştir. Göreve özgü gereksinimleri issue içinde tutun. Cloud agent, Copilot Business ve Enterprise planlarına dahildir. Uygulamalı GitHub Skills laboratuvarı ise özellikle Copilot Pro+ ister. Plan yapmadan önce hesabınızın ve kuruluşunuzun sunduğu erişimi kontrol edin.

Cloud agent'ın bitirebileceği bir issue yazın· github-copilot
Zayıf örnek

GET /health uç noktası eklemek için bir issue yaz ve cloud agent'ın tamamlamasını sağla.

İyi örnek

Hedef: mevcut routing kurallarını izleyerek src/server altındaki mevcut API'ye salt okunur bir GET /health uç noktası ekle. Kabul ölçütleri: HTTP 200 ve {"status":"ok"} JSON gövdesi döndürsün. Onu kapsayan odaklanmış bir test olsun. Mevcut testler hâlâ geçsin. Doğrulama: repository'nin belgelenmiş komutuyla kur, önce odaklanmış testi, sonra tüm paketi çalıştır. Kısıtlamalar: kimlik doğrulamayı değiştirme, bağımlılık ekleme veya dağıtım dosyalarına dokunma. Tamamlama raporu: değiştirilen her dosyayı listele ve her komutu başarılı, başarısız ya da doğrulanmamış olarak bildir.

Bu prompt neden daha iyi? Tek bir sonuca göre sınırlanmış copilot/* branch'i ve pull request elde edersiniz. Tamamlama raporunu her ölçüte göre denetleyebilirsiniz.

Agent'ın geri gönderdiğini nasıl incelersiniz?

Değişiklikler yerel diff veya cloud pull request olarak gelebilir. İnceleme iki durumda da her kabul ölçütünü başarılı, başarısız veya doğrulanmamış olarak sınıflandırmaya dayanır. Başarılı, doğrudan kanıtın ölçütü karşıladığını gösterir. Başarısız, kanıtın ölçütle çeliştiğini gösterir. Doğrulanmamış ise mevcut kanıtın iki sonucu da belirleyemediği anlamına gelir. Odaklı endpoint testi geçebilir, ancak veritabanı yapılandırması olmadığı için tüm test paketi doğrulanmamış kalabilir. Doğrulanmamış başarısız demek değildir, fakat başarılı da değildir. Böyle bir kontrol "Tüm testler geçti" iddiasını desteklemez.

Sonucu üzerinde düşünerek işleyin. Önce tamamlama raporunu veya özeti okuyun, sonra değiştirilen her dosyayı okuyun, ardından bu değiştirilmiş dosya kümesini görevin izin verdiği kapsamla karşılaştırın. Agent'ın bildirdiği sonuca güvenmek yerine en dar kapsamlı ilgili doğrulamayı, güvendiğiniz bir ortamda kendiniz çalıştırın. Ancak diff, kanıt ve repository ilkesi hizaya girdikten sonra birleştirirsiniz.

Bir cloud agent'ın temiz bir GET /health endpoint'i eklediğini ve odaklı testin geçtiğini düşünün. Değişen dosyalar arasında, issue açıkça yasakladığı halde rota için kimlik doğrulamayı atlayan auth.js düzenlemesi de vardır. Odaklı davranış başarılıdır. Test veritabanı yapılandırılmadığı için tüm paket doğrulanmamıştır. Kimlik doğrulama değişikliği ise doğrudan kısıt ihlalidir. Doğru karar değişiklik istemek ve düzeltilmiş commit üzerinde doğrulamayı yeniden çalıştırmaktır. Normal akış testi geçti diye merge etmeyin.

Tamamlanmış çalıştırma, açılmış pull request veya kendinden emin özet sizin inceleyeceğiniz çıktıdır. Karar değildir. İşi agent'a devretseniz de merge kararını ve bu kararı destekleyen kanıtı siz yönetirsiniz. Aynı döngüyü CLI, Özel Talimatlar ve Prompt Dosyaları dersinde terminale ve yeniden kullanılabilir kurallara taşıyacaksınız.

Doğrulanmamış, başarılı değildir

Bir kontrol eksik gizli bilgi, kullanılamayan veritabanı veya atlanan kurulum nedeniyle assertion'larına hiç ulaşmadıysa onu başarılı değil, doğrulanmamış olarak kaydedin. Bir komut çalışamamışken "tüm testler geçiyor" diyen bir özet, bozuk bir değişikliğin incelemeden sıyrılmasının en yaygın yoludur. Onu kendiniz yeniden çalıştırın ya da boşluğu etiketleyin.

Şimdi siz deneyin

Sınırları belli tek bir değişikliği Ask, Plan, Agent'tan geçirin

Tek kullanımlık bir repository veya tek fonksiyonla tek test içeren küçük bir çalışma klasörü kullanın. On dakikada bitecek kadar küçük bir değişiklikte tam gözetimli döngüyü uygulayın.

  1. 01

    Güvenle değiştirebileceğiniz bir repository'de önemsiz bir ekleme seçin, örneğin bir listeyi filtreleyen bir yardımcı ya da bir --verbose bayrağı.

  2. 02

    Ask modunda Copilot'a test komutunu ve değişikliğinizin dokunacağı dosyaları adlandırtın. Adlandırdığı her dosyayı açın ve var olduğunu doğrulayın.

    İpucu: Repository'de olmayan bir dosyayı gösteriyorsa, daha ileri gitmeden durun ve düzeltin.

  3. 03

    Plan moduna geçin ve mevcut davranışı koruyan bir plan isteyin. Bir şeyleri yeniden adlandırıyorsa, bağımlılık ekliyorsa ya da değişiklik dışındaki dosyalara dokunuyorsa reddedin.

  4. 04

    Agent modunda her okuma ve düzenlemeyi teker teker onaylayın ve planı aşan her işlemi reddedin.

  5. 05

    Diff'in tamamını inceleyin ve en dar kapsamlı testi kendiniz çalıştırın. Değiştirilen her dosyanın planda yer aldığını doğrulayın.

Planı, diff'i ve test sonucunu kanıt olarak gösterebildiğiniz tamamlanmış bir değişiklik elde edersiniz. Ayrıca reddettiğiniz işlemi açıklayabilirsiniz.

Aklınızda kalsın

  • Tanımak için Ask'i, incelenebilir bir taslak için Plan'i, sınırları belli uygulama için Agent'ı kullanın.
  • Onay tek bir eyleme izin verir. Nihai sonucu doğrulamadığı için diff'i yine de inceleyin.
  • Yerel agent mode editörde senkron çalışır. Cloud agent uzakta çalışır ve copilot/* branch'i ile pull request döndürür.
  • Cloud agent için sözleşme issue'dur. Tek sonuç, gerçek doğrulama komutları ve açık dışlamalar belirtin.
  • Her sonucu başarılı, başarısız ya da doğrulanmamış olarak inceleyin ve doğrulanmamışı asla başarılı saymayın.

Kendinizi test edin

  1. 1. Bildiğiniz bir repository'ye küçük bir özellik eklemeniz gerekiyor ve her adımın incelenebilir kalmasını istiyorsunuz. Hangi sıra en iyi oturur?

  2. 2. Bir görev commit edilmemiş yerel dosyalara bağlı ve hızlı gidip gelen kararlar gerektiriyor. Nereye aittir?

  3. 3. Bir cloud agent pull request'i şunu bildiriyor: odaklanmış endpoint testi geçti, veritabanı yapılandırılmadığı için tüm paket sıfır test çalıştırdı ve issue kimlik doğrulama değişikliklerini yasaklamışken bir kimlik doğrulama dosyası değişti. Kararınız nedir?

  4. 4. Oturum ortasında Copilot, zaten bellekte olan bir diziyi filtrelemek için yeni bir bağımlılık kurmayı ve package.json'ı düzenlemeyi öneriyor. Ne yapmalısınız?

  5. 5. Agent'ın özeti "tüm kontroller geçti" diyor, ama bir komut gereken bir gizli bilgi eksik olduğu için assertion'larına ulaşamadı. Bu kontrolü nasıl kaydetmelisiniz?

Sık sorulan sorular

Cloud coding agent'ı hangi Copilot planı içerir?

Cloud agent, Copilot Business ve Enterprise'a dâhildir ve Enterprise, Business özelliklerini kapsar. Uygulamalı GitHub Skills cloud agent laboratuvarı ise özellikle Copilot Pro+ ister. Planlar ve kapsamları farklıdır. Bu nedenle her planın aynı erişime sahip olduğunu varsaymak yerine kendi hesabınızın ya da kuruluşunuzun neyi sağladığını kontrol edin.

Bir agent kullanmak için editörümden çıkmam gerekir mi?

Hayır. Yerel agent mode doğrudan VS Code'un içinde çalışır ve yanınızda senkron olarak iş görür. Uzaktan çalışıp bir branch ile pull request döndüren, cloud agent'tır. İş commit edilmemiş dosyalara bağlıysa ya da hızlı gidip gelme gerektiriyorsa yerel modu kullanın.

Kuruluşum cloud agent'ı etkinleştirmediyse ne olur?

Bir kuruluşta devretme kullanılabilir olmadan önce bir yöneticinin agentic özellikleri etkinleştirmesi gerekebilir. Yine de tek kullanımlık bir repository'de yerelde pratik yapabilir ya da tam issue'dan pull request'e akışını görmek için rehberli GitHub Skills cloud agent alıştırmasını izleyebilirsiniz.

Yeşil bir pull request birleştirmek için yeterli mi?

Hayır. Tamamlanmış bir pull request bir öneridir, kanıt değil. Diff'i inceleyin, değiştirilen dosyaları izin verilen kapsamla karşılaştırın, en dar kapsamlı doğrulamayı kendiniz çalıştırın ve birleştirmeden önce her kabul ölçütünü başarılı, başarısız ya da doğrulanmamış olarak sınıflandırın.

Bu dersteki terimler

agent mode
Birden çok adımda plan yapabilen, dosya okuyup düzenleyebilen ve komut çalıştırabilen, her işlemde onayınız için duraklayan bir Copilot modu.
cloud coding agent
Devredilen bir görevi GitHub'da barındırılan bir ortamda yürüten ve değişikliklerini bir copilot/* branch'i ile pull request üzerinde döndüren otonom bir Copilot agent'ı.
onay
Önerilen bir agent işlemine çalışmadan önce izin verme kararıdır. Eyleme yetki verir ama sonucunu belgelemez.
doğrulanmamış
Kanıtı başarılı ya da başarısızı belirleyemeyen bir kontrolün inceleme sonucudur. "Başarısız"dan farklıdır ve ona eşdeğer değildir.
pull request
Bir branch üzerindeki, başka bir branch'e birleştirilmeden önce inceleme için sunulan önerilmiş değişiklikler kümesi.

Daha fazla kaynak