---
title: "Engenharia de prompts, contexto, harness, agêntica e de loops: diferenças e projeto"
locale: pt
category: comparison
category_name: "Comparação"
translation_status: machine
license: cc_by
author: "Injoys Admin"
source_url: https://injoys.com/en/articles/prompt-context-harness-agentic-loop-engineering
published_at: 2026-07-16T17:00:54+09:00
---

# Engenharia de prompts, contexto, harness, agêntica e de loops: diferenças e projeto

> A engenharia de prompts, de contexto, de harness, agêntica e de loops trata, respectivamente, de instruções, informações, ambiente de trabalho, execução autônoma e melhoria iterativa. Este artigo explica, sob uma perspectiva prática, os limites entre as cinco abordagens e sua estrutura combinada, ordem de aplicação, métricas de validação e formas de prevenir falhas.

## Key Points

- A engenharia de prompts é o trabalho de tornar claros o objetivo, as restrições, os exemplos, o contrato de saída e os critérios de sucesso.
- A engenharia de contexto gerencia a relevância, a atualidade, as fontes e a eficiência de tokens das informações que a IA usará no julgamento atual.
- A engenharia de harness cria um ambiente no qual a IA possa trabalhar de forma estável por meio de ferramentas, permissões, sandboxes, estrutura de documentos, validadores e logs.
- A engenharia agêntica delega de forma limitada à IA a escolha da próxima ação e das ferramentas para atingir o objetivo.
- A engenharia de loops conecta geração, validação, análise de causa, correção, reexecução e condições de encerramento para fazer o resultado convergir.

Agrupar todo trabalho de melhorar a qualidade da IA generativa como “escrever bem prompts” dificulta diagnosticar com precisão a causa das falhas. Engenharia de prompts, de contexto, de harness, agêntica e de loops não são palavras da moda que se substituem entre si, mas abordagens de design complementares que tratam de planos de controle diferentes: **expressão da solicitação, seleção de informações, ambiente de execução, tomada de decisão autônoma e melhoria iterativa**.

## Definições centrais dos cinco conceitos

| Categoria | Pergunta central | Principal alvo de design | Entregáveis típicos | Critérios típicos de sucesso |
|---|---|---|---|---|
| Engenharia de prompts | Como instruir a IA a fazer o trabalho? | Instruções, restrições, exemplos, formato de saída | Templates de prompt, exemplos de entrada e saída | Taxa de cumprimento das instruções, precisão do formato, qualidade do primeiro resultado |
| Engenharia de contexto | O que mostrar à IA agora? | Instruções de sistema, documentos recuperados, estado da conversa, memória, resultados de ferramentas | Regras de montagem de contexto, políticas de busca e resumo | Relevância, atualidade, fundamentação, eficiência de tokens |
| Engenharia de harness | Que ambiente de trabalho criar para dificultar erros da IA? | Ferramentas, permissões, sandbox, estrutura de repositório, validadores, logs | Regras de trabalho, interfaces de ferramentas, testes·CI, runbooks | Reprodutibilidade, segurança, verificabilidade, recuperabilidade |
| Engenharia agêntica | Quem decide a próxima ação e dentro de qual escopo? | Objetivos, planos, seleção de ferramentas, transições de estado, delegação | Loop de agente, orquestração, pontos de aprovação | Taxa de conclusão de tarefas, escolha adequada de ferramentas, taxa de intervenção humana |
| Engenharia de loops | Como fazer convergir quando o primeiro resultado está errado? | Geração, avaliação, classificação de causas, correção, reexecução, condições de término | Avaliadores, testes de regressão, políticas de nova tentativa, classificação de falhas | Taxa de aprovação inicial, taxa de recuperação, número de iterações, taxa de aprovação final |

Conectando os cinco conceitos em uma linha, temos:

**Expressar a solicitação → mostrar as informações necessárias → oferecer um ambiente de trabalho seguro → permitir que a IA escolha a próxima ação → verificar e melhorar até que o resultado passe nos critérios.**

### Cuidados ao interpretar os termos

