Hosted-Agent-Infrastruktur

Gehostete Agent-Infrastruktur

Gehostete Agenten laufen in entfernten Sandbox-Umgebungen und nicht auf lokalen Maschinen. Bei gutem Design bieten sie unbegrenzte Parallelität, konsistente Ausführungsumgebungen und Multiplayer-Kollaboration. Die entscheidende Erkenntnis ist, dass die Sitzungsgeschwindigkeit nur durch die Zeit des Modellanbieters bis zum ersten Token begrenzt werden sollte, wobei die gesamte Infrastruktur eingerichtet ist, bevor der Benutzer seine Sitzung startet.

Wann zu aktivieren

Aktivieren Sie diesen Skill, wenn:

• Hintergrund-Codierungsagenten gebaut werden, die unabhängig von Benutzergeräten laufen
• Sandbox-Ausführungsumgebungen für Agent-Workloads entworfen werden
• Multiplayer-Agent-Sitzungen mit gemeinsamem Zustand implementiert werden
• Multi-Client-Agent-Schnittstellen (Slack, Web, Chrome-Erweiterungen) erstellt werden
• Agent-Infrastruktur über lokale Maschinengrenzen hinaus skaliert wird
• Systeme gebaut werden, in denen Agenten Unter-Agenten für parallele Arbeit erzeugen

Aktivieren Sie diesen Skill nicht für angrenzende Arbeiten, die von anderen Skills abgedeckt werden:

• Entwurf der autonomen Forschungsschleife, Neuheitsfilter, Rollback-Richtlinie oder Merge-Grenzen: harness-engineering.
• Auswahl von Supervisor-, Schwarm- oder Übergabe-Topologie ohne gehostete Infrastrukturbelange: multi-agent-patterns.
• Entwurf der von einem gehosteten Agenten verwendeten Tools, wie z.B. Spawn/Status-Tools oder PR-Tools: tool-design.
• Verwaltung des dateibasierten Zustands innerhalb einer Sitzung und nicht der gehosteten Laufzeit selbst: filesystem-context.

Kernkonzepte

Verlagern Sie die Agent-Ausführung in entfernte Sandbox-Umgebungen, um die grundlegenden Grenzen der lokalen Ausführung zu beseitigen: Ressourcenkonflikte, Umgebungsinkonsistenzen und Einzelbenutzer-Einschränkungen. Remote-Sandboxen ermöglichen unbegrenzte Parallelität, reproduzierbare Umgebungen und kollaborative Workflows, da jede Sitzung ihren eigenen isolierten Rechenbereich mit einem bekannten, funktionierenden Umgebungsimage erhält.

Entwerfen Sie die Architektur in drei Schichten, da jede Schicht unabhängig skaliert. Bauen Sie Sandbox-Infrastruktur für isolierte Ausführung, eine API-Schicht für Zustandsverwaltung und Client-Koordination sowie Client-Schnittstellen für die Benutzerinteraktion auf verschiedenen Plattformen. Halten Sie diese Schichten sauber getrennt, so dass Sandbox-Änderungen nicht auf die Clients durchschlagen.

Detaillierte Themen

Sandbox-Infrastruktur

Die Kernherausforderung Beseitigen Sie die Startlatenz der Sandbox, da Benutzer alles über ein paar Sekunden als defekt wahrnehmen. Entwicklungsumgebungen erfordern das Klonen von Repositories, das Installieren von Abhängigkeiten und das Ausführen von Build-Schritten – tun Sie all dies, bevor der Benutzer jemals eine Eingabeaufforderung sendet.

Image-Registry-Muster Erstellen Sie vorab Umgebungsimages in einem regelmäßigen Rhythmus (alle 30 Minuten funktioniert gut), da dies die Synchronisation mit dem neuesten Code zu einem schnellen Delta statt einem vollständigen Klon macht. Fügen Sie in jedes Image ein:

• Geklontes Repository bei einem bekannten Commit
• Alle Laufzeitabhängigkeiten installiert
• Erste Setup- und Build-Befehle abgeschlossen
• Zwischengespeicherte Dateien aus einmaligem Ausführen der App und der Test Suite

Starten Sie beim Beginn einer Sitzung eine Sandbox aus dem aktuellsten Image. Das Repository ist höchstens 30 Minuten veraltet, was die verbleibende Git-Synchronisation schnell macht.

Snapshot und Wiederherstellung Erstellen Sie Dateisystem-Snapshots an wichtigen Punkten, um eine sofortige Wiederherstellung für Folgeaufforderungen ohne erneutes Ausführen des Setups zu ermöglichen:

• Nach dem ersten Image-Build (Basis-Snapshot)
• Wenn der Agent Änderungen abgeschlossen hat (Sitzungs-Snapshot)
• Vor dem Verlassen der Sandbox für potenzielle Nachverfolgung

Git-Konfiguration für Hintergrund-Agenten Konfigurieren Sie die Git-Identität explizit in jeder Sandbox, da Hintergrund-Agenten während des Image-Builds nicht an einen bestimmten Benutzer gebunden sind:

• Generieren Sie GitHub-App-Installationstokens für den Repository-Zugriff während des Klonens
• Setzen Sie die Git-Konfiguration user.name und user.email beim Committen und Pushen von Änderungen
• Verwenden Sie die Identität des auffordernden Benutzers für Commits, nicht die App-Identität

Warm-Pool-Strategie Halten Sie einen Pool von vorgewärmten Sandboxes für stark frequentierte Repositories bereit, da Kaltstarts die Hauptquelle für Benutzerfrustration sind:

• Halten Sie Sandboxes bereit, bevor Benutzer Sitzungen starten
• Lassen Sie Pooleinträge ablaufen und neu erstellen, wenn neue Image-Builds abgeschlossen sind
• Beginnen Sie mit dem Aufwärmen einer Sandbox, sobald ein Benutzer zu tippen beginnt (vorausschauendes Aufwärmen)

Agent-Framework-Auswahl

Server-zentrierte Architektur Strukturieren Sie das Agent-Framework zuerst als Server, mit TUI und Desktop-Apps als dünne Clients, da dies das Duplizieren von Agent-Logik über Oberflächen hinweg verhindert:

• Mehrere benutzerdefinierte Clients teilen sich ein Agent-Backend
• Konsistentes Verhalten über alle Interaktionsoberflächen hinweg
• Plugin-Systeme erweitern die Funktionalität ohne Client-Änderungen
• Ereignisgesteuerte Architekturen liefern Echtzeit-Updates an jeden verbundenen Client

Code als Quelle der Wahrheit Wählen Sie Frameworks, in denen der Agent seinen eigenen Quellcode lesen kann, um das Verhalten zu verstehen. Priorisieren Sie dies, da Code als Quelle der Wahrheit verhindert, dass der Agent über seine eigenen Fähigkeiten halluziniert – ein unterschätzter Fehlermodus in der KI-Entwicklung.

Plugin-System-Anforderungen Fordern Sie ein Plugin-System, das Laufzeit-Interception unterstützt, da dies Sicherheitskontrollen und Beobachtbarkeit ermöglicht, ohne die Kern-Agent-Logik zu ändern:

• Hören Sie auf Tool-Ausführungsereignisse (z.B. tool.execute.before)
• Blockieren oder ändern Sie Tool-Aufrufe bedingt
• Injizieren Sie Kontext oder Zustand zur Laufzeit

Geschwindigkeitsoptimierungen

Vorausschauendes Aufwärmen Beginnen Sie mit dem Aufwärmen der Sandbox, sobald ein Benutzer seine Eingabe tippt, nicht erst, wenn er sie abschickt, da das Tippintervall (5-30 Sekunden) ausreicht, um die meisten Einrichtungen abzuschließen:

• Klonen Sie die neuesten Änderungen parallel zum Tippen des Benutzers
• Führen Sie das anfängliche Setup aus, bevor der Benutzer die Eingabetaste drückt
• Für schnelles Hochfahren kann die Sandbox bereit sein, bevor der Benutzer mit dem Tippen fertig ist

Paralleles Dateilesen Erlauben Sie dem Agenten, sofort mit dem Lesen von Dateien zu beginnen, auch wenn die Synchronisation vom neuesten Basis-Branch noch nicht abgeschlossen ist, da in großen Repositories eingehende Aufforderungen selten kürzlich geänderte Dateien betreffen:

• Der Agent kann sofort recherchieren, ohne auf die Git-Synchronisation zu warten
• Blockieren Sie Dateibearbeitungen (nicht Lesevorgänge), bis die Synchronisation abgeschlossen ist
• Diese Trennung ist sicher, da die Veralterung der Lesedaten von 30 Minuten für die Recherche selten eine Rolle spielt

Maximieren der Arbeit zur Build-Zeit Verlagern Sie alles Mögliche in den Image-Build-Schritt, da die Dauer der Build-Zeit für den Benutzer unsichtbar ist:

