Back to Blog
Jorge

Crónica de un Bot: Superando el 'Dependency Hell' y los Entornos Blindados

Crónica de un Bot: Superando el "Dependency Hell" y los Entornos Blindados

Construir un sistema de automatización moderno parece sencillo sobre el papel: conectas una IA, una base de datos y una API de mercado. Sin embargo, en nuestra última sesión de desarrollo integrando OpenClaw, Groq y Notion en una instancia de Google Cloud, nos recordamos que el código es solo el 50% del trabajo; el otro 50% es navegar por la infraestructura y las políticas de seguridad que cambian constantemente.

Aquí les comparto los aprendizajes clave de una jornada intensa de "debugging" y arquitectura.

1. El fin del "Pip Install" Global: Entendiendo PEP 668

Uno de los primeros obstáculos fue el error externally-managed-environment. Las distribuciones modernas de Linux (Debian/Ubuntu) han implementado el PEP 668, que impide instalar librerías de Python directamente en el sistema para evitar romper herramientas críticas del SO.

El aprendizaje: Ya no es opcional; los Entornos Virtuales (venv) son el estándar sagrado. Crear una "burbuja" aislada para nuestro proyecto no solo evitó errores, sino que nos dio un control total sobre las versiones sin comprometer la estabilidad de nuestra instancia en GCP.

2. SDK vs. REST: Cuando la librería falla, vuelve a las bases

Intentamos instalar una librería especializada para conectar con el Order Book de Polymarket. Entre nombres de paquetes confusos en PyPI y problemas de compatibilidad con versiones de Python 3.12, nos encontramos en el famoso "Dependency Hell".

La decisión técnica: En lugar de perder horas compilando dependencias pesadas, pivotamos hacia una integración directa mediante la API REST usando la librería requests.

  • Aprendizaje: Un SDK es una comodidad, pero el acceso directo vía REST es universal, más ligero y nos quita la carga de mantener librerías de terceros que pueden quedar obsoletas. A veces, "menos es más" en la arquitectura de un bot.

3. Interfaces en Movimiento: El reto de las Plataformas (Notion)

Las plataformas SaaS como Notion evolucionan sus portales de desarrolladores más rápido que su documentación. Nos enfrentamos a la confusión entre Integraciones Públicas e Internas.

Mientras que la integración pública pide políticas de privacidad, términos de uso y URIs de redireccionamiento (OAuth), para herramientas de uso propio lo eficiente es la Integración Interna.

  • Aprendizaje: Antes de llenar formularios burocráticos, revisa los "Capabilities" y los "Secrets". Una integración interna nos dio el token necesario (secret_...) y acceso directo a la base de datos sin necesidad de un servidor web intermedio.

4. Arquitectura de Delegación: Supervisor vs. Especialista

Originalmente, queríamos que OpenClaw (nuestro agente de IA principal) hiciera todo: monitorear mercados, analizar finanzas y auditar infraestructura. Nos dimos cuenta de que esto era ineficiente y costoso en términos de tokens.

La solución: Implementamos un modelo de Delegación.

  • Creamos un Especialista Financiero en Python puro que vive en GCP.
  • Este especialista usa la LPU de Groq (increíblemente rápida y gratuita) para el procesamiento constante.
  • OpenClaw quedó como el Supervisor que solo despierta una vez al día para auditar los logs en Notion.
  • Aprendizaje: Separa la lógica de "fuerza bruta" y monitoreo constante de la lógica de "razonamiento superior". Tu presupuesto y la latencia de tu sistema te lo agradecerán.

5. Seguridad Invisible con Tailscale

Para que nuestro supervisor y nuestro especialista se hablaran de forma segura sin exponer puertos al internet público, la clave fue Tailscale.

  • Aprendizaje: Las redes privadas virtuales (VPN) de malla simplifican la conectividad entre nubes (AWS y GCP) permitiendo que los agentes se comuniquen por IPs privadas. La seguridad no tiene por qué ser compleja si usas las herramientas de red adecuadas.

Conclusión

La programación moderna es, en gran medida, gestión de ecosistemas. Hoy aprendimos que cuando una puerta se cierra (un error de instalación), siempre hay una ventana abierta (una API REST). La clave es mantener la arquitectura limpia, las responsabilidades delegadas y, sobre todo, no tener miedo de volver a lo básico cuando la tecnología de punta se vuelve caprichosa.