Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Agent Framework 1.13.0 enthält geringfügige Änderungen an Python Workflowausführung. Die meisten Anwendungen erfordern keine Änderungen. Die Änderungen wirken sich auf Anwendungen aus, die von exakten Superstep-Anzahlen oder Iterationsnummern abhängen, an der Konvergenzgrenze festgelegt max_iterations , die ursprüngliche Nachrichtenquell-ID prüfen oder Annahmen zur Platzierung und Sortierung des Prüfpunkts treffen.
Hintergrund
Vor 1.13.0 erfüllte prüfpunkting nicht vollständig seine Zusage, den Workflowzustand zu erfassen, der zum Fortsetzen der Ausführung von einer aufgezeichneten Grenze erforderlich ist. Der Startausführer wurde vor der Superstep- und Prüfpunktschleife ausgeführt, sodass der früheste Prüfpunkt die Ausgabe des Startausführers und den aktualisierten Zustand enthielt, aber nicht die ursprüngliche Workfloweingabe. Ebenso wurden Antworten auf Anforderungsereignisse übermittelt und verarbeitet, ohne zuerst in einem Prüfpunkt aufgezeichnet zu werden. Daher konnte kein Prüfpunkt den Startausführer aus der ursprünglichen Eingabe wiedergeben oder eine menschlichen In-the-Loop-Fortsetzung aus der übermittelten Antwort reproduzieren.
Verhaltensänderungen
Version 1.13.0 schließt diese Lücken. Der Start-Executor wird jetzt im ersten Superstep ausgeführt, ein Eintragsprüfpunkt zeichnet die anfängliche Eingabe vor diesem Superstep auf, und ein Antworteingabeprüfpunkt erfasst Antworten, bevor sie verarbeitet werden. Zusammen führen diese Änderungen einen prüfpunktierten Workflow vollständig aus der Eingabe wiederzugeben, einschließlich der Fortsetzungen von Human-in-the-Loop.
Important
Diese Änderungen wirken sich nicht auf Prüfpunkte aus, die vor Version 1.13.0 erstellt wurden. Vorhandene Prüfpunkte werden weiterhin unterstützt und können nach dem Upgrade weiterhin wiederhergestellt werden.
Änderungen, die möglicherweise eine Aktion erfordern
| Bereich | Vor 1.13.0 | In 1.13.0 und höher | Benutzerauswirkungen |
|---|---|---|---|
| Starten des Executors | Der Startausführer wurde vor der Superstepschleife ausgeführt. | Die Eingabe wird für den Startausführer in die Warteschlange gestellt, der im ersten Superstep ausgeführt wird. | Jede neue Ausführung gibt ein zusätzliches Ereignis und superstep_completed ein weiteres superstep_started Ereignis aus. |
| Iterationsanzahl | Iteration 1 repräsentiert den ersten Superstep, nachdem der Startausführer ausgeführt wurde. | Iteration 1 führt den Startausführer aus. Spätere Arbeitsverschiebungen werden um eine Iteration ausgeführt. | Ein Workflow, der zuvor $N$ Iterationen benötigt hat, benötigt jetzt $N + 1$. |
| Eingabenachrichtenquelle | Die ursprüngliche Nachricht hatte die hartcodierte Quell-ID "Workflow". |
Die ursprüngliche Nachricht wird über den internen Edge des Startausführers übermittelt und verfügt über die Quell-ID INTERNAL_SOURCE_ID(start_executor.id). |
Code, der die ursprüngliche Nachrichtenquell-ID liest oder filtert, muss den neuen Wert verwenden. |
Verbesserungen bei der Wiedergabebarkeit
| Bereich | Vor 1.13.0 | In 1.13.0 und höher | Verbesserung |
|---|---|---|---|
| Anfangsprüfpunkt | Der Iterations-0-Prüfpunkt wurde erstellt, nachdem der Startausführer ausgeführt wurde. Er erfasste die Ausgabemeldungen des Executors und den aktualisierten Zustand, jedoch nicht die ursprüngliche Eingabe. | Vor dem Superstep 1 wird ein Eintragsprüfpunkt erstellt. Es zeichnet die ursprüngliche Eingabe in die Warteschlange für den Startausführer auf. | Durch das Wiederherstellen des Eintragsprüfpunkts wird die vollständige Ausführung wiedergegeben, einschließlich des Startausführers. |
| Antwortprüfpunkt | Eine Antwort auf ein Anforderungsereignis wurde übermittelt, ohne zuerst in einem Prüfpunkt aufgezeichnet zu werden. | Ein Prüfpunkt für den Antworteintrag wird erstellt, nachdem die Antwort übermittelt wurde, und bevor der verbrauchende Superstep ausgeführt wird. | Durch das Wiederherstellen des Prüfpunkts für den Antworteintrag wird die Fortsetzung wiedergegeben, die die Antwort verwendet. |
Aktualisieren der Ereignisbehandlung in Supersteps
Eine neue Workflowausführung erzeugt jetzt ein weiteres Paar superstep-Ereignisse, da der Startausführer in Superstep 1 ausgeführt wird:
-
superstep_startedmititeration == 1 -
superstep_completedmititeration == 1
Nachfolgende Ausführungsausführungsarbeitsschichten werden um einen Überschritt verschoben. Aktualisieren Sie Tests, Telemetrie, Statusanzeigen oder anderen Code, der davon ausgeht, dass eine genaue Ereignisanzahl oder ein bestimmter Executor einer festen Iteration zugeordnet wird.
Code, der auf Ereignistypen reagiert, ohne sich auf die Anzahl oder Iteration zu verlassen, muss sich nicht ändern.
Überprüfen des maximalen Iterationsgrenzwerts
Der max_iterations Grenzwert umfasst jetzt den Superstep, der den Startausführer ausführt. Wenn ein Workflow zuvor seinen vollständigen Grenzwert verwendet hat, erhöhen Sie den konfigurierten Wert um eins:
from agent_framework import WorkflowBuilder
workflow = WorkflowBuilder(
start_executor=start_executor,
max_iterations=previous_max_iterations + 1,
).build()
Es ist keine Änderung erforderlich, wenn der Workflow bereits zusammengeführt wird, bevor der konfigurierte Grenzwert erreicht wird.
Aktualisieren der ursprünglichen Nachrichtenquellenüberprüfungen
Wenn ein Startausführer die Quell-ID der ursprünglichen Nachricht verwendet, ersetzen Sie den hartcodierten "Workflow" Wert durch die Quell-ID für den internen Edge des Startausführers.
Vor 1.13.0:
is_workflow_input = ctx.source_executor_ids != ["Workflow"]
In 1.13.0 und höher:
from agent_framework import INTERNAL_SOURCE_ID
is_workflow_input = ctx.source_executor_ids != [INTERNAL_SOURCE_ID(self.id)]
INTERNAL_SOURCE_ID(executor_id) gibt zurzeit zurück "internal:<executor_id>". Verwenden Sie das Hilfsprogramm, anstatt diese Zeichenfolge zu erstellen, damit Ihr Code dem Quell-ID-Format des Frameworks folgt.
Aktualisieren der Prüfpunktbehandlung
Anfängliche Eingabeprüfpunkte
Wenn die Prüfpunkterstellung aktiviert ist, erstellt jede neue Ausführung jetzt einen Eintragsprüfpunkt bei iteration_count == 0. Dieser Prüfpunkt enthält die ursprüngliche Eingabe als In-Flight-Nachricht, die an den Startausführer adressiert ist. Durch das Wiederherstellen wird der Startausführer erneut ausgeführt und die vollständige Workflowausführung reproduziert.
Nach jedem abgeschlossenen Superstep erstellt das Framework weiterhin einen Prüfpunkt. Für eine Ausführung mit $N$ Supersteps erwarten Sie $N + 1$ Prüfpunkte: der Einstiegsprüfpunkt gefolgt von einem Prüfpunkt für jeden abgeschlossenen Superstep.
Überprüfen Sie code, der davon ausgeht, dass der Iterations-0-Prüfpunkt den Zustand enthält, der vom Startausführer erzeugt wird. Dieser Zustand wird nun im Prüfpunkt angezeigt, der nach dem Superstep 1 erstellt wurde.
Anforderungsantwortprüfpunkte
Wenn Sie einen Workflow fortsetzen, workflow.run(responses=...)erstellt das Framework jetzt einen Prüfpunkt für den Antworteintrag, nachdem die Antworten in die Warteschlange warteschlange und vor dem Ausführen des Supersteps, der sie verbraucht, ausgeführt wurde. Durch das Wiederherstellen dieses Prüfpunkts werden die aufgezeichneten Antworten erneut übermittelt und der Rest des Workflows wiedergegeben.
Der Prüfpunkt für den Antworteintrag hat den gleichen Wert iteration_count wie der vorherige Prüfpunkt, der die ausstehende Anforderung enthält. Es handelt sich um einen separaten Prüfpunkt, dessen previous_checkpoint_id Punkte auf diesen Prüfpunkt für ausstehende Anforderungen verweist.
Important
Eine iteration_count ist nicht garantiert einzigartig in einer menschlichen In-the-Loop-Prüfpunkthistorie. Folgen Sie der previous_checkpoint_id Kette, um die Prüfpunktreihenfolge zu bestimmen. Wenn Sie den neuesten Prüfpunkt benötigen, verwenden Sie die Prüfpunktspeicher-API, anstatt die größte iteration_countauszuwählen.
Migrationscheckliste
- Aktualisieren Sie Assertionen und Ereignis-Consumer, die von exakten Superstep-Anzahlen oder Iterationsnummern abhängen.
- Erhöhen Sie
max_iterationsnur eins für Workflows, die den vorherigen Grenzwert erreicht haben. - Ersetzen Sie die anfänglichen Quell-ID-Überprüfungen
"Workflow"durchINTERNAL_SOURCE_ID(start_executor.id). - Behandeln Sie den Iterations-0-Prüfpunkt als Eingabeprüfpunkt vor der Ausführung.
- Ordnen Sie Human-in-the-Loop-Prüfpunkte nach Linie an, anstatt davon auszugehen
iteration_count, dass sie eindeutig ist. - Stellen Sie sicher, dass die Wiedergabe eines Eintragsprüfpunkts und eines Prüfpunkts für den Antworteintrag die erwartete Ausgabe und Nebenwirkungen erzeugt.
Details zur Implementierung finden Sie unter "Vollständige Wiedergabebarkeit des Workflowprüfpunkts zulassen".