MCP mi CLI mi? AI Ajanlarında Hibrit Mimari Dersi
Bir eklenti çöktüğünde MCP sunucuları neden ayakta kaldı? MCP ile CLI'yi birlikte kullanan hibrit ajan mimarisi, token maliyeti ve kalıcılık dersleriyle anlatılıyor.
Bir OpenCode ajanının eklenti olarak kayıtlı MCP köprüsü, ana sürecin yeniden başlatılmasıyla birlikte çökerken, systemd tarafından bağımsız süreçler olarak yönetilen diğer altı MCP sunucusu (bellek, arama, GitHub işlemleri gibi) hiç etkilenmedi. Bu olay, MCP sunucularını eklenti gibi ana sürece gömmek yerine bağımsız yaşam döngüsüne sahip servisler olarak çalıştırmanın kritik önemini ortaya koydu: eklenti ana sürecin ölümünü miras alırken, MCP sunucusu kendi durumunu yönetir ve istemci bağlantısı kesilse bile ayakta kalır.
Ekip, bu deneyimden sonra üç katmanlı bir hibrit mimariye geçti. Sık kullanılan, yapılandırılmış işlemler (bellek sorgulama, semantik arama, CRUD) için 3-8 araçlı odaklı MCP sunucuları kullanılıyor; toplam şema yükü tek bir GitHub MCP sunucusundan bile düşük kalıyor. Ad-hoc komutlar ve yan etkili işlemler için ise token filtreleme (RTK) ve değiştirilemez denetim kaydı sunan bir CLI köprüsü (server-commands-rtk) devrede. Karar kuralı basit: çıktının bilinen bir şeması varsa MCP aracı inşa et, komut küçük çıktılı bir eylemse ham CLI çalıştır.
Ölçümler bu ayrımı doğruluyor: yapılandırılmış bir paket indirme sorgusu MCP aracıyla ham/filtreli CLI'ye göre 2-12 kat daha az token harcarken, git push gibi basit eylemlerde şema yükü olmadan ham CLI daha ucuz kalıyor. Denetim kaydı ise MCP protokolüne değil, köprü katmanına bağlı olduğundan; uyumluluk gereksinimleri MCP kullanmadan da karşılanabiliyor. Sonuç, MCP-CLI tartışmasının aslında yanlış çerçevelendiğini gösteriyor: gerçek ayrım protokol değil, tek süreçli mimariye karşı bağımsız süreçli mimaridir.