Merkezi Sunucusuz Çoklu ajan filosu nasıl oluşturulur?

Çoklu ajan mimarilerinin çoğu aynı modeli takip eder: bir koordinatör, görevleri merkezi bir hub üzerinden çalışanlara dağıtır. Bu hub genellikle bir mesaj kuyruğu, paylaşılan bir veritabanı ya da Ray ve Temporal gibi bir orkestrasyon hizmeti olabilir.

Ancak bu hub, sistemin ilk kırılma noktasıdır. Tek bir hata kaynağı, ölçeklenebilirlik sınırlayıcısı ve ajanlar çalışmadığında bile devam eden operasyonel bir maliyet oluşturur. Peki, merkezi bir ara birime ihtiyaç duymadan ajanların birbirini doğrudan bulabildiği ve görevleri yönlendirebildiği bir filo nasıl inşa edilir?

Merkezi Hub’ın Getirdiği Sorunlar

Beş ajanla başlayan bir prototipte, merkezi bir koordinatör basit ve anlaşılır bir çözümdür. Hata ayıklama süreci kolaydır ve sistemin çalışmasını engellemez.

Ancak ajan sayısı 50’ye ulaştığında, hub sorun yaratmaya başlar. 500’e çıktığında ise sistemin en hassas bileşeni haline gelir. Hub artık küresel bir kilit görevi görür:

• Tüm mesajlar hub üzerinden geçer.
• Herhangi bir hatanın etkisi tüm sisteme yayılır.
• Ölçeklendirme kararları, hub’ın kapasitesine bağımlı hale gelir.

Öte yandan, ajanların birbirini doğrudan bulması ve iletişim kurması cazip görünse de, uygulanması tarihsel olarak zor olmuştur. Peki, ajan A, ajan B’nin adresini nasıl bilecek? NAT geçiş sorununu nasıl çözeceksiniz? Bağlantıları nasıl doğrulayacaksınız?

Bu sorunlar aslında ağ katmanında uzun süredir çözülmüş durumda. Sadece çözümler çoklu ajan sistemlerine uygulanmamıştı — ta ki şimdiye kadar.

OSI Katman 5’te Eşler Arası İletişim

Pilot Protokolü, OSI modelinin 5. katmanında, yani web için TLS’in bulunduğu aynı seviyede çalışır. Bu protokol, her bir ajana aşağıdaki özellikleri sunar:

• Kalıcı 48-bitlik bir adres (0:A91F.0000.7C2E)
• Otomatik NAT geçişi (STUN ile delik açma ve simetrik NAT’ler için aktarım düğümü yedekleme)
• Uçtan uca şifrelenmiş tüneller (X25519 anahtar değişimi, AES-256-GCM, Ed25519 kimlik doğrulama)
• Küresel bir dizin hizmeti (backbone) aracılığıyla ajan keşfi

Pilot’da hub, sizin çalıştırdığınız bir sunucu değil — ağın kendisidir. Ve bu ağ, protokol tarafından yönetilir, operasyon ekibiniz tarafından değil.

Gerçekten İşe Yarayacak Bir Filo Modeli

Bir araştırma filosu için somut bir model şu şekilde çalışır:

Koordinatör ajan ↓ Pilot (Eşler arası, şifreli) [Uzman A] [Uzman B] [Uzman C] ↓ ↓ ↓ Makale verileri Döviz verileri Haber akışları

Her uzman ajan, başladığında yeteneklerini Pilot backbone’una kaydeder. Koordinatör, backbone’a sorguda bulunur — "Akademik alıntıları çözümleyebilecek bir ajan adresi ver" — ve Uzman A’nın adresini alır. Doğrudan bağlantı buradan başlar.

Artık bakımını sizin yaptığınız bir hizmet kaydı, sabit adresler veya çalışan bir ajan taşındığında güncellenmesi gereken yapılandırma dosyaları yok.

Kodla Uygulama

Bir ajanı çevrimiçi hale getirmek için sadece aşağıdaki komutu çalıştırmanız yeterli:

curl -fsSL  | sh pilotctl daemon start --hostname coordinator

