Schnellstart

Einfach installieren und deinen Agenten fragen

Der kürzeste Weg ist, die CLI zu installieren und die Aufgabe deinem LLM zu übergeben. Der Agent liest die Docs-Registry, wählt den passenden Flow, führt die begrenzten Befehle aus und meldet zurück. Du beantwortest gelegentliche Fragen; der Agent erledigt das Setup.

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

Dann gib deinem LLM eine einzeilige Aufgabe:

LLM prompt

Use the ppl CLI in this shell. Start with ppl docs get flows/quickstart.

I want to build, integrate, test, deploy, debug, or document:

Use ppl docs tree and ppl docs search <query> when the next doc is not obvious. Run only commands available in the current profile. Report created or changed IDs, status, observed output, container logs when relevant, and any human-only decision.

Das ist das gesamte Onboarding. Der Agent erledigt component-Lookup, backend-Zusammensetzung, Parameterbindung, Fixture-Läufe, deployments und Nachweise. Er stoppt bei promotion und destruktivem Überschreiben und meldet diese für eine menschliche Entscheidung an dich.

Um es selbst zu bedienen, lies weiter. Der Rest dieser Seite behandelt den manuellen Pfad.

TL;DR

Pipelogic ist eine agent-native KI-Plattform: Jedes Primitiv — components, backends, deployments, applications — ist von einer einzigen CLI aus erreichbar, die so gebaut ist, dass ein LLM sie ebenso mühelos bedienen kann wie ein Mensch.
Die Codeeinheit ist das component: typisiert, versioniert, containerisiert. Die Kompositionseinheit ist das backend: ein geprüfter Graph, der component-Releases festpinnt und sie zu einem Workflow bindet. Die runtime-Einheit ist das deployment.
Die Plattform modelliert KI-Komposition als erstklassige Primitive — typisierte Streams, festgepinnte Releases, geprüfte Graphen, event-sourced backend-Mutationen, getrennte deployments — sodass die Arbeit des Verkettens von Inferenzschritten von der Plattform statt von projektspezifischem Klebecode erledigt wird.
Der Schnellstart beginnt dort, wo du stehst: Code schreiben, vorhandene components zusammensetzen, ein trainiertes Modell integrieren, eine Daten-Pipeline automatisieren, Verhalten vor der promotion nachweisen, Produktivbetrieb fahren oder eine UI binden.
Welchen Pfad du auch wählst, die Schleife ist dieselbe: Code festpinnen → in einen Graphen binden → den Graphen ausführen → Belege sammeln → entscheiden.

Was die Plattform ist

Pipelogic ist eine Plattform, die die gesamte KI-Kompositionsoberfläche — Verketten von Inferenzschritten, Marshalling typisierter Payloads, Versionieren von Modellen, Teilen von Fähigkeiten und Nachweisen von Verhalten über Versionen hinweg — als erstklassige Objekte statt als projektspezifischen Klebecode modelliert.

Die Primitive bilden diese Anliegen direkt ab:

Components umhüllen die lauffähige Einheit (eine Python- oder C++-Codebasis plus ihre Containerisierung). Jedes Release ist unveränderlich und adressierbar; backends pinnen ein bestimmtes Release fest.
Typisierte Streams zwischen components werden zur Graph-Editier-Zeit geprüft, vor dem deployment. Eine Image-Ausgabe an eine [BoundingBox]-Eingabe zu verbinden schlägt sofort fehl, mit einem präzisen Typfehler, statt zur runtime innerhalb eines Containers.
Backends sind ein event-sourced Graph: Jede Änderung (add-vertex, connect, change-parameter, add-file, change-endpoint-alias) ist eine Operation mit einer Inversen, sodass der gesamte Graph rückgängig machbar, reproduzierbar und inspizierbar ist.
Deployments entkoppeln „Graph-Definition" von „Live-runtime". Dasselbe backend kann auf verschiedenen runtimes (managed Cloud, eigene Hardware) erneut bereitgestellt werden, ohne irgendetwas neu zu schreiben.
Applications binden eine Produkt-UI an die endpoints des bereitgestellten backend, wenn die Lösung eine dem Menschen zugewandte Oberfläche braucht.

