Com as ferramentas, é possível conectar playbooks a sistemas externos. Esses sistemas podem aumentar o conhecimento dos playbooks e permitir que eles executem tarefas complexas com eficiência.
Você pode usar ferramentas integradas ou criar ferramentas personalizadas de acordo com seus requisitos.
Teste de ferramentas
Depois de criar uma ferramenta, use o recurso de teste de ferramentas para verificar se ela funciona. Ao visualizar uma ferramenta, clique no botão Testar acima do painel de ferramentas. Isso abre a ferramenta para entrada no simulador. Forneça a entrada da ferramenta e clique em View Output para verificar a saída correta da ferramenta.
Você também pode usar o recurso de teste de ferramentas ao adicionar uma ferramenta a um exemplo.
Ferramentas integradas
As ferramentas integradas são hospedadas pelo Google. É possível ativar essas ferramentas em agentes sem precisar de configuração manual.
As ferramentas integradas compatíveis são:
Code Interpreter
: uma ferramenta própria do Google que combina a capacidade de geração e execução de código e permite que o usuário realize várias tarefas, incluindo análise e visualização de dados, processamento de texto, resolução de equações ou problemas de otimização.
Seu agente é otimizado para determinar como e quando essas ferramentas devem ser invocadas, mas você pode fornecer outros exemplos para se adequar aos seus casos de uso.
Os exemplos precisam ter um esquema como este:
{
"toolUse": {
"tool": "projects/PROJECT_ID/locations/LOCATION_ID/agents/AGENT_ID/tools/df-code-interpreter-tool",
"action": "generate_and_execute",
"inputParameters": [
{
"name": "generate_and_execute input",
"value": "4 + 4"
}
],
"outputParameters": [
{
"name": "generate_and_execute output",
"value": {
"output_files": [
{
"name": "",
"contents": ""
}
],
"execution_result": "8",
"execution_error": "",
"generated_code": "GENERATED_CODE"
}
}
]
}
}
Ferramentas do OpenAPI
Um agente pode se conectar a uma API externa usando uma ferramenta do OpenAPI fornecendo o esquema OpenAPI. Por padrão, o agente vai chamar a API em seu nome. Como alternativa, é possível executar ferramentas da OpenAPI no lado do cliente.
Exemplo de esquema:
openapi: 3.0.0
info:
title: Simple Pets API
version: 1.0.0
servers:
- url: 'https://api.pet-service-example.com/v1'
paths:
/pets/{petId}:
get:
summary: Return a pet by ID.
operationId: getPet
parameters:
- in: path
name: petId
required: true
description: Pet id
schema:
type: integer
responses:
200:
description: OK
/pets:
get:
summary: List all pets
operationId: listPets
parameters:
- name: petName
in: query
required: false
description: Pet name
schema:
type: string
- name: label
in: query
description: Pet label
style: form
explode: true
required: false
schema:
type: array
items:
type: string
- name: X-OWNER
in: header
description: Optional pet owner provided in the HTTP header
required: false
schema:
type: string
- name: X-SESSION
in: header
description: Dialogflow session id
required: false
schema:
$ref: "@dialogflow/sessionId"
responses:
'200':
description: An array of pets
content:
application/json:
schema:
type: array
items:
$ref: '#/components/schemas/Pet'
post:
summary: Create a new pet
operationId: createPet
requestBody:
description: Pet to add to the store
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/Pet'
responses:
'201':
description: Pet created
content:
application/json:
schema:
$ref: '#/components/schemas/Pet'
components:
schemas:
Pet:
type: object
required:
- id
- name
properties:
id:
type: integer
format: int64
name:
type: string
owner:
type: string
label:
type: array
items:
type: string
Você pode usar a referência de esquema interno @dialogflow/sessionId
como tipo de esquema de parâmetro.
Com esse tipo de esquema de parâmetro,
o ID da sessão do Dialogflow para a conversa atual
será fornecido como um valor de parâmetro.
Exemplo:
- name: X-SESSION
in: header
description: Dialogflow session id
required: false
schema:
$ref: "@dialogflow/sessionId"
Limitações da ferramenta OpenAPI
Considere as seguintes limitações:
- Os tipos de parâmetro aceitos são
path
,query
eheader
. O tipo de parâmetrocookie
ainda não é aceito. - Os parâmetros definidos pelo esquema da OpenAPI oferecem suporte aos seguintes tipos de dados:
string
,number
,integer
,boolean
earray
. O tipoobject
ainda não é compatível. - No momento, não é possível especificar parâmetros de consulta no editor de exemplo do console.
- O corpo da solicitação e da resposta precisa estar vazio ou em JSON.
Autenticação da API da ferramenta OpenAPI
As seguintes opções de autenticação têm suporte ao chamar uma API externa:
- Autenticação do agente de serviço do Dialogflow
- O Dialogflow pode gerar um token de ID ou de acesso usando o agente de serviço do Dialogflow. O token é adicionado no cabeçalho HTTP de autorização quando o Dialogflow chama uma API externa.
- Um token de ID pode ser usado para acessar funções e serviços do Cloud Run depois de conceder os papéis roles/cloudfunctions.invoker e roles/run.invoker a service-agent-project-number@gcp-sa-dialogflow.iam.gserviceaccount.com. Se as funções e os serviços do Cloud Run estiverem no mesmo projeto de recursos, não será necessário ter outra permissão do IAM para fazer a chamada.
- Um token de acesso pode ser usado para acessar outras APIs Google Cloud depois de conceder os papéis necessários a service-agent-project-number@gcp-sa-dialogflow.iam.gserviceaccount.com.
Autenticação da conta de serviço
- As contas de serviço podem ser usadas para autenticar solicitações de ferramentas em qualquer API do Google que ofereça suporte a elas. Como as contas de serviço são principais, elas podem acessar recursos no seu projeto ao conceder um papel, assim como você faria para qualquer outro principal. O e-mail da conta de serviço será usado para gerar um token de acesso, que será enviado no cabeçalho
Authorization
da solicitação da ferramenta. Para usar esse recurso, as seguintes permissões são necessárias:
- Conceda o papel
roles/iam.serviceAccountUser
ao usuário que está criando ou atualizando a ferramenta para usar a autenticação da conta de serviço. - papel
roles/iam.serviceAccountTokenCreator
ao Agente de serviço do Dialogflow.
- Conceda o papel
Se você estiver tentando usar contas de serviço em vários projetos, verifique se a política da organização oferece suporte. As duas permissões precisam ser concedidas no projeto que contém a conta de serviço.
- As contas de serviço podem ser usadas para autenticar solicitações de ferramentas em qualquer API do Google que ofereça suporte a elas. Como as contas de serviço são principais, elas podem acessar recursos no seu projeto ao conceder um papel, assim como você faria para qualquer outro principal. O e-mail da conta de serviço será usado para gerar um token de acesso, que será enviado no cabeçalho
Chave de API
- É possível configurar a autenticação de chave de API fornecendo o nome da chave, o local da solicitação (cabeçalho ou string de consulta) e a chave de API para que o Dialogflow transmita a chave de API na solicitação.
- Recomendamos que você forneça sua chave de API usando o Secret Manager.
OAuth
O fluxo de credenciais do cliente OAuth tem suporte para autenticação de servidor para servidor:
- Esse fluxo pode ser usado se o console do Agente Builder for o proprietário do recurso e nenhuma autorização do usuário final for necessária.
- O ID do cliente, a chave secreta do cliente e o endpoint do token do provedor OAuth precisam
ser configurados no Dialogflow.
- Recomendamos que você forneça a chave secreta do cliente usando o Gerenciador de secrets.
- O Dialogflow troca um token de acesso do provedor OAuth e o transmite no cabeçalho de autenticação da solicitação.
Para outros fluxos OAuth que exigem autorização do usuário final, como o fluxo de código de autorização e o fluxo PKCE:
- Você vai precisar implementar sua própria interface de login e receber o token de acesso no lado do cliente.
Em seguida, você pode:
a. Use a opção de autenticação de token do portador para transmitir o token à ferramenta OpenAPI. O Dialogflow vai incluir esse token no cabeçalho de autorização ao invocar a ferramenta.
b. Use a ferramenta "Function" para invocar a ferramenta no lado do cliente e transmitir o resultado da chamada da ferramenta para o Dialogflow.
Token do portador
- É possível configurar a autenticação Bearer para transmitir dinamicamente o token Bearer do cliente. Esse token é incluído no cabeçalho de autenticação da solicitação.
- Ao configurar a autenticação de ferramentas, é possível designar um parâmetro de sessão
para atuar como o token de portador. Por exemplo, use
$session.params.<parameter-name-for-token>
para especificar o token. - No momento da execução, atribua o token de portador ao parâmetro de sessão:
DetectIntentRequest { ... query_params { parameters { <parameter-name-for-token>: <the-auth-token> } } ... }
- Se você precisar configurar um token estático em vez de buscar o token de um parâmetro de sessão, recomendamos fornecer o token usando o Secret Manager.
Autenticação TLS mútua
- Consulte a documentação da Autenticação TLS mútua.
- Certificados de cliente personalizados são aceitos. É possível configurar certificados de cliente no nível do agente na guia "Segurança", nas configurações do agente. O certificado (formato PEM) e a chave privada (formato PEM) são campos obrigatórios. Depois de definido, esse certificado do cliente será usado durante o TLS mútuo para todas as ferramentas e webhooks.
Certificado de CA personalizado
- Consulte a documentação Certificados de AC personalizados.
Autenticação do Secret Manager
Se você usar OAuth, chave de API ou token de portador, poderá armazenar as credenciais como secrets usando o Secret Manager. Confira as etapas necessárias para autenticar sua ferramenta usando chaves secretas:
- Crie seu segredo se você ainda não tiver um.
- Conceda ao Agente de serviço do Dialogflow
o papel de Acessador de secret do Secret Manager
(
roles/secretmanager.secretAccessor
) no novo secret. - Copie sua credencial para a área de transferência.
- Adicione uma nova versão do secret
ao secret. Cole suas credenciais como o valor do secret.
- Omita qualquer caractere de nova linha no final.
- Copie o nome da versão do secret que você acabou de adicionar. O formato do nome é
projects/{project_id}/secrets/{secret_id}/versions/{version_id}"
. - Abra a tela de edição da ferramenta e faça o seguinte:
- Se você usar o OAuth, selecione OAuth como Tipo de autenticação e clique em Versão secreta em Chave secreta do cliente. Em seguida, cole o nome da versão secreta na caixa de entrada Versão secreta.
- Se você usar a chave de API, selecione Chave de API como Tipo de autenticação e clique em Versão secreta em Chave de API. Cole o nome da versão do secret na caixa de entrada Versão do secret.
- Se você usar o token de portador, selecione Token de portador como o Tipo de autenticação e clique em Versão secreta em Token de portador. Cole o nome da versão secreta na caixa de entrada Versão secreta.
- Clique em Salvar.
Acesso à rede particular da ferramenta OpenAPI
A ferramenta OpenAPI se integra ao acesso à rede particular do Diretório de serviços, para que ele possa se conectar aos destinos da API dentro da rede VPC. Isso mantém o tráfego na rede do Google Cloud e aplica o IAM e o VPC Service Controls.
Para configurar uma ferramenta OpenAPI que segmenta uma rede privada:
Siga a configuração de rede particular do Diretório de serviços para configurar sua rede VPC e o endpoint do Diretório de serviços.
A conta de serviço do agente de serviço do Dialogflow com o endereço a seguir precisa existir para o projeto de agente:
Conceda à conta de serviço do Agente de Serviço do Dialogflow os seguintes papéis do IAM:service-agent-project-number@gcp-sa-dialogflow.iam.gserviceaccount.com
servicedirectory.viewer
do projeto do diretório de serviçosservicedirectory.pscAuthorizedService
do projeto de rede
Forneça o serviço do diretório de serviços com o esquema da OpenAPI e informações de autenticação opcionais ao criar a ferramenta.
Acesso ao parâmetro de sessão da ferramenta OpenAPI
As entradas da ferramenta de API aberta são derivadas da conversa dos usuários com o LLM usando o esquema como guia. Em algumas situações, as entradas podem precisar ser derivadas de parâmetros de sessão coletados durante um fluxo ou fornecidas como uma entrada de parâmetro de consulta com a entrada do usuário.
O parâmetro de sessão que precisa ser transmitido como uma entrada pode ser especificado como
parameters:
- in: query
name: petId
required: true
description: Pet id
schema:
type: integer
x-agent-input-parameter: petId # Reads from the $session.params.petId
- in: header
name: X-other
schema:
type: string
x-agent-input-parameter: $request.payload.header # Reads from the header specified in the request payload input
requestBody:
required: false
content:
application/json:
schema:
type: object
properties:
name:
type: string
x-agent-input-parameter: petName # Reads from the $session.params.petName
description: Name of the person to greet (optional).
breed:
type: string
description: Bread of the pet.
Se nenhum parâmetro de sessão estiver disponível, a entrada gerada pelo LLM será transmitida para a ferramenta.
Valores padrão da ferramenta OpenAPI
O esquema da API aberta pode ser usado para especificar valores padrão. Os valores padrão são usados apenas se não houver um valor de entrada gerado pelo LLM ou um valor de entrada baseado no parâmetro de sessão para esse parâmetro ou propriedade.
Os valores padrão podem ser especificados como parte do esquema da seguinte maneira:
parameters:
- in: query
name: zipcode
required: true
description: Zip code to search for
schema:
type: integer
default: 94043
requestBody:
content:
application/json:
schema:
type: object
properties:
breed:
type: string
description: Bread of the pet.
page_size:
type: integer
description: Number of pets to return.
default: 10
Se nenhum valor gerado pelo LLM, valor do parâmetro de sessão ou valor padrão estiver presente, a entrada não será especificada.
Ferramentas de repositório de dados
Para saber como usar ferramentas de armazenamento de dados com um playbook, consulte a documentação ferramentas de armazenamento de dados.
Ferramentas de conector
As ferramentas de conector podem ser usadas por um agente para realizar ações usando suas conexões configuradas em Integration Connectors. Cada ferramenta de conector é configurada com uma única conexão e uma ou mais ações. Se necessário, várias ferramentas podem ser criadas para uma única conexão e agrupar diferentes ações para que o agente as use.
A ferramenta de conector é compatível com os seguintes tipos de conector:
- BigQuery
- CloudSQL: SQL Server
- Gerenciamento de serviços do Jira
- Banco de dados Oracle
- PayPal
- Salesforce
- Salesforce Marketing Cloud
- ServiceNow
- SharePoint
- Stripe
- Zendesk
Os exemplos devem ser usados para melhorar o uso de ferramentas de conector pelo agente, demonstrando como o agente deve chamar a ferramenta e usar a resposta.
Crie uma conexão
Para criar uma conexão e conectá-la ao seu agente, acesse Tools > Create, selecione o tipo de ferramenta Connector, o tipo de conector escolhido e use o botão Create Connection. Isso vai direcionar você para a criação de conectores de integração com vários campos pré-preenchidos.
Você também pode acessar os conectores de integração e seguir as instruções para criar uma conexão.
Ações do conector
Para cada ferramenta de conector, há dois tipos de ações que podem ser disponibilizadas para o agente. Consulte Entidades, operações e ações para mais informações:
Operações CRUD de entidade
Cada uma das suas conexões tem "entidades" correspondentes aos objetos dessa fonte de dados (no BigQuery, são tabelas; no Salesforce, são objetos, como "Pedido" ou "Caso").
É possível realizar operações CRUD em cada entidade:- Criar: cria uma entidade com valores de campo especificados.
- Lista: pesquisa baseada em filtro de instâncias de entidade
- Atualizar: método baseado em filtro para alterar os valores de campo de entidade.
- Excluir: exclui uma entidade.
- Get recupera uma única entidade usando o entityId
Saiba mais sobre os detalhes das operações CRUD de entidades nas documentações dos conectores.
- Criar: cria uma entidade com valores de campo especificados.
Ações específicas do conector
Muitos conectores oferecem suporte à ação ExecuteCustomQuery, que permite executar uma consulta SQL na fonte de dados, em que cada uma das entidades da fonte de dados pode ser referenciada como tabelas. Consulte esta lista para conferir os conectores compatíveis.
As ações adicionais variam de acordo com o tipo de conector. Por exemplo, consulte as ações do conector do BigQuery ou as ações do conector do Salesforce.
Como configurar campos de entrada / saída para operações CRUD
Ao selecionar campos de entrada ou saída específicos para a ação da ferramenta de conector, você pode limitar a complexidade dessas ações para o agente.
Por exemplo, se você só precisa criar uma entidade com um subconjunto de campos, configurar esse conjunto de campos na ação simplifica a ação para o agente.
Especificar um conjunto de campos de saída reduz o tamanho da resposta da ferramenta (útil se os limites de token forem uma preocupação) e simplifica o processamento da saída pelo agente, exibindo apenas os campos relevantes.
Autenticação
Se a conexão que você está usando estiver configurada para permitir a substituição de autenticação, a ferramenta poderá ser configurada para transmitir credenciais de parâmetros de sessão especificados.
Você, como criador do agente, é responsável por como essas credenciais são preenchidas nos parâmetros da sessão, e a ferramenta as transmite automaticamente à fonte de dados para usar na autenticação quando as ações da ferramenta são chamadas.
Ferramentas de função
Se você tiver uma funcionalidade acessível pelo código do cliente, mas não pelas ferramentas da OpenAPI, use as ferramentas de função. As ferramentas de função são sempre executadas no lado do cliente, não pelo agente.
O processo é o seguinte:
- O código do cliente envia uma solicitação de detecção de intent.
- O agente detecta que uma ferramenta de função é necessária, e a resposta de detecção de intent contém o nome da ferramenta e os argumentos de entrada. Essa sessão é pausada até que outra solicitação de detecção de intent seja recebida com o resultado da ferramenta.
- O código do cliente chama a ferramenta.
- O código do cliente envia outra solicitação de detecção de intent que fornece o resultado da ferramenta como argumentos de saída.
O exemplo a seguir mostra o esquema de entrada e saída de uma ferramenta de função:
{
"type": "object",
"properties": {
"location": {
"type": "string",
"description": "The city and state, for example, San Francisco, CA"
}
},
"required": [
"location"
]
}
{
"type": "object",
"properties": {
"temperature": {
"type": "number",
"description": "The temperature"
}
}
}
O exemplo a seguir mostra a solicitação e a resposta iniciais da detecção de intent usando REST:
HTTP method and URL:
POST https://REGION_ID-dialogflow.googleapis.com/v3/projects/PROJECT_ID/locations/LOCATION_ID/agents/AGENT_ID/sessions/SESSION_ID:detectIntent
{
"queryInput": {
"text": {
"text": "what is the weather in Mountain View"
},
"languageCode": "en"
}
}
{
"queryResult": {
"text": "what is the weather in Mountain View",
"languageCode": "en",
"responseMessages": [
{
"source": "VIRTUAL_AGENT",
"toolCall": {
"tool": "<tool-resource-name>",
"action": "get-weather-tool",
"inputParameters": {
"location": "Mountain View"
}
}
}
]
}
}
O exemplo a seguir mostra a segunda solicitação de detecção de intent, que fornece o resultado da ferramenta:
{
"queryInput": {
"toolCallResult": {
"tool": "<tool-resource-name>",
"action": "get-weather-tool",
"outputParameters": {
"temperature": 28.0
}
},
"languageCode": "en"
}
}
Execução do lado do cliente
Assim como as ferramentas de função, as ferramentas OpenAPI e de armazenamento de dados podem ser executadas no lado do cliente aplicando uma substituição de API ao interagir com a sessão.
Exemplo:
DetectIntentRequest {
...
query_params {
playbook_state_override {
playbook_execution_mode: ALWAYS_CLIENT_EXECUTION
}
}
...
}
O processo é o seguinte:
- O código do cliente envia uma solicitação de detecção de intent que especifica a execução do cliente.
- O agente detecta que uma ferramenta é necessária, e a resposta de detecção de intent contém o nome da ferramenta com os argumentos de entrada. Essa sessão é pausada até que outra solicitação de detecção de intent seja recebida com o resultado da ferramenta.
- O código do cliente chama a ferramenta.
- O código do cliente envia outra solicitação de detecção de intent que fornece o resultado da ferramenta como argumentos de saída.