---
term: 'Agente de IA'
seoTitle: 'Agente de IA: Loop ReAct, Tools, Confiabilidade, Segurança'
headline: 'O que é um agente de IA?'
slug: agente-de-ia
category: ai-modern-stack
shortDefinition: 'Um agente de IA é um sistema guiado por LLM que persegue um objetivo em loop: raciocina, chama uma tool, observa o resultado e repete.'
relatedTerms:
  - llm-api
  - model-context-protocol-mcp
  - cloud-code-serverless-functions
  - access-control-lists-acl
contrastsWith:
  - llm-api
aboutTerms:
  - 'O Loop do Agente (ReAct)'
  - 'Tools & Function Calling'
  - 'Memória do Agente'
faq:
  - question: 'O que é um agente de IA em termos simples?'
    answer: 'Um sistema de software que usa um modelo de linguagem para descobrir e executar sozinho um objetivo de múltiplos passos — planejando, usando tools e tomando ações em vez de apenas conversar. A diferença para um chatbot é a autonomia: ele decide a própria sequência de passos e age sobre o mundo através de tools.'
  - question: 'Qual a diferença entre agente e chatbot?'
    answer: 'Um chatbot responde — devolve uma mensagem e para. Um agente age — raciocina sobre o objetivo, decide quais tools usar, as chama, observa os resultados e continua até a tarefa terminar. Um chatbot fala sobre reembolsar o seu pedido; um agente reembolsa.'
  - question: 'Como funciona o loop do agente?'
    answer: 'Receba um objetivo, raciocine sobre o próximo passo, chame uma tool, observe o resultado, raciocine de novo — repita até terminar ou até bater um limite de passos ou de custo. Esse ciclo raciocinar-agir-observar é o padrão ReAct, e é o que torna um agente agêntico em vez de conversacional.'
  - question: 'O que são tools e function calling?'
    answer: 'Tools são funções externas — chamadas de API, consultas ao banco de dados, execução de código — que o agente pode invocar. Function calling é o mecanismo: o modelo emite uma chamada JSON estruturada nomeando uma tool e seus argumentos, o seu código a executa e o resultado volta para o modelo. O modelo nunca executa a tool; ele apenas a solicita.'
  - question: 'O que é a memória de um agente?'
    answer: 'Dois tipos. A memória de curto prazo é o que cabe na janela de contexto (context window) — os passos recentes e o estado de trabalho. A memória de longo prazo é conhecimento persistido num banco de dados ou vector store e recuperado entre sessões. O loop precisa das duas: a janela para raciocinar agora, o store para lembrar depois.'
  - question: 'Agentes de IA são confiáveis e prontos para produção?'
    answer: 'Passos individuais costumam ser confiáveis; cadeias longas, não. Se cada passo tem 95% de sucesso, dez passos têm cerca de 60% e vinte, cerca de 36% — os erros se compõem. Agentes de produção mantêm cadeias curtas, verificam resultados, colocam ações irreversíveis atrás de aprovação humana e restringem o que as tools podem fazer.'
  - question: 'Quando não usar um agente de IA?'
    answer: 'Quando a tarefa é determinística e bem definida, um workflow comum ou código comum é mais barato, mais rápido e mais confiável. Agentes só justificam sua complexidade quando o caminho não pode ser roteirizado de antemão — adicione autonomia quando ela comprovadamente melhora o resultado, não por padrão.'
  - question: 'Como o MCP se relaciona com agentes de IA?'
    answer: 'O Model Context Protocol é um padrão aberto para como um agente descobre e chama tools e dados, substituindo integrações artesanais por uma interface comum. O MCP é o encanamento entre o agente e as suas tools; as tools em si continuam sendo as funções do seu backend, fazendo o trabalho de verdade.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'ReAct: Synergizing Reasoning and Acting in Language Models (Yao et al., 2022)'
    url: 'https://arxiv.org/abs/2210.03629'
  - name: 'Building Effective Agents — Anthropic'
    url: 'https://www.anthropic.com/engineering/building-effective-agents'
  - name: 'LLM-Powered Autonomous Agents — Lilian Weng'
    url: 'https://lilianweng.github.io/posts/2023-06-23-agent/'
  - name: 'Confused Deputy Attacks on Autonomous AI Agents — Cloud Security Alliance'
    url: 'https://cloudsecurityalliance.org/'
  - name: 'AI agent — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/AI_agent'
