O que é um harness de agent? Pesquisas, projetos de código aberto e práticas do setor

Dois agents podem usar exatamente o mesmo modelo e obter pontuações muito diferentes no mesmo benchmark. A OpenAI mediu isso diretamente: no SWE-bench Lite, o GPT-4 obteve 2,7% com um harness e 28,3% com outro — uma diferença de 10 vezes criada inteiramente pelo harness. À medida que o setor passou de “qual modelo é mais inteligente” para “qual agent realmente conclui o trabalho”, o harness de agent se tornou a camada em que a confiabilidade é conquistada ou perdida. Continue lendo para entender o que é um harness de agent, o que dizem os artigos e benchmarks mais recentes sobre o design de harnesses, quais harnesses de código aberto valem seu tempo e como os principais laboratórios de IA projetam os seus — incluindo o Kimi K3.1 Pro, o modelo de pesos abertos que a Moonshot AI combina com seus próprios harnesses.

Um harness de agent é a infraestrutura ao redor que permite a um grande modelo de linguagem operar como um agent em um ambiente real. Enquanto o modelo produz tokens, o harness faz todo o resto: constrói o prompt a cada etapa, define quais ferramentas existem e como são chamadas, executa ações em um sandbox ou terminal, devolve observações ao modelo, impõe limites de etapas e custos e registra a trajetória completa para avaliação ou depuração.

O termo vem do universo da avaliação — um "test harness" é a estrutura que executa um sistema sob condições controladas. Na IA agêntica, a mesma ideia foi estendida à produção: um harness é tanto a estrutura usada para medir um agent (como no SWE-bench ou Terminal-Bench) quanto a usada para executar um agent (como no SWE-agent, OpenHands ou Claude Code).

A própria pesquisa da Anthropic sobre SWE-bench resume bem: o benchmark "não avalia apenas o modelo de IA isoladamente, mas sim todo um sistema de 'agent'", no qual o agent é "a combinação de um modelo de IA e a estrutura de software ao seu redor". Seu Claude 3.5 Sonnet atualizado alcançou 49% no SWE-bench Verified não com um framework complexo, mas com um harness mínimo de um prompt e duas ferramentas de uso geral (uma ferramenta Bash e uma ferramenta Edit).

Durante anos, os ganhos nos rankings foram atribuídos à escala dos modelos. Pesquisas recentes derrubaram essa premissa por duas vias.

Primeiro, o resultado de que "menos é mais": em julho de 2025, a equipe do SWE-bench lançou o mini-SWE-agent, um harness com cerca de 100 linhas de Python, sem ferramentas além de bash, um histórico de mensagens completamente linear e cada ação executada como uma chamada subprocess.run independente. Ele alcançou pontuações de benchmark competitivas com as de frameworks muito mais complexos (abordadas na seção de pesquisa abaixo). A lição foi provocadora: quando o modelo é suficientemente capaz, um harness extremamente simples e previsível pode superar um mais pesado. Ele já é usado como referência pela Meta, NVIDIA, IBM, Princeton e Stanford.

Segundo, o resultado de que "mais é menos": um harness ruim — saídas de ferramentas ruidosas, loops sem limite, recuperação de erros deficiente — pode fazer um modelo de ponta parecer mediano. A OpenAI constatou que corrigir as tarefas problemáticas do SWE-bench (detalhadas na seção da OpenAI abaixo) mais do que dobrou o desempenho medido dos modelos.

É por isso que a engenharia de harnesses se tornou uma disciplina própria. O harness determina:

• O que o modelo vê: a estrutura do prompt, os esquemas das ferramentas e quanto do estado do ambiente e do histórico é incluído na janela de contexto.

• O que o modelo pode fazer: quais ferramentas estão disponíveis (shell, editor de arquivos, navegador, busca) e como as ações são analisadas e validadas antes da execução.

• Como as falhas são tratadas: tentativas, tempos limite, compactação de contexto quando a janela se enche e encerramento controlado.

• Como o trabalho é medido: registro de trajetórias, avaliação e contabilização de custos — sem isso, não há avaliação nem ciclo de melhoria.