• Vollständige Abhängigkeitsinstallation
• Datenbankschema-Setup
• Erste App- und Test-Suite-Läufe (füllt Caches)

Selbst-erzeugende Agenten

Von Agenten erzeugte Sitzungen Bauen Sie Tools, die es Agenten ermöglichen, neue Sitzungen zu erzeugen, da Grenzmodelle in der Lage sind, Arbeit zu zerlegen und Unteraufgaben zu koordinieren:

• Rechercheaufgaben in verschiedenen Repositories
• Parallele Ausführung von Unteraufgaben für große Änderungen
• Mehrere kleinere PRs aus einer großen Aufgabe

Stellen Sie drei Primitive bereit: Starten einer neuen Sitzung mit festgelegten Parametern, Auslesen des Status jeder Sitzung (Check-in-Fähigkeit) und Fortsetzen der Hauptarbeit, während Unter-Sitzungen parallel laufen.

Prompt Engineering für Selbst-erzeugung Entwickeln Sie Prompts, die leiten, wann Agenten Unter-Sitzungen erzeugen sollten, anstatt die Arbeit inline zu erledigen:

• Rechercheaufgaben, die eine repositoryübergreifende Erkundung erfordern
• Aufteilung monolithischer Änderungen in kleinere PRs
• Parallele Erkundung verschiedener Ansätze

API-Schicht

Zustandsisolation pro Sitzung Isolieren Sie den Zustand pro Sitzung (SQLite pro Sitzung funktioniert gut), da sitzungsübergreifende Störungen ein subtiler und schwer zu debuggender Fehlermodus sind:

• Dedizierte Datenbank pro Sitzung
• Keine Sitzung kann die Leistung einer anderen beeinträchtigen
• Architektur bewältigt Hunderte von gleichzeitigen Sitzungen

Echtzeit-Streaming Streamen Sie alle Agent-Arbeiten in Echtzeit, da hochfrequentes Feedback entscheidend für das Benutzervertrauen ist:

• Token-Streaming von Modellanbietern
• Statusaktualisierungen der Tool-Ausführung
• Dateiänderungsbenachrichtigungen

Verwenden Sie WebSocket-Verbindungen mit Hibernation-APIs, um die Rechenkosten in Leerlaufzeiten zu senken, während die Verbindungen offen bleiben.

Synchronisation über Clients hinweg Bauen Sie ein einheitliches Zustandssystem, das sich über alle Clients synchronisiert (Chat-Schnittstellen, Slack-Bots, Chrome-Erweiterungen, Webschnittstellen, VS Code-Instanzen), da Benutzer häufig die Oberfläche wechseln und Kontinuität erwarten. Alle Änderungen werden mit dem Sitzungszustand synchronisiert, was einen nahtlosen Client-Wechsel ermöglicht.

Multiplayer-Unterstützung

Warum Multiplayer wichtig ist Entwerfen Sie von Anfang an für Multiplayer, da es mit der richtigen Synchronisationsarchitektur nahezu kostenlos hinzuzufügen ist und hochwertige Workflows freischaltet:

• Nicht-Ingenieuren den effektiven Einsatz von KI beibringen
• Live-QA-Sitzungen mit mehreren Teammitgliedern
• Echtzeit-PR-Review mit sofortigen Änderungen
• Kollaborative Debugging-Sitzungen

Implementierungsanforderungen Bauen Sie das Datenmodell so, dass Sitzungen nicht an einzelne Autoren gebunden sind, da Multiplayer stillschweigend fehlschlägt, wenn die Autorenschaft hart codiert ist:

• Übergeben Sie Autoreninformationen an jede Aufforderung
• Weisen Sie Codeänderungen dem auffordernden Benutzer zu
• Teilen Sie Sitzungslinks für sofortige Zusammenarbeit

Authentifizierung und Autorisierung

Benutzerbasierte Commits Verwenden Sie die GitHub-Authentifizierung, um PRs im Namen des Benutzers (nicht der App) zu öffnen, da dies den Prüfpfad bewahrt und verhindert, dass Benutzer ihre eigenen KI-generierten Änderungen genehmigen:

• Besorgen Sie Benutzer-Tokens für die PR-Erstellung
• PRs erscheinen als vom Menschen verfasst, nicht vom Bot

Sandbox-zu-API-Ablauf Befolgen Sie diese Sequenz, da sie die Sandbox-Berechtigungen minimal hält, während die API sensible Vorgänge übernimmt:

1. Die Sandbox pusht Änderungen (aktualisiert die Git-Benutzerkonfiguration)
2. Die Sandbox sendet ein Ereignis an die API mit dem Branchnamen und der Sitzungs-ID
3. Die API verwendet das GitHub-Token des Benutzers, um den PR zu erstellen
4. GitHub-Webhooks benachrichtigen die API über PR-Ereignisse

Client-Implementierungen

Slack-Integration Priorisieren Sie Slack als ersten Verteilungskanal für die interne Einführung, da es eine Viralschleife erzeugt, wenn Teammitglieder andere bei der Nutzung sehen:

• Keine Syntax erforderlich, natürliche Chat-Schnittstelle
• Bauen Sie einen Klassifikator (schnelles Modell mit Repository-Beschreibungen), um zu bestimmen, in welchem Repository gearbeitet werden soll
• Fügen Sie Hinweise für häufige Repositories hinzu; erlauben Sie "unbekannt" für mehrdeutige Fälle

Web-Schnittstelle Bauen Sie eine Web-Schnittstelle mit diesen Funktionen, da sie als primäre Power-User-Oberfläche dient:

• Echtzeit-Streaming der Agent-Arbeit auf Desktop und Mobilgeräten
• Gehostete VS Code-Instanz, die in der Sandbox läuft
• Gestreamte Desktop-Ansicht zur visuellen Überprüfung
• Vorher/Nachher-Screenshots für PRs
• Statistikseite: Sitzungen, die zu gemergten PRs führen (primäre Metrik), Nutzung im Zeitverlauf, Live-Anzahl "menschen, die auffordern"

Chrome-Erweiterung Bauen Sie eine Chrome-Erweiterung für nicht-technische Benutzer, da die Extraktion von DOM- und React-Interna eine höhere Präzision als rohe Screenshots bei niedrigeren Tokens-Kosten bietet:

• Sidebar-Chat-Schnittstelle mit Screenshot-Tool
• Extrahieren Sie DOM/React-Interna anstelle von rohen Bildern
• Verteilen Sie über die verwaltete Geräte-Richtlinie (umgeht den Chrome Web Store)

Praktische Anleitung

Checkliste für das Design gehosteter Agenten

Bevor Sie das System bauen, legen Sie diese Infrastruktureigenschaften explizit fest:

1. Sandbox-Lebenszyklus: wie Sitzungen starten, Snapshots erstellen, wiederherstellen, auslaufen und beendet werden.
2. Image- und Warm-Pool-Richtlinie: wie oft Images neu gebaut werden, welche Caches vorberechnet werden und wann warme Sandboxes auslaufen.
3. Lese-/Schreib-Synchronisation: ob Agenten vor Abschluss der Repository-Synchronisation lesen dürfen und welche Ereignisse Schreibvorgänge freigeben.
4. Zustandsisolation pro Sitzung: welcher Speicher zu einer Sitzung gehört, was gemeinsam genutzt wird und wie sitzungsübergreifende Störungen verhindert werden.
5. Auth und Commit-Identität: welche Operationen App-Tokens verwenden, welche Benutzer-Tokens und wie Commits attribuiert werden.
6. Ausgabeextraktion: wie Branches, PRs, Dateien, Logs, Screenshots und Sitzungszusammenfassungen die Sandbox verlassen.
7. Budget und Abbau: maximale Laufzeit, Kostenobergrenzen, Leerlaufrichtlinie und erzwungenes Aufräumverhalten.

Behandlung von Folgeaufforderungen

Wählen Sie zwischen Warteschlangen- und Einfügen von Folgeaufforderungen, die während der Ausführung gesendet werden. Bevorzugen Sie Warteschlangen, da dies einfacher zu verwalten ist und Benutzern ermöglicht, Gedanken zu nächsten Schritten zu senden, während der Agent arbeitet. Bauen Sie einen Mechanismus, um den Agenten bei Bedarf mitten in der Ausführung zu stoppen, da sich Benutzer sonst gefangen fühlen.

Metriken, die zählen

Verfolgen Sie diese Metriken, da sie echten Wert anzeigen und nicht nur Eitelkeitsnutzung:

• Sitzungen, die zu gemergten PRs führen (primäre Erfolgsmetrik)
• Zeit vom Sitzungsstart bis zur ersten Modellantwort
• PR-Genehmigungsrate und Anzahl der Überarbeitungen
• Prozentsatz des vom Agenten geschriebenen Codes über Repositories hinweg

Einführungsstrategie

Treiben Sie die interne Einführung durch Sichtbarkeit voran, nicht durch Anordnungen, da erzwungene Nutzung Groll erzeugt:

• Arbeiten Sie in öffentlichen Räumen (Slack-Kanäle) für Sichtbarkeit
• Lassen Sie das Produkt Viralschleifen erzeugen
• Erzwingen Sie nicht die Nutzung gegenüber bestehenden Tools
• Bauen Sie nach den Bedürfnissen der Menschen, nicht nach hypothetischen Anforderungen

Beispiele

Beispiel 1: Lebenszyklus einer Hintergrund-Codierungssitzung

Benutzereingabe
-> API weist warme Sandbox aus aktuellen Image zu
-> Sandbox synchronisiert das neueste Branch-Delta
-> Lesen sofort erlaubt, Schreiben blockiert bis Sync abgeschlossen
-> Agent bearbeitet und testet im isolierten Arbeitsbereich
-> Sandbox erstellt finalen Dateisystem-Snapshot
-> Branch wird gepusht
-> API erstellt PR mit Benutzer-Token
-> Sitzungszusammenfassung, Logs und PR-URL werden an Clients zurückgegeben

Diese Sequenz hält die Einrichtungsarbeit außerhalb des sichtbaren Benutzerpfads, während sie die Prüfbarkeit und das Eigentum des Benutzers an Codeänderungen bewahrt.

Beispiel 2: Grenzentscheidung

Wenn die Aufgabe "die Agentenschleife tagelang mit gesperrten Rubriken und PR-Genehmigung laufen lassen" ist, verwenden Sie harness-engineering. Wenn die Aufgabe "diese Schleife in Remote-Sandboxes mit Warmpools, Sitzungs-Snapshots, Streaming-Clients und benutzerverfassten PRs ausführen" ist, verwenden Sie diesen Skill.

Richtlinien

1. Erstellen Sie Umgebungsimages in regelmäßigen Abständen vor (30 Minuten ist ein guter Standard)
2. Beginnen Sie mit dem Aufwärmen der Sandboxes, wenn Benutzer mit dem Tippen beginnen, nicht wenn sie abschicken
3. Erlauben Sie Dateilesen vor Abschluss der Git-Synchronisation; blockieren Sie nur Schreibvorgänge
4. Strukturieren Sie das Agent-Framework als Server-zentriert mit Clients als dünne Wrapper
5. Isolieren Sie den Zustand pro Sitzung, um sitzungsübergreifende Störungen zu verhindern
6. Weisen Sie Commits dem Benutzer zu, der die Aufforderung gegeben hat, nicht der App
7. Verfolgen Sie gemergte PRs als primäre Erfolgsmetrik
8. Bauen Sie von Anfang an für Multiplayer; es ist mit der richtigen Synch-Architektur nahezu kostenlos

Fallstricke

1. Kaltstart-Latenz: Das erste Hochfahren der Sandbox dauert 30-60s und Benutzer nehmen dies als defekt wahr. Verwenden Sie Warmpools und vorausschauendes Aufwärmen, um dies zu vermeiden.
2. Sitzungsinterferenz: Wenn der Zustand nicht pro Sitzung isoliert ist, können Aktionen in einer Sitzung andere Sitzungen beschädigen, was zu schwer reproduzierbaren Fehlern führt.
3. Commit-Attribution: Wenn nicht explizit festgelegt, werden Commits als vom System stammend angezeigt, was die Prüfbarkeit bricht und es Benutzern ermöglicht, ihre eigenen Änderungen zu genehmigen.
4. Client-Inkonsistenz: Wenn die Synchronisation nicht korrekt implementiert ist, sehen Benutzer auf verschiedenen Clients unterschiedliche Sitzungszustände, was Vertrauensverlust verursacht.
5. Image-Staleness: Wenn Images zu selten neu erstellt werden, arbeiten Agenten mit veraltetem Code, was zu Konflikten und verschwendeter Arbeit führt.

Fazit

Erfolgreiche gehostete Agent-Infrastruktur eliminiert die Reibung der lokalen Entwicklung, ohne die Einschränkungen der Remote-Ausführung dem Benutzer aufzubürden. Die Schlüsselprinzipien sind: Baue alles Mögliche vor, warme Sandboxen bevor Benutzer sie brauchen, halte den Zustand isoliert und schreibe Berechtigungen so zu, dass die Verantwortlichkeit erhalten bleibt. Wenn es richtig gemacht wird, können Benutzer mit mehreren Agenten interagieren, die in verschiedenen Repositories über verschiedene Oberflächen hinweg arbeiten, mit nahtloser Sitzungskontinuität und klarer Eigentümerschaft an Änderungen.