Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
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.
Doppelte Nachrichten entstehen aus Kontextlücken. Das Agentendesign muss in jedem Schritt den Kontext berücksichtigen.
Ein Subagent, entweder ein Kindagent oder ein verbundener Agent, läuft auf einer eigenen Orchestrierungsschicht innerhalb des Plans eines Elternagenten. Es erhält eine Anfrage vom Elternteil und erfüllt die Aufgabe. Der Subagent erzeugt drei Arten von Ausgaben: Inhalte, die er dem Benutzer zeigt, Werte, die er über definierte Ausgaben zurückgibt, und eine implizite Antwort, die er an den anrufenden Agenten sendet. Der Elternteil kann den Austausch des Subagents mit dem Benutzer nicht sehen und erfährt das Ergebnis nur über die definierten Ausgaben und die implizite Antwort. Diese eingeschränkte Sichtbarkeit führt häufig zu doppelten Nachrichten und verpassten Antworten.
Tip
Für Hinweise, wann die Arbeit zwischen Agenten aufgeteilt werden sollte, und allgemeine Best Practices für mehrere Agenten, konsultieren Sie Multi-agenten-Orchestrierungsmuster sowie Best Practices sowie Multi-Agenten-Muster. Dieser Artikel erklärt, wie Eingaben und Ausgaben die Antwort eines Subagenten mit dem Kontext des Elternagenten in Einklang bringen.
Dieser Artikel baut auf dem in Context Distribution in the Standard Harness beschriebenen Kontextmodell und den Designentscheidungen in Design Best Practices auf, um doppelte Nachrichten zu vermeiden.
Schalte den Elternkontext für einen verbundenen Agenten aus
Ein Subagent, der den Gesprächskontext des Elternteils empfängt, kann darauf reagieren. Wenn dieser Kontext eine Anfrage enthält, die der Elternteil noch nicht beantwortet hat, könnte der Subagent darauf antworten, etwas wiederholen, das der Elternteil bereits erledigt hat, oder die falsche Rolle übernehmen. Diese Aktionen verursachen häufig doppelte Nachrichten.
Ein verbundener Agent hat eine Einstellung, Übermittelt die Konversationshistorie an diesen Agenten, die steuert, ob er den Gesprächskontext des Elternteils empfängt. Diese Einstellung ist standardmäßig aktiviert. Deaktiviere es, sodass der verbundene Agent nur aus den Eingaben funktioniert, die der Elternteil sendet, nicht aus der gesamten Konversation.
Ein Kinderagent hat kein entsprechendes Setting. Es läuft innerhalb des Elternteils und empfängt immer den Kontext des Gesprächs des Elternteils.
Für verbundene Agenten, die den Kontext für die ihnen zugewiesenen Aufgaben beibehalten müssen, und für untergeordnete Agenten, die standardmäßig über Kontext verfügen, verwenden Sie eine Eingabe zur Bereichsbegrenzung, um den Bereich des Unteragenten zu schützen.
Verwenden Sie eine Scoping-Eingabe
Manchmal benötigt ein Subagent den Kontext des Elternagenten, um seine Aufgaben zu erfüllen. Wenn du diesen Kontext übergibst, füge eine Eingabe zur Eingrenzung hinzu – sie teilt dem Subagenten genau mit, woran er arbeiten soll, damit noch offene, unbeantwortete Anfragen im Kontext ihn nicht von seiner Aufgabe ablenken. Wenn du den Kontext nicht übergibst, brauchst du keinen Scoping-Input, weil der Subagent nur die Anfrage hat, die der Elternteil an ihn weitergeleitet hat.
Um den Geltungsbereich des Subagenten zu schützen, fügen Sie eine Eingabe namens scopedRequest mit einer Beschreibung wie zum Beispiel The specific request this agent should fulfill hinzu. Die Orchestrierungsschicht füllt die Eingabe, wenn sie den Subagent aufruft. Der Elternagent identifiziert den relevanten Teil der Anfrage und übergibt nur diesen Teil, selbst wenn sein Kontext eine weitere unbeantwortete Anfrage enthält.
Ein Scoping-Input ist ein robustes Design, selbst wenn du den Elternkontext nicht behältst. Die Eingabe gibt dem Hersteller mehr Kontrolle über den Inhalt der Anfrage, die an den Subagent gesendet wird.
Verankern Sie die Anweisungen des Subagenten an diese Eingabe, sodass sie von der scoped Request aus funktioniert und alles andere, was einer Anfangsanfrage ähnelt, ignoriert.
Beispielanweisungen für Subagenten:
Fulfill the request in the scopedRequest input.
Treat it as your initial request and ignore any other initial requests in the conversation.
Konfigurieren von Eingaben und Ausgaben
Eingaben und Ausgaben sind der Vertrag zwischen dem Elternteil und dem Subagenten. Die Eingabe definiert, woran der Subagent arbeitet, und die Ausgaben teilen dem Elternteil mit, was passiert ist, damit es den Rest der Unterhaltung orchestrieren kann. Der Elternteil kann den Austausch des Subagenten mit dem Nutzer nicht sehen, daher ist dieser Vertrag das einzige verlässliche Signal, das er hat.
Important
Ein Subagent, der keine Ausgaben zurückgibt, ist ein Warnsignal. Ohne Ausgaben hat die übergeordnete Instanz keine Aufzeichnung davon, was der Unteragent geantwortet hat oder was noch offen ist. Es kann eine Antwort wiederholen, die der Subagent bereits gegeben hat, oder den Teil der Anfrage fallen lassen, den der Subagent nicht bearbeitet hat.
Konfigurieren Sie die folgenden Eingaben und Ausgaben und schreiben Sie jeweils eine Beschreibung, damit die übergeordnete Orchestrierungsebene sie lesen kann:
| Eingabe oder Ausgabe | Description | So verwenden Sie |
|---|---|---|
scopedRequest (Eingabe) |
Die konkrete Anforderung, die dieser Agent erfüllen sollte. | Der Elternteil füllt sie nur mit dem relevanten Teil der Anfrage des Nutzers aus. Sie schützt den Subagent davor, die falsche Frage zu beantworten, wenn der Kontext des Elternteils noch andere, unbeantwortete Anfragen enthält. Verankern Sie die Anweisungen des Subagenten an diese Eingabe. |
answered (Ausgabe) |
Das stimmt, wenn der Nutzer bereits eine Antwort auf die scopedRequest erhalten hat. | Setze es bei jedem Subagenten, egal ob er dem Nutzer Nachrichten schreibt oder still bleibt. Die oberste Anweisung, die als Nächstes gezeigt wird, liest sie vor, damit der Elternteil nicht erneut auf dieselbe Anfrage antwortet. |
scopedRequest (Ausgabe) |
Die Anfrage, die dieser Agent bearbeitet hat. | Wiederhole die scoped-Anfrage, sodass sie die oberste Orchestrierungsschicht erreicht, die die erzeugten Eingaben nicht zuverlässig in seinem eigenen Kontext speichert. Bei Dialogzügen mit mehreren Intentionen, die mehr als einen Subagenten erfordern, ermöglicht diese Fähigkeit der obersten Ebene, korrekt zu planen und zu vermeiden, dass der falsche Subagent der falschen Anfrage zugeordnet wird. |
interactionSummary (Ausgabe) |
Eine kurze Zusammenfassung der Antwort, die dem Nutzer gegeben wurde. | Gib sie zurück, wenn der Subagent direkt an den Nutzer schreibt, damit der Elternteil weiß, was kommuniziert wurde, und es nicht wiederholt. |
findings (Ausgabe) |
Die Antwort auf die scopedRequest, die der Elternteil an den Benutzer liefern soll. | Gib sie zurück, wenn der Subagent still bleibt, damit der Elternteil den Inhalt zum Ausliefern hat. |
openQuestions (Ausgabe) |
Jeder Teil der Anfrage des Nutzers, der unbeantwortet bleibt. | Lassen Sie es von jedem Unteragenten zurückgeben, der nur einen Teil der Anforderung erfüllen kann oder in dessen Unterhaltung eine neue Anforderung aufgetaucht ist, damit der übergeordnete Agent den verbleibenden Teil erledigen und die Tool-Verkettung fortsetzen kann. Der Subagent sollte nicht raten, welcher Agent den Rest betreut. |
Wählen Sie aus, welche Komponente mit dem Nutzer kommuniziert
Entscheide, ob der übergeordnete Agent oder der Subagent mit dem Nutzer kommuniziert. In den meisten Fällen sollte der Elternagent mit dem Benutzer kommunizieren, damit er die Ergebnisse zu einer Antwort kombinieren kann. Lassen Sie den Subagent direkt kommunizieren, wenn er eine lange Antwort geben oder ein Gespräch über mehrere Runden führen muss. Gib genügend Informationen zurück, damit der Elternteil den Rest des Gesprächs mit Kontext bewältigen kann.
Welche Komponente auch immer kommuniziert, füge eine oberste Anweisung hinzu, damit die Orchestrierungsschicht die Ausgaben jedes Subagents prüft, bevor sie antwortet.
Diese Beispielanweisung auf oberster Ebene funktioniert in jedem Fall, egal ob ein Subagent direkt Nachrichten an den Benutzer schreibt oder schweigt. Bearbeite und passe es nach Bedarf an.
Wann immer ein Thema oder Agent angerufen wird, suche immer nach dem 'beantworteten' booleschen Output, bevor du entscheidest, was du antwortest. Themen und Agenten haben ihren eigenen Kommunikationskanal mit dem Nutzer. Wenn 'beantwortet' wahr ist, gehen Sie immer davon aus, dass die Anfrage angemessen mit mindestens einer der Ausgabevariablen beantwortet wurde, und prüfen Sie anhand der Ausgabebeschreibung, welche. Geben Sie keine unangenehme Anerkennung des beantworteten Inhalts. Gib nur die unbeantworteten Ausgaben an und führe das Gespräch beim nächsten Schritt natürlich fort.
Der Begriff Kanal bezieht sich nicht auf einen Integrationskanal. Es handelt sich um ein Prompting-Gerät, das der Orchestrierungsschicht mitteilt, dass der Nutzer die Antwort möglicherweise schon über eine andere Komponente gesehen hat.
Schreibe die Beschreibung des Subagenten für die übergeordnete Orchestrierungsebene, damit klar ist, wann der Subagent verwendet werden soll und wie seine Ausgaben zu lesen sind. Beispiel:
Handles payroll questions.
If its answered output is true, the user has already received their response and it should not be answered again.
Konfiguriere für jeden Unteragenten Ausgaben für Antwortstatus und Wert, unabhängig davon, ob der Unteragent eine Nachricht an den Benutzer sendet oder stumm bleibt, und gib dem übergeordneten Agenten eine Anweisung, sie auszulesen. Mit diesem Ansatz kann ein Agent stille Subagenten und Subagenten mischen, die direkt Nachrichten an den Benutzer senden, wobei sie sich nur durch ihre Ausgaben unterscheiden. Erfahren Sie mehr unter Design einer robusten obersten Anweisung, um wiederholte Nachrichten zu vermeiden.
Delegiere die Benutzerkommunikation an den Elternteil
Überlegen Sie, alle Benutzerkommunikation über den Elternagenten statt über einen Unteragenten zu leiten. Sammle alle Eingaben, die der Subagent benötigt, bevor er startet, lies, was er nach Abschluss als Ausgabe erzeugt hat, und weise ihn an, den Benutzer nicht direkt zu kontaktieren. Ein Subagent, der nie an den Nutzer schreibt, kann etwas nicht beantworten, was der Elternteil bereits beantwortet hat.
Sagen Sie dem Subagenten, er soll schweigen und seine Ergebnisse zurückgeben. Beispiel:
Do NOT reply or communicate with the user directly.
Only fulfill the scopedRequest provided in the input and respond with the result.
Ein stummer Subagent liefert findings und openQuestions zurück, die beide in Configure inputs and outputs beschrieben werden, um seine Antwort an den übergeordneten Agenten zu übergeben und verbleibende Arbeit zu kennzeichnen.
Gib eine openQuestions Ausgabe zurück. Es ermöglicht der Orchestrierungsschicht, den Rest der Anfrage des Nutzers abzuschließen und die Tool-Chaining fortzusetzen, wenn ein Subagent nur einen Teil der Forderung erfüllen kann.
Um den Subagenten schweigend zu halten, ist eine explizite Anweisung erforderlich. Standardmäßig kann ein Subagent dem Benutzer während der Ausführung eigenständig Nachrichten schicken. Die Einstellung "After Running Completion verhindert" diese Nachrichten nicht, weil sie dem Elternteil nur sagt, was zu tun ist, wenn der Subagent fertig ist.
Note
Dem Elternagenten zu sagen: "Du bist der einzige Agent, der mit dem Nutzer spricht", funktioniert nicht. Der Elternagent kann einen laufenden Subagent nicht stoppen, und der Subagent kann dem Benutzer weiterhin eigenständig Nachrichten schicken. Stattdessen weist man den Subagenten an, still zu bleiben, und test dann, um es zu bestätigen.
Einige Subagenten müssen direkt kommunizieren
Ein Subagent, der direkt Nachrichten an den Benutzer sendet, ist eine gültige Wahl, kein Verstoß gegen eine Regel, erfordert aber ein bewusstes Design, um wiederholte Nachrichten vom Elternteil zu vermeiden.
In manchen Anwendungsfällen muss der Subagent direkt auf den Nutzer antworten, entweder um eine lange Antwort zu geben, ohne sie in den übergeordneten Kontext zu kopieren, oder um ein Gespräch zu führen. Um wiederholte Nachrichten und verlorenen Kontext zu vermeiden, geben Sie den Kontext in den Ausgaben an die Elternseite über.
Lass den Unteragenten eine ausführliche Antwort geben und eine Zusammenfassung zurückgeben.
Der Subagent liefert seine vollständige Antwort direkt an den Nutzer und gibt nur eine kurze Zusammenfassung oder eine Notiz zurück, dass er die Antwort geliefert hat. Verwenden Sie diesen Ansatz für lange Antworten, wie detaillierte Analysen, und beschränken Sie die zurückgegebenen Informationen auf den Kontext des Elternteils. Das Ziel ist, den Elternkontext klein, aber informiert zu halten.
Gib answered und interactionSummary zurück, die beide in Eingaben und Ausgaben konfigurieren beschrieben werden.
Lass den Subagent ein Gespräch mit dem Nutzer führen
Der Subagent tauscht mehrere Nachrichten mit dem Benutzer in mehreren Schritten aus, um die scoped-Anfrage abzuschließen. Das Hauptrisiko besteht darin, dass der Elternteil nichts von den zwischenführenden Gesprächsschritten, der Arbeit des Subagenten, gegebenen Antworten oder neuen Anfragen weiß. Dadurch kann der Elternteil auf neue Anfragen reagieren oder in späteren Schritten nicht korrekt reagieren.
Geben Sie scopedRequest, interactionSummary und answered zurück, wie in Ein- und Ausgänge konfigurieren beschrieben.
Die oberste Anweisung behandelt auch diesen Anwendungsfall.
Verwandte Informationen
- Kontextverteilung im Standard-Harness
- Entwickeln Sie Best Practices, um doppelte Nachrichten zu vermeiden
- Gestalten Sie Themen als Mini-Agenten, die doppelte Nachrichten vermeiden
- Fehlerbeseitigung von doppelten Nachrichten und verpassten Antworten
- Entdecken Sie Muster der Multi-Agenten-Orchestrierung
- Generative Orchestrierungsfähigkeiten anwenden
- Aufbau von Agent-Lösungen: Grundsätze und Muster