cta:
  title: 'Seu backend é o guardrail do agente'
  text: 'No Back4app, as tools de um agente são funções Cloud Code que rodam sob a sessão do usuário — as ACLs decidem o que o agente pode tocar, então um agente sequestrado não consegue exceder as permissões do próprio usuário.'
  linkText: 'Comece grátis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-08-21'
translationKey: ai-agent
---

**Um agente de IA é um sistema guiado por LLM que persegue um objetivo em loop: raciocina, chama uma tool, observa o resultado e repete.** Uma [chamada simples de LLM](/glossary/pt/api-de-llm/) responde e para; um agente envolve essa chamada num loop de controle com **tools** (funções que ele pode invocar), **memória** (estado entre os passos) e **autonomia** suficiente para escolher a própria sequência de ações. A virada de chave para quem desenvolve backend é o fato mais simples e menos dito sobre agentes: **as "tools" de um agente são os seus endpoints de backend** — quando um agente "usa uma tool", ele está chamando uma API que você escreveu, o que faz do seu backend, e não do prompt, o lugar onde a segurança realmente mora.

## Principais pontos

| Pergunta | Resposta |
| --- | --- |
| O loop | Raciocina → age (chama uma tool) → observa → repete até terminar (ReAct) |
| As quatro partes | Modelo (raciocínio) · tools (ações) · memória (estado) · orquestração (o loop) |
| vs. um chatbot | Um chatbot *fala* sobre a tarefa; um agente a *executa* |
| A verdade dura | A confiabilidade se compõe *para baixo* — 95%/passo é ~60% em 10 passos |
| A fronteira de segurança | O backend impõe o que as tools podem fazer — não o bom comportamento do modelo |

## Como funciona o loop de raciocínio de um agente de IA (ReAct)

```text
OBJETIVO: "Reembolse meu último pedido e me envie a confirmação"

  ┌────────────────────────────────────────────────┐
  │ 1 REASON   modelo: "qual é o último pedido?"     │
  │ 2 ACT      chama tool: find_orders(user, last=1) │
  │ 3 OBSERVE  resultado: pedido #1187, $42, entregue│
  │ 4 REASON   "elegível — reembolsar"               │
  │ 5 ACT      chama tool: refund_order(1187)        │◄─ cada ACT atinge
  │ 6 OBSERVE  resultado: reembolsado                │   o SEU backend
  │ 7 REASON   "agora enviar o e-mail"               │
  │ 8 ACT      chama tool: send_email(...)           │
  │ 9 REASON   "pronto" → resposta final             │
  └────────────────────────────────────────────────┘

O modelo nunca executa uma tool. Ele SOLICITA uma (nome + argumentos);
seu código a executa e devolve o resultado para o próximo passo de raciocínio.
```

As tools desse loop, no backend — com escopo, com permissões, rodando como o usuário:

**JavaScript:**

```javascript
// JavaScript — Cloud Code (cloud/main.js)
// An agent's "tool" is a backend function — scoped, permissioned, auditable
Parse.Cloud.define('refundOrder', async (req) => {
  // Runs under the CALLING USER's session — ACLs gate everything.
  // A hijacked agent can't exceed what this user may already do.
  const order = await new Parse.Query('Order').get(req.params.orderId);
  // beforeSave/ACL checks apply: not your order → this throws, agent or not
  if (order.get('amount') > 100) throw 'Refunds over $100 need human approval';
  order.set('status', 'refunded');
  await order.save();
  return { refunded: order.id }; // the tool result the model reasons over next
});
// The backend, not the prompt, is the security boundary.
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// The agent loop runs server-side; the tools it may call are YOUR functions
final result = await ParseCloudFunction('runAgent')
    .execute(parameters: {'goal': 'Refund my last order and email me'});
print(result.result);
// The agent reasoned, chose the refundOrder tool, and called it —
// but the ACLs on Order decided whether it was ALLOWED to succeed.
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
// The agent loop runs server-side; the tools it may call are YOUR functions
let result: [String: Any] = try await Cloud.run(
    name: "runAgent",
    parameters: ["goal": "Refund my last order and email me"])
print(result)
// The agent reasoned, chose the refundOrder tool, and called it —
// but the ACLs on Order decided whether it was ALLOWED to succeed.
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
// The agent loop runs server-side; the tools it may call are YOUR functions
val params = mapOf("goal" to "Refund my last order and email me")
val result = ParseCloud.callFunction<Map<String, Any>>("runAgent", params)
println(result)
// The agent reasoned, chose the refundOrder tool, and called it —
// but the ACLs on Order decided whether it was ALLOWED to succeed.
```

## Os quatro componentes centrais de um agente de IA

