# aiagentdevelopment.info — texto integral

> O texto completo de cada guia neste idioma, para que um motor de respostas possa ler o catálogo num só pedido. Nada aqui falta nas páginas visíveis.

## Um roteiro de agentes de IA que chega mesmo a produção
https://aiagentdevelopment.info/pt/guides/roteiro-de-desenvolvimento-de-agente
Atualizado a 2026-08-05 · Custo e negócio

- Quatro fases com testes de saída escritos: âmbito, protótipo, endurecimento, lançamento.
- O endurecimento é a fase mais longa e mais subfinanciada.
- Lancem de forma limitada e alarguem pelos números, não pelo calendário.
- Depois do lançamento é um serviço: responsável, avaliação a crescer, requalificação.

O padrão de falha dos projetos de agentes não é técnico. É um bom protótipo na terceira semana, seguido de três meses de melhoria sem rumo e um cancelamento silencioso porque ninguém soube dizer se estava pronto.

Este roteiro corrige isso com testes de saída. Cada fase tem uma condição escrita antes de começar.

### Fase 1 — Âmbito (1–2 semanas)
Escrevam a tarefa como uma frase que alguém possa marcar certa ou errada. Listem as ferramentas com esquemas. Decidam que ações são irreversíveis. Reúnam vinte exemplos reais.
Teste de saída: uma colega que não esteve nas reuniões lê o briefing e avalia corretamente cinco execuções de exemplo.

### Fase 2 — Protótipo (2–3 semanas)
Construam o ciclo mais pequeno que faça a tarefa com ferramentas reais num ambiente de teste. Passem os vossos vinte casos e corrijam o desenho das ferramentas antes do prompt.
Teste de saída: 60% dos vinte casos passam ponta a ponta, e ao lado de cada falha há uma causa identificada.

### Fase 3 — Endurecimento (3–5 semanas)
É aqui que está a maior parte do trabalho real e onde morrem os projetos subfinanciados. Permissões sobre a identidade do utilizador final, portões antes do irreversível, validação de argumentos, rastos legíveis, monitorização, avaliação crescida para cinquenta casos e um modo degradado.
- Autorização verificada no servidor em cada chamada.
- Portão humano antes de cada ação irreversível.
- Tetos de passos e gasto e deteção de repetição.
- Rastos com identificador em cada chamada e retenção decidida de propósito.
- Casos adversariais na avaliação, corridos como qualquer teste.
Teste de saída: 85% no conjunto, 100% no subconjunto de recusas e nenhuma constatação de segurança em aberto.

### Fase 4 — Lançamento (2 semanas, depois contínuo)
Comecem com um público limitado. Leiam execuções todos os dias. Alarguem quando os números aguentarem duas semanas seguidas.
| 1 | Só equipa interna | Rastos, falhas óbvias, erros de ferramentas |
| 2 | 5% do tráfego real | Taxa de escalamento, taxa de sucesso |
| 3–4 | 25% | Custo por tarefa, latência no pico |
| 5+ | Total, se os números aguentarem | Desvio, novas categorias |

Q: Doze semanas parece muito para uma demonstração de três dias.
A: A demonstração funcionou mesmo. As nove semanas restantes são permissões, avaliação, monitorização e caminhos de falha.

Q: As fases podem sobrepor-se?
A: O endurecimento pode começar durante o protótipo. Não comecem o lançamento antes de passar o teste de endurecimento.

Q: E se o protótipo falhar o teste?
A: Olhem para as causas anotadas. Se forem desenho de ferramentas e acesso a dados, corrijam.

## Casos de uso de agentes de IA por setor: o que funciona mesmo
https://aiagentdevelopment.info/pt/guides/casos-de-uso-por-setor
Atualizado a 2026-08-05 · Custo e negócio

- Os agentes ficam onde a tarefa é estreita, há sistema de registo e o arriscado está protegido.
- Reconciliação, triagem e rascunhos internos são as primeiras vitórias mais fiáveis.
- Os projetos encalham por falta de APIs, definição ou responsável — não por limites dos modelos.
- Em setores regulados comecem pelo lado do rascunho e alarguem a autonomia com provas.

As listas de casos de uso leem-se normalmente como listas de desejos. Esta vem do que chega mesmo a produção e lá fica — uma lista muito mais curta e repetitiva do que o marketing sugere.

O padrão é constante entre setores. Uma tarefa estreita com definição clara de concluído, duas ou três ferramentas contra um sistema de registo real, e uma pessoa à frente do que não se desfaz.

### O que funciona, por setor
| Comércio eletrónico | Estado da encomenda, direito a devolução, mudança de morada | Consulta, política, atualização | Reembolsos acima de um limiar |
| Apoio SaaS | Triagem de primeira linha com contexto de conta | Consulta de conta, documentos, ticket | Mudanças de plano, créditos |
| Finanças e operações | Casar faturas com ordens de compra | Ler ERP, analisar documento, marcar | Qualquer pagamento |
| Administração de saúde | Marcações e lembretes | Agenda, leitura de ficha | Tudo o que é clínico |
| Recrutamento | Triagem por critérios explícitos, marcações | Ler ATS, agenda, rascunho de email | Recusas e propostas |
| Logística | Gestão de exceções em atrasos | Rastreio, API da transportadora, aviso | Propostas de compensação |

### Os agentes internos sobre os quais ninguém escreve
As vitórias mais fiáveis são pouco vistosas e internas: reconciliar dois sistemas que divergem, redigir a primeira versão de um relatório recorrente, encaminhar pedidos com o contexto certo e responder a perguntas de política com citação.

### Onde os projetos encalham, em qualquer setor
- Sem sistema de registo com API — o agente não tem chão firme.
- Sem definição partilhada de resultado correto, ninguém pode avaliar.
- Tarefa cheia de juízo com zero apetite de risco: tudo passa por um portão.
- Propriedade difusa: construído pela inovação, necessário às operações, ninguém de piquete.

### Escolher o primeiro
Pontuem candidatos em quatro eixos: volume, repetitividade dos passos, existência de sistema de registo e reversibilidade das ações.
Escolham de propósito algo em que um erro seja embaraçoso e não caro.

Q: Que setor tem as vitórias mais claras?
A: Comércio eletrónico e apoio SaaS.

Q: São úteis a pequenas empresas?
A: Sim, normalmente na forma interna: triagem, rascunhos, reconciliação.

Q: Como estimar o valor antes de construir?
A: Contem o volume, meçam o tempo humano atual e estimem a parte que o agente conclui sem ajuda.

## Medir o ROI de um agente de IA sem enganar-se a si próprio
https://aiagentdevelopment.info/pt/guides/medir-o-roi-dos-agentes
Atualizado a 2026-08-05 · Custo e negócio

- Escrevam a linha de base antes do lançamento — volume, tempo, custo, taxa de erro.
- Contem tarefas concluídas sem pessoas, não desvios nem mensagens.
- Subtraiam custo dos erros e tempo de revisão; é isso que torna o número credível.
- Reportem benefícios qualitativos à parte, não convertidos em dinheiro inventado.

A maioria dos números de ROI de agentes não sobrevive a uma leitura atenta, e a razão é quase sempre a mesma: a linha de base foi reconstruída depois e os erros ficaram fora da conta.

Obter um número honesto não é difícil, mas tem de começar antes do lançamento.

### Escrevam primeiro a linha de base
- Volume: quantas vezes por semana acontece esta tarefa?
- Tempo de tratamento: quanto demora uma pessoa, medido numa amostra?
- Custo horário totalmente carregado.
- Qualidade atual: taxa de erro ou de retrabalho.
- Tempo de espera: quanto espera hoje quem pede, se isso importa.
Uma linha de base reconstruída depois favorece sempre o projeto.

### Métricas que aguentam e métricas que lisonjeiam
| Taxa de desvio | Conta o não respondido como resolvido | Tarefas concluídas sem pessoas |
| Mensagens tratadas | Volume não é valor | Tarefas concluídas ponta a ponta |
| Satisfação nas conversas com o agente | Enviesamento do sobrevivente | Satisfação em todos os contactos |
| Tempo poupado por resposta | Ignora o tempo de revisão | Minutos líquidos após revisão |
| Custo por token | Não é um número de negócio | Custo por tarefa concluída |

### A fórmula, incluindo a parte que se omite
Benefício anual = tarefas concluídas sem pessoas × minutos poupados por tarefa × custo por minuto — menos o custo dos erros introduzidos, menos o tempo de revisão criado. Essa subtração é a parte honesta.
Estimem o custo dos erros explicitamente, mesmo que a olho.

### Quando a resposta honesta é não
Às vezes a aritmética manda parar, e dizê-lo é o mais valioso do exercício. Tarefas de baixo volume raramente pagam uma construção. As cujos resultados têm de ser revistos de qualquer modo só poupam revisão.

Q: Que taxa de conclusão é realista?
A: Sessenta a oitenta por cento de uma tarefa bem delimitada e de grande volume.

Q: Quanto tempo até recuperar?
A: Numa tarefa interna bem escolhida, normalmente seis a doze meses com manutenção incluída.

Q: Como contar valor se o agente só redige?
A: Meçam o tempo da página em branco até ao resultado aprovado, antes e depois.

## Contratar programadores de agentes de IA: o que procurar e como avaliar
https://aiagentdevelopment.info/pt/guides/contratar-programadores-de-agentes
Atualizado a 2026-08-05 · Custo e negócio

