Agente de Producción en Claude sin LangChain y RAG: Arquitectura de 712 Líneas para un Estudio de Diseño de Interiores

Un desarrollador independiente publicó en Habr un análisis detallado de la arquitectura de un agente de producción en Claude, creado para un pequeño estudio de diseño de interiores. Todo el sistema cabe en un único archivo main.py con 712 líneas de código y dos prompts de sistema — sin LangChain, sin frameworks RAG y sin bases de datos vectoriales.

¿De qué componentes consta el agente?

Los roles de dos modelos Claude se dividen claramente por tipo de tarea. La interfaz de chat funciona en Claude Haiku 4.5: el modelo responde rápidamente a las preguntas de los clientes, aclara solicitudes y mantiene el diálogo. Claude Sonnet 4.6 se encarga de la generación de conceptos de diseño: transforma los deseos del cliente en una descripción estructurada del interior. Las fotos para visualizar los conceptos se obtienen de la biblioteca Pexels — esto es significativamente más barato y rápido que generar imágenes a través de DALL-E.

Parámetros clave de la solución:

• Claude Haiku 4.5 — diálogo con el cliente: rápido y económico
• Claude Sonnet 4.6 — generación de conceptos de diseño estructurados
• Pexels API — selección de fotos en lugar de DALL-E
• Un archivo main.py, 712 líneas de código, dos prompts de sistema
• Sin orquestadores, bases de datos vectoriales ni frameworks encima de la API

Esta opción arquitectónica no es accidental. Para un estudio con presupuesto limitado y un pequeño flujo de clientes, una pila RAG completa es ingeniería excesiva. Haiku es más barato para el diálogo; Sonnet solo se activa donde se necesita generación creativa estructurada. No tiene sentido resolver un problema de escalabilidad que aún no existe.

¿Qué obstáculos se encontraron?

El primer punto no obvio es el umbral de caché de prompts en Claude Haiku 4.5. El caché de contexto solo se activa por encima de 4096 tokens. Si el prompt de sistema es más corto que este umbral, cada solicitud se trata como nueva — el caché no funciona en absoluto. Bajo carga alta, esto impacta notablemente tanto el costo de las solicitudes como la latencia de respuesta.

La segunda sutileza es el comportamiento de Sonnet 4.6 con salida estructurada. El modelo a veces envuelve la respuesta JSON en un bloque de texto adicional en lugar de devolver JSON limpio. El `json.loads()` estándar falla con un error en tales casos. El autor probó varias estrategias de análisis y optó por un contenedor simple con lógica de fallback — es más confiable que extraer JSON con expresiones regulares.

"Esto no es una guía de un experto — más bien un diario de decisiones.

Traté de explicar honestamente por qué tomé cada decisión", explica el desarrollador.

La lógica de división de modelos merece atención especial. El autor intentó procesar todo con un solo modelo, pero se dio cuenta rápidamente: Haiku debe usarse donde importan la velocidad y el costo, y Sonnet donde necesitas calidad de salida estructurada. Intentar ahorrar ejecutando la generación de conceptos a través de Haiku produjo resultados notablemente peores.

¿Dónde comenzará a fallar este enfoque?

El desarrollador delimita honestamente los límites de su solución. Un archivo de 712 líneas funciona bien para un MVP y un pequeño estudio, pero la escalabilidad creará problemas:

• A medida que crece la base de clientes, será necesario almacenar el historial de diálogos — sin una base de datos vectorial o almacenamiento externo, es inevitable
• Si el estudio quiere aceptar y analizar fotos de los clientes, será necesario un pipeline multimodal
• Registrar la actividad del agente en un archivo no funciona con múltiples usuarios concurrentes y carga real
• A medida que los prompts se vuelven más complejos, es más difícil probarlos y versionar en un único archivo

La conclusión principal del autor: para una tarea con límites estrechos y claros, "sin RAG" no es una solución perezosa sino una opción arquitectónica deliberada. Los frameworks resuelven problemas reales de escalabilidad pero crean otros nuevos: complejidad, dependencias, sobrecarga de infraestructura. Si el problema aún no ha surgido, no lo crees en nombre de una herramienta.

Qué significa esto

La publicación demuestra: Claude API es suficiente para un agente de producción sin frameworks de apoyo, si la tarea es lo suficientemente específica. Para los desarrolladores que comienzan a construir agentes en Claude, este es un análisis honesto de los obstáculos reales — el umbral de caché de Haiku 4.5, análisis JSON de Sonnet 4.6, distribución reflexiva de tareas entre modelos de diferentes niveles.