Seja uma estrutura de benchmark de pesquisa ou um assistente de programação em produção, quase todo harness de agent implementa o mesmo loop central:

1. Recebimento da tarefa: ler a issue, a instrução ou o objetivo e iniciar um ambiente isolado (geralmente um contêiner Docker ou um snapshot de VM).

2. Montagem do prompt: combinar o prompt de sistema, as definições das ferramentas, a descrição da tarefa e o histórico acumulado de ações e observações.

3. Análise de ações: traduza a saída do modelo em uma chamada concreta de ferramenta — um comando bash, uma edição de arquivo, uma solicitação de API — e rejeite ações malformadas.

4. Execução e observação: execute a ação no ambiente, capture stdout/stderr ou o estado da interface e trunque o resultado para caber no orçamento de contexto.

5. Fluxo de controle: imponha limites de etapas e de custo, além de condições de parada; decida quando pedir ajuda a uma pessoa ou encerrar o episódio.

6. Registro e avaliação: salve a trajetória completa e avalie o estado final — por exemplo, executando a suíte de testes do repositório no SWE-bench.

As decisões de design em cada etapa se acumulam. Só a estratégia de truncamento pode alterar significativamente as pontuações em tarefas de longo horizonte, por isso equipes sérias tratam o harness como software versionado e testável, e não como código de integração.

A literatura acadêmica sobre harnesses de agent chegou a um pequeno conjunto de conclusões conquistadas a duras penas. Em vez de catalogar cada benchmark, esta seção acompanha as questões de pesquisa que levaram a área a tratar o harness com seriedade.

Antes dos artigos, uma breve introdução. Um benchmark é um conjunto fixo de tarefas com uma regra de pontuação, criado para que sistemas diferentes possam ser comparados em condições idênticas. Na avaliação de agent, um benchmark tem três partes móveis: um conjunto de tarefas (issues reais do GitHub, comandos de terminal, tarefas na web), um ambiente de execução (um contêiner Docker, um navegador, um terminal) e um avaliador (uma suíte de testes, uma verificação de estado, uma revisão humana). O harness fica entre o modelo e os três — é ele que determina se a capacidade do modelo aparece na pontuação.

A forma como as pontuações são medidas importa mais do que o número de destaque. No SWE-bench, um agent produz um patch de código; o benchmark então executa duas suítes de testes: FAIL_TO_PASS (testes que falhavam antes da correção e agora devem passar) e PASS_TO_PASS (testes que funcionavam antes e não podem falhar). A tarefa só é considerada resolvida se ambas passarem. É por isso que recursos do harness, como execução de testes e geração de diff, não são extras opcionais — é neles que se ganham ou perdem pontos.

Três regras para interpretar qualquer pontuação de benchmark:

1. Pergunte o que a pontuação esconde. Um modelo treinado com dados públicos do GitHub pode já ter visto as próprias issues nas quais está sendo testado — a contaminação de dados pode inflar as pontuações sem nenhum ganho real de capacidade. Ambientes reproduzíveis e conjuntos de tarefas reservados para teste são o antídoto.

2. Cuidado com a lei de Goodhart: quando uma medida se torna uma meta, ela deixa de ser uma boa medida. Um harness ajustado para se sair perfeitamente em um benchmark pode estar aprendendo truques específicos daquele benchmark, em vez de desenvolver capacidade geral — por isso equipes sérias avaliam em mais de um.

3. Verifique o harness, não apenas o modelo. Como mostra o restante desta seção, o mesmo modelo pode obter 2,7% ou 28,3%, dependendo da estrutura de apoio. Uma pontuação sem um harness identificado é uma anedota, não uma medição.

O artigo original do SWE-bench ("Can Language Models Resolve Real-World GitHub Issues?") apresentou a avaliação hoje canônica: dar a um modelo uma issue real do GitHub e o repositório completo, e verificar se seu patch faz os testes que falhavam passarem. Seu resultado mais citado costuma ser mal interpretado: o melhor modelo da época, Claude 2, resolveu apenas 1,96% das tarefas. Os próprios autores afirmaram que o benchmark testava um "raciocínio complexo que vai muito além da geração tradicional de código" — mas trabalhos posteriores deixaram claro que grande parte da lacuna não era capacidade de raciocínio, e sim a ausência de um harness capaz de navegar por um repositório, executar testes e iterar. Em outras palavras, o SWE-bench não mediu apenas os modelos; revelou que o harness ao redor deles era a peça que faltava.