- Contratem engenheiros de sistemas que pensam em modos de falha, não especialistas em prompts.
- Filtrem com um briefing: esquemas, paragens, dez casos, portões humanos.
- O conhecimento de frameworks é o que menos prevê sucesso.
- Exijam entrega de prompts, esquemas, avaliação e rastos.

O título é novo, a competência não. Quem constrói agentes que aguentam produção são bons engenheiros de sempre que aprenderam a trabalhar com um componente rápido, capaz e por vezes confiante e errado.

Esta reformulação torna a contratação muito mais fácil. Não procuram uma especialista em prompts. Procuram alguém que pergunte por instinto o que acontece quando a ferramenta não devolve nada.

### O que conta, por ordem
- Engenharia de APIs e integrações: a maior parte do trabalho é falar bem com os vossos sistemas.
- Instinto de teste: perguntam pela avaliação antes de perguntar pelo modelo.
- Pensar em modos de falha: resultados vazios, permissões, tempos esgotados, sucesso parcial.
- Consciência de segurança: privilégio mínimo, injection, auditoria, portões.
- Consciência de custo: explicam para onde vão os tokens sem consultar.
- Familiaridade com modelos: útil, aprende-se em semanas.
- Conhecimento de frameworks: o item menos importante e o mais publicitado.

### Um exercício de noventa minutos que resulta
Deem um briefing curto: um agente que responde a perguntas sobre encomendas e pode emitir reembolsos abaixo de cinquenta euros. Peçam a lista de ferramentas com esquemas, as condições de paragem, dez casos de avaliação e o que fica atrás de um portão humano.
Bons candidatos fazem perguntas sobre permissões e casos limite nos primeiros cinco minutos.

### Perguntas que separam experiência de entusiasmo
| Como sabem que uma alteração ajudou? | Testamos à mão | Um conjunto fixo, antes e depois |
| O que fazem se uma ferramenta não devolver nada? | Repetimos | Um vazio explícito sobre o qual o agente pode agir |
| Como travam a injection? | Dizemos ao modelo para ignorar | Privilégio mínimo, isolamento, portões |
| Porque estava lento o vosso último agente? | O modelo era lento | Seis chamadas em série; paralelizei duas |
| Como escolhem o modelo? | O melhor | Por passo, medido nos nossos casos |

### Agência, freelancer ou interno
Uma agência serve para uma primeira construção com prazo: compram uma equipa que já cometeu os erros habituais, e devem exigir a entrega do conjunto de avaliação e dos esquemas.

Q: É preciso um engenheiro de machine learning?
A: Normalmente não. Isto é engenharia de sistemas contra uma API de modelo.

Q: Que dimensão deve ter a equipa?
A: Dois engenheiros e uma especialista de domínio a tempo parcial cobrem a maioria dos primeiros projetos.

Q: O que deve uma agência entregar?
A: Repositório, prompts, esquemas, conjunto de avaliação com resultados, rastos do último mês e uma nota sobre falhas conhecidas.

## Custo de desenvolver um agente de IA: números reais e o que os move
https://aiagentdevelopment.info/pt/guides/custo-de-desenvolvimento-de-agente
Atualizado a 2026-08-05 · Custo e negócio

- Agentes internos custam normalmente 8–45 mil $; virados ao cliente 35–150 mil $.
- Integrações, avaliação e permissões dominam as horas; os prompts são a rubrica menor.
- O custo de operação é normalmente modesto e reduz-se a metade com trabalho de rotina.
- Orçamentem 15–25% do custo de construção por ano e nomeiem um responsável.

Ninguém orça o vosso projeto a partir de uma página web, mas os intervalos também não são mistério, e a forma da estimativa é notavelmente constante nos projetos que fizemos e revimos.

Os três números de que precisam são construir, operar e manter. As equipas negoceiam com dureza o primeiro, preocupam-se com o segundo e esquecem por completo o terceiro.

### Custo de construção por âmbito
| Assistente interno, 2–3 ferramentas de leitura | 8 000–20 000 $ | Ciclo, ferramentas, recuperação, avaliação pequena |
| Agente interno com escrita | 20 000–45 000 $ | Mais permissões, auditoria, portões |
| Agente de apoio virado ao cliente | 35 000–90 000 $ | Mais escalamento, tom, monitorização, carga |
| Agente dentro do produto | 60 000–150 000 $+ | Mais interface, multi-inquilino, SLA, versionamento |
| Só prova de conceito | 5 000–12 000 $ | Um caminho, sem permissões, não lançável |

### Para onde vão mesmo as horas
A distribuição surpreende quem espera que o projeto seja o modelo. Grosso modo: integrações e camada de ferramentas 30%, avaliação e iteração 20%, permissões, auditoria e segurança 15%, monitorização e ferramentas operacionais 10%, prompts e recuperação 15%, e o ciclo em si cerca de 10%.
Se uma proposta não tem rubrica de avaliação, estão a comprar uma demonstração.

### Operar custa menos do que se teme
Num agente de apoio típico, uma tarefa concluída custa entre uns cêntimos e algumas dezenas de cêntimos em chamadas. A dez mil tarefas por mês é dinheiro real, mas raramente o número dominante face ao trabalho substituído.

### A rubrica esquecida: manutenção
- Descontinuação de modelos: requalificar numa nova versão uma ou duas vezes por ano.
- Deriva de APIs: os sistemas chamados pelas vossas ferramentas mudam sem avisar.
- Manutenção da recuperação: os documentos mudam e um índice velho é pior do que nenhum.
- Crescimento da avaliação: novos utilizadores trazem novas categorias de falha.
- Propriedade: alguém tem de responder quando o agente faz algo estranho.
Orçamentem 15–25% do custo de construção por ano. Um agente é um serviço, não um projeto que acaba.

Q: Porque variam tanto os orçamentos?
A: Porque o briefing raramente é tão concreto quanto parece.

Q: Podemos começar mais pequeno?
A: Sim. Uma tarefa estreita, duas ferramentas de leitura e vinte casos de avaliação ficam muitas vezes em 8 000–15 000 $.

Q: É mais barato fazer internamente?
A: Mais barato em caixa, mais caro em tempo, e só se alguém experiente o assumir.

## Escalar agentes de IA: latência, concorrência e limites de ritmo
https://aiagentdevelopment.info/pt/guides/escalar-agentes-de-ia
Atualizado a 2026-08-04 · Produção e operação

- O estrangulamento é a quota do fornecedor, não os vossos servidores.
- Separem tráfego interativo e de fundo e ponham o segundo em fila.
- Transmitam, mostrem progresso real e devolvam parciais úteis nos tetos.
- Construam o modo degradado atrás de um interruptor antes de um incidente o exigir.

O primeiro pico de tráfego ensina a mesma lição a todas as equipas. Os servidores estão quase parados, a base de dados está bem e tudo está lento — porque cada pedido são várias chamadas de segundos a um fornecedor com quota.

Escalar agentes é, portanto, sobretudo teoria de filas e gestão de expectativas, mais um pouco de planeamento de capacidade.

### Saibam qual dos três limites vos atinge
| 429 do fornecedor | Pedidos ou tokens por minuto | Fila, backoff, distribuição por chaves ou regiões |
| Lento mas sem erros | Chamadas em série por execução | Paralelizar passos independentes |
| Memória ou ligações esgotadas | O vosso serviço | Trabalho de capacidade normal |
| Lento só no pico | Disputa de quota partilhada | Fila com prioridade |

### Ponham em fila tudo o que não é interativo
Dividam o tráfego em duas classes desde o primeiro dia. O trabalho interativo recebe prazo curto, teto de passos apertado e um modelo rápido onde a qualidade o permita. O trabalho de fundo vai para uma fila cuja concorrência controlam.

### Encurtem a espera com honestidade
- Transmitam a resposta à medida que é produzida.
- Mostrem o passo atual em linguagem simples.
- Ao atingir um teto, devolvam o resultado parcial útil e digam o que falta.
- Tirem do caminho crítico tudo o que não bloqueia.
A perceção de latência é tanto produto como engenharia.

### Desenhem o modo degradado antes de precisar
Decidam de antemão o que o agente faz quando o fornecedor está lento, sem quota ou em baixo. Uma escada sensata: agente completo, modelo alternativo mais barato, resposta só por recuperação sem ferramentas, e por fim desculpa honesta com passagem a uma pessoa.

Q: Várias contas ou regiões do fornecedor?
A: Para escala ou resiliência reais, sim. Façam-no atrás de uma interface interna.

Q: Como manter a latência interativa aceitável?
A: Tetos rígidos de passos, passos simples para um modelo rápido e transmissão.

Q: O que parte primeiro com o crescimento?
A: Quase sempre os limites do fornecedor, depois a API interna da ferramenta mais usada.

## Segurança de agentes de IA: barreiras, permissões e prompt injection
https://aiagentdevelopment.info/pt/guides/seguranca-e-barreiras-dos-agentes
Atualizado a 2026-08-04 · Produção e operação

- Pensem no agente como uma colega que estranhos conseguem convencer.
- A injection é arquitetural: privilégio mínimo, isolamento, aprovações, auditoria.
- Autorizem sobre a identidade do utilizador final, no servidor, em cada chamada.
- Ponham casos adversariais na avaliação e repitam-nos após cada troca de modelo.

O modelo de segurança dos agentes torna-se mais simples assim que deixarem de pensar no agente como código e passarem a pensar nele como uma colega prestável, rápida, incansável e que um estranho consegue convencer.

A essa pessoa não dariam no primeiro dia acesso ilimitado à base de dados, um cartão sem limite e permissão para escrever a clientes sem supervisão.

