Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Verwenden von Lambda MicroVMS als Sandbox für die OpenAI Agents API

Sie können AWS Lambda MicroVMS als selbst gehostete Umgebung für Agenten verwenden, die mit der OpenAI Agents API erstellt wurden. Workspace-Dateien, Tool-Ausführung und Netzwerkzugriff bleiben in der von Ihnen kontrollierten Infrastruktur erhalten. OpenAI führt den Agenten-Harness aus; die Lambda MicroVM führt Ihre Aufgaben aus. In diesem Beispiel wird es ausgeführtcodex exec-server, das die Tool-Aufrufe des Agenten ausführt und die Workspace-Dateien der Sitzung enthält. Sie entscheiden über den Bildinhalt, die Netzwerkpfade, die der Executor verwenden kann, und über die AWS Ressourcen, auf die seine Ausführungsrolle beschränkt ist.

Jede MicroVM wird als Firecracker-isolated Umgebung ausgeführt, die von einem Snapshot Ihres Images aus gestartet wird. Die Gesamtlebensdauer einer MicroVM beträgt bis zu 8 Stunden, einschließlich Betrieb und Ruhezustand. Beenden Sie sie nach der letzten Runde oder setzen Sie sie zwischen den Runden aus. Sie erstellen ein wiederverwendbares Image und starten dann eine MicroVM entweder von Ihrer Anwendung oder einem Webhook-Launcher aus. Beide Ansätze verwenden dasselbe Image und dieselben Anmeldeinformationen. Weitere Informationen finden Sie im Referenzbeispiel für die selbst gehostete OpenAI Agents API-Sandbox auf Lambda MicroVMS.

Funktionsweise

Im vom Webhook verwalteten Pfad startet eine Launcher-Lambda-Funktion eine MicroVM, wenn die Sitzung zum ersten Mal einen Executor benötigt. Sie verwendet die vorhandene MicroVM wieder und nimmt sie zuerst wieder auf, wenn sie unterbrochen wird. Ihre Anwendung beendet es nach dem letzten Spielzug. Abbildung 1 zeigt den Ablauf:

Abbildung 1. Webhook-managed Bereitstellung einer Agenten-API-Sandbox auf AWS Lambda MicroVMS.

Halten Sie den Anwendungsschlüssel und die Webhook-Signatur außerhalb der MicroVM geheim. Der Launcher übergibt nur den geheimen ARN des Executor-Schlüssels. Die VM ruft den Schlüssel mithilfe ihrer Ausführungsrolle ab.

Wichtige Eigenschaften

Voraussetzungen

Das MicroVM-Image wird vorbereitet

Erstellen Sie ein Image, das die Codex-CLI, Ihre Tool-Abhängigkeiten, ein Arbeitsverzeichnis wie /workspace und einen HTTP-Server für die Lifecycle-Hooks enthält.

Verpacken Sie den Dockerfile und Hook-Server in ein Amazon S3-Artefakt und erstellen Sie dann das codex-executor Image mit 8 GB Basisspeicher (Basisspeicher mit 4 vCPUs). Aktivieren Sie die ausgewählten Hooks in der Image-Konfiguration und stellen Sie den Hook-Port so ein, dass er zu Ihrem Server passt. Halten Sie Sitzungs-IDs, Anmeldeinformationen und Live-Executor-Verbindungen vom Image-Snapshot fern. Informationen zur Build- und Hook-Konfiguration finden Sie unter. MicroVM-Bilder

Beim Start serialisiert Ihre Anwendung oder Ihr Launcher die folgenden Werte als JSON in: runHookPayload

Kehren Sie vom /run Hook zurück, sobald der Executor-Prozess gestartet wurde, ohne auf das Ende der Runde zu warten, um einen Hook-Timeout zu vermeiden.

MicroVMS starten

Sie können MicroVMS von Ihrer Anwendung oder von einem Webhook-Launcher aus starten. Halten Sie in beiden Fällen den Event-Stream der Sitzung geöffnet, bis der Zug beendet ist.

Application-managed Bereitstellung

Webhook-managed Bereitstellung

Ihre Anwendung erstellt die Sitzung, öffnet ihren Stream und übermittelt Eingaben. Der Launcher erledigt den Rest, wenn der Webhook eintrifft.

Das Referenzbeispiel speichert die MicroVM-ID in den Sitzungsmetadaten. Gleichzeitige Webhook-Lieferungen können zusätzliche VMs starten, bevor diese ID gespeichert wird. Vermeiden Sie vor dem Produktionseinsatz gleichzeitige Starts für dieselbe Sitzung und deduplizieren Sie Webhook-Ereignisse.

Beenden einer Runde

Abbildung 2 zeigt den MicroVM-Lebenszyklus für eine einzelne Runde und den optionalen Suspend- und Resume-Pfad für nachfolgende Turns.

