Agent Framework | The .NET Blog

Agent Framework'te CodeAct: Ajanınızın Gecikmesini Yarıya Nasıl İndirirsiniz

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

Bu gönderi otomatik olarak çevrilmiştir. Orijinal sürüm için buraya tıklayın.

Her ajan projesinde, izlemeye bakıp “bu neden bu kadar uzun sürüyor?” diye düşündüğünüz bir an gelir. Model iyi çalışıyor. Araçlar çalışıyor. Ama tek seferinde hesaplanabilecek bir sonuç için yedi gidiş-dönüş oluyor.

CodeAct’ın tam olarak çözdüğü sorun bu — ve Agent Framework ekibi yeni agent-framework-hyperlight paketiyle alfa destek yayınladı.

CodeAct Nedir?

CodeAct deseni zarifçe basittir: Modele tek tek çağrılacak araçların listesini vermek yerine, tek bir execute_code aracı verin ve planın tamamını kısa bir Python programı olarak ifade etmesine izin verin.

Yaklaşım	Süre	Token
Geleneksel	27.81s	6.890
CodeAct	13.23s	2.489
İyileştirme	%52.4	%63.9

Güvenlik: Hyperlight Mikro-VM’leri

agent-framework-hyperlight paketi Hyperlight mikro-VM’leri kullanır. Her execute_code çağrısı kendi yeni mikro-VM’ini alır. Başlatma milisaniyelerle ölçülür. İzolasyon neredeyse ücretsizdir.

Araçlarınız ana bilgisayarda çalışmaya devam eder. Modelin oluşturduğu yapıştırıcı kod sandbox’ta çalışır. Bu doğru ayrımdır.

Minimum Kurulum

from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider

codeact = HyperlightCodeActProvider(
 tools=[get_weather],
 approval_mode="never_require",
)

agent = Agent(
 client=client,
 name="CodeActAgent",
 instructions="You are a helpful assistant.",
 context_providers=[codeact],
)

CodeAct Ne Zaman Kullanılır (Ne Zaman Kullanılmaz)

CodeAct kullanın:

Görev birçok küçük araç çağrısını zincirliyor (aramalar, birleştirmeler, hesaplamalar)
Gecikme ve token maliyeti önemliyse
Model tarafından oluşturulan kod için güçlü izolasyon istiyorsanız

Geleneksel araç çağrısında kalın:

Ajan tur başına yalnızca bir iki araç çağrısı yapıyorsa
Her çağrının bireysel onay gerektiren yan etkileri varsa

Şimdi Deneyin

pip install agent-framework-hyperlight --pre

Agent Framework blogundaki tam gönderiyi okuyun.

Ajanınız Şeyleri Nerede Hatırlıyor? Sohbet Geçmişi Depolama için Pratik Rehber

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

Bu gönderi otomatik olarak çevrilmiştir. Orijinal sürüm için buraya tıklayın.

Bir AI ajanı oluştururken enerjinizin büyük bölümünü modele, araçlara ve istemlere harcarsınız. Konuşma geçmişinin nerede tutulduğu sorusu bir uygulama ayrıntısı gibi görünür — ancak alacağınız en önemli mimari kararlardan biridir.

Kullanıcıların konuşmaları dallandırıp dallandıramayacağını, yanıtları geri alıp alamayacağını, yeniden başlatmadan sonra oturumları devam ettirip ettiremeyeceğini ve verilerinizin altyapınızı terk edip etmediğini belirler. Agent Framework ekibi derinlemesine bir analiz yayımladı.

İki temel desen

Servis tarafından yönetilen: AI servisi konuşma durumunu depolar. Uygulamanız bir referans tutar ve servis her istekte ilgili geçmişi otomatik olarak ekler.

İstemci tarafından yönetilen: Uygulamanız tam geçmişi tutar ve her istekte ilgili mesajları gönderir. Servis durumsuzdur. Her şeyi siz kontrol edersiniz.

Agent Framework bunu nasıl soyutlar

AgentSession session = await agent.CreateSessionAsync();
var first = await agent.RunAsync("Adım Alice.", session);
var second = await agent.RunAsync("Benim adım ne?", session);

session = agent.create_session()
first = await agent.run("Adım Alice.", session=session)
second = await agent.run("Benim adım ne?", session=session)

Sağlayıcı hızlı referans

