Best Practices für die Verwendung von Richtlinien für semantische Governance

Eine effektive Governance beruht auf genauen, klaren und vollständigen Beschreibungen der Tools und ihrer Parameter. Agentische Systeme, einschließlich der Agenten selbst und der Governance-Ebenen wie Richtlinien für semantische Governance, benötigen mehr Details als ein Mensch, um die Anwendbarkeit der verfügbaren Tools zu verstehen.

Toolbeschreibungen optimieren

Verwenden Sie klare Beschreibungen von MCP-Tools und von Parametern, die für diese Tools erforderlich sind.

• Unzureichende Toolbeschreibung: „Nach Artikeln suchen.“
• Effektive Tool-Beschreibung: „Durchsuchen Sie den Inhaltskatalog nach Keyword, Besetzung, Genre oder Format. Verwende diese Antwort, wenn der Nutzer wissen möchte, welche Filme oder TV-Sendungen verfügbar sind. Gibt die 10 wichtigsten Elemente zurück, sortiert nach Relevanz.“

Limits für Textzeilen beachten

Das System für semantische Governance erzwingt die folgenden Längenbeschränkungen für Beschreibungen:

Wenn die Semantic Governance-Laufzeit eine Beschreibung empfängt, die eines dieser Limits überschreitet, wird die Beschreibung auf das angegebene Limit gekürzt und eine Meldung protokolliert.

Wann die Richtlinie für semantische Governance greift

Die Richtlinie zur semantischen Governance dient speziell als Laufzeitsicherheitsprüfung für vorgeschlagene Tool-Aufrufe. Es werden keine Standarddialoge zwischen dem Nutzer und dem LLM des Agents während des Brainstormings, der Planung oder der Argumentation über mehrere Durchgänge hinweg abgefangen, blockiert oder geändert. Die Richtlinien-Engine fängt Anfragen nur dann ab und wertet sie aus, wenn das Modell vorschlägt, ein Tool aufzurufen, um eine Aktion auszuführen.

Szenario 1: Konversationelle Optimierung im Vergleich zur Tool-Ausführung (abgelehnter Tool-Aufruf)

Stellen Sie sich einen Agenten vor, der das Tool initiate_marketing_campaign hat und der folgenden Einschränkung unterliegt:

• Einschränkung:„Es ist nicht zulässig, Marketingkampagnen ohne ausdrückliche Genehmigung des Managers zu erstellen oder zu starten.“

1. Konversationsplanung: Ein Nutzer fragt den Agenten: „Hilf mir, eine Multi-Channel-Marketingkampagne für die Einführung unseres neuen Herbstprodukts zu entwerfen.“ Das LLM unterhält sich in mehreren Schritten frei mit dem Nutzer, umreißt Strategien, entwirft E‑Mail-Text und verfeinert die demografischen Zielgruppen. Die Richtlinien-Engine blockiert diese Antworten nicht, da das Modell keine Aktion vorschlägt, sondern sich auf die Konversationslogik konzentriert.

2. Tool-Aufruf: Wenn die Strategie fertig ist, sagt der Nutzer: „Sieht gut aus. Starte jetzt die Marketingkampagne.“ Das LLM antwortet mit einem vorgeschlagenen Toolaufruf:

   initiate_marketing_campaign(campaign_name="Fall Launch", budget=50000)
   

3. Richtlinienintervention und Ablehnung:Das Agent Gateway fängt diesen vorgeschlagenen Tool-Aufruf ab und leitet ihn an die Richtlinien-Engine weiter. Die Richtlinien-Engine bewertet die Aktion anhand der Einschränkung, stellt fest, dass im Sitzungsverlauf keine Genehmigung durch den Vorgesetzten vorhanden ist, und gibt das Ergebnis DENY aus. Der Tool-Aufruf wird blockiert, bevor er ausgeführt wird, und dem Agent wird eine strukturierte Begründung für die Ablehnung zurückgegeben.

Szenario 2: Konforme Tool-Ausführung (zulässiger Tool-Aufruf)

Berücksichtigen Sie denselben Marketing-Agenten, nachdem die entsprechende Genehmigung durch die Aufsichtsbehörde dokumentiert wurde:

1. Genehmigung erteilt: Der Nutzer gibt an: „Mein Vorgesetzter, der VP of Corporate Marketing (jordan@example.com), hat das Briefing geprüft und unser Budget von 50.000 $ für die Kampagne zum Herbst-Launch genehmigt. Bitte starte es.“

2. Tool-Aufruf:Das LLM schlägt vor, die Aktion aufzurufen:

   initiate_marketing_campaign(campaign_name="Fall Launch", budget=50000, approval="jordan@example.com")
   

3. Richtlinienauswertung und ‑genehmigung:Die Richtlinien-Engine fängt den Tool-Aufruf ab, prüft anhand des Konversationsverlaufs, ob die Genehmigung durch den Manager dokumentiert ist, und gibt ein ALLOW-Ergebnis aus. Das Agent Gateway leitet den Aufruf an den zugrunde liegenden Tool-Endpunkt weiter, sodass die Aktion normal ausgeführt werden kann.

