Hızlı Başlangıç

Sadece kur ve agent'ına sor

En kısa yol CLI'ı kurmak ve görevi LLM'ine devretmektir. agent docs kayıt defterini okur, eşleşen akışı seçer, sınırlanmış komutları çalıştırır ve geri bildirim yapar. Sen ara sıra soruları yanıtlarsın; agent kurulumu yapar.

curl -fsSL https://app.pipelogic.ai/api/v1/install | bashCopyppl login                # or `ppl register` for a new accountCopyppl mode general         # put the shell into the starter agent profileCopy

Sonra LLM'ine tek satırlık bir görev ver:

İşe alıştırma süreci bundan ibarettir. agent component arama, backend kurulumu, parametre bağlama, fixture çalıştırmaları, deployment'lar ve kanıtı yürütür. promotion ve yıkıcı üzerine yazmada durur ve bunları bir insan kararı için sana bildirir.

Onu kendin sürmek için okumaya devam et. Bu sayfanın geri kalanı manuel yolu kapsar.

TL;DR

• Pipelogic bir agent-native yapay zeka platformudur: her primitif — component'ler, backend'ler, deployment'lar, application'lar — bir LLM'in bir insan kadar kolay sürebileceği şekilde inşa edilmiş tek bir CLI'dan erişilebilir.
• Kod birimi component'tir: tipli, sürümlenmiş, konteynerleştirilmiş. Kompozisyon birimi backend'tir: component release'lerini sabitleyen ve onları tek bir iş akışına bağlayan denetlenmiş bir graf. runtime birimi deployment'tır.
• Platform, yapay zeka kompozisyonunu birinci sınıf primitifler olarak modeller — tipli akışlar, sabitlenmiş release'ler, denetlenmiş graflar, event-sourced backend mutasyonları, ayrılmış deployment'lar — böylece çıkarım adımlarını kompoze etme işi, proje başına yapıştırma kodu yerine platform tarafından ele alınır.
• Hızlı başlangıç nerede olursan ol oradan başlar: kod yazma, mevcut component'leri kurma, eğitilmiş bir modeli entegre etme, bir veri hattını otomatikleştirme, promotion öncesi davranışı kanıtlama, üretim çalıştırma veya bir UI bağlama.
• Hangi yolu seçersen seç, döngü aynıdır: kodu sabitle → bir grafa bağla → grafı çalıştır → kanıt topla → karar ver.

Platform nedir

Pipelogic, tüm yapay zeka kompozisyon yüzeyini — çıkarım adımlarını zincirleme, tipli yükleri sıralama, modelleri sürümleme, yetenekleri paylaşma ve sürümler arası davranışı kanıtlama — proje başına yapıştırma kodu yerine birinci sınıf nesneler olarak modelleyen bir platformdur.

Primitifler bu kaygıları doğrudan eşler:

• Component'ler çalıştırılabilir birimi (bir Python veya C++ kod tabanı artı konteynerleştirilmesi) sarar. Her release değişmez ve adreslenebilirdir; backend'ler belirli bir release'i sabitler.
• component'ler arasındaki tipli akışlar graf-düzenleme zamanında, deployment'tan önce denetlenir. Bir Image çıktısını bir [BoundingBox] girdisine bağlamak, bir konteyner içinde runtime'da değil, derhal kesin bir tip hatasıyla başarısız olur.
• Backend'ler event-sourced bir graftır: her değişiklik (add-vertex, connect, change-parameter, add-file, change-endpoint-alias) bir tersi olan bir işlemdir, böylece tüm graf geri alınabilir, yeniden üretilebilir ve incelenebilirdir.
• Deployment'lar "graf tanımı"nı "canlı runtime"dan ayırır. Aynı backend, hiçbir şeyi yeniden yazmadan farklı runtime'larda (yönetilen bulut, kendi donanımın) yeniden dağıtılabilir.
• Application'lar, çözüm insana dönük bir yüzey gerektirdiğinde bir ürün UI'sini dağıtılmış backend endpoint'lerine bağlar.

