Von Tool-Aufrufen zum Agent-Computer: Wie sich die Architektur verändert

Stell dir einen Button zum Lieferantenvergleich in deinem Produkt vor. Ein Kunde wählt mehrere Angebote und möchte eine Tabelle mit Preisen, Lieferterminen und abweichenden Bedingungen. Dein erster Prototyp sendet den Text an ein Modell. Bei einem kurzen Angebot funktioniert das. Dann liefert ein Kunde gescannte PDFs, eine Tabelle und einen Link zur Website eines Lieferanten.

Jetzt muss die Funktion Dateien öffnen, Tabellen auslesen, die Website prüfen, Preise vergleichbar berechnen und eine Tabelle zum Herunterladen erstellen. Das Modell hilft zu entscheiden, was zu tun ist. Es braucht auch einen Ort, an dem die dafür nötigen Programme laufen. Hier hilft ein Agentencomputer.

Was folgt, wenn das Modell einen Befehl ausführen möchte?

Ein Tool-Aufruf ist eine Anfrage des Modells an dein Programm. Das Modell fordert etwa ein Skript an, das die Angebote liest. Dein Programm muss Eingabedateien bereitstellen, den Parser installieren, das Skript ausführen und dessen Ausgabe zurückgeben. Scheitert der Parser an einer gescannten Seite, muss der Agent den Fehler prüfen und eine andere verfügbare Extraktionsmethode versuchen.

Diese Schritte kannst du selbst bauen. Mit wachsendem Funktionsumfang brauchst du außerdem einen Browser, Dateizugriff, Befehlsausgaben und getrennte Arbeitsbereiche für die Kunden. Beeuni fasst das in einer Session zusammen: Der Agent arbeitet auf einem Cloud-Computer, liest Dateien, schreibt Code, führt Befehle aus und nutzt den Browser.

Für den Vergleich kann der Agent ausgelesene Zeilen speichern, ein Berechnungsskript schreiben und es ausführen. Auf einer öffentlichen Lieferantenseite kann er eine Lieferbedingung prüfen. Fehlt in einer Zeile eine klare Einheit oder ein Liefertermin, kann er dies zur Prüfung markieren. Das Ergebnis ist eine Tabelle mit Quellenangaben, die der Kunde prüfen kann.

Von der Tool-Schleife zur Arbeit auf einem Computer

Die bekannte Tool-Schleife steuert weiter die Entscheidungen: Modell fragen, angeforderte Aktion ausführen, Ergebnis zurückgeben und erneut fragen. Beim PDF führt der Computer ein Extraktionsskript aus und liefert Exit-Code, Ausgabe und Fehler. Der Agent liest diese Ergebnisse vor der nächsten Entscheidung. Ein gescheiterter Parser, eine leere Tabelle und eine erfolgreiche Extraktion brauchen unterschiedliche nächste Schritte.

Bewahre Original-PDF, extracted.csv, Berechnungsskript und fertige Tabelle als separate Dateien auf. Stimmen die Zahlen nicht, kannst du sie durch diese Dateien zurückverfolgen. Lass den Agenten eine extrahierte Zeile mit der Originalseite vergleichen, bevor er die Berechnung ändert. So lässt sich der Schritt korrigieren, bei dem Informationen verloren gingen.

Ein Werkzeug kann einen Prozess starten, der länger als der Aufruf selbst läuft. Die Dokumentkonvertierung arbeitet möglicherweise noch, wenn die Anfrage ihr Zeitlimit erreicht. Die Ausführungsschicht muss den Prozess und seine Ausgabe prüfen können. Startet das Modell ihn einfach erneut, laufen vielleicht zwei Konvertierungen, ohne die Verzögerung zu beheben.

Gib getrennten Aufgaben getrennte Arbeitsumgebungen

Teilen zwei Vergleiche ein Verzeichnis, können sie extracted.csv überschreiben oder eine für den anderen unbrauchbare Paketversion installieren. Jede Beeuni-Session hat eine eigene Ausführungsumgebung, die lokale Dateien und Prozesse trennt. Bei Repository-Arbeit kannst du Änderungen im Session-Branch prüfen, bevor du sie in den Standardbranch übernimmst.

Gemeinsame Anwendungen verdienen gesonderte Aufmerksamkeit. Dürfen beide Sessions denselben Einkaufsdatensatz ändern, verhindern verschiedene Computer dort keine Konflikte. Lege fest, ob der Vergleich nur liest oder eine Aktualisierung eine Freigabe braucht.

Entscheide, was einen Stopp oder Ausfall überstehen muss

Die gespeicherte Session zeigt, was der Agent getan hat. Auf dem Datenträger liegen extrahierte Dateien und die Tabelle. Ein laufender Prozess hält möglicherweise noch nicht gespeicherte Arbeit. Das sind verschiedene Zustände. Wiederhergestellte Nachrichten bedeuten nicht, dass eine Konvertierung bei der zuvor ausgeführten Anweisung weiterläuft.

