OpenClaw + Claude Code/Codex: Creando un enjambre de agentes de desarrollo personal

Hola a todos, soy Lu Gong.

Recientemente vi un tweet en X que me llamó la atención de inmediato. Un desarrollador independiente llamado Elvis dijo que ya no usa directamente Claude Code y Codex, sino que utiliza OpenClaw como capa de orquestación, permitiendo que una IA llamada Zoe gestione todo un enjambre de agentes de Claude Code y Codex.

Los datos de este tweet también son impresionantes: 4.9 millones de vistas, 11,000 me gusta, 1,800 retweets.

Hemos estado escribiendo sobre Vibe Coding durante más de cuatro meses, y Claude Code ha sido nuestra herramienta principal. También he escrito algunos artículos sobre colaboración de múltiples agentes, arquitecturas de múltiples agentes en VSCode, entre otros.

Pero al ver el enfoque de Elvis, solo puedo llamarlo un experto. Una persona, utilizando un sistema de orquestación, con un promedio de 50 envíos de código al día, y en el mejor día envió 94 veces, además de recibir 3 llamadas de clientes, sin abrir el editor ni una vez.

¿No es esto como si una sola persona fuera un equipo de desarrollo completo?

Hoy, este artículo desglosará cómo lo logró.

OpenClaw no es desconocido para todos

Este pequeño cangrejo de río ha estado en auge desde antes del Año Nuevo. En pocas palabras, es un marco de agentes de IA de código abierto, que actualmente tiene más de 240,000 estrellas en GitHub, y hace unos días superó oficialmente a React, convirtiéndose en el proyecto de código abierto con el crecimiento más rápido de estrellas en la historia de GitHub.

El fundador Peter Steinberger es un desarrollador austriaco que anteriormente fundó PSPDFKit (una empresa B2B de marco PDF), y en 2021 recibió una inversión de 100 millones de euros de Insight Partners. En febrero de este año, Peter anunció que se unía a OpenAI y que el proyecto OpenClaw sería gestionado por una fundación de código abierto.

La posición de OpenClaw no es la de un chatbot, sino un tiempo de ejecución de agente de IA que corre en tu dispositivo local. Tiene cuatro componentes centrales: Gateway (puerta de enlace, conecta más de 50 plataformas de mensajería), Agent (motor de inferencia), Skills (más de 5,400 plugins), Memory (sistema de memoria).

Sin embargo, la forma en que Elvis utiliza OpenClaw es bastante especial. Él lo utiliza como una capa de orquestación, específicamente para gestionar agentes de codificación como Claude Code y Codex, sin usarlo como asistente general.

Este enfoque es realmente inusual.

¿Por qué se necesita una capa de orquestación?

Elvis mencionó en su tweet un punto clave: la ventana de contexto es un juego de suma cero.

Si llenas el espacio con código, no hay espacio para el contexto del negocio. Si llenas el espacio con el historial de clientes y actas de reuniones, no hay espacio para el repositorio de código. Por muy potente que sea un solo AI, no puede contener simultáneamente estos dos tipos de información completamente diferentes.

Por eso, él dividió el sistema en dos capas.

La capa superior es el orquestador de OpenClaw, Zoe, quien tiene todo el contexto del negocio, incluyendo datos de clientes, actas de reuniones, decisiones históricas, qué soluciones se han probado, cuáles han fallado. Esta información se almacena en la biblioteca de notas Obsidian de Elvis, y Zoe puede leerla directamente.

La capa inferior son los agentes de codificación como Claude Code y Codex, que solo ven código y se encargan de escribir código. Cada vez que se inicia un agente, Zoe le escribe un prompt preciso basado en el contexto del negocio, indicándole qué hacer, cuál es el contexto y qué es lo que el cliente necesita.

En resumen: el orquestador se encarga de entender los requisitos, y los agentes de codificación se encargan de trabajar. Cada uno hace lo que mejor sabe hacer.

Esta arquitectura es similar al sistema interno Minions que Stripe reveló hace poco. Los Minions de Stripe también son un diseño de agentes de codificación paralelos con una capa de orquestación centralizada, capaces de fusionar más de 1,000 PR completamente escritos por IA cada semana. Elvis dice que accidentalmente construyó una arquitectura similar, solo que corre en su Mac mini.

Flujo de trabajo de un caso real