Die CLI (ppl) ist die erstklassige Steueroberfläche für all dies. Sie ist von Anfang an für LLM-getriebene Workflows gebaut: maschinenlesbare Ausgabe, agent-Profile, die festlegen, was das Modell sehen und ausführen kann, und destruktive Operationen, die an der Befehlsgrenze gesperrt sind. Ein Mensch kann sie auf dieselbe Weise bedienen; die App unter app.pipelogic.ai ist eine visuelle Oberfläche über denselben Primitiven.

Ein Satz Primitive, viele Einstiegspunkte

Jeder Einstiegspunkt — aus dem Katalog zusammensetzen, eigene components mitbringen, eigene trainierte Modelle binden, auf managed Cloud oder eigener registrierter Hardware laufen, von einem LLM oder einem Browser aus steuern — landet auf denselben Primitiven, ohne Neuschreiben für den Wechsel dazwischen.

Die umgebende Maschinerie wird über diese Einstiegspunkte hinweg geteilt: direkte Integrationen zu gängigen Hubs und Registries, Typprüfung beim Komponieren von components, Kapazitätsprüfungen beim Landen von deployments und Aufräumen beim Schließen von leases. Jedes ist Teil der Plattform, damit es nicht pro Projekt neu gebaut werden muss.

Mentales Modell

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

Das Diagramm von unten nach oben gelesen: Ein deployment ist eine laufende Instanz eines backend-Graphen auf einer runtime; der Graph selbst ist eine typisierte Komposition festgepinnter component-Releases; Releases stammen aus dem Quellcode des component plus einem component.yml-Manifest, das deklariert, was das component konsumiert, produziert und konfiguriert.

Eine vollständige Lösung ist das bereitgestellte backend, der Beleg, dass es sich wie erwartet verhält, und (wenn das Produkt es braucht) eine application, die an seine endpoints gebunden ist. Alles andere ist unterstützende Maschinerie.

Neu auf der Plattform? Lies zuerst Components und Backends.

Warum eine CLI-first, agent-native Oberfläche

Die CLI ist die primäre Oberfläche, weil sie der Plattform präzise Kontrolle über zwei Dinge gibt, die für LLM-getriebene Workflows wichtig sind: Kontextgröße und Sicherheit an der Befehlsgrenze. Ein Befehl führt eine begrenzte Operation aus, liefert ein kompaktes Ergebnis, und der nächste Befehl wird aus diesem Ergebnis gewählt. Es gibt keine große vorab zu ladende Tool-Registry, kein Streuen von Zwischenzuständen durch das Modell.

Agent-Profile sind eine echte Ausführungsoberfläche, kein Formatierungs-Flag. Das Umschalten der Shell in ein agent-Profil ändert, welche Befehle sichtbar sind, sperrt die Oberfläche gegen destruktive Operationen, schaltet die Ausgabe auf maschinenlesbare Formen um und verhindert, dass die Sitzung still in eine menschliche Oberfläche zurückentkommt. Dasselbe ppl-Binary dient menschlichen Benutzern und LLM-Agenten; das Profil ist, was sich unterscheidet.

Setze die Shell in das breite Einstiegsprofil und lass dein LLM steuern:

ppl mode general

Nach mode bleiben Befehle einfaches ppl …; das Profil ist für die Sitzung haftend. Eine Pro-Befehl-Übersteuerung ist ebenfalls für einmalige Aufrufe verfügbar, ohne die gespeicherte Sitzung zu ändern.

