Flujos de trabajo vs agentes: ¿Quién debería elegir el siguiente paso de investigación?

Un agente de investigación llega a la frase “LangGraph admite una ejecución duradera”, marca una casilla en una tabla de comparación y recomienda el framework. Se envía una aplicación local; el proceso se detiene y nada vuelve a funcionar. ¿Qué falló?

Se pasó por alto una condición. “Admite persistencia” no es lo mismo que “la persistencia está implementada en esta aplicación”. Un agente de inteligencia de mercado útil debería darse cuenta de esa diferencia, leer más allá de las etiquetas de las características y, a veces, cambiar su siguiente pregunta según lo que descubre.

Anteriormente en esta serie, el foco estaba en el propio entorno de ejecución. Aquí, la pregunta es cuánta libertad tiene el modelo dentro de ese entorno.

Dos formas de investigar el mismo encargo

Supongamos que el encargo solicita la relación entre LangGraph y Deep Agents, además de saber qué necesita un servicio de investigación en Python para recuperarse tras un reinicio, utilizando únicamente la documentación oficial.

Un enfoque consiste en un proceso fijo. Usted proporciona las páginas adecuadas, extrae las afirmaciones clave, compara sus limitaciones y elabora un resumen citado. Eso es un flujo de trabajo.

El otro enfoque permite que el modelo elija el siguiente paso. Busca, abre una página, detecta una condición faltante y decide en qué profundizar a continuación. Eso es un agente.

Ambos pueden utilizar modelos, herramientas, ramificaciones y intentos repetidos. La verdadera diferencia radica en quién decide el camino. La nota de LangGraph sobre flujos de trabajo y agentes aclara claramente esta distinción.

Una regla práctica de referencia:

• Los documentos y pasos ya se conocen: prefiera un flujo de trabajo.
• Las fuentes útiles solo aparecen durante la investigación: pruebe con un agente limitado.
• La entrega debe ser predecible, pero la investigación no necesariamente: combine ambos enfoques.

Este proyecto se enmarca en la tercera categoría.

Cuando un hallazgo reescribe la pregunta

A primera vista, el resumen parece ser una competencia entre frameworks. Sin embargo, la descripción de Deep Agents muestra que funciona con el entorno de ejecución LangGraph. La investigación cambia de enfoque.

Pregunta antigua: ¿qué framework gana?

Nuevo hallazgo: operan en capas diferentes.

Pregunta mejor: ¿qué tareas corresponden a la propia aplicación y cuáles a un mecanismo de nivel superior?

La persistencia requiere la misma atención. La documentación describe la configuración de puntos de control y la identidad de los hilos para grafos locales. También distingue entre almacenamientos en memoria y aquellos respaldados por base de datos, señalando que el Agent Server gestiona por sí solo la infraestructura de persistencia. Véase Persistencia y Puntos de Control.

Una respuesta útil mantiene esas condiciones. Una marca en una tabla de características no lo hace. Todo lo que sigue proviene de la lectura directa de la documentación, no de una transcripción de un agente grabado.

Forma del sistema: flujo de trabajo que rodea al investigador

La aplicación controla el objetivo, las fuentes permitidas, los límites de las solicitudes y cómo se maneja el resultado. Dentro de esos límites, el modelo selecciona búsquedas y documentos. La investigación mantiene su flexibilidad; la entrega, en cambio, es explícita.

Componentes involucrados:

• LangGraph ejecuta las etapas externas de la aplicación.
• El SDK de Anthropic proporciona al modelo herramientas nativas para realizar búsquedas y obtener información en la web.
• Un registro de auditoría guardado conserva las fuentes, los registros de citación, el uso del sistema y los errores de las herramientas.

Una sola llamada al proveedor puede incluir varias acciones de búsqueda y lectura. LangGraph dirige el proceso general; no crea cada consulta por sí mismo. Un único investigador puede supervisar fácilmente los límites del sistema. Los agentes avanzados pueden esperar hasta que sea necesario un mayor manejo de contexto y delegación de tareas. Cambiar de proveedor también implicaría reescribir los contratos relacionados con las herramientas y las citaciones.

La búsqueda encuentra páginas; la obtención las lee

La solicitud expone ambas herramientas:

