Der Agent wählt den nächsten Zweig: Dify 1.18 macht Abläufe übertragbar und prüfbar

Eine Agentendemo kann schon nach einer erfolgreichen Anfrage überzeugen. Die schwierigeren Fragen kommen, wenn ein zweites Team sie wiederverwenden möchte: Welchen Zweig wählt sie, welche Dateien reisen mit der Anwendung mit, und wo lässt sich sehen, was in einem verschachtelten Ablauf passiert ist?

Dify 1.18.0, veröffentlicht am 23. Oktober 2026, bringt diese Fragen zusammen. Die Version ergänzt Output Routes für Agenten, übertragbare .ifpkg-App-Pakete und tiefere Einblicke in Arbeitsabläufe. Dabei geht es weniger um eine eindrucksvollere Agentenantwort als darum, die Rolle des Agenten in einer Anwendung verständlich genug für eine Wiederverwendung zu machen. Offizielle Veröffentlichung.

Dify ist eine Plattform zum Erstellen von KI-Anwendungen mit visuellen Abläufen, Modellen, Wissen und Werkzeugen. Teams können die Beurteilung eines Modells mit Anwendungsschritten verbinden, statt denselben Prompt wiederholt in einen Chat zu kopieren. Interessant an dieser Version ist die Verbindung dreier praktischer Fragen: den nächsten Schritt bestimmen, die Anwendung übertragen und ihre Ausführung untersuchen.

Workflow-Oberfläche von LangGenius / Mitwirkenden der Dify-Dokumentation, CC BY 4.0. Ohne Beschnitt verkleinert und in WebP umgewandelt. Die Ansicht veranschaulicht den visuellen Editor, nicht jedes neu veröffentlichte Bedienelement.

Ein Zweig ist eine Entscheidung mit einem Ziel

In herkömmlichen Abläufen prüfen Bedingungen oft einen bekannten Wert: Ein Status ist freigegeben, ein Feld ist leer oder ein Wert überschreitet einen Grenzwert. Sprachliche Anfragen sind weniger ordentlich. Ein Kunde kann Frage, Beschwerde und Ausnahmewunsch in einer Nachricht verbinden.

Difys neue Output Routes lassen einen Agenten zwischen eingerichteten Wegen wählen, damit der Ablauf im entsprechenden Zweig weitergeht. Die Interpretation des Agenten wird zur Auswahl innerhalb eines Prozesses. Der nächste Schritt ist im Ablauf dargestellt und bleibt nicht vollständig generiertem Fließtext überlassen.

Das kann Gestaltung und Prüfung einer Anwendung erleichtern. Der Ersteller legt fest, welche Ziele existieren. Der Agent wählt für eine Anfrage eines davon. Der Ablauf führt die verbundenen Schritte aus. Eine Route kann nützlich sein, auch wenn die natürlichsprachige Erklärung des Agenten nicht das Endprodukt ist.

Die Grenze ist wichtig. Den Weg „eskalieren“ zu wählen, beweist nicht, dass der Fall rechtlich oder finanziell eine Eskalation verlangt. „Antwort entwerfen“ zu wählen, ist keine Erlaubnis zum Versand. Der Ablauf muss weiterhin festlegen, welche Vorgänge nach jeder Wahl erlaubt sind und wer Ausnahmen verantwortet.

Erstes Beispiel: Eine Kundennachricht, drei mögliche Wege

Betrachten wir ein Supportteam mit Produktfragen und Ausnahmewünschen. Seine Anwendung soll drei grobe Wege unterscheiden: aus freigegebenem Hilfsmaterial antworten, einen Entwurf für einen Menschen vorbereiten oder einen ungewöhnlichen Fall eskalieren.

Ausdrückliche Routen machen diese Ziele im Ablauf sichtbar. Eine einfache Einrichtungsfrage kann in einen wissensgestützten Antwortzweig gelangen. Eine Anfrage mit kontospezifischer Unsicherheit kann zur Prüfung führen. Die Bitte, eine geschäftliche Bedingung außer Kraft zu setzen, kann an das dafür zuständige Team gehen.

Das sind beispielhafte Anwendungsentscheidungen, keine fertige Supportregel von Dify. Das Team muss definieren, was zu welcher Route gehört, geeignete Beispiele liefern und über den Umgang mit mehrdeutigen Eingaben entscheiden. Eine überzeugende Erklärung darf keine Befugnisgrenze auflösen.

