Copilot-Laufzeit im Prozess ausführen

Gründe für die Verwendung von In-Process-Hosting

Das In-Process-Hosting eignet sich gut, wenn:

• Ihre Anwendung muss ohne einen separaten Laufzeitprozess ausgeführt werden.
• Sie möchten, dass das SDK den Laufzeitlebenszyklus besitzt.
• Sie können eine systemeigene Bibliothek für jede Bereitstellungsplattform versenden.
• Prozessweite Umgebungs- und Arbeitsverzeichniseinstellungen sind akzeptabel.

Verwenden Sie autoTITLE , wenn die Prozessisolation und der etablierteste Bereitstellungspfad wichtiger sind. Verwenden Sie Einrichtung von Back-End-Diensten, wenn mehrere Anwendungsinstanzen sich über TCP mit einer gemeinsamen Laufzeit verbinden müssen.

So funktioniert es

Das SDK lädt die native Copilot-Laufzeitbibliothek und bindet deren feste C-ABI an. Alle SDK-Methoden verwenden weiterhin das vorhandene, mit Content-Length gerahmte JSON-RPC-Protokoll über eine In-Memory-Verbindung.

Die Laufzeit:

• Wird im Anwendungsprozess ohne Node.js, einen untergeordneten Prozess, einen TCP-Port oder ein Verbindungstoken ausgeführt.
• Unterstützt dieselben Sitzungen, Streamingereignisse, Tools, Hooks, Berechtigungen und Server-zu-Client-Anforderungen wie andere Transporte.
• Kann SDK-Rückrufe aus nativen Arbeitsthreads aufrufen. Das SDK übernimmt das Thread-Marshalling und die Lebensdauer von Callbacks.
• Hält die geladene native Bibliothek und deren Workerpool für die Lebensdauer des Anwendungsprozesses verfügbar.

SDK-Anforderungen

Alle SDKs machen eine explizite In-Process-Verbindungsoption verfügbar. Für einige Sprachen ist eine zusätzliche Build- oder Paketkonfiguration erforderlich.

Das native Laufzeitpaket muss mit dem Hostbetriebssystem, der CPU-Architektur sowie unter Linux auch mit der C-Bibliothek übereinstimmen. Nicht unterstützte Hosts schlagen während der Laufzeitauflösung oder beim Start fehl, anstatt auf einen untergeordneten Prozess zurückzukehren.

Eine prozessinterne Verbindung konfigurieren

Übergeben Sie die sprachspezifische Verbindungsoption, wenn Sie den Client erstellen.

import { CopilotClient, RuntimeConnection } from "@github/copilot-sdk";

const client = new CopilotClient({
  connection: RuntimeConnection.forInProcess(),
});

await client.start();

from copilot import CopilotClient, RuntimeConnection

client = CopilotClient(
    connection=RuntimeConnection.for_inprocess(),
)

await client.start()

client := copilot.NewClient(&copilot.ClientOptions{
    Connection: copilot.InProcessConnection{},
})

if err := client.Start(context.Background()); err != nil {
    log.Fatal(err)
}
defer client.Stop()

#pragma warning disable GHCP001

var client = new CopilotClient(new CopilotClientOptions
{
    Connection = RuntimeConnection.ForInProcess(),
});

await client.StartAsync();

let options = ClientOptions::default()
    .with_transport(Transport::InProcess);

let client = Client::start(options).await?;

import com.github.copilot.AllowCopilotExperimental;

@AllowCopilotExperimental
public class Example {
    public void run() throws Exception {
        CopilotClientOptions options = new CopilotClientOptions()
            .setConnection(RuntimeConnection.forInProcess());

        CopilotClient client = new CopilotClient(options);
        client.start().join();
    }
}

Sie können COPILOT_SDK_DEFAULT_CONNECTION=inprocess auch setzen, bevor Sie die Anwendung starten. Das SDK verwendet diesen Wert nur, wenn der Client keine explizite Verbindung angibt. Ein ungültiger Wert führt dazu, dass der Start fehlschlägt.

Bevorzugen Sie die explizite Clientkonfiguration im Anwendungscode. Verwenden Sie die Umgebungsvariable, wenn die Bereitstellungskonfiguration den Transport auswählen muss, ohne die Anwendung zu ändern.

Konfigurieren Sie die Runtime

Das SDK konvertiert unterstützte typierte Clientoptionen in systemeigene Laufzeitargumente und Hostbereichsumgebungswerte. Je nach SDK sind die folgenden Optionen enthalten:

