Keine Tabellendaten
Eine Aufgabe aus der Praxis umfasst ein überprüfbares Ziel, Einschränkungen, die definieren, was als akzeptabel gilt, sowie einen externen Zustand, der sich während der Systemlaufzeit ändern kann. Ein Ziel ohne Überprüfungsmöglichkeit führt zu einem endlosen Dialog, da das System nicht feststellen kann, wann die Aufgabe erledigt ist.
Der Fokus liegt auf der kleinsten Schleife, die in der Lage ist, zu handeln, zu verifizieren und zu stoppen.
Ein Ziel wird erst dann operativ nutzbar, wenn ein Abschluss-Signal vorliegt, das von einem Programm ausgewertet werden kann – etwa eine geschriebene Datei, ein aktualisierter Status oder ausgefüllte Datenfelder. Einschränkungen grenzen den Bereich zulässiger Ergebnisse ein; dazu gehören beispielsweise Fristen, Budgets für API-Aufrufe, vorgeschriebene Formate oder Richtlinien, die bestimmte Aktionen unterbinden.
Als externer Zustand gilt jede Abhängigkeit außerhalb des Modellaufrufs, wie etwa ein Datenbankeintrag, eine Ticket-Warteschlange, eine Webseite oder ein Kalenderereignis. Ändert sich der externe Zustand, kann ein zuvor korrekter Plan ungültig werden, ohne dass ein Programmfehler auftritt.
Regel Wenn sich der Abschluss einer Aufgabe nicht deterministisch überprüfen lässt, sollte sie als offen betrachtet werden; ergänzen Sie in diesem Fall ein Abbruch-Limit sowie einen Schritt zur menschlichen Überprüfung.
Die minimale Architektur besteht aus einer Schleife, die Daten durch festgelegte Phasen leitet und die jeweiligen Änderungen protokolliert. Die Schleife beginnt mit einer Eingabe, liest den Zustand aus und aktualisiert ihn, ruft ein Modell zur Vorschlagserstellung für die nächste Aktion auf, führt Werkzeugaufrufe (Tools) aus, die den externen Zustand beeinflussen, und prüft schließlich eine Abbruchbedingung, bevor der Vorgang wiederholt wird.
Interagieren Sie mit dem Pipeline-Diagramm und verfolgen Sie, welche Daten in die einzelnen Schritte einfließen und welche Ergebnisse diese liefern.
Sobald die Schleife etabliert ist, lässt sich jeder Fehler lokalisieren. Ein fehlgeschlagener Abruf (Retrieval-Fehler) äußert sich in fehlenden Eingaben für den Modellaufruf, ein Tool-Fehler zeigt sich als Exception oder HTTP-Antwort ungleich 200, und ein Fehler in der Abbruchbedingung führt zu wiederholten Iterationen ohne Fortschritt im Systemzustand.
Eine Aufgabe zur Erstellung von Forschungsberichten endet üblicherweise, wenn ein Dokument Format- und Zitiervorgaben erfüllt sowie eine Verifizierungsprüfung besteht – etwa indem jede Behauptung in der Notizdatei mit einer Quellen-URL belegt ist. Zu den eingesetzten Werkzeugen gehören oft Suchfunktionen, Dokumenten-Parsing und Dateischreibvorgänge; die Kostenkontrolle konzentriert sich typischerweise darauf, Web-Recherchen und das Anwachsen des Kontextumfangs zu begrenzen.
Eine Aufgabe zur Ticket-Triage endet, sobald jedes Ticket kategorisiert, zugewiesen und mit einer kurzen Begründung versehen wurde und das Ticketsystem die Aktualisierung bestätigt hat. Hier kommen häufig eine Ticket-API, eine Richtlinienprüfung und bisweilen eine Abfrage der internen Wissensdatenbank zum Einsatz; der Fokus der Zuverlässigkeit liegt auf der Vermeidung fehlerhafter Aktualisierungen.
Vergleichen Sie die beiden Aufgaben, indem Sie Einschränkungen, Werkzeuge und Abschlusskriterien auswählen, und beobachten Sie, wie sich die Abbruchbedingung verändert.