Defina o destino dos seus prompts antes de conectar um modelo

O Portward funciona com três tipos de modelo: um provedor de IA na nuvem via endpoint de API padrão, um modelo que roda localmente no seu PC e o modelo integrado. Cada escolha define para onde seus prompts vão, então decida antes de direcionar o agente para um servidor.

Três formas de conectar um modelo

Provedor de IA na nuvem

Um provedor de nuvem se conecta por meio de um endpoint de API padrão, que você insere nas configurações junto com sua própria chave de API. O Portward envia seus prompts para esse endpoint, e um prompt pode incluir o texto de qualquer arquivo ou log lido pelo agente, então um modelo na nuvem recebe esse texto. Seus chats, pastas de trabalho e chaves de API permanecem no seu PC, e segredos na saída das ferramentas são ocultados antes de chegarem ao modelo. Essa rota é comum para logs longos e arquivos de configuração grandes, porque o modelo não é limitado pelo seu hardware. Leia os termos do próprio provedor para ver como ele trata os prompts e pressione o botão Testar após inserir o endpoint.

Modelo no seu PC

Um modelo que roda localmente no seu PC mantém tudo na máquina: com um modelo local, nada sai dele. Você conecta o Portward ao endpoint local, e o botão Testar mostra o tempo de resposta e a janela de contexto. Velocidade e qualidade dependem do modelo e do seu hardware, e um modelo menor pode cometer mais erros em um arquivo de configuração longo, então leia cada diff com cuidado. Essa rota é ideal para notas e logs que você não deseja enviar a nenhum provedor, por exemplo, uma cópia de uma configuração de e-mail que contenha nomes privados.

Modelo integrado

O modelo integrado está pronto para uso sem precisar de um endpoint próprio, então não há nada para inserir antes da primeira tarefa. Escolha-o quando quiser analisar os cartões, os diffs e os modos de aprovação antes de conectar qualquer outra coisa. Você pode mudar para um modelo na nuvem ou local depois, se uma tarefa exigir um modelo maior. A qualidade varia de tarefa para tarefa, então leia cada cartão de resultado e cada diff antes de aceitá-los, e teste o resultado no seu servidor a partir de uma segunda sessão.

O que o botão Testar verifica

O botão Testar verifica um endpoint e mostra o tempo de resposta e a janela de contexto. Execute-o após inserir um endpoint na nuvem ou local, antes de dar ao agente uma tarefa de servidor. A janela de contexto indica quanto texto cabe em uma única solicitação, o que é importante quando você cola um log longo ou um arquivo de configuração. Se o teste falhar, verifique o endereço do endpoint e a chave, corrija-os e execute o teste novamente antes de iniciar a tarefa.

Escolha um modelo para a tarefa

Use um modelo maior para etapas complexas, como ler um log longo ou planejar uma alteração no firewall, e um modelo menor para edições simples, como uma linha em um arquivo de configuração copiado. A ferramenta run_on_model envia uma etapa complexa para um modelo maior, enquanto o restante do chat permanece no modelo padrão. A ferramenta task divide verificações independentes, como espaço em disco e status do serviço, entre sub-agentes paralelos. O cron executa um prompt salvo em um agendamento, e os planos sobrevivem a reinicializações, então um trabalho longo pode continuar após fechar o aplicativo.

A qualidade varia entre os modelos, e qualquer modelo pode interpretar mal um log ou sugerir uma configuração errada. Leia o diff antes de aceitá-lo. Ask first pausa antes de ações que alteram algo, Plan only escreve um plano e não executa nada, e Auto-run age imediatamente, então ajuste o modo ao risco da alteração. Teste o resultado você mesmo, por exemplo, fazendo login a partir de uma segunda sessão.