O artigo sobre SWE-agent ("Agent-Computer Interfaces Enable Automated Software Engineering") é o documento fundador da área sobre design de harnesses. Sua tese central é que o design da interface é uma variável de primeira ordem: os autores introduziram o termo Agent-Computer Interface (ACI) e mostraram que uma interface criada para esse propósito — um editor de arquivos protegido por linter, feedback conciso do shell e proteções contra comandos malformados — elevou o pass@1 no SWE-bench de poucos pontos percentuais para 12,5%, o estado da arte na época. A contribuição duradoura do artigo é defender que "agentes de LM representam uma nova categoria de usuários finais" que precisam de software criado para eles, assim como humanos precisam de IDEs. Todos os artigos posteriores sobre harnesses citam esse resultado.

Dois artigos de 2024 ampliaram a pesquisa sobre harnesses, de repositórios de código para o computador inteiro. OSWorld criou o primeiro ambiente escalável de computador real em Ubuntu, Windows e macOS, com 369 tarefas envolvendo aplicativos web e desktop. Seu número de destaque — humanos concluem 72,36% das tarefas, enquanto o melhor modelo conclui 12,24% — identificou o aterramento em GUI (traduzir a saída do modelo em cliques e teclas corretos) como o principal modo de falha, um problema de harness, não de conhecimento. WebArena adotou outra abordagem: um ambiente web auto-hospedado e totalmente reproduzível (e-commerce, fóruns, GitLab, CMS), no qual GPT-4 alcançou apenas 14,41% de sucesso de ponta a ponta, contra 78,24% dos humanos. Ambos os artigos estabeleceram que a avaliação de harnesses deve ser baseada em execução (verificando o estado final do ambiente), e não em correspondência de padrões nas saídas do modelo.

O τ-bench da Sierra ("A Benchmark for Tool-Agent-User Interaction in Real-World Domains") trouxe um ponto mais sutil: em produção, o harness não envolve apenas o modelo e o ambiente — ele também faz a mediação com o usuário. O benchmark simula conversas dinâmicas entre um usuário de modelo de linguagem e um agent com APIs de domínio e diretrizes de política, e então avalia o estado final do banco de dados. Sua métrica principal, pass^k (sucesso em k tentativas independentes), revelou como os agents são inconsistentes: GPT-4o resolveu menos de 50% das tarefas em uma única tentativa, e pass^8 caiu para menos de 25% no varejo. A lição para quem cria harnesses é que confiabilidade é uma propriedade distributiva, não uma propriedade de uma única execução — um harness que funciona uma vez não é um harness que funciona.

O "Measuring AI Ability to Complete Long Software Tasks" da METR introduziu o horizonte de tempo de conclusão de tarefas em 50%: a duração de uma tarefa (medida pelo tempo de conclusão humano) que um modelo finaliza com 50% de confiabilidade. Os modelos de fronteira passaram de minutos para cerca de uma hora entre 2019 e 2025, dobrando aproximadamente a cada sete meses. Para a engenharia de harnesses, esta é a descoberta mais consequente da década: o harness que limita um modelo de 2024 é peso morto para um modelo de 2026. A formulação da Anthropic é que cada componente de um harness incorpora uma suposição sobre o que o modelo não consegue fazer — e essas suposições ficam desatualizadas à medida que os modelos melhoram.

O benchmark original cresceu e se tornou um ecossistema que operacionaliza essas lições:

• SWE-bench Verified (com OpenAI, 2024): um subconjunto de 500 instâncias filtrado por humanos, que removeu tarefas subespecificadas ou avaliadas de forma injusta — 68,3% do conjunto original foi excluído, o que mais que dobrou as pontuações medidas e tornou-se o ranking padrão.

• SWE-smith (2025): um pipeline para gerar tarefas sintéticas de treinamento, para que os modelos possam ser treinados para harnesses de agent, e não apenas avaliados neles.