Sağlayıcı	Depolama	Model	Sıkıştırma
OpenAI/Azure Chat Completions	İstemci	Yok	Siz
Foundry Agent Service	Servis	Doğrusal	Servis
Responses API (varsayılan)	Servis	Dallanma	Servis
Anthropic Claude, Ollama	İstemci	Yok	Siz

Nasıl seçilir

Dallanma veya “geri al” gerekiyor mu? → Servis tarafından yönetilen Responses API
Veri egemenliği gerekiyor mu? → DB destekli istemci tarafından yönetilen
Basit bir sohbet botu mu? → Servis tarafından yönetilen doğrusal yeterli

Tam karar ağacı için tam makaleyi okuyun.

GPT-5.5 Burada ve Azure Foundry'e Geliyor — .NET Geliştiricilerinin Bilmesi Gerekenler

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

Bu gönderi otomatik olarak çevrilmiştir. Orijinal sürüm için buraya tıklayın.

Microsoft, GPT-5.5’in Microsoft Foundry’de genel kullanıma sunulduğunu duyurdu. Azure’da agent oluşturuyorsanız, beklediğiniz güncelleme bu.

GPT-5 Evrimi

GPT-5: akıl yürütme ve hızı tek bir sistemde birleştirdi
GPT-5.4: daha güçlü çok adımlı akıl yürütme, enterprise için erken ajansal özellikler
GPT-5.5: daha derin uzun bağlam akıl yürütme, daha güvenilir ajansal yürütme, daha iyi token verimliliği

Gerçekte ne değişti

Geliştirilmiş ajansal kodlama: GPT-5.5, büyük kod tabanlarında bağlamı korur, mimari düzeydeki hataları teşhis eder ve test gereksinimlerini öngörür. Model, harekete geçmeden önce bir düzeltmenin başka neyi etkilediğini akıl yürütür.

Token verimliliği: Daha az token ve daha az yeniden denemeyle daha yüksek kaliteli çıktılar. Üretimde doğrudan düşük maliyet ve gecikme.

Fiyatlandırma

Model	Girdi ($/M token)	Önbelleğe alınmış	Çıktı ($/M token)
GPT-5.5	$5,00	$0,50	$30,00
GPT-5.5 Pro	$30,00	$3,00	$180,00

Foundry Neden Önemli

Foundry Agent Service, agentları YAML’de tanımlamanıza veya Microsoft Agent Framework, GitHub Copilot SDK, LangGraph ya da OpenAI Agents SDK ile bağlamanıza olanak tanır — ve bunları kalıcı dosya sistemi, Microsoft Entra kimliği ve sıfıra ölçekleme fiyatlandırmasıyla izole barındırılan agentlar olarak çalıştırır.

AIAgent agent = aiProjectClient
 .AsAIAgent("gpt-5.5", instructions: "Yardımcı bir asistansınız.", name: "BenimAgentim");

Tüm ayrıntılar için tam duyuruya bakın.

.NET'te Agent Skills Ciddi Anlamda Esnek Hale Geldi

Emiliano Montesdeoca — Tue, 14 Apr 2026 00:00:00 +0000

Bu yazı otomatik olarak çevrilmiştir. Orijinal için buraya tıklayın.

Microsoft Agent Framework ile agent geliştiriyorsanız rutini bilirsiniz: skill’leri tanımlarsınız, bir provider’a bağlarsınız ve agentın hangisini çağıracağına karar vermesini beklersiniz. Yeni olan şey ise bu skill’leri nasıl yazdığınız — ve esneklik sıçraması önemli.

Son güncelleme, agent skill’leri için üç farklı yazım deseni sunuyor: dosya tabanlı, sınıf tabanlı ve satır içi kod tanımlı. Üçü de tek bir AgentSkillsProviderBuilder‘a takılır; yani herhangi bir yönlendirme mantığı veya özel bağlantı kodu olmadan bunları karıştırıp eşleştirebilirsiniz. Her birini ve ne zaman kullanacağınızı anlatalım.

Dosya tabanlı skill’ler: başlangıç noktası

Dosya tabanlı skill’ler tam olarak adından anlaşıldığı gibi — diskte bir SKILL.md dosyası, isteğe bağlı scriptler ve referans belgelerle dolu bir dizin. Agentınıza yeni yetenekler vermenin en doğrudan yolu olarak düşünün:

skills/
└── onboarding-guide/
├── SKILL.md
├── scripts/
│ └── check-provisioning.py
└── references/
└── onboarding-checklist.md

