Inicio / Varios agentes y verificación adversa

Workflows deterministas: esquemas, checkpoints, reanudación

Un workflow es un script que orquesta subagentes de forma determinista, con una salida estructurada mediante un esquema JSON y un checkpoint después de cada etapa, pero el modelo que se aplica a un agente relanzado sigue un orden de prioridad de cuatro niveles, y sin que los tres primeros estén rellenados, ese agente hereda como último recurso el modelo de la sesión que lo ejecuta, no de la que escribió el script.

Un workflow, en el sentido de este módulo, es un script que encadena varias llamadas de agente de forma determinista: la misma secuencia de etapas y el mismo esquema de salida en cada ejecución, a diferencia de una conversación donde el agente decide solo el orden de sus acciones. La documentación oficial de los workflows de Claude Code muestra un ejemplo que pasa directamente un objeto de esquema a la función que llama a un agente, lo que elimina cualquier margen de interpretación sobre la forma del resultado esperado.

El esquema que reemplaza a un informe en lenguaje libre

Cuando un agente debe transmitir su resultado a la etapa siguiente, un esquema JSON impone campos con nombre y tipos precisos, en lugar de un párrafo que el agente siguiente tendría que releer e interpretar. Dos agentes que intercambian mediante un esquema común no se malentienden sobre la forma, lo que traslada la vigilancia a donde de verdad importa, el contenido.

El checkpoint que evita rehacerlo todo

Cada etapa terminada escribe un checkpoint. En el momento de reanudar un workflow interrumpido, una etapa marcada como terminada devuelve directamente su resultado guardado sin relanzar al agente que lo produjo. Una etapa cuyo prompt ha cambiado desde la última ejecución se relanza, y toda etapa colocada después de ella en la secuencia también, incluso si su propio prompt no se ha movido.

etapa : rédaction_synthèse
estado : terminado
prompt idéntico a la última ejecución : sí
modelo puesto en el script para esta etapa : ninguno

Este último campo, ningún modelo puesto en el script para esta etapa, es el punto más fácil de pasar por alto al releer un script escrito varios meses antes.

El modelo que un agente relanzado hereda realmente

Desde la versión 2.1.251, el modelo que se aplica a un agente relanzado sigue un orden de prioridad de cuatro niveles: el parámetro puesto directamente en la llamada de ese agente, el campo modelo del propio subagente, una variable de entorno propia del subagente, y luego, como último recurso, el modelo de la sesión que ejecuta el script en el momento en que lo relanza. Antes de esta versión, el orden difería en un punto que lo cambia todo para un script antiguo: la variable de entorno pasaba primero y prevalecía sobre el parámetro de la llamada así como sobre el campo modelo del frontmatter, incluso sobre el valor model: inherit. Cuando ninguno de los niveles prioritarios está rellenado, un agente escrito bajo un modelo dado en una fecha determinada cambia silenciosamente al modelo de la sesión que lo relanza meses después, sin que ningún mensaje en pantalla lo señale. Este punto se une a la elección de arquitectura planteada en fan-out, pipeline, barrera: un pipeline guardado sigue siendo un pipeline, y cada una de sus etapas conserva su propio riesgo de herencia silenciosa de modelo.

Reabrir un script escrito varios meses antes y verificar línea por línea qué modelo se aplicará realmente a cada agente lleva unos minutos, a condición de verificar también la versión de la herramienta de orquestación en el momento de la escritura del script frente a la instalada hoy. No hacerlo produce un resultado entregado por un modelo que nadie eligió para esa etapa concreta, sin que ninguna alerta avise del cambio.