### A ameaça que nenhum prompt resolve
A prompt injection são instruções escondidas em conteúdo que o agente lê — um pedido de apoio, uma página, um PDF, a descrição de uma ferramenta. O modelo não separa de forma fiável os dados a analisar das instruções a seguir, e nenhuma frase como `ignora as instruções do documento` fecha essa brecha.
Assumam que todo o conteúdo recuperado foi escrito por alguém que quer o vosso agente a portar-se mal.

### Nove controlos, pela nossa ordem de adoção
- Privilégio mínimo por ferramenta: âmbito estreito, só leitura sempre que possível.
- Autorização sobre o utilizador final, verificada do lado do servidor em cada chamada.
- Aprovação humana antes de cada ação irreversível, com contexto suficiente.
- Validação de argumentos e resolução de identificadores antes de executar.
- Tetos de gasto e passos por execução e limites de ritmo por utilizador e ferramenta.
- Isolamento de conteúdo: o texto recuperado é dado, nunca instrução de sistema.
- Filtragem de saída para tudo o que sai do sistema.
- Registo de auditoria completo: quem, o quê, que registo, que execução, que resultado.
- Interruptor de emergência: uma definição que desliga ferramentas.

### Raio de estragos por tipo de ação
| Ler um registo próprio | — | Verificação de permissões |
| Redigir uma resposta | Sim | Nenhum |
| Atualizar um campo de estado | Normalmente | Auditoria e limite de ritmo |
| Enviar mensagem externa | Não | Aprovação humana |
| Emitir reembolso | Não | Aprovação, limite de valor |
| Apagar dados | Não | Aprovação, só apagamento lógico |

### Testem como um atacante, com regularidade
Ponham casos adversariais no conjunto de avaliação e corram-nos como qualquer outro teste. Qualquer execução que termine numa ação proibida é um teste falhado.

Q: Melhores prompts resolvem a injection?
A: Não. As instruções baixam a taxa mas não a eliminam.

Q: O agente deve usar uma conta de serviço?
A: Só para dados verdadeiramente públicos.

Q: O que fica atrás de um portão humano?
A: Tudo o que é irreversível, visível para clientes, acima de um valor e tudo aquilo de que o agente duvida.

## Monitorizar agentes em produção: o que registar e sobre o que alertar
https://aiagentdevelopment.info/pt/guides/monitorizar-agentes-em-producao
Atualizado a 2026-08-04 · Produção e operação

- Rastreiem cada execução: contextos, chamadas, versões, motivo de paragem, correções.
- Sigam seis métricas; sucesso e intervenção humana são as que mais contam.
- Alertem sobre ritmo de mudança e anexem um rasto a cada alerta.
- Leiam diariamente uma amostra de execuções reais.

Um serviço clássico está saudável se responde depressa e não lança erros. Um agente pode fazer as duas coisas e estar completamente errado: cada pedido respondido em dois segundos, e todos a citar uma política retirada em março.

Por isso monitorizar agentes é outra disciplina. Assenta em duas coisas: um rasto por execução detalhado o suficiente para reconstituir o que aconteceu, e um punhado de métricas de comportamento cujo movimento significa alguma coisa.

### O que um rasto útil contém
- Um identificador de execução em cada linha de log, chamada e pedido de saída.
- O contexto exato enviado ao modelo em cada passo.
- Cada chamada de ferramenta com argumentos, resultado, duração e desfecho.
- Nome e versão do modelo por chamada e contagem de tokens.
- O motivo de paragem: concluído, teto de passos, teto de gasto, portão humano, erro.
- A saída final e se alguém a corrigiu ou reverteu depois.

### Seis métricas que mexem mesmo
| Taxa de sucesso | Queda sustentada | Mudança de modelo, desvio de dados, API alterada |
| Passos por execução | Subida lenta | Erros de ferramenta repetidos; recuperação degradada |
| Taxa de erro por ferramenta | Pico numa | Sistema a montante partido — não o agente |
| Intervenção humana | A subir | Confiança a cair ou nova categoria |
| Afirmações sem suporte | Qualquer subida | A recuperação falha em silêncio |
| Custo por tarefa | Sobe com volume igual | Contexto inchado ou mais repetições |

### Alertem sobre comportamento, não só sobre erros
Um agente raramente falha ruidosamente. Degrada-se: um pouco mais de passos, um pouco mais de repetições, um pouco mais de escalamentos. Alertem sobre ritmo de mudança numa janela móvel e anexem a cada alerta o rasto de uma execução representativa.

### Amostrem e leiam execuções reais todos os dias
Nenhum painel substitui a leitura. Escolham diariamente algumas execuções e leiam-nas por inteiro.
Acrescentem ao conjunto de avaliação, no mesmo dia, tudo o que surpreender.

Q: Quanto tempo guardar rastos completos?
A: O suficiente para depurar e auditar: normalmente 30–90 dias para contextos completos.

Q: Qual é o alerta mais valioso?
A: Uma subida de escalamentos ou correções humanas.

Q: É preciso uma ferramenta de observabilidade dedicada?
A: Não para começar. Uma tabela de rastos consultável cobre quase tudo.

## Reduzir o custo de um agente sem o piorar
https://aiagentdevelopment.info/pt/guides/reduzir-custos-de-agentes
Atualizado a 2026-08-04 · Produção e operação

- Meçam custo por tarefa concluída, por tipo, antes de otimizar.
- O contexto de que já não precisam costuma ser a maior rubrica.
- Desçam de nível os passos de pouco juízo, um a um, com avaliação.
- Limitem o gasto por execução e alertem ao atingir o teto.

Quando uma fatura de tokens surpreende alguém, o reflexo é passar a um modelo barato em todo o lado e aceitar a perda de qualidade. Raramente é preciso. Nos sistemas que auditámos, a maior parte da despesa vinha de contexto que não precisava de estar lá e de passos que não precisavam do modelo caro.

O método abaixo é aborrecido e eficaz: medir primeiro, depois aplicar quatro alterações por ordem de retorno.

### Meçam por execução antes de mudar seja o que for
O gasto mensal agregado não diz nada acionável. Registem por execução: tokens de entrada e saída, número de chamadas, modelo por chamada e tipo de tarefa. Depois olhem para o custo por tarefa concluída, por tipo.
Contem também as execuções falhadas no denominador.

### As quatro alterações, por retorno
| Podar o contexto: descartar documentos usados, comprimir histórico | 20–40% | Baixo se o objetivo continuar fixado |
| Encaminhar passos baratos para um modelo menor | 20–40% | Baixo, com avaliação por passo |
| Fazer cache do prefixo estável | 10–30% em tráfego repetido | Baixo |
| Reduzir passos: melhores ferramentas, menos repetições | 10–25% | Médio — exige trabalho nas ferramentas |

### A fatura é o contexto
Cada turno reenvia o contexto acumulado, por isso uma execução de oito passos pode pagar o mesmo documento oito vezes. Três hábitos resolvem quase tudo: descartar os excertos recuperados quando o seu passo acaba; comprimir turnos antigos em notas factuais; cortar os resultados das ferramentas aos campos usados.

### Encaminhem por passo, não por gosto
Extração, classificação e formatação raramente precisam do vosso modelo mais forte. Desçam o primeiro grupo um nível, corram o conjunto de avaliação e mantenham a alteração só se os números aguentarem.
- Comecem pelo passo de maior volume e menor juízo.
- Mudem um passo de cada vez e voltem a correr a avaliação.
- Registem que modelo produziu que decisão.
- Ponham um teto de gasto por execução.

Q: Vale a pena o cache?
A: Se as execuções partilham um prefixo longo e estável, sim, e é das vitórias mais baratas.

Q: Afinar para poupar?
A: Só para um passo de grande volume, estreito e estável.

Q: Como evitar uma execução caríssima?
A: Tetos de passos e gasto por execução, deteção de chamadas idênticas repetidas e paragem com resultado parcial.

## Testar agentes de IA: um conjunto de avaliação que vale o custo
https://aiagentdevelopment.info/pt/guides/testar-e-avaliar-agentes
Atualizado a 2026-08-04 · Produção e operação

- Cinquenta casos vossos decidem melhor do que qualquer benchmark.
- Avaliem resultados e efeitos, nunca transcrições exatas.
- Cubram de propósito entradas ambíguas, recusas e resultados vazios.
- Voltem a correr a cada alteração de prompt, ferramenta, modelo ou recuperação.

A pergunta que separa os agentes que vão para o ar dos que apodrecem em piloto é simples: como sabem se a alteração de ontem melhorou alguma coisa? Sem resposta, cada retoque de prompt é um palpite e cada regressão é descoberta por um cliente.

Um conjunto de avaliação é a resposta e não exige plataforma. Cinquenta casos num ficheiro, um script que os corre e uma regra de avaliação por caso dizem mais do que qualquer tabela pública, porque são os vossos casos.

### Como é um caso
Um caso é uma entrada, o estado inicial do mundo e uma expectativa verificável. Essa expectativa quase nunca é uma cadeia exata — um agente pode acertar em várias formulações. Avaliem o resultado: chamou a ferramenta de reembolso com a encomenda 4471; a resposta final tem a data certa; recusou e perguntou, como devia.
Guardem o estado necessário junto do caso.

### Cinquenta casos e de onde vêm
| Pedidos reais frequentes dos registos | 20 | Protege o caminho do dia a dia |
| Falhas passadas conhecidas | 10 | Impede o regresso de regressões |
| Entradas ambíguas | 8 | Deve perguntar, não adivinhar |
| Casos a recusar | 6 | Fora de âmbito, sem permissão, inseguros |
| Resultados vazios ou partidos | 6 | O incidente real mais comum |

