ari20089/connected-agent-handoff-boundaries

Grenzen der Verbundenen-Agenten-Übergabe

Microsofts Anleitungen zur Übergabe in Microsoft Copilot Studio sind auf drei Seiten verteilt: Agent-zu-Agent Delegation, Übergabe an einen Live-Agenten und Employee Self-Service Agent Übergabe. Eine vierte Seite definiert die Entscheidungsebenen für die Aktionen eines einzelnen Agenten. Keine Seite sagt, wer welche Art von Aktion an welche Art von Agent delegieren darf, oder stellt an einem Ort dar, was die Übergabe überlebt. Diese Skill verwandelt die dokumentierten Mechanismen in ein Entscheidungs-Grenzmuster pro Aktionstyp. Sie ist beratend: Ändern Sie niemals Agents, Einstellungen, Richtlinien oder Anmeldeinformationen.

Vorbereitung

Bestimmen Sie Folgendes, bevor Sie fortfahren. Falls der Benutzer diese nicht bereitgestellt hat, fragen Sie nach den fehlenden.

1. Harness oder Produkt — Standard, Microsoft Copilot (ehemals GitHub Copilot) oder Customer Conversation Harness in Copilot Studio, oder der Employee Self-Service Agent in Microsoft Copilot. Das Verhalten unterscheidet sich je nach Harness (siehe Schritt 1); falls der Benutzer es nicht weiß, fragen Sie, wie der Agent erstellt wurde, und sagen Sie, welche Sie angenommen haben.
2. Delegierte — jeder Agent oder jede Person, an die das Design übergibt, und wie: untergeordneter Agent, verbundener Copilot Studio Agent, externer Agent (A2A, Foundry, Agents SDK, Fabric Data Agent, Agent aus dem Drittanbieter-Store), Live-Agent über eine Engagement-Hub, oder Themen-Weiterleitung.
3. Aktionsinventar — die Tools, Flows und Themen, die jeder Agent erreichen kann, mit Authentifizierung jedes Tools (Endbenutzer- oder Ersteller-basiert) und ob Endbenutzer vor Ausführung fragen aktiviert ist. Falls unbekannt, klassifizieren Sie anhand der Toolnamen und markieren Sie die Klassifizierung als vorläufig.
4. Delegierer — ob der übergeordnete Agent von Benutzern im Chat, von einem Ereignis oder geplanten Trigger, oder von beidem erreicht wird.
5. Gewünschtes Artefakt — Boundary-Matrix (Standard), Anweisungsblöcke, Übergabevertrag, Überprüfungs-Checkliste, Mietvertrag (Tenant) Testplan oder eine Designüberprüfung des gesamten Satzes.
6. Dokumentationsdatum — falls Sie Webzugriff haben, überprüfen Sie die Microsoft Learn-Seiten im Quellenverzeichnis der Anleitung, vergleichen Sie das ms.date jeder Seite mit dem aufgeführten Datum und sagen Sie, was sich geändert hat. Andernfalls sagen Sie, dass Sie sich auf die Daten in dieser Liste verlassen (zuletzt gelesen am 5. November 2026).
7. Mieterbeobachtungen — alle Ergebnisse, die der Benutzer bereits aus Tests T1 bis T10 hat. Melden Sie diese als im Tenant beobachtet, getrennt von dokumentiert und nicht dokumentiert, mit Tenant-Typ und Datum.

Ausgabestruktur

Erstellen Sie in dieser Reihenfolge:

1. Übergabekarte — eine Zeile pro Delegiertem: Delegierer, Mechanismus, Harness, Delegierter.
2. Dokumentierte Fakten, die zutreffen — Aufzählungspunkte mit der Microsoft Learn-Seite und ihrem Datum, unter Verwendung des Anleitungs-Wortlauts, abdeckend, was jeder Mechanismus übergibt, was er zurückgibt und die Einstellungen, die eine davon ändern.
3. Im Tenant beobachtet — nur, wenn der Benutzer Ergebnisse geliefert hat; andernfalls die Überschrift weglassen.
4. Boundary-Matrix — die Tabelle aus Abschnitt 6.4 der Anleitung, eine Zeile pro Delegiertem, mit dem höchsten Aktionstyp (A1 bis A6) und jeder Zelle ausgefüllt oder als unbekannt markiert.
5. Grenzverletzungen — jede Stelle, an der das Design eine der sieben Regeln in Abschnitt 6.3 bricht, mit der Regelnummer und der Behebung.
6. Offene Fragen, die zutreffen — die relevanten Zeilen aus Q1 bis Q10.
7. Annahmen — eine Zeile, die Standardwerte auflistet, die Sie angewendet haben (Harness, Klassifizierung, Artefakt, Datum). Weglassen, wenn der Benutzer alles geliefert hat.
8. Das angeforderte Artefakt — erstellt aus dem entsprechenden Abschnitt der Anleitung (Schritt 5).
9. Empfehlung — eine klare Position, ob das Design bereit ist, und die Bedingungen, die zuerst erfüllt sein müssen.
10. Quellen und Daten — eine Zeile, die die verwendeten Seiten und deren Daten benennt, plus den Vorschau-Status der verwendeten Mechanismen.

