MCP ile Dağıtık Agent Skills: Uzman Ajana Alternatif

Çoklu ajan mimarilerinde alışılmış kurgu şudur: bir üst ajan kullanıcının isteğini anlar, uzman ajanlara devreder ve dönen yanıtları birleştirir. Microsoft Agent Framework blogunda Tommaso Stocchi, aynı uygulama üzerinde bu klasik yaklaşımı ve alternatifini yan yana kurarak şu soruyu sorguluyor: her uzmanın gerçekten kendi model çalıştırmasına ihtiyacı var mı, yoksa üst ajan çoğu zaman yalnızca uzmanın talimatlarına ve operasyonlarına erişime mi ihtiyaç duyuyor? Bu yazıda, uzman ajanlardan MCP üzerinden sunulan dağıtık Agent Skills yapısına geçişin ne anlama geldiğini, neyin taşındığını ve demo uygulamanın izlerinde gecikme ile token tüketiminin nasıl değiştiğini bulacaksınız.

İki desen, iki farklı devretme biçimi

Kaynak örnek bir kayak merkezi demosu: bir “resort advisor”, hava durumu, güvenlik, kayak koçluğu ve lift trafiği için uzmanlara başvuruyor. Orijinal mimaride her uzman kendi talimatlarına ve araçlarına sahip; advisor onları Agent-to-Agent (A2A) üzerinden çağırıyor.

Ajanı araç olarak kullanmak: Advisor her uzak ajanı çağırabileceği bir fonksiyon olarak görür. Hava durumu sorusunda uzman ajan bağımsız bir akıl yürütme bileşenidir; devredilen soruyu yorumlar, araçlarını seçer ve bir yanıt yazar. Advisor da bu yanıtı yorumlayıp nihai cevabı üretir. Uzmanın özerkliğe ihtiyacı olduğu durumlarda — kendi modeli, özel bağlamı, kapsamlı bir iş akışı veya bağımsız yaşam döngüsü varsa — bu desen yerindedir.

Dağıtık skill: İkinci mimaride hava durumu servisi soruyu yorumlamak için modele ihtiyaç duymaz. Bunun yerine bir açıklama, bir SKILL.md belgesi ve tipli MCP araçları yayımlar. Advisor gerektiğinde talimatları yükler, ilgili araç tanımlarını alır ve bir sonraki operasyonu seçmek için bunları kullanır. Akışı advisor tarafında Microsoft Agent Framework (MAF) yönetir. Bu yolda bir hava durumu ajanı modeli yoktur; ancak uygulama kodunu çalıştıran bir hava durumu servisi hâlâ vardır.

Yazarın vurgusu net: dağıtık skill, Markdown’a sarılmış bir ajan değildir. Advisor’a izlenecek bir prosedür verir; o prosedürün gerektirdiği operasyonları sağlayıcının araçları yürütür.

Bu, “MCP her yerde A2A’nın yerini alır” demek değil. A2A ve MCP farklı sınırlara hitap eder: özerk bir ajan ajan olarak kalabilir, sınırları belirli bir yetkinlik ise skill’e dönüşebilir. Ayrıca “bir ajan bir model çağrısı” demek de değildir; talimat yükleme, operasyon çağırma ve yanıt üretme hâlâ birkaç model isteği gerektirebilir. Fark, taşınan alanın artık kendi iç içe akıl yürütme döngüsünü eklememesidir.

Neler taşınıyor, neler taşınmıyor?

Agent Card’daki her şey skill açıklamasına ait değildir: uç nokta yapılandırması, kimlik doğrulama ve taşıma yetenekleri altyapı meselesi olarak kalır. Benzer şekilde izinlere dair talimatlar, koddaki yetkilendirme denetimlerinin yerini tutmaz.

Demoda iki mimari yan yana duruyor. Dört uzmanın MCP karşılığı var: hava durumu, güvenlik, kayak koçluğu ve lift trafiği. Web araştırması yapan ajan ise her iki advisor’da da sıradan bir ajan aracı olarak kalıyor — yani her yeteneği aynı biçime dönüştürmek zorunlu değil. Dil tercihi de karışık: skills advisor Python, dört MCP sağlayıcısı.NET; A2A advisor.NET ve hem Python hem.NET uzmanları var. Yazar bunun bağımsız uygulama kararları olduğunu, servisleri başka dile taşıma zorunluluğu olmadığını belirtiyor.

Geçişin adımları

1. Yetkinliği ajan çalışma zamanından ayırın