### Avaliem resultados, não caminhos
Duas execuções que chegam ao mesmo resultado correto por caminhos diferentes estão ambas certas, e uma suíte que exige uma transcrição falhará sem razão. Verifiquem o que mudou e o que foi dito.

### Quatro números para seguir ao longo do tempo
- Taxa de sucesso no conjunto e em separado no subconjunto a recusar.
- Taxa de afirmações sem suporte.
- Mediana e percentil 95 de custo e latência por execução.
- Taxa de intervenção humana: quantas vezes alguém teve de entrar, e porquê.

### Corram no pipeline e também depois do lançamento
Corram o conjunto a cada alteração de prompts, ferramentas, versão do modelo ou configuração de recuperação. Depois do lançamento continuem a amostrar tráfego real.

Q: Com quantos casos começar?
A: Cinquenta apanham regressões reais e escrevem-se em poucos dias. Vinte chegam para começar.

Q: Pode um modelo avaliar?
A: Pode, com cuidado. Deem critérios explícitos e verifiquem uma amostra à mão.

Q: A avaliação deve bloquear lançamentos?
A: Bloqueiem no subconjunto crítico de segurança. Para qualidade geral sigam a tendência.

## Sistemas multiagente: quando vários agentes batem um só
https://aiagentdevelopment.info/pt/guides/sistemas-multiagente
Atualizado a 2026-08-04 · Construir agentes

- Usem vários agentes só com subtarefas independentes, com ferramentas diferentes e lentas.
- Passem objetos estruturados e um identificador único para todo o pedido.
- Limitem o custo do sistema inteiro, não por agente.
- Avaliem as passagens além dos resultados.

Os diagramas multiagente são o artefacto mais sedutor deste campo. Caixas com cargos, setas entre elas, um coordenador no topo — parece um organigrama, e organigramas dão sensação de progresso.

Depois chega a produção e começam as perguntas: que agente produziu este número errado, porque é que o coordenador o aceitou, e porque é que um pedido custa agora onze chamadas ao modelo.

### As três condições
Vários agentes compensam quando as três se verificam. As subtarefas são mesmo independentes. Cada uma exige ferramentas ou nível de modelo diferentes. E o trabalho é suficientemente lento para que o paralelismo mude a experiência.
Dois agentes que têm de falar constantemente são um agente com um barramento de mensagens caro.

### Topologias e custos
| Supervisor | Um agente delega a especialistas | N+1 ciclos | O supervisor encaminha mal |
| Pipeline | Passagens fixas, etapas especializadas | Previsível | Uma etapa degrada em silêncio |
| Leque paralelo | Mesma tarefa, vários olhares, fusão | O mais alto | A fusão vira estrangulamento |
| Debate ou crítico | Um propõe, outro contesta | 2× por troca | Acordo sem discernimento |
| Quadro negro | Estado partilhado, todos leem e escrevem | Imprevisível | Corridas e ciclos |

### Regras que o mantêm depurável
- Cada agente com contrato escrito: o que recebe, o que devolve e o que nunca faz.
- Passem objetos estruturados entre agentes, nunca prosa livre.
- Um identificador de execução para todo o pedido.
- Limitem o custo de todo o sistema, não por agente.
- Proíbam ciclos sem contador explícito e condição de saída.
- Cada agente pode devolver `não consegui` e o coordenador trata disso.

### Um exemplo que compensa
A pesquisa de concorrência encaixa mesmo: dadas dez empresas, reunir informação pública sobre cada uma. As subtarefas são independentes, cada uma é lenta e a fusão é uma agregação simples.

Q: Um supervisor melhora a precisão?
A: Só se o encaminhamento acertar. 90% à frente de especialistas a 95% dá cerca de 85% ponta a ponta.

Q: O debate entre agentes compensa?
A: Às vezes, em juízos realmente discutíveis onde podem dar provas ao crítico.

Q: Como depurar uma falha multiagente?
A: Com um identificador partilhado em cada chamada e entradas e saídas guardadas por agente.

## RAG para agentes: ancorar respostas sem afogar no contexto
https://aiagentdevelopment.info/pt/guides/rag-para-agentes
Atualizado a 2026-08-04 · Construir agentes

- Exponham a recuperação como ferramenta chamada pelo agente, não como passo fixo inicial.
- Dividam por estrutura, mantenham fragmentos autónomos, anexem títulos e identificadores.
- Palavras-chave mais vetores batem qualquer uma sozinha em tráfego real.
- Exijam citações e permitam um vazio honesto.

A geração aumentada por recuperação é normalmente apresentada como pipeline: incorporar a pergunta, trazer os melhores fragmentos, colar, gerar. Isso funciona para uma caixa de perguntas. Dentro de um agente é a forma errada, porque o agente não sabe do que precisa antes de dar um passo.

A versão que funciona trata a recuperação como uma ferramenta chamada quando o agente decide que precisa de provas.

### Recuperação como ferramenta, não como preâmbulo
Exponham a pesquisa como ferramenta normal com argumento de consulta e um retorno pequeno e estruturado: alguns excertos, cada um com identificador e fonte.
Registem as consultas escritas pelo agente: é a descrição mais honesta do que os vossos utilizadores perguntam.

### As decisões de divisão contam mais do que o modelo de embeddings
- Dividam por estrutura — títulos, secções, itens de lista — não por número fixo de caracteres.
- Mantenham cada fragmento autónomo.
- Anexem título do documento e cabeçalho de secção a cada fragmento.
- Guardem identificador e URL com cada fragmento para poder citar.
- Prefiram poucos fragmentos grandes e significativos.

### O híbrido bate os vetores puros em corpora reais
| Pergunta conceptual | Forte | Fraca | Vetorial |
| Código de produto ou texto de erro exato | Fraca | Forte | Palavras-chave |
| Nome próprio raro | Misto | Forte | Palavras-chave |
| Pergunta de política reformulada | Forte | Fraca | Vetorial |
| Tráfego real no conjunto | Misto | Misto | Ambos, fundidos e reordenados |

### Façam citar e permitam falhar
Dois requisitos fazem a maior parte do trabalho de fiabilidade. Primeiro, cada afirmação vinda da recuperação leva o identificador do excerto. Segundo, a pesquisa tem de poder não devolver nada, e o agente tem de saber que `não encontro isso na nossa documentação` é um resultado correto.

Q: O agente deve procurar sempre antes de responder?
A: Não. Procurar em cada pedido desperdiça latência e enche o contexto.

Q: Quantos excertos devolver?
A: Três a seis bem escolhidos batem vinte.

Q: E se a recuperação não devolver nada útil?
A: Tem de ser um resultado suportado. Devolvam um vazio explícito.

## Memória nos agentes de IA: o que guardar, comprimir e deitar fora
https://aiagentdevelopment.info/pt/guides/memoria-nos-agentes-de-ia
Atualizado a 2026-08-04 · Construir agentes

- Os modelos não recordam; os agentes têm o que voltarem a montar.
- Quatro camadas: objetivo fixado, turnos recentes, factos comprimidos, recuperado fresco.
- Comprimam para factos verificáveis, não para narrativa, e só a um limiar.
- A memória persistente exige proveniência, validade e forma de correção.

Numa chamada a um modelo não existe memória. Cada turno é um pedido novo e o modelo só sabe o que montaram desta vez. Tudo o que as pessoas descrevem como um agente que se esquece é uma decisão do vosso código sobre o que levar consigo.

Aceite isso, o desenho da memória torna-se um problema de engenharia familiar.

### As quatro camadas
| Fixada | Objetivo, restrições, identidade, política | Nunca | 200–500 tokens |
| Recente | Últimos turnos literais, com resultados | Janela deslizante | 2–5 turnos |
| Comprimida | Turnos antigos como notas factuais curtas | Reescrita ao crescer | Menos de 500 tokens |
| Recuperada | Documentos trazidos para este passo | Descartados após uso | Por passo |

### Comprimam factos, não prosa
O erro habitual é resumir turnos antigos como narrativa. Comprimam para os factos que um passo posterior possa precisar: encomenda 4471, estado enviado, reembolso pedido, política 30 dias, ainda sem reembolso.
Comprimam a um limiar, não em cada turno.

### Recuperar não é recordar
Documentos tirados de uma base de conhecimento pertencem ao passo que deles precisou. Mantê-los no contexto depois é o caminho mais rápido para uma execução inchada, cara e distraída.

### Memória persistente entre sessões
Agentes de vida longa acumulam factos úteis sobre uma pessoa ou conta. Guardem-nos de propósito, num pequeno registo estruturado com um passo de escrita explícito.
- Escrevam de propósito — uma chamada de ferramenta, não um efeito lateral.
- Guardem fonte e data ao lado de cada facto.
- Limitem o tamanho e façam expirar o que não se usa.
- Deixem a pessoa ver e corrigir o que está guardado sobre si.

Q: Quanto histórico manter literal?
A: Três a cinco turnos cobrem quase todo o raciocínio sem dominar o contexto.

Q: É preciso base vetorial para a memória?
A: Para recuperar documentos muitas vezes sim. Para o estado de uma execução não.

Q: Como evitar memória persistente desatualizada?
A: Deem a cada facto fonte, data e validade, e façam o recuperado fresco ter prioridade.

## Chamada de ferramentas: desenhar ferramentas que o agente usa bem
https://aiagentdevelopment.info/pt/guides/chamada-de-ferramentas-para-agentes
Atualizado a 2026-08-04 · Construir agentes