tools = [
    {
        "type": "web_search_20250305",
        "name": "web_search",
        "max_uses": 3,
    },
    {
        "type": "web_fetch_20250910",
        "name": "web_fetch",
        "max_uses": 4,
        "max_content_tokens": 6000,
        "citations": {"enabled": True},
    },
]

Estas definiciones provienen del código complementario y no constituyen un programa completo. El modelo que elija debe ser compatible con las versiones de las herramientas documentadas. Anthropic documenta ambas herramientas en la sección de Agents y Tools de su sitio para desarrolladores; allí encontrará las especificaciones actuales de búsqueda y obtención de datos.

Tres restricciones determinan el diseño.

1. Los límites se aplican por solicitud. Se permiten como máximo dos llamadas al SDK, incluyendo una continuación tras una pausa, y no se activan las reintentos del SDK.
2. Las citaciones en las operaciones de obtención de datos se activan intencionadamente para que los registros de citación nativos se conserven, además del texto de la respuesta.
3. Un código HTTP 200 no es prueba de evidencia. La API puede tener éxito mientras que la operación de obtención de datos dentro de ella falla, por lo que también es necesario examinar los bloques de resultados de la herramienta.

Estos límites limitan la cantidad de solicitudes y herramientas que se pueden utilizar. No representan un techo de gasto ni un plazo estricto.

Las citaciones aún pueden ayudar

Imagínese un informe que afirma que la aplicación se recuperará automáticamente después de una caída, citando una página sobre persistencia configurable. El enlace es real. La afirmación es más amplia que las pruebas disponibles.

Una auditoría básica plantea cuatro preguntas de sí/no: ¿El modelo finalizó normalmente? ¿Obtuvo al menos un documento? ¿Devolvió texto con la respuesta? ¿La respuesta final incluye citas originales? Si se aprueba, el estado es needs_review. Si falla en alguna verificación obligatoria, el estado es incomplete.

Ninguno de estos estados implica que las afirmaciones sean ciertas. Las citas pueden referirse a índices y ubicaciones de pasajes en lugar de URLs, y el prototipo almacena esos registros sin determinar cómo se relacionan entre sí.

Un hábito útil para la revisión: elija una afirmación sustantiva y consulte su fuente. ¿Qué condición, excepción o limitación cambiaría la recomendación?

Aumente la complejidad solo cuando pueda medir las ventajas

Las investigaciones prolongadas podrían requerir una carga selectiva de contexto, notas compactas o investigadores separados para ramas independientes. Esas ideas aparecen en los artículos de Anthropic sobre cómo organizar el contexto para los agentes y sobre sistemas de investigación multiagente. En esta aplicación, se trata de opciones que se deben evaluar, no de mejoras que se incluyan por defecto.

Cuatro verificaciones constituyen una primera evaluación adecuada:

1. ¿Explica la relación entre LangGraph y Deep Agents?
2. ¿Mantiene intactas las condiciones para la recuperación tras un reinicio?
3. ¿Detecta cuando falla la obtención de un documento?
4. ¿Reconoce que los documentos por sí solos no permiten determinar la opción de despliegue más económica?

Coloque el flujo de trabajo de documento proporcionado junto a la búsqueda dirigida por modelo. Mantenga fijos el modelo y los requisitos de respuesta, especifique claramente qué fuentes puede ver cada parte e registre el uso real. Evalúe los hallazgos obtenidos, las condiciones faltantes y la incertidumbre real, y no solo el número de citas.

Situación actual: diez pruebas de integración han superado las pruebas con el SDK real y el entorno de ejecución de LangGraph utilizando HTTP simulado. Todavía no se ha realizado ninguna ejecución con la API en tiempo real, ya que no se habían configurado las credenciales, por lo que no existen cifras medidas sobre calidad, latencia o costos.

Perspectivas futuras

Ahora existe un diseño digno de probar: un investigador capaz de seguir las pruebas, integrado en un software que deja un rastro inspeccionable. El siguiente problema surge cuando el proceso se detiene a mitad de camino. Los archivos de respuesta guardados ayudan a comprender qué ocurrió, pero no reinician el proceso. La siguiente sección añade un estado de ejecución persistente y prueba la recuperación en un proceso nuevo, siguiendo aún utilizando esta aplicación de investigación web.