Choisissez où envoyer vos invites avant de connecter un modèle
Portward fonctionne avec trois types de modèles : un fournisseur d'IA cloud via une API standard, un modèle s'exécutant localement sur votre PC, et le modèle intégré. Chaque choix détermine où partent vos invites, alors faites-le avant de diriger l'agent vers un serveur.
Trois façons de connecter un modèle
Fournisseur d'IA cloud
Un fournisseur cloud se connecte via une API standard que vous saisissez dans les paramètres avec votre clé API. Portward envoie vos invites à cette API, et une invite peut inclure le texte de n'importe quel fichier ou journal lu par l'agent, donc un modèle cloud reçoit ce texte. Vos conversations, dossiers de travail et clés API restent sur votre PC, et les secrets dans la sortie des outils sont masqués avant d'atteindre le modèle. Cette méthode est courante pour les longs journaux et les gros fichiers de configuration, car le modèle n'est pas limité par votre matériel. Lisez les conditions d'utilisation du fournisseur pour voir comment il traite les invites, et appuyez sur le bouton Test après avoir saisi l'adresse de l'API.
Modèle sur votre PC
Un modèle s'exécutant localement sur votre PC garde tout sur la machine : avec un modèle local, rien ne sort. Vous connectez Portward à l'API locale, et le bouton Test indique le temps de réponse et la fenêtre de contexte. La vitesse et la qualité dépendent du modèle et de votre matériel, et un modèle plus petit peut faire plus d'erreurs sur un long fichier de configuration, alors lisez chaque diff avec soin. Cette méthode convient pour les notes et journaux que vous ne souhaitez pas envoyer à un fournisseur, par exemple une copie d'une configuration de messagerie contenant des noms privés.
Modèle intégré
Le modèle intégré est prêt à l'emploi sans API externe, donc rien à saisir avant la première tâche. Choisissez-le lorsque vous voulez examiner les cartes, les diffs et les modes d'approbation avant de connecter autre chose. Vous pouvez passer à un modèle cloud ou local plus tard si une tâche nécessite un modèle plus puissant. La qualité varie d'une tâche à l'autre, alors lisez chaque carte de résultat et chaque diff avant de les accepter, et testez le résultat sur votre serveur depuis une seconde session.
Ce que vérifie le bouton Test
Le bouton Test vérifie une API, puis affiche le temps de réponse et la fenêtre de contexte. Exécutez-le après avoir saisi une API cloud ou locale, avant de donner une tâche de serveur à l'agent. La fenêtre de contexte indique combien de texte tient dans une seule requête, ce qui est important lorsque vous collez un long journal ou un fichier de configuration. Si le test échoue, vérifiez l'adresse de l'API et la clé, corrigez-les et relancez le test avant de démarrer la tâche.
Choisissez un modèle pour la tâche
Utilisez un modèle plus grand pour les étapes difficiles, comme lire un long journal ou planifier un changement de pare-feu, et un modèle plus petit pour les petites modifications, comme une ligne dans un fichier de configuration copié. L'outil run_on_model envoie une étape difficile à un modèle plus grand tandis que le reste de la conversation reste sur votre modèle par défaut. L'outil task divise les vérifications indépendantes, par exemple l'espace disque et l'état du service, entre des sous-agents parallèles. Cron exécute une invite enregistrée selon un calendrier, et les plans survivent aux redémarrages, donc un travail long peut continuer après la fermeture de l'application.
La qualité varie entre les modèles, et tout modèle peut mal lire un journal ou suggérer un paramètre incorrect. Lisez le diff avant de l'accepter. Ask first fait une pause avant les actions qui modifient quelque chose, Plan only écrit un plan et ne rien exécute, et Auto-run agit immédiatement, alors adaptez le mode au risque du changement. Testez le résultat vous-même, par exemple en vous connectant depuis une seconde session.
