2026-07-22 · Atualizado 2026-07-22

[!NOTE] Tradução automática Este artigo foi traduzido automaticamente a partir da versão original em inglês.

Harness engineering para agentes AI: projetar o ciclo em torno do modelo

Parte 6 da série Engenharia da pilha Agentic

O reasoning loop de um agente seleciona a próxima ação. O seu harness fornece contexto, valida e autoriza os tool calls propostos, envia as chamadas aceites para o runtime, regista os resultados e decide se a tarefa está concluída.

Os modelos propõem alterações e podem declarar tarefas como concluídas, enquanto o harness controla as permissões e analisa as verificações de aceitação que determinam se o ciclo pode ser interrompido. Parte 5 Abordou o runtime que mantém o processo ativo. Este artigo foca-se no código de controlo presente nesse runtime: como avaliar se cada alteração é benéfica e como garantir que os controles resultantes permaneçam localizáveis à medida que o harness sofre mudanças.

Para além da primeira verificação explícita de aceitação, cada tentativa de repetição, transferência ou evaluador adicionado representa uma hipótese relativa a uma falha observada. Ele só ganha relevância quando uma comparação controlada demonstra que contribui para a resolução do problema.

Para concretizar esse caminho de controlo, vou utilizar um pequeno repositório de loja fictício. A tarefa de programação consiste em reduzir o limiar para um desconto automático de 10% de $100 para $75. src/checkout.py. O repositório possui duas verificações obrigatórias:

• pytest tests/test_checkout.py verifica o cálculo do desconto. pnpm playwright test tests/checkout_discount.spec.ts Adiciona um artigo no valor de $80 numa loja de teste local e verifica se a página de finalização de compra exibe um desconto de $8.

O exemplo é um recurso didático, e não uma aplicação real ou benchmark. Cada tentativa parte do mesmo commit e dos dados de teste iniciais. O harness só poderá aceitar a alteração quando ambas as comandos derem certo e o rastreio associar esses resultados ao commit testado.

As secções seguintes alternam deliberadamente por outros dois exemplos. Uma ordem de teste API ilustra por que é que as chamadas que alteram o estado necessitam de proteção contra repetição, enquanto uma migração de adaptador de pagamentos demonstra o que é necessário para que uma nova sessão de modelo retome o trabalho inacabado. O laboratório complementar perto do final é novamente separado: pode ser executado, mas contém tarefas simuladas genéricas em vez deste repositório de loja.

TL;DR: Comece com um modelo, algumas ferramentas especializadas e uma verificação explícita de aceitação. Adicione tentativas repetidas após os rastreios indicarem falhas temporárias nas chamadas. Implemente uma transferência de progresso sempre que sessões retomadas repetirem o mesmo trabalho. Ao testar qualquer alteração, mantenha a versão do modelo, as tarefas, o avaliador e o orçamento total inalterados. Remova o componente quando este não melhorar o resultado medido.

O diagrama acompanha a alteração de desconto da proposta para a evidência. O harness fornece a tarefa e os ficheiros, verificando a proposta apresentada edit_file os argumentos e as permissões, e envia a chamada aceite. Após o runtime aplicar a edição, o harness executa os testes de unidade e de aceitação no navegador especificados. Um comando falhado é devolvido ao modelo como evidência para uma nova tentativa; dois comandos bem-sucedidos tornam a alteração elegível para aceitação.

O que o harness possui

da OpenAI Visão geral do ciclo Codex Descreve o ciclo básico. O harness monta um prompt, solicita ao modelo a ação seguinte, envia um tool call aceite para o runtime, anexa o resultado e pergunta novamente até que o harness aceite o resultado ou devolva o controlo ao utilizador.

As implementações podem fundir várias responsabilidades num único processo. As fronteiras de falha continuam a ser diferentes:

Quando ocorre uma falha, deve‑se diagnosticar o limite que deveria responder. Um plano insuficiente pode exigir instruções mais precisas ou um raciocínio de modelo mais eficaz. Se edit_file direciona‑se para um caminho fora src/O harness deve rejeitá‑lo, enquanto um processo sandbox que termina antes da execução da edição pertence ao runtime, o qual deve reiniciar o worker ou reportar a falha.