- A maioria das falhas é desenho de ferramentas, não prompt.
- Uma ferramenta uma tarefa; restrinjam com tipos, não com prosa.
- Escrevam erros como instruções curtas; tratem o vazio como resultado legítimo.
- Validem cada argumento e resolvam identificadores conforme o utilizador.

Quando um agente se porta mal, o reflexo é reescrever o prompt. Na nossa experiência o prompt é a causa talvez um terço das vezes; nas restantes, as ferramentas foram desenhadas para um programa e não para quem tem de deduzir de nomes e descrições o que uma função faz.

As ferramentas são toda a capacidade do agente de afetar o mundo, e as suas definições fazem literalmente parte do contexto do modelo.

### Sete regras que evitam a maioria das chamadas más
- Uma ferramenta, uma tarefa. `search_orders` e `refund_order` batem um `manage_order` com modo.
- Tipos em vez de prosa. Enumerações, intervalos e formatos fazem o que uma descrição nunca faz.
- Nomes que dizem o que acontece. `send_email_to_customer` é inequívoco; `notify` não.
- Erros como instrução: o que correu mal e o que fazer a seguir, numa frase curta.
- Resultados vazios são resultados. Um não-encontrado explícito bate uma exceção.
- Chaves de idempotência em tudo o que tem efeito.
- Retornos pequenos. Cortem aos campos necessários; 40 KB de JSON compram confusão.

### Antes e depois
| `query(sql)` | Poder ilimitado, não auditável | `get_orders_by_customer(customer_id, limit)` |
| `date: string` | O modelo inventa formatos | `date: string, formato AAAA-MM-DD` |
| `HTTP 500` | Não implica ação, repetido sem fim | `Serviço de encomendas indisponível. Peça ao cliente para tentar depois.` |
| Devolve o registo inteiro | Enche o contexto, dilui a atenção | Devolve seis campos nomeados |
| `update_status(id, status)` | Qualquer estado, qualquer registo | `cancel_order(id)` com verificação de permissões |

### As descrições são prompt
O campo de descrição não é documentação para colegas; é texto que o modelo lê enquanto decide. Digam quando usar a ferramenta e quando não, nomeiem a precondição que importa e deem um exemplo de argumento.
Se duas ferramentas puderem servir o mesmo pedido, o agente escolherá mal às vezes.

### Validem sempre antes de executar
Nunca passem a saída do modelo a uma chamada de sistema sem verificação. Validem argumentos contra o esquema, resolvam identificadores contra registos que este utilizador pode ver, e rejeitem o que não encaixa em vez de o forçar.

Q: Quantas ferramentas são demasiadas?
A: Acima de cerca de dez num ciclo, a precisão de seleção cai e as descrições enchem o contexto.

Q: As ferramentas devem devolver respostas de API em bruto?
A: Não. Devolvam uma forma pequena e estável com os campos necessários.

Q: Como evito argumentos inventados?
A: Restringindo: enumerações em vez de texto livre, formatos explícitos e identificadores que têm de resolver.

## Arquitetura de agentes de IA: os padrões que aguentam produção
https://aiagentdevelopment.info/pt/guides/padroes-de-arquitetura-de-agentes
Atualizado a 2026-08-04 · Construir agentes

- Por omissão: ciclo limitado com condições de paragem explícitas e rasto linear.
- O gateway de ferramentas é o componente mais valioso.
- Planeador–executor dá intenção visível; a crítica reduz afirmações sem suporte.
- Estratifiquem a memória: objetivo, turnos recentes, factos comprimidos, recuperado fresco.

As discussões de arquitetura começam quase sempre pelo lado errado: um diagrama de caixas com nomes de conceitos. A versão útil começa pela falha que querem evitar, porque cada padrão abaixo existe para travar uma tarde má concreta.

Estes seis são aqueles a que voltamos sempre. Combinam-se: um agente em produção é tipicamente um ciclo limitado com gateway de ferramentas, duas camadas de memória e um portão humano.

### 1. O ciclo limitado
O caso base e a vossa opção por omissão. Um ciclo sobre um pequeno conjunto de ferramentas com condições de paragem explícitas: teto de passos, teto de gasto, deteção de repetição e limite de tempo. A virtude é um rasto linear lido de cima a baixo.
Se não conseguem desenhar o agente como um ciclo com uma lista de saídas, ainda não têm arquitetura: têm um prompt ambicioso.

### 2. Planeador–executor com replaneamento
Para tarefas acima de cinco passos, peçam primeiro um plano numerado, executem e replaneiem ao falhar em vez de seguir um plano desatualizado. O ganho não é precisão: é que uma pessoa vê a intenção antes da ação.

### 3. A passagem crítica
Uma segunda chamada revê o rascunho ou a ação proposta contra o objetivo e as provas recuperadas, e pode devolvê-la uma vez. Apanha uma parte real da saída confiante mas sem suporte.
| Ciclo limitado | 0 | Rastreabilidade, controlo de custo | Nunca — é a base |
| Planeador–executor | 1–2 | Intenção visível, auditabilidade | Tarefas abaixo de cinco passos |
| Passagem crítica | 1 por saída revista | Menos afirmações sem suporte | Saídas baratas e reversíveis |
| Gateway de ferramentas | 0 | Permissões, auditoria, limites | Só protótipos |
| Memória em camadas | 0–1 | Pertinência com contexto longo | Execuções curtas |
| Portão humano | 0 | O irreversível fica seguro | Se nada for irreversível |

### 4. O gateway de ferramentas
Não deixem o agente chamar os vossos sistemas diretamente. Ponham à frente de cada ferramenta uma camada que faça quatro coisas: validar argumentos contra um esquema, verificar se este utilizador final pode tocar naquele registo, aplicar um limite de ritmo e escrever uma linha de auditoria com o identificador da execução.

### 5. Memória em camadas
Um histórico indiferenciado é a causa mais comum de um agente que piora ao longo de uma execução. Separem: objetivo e restrições, nunca podados; turnos recentes literais; turnos antigos comprimidos em notas factuais; e conhecimento recuperado, trazido por passo e nunca acumulado.

### 6. O portão humano
Cada ação irreversível fica atrás de uma aprovação explícita com contexto suficiente para decidir em segundos. O portão é uma funcionalidade de produto, não uma limitação.

Q: São precisos os seis padrões?
A: Não. Comecem pelo ciclo limitado e pelo gateway; ambos são quase obrigatórios em tudo o que toca sistemas reais.

Q: A passagem crítica melhora mesmo a precisão?
A: Em tarefas onde o modelo pode produzir respostas plausíveis mas sem suporte, claramente sim.

Q: Onde deve ficar o gateway?
A: No vosso serviço, entre agente e sistemas, com a identidade do utilizador final a atravessá-lo.

## Plataformas no-code ou desenvolvimento à medida: comparação honesta
https://aiagentdevelopment.info/pt/guides/no-code-ou-desenvolvimento-a-medida
Atualizado a 2026-08-04 · Frameworks e modelos

- Plataforma e à medida são fases, não rivais.
- Permissões por utilizador, propriedade do produto e volume empurram para o à medida.
- Provem o fluxo na plataforma e reconstruam só o que o mereceu.
- Exportem prompts, definições e registos desde o primeiro dia.

O debate no-code contra à medida costuma ser travado por quem tem algo para vender. Tendo construído ambos, a nossa opinião é mais monótona e mais útil: são fases, não rivais — e o erro é ficar numa delas mais tempo do que as provas sustentam.

Uma plataforma é a forma mais barata de descobrir o que a vossa tarefa exige. O à medida é como retomam o controlo de permissões, custo unitário e superfície de produto.

### Lado a lado, sem marketing
| Tempo até à primeira versão | Dias | Semanas |
| Forma do custo | Por lugar ou execução, recorrente | Engenharia à frente, depois infraestrutura |
| Acesso a sistemas internos | O que os conectores derem | Tudo o que conseguirem programar |
| Permissões por utilizador final | Normalmente grosseiras | Tão finas quanto construírem |
| Avaliação e testes de regressão | Do fornecedor, por vezes superficiais | Vossos, tão profundos quanto investirem |
| Portabilidade | A configuração vive no fornecedor | Repositório vosso |
| Encaixa quando | Prova de valor, tarefa padrão, equipa pequena | Superfície de produto, permissões reais, volume |

### Quatro perguntas que resolvem depressa
- O agente precisa de permissões por utilizador em dados internos? Se sim, quase sempre à medida.
- O agente faz parte do que vendem? Se sim, à medida.
- Mais do que alguns milhares de tarefas por mês? Façam as contas ao preço por execução.
- Precisam de avaliação e trilho de auditoria próprios? Vejam primeiro o que a plataforma exporta.

### O padrão híbrido que funciona
Provem o fluxo numa plataforma, instrumentem tudo e deixem correr um mês com utilizadores reais. Depois reconstruam só as partes que o mereceram.
Exportem prompts, definições e registos desde o primeiro dia.

Q: O no-code pode ser a resposta definitiva?
A: Sim, para tarefas internas, padrão, de volume moderado e com baixo custo de erro.

Q: O à medida é sempre mais preciso?
A: Não. A precisão vem do desenho das ferramentas, da ancoragem e da avaliação.

Q: Qual é o maior custo escondido?
A: A manutenção. Orçamentem 15–25% do custo de construção por ano e nomeiem um responsável.

## O Model Context Protocol explicado a quem constrói
https://aiagentdevelopment.info/pt/guides/model-context-protocol-explicado
Atualizado a 2026-08-04 · Frameworks e modelos