• mini-SWE-agent (2025): o harness de cerca de 100 linhas que agora supera 74% no SWE-bench Verified, demonstrando que um loop mínimo, apenas com bash e histórico linear, basta quando o modelo é forte — e tornando-se a referência padrão da comunidade.

• Terminal-Bench (Stanford × Laude, 2025): avaliação de tarefas de terminal baseada no framework Harbor, levando os harnesses além da edição de código e para a administração de sistemas.

• CodeClash (2025) e ProgramBench (2026): criação de software orientada a objetivos e do zero, estendendo os harnesses de correções de uma única issue para o desenvolvimento aberto.

O fio condutor de todos esses trabalhos é consistente: o harness não é infraestrutura, é o objeto de estudo. Informe o harness junto com a pontuação, mantenha o ambiente reproduzível e desconfie de qualquer resultado cujo harness não possa ser inspecionado.

Os harnesses open source são o ponto de partida da maioria das equipes. Os projetos abaixo combinam grandes comunidades no GitHub (dezenas de milhares de estrelas entre os líderes) com manutenção ativa:

Ao escolher entre elas, a regra prática da comunidade é: use a infraestrutura mínima capaz de expressar sua tarefa (a filosofia do mini-SWE-agent) e adicione complexidade somente quando uma falha mensurada exigir isso. DeepSeek Harness ocupa o extremo oposto do espectro — uma plataforma totalmente orientada por plugins para equipes que querem que todas as camadas sejam substituíveis —, mas ambas compartilham uma disciplina: um log de sessão durável, somente de acréscimo, como fonte única da verdade sobre o que o modelo viu.

Os laboratórios de ponta tratam a engenharia de infraestrutura como propriedade intelectual central, e vários deles publicaram suas ideias com um nível incomum de detalhamento.

A Anthropic publicou o registro público mais completo sobre engenharia de infraestrutura, e sua arquitetura — detalhada em Building Effective Agents (2024), a publicação sobre a infraestrutura do SWE-bench (2024) e Managed Agents (2026) — pode ser entendida como três camadas concêntricas.

A camada de execução é deliberadamente mínima: uma ferramenta Bash para executar comandos e uma ferramenta Edit para visualizar e modificar arquivos. O esforço de design foi voltado a tornar essas ferramentas à prova de erros — exigindo caminhos absolutos, truncando saídas longas e aplicando edições apenas a uma correspondência única de string — para que o modelo raramente precise se recuperar de falhas evitáveis nas ferramentas.

A camada de sessão é um log de eventos durável, somente de acréscimo, que fica fora da janela de contexto do modelo. Cada ação e observação é registrada nele; o contexto do modelo é uma projeção desse log, não o log em si. Essa separação permite reiniciar e retomar uma infraestrutura que falhou no meio da tarefa, além de torná-la um "gado" descartável, e não um animal de estimação.

A camada de orquestração — que a Anthropic chama de "meta-harness" — desacopla o "cérebro" (o modelo e seu loop) das "mãos" (sandboxes e ferramentas) por meio de interfaces explícitas. Como o cérebro deixa de ficar dentro do contêiner de execução, os sandboxes podem ser provisionados sob demanda e as credenciais podem ser mantidas em um cofre que o sandbox nunca acessa. O ganho relatado é estrutural, não cosmético: o p50 do tempo até o primeiro token caiu cerca de 60%, e o p95, mais de 90%, porque as sessões não esperam mais por contêineres que talvez nunca usem.

Três documentos traçam essa evolução: Building Effective Agents (2024), a publicação sobre a infraestrutura do SWE-bench (2024) e Managed Agents (2026).

A OpenAI fez parceria com a equipe do SWE-bench para criar a divisão Verified validada por humanos, justamente porque as infraestruturas precisam de tarefas bem definidas: sua campanha de anotação (93 desenvolvedores, 1.699 amostras) constatou que 68,3% das tarefas do benchmark original eram problemáticas, e removê-las mais que dobrou o desempenho medido. A mesma publicação observa que apenas a escolha da infraestrutura elevou o GPT-4 de 2,7% para 28,3% no SWE-bench Lite — uma diferença que eles citam para defender que as avaliações devem considerar o progresso das infraestruturas criadas pela comunidade.