o próprio da OpenAI harness – estudo de caso de engenharia Descreve uma instância de aplicação inicializável para cada worktree. A equipa integrou também a automação de navegadores no ambiente do agente, além de disponibilizar registos, métricas e rastreios.

Uma tarefa como “nenhum intervalo nestas quatro jornadas críticas do utilizador excede dois segundos” passou a ser testável porque o agente conseguia executar a aplicação e consultar os mesmos indicadores que um engenheiro analisaria. O estudo de caso é específico do produto. O que é transferido é a condição por trás do resultado: a aplicação e os seus indicadores de desempenho tinham de estar disponíveis no ambiente do agente.

Lopopolo, o autor daquele estudo de caso, mantém um Guia prático para harness de engenharia Esse texto identifica as duas abordagens fundamentais abordadas neste artigo: tratar o modelo e o agente de codificação como caixas pretas imutáveis, e projetar o contexto e as ferramentas que os rodeiam. A forma como ele apresenta o assunto também explica por que grande parte do harness acaba se transformando em código comum.

A barra de qualidade, os procedimentos, o histórico de exceções e as relações de autoridade de uma organização encontram‑se abaixo do nível de conhecimento que um modelo genérico consegue alcançar. O harness traz esses elementos à tona na forma de instruções de repositório, regras de permissão e verificações de aceitação. Cada execução aceite pode repassar as suas lições para esses artefatos, em vez de depender da sessão seguinte para as redescobrir.

Siga a alteração do desconto desde a proposta até à aceitação

Para a tarefa de desconto definida acima, o modelo propõe alterar calculate_discount em src/checkout.py. Acontecem várias coisas antes disso a edição é considerada um progresso:

1. O construtor de contexto fornece a tarefa, as instruções do repositório, os ficheiros relevantes, o tool results anterior e o plano atual.
2. O modelo propõe um edit_file chamar com um caminho e texto de substituição.
3. A fronteira da ferramenta (o código harness entre a proposta e a execução) valida os argumentos, verifica o caminho em relação ao escopo permitido e solicita aprovação caso a operação a exija.
4. O runtime aplica a edição no sandbox e devolve um resultado estruturado.
5. O harness é executado pytest tests/test_checkout.py, seguido de pnpm playwright test tests/checkout_discount.spec.ts, e lê ambos os códigos de saída. O teste no navegador verifica o desconto visível de $8 no carrinho inicializado em $80.
6. O harness determina o significado dos resultados. Uma verificação falhada torna‑se o novo contexto para a próxima iteração do modelo, enquanto uma execução bem‑sucedida torna a tarefa um candidato a conclusão.
7. Um resultado positivo só se torna evidência de conclusão após o harness registrar o comando, o código de saída e a versão do artefato testado no registo de trilhas.

Na etapa 2, nenhum ficheiro foi alterado. O harness pode rejeitar isso. ../../secrets.env, é necessário obter aprovação para executar uma instrução destrutiva ou interromper uma execução que esgotou o seu orçamento. Após a execução dos testes, o harness lê os seus códigos de saída por si mesmo. O modelo não pode marcar a sua própria edição como aprovada.

O rasto deve exibir o caminho proposto e o texto de substituição, a decisão de permissão, os ficheiros que foram alterados, o commit testado e os resultados de ambas as comandos. Uma versão final done A mensagem sem esses registos não prova que esta alteração passou nos controlos exigidos.

Decida onde cada regra é aplicada

Colocar tests/checkout_discount.spec.ts dentro da lógica normal de um programa. O harness envia o comando Playwright para o runtime, lê o seu código de saída e se recusa a encerrar a execução enquanto houver falhas. Um prompt pode lembrar o modelo de executar o teste. No entanto, não consegue impedir que o modelo declare sucesso sem evidências concretas.

Outras regras aplicam-se a camadas diferentes:

Os contratos de ferramenta separam a proposta da autorização