CLI (ppl) tüm bunlar için birinci sınıf kontrol yüzeyidir. Baştan beri LLM-güdümlü iş akışları için inşa edilmiştir: makine tarafından okunabilir çıktı, modelin neyi görüp çalıştırabileceğini kapsayan agent profilleri ve komut sınırında kapılanmış yıkıcı işlemler. Bir insan onu aynı şekilde sürebilir; app.pipelogic.ai adresindeki App, aynı primitifler üzerinde görsel bir yüzeydir.

Tek bir primitif kümesi, birçok giriş noktası

Her giriş noktası — katalogdan kurma, kendi component'lerini getirme, kendi eğitilmiş modellerini bağlama, yönetilen bulut veya kendi kayıtlı donanımında çalıştırma, bir LLM'den veya bir tarayıcıdan sürme — aralarında geçiş için yeniden yazma olmadan aynı primitiflere iner.

Çevreleyen mekanizma bu giriş noktaları arasında paylaşılır: yaygın hub'lara ve registry'lere doğrudan entegrasyonlar, component'ler kompoze edildiğinde tip denetimi, deployment'lar yerleştiğinde kapasite denetimi ve lease'ler kapandığında temizlik. Her biri platformun parçasıdır, böylece proje başına yeniden inşa edilmesi gerekmez.

Zihinsel model

component.yml + src/
        │
        ▼
   component
   prerelease  ──promote──▶  released version
        │
        ▼
   backend graph ──deploy──▶ deployment ──▶ proof + (optional) application
   (vertices,
    bindings,
    endpoints)

Diyagramı alttan yukarıya okuyalım: bir deployment, bir runtime üzerinde bir backend grafının çalışan bir örneğidir; grafın kendisi sabitlenmiş component release'lerinin tipli bir kompozisyonudur; release'ler, component'in kaynak kodundan artı component'in neyi tükettiğini, ürettiğini ve yapılandırdığını bildiren bir component.yml manifestosundan gelir.

Eksiksiz bir çözüm dağıtılmış backend, beklendiği gibi davrandığına dair kanıt ve (ürün gerektirdiğinde) endpoint'lerine bağlı bir application'dır. Geri kalan her şey destekleyici mekanizmadır.

Platforma yeni misin? Önce Components ve Backends oku.

Neden CLI-first, agent-native bir yüzey

CLI birincil yüzeydir çünkü platforma LLM-güdümlü iş akışları için önemli olan iki şey üzerinde kesin kontrol verir: bağlam boyutu ve komut sınırındaki güvenlik. Bir komut bir sınırlı işlem çalıştırır, bir kompakt sonuç döndürür ve bir sonraki komut o sonuçtan seçilir. Yüklenecek büyük bir ön-yükleme araç kayıt defteri yoktur, ara durumun modelden saçılması yoktur.

Agent profilleri bir biçimlendirme bayrağı değil, gerçek bir yürütme yüzeyidir. Shell'i bir agent profiline geçirmek hangi komutların görünür olduğunu değiştirir, yüzeyi yıkıcı işlemlere karşı kilitler, çıktıyı makine tarafından okunabilir biçimlere geçirir ve oturumun sessizce bir insan yüzeyine geri kaçmasını önler. Aynı ppl binary'si insan kullanıcılara ve LLM agent'larına hizmet eder; farklılaşan profildir.

Shell'i geniş başlangıç profiline ayarla ve LLM'inin sürmesine izin ver:

ppl mode generalCopy

mode'dan sonra komutlar düz ppl … olarak kalır; profil oturum boyunca yapışkandır. Kaydedilmiş oturumu değiştirmeden tek seferlik çağrılar için komut-başına geçersiz kılma da mevcuttur.