Ein normaler Stopp erhält den Datenträger. Ein gelöschter oder verlorener Computer braucht einen anderen Wiederherstellungsweg, soweit verfügbar mit gespeicherter Unterhaltung und Repository-Arbeit. Sichere wichtige Ausgaben im gewählten Speicher und pushe benötigte Codeänderungen. Der Session-Leitfaden erklärt, was jede Operation behält.

Vergib Rechte für die entscheidenden Aktionen

Der Agent darf vielleicht Lieferantendokumente lesen, während eine Bestellung die Entscheidung eines Menschen verlangt. Beeunis Connector-Regeln können eine Tool-Aktion erlauben, eine Freigabe verlangen oder sie blockieren. Konfiguriere die Aktion selbst, statt dich ganz auf einen Satz im Auftrag zu verlassen. Ein Computer trennt lokale Arbeit; verbundene Werkzeuge können trotzdem das echte Einkaufssystem verändern.

Dein Produkt prüft auch, welcher Kunde den Vergleich und seine Dateien öffnen darf. Ein API-Schlüssel auf dem Server authentifiziert deine Anwendung gegenüber Beeuni. Deine Zugriffskontrolle verbindet die Anfrage mit der Person, die das Ergebnis sehen darf.

Lass lange Aufgaben über eine Verbindung hinaus weiterlaufen

Ein Kunde kann die Seite während der Konvertierung schließen. Speichere die Beeuni-Session-ID beim Vergleich, damit die zurückkehrende Seite dieselbe Arbeit findet. Ereignisstreams zeigen Live-Fortschritt, gespeicherte Logs holen den Verlauf nach. Ein erreichbarer Computer kann beschäftigt sein, fertig sein oder auf Eingaben warten. Zeige deshalb Aufgabenstatus und Computerverfügbarkeit getrennt.

Prüfe vor dem Wiederholen einer unterbrochenen Anfrage, was passiert ist. Gerade bei externen Aktionen kann eine Bestellung bereits angelegt sein, obwohl die Bestätigung fehlt. Der Leitfaden zum Agenten-Backend erklärt die anwendungsseitigen Datensätze und das Wiederverbinden.

Mach Fehler nachvollziehbar

Angenommen, die Preisspalte der erzeugten Tabelle ist leer. Öffne die Session-Dateien und Befehlsausgaben. Hat der PDF-Parser keine Zeilen geliefert? Hat das Skript eine Spalte namens Price erwartet, obwohl das Angebot Unit cost verwendet? Verlangt die Lieferantenseite eine Anmeldung? Je nach Ursache ist eine andere Korrektur nötig.

Weil der Agent mit Dateien und Programmen arbeitet, kannst du ihn eine zwischenzeitlich erzeugte CSV prüfen, die Spaltenzuordnung korrigieren und die Berechnung wiederholen lassen. Das hilft oft mehr, als die endgültige Antwort ohne Kenntnis des Fehlers neu generieren zu lassen.

Prüfe den langsamen Schritt, bevor du ihn änderst

Bei dieser Funktion kosten die Computervorbereitung, Modellantworten, Dokumentextraktion und das Laden von Websites Zeit. Sieh dir einen echten Vergleich an, bevor du die Architektur änderst. Öffnet der Agent wiederholt dasselbe PDF, speichere den extrahierten Text und arbeite damit. Ist das Berechnungsskript langsam, prüfe das Skript. Lädt die Lieferantenwebsite langsam, macht ein anderes Modell die Seite nicht schneller.

Prüfe die Tabelle nach jeder Änderung. Eine schnellere Extraktion hilft nur, wenn Preise und Bedingungen weiterhin korrekt erfasst werden. Vergleiche dieselben Dokumente bei denselben Modelleinstellungen, um die Wirkung der Änderung zu erkennen.

Was die Architektur jetzt übernimmt

Das Modell wählt weiterhin Aktionen über eine Tool-Schleife. Der Dienst darum führt Programme aus, trennt Aufgaben, bewahrt nützliche Arbeit auf, setzt Berechtigungen um und zeigt Fortschritt. Das ist die Architekturänderung hinter einem Agentencomputer. Beeuni stellt Ausführungs- und Session-Schnittstellen bereit, damit deine Anwendung eine Aufgabe senden und die laufende Arbeit prüfen kann.

Dieselbe Aufteilung eignet sich für die Datensatzvorbereitung oder ein Browser-Testwerkzeug. Dateien, Befehle und erwartete Ausgaben ändern sich. Dein Produkt startet weiterhin eine Session, verfolgt die Arbeit und zeigt dem Kunden ein nutzbares Ergebnis.

Beginne mit Sessions aus Code und Authentifizierung. Die Produktidee erklärt Was ist ein KI-Computer?.