Neden sadece bir render katmanı değil
Generative UI protokolünün size sağladıkları, sağlamadıkları ve asıl işin nerede olduğu.
Artık bir modelin arayüz tanımlaması için açık protokoller var — aralarında Google'ın A2UI protokolü de bulunuyor — ve bunlar gayet başarılı. Bunlardan biriyle bu çözüm arasında bir seçim yapıyorsanız, dürüst cevap şudur: Bunlar problemin farklı bir kısmını çözer ve çözdükleri kısım, asıl zaman alan kısım değildir.
Bir render katmanının size sağladıkları
“Bu alanlara sahip bir kart çiz” için bir söz varlığı ve bunun için bir render aracı. Bu gerçek bir iştir ve iki kez yapmamaya değer.
Rendel'in da böyle bir katmanı var. Her biri bir cihaza ulaşmadan önce şemasına göre ve kullanıcının işlem yaptığı değerler için bu değerlerin nereden geldiğine göre sunucuda doğrulanmış 36 adet tiplendirilmiş bileşen. Flutter bunları yerel olarak çizer, web ise DOM olarak çizer. Bütün ürün bundan ibaret olsaydı, bakımını yapmak zorunda olmadığınız bir protokol daha iyi bir tercih olurdu ve biz de bunu açıkça söylerdik.
Geriye ne kalıyor
Aşağıdakilerin tümü, bir render katmanının hakkında fikir sahibi olmadığı konulardır ve her biri, bir asistan gerçek bir hesaba dokunmadan önce birisinin alması gereken bir karardır.
Hangi fonksiyonlarınızın çağrılabileceği ve bunları çağırmanın neye mal olduğu. Tipli bir manifest, aksiyon başına bir risk seviyesi, sunucunun şablonunuzdan ve doğruladığı parametrelerden oluşturduğu — asla model çıktısından değil — bir onay kartı ve her bir önerinin ve nasıl sonuçlandığının bir kaydı. Bir render katmanı üzerinde “Refund £400” yazan bir butonu seve seve çizer; butona basıldığında ne olduğu ise üründür.
Dokunmanın gerçek olup olmadığı. Sunucu aracılı onay etkinken, işleyiciniz çalışmadan önce dokunma burada kaydedilir ve istemcinin beyanı dikkate alınmaz. Bu, bir bileşenin değil, iletim hattının ve veritabanının bir özelliğidir.
Modelin neyi görmesine izin verildiği. Kullanıcıların mesajlarında yazdığı e-posta adresleri ve telefon numaraları, herhangi bir model çağrısından önce tiplendirilmiş yer tutuculara dönüşür; kart benzeri numaralar kaldırılır (redaksiyon). Değerler şifrelenir, Frankfurt'ta kalır ve asla bir URL alanına yerleştirilmeden, yalnızca sohbete sahip cihaza giderken tekrar yerine koyulur. Bir render protokolünün tüm bunlar hakkında haklı olarak hiçbir fikri yoktur — bu onun işi değildir.
Faturalandırılabilir, devam ettirilebilir bir birim olarak diyalog sırası. Bir POST, bir veri akışı, bir kullanım satırı, yeniden denemede geçerliliğini koruyan bir idempotency anahtarı ve iş bittikten sonra kesilen bir akış için devam yolu. Bu sistemdeki zorlu hataların çoğu burada yer almıştır.
Her şey canlıya geçişten sonra. Bu sohbetlerin kime ait olduğu, ne kadar süre saklandığı, sağlayıcı tarafında bunları kimin okuduğu, Rendel'in arkasında hiçbir veri olmadan ne yanıt verdiği, insanların sürekli hangi aksiyonu reddettiği.
Doğrudan karşılaştırma
| Bir render protokolü | Rendel | |
|---|---|---|
| Bileşen söz varlığı | Evet ve açık | Evet: 36 adet, bize ait ve sürümlendirilmiş |
| Kendi bileşenlerinizi getirme | Amacı bu | Hayır. Bir katalog bloğunu kendi widget'ınızla yeniden çizebilirsiniz (ComponentRegistry.register, Flutter), ancak yeni bir tip ekleyemezsiniz. |
| aksiyon yürütme | Kapsam dışı | Tiplendirilmiş, risk seviyeleri belirlenmiş, onaylı |
| Güvenebileceğiniz onay | Kapsam dışı | Sunucunun oluşturduğu kart, isteğe bağlı olarak sunucunun kaydettiği dokunma |
| Çıkarım öncesi redaksiyon | Kapsam dışı | Yerleşik, isteğe bağlı değil |
| Çoklu kiracılık, kotalar, faturalandırma | Kapsam dışı | Bir sunucunun var olma sebebi |
| Dökümler, denetim, analitik | Kapsam dışı | yönetim paneli |
| Sağlayıcıya bağımlılık | Yok | Gerçek. Okumaya devam edin. |
Bu durum sizi nereye getiriyor
Aksiyon katmanını, güvenlik modelini ve operasyonel yüzeyi sahiplenmek isteyen bir arka uç ekibiniz varsa ve bir hizmetten ziyade bir söz varlığına ihtiyacınız varsa bir render protokolü kullanın. Bu meşru bir geliştirme sürecidir ve bir yılın büyük kısmını alır.
İstediğiniz şey, yanlış yapılması maliyetli olan kısımları önceden kararlaştırılmış şekilde, Rendel'in önümüzdeki hafta uygulamanızda çalışmasıysa bunu kullanın.
Platform bağımlılığı gerçektir ve adını koymaya değer. Sizin aksiyonlarınız SDK'mızın biçiminde tanımlanır, sohbetleriniz bizim veritabanımızda yer alır ve katalog bize aittir. Bunu azaltan unsurlar: manifest birebir MCP'nin tool biçimidir, bu sayede aksiyon tanımlarınız taşınabilirdir; her bileşen alan alan belgelenmiştir ve dışa aktarma istediğiniz her an tüm uygulamanızı tek bir dosya olarak size geri verir. Bunu dördüncü ayda fark etmeniz yerine açıkça belirtmeyi tercih ederiz.
Birini destekleyecek misiniz?
Muhtemelen bir girdi olarak: Tanımlanan bir bileşenin bizimkilerden birine uyduğu durumlarda kataloğa bir eşleme şeklinde. Katalog, bir cihazın neleri çizebileceğinin sözleşmesidir. Bizde olmayan bir bileşen; doğrulayamadığımız, kontrol edemediğimiz veya render edemediğimiz bir bileşendir, bu nedenle rastgele tanımlamaları kabul etmeyeceğiz. Bir şey uymadığında çözüm, bizim ekleyeceğimiz bir bloktur.
Bu konu sizin için bir kararı engelliyorsa, hangi protokolü istediğinizi belirtmek yerine buna ne için ihtiyaç duyduğunuzu bize iletin. Yanıt genellikle eklememiz gereken bir bileşendir.