Abbildung 2. MicroVM-Lebenszyklus für eine Agenten-API-Runde. RunMicrovmstartet die MicroVM, der /run Hook startet den Executor, die Umgebung stellt eine Verbindung her, der Turn läuft und der Turn endet. Im Single-Turn-Pfad rufen Sie Dateien ab und rufen auf. TerminateMicrovm Beim Multiturn-Pfad wird die MicroVM nach dem Turn unterbrochen und bei der nächsten Verbindungsanforderung wieder aufgenommen.

Warten Sie im Sitzungsstream auf oder auf den Hauptagenten agent.session.turn.completedagent.session.turn.failed, agent.session.turn.cancelled wo er sich befindet. event.turn.subagent_id null Unteragenten teilen sich die MicroVM, sodass ihre Terminalereignisse keine Säuberung auslösen. Rufen Sie die Dateien ab, die Sie benötigen. Rufen Sie nach dem letzten Zug an TerminateMicrovm und bestätigen Sie, dass die VM das Ziel erreichtTERMINATED. Lassen Sie die Maschine laufen oder setzen Sie sie aus, wenn Sie weitere Züge ausführen möchten. Führen Sie die Bereinigung durch, wenn in Ihrer Anwendung ein Fehler auftritt.

Turn-Ergebnisse kommen als Stream-Ereignisse an, nicht als Webhook-Abonnements. Der agent.session.failed Webhook deckt Sitzungsfehler ab, aber nicht jede fehlgeschlagene Runde. Aus diesem Grund sollten Sie den Vorgang nicht agent.session.idle alleine beenden, da er eintreffen kann, bevor die Warteeingabe beginnt.

Um die Lebensdauer der MicroVM zu begrenzen, falls die Bereinigung nicht ausgeführt wird, konfigurieren Sie beim Start die folgenden Einstellungen:

Informationen zu Steuerungen über die gesamte Lebensdauer und den Leerlauf finden Sie unter. MicroVMs ausführen und verwenden

Löschen Sie die Sitzung separat. Durch das Löschen einer Sitzung wird die MicroVM nicht gestoppt und es wird kein Löschen-Webhook gesendet. Halten Sie das Image und den Executor-Schlüssel zur Wiederverwendung geheim. Informationen zum Umgang mit nachfolgenden Turns finden Sie unter Sandbox-Lebenszyklus.

Unterbrechen und Wiederaufnehmen zwischen den Zügen

Um den Speicher- und Festplattenstatus zwischen den Durchgängen beizubehalten, setzen Sie die MicroVM aus, nachdem der Haupt-Agent an der Reihe ist und alle Tools und Unteragenten fertig sind. Nehmen Sie dieselbe MicroVM wieder auf, wenn die nächste Sitzung einen Executor benötigt.

Netzwerk

Erlauben Sie dem Executor die erforderlichen ausgehenden Verbindungen zu OpenAI und den Zugriff auf Secrets Manager. Um private Ressourcen zu erreichen oder Ihre eigenen Netzwerkeinschränkungen anzuwenden, fügen Sie beim Start einen VPC-Anschluss für ausgehenden Datenverkehr hinzu. Siehe Arbeiten mit ausgehenden Netzwerkverbindern.

Das Beispiel unterstützt das Hoch- und Herunterladen von Dateien über den HTTPS-Endpunkt der MicroVM, wobei ein Authentifizierungstoken verwendet wird, das auf den Port des Servers beschränkt ist.

Überwachen

Führen Sie eines der beiden Beispiele aus und bestätigen Sie dann, dass die MicroVM die Datei hello.txt herunterlädt und die gelöschte TERMINATED Sitzung HTTP 404 zurückgibt.

Launcher-Protokolle. Überprüfe die Logs der Launcher-Lambda-Funktion in CloudWatch Logs:

aws logs tail /aws/lambda/codex-agents-api-webhook --since 10m

MicroVMS ausführen. Stellen MICROVM_IMAGE_ARN Sie Ihr Image-ARN ein, verwenden Sie die AWS Region Ihrer Bereitstellung und listen Sie die MicroVMs für das Image auf:

aws lambda-microvms list-microvms \
  --image-identifier "$MICROVM_IMAGE_ARN" \
  --query 'items[].{id:microvmId,state:state}' --output table

Protokollieren Sie Sitzungs- und MicroVM-IDs zusammen, damit Sie einen Lauf von Ende zu Ende verfolgen können. Halten Sie Anmeldeinformationen und unformatierte Webhook-Texte aus den Protokollen fern.

Fehlerbehebung

Prüfen Sie agent.session.environment.failed Ereignisse und die Executor-Protokolle auf Verbindungsfehler. Den Vertrag über den gemeinsamen Testamentsvollstrecker finden Sie unter Sandboxes. Self-hosted

Zugehörige Ressourcen