Google hat vor kurzem einen kostenlosen Agent-Kurs eingeführt.
Die Kurse reichen von Prompt, Agent Loop bis hin zu Graph Workflow, Multi-Agent und selbstentwickelten Systemen. Auf den ersten Blick ist es wie eine neue Methode zur Agententwicklung.
Aber wenn ich die offiziellen Daten von Google ADK 2.0, die Google Cloud-Architekturrichtlinien und einige kürzlich durchgeführte Agent-Reviews zusammen betrachte, finde ich, dass es sich nicht um eine bestimmte API handelt, sondern um eine größere Veränderung:
Die Agententwicklung geht vom „Modell-Tuning" in die Phase des „Design-Systems" ein.
In der Vergangenheit waren die meisten AI-Anwendungen so:
Eingabe → Prompt → Modell → Export.
Übersetzungen, Zusammenfassungen, Klassifizierungen, Informationsgewinnung, Inhaltsumarbeitung - diese Aufgaben können in der Regel mit einem einzigen Aufruf erledigt werden.
Die Entwicklung ist schnell, die Kosten sind einfach zu schätzen, und wenn es einen Fehler gibt, kann man ihn einmal wieder aufrufen.
Nachdem jedoch der Tool-Aufruf erschienen ist, beginnt der Agent wirklich in den Geschäftsprozess einzutauchen.
Es kann Daten durchsuchen, APIs aufrufen, Code ausführen, Datenbanken abfragen und dann den nächsten Schritt basierend auf den Ergebnissen des Tools entscheiden.
Das Modell ist nicht mehr nur "Fragen beantworten".
Er begann „Sachen zu tun".
Sobald das Modell an der Umsetzung beteiligt ist, ist das Problem völlig anders.
Der Kontext wächst ständig, die Ergebnisse des Tools werden ständig in die Vergangenheit eingetragen, Agenten können das Tool wiederholt aufrufen oder auf halbem Weg vom Ziel abweichen oder sogar vorzeitig beenden, bevor die Aufgabe abgeschlossen ist.
Unternehmensprozesse erhöhen außerdem die Anforderungen an Berechtigungen, Genehmigungen, Status, Wiederversuche, Wiederherstellung und Auditing.
Kundenservice Rückerstattung, Rechnungsüberprüfung, Mitarbeiterinführung, Bestellverarbeitung, diese Dinge sind nicht einfach eine Frage und Antwort.
Die wirklichen Schwierigkeiten des Agenten sind also schon von:
Wie kann man das Modell mehrfach richtig beantworten?
wurde:
„Wie lässt sich ein Geschäftsprozess, an dem das Modell beteiligt ist, stabil ablaufen?"
Das ist auch der Punkt, an dem ich denke, dass Google ADK 2.0 einen Blick verdient.
Prompt, Agent Loop, Graph - was ist der Unterschied?
Viele Leute sprechen heute von Agenten, und es ist leicht, Prompt, Agent Loop und Workflow zu verwechseln.
Sie lösen Probleme auf drei verschiedenen Ebenen.
prompt lösen „verstanden"
prompt sagt dem model:
Was Sie tun, was Sie tun sollten, welches Format exportieren, welche Einschränkungen es gibt.
Wenn die Aufgabe selbst relativ einfach ist, wie Übersetzen, Zusammenfassungen, Klassifizierung, Umschreiben, dann ist prompt oft ausreichend.
Agent Loop löst „Aktion"
Sobald das Modell über die Werkzeuge verfügt, kann es:
Verstehen Sie das Ziel → machen Sie den nächsten Schritt → Aufrufen von Werkzeugen → Lesen Sie die Ergebnisse → entscheiden Sie dann für den nächsten Schritt.
Das ist ein typischer Agent Loop.
Sie eignet sich besonders für offene Aufgaben.
Zum Beispiel Datensuche, Code-Reparaturen und komplexe Datenanalyse.
Da es schwierig ist, jeden Schritt im Voraus zu schreiben, müssen Modelle den Plan dynamisch anhand der Ergebnisse vor Ort anpassen.
Graph Workflow löst „Ausführung"
Der Workflow beschäftigt sich mit:
Wie sollte der gesamte Prozess laufen?
Welche Schritte müssen durchgeführt werden?
Welche Aufgaben können parallel ausgeführt werden?
Unter welchen Umständen kann ich die Branche betreten?
Wann muss man die Genehmigung manuell erledigen?
Wo soll man es nach dem Scheitern noch einmal versuchen?
Welche Zustände müssen aufbewahrt werden?
Diese Fragen können nicht ganz dem Modell überlassen werden.
Sie sind besser geeignet, in das Verfahren zu schreiben.
Man kann die drei einfach verstehen:
Prompt ist für das Verständnis verantwortlich, Agent Loop für die Aktion und Workflow für die Einschränkung der Ausführung.
Die drei können sich nicht gegenseitig ersetzen, sondern überlaufen.
Problemen, die mit einem Modellaufruf gelöst werden können, müssen nicht erzwungen werden, einen Workflow zu erstellen.
Ein einzelner Agent ist bereits in der Lage, die Aufgaben stabil zu erledigen, und es ist nicht notwendig, mehrere Agenten für „Agentic" aufzuteilen.
Wann beginnt die Prompt-Funktion?
Das größte Problem von Prompt ist nicht, dass es nicht stark genug ist.
Wenn sich die Geschäftsprozesse zunehmend komplizieren,Der Prozess selbst beginnt sich in der Prompt zu verstecken.
Zum Beispiel bei einem Rückerstattungsprozess:
Der Benutzer stellt eine Rückerstattung vor → Abfrage nach Bestellungen → Beurteilung von Richtlinien → Entscheiden, ob eine Rückerstattung stattfindet → Ausführung einer Rückerstattung → Senden einer Bestätigungs-E - Mail → Aktualisieren der Arbeitskarte.
Wenn Sie all das einem Agenten überlassen und das Modell selbst entscheiden lassen, ist es sehr flexibel.
Das Produktionsumfeld wird jedoch bald auftreten.
Für Entwickler ist es schwierig, sich zu entscheiden:
Wird dieser Schritt jedes Mal ausgeführt?
Haben Sie vor der Rückerstattung eine Überprüfung abgeschlossen?
Wird die Rückerstattung nach dem Ausfall des Tools wiederholt?
Wohin sollte ich nach einem fehlgeschlagenen Versand fortfahren?
Wenn die Datenbank-Aktualisierung fehlschlägt, muss der vorherige Vorgang nicht rückgängig gemacht werden?
Das sind keine Probleme mehr.
Es geht um Software Engineering.
Wirklich zuverlässige Systeme haben also in der Regel eine realistische Arbeitsteilung:
Das Modell ist für die Unsicherheit verantwortlich, der Code für die Gewissheit.
Zum Beispiel,
Das Verständnis und die Analyse des Beschwerdeninhalts kann an das Modell übergeben werden.
Bestelluntersuchungen, Rückerstattungsausführung und Datenbankaktualisierungen sollten vom Programm gesteuert werden.
3. Agent Loop ist flexibel, aber die Produktionsumgebung muss „die Zügel" tragen
Der Charme von Agent Loop liegt darin, dass es nicht erforderlich ist, alle Pfad im Voraus zu kennen.
Das Modell kann den Plan ständig anhand der Ergebnisse des Werkzeugs anpassen.
Zum Beispiel:
„Helfen Sie mir, die jüngsten Finanzierungen dieses Unternehmens zu untersuchen."
Der Agent kann die Webseite durchsuchen, Datenbanken abfragen, Daten organisieren und die Suche fortführen, wenn es zu wenig Informationen gibt.
Wenn diese Aufgabe vollständig abgeschrieben wird, wäre sie sehr schwer.
Aber Loop hat auch ein natürliches Risiko:
Er weiß nicht, wann er aufhören sollte.
Daher müssen Agent Loops in einer Produktionsumgebung in der Regel explizit konfiguriert werden:
- Maximale Ausführungsschritte
- Gesamtzeitüberschreiten
- Token / API-Budget
- Erfolgsbedingung
- Bedingungen des Scheiters
- Künstlicher Upgrade-Pfad
Ansonsten kann ein Fehler zu einem Urteil führen:
Aufrufen des Tools → Erhalten eines falschen Ergebnisses → erneut aufrufen → erneut fehlschlagen → Versuch fortführen.
Das Endergebnis ist:
Die Kosten steigen, die Verzögerungen steigen und die Aufgaben werden nicht abgeschlossen.
Also:
Wenn der Weg unsicher ist, lassen Sie das Modell entscheiden.
Wenn der Weg festgelegt ist, lassen Sie das Modell nicht raten.
Dies ist ein sehr wichtiges Prinzip im Agent-Projekt.
4. Was löst Graph Workflow wirklich?
Graph Workflow ist sehr einfach:
Die Prozesse, die ursprünglich in der Entscheidungsfindung des Modells verborgen waren, werden in Software-Architekturen verwandelt, die Entwickler sehen, testen und ändern können.
Ein Rückerstattungsprozess kann beispielsweise so gestaltet werden:
Befragung der Bestellung
↓
Analyse von Benutzerbeschwerden
↓
Beurteilung der Rückerstattungsbedingungen
↓
Erfüllung der Voraussetzungen Rückerstattung
│
Unzufriedenheit - Schließung der Arbeit
↓
Bestätigungs-E - Mail erstellen
↓
Aktualisieren des Arbeitsstatus
So wird jeder Punkt klar.
Welche Schritte müssen durchgeführt werden?
Welche Schritte können parallel durchgeführt werden?
Wo braucht man eine manuelle Bestätigung?
Woher kommt man nach dem Scheitern?
Welche Ergebnisse müssen dauerhaft bleiben?
Alles kann eindeutig ausgedrückt werden.
Das ist auch der größte Wert von Workflow:
Es macht den Agent nicht intelligenter, sondern den Agent kontrollierbarer.
Warum ist Google ADK 2.0 interessant?
Eine wichtige Änderung in Google ADK 2.0 ist, dass die Workflow-Laufzeitzeit offiziell in den Mittelpunkt der Agententwicklung gestellt wird.
Python 2.0 wird am 19. Mai 2026 GA und Go 2.0 am 30. Juni in die GA gehen.
Offiziell können Agenten, Tools und Funktionen als Knoten in einem Workflow dienen, der den gesamten Prozess über eine ausführende Beziehung steuert.
Sequenzielle Ausführung, bedingtes Routing, parallele Aufgaben, Schleifen, dynamische Workflows, verschachtelte Prozesse und menschliches Eingreifen können alle in ein einheitliches Betriebsmodell integriert werden.
Noch wichtiger ist, dass es beginnt, den Status und die Wiederherstellung von langen Aufgaben zu konzentrieren.
Denn eine echte Unternehmensaufgabe kann nicht in Sekunden erledigt werden.
Es kann mehrere Minuten oder sogar länger laufen.
Auf halbem Weg kann ausgesetzt werden.
Möglicherweise wartet man auf eine manuelle Genehmigung.
Ein externes System ist möglicherweise vorübergehend nicht verfügbar.
Das System muss wissen, dass:
Wo wurde sie vorher umgesetzt?
Ohne Checkpoint und Zustandwiederherstellung kann der Agent nach Unterbrechung nur neu starten.
Aus diesem Grund werden Unternehmensagenten letztendlich zunehmend wie herkömmliche Softwaresysteme werden.
Sie braucht:
Zustand.
Ereignisse.
Kontrollpunkte.
Versuchen Sie erneut.
Kompetenz.
Tagebuch.
Audit.
Wiederherstellung.
6. Lange Kontext ist nicht gleichbedeutend mit zuverlässigen Erinnerungen
Hier gibt es noch eine Frage, die leicht übersehen werden kann:
Kontext rot.
Viele Leute glauben, dass der Agent sich „alles erinnert", sobald er die gesamte Geschichte in den Kontext steckt.
Tatsächlich ist die Sache nicht so einfach.
Wenn die Eingabe länger wird, kann die Fähigkeit des Modells, wirklich wichtige Informationen aus dem Kontext genau zu finden, sinken.
Das Problem ist leichter für den Agent als für einen normalen Chat.
Jeder Aufruf des Tools kann neue Daten mit sich bringen.
搜索结果、网页内容、数据库记录、API 返回值、中间推理……
Wenn alles ständig in den Kontext hinzugefügt wird, entsteht letztendlich eine riesige Informationsmülldecke.
Je länger der Kontext ist, desto schlauer ist er nicht unbedingt.
Manchmal ist es leichter zu irren.
Der Workflow lässt sich in drei Richtungen erleichtern:
Zunächst ist die Isolierung des Kontextes.
Jeder Knoten liest nur die Informationen, die er wirklich braucht.
Zweitens, die Verwendung von Strukturen.
Schicken Sie nicht jedes Mal den vollständigen Chat-Datalog an das Modell.
Drittens: Einrichtung von Kontrollpunkten.
Ein Knoten speichert das Ergebnis der Bestätigung, nachdem er fertig ist, und der nächste Knoten setzt vom bereits bestätigten Zustand fort.
Aber hier gibt es noch einen wichtigen Unterschied:
Das speichern von chat-aufzeichnungen ist nicht gleichbedeutend mit erholungsfähigkeit.
Eine echte Wiederherstellung muss auch berücksichtigt werden:
Checkpoints, Ereignisprotokolle, idempotente Operationen und Wiedergabe-Richtlinien für externe Systeme.
7. Je mehr Agenten sind, desto weiter.
Es gibt einen Trend, der leicht missverstanden wird:
Je mehr Agenten es gibt, desto fortschrittlicher wird das System.
Tatsächlich ist das überhaupt nicht so.
Mehr Agent ist wirklich wertvoller Ort, ja.Verantwortlichkeitsteilung klar。
Zum Beispiel,
Ein Agent ist für die Suche verantwortlich.
Ein Agent ist für die Analyse zuständig.
Ein Agent ist für die Umsetzung zuständig.
Auf diese Weise kann jeder Agent unterschiedliche Tools, Berechtigungen und Kontext haben.
Das Problem kommt auch darauf an:
mehr gerufen.
mehr Kommunikation.
Die Synchronisierung ist komplizierter.
Fehler zu identifizieren ist schwieriger.
Gleichzeitig entstehen auch Strombegrenzungen, Ressourcenkonkurrenz und Konsistenzprobleme.
Die MAST-Studie von NeurIPS 2025 analysierte mehr als 1.600 Multi-Agent - Ausführungsbahnen und ergab 14 Fehlerkategorien.
Viele dieser Probleme sind nicht, dass Prompt schlecht geschrieben ist.
Sondern:
Unvernünftige Aufgabeteilung, fehlgeschlagene Agent-Kooperation, verwirrte Zustandverwaltung und nicht validierte Ergebnisse.
Ich bin mir daher ein ganz einfaches Prinzip bewusst:
Ohne klare Aufgabengrenzen sollten Sie nicht mehr Agenten für "Multi-Agenten" verwenden.
Ein Problem, das mit einem Agent stabil gelöst werden kann, nutze zuerst einen.
Erst wenn die Aufgaben wirklich eine klare Rollenteilung, eine Isolierung von Rechten oder eine komplexe Zusammenarbeit aufweisen, sollten Sie eine Aufteilung in Betracht ziehen.
8. Die Beurteilung des Agenten kann nicht nur „richtig" sein.
Bei traditionellen LLM-Anwendungen ist es leicht, einen Genauigkeitstest zu machen.
Der Agent ist anders.
Weil es nicht nur „richtige Antworten", sondern auch „die Dinge zu beenden" braucht.
Zum Beispiel bei einem Rückerstattungsagent.
Er antwortete schließlich:
"Die Rückerstattung für Sie wurde abgeschlossen."
Schöner zu sagen, hat dieser Satz keinen Sinn.
Was wir wirklich überprüfen müssen:
Wurde die Rückzahlung wirklich durchgeführt?
Rückzahlung, oder?
Gibt es wiederholte Rückzahlungen?
Gibt es eine übermäßige Handlung?
Wurde die Arbeit aktualisiert?
Hat der Benutzer eine Benachrichtigung erhalten?
Wurde der gesamte Prozess vollständig dokumentiert?
Wenn Unternehmen einen Agent bewerten, empfehle ich, eine Reihe von echten, desensibilisierten historischen Aufgaben zu vergleichen.
Zum Beispiel 20 bis 50 Aufgaben.
Vergleichen Sie mindestens drei Möglichkeiten:
- Einmaler Aufruf zum Modell
- Ein Agent mit Werkzeugen
- Graph-Workflow oder Multi-Agent
Sie verwenden die gleichen Aufgaben und Akzeptanzkriterien.
Schwerpunkt-Aufzeichnungen:
- Erstmals Erfolgsquote
- Endgültige Mission Erfolgsrate
- Manuelle Änderung der Zeit
- Ende zu Ende Verzögerung
- Gesamtkosten von Modellen und Werkzeugen
- Anzahl Wiederversuche
- In welchem Punkt kommt das Scheitern auf.
- Anzahl der nicht autorisierten Operationen
- Ob die Quelle und die Ausführung vollständig sind
Insbesondere bei Risikogeschäften kann man nicht nur „Erfolg / Misserfolg" dokumentieren.
Es sollte auch behalten werden:
Bewertungsgrundlagen, ursprüngliche Beweise, Ausführungsverlauf und manuelle Überprüfungen.
Wenn Sie wirklich online sind, müssen Sie nicht nur antworten:
„Hat er es richtig gemacht?"
Noch zu antworten:
„Warum machst du das?"
9. Der beste Ausgangspunkt für einen Agent ist nicht "einen Super-Agent zu bauen".
Wenn ich mich jetzt als Agent für ein Unternehmen tätige, würde ich nicht zuerst darüber nachdenken:
„Wollen wir ein Multi-Agent - System bauen?"
Ich frage zuerst:
Gibt es bereits einen manuellen Prozess mit klaren Grenzen und überprüfbaren Ergebnissen?
Zum Beispiel:
Rechnungen überprüft.
Rückerstattung des Kunden.
Vertrag prüft.
Mitarbeiter eingesetzt.
Verkaufspuren erstellt.
Zuerst sollte man den Prozess klar machen.
Wie lange braucht es?
Wie hoch sind die Kosten?
Wo sind die häufigsten Fehler?
Welche Schritte sind am meisten arbeitsverschwendend?
Welche Schritte gehören zur Festlegung von Regeln?
Welche Schritte erfordern menschliches Urteil?
Nachdem Sie diese Benchmark haben, entscheiden Sie, wo Sie das Modell verwenden sollten.
Danach:
Wenn Sie mit einem Agent lösen können, müssen Sie sich nicht beeilen, mehrere zu entfernen.
Wenn Sie den Code verwenden können, lassen Sie das Modell nicht entscheiden.
Nur, wenn der Prozess klar ist:
Verzweigung, Parallelisierung, Genehmigung, Wiederholung, Wiederherstellung
Bei Bedarf wird der Workflow eingesetzt.
Wenn es um Zahlungen, Datenbankschreibungen, E-Mail - Versenden, Senden von Aufträgen und andere irreversible Aktionen geht, müssen Sie im Voraus planen:
Berechtigungsprüfungen, identische Schlüssel, manuelle Bestätigung, Rollback-Pfad.
In diesem Moment werden Sie entdecken:
Das Engineering von Agenten kommt im Wesentlichen immer näher an das traditionelle Software-Engineering.
Was ist die nächste Phase des Agenten?
In den letzten zwei Jahren haben wir geforscht:
Wie kann das Modell intelligenter werden?
Wie kann man Prompt effizienter machen?
Wie kann der Agent das Werkzeug besser nutzen?
Aber als nächstes könnten die Fragen, die Unternehmen wirklich interessieren, zu werden:
Wie kann ein Agent eine Aufgabe stabil erledigen?
Diese beiden Dinge sind völlig unterschiedlich.
Ein Modell, das gelegentlich erstaunlich ist, bedeutet nicht, dass es in die Produktionsumgebung kommen kann.
Ein Agent, der eine Aufgabe erledigen kann, bedeutet nicht, dass er täglich 10.000 Aufgaben erledigen kann.
Was Unternehmen wirklich brauchen, ist:
Stabiler Erfolg.
Kontrollierbare Kosten.
Prozess verfolgt werden kann.
Zustand wiederhergestellt werden kann.
Mindeste Befugnisse.
Zuverlässig wiederholen.
vollständige Audit.
künstliche Eingriffe.
kontinuierliche Beurteilung.
Daher würde ich den Agenten eher als ein neues Softwaresystem betrachten als ein Chatfenster, das Tools aufruft.
Prompt lässt das Modell die Aufgabe verstehen.
Agent Loop lässt das Modell basierend auf den Ergebnissen handeln.
Graph Workflow beschränkt den gesamten Ausführungsprozess.
Die drei sind an der richtigen Stelle, um gleichzeitig die Flexibilität von KI und die Gewissheit von herkömmlicher Software zu erhalten.
Was Google ADK 2.0 wirklich interessiert, ist vielleicht nicht, wie viele APIs es hinzufügt.
Sie sendet ein klares Signal:
Der Agent wird von einem „Chatbot, der Tools aufruft" zu einem „Software-System, das entworfen, betrieben und auditiert werden kann".
Graph Workflow ist nur ein Schritt auf diesem Weg.
Die Entscheidung, ob ein Agent online sein kann, ist immer noch nicht, wie erstaunlich die Demo ist, sondern:
Erfolgsraten, manuelle Nacharbeit, Verzögerungen, Kosten und Sicherheitsbilanz.
Dies ist wahrscheinlich die wichtigste Wettbewerbsfähigkeit, nachdem der Agent wirklich in die Produktionsumgebung des Unternehmens eingetreten ist.