- O MCP normaliza descoberta e invocação entre cliente de agente e servidor de ferramentas.
- Autenticação, autorização e aprovação continuam vossas.
- Encapsulem capacidades estreitas e apliquem permissões no servidor, por chamada.
- Servidores de terceiros são dependências cujas descrições entram no vosso contexto.

Toda equipa que constrói mais do que um agente escreve o mesmo adaptador duas vezes: ligar a um sistema, descrever o que ele faz e expor essas capacidades ao modelo na forma que o cliente do momento espera. O Model Context Protocol existe para travar essa duplicação.

É genuinamente útil e também mais estreito do que o entusiasmo sugere. O MCP descreve como as capacidades são anunciadas e invocadas. Não decide quem as pode invocar, e confundir as duas coisas é a origem dos incidentes de segurança.

### O que o protocolo normaliza
- Descoberta: o servidor diz ao cliente que ferramentas e recursos oferece, com esquemas.
- Invocação: o cliente chama com argumentos tipados e recebe um resultado estruturado.
- Recursos: conteúdo só de leitura que o cliente puxa para o contexto quando pede.
- Transporte: um formato comum para que cliente e servidor de autores diferentes se entendam.

### O que deliberadamente não faz
O MCP não autentica os vossos utilizadores, não decide que registos cada um pode ler nem se uma ação precisa de aprovação. Isso continua vosso e tem de viver do lado do servidor.
Tratem cada ferramenta MCP como se um chamador confuso ou manipulado a fosse invocar com os piores argumentos plausíveis.

### Onde compensa hoje
| Um sistema interno, vários clientes de agente | Alto — o servidor escreve-se uma vez |
| Assistentes de secretária com contexto local | Alto — o ecossistema nasceu aí |
| Um agente com três ferramentas próprias | Baixo — chamadas diretas são mais simples |
| Ferramentas de terceiros fora do vosso controlo | Médio — prático, mas auditem o servidor |

### Uma forma segura de adotar
- Encapsulem capacidades estreitas, não poder geral: `get_order(id)` em vez de `sql(query)`.
- Apliquem autorização dentro do servidor, por chamada, com a identidade do utilizador final.
- Devolvam erros curtos e honestos — `não encontrado`, `sem permissão`.
- Registem cada invocação com argumentos e identidade.
- Fixem os servidores usados em versões revistas.

Q: Preciso de MCP para construir um agente?
A: Não. Para um agente com poucas ferramentas próprias, chamadas diretas são mais simples.

Q: O MCP é seguro por omissão?
A: É uma norma de transporte e descoberta, não um modelo de segurança.

Q: Os servidores MCP podem ser vetor de injeção?
A: Sim, tanto por descrições que entram no contexto como pelo conteúdo devolvido.

## Escolher um modelo para o agente: capacidade, latência e custo
https://aiagentdevelopment.info/pt/guides/escolher-modelo-para-o-agente
Atualizado a 2026-08-04 · Frameworks e modelos

- Escolham por passo, não um modelo para todo o agente.
- Os benchmarks fazem a lista curta; trinta casos vossos decidem.
- Latência, saída estruturada fiável e comprimento real de contexto são as restrições.
- Fixem versões explícitas e mantenham a avaliação a um comando de distância.

A pergunta que se faz é qual o melhor modelo para agentes. A que produz um bom sistema é: qual o melhor modelo para este passo, nos nossos dados, dentro do nosso orçamento de latência — e a resposta é normalmente mais do que um.

Uma execução não é homogénea. Decidir a ação seguinte exige raciocínio. Extrair três campos de um documento não. Resumir um resultado para o utilizador também não.

### Dividam a execução antes de escolher
| Planear ou escolher ação | Raciocínio, seguir instruções | O mais forte que puderem pagar |
| Chamar ferramenta com argumentos | Saída estruturada fiável | Gama média com esquemas estritos |
| Extrair campos de um resultado | Precisão em texto curto | Pequeno e rápido |
| Classificar ou encaminhar | Consistência | Pequeno ou classificador afinado |
| Escrever a resposta ao utilizador | Tom e clareza | Gama média |

### Os benchmarks fazem a lista curta, não a decisão
Os benchmarks públicos dizem que modelos são plausíveis. Não dizem qual aguenta os vossos esquemas, formatos e clientes difíceis. Construam trinta casos reais dos vossos registos e passem a lista curta por eles.
Incluam casos em que o correto é recusar ou perguntar.

### As três restrições que apertam
- Piso de latência: cada chamada tem um e um agente faz várias.
- Fiabilidade da saída estruturada: 97% de argumentos válidos parte uma execução em dez com três chamadas.
- Comportamento com contexto: contexto longo custa e dilui a atenção.

### Encaminhamento sem projeto de investigação
O encaminhamento de modelos soa sofisticado e costuma ser um ficheiro de configuração. Modelo por omissão por tipo de passo, substituição por ferramenta e registo de que modelo produziu que decisão.

Q: Uso o maior modelo para tudo?
A: Só se não mediram. O passo de decisão costuma beneficiar; extração, classificação e formatação raramente.

Q: Os modelos abertos servem para agentes?
A: Para passos estreitos com esquemas estritos muitas vezes sim.

Q: Com que frequência rever a escolha?
A: Em cada versão que possam adotar e, de resto, a cada dois trimestres.

## Orquestração de agentes: quando é precisa e quando é peso morto
https://aiagentdevelopment.info/pt/guides/orquestracao-de-agentes
Atualizado a 2026-08-04 · Frameworks e modelos

- A orquestração compra durabilidade, idempotência, ramos e retoma.
- Perguntem quanto custa repetir uma execução falhada a meio.
- Fila, linha de estado e chaves de idempotência dão a maior parte do benefício barato.
- Mantenham prompts e esquemas fora das definições de fluxo.

As bibliotecas de orquestração resolvem um problema real: uma execução que dura minutos, toca vários sistemas e tem de sobreviver a um reinício sem repetir o pagamento já feito. Isso é real e desagradável de resolver à mão.

Também não é o problema da maioria dos agentes. Um agente de apoio que responde em quinze segundos e pode recomeçar do zero não precisa de nada disto.

### O que a orquestração dá mesmo
- Estado durável: a execução sobrevive a um deploy, a uma falha ou a uma redução de escala.
- Passos idempotentes: uma repetição não repete um efeito já ocorrido.
- Ramos e junções: verdadeiro controlo de fluxo, não um prompt que o descreve.
- Retoma: pausa para uma aprovação humana que chega quatro horas depois.
- Observabilidade por construção: cada passo é um objeto com estado.

### O teste que decide
Uma pergunta: se esta execução morresse a meio, quanto custaria repeti-la? Se forem uns cêntimos e uns segundos, repitam — precisam de repetição, não de durabilidade. Se for um reembolso duplicado ou vinte minutos de espera de uma pessoa, precisam de passos duráveis e idempotentes.
A maioria das equipas descobre a sua resposta no primeiro deploy a meio de uma execução.

### Onde aparece a complexidade
| Desenvolvimento local | Correr o ficheiro | Mais worker e armazenamento de estado |
| Depuração | Um rasto linear | Correlacionar passos num histórico |
| Deploy a meio da execução | A execução morre | A execução retoma |
| Aprovações humanas | Desajeitado; normalmente novo pedido | Pausa e retoma de primeira classe |
| Custo de um bug no passo 3 | Correr tudo de novo | Correr só o passo 3 |

### O meio-termo que muitos saltam
Não precisam de escolher entre ciclo nu e plataforma completa. Uma fila modesta, uma linha de estado por execução e chaves de idempotência nas duas ferramentas com efeitos cobrem talvez oitenta por cento do benefício.

Q: Posso usar orquestração num agente de conversa simples?
A: Podem, e funciona, mas pagam diariamente em atrito no desenvolvimento local por um benefício que raramente acionam.

Q: Basta uma fila de mensagens?
A: Muitas vezes sim. Fila mais linha de estado por execução mais chaves de idempotência cobrem as falhas habituais.

Q: Como manter execuções distribuídas depuráveis?
A: Com um identificador estável em cada linha de log, chamada e pedido de saída.

## Escolher um framework de agentes: o que conta mesmo
https://aiagentdevelopment.info/pt/guides/escolher-framework-de-agentes
Atualizado a 2026-08-04 · Frameworks e modelos

- Os rankings envelhecem depressa; as perguntas de adequação não.
- Três acordos: SDK do fornecedor, biblioteca de orquestração, plataforma gerida.
- Prompts, esquemas, avaliação e formato de rastos vivem no vosso repositório.
- Construam o mesmo pequeno agente duas vezes e meçam a facilidade de depuração.

Qualquer artigo que ordene frameworks de agentes por nome está desatualizado antes de ser indexado. Estas bibliotecas reescrevem as suas abstrações centrais a cada poucas versões, e o que hoje ganha uma comparação pode ter mudado quando o vosso projeto for para o ar.

Por isso este guia faz algo mais duradouro: lista as oito perguntas que determinam se daqui a seis meses ainda estarão contentes com a escolha, e explica o que custa cada resposta.

### As oito perguntas, por ordem de importância
- Consigo ler o ciclo? Sem o ficheiro onde a saída do modelo vira chamada de ferramenta, não se depura uma má execução.
- O que acontece numa falha de ferramenta — chega-me, ou é repetida invisivelmente com outro prompt?
- O meu prompt é o prompt do framework? Texto de sistema que não escreveram surpreende numa auditoria.
- O estado pode ser persistido e retomado, ou uma falha perde a execução?
- Como se definem as ferramentas e posso reutilizar essas definições fora?
- Como é a história das atualizações — houve renomeações centrais nas duas últimas versões?
- Posso trocar de modelo sem trocar de framework?
- Quanto acrescenta ao arranque a frio e a cada turno?

