Rumo a um harness que possa fazer qualquer coisa
Desenvolvedores estão debatendo a melhor forma de “harness” modelos de linguagem grandes: seja por frameworks genéricos, no estilo Unix e centrados em arquivos, como o sistema Ambiance proposto, seja por orquestradores estritamente delimitados e específicos de domínio que envolvem ferramentas e testes ao redor de um LLM. Um tema recorrente é deslocar o máximo de trabalho possível para código e scripts determinísticos — usando LLMs apenas para decisões e casos de borda — enquanto se lidam com questões práticas como custos de tokens, confiabilidade, auditabilidade e restrições de plataforma. Muitos veem os fluxos de trabalho de IA do futuro como ferramentas Unix componíveis ou serviços em nível de sistema operacional, com LLMs levemente embutidos em vez de atuarem como agentes autônomos e livres.
O que é um “harness” e por que as pessoas se importam
- Um harness é descrito como a cola entre um LLM e ferramentas: ele analisa chamadas de ferramentas, executa comandos (FS, rede, etc.) e devolve os resultados.
- Alguns o veem como um “exoesqueleto agêntico” ou uma estrutura determinística ao redor de um modelo que, de outra forma, é difuso.
- Outros zombam da terminologia por parecer cheia de buzzwords, mas aceitam a necessidade subjacente: restringir e estruturar o comportamento do LLM.
Fluxos de trabalho determinísticos vs agentes “puros”
- Há uma forte corrente a favor do determinismo: usar código e scripts reais para fluxos de trabalho repetíveis; invocar LLMs apenas para julgamento/casos de borda.
- Padrões mencionados: árvores de decisão em que a maioria das folhas é “executar script”, e algumas poucas são “perguntar ao LLM”; código+testes como o esqueleto, LLM como ajudante ocasional.
- As pessoas descrevem encapsular ferramentas como Claude Code/Codex em loops determinísticos externos (testes, git, verificações de segurança, hooks de pre-commit).
- Alguns frameworks (langgraph, ACP, etc.) são citados como bons para orquestrar esses loops, embora alguns não gostem de sistemas que fazem a “construção de agentes” parecer ritualizada.
Filosofia Unix, “tudo é um arquivo” e alternativas
- Muitos gostam de mapear conceitos de agentes para primitivos Unix: fluxos de trabalho orientados a eventos, FS como estado compartilhado, FUSE, “agente como usuário Linux” com permissões e e-mail.
- Outros rejeitam “tudo é um arquivo” para LLMs, argumentando que, para modelos, “tudo são tokens/embeddings” e bancos vetoriais ou JSON tipado são mais naturais.
- Arquivos são vistos por alguns como um mínimo pragmático local: bons tanto para humanos quanto para modelos; outros chamam a FHS de datada e sugerem ideias no estilo Nix/Plan 9.
Harnesses genéricos vs específicos de domínio
- Vários argumentam que harnesses específicos de domínio (por exemplo, para engenharia de software) já superam os genéricos: ADRs embutidos, planejamento, testes comportamentais, validação rigorosa.
- Rodar LLMs “puros” é comparado a dirigir sem freios; outros relatam ter abandonado harnesses complexos e voltado a CLIs mais simples porque a complexidade extra não ajudava.
Custos, tokens e praticidade
- Há preocupação com os custos de tokens para monitoramento do FS ou polling frequente; sugerem acionar apenas em limiares significativos de arquivos.
- Alguns enfatizam testes, logging e scripts mínimos, sem exagero de engenharia; a generalização excessiva é vista como uma armadilha de manutenção.
Recepção do Ambiance e da afirmação de “fazer qualquer coisa”
- Positivo: modelo mental nativo de Unix, abordagem leve e auditável, um bom núcleo para construir variações em cima.
- Críticas: ideias “moles”, pouco claras sobre ganhos concretos em relação a sandboxes existentes; suporte apenas para macOS irrita alguns; o branding de “pode fazer qualquer coisa” é visto como exagerado.