Die Docs-Registry ist die Karte des Agenten von der Plattform: Entdecke die verfügbare Dokumentation als Baum, suche, wenn der Zweig unklar ist, hole den genauen Flow und führe dann den nächsten begrenzten Befehl aus. Der Agent braucht kein separates Konzept davon, „welche Flows existieren" — er fragt die Registry.

ppl docs treeppl docs search <query>ppl docs get flows/quickstart

Die MCP-Integration wird für Editor-Workflows hinzugefügt, aber sie baut auf demselben ppl-Befehl und derselben Docs-Oberfläche auf, statt sie zu ersetzen. Die CLI bleibt der tragende Pfad, damit der Standard-LLM-Workflow schlank und deterministisch bleibt.

Installieren und anmelden

curl -fsSL https://app.pipelogic.ai/api/v1/install | bashppl register      # new accountppl login         # existing account (browser flow)ppl login --console   # terminal credentials when browser is unavailable

Wähle deinen Ausgangspunkt

Jeder Schnellstart-Pfad landet in derselben Schleife — Code festpinnen, in einen Graphen binden, den Graphen ausführen, Belege sammeln — aber jeder beginnt mit einem anderen Artefakt, das du bereits hast.

Ein component bauen

Verwende diesen Pfad, wenn die Arbeitseinheit neuer Code ist: eine Python- oder C++-Implementierung einer Fähigkeit, die noch nicht im Katalog existiert oder die du als wiederverwendbaren Baustein besitzen willst.

Ein component ist mehr als „eine als Container verpackte Funktion". Es ist ein typisierter Vertrag: deklarierte Eingabe- und Ausgabe-Stream-Typen, deklariertes Konfigurationsschema, optionale deklarierte Modell-Datei-Slots, optionale deklarierte Service-Abhängigkeiten. Der typisierte Vertrag ist das, worauf sich der backend-Graph zur Kompositionszeit verlässt, und das, was dasselbe component über viele backends hinweg wiederverwendbar macht, ohne neu erklären zu müssen, was es tut.

Die Autoren-Schleife ist bewusst kurz: die Codebasis scaffolden, die Implementierung gegen die typisierten Eingaben und Ausgaben schreiben, eine prerelease veröffentlichen (die Plattform baut und registriert sie), dann die prerelease innerhalb eines live backend testen, bevor sie promotet wird. Die promotion in den freigegebenen Katalog ist eine separate, bewusste Entscheidung — sie ist die öffentliche Zusicherung, dass die Version stabil ist.

Walkthrough und sprachspezifische Authoring-Details: Test with a live backend, Release semantics und die Component API reference.

Ein backend aus vorhandenen components zusammensetzen

Verwende diesen Pfad, wenn der Katalog bereits die Bausteine enthält und die Arbeit Komposition ist: die richtigen components wählen, ihre typisierten Streams miteinander verdrahten, Parameter und Dateien binden und die endpoints freilegen, die der Aufrufer oder die application verwenden wird.

Die backend-Zusammensetzung ist event-sourced Graph-Editierung: Jede Änderung ist eine Operation mit einer Inversen, der gesamte Graph ist aus seinem Operations-Log reproduzierbar, die Typinferenz läuft bei jeder Bearbeitung erneut, sodass Inkonsistenzen sofort sichtbar werden, und dieselben Bearbeitungen laufen unverändert in der App und über die CLI.

Backends komponieren; components nicht. Ein gegebenes component kann als mehrere vertices im selben backend mit unterschiedlichen Parameterbindungen und unterschiedlichen nachgelagerten Konsumenten erscheinen. Diese Trennung ist der Grund, warum eine einzelne Fähigkeit viele Lösungen antreiben kann, ohne den Code zu forken.

Walkthrough: Backend operations und Test with a live backend.

Ein trainiertes Modell integrieren

Verwende diesen Pfad, wenn die Eingabe ein Modell-Artefakt ist: Gewichte, Checkpoint, ONNX-Datei, Adapter oder ein Modell-Repository, und die Arbeit ist, „es in eine bedienende Fähigkeit innerhalb eines backend zu verwandeln".