Verwenden Sie Tabellen für die Karte, Matrix und den Testplan, nummerierte Listen für Checklisten und umschlossene Blöcke für jeden Anweisungs- oder Beschreibungstext, den der Benutzer in Copilot Studio einfügen wird.

Schritt 1: Identifizieren Sie den Harness und die Mechanismen

Lesen Sie references/handoff-guide.md Abschnitte 1 und 2. Klären Sie zuerst den Harness: dasselbe Wort bedeutet verschiedene Dinge.

Benutzer sagt	Bedeutet auf	Achten Sie auf
"Child Agent"	Standard Harness	Erhält immer den übergeordneten Kontext; keine Einstellung, um dies auszuschließen
"Sub-Agent"	Customer Conversation Harness (oder lose, jeder Unter-Agent)	Teilt Konfiguration, Bereitstellung und ALM mit dem primären Agenten
"Connected Agent"	Jeder Harness	Standard: History-Umschalter, gleiche Umgebung, eine Ebene. Microsoft Copilot Harness: Der übergeordnete Agent ist der einzige Kommunikator; keine History-Einstellung benannt (Q3). Customer Conversation: nur Microsoft Foundry Agents.
"A2A Agent", "Foundry Agent"	Standard oder Microsoft Copilot Harness	Extern: Microsoft legt die Verantwortung für Datenflüsse und Genehmigungen auf den Ersteller
"An einen Menschen übergeben", "eskalieren"	Standard Harness oder Customer Conversation Eskalationspfade	Standard: Vollständige History und alle benutzerdefinierten Themenvariablen gehen an den Hub. Customer Conversation: Nutzlast nicht dokumentiert.
"Agent-Übergabe", "Hub-Agent"	Employee Self-Service Agent in Microsoft Copilot	Übergabe übergibt History und die ursprüngliche Eingabeaufforderung, kann Umgebungen überschreiten und kann auf Drittanbieter-Agents abzielen

Wenn der Benutzer Harnesses in einem Design mischt, behandeln Sie jede Delegationskante separat.

Schritt 2: Stellen Sie fest, was jede Übergabe überquert

Geben Sie für jeden Delegierten aus Anleitungsabschnitt 3 an, was er empfängt, was er zurückgibt und was verloren geht: umformulierte Anfragen, Zitate, eigene Nachrichten eines Unter-Agenten, Adaptive Card Aktionen und Zugriff. Verwenden Sie Microsofts Wortlaut. Wo die Anleitung nicht dokumentiert sagt, sagen Sie dies; füllen Sie die Lücke nicht aus dem Verhalten eines anderen Harnesses.

Schritt 3: Klassifizieren Sie Aktionen und legen Sie die Ebene fest, auf der sie ausgeführt werden

Klassifizieren Sie jeden Delegierten nach dem höchsten Aktionstyp unter den Tools, die er erreichen kann (Anleitungsabschnitt 6.1, A1 bis A6). Ordnen Sie jeden Typ Microsofts drei Ebenen zu (Anleitungsabschnitt 5): keine Bestätigung, Bestätigung im Gespräch, Offline-Genehmigung. Die Ebene gehört dem Agenten, der das Tool besitzt. Lesen Sie Anleitungsabschnitt 4, wo Bestätigung und Anmeldeinformationen festgelegt werden, und kennzeichnen Sie jedes Delegierten-Tool auf A2 bis A5, das vom Ersteller bereitgestellte Anmeldeinformationen verwendet. Zählen Sie MCP-Server-Tools als Tools.

Schritt 4: Prüfen Sie, wer was an wen delegieren darf

Wenden Sie Anleitungsabschnitt 6.2 (die Delegationstabelle und die Regel für autonome Delegierer) und die sieben Regeln in Abschnitt 6.3 an. Listen Sie jede Verletzung mit ihrer Regelnummer und einer konkreten Behebung in Copilot Studio Begrifflichkeiten auf, wobei Sie die Einstellung, den Knoten oder die Eingabe benennen.

Schritt 5: Erstellen Sie das Artefakt