docs kayıt defteri, agent'ın platform haritasıdır: mevcut belgeleri bir ağaç olarak keşfet, dal belirsizken ara, tam akışı getir, sonra bir sonraki sınırlı komutu çalıştır. agent'ın "hangi akışlar var" diye ayrı bir kavrama ihtiyacı yoktur — kayıt defterine sorar.

ppl docs treeCopyppl docs search <query>Copyppl docs get flows/quickstartCopy

MCP entegrasyonu editör iş akışları için ekleniyor, ancak onu değiştirmek yerine aynı ppl komutu ve docs yüzeyi üzerine inşa ediyor. CLI yük taşıyan yol olarak kalır, böylece varsayılan LLM iş akışı yalın ve deterministik kalır.

Kur ve oturum aç

curl -fsSL https://app.pipelogic.ai/api/v1/install | bashCopyppl register      # new accountCopyppl login         # existing account (browser flow)Copyppl login --console   # terminal credentials when browser is unavailableCopy

Başlangıç noktanı seç

Her hızlı başlangıç yolu aynı döngüye iner — kodu sabitle, bir grafa bağla, grafı çalıştır, kanıt topla — ama her biri zaten elinde olan farklı bir yapıttan başlar.

Bir component oluştur

İş birimi yeni kod olduğunda bu yolu kullan: katalogda henüz var olmayan veya yeniden kullanılabilir bir yapı taşı olarak sahiplenmek istediğin bir yeteneğin Python veya C++ implementasyonu.

Bir component "bir konteyner olarak paketlenmiş bir fonksiyon"dan fazlasıdır. Tipli bir sözleşmedir: bildirilen girdi ve çıktı akış tipleri, bildirilen yapılandırma şeması, isteğe bağlı bildirilen model dosya yuvaları, isteğe bağlı bildirilen servis bağımlılıkları. Tipli sözleşme, backend grafının kompozisyon zamanında dayandığı şeydir ve aynı component'i ne yaptığını yeniden açıklamadan birçok backend arasında yeniden kullanılabilir kılan şeydir.

Yazar döngüsü kasıtlı olarak kısadır: kod tabanını scaffold et, implementasyonu tipli girdi ve çıktılara karşı yaz, bir prerelease yayımla (platform onu derler ve kaydeder), sonra promote etmeden önce prerelease'i bir live backend içinde test et. Yayımlanmış kataloğa promotion ayrı, bilinçli bir karardır — sürümün kararlı olduğuna dair herkese açık taahhüttür.

İzlenecek yol ve dile özgü yazma ayrıntıları: Test with a live backend, Release semantics ve Component API reference.

Mevcut component'lerden bir backend kur

Katalog yapı taşlarına zaten sahipken ve iş kompozisyon olduğunda bu yolu kullan: doğru component'leri seç, tipli akışlarını birbirine bağla, parametreleri ve dosyaları bağla ve çağıranın veya application'ın kullanacağı endpoint'leri açığa çıkar.

backend kurulumu event-sourced graf düzenlemedir: her değişiklik bir tersi olan bir işlemdir, tüm graf işlem logundan yeniden üretilebilir, tip çıkarımı her düzenlemede yeniden çalışır böylece uyumsuzluklar derhal görünür olur ve aynı düzenlemeler App'te ve CLI üzerinden değişmeden çalışır.

backend'ler kompoze olur; component'ler olmaz. Belirli bir component aynı backend'de farklı parametre bağlamaları ve farklı aşağı akış tüketicileriyle birden çok vertex olarak görünebilir. Bu ayrım, tek bir yeteneğin kodu fork etmeden birçok çözüme güç verebilmesinin nedenidir.

İzlenecek yol: Backend operations ve Test with a live backend.

Eğitilmiş bir modeli entegre et

Girdi bir model yapıtı olduğunda bu yolu kullan: ağırlıklar, checkpoint, ONNX dosyası, adaptör veya bir model deposu, ve iş "onu bir backend içinde bir sunum yeteneğine dönüştürmek".

