Ganchos¶
Este tópico descreve como usar ganchos para executar código personalizado em pontos-chave do ciclo de vida do agente. Os ganchos permitem interceptar chamadas de ferramentas, auditar o comportamento de agentes, aplicar políticas, injetar contexto e controlar o fluxo de execução.
Como funcionam os ganchos¶
Os ganchos seguem um processo de quatro etapas: um evento é acionado, o SDK verifica se há alguma correspondência, ele chama o retorno de chamada e esse retorno envia uma decisão que controla o que acontece depois.
O agente aciona um evento (por exemplo, está prestes a chamar uma ferramenta).
O SDK verifica cada correspondência de gancho registrada para aquele tipo de evento.
Se houver uma correspondência (ou não houver um padrão de correspondência, o que significa que corresponde a tudo), o SDK chama as funções de retorno de chamada associadas.
Cada retorno de chamada envia um objeto de saída que pode permitir, bloquear ou modificar a operação.
Eventos de gancho¶
Os seguintes eventos estão disponíveis:
Evento |
Quando é acionado |
|---|---|
|
Antes da execução de uma ferramenta. Pode bloquear a ferramenta ou modificar a entrada. |
|
Depois que uma ferramenta é executada com sucesso. Pode incluir contexto adicional. |
|
Após uma falha na execução de uma ferramenta. |
|
Quando o usuário envia um prompt. Pode incluir contexto adicional. |
|
Quando o agente está prestes a parar. Pode injetar contexto ou interromper a sessão. |
|
Quando um subagente é iniciado. |
|
Quando um subagente está prestes a parar. |
|
Antes que a conversa seja compactada (resumida para se ajustar à janela de contexto). |
|
Quando o agente emite uma notificação. |
|
Quando ocorre uma verificação de permissão da ferramenta. |
Configurando ganchos¶
Passe os ganchos pela opção hooks ao criar uma sessão. Cada evento de gancho é mapeado para uma lista de correspondências, e cada correspondência contém uma lista de funções de retorno de chamada.
Correspondências¶
Cada correspondência de gancho tem três campos:
Campo |
Tipo |
Descrição |
|---|---|---|
|
|
Um padrão regex usado por eventos que oferecem suporte à correspondência. |
|
lista de retornos de chamada |
Uma ou mais funções de retorno de chamada a serem executadas quando houver correspondência. |
|
|
Tempo máximo em segundos para todos os retornos de chamada da correspondência. O padrão é 60. |
O campo matcher aceita qualquer padrão regex válido. Por exemplo:
"Bash"– corresponde apenas à ferramenta Bash"Write|Edit"– corresponde a gravação ou edição".*"– corresponde a todas as ferramentas (o mesmo que omitir a correspondência)
Entradas de retorno de chamada¶
Cada retorno de chamada recebe três argumentos:
Argumento |
Descrição |
|---|---|
|
Um objeto com dados específicos do evento. Todos os eventos incluem |
|
A ferramenta usa ID (para eventos relacionados a ferramentas) ou |
|
Um objeto de contexto. Reservado para uso futuro (por exemplo, sinais de anulação). |
Os campos de entrada variam de acordo com o evento:
Evento |
Campos de entrada adicionais |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ganchos no ciclo de vida da ferramenta e PermissionRequest também podem incluir os campos opcionais agent_id e agent_type quando eles forem disparados de um subagente.
Saídas de retorno de chamada¶
Os retornos de chamada enviam um objeto de saída que controla a execução. Os seguintes campos estão disponíveis:
Campo |
Tipo |
Descrição |
|---|---|---|
|
|
Se o processamento deve prosseguir. Defina como |
|
|
Mensagem exibida quando |
|
|
Defina como |
|
|
Mensagem de feedback para o agente sobre a decisão. |
|
|
A mensagem de aviso exibida ao usuário. |
|
|
Controles específicos do evento (consulte abaixo). |
Nota
O SDK Python usa continue_ (com um sublinhado no final) em vez de continue para evitar o conflito de palavras-chave do Python. O SDK converte automaticamente isso em continue ao se comunicar com a CLI.
Saídas específicas de gancho¶
O campo hookSpecificOutput aceita controles específicos do evento:
PreToolUse
Campo |
Descrição |
|---|---|
|
|
|
Motivo da decisão sobre a permissão. |
|
Entrada da ferramenta modificada para usar em vez da original. |
PostToolUse
Campo |
Descrição |
|---|---|
|
Contexto extra injetado na conversa após a execução da ferramenta. |
UserPromptSubmit
Campo |
Descrição |
|---|---|
|
Contexto extra injetado na conversa. |
PermissionRequest
Campo |
Descrição |
|---|---|
|
|
|
Mensagem exibida ao negar a solicitação da permissão. |
Exemplos¶
Bloquear ferramentas perigosas¶
Impedir que o agente execute comandos bash específicos:
Permitir automaticamente solicitações de permissão somente leitura¶
Autorizar solicitações de permissão para ferramentas que leem apenas dados:
Modificar entrada da ferramenta¶
Adicionar um tempo limite para todos os comandos bash antes de serem executados:
Registros de auditoria¶
Registrar todas as chamadas de ferramenta para fins de auditoria sem afetar a execução:
Ganchos vs. canUseTool¶
Tanto os ganchos quanto o retorno de chamada canUseTool pode interceptar chamadas de ferramentas, mas têm finalidades diferentes:
Recurso |
|
Ganchos |
|---|---|---|
Escopo |
Somente verificação de permissão pré-execução |
Vários eventos do ciclo de vida (ciclo de vida da ferramenta, envio de prompts, interrupções, ciclo de vida do subagente, notificação e compactação) |
Eventos |
Um: solicitação de permissão |
Dez: |
Correspondência de padrões |
Sem suporte para correspondência. Invocado para solicitações de permissão que ainda não foram resolvidas por listas de regras. |
Sim (as correspondências regex filtram por nome de ferramenta, tipo de notificação ou acionador de compactação, dependendo do evento) |
Modificar entrada |
Limitado. |
Sim ( |
Melhor para |
Decisões simples de permissão/negação |
Registro de auditoria, injeção de contexto, políticas complexas, ações pós-execução |
É possível usar as duas juntas. O retorno de chamada canUseTool é executado como parte do sistema de permissão da CLI, enquanto os ganchos PreToolUse são executados separadamente.
Avisos legais¶
Quando sua configuração do Cortex Code usa um modelo que consta em Model and Service Pass-Through Terms, seu uso desse modelo está sujeito aos respectivos termos nessa página.
A classificação dos dados de entradas e saídas é definido na tabela a seguir.
Classificação de dados de entrada |
Classificação de dados de saída |
Designação |
|---|---|---|
Usage Data |
Dados de cliente |
Recursos de AI incluídos [1] |
Para obter informações adicionais, consulte AI e ML Snowflake.