SKILL.md frontmatter’ı skill adını ve açıklamasını bildirir, talimatlar bölümü ise agenta scriptleri ve referansları nasıl kullanacağını söyler:

---
name: onboarding-guide
description: >-
 Walk new hires through their first-week setup checklist.
---

## Instructions

1. Ask for the employee's name and start date.
2. Run `scripts/check-provisioning.py` to verify accounts.
3. Walk through `references/onboarding-checklist.md`.
4. Follow up on incomplete items.

Ardından script yürütmesi için SubprocessScriptRunner.RunAsync ile bağlantı kurarsınız:

var skillsProvider = new AgentSkillsProvider(
 Path.Combine(AppContext.BaseDirectory, "skills"),
 SubprocessScriptRunner.RunAsync);

AIAgent agent = new AzureOpenAIClient(new Uri(endpoint), new DefaultAzureCredential())
 .GetResponsesClient()
 .AsAIAgent(new ChatClientAgentOptions
 {
 Name = "HRAgent",
 ChatOptions = new() { Instructions = "You are a helpful HR assistant." },
 AIContextProviders = [skillsProvider],
 },
 model: deploymentName);

Agent, skill’i otomatik olarak keşfeder ve hesap durumunu kontrol etmesi gerektiğinde provisioning scriptini çağırır. Temiz ve basit.

Sınıf tabanlı skill’ler: NuGet üzerinden yayımlayın

İşte ekipler için ilginç kısım. Sınıf tabanlı skill’ler AgentClassSkill<T>‘dan türetilir ve [AgentSkillResource] ile [AgentSkillScript] gibi attribute’lar kullanır; framework her şeyi yansıma (reflection) yoluyla keşfeder:

public sealed class BenefitsEnrollmentSkill : AgentClassSkill<BenefitsEnrollmentSkill>
{
 public override AgentSkillFrontmatter Frontmatter { get; } = new(
 "benefits-enrollment",
 "Enroll an employee in health, dental, or vision plans.");

 protected override string Instructions => """
 1. Read the available-plans resource.
 2. Confirm the plan the employee wants.
 3. Use the enroll script to complete enrollment.
 """;

 [AgentSkillResource("available-plans")]
 [Description("Plan options with monthly pricing.")]
 public string AvailablePlans => """
 ## Available Plans (2026)
 - Health: Basic HMO ($0/month), Premium PPO ($45/month)
 - Dental: Standard ($12/month), Enhanced ($25/month)
 - Vision: Basic ($8/month)
 """;

 [AgentSkillScript("enroll")]
 [Description("Enrolls employee in the specified benefit plan.")]
 private static string Enroll(string employeeId, string planCode)
 {
 bool success = HrClient.EnrollInPlan(employeeId, planCode);
 return JsonSerializer.Serialize(new { success, employeeId, planCode });
 }
}

Buradaki güzellik, bir ekibin bunu NuGet paketi olarak paketleyebilmesidir. Projenize eklersiniz, builder’a bırakırsınız ve dosya tabanlı skill’lerinizle sıfır koordinasyonla birlikte çalışır:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

Her iki skill de agentın sistem prompt’unda görünür. Agent, konuşmaya göre hangisini kullanacağına karar verir — yönlendirme kodu gerekmez.

Satır içi skill’ler: hızlı köprü

Başka bir ekibin tam ihtiyacınız olan skill’i geliştirdiğini ama bir sprint boyunca yayımlanmayacağını bildiğiniz anı tanıyor musunuz? AgentInlineSkill köprünüzdür:

var timeOffSkill = new AgentInlineSkill(
 name: "time-off-balance",
 description: "Calculate remaining vacation and sick days.",
 instructions: """
 1. Ask for the employee ID if not provided.
 2. Use calculate-balance to get the remaining balance.
 3. Present used and remaining days clearly.
 """)
 .AddScript("calculate-balance", (string employeeId, string leaveType) =>
 {
 int totalDays = HrDatabase.GetAnnualAllowance(employeeId, leaveType);
 int daysUsed = HrDatabase.GetDaysUsed(employeeId, leaveType);
 int remaining = totalDays - daysUsed;
 return JsonSerializer.Serialize(new { employeeId, leaveType, totalDays, daysUsed, remaining });
 });

Diğerleri gibi builder’a ekleyin:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

NuGet paketi sonunda yayımlandığında, satır içi skill’i sınıf tabanlıyla değiştirirsiniz. Agent farkı anlamaz.