Engenharia de prompts e agentes são termos relativamente difundidos, mas engenharia de harness ainda tem um escopo de uso que varia conforme o contexto. Alguns textos chamam de harness praticamente toda a camada de execução fora do modelo, enquanto outros a explicam de forma mais estreita como a estrutura de regras, validação e feedback que usuários de agentes de codificação criam fora do repositório. “Engenharia de loops” também deve ser entendida mais como uma denominação prática para projetar geração e validação como um processo de feedback fechado do que como uma classificação formal fixada por um padrão único. ([OpenAI][1])

## 1. Engenharia de prompts: projetar a qualidade das instruções

Engenharia de prompts é o trabalho de tornar as instruções entregues ao modelo claras e verificáveis. Ela costuma produzir o efeito mais visível em uma única solicitação e resposta, mas também se aplica a mensagens de sistema e regras de conversas multiturno.

Um bom prompt normalmente separa os seguintes elementos.

- **Objetivo:** o que precisa ser concluído
- **Entrada:** qual é o objeto de análise e quais são os limites da entrada
- **Restrições:** o que não deve ser feito, escopo permitido, tamanho e formato
- **Contrato de saída:** estrutura do resultado, como JSON, tabela ou patch de código
- **Critérios de sucesso:** o que deve ser satisfeito para considerar a resposta correta
- **Tratamento de incerteza:** o que fazer quando faltam informações ou há conflito
- **Exemplos:** entradas e saídas representativas que mostram o comportamento esperado

Um template prático pode começar de forma simples assim.

```text
Objetivo:
Entrada:
Restrições:
Formato de saída:
Critérios de sucesso:
Método de validação:
Tratamento quando houver incerteza:
Exemplo representativo:
```

É importante definir primeiro os critérios de sucesso e os métodos de teste empíricos antes de refinar o prompt. Nem toda falha se resolve com uma mudança no prompt; custo, latência, erros de ferramentas e seleção incorreta de materiais podem ser problemas de outras camadas. ([Claude Platform Docs][2])

### Problemas que a engenharia de prompts resolve bem

- Problemas em que o formato do resultado quebra com frequência
- Problemas em que a prioridade das instruções é ambígua
- Problemas com entrada e saída relativamente claras, como classificação, extração, transformação e resumo
- Problemas em que o desempenho se estabiliza ao fornecer exemplos representativos

### Problemas difíceis de resolver apenas com prompts

- Quando os fatos ou arquivos necessários não estão na entrada
- Quando documentos antigos ou conflitantes estão misturados
- Quando é necessário consultar ou modificar sistemas externos com segurança
- Quando são necessários estados de execução em várias etapas e recuperação de falhas
- Quando não há método objetivo para verificar se o resultado está correto

## 2. Engenharia de contexto: projetar as informações vistas pela IA

Engenharia de contexto é o trabalho de selecionar, ordenar, comprimir e atualizar o conjunto completo de informações que o modelo pode usar no momento em que gera a resposta. O contexto pode incluir não apenas o prompt, mas também instruções de sistema, solicitação do usuário, histórico da conversa, documentos recuperados, memória, descrições de ferramentas, resultados de execução de ferramentas, horário atual, estado de permissões e andamento da tarefa.

Como a janela de contexto é finita, o objetivo não é “colocar muita coisa”, mas **colocar as informações necessárias no momento certo**. A Anthropic descreve o contexto como um recurso importante, porém finito, dos agentes e recomenda, em interações longas, estratégias como conjunto mínimo de ferramentas, exemplos representativos, busca em tempo de execução, compressão e memória. ([Anthropic][3])

### Princípios centrais de design

1. **Priorizar relevância:** incluir apenas as informações necessárias para a etapa atual.
2. **Fonte e atualidade:** gerenciar também data de criação, versão, proprietário e confiabilidade dos documentos.
3. **Busca sob demanda:** em vez de injetar todos os materiais antecipadamente, recuperá-los de arquivos, DB ou sistemas de busca quando necessário.
4. **Estratificação da informação:** separar regras fixas, tarefa atual, materiais de referência e resultados de ferramentas.
5. **Tratamento de conflitos:** quando materiais divergem, explicitar prioridades e fonte de referência.
6. **Compressão e preservação de estado:** resumir conversas antigas sem perder decisões, pendências e links de fundamentação.
7. **Separação entre instruções e dados:** estabelecer limites para que frases em páginas web ou documentos não sejam tratadas como comandos de sistema.

### Exemplo

