Salida estructurada en CrewAI: evita la deriva de datos con Pydantic

Si viste que una tarea devuelve markdown una vez y un ensayo libre en la siguiente, no estás solo.
La solución es directa: define un esquema de salida con Pydantic.

¿Por qué salida estructurada?

• Las tareas siguientes pueden leer campos fijos
• Evitas parsear strings frágiles en cada ejecución
• Los fallos aparecen antes (incompatibilidad de campos lanza error)

En esencia, es un contrato de API. La colaboración estable necesita contrato.

Crear modelos de salida

from pydantic import BaseModel, Field
 
class Finding(BaseModel):
    title: str = Field(description="Finding title")
    summary: str = Field(description="Brief explanation")
    source: str = Field(description="Reference URL")
 
class ResearchReport(BaseModel):
    topic: str = Field(description="Topic name")
    findings: list[Finding] = Field(description="Key findings list")
    conclusion: str = Field(description="Final conclusion")

Usar output_pydantic en Task

from crewai import Task
 
research_task = Task(
    description="Research AI observability tools in 2026.",
    expected_output="Structured research result.",
    output_pydantic=ResearchReport,
)

Tras ejecutar, puedes acceder directamente a campos estables en lugar de adivinar desde texto.

Estilo recomendado de combinación

• Mantén explícitos los requisitos de calidad en expected_output
• Define semántica de campos (longitud de summary, formato de source)
• Haz que tareas posteriores dependan de campos, no del estilo de redacción

Errores comunes de principiantes

1. Creer que con Pydantic ya no hace falta expected_output
2. Definir muy pocos campos y perder información
3. Definir demasiados campos granulares y provocar omisiones frecuentes

⚠️ Empieza con 3-5 campos clave. Amplía solo cuando sea necesario.

Siguiente paso

Ahora tu crew individual ya puede generar salida consistente. El siguiente paso es orquestar múltiples crews.
👉 Flow Basics