Google publicó ‘google/agents-cli’, y la primera reacción puede ser meterlo en la carpeta de “otra herramienta de agentes”. Yo no lo leería así. No reemplaza a Codex, Claude Code ni a otros asistentes de programación. Les da un camino más claro para construir, evaluar, desplegar y observar agentes ADK en Google Cloud.
La diferencia importa. Hoy muchos equipos pueden armar una demo de agente. Lo difícil empieza después: qué fuentes puede leer, cómo se detecta una mala respuesta, quién aprueba la salida, dónde quedan los logs y quién lo detiene si el despliegue cambia el comportamiento.
Por qué escribí sobre esto
La frase “vamos a crear un agente” ya no me impresiona tanto. La primera versión suele salir. El problema aparece en la segunda semana, cuando alguien pregunta por qué respondió distinto, qué fuente usó y quién se hace cargo de corregirlo.
Por eso ‘agents-cli’ merece atención. La FAQ oficial de GitHub dice que no es una alternativa a Codex, Claude Code o Antigravity CLI. Es una herramienta para esos agentes de programación. Les da comandos y skills para construir, evaluar y desplegar agentes ADK en Google Cloud.
Suena menos llamativo que un nuevo superagente. Para trabajo real, esa parte es más importante.
El caso de trabajo que usé
No empezaría con un bot público de soporte. Empezaría con un agente interno de triaje para consultas de proveedores o excepciones de política.
El paquete de entrada sería pequeño:
- una solicitud entrante,
- un documento de política vigente,
- una nota de estado del cliente o proyecto,
- un formato de salida esperado.
El agente tendría que redactar una respuesta corta, citar el párrafo fuente, marcar si requiere revisión humana y asignar el siguiente responsable. Es un caso cercano a trabajo real y acotado para detectar errores.
Lo que comparé en la práctica
Tomé ‘agents-cli’ como una capa de ciclo de vida, no como una fábrica mágica.
| Paso | Lo que espero | Lo que todavía no confiaría |
|---|---|---|
| Setup | Python 3.11+, ‘uv’, Node.js y skills instalados de forma repetible | Comandos copiados de memoria |
| Scaffold | Separación entre código del agente, pruebas, evals y despliegue | Una carpeta de archivos generados sin revisión |
| Código ADK | Herramientas, callbacks, estado y conducta visibles | Un agente basado solo en un prompt largo |
| Evaluación | Casos de prueba, grading, comparación de versiones y análisis de fallos | Un ejemplo correcto como prueba suficiente |
| Despliegue | Ruta clara a Agent Runtime, Cloud Run o GKE | Un despliegue sin dueño ni coste claro |
| Observabilidad | Logs y trazas que expliquen fallos | Un agente en producción que nadie revisa al segundo día |
La entrada oficial es sencilla: ‘uvx google-agents-cli setup’. Para instalar solo las skills, la documentación muestra ‘npx skills add google/agents-cli’. El inicio es ligero. Justamente por eso pondría los límites operativos desde el principio.
Las comprobaciones que pondría al lado
Pondría tres controles junto al primer piloto.
Primero, un archivo con casos fallidos. Solicitudes ambiguas, políticas antiguas, fuentes incompletas. Un ejemplo limpio no demuestra demasiado.
Segundo, un responsable de revisión. Si una persona aprueba la salida, debe saber qué mirar para aceptarla o rechazarla.
Tercero, una vía de parada. Si el comportamiento cambia tras desplegar, la primera respuesta no puede ser convocar una reunión.
Dónde se rompe en la práctica
El punto débil no suele ser el comando. Suele ser la confianza.
Un agente generado puede verse ordenado y aun así fallar donde duele:
- cita el párrafo correcto, pero ignora la fecha de versión,
- manda una excepción al responsable equivocado,
- escribe como si fuera una respuesta para cliente cuando debía quedar interna,
- pasa los casos fáciles de evaluación y se cae con solicitudes sucias,
- se despliega, pero nadie mira los logs después del primer día.
Por eso me interesa más la parte de evaluación que el scaffold. La documentación habla de generar evals, calificar, comparar versiones, analizar fallos, listar métricas y optimizar prompts. Si un equipo salta ese bucle, la CLI solo produce una primera versión más limpia.
Qué volvería a elegir
Probaría ‘google/agents-cli’ cuando se cumplan tres condiciones.
El equipo ya trabaja cómodo con Google Cloud. El agente probablemente vivirá cerca de ADK, Agent Runtime, Cloud Run, GKE o Gemini Enterprise. Y alguien mantendrá los casos de evaluación después del lanzamiento.
No lo usaría por defecto para una automatización local pequeña, un script puntual o un chatbot sencillo. Cuando la herramienta pesa más que el trabajo, deja de ser automatización y pasa a ser carga operativa.
El piloto seguro es estrecho: un agente interno de triaje, un conjunto de fuentes, un formato de salida, un destino de despliegue y entre diez y cincuenta casos de evaluación deliberadamente incómodos.
Permisos y límites: dónde no lo pondría
Miro primero si una persona conserva la revisión final. Para triaje interno, revisión de políticas o preparación operativa, lo probaría. No lo pondría de entrada en respuestas finales a clientes, cambios de registros o aprobaciones de excepción.
La señal de fallo es concreta: si el agente inventa una fuente, enruta mal el caso o no deja logs útiles, el diseño es frágil y hay que parar el piloto.
Checklist antes de usarlo
- Confirma si la estrategia de Windows encaja. La documentación actual apunta a WSL 2, no a Windows nativo.
- Separa desarrollo local con AI Studio de despliegue real en Google Cloud.
- Escribe los casos de evaluación antes de confiar en el scaffold.
- Guarda al menos un caso fallido dentro del repo.
- Nombra al revisor, al dueño del proyecto cloud y al responsable de costes.
- No amplíes permisos de ejecución o despliegue hasta ver el camino de logs.
- Usa LLM-as-judge como filtro, no como juez final para decisiones sensibles.
Fuentes que revisé
Revisé el repositorio oficial de GitHub, Getting Started, la referencia CLI, la guía de evaluación, la guía de despliegue, el quickstart de Google Cloud, el blog de Google Developers y la página de PyPI el 6 de julio de 2026. En una herramienta que cambia rápido, prefiero fuentes primarias antes que resúmenes que mezclan ADK, Agent Platform y agents-cli.
Respuesta corta
Si tu equipo ya contempla agentes ADK sobre Google Cloud, ‘agents-cli’ merece una prueba. Si solo necesitas automatizar una tarea local pequeña, probablemente es demasiado.
Yo escribiría esto en la tarjeta del piloto:
‘agents-cli’ sirve para hacer visible el ciclo de vida del agente, no para dejar de pensar en él.
La CLI puede ayudar a un agente de programación a no olvidar los pasos correctos. No decide si el agente debe existir, si el conjunto de evaluación es honesto o si la organización está lista para operarlo.
Un piloto de dos horas
Le daría dos horas y ningún permiso de producción.
Primera hora: instalar skills, crear un scaffold estrecho y escribir el design spec. La tarea debe ser aburrida para que los errores sean visibles. El triaje interno funciona porque la salida esperada es clara: párrafo fuente, marca de revisión, responsable y siguiente acción.
Segunda hora: escribir el conjunto de evaluación y calificarlo. Mezclaría solicitudes limpias, solicitudes sin fuente suficiente, políticas antiguas y casos que deben rechazarse. Después cambiaría un prompt o una regla y compararía versiones.
Si la segunda hora no produce notas útiles de fallo, no desplegaría.
Preguntas para la nota de despliegue
| Pregunta | Respuesta antes de ampliar |
|---|---|
| ¿Qué puede leer el agente? | Solo el paquete de políticas nombrado |
| ¿Qué no puede hacer? | Enviar respuestas finales o cambiar registros |
| ¿Qué prueba que mejora? | Baja el tiempo de revisión sin subir correcciones |
| ¿Qué detiene el piloto? | Fuente inventada, mal enrutamiento o falta de logs |
| ¿Quién posee la siguiente versión? | Un editor o platform owner con nombre, no “el equipo de IA” |
Con esa nota, la herramienta empieza a tener valor. Sin ella, ‘agents-cli’ solo es otra forma de crear software más rápido de lo que la organización puede operarlo.
FAQ
¿Google Agents CLI reemplaza a Codex o Claude Code?
No. La FAQ oficial lo presenta como una herramienta para agentes de programación, no como un agente de programación en sí.
¿Funciona sin Google Cloud?
Para desarrollo local, sí. Para despliegue y funciones cloud, hace falta Google Cloud.
¿Hace seguros los agentes de producción por defecto?
No. Ayuda con estructura, evaluación, despliegue y logs. El conjunto de evaluación, permisos, fuentes y límite de revisión siguen siendo responsabilidad del equipo.
¿Por dónde empezar?
Por un agente interno de triaje que no hable directamente con clientes. Si no supera un conjunto pequeño pero incómodo de evaluación, no ampliaría permisos.
Ruta de workflow
Dónde encaja esta guía
Usa esta sección para conectar la guía que estás leyendo con el workflow más amplio que apoya.
Una ruta para comparar plataformas de automatización, builders de apps, builders de agentes, contabilidad y asistentes de IA.
Abrir ruta de workflow- Mejor encaje
- equipos que deciden entre comprar una herramienta simple, construir un flujo interno o adoptar una plataforma más amplia
- No es ideal si
- Necesitas instrucciones paso a paso más que un marco de decisión.
Fuentes consultadas
Páginas públicas usadas para contrastar hechos reportados, documentación oficial, contexto de política, información de producto y afirmaciones que pueden cambiar.
- google/agents-cli GitHub repository Google
- Agents CLI getting started Google
- Agents CLI reference Google
- Agents CLI evaluation guide Google
- Agents CLI deployment guide Google
- Build an agent with ADK and Agents CLI in Agent Platform Google Cloud
- Agents CLI in Agent Platform: create to production in one CLI Google Developers Blog
- google-agents-cli on PyPI PyPI