Quando uma IA de atendimento ao cliente responde sobre a política de reembolso, há limite em apenas reforçar o prompt com “responda com precisão”. Uma boa engenharia de contexto consulta no momento necessário o país do cliente, data da compra, tipo de produto, versão atual da política, cláusulas de exceção e estado do pedido, fornece essas informações em conjunto e torna rastreáveis as cláusulas da política usadas na resposta.

## 3. Engenharia de harness: projetar o ambiente em que a IA trabalha

O harness é a estrutura de execução que conecta a inteligência do modelo ao trabalho real. Engenharia de harness é o trabalho de projetar o ambiente de trabalho para prevenir erros frequentes da IA ou detectá-los cedo por meio de documentos, ferramentas, permissões, estrutura, validação automática e feedback.

### Principais componentes do harness

| Componente | Papel | Exemplos |
|---|---|---|
| Instruções de trabalho | Especificar procedimentos e proibições de tarefas repetitivas | `AGENTS.md`, runbooks, checklists |
| Estrutura de conhecimento | Ajudar a IA a encontrar facilmente os materiais necessários | Mapa do repositório, ADR, glossário, coleção de exemplos |
| Interface de ferramentas | Limitar claramente entradas e saídas das ações | Busca de arquivos, consulta a DB, execução de código, API de deploy |
| Ambiente de execução | Isolar falhas e aumentar a reprodutibilidade | Sandbox, contêiner, dependências fixadas |
| Validadores | Verificar automaticamente se o resultado satisfaz os critérios | Verificação de schema, testes unitários, linter, verificação de políticas |
| Permissões e aprovações | Limitar ações perigosas | Privilégio mínimo, separação leitura/escrita, aprovação humana |
| Observabilidade | Registrar o que foi visto e quais ações foram realizadas | Traces, logs, registros de chamadas de ferramentas, custos |
| Estrutura de recuperação | Reverter e retomar com segurança após falhas | Checkpoints, rollback, orçamento de novas tentativas |

Os casos de engenharia de harness da OpenAI descrevem o papel do engenheiro menos como simples escrita de código e mais como design de ambiente, intenção, conhecimento do repositório, testes, validação, revisão e loops de recuperação. O ponto central não é pedir novamente à IA para “se esforçar mais”, mas adicionar explicitamente ao ambiente as capacidades e sinais que estavam faltando. ([OpenAI][1])

### Exemplo de estrutura de materiais

```text
/ai
  /instructions   # regras comuns e instruções por função
  /skills         # procedimentos de tarefas repetitivas
  /examples       # bons e maus resultados
  /evals          # dados de avaliação e regras de pontuação
  /policies       # políticas de permissão, segurança e aprovação
  /runbooks       # resposta a incidentes e exceções
```

Essa estrutura em si não é a resposta correta. O importante é que os materiais sejam mantidos atualizados, tenham pouca duplicação e conflito, possam ser encontrados pela IA no momento necessário e que as regras levem a verificações automáticas.

## 4. Engenharia agêntica: dar objetivos e ferramentas e delegar a próxima ação

Engenharia agêntica é o design que fornece à IA objetivos, ferramentas, estado da tarefa e condições de contorno, permitindo que ela escolha por conta própria, dentro de certo escopo, os próximos passos para alcançar o objetivo.

A Anthropic distingue **workflows** como sistemas que coordenam LLMs e ferramentas por caminhos de código previamente definidos, e **agentes** como sistemas em que o modelo decide dinamicamente seu próprio processo e uso de ferramentas. A OpenAI também descreve agentes como sistemas em que um LLM gerencia a execução do workflow e escolhe dinamicamente ferramentas para interagir com sistemas externos. ([Anthropic][4])

### Loop básico de agente

1. Observa o objetivo e o estado atuais.
2. Planeja o próximo subobjetivo ou ação.
3. Seleciona e executa uma ferramenta.
4. Verifica o resultado e as mudanças no ambiente.
5. Decide entre concluir, corrigir, tentar novamente ou encaminhar a um humano.

### Quando agentes são adequados

- Quando a ordem das tarefas muda conforme a entrada
- Quando é necessário interpretar informações não estruturadas, como linguagem natural, documentos e código
- Quando várias ferramentas precisam ser usadas seletivamente
- Quando é necessário mudar o plano com base em resultados intermediários
- Quando as causas de falha são variadas e algum nível de recuperação é possível