Pipelogic trennt „Modell-bedienende Infrastruktur" bewusst vom „Modell-Artefakt". Bedienende runtimes — Triton, TorchServe, Ollama, vLLM, SGLang — sind plattformverwaltete Services. Ein component deklariert, von welchem bedienenden Service es abhängt, und die Plattform stellt den Service neben den component-Containern auf, wenn das backend bereitgestellt wird. Du betreibst Triton nicht; du zeigst darauf.

Das Artefakt selbst wird als typisierte Datei hochgeladen, dann in den Datei-Slot eines component-vertex gebunden. Diese Bindung ist Teil des backend-Graphen: Sie ist reproduzierbar, rückgängig machbar, und das Tauschen des Artefakts gegen eine neue Version ist eine einzige Graph-Mutation statt eines erneuten deployment des zugrunde liegenden bedienenden Service. Dasselbe Modell kann in mehrere backends gebunden werden; verschiedene Modellversionen können innerhalb eines einzigen backend per A/B getestet werden, indem beide in Geschwister-vertices gebunden werden.

Die harte Arbeit in diesem Pfad ist selten „die Datei hochladen". Es ist schnelle Iteration: das Artefakt ändern, repräsentative Fixtures ausführen, Ausgaben vergleichen, Kaltstart- und Dauerlatenz messen, Fehlermodi prüfen (Out-of-Memory, falscher Tokenizer, falsche Bildgröße, falscher Label-Satz) und entscheiden, ob das Artefakt bereit für die promotion ist.

Walkthrough: Model artifact integration und Models.

Eine Daten-Pipeline automatisieren

Verwende diesen Pfad, wenn die Eingabe Daten sind — CSV, Bilder, Audio, JSON, Parquet oder ein beliebiger wiederholbarer Eingabesatz — und die Arbeit ist, „sie durch ein backend zu verarbeiten, nach Zeitplan oder auf Abruf, auf eine Weise, die nächstes Quartal reproduzierbar ist".

Ein backend ist standardmäßig ein Echtzeit-Graph: Es konsumiert seine Eingaben als typisierte Streams und gibt Ausgaben als typisierte Streams aus. Das ist genau das, was eine „automatisierte Daten-Pipeline" braucht. Dasselbe backend kann als einmalige Fixture, als geplanter Batch über ein Verzeichnis von Eingaben oder als langlebiger Stream-Konsument laufen; der Graph ändert sich nicht, nur die Eingabequelle.

Daten-Pipelines als backends zu behandeln — nicht als maßgeschneiderte ETL-Skripte — verschafft dir dieselben Garantien wie der Rest der Plattform: Typprüfung vor dem deployment, reproduzierbare Läufe über Versionen hinweg, austauschbare component-Releases, trennbare runtimes. Die gestrige Pipeline produziert immer noch die gestrige Ausgabe, weil das backend von Ende zu Ende festgepinnt ist.

Walkthrough: Data pipeline automation und File upload and binding.

Verhalten vor der promotion nachweisen

Verwende diesen Pfad, wenn etwas kurz vor dem Ausliefern steht — eine neue component-Version, ein neues Modell-Artefakt, eine neue backend-Revision — und die Arbeit ist, „reproduzierbare Belege zu erzeugen, dass es tut, was es behauptet, auf den Eingaben, die zählen".

Der Nachweis wird als erstklassige Schleife behandelt, nicht als nachträglicher Gedanke. Die mentale Form ist dieselbe wie ein Test in jeder anderen Ingenieursdisziplin: die genaue zu testende Einheit identifizieren, die Fixtures einfrieren, sie durch die runtime laufen lassen, Ausgaben und runtime-Signale sammeln, mit den Erwartungen vergleichen, die Artefakte behalten. Pipelogic gibt dir die Primitive — festgepinnte Versionen, deterministische Graphen, erfassbare Ausgaben, Container-Logs — und hält sich aus dem Geschäft heraus, zu erklären, was „besteht".