Ancak satır içi skill’ler sadece köprü için değil. Çalışma zamanında dinamik olarak skill üretmeniz gerektiğinde de doğru seçimdir — config’den yüklenen iş birimi başına bir skill gibi — veya bir scriptin DI container’ına ait olmayan yerel durumu kapatması (closure) gerektiğinde.

Script onayı: human-in-the-loop

Üretim agentları geliştiren .NET geliştiricileri için bu, dağıtım konuşmalarını gerçekten açık eden kısım. Bazı scriptlerin gerçek sonuçları var — birini sigorta planına kaydetmek, üretim altyapısını sorgulamak. UseScriptApproval‘ı açın ve agent herhangi bir scripti çalıştırmadan önce duraklar:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .UseScriptApproval(true)
 .Build();

Agent bir script çalıştırmak istediğinde, bunun yerine bir onay isteği döndürür. Uygulamanız kararı toplar — onayla veya reddet — ve agent buna göre devam eder. Düzenlenmiş ortamlarda bu, “bunu dağıtabiliriz” ile “hukuk hayır diyor” arasındaki farktır.

Bu kombinasyonun önemi

Gerçek güç tek bir yazım deseninde değil — kompozisyondadır. Şunları yapabilirsiniz:

Küçük başlayın dosya tabanlı skill ile, talimatlarda yineleyin ve C# yazmadan yayımlayın
Yeniden kullanılabilir skill’ler yayımlayın NuGet paketleri olarak; diğer ekipler tek satırla ekleyebilir
Boşlukları kapatın satır içi skill’lerle ihtiyacınız olan şeyi hemen geliştirmek için
Paylaşılan skill dizinlerini filtreleyin predicate’lerle, agentınızın yalnızca gereken şeyi yüklemesi için
İnsan denetimi ekleyin üretim sistemlerine dokunan scriptler için

Bunların tümü AgentSkillsProviderBuilder üzerinden birleşir. Özel yönlendirme, koşullu mantık, skill tür kontrolleri yok.

Sonuç

.NET’te agent skill’leri artık gerçekten esnek bir yazım modeline sahip. İster dosya tabanlı skill’lerle prototip çizen solo bir geliştirici olun, ister NuGet aracılığıyla paketlenmiş yetenekler yayımlayan kurumsal bir ekip, desenler her duruma uyuyor. Ve script onay mekanizması, insan denetim noktasına ihtiyaç duyduğunuz ortamlar için üretime hazır hale getiriyor.

Tam rehber için orijinal duyuruya, Microsoft Learn’deki Agent Skills belgelerine ve uygulamalı deneyim için GitHub’daki .NET örneklerine göz atın.

Kara Kutu Hissi Vermeyen Gerçek Zamanlı Çoklu-Agent Arayüzleri Oluşturmak

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Bu yazı otomatik olarak çevrilmiştir. Orijinal için buraya tıklayın.

Çoklu-agent sistemler hakkında şunu söylemek gerekir: demo ortamlarında inanılmaz görünürler. Üç agent iş birbirine aktarır, sorunları çözer, kararlar alır. Sonra bunu gerçek kullanıcıların önüne koymaya çalışırsınız ve… sessizlik. Dönen bir yükleme göstergesi. Hangi agentın ne yaptığını ya da sistemin neden durduğunu anlatan hiçbir şey yok. Bu bir ürün değil — bu bir güven sorunudur.

Microsoft Agent Framework ekibi, MAF iş akışlarını AG-UI ile eşleştiren harika bir rehber yayımladı. AG-UI, agent yürütme olaylarını Server-Sent Events üzerinden bir frontend’e aktarmak için kullanılan açık bir protokoldür. Ve dürüst olmak gerekirse? Bu, eksik olan köprünün ta kendisi.

.NET geliştiricileri için neden önemli

AI destekli uygulamalar geliştiriyorsanız, muhtemelen bu duvarla karşılaşmışsınızdır. Backend orkestrasyonunuz mükemmel çalışır — agentlar birbirlerine iş devreder, araçlar tetiklenir, kararlar alınır. Ancak frontend, perde arkasında ne olduğundan habersizdir. AG-UI, agent olaylarını (RUN_STARTED, STEP_STARTED, TOOL_CALL_*, TEXT_MESSAGE_* gibi) SSE üzerinden doğrudan UI katmanınıza aktarmak için standart bir protokol tanımlayarak bunu çözer.

