OpenClaw'ı tek bir asistandan çok rollü işbirlikçi bir işletim sistemine dönüştürmek için uzun zaman harcadım. Bu sadece "birkaç bot açıp ayrı ayrı sohbet etmek" değil.
5 AI rolü, tek bir geçidi paylaşıyor, Discord ve Telegram çift kanalında çalışıyor, net bir iş bölümü, yönlendirme, bellek izolasyonu ve iş birliği kuralları ile bir ekip gibi röle yaparak çalışabiliyor.
Bu yazıda, tüm inşa sürecini, her katmandaki tasarım kararlarını, belirli konfigürasyonları ve karşılaştığım tuzakları adım adım anlatıyorum.
Eğer siz de OpenClaw kullanıyorsanız veya "birden çok AI'ın gerçekten nasıl iş birliği yapmasını sağlarım" konusuyla ilgileniyorsanız, bu yazı size birçok dolambaçlı yoldan kurtulmanızda yardımcı olacaktır.
Sonuç Önce: Bu "çok botlu" değil, tek bir Gateway altında çoklu ajan işletim sistemidir.
Birçok kişi "5 AI rolü" duyduğunda ilk tepkisi şu oluyor: 5 tane bağımsız bot çalıştırıyorsun, değil mi?
Evet, ama aynı zamanda hayır.
Mimari şu şekilde:
- 1 Gateway süreci, kanal erişimini ve yönlendirmeyi birleştiriyor
- 5 bağımsız Ajan: Komutan, Stratejist, Mühendis, Yaratıcı, Düşünür
- Her Ajanın kendi bağımsız çalışma alanı var (kişilik, kurallar, bellek ve oturumların tümü izole)
- Discord + Telegram çift kanalı aynı anda çalışıyor (birçok platform çalıştırılabilir, ancak ben yalnızca Discord kullanıyorum), hassas mesaj dağıtımı için bağlamalar (bindings) kullanılıyor
- Özel ve grup sohbetleri tamamen farklı mekanizmalar kullanıyor
Bir benzetme: Bu, 5 kişiyi işe alıp bir odaya atıp serbestçe hareket etmelerine izin vermek değil. Bu bir şirket kurmak—bir organizasyon yapısı, iş tanımları, iletişim protokolleri, bağımsız ofisler ve toplantı kuralları ile.
OpenClaw'ın kendisi, birden çok platformu (Discord, Telegram, WhatsApp, vb.) ve birden çok modeli (Claude, GPT, Gemini, vb.) destekleyen, verileri tamamen yerelleştirilmiş, açık kaynaklı bir kişisel AI asistan çerçevesidir.
Çoklu ajan yeteneği, onu seçmemin temel nedenidir—yerel olarak çoklu ajan bağımsız çalışma alanlarını + bağlamalar yönlendirmesini destekler, bu da üzerine gerçek bir iş birliği sistemi kurmamı sağladı.
1. Genel Mimari: Tek Gateway + Çoklu Ajan + Çoklu Çalışma Alanı + Çoklu Kanal
Öncelikle, en alt seviyedeki mimari kararlardan bahsedelim.
1) Tek Gateway ile Birleşik Barındırma
Şu anda tüm yetenekleri taşıyan tek bir OpenClaw Gateway sürecim var—mesaj erişimi, yönlendirme, oturum yönetimi, araç çağrıları, bellek indeksleme ve durum yönetimi, hepsi tek bir geçitte.
Neden her rol için bir dizi hizmet çalıştırmıyorum? Üç nedeni var:
- Merkezi bakım: Bakımı yapılacak yalnızca bir Gateway var, her rol için bağımsız hizmetler çalıştırmaya gerek yok.
- Birleşik yapılandırma: Tek bir ana yapılandırma, genel stratejileri yönetir ve izleme/sorun giderme de merkezileştirilir.
- İş birliği temeli: Rollerin iş birliği yapabilmesi için verimli iletişim kurabilmeleri adına aynı çalışma zamanında olmaları gerekir.
2) 5 Gevşek Bot Değil, 5 Paralel Ajan
Benim 5 sabit rolüm:
- Komutan (zongzhihui): Genel durum farkındalığı, görev ayrıştırma, atama, düzeltme ve kapatma.
- Stratejist (junshi): Stratejik analiz, teklif değerlendirme ve risk tahmini.
- Mühendis (engineer): Teknik yürütme, kod uygulama ve sistem bakımı.
- Yaratıcı (creator): İçerik oluşturma, ifade optimizasyonu ve harici çıktı.
- Düşünür (zhiku): Bilgi denetimi, kalite kontrol ve uyumluluk kontrolleri.
Her ajanın kendi çalışma alanı vardır, örneğin workspace-engineer, workspace-junshi, vb. Kişilik dosyaları, kural dosyaları, bellek dosyaları ve betik varlıklarının tümü bağımsızdır ve birbirlerini kirletmezler.
3) Çok Kanallı Çift Yığın Erişimi: Discord + Telegram
Aynı Gateway, hem Discord'a hem de Telegram'a bağlıdır. Her rolün her iki kanalda da accountId düzeyinde bağlamaları vardır. Elbette, aynı yapılandırma dosyasını Lark, WeChat vb. gibi daha fazla platformu entegre etmek için de kullanabilirsiniz.
Bu "platformlar arası çoğaltılmış dağıtım" değil, "aynı beyin kümesi, farklı erişim katmanları"dır. Discord'u ana iş birliği savaş alanı olarak yapılandırdım.
Birden çok ajanın bir grupta iş birliği yapmasını ve birlikte çalışmasını istiyorsanız, sadece Discord'u seçin; tek bir platform yeterlidir. Diğerleri mükemmel değil, denedim!!!
2. Yönlendirme Katmanı: Bağlamalar "Hesapları" "Rollere" Eşler
Bu, tüm sistemin giriş mantığıdır.
Çift kanal için açık bir bağlama stratejisi yapılandırdım: kanal + accountId -> agentId.
Spesifik olarak:
discord + zongzhihui -> zongzhihuidiscord + engineer -> engineertelegram + creator -> creator- ... toplam 10 eşleme (5 rol × 2 kanal)
Neden böyle yapıyorum?
Çünkü sistem, "bu mesajı kim işlemeli" kararını giriş katmanında verir, tüm ajanların duymasını ve ardından cevaplamak için birbirleriyle yarışmasını beklemez. Bu adım iyi yapılmazsa, sonraki tüm iş birliği kaotik olur.
Bağlamaları bu sistemin "ön büro triyajı" olarak düşünebilirsiniz. Bir mesaj geldiğinde, önce hangi kanal ve hesap tarafından alındığını kontrol eder, ardından doğrudan ilgili role yönlendirir—temiz ve verimli.
3. Oturum İzolasyonu: Özel Sohbetler Neden Kesişmez ve Grup Sohbetleri Neden Karışmaz
Bu, sistemimdeki en kritik mühendislik noktalarından biridir.
Temel yapılandırma: session.dmScope = per-account-channel-peer
Bu parametre şu anlama gelir: Özel sohbet bağlamı, "hesap + kanal + eş kullanıcı" olmak üzere üç boyutta izole edilir.
Neden bunu seçtim?
- Aynı kişi aynı rolle Discord ve Telegram üzerinden iletişime geçerse, bağlamlar birbirine karışmaz.
- Farklı kullanıcılar aynı rolle iletişime geçerse, bağlamlar tamamen izole olur.
- Çoklu ajan + çoklu hesap senaryolarında "çapraz konuşma" riski en aza indirilir.
Başka bir deyişle, sadece "çoklu roller" oluşturmadım; aynı zamanda "bağlam izolasyon stratejisi mühendisliği" de yaptım.
Birçok kişi çoklu ajan sistemleri kurar, roller net bir şekilde ayrılır, ancak bağlam yönetimi berbat bir hal alır—Kullanıcı A'nın özel sohbet içeriği Kullanıcı B'nin yanıtında ortaya çıkar veya Discord konuşma belleği Telegram bağlamını kirletir.
per-account-channel-peer, OpenClaw tarafından çoklu hesap senaryoları için önerilen izolasyon stratejisidir ve testlerim, gerçekten de en kararlı seçenek olduğunu gösteriyor.
4. Grup Sohbeti Orkestrasyonu: Kural Güdümlü İş Birliği, Serbest Sohbet Değil
Bu kısım en ilginç olanı ve aynı zamanda en çok tuzağın bulunduğu kısım.
Temel Strateji: Komutan Küresel Dinleme + Diğer Roller @ Tetikleme
Discord tarafındaki grup sohbeti stratejim şöyledir:
Komutan: requireMention = false (Küresel dinleme)
- Gruptaki tüm mesajları varsayılan olarak görebilir.
- Genel durumu kavramaktan, iş birliğinin gerekli olup olmadığına karar vermekten, görev ayrıştırması yapmaktan ve iş atamaktan sorumludur.
Diğer 4 Rol: `requireMention = true` (@ Tetikleme)
- Yalnızca açıkça @ ile anıldıklarında harekete geçerler.
- Gürültüyü azaltır ve birbirlerinin sözünü kesmelerini önler.
Her role `mentionPatterns` yapılandırıldı
- Örneğin, mühendis
@Engineerveya[@engineer](https://x.com/@engineer)ile tetiklenebilir. - Grupta çağırmayı daha istikrarlı ve öngörülebilir kılar.
Bu kombinasyonun özü nedir?
- Komutan "büyük resmi görür," tıpkı bir ekipteki PM gibi.
- Uzmanlaşmış roller "ihtiyaç duyuldukça tetiklenir," tıpkı çeşitli pozisyonlardaki uzmanlar gibi.
- Grup konuşması "serbest biçimden" "kontrollü röleye" dönüşür.
Gerçek etki: Grupta bir soru sorarsınız, Komutan önce ne tür bir görev olduğunu değerlendirir, ardından ilgili rolü halletmesi için @ ile anar. Rol işi bitirdiğinde, Komutan döngüyü kapatır. Tüm süreç, gerçek bir ekibin toplantı yapması gibidir.
5. Discord vs Telegram: Discord Neden Ana Savaş Alanı
Kesin olarak söylemek gerekirse, "yalnızca Discord iş birliği yapabilir" değil. Sadece benim mevcut yapılandırmam altında, Discord çok rollü kamusal iş birliği orkestrasyonu için en uygun olanıdır.
Spesifik nedenler:
- Discord'da 5 paralel hesap + net bir @iş birliği mekanizması yapılandırdım.
- Rol kimlikleri, konuşma zincirleri ve röle süreci görünür—bir ekip tartışması gibi görünür.
- Komutanın küresel dinleme + diğer rollerin bahsetme geçidi stratejisi, grup sohbeti senaryolarında daha sezgiseldir.
- Şu anda Discord
groupPolicydeğeriniopenolarak ayarladım, bu da daha yüksek esneklik sunar.
Telegram tarafında ise stratejim daha çok allowlist + mentionGate yönünde, bu da daha kısıtlı ve güvenlidir, "kontrollü üretim kanalları" için uygundur.
Yani özetle: Discord iş birliği sahnesidir.
6. Yapılandırma Katmanı + Komut Katmanı: Çift Yönlü Yönetişim
Bu, bu sistemi "sadece oyuncakla uğraşmaktan" ayıran en büyük farktır.
Yalnızca yapılandırmaya veya yalnızca Komutlara (Prompt) güvenmiyorum. İki örtüşen yol kullanıyorum.
A. Yapılandırma Yolu (Platform Düzeyinde Kontrol)
Bunlar, OpenClaw platform düzeyindeki sabit yapılandırmalardır:
- kanal politikası:
groupPolicy,dmPolicy, grup ve özel sohbetler için temel stratejileri kontrol eder. requireMention: Varsayılan olarak yanıt vermek için kimin @ ile anılması gerektiği.bindings: Mesaj yönlendirme eşlemesi.dmScope: Oturum izolasyonu ayrıntı düzeyi.agentToAgentping-pong sınırı: Bunu 0 olarak ayarladım ve ajanlar arasındaki anlamsız gidip gelmeleri doğrudan bastırdım.
Sonuncusu çok önemlidir—ajanlar arası ping-pong'u sınırlamazsanız, bir grupta iki AI'ın kibarlık yaptığını, birbirleriyle onayladığını ve sonsuza kadar döngüye girdiğini görürsünüz. 0 olarak ayarlamak, sisteme şunu söyler: ajanlar otomatik olarak birbirlerine ping atmamalıdır.
B. Kural Yolu (Davranış Düzeyinde Kontrol)
Bunlar, her çalışma alanına yazdığım kural dosyalarıdır:
SOUL.md: Rolün ruh dosyası—kişilik, ton, sorumluluklar ve çıktı kalitesi tabanı.AGENTS.md: Operasyon el kitabı—iş birliği kontrol süreçleri, bellek okuma/yazma normları ve tembel yükleme stratejileri.ROLE-COLLAB-RULES.md: Role özgü iş birliği sınırları ve kırmızı çizgiler.TEAM-RULEBOOK.md: Takım için birleşik sabit kurallar (tüm roller tarafından paylaşılır).TEAM-DIRECTORY.md: Rollerin gerçek kimliklere eşleme tablosu, yanlış kişiyi @ ile anmayı önlemek için.
Bu iki yolun örtüşmesinin etkisi şudur: platform katmanı akışı sınırlar + davranış katmanı kısıtlamalar ekler.
Her şeyi modelin "öz farkındalığına" bırakmak değildir. Modeller hata yapar, kayar ve kuralları unutur. Bu nedenle, önce yapılandırma katmanında sabit kısıtlamalar, ardından komut katmanında yumuşak yönlendirme ayarlanmalıdır. Çifte garanti.
7. Çalışma Alanı Dosya Sistemi: Her Rolün "Bağımsız Ofisi"
Her çalışma alanının dosya iskeleti temelde tutarlıdır, bu önemlidir—bu, rastgele dosya yığmak yerine standardizasyon yaptığımı gösterir.
Standart Dosya Yapısı
Dosya | Rol |
|---|---|
SOUL.md | Rol Ruhu: Kişilik tanımı, davranış kalıpları, kalite tabanı |
AGENTS.md | Operasyon El Kitabı: İş birliği süreçleri, bellek normları, kontrol listeleri |
ROLE-COLLAB-RULES.md | İş Birliği Sınırları: Bu rolün yapabilecekleri ve yapamayacakları |
IDENTITY.md | Kimlik Tanımı: Ad, konumlandırma, yetenek kapsamı, dış ton |
USER.md | Kullanıcı Profili: Tercihler, hedefler, tabular, yaygın terminoloji |
TOOLS.md | Araç Listesi: Hangi araçlara izin verildiği, izin sınırları |
MEMORY.md | Uzun Süreli Bellek: Sabit tercihler, uzun vadeli kararlar, yeniden kullanılabilir deneyim |
GROUP_MEMORY.md | Grup Belleği: Gruptan yalnızca yeniden kullanılabilir ve güvenli bilgileri saklar |
HEARTBEAT.md | Kalp Atışı Normları: Periyodik kendi kendine kontroller, hata kurtarma, durum bakımı |
memory/YYYY-AA-GG*.md | Günlük Kayıtlar: O güne ait görev süreçleri, bağlam parçaları, yerinde kararlar |
8. Bellek Sistemi: Tembel Yükleme + Katmanlama + Arşivleme
Bellek yönetimi, çoklu ajan sistemlerinde en kolay gözden kaçan ancak en sorunlu kısımdır.
Benim stratejim "mümkün olduğunca çok hatırla" değil, net katmanlamadır:
1) Kısa Vadeli Kayıtlar (günlük bellek)
- Günün görev süreçlerini, bağlam parçalarını ve yerinde kararlarını kaydeder.
- Dosyalar tarihe göre adlandırılır, doğal olarak bir zaman çizelgesi oluşturur.
2) Uzun Süreli Bellek (MEMORY.md)
- Sabit tercihleri, uzun vadeli kararları, yeniden kullanılabilir deneyimleri ve sabit kuralları damıtır.
- Her şey girmez; yalnızca doğrulanmış, istikrarlı bilgiler yazılır.
3) Grup Uzun Süreli Belleği (GROUP_MEMORY.md)
- Gruptan yalnızca yeniden kullanılabilir ve güvenli bilgileri saklar.
- Özel sohbet içeriğini karıştırmaz; bu bir gizlilik kırmızı çizgisidir.
4) Soğuk Arşivleme (archive)
- Eski veriler periyodik olarak arşivlenir, böylece aktif bağlamın kontrolden çıkması önlenir.
- Silinmez, düşük öncelikli depolamaya taşınır.
5) Geri Çağırma Mekanizması (memory_search + memory_get)
- Önce anlamsal geri çağırma, ardından hassas okuma.
- Tam yüklemeyi önler—bağlam penceresi sınırlı bir kaynaktır ve boşa harcanamaz.
Bu katmanlamanın temel değeri:
- Özel sohbet kalitesi, grup sohbeti geçmişi tarafından kirletilmez.
- Grup iş birliği, kişisel özel bağlam tarafından engellenmez.
- Bağlam penceresi "talep üzerine yüklenir," "tamamen dökülmez."
Bağlam bütçesini bir kaynak yönetimi problemi olarak ele alıyorum. Token'lar sınırlıdır; eklenen her bellek, çıkarım alanını işgal eder. Bu nedenle, her bir parça dikkatlice hesaplanmalıdır.
9. Özel Mod vs Grup Modu: Aynı Rol İçin İki Strateji
Bu, birçok kişinin aklına gelmeyen bir şeydir: aynı rol, özel ve grup sohbetlerinde farklı davranmalıdır.
Her rolün SOUL.md dosyasında iki modu açıkça ayırt ediyorum:
Özel Mod:
- Her rol, tek başına bir uzman olarak hareket eder, kullanıcı sorunlarını uçtan uca halleder.
- İş birliği sürecine gerek yoktur; doğrudan eksiksiz yanıtlar sağlayın.
- Kalite standardı "tek kişi halledebilir"dir.
Grup Modu:
- Takım iş birliği protokollerine göre artımlı röle gerçekleştirir.
- Her rol yalnızca iyi olduğu şeyden sorumludur.
- Komutan bağlantı kurmaktan ve kapatmaktan sorumludur.
Her role özel:
- Komutan: Grupta varsayılan olarak sessiz kalır ve gözlemler, yalnızca gerektiğinde güçlü bir şekilde müdahale eder, başkalarının sözünü kesmemek için.
- Mühendis: Çıktılar çalıştırılabilir, doğrulanabilir ve geri alınabilir olmalıdır—sadece bir fikir vermek değil.
- Stratejist: Sonuçlar, varsayımlar ve doğrulama yolları ile birlikte gelmelidir—sadece akla geleni söylemek değil.
- Düşünür: Denetimler, sorun derecelendirmesi + onarım planları sağlamalıdır—sadece "bir sorun var" demek değil.
- Yaratıcı: İfade, özgünlükten ve uygulanabilirlikten ödün vermemelidir—sadece estetik peşinde koşmak değil.
"Aynı rolün farklı senaryolarda farklı performans göstermesinin" kaynağı budur. Modelin kendi yargısına güvenmez, kural dosyaları aracılığıyla açıkça söylenir.
Son Sözler
Çoklu Ajan, sadece birkaç bot daha açmak değildir. Bu, mimari tasarımdan yönlendirme stratejilerine, oturum izolasyonundan iş birliği orkestrasyonuna, bellek yönetiminden kural yönetişimine ve otomatik kontrollere kadar her katmanın dikkatle tasarlanması gereken kocaman bir mühendislik sistemidir.
OpenClaw harika bir temel sağlar, ancak "çalıştırılabilir" durumdan "iyi çalışır" duruma geçmek için gereken mühendislik miktarı, çoğu insanın hayal ettiğinden çok daha fazladır.
Eğer benzer bir şey yapıyorsanız, umarım bu yazı size bir miktar referans sağlar. Elbette, bu içerik sadece bir başlangıç; daha sonra "daha spesifik ve incelikli" konuları paylaşmak için birkaç bölüm daha yayınlayacağım.