Pipelogic "model sunum altyapısı"nı "model yapıtı"ndan kasıtlı olarak ayırır. Sunum runtime'ları — Triton, TorchServe, Ollama, vLLM, SGLang — platform tarafından yönetilen servislerdir. Bir component hangi sunum servisine bağlı olduğunu bildirir ve backend dağıtıldığında platform servisi component konteynerlerinin yanında ayağa kaldırır. Triton'u sen çalıştırmazsın; ona işaret edersin.

Yapıtın kendisi tipli bir dosya olarak yüklenir, sonra bir component vertex'inin dosya yuvasına bağlanır. Bu bağlama backend grafının bir parçasıdır: yeniden üretilebilirdir, geri alınabilirdir ve yapıtı yeni bir sürümle değiştirmek, alttaki sunum servisinin yeniden dağıtımı yerine tek bir graf mutasyonudur. Aynı model birden çok backend'e bağlanabilir; farklı model sürümleri her ikisini de kardeş vertex'lere bağlayarak tek bir backend içinde A/B test edilebilir.

Bu yoldaki zor iş nadiren "dosyayı yükle"dir. Hızlı iterasyondur: yapıtı değiştir, temsili fixture'lar çalıştır, çıktıları karşılaştır, soğuk başlatma ve kararlı durum gecikmesini ölç, hata modlarını kontrol et (bellek yetersizliği, yanlış tokenizer, yanlış görüntü boyutu, yanlış etiket kümesi) ve yapıtın promotion için hazır olup olmadığına karar ver.

İzlenecek yol: Model artifact integration ve Models.

Bir veri hattını otomatikleştir

Girdi veri olduğunda — CSV, görüntü, ses, JSON, parquet veya herhangi bir tekrarlanabilir girdi seti — ve iş "onu bir backend üzerinden, bir zamanlamada veya talep üzerine, gelecek çeyrekte yeniden üretilebilir bir şekilde işlemek" olduğunda bu yolu kullan.

Bir backend varsayılan olarak gerçek zamanlı bir graftır: girdilerini tipli akışlar olarak tüketir ve çıktıları tipli akışlar olarak yayar. "Otomatikleştirilmiş bir veri hattının" tam da ihtiyaç duyduğu şey budur. Aynı backend tek seferlik bir fixture olarak, bir girdi dizini üzerinde zamanlanmış bir batch olarak veya uzun ömürlü bir akış tüketicisi olarak çalışabilir; graf değişmez, yalnızca girdi kaynağı değişir.

Veri hatlarını backend'ler olarak ele almak — özel ETL betikleri olarak değil — sana platformun geri kalanının verdiği aynı garantileri kazandırır: deployment öncesi tip denetimi, sürümler arası yeniden üretilebilir çalıştırmalar, değiştirilebilir component release'leri, ayrılabilir runtime'lar. Dünkü hat hâlâ dünkü çıktıyı üretir, çünkü backend uçtan uca sabitlenmiştir.

İzlenecek yol: Data pipeline automation ve File upload and binding.

promotion'dan önce davranışı kanıtla

Bir şey gönderilmek üzereyken bu yolu kullan — yeni bir component sürümü, yeni bir model yapıtı, yeni bir backend revizyonu — ve iş "iddia ettiği şeyi, önemli olan girdiler üzerinde yaptığına dair yeniden üretilebilir kanıt üretmek".

Kanıt sonradan akla gelen bir şey değil, birinci sınıf bir döngü olarak ele alınır. Zihinsel biçim, başka herhangi bir mühendislik disiplinindeki bir testle aynıdır: test edilen tam birimi tanımla, fixture'ları dondur, onları runtime'dan geçir, çıktıları ve runtime sinyallerini topla, beklentilerle karşılaştır, yapıtları sakla. Pipelogic sana primitifleri verir — sabitlenmiş sürümler, deterministik graflar, yakalanabilir çıktılar, konteyner logları — ve neyin "geçtiğini" bildirme işinden uzak durur.