### Quando agentes são excessivos

- Automação simples com regras e ordem fixas
- Tarefas resolvidas de forma confiável com uma única chamada de API ou SQL
- Tarefas sem meios de validação e com custo de erro muito alto
- Estruturas que executam sem aprovação ações difíceis de reverter, como pagamento, exclusão ou deploy
- Estruturas multiagente que apenas aumentam papéis quando um único agente seria suficiente

Autonomia não é uma dicotomia. Ela pode ser dividida em assistentes que apenas recomendam, executores com leitura e escrita limitadas, modelos supervisionados que exigem aprovação em cada etapa principal e modelos de alta autonomia que operam por longos períodos em escopos de baixo risco. A expansão deve ser gradual, de acordo com o risco da tarefa e a capacidade de validação.

## 5. Engenharia de loops: projetar um processo de melhoria verificável

Engenharia de loops não é uma simples nova tentativa. É transformar **geração → validação → análise da causa da falha → escolha da estratégia de correção → reexecução → decisão de término** em um sistema explícito de feedback fechado.

### Composição de um loop adequado

1. **Geração de candidato:** criar rascunho, código, plano ou resultado de transformação de dados.
2. **Validação:** executar testes, schema, dados de referência, políticas e verificação de fundamentação.
3. **Classificação de causa:** distinguir erro de instrução, ausência de contexto, falha de ferramenta, defeito de implementação e defeito do avaliador.
4. **Correção:** aplicar a menor alteração adequada à causa da falha.
5. **Reexecução:** não repetir tudo desde o início; refazer apenas a partir da etapa necessária.
6. **Término:** parar em uma das condições: aprovação, número máximo de iterações, limite de custo, limite de tempo ou limiar de incerteza.
7. **Proteção contra regressão:** verificar se a nova correção não quebrou casos já bem-sucedidos.

Avaliar agentes é mais complexo do que uma avaliação de turno único que considera apenas entrada e saída. Como agentes chamam ferramentas várias vezes e alteram o estado do ambiente, é preciso verificar não apenas o resultado final, mas também o processo e as mudanças no ambiente. O núcleo da avaliação automática é fornecer uma entrada e aplicar lógica de pontuação à saída ou ao estado alterado. ([Anthropic][5])

### Prioridade dos validadores

- **Validação determinística:** compilação, testes unitários, schema, restrições matemáticas, verificação de permissões
- **Validação baseada em referência:** dados de referência, citações do original, comparação com banco de dados
- **Validação baseada em regras:** palavras proibidas, campos obrigatórios, condições de política
- **Avaliação baseada em modelo:** itens difíceis de converter em regras, como estilo, preservação de significado e qualidade geral
- **Avaliação humana:** decisões de alto risco, validade do próprio objetivo, aprovação de exceções

Sempre que possível, use primeiro validações determinísticas e não faça o modelo avaliar sozinho seus próprios resultados apenas com avaliação de modelo. Ao usar avaliação por modelo, inclua critérios de avaliação, exemplos, verificação de vieses e revisão humana por amostragem.

## Os cinco métodos são camadas, não substitutos

Em sistemas reais, os cinco métodos funcionam juntos.

- O prompt cria **o contrato da ação atual**.
- O contexto fornece **o estado e as evidências necessários ao julgamento**.
- O harness fornece **um ambiente acionável e salvaguardas**.
- O design agêntico distribui **o direito de escolha da próxima ação**.
- O design de loops **descobre erros e faz a qualidade convergir**.

Portanto, entendimentos como “a engenharia de contexto substituiu a engenharia de prompts” ou “se usar agentes, não precisa de workflows” são imprecisos. Camadas mais amplas apenas incluem ou utilizam camadas mais estreitas, e, para problemas simples, designs simples podem ser mais estáveis.

## Exemplo prático: sistema de codificação com IA que corrige um bug

Suponha que a IA vá corrigir um bug em que “apenas determinados usuários recebem erro 500 após o login”.

### Engenharia de prompts

- Verifique as condições de reprodução do erro.
- Não altere a API pública.
- Resolva com a menor correção possível.
- Após a correção, reporte os resultados dos testes e os riscos restantes.

### Engenharia de contexto

