Introdução

No desenvolvimento assistido por IA moderno, o modelo raramente é o produto inteiro. O harness é tudo ao redor dele: prompts, seleção de contexto, wiring de ferramentas, delegação a subagentes, limites de segurança e o loop que mantém o trabalho avançando até a tarefa terminar. O time do Cursor descreve o harness como um problema de engenharia de anos — e aposta que orquestração, não tamanho bruto do modelo, separa demo de ferramenta de uso diário.

Desenvolvimento

As quatro perguntas de cada turno

Em alto nível, o harness responde quatro perguntas a cada turno:

Gestão de contexto inclui indexação do codebase, busca semântica, grep, edições recentes e docs — curados para o modelo receber sinal, não o repositório inteiro. Acesso a ferramentas cobre terminal, linters, servidores MCP, automação de browser e APIs internas. Subagentes deixam o agente principal spawnar especialistas — planejamento, edições rápidas, debug — cada um com prompt e modelo próprios.

Por que dois produtos com o mesmo modelo parecem diferentes

Um pode alucinar caminhos de arquivo; outro encontra o módulo certo porque indexação e retrieval foram engenheirados no harness. Um roda chat longo único; outro paraleliza review e implementação via subagentes com janelas de contexto separadas. O harness é a diferença entre “chat com código colado” e “agente que opera dentro do projeto”.

Configuração prática no Cursor

O Cursor productizou essa camada via app desktop, CLI, cloud agents e Cursor SDK. Estrutura típica no repositório:

.cursor/
├── skills/           # skills descobertas automaticamente
├── hooks.json        # hooks de ciclo de vida
└── rules/            # regras do projeto (alternativa a .cursorrules)

Exemplo de .cursor/hooks.json:

{
  "version": 1,
  "hooks": {
    "beforeShellExecution": [
      {
        "command": "./scripts/validate-shell.sh"
      }
    ]
  }
}

Skills em .cursor/skills/ formalizam loops de engenharia — spec, implementar, revisar, corrigir:

.cursor/skills/harness-ship/
└── SKILL.md

Harness orchestrator

O harness também explica a ascensão de fluxos contract-driven como padrões Harness orchestrator (/harness-plan, /harness-build, /harness-ship). Essas skills formalizam loop de engenharia — spec, implementar, revisar, corrigir, commit, push — sobre o harness da IDE. Em vez de esperar que prompt único gere código pronto para produção, o system impõe quality gates, review adversarial e trilhas de auditoria.

SDK e CI

Agentes lançados programaticamente herdam o mesmo runtime: configuração MCP, skills, hooks e subagentes. Desenvolvimento interativo fica no editor; modos headless podem dirigir o mesmo pipeline a partir do CI quando necessário.

# Exemplo conceitual — agente headless no CI
cursor agent run --prompt "Execute harness-ship para PR #42"

Harness vs modelo vs plataforma

Use o melhor modelo que couber no orçamento, mas invista no ambiente que o controla. OpenClaw entrega Gateway e slots de plugin. Hermes entrega loop de aprendizado e skills auto-geradas. Claude Code entrega agente nativo de terminal. O harness conecta modelos a repositórios reais com comportamento repetível.

Conclusão

Se você está construindo hoje, documente explicitamente premissas do harness:

• Ferramentas permitidas
• Passos de review obrigatórios
• Regras de memória e retenção
• Caminhos de escalonamento quando o agente travar

Times que extraem valor consistente não correm atrás de todo modelo novo no dia um; apertam o loop em torno do que já têm. Esse é o mindset do harness — menos mágica, mais engenharia.

Leitura relacionada: OpenClaw para plataforma multi-canal, Hermes Agent para agente self-hosted com skills, Claude Code para execução no terminal.