Anmerkung des Autors: Dieser Artikel richtet sich an Entwickler, die bereits mit Agents arbeiten. Er zeigt, welche Kontextinformationen, Referenzmaterialien und überprüfbaren Abnahmekriterien vor der Aufgabenübergabe vorbereitet werden sollten – und wo weiterhin menschliches Urteil gefragt ist.
Seit dem Einsatz von Agents entsteht zwar mehr, aber die Arbeit wird anstrengender. Am 3. November 2026 beschrieb ein Entwickler auf V2EX genau diese Situation: Der Mensch bleibt Teil der Schleife, muss Ergebnisse prüfen und jederzeit eingreifen, wenn eine Aufgabe vom Kurs abkommt oder Designprobleme auftauchen. Wirklich loslassen fällt da schwer. Im Beitrag wird eine bekannte Erfahrung angesprochen: Ausführlichere Kontextinformationen und Referenzmaterialien helfen Agents, Aufgaben besser zu verstehen und bessere Ergebnisse zu liefern. Was „ausführlicher“ konkret bedeutet, bleibt dort allerdings offen.
Das ist kein weiterer allgemeiner Ratgeber zum Schreiben guter Eingabeaufforderungen. Dieser Artikel konzentriert sich auf die Vorbereitung vor der Aufgabenübergabe: Vage Anforderungen werden in Ziele, Einschränkungen, Referenzmaterialien und überprüfbare Kriterien für die Fertigstellung zerlegt. So kann der Agent seine Arbeit selbst prüfen und Sie müssen nur an wenigen wichtigen Punkten eingreifen. Allerdings gibt es derzeit keine öffentlich verfügbaren Vergleichsdaten, mit denen sich die Wirkung verschiedener Vorbereitungsweisen beziffern lässt. Die Beispiele im Artikel fassen typische Situationen zusammen – prüfen Sie die Wirkung bei Ihren eigenen Aufgaben.
Das nehmen Sie mit: eine wiederverwendbare Struktur für Aufgabenbeschreibungen und eine Methode zum Formulieren von Abnahmekriterien. Ausserdem können Sie besser einschätzen, welche Schritte der Agent selbst prüfen kann und wo ein Mensch entscheiden muss.
Agent-Kontext und Abnahmekriterien: das Wichtigste
Bevor Sie eine Aufgabenbeschreibung schreiben, lohnt sich ein Blick auf das Gesamtbild: Wenn ein Agent vom Kurs abkommt, liegt das meist daran, dass er anders als Sie versteht, „was zu tun ist“, „wie weit er gehen soll“ oder „was er nicht anfassen darf“. Die folgende Tabelle zeigt die fünf Bestandteile einer guten Aufgabenbeschreibung.
| Bestandteil | Beschreibung | Welches Problem er löst |
|---|---|---|
| Ziel | In einem Satz erklären, was geliefert werden soll und für wen | Verhindert, dass der Agent die Anforderungen eigenmächtig erweitert oder in die falsche Richtung arbeitet |
| Hintergrundkontext | Aktueller Projektstand, relevante Module und bisherige Lösungsversuche | Verhindert doppelte Arbeit und schützt bestehende Designentscheidungen |
| Einschränkungen | Dateien, die nicht geändert werden dürfen, vorgeschriebener Technologie-Stack sowie Leistungs- oder Kompatibilitätsanforderungen | Verhindert Lösungen, die zwar laufen, aber nicht einsetzbar sind |
| Referenzmaterial | Vorhandene Codebeispiele, Schnittstellendokumentation und Stilvorlagen | Sorgt dafür, dass Stil und Struktur zum bestehenden Projekt passen |
| Abnahmekriterien | Einzeln prüfbare, möglichst automatisiert überprüfbare Bedingungen für den Abschluss | Ermöglicht dem Agenten eine Selbstprüfung und erspart Ihnen eine zeilenweise Prüfung |
Typische Anzeichen dafür, dass ein Agent vom Kurs abkommt
Der ursprüngliche Beitrag nennt keine konkreten Beispiele. Hier sind einige häufige Fälle bei Programmier- und Aufgaben-Agenten zusammengefasst. Sie sehen unterschiedlich aus, lassen sich aber oft darauf zurückführen, dass in der Aufgabenbeschreibung ein Bestandteil fehlt.
| Anzeichen | Häufige Ursache | Vorbeugende Massnahme |
|---|---|---|
| Ein Bug wird behoben und nebenbei das halbe Modul umgebaut | Die Grenzen des Ziels und der Umfang der Änderungen sind unklar | Unter den Einschränkungen festlegen, welche Dateien oder Funktionen geändert werden dürfen |
| Eine neue Abhängigkeit wird eingeführt, die im Projekt bisher nicht vorhanden ist | Der bestehende Technologie-Stack ist nicht bekannt | Im Kontext vorhandene Abhängigkeiten und Regeln gegen neue Abhängigkeiten aufführen |
| Der Codestil passt nicht zum Rest des Projekts | Referenzbeispiele fehlen | Ein oder zwei ähnliche Implementierungen als Referenzmaterial beifügen |
| Der Agent meldet „erledigt“, aber wichtige Szenarien sind nicht abgedeckt | Die Kriterien für den Abschluss sind unklar | Abnahmekriterien als ausführbare Prüfpunkte formulieren |
| Die Lösung ist technisch machbar, entspricht aber nicht der Produktabsicht | Designentscheidungen wurden nicht vorab erklärt | Menschen treffen zuerst die Designentscheidung und übergeben dann die Umsetzung an den Agenten |
Der letzte Fall verdient besondere Aufmerksamkeit. Er entsteht nicht durch „zu wenig“ Kontext, sondern dadurch, dass die Designabwägung selbst von Menschen getroffen werden muss. Darauf gehen wir später gesondert ein.
Eine Aufgabenbeschreibung für Agents erstellen: die Struktur in fünf Abschnitten
Aus den fünf genannten Elementen lässt sich ein Dokument erstellen, das ein Agent versteht und anhand dessen er seine Arbeit selbst prüfen kann. Am besten pflegen Sie es als Markdown-Datei im Projekt-Repository, zum Beispiel unter dem Namen TASK.md. Alternativ können Sie allgemeine Vorgaben in einer projektweiten Datei wie AGENTS.md und konkrete Ziele in einem Dokument für die jeweilige Aufgabe festhalten.
Erster Abschnitt: Das Aufgabenziel für den Agent formulieren
Das Ziel sollte in einem Satz klären, was geliefert werden soll, für wen es gedacht ist und in welchem Kontext es verwendet wird. Eine Beschreibung wie „das Login-Modul optimieren“ könnte der Agent als Leistungsoptimierung, Code-Refactoring oder Überarbeitung der Benutzeroberfläche verstehen. Besser wäre: „Der Login-Endpunkt soll bei einem falschen Passwort einen einheitlichen Fehlercode zurückgeben, anhand dessen das Frontend eine Meldung anzeigt. Der Ablauf bei erfolgreicher Anmeldung bleibt unverändert.“
Bei größeren Aufgaben empfiehlt es sich, unter dem Ziel auch festzuhalten, was diesmal nicht umgesetzt werden soll. Klare Ausschlüsse verhindern oft besser als eine positive Beschreibung, dass der Agent den Umfang der Aufgabe ausweitet.
Zweiter Abschnitt: Den Hintergrundkontext für den Agent bereitstellen
Beim Hintergrundkontext kommt es nicht auf die Menge an, sondern auf die Relevanz. Dem Agent einfach das gesamte Repository zu geben, reicht nicht aus: Er muss trotzdem wissen, welche Teile für die aktuelle Aufgabe wichtig sind. Eine sinnvolle Reihenfolge ist:
- Relevante Module: Dateien oder Verzeichnisse, die direkt mit der Aufgabe zu tun haben, etwa die Login-Logik unter
src/auth/und die zugehörigen Testdateien. - Bereits getroffene Entscheidungen: Warum etwas auf eine bestimmte Weise umgesetzt wurde, zum Beispiel: „Fehlercodes werden zentral im Modul
errorsdefiniert und nicht im Anwendungscode hart codiert.“ - Bereits getestete Ansätze: Falls ein Ansatz ausprobiert und verworfen wurde, erläutern Sie den Grund, damit der Agent ihn nicht erneut verfolgt.
- Begriffserklärungen: Projektinterne Fachbegriffe, die der Agent nicht zuverlässig aus dem Code ableiten kann.
Dritter Abschnitt: Checkliste der Vorgaben für den Agent
Vorgaben sind entscheidend, um Ergebnisse zu vermeiden, die zwar laufen, aber nicht brauchbar sind. Häufige Einschränkungen lassen sich als Checkliste festhalten, die der Agent vor und nach der Ausführung durchgeht:
- Der Bereich, in dem Änderungen erlaubt sind, und Dateien, die ausdrücklich nicht geändert werden dürfen, zum Beispiel Datenbankmigrationsskripte oder Definitionen öffentlicher Schnittstellen.
- Einschränkungen des Technologie-Stacks, etwa „keine neuen Drittanbieter-Abhängigkeiten hinzufügen“ oder „nur die bereits im Projekt verwendete Logging-Bibliothek nutzen“.
- Kompatibilitäts- und Leistungsanforderungen, zum Beispiel „bestehende Schnittstellensignaturen unverändert lassen“.
- Vorgehen bei Unklarheiten, etwa: „Falls eine Änderung an einer öffentlichen Schnittstelle nötig ist, anhalten und den Grund erläutern, statt sie eigenständig zu ändern.“
Der letzte Punkt ist besonders wichtig. Eine klare Bedingung, wann der Agent anhalten und nachfragen soll, spart deutlich mehr Aufwand, als erst nachträglich eigenmächtige Änderungen zu entdecken.
Vierter Abschnitt: Referenzmaterial für den Agent auswählen
Referenzmaterial hilft dem Agent, bestehende Vorgehensweisen zu übernehmen, statt bei null anzufangen. Besonders hilfreich sind meist ähnliche Implementierungen im selben Projekt, zum Beispiel: „Für den neuen Endpunkt an der Implementierung unter src/user/ orientieren, einschliesslich Parametervalidierung und Fehlerbehandlung.“ Bei externer Dokumentation sollten Sie nur die für die Aufgabe relevanten Abschnitte angeben und die Version nennen, damit der Agent keinen Code für eine veraltete Schnittstelle schreibt.
Wie formuliert man überprüfbare Akzeptanzkriterien für einen Agenten?
Akzeptanzkriterien sind der Teil einer Aufgabenbeschreibung, der am leichtesten vage bleibt – und in den sich Zeit besonders lohnt. Die Faustregel ist einfach: Wenn ein Agent nicht selbst prüfen kann, ob ein Akzeptanzkriterium erfüllt ist, dann ist es ein Wunsch und kein Kriterium.
| Vage Formulierung | Überprüfbare Formulierung | Überprüfung |
|---|---|---|
| Die Codequalität soll gut sein | Die vorhandenen Lint-Prüfungen des Projekts laufen ohne neue Warnungen durch | Der Agent führt den Prüfbefehl aus und berichtet das Ergebnis |
| Die Funktion soll korrekt arbeiten | Neue Unit-Tests decken die drei Fälle falsches Passwort, nicht vorhandenes Konto und erfolgreiche Anmeldung ab und bestehen alle | Tests ausführen und eine Zusammenfassung der Ergebnisse angeben |
| Andere Funktionen dürfen nicht beeinträchtigt werden | Die bestehende Testsuite besteht vollständig, und keine der durch die Vorgaben ausgeschlossenen Dateien wurde geändert | Gesamte Testsuite ausführen und die geänderten Dateien auflisten |
| Die Dokumentation soll vollständig sein | Die Schnittstellendokumentation enthält neue Beschreibungen der Fehlercodes im Format der bestehenden Einträge | Jeden Eintrag mit dem Referenzbeispiel vergleichen |
| Die Performance darf sich nicht verschlechtern | Im kritischen Pfad kommen keine Datenbankabfragen hinzu | In der Zusammenfassung erläutern, wie sich die Anzahl der Abfragen verändert hat |
Fordern Sie den Agenten am Ende der Aufgabenbeschreibung auf, den Abschluss anhand der Akzeptanzkriterien Punkt für Punkt zu dokumentieren: Für jedes Kriterium soll er angeben, ob es erfüllt ist, worauf diese Einschätzung beruht und warum es gegebenenfalls nicht erfüllt wurde. So müssen Sie bei der Prüfung nur diese Übersicht durchgehen, statt alle Änderungen von Anfang an zu lesen.
Agent-Kontext und Abnahmekriterien: ein schneller Einstieg
Die bisherigen Inhalte lassen sich zu einem direkt umsetzbaren Ablauf zusammenfassen. Dafür sind keine zusätzlichen Tools nötig – ein Markdown-Dokument reicht für den Anfang.
Eine Agent-Aufgabenbeschreibung in 5 Schritten vorbereiten
- Erst die Abnahmekriterien schreiben, dann das Ziel: Diese Reihenfolge zwingt dich, genau zu überlegen, woran du erkennst, dass die Aufgabe erledigt ist. So vermeidest du zu weit gefasste Ziele.
- Den Hintergrund ergänzen: Nenne nur relevante Module, bereits getroffene Entscheidungen und gescheiterte Versuche. Halte dich dabei kurz.
- Einschränkungen und Abbruchbedingungen festlegen: Beschreibe, was nicht verändert werden darf und in welchen Fällen der Agent anhalten und nachfragen muss.
- Ein bis zwei Referenzbeispiele auswählen: Bevorzuge vergleichbare Implementierungen im Projekt und verweise bei externer Dokumentation nur auf die relevanten Abschnitte.
- Einen strukturierten Bericht verlangen: Der Agent soll nach Abschluss jedes Abnahmekriterium einzeln behandeln und eine Liste der geänderten Dateien sowie offener Probleme beifügen.
Beispiel für eine Agent-Aufgabenbeschreibung: Fehlerhinweise bei der Anmeldung korrigieren
Die folgende Vorlage beschreibt ein hypothetisches Szenario. Du kannst die einzelnen Punkte direkt durch deine eigenen Angaben ersetzen:
- Ziel: Die Anmeldeschnittstelle gibt bei falschem Passwort und nicht vorhandenem Konto denselben Fehlercode zurück. Das Frontend zeigt daraufhin einen Hinweis an. Der Ablauf einer erfolgreichen Anmeldung und das Seitendesign bleiben unverändert.
- Hintergrund: Fehlercodes sind zentral im Modul
errorsdefiniert. Ein früherer Versuch, den Fehlertext im Frontend auszuwerten, wurde wegen der Mehrsprachigkeit verworfen. - Einschränkungen: Änderungen sind nur in
src/auth/und den zugehörigen Tests erlaubt. Keine neuen Abhängigkeiten hinzufügen. Falls eine öffentliche Schnittstellendefinition geändert werden muss, zuerst stoppen und dies erklären. - Referenz: Die Fehlerbehandlung der Registrierungsschnittstelle in
src/user/. - Abnahmekriterien: Für drei Szenarien werden neue Unit-Tests ergänzt und bestehen; alle bestehenden Tests bestehen; der Linter meldet keine neuen Warnungen; die Schnittstellendokumentation wird um zwei Fehlercodebeschreibungen ergänzt.
- Berichtsformat: Die Abnahmekriterien einzeln durchgehen, geänderte Dateien auflisten und offene Punkte erläutern.
🚀 Tipp für den Einstieg: Du kannst dieselbe Aufgabenbeschreibung von verschiedenen Modellen bearbeiten lassen und vergleichen, welches die Einschränkungen und Stoppbedingungen am besten einhält. Über eine Plattform wie APIYI apiyi.com kannst du mit derselben Schnittstelle und demselben API-Schlüssel zwischen Modellen verschiedener Anbieter wechseln. So sparst du dir die Registrierung und Einrichtung mehrerer Konten und kannst die Modelle leichter anhand deiner eigenen Aufgaben vergleichen.
Agent-Lösungen mit Modellen verschiedener Anbieter gegenprüfen
Der Autor des ursprünglichen Beitrags spricht noch eine Sorge an: Modelle desselben Anbieters könnten ähnliche blinde Flecken haben. Deshalb möchte er Agents verschiedener Anbieter gegenseitig prüfen lassen. Bisher lassen sich Informationen jedoch nur über Markdown-Dokumente oder per Kopieren und Einfügen austauschen – der Koordinationsaufwand ist hoch. Dieser Ansatz lässt sich mit der Methode aus diesem Artikel verbinden: Die Aufgabenbeschreibung und die Abnahmekriterien sind selbst die beste gemeinsame Grundlage für die Gegenprüfung. Die prüfende Instanz muss nicht alle Absichten hinter der Aufgabe verstehen. Es reicht, wenn sie das Ergebnis anhand derselben Kriterien Punkt für Punkt hinterfragt.
Ein vergleichsweise einfacher Ansatz ist, verschiedenen Modellen unterschiedliche Rollen zuzuweisen und allen dieselbe Aufgabenbeschreibung als Eingabe zu geben:
| Rolle | Eingabe | Aufgabe | Anbindung |
|---|---|---|---|
| Ausführender Agent | Aufgabenbeschreibung | Lösung umsetzen und anhand der Abnahmekriterien selbst prüfen | Ihr gewohnter Programmier-Agent |
| Prüfer A | Aufgabenbeschreibung + Zusammenfassung der Änderungen | Abnahmekriterien einzeln prüfen und nicht abgedeckte Szenarien aufzeigen | Modell eines anderen Anbieters, aufrufbar über die einheitliche Schnittstelle von APIYI |
| Prüfer B | Aufgabenbeschreibung + Zusammenfassung der Änderungen | Gezielt auf Verstösse gegen Einschränkungen und Abbruchbedingungen prüfen | Modell eines dritten Anbieters; an derselben Schnittstelle genügt ein Wechsel des Modellnamens |
| Mensch | Zusammenfassung der Prüfergebnisse | Nur Meinungsverschiedenheiten zwischen den Prüfern und Designfragen klären | Keine |
Mit einem kleinen Skript, das „Ausführungsergebnis → an die Prüfmodelle senden → Rückmeldungen zusammenfassen“ verbindet, lässt sich ein Grossteil des manuellen Kopierens und Einfügens ersetzen. APIYI bietet eine einheitliche Schnittstelle, die mit gängigen SDKs kompatibel ist. Im Skript genügt ein anderer Modellname, um das Modell eines anderen Anbieters aufzurufen. Das vereinfacht gerade den aufwendigsten Teil beim Einsatz von Agents verschiedener Anbieter: die Anbindung. Wichtig ist aber: Automatisiert wird die Informationsübertragung – die endgültige Entscheidung sollte beim Menschen bleiben.
Welche Probleme der Agent-Kontext lösen kann – und wo Menschen eingreifen müssen
Gut aufbereiteter Kontext erspart viele Korrekturen, macht menschliches Eingreifen aber nicht vollständig überflüssig. Im ursprünglichen Beitrag werden „vom Auftrag abweichen“ und „Designprobleme“ nebeneinander genannt. Tatsächlich unterscheiden sich die beiden: Im ersten Fall fehlen meist Informationen, im zweiten geht es oft um Entscheidungen zwischen verschiedenen Optionen.
| Problemtyp | Durch Kontext lösbar? | Grund | Rolle des Menschen |
|---|---|---|---|
| Änderungen überschreiten den vereinbarten Umfang | Grundsätzlich ja | Bei klaren Vorgaben kann sich der Agent selbst überprüfen | Änderungsliste stichprobenartig prüfen |
| Uneinheitlicher Stil oder uneinheitliche Formatierung | Grundsätzlich ja | Referenzbeispiele reichen als Vorlage aus | Gelegentlich prüfen |
| Unvollständige Testabdeckung | Größtenteils ja | Die Szenarien müssen nur in den Akzeptanzkriterien stehen | Szenarioliste auf Vollständigkeit prüfen |
| Abwägungen zu Architektur und Design | Kaum | Es braucht eine Wertentscheidung zwischen mehreren sinnvollen Lösungen | Vorab entscheiden und in der Aufgabenbeschreibung festhalten |
| Produktabsicht und Nutzererfahrung | Kaum | Hängen von Geschäftszielen und dem Verständnis der Nutzer ab | Vorab definieren und anschließend abnehmen |
| Korrektheit der Akzeptanzkriterien selbst | Nein | Der Agent kann nur anhand der Kriterien prüfen, nicht deren Voraussetzungen hinterfragen | Muss vom Menschen verantwortet werden |
Designfragen lassen sich nur schwer vollständig an einen Agent delegieren, weil es meist keine einzige richtige Antwort gibt. Ein Beispiel: „Gehören Fehlercodes in ein gemeinsames Modul oder in ein Fachmodul?“ Beide Varianten funktionieren. Die Wahl hängt davon ab, wie sich das Team künftig weiterentwickeln will und wie es die Wartung handhabt. Dieses Wissen steckt oft in den Einschätzungen der Beteiligten und lässt sich nur schwer vollständig verschriftlichen.
Eine pragmatischere Strategie lautet deshalb: Menschen früher einbinden. Werden Designentscheidungen vor Beginn der Aufgabe getroffen und als Vorgaben festgehalten, muss während der Ausführung niemand ständig den Agent überwachen. Nach Abschluss genügt es, die Übersicht der Akzeptanzkriterien und die Meinungsverschiedenheiten zwischen den Prüfenden zu kontrollieren. So verändert sich die Rolle des Menschen im gesamten Ablauf: Statt „durchgehend zu begleiten“ gibt er „am Anfang die Richtung vor und nimmt am Ende das Ergebnis ab“.
Häufige Fragen (FAQ)
Q1: Was sind Akzeptanzkriterien für einen Agenten?
Akzeptanzkriterien sind einzeln überprüfbare Bedingungen, die bei Abschluss einer Aufgabe erfüllt sein müssen, zum Beispiel „Alle angegebenen Tests bestehen“ oder „Keine Änderungen an gesperrten Dateien“. Sie helfen dem Agenten bei der Selbstkontrolle und Menschen dabei, das Ergebnis schnell zu beurteilen, ohne die gesamte Ausgabe Zeile für Zeile lesen zu müssen.
Q2: Ist mehr Kontext immer besser?
Nein. Irrelevante Informationen lenken vom Wesentlichen ab und können sogar dazu führen, dass der Agent Teile verändert, die er nicht anfassen sollte. Wählen Sie den Kontext passend zur Aufgabe aus: relevante Module, bereits getroffene Entscheidungen, fehlgeschlagene Versuche und notwendige Fachbegriffe. Wenn Sie unsicher sind, ob bestimmte Informationen hilfreich sind, können Sie über APIYI apiyi.com verschiedene Modelle aufrufen und jeweils eine kurze und eine vollständige Aufgabenbeschreibung testen. So sehen Sie, welche Variante seltener vom Ziel abweicht.
Q3: Braucht jede kleine Aufgabe eine so ausführliche Beschreibung?
Nein. Allgemeine Vorgaben und Projekthintergrund können Sie in einer projektweiten Anweisungsdatei festhalten und dauerhaft wiederverwenden. Für einzelne Aufgaben ergänzen Sie dann nur noch Ziel, Referenzmaterial und Akzeptanzkriterien. Bei kleinen Änderungen, die in wenigen Minuten erledigt sind, reichen meist ein Satz zum Ziel und zwei bis drei Akzeptanzkriterien.
Q4: Für welche Agenten und Aufgabentypen eignet sich diese Methode?
Sie eignet sich vor allem für Programmieragenten und aufgabenorientierte Agenten mit klar definierten Ergebnissen, etwa zum Beheben von Fehlern, Implementieren von Schnittstellen, Erstellen von Dokumentation oder Aufbereiten von Daten. Bei stark explorativen Aufgaben, deren Ziel noch nicht feststeht, lassen sich Akzeptanzkriterien nur schwer im Voraus formulieren. Hier ist es sinnvoller, wenn Mensch und Agent zunächst gemeinsam eine Richtung festlegen und erst dann mit der Umsetzung beginnen.
Q5: Wie kann ich Modelle verschiedener Anbieter zur gegenseitigen Überprüfung einsetzen, ohne ständig Inhalte zu kopieren und einzufügen?
Sie können ein kleines Skript schreiben, das das Ergebnis zusammen mit der Aufgabenbeschreibung an ein Prüfmodell sendet und anschließend die Rückmeldungen zusammenfasst. Über die einheitliche Schnittstelle von APIYI apiyi.com genügt es, im Skript den Modellnamen zu ändern, um Modelle verschiedener Anbieter aufzurufen. Sie müssen nicht für jeden Anbieter ein separates SDK und Konto anbinden. So lässt sich schnell ein Prototyp für einen Ablauf aus „Ausführung + Prüfung durch mehrere Modelle“ erstellen.
Q6: Welche Grenzen hat diese Methode?
Erstens ersetzt sie keine Designentscheidungen: Architekturabwägungen und Produktabsichten müssen weiterhin Menschen festlegen. Zweitens erfüllt der Agent auch falsch formulierte Akzeptanzkriterien zuverlässig. Außerdem fehlen derzeit öffentliche Daten, die die Auswirkungen verschiedener Vorbereitungsweisen quantifizieren. Vergleichen Sie die Ansätze daher am besten zunächst bei einigen eigenen Aufgaben und halten Sie fest, wie oft Sie korrigierend eingreifen mussten.
Agent-Kontext und Abnahmekriterien: Das Wichtigste auf einen Blick
- Abweichungen entstehen oft durch fehlende Informationen: Fehlen Ziel, Einschränkungen oder Referenzmaterialien, kann das zu Nacharbeit führen.
- Fünf Bausteine einer Aufgabenbeschreibung: Ziel, Hintergrundkontext, Einschränkungen, Referenzmaterialien und Abnahmekriterien gehören alle dazu.
- Abnahmekriterien müssen überprüfbar sein: Was der Agent nicht selbst überprüfen kann, bleibt lediglich ein Wunsch.
- Stoppbedingungen festlegen: Halten Sie fest, wann der Agent anhalten und nachfragen muss. Das spart Aufwand gegenüber nachträglichen Korrekturen.
- Designentscheidungen früh treffen: Architektur- und Produktentscheidungen trifft zuerst der Mensch und hält sie dann als Einschränkungen fest.
- Für Gegenprüfungen dieselben Kriterien verwenden: Über die einheitliche Schnittstelle von APIYI lassen sich Modelle verschiedener Anbieter für eine vergleichende Prüfung aufrufen.
Zusammenfassung
Dass die Arbeit mit Agents im geschlossenen Regelkreis für Menschen oft so anstrengend ist, liegt vor allem an unvollständigen Aufgabenbeschreibungen. Dadurch müssen Sie den Agent ständig beobachten und bei Bedarf korrigieren. Eine gute Vorbereitung konzentriert sich auf drei Punkte:
- Aufgabenbeschreibungen in fünf Abschnitte gliedern: Ziel, Hintergrund, Einschränkungen, Referenzmaterialien und Abnahmekriterien zeigen dem Agent, was er tun soll, welches Ergebnis erwartet wird und was tabu ist.
- Abnahmekriterien als überprüfbare Punkte formulieren: Lassen Sie den Agent zu jedem Punkt berichten. Sie selbst prüfen dann nur noch die Übersicht und die offenen Fragen.
- Zwischen Kontext und menschlicher Verantwortung unterscheiden: Designentscheidungen werden vorab getroffen; für die Abnahmekriterien selbst bleibt der Mensch verantwortlich.
Beginnen Sie am besten bei Ihrer nächsten konkreten Aufgabe: Formulieren Sie zuerst die Abnahmekriterien und ergänzen Sie dann die übrigen Abschnitte. Halten Sie ausserdem fest, wie oft Sie zwischendurch eingreifen mussten. Das gibt Ihnen eine Grundlage für Verbesserungen. Wenn Sie auch mit Gegenprüfungen durch Modelle verschiedener Anbieter experimentieren, können Sie über APIYI auf apiyi.com unterschiedliche Modelle über eine einheitliche Schnittstelle anbinden und an realen Aufgaben prüfen, welche Kombination Ihre Eingriffe am stärksten reduziert.
📚 Quellen
- V2EX-Diskussion – Wie sich menschliche Eingriffe reduzieren lassen, damit Agenten eigenständig arbeiten und bessere Ergebnisse liefern: Ausgangspunkt für diesen Artikel
- Link:
v2ex.com/t/1254207 - Inhalt: Beschreibt die Ermüdung bei menschlicher Beteiligung am Agenten-Regelkreis, die Rolle des Kontexts und die Idee, Agenten verschiedener Anbieter ihre Ergebnisse gegenseitig prüfen zu lassen
Autor: APIYI-Technikteam
Technischer Austausch: Kontaktieren Sie uns über die APIYI-Startseite apiyi.com, um Erfahrungen mit Aufgabenbeschreibungen für Agenten und der Zusammenarbeit mehrerer Modelle auszutauschen.
