Hoje li um extenso artigo sobre Harness Engineering — dezenas de milhares de palavras, quase certamente escrito por IA. Minha primeira reação não foi "uau, que conceito poderoso." Foi "essas pessoas têm alguma ideia além de criar novos termos para velhos?" Sempre fiquei incomodado com esse padrão no mundo da IA — a constante reinvenção de conceitos existentes. Desde prompt engineering a context engineering, agora a harness engineering. A cada poucos meses alguém cria um novo termo, escreve um ensaio de 10.000 palavras, adiciona alguns estudos de caso de grandes empresas, e toda a comunidade começa a agitar. Mas se você realmente olhar para o conteúdo, é a mesma coisa toda vez: Desenhe o ambiente em que seu modelo opera — que informações ele recebe, que ferramentas pode usar, como os erros são interceptados, como a memória é gerida entre sessões. Isso existe desde o dia em que o ChatGPT foi lançado. Não se torna uma nova disciplina só porque alguém — por qualquer motivo — decidiu dar-lhe um novo nome. Dito isso, deixando as queixas de lado, a pesquisa e os estudos de caso citados no artigo têm valor — especialmente porque se sobrepõem fortemente ao que venho construindo com o how-to-sglang. Então, deixe-me usar isso como uma oportunidade para falar sobre os erros que realmente cometi. Um pouco de contexto primeiro. Os pedidos mais comuns na comunidade SGLang são Perguntas de Como — como implantar o DeepSeek-V3 em 8 GPUs, o que fazer quando o gateway não consegue alcançar o endereço do trabalhador, se a diferença entre GLM-5 INT4 e FP8 oficial é significativa. Essas perguntas abrangem uma superfície técnica extremamente ampla, e à medida que a comunidade cresce cada vez mais rápido, não conseguimos acompanhar as respostas. Então, comecei a construir um sistema multi-agente para respondê-las automaticamente. A primeira ideia foi, claro, a mais ingênua — construir um único Agente onisciente, colocar toda a documentação, código e livros de receitas do SGLang nele, e deixá-lo responder tudo. Isso não funcionou. Você não precisa de teoria de harness engineering para explicar por quê — a janela de contexto não é RAM. Quanto mais você coloca nela, mais a atenção do modelo se dispersa e piores as respostas ficam. Um Agente tentando entender simultaneamente quantização, desagregação PD, serviço de difusão e compatibilidade de hardware acaba não entendendo nenhum deles profundamente. O design que eventualmente adotamos é uma arquitetura de especialistas em subdomínios em múltiplas camadas. A documentação do SGLang já possui limites funcionais naturais — recursos avançados, plataformas, modelos suportados — com livros de receitas organizados por modelo. Transformamos cada subdomínio em um agente especialista independente, com um Gerente de Debates de Especialistas responsável por receber perguntas, decompor em sub-perguntas, consultar a Tabela de Roteamento de Especialistas para ativar os agentes certos, resolver em paralelo e, em seguida, sintetizar respostas. Olhando para trás, esse design se mapeia quase perfeitamente nos padrões que a comunidade de harness engineering defende. Mas quando eu estava construindo isso, não tinha ideia de que esses padrões tinham nomes. E eu não precisava. 1. Divulgação progressiva — não despejamos toda a documentação em nenhum agente único. Cada especialista de domínio carrega apenas seu próprio conhecimento de domínio, e o Gerente decide quem ativar com base no tipo de pergunta. Minha intuição é que esse design rendeu muito mais melhorias do que trocar por um modelo mais forte já fez. Você não precisa saber que isso se chama "divulgação progressiva" para tomar essa decisão. Você só precisa ter tentado a abordagem de "colocar tudo" uma vez e assistido ao seu fracasso. 2. Repositório como fonte da verdade — todo o fluxo de trabalho vive no repositório how-to-sglang. Todos os agentes especialistas extraem seu conhecimento de arquivos markdown dentro do repositório, sem dependência de documentos externos ou acordos verbais. No início, tivemos a vontade de escrever um enorme sglang-maintain.md cobrindo tudo. Aprendemos rapidamente que isso não funciona. A equipe Codex da OpenAI cometeu o mesmo erro — tentou um AGENTS.md único e superdimensionado e viu-o apodrecer de maneiras previsíveis. Você não precisa ter lido o blog deles para pisar nessa mina terrestre. É o clássico problema de engenharia de software de "documentação monolítica sempre fica desatualizada," exceto que em um contexto de agente as consequências são piores — documentação desatualizada não apenas não é lida, mas ativamente engana o agente. 3. Roteamento estruturado — a Tabela de Roteamento de Especialistas mapeia explicitamente tipos de perguntas para agentes. Uma pergunta sobre GLM-5 INT4 ativa simultaneamente o Especialista de Domínio de Livro de Receitas e o Especialista de Domínio de Quantização. O Gerente não adivinha; ele segue um índice estruturado. A turma de harness engineering chama isso de "restrições mecanizadas." Eu chamo de engenharia normal. Não estou dizendo que as ideias por trás da harness engineering são ruins. A pesquisa citada é sólida, o conceito ACI do SWE-agent é genuinamente valioso, e a arquitetura de agente duplo da Anthropic (agente inicializador + agente de codificação) é material de referência valioso para qualquer um que esteja realizando tarefas de longo prazo. O que eu acho cansativo é a constante criação de novos termos — empacotar o senso comum de engenharia estabelecido como uma nova disciplina, e depois fabricar ansiedade em torno de "você está atrasado se não souber essa palavra." Prompt engineering, context engineering, harness engineering — são diferentes facetas da mesma coisa. No próximo mês, alguém provavelmente criará scaffold engineering ou orchestration engineering, escreverá outro extenso ensaio citando o mesmo artigo do SWE-agent, e a comunidade começará outro ciclo de amplificação. O que realmente aprendi com o how-to-sglang pode ser declarado sem nenhum novo vocabulário:...