No campo do código aberto, o Codex CLI é distribuído como uma infraestrutura de referência completa. Sua arquitetura é organizada em camadas que refletem os demais sistemas desta seção: um loop central do agente cuida do planejamento e das chamadas de ferramentas; uma camada de sandbox isola a execução com políticas configuráveis por tarefa; uma camada de sessão preserva as conversas para que possam ser retomadas, bifurcadas ou compactadas; e uma camada de ferramentas oferece tanto acesso ao shell local quanto ferramentas externas baseadas em MCP. Em vez de fixar uma única interface, o mesmo mecanismo é disponibilizado em três superfícies — uma UI de terminal para trabalho interativo, um servidor de aplicativo JSON-RPC para clientes avançados como VS Code e um serviço remoto de execução de código para sandboxes na nuvem —, permitindo que a infraestrutura seja executada localmente ou controlada por programação. O design adota os mesmos compromissos recomendados pela literatura de pesquisa: loop mínimo, sandbox robusto, gerenciamento explícito de contexto e uma fronteira clara entre o modelo e o mundo externo.

Com o Kit de Desenvolvimento de Agents (ADK) e o protocolo Agent2Agent (A2A) — lançados em abril de 2025 com mais de 50 parceiros de tecnologia, incluindo Atlassian, Salesforce, SAP e ServiceNow —, o Google está transformando a camada de harness em produto. O A2A padroniza como os agentes anunciam capacidades (por meio de "Agent Cards" em JSON), gerenciam tarefas de longa duração, trocam artefatos e negociam formatos de interface, para que os harnesses se tornem uma infraestrutura interoperável, em vez de integrações personalizadas. Ele foi projetado explicitamente para complementar o Model Context Protocol (MCP) da Anthropic, que padroniza o lado das ferramentas do harness.

O AutoGen e o Magentic-One da Microsoft oferecem harnesses nos quais um agent orquestrador gerencia um registro de fatos e progresso — um projeto publicado para evitar os loops sem limite que afligem harnesses ingênuos. O GAIA, da Meta e do Hugging Face, criou um benchmark de assistentes gerais cujo harness avalia perguntas do mundo real que exigem navegação na web e manipulação de arquivos; o Open Agent Leaderboard do Hugging Face continua o esforço por classificações comparáveis e sensíveis ao harness.

O DeepSeek Harness (dsh) leva a ideia de meta-harness adiante e a torna componível. Sua arquitetura é baseada no framework Cordis, e sua principal proposta é que cada parte do harness é um plugin substituível — incluindo o adaptador de modelo, o registro de ferramentas, o log de sessão e o próprio loop do agent.

O design se baseia em três elementos primitivos. Primeiro, um log de sessão durável, que é a única fonte da verdade sobre o que o modelo viu; tudo que chega ao modelo precisa poder ser reconstruído a partir do log, exigência aplicada como um invariante de execução. Segundo, pontos de extensão de capacidades: uma interface de provedor intercambiável entre o agent e o mundo externo, de modo que direcionar os provedores de sistema de arquivos e subprocessos para um sandbox remoto também transfere o acesso ao Bash, ao terminal e ao servidor de linguagem, sem bifurcar o harness. Terceiro, um ciclo de vida explícito de turno/etapa, com eventos de extensão nomeados (agent/pre-step, tools/execute, agent/turn-stopping) que permitem aos plugins interceptar ou reescrever o loop sem modificar o código central.

O resultado é a implementação de código aberto mais próxima do meta-harness da Anthropic: um harness cuja estrutura não é um framework fixo, mas uma composição de plugins que podem ser trocados por configuração. Com mais de 170 mil estrelas no GitHub em seus primeiros meses, ele sinaliza que o harness de agentes está se tornando uma categoria de produto por si só.

O padrão compartilhado por todos eles: mantenha o loop simples, isole tudo em sandbox, registre cada etapa e nunca confie em uma pontuação sem conhecer o harness que a produziu.

