Google ha lanzado recientemente un curso gratuito de Agente.
Las lecciones van desde Prompt, Agent Loop hasta Graph Workflow, Multi-Agent y sistemas autoevolucionarios. A primera vista, es como introducir un nuevo conjunto de métodos de desarrollo de agentes.
Pero al juntar el material oficial de Google ADK 2.0, la Guía de Arquitectura de Google Cloud y varios estudios recientes de revisión de agentes, creo que no es una API en particular lo que realmente vale la pena prestar atención, sino un cambio más grande:
El desarrollo del agente está pasando de la etapa de "modelo de ajuste " a la de" diseño de sistemas ".
En el pasado, la mayoría de las aplicaciones de IA eran:
Input → Prompt → Model → Export.
Traducción, resumen, clasificación, extracción de información, reescritura de contenido, estas tareas generalmente se pueden completar con una sola llamada.
El desarrollo es rápido, el costo es fácil de estimar, y si hay un error, vuelva a llamar una vez.
Pero después de la llamada a la herramienta, el agente comienza a entrar realmente en el proceso de negocio.
Puede buscar materiales, llamar a API, ejecutar código, consultar bases de datos y luego decidir el siguiente paso en función de los resultados devueltos por la herramienta.
El modelo ya no es simplemente "respuestas a preguntas ".
Comienza a "hacer cosas ".
Una vez que el modelo participa en la ejecución, el problema es completamente diferente.
El contexto sigue creciendo, los resultados de las herramientas siguen entrando en el historial, los agentes pueden llamar a las herramientas repetidamente, o pueden desviarse del objetivo a mitad de camino, o incluso terminar antes de que se complete la misión.
Los procesos empresariales también agregan requisitos adicionales como permisos, aprobaciones, estado, reintentos, restauración y auditoría.
El reembolso del servicio al cliente, la verificación de la factura, la incorporación del personal, el procesamiento de pedidos, estas cosas no son simples preguntas y respuestas.
Así que la verdadera dificultad del agente ha ido de:
"¿Cómo puedo hacer que el modelo responda correctamente cuántas veces? "
Se convierte en:
"¿Cómo se puede lograr un proceso de negocio que involucra a un modelo? "
Y aquí es donde creo que vale la pena prestar atención a Google ADK 2.0.
Prompt, Agent Loop y Graph, ¿cuál es la diferencia?
Muchas personas ahora hablan de Agentes, y es fácil mezclar Prompt, Agent Loop y Workflow.
En realidad, abordan problemas en tres niveles diferentes.
Resolver rápidamente "Comprender"
Prompt dice al modelo:
¿Qué vas a hacer, cómo debes hacerlo, qué formato de salida, cuáles son las limitaciones?
Si la tarea en sí es relativamente simple, por ejemplo, traducción, resumen, clasificación, reescritura, entonces Prompt tiende a ser suficiente.
Agente Loop resuelve la acción.
Una vez que el modelo tiene las herramientas, puede:
Comprender el objetivo → hacer el siguiente paso → llamar a la herramienta → leer los resultados → decidir el siguiente paso.
Este es el típico bucle de agente.
Es particularmente adecuado para tareas abiertas.
como la búsqueda de materiales, la corrección de código, el análisis de datos complejos.
Debido a que es difícil escribir cada paso de antemano, el modelo necesita ajustar dinámicamente el plan en función de los resultados del campo.
Graph Workflow resuelve la "execución"
El Workflow se centra en:
¿Cómo debe correr todo el proceso?
¿Qué pasos deben ser realizados?
¿Qué tareas se pueden realizar en paralelo?
¿En qué circunstancias puedo entrar en la rama?
¿Cuándo debe ser aprobado manualmente?
¿Dónde volver a intentar después de un fracaso?
¿Qué estados deben guardarse?
Estas preguntas no se pueden dejar a los modelos para tomar decisiones ad hoc.
Son más adecuados para escribir en un programa.
Por lo tanto, los tres pueden entenderse simplemente como:
Prompt es responsable de la comprensión, Agent Loop es responsable de la acción y Workflow es responsable de la ejecución restringida.
Los tres no se reemplazan entre sí, sino que se pueden superponer.
Los problemas que se pueden resolver con una sola llamada al modelo no necesitan ser forzados a crear un flujo de trabajo.
Un solo agente ya puede completar tareas de manera estable, y no es necesario dividirlos en múltiples agentes para "agentic".
¿Cuándo comienza a fallar el prompt?
El mayor problema de Prompt no es que no sea lo suficientemente fuerte.
Pero a medida que el proceso de negocio se vuelve más complejo,El proceso en sí comienza a ocultarse dentro de Prompt.
Por ejemplo, un proceso de reembolso:
El usuario solicita un reembolso → consulta de pedidos → política de juicio → decidir si reembolsar → ejecutar el reembolso → enviar un correo electrónico de confirmación → actualizar la orden de trabajo.
Si se le asigna todo esto a un agente y se deja que el modelo decida por sí mismo el siguiente paso, parece muy flexible.
Pero los entornos de producción pueden surgir problemas rápidamente.
Es difícil para los desarrolladores determinar:
¿Este paso se lleva a cabo cada vez?
¿Ha completado la verificación de permisos antes de devolver el dinero?
¿Se repite el reembolso después de que la herramienta falla?
¿Dónde puedo continuar después de un error de envío de correo?
Después de que la actualización de la base de datos falló, la operación anterior no necesita revertirse?
Estos ya no son problemas rápidos.
Se trata de un problema de ingeniería de software
Por lo tanto, los sistemas verdaderamente confiables suelen adoptar una división más realista del trabajo:
El modelo es responsable de la incertidumbre y el código es responsable de la certeza.
Por ejemplo:
La comprensión y el análisis del contenido de la queja, puede ser entregada al modelo.
La consulta de pedidos, la ejecución de reembolsos, la actualización de la base de datos, deben ser controlados por el programa.
El bucle del agente es flexible, pero el entorno de producción debe "poner las riendas".
El encanto del bucle de agentes es que no necesita conocer todas las rutas de antemano.
El modelo puede ajustar continuamente el plan en función del resultado devuelto por la herramienta.
Por ejemplo,
"Ayúdame a investigar el reciente financiamiento de esta compañía ".
El agente puede buscar en páginas web, consultar bases de datos, organizar datos y luego continuar la búsqueda cuando descubra que la información es insuficiente.
Esta tarea puede ser pesada si se escribe completamente el flujo.
Pero Loop también tiene un riesgo inherente:
No sabe cuándo debe detenerse.
Por lo tanto, el bucle de agente en un entorno de producción generalmente requiere una configuración explícita:
- Número máximo de pasos de ejecución
- Tiempo total de espera
- Presupuesto de Token / API
- Condición de éxito
- Condiciones de falla
- Camino de escalada manual
De lo contrario, un error de juicio, puede convertirse en:
Llamar a la herramienta → Obtener un resultado incorrecto → Llamar de nuevo → Fallar de nuevo → Continuar intentando.
El resultado final fue:
Los costos aumentan, los retrasos aumentan, pero las tareas no se completan.
Por lo tanto:
Cuando el camino es incierto, deje que el modelo tome la decisión.
No deje que el modelo adivinar cuando la ruta esté determinada.
Este es un principio muy importante en la ingeniería de agentes.
¿Qué es lo que realmente resuelve el Graph Workflow?
Lo que hace Graph Workflow es muy simple:
El proceso que estaba oculto en la toma de decisiones del modelo se convierte en una estructura de software que los desarrolladores pueden ver, probar y modificar.
Por ejemplo, un proceso de reembolso podría diseñarse para:
Query orden
por
Análisis de quejas del usuario
por
Determinación de condiciones de devolución
por
Cumplir las condiciones → Ejecutar el reembolso
El │
- - Insatisfactorio → Cerrar la orden de trabajo
por
Generar un correo electrónico de confirmación
por
Actualización del estado de la orden
De esta manera, cada nodo se vuelve claro.
¿Qué pasos deben ser realizados?
¿Qué pasos se pueden hacer en paralelo?
¿Dónde se necesita la confirmación manual?
¿Dónde recuperarse después de un fracaso?
¿Qué resultados deben ser duraderos?
Todo puede ser expresado claramente.
Este es también el mayor valor de Workflow:
No hace que el agente sea más inteligente, sino que hace que el agente sea más controlable.
¿Por qué Google ADK 2.0 merece la pena prestar atención?
Un cambio importante en Google ADK 2.0 es poner oficialmente el tiempo de ejecución de flujo de trabajo en el centro del desarrollo de agentes.
Python 2.0 entró en GA el 19 de mayo de 2026 y Go 2.0 entró en GA el 30 de junio.
Desde el diseño oficial, los agentes, herramientas y funciones pueden ser nodos en el flujo de trabajo, y luego controlar todo el proceso a través de la relación de ejecución.
La ejecución secuencial, el enrutamiento condicional, las tareas paralelas, los bucles, los flujos de trabajo dinámicos, los procesos anidados y la intervención humana se pueden incorporar en un modelo de operación unificado.
Más importante aún, comienza a centrarse en el estado y la recuperación de las tareas largas.
Porque una verdadera tarea corporativa puede no ser completa en segundos.
Puede durar decenas de minutos, o incluso más.
Puede ser suspendido a mitad de camino.
Puede esperar la aprobación manual.
Es posible que un sistema externo no esté disponible temporalmente.
En este momento, el sistema debe saber:
¿Dónde diablos había estado antes?
Sin un punto de control y capacidad de recuperación de estado, el agente solo puede reiniciar una vez que se interrumpe.
Esta es la razón por la que los agentes empresariales eventualmente se parecerán cada vez más a los sistemas de software tradicionales.
Se requiere:
Estado.
evento.
Puntos de control.
Reintento.
autoridad.
El diario.
auditoría.
recuperación.
El contexto largo no es igual a una memoria confiable
Aquí hay otro problema que es muy fácil de pasar por alto:
Contexto Rot.
Muchas personas piensan que el agente "recuerda todo" simplemente poniendo toda la historia en contexto.
En realidad, las cosas no son tan simples.
A medida que la entrada se hace más larga, la capacidad del modelo para encontrar con precisión la información realmente importante del contexto puede disminuir.
Los agentes son más propensos a encontrar este problema que el chat normal.
Porque cada llamada a la herramienta, puede traer nuevos datos.
Resultados de búsqueda, contenido de la página web, registros de base de datos, valores de retorno de la API, razonamiento intermedio...
Si todo se añade constantemente al contexto, eventualmente se forma un enorme basurero de información.
Cuanto más largo sea el contexto, no necesariamente más inteligente.
A veces, es más fácil cometer errores.
Por lo tanto, el flujo de trabajo se puede aliviar de tres direcciones:
En primer lugar, el nodo aisla el contexto.
Cada nodo lee solo la información que realmente necesita.
En segundo lugar, el uso de estados estructurados.
No vuelva a llenar el historial de chat completo de la modelo cada vez.
Tercero, establecer puntos de control.
Después de que un nodo ha completado, el resultado de la confirmación se guarda y el siguiente nodo continúa desde el estado confirmado.
Pero aquí hay otra diferencia importante:
Guardar un registro de chat no es lo mismo que tener capacidad de recuperación.
Los mecanismos de recuperación reales también deben tenerse en cuenta:
Puntos de control, registro de eventos, operaciones idempotentes y políticas de reproducción para sistemas externos.
Los agentes múltiples no son más avanzados.
Hay otra tendencia que es fácil de malinterpretar:
Parece que cuanto más agentes hay, más avanzado es el sistema.
En realidad no es así.
Lo que realmente vale la pena con el multiagente es queDivisión clara de responsabilidades。
Por ejemplo:
Un agente es responsable de la recuperación.
Un agente se encarga del análisis.
Un agente se encarga de la ejecución.
Esto permite que cada agente tenga diferentes herramientas, permisos y contextos.
También surgieron preguntas:
Más llamadas.
Más comunicación.
La sincronización del estado es más compleja.
La solución de problemas es más difícil.
Después de la concurrencia, también surgen limitaciones de flujo, competencia de recursos y problemas de consistencia.
El estudio MAST de NeurIPS 2025 analizó más de 1.600 trayectorias de ejecución multiagente y resumió 14 categorías de fallas.
Muchos de esos problemas no son que Prompt esté mal escrito.
sino que:
La división de tareas no es razonable, la cooperación del agente falla, la gestión del estado es confusa y los resultados no pueden ser verificados.
Por lo tanto, estoy muy de acuerdo con un principio simple:
Sin límites claros de responsabilidades, no se debe tener más agentes para "multi-agentes ".
Los problemas que pueden resolverse de manera estable con un agente, primero utilice uno.
Solo si las tareas realmente tienen una división clara de roles, aislamiento de autoridad o colaboración compleja, considere la división.
La evaluación del agente no puede simplemente ver la respuesta "No ".
Las aplicaciones LLM tradicionales son fáciles de hacer con una prueba de tasa de precisión.
El agente es diferente.
Porque no solo tiene que "responder correctamente ", sino también" terminar las cosas ".
Como un agente de reembolso de servicio al cliente.
Y finalmente responde:
"El reembolso se ha completado para usted ".
No importa cuán bellamente dicho sea, no tiene sentido.
Lo que realmente debe ser verificado es:
¿El reembolso se ha ejecutado realmente?
¿Cantidad de reembolso, verdad?
¿Ha habido reembolsos duplicados?
¿Alguna operación fuera de autoridad?
¿Se ha actualizado la orden de trabajo?
¿El usuario ha recibido una notificación?
¿Hay un registro completo de todo el proceso?
Por lo tanto, cuando las empresas evalúan a los agentes, sugiero que contraste con un lote de tareas históricas reales y desensibilizadas.
Por ejemplo, 20 - 50 tareas.
Al menos tres implementaciones se comparan:
- Llamada al modelo único
- Agente único con herramientas
- Flujo de trabajo gráfico o multiagente
y utilizar el mismo conjunto de tareas y criterios de aceptación.
Registros clave:
- Tasa de éxito de primera finalización
- Tasa de éxito de la misión final
- Tiempo de modificación manual
- End-to - end retraso
- Costo total del modelo y las herramientas
- Número de reintentos
- En qué nodo se produce el fallo
- Número de acciones no autorizadas
- La fuente y la trayectoria de ejecución están completas
Especialmente para los negocios de alto riesgo, no se puede registrar solo el "éxito / fracaso".
También se debe mantener:
Justificación de la puntuación, evidencia original, trayectoria de ejecución y registro de revisión manual.
Porque después de realmente estar en línea, no solo necesita responder:
"¿Es que lo hizo bien? "
También responde:
"¿Por qué lo haces? "
El mejor punto de partida no es "crear un súper agente".
Si me tuvieran que ser un agente corporativo ahora, no pensaría primero en:
"¿Deberíamos tener un sistema multiagente? "
Voy a preguntar:
¿La empresa tiene un proceso manual que ya existe, con límites claros y resultados verificables?
Por ejemplo,
Verificación de factura.
Servicio al cliente de reembolso.
Auditoría del contrato.
Empleados en el trabajo.
El lead de ventas.
Primero, aclare el proceso manual.
¿Cuánto tiempo?
¿Cuánto cuesta?
¿Dónde están los errores más comunes?
¿Cuáles son los pasos que más desperdician mano de obra?
¿Cuáles son los pasos que determinan las reglas?
¿Qué pasos requieren el juicio humano?
Con este punto de referencia, luego decida dónde debe utilizarse el modelo.
Y luego:
Puede resolverlo con un agente, no se apresure a desmantelar más de uno.
Puede resolverlo con código, no deje que el modelo decida.
Sólo cuando el proceso aparece claro:
Ramas, paralelas, aprobaciones, reintentos, restauración
Cuando sea necesario, introduzca el Workflow.
Si se involucran acciones irreversibles como pagos, escritura de bases de datos, envío de correo electrónico, envío de órdenes de trabajo, se requiere un diseño previo:
Verificación de permisos, clave ipotente, confirmación manual, ruta de retroceso.
En ese momento descubrirás:
La ingeniería del agente se está acercando cada vez más a la ingeniería de software tradicional.
Por último: ¿Cuál es la próxima fase real para el agente?
Durante los últimos dos años, hemos estado investigando:
¿Cómo hacer que los modelos sean más inteligentes?
¿Cómo hacer que Prompt sea más eficaz?
¿Cómo hacer que el agente use mejor las herramientas?
Pero a continuación, los problemas que realmente preocupan a las empresas pueden convertirse en:
¿Cómo puedo hacer que un agente complete un trabajo de manera estable?
Estas dos cosas son muy diferentes.
El hecho de que un modelo se desempeñe de vez en cuando no significa que pueda entrar en un entorno de producción.
El hecho de que un agente pueda completar una tarea no significa que pueda completar de manera constante diez mil tareas al día.
Lo que las empresas realmente necesitan es:
éxito constante.
Costos controlables.
proceso rastreable.
Estado recuperable.
Permisos mínimos.
Reintento confiable.
Auditoría completa.
intervenciones manuales.
Evaluación continuada.
Así que prefiero ver al agente como un nuevo sistema de software en lugar de una ventana de chat que invoca herramientas.
Prompt permite que el modelo entienda la tarea.
El bucle del agente permite que el modelo actúe en función de los resultados.
El flujo de trabajo de gráficos limita todo el proceso de ejecución.
Los tres se colocan en el lugar correcto para obtener la flexibilidad de la IA y la certeza del software tradicional.
Y lo que realmente vale la pena prestar atención en Google ADK 2.0 tal vez no sea la cantidad de API que añade.
En cambio, envía una señal muy clara:
El agente está pasando de ser un "chatbot que invoca herramientas " a ser un" sistema de software que puede ser diseñado, operado y auditado ".
Graph Workflow es solo un paso en este camino.
En última instancia, lo que decide si un agente puede estar en línea todavía no es lo increíble que es la demo, sino:
Tasa de éxito, retrabajo manual, retrasos, costos y registros de seguridad.
Esta puede ser la competencia más digna de atención después de que el agente realmente ingrese al entorno de producción empresarial.