Der Nutzen liegt nicht darin, dass jede Nachricht leicht einzuordnen wird. Der Ersteller kann vielmehr eine bestimmte Entscheidung bewerten. Schickt der Agent einen schwierigen Fall in den gewöhnlichen Antwortzweig, ist der Test klar gescheitert. Schickt er jede Anfrage zu einem Menschen, ist der Ablauf vielleicht sicher, bietet aber wenig Automatisierungsnutzen.

Bewahren Sie schwierige Nachrichten mit den erwarteten Zielen auf. Dazu gehören gemischte Anliegen, fehlende Angaben und sprachliche Varianten, die echten Kundeneingängen ähneln. Ein Ablauf, der nur mit besonders sauberen Beispielen gelingt, bleibt eine Demo, auch wenn sein Diagramm fertig aussieht.

Eine eingerichtete Route macht aus einer sprachlichen Beurteilung ein sichtbares Ablaufziel. Jedes Ziel braucht weiterhin eigene erlaubte Aktionen und Prüfregeln.

Übertragbarkeit bedeutet mehr als einen Prompt zu kopieren

Eine KI-Anwendung kann von Anweisungen, Agentendefinitionen, Skills, Dateien und Verweisen auf Ressourcen im Arbeitsbereich abhängen. Wer nur den sichtbarsten Prompt kopiert, lässt große Teile der Anwendung zurück.

Dify 1.18 führt ein .ifpkg-Paket ein, das eingebettete Agents, Skills und ihre Dateien enthalten kann. Beim Import werden diese Ressourcen laut Veröffentlichung neu angelegt und Referenzen neu zugeordnet. Datei- und URL-Import unterstützen YAML und das Paketformat; ein ausdrücklicher YAML-Export bleibt verfügbar. Änderungen an Paketen und Import.

Das ist für die Wiederverwendung relevant. Ein Team kann eher die zusammengehörigen Bestandteile übertragen, die das Verhalten des Agenten erklären, statt einen Kollegen alles anhand manueller Anweisungen rekonstruieren zu lassen.

Damit ist nicht belegt, dass jede externe Abhängigkeit automatisch mitwandert. Modellzugriff, Zugangsdaten, verfügbare Plugins, Netzwerkberechtigungen und Wissensressourcen können von der Zielumgebung abhängen. Eine importierte App kann strukturell vollständig sein und trotzdem Konfiguration brauchen, bevor sie korrekt läuft.

Behandeln Sie das Paket als nützliches Anwendungsartefakt, das geprüft werden muss. Eine Datei kann Anweisungen und unterstützende Inhalte enthalten, die ein anderes Team nicht selbst geschrieben hat. Klären Sie vor dem Import in einen Arbeitsbereich mit wertvollen Zugängen ihre Herkunft und die vorgesehenen Handlungen ihrer Agenten und Werkzeuge.

Zweites Beispiel: Ein Angebotsablauf wechselt das Team

Stellen wir uns ein Dienstleistungsunternehmen vor, das einen Ablauf für erste Angebotsentwürfe erstellt hat. Er erfasst eine Anfrage, wendet einen Schreib-Skill an, prüft erforderliche Abschnitte und leitet unklare Geschäftsbedingungen an einen Menschen weiter.

Ein zweites Team möchte denselben Ansatz mit einem anderen Leistungskatalog nutzen. Eine reine Promptübergabe wäre unvollständig: Wiederverwendbare Schreibanweisungen, angehängte Vorlagen und Agentenreferenzen gehören zum Verhalten. Das Paketformat soll mehr dieser verbundenen Teile gemeinsam übertragen helfen.

Das empfangende Team muss trotzdem arbeiten. Es muss Leistungsinformationen ersetzen oder bestätigen, erlaubte Modelle und Werkzeuge konfigurieren und prüfen, wer ein Angebot freigeben darf. Verweist ein importierter Ablauf auf eine Ressource, die nicht in den neuen Arbeitsbereich gehört, ist ein erfolgreicher Import kein Grund, diese Referenz ungeprüft zu lassen.

Führen Sie vor und nach dem Umzug dieselbe kleine Auswahl an Beispielanfragen aus. Vergleichen Sie Routenauswahl, Pflichtabschnitte, Werkzeugzugriff und Prüfverhalten. Eine übertragbare Anwendung sollte den beabsichtigten Prozess erhalten und zugleich bewusste Änderungen zielspezifischer Informationen erlauben.

