Pause um agente para aprovação com KV Store
Execute um loop de agente com tool calling em uma function, pause-o no KV Store antes de uma ação que uma pessoa aprova e registre cada evento no SQL Database.
Você executa um loop de agente com tool calling em uma function, armazena uma tarefa no KV Store quando o modelo pede uma ação que uma pessoa precisa aprovar, retoma a tarefa com a decisão e grava cada evento da tarefa no SQL Database, com a Azion CLI e o código de uma function.
Pré-requisitos
- Uma aplicação e um workload que servem o seu domínio, com o Application Accelerator ativado, que o behavior Run Function exige. Para criá-los, consulte Primeiros passos com Applications.
- KV Store e SQL Database habilitados na conta. Os dois estão em Preview e não vêm habilitados por padrão, então solicite acesso pelo Technical Support.
- O namespace
agent-statedo KV Store. Para criá-lo, consulte Crie o namespace. - O banco de dados
agent-history, com uma tabela criada pela instruçãoCREATE TABLE task_events (task_id TEXT NOT NULL, event TEXT NOT NULL, steps INTEGER NOT NULL, at TEXT NOT NULL);. Para criar o banco de dados e enviar a instrução, consulte Crie um banco de dados usando a API e Crie uma tabela pela API. - Um personal token com a permissão Edit SQL Database, para as gravações do histórico. Para criar um, consulte Gerencie personal tokens.
- A Azion CLI, instalada e autorizada, para armazenar as variáveis de ambiente.
- Um provedor de terceiros cujo endpoint de chat aceite o formato de chat completions da OpenAI com definições de ferramentas, com a URL dele, o nome de um modelo que suporte tool calling e uma API key.
Os exemplos dão ao agente duas ferramentas sobre um serviço de pedidos em https://api.example.com/v1: get_order, que lê GET /orders/{id}, e refund_order, que chama POST /orders/{id}/refunds e precisa da aprovação de uma pessoa. Eles usam www.example.com para o domínio. Substitua-os pelos seus valores.
Armazene os valores que a function lê
A chave do provedor, o token do backend, o segredo de quem aprova e o personal token ficam fora do código, como variáveis de ambiente.
Para armazenar os valores que a function lê, execute estes comandos com a Azion CLI. Uma key que contém key, token ou secret é armazenada como secret por padrão:
A conta guarda as sete variáveis que a function do agente lê com Azion.env.get().
O caso de uso Criar agentes de IA usa os valores deste exemplo.
Crie a function do agente
A function executa o loop em /api/agent/tasks e o retoma em /api/agent/approve. Uma ferramenta em APPROVAL_TOOLS nunca é executada a partir do loop: a function armazena a tarefa sob task:<task-id> em agent-state por um dia e executa a ferramenta apenas quando uma pessoa a aprova.
Crie uma function chamada ops-agent com este código. A chamada ao provedor envia a chave como Authorization: Bearer; mude esse header para o que o seu provedor exige:
Para criar a function e a sua instância, siga Primeiros passos com Functions com o nome ops-agent e dê à instância o nome ops-agent, sem Args.
A aplicação tem uma instância ops-agent que executa uma tarefa até que o modelo responda, um reembolso precise de aprovação ou seis etapas passem.
O caso de uso Criar agentes de IA usa os valores deste exemplo.
Execute a function nos caminhos do agente
Uma regra executa a instância nos dois caminhos do agente. Os dois recebem POST, e a function responde a qualquer outro método com 405.
Crie uma regra de Request Phase como Crie a regra para o caminho e o método descreve, com estes valores: o nome agent - tasks and approvals, um grupo de critérios com ${uri} starts with /api/agent/ no lugar dos grupos de caminho e de método do guia, e o behavior Run Function selecionando a instância ops-agent.
Uma tarefa enviada para /api/agent/tasks executa o agente, e cada início, pausa, decisão e fim chega a task_events. Uma regra nova leva alguns minutos para se propagar.
Confirme que uma tarefa pausa e retoma uma vez
Para enviar uma tarefa que precisa apenas de get_order:
A resposta traz "status":"completed", uma answer que informa o status do pedido e steps igual a 2 ou mais: uma etapa que chama get_order e uma que responde.
Envie {"task":"Refund order <order-id>, the customer received a damaged item."} para o mesmo caminho. A resposta traz "status":"awaiting_approval", o task_id e uma action que indica refund_order com o ID do pedido, e o serviço de pedidos não recebeu nenhum reembolso.
Para aprovar o reembolso, envie o task_id dessa resposta com o segredo de quem aprova:
A resposta traz "status":"completed", e o serviço de pedidos recebeu um reembolso. A mesma requisição enviada de novo responde 404 com no pending action for this task, e uma requisição sem o header Authorization responde 401.
Para ler os eventos da tarefa de reembolso, envie a instrução SELECT event, steps FROM task_events WHERE task_id = '<task-id>' ORDER BY rowid; à API do SQL Database, como mostra Consulte linhas. As linhas de results listam started, awaiting_approval, approved e completed, nessa ordem.
O agente pausa antes do reembolso, o executa uma vez depois da aprovação e registra cada evento em task_events.
Estas verificações confirmam o caso de uso Criar agentes de IA.