Artefakt	Anleitungsabschnitt	Inhalt
Boundary-Matrix	6.4	Eine Zeile pro Delegiertem, jede Spalte ausgefüllt oder unbekannt
Anweisungsblöcke	7	Übergeordnete-, Untergeordnete- und Beschreibungsblöcke, Namen angepasst, Microsofts Zeilen wörtlich beibehalten, Grenzzeilen markiert
Übergabevertrag	8	Eingaben und Ausgaben pro Delegiertem, mit Beschreibungen für den Orchestrator
Überprüfungs-Checkliste	11	Die zehn Prüfungen, jede mit bestanden, nicht bestanden oder unbekannt für dieses Design markiert
Mietvertrag (Tenant) Testplan	10	Die Tests, die auf die Harnesses und Delegierten des Benutzers zutreffen; bereits durchgeführte Tests streichen und ihre Ergebnisse in "Im Tenant beobachtet" einfließen lassen
Designüberprüfung	6.4, 6.3, 11	Matrix, Verletzungen, Checkliste und Empfehlung zusammen

Jedes Artefakt trägt das Dokumentationsdatum und den Vorschau-Status der von ihm abgedeckten Mechanismen.

Schritt 6: Empfehlen Sie, dann aufhören

Geben Sie eine klare Position: bereit, bereit mit aufgeführten Korrekturen oder nicht bereit. Ein Design ist nicht bereit, wenn eine A5-Aktion durch generative Weiterleitung erreichbar ist, wenn ein Delegierten-Tool auf A2 bis A5 vom Ersteller bereitgestellte Anmeldeinformationen ohne dokumentierte Ausnahme verwendet (ein autonomer Delegierer benötigt immer eine, da Trigger mit den Anmeldeinformationen des Erstellers laufen; Anleitungsabschnitte 4 und 6.2), oder wenn ein externer Delegierter Chat-Verlauf ohne dokumentierte Datenweitergabe-Entscheidung erhält. Bieten Sie nicht an, die Agents zu ändern.

Regeln

• Sagen Sie niemals, dass die Bestätigung, Anmeldeinformationen oder Datenrichtlinie eines übergeordneten Agenten für die Tools eines Delegierten gilt. Microsoft dokumentiert diese pro Tool, in dem Agenten, der das Tool besitzt.
• Sagen Sie niemals, dass ein verbundener Agent nur die Aufgabe erhält, es sei denn, der Benutzer hat bestätigt, dass Conversation history an diesen Agenten übergeben bei einem Standard-Harness-Agenten deaktiviert ist. Standardmäßig wird der Verlauf übergeben.
• Nennen Sie niemals eine History-Einstellung, eine Delegationstiefe, einen Admin-Block für Agentenverbindungen oder eine Benutzer-Token-Durchleitung, wo die Anleitung nicht dokumentiert sagt. Antworten Sie "nicht dokumentiert zum Stand " und nennen Sie den Test, der dies feststellen würde. Verneinen Sie es auch nicht: Die FAQ sagt, Sie "können konfigurieren, ob der vollständige Gesprächsverlauf übergeben wird" an externe Agents, obwohl keine Seite die Einstellung benennt (Anleitung Q3; Test T6).
• Präsentieren Sie niemals die Aktionstypen, Delegationstabelle, sieben Regeln, actionsTaken Ausgabe oder boundary Anweisungszeilen als Microsoft-Anleitung. Sie sind das Muster dieser Skill, das auf Microsofts Fakten aufsetzt; kennzeichnen Sie sie.
• Halten Sie immer drei Klassen von Fakten getrennt: dokumentiert (Seite und Datum), im Tenant beobachtet (wessen Test, wann) und nicht dokumentiert.
• Zitieren Sie immer Microsofts Wortlaut aus der Anleitung oder einem Live-Abruf der zitierten Seite, nicht aus dem Gedächtnis.
• Lösen Sie immer den Konflikt "nur der Agent, der mit dem Benutzer spricht" (Q6) zugunsten der Sub-Agenten-Seite, auf die die Muster-Seite jetzt verweist: Weisen Sie den Sub-Agenten an, still zu sein; verlassen Sie sich nicht auf eine Nur-Übergeordneter Anweisung.
• Verwenden Sie immer Microsofts aktuelle Namen: Standard Harness; Microsoft Copilot Harness (umbenannt vom GitHub Copilot Harness am 28. Oktober 2026; Learn und das Produkt zeigen möglicherweise noch den alten Namen; behalten Sie den alten Namen in Learn-Seitentiteln und Zitaten bei; "ein Microsoft Copilot Studio Authoring- und Orchestrierungs-Framework, nicht der GitHub Copilot Dienst"; ein Copilot Studio Harness, nicht das Microsoft Copilot Produkt); Customer Conversation Harness, dessen Spezialisten Unteragenten sind; Microsoft Foundry (nicht Azure AI Foundry); Agent2Agent (A2A); Microsoft 365 Agents SDK; Engagement Hub; und, für den Employee Self-Service Agenten, Microsoft Copilot und Copilot Chat, wie es auf dessen Seiten heißt.
• Halten Sie immer die Namen von Tenant, Agent, Benutzer und Kunden, die der Benutzer weitergibt, aus wiederverwendbaren Beispielen und einfügefertigen Blöcken heraus.
• Wenn das Design keine Delegation hat, sagen Sie, dass diese Skill das falsche Werkzeug ist, und verweisen Sie auf die Ebenen in Abschnitt 5 der Anleitung für einen einzelnen Agenten.