Uç noktadan değil, uzmanın içinden başlayın. Tipik bir uzman üç şeyi birleştirir: talimatlar, ajan/model çalışma zamanı ve iş sistemine ulaşan fonksiyonlar. Protokolü değiştirmeden önce bu sorumlulukları ayırın. Hava durumunda koşulların alınması ve demo tahmininin hesaplanması zaten bir alan servisine aittir; bir gözlemi okumak ya da tahmin hesaplamak için başka bir modele ihtiyaç yoktur. Servisin iş kuralları, veri erişimi ve doğrulaması korunur; uzmanın talimatları skill’e taşınır, operasyonları MCP araçlarıyla açılır ve model döngüsü yalnızca advisor operasyon seçimi ile sonuç yorumlamayı üstlenebiliyorsa kaldırılır.

Yazarın uyarısı: “sağlayıcıda model yok” ifadesi çıktının sabit olduğu anlamına gelmez. Demonun telemetrisi zamanla değişir ve tahmini rastgele varyasyon kullanır. Ayrım, uygulama mantığı ile ayrı bir ajan döngüsü arasındadır.

2. Agent Card açıklamasını skill keşfine dönüştürün

Orkestratörün her istekte her uzmanın tüm talimatlarına ihtiyacı yoktur; hangi yetkinliğin ilgili olduğuna karar verecek kadar bilgi yeterlidir. Her sağlayıcı kendi MCP uç noktasını /skillsmcp altında açar ve kaynak yüzeyinde yalnızca skill://index.json ile skill://<skill-name>/SKILL.md bulunur. Hava durumu için indeks şöyle:

{
"$schema": "https://schemas.agentskills.io/discovery/0.2.0/schema.json",
"skills": [
{
"name": "weather",
"type": "skill-md",
"description": "Weather intelligence agent providing real-time conditions, forecasts, and storm alerts for the ski resort",
"url": "skill://weather/SKILL.md"
}
]
}

Açıklama, eski Agent Card’ın yönlendirme bilgisini taşır: bu yetkinlik ne zaman işe yarar. Kartın ağ veya güvenlik yapılandırmasını taşımaz. skill:// URI’si, halihazırda yapılandırılmış bir MCP bağlantısındaki içeriği tanımlar; çözülecek bir ana bilgisayar adı ya da skill metninin yeni bir ağ uç noktası seçmesinin yolu değildir.

3. Uzmanın prosedürünü SKILL.md’ye taşıyın

Açıklama “ne zaman kullanılır” sorusunu, SKILL.md ise “nasıl uygulanır” sorusunu yanıtlar. Eski uzmanın sistem istemi başlangıç malzemesidir: alan kuralları, yorumlama, güvenlik öncelikleri ve yanıt rehberliği. Bağımsız bir konuşma varsayımlarını temizleyip mevcut araçların seçim prosedürünü eklemek gerekir. Yazarın paylaştığı taşınabilir örnek prosedür (demonun ürettiği belgenin birebir kopyası değil):

---
name: weather
description: Assess current resort weather, forecasts, and storm threats.
---
# Weather procedure
1. Use weather_current_conditions for current temperature, wind,
snow intensity, visibility, and observation time.
2. Use weather_forecast when the request concerns later conditions.
Supply an integer hours value from 1 through 24.
Explain that this demo forecast is a simulation, not a weather service.
3. Use weather_storm_status when a storm assessment is relevant.
4. Report specific values with their units and source limitations.
Prioritize safety and do not invent missing observations.

Prosedür MCP operasyonlarına weather_forecast gibi adlarıyla atıfta bulunur; araç açıklamalarını ve parametre şemalarını MCP sağlar. Demo ayrıca araçların bu advisor’da nasıl kullanılabilir hâle geldiğini anlatan kısa bir bölüm ekliyor: skill yüklendiğinde sağlayıcının araçları bir sonraki model yinelemesinde görünür oluyor ve çağrılabilir adlar host’un sağlayıcı öneki ile listeleniyor — örneğin weather_forecast, weather_weather_forecast hâline geliyor.

4. Operasyonları MCP araçları olarak yayımlayın

Operasyonlar araç olmayı sürdürür; değişen, advisor’ın onlara nasıl ulaştığıdır. Uzman bir ajandan operasyon seçmesini istemek yerine tipli MCP aracı doğrudan çağrılır. WeatherTools.cs dosyasından bir kesit:

[McpServerTool(
Name = "weather_forecast",
ReadOnly = true,
Destructive = false,
UseStructuredContent = true)]
[Description("Generate a demo hourly forecast from current conditions. Forecast variation is randomized.")]
public async Task<WeatherForecast> Forecast(
[Description("Forecast horizon in hours, from 1 through 24."),
Range(1, 24)] int hours,
CancellationToken cancellationToken)
{
if (hours is <1or> 24)
throw new ArgumentOutOfRangeException(
nameof(hours), "Hours must be between 1 and 24.");
return Read<WeatherForecast>(
await service.GetForecastAsync(hours, cancellationToken));
}

