Bir Windows ajanı seans ortasında sessizce çöktü. Görevleri ark-delegator üzerinden yönlendiriyordu; WSL'de yaşayan çapraz ortam köprüsü. Ancak arkasındaki MCP sunucusu, OpenCode'un son daemon yeniden başlatmasıyla çökmüştü, çünkü bir eklenti olarak kaydedilmişti. Aynı süreç. Aynı hata. Aynı veri kaybı. Süreç tablosunu kontrol ettiğimde, ark-memory hâlâ 8102 portunda çalışıyordu. ark-exec 8101'de sağlıklıydı. Tüm MCP sunucuları ayaktaydı; çünkü systemd tarafından yönetiliyorlardı, OpenCode tarafından değil. Eklenti ölmüştü çünkü eklentiler ajanın süreci içinde yaşar. MCP sunucuları ise bağımsızdı. O gün MCP sunucularını eklenti olarak görmeyi bıraktım.
Üç katmanlı bir yapı kurduk: odaklanmış MCP sunucuları (her biri 3-8 araç), bir CLI köprüsü (server-commands-rtk ile RTK filtreleme ve audit loglama) ve hibrit dağıtım (ajan seviyesinde karar verme). MCP sunucuları, yapılandırılmış işlemler için kullanılıyor; hafıza, arama, CRUD gibi. CLI köprüsü ise ad-hoc komutlar, küçük çıktılı işlemler ve yan etkiler için. Örneğin, 'git push origin main' gibi bir komut ~50 token ile çalışırken, MCP ile aynı işlemin şema yükü yoktur. Bu hibrit yapı, her iki dünyanın avantajlarını birleştiriyor: MCP'nin yapılandırılmış çıktısı ve CLI'nin düşük ek yükü.
MCP sunucularının bağımsız yaşam döngüsü, onları eklentilerden ayıran en kritik özellik. Bir eklenti, ana süreçle birlikte ölür ve yeniden başlatıldığında soğuk önbellek ve boş bağlantı havuzlarıyla başlar. MCP sunucuları ise kendi süreçlerinde çalışır; istemci kopsa bile hizmet vermeye devam eder. Örneğin, oh-my-mcp yapılandırmasında altı MCP sunucusu var: ark-exec, ark-memory, ark-resolve, mempalace, ark-gist ve ark-delegator. Her biri ayrı bir portta dinler ve systemd tarafından denetlenir. Toplam şema yükü ~8.000-10.000 token, tek bir GitHub MCP sunucusundan daha az. Bu, ajanın yalnızca ihtiyaç duyduğu şemaları yüklemesini sağlar.
Sistem Güvenliği
Token optimizasyonu kritik bir avantaj. Örneğin, npm paket indirme sayısını kontrol etmek için MCP aracı 170 token ve 3 alan kullanırken, ham CLI çıktısı 2.000+ token (RTK filtreleme ile ~400) tüketir. MCP aracı 2,4 kat daha ucuzdur. Haftada binlerce benzer kontrolde bu fark önemli hale gelir. Öte yandan, 'git push' gibi komutlar için CLI sıfır şema yüküyle aynı sonucu verir. Kural: Çıktının bilinen bir şeması varsa araç oluştur, komut küçük bir eylemse ham olarak çalıştır.
Teknik Analiz
Audit loglama, MCP vs CLI tartışmasında sıkça gözden kaçan bir nokta. server-commands-rtk, her komutu yapılandırılmış bir JSON formatında kaydeder: zaman damgası, komut, çıkış kodu, süre ve RTK filtresi kullanımı. Bu, MCP'nin yapılandırılmış I/O'su ile aynı uyumluluk yüzeyini sağlar. Fark mimaridir: loglama köprü katmanında yapılır, protokol katmanında değil. Bu, audit ihtiyacı olan ekipler için MCP'nin şart olmadığını gösterir.
Detaylar ve Etkileri
Pratik çıkarım: AI ajan iş akışlarında tek bir model seçmek yerine hibrit bir yaklaşım benimseyin. Sık kullanılan, yapılandırılmış işlemler için MCP sunucuları kurun; bağımsız yaşam döngüsü sayesinde dayanıklılık kazanın. Ad-hoc komutlar ve küçük çıktılar için CLI köprüsü kullanın; token maliyetini düşürün. Audit loglama için köprü katmanında yapılandırılmış log tutun. Bu üç katmanlı yapı, hem esneklik hem de sağlamlık sağlar. Plugin modelinden kaçının; çünkü süreç bağımlılığı veri kaybına yol açar. MCP sunucularını systemd gibi bir süpervizörle yönetin; böylece her biri bağımsız olarak yeniden başlatılabilir.
Kaynak: dev.to