Geliştirdikleri demo, üç agentlı bir müşteri destek iş akışı: istekleri yönlendiren bir triage agentı, para işlerini yöneten bir refund agentı ve ikame yönetimi yapan bir order agentı. Her agentın kendi araçları var ve devir teslim topolojisi açıkça tanımlanmış — “prompt’tan çöz” vibesinden eser yok.

Devir teslim topolojisi asıl yıldız

Dikkatimi çeken şey, HandoffBuilder‘ın agentlar arasında yönlendirilmiş bir rotalama grafiği tanımlamanıza izin vermesidir:

builder = HandoffBuilder(
 name="ag_ui_handoff_workflow_demo",
 participants=[triage, refund, order],
 termination_condition=termination_condition,
)

(
 builder
 .add_handoff(triage, [refund], description="Refunds, damaged-item claims...")
 .add_handoff(triage, [order], description="Replacement, exchange...")
 .add_handoff(refund, [order], description="Replacement logistics needed after refund.")
 .add_handoff(order, [triage], description="After replacement/shipping tasks complete.")
)

Her add_handoff, doğal dil açıklamasıyla yönlendirilmiş bir kenar oluşturur. Framework, bu topolojiye dayanarak her agent için devir teslim araçları üretir. Böylece yönlendirme kararları, LLM’in keyfine değil, orkestrasyon yapınıza dayanır. Bu, üretim güvenilirliği açısından son derece önemlidir.

Gerçekten işe yarayan human-in-the-loop

Demo, her gerçek dünya agent uygulamasının ihtiyaç duyduğu iki kesme (interrupt) deseni sergiliyor:

Araç onay kesmeleri — bir agent approval_mode="always_require" ile işaretlenmiş bir araç çağırdığında iş akışı duraklar ve bir olay yayımlar. Frontend, araç adı ve argümanlarıyla bir onay modalı gösterir. Token yakan yeniden deneme döngüleri yok — sadece temiz bir duraklat-onayla-devam et akışı.

Bilgi isteği kesmeleri — bir agentın kullanıcıdan daha fazla bağlam (örneğin bir sipariş ID’si) ihtiyacı olduğunda durur ve sorar. Frontend soruyu gösterir, kullanıcı yanıtlar ve yürütme tam kaldığı yerden devam eder.

Her iki desen de standart AG-UI olayları olarak stream edilir; bu nedenle frontend’inizin her agent için özel mantığa ihtiyacı yoktur — SSE bağlantısından gelen olayı olduğu gibi gösterir.

Bağlantı kurmak şaşırtıcı derecede basit

MAF ile AG-UI arasındaki entegrasyon tek bir fonksiyon çağrısıdır:

from agent_framework.ag_ui import (
 AgentFrameworkWorkflow,
 add_agent_framework_fastapi_endpoint,
)

app = FastAPI()

demo_workflow = AgentFrameworkWorkflow(
 workflow_factory=lambda _thread_id: create_handoff_workflow(),
 name="ag_ui_handoff_workflow_demo",
)

add_agent_framework_fastapi_endpoint(
 app=app, agent=demo_workflow, path="/handoff_demo",
)

workflow_factory, thread başına yeni bir iş akışı oluşturur; böylece her konuşma izole bir duruma sahip olur. Endpoint, tüm SSE altyapısını otomatik olarak yönetir. Zaten FastAPI kullanıyorsanız (ya da hafif bir katman olarak ekleyebiliyorsanız), bu neredeyse hiç sürtünme gerektirmez.

Benim görüşüm

.NET geliştiricileri olarak aklımıza gelen ilk soru şu: “Bunu C#’ta yapabilir miyim?” Agent Framework hem .NET hem de Python için mevcut ve AG-UI protokolü dilden bağımsız (aslında sadece SSE). Bu nedenle, bu demo Python ve FastAPI kullansa da, desen doğrudan çevrilebilir. Aynı AG-UI olay şemasını takip eden SSE endpoint’leriyle ASP.NET Core minimal API kurabilirsiniz.

Daha büyük çıkarım şu: çoklu-agent arayüzleri artık sonradan düşünülen bir konu değil, birinci sınıf bir endişe haline geliyor. Agentların insanlarla etkileşime girdiği herhangi bir şey geliştiriyorsanız — müşteri desteği, onay iş akışları, belge işleme — MAF orkestrasyonu ve AG-UI şeffaflığının bu kombinasyonu, izlenecek yol.