Beispiele für effektive Einschränkungen

Eine gute Einschränkung beseitigt Unklarheiten, gibt genaue Grenzen (finanziell, zeitlich oder geografisch) an und verwendet eine Sprache, die zu den Tools passt, die der Agent verwendet.

IT-Cloud-Infrastruktur (Sicherheit und Kostenkontrolle)

• Szenario:Testumgebungen.
• Tool:provision_cloud_server (Parameter: region, instance_type, duration_hours).
• Tool-Beschreibung:Sendet eine Anfrage zum Bereitstellen eines Cloud-Servers in einer bestimmten Region mit einem bestimmten Instanztyp für einen bestimmten Zeitraum.
• Gültige Einschränkung:„Bereitstellung von Cloud-Servern nur in den Regionen ‚us-east‘ oder ‚eu-west‘ zulassen. Anfragen zum Bereitstellen von Instanztypen „gpu-large“ oder „gpu-xlarge“ ablehnen. Der Parameter „duration_hours“ darf maximal 72 Stunden betragen.“
• Warum das funktioniert:Die verwendete Sprache stimmt mit der Toolbeschreibung überein und es wird speziell auf die vom Tool akzeptierten Parameter verwiesen.

Kundenservice im E-Commerce (finanzielle Leitplanken)

• Szenario:Konto-Guthaben ausstellen
• Tool:apply_account_credit (Parameter: account_id, credit_amount, reason_category).
• Effektive Einschränkung:„Kontogutschriften auf maximal 50 $ pro Interaktion begrenzen. Wende keine Gutschriften an, wenn die reason_category „shipping_delay“ ist und das ursprüngliche Bestelldatum weniger als 5 Tage zurückliegt.“
• Warum das funktioniert:Es wird ein strenger Dollar-Schwellenwert festgelegt und mit einer logischen Bedingung kombiniert, die auf Zeit und Kategorie basiert.

Beispiele für ineffektive Einschränkungen

Eine schlechte Einschränkung ist in der Regel vage, verwendet subjektive Sprache oder lässt sich nicht direkt auf Beschreibungen von Tools oder Toolparametern beziehen.

IT-Cloud-Infrastruktur (subjektiv)

• Ineffective Constraint (Ineffektive Einschränkung): „Make sure not to create servers that are too expensive. Halte die Dauer auf einem angemessenen Niveau.“
• Warum das nicht funktioniert:Ein LLM erzielt bessere Ergebnisse mit konkreten Zahlen (z. B. „Limit von 50 $“) als mit abstrakten Konzepten wie „angemessen“ oder „teuer“.

Kundenservice (falsche Terminologie)

• Ineffektive Einschränkung:„Gib verärgerten Käufern außerhalb der regulären Öffnungszeiten kein Geld zurück.“
• Warum das nicht funktioniert: „Give money back“ (Geld zurückgeben) entspricht nicht den Tool-Parametern (refund_amount). „Angry shoppers“ (Verärgerte Käufer) ist subjektiv und „business hours“ (Geschäftszeiten) ist ohne Zeitzone nicht definiert.

Hinweise zur Sprache

Beachten Sie beim Erstellen von Einschränkungen die folgenden Richtlinien:

• Verwenden Sie eine einfache, menschliche Sprache:Verwenden Sie vollständige Sätze im Aussagesatz oder im Imperativ (z. B. „Sie dürfen nicht zulassen…“ oder „Nicht zulassen…“).
• Vermeiden Sie schwache Formulierungen wie „Ich denke, es ist am besten, wenn…“ oder „Versuche, … zu vermeiden“. Die Formulierung ist für den LLM-Judge wichtig.
• Konkret sein: Geben Sie Einschränkungen mit direkt angegebenen Limits an, z. B. „1.000 $“ oder „8:00 bis 16:00 Uhr EST“. Verwenden Sie eine Formulierung, die mit den Beschreibungen von Tools und Parametern übereinstimmt.
• Widersprüche vermeiden:Achten Sie darauf, dass sich die Einschränkungen für den Agent- und den Tool-Bereich nicht widersprechen (z. B. unterschiedliche Dollar-Grenzwerte).

Einschränkungen testen:Sie können Ihre Einschränkungen in natürlicher Sprache im Probelaufmodus testen. Dabei werden Richtlinien ausgewertet, ohne sie zu erzwingen.

Nächste Schritte

• Weitere Informationen zum Verwalten von Skills finden Sie unter Agent-Skills verwalten.
• Informationen zum Binden von Richtlinien an den Gateway-Ausgang finden Sie unter Autorisierung an Richtlinien für die semantische Governance delegieren.
• Konfigurieren Sie Richtlinien unter Richtlinien für die semantische Governance konfigurieren.