Bu komut, ajanı adreslenebilir, doğrulanabilir ve NAT, güvenlik duvarı ya da bulut bölgesi fark etmeksizin herhangi bir Pilot peer’inden erişilebilir hale getirir.

Uzman ajanlar için ise:

# Her çalışan düğümde
pilotctl daemon start --hostname specialist-papers
pilotctl daemon start --hostname specialist-fx
pilotctl daemon start --hostname specialist-news

Her ajan otomatik olarak backbone’a katılır. Koordinatör, ajanlara doğrudan erişebilir:

pilotctl ping specialist-papers
# ✓ Yanıt alındı: 0:4B2E.0000.1A3D · 22ms

Kendiliğinden Örgütlenme: Grupların Çalışma Biçimi

Bireysel eşler arası bağlantılarının ötesinde, Pilot gruplar kavramını destekler — ajanların paylaşılan bir alana göre kendiliğinden örgütlendiği kümeler.

Bir ticaret filosu, TRADING grubunu oluşturabilir. Bir araştırma filosu ise RESEARCH grubuna katılabilir. Gruptaki ajanlar, tüm üyelerine yayın yapabilir ya da alandaki en ilgili ajana görev yönlendirebilir.

Bu yaklaşım, insan organizasyonlarına daha çok benziyor: yeni bir çalışan şirkete katıldığında, tüm departmandaki meslektaşlarına doğrudan erişime sahip olur — sadece her şeyi aktarması gereken tek bir yöneticiye değil.

Pilot ağ durum sayfasında Polo.pilotprotocol.network gerçek zamanlı olarak BACKBONE, TRAVEL, TRADING, RESEARCH, INSURANCE gibi gruplar ve ajan sayıları görüntülenebilir.

Vazgeçmeniz Gerekenler

Merkezi orkestrasyonun bazı avantajları vardır. Eşler arası modele geçerken aşağıdakilerden vazgeçmeniz gerekir:

• Gözlemlenebilirlik: Merkezi bir hub, araçlarla kolayca izlenebilir. Eşler arası bir ağda ise dağıtık izleme sistemlerine ilk günden itibaren ihtiyaç duyarsınız. Bu planlamayı erkenden yapın.

• Hata ayıklanabilirlik: Bir şeyler ters gittiğinde, "Zaman T’de mesaj kuyruğunun durumu neydi?" sorusuna cevap vermek, "Eşler arası grafiğin durumu neydi?" sorusundan daha kolaydır. Ajanda yoğun loglama uygulayın.

• Basitlik: Üç ajanla başlayan bir prototipte, koordinatör basittir. Eşler arası modelin karmaşıklığı, ölçeklenmeyle birlikte anlam kazanır.

Ne Zaman Geçiş Yapmalısınız?

Merkezi bir mimariden eşler arası modele geçiş yapmanın zamanı genellikle düşündüğünüzden daha geç, ancak istediğinizden daha erken olabilir. İşte bu geçiş için sinyaller:

• Koordinatörün güvenilirliği için mühendislik ekibinizin önemli miktarda zaman harcadığı durumlar
• Farklı bulut bölgelerindeki ajanların merkezi sunucu üzerinden gecikme maliyeti ödediği durumlar
• Farklı operatörlerden ajanların, birbirlerinin altyapısına erişim vermeden işbirliği yapmasını istediğiniz durumlar
• Filonun hızla büyümesi ve merkezi bir engelin ölçeklendirme tartışmasını tetiklediği durumlar

Yukarıdaki durumlardan ikisi veya daha fazlası geçerliyse, OSI katman 5 yaklaşımına yatırım yapmanın zamanı gelmiş demektir.

Geleceğe bakıldığında, çoklu ajan sistemlerinde merkezi olmayan mimarilerin benimsenmesiyle birlikte, ölçeklenebilir, güvenilir ve esnek sistemlerin inşa edilmesi kolaylaşacak. Pilot Protokolü gibi yenilikçi çözümler, bu dönüşümde kilit rol oynayabilir. Sistemlerinizin karmaşıklığını azaltmak ve güvenlik açıklarını en aza indirmek için eşler arası iletişim modellerini değerlendirmek, geleceğin teknoloji mimarilerinin temel taşlarından biri olabilir.