Elige dónde van tus prompts antes de conectar un modelo
Portward funciona con tres tipos de modelos: un proveedor de IA en la nube a través de un endpoint API estándar, un modelo que se ejecuta localmente en tu PC y el modelo integrado. Cada opción determina dónde van tus prompts, así que decídelo antes de dirigir al agente a un servidor.
Tres formas de conectar un modelo
Proveedor de IA en la nube
Un proveedor en la nube se conecta mediante un endpoint API estándar que ingresas en la configuración junto con tu propia clave API. Portward envía tus prompts a ese endpoint, y un prompt puede incluir el texto de cualquier archivo o registro que el agente haya leído, por lo que un modelo en la nube recibe ese texto. Tus chats, carpetas de trabajo y claves API permanecen en tu PC, y los secretos en la salida de las herramientas se ocultan antes de llegar al modelo. Esta ruta es común para registros largos y archivos de configuración grandes, porque el modelo no está limitado por tu hardware. Lee los términos del proveedor para ver cómo maneja los prompts y presiona el botón Probar después de ingresar el endpoint.
Modelo en tu PC
Un modelo que se ejecuta localmente en tu PC mantiene todo en la máquina: con un modelo local nada sale de ella. Conectas Portward al endpoint local, y el botón Probar muestra el tiempo de respuesta y la ventana de contexto. La velocidad y la calidad dependen del modelo y de tu hardware, y un modelo más pequeño puede cometer más errores en un archivo de configuración largo, así que lee cada diff con cuidado. Esta ruta es adecuada para notas y registros que no deseas enviar a ningún proveedor, por ejemplo, una copia de una configuración de correo que contenga nombres privados.
Modelo integrado
El modelo integrado está listo para usar sin un endpoint propio, así que no hay nada que ingresar antes de la primera tarea. Escógelo cuando quieras ver las tarjetas, los diffs y los modos de aprobación antes de conectar cualquier otra cosa. Puedes cambiar a un modelo en la nube o local más adelante si una tarea requiere uno más potente. La calidad varía según la tarea, así que lee cada tarjeta de resultado y cada diff antes de aceptarlo, y prueba el resultado en tu servidor desde una segunda sesión.
Qué verifica el botón Probar
El botón Probar verifica un endpoint y luego muestra el tiempo de respuesta y la ventana de contexto. Ejecútalo después de ingresar un endpoint en la nube o local, antes de darle al agente una tarea de servidor. La ventana de contexto te dice cuánto texto cabe en una sola solicitud, lo cual es importante cuando pegas un registro largo o un archivo de configuración. Si la prueba falla, verifica la dirección del endpoint y la clave, corrígelos y ejecuta la prueba nuevamente antes de iniciar la tarea.
Elige un modelo para la tarea
Usa un modelo más grande para pasos complejos, como leer un registro largo o planificar un cambio en el firewall, y un modelo más pequeño para ediciones pequeñas, como una línea en un archivo de configuración copiado. La herramienta run_on_model envía un paso complejo a un modelo más grande mientras el resto del chat permanece en tu modelo predeterminado. La herramienta task divide verificaciones independientes, como el espacio en disco y el estado del servicio, entre sub-agentes en paralelo. Cron ejecuta un prompt guardado en un horario programado, y los planes sobreviven a los reinicios, por lo que un trabajo largo puede continuar después de cerrar la aplicación.
La calidad varía entre modelos, y cualquier modelo puede malinterpretar un registro o sugerir una configuración incorrecta. Lee el diff antes de aceptarlo. Ask first hace una pausa antes de las acciones que cambian algo, Plan only escribe un plan y no ejecuta nada, y Auto-run actúa de inmediato, así que ajusta el modo al riesgo del cambio. Prueba el resultado tú mismo, por ejemplo, iniciando sesión desde una segunda sesión.