Der Nachweis braucht seine eigene Schleife, weil ein einzelnes bestehendes Beispiel kein Beleg ist. Echter Nachweis ist Fixture-Abdeckung, Erfassung von runtime-Signalen, semantischer Vergleich und eine Aufzeichnung, die gegen die nächste Kandidatenversion replayt werden kann, sodass eine promotion-Entscheidung auf beobachtetem Verhalten statt auf einer Vermutung beruht.

Walkthrough: Prove behavior.

Bereitstellen, überwachen und debuggen

Verwende diesen Pfad, wenn der Graph bereits sauber ist und die Arbeit das Betreiben ist: auf eine runtime bereitstellen, die laufenden Container beobachten, debuggen, wenn etwas sich falsch verhält, bei einem Versionssprung erneut bereitstellen, abbauen, wenn fertig.

Das deployment ist bewusst vom Graph-Editieren getrennt. Das backend ist eine geprüfte Definition; das deployment ist eine laufende Instanz dieser Definition auf einer runtime. Dasselbe backend kann mehrfach in verschiedenen Umgebungen bereitgestellt werden, indem das backend zuerst geforkt wird — die Verbindung zwischen einem backend und seinem deployment ist 1:1, und diese Einschränkung macht „was gerade läuft" eindeutig.

Einmal bereitgestellt, verschiebt sich die runtime-Sicht von „dem Graphen" zu „den Containern": Jeder vertex wird zu einem oder mehreren component-Containern auf der runtime, jede Kante wird zum Plattform-Transport zwischen ihnen. Das Debuggen ist auf Container-Ebene — Container-Logs sind die Quelle der Wahrheit dafür, was ein component tut — und die Plattform legt dieselbe vertex/endpoint/runtime-Abbildung offen, die der Graph hatte.

Walkthrough: Deploy and monitor und Deployments. Fehler-Nachschlag: Common failures.

Eine application an ein backend binden

Verwende diesen Pfad, wenn die Lösung zusätzlich zum backend-Graphen eine Produkt-UI braucht.

Eine application in Pipelogic ist eine verwaltete Oberfläche, die von einem Manifest deklariert wird. Jeder Eintrag im needs-Array des Manifests deklariert einen benannten endpoint, den die UI benötigt: seine Rolle, seine Richtung (ingress oder egress), die Transporte, die er spricht (http, ws, sse oder webrtc), und ob er erforderlich ist. Das Manifest wird an ein bereitgestelltes backend gebunden, damit endpoint-URLs konsistent auflösen und damit ein Brechen der Bindung — das Bereitstellen einer inkompatiblen backend-Revision — als application-Fehler statt als still fehlgeschlagene Anfrage sichtbar wird.

Die application-Erstellung ist derzeit eine private Alpha-Oberfläche — die Befehlsgruppe erscheint nur in Workspaces, in denen sie aktiviert wurde. Wenn verfügbar, ist die Schleife: das Manifest deklarieren, das UI-Image bauen oder hochladen, die application bereitstellen, die URL verifizieren, iterieren.

Siehe Applications und Deploy and monitor.

Wo die Schleife endet

Jeder Pfad landet am selben Kontrollpunkt: eine Fixture ging hinein, eine Ausgabe kam zurück, der runtime-Zustand wurde inspiziert, und eine eindeutige Entscheidung ist verfügbar — promoten, erneut bereitstellen, forken, abbauen oder an einen Menschen zurückgeben. Typisierte Graphen, unveränderliche Releases, getrennte deployments und Nachweis-Schleifen sind das, was diese Entscheidung auf angefügten Belegen statt auf einer Vermutung beruhen lässt, ob die Funktion funktioniert hat.