Kanıt kendi döngüsüne ihtiyaç duyar çünkü tek bir başarılı örnek kanıt değildir. Gerçek kanıt fixture kapsaması, runtime-sinyali yakalama, anlamsal karşılaştırma ve bir sonraki aday sürüme karşı replay edilebilen bir kayıttır, böylece bir promotion kararı bir tahmin yerine gözlemlenen davranışa dayanır.

İzlenecek yol: Prove behavior.

Dağıt, izle ve hata ayıkla

Graf zaten temizken ve iş onu işletmek olduğunda bu yolu kullan: bir runtime'a dağıt, çalışan konteynerleri izle, bir şey yanlış davrandığında hata ayıkla, bir sürüm artışında yeniden dağıt, bittiğinde kaldır.

deployment kasıtlı olarak graf düzenlemeden ayrıdır. backend denetlenmiş bir tanımdır; deployment o tanımın bir runtime üzerindeki çalışan bir örneğidir. Aynı backend, önce backend'i fork ederek farklı ortamlarda birden çok kez dağıtılabilir — bir backend ile deployment'ı arasındaki bağ 1:1'dir ve bu kısıtlama "şu anda neyin çalıştığını" net kılan şeydir.

Bir kez dağıtıldığında, runtime görünümü "graf"tan "konteynerler"e kayar: her vertex runtime üzerinde bir veya daha fazla component konteynerine dönüşür, her kenar aralarında platform taşımasına dönüşür. Hata ayıklama konteyner düzeyindedir — konteyner logları bir component'in ne yaptığına dair gerçeğin kaynağıdır — ve platform grafın sahip olduğu aynı vertex/endpoint/runtime eşlemesini açığa çıkarır.

İzlenecek yol: Deploy and monitor ve Deployments. Hata arama: Common failures.

Bir application'ı bir backend'e bağla

Çözüm backend grafına ek olarak bir ürün UI'sine ihtiyaç duyduğunda bu yolu kullan.

Pipelogic'te bir application, bir manifesto tarafından bildirilen yönetilen bir yüzeydir. Manifestonun needs dizisindeki her giriş, UI'ın gerektirdiği adlandırılmış bir endpoint bildirir: rolü, yönü (ingress veya egress), konuştuğu taşımalar (http, ws, sse veya webrtc) ve gerekli olup olmadığı. Manifesto dağıtılmış bir backend'e bağlanır, böylece endpoint URL'leri tutarlı şekilde çözülür ve böylece bağlamayı bozmak — uyumsuz bir backend revizyonu dağıtmak — sessiz bir başarısız istek olarak değil, bir application hatası olarak görünür olur.

application oluşturma şu anda özel bir alfa yüzeyidir — komut grubu yalnızca etkinleştirildiği workspace'lerde görünür. Kullanılabilir olduğunda döngü şudur: manifestoyu bildir, UI image'ını oluştur veya yükle, application'ı dağıt, URL'yi doğrula, iterasyon yap.

Applications ve Deploy and monitor bölümlerine bak.

Döngü nerede biter

Her yol aynı kontrol noktasına iner: bir fixture girdi, bir çıktı geri geldi, runtime durumu incelendi ve net bir karar mevcut — promote et, yeniden dağıt, fork et, kaldır veya bir insana geri ver. Tipli graflar, değişmez release'ler, ayrılmış deployment'lar ve kanıt döngüleri, bu kararın özelliğin işe yarayıp yaramadığına dair bir çıkarım yerine ekli kanıta dayanmasını sağlayan şeylerdir.

İlgili

• Components — bir component'in gerçekte ne olduğu ve release'lerin nasıl çalıştığı.
• Backends — tipli graflar ve event-sourced işlem logu.
• Types — backend bağlantılarının doğruladığı sözleşmeler.
• Deployments — bir runtime üzerindeki bir backend için runtime modeli.
• Guides — göreve göre önerilen okuma sırası.
• Deploy and monitor — denetlenmiş backend'den canlı trafiğe.