Bevor ich einen Agenten entwerfe, schreibe ich die Entscheidungen auf, die das System treffen soll. „Eingehende Anfragen bearbeiten“ ist ein Ziel, aber es sagt mir nicht, ob der nächste Schritt vorhersehbar ist, ob fehlende Informationen wiederhergestellt werden können oder welche Befugnis das System benötigt.
Diese Details bestimmen die Architektur. Ein fester Workflow folgt einer expliziten Sequenz oder einer Reihe von Verzweigungen. Ein Agent kann seine nächste Aktion aus Beobachtungen wählen. Beide können ein Sprachmodell verwenden; die nützliche Unterscheidung ist, wer den Weg durch die Arbeit kontrolliert.
Trennen Sie Unsicherheit von gewöhnlichen Geschäftsregeln
Betrachten Sie eine Anfrage zur Aktualisierung einer Lieferadresse. Das Lesen einer locker formulierten Nachricht kann ein Verständnis der Sprache erfordern. Zu überprüfen, ob die Bestellung dem Kunden gehört, ist eine gewöhnliche Zugriffsentscheidung. Festzustellen, ob der Versand bereits begonnen hat, ist eine Abfrage des aktuellen Zustands. Die Änderung anzuwenden, ist eine Geschäftsoperation.
Es hat wenig Wert, ein Modell zu bitten, alle vier Schritte zu improvisieren. Ich würde es dazu bringen, die Anfrage zu identifizieren und eine vorgeschlagene Adresse zu extrahieren, und dann explizite Regeln für Eigentum, Berechtigung und das eigentliche Update verwenden. Wenn die Adresse unvollständig ist, kann der Workflow eine gezielte Klarstellungsfrage stellen.
Eine andere Aufgabe, wie das Untersuchen widersprüchlicher Beschreibungen aus mehreren Quellen, könnte eine weniger vorhersehbare Reihenfolge erfordern. Ein Agent könnte entscheiden, welche Quelle als Nächstes untersucht werden soll, vorausgesetzt, sein Forschungsbereich und die Abschlusskriterien sind klar.
Zeichnen Sie die Entscheidungsgrenze vor der Werkzeugliste
Ich beginne mit drei Fragen: Was kann das System beobachten, was kann es entscheiden und was kann es ändern? Diese Fragen zeigen nützlichere Grenzen auf als eine lange Liste verfügbarer Integrationen. Ein System, das jeden Kontopost lesen kann, hat möglicherweise dennoch nur die Berechtigung, ein einziges Feld auf einem verifizierten Konto zu ändern.
Für jeden vorgeschlagenen autonomen Schritt frage ich, welche neuen Informationen die nächste Aktion ändern könnten. Wenn die Antwort immer gleich ist, ist ein fester Schritt in der Regel einfacher zu überprüfen. Wenn die Antwort von Beweisen abhängt, die im Voraus nicht vorhergesagt werden können, kann eine eingeschränkte Agentenauswahl nützlich sein.
Die Ingenieurarbeit, die ich durch Wizutech leiste, gibt mir einen praktischen Grund, diese Unterscheidung zu treffen: Betriebsoftware muss mehrdeutige menschliche Anfragen mit präzisem Systemverhalten verbinden. Die Architektur sollte diesen Übergang verständlich machen.
Geben Sie dem flexiblen Abschnitt eine kleine Schnittstelle
Ein nützliches hybrides Design hat eine explizite Eingangsbedingung, eine begrenzte Agentenaufgabe und ein überprüftes Ergebnis. Für eine Forschungsaufgabe könnte das Ergebnis Kandidatenaufzeichnungen, unterstützende Quellen und ungelöste Fragen enthalten. Es sollte kein unbegrenzter Absatz sein, den der nächste Schritt neu interpretieren muss.
Diese Grenze erleichtert auch den Austausch. Ein Modell kann sich ändern, während die umgebende Anwendung weiterhin die gleiche Ergebnisstruktur erwartet. Der wichtige Vertrag ist die Bedeutung der Ausgabe, einschließlich wie ein unvollständiges Ergebnis aussieht.
Meine Begleitnotiz zu Werkzeugverträgen für mehrdeutige Anfragen entwickelt diese Schnittstelle näher. Ein kleinerer Entscheidungsspielraum ist nur dann nützlich, wenn die Werkzeuge darin klare Semantiken haben.
Vergleiche die vollständige Aufgabe
Ich würde einen Workflow und einen Agenten anhand repräsentativer Anfragen vergleichen, einschließlich der Fälle, die eine Klärung erfordern oder nicht abgeschlossen werden können. Die nützlichen Maßnahmen umfassen akzeptierte Ergebnisse, falsche Aktionen, den Aufwand des Betreibers und die Gesamtausführungskosten. Allein die Zählung der Modellaufrufe sagt wenig darüber aus, ob das System das Problem gelöst hat.
Fehler sollten nach ihrer Ursache gruppiert werden. Eine fehlende Geschäftsregel benötigt eine Regel. Eine unklare Anfrage benötigt Klarstellung. Eine wirklich offene Untersuchung kann von adaptiver Planung profitieren. Die Erweiterung der Autonomie ist ein schlechter Ersatz dafür, zu identifizieren, welches Problem aufgetreten ist.
Bevor ich das Design erweitere, überprüfe ich, ob die Delegierung an mehrere Agenten unabhängige Ergebnisse liefern würde. Ein begrenzter Agent innerhalb eines vorhersehbaren Workflows kann ein starker Ausgangspunkt sein: genügend Flexibilität, um Unsicherheiten zu untersuchen, während die umgebende Anwendung weiterhin für die Grenzen und das Ergebnis der Aufgabe verantwortlich ist.
Aktualisiert am 30. September 2026.