A tarefa de desconto requer apenas edições de ficheiros e comandos de teste. Um API que altera o estado possui um modo de falha diferente, portanto devem ser utilizados exemplos alternativos para esta secção. Suponhamos que o agente consiga fazer chamadas create_test_order contrariamente a um serviço de ordem de preparação durante a criação de dados de teste. Esta ferramenta não faz parte das verificações de aceitação da tarefa de desconto. Ela é útil nesse contexto porque um tempo de espera excessivo pode ocultar se o serviço criou realmente uma ordem.

A definição dos limites da ferramenta requer mais do que uma descrição em linguagem natural. Para create_test_order, o harness necessita de um contrato com:

• argumentos validados, de modo que entradas mal formatadas são rejeitadas antes da execução
• um resultado estruturado como { "order_id": "123", "created": true }, portanto as verificações posteriores não precisam de analisar texto em formato livre
• uma categoria de efeito que regista se a chamada apenas obtém informações ou altera um ficheiro, um registo de base de dados ou um serviço externo. Regista também se é seguro repetir a chamada. Este rótulo indica ao harness se uma tentativa automática de repetição poderia duplicar trabalho: pode tentar novamente get_order_status quando o serviço define essa consulta como de leitura apenas, mas não deve tentar novamente de forma cega create_test_order pois a primeira chamada já pode ter criado a encomenda
• uma política de tempo limite e tentativas, de modo que uma resposta perdida não desencadeie uma sequência ilimitada de chamadas
• uma regra de permissão que especifica que tipo de aprovação é necessária. A leitura do estado da encomenda pode ser realizada automaticamente, enquanto a criação de uma encomenda pode exigir confirmação

A descrição em linguagem natural é o texto exibido ao modelo. Pode conter frases como: “Crie uma encomenda de teste para verificação no checkout.” Essa frase ajuda o modelo a decidir quando propor create_test_order. Não autoriza a chamada. Neste exemplo, o cliente do harness’s MCP valida os argumentos, aplica as suas próprias regras e verifica a confiança no servidor, os requisitos de aprovação e os critérios de segurança para tentativas repetidas antes de enviar qualquer dado.

Um servidor MCP publica descrições de ferramentas e anotações opcionais sobre comportamento para o cliente. Um servidor defeituoso ou malicioso pode descrever uma ferramenta que altera estados como sendo inofensiva. Se o cliente aceitar automaticamente essa afirmação, poderá executá-la ou tentar novamente create_test_order sem aprovação e criar um duplicado, pelo que a especificação MCP exige que os clientes tratem Anotações de ferramenta como não fidedignas a menos que o próprio servidor seja considerado fidedigno.

A especificação não define uma configuração de confiança universal. Por isso, o cliente necessita de uma política de confiança explícita para a sua implementação; um servidor não pode tornar as suas próprias anotações confiáveis. Essa política determina quais metadados podem influenciar as decisões relativas a permissões ou tentativas de recuperação, e quais anotações permanecem apenas como recomendações.

Tentar novamente uma chamada que altera estado requer proteção contra reprodução não autorizada

Surge um problema mais complexo de tentativa de recuperação quando create_test_order É criada a encomenda, mas a sua resposta HTTP é perdida. O harness deteta um tempo de espera e não consegue determinar se o servidor concluiu o pedido. Repetir a chamada pode gerar uma segunda encomenda.

Uma consulta de estado pode ser tentada novamente quando o serviço a define como somente leitura. Uma chamada de criação requer proteção, como uma chave de idempotência: o cliente anexa um identificador único de solicitação, e o serviço devolve o primeiro resultado em vez de criar outra encomenda ao detectar esse mesmo identificador. Sem essa proteção, o harness deve verificar se a encomenda já existe ou solicitar uma decisão humana antes de realizar outra tentativa. A AWS descreve este padrão nos seus documentos orientações para operações idempotentes API.

A aceitação requer evidências independentes

Um sucesso create_test_order A resposta indica apenas que a ferramenta retornou dados. Ela não comprova que uma tarefa de programação superou os seus testes. Se um teste de navegador posterior depender da ordem de execução, o harness deve validar o esquema da resposta e ainda executar esse teste antes de aceitar a alteração no código.

