A2A Gateway
Genel Bakış
A2A (Agent2Agent), farklı sağlayıcılara ait AI ajanlarının birbirleriyle standart bir protokol üzerinden görev alışverişi yapmasını sağlayan açık bir protokoldür. Apinizer'da A2A, diğer proxy tipleriyle (REST, SOAP, AI, MCP) aynı seviyede birinci sınıf bir API Proxy tipidir — kendi başına ayrı bir yönetim ekranı veya kimlik doğrulama modeli taşımaz, mevcut API Proxy yaşam döngüsünün (deploy, redeploy, rollback, export/import) tamamını paylaşır.
Önceki sürümlerde bir ajan yayınlamak, kendi CRUD ekranına, tek bir hedef proxy'ye ve kendi kimlik doğrulama moduna (Yok / API Anahtarı) sahip ayrı bir "A2A Inbound Agent" kaydı gerektiriyordu. Bu model tamamen kaldırıldı. Artık ajan yayınlamak, A2A tipinde bir API Proxy oluşturup onun yönlendirme modunu seçmekten ibarettir; kimlik doğrulama da proxy'nin normal politika zincirinden gelir. Ayrıca yeni modelde dış bir A2A ajanına passthrough yapabilme ve birden çok dış ajanı tek proxy arkasında birleştirebilme gibi eski modelde bulunmayan yetenekler eklendi. Ayrıntı için bu sayfanın sonundaki Eski Sürümden Geçiş bölümüne bakın.
Bir A2A Gateway, iki yönlendirme modundan biriyle çalışır:
- Agent Yayınla — proxy, kendi LLM yapılandırmasıyla desteklenen bir A2A ajanı olarak kendini yayınlar
- Passthrough — proxy görevleri dış bir A2A ajanına iletir, yol boyunca skill filtresi ve agent card yeniden yazımı uygular
Menüdeki A2A Gateway girişi, A2A Gateway'lerinizin kart görünümlü listesini açar — AI Gateway'lerle aynı düzen; bir kartı açtığınızda o proxy'nin yönlendirme, politika ve trace/trafik/analitik/görev sekmelerine ulaşırsınız.
Apinizer'ı bunun tersi yönde, yani dış A2A ajanlarına görev gönderen taraf olarak kullanmak için ayrı bir A2A Gateway'e gerek yoktur; bu, herhangi bir AI Gateway'e eklenen A2A Çağrısı (LLM) / A2A Çağrısı (Sabit) politikasıyla yapılır, bkz. Giden Ajan Çağrısı.
A2A protokolü JSON-RPC 2.0 üzerine kuruludur. Apinizer, hem senkron görev gönderimini hem de Sunucu Tarafından Gönderilen Olaylar (SSE) ile akış (streaming) yanıtları destekler.
Hızlı Başlangıç
A2A tipinde bir API Proxy oluşturma akışını başlatın — proxy tipi zaten A2A olarak seçili gelir, bir tip seçim ekranı gösterilmez ve doğrudan minimal bir oluşturma formu açılır. Proxy'ye tek bir istemci relative path'i (örn. /a2a/asistan) atanır — bu tek yol, hem JSON-RPC trafiğini hem de discovery belgesini taşır.
Proxy'nin A2A Routing sekmesinde iki moddan birini seçin: proxy'nin kendi ajanı olarak yayın yapması için Agent Yayınla, dış bir A2A ajanına geçiş yapması için Passthrough. Aşağıdaki Modlar bölümüne bakın.
Agent Yayınla modunda proxy'nin AI Routing sekmesinde bir LLM backend'i tanımlamanız zorunludur — bu ayarlanmadan A2A Routing kaydedilemez. Passthrough modunda arka uç A2A ajanını/ajanlarını satır içi tanımlayın ve gerekiyorsa skill izin listesini daraltın.
Proxy'yi normal bir API Proxy gibi bir ortama deploy edin. Deploy geçmişi, redeploy ve rollback davranışı diğer proxy tipleriyle birebir aynıdır.
Bir A2A istemcisi önce {relativePath}/.well-known/agent-card.json üzerinden ajanı keşfeder, ardından proxy'nin relative path'ine JSON-RPC ile görev gönderir (SendMessage, ...). Discovery belgesi kimlik doğrulamadan muaftır; asıl erişim kontrolü, istek proxy'nin politika zincirinden geçerken uygulanır.
Modlar
Agent Yayınla (Agent Expose)
Proxy kendi Agent Card'ını yayınlar ve görevleri kendi LLM backend'i (AI Routing sekmesindeki yönlendirme) üzerinden işler — başka bir proxy'ye devir (loopback) yoktur. Agent Card ayarlarında açıklama override'ı, girdi/çıktı modaliteleri ve manuel bir skill listesi tanımlanabilir; skill listesi boş bırakılırsa proxy'nin adı ve açıklamasından tek bir varsayılan skill türetilir — kart hiçbir zaman boş/doğrulanmamış yayınlanmaz.
Push bildirimleri bu modda proxy bazında açılıp kapatılabilir; ayrıca cluster-içi (private network) hedeflere push gönderilmesine izin verecek ayrı bir anahtar vardır (bkz. Güvenlik ve Governance).
Passthrough
Proxy'ye gelen her A2A çağrısını, arka uç bir A2A ajanına iletir. Dış ajanın Agent Card'ı, bu proxy'nin kendi adresini ve gerçek kimlik doğrulama şemasını yansıtacak şekilde yeniden yazılarak (hostname + güvenlik şeması rewrite) yayınlanır — istemci hiçbir zaman dış ajanın gerçek adresini görmez. Bir skill izin listesi ile Agent Card'da hangi skill'lerin yayınlanacağı daraltılabilir.
Skill izin listesi (ve aşağıdaki kimlik bazlı erişim listesi) Passthrough modunda yalnızca Agent Card yayınında uygulanır — A2A'nın kablo protokolü, MCP'nin araç çağrısındaki gibi çağrı-anında hangi skill'in hedeflendiğini taşıyan bir alan içermez. Bu nedenle bir görev gönderme çağrısı (SendMessage) çağrı anında skill bazında filtrelenemez: izinsiz bir skill Agent Card'da hiç görünmez, ama o skill adını başka bir yoldan zaten bilen bir çağıran yine de bir görev gönderebilir. Gerçek yetkilendirme bu durumda dış ajanın kendi tarafına kalır.
Passthrough modundaki arka uç A2A ajanı/ajanları, proxy'nin A2A Routing sekmesinde, ayrı bir bağlantı ekranına gitmeden doğrudan tanımlanır:
A2A Routing sekmesinin Passthrough bölümünde Sunucu Ekle ile bir satır açın; ajanın uç nokta adresini, kimlik doğrulama bilgilerini ve gerekiyorsa mTLS ayarlarını aynı satırda girin.
Proxy ilk kez deploy edildiğinde Apinizer, tanımlı ajanın/ajanların Agent Card'ını otomatik getirir; yetenekler ve desteklenen modaliteler doğrulanır.
Gönderilen görevlerin durumunu proxy detayındaki Görevler sekmesinden canlı izleyin.
Arka uç ajan, hedefin gerektirdiği kimlik doğrulama şemasına göre yapılandırılır; OAuth2 client credentials akışı da dahil olmak üzere token gerektiren hedeflere bağlanabilirsiniz — token alımı çalışma zamanında otomatik yapılır.
Passthrough yapılandırması APIops REST API ile de yönetilebilir; bkz. API Referansı: API Proxies — Update A2A Routing.
Arka Uç Ajanı Uygulamak: Listeye Uygula → Kaydet → deploy
Arka uç ajanı, satırın sağından açılan çekmecede eklersiniz veya düzenlersiniz. Çekmecedeki Listeye Uygula düğmesi değişikliği yalnızca tabloya yazar — o adımda sunucuya hiçbir şey gitmez. Kalıcı olması için sekmenin altındaki Kaydet düğmesine basmanız gerekir; kaydedilmemiş değişiklik varken sekmenin üstünde bir uyarı durur ve bu uyarı yalnızca kayıt başarılı olduğunda kalkar. Sıra şudur: Listeye Uygula → Kaydet → deploy. Ortadaki adım atlanırsa tabloda yeni ajan görünür, gateway ise eski yapılandırmayı sunmaya devam eder.
Gateway her zaman en son deploy edilen yapılandırmayı sunar. A2A Routing sekmesini kaydetmek tek başına çağıranların gördüğünü değiştirmez; arka uç ajanlar, yayınlanan skill kataloğu ve yönlendirme modu ancak proxy'yi o ortama yeniden deploy ettiğinizde istemcilere ulaşır. Kaydedilmiş ama deploy edilmemiş değişiklik varken, etkilenen ortamları adlarıyla listeleyen bir uyarı şeridi A2A Routing sekmesinin üstünde görünür.
Giden Ajan Çağrısı
Apinizer üzerinden dış bir A2A ajanına görev göndermek istediğinizde, bu görevi fiilen ileten bileşen A2A Çağrısı (LLM) / A2A Çağrısı (Sabit) politikasıdır (bir AI Gateway'ine eklenir). Hedef ajan, Passthrough modundaki gibi politikanın kendi ekranında satır içi tanımlanır:
Bir AI Gateway'ine A2A Çağrısı (LLM) politikasını ekleyin.
A2A Ajanı (Satır İçi) bölümünde uç nokta adresini, kimlik doğrulama bilgilerini ve gerekiyorsa mTLS ayarlarını girin.
Skill'leri Keşfet butonu ajana bağlanır, Agent Card'ı getirir ve skill listesini doğrular — kaydetmeden önce çalışır, ayrı bir "bağlantıyı test et" adımı yoktur.
Boş bırakılırsa keşfedilen tüm skill'lere izin verilir. Kısıtlamak için İzinli Skill'ler listesinden seçim yapın.
Bu ajan tanımı da Passthrough modundakiyle aynı SSRF korumasına tabidir (bkz. Güvenlik ve Governance). Politika ekranındaki A2A Bağlantısı alanı geriye dönük uyumluluk için korunur: satır içi ajan tanımlıyken devre dışı kalır, çalışma zamanında ikisinden yaln ızca biri kullanılır.
Girdiğiniz uç nokta, görevlerin gönderildiği adrestir. Ajanın Agent Card'ı önce aynı adreste aranır; kart orada yayınlanmıyorsa bu adresin altındaki standart keşif yolunda (.../.well-known/agent-card.json) aranır. Yani ajanın görev uç noktasını girmeniz keşif için yeterlidir; doğrudan kart adresini girmek de eskisi gibi çalışmaya devam eder.
Bu politika da APIops REST API ile eklenip güncellenebilir; bkz. API Referansı: Policies.
Agent Card, Görev Yaşam Döngüsü ve Streaming
Agent Card
Her ajan (Agent Yayınla modunda proxy'nin kendisi, Passthrough modunda yeniden yazılmış dış ajan) .well-known/agent-card.json üzerinden kendini tanıtan bir Agent Card yayınlar:
{
"name": "Asistan Proxy",
"description": "Müşteri destek ajanı",
"version": "1.0",
"capabilities": { "streaming": true, "pushNotifications": true },
"defaultInputModes": ["text", "image", "data"],
"defaultOutputModes": ["text"],
"skills": [
{ "id": "asistan-proxy", "name": "Asistan Proxy", "description": "Müşteri destek ajanı" }
],
"securitySchemes": {
"bearerAuth": { "type": "http", "scheme": "bearer" }
}
}
Kartın securitySchemes alanı kart yalan söylemez ilkesiyle, sabit bir listeden değil, proxy'nin fiilen tanımlı olan auth politikalarından türetilir — hiç auth politikası yoksa alan boş kalır, asla yanlış bir şema ilan edilmez. Agent Card bu sürümde imzasız yayınlanır ve insan-onaylı (human-in-the-loop) görev onayı desteklenmez.
Passthrough modunda yeniden yazılan kartın documentationUrl alanı, arka uç ajanın değil bu proxy'nin gateway üzerindeki tam adresini gösterir — ortamın erişim adresi, Apinizer kök bağlamı ve proxy'nin istemci yolu birlikte — böylece adresi izleyen istemci doğrudan gateway'e ulaşır. Ortamda erişim adresi tanımlı değilse alan kök-göreli olur — Apinizer kök bağlamı ve proxy yolu; ikisi de tanımlı değilse yalnızca proxy yoluna düşer.
Kimlik doğrulaması gerektiren bir kanaldan (istekte proxy'nin auth politika zinciri geçildikten sonra) aynı kart GetExtendedAgentCard JSON-RPC metoduyla da alınabilir — kimlik bazlı erişim listesi tanımlıysa bu çağrı, çağıranın kimliğine göre kişiselleştirilmiş bir skill kümesi döndürebilir; herkese açık discovery uç noktası ise her zaman kimliklenmemiş bir çağıranmış gibi değerlendirilir.
Protokol Sürümü
A2A protokolünün tek desteklenen sürümü 1.0'dır (alan gelecekteki bir sürüm genişlemesi için ayrı tutulmuştur) — MCP'nin aksine bir sürüm seçimi yapmanız gerekmez.
Görev Yaşam Döngüsü
İstemciler SendMessage metodu ile görev gönderir; görev durumu GetTask/ListTasks ile sorgulanabilir, CancelTask ile iptal edilebilir:
{
"jsonrpc": "2.0",
"id": 1,
"method": "SendMessage",
"params": {
"message": {
"role": "user",
"parts": [{ "type": "text", "text": "Siparişimin durumu nedir?" }]
}
}
}
Agent Yayınla modunda Apinizer'ın kendi ajanı bir görevi yalnızca şu durumlar arasında ilerletir: submitted → working → completed / failed / canceled / rejected. Diğer iki durum (input-required, auth-required) Apinizer'ın kendi ajanı tarafından hiç üretilmez; bunlar yalnızca Apinizer'ın giden istemci olarak konuştuğu dış ajanlarda gözlemlenebilecek durumlardır.
| Durum | Anlamı |
|---|---|
submitted | Görev alındı, işleme henüz başlamadı |
working | Görev işleniyor |
completed | Görev başarıyla tamamlandı |
failed | Görev hata ile sonuçlandı |
canceled | Görev iptal edildi |
Passthrough modunda görevlerin sahibi arka uç ajandır; bu yüzden GetTask ve CancelTask iki adımda çözülür: proxy önce kendi izlediği görevler arasında arar (akış/streaming relay'i gateway tarafından izlenir), gelen kimlik bunlardan biri değilse çağrı arka uç ajana iletilir ve ajanın yanıtı olduğu gibi döndürülür — görev orada da bilinmiyorsa ajanın kendi "görev bulunamadı" yanıtı dahil. İstemcinin, Passthrough SendMessage çağrısından aldığı görev kimliğini doğrudan sorgulayabilmesini sağlayan davranış budur. Bir görev kimliğinin okunup okunamayacağına/iptal edilip edilemeyeceğine, iletilen mesajın yetkilendirmesinde olduğu gibi arka uç ajan karar verir. ListTasks ve SubscribeToTask her zaman gateway'in kendi görev kayıtlarından yanıtlanır, arka uca iletilmez; birden fazla ajanı birleştiren bir proxy'de ise GetTask/CancelTask, görevin hangi ajana ait olduğunu tahmin etmek yerine hata döndürür.
Gateway'in kendi tuttuğu görev kayıtları terminal durumlara (completed/failed/canceled) ulaştığında bir süre sonra otomatik temizlenir; aktif görevler süresiz saklanır. Passthrough modunda akış dışı bir çağrıyla oluşan görevin saklama süresine arka uç ajan karar verir.
Gelen A2A ajanları APIops REST API ile de yönetilebilir; bkz. API Referansı: API Proxies.
Akış (Streaming) ve Yeniden Abone Olma
İstemciler SendStreamingMessage metoduyla görev güncellemelerini baştan itibaren SSE üzerinden chunk chunk alabilir. Bağlantı kesilirse istemci SubscribeToTask metoduyla, saklanan görev geçmişinden yeniden oynatma ile kaldığı yerden akışa yeniden abone olarak devam edebilir.
Push (Webhook) Tamamlanma Bildirimi
Uzun süren görevler için istemciler, CreateTaskPushNotificationConfig metoduyla görev başına bir webhook hedefi + kimlik doğrulama bilgisi kaydedebilir (yönetimi için ayrıca GetTaskPushNotificationConfig/ListTaskPushNotificationConfigs/DeleteTaskPushNotificationConfig metotları vardır). Görev tamamlandığında/başarısız olduğunda Apinizer bu webhook'a bir bildirim isteği gönderir. Bu, uzun süren ajan görevleri için sürekli sorgulamaya (polling) göre birincil tamamlanma bildirim kanalıdır.
Çok-Modaliteli Görev Parçaları
Bir görev, metin dışında görsel ve yapılandırılmış veri içeren parçalar (part) taşıyabilir.
Desteklenen görev parçası türleri metin, yapılandırılmış veri ve görseldir. Ses ve video türleri bu kapsamda değildir.
Çoklu Hedef (Aggregation)
Passthrough modunda, A2A Routing sekmesindeki satır içi ajan listesine en fazla 10 arka uç A2A ajanı eklenebilir. Apinizer bu ajanların Agent Card skill kataloglarını tek bir kartta birleştirir; farklı ajanlarda aynı isme sahip skill'ler deterministik biçimde ajanAdı__skillAdı şeklinde isimlendirilerek çakışma önlenir.
Bu birleştirme yalnızca Agent Card/skill keşfi seviyesindedir. Birden fazla hedef yapılandırıldığında SendMessage dispatch'i desteklenmez — A2A'nın kablo protokolünde MCP'nin araç çağrısındaki gibi bir hedef-skill alanı olmadığından, isteği hangi ajana yönlendireceğini güvenle seçmek mümkün değildir; bu durumda çağrı sessizce ilk hedefe yönlendirilmek yerine açık bir hata döner. Tek bir ajan yeterliyse listeye tek satır eklemek yeterlidir; davranış önceki (tek-hedef) sürümle birebir aynı kalır.
Güvenlik ve Governance
Kimlik doğrulama artık proxy'nin normal politika zincirinden gelir — JWT, OIDC, API Anahtarı, Basic gibi mevcut tüm auth politikaları A2A Gateway'lerinde de kullanılabilir; eski modeldeki Yok/API Anahtarı ikilisiyle sınırlı değildir. Discovery belgesi (.well-known/agent-card.json) bu zincirden muaftır ve her zaman açık erişimlidir.
Aynı politika zincirinden Kişisel Veri (PII) Maskeleme, İstem Koruması, Veri Sızıntısı Koruması (DLP), Konu-Dışı Koruması ve Tekrar-Fırtınası (Loop) Koruması gibi gelişmiş korumalar da geçer — gönderilen görevin mesaj parçalarına (parts[], hem metin hem yapılandırılmış veri) uygulanır. Bir A2A Gateway'ine yalnızca bu beş koruma eklenebilir; bir LLM çağrısına doğrudan bağlı diğer AI politikaları (Semantik Önbellek, Token Kotaları, Prompt Süsleyici, Prompt Şablonları, RAG, Bağlam Bütünlüğü Koruması) kaydetme adımında reddedilir. İstem Koruması ve Konu-Dışı Koruması bir A2A Gateway'inde kullanıldığında, aynı politikaların taşıdığı dış sağlayıcı guardrail desteği de bu proxy'de aynen çalışır — görevin mesaj parçaları, tanımlıysa bir dış LLM hakemine de gönderilir.
Aşağıdaki governance özellikleri şu an bir yönetim ekranı üzerinden değil, API proxy yapılandırmasının bir parçası olarak (APIops) ayarlanır:
- Kimlik bazlı erişim listesi (identity-ACL) — yalnızca Passthrough modunda uygulanır; Agent Yayınla modunda bu liste hiç değerlendirilmez, proxy kendi Agent Card'ını her zaman herkese aynı şekilde yayınlar. Passthrough'ta opsiyoneldir: boş bırakılırsa mevcut skill izin listesi/keşif davranışı aynen sürer. Doldurulursa default-deny olur: kimlik bilgisi (credential), rol veya organizasyon bazında tanımlanan kurallarla eşleşmeyen bir çağıran hiçbir skill'i Agent Card'da göremez. Yukarıdaki uyarıda belirtildiği gibi, bu yalnızca kart yayınını daraltır,
SendMessageçağrısını çağrı-anında gate'lemez. - Çağrı kotası (call-quota) — dakika/saat/gün periyodunda bir çağrı limiti tanımlanabilir. Varsayılan kapalıdır. Gelen
SendMessageçağrısının A2A protokolünde bir skill adı taşımaması nedeniyle, araç bazlı kota bu yüzeyde proxy başına tek bir kovaya, "araç + kimlik bilgisi" bazlı kota ise doğrudan kimlik bilgisi bazlı kovaya indirgenir; giden A2A ajan çağrısı politikaları bu sınırlamadan etkilenmez (her zaman gerçek bir skill adı taşırlar). - Katalog sapması (catalog drift) koruması — bir A2A ajanının skill kataloğu ilk keşfedildiğinde (veya elle yeniden keşfedildiğinde) onaylanan katalog bir özet (hash) olarak sabitlenir; periyodik bir sağlık kontrolü canlı kataloğu bu özetle karşılaştırır. Varsayılan davranış (yalnızca uyar) sapmayı loglar ve uyarı üretir ama çağrıları engellemez; kapalı-güvenli davranış seçilirse, katalog yeniden onaylanana kadar sapma tespit edilen ajan üzerindeki çağrılar reddedilir. MCP ile aynı mekanizmayı paylaşır.
- Token passthrough (opt-in) — çağıranın kendi token'ının backend agent'a iletilmesi varsayılan olarak her yerde kapalıdır. A2A Routing sekmesindeki "istemci token'ını ilet" seçeneği tek başına yeterli değildir; iletimin fiilen etkinleşmesi için ayrıca (APIops ile) açık bir onay + opsiyonel bir hedef-kitle (audience) izin listesi yapılandırılması gerekir. Bir iletim denemesi başarısız olursa (özellik kapalı, token bulunamadı veya hedef kitle eşleşmedi) ajanın kendi kimlik bilgisi kullanılmaya devam eder — kimliksiz bir çağrı asla arka uca sessizce geçmez.
Passthrough çağrıları (Agent Card getirme + görev gönderimi) SSRF (Server-Side Request Forgery) koruması altındadır:
Hedef URL; bulut metadata uç noktaları, loopback, link-local, multicast ve carrier-grade-NAT (CGNAT) aralıklarına karşı her zaman doğrulanır — bu adreslere yönelik istekler, yapılandırmadan bağımsız olarak her zaman engellenir. Bir ajan tanımı ya da proxy, opsiyonel olarak diğer özel ağ aralıklarına (RFC1918 / IPv6 ULA — örn. cluster-içi bir ajan) erişecek şekilde ayrıca izinlendirilebilir, ancak bu opt-in yukarıdaki adresleri asla açmaz.
Push bildirimleri için de aynı mantık geçerlidir: webhook hedefleri varsayılan olarak özel IP aralıklarına gönderilemez; yalnızca güvenilir cluster-içi hedefler için ayrı bir anahtarla bu kısıtlama proxy bazında gevşetilebilir.
Bu koruma MCP Gateway giden sunucu tanımları tarafından da paylaşılır.
Yapılandırmada Ortam Değişkenleri
A2A Gateway yapılandırmasına yazdığınız metinlerin çoğu ${DEGISKEN_ADI} biçiminde ortam değişkeni referansı kabul eder; değer proxy'nin çalıştığı ortama göre çözülür ve aynı yapılandırma test ortamından canlıya elle düzenlenmeden taşınır.
Değişken kabul eden alanlar:
| Nerede | Alanlar |
|---|---|
| Giden ajan çağrısı | Yetenek adı, mesaj şablonu |
| Erişim kuralları | İzinli yetenek listesi, kimlik kuralındaki kullanıcı/rol/organizasyon adı, izin ve ret listeleri |
| Token aktarımı | Kabul edilen hedef kitle listesi |
Mesaj şablonu ayrıca #{...} biçimindeki bağlam değişkenlerini de kabul eder; bunlar ortam değişkenleri yerleştirildikten sonra her istek için değerlendirilir.
Çözümleme, MCP Gateway tarafındaki ile birebir aynı şekilde fail-closed çalışır: tanımsız bir değişkende metin yazıldığı gibi kalır, bu da gerçek hiçbir yetenek veya hedef kitle ile eşleşmez; çağrı yanlış bir eşleşmeye düşmek yerine reddedilir. Çağıran taraf da yetenek adı olarak birebir ${DEGISKEN_ADI} metnini gönderip erişim kuralını aşamaz.
Push bildirim ayarları bilinçli tek istisnadır: webhook adresi ve token'ı operatörden değil, çalışma anında çağıran istemciden gelir; bu nedenle her zaman düz metin kabul edilir. Bunların çözülmesi, çağıran tarafın gateway'e kendi ortam değerlerinden birini kendi kontrolündeki bir webhook'a yazdırabilmesi anlamına gelirdi.
Loglama ve Analytics
A2A tipindeki bir proxy'nin detay sayfasında da Trace, Trafik ve Analitik sekmeleri bulunur — REST/SOAP proxy'lerindeki eşdeğer sekmelerle aynı yapıdadır (sekme adı proxy tipini tekrarlamaz, zaten o proxy'nin içindesinizdir); ayrıca yalnızca A2A Gateway'lerinde görünen bir Görevler sekmesi, gateway'in kendi izlediği görevleri canlı listeler: Agent Yayınla modundaki tüm görevler ve Passthrough modunda akış (streaming) çağrısıyla oluşan görevler. Passthrough'ta akış dışı bir çağrıyla oluşan görevin sahibi arka uç ajandır; bu görev trafik logunda görünür ancak bu sekmede listelenmez — istemcinin GetTask sorgusu da o ajan tarafından yanıtlanır (bkz. Görev Yaşam Döngüsü). Her A2A çağrısı (gelen görev gönderimi/sorgulama/iptal, giden ajan çağrısı ve giden sağlık yoklaması), gecikme/boyut/istemci IP'si gibi standart alanların yanında A2A'ya özgü alanlarla birlikte trafik logunda görünür. Analitik sayfasının Trafik tab'ındaki "Flags" rozet kolonu bir isteğin önbellek/koruma/PII/streaming durumunu tek bakışta gösterir; ayrıntılı kullanım, maliyet ve koruma metrikleri aynı Analitik sayfasında izlenebilir — bkz. Raporlar ve Analitik.
Bir AI Gateway'in dış ajanlara birden çok görev gönderdiği durumlarda, her görevin süresi ve sonuç durumu ayrı ayrı uçtan uca izleme kaydında (trace) görünür. Uçtan uca bir görev zincirini takip etmek için İzleme ve Tekrar Oynatma sayfasına bakın.
Giden Ajan Çağrıları: Trace'ten Bağımsız Denetim İzi
Hangi giden ajana/beceriye (skill) gidildiğinin kaydı trace açık/kapalı olmasından bağımsız olarak ana trafik satırında tutulur — trace kapalıyken (varsayılan kurulum) de kaybolmaz. Bu istek boyunca dispatch edilen tüm giden ajan çağrılarının adları iki alanla taşınır:
- Tekilleştirilmiş isim listesi — A2A'da beceri (skill) adı opsiyonel bir alan olduğu için, bir çağrıda skill adı yoksa bunun yerine ajan anahtarı (agent key) kaydedilir (boş bir liste + sıfır olmayan bir sayaç bozuk bir denetim izi olurdu). Aynı istekte tekrar eden adlar tek kez, ilk görülme sırasıyla, virgülle ayrılmış biçimde tutulur; 256 karakter tavanı vardır ve bir isim asla ortasından kesilmez — sığmayan isim(ler) bütün olarak düşer ve bu durum
,…işaretiyle belli edilir (sessiz kesme yoktur). - Ham çağrı sayacı — aynı istekte dispatch edilen tüm giden ajan çağrılarının (tekrarlar dahil) toplam sayısı; isim listesi 256 karakter sınırı nedeniyle kırpılsa bile bu sayaç gerçek toplamı taşır.
Bu denetim izi, bir guard veya kota tarafından reddedilen ajan çağrılarını da içerir — amacı yalnızca başarılı çağrıları değil, hangi ajana gidilmek istendiğini göstermektir; reddedilen bir çağrı güvenlik açısından başarılı olanı kadar (bazen daha fazla) ilgi çekicidir.
Elasticsearch ve MongoDB trafik-log connector'ları bu alanları otomatik olarak taşır. SQL/JDBC trafik-log connector'ı kullanan mevcut kurulumlar için bkz. 2026.09.0 — Log Tablosu ALTER Scriptleri.
Eski Sürümden Geçiş
Aşağıdaki ekranlar ve kavramlar kaldırıldı; otomatik bir geçiş yoktur — eşdeğerini A2A tipinde yeni bir API Proxy olarak yeniden oluşturmanız gerekir:
- Ayrı "A2A Inbound Agent" listeleme/oluşturma/düzenleme ekranı; bu kayıt tek bir hedef proxy'ye bağlıydı ve bu kayda özgü ajan bazlı kimlik doğrulama modları (Yok / API Anahtarı) taşıyordu.
- Eski istemci uç noktası
/a2a/{id}— yerini proxy'nin kendi relative path'i aldı. - A2A ajanına özgü ayrı bir deploy tipi — artık standart API Proxy deploy akışının bir parçası.
Passthrough modu, çoklu hedef birleştirme ve tam auth politika zinciri desteği, eski modelde bulunmayan yeni yeteneklerdir.
| Eski kavram | Yeni karşılığı |
|---|---|
| A2A Inbound Agent kaydı | A2A tipinde API Proxy |
| Ajan bazlı Yok/API Anahtarı modu | Proxy'nin normal auth politika zinciri |
/a2a/{id} | Proxy'nin relative path'i |
Giden Bağlantı Ekranının Kaldırılması
Ayrı bir giden A2A bağlantısı listeleme/oluşturma ekranı (ve buna karşılık gelen bağımsız APIops uç noktaları) da kaldırıldı; ajan tanımı artık yukarıda anlatıldığı gibi Passthrough modunda A2A Routing sekmesinde, görev gönderiminde ise A2A Çağrısı (LLM) / A2A Çağrısı (Sabit) politikasının kendisinde satır içi tutulur. Ajan kartı (agent card) keşfi, sağlık yoklaması, katalog kayması (drift) koruması ve token passthrough aynı şekilde çalışmaya devam eder; artık paylaşılan bir kayda değil, ajanın kendi tanımına bağlıdır.
Bu değişiklik için otomatik bir geçiş vardır: bu eski ekrandan önceden oluşturulmuş bağlantılara sahip mevcut proxy ve politika yapılandırmaları, bir sonraki yükseltmede otomatik olarak satır içi ajan tanımına taşınır — yeniden oluşturmanız gerekmez. Aynı bağlantı birden fazla proxy/politika tarafından paylaşılıyorsa, yükseltme sonrasında her biri kendi bağımsız (kimlik bilgisi dahil) kopyasını taşır; kimlik bilgisini rotasyona sokarken bunu göz önünde bulundurun.
Sonraki Adımlar
API'lerinizi araç olarak sunun ya da dış araçlara bağlanın
DLP, döngü ve konu-dışı korumalarını yapılandırın
A2A görevlerini trace zinciriyle izleyin ve yeniden çalıştırın
Ajan protokolleri hakkında temel kavramları öğrenin