Hier wird Verpackung zur betrieblichen Funktion. Sie kann Rekonstruktionsarbeit senken; der nützliche Ausgang ist aber eine wiederholbare Übergabe, die ein anderes Team versteht und testen kann. Eingesparte Klicks beim Import sind nur ein Teil davon.

Einblicke in den Ablauf verändern die Fehlersuche

Die Veröffentlichung betont außerdem tiefere Einblicke in Arbeitsabläufe, einschließlich verschachtelter Ausführung. Das ist wichtig, weil ein Anwendungsfehler mehrere Schritte vor der Stelle entstehen kann, an der Nutzer ihn bemerken.

Ein schlechter Endentwurf kann von einer falschen Route, einer fehlenden Wissensquelle, einem unvollständigen Werkzeugergebnis oder Anweisungen in einem verschachtelten Ablauf stammen. Sieht das Team nur die endgültige Antwort, überarbeitet es vielleicht immer wieder einen Prompt, der nicht für den Fehler verantwortlich ist.

Sichtbarere Ausführung ermöglicht engere Fragen: Welche Eingabe erreichte diesen Schritt, welches Ergebnis erzeugte er und welcher Schritt verwendete das Ergebnis danach? Die Antwort unterstützt eine gezieltere Korrektur als gleichzeitige Änderungen an mehreren Anwendungsteilen.

Sichtbarkeit ist keine vollständige Erklärung der internen Modellüberlegungen. Ausführungsinformationen können Ereignisse und Datenfluss einer Anwendung zeigen, ohne zu belegen, warum jedes Token oder jede Route gewählt wurde. Sie bestimmen auch nicht automatisch, welche Spurinformationen jeder Betrachter sehen darf.

Nutzen Sie die verfügbaren Einblicke für das beobachtbare Verhalten des Ablaufs. Entscheiden Sie getrennt über Aufbewahrungsdauer der Spuren, enthaltene sensible Daten und Zugriffsrechte. Eine Anwendung mit vertraulichen Anfragen sollte bequeme Fehlersuche nicht in unbeschränkten Inhaltszugriff verwandeln.

Veröffentlichte Version und Upgrade sind getrennte Fragen

Die offizielle GitHub-Version ist eine datierte Softwareveröffentlichung. Sie beweist für sich allein nicht, dass in jedem gehosteten Dify-Arbeitsbereich zur selben Zeit dieselben Funktionen aktiviert sind. Nutzer eines verwalteten Dienstes sollten ihren tatsächlichen Arbeitsbereich und die Dokumentation prüfen, bevor sie mit einem bestimmten Bedienelement planen.

Selbst gehostete Installationen haben eine andere Verantwortung. Die Versionshinweise zu Dify 1.18 beschreiben abgestimmte Änderungen an API, Workern, Agent Backend und Laufzeit-Images, einschließlich eines veränderten Agentenlaufzeitprotokolls. Nur eine sichtbare Komponente zu aktualisieren ist kein verlässlicher Weg bei einer Version, die die Kommunikation mehrerer Komponenten verändert.

Die Hinweise nennen auch Konfigurations- und Migrationsdetails für lokale Agenten-Sandboxes und Werkzeuge. Diese gehören in einen Upgradeplan für die konkrete Installation. Sie sollten nicht auf einen allgemeinen Befehl aus einer Produktübersicht reduziert werden.

Bewahren Sie vor einem Upgrade die aktuelle Konfiguration und Anwendungsartefakte auf, ermitteln Sie unterstützte Komponentenversionen und testen Sie die Migration in einer geeigneten Umgebung. Ersetzen Sie dauerhafte Authentifizierungs- oder Verschlüsselungseinstellungen nicht allein deshalb, weil eine Beispielkonfiguration einen neu wirkenden Wert enthält. Folgen Sie den genauen Migrationshinweisen der Version.

Wer zunächst Routen oder Pakete bewerten möchte, kann sinnvoll mit einer separaten Testanwendung beginnen. So lässt sich neues Verhalten kennenlernen, ohne aus dem ersten Versuch gleich die Migration des wichtigsten Ablaufs zu machen.

Eine brauchbare Bewertung passt auf eine Seite