Alguns critérios não podem ser traduzidos num código de saída. Para uma tarefa distinta de design visual, um avaliador novo pode comparar uma página ou diagrama gerado com uma rubrica escrita. As equipas devem verificar esse avaliador face a revisões realizadas por humanos antes de o utilizarem como porta de controlo para a conclusão do trabalho.

A migração do adaptador de pagamentos requer uma transferência de responsabilidades

Mude novamente de tarefa, mas permaneça no repositório da loja fictícia. O agente agora precisa migrar o processo de pagamento do adaptador v1 para o v2. Este trabalho abrange o manipulador de checkout, o cliente de pagamento, as configurações e os testes, pelo que pode durar mais do que uma única sessão do modelo.

Antes de a primeira sessão atingir o seu limite de contexto, ela modificou vários ficheiros, iniciou um pagamento local sandbox e saiu tests/payment_migration.spec.ts Falha. Esse teste de aceitação no navegador conclui um pagamento através do adaptador v2 e verifica o ID do fornecedor registado. Um resumo da conversa pode orientar a próxima sessão do modelo, mas não consegue reiniciar o sandbox nem comprovar quais ficheiros estão atualmente modificados.

A próxima sessão tem de recuperar três elementos:

A compactação substitui mensagens mais antigas por um resumo mais curto, permitindo que a sessão atual continue. Uma transferência de estado regista o que é necessário para a próxima sessão: o ramo atual, os ficheiros modificados, a última ordem de teste e os seus resultados, bem como o próximo passo ainda não resolvido. Se a conversa anterior conter pressupostos desatualizados, o harness pode iniciar uma nova sessão do modelo com essa informação e o espaço de trabalho atual. A substituição de um processo corrompido e a restauração dos seus processos constituem uma tarefa de recuperação separada, denominada runtime.

Uma pequena edição na documentação pode não exigir nenhum destes mecanismos. A migração de pagamentos requer uma transferência de responsabilidades assim que o trabalho ultrapassa as sessões atuais, pois a próxima sessão do modelo deve reconstruir tanto o espaço de trabalho como o estado da tarefa.

os experimentos da Anthropic com agentes de programação de execução prolongada utilizava o histórico do Git e um ficheiro de progresso entre sessões, enquanto as versões posteriores harness-relatório de projeto Separa a compactação da transferência de contexto fresco e informa sobre a orquestração adicional, o consumo de tokens e o tempo gasto com essas transferências.

Utilize rastreios para distinguir três tipos de falhas

As três linhas seguintes são esboços ilustrativos de trilhas, e não resultados de execuções medidas ou saídas do laboratório associado. Cada linha representa um tipo diferente de falha e, consequentemente, uma resposta distinta para o harness.

Esta distinção é importante porque um 503 Isto não torna todas as chamadas seguras para serem reenviadas. A primeira linha corresponde a uma consulta de leitura apenas. A segunda linha representa um pedido que altera o estado, pelo que a chave de idempotência e o estado no lado do servidor determinam se é permitida outra tentativa de criação. A terceira linha não indica falha alguma na ferramenta; o harness ainda não recolheu as provas necessárias para aceitar a alteração no desconto.

Uma transcrição de chat regista o que o modelo processou. Não é possível comprovar se o serviço de pedidos efetuou uma requisição antes de a resposta desaparecer. O rasto deve incluir a chamada feita pelo cliente, a decisão de aprovação, a chave de idempotência, o resultado ou consulta de estado do servidor, a confirmação da operação testada e o resultado do teste de aceitação. Esses campos indicam ao harness qual dos três caminhos está a seguir.

Antes de adicionar um componente, defina o falhanço recorrente que ele deve reduzir e o valor que irá ser monitorizado. Remova o componente se uma comparação controlada não conseguir diminuir esse valor suficientemente para compensar o seu custo.

Medir uma alteração de cada vez

Uma ablação avalia se um componente harness é responsável pelo efeito esperado, alterando ou removendo esse componente, mantendo o resto do experimento inalterado. Por exemplo, será que a verificação de sintaxe do editor ajuda este modelo neste conjunto de tarefas?