- Descrição do issue e logs de erro
- ID de rastreamento da solicitação relacionada
- Arquivos relacionados a autenticação e modelo de usuário
- Histórico de alterações recentes
- Regras de arquitetura e padrões de codificação
- Testes com falha e informações do ambiente de execução

### Engenharia de harness

- Ferramentas de busca no repositório, leitura e edição de arquivos e execução de testes
- Branch isolada e sandbox
- Formatter, linter, testes unitários e de integração
- Áreas proibidas de alteração e políticas de permissão
- Logs de todos os comandos e alterações de arquivos
- Rollback e checkpoints em caso de falha

### Engenharia agêntica

A IA escolhe conforme a situação a ordem entre reprodução, formulação de hipóteses, exploração do código relacionado, patch, testes e resumo dos resultados. No entanto, deploy ou alteração de dados exige aprovação humana.

### Engenharia de loops

Se os testes falharem, em vez de repetir o mesmo comando, o tipo de falha é classificado. Se a reprodução falhou, complementa-se a coleta de contexto; se houve falha de regressão, reduz-se o patch; se foi erro de ambiente, recuperam-se dependências e configurações. O processo termina quando todos os testes obrigatórios passam e a justificativa da alteração fica registrada.

## Como descobrir qual engenharia é necessária pelos sintomas do problema

| Sintoma | Área a verificar primeiro |
|---|---|
| O formato ou estilo da saída frequentemente sai do esperado | Prompt |
| Faltam fatos ou arquivos necessários na resposta | Contexto |
| A IA escolhe ferramentas erradas ou executa comandos perigosos | Harness e design de permissões |
| Há muitas variações difíceis de tratar com uma ordem fixa | Design agêntico |
| O primeiro resultado costuma estar errado, mas a decisão automática é possível | Loop e avaliador |
| Não é possível saber a causa da falha e é difícil reproduzi-la | Observabilidade do harness |
| Quanto mais se repete, mais o custo aumenta sem melhora de qualidade | Classificação de causas, sinais de validação, condições de término |
| Quanto mais materiais são adicionados, pior fica a resposta | Organização do contexto e política de busca |

## Ordem recomendada de construção

### Etapa 1: criar primeiro critérios de sucesso e conjunto de avaliação

Reúna tarefas representativas, casos difíceis e casos proibidos, e defina como julgar os resultados. Se não houver dados corretos, crie pelo menos schema, evidências obrigatórias, conformidade com políticas e critérios de avaliação humana.

### Etapa 2: criar uma linha de base de chamada única

Meça desempenho, custo e latência com o prompt mais simples e o mínimo de contexto necessário. Se agentes forem introduzidos sem linha de base, fica difícil distinguir o efeito da complexidade.

### Etapa 3: instrumentar o fornecimento de contexto

Registre quais documentos e resultados de ferramentas entraram, quão antigos eram e se foram realmente usados na resposta. Distinga falhas de busca de contexto excessivo.

### Etapa 4: criar um harness mínimo

Reduza o número de ferramentas e torne nomes e entradas claros. Priorize sandbox, privilégio mínimo, testes automáticos, logs e checkpoints.

### Etapa 5: conceder autonomia limitada

Faça um único agente executar primeiro tarefas de baixo risco centradas em leitura. Explicite condições de término e encaminhamento humano, e aprove separadamente permissões de escrita, exclusão, pagamento e deploy.

### Etapa 6: fechar o loop de validação e recuperação

Conecte classificação de falhas, estratégias de correção, número máximo de iterações, limite de custo e testes de regressão. Amplie ferramentas e escopo de autonomia apenas depois que a taxa de sucesso estiver estável.

## Métricas operacionais

Não há metas universais, portanto os critérios devem ser definidos conforme o risco e o custo da tarefa.

| Métrica | Significado |
|---|---|
| Taxa de conclusão de tarefas | Proporção que atendeu aos critérios finais de sucesso |
| Taxa de aprovação inicial | Proporção aprovada de primeira, sem correção iterativa |
| Taxa de recuperação | Proporção que teve sucesso por meio do loop após a primeira falha |
| Número médio de iterações | Número de ciclos necessários até sucesso ou interrupção |
| Taxa de erro na escolha de ferramentas | Proporção de chamadas de ferramentas inadequadas ou desnecessárias |
| Completude das evidências | Proporção de afirmações centrais com fontes rastreáveis |
| Taxa de intervenção humana | Proporção que exigiu aprovação, correção ou nova instrução |
| Custo e latência por sucesso unitário | Recursos gastos para concluir uma tarefa bem-sucedida |
| Número de incidentes de segurança | Quantidade de violações de permissão, escritas incorretas e ações irreversíveis |
| Taxa de falha de regressão | Proporção em que uma nova alteração quebrou casos já bem-sucedidos |