Es braucht keine Dutzende Agenten, um den Nutzen dieser Funktionen zu prüfen. Eine Anwendung mit echter Entscheidung und eine zweite Umgebung für den Importtest reichen aus, um mehrere wichtige Eigenschaften zu erkennen.

1. Eine begrenzte Aufgabe wählen. Nehmen Sie einen Prozess mit erkennbaren Eingaben und Ergebnissen, etwa die Vorbereitung einer geprüften Supportantwort. Benennen Sie den Verantwortlichen für Ausnahmen.
2. Wenige Routen definieren. Geben Sie jeder Route eine betriebliche Bedeutung und legen Sie ihre Folgeaktionen fest. Ergänzen Sie einen Weg für nicht sicher einzuordnende Anfragen.
3. Repräsentative Fälle sammeln. Verwenden Sie normale Anfragen, gemischte Absichten und fehlende Angaben. Notieren Sie die erwartete Route vor der Ausführung.
4. Ausführung statt nur Endantwort prüfen. Verfolgen Sie die relevanten verschachtelten Schritte und erkennen Sie, wo ein unerwarteter Wert oder eine Wahl erstmals auftaucht.
5. Anwendung exportieren und importieren. Prüfen Sie enthaltene Ressourcen sowie Referenzen, Werkzeuge, Modelle und Geheimnisse am Ziel. Fehlender Zugriff sollte nicht automatisch gewährt werden.
6. Nach dem Umzug dieselben Fälle wiederholen. Vergleichen Sie Routen und Ergebnisse und dokumentieren Sie beabsichtigte Abweichungen in der Konfiguration des empfangenden Teams.

Die nützlichen Messwerte sind konkret: Wie oft erreicht eine Anfrage das vorgesehene Ziel, wie viel Konfiguration braucht die Übergabe, und kann ein Prüfer einen Fehler finden, ohne den gesamten Lauf zu rekonstruieren? Keine dieser Messungen erfordert, generierten Text als Beleg seiner eigenen Richtigkeit zu behandeln.

Ein Paket kann die Anwendungsstruktur übertragen. Am Ziel bleiben eigene Zugriffsprüfungen und die Wiederholung jener Fälle nötig, die erfolgreiches Verhalten definieren.

Was aussichtsreicher wird und was Sorgfalt verlangt

Die vielversprechende Richtung ist eine besser wiederverwendbare Anwendungseinheit. Ein Ablauf kann ausdrückliche Ziele enthalten, mehr unterstützende Agentenressourcen mitbringen und bei Problemen mehr von seiner Ausführung sichtbar machen. Diese Kombination hilft Teams, die über isolierte Prompts hinaus sind, aber nicht jede Anwendung zu einem individuellen Integrationsprojekt machen möchten.

Die entsprechende Sorge ist, dass Übertragbarkeit Fehler genauso effizient verbreiten kann wie gute Muster. Eine unklare Routendefinition oder ein zu mächtiges Werkzeug wird durch eine saubere Verpackung nicht angemessen. Prüfen Sie das importierte Verhalten und nicht nur, ob sich die Datei erfolgreich öffnen lässt.

Für Dify ist der nächste aussagekräftige Test, ob Teams diese Anwendungen über Veränderungen hinweg pflegen können: ein anderes Modell, ein neuer Skill, eine geänderte Geschäftsregel oder ein neuer Arbeitsbereich. Ein gelungener erster Import ist ermutigend. Ein kontrolliertes Update, das beabsichtigtes Verhalten erhält, ist ein stärkeres Reifezeichen.

Dify 1.18 macht diesen Versuch interessanter, weil Agentenentscheidungen mit sichtbarer Ablaufstruktur verbunden werden. Beginnen Sie mit einem kleinen Prozess, halten Sie die Routen verständlich und machen Sie die Übergabe wiederholbar. So wird aus einer vielversprechenden Demo etwas, das ein anderes Team verantwortungsvoll nutzen kann.

Quellen

• Dify-1.18.0-Versionshinweise, veröffentlicht am 23. Oktober 2026 um 06:33 UTC.
• Offizielle Dify-Dokumentation, Produkthintergrund; die Verfügbarkeit der Version ist im tatsächlichen Arbeitsbereich zu prüfen.

Möchten Sie einen durchsuchbaren Ort für Ablaufnotizen, Beispielanfragen und Entscheidungen hinter einer Überarbeitung? Sammeln Sie Ihr Referenzmaterial in Telli.sh und halten Sie die Übergabe verständlich.