{"content_id":"uxrumphsyw","slug":"prompt-context-harness-agentic-loop-engineering","locale":"pt","schema_type":"TechArticle","category":"comparison","category_name":"Comparação","title":"Engenharia de prompts, contexto, harness, agêntica e de loops: diferenças e projeto","summary":"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.","author":{"name":"Injoys Admin","url":"https://injoys.com/ko/about"},"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."],"content_markdown":"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**.\n\n## Definições centrais dos cinco conceitos\n\n| Categoria | Pergunta central | Principal alvo de design | Entregáveis típicos | Critérios típicos de sucesso |\n|---|---|---|---|---|\n| 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 |\n| 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 |\n| 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 |\n| 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 |\n| 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 |\n\nConectando os cinco conceitos em uma linha, temos:\n\n**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.**\n\n### Cuidados ao interpretar os termos\n\nEngenharia 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])\n\n## 1. Engenharia de prompts: projetar a qualidade das instruções\n\nEngenharia 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.\n\nUm bom prompt normalmente separa os seguintes elementos.\n\n- **Objetivo:** o que precisa ser concluído\n- **Entrada:** qual é o objeto de análise e quais são os limites da entrada\n- **Restrições:** o que não deve ser feito, escopo permitido, tamanho e formato\n- **Contrato de saída:** estrutura do resultado, como JSON, tabela ou patch de código\n- **Critérios de sucesso:** o que deve ser satisfeito para considerar a resposta correta\n- **Tratamento de incerteza:** o que fazer quando faltam informações ou há conflito\n- **Exemplos:** entradas e saídas representativas que mostram o comportamento esperado\n\nUm template prático pode começar de forma simples assim.\n\n```text\nObjetivo:\nEntrada:\nRestrições:\nFormato de saída:\nCritérios de sucesso:\nMétodo de validação:\nTratamento quando houver incerteza:\nExemplo representativo:\n```\n\nÉ 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])\n\n### Problemas que a engenharia de prompts resolve bem\n\n- Problemas em que o formato do resultado quebra com frequência\n- Problemas em que a prioridade das instruções é ambígua\n- Problemas com entrada e saída relativamente claras, como classificação, extração, transformação e resumo\n- Problemas em que o desempenho se estabiliza ao fornecer exemplos representativos\n\n### Problemas difíceis de resolver apenas com prompts\n\n- Quando os fatos ou arquivos necessários não estão na entrada\n- Quando documentos antigos ou conflitantes estão misturados\n- Quando é necessário consultar ou modificar sistemas externos com segurança\n- Quando são necessários estados de execução em várias etapas e recuperação de falhas\n- Quando não há método objetivo para verificar se o resultado está correto\n\n## 2. Engenharia de contexto: projetar as informações vistas pela IA\n\nEngenharia 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.\n\nComo 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])\n\n### Princípios centrais de design\n\n1. **Priorizar relevância:** incluir apenas as informações necessárias para a etapa atual.\n2. **Fonte e atualidade:** gerenciar também data de criação, versão, proprietário e confiabilidade dos documentos.\n3. **Busca sob demanda:** em vez de injetar todos os materiais antecipadamente, recuperá-los de arquivos, DB ou sistemas de busca quando necessário.\n4. **Estratificação da informação:** separar regras fixas, tarefa atual, materiais de referência e resultados de ferramentas.\n5. **Tratamento de conflitos:** quando materiais divergem, explicitar prioridades e fonte de referência.\n6. **Compressão e preservação de estado:** resumir conversas antigas sem perder decisões, pendências e links de fundamentação.\n7. **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.\n\n### Exemplo\n\nQuando 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.\n\n## 3. Engenharia de harness: projetar o ambiente em que a IA trabalha\n\nO 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.\n\n### Principais componentes do harness\n\n| Componente | Papel | Exemplos |\n|---|---|---|\n| Instruções de trabalho | Especificar procedimentos e proibições de tarefas repetitivas | `AGENTS.md`, runbooks, checklists |\n| Estrutura de conhecimento | Ajudar a IA a encontrar facilmente os materiais necessários | Mapa do repositório, ADR, glossário, coleção de exemplos |\n| 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 |\n| Ambiente de execução | Isolar falhas e aumentar a reprodutibilidade | Sandbox, contêiner, dependências fixadas |\n| Validadores | Verificar automaticamente se o resultado satisfaz os critérios | Verificação de schema, testes unitários, linter, verificação de políticas |\n| Permissões e aprovações | Limitar ações perigosas | Privilégio mínimo, separação leitura/escrita, aprovação humana |\n| Observabilidade | Registrar o que foi visto e quais ações foram realizadas | Traces, logs, registros de chamadas de ferramentas, custos |\n| Estrutura de recuperação | Reverter e retomar com segurança após falhas | Checkpoints, rollback, orçamento de novas tentativas |\n\nOs 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])\n\n### Exemplo de estrutura de materiais\n\n```text\n/ai\n  /instructions   # regras comuns e instruções por função\n  /skills         # procedimentos de tarefas repetitivas\n  /examples       # bons e maus resultados\n  /evals          # dados de avaliação e regras de pontuação\n  /policies       # políticas de permissão, segurança e aprovação\n  /runbooks       # resposta a incidentes e exceções\n```\n\nEssa 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.\n\n## 4. Engenharia agêntica: dar objetivos e ferramentas e delegar a próxima ação\n\nEngenharia 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.\n\nA 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])\n\n### Loop básico de agente\n\n1. Observa o objetivo e o estado atuais.\n2. Planeja o próximo subobjetivo ou ação.\n3. Seleciona e executa uma ferramenta.\n4. Verifica o resultado e as mudanças no ambiente.\n5. Decide entre concluir, corrigir, tentar novamente ou encaminhar a um humano.\n\n### Quando agentes são adequados\n\n- Quando a ordem das tarefas muda conforme a entrada\n- Quando é necessário interpretar informações não estruturadas, como linguagem natural, documentos e código\n- Quando várias ferramentas precisam ser usadas seletivamente\n- Quando é necessário mudar o plano com base em resultados intermediários\n- Quando as causas de falha são variadas e algum nível de recuperação é possível\n\n### Quando agentes são excessivos\n\n- Automação simples com regras e ordem fixas\n- Tarefas resolvidas de forma confiável com uma única chamada de API ou SQL\n- Tarefas sem meios de validação e com custo de erro muito alto\n- Estruturas que executam sem aprovação ações difíceis de reverter, como pagamento, exclusão ou deploy\n- Estruturas multiagente que apenas aumentam papéis quando um único agente seria suficiente\n\nAutonomia 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.\n\n## 5. Engenharia de loops: projetar um processo de melhoria verificável\n\nEngenharia 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.\n\n### Composição de um loop adequado\n\n1. **Geração de candidato:** criar rascunho, código, plano ou resultado de transformação de dados.\n2. **Validação:** executar testes, schema, dados de referência, políticas e verificação de fundamentação.\n3. **Classificação de causa:** distinguir erro de instrução, ausência de contexto, falha de ferramenta, defeito de implementação e defeito do avaliador.\n4. **Correção:** aplicar a menor alteração adequada à causa da falha.\n5. **Reexecução:** não repetir tudo desde o início; refazer apenas a partir da etapa necessária.\n6. **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.\n7. **Proteção contra regressão:** verificar se a nova correção não quebrou casos já bem-sucedidos.\n\nAvaliar 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])\n\n### Prioridade dos validadores\n\n- **Validação determinística:** compilação, testes unitários, schema, restrições matemáticas, verificação de permissões\n- **Validação baseada em referência:** dados de referência, citações do original, comparação com banco de dados\n- **Validação baseada em regras:** palavras proibidas, campos obrigatórios, condições de política\n- **Avaliação baseada em modelo:** itens difíceis de converter em regras, como estilo, preservação de significado e qualidade geral\n- **Avaliação humana:** decisões de alto risco, validade do próprio objetivo, aprovação de exceções\n\nSempre 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.\n\n## Os cinco métodos são camadas, não substitutos\n\nEm sistemas reais, os cinco métodos funcionam juntos.\n\n- O prompt cria **o contrato da ação atual**.\n- O contexto fornece **o estado e as evidências necessários ao julgamento**.\n- O harness fornece **um ambiente acionável e salvaguardas**.\n- O design agêntico distribui **o direito de escolha da próxima ação**.\n- O design de loops **descobre erros e faz a qualidade convergir**.\n\nPortanto, 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.\n\n## Exemplo prático: sistema de codificação com IA que corrige um bug\n\nSuponha que a IA vá corrigir um bug em que “apenas determinados usuários recebem erro 500 após o login”.\n\n### Engenharia de prompts\n\n- Verifique as condições de reprodução do erro.\n- Não altere a API pública.\n- Resolva com a menor correção possível.\n- Após a correção, reporte os resultados dos testes e os riscos restantes.\n\n### Engenharia de contexto\n\n- Descrição do issue e logs de erro\n- ID de rastreamento da solicitação relacionada\n- Arquivos relacionados a autenticação e modelo de usuário\n- Histórico de alterações recentes\n- Regras de arquitetura e padrões de codificação\n- Testes com falha e informações do ambiente de execução\n\n### Engenharia de harness\n\n- Ferramentas de busca no repositório, leitura e edição de arquivos e execução de testes\n- Branch isolada e sandbox\n- Formatter, linter, testes unitários e de integração\n- Áreas proibidas de alteração e políticas de permissão\n- Logs de todos os comandos e alterações de arquivos\n- Rollback e checkpoints em caso de falha\n\n### Engenharia agêntica\n\nA 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.\n\n### Engenharia de loops\n\nSe 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.\n\n## Como descobrir qual engenharia é necessária pelos sintomas do problema\n\n| Sintoma | Área a verificar primeiro |\n|---|---|\n| O formato ou estilo da saída frequentemente sai do esperado | Prompt |\n| Faltam fatos ou arquivos necessários na resposta | Contexto |\n| A IA escolhe ferramentas erradas ou executa comandos perigosos | Harness e design de permissões |\n| Há muitas variações difíceis de tratar com uma ordem fixa | Design agêntico |\n| O primeiro resultado costuma estar errado, mas a decisão automática é possível | Loop e avaliador |\n| Não é possível saber a causa da falha e é difícil reproduzi-la | Observabilidade do harness |\n| 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 |\n| Quanto mais materiais são adicionados, pior fica a resposta | Organização do contexto e política de busca |\n\n## Ordem recomendada de construção\n\n### Etapa 1: criar primeiro critérios de sucesso e conjunto de avaliação\n\nReú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.\n\n### Etapa 2: criar uma linha de base de chamada única\n\nMeç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.\n\n### Etapa 3: instrumentar o fornecimento de contexto\n\nRegistre 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.\n\n### Etapa 4: criar um harness mínimo\n\nReduza o número de ferramentas e torne nomes e entradas claros. Priorize sandbox, privilégio mínimo, testes automáticos, logs e checkpoints.\n\n### Etapa 5: conceder autonomia limitada\n\nFaç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.\n\n### Etapa 6: fechar o loop de validação e recuperação\n\nConecte 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.\n\n## Métricas operacionais\n\nNão há metas universais, portanto os critérios devem ser definidos conforme o risco e o custo da tarefa.\n\n| Métrica | Significado |\n|---|---|\n| Taxa de conclusão de tarefas | Proporção que atendeu aos critérios finais de sucesso |\n| Taxa de aprovação inicial | Proporção aprovada de primeira, sem correção iterativa |\n| Taxa de recuperação | Proporção que teve sucesso por meio do loop após a primeira falha |\n| Número médio de iterações | Número de ciclos necessários até sucesso ou interrupção |\n| Taxa de erro na escolha de ferramentas | Proporção de chamadas de ferramentas inadequadas ou desnecessárias |\n| Completude das evidências | Proporção de afirmações centrais com fontes rastreáveis |\n| Taxa de intervenção humana | Proporção que exigiu aprovação, correção ou nova instrução |\n| Custo e latência por sucesso unitário | Recursos gastos para concluir uma tarefa bem-sucedida |\n| Número de incidentes de segurança | Quantidade de violações de permissão, escritas incorretas e ações irreversíveis |\n| Taxa de falha de regressão | Proporção em que uma nova alteração quebrou casos já bem-sucedidos |\n\n## Erros de design frequentes\n\n| Área | Erro | Método de melhoria |\n|---|---|---|\n| Prompt | Acumular todas as exceções em uma única frase | Estruturar regras e separar exemplos representativos e avaliação |\n| Prompt | Instruir “escreva bem” sem critérios de sucesso | Explicitar formato, conteúdos obrigatórios, proibições e critérios de julgamento |\n| Contexto | Inserir todos os documentos, inclusive irrelevantes | Usar busca em tempo de execução e contexto por etapa |\n| Contexto | Fornecer políticas antigas e atuais juntas | Gerenciar versão, data de validade e fonte de referência |\n| Harness | Oferecer muitas ferramentas com funcionalidades sobrepostas | Projetar um conjunto mínimo de ferramentas e parâmetros claros |\n| Harness | Não ter permissão de escrita nem função de reversão | Usar privilégio mínimo, sandbox e checkpoints |\n| Agêntico | Criar múltiplos agentes desde o início | Validar primeiro com um único agente e workflows determinísticos |\n| Agêntico | Deixar executar continuamente sem condição de conclusão | Definir condições explícitas de término, orçamento e encaminhamento |\n| Loop | Repetir a mesma solicitação sem alteração | Classificar a causa da falha e mudar o ponto de correção |\n| 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 |\n\n## Checklist de implementação\n\n- [ ] As condições de sucesso são verificáveis mecanicamente na medida do possível, e não apenas por frases?\n- [ ] As prioridades de prompt, materiais de referência e resultados de ferramentas estão separadas?\n- [ ] É possível rastrear fonte, versão, data de validade e proprietário dos documentos?\n- [ ] Os nomes e parâmetros das ferramentas são claros e não se sobrepõem?\n- [ ] As permissões de leitura, escrita, exclusão, pagamento e deploy estão separadas por nível de risco?\n- [ ] Há sandbox para isolar falhas e meios de reversão?\n- [ ] Todas as ações importantes e chamadas de ferramentas são registradas de forma reprodutível?\n- [ ] Há validadores externos, como testes, schema e verificações de política?\n- [ ] Estão definidas condições de número máximo de iterações, custo, tempo e encaminhamento humano?\n- [ ] Há avaliação de regressão para garantir que novas melhorias não quebrem casos existentes?\n\n## Conclusão\n\nUm 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.","content_html":"\u003cp\u003eAgrupar 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: \u003cstrong\u003eexpressão da solicitação, seleção de informações, ambiente de execução, tomada de decisão autônoma e melhoria iterativa\u003c/strong\u003e.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#definições-centrais-dos-cinco-conceitos\" class=\"anchor\" id=\"definições-centrais-dos-cinco-conceitos\"\u003e\u003c/a\u003eDefinições centrais dos cinco conceitos\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eCategoria\u003c/th\u003e\n\u003cth\u003ePergunta central\u003c/th\u003e\n\u003cth\u003ePrincipal alvo de design\u003c/th\u003e\n\u003cth\u003eEntregáveis típicos\u003c/th\u003e\n\u003cth\u003eCritérios típicos de sucesso\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eEngenharia de prompts\u003c/td\u003e\n\u003ctd\u003eComo instruir a IA a fazer o trabalho?\u003c/td\u003e\n\u003ctd\u003eInstruções, restrições, exemplos, formato de saída\u003c/td\u003e\n\u003ctd\u003eTemplates de prompt, exemplos de entrada e saída\u003c/td\u003e\n\u003ctd\u003eTaxa de cumprimento das instruções, precisão do formato, qualidade do primeiro resultado\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eEngenharia de contexto\u003c/td\u003e\n\u003ctd\u003eO que mostrar à IA agora?\u003c/td\u003e\n\u003ctd\u003eInstruções de sistema, documentos recuperados, estado da conversa, memória, resultados de ferramentas\u003c/td\u003e\n\u003ctd\u003eRegras de montagem de contexto, políticas de busca e resumo\u003c/td\u003e\n\u003ctd\u003eRelevância, atualidade, fundamentação, eficiência de tokens\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eEngenharia de harness\u003c/td\u003e\n\u003ctd\u003eQue ambiente de trabalho criar para dificultar erros da IA?\u003c/td\u003e\n\u003ctd\u003eFerramentas, permissões, sandbox, estrutura de repositório, validadores, logs\u003c/td\u003e\n\u003ctd\u003eRegras de trabalho, interfaces de ferramentas, testes·CI, runbooks\u003c/td\u003e\n\u003ctd\u003eReprodutibilidade, segurança, verificabilidade, recuperabilidade\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eEngenharia agêntica\u003c/td\u003e\n\u003ctd\u003eQuem decide a próxima ação e dentro de qual escopo?\u003c/td\u003e\n\u003ctd\u003eObjetivos, planos, seleção de ferramentas, transições de estado, delegação\u003c/td\u003e\n\u003ctd\u003eLoop de agente, orquestração, pontos de aprovação\u003c/td\u003e\n\u003ctd\u003eTaxa de conclusão de tarefas, escolha adequada de ferramentas, taxa de intervenção humana\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eEngenharia de loops\u003c/td\u003e\n\u003ctd\u003eComo fazer convergir quando o primeiro resultado está errado?\u003c/td\u003e\n\u003ctd\u003eGeração, avaliação, classificação de causas, correção, reexecução, condições de término\u003c/td\u003e\n\u003ctd\u003eAvaliadores, testes de regressão, políticas de nova tentativa, classificação de falhas\u003c/td\u003e\n\u003ctd\u003eTaxa de aprovação inicial, taxa de recuperação, número de iterações, taxa de aprovação final\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eConectando os cinco conceitos em uma linha, temos:\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eExpressar 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.\u003c/strong\u003e\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#cuidados-ao-interpretar-os-termos\" class=\"anchor\" id=\"cuidados-ao-interpretar-os-termos\"\u003e\u003c/a\u003eCuidados ao interpretar os termos\u003c/h3\u003e\n\u003cp\u003eEngenharia 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])\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#1-engenharia-de-prompts-projetar-a-qualidade-das-instruções\" class=\"anchor\" id=\"1-engenharia-de-prompts-projetar-a-qualidade-das-instruções\"\u003e\u003c/a\u003e1. Engenharia de prompts: projetar a qualidade das instruções\u003c/h2\u003e\n\u003cp\u003eEngenharia 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.\u003c/p\u003e\n\u003cp\u003eUm bom prompt normalmente separa os seguintes elementos.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eObjetivo:\u003c/strong\u003e o que precisa ser concluído\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eEntrada:\u003c/strong\u003e qual é o objeto de análise e quais são os limites da entrada\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eRestrições:\u003c/strong\u003e o que não deve ser feito, escopo permitido, tamanho e formato\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eContrato de saída:\u003c/strong\u003e estrutura do resultado, como JSON, tabela ou patch de código\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCritérios de sucesso:\u003c/strong\u003e o que deve ser satisfeito para considerar a resposta correta\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTratamento de incerteza:\u003c/strong\u003e o que fazer quando faltam informações ou há conflito\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eExemplos:\u003c/strong\u003e entradas e saídas representativas que mostram o comportamento esperado\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eUm template prático pode começar de forma simples assim.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eObjetivo:\n\u003c/span\u003e\u003cspan\u003eEntrada:\n\u003c/span\u003e\u003cspan\u003eRestrições:\n\u003c/span\u003e\u003cspan\u003eFormato de saída:\n\u003c/span\u003e\u003cspan\u003eCritérios de sucesso:\n\u003c/span\u003e\u003cspan\u003eMétodo de validação:\n\u003c/span\u003e\u003cspan\u003eTratamento quando houver incerteza:\n\u003c/span\u003e\u003cspan\u003eExemplo representativo:\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eÉ 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])\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#problemas-que-a-engenharia-de-prompts-resolve-bem\" class=\"anchor\" id=\"problemas-que-a-engenharia-de-prompts-resolve-bem\"\u003e\u003c/a\u003eProblemas que a engenharia de prompts resolve bem\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eProblemas em que o formato do resultado quebra com frequência\u003c/li\u003e\n\u003cli\u003eProblemas em que a prioridade das instruções é ambígua\u003c/li\u003e\n\u003cli\u003eProblemas com entrada e saída relativamente claras, como classificação, extração, transformação e resumo\u003c/li\u003e\n\u003cli\u003eProblemas em que o desempenho se estabiliza ao fornecer exemplos representativos\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\u003ca href=\"#problemas-difíceis-de-resolver-apenas-com-prompts\" class=\"anchor\" id=\"problemas-difíceis-de-resolver-apenas-com-prompts\"\u003e\u003c/a\u003eProblemas difíceis de resolver apenas com prompts\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eQuando os fatos ou arquivos necessários não estão na entrada\u003c/li\u003e\n\u003cli\u003eQuando documentos antigos ou conflitantes estão misturados\u003c/li\u003e\n\u003cli\u003eQuando é necessário consultar ou modificar sistemas externos com segurança\u003c/li\u003e\n\u003cli\u003eQuando são necessários estados de execução em várias etapas e recuperação de falhas\u003c/li\u003e\n\u003cli\u003eQuando não há método objetivo para verificar se o resultado está correto\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\u003ca href=\"#2-engenharia-de-contexto-projetar-as-informações-vistas-pela-ia\" class=\"anchor\" id=\"2-engenharia-de-contexto-projetar-as-informações-vistas-pela-ia\"\u003e\u003c/a\u003e2. Engenharia de contexto: projetar as informações vistas pela IA\u003c/h2\u003e\n\u003cp\u003eEngenharia 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.\u003c/p\u003e\n\u003cp\u003eComo a janela de contexto é finita, o objetivo não é “colocar muita coisa”, mas \u003cstrong\u003ecolocar as informações necessárias no momento certo\u003c/strong\u003e. 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])\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#princípios-centrais-de-design\" class=\"anchor\" id=\"princípios-centrais-de-design\"\u003e\u003c/a\u003ePrincípios centrais de design\u003c/h3\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003ePriorizar relevância:\u003c/strong\u003e incluir apenas as informações necessárias para a etapa atual.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eFonte e atualidade:\u003c/strong\u003e gerenciar também data de criação, versão, proprietário e confiabilidade dos documentos.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eBusca sob demanda:\u003c/strong\u003e em vez de injetar todos os materiais antecipadamente, recuperá-los de arquivos, DB ou sistemas de busca quando necessário.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eEstratificação da informação:\u003c/strong\u003e separar regras fixas, tarefa atual, materiais de referência e resultados de ferramentas.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTratamento de conflitos:\u003c/strong\u003e quando materiais divergem, explicitar prioridades e fonte de referência.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCompressão e preservação de estado:\u003c/strong\u003e resumir conversas antigas sem perder decisões, pendências e links de fundamentação.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSeparação entre instruções e dados:\u003c/strong\u003e estabelecer limites para que frases em páginas web ou documentos não sejam tratadas como comandos de sistema.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch3\u003e\u003ca href=\"#exemplo\" class=\"anchor\" id=\"exemplo\"\u003e\u003c/a\u003eExemplo\u003c/h3\u003e\n\u003cp\u003eQuando 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.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#3-engenharia-de-harness-projetar-o-ambiente-em-que-a-ia-trabalha\" class=\"anchor\" id=\"3-engenharia-de-harness-projetar-o-ambiente-em-que-a-ia-trabalha\"\u003e\u003c/a\u003e3. Engenharia de harness: projetar o ambiente em que a IA trabalha\u003c/h2\u003e\n\u003cp\u003eO 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.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#principais-componentes-do-harness\" class=\"anchor\" id=\"principais-componentes-do-harness\"\u003e\u003c/a\u003ePrincipais componentes do harness\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eComponente\u003c/th\u003e\n\u003cth\u003ePapel\u003c/th\u003e\n\u003cth\u003eExemplos\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eInstruções de trabalho\u003c/td\u003e\n\u003ctd\u003eEspecificar procedimentos e proibições de tarefas repetitivas\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003eAGENTS.md\u003c/code\u003e, runbooks, checklists\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eEstrutura de conhecimento\u003c/td\u003e\n\u003ctd\u003eAjudar a IA a encontrar facilmente os materiais necessários\u003c/td\u003e\n\u003ctd\u003eMapa do repositório, ADR, glossário, coleção de exemplos\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eInterface de ferramentas\u003c/td\u003e\n\u003ctd\u003eLimitar claramente entradas e saídas das ações\u003c/td\u003e\n\u003ctd\u003eBusca de arquivos, consulta a DB, execução de código, API de deploy\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eAmbiente de execução\u003c/td\u003e\n\u003ctd\u003eIsolar falhas e aumentar a reprodutibilidade\u003c/td\u003e\n\u003ctd\u003eSandbox, contêiner, dependências fixadas\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eValidadores\u003c/td\u003e\n\u003ctd\u003eVerificar automaticamente se o resultado satisfaz os critérios\u003c/td\u003e\n\u003ctd\u003eVerificação de schema, testes unitários, linter, verificação de políticas\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003ePermissões e aprovações\u003c/td\u003e\n\u003ctd\u003eLimitar ações perigosas\u003c/td\u003e\n\u003ctd\u003ePrivilégio mínimo, separação leitura/escrita, aprovação humana\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eObservabilidade\u003c/td\u003e\n\u003ctd\u003eRegistrar o que foi visto e quais ações foram realizadas\u003c/td\u003e\n\u003ctd\u003eTraces, logs, registros de chamadas de ferramentas, custos\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eEstrutura de recuperação\u003c/td\u003e\n\u003ctd\u003eReverter e retomar com segurança após falhas\u003c/td\u003e\n\u003ctd\u003eCheckpoints, rollback, orçamento de novas tentativas\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eOs 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])\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#exemplo-de-estrutura-de-materiais\" class=\"anchor\" id=\"exemplo-de-estrutura-de-materiais\"\u003e\u003c/a\u003eExemplo de estrutura de materiais\u003c/h3\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e/ai\n\u003c/span\u003e\u003cspan\u003e  /instructions   # regras comuns e instruções por função\n\u003c/span\u003e\u003cspan\u003e  /skills         # procedimentos de tarefas repetitivas\n\u003c/span\u003e\u003cspan\u003e  /examples       # bons e maus resultados\n\u003c/span\u003e\u003cspan\u003e  /evals          # dados de avaliação e regras de pontuação\n\u003c/span\u003e\u003cspan\u003e  /policies       # políticas de permissão, segurança e aprovação\n\u003c/span\u003e\u003cspan\u003e  /runbooks       # resposta a incidentes e exceções\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eEssa 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.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#4-engenharia-agêntica-dar-objetivos-e-ferramentas-e-delegar-a-próxima-ação\" class=\"anchor\" id=\"4-engenharia-agêntica-dar-objetivos-e-ferramentas-e-delegar-a-próxima-ação\"\u003e\u003c/a\u003e4. Engenharia agêntica: dar objetivos e ferramentas e delegar a próxima ação\u003c/h2\u003e\n\u003cp\u003eEngenharia 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.\u003c/p\u003e\n\u003cp\u003eA Anthropic distingue \u003cstrong\u003eworkflows\u003c/strong\u003e como sistemas que coordenam LLMs e ferramentas por caminhos de código previamente definidos, e \u003cstrong\u003eagentes\u003c/strong\u003e 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])\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#loop-básico-de-agente\" class=\"anchor\" id=\"loop-básico-de-agente\"\u003e\u003c/a\u003eLoop básico de agente\u003c/h3\u003e\n\u003col\u003e\n\u003cli\u003eObserva o objetivo e o estado atuais.\u003c/li\u003e\n\u003cli\u003ePlaneja o próximo subobjetivo ou ação.\u003c/li\u003e\n\u003cli\u003eSeleciona e executa uma ferramenta.\u003c/li\u003e\n\u003cli\u003eVerifica o resultado e as mudanças no ambiente.\u003c/li\u003e\n\u003cli\u003eDecide entre concluir, corrigir, tentar novamente ou encaminhar a um humano.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch3\u003e\u003ca href=\"#quando-agentes-são-adequados\" class=\"anchor\" id=\"quando-agentes-são-adequados\"\u003e\u003c/a\u003eQuando agentes são adequados\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eQuando a ordem das tarefas muda conforme a entrada\u003c/li\u003e\n\u003cli\u003eQuando é necessário interpretar informações não estruturadas, como linguagem natural, documentos e código\u003c/li\u003e\n\u003cli\u003eQuando várias ferramentas precisam ser usadas seletivamente\u003c/li\u003e\n\u003cli\u003eQuando é necessário mudar o plano com base em resultados intermediários\u003c/li\u003e\n\u003cli\u003eQuando as causas de falha são variadas e algum nível de recuperação é possível\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\u003ca href=\"#quando-agentes-são-excessivos\" class=\"anchor\" id=\"quando-agentes-são-excessivos\"\u003e\u003c/a\u003eQuando agentes são excessivos\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eAutomação simples com regras e ordem fixas\u003c/li\u003e\n\u003cli\u003eTarefas resolvidas de forma confiável com uma única chamada de API ou SQL\u003c/li\u003e\n\u003cli\u003eTarefas sem meios de validação e com custo de erro muito alto\u003c/li\u003e\n\u003cli\u003eEstruturas que executam sem aprovação ações difíceis de reverter, como pagamento, exclusão ou deploy\u003c/li\u003e\n\u003cli\u003eEstruturas multiagente que apenas aumentam papéis quando um único agente seria suficiente\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eAutonomia 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.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#5-engenharia-de-loops-projetar-um-processo-de-melhoria-verificável\" class=\"anchor\" id=\"5-engenharia-de-loops-projetar-um-processo-de-melhoria-verificável\"\u003e\u003c/a\u003e5. Engenharia de loops: projetar um processo de melhoria verificável\u003c/h2\u003e\n\u003cp\u003eEngenharia de loops não é uma simples nova tentativa. É transformar \u003cstrong\u003egeração → validação → análise da causa da falha → escolha da estratégia de correção → reexecução → decisão de término\u003c/strong\u003e em um sistema explícito de feedback fechado.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#composição-de-um-loop-adequado\" class=\"anchor\" id=\"composição-de-um-loop-adequado\"\u003e\u003c/a\u003eComposição de um loop adequado\u003c/h3\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eGeração de candidato:\u003c/strong\u003e criar rascunho, código, plano ou resultado de transformação de dados.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eValidação:\u003c/strong\u003e executar testes, schema, dados de referência, políticas e verificação de fundamentação.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eClassificação de causa:\u003c/strong\u003e distinguir erro de instrução, ausência de contexto, falha de ferramenta, defeito de implementação e defeito do avaliador.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCorreção:\u003c/strong\u003e aplicar a menor alteração adequada à causa da falha.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eReexecução:\u003c/strong\u003e não repetir tudo desde o início; refazer apenas a partir da etapa necessária.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTérmino:\u003c/strong\u003e 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.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eProteção contra regressão:\u003c/strong\u003e verificar se a nova correção não quebrou casos já bem-sucedidos.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eAvaliar 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])\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#prioridade-dos-validadores\" class=\"anchor\" id=\"prioridade-dos-validadores\"\u003e\u003c/a\u003ePrioridade dos validadores\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eValidação determinística:\u003c/strong\u003e compilação, testes unitários, schema, restrições matemáticas, verificação de permissões\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eValidação baseada em referência:\u003c/strong\u003e dados de referência, citações do original, comparação com banco de dados\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eValidação baseada em regras:\u003c/strong\u003e palavras proibidas, campos obrigatórios, condições de política\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAvaliação baseada em modelo:\u003c/strong\u003e itens difíceis de converter em regras, como estilo, preservação de significado e qualidade geral\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAvaliação humana:\u003c/strong\u003e decisões de alto risco, validade do próprio objetivo, aprovação de exceções\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eSempre 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.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#os-cinco-métodos-são-camadas-não-substitutos\" class=\"anchor\" id=\"os-cinco-métodos-são-camadas-não-substitutos\"\u003e\u003c/a\u003eOs cinco métodos são camadas, não substitutos\u003c/h2\u003e\n\u003cp\u003eEm sistemas reais, os cinco métodos funcionam juntos.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eO prompt cria \u003cstrong\u003eo contrato da ação atual\u003c/strong\u003e.\u003c/li\u003e\n\u003cli\u003eO contexto fornece \u003cstrong\u003eo estado e as evidências necessários ao julgamento\u003c/strong\u003e.\u003c/li\u003e\n\u003cli\u003eO harness fornece \u003cstrong\u003eum ambiente acionável e salvaguardas\u003c/strong\u003e.\u003c/li\u003e\n\u003cli\u003eO design agêntico distribui \u003cstrong\u003eo direito de escolha da próxima ação\u003c/strong\u003e.\u003c/li\u003e\n\u003cli\u003eO design de loops \u003cstrong\u003edescobre erros e faz a qualidade convergir\u003c/strong\u003e.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003ePortanto, 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.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#exemplo-prático-sistema-de-codificação-com-ia-que-corrige-um-bug\" class=\"anchor\" id=\"exemplo-prático-sistema-de-codificação-com-ia-que-corrige-um-bug\"\u003e\u003c/a\u003eExemplo prático: sistema de codificação com IA que corrige um bug\u003c/h2\u003e\n\u003cp\u003eSuponha que a IA vá corrigir um bug em que “apenas determinados usuários recebem erro 500 após o login”.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#engenharia-de-prompts\" class=\"anchor\" id=\"engenharia-de-prompts\"\u003e\u003c/a\u003eEngenharia de prompts\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eVerifique as condições de reprodução do erro.\u003c/li\u003e\n\u003cli\u003eNão altere a API pública.\u003c/li\u003e\n\u003cli\u003eResolva com a menor correção possível.\u003c/li\u003e\n\u003cli\u003eApós a correção, reporte os resultados dos testes e os riscos restantes.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\u003ca href=\"#engenharia-de-contexto\" class=\"anchor\" id=\"engenharia-de-contexto\"\u003e\u003c/a\u003eEngenharia de contexto\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eDescrição do issue e logs de erro\u003c/li\u003e\n\u003cli\u003eID de rastreamento da solicitação relacionada\u003c/li\u003e\n\u003cli\u003eArquivos relacionados a autenticação e modelo de usuário\u003c/li\u003e\n\u003cli\u003eHistórico de alterações recentes\u003c/li\u003e\n\u003cli\u003eRegras de arquitetura e padrões de codificação\u003c/li\u003e\n\u003cli\u003eTestes com falha e informações do ambiente de execução\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\u003ca href=\"#engenharia-de-harness\" class=\"anchor\" id=\"engenharia-de-harness\"\u003e\u003c/a\u003eEngenharia de harness\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eFerramentas de busca no repositório, leitura e edição de arquivos e execução de testes\u003c/li\u003e\n\u003cli\u003eBranch isolada e sandbox\u003c/li\u003e\n\u003cli\u003eFormatter, linter, testes unitários e de integração\u003c/li\u003e\n\u003cli\u003eÁreas proibidas de alteração e políticas de permissão\u003c/li\u003e\n\u003cli\u003eLogs de todos os comandos e alterações de arquivos\u003c/li\u003e\n\u003cli\u003eRollback e checkpoints em caso de falha\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\u003ca href=\"#engenharia-agêntica\" class=\"anchor\" id=\"engenharia-agêntica\"\u003e\u003c/a\u003eEngenharia agêntica\u003c/h3\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#engenharia-de-loops\" class=\"anchor\" id=\"engenharia-de-loops\"\u003e\u003c/a\u003eEngenharia de loops\u003c/h3\u003e\n\u003cp\u003eSe 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.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#como-descobrir-qual-engenharia-é-necessária-pelos-sintomas-do-problema\" class=\"anchor\" id=\"como-descobrir-qual-engenharia-é-necessária-pelos-sintomas-do-problema\"\u003e\u003c/a\u003eComo descobrir qual engenharia é necessária pelos sintomas do problema\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eSintoma\u003c/th\u003e\n\u003cth\u003eÁrea a verificar primeiro\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eO formato ou estilo da saída frequentemente sai do esperado\u003c/td\u003e\n\u003ctd\u003ePrompt\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eFaltam fatos ou arquivos necessários na resposta\u003c/td\u003e\n\u003ctd\u003eContexto\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eA IA escolhe ferramentas erradas ou executa comandos perigosos\u003c/td\u003e\n\u003ctd\u003eHarness e design de permissões\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eHá muitas variações difíceis de tratar com uma ordem fixa\u003c/td\u003e\n\u003ctd\u003eDesign agêntico\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eO primeiro resultado costuma estar errado, mas a decisão automática é possível\u003c/td\u003e\n\u003ctd\u003eLoop e avaliador\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eNão é possível saber a causa da falha e é difícil reproduzi-la\u003c/td\u003e\n\u003ctd\u003eObservabilidade do harness\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eQuanto mais se repete, mais o custo aumenta sem melhora de qualidade\u003c/td\u003e\n\u003ctd\u003eClassificação de causas, sinais de validação, condições de término\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eQuanto mais materiais são adicionados, pior fica a resposta\u003c/td\u003e\n\u003ctd\u003eOrganização do contexto e política de busca\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\u003ca href=\"#ordem-recomendada-de-construção\" class=\"anchor\" id=\"ordem-recomendada-de-construção\"\u003e\u003c/a\u003eOrdem recomendada de construção\u003c/h2\u003e\n\u003ch3\u003e\u003ca href=\"#etapa-1-criar-primeiro-critérios-de-sucesso-e-conjunto-de-avaliação\" class=\"anchor\" id=\"etapa-1-criar-primeiro-critérios-de-sucesso-e-conjunto-de-avaliação\"\u003e\u003c/a\u003eEtapa 1: criar primeiro critérios de sucesso e conjunto de avaliação\u003c/h3\u003e\n\u003cp\u003eReú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.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#etapa-2-criar-uma-linha-de-base-de-chamada-única\" class=\"anchor\" id=\"etapa-2-criar-uma-linha-de-base-de-chamada-única\"\u003e\u003c/a\u003eEtapa 2: criar uma linha de base de chamada única\u003c/h3\u003e\n\u003cp\u003eMeç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.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#etapa-3-instrumentar-o-fornecimento-de-contexto\" class=\"anchor\" id=\"etapa-3-instrumentar-o-fornecimento-de-contexto\"\u003e\u003c/a\u003eEtapa 3: instrumentar o fornecimento de contexto\u003c/h3\u003e\n\u003cp\u003eRegistre 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.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#etapa-4-criar-um-harness-mínimo\" class=\"anchor\" id=\"etapa-4-criar-um-harness-mínimo\"\u003e\u003c/a\u003eEtapa 4: criar um harness mínimo\u003c/h3\u003e\n\u003cp\u003eReduza o número de ferramentas e torne nomes e entradas claros. Priorize sandbox, privilégio mínimo, testes automáticos, logs e checkpoints.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#etapa-5-conceder-autonomia-limitada\" class=\"anchor\" id=\"etapa-5-conceder-autonomia-limitada\"\u003e\u003c/a\u003eEtapa 5: conceder autonomia limitada\u003c/h3\u003e\n\u003cp\u003eFaç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.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#etapa-6-fechar-o-loop-de-validação-e-recuperação\" class=\"anchor\" id=\"etapa-6-fechar-o-loop-de-validação-e-recuperação\"\u003e\u003c/a\u003eEtapa 6: fechar o loop de validação e recuperação\u003c/h3\u003e\n\u003cp\u003eConecte 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.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#métricas-operacionais\" class=\"anchor\" id=\"métricas-operacionais\"\u003e\u003c/a\u003eMétricas operacionais\u003c/h2\u003e\n\u003cp\u003eNão há metas universais, portanto os critérios devem ser definidos conforme o risco e o custo da tarefa.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eMétrica\u003c/th\u003e\n\u003cth\u003eSignificado\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eTaxa de conclusão de tarefas\u003c/td\u003e\n\u003ctd\u003eProporção que atendeu aos critérios finais de sucesso\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eTaxa de aprovação inicial\u003c/td\u003e\n\u003ctd\u003eProporção aprovada de primeira, sem correção iterativa\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eTaxa de recuperação\u003c/td\u003e\n\u003ctd\u003eProporção que teve sucesso por meio do loop após a primeira falha\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eNúmero médio de iterações\u003c/td\u003e\n\u003ctd\u003eNúmero de ciclos necessários até sucesso ou interrupção\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eTaxa de erro na escolha de ferramentas\u003c/td\u003e\n\u003ctd\u003eProporção de chamadas de ferramentas inadequadas ou desnecessárias\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eCompletude das evidências\u003c/td\u003e\n\u003ctd\u003eProporção de afirmações centrais com fontes rastreáveis\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eTaxa de intervenção humana\u003c/td\u003e\n\u003ctd\u003eProporção que exigiu aprovação, correção ou nova instrução\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eCusto e latência por sucesso unitário\u003c/td\u003e\n\u003ctd\u003eRecursos gastos para concluir uma tarefa bem-sucedida\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eNúmero de incidentes de segurança\u003c/td\u003e\n\u003ctd\u003eQuantidade de violações de permissão, escritas incorretas e ações irreversíveis\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eTaxa de falha de regressão\u003c/td\u003e\n\u003ctd\u003eProporção em que uma nova alteração quebrou casos já bem-sucedidos\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\u003ca href=\"#erros-de-design-frequentes\" class=\"anchor\" id=\"erros-de-design-frequentes\"\u003e\u003c/a\u003eErros de design frequentes\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eÁrea\u003c/th\u003e\n\u003cth\u003eErro\u003c/th\u003e\n\u003cth\u003eMétodo de melhoria\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003ePrompt\u003c/td\u003e\n\u003ctd\u003eAcumular todas as exceções em uma única frase\u003c/td\u003e\n\u003ctd\u003eEstruturar regras e separar exemplos representativos e avaliação\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003ePrompt\u003c/td\u003e\n\u003ctd\u003eInstruir “escreva bem” sem critérios de sucesso\u003c/td\u003e\n\u003ctd\u003eExplicitar formato, conteúdos obrigatórios, proibições e critérios de julgamento\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eContexto\u003c/td\u003e\n\u003ctd\u003eInserir todos os documentos, inclusive irrelevantes\u003c/td\u003e\n\u003ctd\u003eUsar busca em tempo de execução e contexto por etapa\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eContexto\u003c/td\u003e\n\u003ctd\u003eFornecer políticas antigas e atuais juntas\u003c/td\u003e\n\u003ctd\u003eGerenciar versão, data de validade e fonte de referência\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eHarness\u003c/td\u003e\n\u003ctd\u003eOferecer muitas ferramentas com funcionalidades sobrepostas\u003c/td\u003e\n\u003ctd\u003eProjetar um conjunto mínimo de ferramentas e parâmetros claros\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eHarness\u003c/td\u003e\n\u003ctd\u003eNão ter permissão de escrita nem função de reversão\u003c/td\u003e\n\u003ctd\u003eUsar privilégio mínimo, sandbox e checkpoints\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eAgêntico\u003c/td\u003e\n\u003ctd\u003eCriar múltiplos agentes desde o início\u003c/td\u003e\n\u003ctd\u003eValidar primeiro com um único agente e workflows determinísticos\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eAgêntico\u003c/td\u003e\n\u003ctd\u003eDeixar executar continuamente sem condição de conclusão\u003c/td\u003e\n\u003ctd\u003eDefinir condições explícitas de término, orçamento e encaminhamento\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eLoop\u003c/td\u003e\n\u003ctd\u003eRepetir a mesma solicitação sem alteração\u003c/td\u003e\n\u003ctd\u003eClassificar a causa da falha e mudar o ponto de correção\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eLoop\u003c/td\u003e\n\u003ctd\u003eUsar um único modelo generativo para autoavaliar todos os resultados\u003c/td\u003e\n\u003ctd\u003eCombinar verificações determinísticas, comparação com referências e revisão humana por amostragem\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\u003ca href=\"#checklist-de-implementação\" class=\"anchor\" id=\"checklist-de-implementação\"\u003e\u003c/a\u003eChecklist de implementação\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e As condições de sucesso são verificáveis mecanicamente na medida do possível, e não apenas por frases?\u003c/li\u003e\n\u003cli\u003e As prioridades de prompt, materiais de referência e resultados de ferramentas estão separadas?\u003c/li\u003e\n\u003cli\u003e É possível rastrear fonte, versão, data de validade e proprietário dos documentos?\u003c/li\u003e\n\u003cli\u003e Os nomes e parâmetros das ferramentas são claros e não se sobrepõem?\u003c/li\u003e\n\u003cli\u003e As permissões de leitura, escrita, exclusão, pagamento e deploy estão separadas por nível de risco?\u003c/li\u003e\n\u003cli\u003e Há sandbox para isolar falhas e meios de reversão?\u003c/li\u003e\n\u003cli\u003e Todas as ações importantes e chamadas de ferramentas são registradas de forma reprodutível?\u003c/li\u003e\n\u003cli\u003e Há validadores externos, como testes, schema e verificações de política?\u003c/li\u003e\n\u003cli\u003e Estão definidas condições de número máximo de iterações, custo, tempo e encaminhamento humano?\u003c/li\u003e\n\u003cli\u003e Há avaliação de regressão para garantir que novas melhorias não quebrem casos existentes?\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\u003ca href=\"#conclusão\" class=\"anchor\" id=\"conclusão\"\u003e\u003c/a\u003eConclusão\u003c/h2\u003e\n\u003cp\u003eUm bom sistema de IA não é o sistema com o prompt mais longo. É o sistema que distingue se a falha ocorreu em \u003cstrong\u003einstruções\u003c/strong\u003e, \u003cstrong\u003einformações\u003c/strong\u003e, \u003cstrong\u003eambiente\u003c/strong\u003e, \u003cstrong\u003etomada de decisão\u003c/strong\u003e ou \u003cstrong\u003evalidação e recuperação\u003c/strong\u003e, 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.\u003c/p\u003e\n","tags":["Engenharia de prompts","Engenharia de contexto","Engenharia de harness","Agentes de IA","Avaliação de IA"],"faqs":[{"question":"As cinco abordagens de engenharia precisam necessariamente ser introduzidas em ordem?","answer":"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."},{"question":"A engenharia de contexto substitui a engenharia de prompts?","answer":"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."},{"question":"Qual é a diferença entre engenharia de contexto e engenharia de harness?","answer":"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."},{"question":"Como um agente difere da automação de fluxo de trabalho comum?","answer":"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."},{"question":"Em que a engenharia de loops difere de uma simples nova tentativa?","answer":"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."},{"question":"Quando devo usar múltiplos agentes?","answer":"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."},{"question":"Posso deixar a AI avaliar seus próprios resultados?","answer":"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."},{"question":"O que deve ser incluído na documentação do harness?","answer":"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."},{"question":"Qual é o princípio de segurança mais importante ao colocar documentos externos no contexto?","answer":"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."},{"question":"Por onde uma equipe pequena deve começar?","answer":"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":[{"url":"https://platform.claude.com/docs/ko/build-with-claude/prompt-engineering/overview","title":"Visão geral da engenharia de prompts - Claude Platform Docs","type":"source"},{"url":"https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents","title":"Engenharia de contexto eficaz para agentes de IA","type":"source"},{"url":"https://openai.com/index/harness-engineering/","title":"Engenharia de harness: aproveitando o Codex em um mundo centrado em agentes","type":"source"},{"url":"https://www.anthropic.com/engineering/building-effective-agents","title":"Criando agentes eficazes","type":"source"},{"url":"https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/","title":"Um guia prático para criar agentes","type":"source"},{"url":"https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents","title":"Desmistificando avaliações para agentes de IA","type":"source"},{"url":"https://martinfowler.com/articles/harness-engineering.html","title":"Engenharia de harness para usuários de agentes de programação","type":"source"}],"images":[{"id":192,"url":"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","is_representative":true,"generation_method":"upload","mime_type":"image/webp","original_filename":"ChatGPT Image 2026년 7월 16일 오후 04_12_32.png","translations":{"ko":{"alt":"중앙 AI 허브와 지시, 정보, 도구, 자율 실행, 검증 루프 모듈이 연결된 시스템 구조","caption":"다섯 가지 AI 엔지니어링 방식이 하나의 시스템에서 연결되고 반복 개선되는 구조를 보여준다.","description":null},"en":{"alt":"Central AI hub connected to instruction, context, tools, autonomous action, and validation loop modules","caption":"The illustration shows five AI engineering approaches working together in a connected improvement cycle.","description":null},"ja":{"alt":"中央のAIハブに指示、情報、ツール、自律実行、検証ループの各モジュールが接続された構成","caption":"5つのAIエンジニアリング手法が連携し、反復的に改善される仕組みを表している。","description":null},"es":{"alt":"Núcleo central de IA conectado con módulos de instrucciones, contexto, herramientas, acción autónoma y validación","caption":"La ilustración muestra cinco enfoques de ingeniería de IA integrados en un ciclo de mejora continua.","description":null},"id":{"alt":"Pusat AI terhubung ke modul instruksi, konteks, alat, tindakan otonom, dan siklus validasi","caption":"Ilustrasi ini menunjukkan lima pendekatan rekayasa AI yang bekerja bersama dalam siklus perbaikan.","description":null},"pt":{"alt":"Núcleo central de IA ligado a módulos de instruções, contexto, ferramentas, ação autônoma e validação","caption":"A ilustração mostra cinco abordagens de engenharia de IA integradas em um ciclo contínuo de melhoria.","description":null},"zh-hant":{"alt":"中央 AI 核心連接指令、情境、工具、自主執行與驗證迴圈模組的系統架構","caption":"圖中呈現五種 AI 工程方法如何協同運作並形成持續改進的循環。","description":null}}},{"id":193,"url":"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","is_representative":false,"generation_method":"upload","mime_type":"image/webp","original_filename":"ChatGPT Image 2026년 7월 16일 오후 04_36_26.png","translations":{"ko":{"alt":"지시 설정부터 정보 선별, 안전 환경, 자율 실행, 검증 반복까지 이어지는 AI 구축 파이프라인","caption":"AI 시스템을 단계적으로 설계하고 검증 결과를 앞 단계에 반영하는 실무 흐름을 보여준다.","description":null},"en":{"alt":"AI build pipeline from instruction setup and context filtering to safe execution, autonomous action, and validation loops","caption":"The illustration shows a step-by-step AI workflow with feedback loops returning results to earlier stages.","description":null},"ja":{"alt":"指示設定、情報選別、安全な実行環境、自律動作、検証ループへ続くAI構築パイプライン","caption":"AIシステムを段階的に設計し、検証結果を前の工程へ反映する流れを示している。","description":null},"es":{"alt":"Flujo de creación de IA con instrucciones, filtrado de contexto, entorno seguro, acción autónoma y validación iterativa","caption":"La ilustración muestra un proceso gradual de diseño de IA con ciclos de retroalimentación hacia etapas anteriores.","description":null},"id":{"alt":"Alur pembangunan AI dari pengaturan instruksi dan penyaringan konteks hingga eksekusi aman, tindakan otonom, dan validasi","caption":"Ilustrasi ini menunjukkan tahapan perancangan sistem AI dengan umpan balik ke proses sebelumnya.","description":null},"pt":{"alt":"Fluxo de construção de IA com instruções, filtragem de contexto, ambiente seguro, ação autônoma e validação iterativa","caption":"A ilustração mostra um processo gradual de projeto de IA com ciclos de retorno às etapas anteriores.","description":null},"zh-hant":{"alt":"從指令設定、情境篩選與安全環境，到自主執行和反覆驗證的 AI 建置流程","caption":"圖中呈現 AI 系統的分階段設計流程，以及驗證結果回饋至前序階段的機制。","description":null}}}],"published_at":"2026-07-16T17:00:54+09:00","updated_at":"2026-07-16T17:00:54+09:00","license":"cc_by","translation_status":"machine","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant"],"url":"https://injoys.com/en/articles/prompt-context-harness-agentic-loop-engineering"}