Utilize o seguinte protocolo:

1. Congele a versão do modelo, as instâncias de tarefa, o ambiente, o avaliador e prompts fora da componente em teste.
2. Assegure que ambas as variantes disponham do mesmo orçamento total em termos de tokens, tempo e recursos financeiros.
3. Escolha o número de tentativas ou a regra de interrupção antes de executar a comparação.
4. Execute as mesmas instâncias de tarefa em ambas as variantes. Como as saídas do modelo variam, repita cada tarefa várias vezes.
5. Relate a média juntamente com a dispersão ou o intervalo de confiança.
6. Conte todas as tentativas iniciadas, incluindo tempos de espera, interrupções por política, falhas harness e erros no processo de avaliação.

A taxa de sucesso por si só pode ocultar a existência de um componente dispendioso. No mínimo, deve-se monitorizar as tarefas com falhas que foram consideradas concluídas, o custo e o tempo gasto por cada tarefa finalizada, os erros das ferramentas, os pedidos duplicados, os minutos gastos em revisões e as anulações manuais de permissões. Escolha a métrica que reflete realmente o custo associado ao produto. Um aumento de dois pontos nas tarefas concluídas é uma troca desfavorável se isso fizer com que a fila de revisões dobre de tamanho.

Um experimento de migração de pagamentos emparelhado permite que a transição de progresso seja medida de forma objetiva. Cada par de controlo/tratamento parte do mesmo commit do repositório e é inicializado com checkpoint, utilizando o mesmo modelo, tarefa, sistema de avaliação e orçamento total. A transição representa a única alteração introduzida no processo. A métrica principal conta as ações duplicadas realizadas após a retomada: uma ação é considerada duplicada quando a sua operação e o respetivo artefato correspondem a um passo que já foi concluído na sessão anterior.

O Artigo sobre SWE-agent Corrige o GPT-4 Turbo no subconjunto de 300 tarefas do SWE-bench Lite e reporta 18,0% de tarefas resolvidas com a sua interface completa, em comparação com 11,0% para o agente que utiliza apenas a interface de linha de comando. O artigo também modificou as funcionalidades individuais da interface:

Estes números referem‑se a esse modelo, benchmark, e ao limite de $4 por tarefa. O without linting, full file, e full history As linhas representam os testes úteis de uma única característica: em cada um deles, era alterada apenas uma funcionalidade da interface, mantendo-se o modelo e a configuração de avaliação inalterados.

LangChain publicou uma versão mais abrangente comparação de modelos fixos para deepagents-cli. Relata um aumento de Terminal-Bench 2.0, passando de 52,8% para 66,5%, com gpt-5.2-codex Foi resolvido enquanto a sua equipa alterava o system prompt, as ferramentas e o middleware. A publicação agrupa várias alterações e omite o intervalo de confiança, a comparação do orçamento total fixo e a tabela de ablação por alteração. Esse resultado não consegue identificar qual a alteração mais útil.

da Anthropic relatório de aplicação em execução prolongada Trata‑se de um estudo de caso qualitativo e específico de produto, em vez de um experimento controlado benchmark. O seu avaliador verificou 27 critérios do editor de níveis na Sprint 3. A equipa relata que as chamadas feitas pelo avaliador passaram a representar um custo adicional nas tarefas que o Opus 4.6 conseguia concluir de forma fiável por conta própria, mas que ainda assim eram úteis perto dos limites do modelo; por isso, após a atualização do modelo, foram removidas as componentes harness uma a uma. Este exemplo serve como motivo para revalidar as estruturas antigas quando o modelo é alterado; contudo, não permite estimar um tamanho de efeito geral.

Mantenha o harness editável após ele ter sido integrado no sistema

A ablação mantém um harness pequeno, mas o seu código pode ainda sobreviver ao modelo para o qual foi ajustado. Um pedido como “mascarar segredos em cada caminho de captura” refere‑se a um comportamento, e não a um ficheiro. Num harness em produção, esse comportamento pode abranger várias fases de execução e estados partilhados. Um humano ou um agente de programação deve encontrar todos os locais de implementação antes de os alterar de forma segura.

