OpenCode intern einsetzen: Sichere Toolnutzung auf TrueFoundry

Wir alle hatten diesen Moment mit dem Code Interpreter von ChatGPT (jetzt „Advanced Data Analysis“). Du lädst eine chaotische CSV-Datei hoch, bittest sie, „die Daten zu korrigieren und den Trend zu zeichnen“, und beobachtest voller Ehrfurcht, wie Python-Code in Echtzeit geschrieben und ausgeführt wird.

Es ist eine Produktivitäts-Superwaffe. Es ist auch eine massive Sicherheitslücke, wenn Sie mit sensiblen Daten arbeiten.

In dem Moment, in dem du die CSV-Datei hochlädst, verlässt sie deinen Umkreis. Für unser Team bestand das Ziel darin, diese „OpenCode“ -Funktion zu replizieren und unseren LLM-Agenten die Möglichkeit zu geben, Code zu schreiben und auszuführen — ohne das Risiko einer Datenexfiltration. Wir wollten keine „Blackbox“ -API; wir brauchten eine Privater Code-Interpreter wo die Berechnung neben den Daten stattfindet.

So haben wir die sichere Toolnutzung und Codeausführung mithilfe der Infrastrukturkomponenten von TrueFoundry implementiert.

Die Architektur eines privaten Code-Interpreters

Bei „OpenCode“ geht es nicht nur darum, ein Modell zu haben, das Python schreiben kann. Es erfordert drei verschiedene Komponenten, die zusammenarbeiten:

1. Das Gehirn (LLM): Ein Modell, das in der Lage ist, logisch zu denken und Funktionen aufzurufen (z. B. Llama 3, DeepSeek-Coder oder GPT-4o via Gateway).
2. Die Hände (Sandbox): Eine isolierte, kurzlebige Umgebung, in der der Code tatsächlich ausgeführt wird.
3. Der Kleber (Gateway): Die Middleware, die die Absicht des Modells analysiert und die Ausführungsanforderung weiterleitet.

Die meisten Leute bleiben bei „The Hands“ hängen. Sie können nicht einfach ein LLM os.system ('rm -rf /') auf Ihrem Produktionscluster ausführen lassen. Sie benötigen eine Sandbox.

TrueFoundry löst dieses Problem, indem es uns die Bereitstellung ermöglicht kurzlebige Ausführungsumgebungen (Dienste oder Jobs), die als Sandbox dienen. Das LLM Gateway verarbeitet die Definitionen der Toolnutzung, und die eigentliche Ausführung erfolgt in einem gesperrten Container innerhalb unserer VPC.

Hier ist der Arbeitsablauf, wie aus einer Benutzeranfrage eine sichere Codeausführung wird.

Bild 1: Arbeitsablauf der OpenCode-Ausführungsschleife

Das Sandbox-Problem: Umgang mit „The Hands“

Als wir zum ersten Mal versuchten, dies zu erstellen, haben wir die Komplexität der Ausführungsumgebung unterschätzt. Wenn Sie eine standardmäßige SaaS-Code-Interpreter-API verwenden, senden Sie Ihre Daten an sie. Wenn Sie es lokal ausführen, riskieren Sie, den Host zu gefährden.

Wir verwenden TrueFoundry Dienstleistungen um einen benutzerdefinierten „Code Execution Agent“ zu hosten. Dies ist im Wesentlichen ein Python-FastAPI-Dienst, der in einen Docker-Container eingebettet ist und Folgendes enthält:

• Eingeschränkter Netzwerkzugriff: Kein Internetzugang außer zu bestimmten internen PyPI-Spiegeln.
• Ressourcenbeschränkungen: Feste Obergrenzen für RAM und CPU (festgelegt über den Resource Toggle von TrueFoundry), um zu verhindern, dass While (true) -Schleifen den Knoten schmelzen.
• Kurzlebiger Speicher: Das Dateisystem wird nach jeder Anfrage gelöscht.

Da TrueFoundry das zugrunde liegende Kubernetes-Manifest verwaltet, können wir diese Sicherheitseinschränkungen (SecurityContext, NetworkPolicies) direkt über die Bereitstellungsoberfläche oder Terraform einfügen, um sicherzustellen, dass die Sandbox wirklich eine Sandbox ist.

Vergleich: Öffentliche und private Toolnutzung

Der Kompromiss war schon immer Bequemlichkeit und Kontrolle. Indem wir TrueFoundry nutzen, um das „OpenCode“ -Muster zu orchestrieren, verschieben wir das Gleichgewicht. Wir genießen den Komfort einer verwalteten Bereitstellung ohne das Datenrisiko.

Tabelle 1: Dies ist das Beispiel für einen Vergleich zwischen Gateway und Sandbox

Werkzeuggebrauch und der „Ah-ha“ -Moment

Die wahre Kraft entfaltet sich, wenn du kombinierst Verwendung des Tools mit Ihren internen APIs.

Wir haben das TrueFoundry LLM Gateway so konfiguriert, dass nicht nur das Tool „Python Interpreter“ verfügbar ist, sondern auch Tools für unseren internen Data Lake (z. B. get_user_churn_metrics (user_id)).

Da das LLM durch das Gateway leitet und das Gateway mit unseren privaten Diensten verbunden ist, kann das Modell jetzt:

1. Abfrage unsere interne SQL-Datenbank (über ein Tool).
2. Ziehen diese Daten in die Python-Sandbox.
3. Analysieren es verwendet das „OpenCode“ -Muster.
4. Rückkehr die Antwort an den Benutzer.

All dies geschieht, ohne dass ein einziges Byte an Kundendaten unser privates Subnetz verlässt.

Wir machen es bereit für die Produktion

Die Implementierung von „OpenCode“ ist nicht mehr nur ein lustiges Hackathon-Projekt, sondern eine Voraussetzung für moderne KI-Agenten. Aber du kannst es nicht einfach zusammen mit LangChain hacken und auf das Beste hoffen.

Wir behandeln unseren Code-Interpreter als kritische Infrastruktur. Wir überwachen es mithilfe des Observability-Stacks von TrueFoundry und verfolgen nicht nur die LLM-Token, sondern auch die CPU-Spitzen in der Sandbox und die Ausführungslatenz. Wenn ein Benutzer ein Skript schreibt, das versucht, 50 GB RAM zuzuweisen, beendet TrueFoundry den Pod, bevor er sich auf den Cluster auswirkt, und der Benutzer erhält eine höfliche Fehlermeldung.

Das ist der Unterschied zwischen einer Demo und einer Plattform.

‍