A governança eficaz depende de descrições precisas, claras e completas das ferramentas e dos parâmetros correspondentes. Os sistemas com agentes, incluindo os próprios agentes e camadas de governança, como políticas de governança semântica, exigem mais detalhes do que um humano para entender a aplicabilidade das ferramentas disponíveis.
Otimizar descrições de ferramentas
Use descrições claras das ferramentas do MCP e dos parâmetros exigidos por elas.
- Descrição insuficiente da ferramenta: "Pesquise itens".
- Descrição eficaz da ferramenta: "Pesquise no catálogo de conteúdo por palavra-chave, membro do elenco, gênero ou formato. Use isso quando o usuário quiser saber quais filmes ou programas de TV estão disponíveis. Retorna os 10 principais itens classificados por relevância."
Preste atenção aos limites de descrições
O sistema de governança semântica aplica estes limites de comprimento para descrições:
| Item de descrição | Aplicável a | Limite de comprimento |
|---|---|---|
| Ferramenta | O servidor MCP ou outra entidade que expõe ferramentas | 1000 caracteres |
| Ação | Uma ferramenta individual no servidor MCP ou uma chamada de função disponível para seu agente | 750 caracteres |
| Parâmetro | Um parâmetro usado em uma ferramenta ou chamada de função | 300 caracteres |
Se o tempo de execução da governança semântica receber uma descrição que exceda qualquer um desses limites, ela será truncada até o limite declarado, e uma mensagem será registrada.
Quando a política de governança semântica intervém
A política de governança semântica funciona especificamente como uma verificação de segurança de tempo de execução em chamadas de ferramentas propostas. Ela não intercepta, bloqueia nem modifica o diálogo padrão entre o usuário e o LLM do agente durante brainstorming, planejamento ou raciocínio em várias etapas. O mecanismo de política intercepta e avalia solicitações apenas no momento em que o modelo propõe invocar uma ferramenta para executar uma ação.
Cenário 1: refinamento da conversa x execução de ferramentas (chamada de ferramenta negada)
Considere um agente que tenha uma ferramenta initiate_marketing_campaign e seja regido pela seguinte restrição:
- Restrição:"Não é permitido criar ou iniciar campanhas de marketing sem aprovação explícita do gerente".
- Planejamento conversacional: um usuário pede ao agente: "Me ajude a criar uma campanha de marketing multicanal para o lançamento do nosso novo produto de outono". O LLM conversa livremente com o usuário em várias rodadas, descrevendo estratégias, criando cópias de e-mail e refinando os dados demográficos segmentados. O mecanismo de política não bloqueia nem nega essas interações porque o modelo está usando o raciocínio conversacional em vez de propor uma ação.
Invocação da ferramenta: quando a estratégia é finalizada, o usuário diz: "Parece ótimo, inicie a campanha de marketing agora". O LLM responde gerando uma proposta de chamada de ferramenta:
initiate_marketing_campaign(campaign_name="Fall Launch", budget=50000)Intervenção e negação de política:o gateway de agente intercepta essa chamada de ferramenta proposta e a encaminha para o mecanismo de política. O mecanismo de políticas avalia a ação em relação à restrição, determina que não há aprovação do gerente no histórico da sessão e emite um veredito
DENY. A chamada de ferramenta é bloqueada antes da execução, e uma justificativa de recusa estruturada é retornada ao agente.
Cenário 2: execução de ferramenta em conformidade (chamada de ferramenta permitida)
Considere o mesmo agente de marketing depois que a autorização supervisora adequada for documentada:
- Aprovação fornecida: o usuário especifica: "Meu gerente, VP de Marketing Corporativo (jordan@example.com), analisou o resumo e aprovou nosso orçamento de US $50.000 para a campanha de lançamento de outono. Inicie."
Invocação de ferramenta:o LLM propõe invocar a ação:
initiate_marketing_campaign(campaign_name="Fall Launch", budget=50000, approval="jordan@example.com")Avaliação e aprovação da política:o mecanismo de políticas intercepta a chamada de função, verifica no histórico de turnos da conversa se a aprovação do gerente está documentada e emite um veredito
ALLOW. O Gateway de Agente encaminha a chamada para o endpoint da ferramenta subjacente, permitindo que a ação prossiga normalmente.
Exemplos de restrições eficazes
Uma boa restrição remove a ambiguidade, especifica limites exatos (financeiros, temporais ou geográficos) e usa uma linguagem que corresponde às ferramentas usadas pelo agente.
Infraestrutura em nuvem de TI (segurança e controle de custos)
- Cenário:ambientes de teste.
- Ferramenta:
provision_cloud_server(parâmetros:region,instance_type,duration_hours). - Descrição da ferramenta:envia uma solicitação para provisionar um servidor de nuvem em uma região específica, usando um tipo de instância específico, para persistir por um determinado período.
- Restrição efetiva:"Permitir o provisionamento de servidores na nuvem apenas nas regiões "us-east" ou "eu-west". Negue todas as solicitações para provisionar tipos de instância "gpu-large" ou "gpu-xlarge". Limite o parâmetro "duration_hours" a um máximo de 72 horas."
- Por que funciona:usa uma linguagem alinhada à descrição da ferramenta e se refere especificamente aos parâmetros aceitos por ela.
Atendimento ao cliente de e-commerce (proteções financeiras)
- Cenário:emissão de créditos na conta.
- Ferramenta:
apply_account_credit(parâmetros:account_id,credit_amount,reason_category). - Restrição efetiva:"Limite os créditos da conta a um máximo de US $50 por interação. Não aplique créditos se o reason_category for "shipping_delay" e a data original do pedido for de menos de cinco dias atrás."
- Por que funciona:define um limite de dólar estrito e o combina com uma condição lógica baseada em tempo e categoria.
Exemplos de restrições ineficazes
Uma restrição ruim geralmente é vaga, usa linguagem subjetiva ou não mapeia diretamente para descrições de ferramentas ou parâmetros de ferramentas.
Infraestrutura em nuvem de TI (subjetiva)
- Restrição ineficaz:"Não crie servidores muito caros. Mantenha a duração em um período razoável."
- Por que isso não funciona:um LLM tem um desempenho melhor com números concretos (por exemplo, "limite de US$ 50") do que com conceitos abstratos como "razoável" ou "caro".
Atendimento ao cliente (terminologia desalinhada)
- Restrição ineficaz:"Não devolva dinheiro a compradores irritados fora do horário de funcionamento normal".
- Por que a solicitação falha: "Devolver o dinheiro" não corresponde aos parâmetros da ferramenta (
refund_amount). "Compradores irritados" é subjetivo, e "horário de funcionamento" não é definido sem um fuso horário.
Orientações sobre linguagem
Ao criar restrições, siga estas diretrizes:
- Use linguagem humana simples:use frases completas em um sentido declarativo ou imperativo (por exemplo, "Não permita..." ou "Não permitir...").
- Evite frases fracas:evite "Acho melhor se..." ou "Tente evitar...". A forma como você se expressa é importante para o LLM Judge.
- Seja específico:especifique restrições com limites declarados diretamente (por exemplo, "US$ 1.000", "das 8h às 16h EST"). Use uma linguagem que esteja alinhada com as descrições de ferramentas e parâmetros.
- Evite contradições:garanta que as restrições de escopo do agente e da ferramenta não entrem em conflito (por exemplo, diferentes limites mínimos de valor em dólar).
Restrições de teste:é possível testar suas restrições de linguagem natural usando o modo de teste, que avalia as políticas sem aplicá-las.
A seguir
- Saiba mais sobre como governar habilidades em Governança de habilidades do agente.
- Saiba como vincular políticas à saída do gateway em Delegar autorização a políticas de governança semântica.
- Configure as políticas em Configurar políticas de governança semântica.