## Erros de design frequentes

| Área | Erro | Método de melhoria |
|---|---|---|
| Prompt | Acumular todas as exceções em uma única frase | Estruturar regras e separar exemplos representativos e avaliação |
| Prompt | Instruir “escreva bem” sem critérios de sucesso | Explicitar formato, conteúdos obrigatórios, proibições e critérios de julgamento |
| Contexto | Inserir todos os documentos, inclusive irrelevantes | Usar busca em tempo de execução e contexto por etapa |
| Contexto | Fornecer políticas antigas e atuais juntas | Gerenciar versão, data de validade e fonte de referência |
| Harness | Oferecer muitas ferramentas com funcionalidades sobrepostas | Projetar um conjunto mínimo de ferramentas e parâmetros claros |
| Harness | Não ter permissão de escrita nem função de reversão | Usar privilégio mínimo, sandbox e checkpoints |
| Agêntico | Criar múltiplos agentes desde o início | Validar primeiro com um único agente e workflows determinísticos |
| Agêntico | Deixar executar continuamente sem condição de conclusão | Definir condições explícitas de término, orçamento e encaminhamento |
| Loop | Repetir a mesma solicitação sem alteração | Classificar a causa da falha e mudar o ponto de correção |
| Loop | Usar um único modelo generativo para autoavaliar todos os resultados | Combinar verificações determinísticas, comparação com referências e revisão humana por amostragem |

## Checklist de implementação

- [ ] As condições de sucesso são verificáveis mecanicamente na medida do possível, e não apenas por frases?
- [ ] As prioridades de prompt, materiais de referência e resultados de ferramentas estão separadas?
- [ ] É possível rastrear fonte, versão, data de validade e proprietário dos documentos?
- [ ] Os nomes e parâmetros das ferramentas são claros e não se sobrepõem?
- [ ] As permissões de leitura, escrita, exclusão, pagamento e deploy estão separadas por nível de risco?
- [ ] Há sandbox para isolar falhas e meios de reversão?
- [ ] Todas as ações importantes e chamadas de ferramentas são registradas de forma reprodutível?
- [ ] Há validadores externos, como testes, schema e verificações de política?
- [ ] Estão definidas condições de número máximo de iterações, custo, tempo e encaminhamento humano?
- [ ] Há avaliação de regressão para garantir que novas melhorias não quebrem casos existentes?

## Conclusão

Um bom sistema de IA não é o sistema com o prompt mais longo. É o sistema que distingue se a falha ocorreu em **instruções**, **informações**, **ambiente**, **tomada de decisão** ou **validação e recuperação**, e posiciona a solução mais simples na camada correspondente. A abordagem estável é criar primeiro critérios de sucesso e uma linha de base de chamada única, reforçar contexto e harness apenas na medida necessária e, depois, expandir autonomia e loops iterativos dentro de um escopo verificável.

## FAQ

### As cinco abordagens de engenharia precisam necessariamente ser introduzidas em ordem?
Não são etapas fixas de maturidade. No entanto, depois de criar critérios de sucesso e uma linha de base de chamada única, organizar o prompt e o contexto e, quando necessário, adicionar harness, autonomia e loops de repetição facilita medir o efeito da complexidade.

### A engenharia de contexto substitui a engenharia de prompts?
Não substitui. O prompt define a ação a ser realizada e o contrato de saída, enquanto o contexto fornece os fatos, o estado e as evidências necessários para essa ação. Bons sistemas projetam os dois em conjunto.

### Qual é a diferença entre engenharia de contexto e engenharia de harness?
A engenharia de contexto se concentra nas informações que o modelo vê em um momento específico. A engenharia de harness inclui as ferramentas, permissões, ambiente de execução, estrutura de documentos, logs e mecanismos de recuperação que encontram essas informações, executam ações e verificam resultados.

