Un bucle de codificación con dos agentes sin cabeza utilizando OpenCode y Ollama
Cómo dividir la planificación y la revisión entre dos agentes en OpenCode con Ollama, con permisos, habilidades, reglas de redacción, capturas de pantalla y commits exclusivos para humanos.
Fuentes: Ollama on Steroids with OpenCode: A Headless Multi Agent Coding Workflow
La mayoría de las demostraciones de programación con IA impresionan hasta el momento en que alguien plantea una pregunta técnica aburrida: ¿qué sucedió exactamente, quién lo revisó, qué pruebas se ejecutaron y se puede reproducir todo esto mañana?
El flujo de trabajo que se describe a continuación intenta responder a eso. En lugar de una ventana de chat que de vez en cuando genera un parche decente, trata la programación con IA como un pequeño ciclo de ingeniería:
- un agente planifica e implementa
- un segundo agente revisa y da su aprobación
- cada solicitud recibe su propia carpeta de sesión local
- cada ejecución deja un rastro de registros y pruebas de que se realizaron pruebas
- un humano, nunca un agente, decide cuándo se compromete o envía el código
- las solicitudes privadas y los resultados de las sesiones permanecen privados
La división del trabajo: MiniMax elabora planes y escribe código, GLM revisa y aprueba, OpenCode gestiona el flujo de trabajo y Ollama dirige las solicitudes a los modelos. Lo que se obtiene no es una autonomía mágica, sino un ciclo repetible que genera planes, revisiones, pruebas, capturas de pantalla, verificaciones de seguridad y commits controlados por una persona.
En cuanto a las herramientas, OpenCode ofrece una opción no interactiva opencode run, agentes nombrados, selección de modelos, una bandera --dir y la posibilidad de asociar una ejecución a una instancia sin interfaz de opencode serve. Las sesiones pueden exportarse con --sanitize. Ollama documenta la integración con OpenCode mediante ollama launch opencode, y OpenCode lee la configuración a nivel de proyecto, los agentes, los permisos, las habilidades y los servidores MCP.
La configuración de ejemplo denomina a sus modelos Ollama Cloud minimax-m3:cloud y glm-5.1:cloud; MiniMax está destinado al desarrollo de código y a tareas de agencia, mientras que GLM se describe como la opción principal para la ingeniería de agencia. El patrón en sí no depende de esos modelos específicos. Considere los nombres de los modelos como ejemplos y consulte el catálogo actual de Ollama antes de copiarlos. Aquí no se comparten los prompts en bruto, los resultados de las sesiones, las rutas locales, las claves ni las capturas de pantalla del proyecto original, solo el método.
Deje de tratar la programación con IA como una sola conversación
Un agente de programación solitario comparte una debilidad con un desarrollador individual bajo presión: puede convencerse a sí mismo de que ya ha terminado. Pedirle lo mismo al modelo no soluciona eso. Un proceso sí lo hace:
Prompt -> Plan -> Review -> Implement -> Test -> Review -> Fix -> Signoff -> Human commit
El diseño se ve así:
control-workspace/
AGENTS.md
opencode.json
.opencode/
agents/
minimax-builder.md
glm-reviewer.md
skills/
opencode-ollama-agent-guardrails/
SKILL.md
agent-sessions/
project-slug/
promptNN/
PROMPTNN_CODER.md
PROMPTNN_REVIEWER.md
PROMPTNN_PLAN.md
PROMPTNN_PLAN_REVIEW.md
PROMPTNN_IMPLEMENTATION.md
PROMPTNN_TEST_RESULTS.md
PROMPTNN_IMPLEMENTATION_REVIEW.md
PROMPTNN_SIGNOFF.md
redacted logs
screenshot references
product-repo/
¿Por qué comenzar desde un espacio de trabajo de control padre? Solo dentro del repositorio del producto, el agente podría no poder ver los archivos de instrucciones, los archivos de sesión, las reglas compartidas ni el flujo de trabajo completo. Por su parte, las rutas absolutas pueden incluir detalles específicos de la máquina en los registros. De ahí la regla: ejecute OpenCode desde el control padre, utilice rutas relativas, mantenga las ediciones del producto en el repositorio del producto y guarde la salida de la sesión fuera de él. Suena aburrido, y precisamente por eso funciona.
Dos agentes con funciones separadas
La elección de diseño clave no es el modelo exacto, sino la separación de funciones.
El creador
minimax-builder puede planificar, editar código, ejecutar comandos y redactar notas de implementación. Sus responsabilidades son leer la instrucción y AGENTS.md, elaborar un plan, aplicar los comentarios del revisor, implementar únicamente el alcance aprobado, ejecutar pruebas de validación, registrar qué cambios se realizaron y qué falló, y detenerse a la espera de la aprobación humana para cualquier commit. Está prohibido: hacer commits, subir cambios, rebasar referencias, forzar subidas, pasar a la siguiente instrucción, suavizar pruebas y editar archivos reservados para el revisor.
El revisor
glm-reviewer está diseñado para ser estricto. Su lista de verificación incluye: ¿el plan se ajusta a la instrucción?, ¿la implementación se mantuvo dentro del alcance?, ¿las pruebas son significativas?, ¿los archivos generados se modificaron intencionadamente?, ¿las capturas de pantalla del navegador respaldan las afirmaciones?, ¿el manejo de información confidencial es adecuado?, ¿y el generador está exagerando sus resultados?
Su vocabulario de decisiones se mantiene muy reducido:
APPROVED
CHANGES_REQUESTED
SIGNED_OFF
NOT_SIGNED_OFF
Un vocabulario limitado deja poco margen para maniobrar. “Se ve bien en general” no constituye una aprobación final.
La configuración de OpenCode
Así es la estructura de la configuración:
{
"$schema": "https://opencode.ai/config.json",
"model": "ollama/minimax-m3:cloud",
"default_agent": "minimax-builder",
"share": "disabled",
"instructions": ["AGENTS.md"],
"enabled_providers": ["ollama"],
"permission": {
"read": {
"*": "allow",
"*.env": "deny",
"*.env.*": "deny",
"*.env.example": "allow"
},
"glob": "allow",
"grep": "allow",
"webfetch": "ask",
"websearch": "ask",
"external_directory": "deny",
"skill": {
"*": "allow"
}
},
"agent": {
"minimax-builder": {
"description": "Main planning and implementation agent.",
"mode": "primary",
"model": "ollama/minimax-m3:cloud",
"temperature": 0.2,
"permission": {
"edit": {
"*": "deny",
"product-repo/**": "allow",
"agent-sessions/project-slug/**": "allow"
},
"bash": {
"*": "ask",
"cd product-repo && *": "ask",
"git status *": "allow",
"git diff *": "allow",
"git log *": "allow",
"git commit *": "deny",
"git push *": "deny",
"git rebase *": "deny",
"rm *": "deny"
}
}
},
"glm-reviewer": {
"description": "Strict reviewer. Must not edit product code.",
"mode": "primary",
"model": "ollama/glm-5.1:cloud",
"temperature": 0.1,
"permission": {
"edit": {
"*": "deny",
"agent-sessions/project-slug/**": "allow"
},
"bash": {
"*": "ask",
"git status *": "allow",
"git diff *": "allow",
"git log *": "allow",
"grep *": "allow",
"rg *": "allow",
"git commit *": "deny",
"git push *": "deny",
"git rebase *": "deny",
"rm *": "deny"
},
"task": "deny"
}
}
}
}
Dos detalles merecen atención. El compartir está deshabilitado por defecto, y dado que OpenCode cuenta con una opción share, establecerla en "disabled" bloquea una vía para evitar fugas accidentales. El revisor también carece de amplios derechos de edición: puede escribir archivos de revisión y aprobación en la carpeta de sesión, pero no debería modificar el código en producción. OpenCode dispone de reglas de permisos detalladas para edit, bash, read, grep, glob, skill y otros, por lo que la propia configuración debería hacer cumplir el flujo de trabajo.
Ajuste las rutas según su propio repositorio. El principio se mantiene igual:
builder can edit product code;
reviewer can write review notes;
neither agent can commit or push;
external directories are denied;
dangerous shell commands ask or deny.
Habilidades como barandilla portátil
La parte más reutilizable no es solo el archivo de configuración, sino la habilidad en sí. Las habilidades de OpenCode son definiciones reutilizables de SKILL.md que se almacenan en carpetas de habilidades a nivel de proyecto o global. La ubicación canónica a nivel de proyecto es:
.opencode/skills/<skill-name>/SKILL.md
También existen rutas de habilidades compatibles con Claude y con agentes, pero para este flujo de trabajo es sensato mantenerlo simple. Coloque la habilidad de protección aquí:
.opencode/
skills/
opencode-ollama-agent-guardrails/
SKILL.md
Cada SKILL.md debe contener información de metadatos con al menos un name y un description. El nombre debe estar en minúsculas, separado por guiones y ser idéntico al nombre de la carpeta. Una habilidad de restricción puede indicar a los agentes reglas como:
- Do not publish raw prompts.
- Do not publish raw session logs.
- Do not use absolute local paths.
- Do not edit outside the approved product directory.
- Do not claim success without test output.
- Do not weaken tests to make validation pass.
- Do not commit, push, rebase, or force-push.
- Store review notes separately from production code.
- Treat screenshots as sensitive evidence.
- Stop for human approval after signoff.
Las reglas parecen elementales, pero evitan errores reales. Si se encuentran únicamente en el AGENTS.md de un repositorio, permanecen allí. Al estar empaquetadas como una habilidad, te acompañan a dondequiera que vayas.
El modo sin interfaz lo hace reproducible
La programación interactiva es adecuada para la exploración. El modo sin interfaz es mejor para ejecuciones reproducibles. El paso del constructor se ve así:
opencode run \
--model ollama/minimax-m3:cloud \
--agent minimax-builder \
--dir . \
"$(cat agent-sessions/project-slug/promptNN/PROMPTNN_CODER.md)"
Y la aprobación del revisor:
opencode run \
--model ollama/glm-5.1:cloud \
--agent glm-reviewer \
--dir . \
"$(cat agent-sessions/project-slug/promptNN/PROMPTNN_REVIEWER.md)"
Para configuraciones más complejas con servidores MCP, inicie un servidor OpenCode local una vez y conecte las ejecuciones posteriores a él, evitando así reinicios repetidos desde cero:
opencode serve --hostname 127.0.0.1 --port 4096
opencode run \
--attach http://localhost:4096 \
--agent minimax-builder \
--dir . \
"$(cat agent-sessions/project-slug/promptNN/PROMPTNN_CODER.md)"
Vincule el servidor a 127.0.0.1. Quienquiera que lo exponga a otra máquina debe establecer OPENCODE_SERVER_PASSWORD y ejecutarlo como un servicio de desarrollo real, ya que la documentación de la CLI describe la autenticación básica HTTP a través de esa variable. El modelo no se ha vuelto más inteligente; simplemente es más difícil engañarlo.
Conservar los comandos y la salida sin que se filtren
Es útil almacenar localmente los archivos de comandos y la salida de las sesiones para depurar el comportamiento del agente. No lo es publicar comandos en bruto ni exportaciones sin procesar. Los registros de los agentes pueden contener rutas locales, comandos de la shell, nombres de ramas, tareas pendientes internas, secretos de implementación, nombres de entorno, rutas de capturas de pantalla, credenciales sueltas y redacciones de comandos que preferiría reutilizar en privado.
La regla: almacenar todo localmente y publicar únicamente resúmenes editados y plantillas reutilizables. La opción opencode export [sessionID] de OpenCode con --sanitize ayuda en la revisión interna, pero hay que considerarla como una primera pasada y no como un botón de publicación. Todo lo que sea público debe someterse a una segunda revisión de edición.
Para un repositorio público, guarde estos cambios:
AGENTS.md
opencode.json
.opencode/agents/*.md
.opencode/skills/*/SKILL.md
templates/*.md
scripts/*.zsh
scripts/redact_sessions.py
docs/publication-redaction-checklist.md
Y ignora estos archivos:
agent-sessions/**
screenshots/**
.env
project.local.env
*.raw.log
*.events.jsonl
opencode-session-*.json
El resultado son informes compartibles sin convertir el repositorio en una fuente de fugas de información.
Dónde ayudaron las herramientas MCP
Los modelos son solo una parte del sistema, y la interfaz de las herramientas es de suma importancia. Una forma útil de ver los MCP y las herramientas integradas es como sentidos y manos especializados:
| Workflow stage | Useful tool or MCP category | What it helped with |
| ---------------- | ------------------------------------------------------- | -------------------------------------------------- |
| Planning | repo search, docs lookup, issue/context reader | understand current architecture before changing it |
| Coding | filesystem, shell, language server, package manager | edit code, inspect symbols, run targeted commands |
| Review | git diff, grep, test reports, generated artifact reader | catch scope creep and weak tests |
| Unit tests | test runner, coverage | prove the patch did not only compile |
| Browser tests | Playwright/browser automation | validate real UI routes and flows |
| Security tests | secret scan, dependency audit, SAST | catch obvious unsafe output before publish |
| Docs/site checks | static-site build, route checks, smoke tests | catch generated-output drift |
La mejor configuración de MCP no habilita todo. Proporciona al agente las pocas herramientas que necesita y hace que las más arriesgadas requieran autorización previa. OpenCode define los servidores MCP bajo la clave mcp en opencode.json y dispone de comandos de línea de comandos para gestionarlos. Trate estas definiciones como dependencias de producción: fije sus versiones, revísalas y elimine las que no se utilicen.
Por qué las capturas de pantalla tienen su lugar
Las pruebas del navegador devuelven un resultado de éxito o fracaso. Las capturas de pantalla ofrecen evidencia visual. Ayudaron al revisor a detectar lo que las pruebas unitarias pasan por alto: un diseño dañado después de una compilación correcta, contenido incorrecto en una ruta, páginas generadas vacías, regresiones en la navegación, un banner de error sobre el que ninguna prueba se realizó, y prueba de que existe una ruta de sitio estático y que se renderiza.
También conllevan riesgos: los nombres de los perfiles del navegador, las pestañas privadas, las rutas de localhost, los títulos de los problemas, los tokens de URL y los resultados de las herramientas de desarrollo pueden terminar todos en el marco de captura. La política establece tomar capturas de pantalla únicamente de la interfaz de localhost, recortarlas cuidadosamente, revisarlas antes de publicarlas, y nunca capturar páginas de autenticación, paneles de producción, pestañas privadas ni terminales que muestren valores del entorno. Una captura de pantalla es una prueba y, por defecto, no se considera un artefacto público.
Un estudio de caso sobre un proyecto wiki privado
El autor lo aplicó a una wiki privada de LLM y a un proyecto de sitio estático, publicando únicamente un resumen sanitizado. Sus notas finales de validación indicaban que 977 pruebas de Python habían pasado, se había realizado una reconstrucción del sitio estático con actualización, pruebas de validación de dominio y sitio de prueba, se había generado la documentación, se habían verificado las rutas y 150 pruebas de Playwright también habían pasado. Respecto a las funcionalidades completadas dentro del alcance definido, la confianza del autor era alta, aproximadamente de 8 a 9 sobre 10, respaldada por pruebas reproducibles, verificaciones del sitio generado, comprobaciones de rutas y validación en navegador. Esa puntuación es subjetiva y no debería generalizarse más allá de ese proyecto.
El punto débil no era el código del producto. Un script de automatización sin interfaz falló porque los nombres de los agentes estaban configurados incorrectamente. Utilizaba nombres genéricos:
planner
coder
tester
reviewer
mientras que los agentes configurados eran en realidad:
minimax-builder
glm-reviewer
La discrepancia hizo que el proceso volviera a adoptar un comportamiento incorrecto, por lo que la finalización multiagente prevista no se completó. Este fallo resultó útil, ya que demostró la importancia de los nombres simples, la configuración exacta, las rutas relativas y la verificación de la carpeta de sesión. El patrón corregido se ve así:
opencode run \
--model ollama/minimax-m3:cloud \
--agent minimax-builder \
--dir . \
"$(cat agent-sessions/project-slug/promptNN/PROMPTNN_CODER.md)"
opencode run \
--model ollama/glm-5.1:cloud \
--agent glm-reviewer \
--dir . \
"$(cat agent-sessions/project-slug/promptNN/PROMPTNN_REVIEWER.md)"
Eso significa que no hay rutas absolutas, ni nombres de agentes inventados, ni archivos de instrucciones ocultos fuera del alcance de trabajo.
¿Qué tan cerca estamos de un flujo de trabajo de Frontier?
Aquí es donde es fácil exagerar. Una configuración de MiniMax más GLM en OpenCode y Ollama no es lo mismo que ejecutar directamente el mejor modelo de programación de Frontier. Los modelos de Frontier siguen teniendo un razonamiento más sólido, un mejor comportamiento con contextos largos y una mejor capacidad para seguir instrucciones por defecto, por lo que comparar modelo por modelo no sería justo. La comparación relevante es la calidad del flujo de trabajo: planificación, revisión, pruebas, capturas de pantalla, verificaciones de seguridad y aprobación humana.
El flujo de trabajo tiene una gran importancia. En tareas bien delimitadas respaldadas por pruebas sólidas, la configuración puede parecerse mucho a la de un modelo de tipo Frontier, ya que incluye roles separados, planificación previa, revisiones por ambas partes durante la implementación, puntos de validación obligatorios, memoria de sesión local, pruebas con capturas de pantalla, verificaciones de seguridad y commits controlados por humanos.
Se acerca bastante a los modelos deterministas en tareas de desarrollo de funcionalidades, generación de sitios estáticos, sistemas de recuperación e búsqueda, tareas que requieren muchas pruebas, revisión de los resultados generados, detección de ampliaciones no planificadas del alcance y obligación a los desarrolladores de documentar los fallos. Sin embargo, los modelos Frontier siguen siendo superiores en situaciones de arquitectura ambigua, refactorizaciones profundas en código poco probado, juicios relacionados con el estilo y el producto, capacidad de autocorrección a largo plazo, necesidad de menos intentos, seguimiento automático de instrucciones y análisis de capturas de pantalla complejas.
Modelo de amenazas
Varios riesgos conocidos relacionados con la programación por IA disminuyen con este flujo de trabajo: afirmaciones infundadas de éxito, desarrolladores que trabajan fuera del repositorio previsto, revisores que se convierten en implementadores, prompts en bruto que llegan a repositorios públicos, registros que exponen rutas o secretos, capturas de pantalla que revelan pestañas o tokens privados, cambios silenciosos en los archivos generados, y agentes que realizan commits o pushes antes de que alguien los revise.
La revisión humana sigue siendo necesaria. La autonomía total no es el objetivo; lo que sí lo es es un ciclo más estricto, en el que cada afirmación vaya acompañada de pruebas y cada acción riesgosa tenga un límite.
Pros y contras
Pros
- Reproducibilidad. Los prompts generan carpetas, las ejecuciones dejan notas y los procesos de aprobación pueden rastrearse.
- Gobernanza. El desarrollador no puede omitir silenciosamente las pruebas si el revisor debe bloquear la aprobación sin pruebas de validación.
- Flexibilidad del modelo. Puede cambiar de modelo a medida que evolucionan las capacidades de Ollama y OpenCode, y este proceso supera la tasa de rotación de usuarios.
- Velocidad. Una vez que existen los prompts y scripts, ejecutar la siguiente tarea definida es rápido.
Desventajas
- Más trámites. Es más complejo que un simple prompt de chat, y ese es el costo a pagar.
- Se necesita configuración para la aplicación de reglas. Pedirle al revisor que no edite el código en producción es menos efectivo que hacerlo mediante permisos y verificaciones de CI.
- Los prompts defectuosos siguen generando resultados deficientes. El ciclo reduce el caos, pero no reemplaza un alcance bien definido.
- Los permisos requieren cuidado. Los servidores MCP y el acceso a la shell son muy potentes, por lo que deben tratarse como acceso a entornos de producción.
- Los registros son sensibles. Cuanto más detallados sean los registros, mayor debe ser la precaución al editarlos.
La afirmación que se mantiene
Esta configuración no convertirá a MiniMax ni a GLM en modelos de vanguardia de primer nivel. Lo que sí hace es hacer que el código agente más económico, gestionado por Ollama, sea más disciplinado, auditable y útil para tareas de ingeniería bien delimitadas. Esa es la única afirmación que puede hacer honestamente.