Um preprint de 2026 de Wang et al., o Harness Manual, Chama-se a esta etapa behavior localization. O manual cria um mapa centrado no comportamento a partir da base de código harness. A análise estática extrai um grafo de programa sem chamadas a modelos e, em seguida, um LLM organiza as suas unidades em fases de execução.

O mantenedor ou agente de programação começa com uma visão geral do sistema, abre a fase de execução relevante e desce até às entradas baseadas na fonte de uma função ou ficheiro. Uma visualização de registo regista onde o estado partilhado é escrito e lido entre as fases. Esta hierarquia mantém a visão geral concisa, ao mesmo tempo que preserva um caminho até à fonte.

A atualidade é uma regra distinta. Cada localizador deve ser resolvido em relação ao repositório ativo. O manual exclui entradas desatualizadas em vez de fazer suposições, e cada diferença não vazia resincroniza as entradas que afeta.

O diagrama simplifica o ciclo de modificação: um pedido que contém apenas informações comportamentais desce pelos níveis do manual; cada localizador candidato é verificado em relação ao repositório ativo antes que o plano seja criado, e cada diferença aplicada realiza uma resincronização do mapa.

O Avaliação de manual segue o protocolo defendido neste artigo. Em dois frameworks de código aberto (Terminus-2, seis ficheiros em Python e o monorepo Codex, com 2.267 ficheiros em Rust), um planeador somente de leitura alimentado pelo DeepSeek-V4-Pro explorou diretamente o repositório ou foi direcionado através do manual. Os pedidos, as permissões do repositório e das ferramentas, bem como o processo de decodificação, foram idênticos em ambos os cenários. Três avaliadores (GPT-5.5, Opus 4.8 e DeepSeek-V4-Pro) avaliaram cada plano de edição em termos de localização, controlo de escopo e raciocínio:

O planeador assistido por manual obteve mais vitórias e utilizou menos tokens de planeamento em ambos os repositórios. As condições associadas a esse resultado mantêm-se as mesmas: três LLM juízes avaliaram os planos de edição gerados por um modelo de planeador em dois ambientes de teste. O estudo analisou os planos, e não as diferenças efetivamente executadas nem as taxas de defeitos na produção.

As secções anteriores utilizam rastreios para explicar por que um componente existe. Este mapa responde à próxima questão: onde fica esse componente quando precisa ser alterado?

Teste o método no laboratório de apoio

O harness – projeto de demonstração no commit 517353f3 é um exercício pequeno e determinístico com 12 tarefas sintéticas genéricas que abrangem alterações de código, como fix-parser-edge-case, split-large-module, e wire-browser-test. Ele não implementa o repositório de loja fictício.

Cada fixture de tarefa declara um nível de dificuldade além de quatro condições booleanas: uma ferramenta instável, perda de progresso, uma lacuna na implementação não resolvida e uma conclusão ambígua. O simulador determina uma quinta condição para tarefas difíceis que também exigem um ficheiro de progresso: sem context_reset, a compactação preserva suposições obsoletas. Um avaliador determinístico marca uma tarefa como concluída apenas quando a configuração selecionada lida com todas as condições aplicáveis. Nenhum modelo nem serviço externo é executado.

Os comandos respondem a perguntas diferentes:

• make check executa o Ruff e sete testes unitários, incluindo o validador que rejeita qualquer par de ablações que altere mais do que um componente. make run imprime uma matriz de ensino cumulativa e, em seguida, cinco comparações válidas de tipo “deixar um componente de fora”. make failures dá um nome à condição não tratada para cada tarefa falhada. O harness completo deve terminar com all synthetic tasks pass.

make check
make run
make failures

A secção causal de make run Parece ser isto:

component                 control  treatment  delta
retry_policy              8/12     12/12       +4
progress_handoff          7/12     12/12       +5
evaluator                 8/12     12/12       +4
fail_closed_acceptance    7/12     12/12       +5
context_reset            10/12     12/12       +2