### Três categorias, três acordos diferentes
| SDK do fornecedor e ciclo próprio | Visibilidade total, poucas dependências | Repetições, estado e persistência escrevem vocês | Um agente, poucas ferramentas, muita depuração |
| Biblioteca de orquestração | Estado durável, ramos, repetições, retoma | Alguma visibilidade; agitação nas versões | Fluxos longos ou multipasso |
| Plataforma gerida | Alojamento, rastos, avaliação, interface | Portabilidade; preço por lugar ou execução | Equipa pequena, tarefa padrão, prova rápida |

### Escrevam vocês o que deve continuar vosso
Escolham o que escolherem, quatro ativos devem viver no vosso repositório numa forma que nenhum framework possui: os prompts, as definições de ferramentas com os esquemas JSON, o conjunto de avaliação e o formato dos rastos.

### O teste que ninguém faz
Antes de decidir, construam duas vezes o mesmo pequeno agente: uma com o favorito e outra com o SDK do fornecedor e um ciclo escrito à mão. Não estão a medir precisão — será parecida. Estão a medir quanto tempo levou, quão legível é o rasto e quão fácil foi descobrir porque falhou o caso sete.
Guardem a versão feita à mão: será a referência quando precisarem de provar se uma estranheza vem do prompt ou do framework.

Q: É preciso framework para um primeiro agente?
A: Não. Um primeiro agente com três ferramentas é um ciclo, uma lista de esquemas e uma condição de paragem.

Q: Uma plataforma gerida é uma armadilha?
A: Não, se mantiverem prompts, esquemas e avaliação portáteis.

Q: Quanto é que o framework afeta a precisão?
A: Muito menos do que se pensa. A precisão vem do desenho das ferramentas, da ancoragem e da avaliação.

## Quando não usar um agente de IA (e o que construir em vez disso)
https://aiagentdevelopment.info/pt/guides/quando-nao-usar-um-agente-de-ia
Atualizado a 2026-08-04 · Fundamentos

- Sequências fixas querem um pipeline com um passo de modelo, não um agente.
- Aritmética, correspondência exata e latência abaixo do segundo não encaixam.
- Sem conjunto de avaliação não saberão se uma alteração ajudou.
- Ações irreversíveis e valiosas ficam atrás de um portão humano; o agente redige.

Construímos agentes para viver, e é precisamente por isso que esta página existe. A forma mais rápida de estragar a confiança de uma equipa nesta tecnologia é pôr um agente numa tarefa que não precisava dele, vê-lo acertar 94% onde um script acertava 100%, e passar o trimestre seguinte a defendê-lo.

Abaixo, as seis situações em que dizemos que não, e o que sugerimos em vez disso.

### 1. Os passos nunca mudam
Se a sequência é fixa — buscar ficheiro, validar colunas, transformar, carregar, notificar — nada precisa de decidir o passo seguinte, porque nada decide. Escrevam o pipeline. Se um passo exige juízo, chamem o modelo para esse passo e mantenham o resto determinístico.
É o excesso de construção mais comum que vemos.

### 2. A tarefa é aritmética ou correspondência exata
Totais, reconciliações, impostos, regras de elegibilidade com limiares publicados: têm respostas certas e implementações existentes. Um modelo pode explicar um cálculo lindamente e mesmo assim errar de vez em quando.

### 3. Orçamento de latência abaixo de um segundo
Um agente que planeia, chama duas ferramentas e responde não o faz de forma fiável abaixo de um segundo. Se estão dentro de um checkout ou de uma pesquisa enquanto se escreve, tirem o trabalho do caminho crítico.

### 4. Ninguém sabe dizer como é uma execução correta
Se a equipa não consegue produzir vinte exemplos da tarefa bem feita, não têm conjunto de avaliação — e sem ele não há como saber se uma alteração ajudou.
Vinte exemplos rotulados é uma fasquia deliberadamente baixa.

### 5. Todas as ações são irreversíveis e valiosas
Transferências, assinaturas de contrato, eliminações em produção. Podem pôr um agente à frente — como redator que monta o caso e o entrega a uma pessoa.

### 6. Os dados necessários não estão acessíveis
Um agente vale o que valem as suas ferramentas, e estas valem o que valem as vossas APIs. Se a informação vive num sistema sem API de leitura, o agente fica reduzido a adivinhar. Reparem primeiro o acesso.

Q: Então quando é o agente claramente a ferramenta certa?
A: Quando o passo seguinte depende mesmo do que o anterior devolveu, quando podem ser precisas várias ferramentas numa ordem não fixável, e quando hoje alguém faz isto a consultar e decidir.

Q: Já temos um agente num pipeline fixo. Deitamos fora?
A: Não necessariamente: meçam primeiro.

Q: Um agente pode fazer parte de um sistema determinístico?
A: Sim, e é muitas vezes o melhor desenho.

## Tipos de agentes de IA: cinco formas que cobrem quase tudo
https://aiagentdevelopment.info/pt/guides/tipos-de-agentes-de-ia
Atualizado a 2026-07-28 · Fundamentos

- Cinco formas: respondedor, ciclo único, planeador–executor, router, agentes a colaborar.
- Cada degrau compra capacidade gastando rastreabilidade e custo.
- A maioria dos agentes em produção é um ciclo com três a seis ferramentas.
- Subam só com um rasto que prove a falha estrutural da forma simples.

As taxonomias académicas — reflexo, baseado em modelo, em objetivos, em utilidade — servem para exames e quase nada para decidir o que construir na segunda-feira. Na prática conta a forma do fluxo de controlo, porque determina custo, latência e dificuldade de depuração.

Cinco formas cobrem quase todos os agentes que entregámos ou revimos. Formam uma escada de complexidade, e o erro caro mais comum é começar dois degraus acima.

### As cinco formas, da barata à difícil
| Respondedor com ferramentas | Uma chamada, talvez uma ferramenta | Consultas, enriquecimento, classificação | Mal chega a agente; tudo bem |
| Agente de ciclo único | O modelo cicla sobre poucas ferramentas | Apoio, pesquisa, triagem | Divagar em tarefas longas |
| Planeador–executor | Planear, executar, replanear ao falhar | Operações multipasso, migrações | Planos desatualizados após o terceiro passo |
| Router com especialistas | Um router escolhe um subagente estreito | Domínios amplos com competências distintas | Erros de encaminhamento acumulam |
| Agentes a colaborar | Vários agentes trocam resultados | Pesquisa realmente paralela | Custo, latência, falhas irrastreáveis |

### Comecem um degrau abaixo do que parece certo
O agente de ciclo único resolve muito mais problemas reais do que a fama sugere e tem uma enorme vantagem: um rasto linear que se lê de cima a baixo. Cada degrau acima compra capacidade gastando rastreabilidade.

### Que degrau precisam mesmo
- Uma consulta e uma decisão: respondedor com ferramentas.
- Poucas ferramentas e ordem variável: um ciclo.
- Uma pessoa escreveria primeiro uma lista de verificação: planeador–executor.
- O trabalho divide-se em competências distintas com ferramentas distintas: router.
- Duas subtarefas realmente independentes e ambas lentas: colaborar pode compensar.

### A armadilha do especialista
Os routers ficam bem no diagrama e portam-se mal nas margens. O router só vê o pedido, não o que os especialistas encontrariam, portanto tem de adivinhar.
Meçam a precisão do encaminhamento em separado. Um router a 90% à frente de especialistas a 95% dá 85% ponta a ponta.

Q: Os sistemas multiagente são melhores do que um só?
A: Só quando as subtarefas são mesmo independentes e cada uma exige ferramentas ou níveis de modelo diferentes.

Q: Que forma é mais comum em produção?
A: O agente de ciclo único com três a seis ferramentas e um portão humano à frente do irreversível.

Q: Quando subir um degrau?
A: Quando tiverem o rasto de uma falha real que a forma simples não consegue resolver estruturalmente.

## Como funcionam os agentes de IA: o ciclo, passo a passo
https://aiagentdevelopment.info/pt/guides/como-funcionam-os-agentes-de-ia
Atualizado a 2026-07-28 · Fundamentos

- Um turno: montar contexto, decidir, validar, executar, registar, verificar paragem.
- O modelo só vê o que voltarem a pôr — a poda causa quase todas as estranhezas.
- Escrevam os erros como instruções acionáveis, não como diagnósticos.
- Os rastos são a principal ferramenta de depuração; construam-nos antes da segunda funcionalidade.

Os agentes parecem magia nas demonstrações e canalização em produção. A razão é que a parte interessante não é a saída do modelo mas o ciclo que a consome, e esse ciclo é curto o suficiente para se ler de uma assentada.

Este guia leva um único pedido de ponta a ponta: o que o modelo vê em cada turno, o que o vosso código faz com o resultado, como volta uma ferramenta que falhou e o que para o ciclo.

### Uma volta do ciclo, por ordem
- Montar o contexto: objetivo, definições de ferramentas, factos recuperados e histórico podado.
- Pedir ao modelo o passo seguinte: responde ou pede uma chamada com argumentos.
- Validar os argumentos antes de fazer o que quer que seja — tipos, intervalos e se este chamador pode tocar naquele registo.
- Executar a ferramenta. Apanhar falhas e traduzi-las em mensagens curtas e factuais.
- Acrescentar chamada e resultado ao histórico e verificar as condições de paragem.
- Repetir, ou devolver a resposta final com o que o agente realmente fez.