.NET MCP SDK araç tanımını yayımlar ve çağrıları metoda bağlar. İşleyici aralığı doğrular, iptal belirtecini geçirir ve mevcut servise devreder. Skill metni operasyon seçimine rehberlik eder; parametre şemasının veya sunucu tarafı doğrulamanın yerini almaz. Sağlayıcı bu araçları talimat kaynaklarıyla birlikte Streamable HTTP üzerinden barındırır:

builder.Services.AddMcpServer(options =>
{
options.ServerInfo = new()
{
Name = "weatherskills",
Version = "1.0.0"
};
})
.WithHttpTransport()
.WithResources<WeatherSkillResources>()
.WithTools<WeatherTools>();
var app = builder.Build();
app.MapMcp("/skillsmcp");
app.Run();

Burada resources/read talimatları getirir, tools/list yetkili operasyon tanımlarını sağlar, tools/call iş operasyonlarını yürütür.

5. Uzak ajan kayıtlarını skill ve araçlarla değiştirin

Önceki advisor bir A2A Agent Card’ını çözüp uzak ajanı AI fonksiyonu olarak kaydediyordu:

var resolver = new A2ACardResolver(
endpoint,
httpClient,
agentCardPath: "/.well-known/agent-card.json");
var card = await resolver.GetAgentCardAsync();
var remoteAgent = card.AsAIAgent(httpClient);
var specialistTool = remoteAgent.AsAIFunction();

Yeni advisor bunun yerine MCP sağlayıcılarına bağlanır. Skill keşfi ve talimat yüklemesini MAF’ın yerleşik SkillsProvider ve MCPSkillsSource bileşenleri üstlenir. Demo ayrıca araçların görünürlüğünü model bir skill seçene kadar erteler. Yazar bunun küçük kataloglar için isteğe bağlı olduğunu belirtiyor: MCP araçlarını baştan kaydedip yalnızca talimatları talep üzerine yüklemek de mümkün. Kayak merkezinin dört skill’i ve on iki aracı, daha büyük kataloglar için düşünülmüş bir deseni örnekliyor.

skill_tools = SkillToolsMiddleware(connections)
skills = SkillsProvider(
skill_tools.source,
disable_load_skill_approval=True,
disable_read_skill_resource_approval=True,
)
agent = client.as_agent(
name="skiadvisorskill",
instructions=INSTRUCTIONS,
context_providers=[skills],
tools=[researcher_tool],
middleware=[skill_tools],
)
await skill_tools.initialize(agent, exit_stack)

context_providers=[skills] skill’leri keşfedilebilir ve talimatlarını yüklenebilir kılar; middleware=[skill_tools] ise başarılı bir skill yüklemesini ilgili araç kataloğuna bağlar. Başlangıçta host skill’leri keşfeder ve her sağlayıcının araç kataloğunu MCP tools/list ile alır. Model başlangıçta yalnızca skill özetlerini, yükleme yardımcılarını ve mevcut araştırmacı aracını görür — her sağlayıcının operasyon şemalarını değil. Advisor load_skill("weather") çağırdığında MAF hava durumu talimatlarını getirir; yükleme başarılı olunca middleware, MAF’ın add_tools API’siyle üç hava durumu aracını o çalıştırma için kullanılabilir yapar. Diğer sağlayıcıların araçları skill’leri yüklenene kadar bağlam dışında kalır ve bir aracı kullanılabilir kılmak onu çalıştırmak anlamına gelmez.

Gerçek bir çalıştırmanın izleri

Karşılaştırma için yazar, aynı çalışan Aspire uygulamasının her iki sohbet yolundan şu istemi gönderdi: considering weather and waiting time, where should i start? İkisi de frontend’in Responses API proxy’si üzerinden girdi; biri içeride A2A uzmanlarını, diğeri native MCP skill ve araçlarını kullandı. Yani karşılaştırma, ham bir A2A isteği ile tek bir MCP çağrısı arasında değil, iki eksiksiz advisor yolu arasında.

1. ve 2. çiftlerde A2A advisor hava durumu ve lift trafiğini seçti; her uzman iki model çağrısı, advisor da iki çağrı kullandı — toplam altı. 3. çiftte koç da devreye girdi ve tek çağrısında eksik kayakçı bilgisini istedi:

  chat gpt41                         advisor selects specialists
overlapping specialist calls:
weatheragenta2a
chat gpt41
get_current_conditions
chat gpt41
lifttrafficagenta2a
chat gpt41
GetWaitTimes
SuggestLessBusyArea
chat gpt41
skicoachagenta2a
chat gpt41                     asks for skill level/preferences
chat gpt41                         recommends Eagle Chair and asks about ability

Bu yedi model çağrısıdır, ancak yedi ardışık çağrı değildir; uzak uzmanlar çakıştığı için sürelerinin toplanması istemci tarafı geçen süreyi vermez. Skill kapsamlı üç çalıştırmanın hepsi hava durumu ve lift trafiğini seçti ve şu üç çağrılık diziyi izledi:

chat gpt41 #1
load_skill({"skill_name":"weather"})
load_skill({"skill_name":"lift-traffic"})
chat gpt41 #2
weather_weather_current_conditions({})
lifttraffic_lift_traffic_least_busy_area({})
chat gpt41 #3
final answer

Host, skill okumalarının ardından üç hava durumu ve dört lift trafiği aracının tamamını kaydetti; model her gruptan birer operasyon seçti. Ayrı bir araç yükleyici çağrısı olmadı; skill okumaları ve iki operasyon çağrısı kendi model yinelemeleri içinde toplu yürütüldü. Altı yanıtın tamamı Eagle Chair’i önerdi, ama aynı işi yapmadılar: A2A hem GetWaitTimes hem SuggestLessBusyArea çağırırken skills advisor yalnızca lift_traffic_least_busy_area çağırdı; 3. çiftin A2A yanıtı ayrıca kayakçının seviyesini sordu. Hava durumu değerleri ve kuyruk süreleri istekler arasında değişti.

Gecikme ve token tablosu

Ölçümler gpt41 dağıtımıyla alındı. Her istek yukarıdaki istemi ve taze bir konuşmayı kullandı; önceki yanıt kimliği veya geçmiş yoktu. Altısı da zaten çalışan servis ve bağlantıları yeniden kullandı. Sıra 1. çiftte A2A/native, 2. çiftte native/A2A, 3. çiftte A2A/native idi ve yanıtlarla sonraki istekler arasında en az 65 saniye bırakıldı. Geçen süre, frontend POST’unun gönderilmesinden SSE yanıt gövdesinin bitmesine kadarki istemci duvar saati süresidir; proxy, model ve araç işini içerir, bekleme sürelerini içermez ve ilk token’a kadar geçen süre değildir. Token toplamları her benzersiz yaprak chat gpt41 span’ını bir kez toplar.

* A2A advisor span’ları önbellekli girdiyi sıfır raporladı, uzman span’ları ise önbellek sayaçlarını hiç içermedi. Dolayısıyla sistem genelindeki önbellekli girdi bilinmiyor, sıfır değil. Native tarafta önbellekli token’lar girdi toplamlarına zaten dahil.

Skills yolu bu yeniden kullanılan süreç ve önbellekten etkilenen çalıştırmalarda daha hızlıydı: ortalama süre 6,348 saniyeye karşı A2A için 15,480 saniye. Ancak yazar bu farkın mimari hızlanmayı önbellek etkilerinden, ilk kullanımdaki kimlik bilgisi başlatmasından, dil/çalışma zamanı farklarından ve yapılan iş miktarından ayrıştırmadığını açıkça belirtiyor. Toplam token açısından ise skills yolu daha az tüketmedi.

Çıkarım

Bu karşılaştırmanın ana fikri, dağıtık yapıyı bozmadan akıl yürütmenin yerini değiştirmek: alan servisleri dağıtık kalır, uzmanın talimatları orkestratöre taşınır, ikinci bir model oraya taşınmaz. Özerkliğe gerçekten ihtiyaç duyan uzman ajan olarak kalabilir; sınırları belirli bir yetkinlik ise SKILL.md ve tipli MCP araçlarına dönüşebilir. Demodaki hibrit yapı — web araştırmacısının her iki tarafta da ajan aracı olarak kalması — bu tercihin tümden bir geçiş gerektirmediğini gösteriyor.

Kaynaklar ve İleri Okuma

• devblogs.microsoft.com
• devblogs.microsoft.com
• github.com
• github.com
• github.com

• From Specialist Agents to Distributed Skills over MCP — Tommaso Stocchi, Microsoft Agent Framework Blog
• ski-resort-demo deposu (GitHub)
• Karşılaştırmada kullanılan 56f453a commit’i
• native_mcp.py — skill başına araç eşlemesi
• agent_builder.py — skill sağlayıcı ve middleware bağlantısı
• ski-advisor-a2a/Program.cs — A2A advisor kaydı
• Agent Skills spesifikasyonu
• MCP skills extension önerisi (PR 2640)
• .NET Agent Skills: Üç Yöntem, Tek Sağlayıcı
• Agent Framework Orchestration 1.0: Çoklu Ajan Koordinasyonu

Aşkın KILIÇYazar

20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102

İlgili Yazılar

Azure DevOps Server Şubat Güncellemesi: Güvenlik9 Mar 2026

GitHub Models Kapandı: Alternatifler ve Geçiş Yolu31 Tem 2026

Visual Studio’da Plan Agent: Kodu Yazmadan Önce Durup Düşünmek24 May 2026

GitHub Actions’ta 50 Yeniden Çalıştırma Sınırı: Sahada Ne Değişiyor?11 Nis 2026