• Authentifizierungstoken und Fallback für angemeldete Benutzer.
• Copilot Basisverzeichnis.
• Protokollierungsstufe.
• Leerlaufzeitlimit der Sitzung.
• Modus für Remotesitzungen.

Die In-Process-Laufzeit erhält eine Momentaufnahme der Hostumgebung sowie unterstützte, vom SDK verwaltete Überschreibungen. Die Hostumgebung wird nicht verändert.

Legen Sie prozessweite Werte fest, bevor Sie den ersten In-Process-Client erstellen. Dazu gehören Umgebungsvariablen, die nicht durch eingegebene Clientoptionen und das aktuelle Arbeitsverzeichnis der Anwendung dargestellt werden.

Auflösung der Laufzeitbibliothek

Jedes SDK sucht zunächst nach einer kompatiblen gebündelten oder zwischengespeicherten Laufzeitbibliothek. Sie können COPILOT_CLI_PATH so festlegen, dass es auf ein kompatibles Copilot-Laufzeitpaket verweist, wenn Sie die Laufzeit separat bereitstellen müssen.

In einem Prozess kann normalerweise nur ein systemeigener Laufzeitbibliothekspfad und eine systemeigene Version geladen werden. Das Starten eines anderen Clients mit derselben geladenen Bibliothek wird unterstützt, der Versuch, eine andere Laufzeitbibliothek zu laden, schlägt jedoch fehl.

Für Produktionsumgebungen:

1. Erstellen und testen Sie die Anwendung für jede Zielplattform.
2. Stellen Sie sicher, dass das übereinstimmende systemeigene Laufzeitartefakt im bereitgestellten Paket enthalten ist oder über den Laufzeitdownloadmechanismus des SDK verfügbar ist.
3. Starten Sie mindestens eine Sitzung und schließen Sie in einem Deployment-Smoke-Test mindestens einen Modelldurchlauf ab.
4. Beenden Sie Clients ordnungsgemäß, bevor die Anwendung beendet wird.

Lebenszyklusverhalten

Beim Starten eines in-Process-Clients wird die systemeigene Bibliothek geladen, ein Laufzeithost erstellt, eine In-Memory-Verbindung geöffnet und der normale Handshake der SDK-Protokollversion ausgeführt.

Während des geordneten Herunterfahrens führt das SDK Folgendes aus:

1. Schließt aktive Sitzungen.
2. Fordert das normale Herunterfahren der Laufzeit über JSON-RPC an.
3. Schließt die JSON-RPC- und systemeigenen Verbindungen.
4. Gibt den Laufzeithost frei.

Die systemeigene Bibliothek kann bis zum Beenden des Anwendungsprozesses geladen werden. Verlassen Sie sich nicht darauf, die Laufzeitbibliothek nach der ersten Verwendung zu entladen und zu ersetzen.

Einschränkungen

Das In-Process-Hosting weist die folgenden aktuellen Einschränkungen auf:

• Experimentelle API: Verhaltens- und Verpackungsanforderungen können sich zwischen Versionen ändern.
• Gemeinsamer Prozessstatus: Alle Clients teilen sich die Hostprozessumgebung, das aktuelle Arbeitsverzeichnis, die native Bibliothek und den Worker-Pool der Laufzeitumgebung.
• Eingeschränkte Prozessoptionen: SDK-Optionen für eine beliebige Umgebung, Arbeitsverzeichnis, Telemetriekonfiguration, ausführbarer Pfad oder CLI-Argumente werden ggf. abgelehnt. Konfigurieren Sie prozess-globale Werte für den Hostprozess, und verwenden Sie unterstützte typierte Optionen für Laufzeiteinstellungen.
• Kein Arbeitsverzeichnis pro Client: Die Laufzeit verwendet das Arbeitsverzeichnis des Hostingprozesses.
• Eine Laufzeitversion pro Prozess: Das Laden eines anderen systemeigenen Bibliothekspfads oder einer anderen Version wird nicht unterstützt.
• Die Plattformreife variiert: Einige SDK- und Plattformkombinationen weisen eine geringere Abdeckung bei Modellwechseln oder beim Herunterfahren auf. Überprüfen Sie die genaue Kombination, die Sie bereitstellen.

Weiterführende Lektüre

• Setup-Leitfäden: Vergleichen des In-Process-Hostings mit anderen Bereitstellungsmodellen
• Standardsetup (gebündelte CLI): Ausführen der gebündelten Laufzeit in einem verwalteten untergeordneten Prozess
• Einrichtung von Back-End-Diensten: Verbinden von Anwendungen mit einer freigegebenen Laufzeit über TCP
• Session Lifecycle Hooks: Sitzungsstart- und -endereignisse verarbeiten