Elvis utilizó un caso real en su tweet para explicar su flujo de trabajo completo, y yo resumiré los pasos clave.Él recibió una llamada de un cliente que quería reutilizar configuraciones existentes dentro del equipo. Al finalizar la llamada, habló con Zoe sobre esta necesidad. Dado que todas las actas de las reuniones se sincronizan automáticamente con Obsidian, Zoe ya sabía lo que el cliente había mencionado, por lo que Elvis no necesitaba explicaciones adicionales. Juntos definieron el alcance de la funcionalidad, y la solución final fue crear un sistema de plantillas.

Luego, Zoe realizó automáticamente tres acciones: recargó el servicio de desbloqueo para el cliente (ella tiene permisos de API de administrador), extrajo la configuración existente del cliente de la base de datos de producción (con permisos de solo lectura, el agente de codificación nunca tendrá este permiso), y luego generó un Codex Agent, con un prompt detallado que incluye el contexto completo del negocio.

Cada agente tiene su propio worktree (rama aislada) y sesión de tmux. El comando de inicio es algo así:

# Crear worktree + iniciar agente git worktree add ../feat-custom-templates -b feat/custom-templates origin/main cd ../feat-custom-templates && pnpm install tmux new-session -d -s "codex-templates" \ -c "/Users/elvis/Documents/GitHub/medialyst-worktrees/feat-custom-templates" \ "$HOME/.codex-agent/run-agent.sh templates gpt-5.3-codex high Después de que el agente se inicia, hay una tarea programada que verifica cada 10 minutos. Pero no preguntará directamente al agente (eso consumiría demasiados tokens), sino que ejecuta un script de Shell determinista para verificar si la sesión de tmux sigue activa, si se ha creado un PR y si CI ha pasado.

Si CI falla, reinicia automáticamente el agente, con un máximo de 3 intentos. Solo se envían notificaciones cuando se requiere intervención manual.

Después de completar la tarea, el agente creará automáticamente un PR. Pero solo crear un PR no es suficiente; Elvis definió un conjunto de criterios de finalización: creación de PR, sincronización de la rama con main (sin conflictos de fusión), CI aprobado en su totalidad, revisión de código de los tres modelos de IA aprobada, y si hay cambios en la UI, también debe incluir capturas de pantalla.

Tres modelos de IA realizan la revisión de código

La revisión de código por parte de los tres modelos de IA parece muy sólida. Hablando sobre su evaluación de estos tres modelos, es bastante interesante.

Codex Reviewer, él lo evaluó como el mejor, diciendo que su revisión en casos límite y errores lógicos es muy exhaustiva, con una baja tasa de falsos positivos.

Gemini Code Assist Reviewer, que es gratuito, lo considera muy útil, capaz de detectar vulnerabilidades de seguridad y problemas de escalabilidad que otros modelos pasan por alto, además de proporcionar soluciones específicas para corregirlos.

Claude Code Reviewer, su comentario fue "prácticamente inútil", mencionando que es excesivamente cauteloso, llenando la pantalla con sugerencias como "considera agregar...", la mayoría de las cuales son sobre-diseño. A menos que se marque como un problema crítico, él simplemente lo salta.

Me sorprendió un poco al leer esto. Como usuario frecuente de Claude Code, también he encontrado que es demasiado conservador en la revisión de código, pero calificarlo como "prácticamente inútil" parece un poco extremo. Sin embargo, esto también indica que la revisión cruzada entre múltiples modelos tiene un valor real, ya que los sesgos de diferentes modelos se complementan entre sí.

Solo después de que las tres revisiones sean aprobadas, Elvis recibirá una notificación por Telegram. En este punto, él principalmente revisa las capturas de pantalla para confirmar si los cambios en la UI son correctos; muchos PR los fusiona directamente sin mirar el código. Él dice que su revisión manual solo toma de 5 a 10 minutos.

La proactividad de Zoe

Zoe no es solo una ejecutora. Más interesante que el flujo de trabajo en sí es la proactividad de Zoe.

Elvis dice que Zoe no espera a que se le asignen tareas, sino que busca activamente trabajo. Por la mañana, escanea los registros de errores de Sentry, encuentra 4 nuevos errores y genera automáticamente 4 agentes para corregirlos. Después de la reunión, escanea las actas y marca 3 necesidades funcionales mencionadas por el cliente, luego inicia automáticamente 3 Codex Agents. Por la noche, escanea los registros de Git y activa a Claude Code para actualizar el changelog y la documentación del cliente.

