Hooks¶
Unter diesem Thema wird beschrieben, wie Sie Hooks verwenden, um benutzerdefinierten Code an Schlüsselpunkten im Lebenszyklus des Agenten auszuführen. Mit Hooks können Sie Tool-Aufrufe abfangen, das Verhalten von Agenten überprüfen, Richtlinien durchsetzen, Kontext einfügen und den Ausführungsablauf kontrollieren.
Funktionsweise von Hooks¶
Hooks folgen einem vierstufigen Prozess: Es wird ein Ereignis ausgelöst, das SDK prüft, ob ein Matcher zutrifft, ruft Ihren Callback auf, und Ihr Callback gibt eine Entscheidung zurück, die steuert, was als Nächstes passiert.
Der Agent löst ein Ereignis aus (z. B. wenn er dabei ist, ein Tool aufzurufen).
Das SDK überprüft jeden Hook-Matcher, der für diesen Ereignistyp registriert ist.
Wenn ein Matcher übereinstimmt (oder kein Matcher-Muster hat, d. h. er stimmt mit allem überein), ruft das SDK die zugehörigen Callback-Funktionen auf.
Jeder Callback gibt ein Ausgabeobjekt zurück, das die Operation zulassen, blockieren oder ändern kann.
Hook-Ereignisse¶
Die folgenden Ereignisse sind verfügbar:
Ereignis |
Wenn es ausgelöst wird |
|---|---|
|
Bevor ein Tool ausgeführt wird. Kann das Tool blockieren oder seine Eingabe ändern. |
|
Nachdem ein Tool erfolgreich ausgeführt wurde. Kann zusätzlichen Kontext einfügen. |
|
Nachdem die Ausführung eines Tools fehlgeschlagen ist. |
|
Wenn der Benutzer eine Aufforderung sendet. Kann zusätzlichen Kontext einfügen. |
|
Wenn der Agent kurz davor ist, anzuhalten. Kann Kontext einfügen oder die Sitzung anhalten. |
|
Wenn ein Subagent startet. |
|
Wenn ein Subagent kurz davor ist, anzuhalten. |
|
Bevor die Konversation komprimiert wird (zusammengefasst, um in das Kontextfenster zu passen). |
|
Wenn der Agent eine Benachrichtigung ausgibt. |
|
Wenn eine Tool-Berechtigungsprüfung stattfindet. |
Konfigurieren von -Hooks¶
Führen Sie die Hooks durch der hooks-Option beim Erstellen einer Sitzung. Jedes Hook-Ereignis wird einer Liste von Matchern zugeordnet und jeder Matcher enthält eine Liste von Callback-Funktionen.
Matcher¶
Jeder Hook-Matcher hat drei Felder:
Feld |
Typ |
Beschreibung |
|---|---|---|
|
|
Ein Regex-Muster, das von Ereignissen verwendet wird, die Abgleiche unterstützen. |
|
Liste der Callbacks |
Eine oder mehrere Callback-Funktionen, die ausgeführt werden, wenn der Matcher übereinstimmt. |
|
|
Maximale Zeit in Sekunden für alle Callbacks in diesem Matcher. Der Standardwert ist 60. |
Das matcher-Feld akzeptiert jedes gültige Regex-Muster. Beispiel:
"Bash"– gleicht nur mit dem Bash-Tool ab"Write|Edit"– gleicht mit „Schreiben“ oder „Bearbeiten“ ab".*"– gleicht mit allen Tools ab (wie das Weglassen des Matchers)
Callback-Eingaben¶
Jeder Callback erhält drei Argumente:
Argument |
Beschreibung |
|---|---|
|
Ein Objekt, das ereignisspezifische Daten enthält. Alle Ereignisse enthalten |
|
Die Toolverwendungs-ID (für Tool-bezogene Ereignisse) oder |
|
Ein Kontextobjekt. Reserviert für zukünftige Verwendung (z. B. Abbruchsignale). |
Die Eingabefelder variieren je nach Ereignis:
Ereignis |
Zusätzliche Eingabefelder |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Tool-Lebenszyklus-Hooks und PermissionRequest können optional auch agent_id und``agent_type``-Felder enthalten, wenn sie von einem Subagenten ausgelöst werden.
Callback-Ausgaben¶
Callbacks geben ein Ausgabeobjekt zurück, das die Ausführung steuert. Die folgenden Felder sind verfügbar:
Feld |
Typ |
Beschreibung |
|---|---|---|
|
|
Gibt an, ob die Verarbeitung fortgesetzt werden soll. Setzen Sie auf |
|
|
Meldung, die angezeigt wird, wenn |
|
|
Setzen Sie auf |
|
|
Feedback-Meldung an den Agenten über die Entscheidung. |
|
|
Warnmeldung, die dem Benutzer angezeigt wird. |
|
|
Ereignisspezifische Steuerelemente (siehe unten). |
Bemerkung
Das Python-SDK verwendet continue_ (mit einem nachstehenden Unterstrich) anstelle von continue, um den Python-Schlüsselwortkonflikt zu vermeiden. Das SDK wandelt dies automatisch in continue bei der Kommunikation mit CLI um.
Hook-spezifische Ausgaben¶
Das hookSpecificOutput-Feld akzeptiert ereignisspezifische Steuerelemente:
PreToolUse
Feld |
Beschreibung |
|---|---|
|
|
|
Grund für die Entscheidung über die Berechtigung. |
|
Geänderte Tool-Eingabe, anstelle der ursprünglichen zu verwenden. |
PostToolUse
Feld |
Beschreibung |
|---|---|
|
Zusätzlicher Kontext, der nach der Ausführung des Tools in die Konversation eingefügt wird. |
UserPromptSubmit
Feld |
Beschreibung |
|---|---|
|
Zusätzlicher Kontext, der in die Konversation eingefügt wird. |
PermissionRequest
Feld |
Beschreibung |
|---|---|
|
|
|
Meldung, die angezeigt wird, wenn die Berechtigungsanfrage abgelehnt wird. |
Beispiele¶
Gefährliche Tools blockieren¶
Verhindern, dass der Agent bestimmte Bash-Befehle ausführt:
Anfragen nach Nur-Lesen-Berechtigung automatisch zulassen¶
Berechtigungsanfragen für Tools zulassen, die nur Daten lesen:
Tool-Eingabe ändern¶
Fügen Sie allen Bash-Befehlen ein Timeout hinzu, bevor sie ausgeführt werden:
Audit-Protokollieren¶
Protokollieren Sie alle Tool-Aufrufe zu Auditing-Zwecken, ohne die Ausführung zu beeinträchtigen:
Hooks vs. canUseTool¶
Sowohl Hooks als auch der canUseTool-Callback können Toolaufrufe abfangen, aber sie dienen unterschiedlichen Zwecken:
Feature |
|
Hooks |
|---|---|---|
Bereich |
Nur Berechtigungsprüfung vor der Ausführung |
Mehrere Lebenszyklusereignisse (Tool-Lebenszyklus, Prompt-Eingabe, Stopp, Lebenszyklus des Subagenten, Benachrichtigung und Komprimierung) |
Veranstaltungen |
Eins: Berechtigungsanfragen |
Zehn: |
Mustererkennung |
Keine Matcher-Unterstützung. Wird für Berechtigungsanfragen aufgerufen, die noch nicht durch Regellisten aufgelöst wurden. |
Ja (Regex-Matcher filtern je nach Ereignis nach Toolname, Benachrichtigungstyp oder Komprimierungstrigger) |
Eingabe ändern |
Begrenzt. |
Ja ( |
Am besten geeignet für |
Einfache Entscheidungen zwischen Zulassen/Ablehnen |
Audit-Protkollieren, Kontexteinschleusung, komplexe Richtlinien, Aktionen nach der Ausführung |
Sie können beides zusammen verwenden. Der canUseTool-Callback wird als Teil des Berechtigungssystem von CLI ausgeführt, während PreToolUse-Hooks separat ausgeführt werden.
Rechtliche Hinweise¶
Wenn Ihre Cortex Code-Konfiguration ein Modell verwendet, das im Rahmen der Modell- und Service-Pass-Through-Bedingungen bereitgestellt wurde, unterliegt Ihre Nutzung dieses Modells zusätzlich den Bedingungen für dieses Modell auf dieser Seite.
Die Datenklassifizierung der Eingaben und Ausgaben ist in der folgenden Tabelle aufgeführt.
Klassifizierung von Eingabedaten |
Klassifizierung von Ausgabedaten |
Benennung |
|---|---|---|
Usage Data |
Kundendaten |
Abgedeckte AI-Features [1] |
Weitere Informationen dazu finden Sie unter KI und ML in Snowflake.