Sonuç

AG-UI + Microsoft Agent Framework, her iki dünyanın en iyisini sunar: backend’de sağlam çoklu-agent orkestrasyonu, frontend’de gerçek zamanlı görünürlük. Artık kara kutu agent etkileşimleri yok.

Daha fazla bilgi için tam rehbere ve AG-UI protokol deposuna göz atın.

Microsoft Agent Framework 1.0 Yayımlandı — .NET Geliştiricileri İçin Gerçekten Önemli Olan Şeyler

Emiliano Montesdeoca — Fri, 03 Apr 2026 00:00:00 +0000

Bu yazı otomatik olarak çevrilmiştir. Orijinal için buraya tıklayın.

Erken Semantic Kernel ve AutoGen günlerinden bu yana Agent Framework yolculuğunu takip ediyorsanız, bu gelişme önemli. Microsoft Agent Framework 1.0 sürümüne ulaştı — üretime hazır, kararlı API’lar, uzun vadeli destek taahhüdü. Hem .NET hem de Python için mevcut ve gerçek iş yükleri için gerçekten hazır.

Duyuru gürültüsünü bir kenara bırakarak, .NET ile AI destekli uygulamalar geliştiriyorsanız önemli olan şeylere odaklanayım.

Özet

Agent Framework 1.0, eski Semantic Kernel ve AutoGen’i tek, açık kaynaklı bir SDK’da birleştirir. Tek bir agent soyutlaması. Tek bir orkestrasyon motoru. Birden fazla AI sağlayıcısı. Kurumsal desenler için Semantic Kernel ile araştırma düzeyindeki çoklu-agent iş akışları için AutoGen arasında gidip geliyorsanız, buna son verebilirsiniz. Artık tek SDK bu.

Başlamak neredeyse haksız derecede kolay

İşte .NET’te çalışan bir agent:

// dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry;
using Azure.Identity;

var agent = new AIProjectClient(endpoint: "https://your-project.services.ai.azure.com")
 .GetResponsesClient("gpt-5.3")
 .AsAIAgent(
 name: "HaikuBot",
 instructions: "You are an upbeat assistant that writes beautifully."
 );

Console.WriteLine(await agent.RunAsync("Write a haiku about shipping 1.0."));

Bu kadar. Birkaç satırla Azure Foundry üzerinde çalışan bir AI agentınız var. Python karşılığı da aynı derecede özlü. İlerlediğinizde function araçları, çok turlu konuşmalar ve streaming ekleyin — API yüzeyi tuhaflaşmadan büyür.

Çoklu-agent orkestrasyonu — işte asıl konu bu

Tek agentlar demolar için güzel, ama üretim senaryoları genellikle koordinasyon gerektirir. Agent Framework 1.0, Microsoft Research ve AutoGen’den gelen savaşta test edilmiş orkestrasyon desenlerini içerir:

Sequential (Sıralı) — agentlar sırayla işler (yazar → gözden geçiren → editör)
Concurrent (Eş zamanlı) — birden fazla agenta paralel olarak yayıl, sonuçları birleştir
Handoff (Devir teslim) — bir agent, niyete göre başka birine devreder
Group chat (Grup sohbeti) — birden fazla agent tartışır ve bir çözümde uzlaşır
Magentic-One — MSR’den araştırma düzeyindeki çoklu-agent deseni

Tümü streaming, checkpointing, human-in-the-loop onayları ve duraklat/devam et özelliklerini destekler. Checkpointing kısmı kritik — uzun süreli iş akışları süreç yeniden başlatmalarını atlatır. Azure Functions ile dayanıklı iş akışları geliştirmiş .NET geliştiricileri için bu tanıdık hissettiriyor.

En önemli özellikler

Bilmeye değer şeylerin kısa listesi:

Middleware kancaları. ASP.NET Core’un middleware pipeline’ları var ya? Aynı kavram, ama agent yürütmesi için. Her aşamayı yakalayın — içerik güvenliği, loglama, uyumluluk politikaları ekleyin — agent prompt’larına dokunmadan. Agentları kurumsal düzeyde hazır kılmanın yolu budur.

Takılabilir bellek. Konuşma geçmişi, kalıcı anahtar-değer durumu, vektör tabanlı erişim. Backend’inizi seçin: Foundry Agent Service, Mem0, Redis, Neo4j veya kendinizinkini yazın. Bellek, durumsuz bir LLM çağrısını gerçekten bağlamı hatırlayan bir agenta dönüştüren şeydir.