Tudo nesta seção até agora — os loops mínimos, os logs de sessão duráveis, a execução em sandbox, as arquiteturas de plugins — parte de uma premissa: o ambiente do agent é um computador. Um terminal, um navegador, um sistema de arquivos, um repositório. O harness existe para que o agent possa operar essa máquina de forma confiável.

Mas a trajetória de pesquisa descrita acima aponta para outro lugar. O τ-bench colocou o usuário dentro do harness. O METR mostrou agents assumindo trabalhos que duram dias, não minutos. O OSWorld e o WebArena levaram o ambiente de um repositório limpo para o mundo real, com toda a sua desordem. A direção é consistente: à medida que os agents deixam de ser ferramentas de programação e se tornam verdadeiros assistentes de trabalho, o ambiente que precisam navegar deixa de ser apenas silício — são pessoas. Usuários com expectativas, equipes com histórico, organizações com permissões e conhecimento institucional.

Essa mudança atinge um subsistema do harness mais do que todos os outros: o gerenciamento de contexto. Uma sessão de terminal tem um operador e um histórico limitado; um engajamento longo tem dez partes interessadas, meses de decisões e um repositório que continua crescendo. Um sistema de arquivos é passivo; uma relação de trabalho é um fluxo de compromissos implícitos, pensamentos inacabados e escolhas feitas de passagem. Tudo isso precisa ser resumido, compactado ou descartado antes de chegar ao modelo, e cada uma dessas decisões é um ponto em que o agent perde algo de que a tarefa precisava.

Um harness pode compactar, mas não pode compactar arbitrariamente. Por isso, o tamanho da janela de contexto deixou de ser uma especificação do modelo e se tornou um parâmetro de design do harness.

O portfólio de harnesses da Moonshot AI mapeia a anatomia definida anteriormente neste artigo em uma única stack gerenciada. Para o problema Agent × Computador, seus harnesses ampliam o loop padrão: a Kimi Browser Extension controla uma sessão real de navegador pelo Chrome DevTools Protocol, em vez de um sandbox estéril; um ponto de extensão de Perguntar antes de agir garante o consentimento no nível do sistema de arquivos; e um Agent Swarm amplia a orquestração para 300 subagentes em tarefas de longo horizonte.

O que impulsiona esse loop é o Kimi K3.1 Pro — o primeiro modelo da série K3.1 e o modelo de pesos abertos da classe 3T mais capaz da Moonshot AI até hoje, com uma janela de contexto de 1.048.576 tokens. Três de suas propriedades têm relação direta com o design do harness:

• Uma janela grande o bastante para adiar a compactação. Um milhão de tokens comporta um repositório de trabalho, a trajetória em curso e os documentos de referência ao mesmo tempo. O harness ainda trunca o contexto — sempre precisa fazê-lo —, mas o ponto em que a sumarização começa a destruir informações é deslocado o suficiente para que tarefas de longo horizonte deixem de se degradar silenciosamente no meio do caminho.

• Esforço de raciocínio como ajuste do harness. O K3.1 Pro sempre raciocina, e reasoning_effort aceita low, high ou max, sendo max o padrão. Isso transforma o custo de raciocínio do modelo em um orçamento por tarefa definido pelo harness, em vez de um custo fixo de entrada.

• Ferramentas que chegam no meio do episódio. O carregamento dinâmico de ferramentas permite que o harness injete uma definição completa de ferramenta em uma mensagem de sistema, tornando-a disponível a partir dessa mensagem — sem reinicialização e sem pagar pelo seu esquema em cada turno de uma conversa que nunca a utiliza.

A Moonshot apresenta o harness junto com o modelo, disciplina que o restante deste artigo defende. No Terminal-Bench 4.0 — que avalia agentes de programação em tarefas realistas de terminal, com recursos restritos e testes rigorosos específicos para cada tarefa —, o K3.1 Pro alcança 65,7%, à frente do GPT-6 Astra (58,2%) e logo atrás do Claude Opus 5.5 (66,4%). No Kimi Code Bench 3.0 Long-horizon, um benchmark interno de execução em múltiplas etapas, uso de ferramentas e resolução de problemas de ponta a ponta, ele atinge 61,2%, contra 55,95% do K3. A documentação é igualmente explícita sobre o acoplamento no sentido inverso: parâmetros de amostragem como temperature e top_p são fixos e devem ser omitidos das solicitações, e a mensagem completa do assistente deve ser retornada sem alterações entre os turnos — um harness que reescreve a mensagem perde o raciocínio do qual depende a próxima chamada de ferramenta.