### Como um agente difere da automação de fluxo de trabalho comum?
Um fluxo de trabalho comum segue uma sequência e ramificações predefinidas, enquanto um agente interpreta o estado atual e escolhe dinamicamente a próxima ação e as ferramentas. Para tarefas em que as regras são estáveis, um fluxo de trabalho determinístico pode ser mais barato e previsível.

### Em que a engenharia de loops difere de uma simples nova tentativa?
Uma simples nova tentativa apenas gera novamente sob as mesmas condições. A engenharia de loops identifica a falha por meio de sinais externos de validação, classifica a causa e então corrige as partes necessárias entre prompt, contexto, ferramentas e implementação, aplicando condições de encerramento e testes de regressão.

### Quando devo usar múltiplos agentes?
Considere isso quando as ferramentas e permissões por função forem claramente diferentes e quando o contexto ou o conjunto de ferramentas de um agente ficar grande demais, prejudicando o desempenho e a avaliação. Criar vários agentes apenas para uma simples divisão de papéis pode aumentar custos, latência, propagação de erros e dificuldade de depuração.

### Posso deixar a AI avaliar seus próprios resultados?
Pode ser usado como sinal auxiliar, mas é arriscado torná-lo o único verificador. Sempre que possível, aplique primeiro testes, esquemas, dados de referência e regras de política, e complemente a avaliação do modelo com rubricas explícitas e revisão humana por amostragem.

### O que deve ser incluído na documentação do harness?
Inclua procedimentos de tarefas recorrentes, estrutura de repositórios e sistemas, ações permitidas e proibidas, instruções de uso de ferramentas, bons e maus exemplos, comandos de teste, resposta a falhas, políticas de aprovação e critérios de conclusão. A documentação deve ser curta, pesquisável e versionada.

### Qual é o princípio de segurança mais importante ao colocar documentos externos no contexto?
Documentos externos devem ser tratados como dados não confiáveis e separados das instruções do sistema. Minimize as permissões de ferramentas para não executar comandos contidos nos documentos e estabeleça verificações de política separadas e aprovação humana para ações importantes de escrita, exclusão, pagamento e implantação.

### Por onde uma equipe pequena deve começar?
Reúna um pequeno conjunto de avaliação representativo e casos de falha para medir a linha de base de uma única chamada ao modelo. Depois, é eficiente identificar se a maior causa de falha está em instruções, informações, ambiente de ferramentas, planejamento ou validação, e melhorar uma camada por vez.

## Sources

- [Visão geral da engenharia de prompts - Claude Platform Docs](https://platform.claude.com/docs/ko/build-with-claude/prompt-engineering/overview)
- [Engenharia de contexto eficaz para agentes de IA](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)
- [Engenharia de harness: aproveitando o Codex em um mundo centrado em agentes](https://openai.com/index/harness-engineering/)
- [Criando agentes eficazes](https://www.anthropic.com/engineering/building-effective-agents)
- [Um guia prático para criar agentes](https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/)
- [Desmistificando avaliações para agentes de IA](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents)
- [Engenharia de harness para usuários de agentes de programação](https://martinfowler.com/articles/harness-engineering.html)

## Images

![Núcleo central de IA ligado a módulos de instruções, contexto, ferramentas, ação autônoma e validação](https://injoys.com/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsiZGF0YSI6MTg0NywicHVyIjoiYmxvYl9pZCJ9fQ==--9f1b84d1d297642915a0d27477d3800017987668/ChatGPT%20Image%202026%E1%84%82%E1%85%A7%E1%86%AB%207%E1%84%8B%E1%85%AF%E1%86%AF%2016%E1%84%8B%E1%85%B5%E1%86%AF%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2004_12_32.webp)
![Fluxo de construção de IA com instruções, filtragem de contexto, ambiente seguro, ação autônoma e validação iterativa](https://injoys.com/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsiZGF0YSI6MTg1NCwicHVyIjoiYmxvYl9pZCJ9fQ==--47acd549387f7a60f4c18de6ac673ca1b551dd36/ChatGPT%20Image%202026%E1%84%82%E1%85%A7%E1%86%AB%207%E1%84%8B%E1%85%AF%E1%86%AF%2016%E1%84%8B%E1%85%B5%E1%86%AF%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2004_36_26.webp)