Beispiele

Eingabe: "Unser IT-Helpdesk Agent (Standard-Harness) leitet an einen verbundenen Facility-Agenten in derselben Umgebung und an einen A2A-Agenten eines Anbieters weiter, der Hardware-Bestellungen stornieren kann. Benutzer chatten über Microsoft Teams mit ihm. Welche Grenzen brauchen wir?"

Ausgabe (gekürzt):

Übergabekarte: Helpdesk → Facilities (verbundener Copilot Studio Agent, Standard); Helpdesk → Anbieterbestellungen (A2A, Standard). Dokumentierte Fakten: Facilities empfängt den Gesprächsverlauf, es sei denn, Conversation history an diesen Agenten übergeben ist deaktiviert; es ist "standardmäßig aktiviert" (Sub-Agenten entwerfen, 4. Nov. 2026). Die A2A-Beispielnutzlast enthält "Den vollständigen Chat-Verlauf, nicht nur die letzte Benutzereingabe" (A2A, 26. Aug. 2026). Für externe Agents "sind Sie für die Nutzung solcher Agents verantwortlich" (gleiche Seite). Bestätigung ist pro Tool: Endbenutzer vor Ausführung fragen "ist standardmäßig auf Nein gesetzt" (Tools hinzufügen, 1. Okt. 2026). Boundary-Matrix: Facilities, A3 (erstellt Arbeitsaufträge), generative Weiterleitung, Verlauf an (unbekannt warum), Endbenutzer-Anmeldeinformationen, keine Bestätigung, keine Ausgaben: verstößt gegen Regel 4. Anbieterbestellungen, A5 (storniert Bestellungen), generative Weiterleitung, voller Chat-Verlauf, OAuth 2.0-Verbindung, keine Bestätigung: verstößt gegen die Regeln 1, 3 und 5. Verstöße und Korrekturen:

• Regel 5: Entfernen Sie den Anbieter-Agenten aus der generativen Weiterleitung. Erreichen Sie ihn nur über ein Thema "Bestellung stornieren" mit einem Bestätigungsknoten und einer Weiterleitung, unter Übergabe einer scopedRequest, die nur die Bestellnummer enthält.
• Regel 3: Dokumentieren Sie eine Datenweitergabe-Entscheidung mit dem Anbieter, die den Chat-Verlauf abdeckt, oder verbinden Sie den Agenten nicht.
• Regel 4: Fügen Sie Facilities die Ausgaben answered, findings, openQuestions und actionsTaken hinzu und deaktivieren Sie den Verlaufsumschalter. Offene Fragen: Q1, Q4, Q5. Empfehlung: nicht bereit. Facilities nach der Korrektur von Regel 4 ausliefern; die Anbieterverbindung zurückhalten, bis das Weiterleitungsthema existiert und die Datenweitergabe-Entscheidung unterzeichnet ist. Quellen und Daten: Multi-Agent-Muster (4. Nov. 2026); Verbindung zu einem bestehenden Copilot Studio Agenten herstellen (30. Okt. 2026); A2A (26. Aug. 2026); Sub-Agenten entwerfen (4. Nov. 2026); Tools hinzufügen (1. Okt. 2026). "Andere Agents hinzufügen" im Standard-Harness ist Vorschau-Dokumentation.

Referenzen

• references/handoff-guide.md — wo Microsofts Anleitung lebt (Abschnitt 1); Mechanismen nach Harness (2); was jede Übergabe überquert, wörtlich (3); wo Anmeldeinformationen und Bestätigung festgelegt werden (4); Microsofts Entscheidungsebenen (5); das Grenzmuster dieser Skill: Aktionstypen, Delegationstabelle, sieben Regeln, Matrix-Vorlage (6); einfügefertige Anweisungsblöcke (7); Übergabevertrag (8); offene Fragen Q1 bis Q10 (9); Mietvertragstests T1 bis T10 (10); Überprüfungs-Checkliste (11); worauf zu achten ist (12); alle Quellen mit Daten. Lesen Sie es, bevor Sie antworten; lesen Sie den in Schritt 5 genannten Abschnitt, bevor Sie ein Artefakt erstellen.