Erstellen

Der Schnellstart hat Ihnen einen Aufruf gezeigt. Lesen Sie diese Zeile langsam, denn sie ist die ganze Zukunft in einem Satz: mit einem einzigen Application Key erhält jeder Nutzer Ihres Produktes Tausende KI-Verbindungen ab Tag eins, jeder Nutzer isoliert mit eigenen Connectors, Credentials und Capabilities, und keiner von ihnen jemals gegenüber Vinkius offengelegt. Keine Plattform auf dem Markt bietet diesen Satz. Die fünf vollständigen Builds dieses Abschnitts zeigen, wie er in Produktion aussieht: ein Consumer-Chatbot, Abteilungs-Copilots, eine Agentenflotte, unbeaufsichtigte Automationen und ein mandantenfähiges SaaS, jeder so geschrieben, dass ein Entwickler ganz oben anfangen und mit funktionsfähiger KI enden kann, die in der realen Welt handelt.

Das Primitiv unter allen fünf ist das, das der Rest der Industrie nicht anbietet: jede Entität, die handeln muss, wird zu einem Benutzer. Branchenkostenanalysen beziffern eine selbstgebaute Version dieser Architektur auf sechs Stellen über drei Jahre, und sie ist auch dann nie fertig ausgeliefert. Auf dem AI Connect SDK ist sie die Startlinie, nicht die Ziellinie.

Die Idee, die alles freischaltet

In jedem Tutorial taucht dieselbe Zeile auf:

const user = vinkius.user(externalId);

Diese externalId ist ein Wert, den Sie definieren. Es ist kein Vinkius-Konto, keine E-Mail, kein Mensch. Es ist eine opake, URL-sichere Zeichenkette, die Ihr Backend bereits kontrolliert, und das SDK behandelt sie als die Grenze, die Connectors, Credentials und Capabilities voneinander isoliert. Weil sie opak ist, kann sie alles benennen, das handeln muss:

Bedenken Sie, wie radikal das ist. Jede Konnektivitätsplattform, die die Industrie bis heute ausgeliefert hat, verbindet eine Anwendung mit einem Dienst. Keine davon gibt Ihrem Produkt ein eigenes Benutzermodell pro Entität, mit Credentials, die Ihr Code nie wieder auslesen kann. Die Zeile oben tut genau das, und sie ist der Unterschied zwischen gemieteter Konnektivität für Ihre App und einer eigenen Konnektivitätsplattform für Ihre Benutzer.

Wählen Sie Ihren Build

Der Ablauf, den alle Builds teilen

Unabhängig davon, welche Entität Sie modellieren, ist die Laufzeit-Schleife identisch. Lernen Sie sie einmal, und Sie können alle fünf aus dem Gedächtnis bauen:

1. Erstellen Sie einen Client auf Ihrem Server aus einem einzelnen Application Key.
2. Identifizieren Sie den Akteur: geben Sie vinkius.user(externalId) die ID, der die Aktion gehört.
3. Verbinden Sie einen Connector: user.connector('github').connect(), speichern Sie Credentials einmal, lesen Sie sie nie wieder aus.
4. Entdecken Sie Capabilities: user.capabilities() gibt nur zurück, was dieser Akteur bereit hat.
5. Geben Sie sie an ein Modell: ein Adapter wandelt die Menge in OpenAI, Anthropic, Gemini, Vercel AI SDK, LangChain oder reines JSON Schema um.
6. Führen Sie aus und speisen Sie zurück: führen Sie den Tool-Call des Modells aus; isError lässt den Agenten wiederherstellen, statt abzustürzen.

Der Wettbewerbsvorteil im Detail

Jeder der folgenden Builds stützt sich auf dieselbe Architektur, und sie zu verstehen macht das Versprechen „Sie besitzen die Integrationsinfrastruktur nicht" glaubwürdig statt bloßes Marketing.

• Zwei Ebenen, ein Geheimnis. Eine Kontroll-Ebene (users, connectors, credentials, catalog) über REST, und eine Ausführungs-Ebene (Capabilities auflisten und ausführen), die per JSON-RPC direkt mit dem Runtime jeder Verbindung spricht. Alles wird mit einem einzigen vk_app_sk_*-Key erreicht; der Runtime spricht intern das MCP-Protokoll, aber das erscheint niemals in Ihrem Vokabular.
• Pro Verbindung gemessen und widerrufbar. Jede Verbindung besitzt einen eigenen vk_live_*-Datenebenen-Token. Ausgabe und sofortiger Widerruf gelten pro Verbindung, weshalb eine Abteilung, ein Agent oder ein Dienstkonto finanziell und operativ isoliert werden kann, nicht nur logisch.
• Schreibgeschützte Credentials. Ihr Server speichert die Connector-Geheimnisse eines Benutzers und kann sehen, welche Felder konfiguriert sind, aber nichts, weder Ihr Code, noch das Modell, noch das Dashboard, liest die Werte je wieder aus.
• Maskierung als Standard. Observability-hooks werden mit bereinigten Daten gespeist: Authorization, credential-artige Felder und vk_live_*-URL-Segmente werden maskiert, bevor Ihr Callback läuft.
• Keine Laufzeitabhängigkeiten, überall. Natives fetch, duales ESM/CJS, typisiert, es läuft auf Node 18+, Bun, Deno und der Edge, sodass dasselbe Build-Ziel sowohl einen Cron-Container als auch einen Worker abdeckt.
• Wiederholung und Idempotenz, durchdacht. Flüchtige Fehler werden automatisch mit vollem Jitter-Backoff erneut versucht, und das Deklarieren eines idempotencyKey ist das, was selbst eine nicht-idempotente Schreibaktion sicher wiederholbar macht.

Bevor Sie beginnen

Jeder Build setzt dieselben drei Voraussetzungen voraus, die in Installation und Authentifizierung und Scope ausführlich behandelt werden:

• Node.js 18+ oder beliebiger Server-Runtime mit fetch (Bun, Deno, Edge, Cloudflare Workers)
• @vinkius/connect installiert
• Eine Vinkius-App-ID (vk_app_…) und ein Application Key (vk_app_sk_…) in Server-Umgebungsvariablen

Bereit? Keine andere Plattform auf dem Markt kann diesen Abschnitt beherbergen, weil keine seine Prämisse anbietet: dass ein Benutzer jede Entität ist, die handeln muss. Wählen Sie einen Build und beenden Sie ihn, mit einer KI, die für jeden Benutzer handelt, den Sie definieren.