Kontextverteilung im Standard-Testgerüst

Das Standard-Harness verteilt den Kontext über die Komponenten, die eine Anfrage verarbeiten. Jede Komponente arbeitet in ihrem eigenen Kontext, und das Harness gleicht die Kontexte auf oberster Ebene nicht automatisch ab. Diese Trennung bietet Flexibilität, kann aber zu doppelten Nachrichten oder verpassten Antworten führen, wenn Informationen nicht explizit von unabhängigen Komponenten zurückgegeben werden.

Dieser Artikel erklärt, warum der Kontext verteilt ist, wie sich das GitHub Copilot-Harness unterscheidet, wie der Kontext zwischen der Agenten-Orchestrierungsschicht und einer Komponente wechselt und was jede Komponente sehen und zurückgeben kann. Nutzen Sie diese Informationen, um Kontextlücken zu identifizieren und Agenten zu entwerfen, die den Kontext gezielt verwalten.

Das folgende Diagramm zeigt, wie Kontext und Kommunikation zwischen der Orchestrierungsschicht, den einzelnen Komponenten und dem Benutzer im Standard-Harness ablaufen.

Diagramm zeigt Kontext und Kommunikation, die zwischen der Orchestrierungsschicht, jeder Komponente und dem Benutzer in einem Standard-Harness-Agent übertragen werden.

Note

Dieser Artikel beschreibt die Funktionen und das Verhalten des Standard-Harness. Erfahren Sie, wie Sie auf Standardfunktionen in Zugriff auf Standard-Agenten und Agentenflüsse zugreifen.

Ein Grundgerüst bildet die Grundlage für alles, was mit Copilot Studio erstellt wird, und das ausgewählte Modell liefert Schlussfolgerungen und Generierung. Ein Harness ist eine Laufzeit, die zwischen beiden liegt: Sie bestimmt, wann das Modell aufgerufen wird, welche Komponenten an das Modell gesendet werden, interpretiert die Rückgaben und ruft die richtigen Werkzeuge auf. Erfahren Sie mehr darüber, wie Sie Copilot Studio nutzen.

Warum das Standard-Harness den Kontext verteilt

Der Standard-Kabelbaum ist auf Flexibilität ausgelegt:

  • Es orchestriert Aufgaben und unterstützt transaktionale Anwendungsfälle.
  • Es balanciert deterministische Steuerung und KI durch Variablen, Trigger und spezialisierte Funktionen.
  • Es verteilt die Kontrolle über Komponenten wie Themen, Wissen, Kinderagenten, verbundene Agenten und Werkzeuge.
  • Es unterstützt mehrere Authentifizierungs-, Kanal- und Integrationsoptionen.

Die Verteilung der Arbeit auf unabhängige Komponenten bietet Flexibilität, kann aber Lücken im Kontext schaffen:

  • Die Agenten-Orchestrierungsschicht gibt bei bestimmten Komponentenaufrufen die Steuerung ab.
  • Während eine Komponente läuft, kann die Orchestrierungsschicht die Nachrichten, die die Komponente an den Benutzer sendet, nicht sehen.
  • Die Orchestrierungsschicht gleicht den Kontext an der obersten Ebene nicht ab.

Wenn das Design den Kontext des Agenten nicht verwaltet, entstehen Lücken, und Anfragen können unbeantwortet erscheinen. Diese Lücken können zu doppelten oder verpassten Antworten führen.

Wie sich das GitHub Copilot-Harness unterscheidet

Die Orchestrierungsschicht des GitHub Copilot-Harnesss vermeidet die Kontextunstimmigkeit, indem sie der alleinige Kommunikator mit dem Nutzer ist. Es lässt niemals einen verbundenen Agenten die Kommunikation übernehmen:

  • Die Logik- und Kommunikationsschleife funktioniert ohne gezieltes Kontextmanagement.
  • Nachrichten der verbundenen Agenten passieren bei jeder Ecke die KI-Ebene des Elternteils.

Die Orchestrierungsschicht des GitHub Copilot-Harnesss behandelt ebenfalls die Kontextgröße anders, was den Kontext um Größenordnungen größer macht als der Standard-Harness:

  • Sie hat direkten Zugriff auf den Modellkontext.
  • Es kann Komprimierung nutzen.
  • Es kann Daten und Dateien in seinen Bash-Sandbox-Container schreiben.

Wie Kontext an Komponenten übergeben wird und zur Orchestrierungsschicht zurückkehrt

Um den Kontext im Standard-Harness effektiv zu verwalten, sollten Sie sowohl betrachten, was die Orchestrierungsschicht an eine Komponente weitergibt, als auch was die Komponente zurückgibt.

Kontext geht auf zwei Arten auf Komponenten über:

  • Explizite Eingaben und Anfragen: Die Orchestrierungsschicht füllt die Eingaben jeder Komponente aus ihrem aktiven Kontext aus und übermittelt eine Anfrage wie vorgesehen.

  • Impliziter Gesprächskontext: Die Orchestrierungsschicht übergibt außerdem einen längeren Gesprächskontext an Komponenten wie Wissen und an Subagenten, ohne explizite Konfiguration. Beachte, dass ein Child-Agent immer den Kontext des Elterngesprächs empfängt. Ein verbundener Agent hat eine Einstellung, die ihn einschließt oder ausschließt. Ein Werkzeug oder Fluss erhält nur seine Eingaben.

Eine Komponente sendet Informationen auf zwei Arten zurück an die Orchestrierungsschicht:

  • Explizite Ausgaben und Reaktionen wie vorgesehen.
  • Impliziter Kontext aus bestimmten Komponenten.