Para cada linha, o controlo corresponde à configuração completa com um componente removido; o tratamento restabelece apenas esse componente. A matriz cumulativa anterior é útil para efeitos de orientação, mas algumas das suas linhas adjacentes adicionam vários componentes de uma só vez e, por isso, não conseguem identificar uma causa específica.

O laboratório valida cada par declarado antes de o executar. Os seus testes de regressão incluem também um par intencionalmente inválido que altera em conjunto a política de repetição e o avaliador; o validador rejeita-o.

O esquema de configuração do laboratório verifica todos os cinco campos de componente. Este excerto executável mostra a mesma proteção aplicada a um par válido de transferência de progresso:

from dataclasses import dataclass, fields


@dataclass(frozen=True)
class Config:
    progress_handoff: bool = False
    evaluator: bool = False
    retry_policy: bool = False
    fail_closed_acceptance: bool = False
    context_reset: bool = False


def changed_components(control: Config, treatment: Config) -> tuple[str, ...]:
    return tuple(
        field.name
        for field in fields(control)
        if getattr(control, field.name) != getattr(treatment, field.name)
    )


control = Config(progress_handoff=False, evaluator=True, retry_policy=True)
treatment = Config(progress_handoff=True, evaluator=True, retry_policy=True)
assert changed_components(control, treatment) == ("progress_handoff",)

Comece com um ciclo e uma verificação de aceitação

Eu começaria por criar um agente de programação harness com um modelo capaz, instruções para o repositório, algumas ferramentas especializadas, um sandbox, e um teste de aceitação explícito. Registaria tool calls, os resultados, os custos e esse teste final num único registo de rastreio, de modo que os primeiros falhas úteis fiquem visíveis sem ser necessário reconstruí-los a partir de logs de terminal ou transcrições de conversas. Trata‑se de uma linha de base proposta, e não de evidências provenientes de um sistema já implantado.

A partir daí, adicione apenas o que um registo de execução justifica. Registe quem mantém cada componente, quantos tokens ou segundos ele adiciona, e qual teste de regressão justificaria a sua remoção após uma atualização do modelo.

Seis meses depois, alguém que observar progress_handoff=True Deve ser capaz de identificar os rastreios com falhas que justificaram essa situação, bem como os casos de regressão que ainda o mantêm nesse estado. Os rastreios explicam por que o componente existe; um mapa de comportamento atual indica onde intervir.

Referências

• OpenAI, Desenrolar o Codex agent loop.
• OpenAI, Harness engineering: a utilização do Codex num mundo orientado para agentes.
• Lopopolo, Harness engineering: antologia, guia de campo e pacote de contexto do agente.
• Engenharia Anthropic, Mecanismos eficazes para agentes em execução de longa duração.
• Engenharia Anthropic, Harness design para o desenvolvimento de aplicações de execução contínua.
• LangChain, Melhorar Agentes Profundos com harness engineering.
• Yang et al., SWE-agent: As interfaces agente-computador permitem a engenharia de software automatizada.
• Wang et al., Harness Manual: Tornar os Ferramentários de Agente em Evolução Legíveis, Navegáveis e Editáveis, arXiv:2607.13285, 2026.
• AWS, Tornar as tentativas de repetição seguras através de operações idempotentes APIs.
• Protocolo de Contexto do Modelo, Especificação de ferramentas.

Série: Engenharia da pilha Agentic

• Parte 1: AI Laços de Raciocínio de Agente em 2026: ReAct, ReWOO e Plan-and-Execute Parte 2: AI Arquitetura de Memória de Agente em 2026: checkpoints, armazenamentos vetoriais e memória de documentos Parte 3: AI Agente Tool Use em 2026: MCP, CLI, competências, execução de código e ACI
• Parte 4: AI Segurança de Agentes em 2026: regras de segurança, permissões, sandboxes, HITL e delimitação de escopo de MCP Parte 5: Agente AI de execução contínua Runtime em 2026: sessões, sandboxes, checkpoints, mecanismos de aproveitamento e formas de implementação
• Parte 6: Harness Engineering para Agentes AI (este artigo)