```mermaid
flowchart LR
  accTitle: Os quatro componentes de um agente de IA
  accDescr: Um agente de IA combina um modelo de linguagem para raciocinar, tools que ele pode invocar para agir, memória de curto e longo prazo para o estado e um loop de orquestração que percorre raciocínio, ação e observação até alcançar o objetivo. As tools são funções e APIs do backend.
  M["Modelo<br/>(núcleo de raciocínio)"] --> O["Loop de orquestração<br/>raciocina → age → observa"]
  T["Tools<br/>(sua API / funções)"] --> O
  MEM["Memória<br/>curto prazo (janela)<br/>longo prazo (banco de dados)"] --> O
  O -->|"chamadas de tool"| BE[("Seu backend<br/>+ dados")]
  BE -->|"resultados"| O
```

A [decomposição canônica](https://lilianweng.github.io/posts/2023-06-23-agent/) é modelo + planejamento + memória + uso de tools, mas a versão operacional é mais simples: um **modelo** raciocina, **tools** agem (e elas são funções do backend), a **memória** guarda o estado — curto prazo na [janela de contexto](/glossary/pt/api-de-llm/), longo prazo num [banco de dados ou vector store](/glossary/pt/banco-de-dados-vetorial/) — e o **loop de orquestração** amarra tudo, baseado no [padrão ReAct](https://arxiv.org/abs/2210.03629) de intercalar raciocínio e ação.

## Agente vs. chatbot vs. chamada de LLM vs. workflow

| | Chamada simples de LLM | Chatbot | Workflow | Agente de IA |
| --- | --- | --- | --- | --- |
| Faz | Responde uma vez | Conversa | Executa passos fixos | Escolhe os próprios passos |
| Fluxo de controle | Nenhum | Turnos de conversa | **Caminhos de código predefinidos** | **Dirigido pelo modelo** |
| Toma ações | Não | Não | Sim, roteirizadas | Sim, decididas em runtime |
| Previsível | Por chamada | Mais ou menos | **Determinístico** | **Probabilístico** |
| Ideal para | Q&A, extração | Chat de suporte | Processos conhecidos | Objetivos abertos |

A distinção que mais importa, e que quase nenhum glossário traça: **um workflow é [orquestração](/glossary/api-orchestration/) por caminhos de código predefinidos; um agente deixa o modelo dirigir o próprio caminho.** A [orientação da Anthropic](https://www.anthropic.com/engineering/building-effective-agents) é direta sobre a consequência — a maioria das tarefas que *parecem* precisar de um agente é mais bem servida por um workflow determinístico, e você só adiciona agência quando o caminho genuinamente não pode ser roteirizado.

## Confiabilidade: os erros se compõem para baixo

A seção honesta que as páginas de vendor evitam. Agentes são impressionantes por passo e frágeis por cadeia, porque **o sucesso se multiplica**: se cada passo tem probabilidade de sucesso *p*, uma tarefa de *n* passos tem sucesso de aproximadamente *pⁿ*.

```text
sucesso por passo   10 passos   20 passos
      95%             ~60%        ~36%
      90%             ~35%        ~12%
      85%             ~20%         ~4%

Uma demo que acerta um passo impressionante não é um sistema que acerta vinte.
No mundo real, o sucesso de agentes multi-passo entre sistemas fica muitas vezes em 20–40%.
```

Essa matemática dita o manual de produção: **mantenha as cadeias curtas**, **verifique os resultados** entre os passos em vez de confiar neles, **coloque ações irreversíveis** (enviar, apagar, cobrar, publicar) atrás de aprovação humana e **limite o loop** com tetos de passos e de custo, para que um agente confuso falhe barato em vez de caro. Confiabilidade não é uma propriedade do modelo que você espera melhorar; é uma arquitetura que você impõe.

## A superfície de segurança

Um agente que pode *agir* pode ser *enganado para agir*, o que faz dele uma superfície de ataque genuinamente nova. **Prompt injection** transforma instruções na entrada do modelo em ações reais — e a variante perigosa é a *indireta*: uma página web envenenada, um e-mail ou um ticket de suporte que o agente lê pode carregar instruções que ele então executa com as suas credenciais. **Confused deputy** é o formato do estrago: um agente com permissões amplas, manipulado para usá-las mal em nome de um atacante. As mitigações são disciplina de segurança antiga mirando um ator novo — **credenciais de menor privilégio, com escopo do usuário** (nunca dê ao agente mais do que o usuário da tarefa já tem), **tools negadas por padrão e de escopo estreito**, sandboxing e aprovação humana em tudo que for irreversível. O enquadramento mais importante de todos: **o backend, não o prompt, é a fronteira de segurança.** Um prompt pode ser injetado; uma [checagem de permissão](/glossary/pt/listas-de-controle-de-acesso-acl/) no servidor não pode ser convencida a deixar de se aplicar.

## Como projetar tools que um agente não consegue usar mal

Como as tools *são* o seu backend, design de tool é segurança de backend com o volume no máximo. Torne cada tool **idempotente** onde possível (um reembolso repetido não deve reembolsar em dobro), **de escopo estreito** (uma ação clara, não acesso cru ao banco), **com permissões** (ela roda sob a identidade do usuário e as [ACLs](/glossary/pt/listas-de-controle-de-acesso-acl/) dele se aplicam) e **com schema claro** — as descrições que o modelo lê para decidir *se* e *como* chamar uma tool merecem tanto cuidado quanto os seus prompts, porque uma descrição vaga de tool é um bug que o modelo vai encontrar. Exponha *ações*, não tabelas: `refund_order(id)` com as próprias checagens, nunca `run_sql(query)`.

## Casos de uso comuns

- **Operações de atendimento** — um agente resolvendo um objetivo de suporte de ponta a ponta via tools com permissões, com aprovação humana em reembolsos e cancelamentos.
- **Assistentes de código** — lendo um repositório, rodando tools, iterando até uma mudança sob revisão.
- **Pesquisa e síntese** — recuperação e resumo em múltiplos passos, quando o caminho não é conhecido de antemão.
- **Workflows de dados com julgamento** — passos que precisam de raciocínio entre eles, não só de um [pipeline](/glossary/api-orchestration/) fixo.
- **Agendamento e coordenação** — objetivos que atravessam vários sistemas, cada um alcançado por uma tool com escopo.

## Você deveria construir um agente? Matriz de decisão

| Situação | Escolha |
| --- | --- |
| Os passos são conhecidos de antemão | Um [workflow](/glossary/api-orchestration/) — determinístico, testável |
| Uma pergunta ou extração pontual | Uma [chamada simples de LLM](/glossary/pt/api-de-llm/) |
| Objetivo aberto, caminho decidido em runtime | Um agente — a casa dele |
| Ações irreversíveis no loop | Um agente *com aprovação humana* |
| Muitas tools reutilizáveis entre agentes/modelos | Padronize-as via [MCP](/glossary/pt/mcp/) |
| A confiabilidade é crítica para a segurança | Cadeias curtas, verificação — ou não automatize |

## Limitações e trade-offs

- **Autonomia troca confiabilidade por capacidade.** A liberdade que permite ao agente lidar com objetivos abertos é a mesma que compõe erros — limite-a deliberadamente.
- **Loops custam dinheiro e tempo.** Cada iteração são mais chamadas de modelo; agentes são mais lentos e mais caros que uma chamada única por design — imponha tetos e monitore ambos.
- **Não-determinismo resiste a testes.** Um workflow você testa com unit tests; um agente você *avalia* estatisticamente, ao longo de muitas execuções, porque a mesma entrada pode seguir caminhos diferentes.
- **O raio de explosão são as suas credenciais.** Um agente é tão seguro quanto a permissão mais estreita que você deu às suas tools; acesso amplo demais é o incidente esperando para acontecer.
- **Impressionante ≠ confiável.** Uma demo empolgante é uma cadeia com sorte; produção é o trabalho chato de guardrails, aprovações e caminhos curtos.

## Agentes de IA no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. A tese de que "tools são funções de backend" é a integração inteira: as tools de um agente são [funções Cloud Code](/glossary/pt/cloud-code-funcoes-serverless/) e, como elas rodam sob a sessão do usuário que chama, as [ACLs e permissões de classe](/glossary/pt/listas-de-controle-de-acesso-acl/) da plataforma filtram cada leitura e escrita que o agente tenta — como mostram as abas de código, um agente sequestrado ou vítima de prompt injection *não consegue exceder as permissões do próprio usuário*, porque o raio de explosão do confused deputy é limitado pelo controle de acesso, não pelo bom comportamento do modelo. O resto decorre daí: exponha ações com escopo (`refundOrder`), não dados crus; mantenha a [chave do modelo no servidor](/glossary/pt/seguranca-de-chaves-de-api/); padronize a superfície de tools com [MCP](/glossary/pt/mcp/) quando vários agentes a compartilham; e deixe o backend dizer não. O agente propõe; o backend dispõe — que é exatamente onde a segurança de um sistema autônomo deveria morar.