O mesmo modelo opera toda a superfície. Você pode experimentar a versão web gerenciada pelo Kimi Agent, executar o harness local completo com o Kimi Work, trabalhar no terminal com o Kimi Code ou chamar kimi-k3.1-pro diretamente pela Kimi API. Uma variante kimi-k3.1-pro-highspeed troca aproximadamente o dobro do preço por token por uma velocidade de saída duas a três vezes maior.

Quer esteja avaliando modelos ou lançando um produto, a mesma lista de verificação se aplica:

1. Comece pela tarefa, não pelo framework. Se seus agentes editam código, um harness de Bash com editor, como o ACI do SWE-agent, é uma opção comprovada. Se controlam interfaces gráficas ou a web ao vivo, você precisa de observações de sessões reais e ações no nível de cliques.

2. Torne os ambientes reproduzíveis. Imagens Docker, dependências fixadas e dados com seed são a diferença entre um benchmark e uma anedota.

3. Planeje deliberadamente o orçamento da janela de contexto. Truncamento de observações, sumarização de histórico e compactação são recursos do harness que afetam diretamente as pontuações e os custos — e explicam por que modelos de contexto longo reduzem o quanto o harness precisa descartar.

4. Imponha limites rígidos. Limites de etapas, tempos limite de execução e orçamentos em dólares por episódio mantêm os agentes seguros e as avaliações comparáveis.

5. Registre trajetórias completas desde o primeiro dia. Todo ciclo sério de melhoria — revisão humana, agrupamento de falhas, fine-tuning — consome dados de trajetória. O Managed Agents da Anthropic e o DeepSeek Harness vão além: mantêm o log de sessão fora do loop do harness como um fluxo de eventos somente para anexação, para que o próprio harness seja descartável e o contexto do modelo possa sempre ser reconstruído.

6. Avalie em mais de um harness. Se seu agent só funciona dentro de um harness, você construiu um comportamento específico de harness, não uma capacidade.

7. Mantenha as credenciais fora do sandbox — ou inteiramente fora da nuvem. Trate o ambiente de execução do agent como não confiável; mantenha os tokens em um cofre e injete-os por meio de um proxy, ou execute toda a sessão localmente para que as credenciais e o conteúdo das páginas nunca saiam do dispositivo — abordagem adotada pelo Kimi em seus harnesses locais.

O harness de agentes tornou-se discretamente a camada mais importante da stack agêntica. Pesquisas do SWE-bench, mini-SWE-agent, Terminal-Bench e METR mostram que o design do harness pode rivalizar com atualizações de modelo em impacto; projetos de código aberto como DeepSeek Harness, OpenHands, SWE-agent e Aider colocam harnesses de nível de produção ao alcance de todos; e Anthropic, OpenAI, Google, Microsoft e Moonshot AI agora tratam a engenharia de harness como trabalho de primeira classe.

Mas a mudança mais profunda é conceitual. A primeira geração de harnesses resolveu Agent × Computador: deu a um modelo mãos confiáveis para um terminal, um navegador e um sistema de arquivos. A próxima geração está resolvendo o problema de contexto que esses ambientes criam — trabalho que se estende por dias, partes interessadas e repositórios que nenhum sumarizador compacta sem perdas. O harness está evoluindo de estrutura de apoio para ambiente operacional, e a linha entre o que o harness precisa gerenciar e o que o modelo pode simplesmente reter continua se deslocando. A janela de um milhão de tokens do Kimi K3.1 Pro é o exemplo atual mais claro: uma mudança no modelo que elimina trabalho que o harness antes precisava fazer.

Se você cria o seu próprio, adota um framework de código aberto ou opera um harness de produção, as equipes que tratam o harness como software projetado, versionado e mensurável são as que fazem seus agentes realmente concluir o trabalho.