Bildirimsel YAML agentları. Agentınızın talimatlarını, araçlarını, belleğini ve orkestrasyon topolojisini sürüm kontrollü YAML dosyalarında tanımlayın. Tek bir API çağrısıyla yükleyin ve çalıştırın. Bu, kod yeniden dağıtmadan agent davranışını yinelemek isteyen ekipler için oyun değiştiricidir.

A2A ve MCP desteği. MCP (Model Context Protocol), agentların harici araçları dinamik olarak keşfetmesine ve çağırmasına izin verir. A2A (Agent-to-Agent protokolü), çalışma zamanları arası işbirliğini mümkün kılar — .NET agentlarınız diğer framework’lerde çalışan agentlarla koordinasyon kurabilir. A2A 1.0 desteği yakında geliyor.

Takip etmeye değer önizleme özellikleri

Bazı özellikler 1.0’da önizleme olarak yayımlandı — işlevsel ama API’lar gelişebilir:

DevUI — agent yürütmesini, mesaj akışlarını ve araç çağrılarını gerçek zamanlı olarak görselleştirmek için tarayıcı tabanlı yerel hata ayıklayıcı. Application Insights gibi ama agent muhakemesi için.
GitHub Copilot SDK ve Claude Code SDK — Copilot veya Claude’u doğrudan orkestrasyon kodunuzdan agent harness’i olarak kullanın. Kod yazabilen bir agentı aynı iş akışındaki diğer agentlarla birleştirin.
Agent Harness — agentlara shell, dosya sistemi ve mesajlaşma döngülerine erişim sağlayan özelleştirilebilir yerel çalışma zamanı. Kodlama agentları ve otomasyon desenlerini düşünün.
Skills — agentlara kullanıma hazır yapılandırılmış yetenekler sunan yeniden kullanılabilir alan yetkinliği paketleri.

Semantic Kernel veya AutoGen’den geçiş

Mevcut Semantic Kernel veya AutoGen kodunuz varsa, kodunuzu analiz eden ve adım adım geçiş planları üreten özel geçiş asistanları mevcuttur. Semantic Kernel geçiş rehberi ve AutoGen geçiş rehberi her şeyi adım adım anlatıyor.

RC paketlerindeyseniz, 1.0’a yükseltme sadece bir sürüm güncellemesidir.

Sonuç

Agent Framework 1.0, kurumsal ekiplerin beklediği üretim mihenk taşıdır. Kararlı API’lar, çoklu sağlayıcı desteği, gerçek ölçekte çalışan orkestrasyon desenleri ve hem Semantic Kernel hem de AutoGen’den geçiş yolları.

Framework GitHub’da tamamen açık kaynak ve dotnet add package Microsoft.Agents.AI ile bugün başlayabilirsiniz. Ellerinizi kirletmek için hızlı başlangıç rehberine ve örneklere göz atın.

“Üretimde kullanmak güvenli” sinyalini bekliyorsanız — işte bu.

Microsoft Agent Framework'te Arka Plan Yanıtları: Zaman Aşımı Kaygısına Son

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

Bu yazı otomatik olarak çevrilmiştir. Orijinal için buraya tıklayın.

o3 veya GPT-5.2 gibi akıl yürütme modelleriyle bir şeyler geliştirdiyseniz, o acıyı biliyorsunuzdur. Agent’ınız karmaşık bir görev üzerinde düşünmeye başlıyor, istemci beklemeye devam ediyor ve “bu tamam” ile “çöktü mü acaba?” arasında bir yerde bağlantınız zaman aşımına uğruyor. Tüm o emek? Gitti.

Microsoft Agent Framework yeni arka plan yanıtlarını yayınladı — ve dürüst olmak gerekirse bu, ilk günden beri var olması gereken özelliklerden biri.

Engelleyen çağrıların sorunu

Geleneksel istek-yanıt kalıbında, agent işini bitirene kadar istemciniz bekler. Hızlı görevler için bu sorunsuz çalışır. Ama bir akıl yürütme modelinden derin araştırma, çok adımlı analiz veya 20 sayfalık rapor oluşturması istediğinizde? Gerçek zamanlı dakikalar söz konusu. Bu pencerede:

HTTP bağlantıları zaman aşımına uğrayabilir
Ağ kesintileri tüm işlemi mahvedebilir
Kullanıcınız bir şeylerin olup olmadığını merak ederek dönen bir simgeye bakmak zorunda kalır

