Agente de Produção no Claude sem LangChain e RAG: Arquitetura em 712 Linhas para um Estúdio de Design de Interiores

Um desenvolvedor independente publicou no Habr uma análise detalhada da arquitetura de um agente de produção em Claude, criado para um pequeno estúdio de design de interiores. Todo o sistema cabe em um único arquivo main.py com 712 linhas de código e dois prompts de sistema — sem LangChain, sem frameworks RAG e sem bancos de dados vetoriais.

Quais componentes compõem o agente

Os papéis de dois modelos Claude são claramente divididos por tipo de tarefa. A interface de chat roda em Claude Haiku 4.5: o modelo responde rapidamente às perguntas dos clientes, esclarece solicitações e mantém o diálogo. Claude Sonnet 4.6 fica responsável pela geração de conceitos de design: transforma os desejos do cliente em uma descrição estruturada de interiores. As fotos para visualização dos conceitos são obtidas da biblioteca Pexels — isso é significativamente mais barato e rápido do que gerar imagens através do DALL-E.

Parâmetros-chave da solução:

• Claude Haiku 4.5 — diálogo com cliente: rápido e econômico
• Claude Sonnet 4.6 — geração de conceitos de design estruturados
• Pexels API — seleção de fotos em vez de DALL-E
• Um arquivo main.py, 712 linhas de código, dois prompts de sistema
• Sem orquestradores, bancos de dados vetoriais ou frameworks acima da API

Essa escolha arquitetural não é acidental. Para um estúdio com orçamento limitado e pequeno fluxo de clientes, uma stack RAG em escala completa é engenharia excessiva. Haiku é mais barato no diálogo; Sonnet é acionado apenas onde é necessária geração criativa estruturada. Não há sentido em resolver um problema de escalabilidade que ainda não existe.

Que dificuldades foram encontradas?

O primeiro ponto não óbvio é o limite de cache de prompts no Claude Haiku 4.5. O cache de contexto só é ativado acima de 4096 tokens. Se o prompt de sistema for menor que esse limite, cada requisição é tratada como nova — o cache não funciona de forma alguma. Sob alta carga, isso impacta notavelmente tanto o custo das requisições quanto a latência de resposta.

A segunda sutileza é o comportamento do Sonnet 4.6 com saída estruturada. O modelo às vezes envolve a resposta JSON em um bloco de texto adicional em vez de retornar JSON limpo. O `json.loads()` padrão falha com um erro nesses casos. O autor testou várias estratégias de parsing e optou por um wrapper simples com lógica de fallback — é mais confiável do que extrair JSON com expressões regulares.

"Isso não é um guia de um especialista — mais como um diário de decisões.

Tentei explicar honestamente por que tomei cada decisão", explica o desenvolvedor.

A lógica de divisão de modelos merece atenção especial. O autor tentou processar tudo com um único modelo, mas rapidamente percebeu: Haiku deve ser usado onde velocidade e custo importam, e Sonnet onde você precisa de qualidade de saída estruturada. Tentar economizar executando a geração de conceitos através do Haiku produziu resultados notavelmente piores.

Onde essa abordagem começará a falhar?

O desenvolvedor delimita honestamente as fronteiras da sua solução. Um arquivo com 712 linhas funciona bem para um MVP e um pequeno estúdio, mas a escalabilidade criará problemas:

• Conforme a base de clientes cresce, será necessário armazenar o histórico de diálogos — sem um banco de dados vetorial ou armazenamento externo, é inevitável
• Se o estúdio quiser aceitar e analisar fotos dos clientes, será necessário um pipeline multimodal
• Registrar a atividade do agente em um arquivo não funciona com múltiplos usuários simultâneos e carga real
• À medida que os prompts crescem em complexidade, ficam mais difíceis de testar e versionar em um único arquivo

A conclusão principal do autor: para uma tarefa com fronteiras estreitas e claras, "sem RAG" não é uma solução preguiçosa, mas uma escolha arquitetural deliberada. Frameworks resolvem problemas reais de escalabilidade, mas criam novos: complexidade, dependências, overhead de infraestrutura. Se o problema ainda não surgiu, não o crie em nome de uma ferramenta.

O que isso significa

A publicação mostra: Claude API é suficiente para um agente de produção sem frameworks de suporte, se a tarefa for específica o bastante. Para desenvolvedores que começam a construir agentes em Claude, esta é uma análise honesta de dificuldades reais — o limite de cache do Haiku 4.5, parsing JSON do Sonnet 4.6, distribuição criteriosa de tarefas entre modelos de diferentes níveis.