Cuando Elvis sale a dar un paseo y regresa, encuentra un mensaje en Telegram: 7 PR listos, 3 nuevas funcionalidades, 4 correcciones de errores. ¿No es esto exactamente el efecto de un equipo de desarrollo de una sola persona que siempre he querido crear?Además, cuando el Agent falla, la forma en que Zoe maneja la situación es mucho más avanzada que simplemente reintentar. Ella combina el análisis del contexto del negocio para entender la razón del fallo. ¿El contexto del Agent se ha saturado? Ella reducirá el alcance, haciendo que el Agent se concentre solo en tres archivos. ¿El Agent se ha desviado? También corregirá, informando al Agent que el cliente quiere X y no Y, y adjuntará las palabras exactas de la reunión.

Con el tiempo, Zoe también acumulará experiencia, recordando qué estructuras de prompt funcionan mejor para qué tipo de tareas, y la próxima vez generará un prompt más preciso.

Esta idea es en realidad una versión mejorada del Ralph Loop. La lógica central de Ralph Loop es un ciclo de extraer contexto, generar salida, evaluar resultados y guardar experiencia, pero la mayoría de las implementaciones utilizan un prompt fijo para cada ciclo. El sistema de Elvis es diferente; cada vez que reintenta, Zoe ajusta dinámicamente el prompt según la razón del fallo, y además cuenta con un contexto de negocio completo.

Costos y hardware

En términos de costos, los datos públicos de Elvis indican que Claude cuesta aproximadamente 100 dólares al mes, y Codex alrededor de 90 dólares al mes. También mencionó que se puede comenzar a probar con 20 dólares.

Este costo es, por supuesto, ridículamente barato en comparación con contratar a un desarrollador. Pero si consideras que también necesitas tomar decisiones sobre el producto, comunicarte con los clientes y revisar el código, se parece más a un amplificador de eficiencia, ayudándote a ahorrar en las etapas más repetitivas de codificación y pruebas.

En cuanto al hardware, Elvis mencionó que su mayor cuello de botella actualmente es la RAM. Cada Agent necesita un worktree independiente, cada worktree tiene sus propios node_modules, y cada Agent debe ejecutar construcción, verificación de tipos y pruebas. Ejecutar 5 Agents simultáneamente significa 5 compiladores de TypeScript en paralelo, 5 ejecutores de pruebas y 5 conjuntos de dependencias.

Su Mac mini con 16GB de RAM puede ejecutar un máximo de 4 a 5 Agents al mismo tiempo; más que eso comenzará a intercambiar memoria. Por eso compró un Mac Studio M4 Max con 128GB de RAM (3500 dólares), con la intención de manejar más concurrencia de Agents.

Resumen y problemas reales

Honestamente, el sistema de Elvis me ha impactado bastante. Antes, siempre había considerado OpenClaw como un juguete, y para aumentar la productividad, dependía de Claude Code independiente. Ocasionalmente usaba worktree para paralelizar, pero no estaba ni cerca de este nivel de orquestación sistemática. Después de leer sus tweets, siento que el techo de la programación AI ha sido elevado nuevamente.

Recientemente, estoy siguiendo su enfoque y planeo usar OpenClaw para crear un equipo de desarrollo completamente automatizado de una sola persona. Así que, en el futuro, publicaremos varios artículos prácticos sobre OpenClaw.

Hay algunos problemas reales que debo mencionar.

El pre-requisito para este sistema es que debes tener un producto claro, necesidades de cliente definidas y una línea de CI/CD bien establecida. Elvis está trabajando en un producto SaaS B2B real, con clientes, ingresos y un entorno de producción. Si aún estás en la fase de escribir demos o aprendiendo, el ROI de esta arquitectura puede no ser muy rentable.

Además, también hay que tener en cuenta los problemas de seguridad actuales de OpenClaw. Según información pública, ya se han revelado múltiples CVE de alto riesgo, y se han encontrado 341 plugins comunitarios maliciosos que realizan actividades de robo de datos. Al desplegar OpenClaw, es crucial hacer un buen trabajo en la aislación y el control de permisos. Esta es también la razón por la que aún no he desplegado OpenClaw en mi máquina principal local.

Por último, Elvis ha dado una evaluación baja sobre la revisión de código de Claude Code en sus tweets, pero recientemente Claude Code lanzó la función de Agent Teams (colaboración de múltiples Agents integrada oficialmente), y Anthropic también está trabajando en la orquestación en esta dirección.

Sin embargo, dejando de lado estos detalles, la arquitectura de Elvis que combina la capa de orquestación con la capa de ejecución realmente merece atención. La competencia de suma cero en la ventana de contexto es una restricción real, y usar una arquitectura en capas para resolver este problema, permitiendo que diferentes AI cumplan con sus roles, es un enfoque que personalmente considero correcto.

Para aquellos interesados en este tema, pueden ir directamente a ver el tweet original de Elvis, la densidad de información es muy alta:...