Arka plan yanıtları bunu tersine çeviriyor.

Continuation token’lar nasıl çalışır

Engellemek yerine, agent görevini başlatırsınız ve geriye bir continuation token alırsınız. Bunu bir tamirhanedeki teslimat fişi gibi düşünün — tezgahın önünde beklemezsiniz, hazır olduğunda gelirsiniz.

Akış basit:

AllowBackgroundResponses = true ile isteğinizi gönderin
Agent arka plan işlemeyi destekliyorsa bir continuation token alırsınız
Token null döndürene kadar kendi zamanlamanızda sorgulama yapın — bu, sonucun hazır olduğu anlamına gelir

.NET versiyonu şöyle:

AIAgent agent = new AzureOpenAIClient(
 new Uri("https://<myresource>.openai.azure.com"),
 new DefaultAzureCredential())
 .GetResponsesClient("<deployment-name>")
 .AsAIAgent();

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();

AgentResponse response = await agent.RunAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options);

// Tamamlanana kadar sorgula
while (response.ContinuationToken is not null)
{
 await Task.Delay(TimeSpan.FromSeconds(2));
 options.ContinuationToken = response.ContinuationToken;
 response = await agent.RunAsync(session, options);
}

Console.WriteLine(response.Text);

Agent hemen tamamlarsa (basit görevler, arka plan işleme gerektirmeyen modeller), continuation token döndürülmez. Kodunuz sadece çalışır — özel bir işlem gerekmez.

Devam ettirme özellikli streaming: asıl sihir

Sorgulama, fırlat-unut senaryoları için uygun, ama gerçek zamanlı ilerleme izlemek istediğinizde ne olur? Arka plan yanıtları aynı zamanda yerleşik devam ettirme özelliğiyle streaming’i de destekliyor.

Her streaming güncellemesi kendi continuation token’ını taşıyor. Bağlantınız streaming ortasında kesilirse, tam kaldığınız yerden devam ediyorsunuz:

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();
AgentResponseUpdate? latestUpdate = null;

await foreach (var update in agent.RunStreamingAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options))
{
 Console.Write(update.Text);
 latestUpdate = update;
 break; // Ağ kesintisini simüle et
}

// Tam kaldığımız yerden devam et
options.ContinuationToken = latestUpdate?.ContinuationToken;
await foreach (var update in agent.RunStreamingAsync(session, options))
{
 Console.Write(update.Text);
}

Agent, istemcinizde ne olursa olsun sunucu tarafında işlemeye devam ediyor. Bu, retry mantığı veya circuit breaker yazmadan yerleşik hata toleransı demek.

Bunu gerçekten ne zaman kullanmalısınız

Her agent çağrısının arka plan yanıtlarına ihtiyacı yok. Hızlı tamamlamalar için gereksiz yere karmaşıklık ekliyor olursunuz. Ama bunların parlattığı durumlar şunlar:

Karmaşık akıl yürütme görevleri — çok adımlı analiz, derin araştırma, bir akıl yürütme modelinin gerçekten düşünmesi gereken her şey
Uzun içerik üretimi — ayrıntılı raporlar, çok bölümlü belgeler, kapsamlı analizler
Güvenilmez ağlar — mobil istemciler, edge dağıtımlar, kararsız kurumsal VPN’ler
Asenkron UX kalıpları — görevi gönder, başka bir şey yap, sonuçlar için geri gel

Kurumsal uygulamalar geliştiren .NET geliştiricileri olarak bizim için özellikle son madde ilginç. Kullanıcının karmaşık bir rapor talep ettiği bir Blazor uygulaması düşünün — agent görevini başlatırsınız, ilerleme göstergesi gösterirsiniz ve kullanıcının çalışmaya devam etmesine izin verirsiniz. WebSocket karmaşası yok, özel kuyruk altyapısı yok, sadece bir token ve bir sorgulama döngüsü.

Sonuç

Arka plan yanıtları Microsoft Agent Framework üzerinden şu anda hem .NET hem de Python’da mevcut. Basit soru-cevabın ötesinde herhangi bir şey yapan agent’lar geliştiriyorsanız, bunu araç kutunuza eklemeye değer. Continuation token kalıbi, gerçek bir üretim sorununu çözerken işleri basit tutuyor.

Tam API referansı ve daha fazla örnek için belgelere bakın.