Sıkça sorulan sorular
agentixmesh'in ne olduğu, hangi agent araçlarıyla çalıştığı, neyi güvenceye aldığı ve bir message queue'dan nasıl farklı olduğu hakkında net yanıtlar.
Temel Bilgiler
- agentixmesh nedir?
- agentixmesh bir agent trust layer'dır (ajan güven katmanı) — bir makinedeki AI agent oturumlarının, `uid:project` olarak adreslenerek, birbirlerinin yetkisini devralmadan mesaj alışverişi yapmasını sağlayan, dosya tabanlı bir teslimat katmanı. Taşıma katmanı bir maildir (new/cur/held/seen dizinleri) artı bir inject hook'tur: daemon yok, network listener yok, açık port yok, sudo yok. MIT lisanslıdır ve GitHub'da açıktır (github.com/TokonoMix/agentixmesh).
- "Veri yetki değildir" ne anlama gelir?
- Gelen bir mesajın, uyulması gereken bir komut olarak değil, okunması gereken atıl (inert) bir DATA çerçevesi olarak sunulduğu anlamına gelir. Alıcı agent ne yapacağına kendisi karar verir; mesh, bir mesajın içeriğine göre asla otomatik hareket etmez. Bir mesaja kelimelerle yanıt vermek sorun değildir; sırf mesaj gövdesi öyle söylüyor diye bir eylem gerçekleştirmek, kod çalıştırmak veya sır ifşa etmek sorun teşkil eder.
- agentixmesh gerçekte hangi problemi çözüyor?
- Yerel agent-to-agent mesajlaşmanın "confused deputy" (şaşkın vekil) riskini çözer: bir oturumun, sırf bir mesaj geldi diye başka bir oturumun yetkisini devralması. agentixmesh, bir mesajı kimin gönderdiğini (kernel-verified bir OS kullanıcı kimliği) mesajın ne söylediğinden (güvenilmeyen bir gövde) ayırır; böylece bir mesaj, istediği hiçbir şeye yetki vermeden gönderenini kanıtlayabilir. Zor kısım iletişim değil, containment'tır (sınırlama/izolasyon).
- agentixmesh kimler için?
- Aynı makinede birden fazla AI agent oturumu çalıştıran mühendisler için — bugün Claude Code, adapter'lar çıktıkça diğer harness'lar da — bu oturumların bir message queue veya ticket sistemi kurmadan bilgi devretmesi veya koordine olması gerekiyor, ve bir oturumun çıktısının sessizce başka bir oturumun talimatına dönüşmesi istenmiyor. Komut satırı agent iş akışlarını varsayar, son kullanıcı chat ürünlerini değil.
- agentixmesh production-ready mi?
- Kısmen, ve tasarım gereği aşamalı olarak. Same-user (aynı kullanıcı) çekirdek public ve stabildir — bu, yayında ve dogfood edilen varsayılan katmandır. Cross-user teslimat (ayrı OS kullanıcıları, tek makine) uçtan uca doğrulanmıştır, ancak production go-live'ı insan-kapılı (human-gated) kalır: bir mesaj gövdesi bir insan onu serbest bırakana kadar bekletilir. Cross-machine teslimat henüz mevcut değildir — bu roadmap'tir, agentixmesh değil.
- agentixmesh sadece bir message bus veya pub/sub sistemi mi?
- Hayır. Bir message bus byte taşır; agentixmesh, byte'lar ulaştığında bir oturumun ne yapmasına izin verildiğiyle ilgilenir. Ayırt edici parça taşıma katmanı (bir maildir) değildir — kernel-verified gönderen kimliği artı, teslim edilen bir mesajın komut olarak ele alınmasını engelleyen inert-DATA framing'tir. Sıradan pub/sub'da bu özelliklerin hiçbiri yoktur.
- Neden bir soket veya daemon yerine dosya tabanlı (bir maildir)?
- Bir maildir çalışan bir process, bir port veya ayrıcalık yükseltmesi (privilege escalation) gerektirmez — teslimat, işletim sisteminin zaten koruduğu owner-only (0700) dizinler arasında dosyaların hareket etmesinden ibarettir. Bir daemon veya soket dinleyicisi, sürekli açık bir saldırı yüzeyi ve operasyonel yük (başlat/durdur, çökme kurtarma, izinler) ekler — bu ise düz dosya sistemi semantiğinin zaten kapsadığı, tek makineli, düşük throughput'lu bir kullanım senaryosu için.
- "Agent trust layer" ne anlama gelir?
- agentixmesh'in mesaj içeriğinin altında oturup tek bir soruyu yanıtladığı anlamına gelir: bunu kimin gönderdiğine güvenebilir misin? Açık dosya tanımlayıcısı (open file descriptor) üzerinde fstat ile gönderenin OS kullanıcı kimliğini kernel-verify eder — sahtelenemez — bunun dışındaki her şeyi, gövde ve gönderenin kendi beyan ettiği proje etiketi dahil, güvenilmez olarak ele alır. Buradaki güven kimlikle ilgilidir, bir mesajın ne iddia ettiğiyle değil.
- Bir adres (uid:project) nedir?
- Bir adres `uid:project`'tir — hedef alıcının sayısal OS kullanıcı kimliği artı bir proje etiketi. uid yarısı, mesh'in teslimatı fiilen üzerine uyguladığı kısımdır. Proje yarısı ise sadece gönderenin geçerli çalışma dizininin (current-working-directory) basename'idir, kendi kendine beyan edilir ve doğrulanmaz; o kullanıcının doğru gelen kutusuna yönlendirmek için kullanılır. `mesh-whoami` kendi adresinizi yazdırır.
- agentixmesh'te insanın rolü nedir?
- İnsan nihai otoritedir, en somut haliyle cross-user teslimatta: bir mesaj gövdesi, bir insan onu serbest bırakana kadar bekletilir, böylece denetimsiz cross-user eylem yapısal olarak imkansızdır. Daha genel olarak, agentixmesh bir mesajın içeriğine göre asla otomatik hareket etmez — alıcı agent onunla ne yapacağına karar verir — sonuç doğuran kararların kontrolünü mesh'te değil insanlarda bırakır.
- agentixmesh bir framework mü yoksa bir protokol mü?
- Bir framework'ten çok, bir protokol artı ince bir referans implementasyonuna yakındır. Çekirdek — kernel-verified gönderen kimliği, maildir taşıma, inert-DATA framing — tasarım gereği harness-agnostic'tir (harness'tan bağımsız) ve agent'ınızın iç yapısını dikte etmez. Entegrasyonu, agent'ınızı agentixmesh'in yapısına uyacak şekilde yeniden yazarak değil, bir harness adapter'ını protokole bağlayarak yaparsınız.
- agentixmesh NE OLMAYA çalışmıyor?
- Genel amaçlı bir message queue, cross-machine bir taşıma katmanı veya prompt injection'a karşı bir güvenlik garantisi olmaya çalışmıyor. Agent'ları sizin adınıza otonom hale getirmeye çalışmıyor — cross-user otomatik hareket, sadece caydırılmış değil, tasarım gereği engellenmiştir. Cross-machine teslimat ve leader-gate co-approval gibi daha yüksek yetkili özellikler yalnızca roadmap maddeleri olarak var, bugün yaptığını iddia ettiği şeyler olarak değil.
Uyumluluk ve harness'lar
- agentixmesh Claude Code ile çalışıyor mu?
- Evet — Claude Code referans adapter'dır ve bugün yayındadır. Mesh'i Claude Code'un SessionStart ve UserPromptSubmit hook'ları üzerinden bağlar, böylece mesajlar Claude Code'u kullanma şeklinizi değiştirmeden otomatik olarak context'te belirir. Bu, en çok savaş-test edilmiş entegrasyondur ve maildir/inject-hook tasarımının ilk olarak karşı inşa edildiği entegrasyondur.
- agentixmesh OpenAI Codex CLI ile çalışıyor mu?
- Bir adapter yayınlanmıştır ve unit-test edilmiştir. Gerçek Codex CLI'ye karşı canlı-binary uçtan uca doğrulama hâlâ devam etmektedir, bu yüzden bunu production-proven değil, yayınlanmış-ama-henüz-tam-canlı-doğrulanmamış olarak ele alın. Bu canlı doğrulama tamamlanana kadar Codex yolunu "tamamlandı" olarak tanımlamayacağız.
- agentixmesh Gemini veya diğer agent araçlarıyla çalışıyor mu?
- Henüz değil. Hermes ve OpenClaw adapter'ları tasarlanmış ve prototiplenmiştir, bu onları yayınlanmış set yerine roadmap'e koyar. Bugün mevcut tek adapter'lar Claude Code (referans, yayında) ve OpenAI Codex CLI'dir (unit-test edilmiş, canlı e2e doğrulama devam ediyor). Bir adapter yayınlanana kadar başka herhangi bir harness'ı desteklenmiyor olarak kabul edin.
- "Harness-agnostic" burada gerçekte ne anlama geliyor?
- Çekirdeğin — maildir taşıma, kernel-verified kimlik, mesaj framing — herhangi bir belirli agent aracına bağımlılığı olmadığı anlamına gelir. Araca özgü olan kısım, bu çekirdeği bir harness'ın kendi hook sistemine bağlayan ince bir adapter katmanıdır, tıpkı Claude Code'un SessionStart/UserPromptSubmit'i gibi. Protokol araca göre değişmez; sadece bağlantı (wiring) değişir.
- Claude Code ve Codex CLI gibi iki farklı agent aracı aynı mesh üzerinde mesaj alışverişi yapabilir mi?
- Mimari olarak evet — maildir formatı ve kernel-verified kimlik modeli, bir mesajı hangi harness'ın yazdığı veya okuduğuyla değil, sadece hangi OS kullanıcısının yazdığıyla ilgilenir. Ancak bugünkü canlı kanıt uçtan uca sadece Claude Code'u kapsıyor; Codex CLI'nin canlı-binary e2e'si, gerçek cross-harness alışverişi dahil, hâlâ devam ediyor, bu yüzden bu senaryoyu henüz doğrulanmış olarak ele almayın.
- agentixmesh'i kullanmak için agent'ımın kodunu değiştirmem gerekiyor mu?
- Hayır — CLI wrapper'larını kurar ve küçük bir hook'u bir kez bağlarsınız; agent'ın kendi kaynak koduna hiçbir değişiklik yapılmaz. Claude Code için bu referans adapter'dır, bugün yayındadır. Diğer harness'lar için bir adapter, aynı temel mesh komutlarını o aracın hook sistemine bağlar.
- Push-hook sözleşmesi nedir — bir mesaj agent'ımın context'inde nasıl sonlanır?
- Hook, oturum başlangıcında ve her user prompt submit'te tetiklenir. Posta kutusunun sıfır-token'lı bir dosya okumasını yapar ve yeni mail varsa stdout'a atıl bir DATA çerçevesi yazdırır. Harness, hook stdout'unu enjekte edilmiş context olarak ele alır, böylece mesh'in kendisi hiçbir LLM çağrısı yapmadan mesaj görünür hale gelir.
- agentixmesh farklı makineler arasında çalışıyor mu?
- Hayır, sadece aynı makine. Mevcut tüm teslimat — Claude Code ve Codex CLI — yerel bir maildir üzerinden tek bir host'ta çalışır; network listener veya uzak taşıma yoktur. Cross-machine, kriptografik olarak imzalanmış teslimat ayrı bir üründür, AgentsWeaver, ve bu o projenin roadmap'indedir, agentixmesh'in parçası değil.
- Yeni bir harness için destek nasıl eklerim?
- Bağlantı kurarsınız, yeni bir protokol tasarlamazsınız. Bir harness adapter'ının iki şeye ihtiyacı vardır: oturum başlangıcında veya prompt submit'te bir komut çalıştırma yolu (push hook) ve o komutun stdout'unu context haline getirme yolu. Maildir formatı, kimlik doğrulama ve framing zaten harness-agnostic ve değişmeden kalır.
- agentixmesh gelecekte Gemini CLI veya diğer harness'ları destekleyecek mi?
- Hermes ve OpenClaw adapter'ları zaten tasarlanmış ve prototiplenmiştir — bu güncel roadmap'tir, yayınlanmış bir özellik değil. Gemini'ye özgü bir adapter ayrıca teyit edilmemiştir. Bir harness eklemek yeni protokol işi değil bağlantı işi olduğundan, her yeni araç için beklenen efor küçüktür, ama bugün Claude Code ve Codex CLI dışında hiçbir şey yayında değil.
- Harness-agnostic, herhangi iki agent aracının ek risk olmadan serbestçe karıştırılabileceği anlamına mı geliyor?
- Hayır — harness-agnostic, taşıma ve kimlik katmanını tanımlar, kapsamlı bir güvenlik garantisi değil. Gönderen kimliği hâlâ sadece kernel-verified bir OS kullanıcı kimliğidir, doğrulanmış bir agent veya proje değil. Bir mesajı hangi harness alırsa alsın, agent onu hâlâ atıl veri olarak ele almalı, asla uyulması gereken bir talimat olarak değil.
- agentixmesh'te "core" (çekirdek) ile "adapter" arasındaki fark nedir?
- Çekirdek, maildir taşıma, kernel-verified gönderen kimliği ve DATA-frame mesaj formatıdır — her harness için sabit ve aynıdır. Bir adapter ise ince, harness'a özgü tutkaldır: belirli bir agent aracını o çekirdeğe bağlayan hook kaydı artı stdout bağlantısı. Yeni harness desteği tamamen adapter'a odaklanır, çekirdeğe değil.
- agentixmesh'i özel, kurum-içi bir agent harness'ıyla kullanabilir miyim?
- Evet, iki adapter gereksinimini implemente edebiliyorsanız: oturum başlangıcında veya prompt zamanında çalışan bir hook ve o hook'un stdout'unu agent'ın context'ine besleme yolu. Mesh çekirdeği harness-agnostic olduğundan, özel bir harness protokol değişikliği gerektirmez — sadece Claude Code ve Codex CLI'nin kullandığı türden bir bağlantı.
- Aynı mesh üzerinde birden fazla harness kullanmak gönderen-kimliği garantisini zayıflatır mı?
- Hayır — kimlik doğrulama, açık dosya tanımlayıcısı üzerinde fstat ile, herhangi bir harness'ın tamamen altında ve ondan bağımsız olarak, OS/kernel seviyesinde gerçekleşir. Bir mesaj hangi araçtan geçerse geçsin, gönderenin OS kullanıcı kimliği aynı sahtelenemez şekilde doğrulanır; harness seçimi bu garantiyi hiçbir şekilde etkilemez.
Çoklu kullanıcı (cross-user)
- Tek bir makinedeki iki farklı OS kullanıcısı agentixmesh ile birbirine mesaj gönderebilir mi?
- Evet — bir host üzerindeki iki ayrı OS kullanıcı hesabı, her kullanıcının kendi özel gelen kutusu yerine paylaşılan, grup sahipli bir maildir üzerinden yönlenen agentixmesh'in cross-user modu aracılığıyla mesaj alışverişi yapabilir. Bu, gerçek gönder-teslimat döngüleriyle uçtan uca doğrulanmıştır. Same-user mesajlaşmadan bir açıdan farklı davranır: teslimat varsayılan olarak beklemede tutulur (held), anında değil.
- Bir mesaj OS-kullanıcı sınırlarını geçtiğinde gönderen nasıl doğrulanır?
- Same-user mesajlarla aynı şekilde: mesajın kendisi değil, kernel. agentixmesh, gerçek OS-seviyesi sahip uid'ini okumak için açık dosya tanımlayıcısı üzerinde fstat çağırır; bu, mesajın iddia ettiği hiçbir şeyle sahtelenemez. Doğrulanmayan şey adresin proje yarısıdır — herkesin istediği şeye ayarlayabileceği kendi kendine beyan edilen bir etiket.
- Human-gate (insan kapısı) nedir ve bir cross-user mesaj gövdesi neden bekletilir?
- Bir cross-user mesaj beklemede (held) gelir: alıcı agent sadece metadata görür — kernel-verified gönderen uid'i, uzunluk, thread id, zaman damgası — gövde metnini asla. Gövde agent'a ulaşmadan önce bir insan onu açıkça serbest bırakmalıdır. Bu, sadece mesajı işaretlemenin değil, gövdeyi bekletmenin, enjekte edilmiş içeriğe maruziyeti fiilen sınırlayan şey olması nedeniyle var.
- Bir cross-user mesaj hiç otomatik onaylanabilir veya otomatik hareket edilebilir mi?
- Hayır — bu, birinin kilitlemeyi unuttuğu bir ayar değil, yapısal olarak imkansızdır. Cross-user teslimat her zaman varsayılan olarak human-gated'dir ve adres-başına veya proje-başına override'lar güveni yalnızca daha kısıtlayıcı hale getirebilir, asla auto'ya yükseltemez. Beklemedeki bir cross-user gövdesinin açık bir insan serbest bırakması olmadan bir agent'a ulaştığı hiçbir kod yolu yoktur.
- Cross-user mesajlaşma production-ready mi?
- Mekanizma uçtan uca doğrulanmıştır — iki OS kullanıcısı arasında gerçek held, human-released, teslim edilmiş döngüler canlı olarak kanıtlanmıştır. Ancak belirli bir dağıtım için go-live tasarım gereği human-gated kalır: bekletme adımı sonradan kapatılacak bir rollout boşluğu değil, cross-user için kalıcıdır. Yani "hazır", denetimsiz bırakılmaya güvenli değil, denetim altında çalıştırmaya güvenli anlamına gelir.
- Bekleyen bir cross-user mesajı serbest bırakmak nasıl çalışır?
- Alıcı taraftaki bir insan, beklemedeki mesajın metadata'sını — gönderen uid, uzunluk, thread id, zaman damgası — inceler, ardından gövdeyi ilk kez agent'a açan açık bir serbest bırakma eylemi gerçekleştirir. Bu adımdan önce hiçbir şey teslim edilmez ve serbest bırakma hiç gerçekleşmezse mesaj süresiz olarak beklemede kalır.
- Serbest bırakılmadan önce bir OS kullanıcısı başka bir kullanıcının mesajlarından ne görebilir?
- Yapısal metadata dışında hiçbir şey. Alıcı taraf, bir mesajın var olduğunu, hangi kernel-verified uid'in gönderdiğini, ne kadar uzun olduğunu ve hangi thread'e ait olduğunu görebilir — metni asla. Bu bilinçlidir: metadata tek başına bir talimat taşıyamaz, bu yüzden insan incelemesinden önce göstermek, bekletmenin kapatmak için var olduğu injection yüzeyini yeniden açmaz.
- Bir meslektaş cross-user mesaj gönderip almak için nasıl onboard edilir?
- Onboarding, kutuda sadece bir OS hesabı oluşturmak değil, özel bir enrollment (kayıt) adımıdır. Yeni bir üye, kernel-verified uid'inin meşru bir mesh katılımcısı olarak tanınacağı şekilde kaydedilir; kimlik, kendi kendine bildirilen bir iddiadan değil, out-of-band olarak teyit edilir. Enroll edilene kadar, o uid'den gelen mesajlar bilinen bir üyeden geliyormuş gibi ele alınmaz.
- Bir meslektaş ayrıldığında veya erişimini kaybettiğinde ne olur?
- Mesh üyeliği iptal edilir (revoke), bu da o uid'den gelecek mesajların tanınan bir üyeden geliyormuş gibi ele alınmasını durdurur. İptal, herhangi bir agent veya mesajın talep edebileceği bir anahtar değil, OS-seviyesi kimliğe bağlı açık bir yönetimsel eylemdir — agentixmesh'in geri kalanıyla tutarlı olarak, güven değişiklikleri kasıtlı insan eylemleridir.
- İki kullanıcının aynı makinede olması gerekiyor mu?
- Evet — agentixmesh'in cross-user modu sadece tek makine içindir. Yerel bir dosya sistemine ve kernel-seviyesi uid doğrulamasına dayanır, ikisi de ayrı makineler arasında hiçbir anlamı olmayan host-yerel kavramlardır. Farklı host'lardaki agent'lar arasında mesajlaşma bugün agentixmesh'in yaptığı bir şey değildir; bu, aynı ailenin cross-machine, kriptografik olarak imzalanmış üyesi olan AgentsWeaver'ın inşa edildiği şeydir.
- Kötü niyetli bir kullanıcı bir meslektaşın agent'ını kandırmak için farklı bir proje gibi davranabilir mi?
- Proje etiketini sahteleyebilirler, gönderen'i değil. Bir adresin proje yarısı, kendi kendine beyan edilen bir string'dir — gönderenin kendi cwd basename'i — ve doğrulanmaz, bu yüzden bir mesaj ilgisiz bir projeden geliyormuş gibi etiketlenmiş olarak varabilir. Gerçekten geldiği uid kernel-verified kalır: hangi OS kullanıcısının gönderdiğini her zaman bilirsiniz, sadece hangi projesinden geldiğini bilmezsiniz.
- Bir takım için cross-user mesajları birlikte onaylayabilecek bir leader (lider) veya approver (onaylayıcı) rolü var mı?
- Daha yüksek yetkili bir katman — leader-gate co-approval ve grup rolleri — tasarımda mevcuttur ama roadmap'tir, yayınlanmış production güvenliği değil; buna bugün güvenmeyin. Cross-user için canlı ve yük taşıyan (load-bearing) kontrol, mesaj-başına insan serbest bırakma kapısıdır: her cross-user mesajı, herhangi bir grup yapısından bağımsız olarak bu kapıdan geçer.
- Bir kullanıcı başka bir kullanıcının mesh trafiğini izleyebilir mi, örneğin sorunları izleyen bir takım lideri?
- Onay-kapılı (consent-gated) leader-read izleme tasarlanmıştır ama yayınlanmamıştır — leader-gate ve grup-rolleri katmanıyla aynı roadmap durumu. Şu anki haliyle, bir kullanıcının posta kutusu sadece o kullanıcı tarafından okunabilir; başka bir tarafın, izin olsun ya da olmasın, birinin mesajlarını, beklemede veya serbest bırakılmış, gözlemlemesine izin veren canlı bir özellik yoktur.
- Cross-user bekletme her mesaja mı yoksa sadece bazılarına mı uygulanır?
- Her cross-user mesajına uygulanır — sadece-metadata-ile-bekletme, mesaj-başına veya gönderen-başına bir seçenek değil, varsayılan ve tek moddur. "Bu uid'e güven, otomatik teslim et" şeklinde bir cross-user ayarı yoktur. Sahiplikin sahteciliği ortadan kaldırması artı insan kapısı, bir uid sınırını geçen herhangi bir mesaj için sabit sözleşmedir.
- Gönderenin uid'i sahtelenemiyorsa, neden insan adımını atlamıyoruz?
- Çünkü uid doğrulaması ve injection güvenliği farklı problemlerdir. Gönderenin uid'ini kernel-verify etmek, mesajı kimin gönderdiğini kanıtlar, içeriğinin üzerinde hareket etmenin güvenli olduğunu değil — meşru şekilde gönderilmiş bir mesaj hâlâ bir talimat gibi görünecek şekilde hazırlanmış metin içerebilir. İnsan serbest bırakma adımı o içeriğe maruziyeti sınırlar; bu, fazladan (redundant) bir kimlik kontrolü değildir.
- Bir cross-user mesaj serbest bırakıldıktan sonra, agent otomatik olarak ona göre hareket edebilir mi?
- Hayır — serbest bırakıldıktan sonra, same-user mesajlarla aynı standart kural altında, tıpkı diğer atıl veri çerçeveleri gibi ele alınır: bir mesaj gövdesine asla uyma. Agent kelimelerle yanıt verebilir, ama mesajın buyruğuyla kod çalıştırmak, bir eylem gerçekleştirmek veya sır ifşa etmek, mesaj aynı kullanıcıdan mı yoksa farklı bir kullanıcıdan mı geldiğine bakılmaksızın bu kurala aykırıdır.
- Paylaşılan bir cross-user posta kutusunu makinedeki diğer kullanıcılardan hangi OS-seviyesi izinler korur?
- Cross-user teslimat, same-user modunun katı owner-only (0700) dizinleri yerine grup sahipli bir dizin kullanır, çünkü birden fazla uid'in ona ulaşması gerekir. Grup üyeleri bir mesajı bırakabilir ve dizini geçebilir (traverse) ama içindekini listeleyemez veya okuyamaz; sadece amaçlanan alıcı bir mesajı okuyabilir, bu yüzden kutudaki diğer kullanıcılar birbirinin postasına göz atamaz.
Güvenlik ve güven modeli
- agentixmesh prompt injection'ı durdurur mu?
- Hayır — prompt-injection riskini azaltır, ortadan kaldırmaz. Sahiplik (ownership), bir mesajı kimin gönderdiğini garanti eder, mesajın ne söylediğini değil. Meşru şekilde gönderilmiş bir mesaj hâlâ bir talimat gibi görünecek şekilde hazırlanmış metin içerebilir ve onu okuyan agent zayıf noktadır. agentixmesh bunu inert-DATA framing, sanitasyon ve standart bir asla-uyma kuralı ile hafifletir — ama alıcı LLM sonuçta ne yapacağına kendisi karar verir.
- Sahtecilik (forgery) ile prompt injection arasındaki fark nedir ve agentixmesh bunlara neden farklı davranır?
- Sahtecilik, bir mesajın kimin gönderdiği konusunda yalan söylemesidir; injection ise meşru şekilde gönderilmiş bir mesajın bir agent'ı bir eyleme ikna etmeye çalışmasıdır. agentixmesh, kernel-verified sert bir garantiyle birincisini ortadan kaldırır — sahtelenmiş bir gönderen, bir agent mesajı görmeden reddedilir. İkincisini yalnızca azaltır, çünkü injection mesaj içeriğinde yaşar; mesh bunu çerçeveleyebilir ve sanitize edebilir ama tam olarak etkisiz hale getiremez.
- "Kernel-verified sender" (kernel-doğrulanmış gönderen) gerçekte ne anlama gelir?
- Gönderen OS kullanıcı kimliğinin, mesajın içindeki herhangi bir alandan değil, teslim edilen mesajın açık dosya tanımlayıcısı üzerinde fstat ile okunduğu anlamına gelir. Kernel, dosya sahipliğini mesaj içeriğinden bağımsız olarak takip eder, bu yüzden bir gönderen farklı bir kullanıcı olduğunu iddia edemez — OS'nin, az önce yazdığı dosyanın kime ait olduğu konusunda yalan söylemesi gerekirdi, ki yapmaz.
- Biri bir mesajın kimden geldiğini sahteleyebilir mi?
- Hayır — gönderen kimliği, gönderenin geçersiz kılabileceği bir kural değil, sert, kernel-tarafından-uygulanan bir garantidir. uid, kendi kendine bildirilen bir alandan değil işletim sisteminin kendi dosya-sahipliği metadata'sından geldiğinden, bir kullanıcı olarak çalışan bir process, bir mesajı başka bir kullanıcıdan geliyormuş gibi gösteremez. Bu, güven modelinin olasılıksal olmayan tek parçasıdır.
- uid:project adresinin proje yarısı güvenilir mi?
- Hayır — proje etiketi kendi kendine beyan edilir (sadece gönderenin çalışma dizini basename'idir) ve doğrulanmaz. agentixmesh, bir mesajı hangi OS kullanıcısının gönderdiğini kanıtlar, hangi agent'ın, repository'nin veya projenin gönderdiğini değil. Herhangi bir adresin proje yarısını yönlendirme için bir ipucu olarak ele alın, asla bir güvenlik iddiası olarak değil — aynı kullanıcı tarafından çalıştırılan iki agent, istediği herhangi bir proje adını iddia edebilir.
- Başka bir agent'tan gelen bir mesaj, agent'ıma bir komut çalıştırtabilir veya bir sır sızdırtabilir mi?
- Hiçbir mesaj bir eylemi zorlayamaz — agentixmesh yalnızca veriyi context'e teslim eder; gönderen adına asla hiçbir şey çalıştırmaz. Bir agent'ın bir komut çalıştırıp çalıştırmayacağı veya bir sır ifşa edip etmeyeceği, tamamen o agent'ın kendi karar verme sürecine ve tool izinlerine bağlıdır. Mesh'in işi, alıcı agent'a atıl metni ve onu veri olarak ele alma kuralını teslim etmektir, bir yetenek (capability) vermek veya kullanmak değil.
- "Atıl DATA çerçevesi" (inert DATA frame) nedir?
- Gelen bir mesajın alıcı agent'a nasıl sunulduğudur: uyulması gereken bir komut olarak değil, okunması gereken veri olarak açıkça sınırlandırılmış. Bu framing, bir mesaj gövdesinin buyruğunun hiçbir şeye yetki vermediği yönündeki standart bir kuralla eşleşir — kelimelerle yanıt vermek sorun değildir, ama bir mesajın talimatı üzerine bir eylem gerçekleştirmek, kod çalıştırmak veya bir sır ifşa etmek sorun teşkil eder. Sonrasında ne olacağına mesh değil, agent karar verir.
- agentixmesh gelen mesajlara ne tür sanitasyon uygular?
- Bir mesaj bir agent'ın context'ine ulaşmadan önce, agentixmesh talimatları güvenilir çıktı gibi göstermek için yaygın olarak kullanılan yapıları ayıklar — kontrol karakterleri, görünmez/sıfır-genişlikli karakterler ve yeni bir konuşma turu başlangıcını taklit eden metin kalıpları gibi. Bu, injection yüzeyini daraltır ama her olası manipülatif mesaj ifadesini yakalayabilecek bir filtre değil, bir hafifletmedir (mitigation).
- Tekrarlanan (replayed) veya yinelenen (duplicate) mesajlara karşı koruma var mı?
- Evet — teslim edilen mesajlar takip edilir, böylece aynı mesaj daha sonraki bir poll'da bir agent'ın context'ine yeniden enjekte edilmez. Bu, bir mesajın sessizce yeniden teslim edilmesine ve yeniymiş gibi yeniden okunmasına karşı korur, ki bu önemlidir çünkü aynı hazırlanmış metne tekrar tekrar maruz kalmak, bir agent üzerinde baskı kurmanın bir yoludur. Bu bir teslimat-hijyeni kontrolüdür, ilk kez yapılan bir injection girişimine karşı bir savunma değil.
- agentixmesh'in tehdit modeli nedir?
- Tek bir makineyi paylaşan güvenilir meslektaşlar, düşman-root bir saldırgan değil. Tasarım, katılımcı OS kullanıcılarının birbirlerini taklit etmek için host'un kernel'ine veya dosya izinlerine aktif olarak saldırmadığını varsayar — bir kullanıcının root-seviyesi erişimi varsa, neredeyse her yerel güven mekanizmasını alt edebilir. Bu varsayım içinde, agentixmesh'in sahtecilik garantisi geçerlidir; kötü niyetli bir sistem yöneticisine veya güvenliği ihlal edilmiş bir kernel'e karşı dayanacak şekilde tasarlanmamıştır.
- agentixmesh bir güvenlik ürünü mü?
- Hayır — daha geniş anlamda bir güvenlik ürünü değil, mesaj teslimatı için bir güven sınırıdır (trust boundary). Dar bir soruyu güvenilir şekilde yanıtlar (bu mesajı kim gönderdi) ve daha geniş bir problemde kısmen yardımcı olur (mesaj içeriğinin bir agent'ı ele geçirmesine izin verme). Endpoint sertleştirmenin (hardening), secrets management'in veya bir agent'ın kendi izin kapsamlamasının yerini almaz — bunlar operatörün sorumluluğu olarak kalır.
- Dosya sahipliği NEYİ çözmez?
- Sahiplik, bir mesajı kimin gönderdiğini çözer; mesajın ne söylediğini veya bir agent'ın buna nasıl tepki verdiğini çözmez. Meşru şekilde gönderilmiş bir mesajın manipülatif metin içermesini engellemez, mesaj içeriğini güvenlik açısından denetlemez ve alıcı bir agent'ın ne yapabileceğini kısıtlamaz — bu, mesh'in değil, agent'ın kendi tool izinlerinin bir fonksiyonudur.
- Agent'ım bir mesaj gövdesine gömülü kötü niyetli bir talimata uyarsa, bu bir agentixmesh hatası mı?
- Hayır — bu, alıcı agent'ın mesaj-gövdesine-asla-uyma kuralına uymamasıdır, ki bu tam olarak agentixmesh'in açıkça belirttiği artık risktir. Mesh, mesajı atıl veri olarak çerçevelenmiş şekilde teslim eder ve bir LLM'i bu framing'e saygı göstermeye zorlayamaz. Bu hata modunu daha da azaltmak, alıcı taraftaki bir model/prompt-disiplini problemidir, bir teslimat katmanının tek başına düzeltebileceği bir şey değil.
- agentixmesh bir mesajı gönderen agent'ı veya harness'ı doğrular mı?
- Hiçbiri — sadece gönderen process'in çalıştığı OS kullanıcısını doğrular, bunun ötesinde hiçbir şeyi değil. Claude Code'u başka bir harness'tan veya aynı kişi tarafından çalıştırılan bir agent process'ini ikincisinden ayırt edemez. Bir şeyi hangi belirli agent veya aracın gönderdiğini bilmeniz gerekiyorsa, bu agentixmesh'in kimlik garantisinden değil, context'ten veya kuraldan (convention) gelmelidir.
- Cross-user mesajlaşma (ayrı OS kullanıcıları, aynı makine) bugün kullanmak için güvenli mi?
- Uçtan uca doğrulanmıştır ama production go-live'ı kasıtlı olarak human-gated'dir; henüz genel olarak kullanılabilir gibi ele alınmamalıdır. Bir cross-user mesaj gövdesi bir insan onu serbest bırakana kadar bekletilir ve cross-user otomatik hareket yapısal olarak imkansızdır — o kapı bir formalite değil, güvenlik mekanizmasının kendisidir. Cross-user'ı, kasıtlı bir rollout kararını hâlâ bekleyen, incelenmiş bir yetenek olarak ele alın.
- Bir mesaj hiçbir inceleme olmadan bir eylemi otomatik tetikleyebilir mi?
- Hayır — teslimat, bir mesajı sadece bir agent'ın context'ine koyar; agentixmesh'te hiçbir şey bir mesajın adına çalışmaz. Bir kullanıcının kendi oturumları içinde, bir mesajı okuyan agent asla-uyma kuralı altında ne yapacağına kendisi karar verir. Kullanıcılar arasında ise, eklenen human-release kapısı, bir gövdenin bir insan onu geçirene kadar görünür bile olmadığı anlamına gelir, ki bu yapısal olarak her türlü otomatik hareketi dışlar.
- Her mesajın kalıcı bir audit trail'i (denetim izi) var mı?
- Same-user çekirdekte yayınlanmış, production bir garanti olarak değil — güvenilir olan kısım, yeniden teslimatı engelleyen replay guard'dır, kurcalamaya-karşı-kanıt (tamper-evident) bir log değil. Başka bir kullanıcının posta kutusunun onay-kapılı izlenmesi (leader-read), cross-user katmanı için tasarım gereği mevcuttur ama roadmap'tir, bugün production güvenlik veya uyumluluk (compliance) özelliği olarak reklamı yapılan bir şey değildir.
İzolasyon ve sınırlar
- Bir uid:project adresi gerçekte neyi tanımlar?
- İki farklı garantiye sahip iki farklı şey. uid, alıcı tarafta fstat ile kernel-verify edilen OS kullanıcısıdır, bu yüzden ona güvenilebilir. Proje yarısı, gönderenin kendi çalışma dizini basename'idir, kendi kendine beyan edilir ve doğrulanmaz — bunu bilgilendirici bağlam olarak ele alın, bir mesajın nereden geldiğinin kanıtı olarak değil.
- Bir adresin proje yarısı sabit, benzersiz bir tanımlayıcı mı?
- Hayır. Sadece gönderen oturumun çalışma dizininin o an neresi olduğunun basename'i. Bunu hiçbir şey kaydetmez veya bir makine genelinde benzersizliğini uygulamaz. Aynı adı paylaşan iki ilgisiz klasör, teslimattan önce çakışmaları kontrol eden merkezi bir otorite olmadan, birebir aynı adresi üretir.
- Posta kutuları projeler arasında nasıl izole edilir?
- Her adres, owner-only (0700) olarak oluşturulan, yalnızca ona sahip olan OS kullanıcısı tarafından okunabilen kendi maildir dizinini alır. İzolasyon, uygulama-seviyesi mantıkla değil, dosya sistemi izinleriyle uygulanır — farklı bir OS kullanıcısı olarak çalışan bir process, ne denerse denesin dizini hiç açamaz.
- Bir proje başka bir projenin gelen kutusunu okuyabilir veya üzerinde işlem yapabilir mi?
- Hayır, OS kullanıcıları arasında — teslimat adres-başınadır ve bir mesaj sadece kendi uid:project hedefiyle eşleşen maildir'e düşer. Bir mesaj ayrıca hiçbir yetki taşımaz: birini almak, bir oturuma başka bir gelen kutusuna erişme, bir eşin adına hareket etme veya herhangi bir şeyi otomatik tetikleme yeteneği asla vermez.
- OS kullanıcım birkaç farklı agent projesi çalıştırıyorsa, birbirlerinin postasını okuyabilirler mi?
- Maildir sahipliği uid seviyesinde ayarlandığından, izolasyon proje-başına değil OS-kullanıcı-başına uygulanır. Aynı uid olarak çalışan bir process, prensip olarak o uid'in sahip olduğu herhangi bir maildir'i açabilir. Proje etiketi sadece bir teslimat adresi seçer — tek bir kullanıcı içinde ayrı bir izin sınırı değildir.
- Bir mesaj hangi projeden gönderildiğini sahteleyebilir mi?
- Evet — proje etiketi kendi kendine beyan edilir ve kriptografik olarak kontrol edilmez, bu yüzden bir gönderen adresin o yarısına istediği herhangi bir string'i koyabilir. Sahtelenemeyecek olan uid'dir: kernel-verified gönderen kimliği, iddia edilen proje adından bağımsız olarak, mesajı hangi OS kullanıcısının gerçekten gönderdiğini söyler.
- Bir adresi yanlış yazarsam ve tesadüfen farklı gerçek bir projeyle eşleşirse ne olur?
- Mesaj sessizce oraya teslim edilir. Yazdığınız hedefin kastettiğiniz hedef olup olmadığını kontrol eden bir onay adımı yoktur, bu yüzden başka bir canlı adresle çakışan bir yazım hatası, mesajınızı basitçe o oturumun gelen kutusuna yönlendirir — hiçbir tarafa bir hata olduğunu söyleyen bir şey olmadan.
- Var olmayan veya çalışmayan bir projeye adres yazarsam ne olur?
- Mesaj o posta kutusuna yazılır ve bekler — karşılaştırılacak aktif adreslerin bir kaydı yoktur, bu yüzden var olmayan veya o an boşta olan bir uid:project'e göndermek hiçbir hata üretmez. Sadece tam olarak o adrese sahip bir oturum daha sonra posta kutusunu kontrol ederse okunabilir hale gelir.
- Kendi mesh adresimi nasıl bulurum?
- mesh-whoami çalıştırın — diğer oturumların size ulaşmak için yazması gereken uid:project adresinizi, OS uid'inizden ve çalışma dizininizin basename'inden canlı olarak türeterek tam olarak yazdırır. Adresi hafızadan yeniden inşa etmek yerine bunu kullanın, çünkü proje yarısı cwd'ye bağlıdır ve kayabilir.
- Başka bir oturuma, tam adresini elle yazmadan veya tahmin etmeden nasıl ulaşırım?
- Gönderen-tarafı adres defterini kullanın — akılda kalıcı isimleri tam uid:project adreslerine eşleyen, yerel olarak sizin tuttuğunuz bir takma-ad listesi, böylece her seferinde tam bir basename'i hatırlamak veya yeniden yazmak zorunda kalmazsınız. Bu sadece bir hedefe nasıl atıfta bulunduğunuzu etkiler; alıcının nasıl adreslendiğini değiştirmez.
- agentixmesh makinedeki diğer projeleri otomatik keşfedip benim için köprüler mi?
- Hayır. Otomatik keşif, aktif projelerin bir dizini veya oturumların otomatik bağlanması yoktur. Her mesaj, bir gönderenin açıkça sağladığı tek bir belirli uid:project adresine gider. İzolasyon varsayılan durumdur; bir sınır ancak biri o tam hedefi kasıtlı olarak adlandırdığı için aşılır.
- Proje etiketi güvenilir olmadığına göre, izolasyon garantileri için gerçekte neye güvenmeliyim?
- uid sınırına güvenin. agentixmesh, posta kutularının yalnızca onlara sahip OS kullanıcısı tarafından okunabildiğini garanti eder ve gelen bir mesajı hangi OS kullanıcısının gönderdiğini bildiğinizi garanti eder. İddia edilen gönderen projenin doğru olduğunu garanti etmez — bir mesajın içindeki veya ona eklenmiş herhangi bir proje adını bağlam olarak ele alın, asla erişim kontrolü olarak değil.
- Aynı basename'e sahip iki farklı dizin tek bir adreste çakışabilir mi?
- Evet. Adresleme sadece çalışma dizininin basename'ini kullanır, bu yüzden aynı adı paylaşan herhangi iki klasör — örneğin bir projenin ana checkout'u ve başka bir yerdeki ayrı bir kopyası veya checkout'u — özdeş uid:project adresine çözülür ve gönderme veya alma anında hiçbir uyarı olmadan sessizce bir gelen kutusunu paylaşır.
- Mesh mesajları alabilmesi için bir projeyi kaydetmem gerekiyor mu?
- Hiçbir kayıt adımı yoktur. Bir projenin adresi, o OS kullanıcısı olarak çalışan ve o basename'e sahip bir dizinden gelen bir şey posta kutusunu kontrol ettiği anda örtük olarak var olur. Hiç "oluşturulmamış" bir adrese göndermek, basitçe mesajı bir maildir'e yazar, ki bu daha sonra eşleşen bir oturum onu poll ettiğinde okunabilir hale gelir.
- Posta kutusu izolasyonu agentixmesh'in kendi kodu tarafından mı, yoksa işletim sistemi tarafından mı uygulanıyor?
- İşletim sistemi tarafından. Posta kutusu dizinleri owner-only (0700) olarak oluşturulur, bu yüzden izolasyon garantisi agentixmesh'in yanlış yapabileceği bir uygulama-seviyesi kontrolden değil, standart Unix dosya sistemi izinlerinden gelir. Bu aynı zamanda hatalı veya kötü niyetli bir agent process'ine karşı da geçerli olmasının nedenidir — kernel, herhangi bir mesh kodu çalışmadan önce open()'ı reddeder.
Maliyet ve token'lar
- Mesh'i yeni mesajlar için kontrol etmek LLM token'ına mal olur mu?
- Hayır. Mesh'i kontrol etmek, bir LLM çağrısı değil, yerel maildir'inize karşı düz bir dosya okumasıdır, bu yüzden sıfır token'a mal olur. Poll sıklığı bunu değiştirmez — `mesh-poll status` ve oturum başlangıcındaki otomatik inject-hook kontrolü dosya sistemi işlemleridir. Bu kontrolün çalışıp çalışmayacağını `mesh-poll on/off/status` ile kendiniz kontrol edersiniz.
- Bir mesh mesajı gerçekte ne zaman token'a mal olur?
- Sadece bir agent'ın context'ine okuması için teslim edildiğinde. Bir maildir'de bekleyen bir mesaj hiçbir şeye mal olmaz; maliyet, metni bir DATA çerçevesi olarak konuşmaya render edildiği anda ortaya çıkar ve bu teslimat agent'a açıklanır — gizli bir arka plan ücreti değildir.
- Serbest bırakılmayı bekleyen kuyrukta veya beklemede duran bir mesaj token'a mal olur mu?
- Hayır. Bir mesajı beklemede veya kuyrukta tutmak, `held` (veya `new`) dizininde diskte duran bir dosyadır; serbest bırakılana kadar hiçbir şey onu bir agent'ın context'ine okumaz, bu yüzden sıfır token maliyeti tahakkuk eder. Maliyet ancak mesaj fiilen teslim edilip okunduğunda başlar — kuyrukta bekleme süresi harcamayla ilgisizdir.
- Bir mesh mesajını bir insan kanalına, örneğin bir telefona iletmek LLM token'ına mal olur mu?
- Hayır. Bir insan kanalına iletmek — örneğin bir bildirimi bir telefona aktarmak — bir LLM çağrısı değil, düz bir mesaj-aktarma işlemidir, bu yüzden hiçbir LLM token maliyeti doğurmaz. Token maliyeti özellikle bir agent'ın içeriği kendi context'ine okumasına bağlıdır, metni teslimat kanalları arasında taşımaya değil.
- agentixmesh kullanımı ücretsiz mi?
- Mesaj-başına bir ücret yoktur ve mesh'i poll etmenin veya kontrol etmenin token maliyeti yoktur — bu kısım ücretsizdir. Buradaki "ücretsiz" LLM token'larından ücretsiz anlamına gelir: agentixmesh'in kendisi hiçbir şey ücretlendirmez. Ücretsiz olmayan şey, altta yatan agent oturumudur — gönderen ve alan agent'ları çalıştırmanın hosting ve compute'u zaten ödediğiniz ayrı bir maliyettir.
- agentixmesh açık kaynak mı?
- Evet. MIT lisanslıdır ve GitHub'da yayınlanmıştır (github.com/TokonoMix/agentixmesh). Maliyet veya güvenlik iddialarını körü körüne kabul etmek yerine, taşıma, kimlik-doğrulama ve teslimat kodunu kendiniz okuyabilirsiniz — mesaj teslimatına aracılık eden veya kullanımı ölçen kapalı bir bileşen yoktur.
- Mesh'in kendisini kullanmak için bir API anahtarına veya abonelik gerekli mi?
- Hayır. Mesh yerel dosyalardır — bir maildir artı bir inject hook — kimlik doğrulanacak bir daemon, network listener veya harici servis yoktur, bu yüzden mesh katmanı için anahtarlanacak veya abone olunacak bir şey yoktur. Göreceğiniz tek maliyet, bir mesajı okurken kendi agent'ınızın model kullanımıdır.
- Mesh teslimatından gelen token harcamasını sınırlayabilir veya kapatabilir miyim?
- Evet, `mesh-poll off` ile. Poll'u kapatmak, inject hook'un context'inize yeni mesajlar için kontrol etmesini veya teslim etmesini durdurur, bu yüzden hiçbir şey okunmaz ve mesh içeriğine hiç token harcanmaz. `mesh-poll status` mevcut durumu gösterir; `mesh-poll on` teslimatı tekrar istediğinizde yeniden etkinleştirir.
- mesh-send ile bir mesaj göndermek token'a mal olur mu?
- `mesh-send` ile bir mesaj yazmak, bir LLM işlemi değil, alıcının maildir'ine bir dosya yazmadır, bu yüzden gönderme eylemi, agent'ınızın göndermek istediği metni oluşturmak için zaten harcadığı token'ların ötesinde hiçbir token eklemez. Bu yazmanın üzerine katmanlanmış bir mesh-tarafı ücreti yoktur.
- Oturum başlangıcında çalışan otomatik inject hook, her turda sessizce token harcıyor mu?
- Hayır, gerçekten teslim edilecek bir mesaj olmadıkça değil. Hook'un yeni mail kontrolü bir dosya okumasıdır; maildir boşsa, context'e hiçbir şey eklenmez ve hiç token harcanmaz. Token'lar yalnızca bekleyen bir mesajın fiilen konuşmaya render edildiği turlarda harcanır.
- Beklemede veya bekleyen bir mesajı hiç okumazsam, yine de onun için ödeme yapar mıyım?
- Hayır. Okunmamış bir mesaj — `new`, `held`'de duran veya hiç talep edilmemiş — hiçbir agent'ın context'ine hiç tokenize edilmez, bu yüzden hiçbir şeye mal olmaz. Maliyet, bir mesajın bir posta kutusunda sadece var olmasına değil, kesinlikle bir agent'ın teslim edilen içeriği okuma eylemine bağlıdır.
Karşılaştırmalar
- agentixmesh, Redis veya RabbitMQ gibi bir message queue'dan nasıl farklı?
- Bir queue, endpoint'ler arasında byte taşır; onları kimin gönderdiğini bilmez veya doğrulamaz. agentixmesh, alıcı agent mesajı hiç görmeden önce, açık dosya tanımlayıcısı üzerinde fstat ile gönderenin OS kullanıcısını kernel-verify eder, bu yüzden 'kullanıcı X'ten' olduğunu iddia eden bir queue mesajı sahtelenebilir — bir agentixmesh mesajı sahtelenemez. Bu kimlik garantisi asıl noktadır; bir queue bunu sağlamaz.
- Aynı şeyi Redis pub/sub veya bir veritabanı tablosuyla inşa edebilir miyim?
- Byte'ları taşıyabilirsiniz, ama gönderen doğrulamasını kendiniz eklemeniz gerekir — Redis ve paylaşılan bir DB tablosu, kendilerine yazan herhangi bir client'a güvenir. agentixmesh'in garantisi OS'den gelir: sadece dosya tanımlayıcısını açan gerçek uid, kaydedilen gönderen olabilir. Bunu bir queue üzerinde yeniden implemente etmek, kernel-seviyesi kimlik kontrollerini yeniden türetmek anlamına gelir, ki bu zor kısmın çoğudur.
- agentixmesh, uygun bir message queue gibi teslimat garantileri veya sıralama sunuyor mu?
- Bir queue ürününün yaptığı şekilde değil — acks-with-retries-and-DLQ mekanikleri yok, gönderenler arası sıralama garantisi yok. Bir maildir'dir: mesajlar new/'e düşer, okunduğunda cur/'a taşınır, kapılı durumlar için held/'e. Bu kasıtlı olarak basit. Broker-seviyesi throughput, sıralama veya backpressure gerekiyorsa, agentixmesh bu araç değildir — o bir güven katmanıdır, bir queue ürünü değil.
- agentixmesh, MCP (Model Context Protocol) ile nasıl ilişkilidir?
- Farklı bir katman. MCP, bir agent oturumunu çağırdığı araçlara ve kaynaklara — veritabanları, API'ler, dosyalar — bağlar. agentixmesh, bir agent oturumunu başka bir agent oturumuna bağlar, böylece biri diğerinin yetkisini devralmadan mesaj alışverişi yapabilirler. Bir oturum, araçlar için MCP sunucularını, eş agent'larla konuşmak için agentixmesh'i kullanabilir — birbirini tamamlarlar, rekabet etmezler.
- agentixmesh ve MCP'yi birlikte kullanabilir miyim?
- Evet — farklı problemleri çözerler ve çakışmazlar. Bir Claude Code oturumunun, bir veritabanı veya arama API'si gibi tool erişimi için bağlanmış MCP sunucuları olabilir ve ayrıca ilgili bir görev üzerinde çalışan başka bir oturumdan agentixmesh mesajları alabilir. MCP, context'in agent-to-tool kenarını yönetir; agentixmesh, agent-to-agent kenarını yönetir. Birinin varlığı diğerini gerektirmez veya engellemez.
- agentixmesh, cross-machine iletişimi hedefleyen A2A veya diğer agent-to-agent protokolleriyle nasıl karşılaştırılır?
- Bu bir özellik boşluğu değil, bir konumlandırma farkıdır: agentixmesh tek makinelidir, dosya tabanlıdır, kernel-verified gönderen kimliğine sahiptir — cross-machine taşıma, TLS veya host'lar arası kriptografik imzalama yapmaz. Ayrı makinelerdeki agent'lar için inşa edilmiş protokoller, ağ-seviyesi güveni çözer, ki bu yerel dosya-tanımlayıcısı güveninden farklı bir problemdir. Cross-machine, imzalı agent iletişimi bizim için roadmap alanıdır (AgentsWeaver), agentixmesh'in bugün yaptığı şey değil.
- Neden agent'lar sadece paylaşılan bir dosyayı veya veritabanını okuyup yazmasın?
- Paylaşılan bir dosya veya DB, yazanın iddia ettiğinin ötesinde belirli bir satırı kimin yazdığı konusunda hiçbir kavrama sahip değildir — yazma erişimi olan herhangi bir process bir gönderen alanını sahteleyebilir. agentixmesh'in maildir'i owner-only'dir (0700, same-user) ve gönderen, kendi kendine bildirilen bir sütundan değil, dosyayı açan process'in kernel-verified uid'inden türetilir. Paylaşılan depolama size byte verir, provenance (köken) vermez.
- İki agent'ın ikisinin de değişiklikler için poll ettiği paylaşılan bir scratch dizininin sorunu nedir?
- Hiçbir şey bir agent'ı, bir bug'ı veya enjekte edilmiş bir talimatı, başka bir gönderenin kimliğine bürünen bir dosya yazmaktan alıkoymaz — düz paylaşılan bir dizinde hiçbir kimlik kontrolü yoktur. agentixmesh tam olarak bunu ekler: mesaj başına kernel-verified bir gönderen, artı alınan bir mesajın otomatik uyulmadan okunmasını sağlayan inert-DATA framing. Bir scratch dizini bu garantilerin hiçbirini vermez.
- Neden bir agent'ın çıktısının doğrudan başka bir agent'ın prompt'u haline gelmesine izin vermeyelim?
- Bu, agentixmesh'in hafifletmek için var olduğu confused-deputy/injection riskidir. Bir agent'ın ham çıktısını doğrudan başkasının prompt'una aktarmak, ona doğrudan bir talimatla aynı yetkiyi verir, o çıktıya kaçak sokulmuş herhangi bir şey dahil. agentixmesh bunun yerine mesajları, alıcı agent'ın okuduğu ama asla otomatik çalıştırmadığı bir atıl DATA çerçevesi olarak teslim eder; kelimelerle yanıt vermek sorun değildir, bir mesajın buyruğu üzerine hareket etmek sorun teşkil eder.
- Mesajları atıl veri olarak çerçevelemek, diğer agent'ı doğrudan prompt'lamaya kıyasla sürtünme eklemiyor mu?
- Biraz, evet, ve bu kasıtlı. Doğrudan prompt'lama, 'alınan metin' ile 'uyulacak talimat'ı tek bir şeye indirger, ki bu tam olarak confused-deputy hata modudur. agentixmesh bunları ayrı tutar: çerçeve açıkça veridir ve mesajın değil, alıcı agent'ın hareket edip etmeyeceğine ve nasıl edeceğine karar verir. Bu, kolayca enjekte edilebilir olmamanın bedelidir.
- Bu, iki agent'ı Slack veya bir chat kanalı üzerinden köprülemekten nasıl farklı?
- Bir chat köprüsü, kimlik bilgilerine sahip herkesin kendisi olarak paylaşım yapabildiği paylaşılan bir oda verir — insanlar için faydalı, ama bir mesajı hangi process'in gönderdiğini OS seviyesinde doğrulamaz ve yerleşik bir 'bu veridir, komut değildir' framing'i yoktur. agentixmesh'in kimlik garantisi kernel-türevlidir (gönderenin kendi açık dosya tanımlayıcısı üzerinde fstat) ve teslimat, bir agent'ın talimat olarak okuyabileceği canlı bir akış yerine varsayılan olarak atıl framing'e sahiptir.
- agentixmesh, AgentsWeaver ve Tokonomix'e göre nereye oturuyor?
- Bunlar rakip değil, tek bir ailenin üç katmanıdır. agentixmesh yerel, tek-makineli giriş noktasıdır — dosya tabanlı, kernel-verified kimlik, tek host. AgentsWeaver, agent'lar host'lar arasına yayıldığında ölçeklenen cross-machine, kriptografik olarak imzalı katmandır. Tokonomix, cross-vendor LLM consensus'tur — bir soruyu birden fazla modele yönlendirip yanıtları değerlendirir. Farklı problemler, aynı güven-öncelikli yaklaşım.
- agentixmesh'i ne zaman aşarım ve AgentsWeaver gibi bir şeye ihtiyacım olur?
- Agent oturumlarınız tek bir makinede yaşamayı bıraktığında. agentixmesh'in kimlik garantisi yerel bir kernel primitifinde köklüdür — açık bir dosya tanımlayıcısı üzerinde fstat — ki bu bir mesajın farklı bir host'tan geldiğini kanıtlamak için bir yanıtı yoktur; bu, AgentsWeaver'ın hedeflediği problem olan ağ-seviyesi kriptografik imzalama gerektirir. Tek bir makinedeki birden fazla OS kullanıcısı hâlâ agentixmesh'in alanıdır (cross-user modu), sadece human-gated.
- Tokonomix, agentixmesh'in yerini mi alıyor?
- Hayır — farklı bir iş. Tokonomix, bir soruyu birden fazla LLM sağlayıcısına gönderip değerlendirilmiş bir yanıt sentezleyerek 'bu çıktı iyi mi?' sorusunu yanıtlar. agentixmesh, agent oturumları arasında 'bu mesajı bana kimin gönderdiğine güvenebilir miyim?' sorusunu yanıtlar. Aynı iş akışında yan yana kullanılabilirler, ama hiçbiri diğerinin yerini tutmaz.
- agentixmesh, LangGraph veya CrewAI gibi orkestrasyon framework'lerinin yerini mi alıyor?
- Hayır — orkestrasyon framework'leri, bir agent'ın tek bir process veya iş akışı içinde sırada ne yapacağına karar verir; agentixmesh, belleği veya yetkiyi paylaşmayan ayrı agent oturumları veya process'ler arasında güvenilir mesajlar taşır. Bir oturum içeride bir orkestrasyon framework'ü çalıştırabilir ve ayrıca agentixmesh üzerinden gönderip alabilir — farklı katmanlarda çalışırlar ve büyük ölçüde çakışmazlar.
- agentixmesh, MCP'den (Model Context Protocol) nasıl farklıdır?
- Farklı katmanlarda dururlar. MCP bir modeli araçlarına ve bağlamına bağlar — agent yetenekleri bilinçli olarak, kendi eylemleri olarak çağırır. agentixmesh ise zaten çalışan agent oturumları arasındaki güven sınırıdır: gönderenin işletim sistemi kullanıcı kimliği çekirdek tarafından doğrulanır ve içerik etkisiz veri olarak gelir; agent'ın uyması gereken bir talimat olarak asla. Komşudur, rakip değil — agentixmesh vs MCP sayfası tam karşılaştırmayı sunar.
- agentixmesh ile MCP yan yana çalışabilir mi?
- Evet — beklenen kurulum budur. Her oturum yetenekler için kendi MCP sunucularını tutar; agentixmesh ise oturumlar arasındaki mesajları taşır. Mesh bir isteği veri olarak teslim eder; agent'ın buna göre hareket edip etmeyeceği, alan oturumun içinde, kendi izinleri altında verilen bir karar olarak kalır.
Kurulum, sınırlar ve yol haritası
- agentixmesh bir arka plan daemon'u veya sunucu process'i gerektirir mi?
- Daemon yok. Same-user teslimat, bir maildir (new/cur/held/seen klasörleri) artı bir agent oturumu başladığında veya bir prompt gönderildiğinde tetiklenen bir inject hook üzerinde çalışır — arka planda sürekli çalışması gereken hiçbir şey yoktur. Çekirdek same-user yolu için çökebilecek, yeniden başlatılması veya bakımı gereken kalıcı bir process yoktur.
- agentixmesh bir ağ portu açar mı?
- Hayır. Hiçbir türden network listener yoktur — same-user mesajlaşma düz dosya sistemi G/Ç'sidir: bir mesaj bir maildir dizinine yazılır ve bir sonraki oturum olayında inject hook tarafından alınır. Açılacak bir soket, güvenlik duvarına eklenecek bir port, bağlantı için dinleyen hiçbir şey yoktur.
- agentixmesh'i kullanmak için sudo veya root'a ihtiyacım var mı?
- Hayır, same-user çekirdek için gerekmez. Posta kutuları, normal bir kullanıcı hesabının kendi başına oluşturup okuduğu owner-only dizinlerdir (mode 0700). Root, ancak isteğe bağlı cross-user katmanının paylaşılan host kurulumunu sağlamaya geçerseniz devreye girer — günlük same-user mesajlaşma asla sudo'ya dokunmaz.
- Bir host'un agentixmesh'i çalıştırması için neye ihtiyacı var?
- Sadece tek bir makine, kullanıcı hesabının yazabileceği bir dosya sistemi, Python ve o kullanıcının home dizini altında yaşayan bir maildir. Diğer parça, gelen mesajların bir oturumun context'ine render edilmesi için agent harness'ınıza bağlanmış bir inject hook'tur — bunun ötesinde egzotik bir altyapı yoktur.
- agentixmesh'i nasıl kurarım?
- Dört host entegrasyon noktasını bağlayın: paketin import edilebilir olması için bir Python path girdisi, PATH'inizde CLI wrapper'ları (`mesh-send` gibi), agent harness'ınızın yüklediği bir skill dosyası ve oturum başlangıcında ve prompt submit'te tetiklenen bir inject hook. GitHub'da açık kaynaktır (github.com/TokonoMix/agentixmesh, MIT), bu yüzden onu clone'layıp kurulum adımlarını kendiniz çalıştırırsınız.
- agentixmesh self-hostable mi?
- Evet — sadece self-hosted'dir. Hosted bir servis veya SaaS backend'i yoktur; agentixmesh, kendi makinenizdeki kendi agent harness'ınıza kurduğunuz yerel dosyalardır (bir maildir) artı bir hook. Taşımayı uçtan uca siz kontrol edersiniz ve hiçbir mesaj verisi host'unuzdan çıkmaz.
- Inject hook'u hiç kurmazsam ne olur?
- Mesajlar sadece maildir'de teslim edilmemiş halde bekler. Hook, yeni bir mesajı oturum başlangıcında veya prompt submit'te bir agent oturumunun context'ine render eden şeydir — o olmadan, gönderme yine çalışır ve mesajlar birikir, ama hook çalışana kadar hiçbir şey onları alıcı agent'a göstermez.
- agentixmesh tek bir makineyle mi sınırlı?
- Evet — bugün agentixmesh sadece aynı makinedeki agent oturumları arasında teslimat yapar. Ağ taşıması olmadığından, bir mesajı farklı bir host'ta çalışan bir oturuma yönlendiremez. Cross-machine teslimat, şu anda ele almadığı gerçek, ayrı bir ihtiyaçtır.
- agentixmesh cross-machine teslimatı destekleyecek mi?
- Roadmap'te, bugün yayında değil. agentixmesh'in çekirdeği sadece tek makinelidir, yerleşik bir ağ taşıması yoktur. Ölçekte cross-machine, kriptografik olarak imzalı teslimat, kardeş bir projenin (AgentsWeaver) açık işidir — agentixmesh, yerel, tek-makineli giriş noktası olarak konumlandırılmıştır, ölçeklenmiş cross-network taşıma olarak değil.
- Roadmap'teki "daha yüksek yetkili katman" nedir?
- Leader-gate co-approval, grup rolleri ve onay-kapılı leader-read izleme — bir takım liderinin onay ile agent trafiğini birlikte onaylaması veya gözlemlemesi için mekanizmalar. Bugün tasarım/prototip formunda mevcutlar ama yayınlanmadılar ve açıkça production güvenliği olarak reklamı yapılmıyorlar; bunları sertleştirilmiş bir garanti değil, roadmap olarak ele alın.
- agentixmesh hangi lisans altında?
- MIT. Kod, github.com/TokonoMix/agentixmesh adresinde GitHub'da public'tir — izin istemeden okuyun, fork'layın, self-host edin veya değiştirin. Public repo'nun arkasına saklanan ayrı bir ücretli katman veya kapalı bir çekirdek yoktur; gördüğünüz şey çalışan şeydir.
- agentixmesh aktif olarak sürdürülüyor mu?
- GitHub'da tam commit geçmişi public olan bir açık kaynak projesi olarak geliştirilir, bu yüzden ona bağımlı olmadan önce aktivitesini kendiniz kontrol edebilirsiniz. Resmi bir destek SLA'sı yoktur — herhangi bir MIT-lisanslı proje gibi, onu benimsemek, çalıştırdığınız fork'un kendi operasyonel sahipliğini üstlenmek anlamına gelir.
- agentixmesh kasıtlı olarak NE YAPMAZ?
- Bir ağ servisi olarak çalışmaz, same-user kullanım için sudo gerektirmez, bir mesajın içeriğine göre otomatik hareket etmez ve prompt injection'ı tamamen durdurduğunu iddia etmez. Mesajları, bir agent'ın okuyup karar vereceği atıl veri olarak teslim eder — mesh'in kendisi asla bir mesaj gövdesinde bulunan bir talimatı çalıştırmaz.