### O que o modelo vê e não vê
O modelo não guarda nada do turno anterior além do que voltarem a pôr no contexto. Esse único facto explica quase todo o comportamento confuso. Se o agente esquece uma restrição de há quatro passos, foi a vossa poda que a retirou.
Escrevam os erros das ferramentas como instruções, não como diagnósticos. Não `HTTP 404`, mas `Não há cliente com este ID. Peça confirmação do número de encomenda.`

### Parar: a parte que as demonstrações nunca mostram
| Teto de passos | 8–15 chamadas | Devolver trabalho parcial com explicação |
| Teto de gasto | Custo fixo por execução | Parar e registar para revisão |
| Relógio | 30–120 s em uso interativo | Entregar com o que se sabe |
| Deteção de repetição | Mesma chamada e argumentos duas vezes | Forçar outro ramo ou parar |
| Portão humano | Qualquer ação irreversível | Pausar e pedir aprovação |

### Ler um rasto quando algo corre mal
Um rasto é o registo ordenado de cada contexto, decisão, chamada e resultado de uma execução. É a única ferramenta de depuração que conta e a primeira a construir. A pergunta nunca é porque é que o modelo é mau, mas que turno correu mal primeiro e o que o modelo podia ver nesse momento.

Q: Quantos passos antes de parar?
A: Em tarefas interativas, um teto de oito a doze chamadas cobre quase tudo o que é legítimo.

Q: Planear primeiro ou decidir passo a passo?
A: Tarefas curtas correm bem passo a passo. Acima de cinco passos, um plano explícito torna a execução auditável.

Q: Porque é que o meu agente repete a mesma chamada falhada?
A: Quase sempre porque a mensagem de erro não traz informação acionável.

## Agente de IA ou chatbot: do que o vosso problema precisa mesmo
https://aiagentdevelopment.info/pt/guides/agente-de-ia-ou-chatbot
Atualizado a 2026-07-21 · Fundamentos

- Chatbots respondem; agentes mudam sistemas fora da conversa.
- A diferença fixa orçamento, testes e o círculo de aprovação.
- A maioria dos projetos bem-sucedidos é híbrida: recuperação mais duas ou três ferramentas.
- Registem o que os utilizadores pedem sem obter — é o vosso roteiro.

A maioria das equipas que pede um agente descreve um chatbot, e várias que pedem um chatbot descrevem um agente. O rótulo importa porque, além da caixa de texto, os dois quase nada têm em comum: falhas diferentes, testes diferentes, aprovações diferentes, curvas de custo diferentes.

A linha divisória é simples. O software precisa de mudar algo fora da conversa? Se não — explica, resume, redige, procura — querem um chatbot, provavelmente com recuperação, e estarão online em semanas. Se sim — marca, reembolsa, atualiza, envia — querem um agente e planeiam em meses, porque o trabalho interessante está nas permissões e nos caminhos de recuperação.

### A comparação honesta
| O que produz | Texto para ler | Alterações num sistema, mais texto |
| Pior falha realista | Resposta errada sobre a qual se age | Ação errada já executada |
| Testes | Qualidade da resposta num conjunto | Correção do resultado em execuções inteiras |
| Tempo típico de construção | 2–6 semanas | 2–4 meses até produção |
| Quem aprova | Conteúdo e apoio | Também segurança, dados e dono do sistema |
| Custo recorrente | Tokens e manutenção de conteúdo | Deriva das integrações e manutenção da avaliação |

### Sinais de que querem um chatbot
- A saída útil é uma explicação, um resumo ou um rascunho que alguém revê.
- O vosso conhecimento muda mais vezes do que os processos.
- Não há uma API onde se sintam à vontade a deixar software escrever.
- O valor é o desvio: menos pedidos fáceis a chegar a pessoas.

### Sinais de que querem um agente
- Quem lê a resposta faz depois cinco cliques noutro sistema.
- É preciso consultar algo antes de saber qual é o passo seguinte.
- O sucesso é uma transação concluída, não um leitor satisfeito.
- Alguém já segue uma lista de verificação, e essa lista ramifica.

### O híbrido que costuma ganhar
O que sobrevive ao contacto com utilizadores reais raramente é puro: um chatbot capaz de chamar duas ou três ferramentas escolhidas, com um portão humano à frente de tudo o que é irreversível.
Instrumentem primeiro o chatbot: registem o que as pessoas pedem e ele não sabe fazer. Esse registo é o vosso roteiro de ferramentas.

Q: Posso transformar um chatbot em agente mais tarde?
A: Sim, e costuma ser o caminho mais barato.

Q: Um chatbot é sempre mais barato?
A: Por pedido quase sempre. Por resultado muitas vezes não.

Q: Qual é mais arriscado num negócio regulado?
A: Claramente o agente, porque age. Isso significa que portões de aprovação e caminhos de reversão fazem parte da construção.

## O que é um agente de IA? Uma definição útil para quem constrói
https://aiagentdevelopment.info/pt/guides/o-que-e-um-agente-de-ia
Atualizado a 2026-07-21 · Fundamentos

- Um agente de IA decide, age através de ferramentas reais, observa e decide de novo.
- A engenharia está no ciclo e nos contratos das ferramentas; o modelo é um componente.
- Sequências fixas são fluxos de trabalho: mais baratos, mais previsíveis e muitas vezes a resposta certa.
- A autonomia escolhe-se por ação: só rascunho, só reversível, sandbox ou sem limites.

A palavra agente foi esticada até cobrir tudo: de um prompt com um nome bonito a um sistema distribuído com escala de piquete própria. Não é um problema de vocabulário, é de orçamento: as equipas aprovam uma coisa e recebem outra.

Esta é a definição que usamos ao delimitar trabalho, e é deliberadamente estreita. Um agente de IA é software em que um modelo de linguagem escolhe o passo seguinte, chama uma ferramenta real para o dar, lê o que voltou e escolhe de novo — até cumprir um objetivo ou até um limite o travar. Se nada no vosso sistema chama uma ferramenta, têm um gerador de texto muito bom. Se a sequência está fixada de antemão, têm um fluxo de trabalho com um modelo numa das caixas. Ambos são legítimos. Nenhum precisa de orçamento de agente.

### O produto é o ciclo, não o modelo
Todo agente são os mesmos três movimentos repetidos: decidir, agir, observar. O modelo contribui apenas com o decidir. Tudo o resto — que ferramentas existem, como os seus erros são formulados, que estado sobrevive entre iterações, quando o ciclo deve parar — é software comum que escrevem e pelo qual respondem. Equipas convencidas de que o produto é o modelo passam o tempo em prompts e admiram-se com a falta de fiabilidade. As que tratam o ciclo como produto trabalham contratos de ferramentas e condições de paragem, e ficam com algo depurável numa tarde má.
Teste útil: se tirassem o modelo e pusessem uma pessoa a ler a mesma informação, o resto do sistema ainda faria sentido? Se não, o software à volta é fino demais.

### O que separa um agente daquilo com que é confundido
| Chatbot | Ninguém — responde | Não | Resposta errada ou inventada |
| Fluxo com um passo LLM | Quem desenvolve, à partida | Sim, em ordem fixa | Parte com entradas fora do fluxo |
| Agente | O modelo, em execução | Sim, escolhidas na hora | Divaga, cicla, age sobre dados maus |
| Sistema multiagente | Vários modelos e um coordenador | Sim | Tudo acima, mais difícil de rastrear |

### As quatro partes de qualquer agente real
Tirem os nomes de frameworks e todo agente em produção com que trabalhámos contém as mesmas quatro partes.
- Um objetivo verificável: uma frase que alguém possa marcar certa ou errada.
- Uma superfície de ferramentas: as funções concretas, com argumentos tipados e erros honestos.
- Um portador de estado: o que a iteração seguinte pode ver da anterior.
- Condições de paragem: teto de passos, teto de gasto e uma regra para passar a uma pessoa.

### A autonomia é um botão rotativo, não um interruptor
A decisão interessante não é usar ou não um agente, mas quanta corda lhe dar. Na prática há quatro posições, e os projetos que correm bem começam mais à esquerda do que a demonstração sugere: o agente redige e uma pessoa envia; o agente age no reversível e pergunta no irreversível; o agente age livre numa sandbox com teto de gasto; o agente age livre em produção. Cada passo à direita multiplica valor e raio de estragos.

### Onde a definição se paga
Ser rigoroso poupa em três pontos. Ao delimitar: cinco chamadas de API fixas com um passo de resumo são um fluxo, e construí-lo como agente acrescenta um indeterminismo desnecessário. Ao estimar: agentes custam mais porque a superfície de falha é maior. Ao avaliar: só se testa bem um agente aceitando que a mesma entrada pode seguir caminhos diferentes.
Se alguém pede um agente, perguntem que decisão o software deve tomar sozinho. Se não houver nenhuma, acabaram de poupar três meses.

Q: Um chatbot é um agente de IA?
A: Com esta definição, não. Um chatbot responde dentro da conversa; um agente age em sistemas fora dela.

Q: Um agente tem de ser autónomo?
A: Tem de escolher o próprio passo seguinte, o que não é o mesmo que agir sem supervisão.

Q: É preciso um framework?
A: Não. O agente útil mais pequeno é um ciclo, uma lista de definições de ferramentas e uma condição de paragem.