Was eine Komponente nur dem Benutzer zeigt oder nur ihre eigenen Variablen behält, erreicht möglicherweise nie die Orchestrierungsschicht, es sei denn, sie kommt über einen dieser beiden Kanäle zurück.

Das implizite Weitergeben von Informationen führt zu etwa der Hälfte der Fälle mit doppelten oder verpassten Antworten, da eine Komponente auf eine Anfrage reagieren kann, die ihr nie explizit übermittelt wurde.

Wie sich der Kontext zwischen den Komponenten unterscheidet

Die für den Benutzer sichtbare Unterhaltung und der Kontext der Orchestrierungsschicht überschneiden sich, sind aber nicht identisch. Die folgenden Prinzipien gelten für das, was aus einem Komponentenaufruf den Kontext der Orchestrierungsschicht erreicht:

  • Was eine Komponente für sich behält, bleibt verborgen. Themenvariablen und mehrteilige Dialoge innerhalb von Subagenten befinden sich in der Komponente. Die Orchestrierungsschicht sieht sie nur, wenn sie als Outputs zurückgegeben werden.

  • Nur zwei Arten von Informationen werden zurückgegeben. Die Orchestrierungsschicht erhält von einer Komponente die explizit entworfenen Ausgaben und den impliziten Kontext. Eine Komponente, die funktioniert, aber nichts zurückgibt, kann die Orchestrierungsschicht unwissend lassen, was passiert ist.

Jede Komponente hat ihren eigenen Kontext oder Standpunkt. Die Orchestrierungsschicht nutzt ihren aktiven Kontext, um Schritte auszuwählen und Eingaben zu generieren. Ein verbundener Agent hat seine eigene Orchestrierungsschicht, eigene Anweisungen sowie ein eigenes internes Werkzeug und Wissensaufrufe.

Verwenden Sie die folgende Tabelle, um eine präzise Frage zu stellen: Welche Komponente hat eine bestimmte Tatsache in ihrem aktiven Kontext?

Sichtweise Ist im aktiven Kontext vorhanden Kann in den Chatbereich schreiben Kann als Kontext zurückkehren
Orchestrierungsebene Benutzeranforderung, Gesprächskontext, Komponentenbeschreibungen, Eingabebeschreibungen, Ausgabebeschreibungen, Planzustand, implizite Antworten (aber nicht , ob die impliziten Informationen dem Nutzer gezeigt wurden) Ja. Eigene Fragen und Antworten. Eigene Fragen, Antworten, Begründungen und ein Plan.
Thema Topic-Variablen, aktueller Knotenzustand Ja. Über Nachrichtenknoten, Frageknoten und „Ask with Adaptive Card“. Themenausgaben und implizite Nachrichtenaustausche, die dennoch zu Doppelungen führen können.
Werkzeug oder Fluss Eingaben, die von der Orchestrierungsschicht generiert werden Nein. Werkzeug- oder Ablaufausgaben.
Wissens-Schritt Benutzeranfrage plus der aktive Kontext seines Agenten Nein. Er schreibt an seinen eigenen Agenten, nicht an den Chat-Bereich. Seine Antwort.
Generativer Antwortknoten (innerhalb eines Themas) Was in seiner Eingabe gesendet wird, plus der Kontext seines Agenten Ja. Direkt oder an eine Themenvariable. Nicht explizit, darf wiederholt werden.
Subagent (Kind oder verbundener Agent) Die ursprüngliche Anfrage sowie die von der übergeordneten Instanz bereitgestellten Eingaben und alle enthaltenen übergeordneten Kontexte im Kontext der eigenen Orchestrierungsebene Ja, wenn es konfiguriert oder angewiesen ist, direkt zu antworten. Eine Antwort und ihre Ausgabewerte.

Important

Themen: Impliziter Kontext, der von Themen zurückgegeben wird, enthält nur Klartextinformationen, aber nicht, ob der Nutzer sie gesehen hat. Klartextinformationen können von Nachrichtenknoten, Frageknoten, Inhalten der adaptiven Karte und von den vom Nutzer getippten Antworten stammen. Adaptive Card-Aktionsbuttons und Benutzerinteraktionen mit ihnen erreichen jedoch nicht den Standard-Gurt-Kontext. Adaptive Card Handling verursacht die meisten Kontextfehler. Verlasse dich nicht auf den Inhalt der Karten als Kontext. Stattdessen geben Sie alle Informationen zurück, die ein späterer Schritt als Themenausgabe benötigt, und setzen Sie eine beantwortete Zustandsausgabe. Erfahren Sie mehr unter Design-Themen als Mini-Agenten, die doppelte Nachrichten vermeiden.

Subagenten: Wenn der Elternkontext an einen verbundenen Agenten weitergegeben wird, kann dieser jedes Tool, Thema und jeden Wissensaufruf beeinflussen, den der Agent tätigt. Wenn der enthaltene Kontext immer noch eine Anfrage enthält, die scheinbar nicht beantwortet wurde, könnte der verbundene Agent versuchen, sie zu kompensieren und erneut zu beantworten. Ein Kinderagent birgt das gleiche Risiko mit weniger Kontrolle. Es läuft innerhalb des Elternteils und empfängt immer den Gesprächskontext des Elternteils, ohne eine Einstellung, ihn auszuschließen. Erfahren Sie mehr unter Design Subagents, die doppelte Nachrichten vermeiden.

Nächster Schritt

Mit diesem Kontextmodell im Hinterkopf erklärt der nächste Artikel dieser Reihe, warum dieses Modell doppelte Nachrichten verursacht, und schlägt Designmuster vor, um diese zu verhindern.

Entwickeln Sie Best Practices, um doppelte Nachrichten zu vermeiden

  • Last updated on