Como agendar um agente de programação no Open WebUI num servidor doméstico

O Open WebUI v0.13.3 pode agendar um agente de programação para trabalhar num terminal e diretório de trabalho selecionados. Comece com uma tarefa que apenas gere um relatório, numa cópia de trabalho descartável: execute um comando de teste conhecido, resuma as falhas e envie o resultado para uma conversa. Este teste verifica o agendador, as permissões e o percurso de entrega antes de dar a uma tarefa recorrente acesso a ficheiros importantes.

Precisa de uma instalação compatível do Open WebUI, de uma integração de terminal acessível que disponibilize o agente pretendido e de um espaço de trabalho acessível. As notas de lançamento da versão v0.13.3 indicam que as execuções agendadas verificam se o terminal e o agente guardados continuam disponíveis. Trate o terminal, o sistema de ficheiros e a ligação ao modelo subjacente como partes separadas da configuração.

O que mudou na versão de novembro?

O editor de automatizações permite selecionar um terminal e um diretório e, em seguida, escolher um agente disponibilizado por esse terminal. O terminal e a pasta configurados são usados na execução agendada. Os resultados das automatizações com agentes são enviados para uma conversa, enquanto outros tipos de automatização podem ter opções de destino diferentes. A versão anterior v0.13.1 introduziu agentes de programação no seletor de modelos quando um terminal ligado os disponibiliza.

Um terminal selecionado pode ser executado no mesmo anfitrião que o Open WebUI ou ser um serviço separado e acessível. O sistema de ficheiros do terminal é o que importa para a tarefa. Um diretório visível no seu computador portátil pode não existir num contentor. Um ficheiro disponível num terminal pode não existir noutro. Verifique o caminho no terminal exato selecionado para a automatização.

Como deve preparar o espaço de trabalho?

Crie uma cópia de trabalho de teste dedicada, idealmente para um repositório pequeno sem segredos de produção. Fixe uma revisão conhecida e inclua na configuração um teste simples que passe e outro que falhe. Para o primeiro relatório, disponibilize a cópia de entrada apenas para leitura, se o executor de testes o permitir. Forneça um local temporário com permissões de escrita para as caches e os registos dos testes. Algumas ferramentas de compilação insistem em escrever na árvore, por isso configure-as para escrever noutro local ou use uma cópia descartável com permissões de escrita.

Se partilhar um repositório entre várias tarefas, crie uma árvore de trabalho por agente ou tarefa. Mantenha as cópias de segurança e o diretório de trabalho separados. Leia por que motivo as cópias de segurança podem falhar com o acesso partilhado antes de conceder a uma tarefa amplas permissões de escrita num servidor de ficheiros.

Como configurar a primeira tarefa agendada?

Abra o editor de automatizações numa versão que inclua a automatização de agentes. Selecione o terminal, o diretório visível a partir desse terminal e, em seguida, o agente. Para o primeiro teste, escolha uma execução única para breve, se a sua instalação disponibilizar essa opção de agendamento. Consulte o agendamento no fuso horário configurado. Defina um limite modesto de tempo de execução ou de etapas, recorrendo aos controlos disponíveis para o seu agente e a sua implementação.

Defina uma entrada, um comando e um formato de resultado concretos para a tarefa. Por exemplo:

Inspecione a cópia de trabalho no diretório selecionado.
Execute uma vez o comando local existente para testes básicos.
Comunique o comando, o código de saída e o primeiro teste que falhou.
Se o comando ou a pasta não estiver disponível, comunique essa falha.
Não instale dependências, não altere o repositório nem contacte serviços externos.

As instruções orientam o agente. Aplique os limites do sistema de ficheiros e da rede separadamente, através do terminal e da configuração do contentor. Confirme que a ausência de uma dependência resulta numa falha clara, e não numa instalação inesperada. A documentação do Open WebUI é o ponto de partida para as definições do terminal e do administrador.

O que deve verificar após a primeira execução?

Abra o chat resultante e verifique a identidade do agente, o caminho de trabalho, o comando de teste, o código de saída e a revisão que foi testada. Compare o resultado com a execução manual do mesmo comando nesse terminal. Uma automatização concluída apenas mostra que o fluxo de trabalho terminou. O relatório continua a precisar de provas de que o teste pretendido foi realmente executado.

Teste deliberadamente um cenário de falha. Aponte uma tarefa de teste para um ficheiro de entrada inexistente e inofensivo ou pare brevemente o terminal descartável e observe o estado resultante. Reponha-o após o teste. Um operador deve conseguir distinguir um agente indisponível, uma pasta inexistente, um teste falhado e um tempo limite do modelo sem ter de ler toda a transcrição do chat. Verifique se a execução legítima seguinte não reutiliza silenciosamente resultados desatualizados.

O alojamento próprio do Open WebUI mantém o código local?

O Open WebUI e o respetivo terminal podem ser autoalojados, enquanto o agente de programação selecionado utiliza um modelo remoto. Determine para onde o agente envia as instruções do sistema, os excertos de ficheiros e os registos de testes. Verifique a configuração do fornecedor antes de ligar um checkout privado. Guarde as credenciais do fornecedor na configuração de segredos designada para o serviço e evite partilhá-las em instruções ou registos.

Comece por um ponto de acesso a um modelo local, caso os seus requisitos proíbam o processamento externo. Verifique o ponto de acesso e a configuração de contingência do agente e, em seguida, confirme eventuais restrições de rede aplicáveis ao terminal. Para saber mais sobre como limitar a exposição, consulte este guia de triagem de vulnerabilidades de IA e segredos.

Como deve uma tarefa que apenas gera relatórios passar a ser um fluxo de trabalho recorrente?

Depois de conseguir interpretar as primeiras execuções bem-sucedidas e falhadas, adicione um agendamento recorrente que não se sobreponha a outra tarefa que utilize o mesmo diretório. Inclua nos relatórios uma data e hora e a revisão do repositório. Mantenha os alertas simples: assinale as falhas que exigem ação e conserve contexto suficiente para as reproduzir. Verifique periodicamente se as credenciais do agente, a conectividade do terminal e o diretório agendado continuam a funcionar após as atualizações.

Se mais tarde permitir alterações, mantenha-as num ramo isolado e exija uma revisão antes de as integrar. Caso contrário, uma nova tentativa do agendador pode duplicar efeitos secundários. É mais fácil repetir uma tarefa de relatório porque esta apenas escreve um resultado, enquanto as atualizações de dependências e os comandos de implementação alteram o estado. Trate essa transição como uma decisão de autorização separada.

Perguntas frequentes

Que versão introduziu as automatizações de agentes?

A funcionalidade relevante está indicada no Open WebUI v0.13.3. A funcionalidade de seleção de agentes da v0.13.1 está relacionada, mas é distinta.

Porque é que o agente não aparece no seletor?

Confirme que o terminal selecionado está acessível e anuncia esse agente, e que a versão instalada e as permissões da conta disponibilizam a funcionalidade.

Posso escolher uma pasta do meu portátil?

Escolha um caminho no terminal onde a tarefa possa realmente ser executada. Se necessário, monte ou copie primeiro para lá o checkout.

O resultado de uma automatização é enviado para um canal?

As notas da v0.13.3 especificam a entrega por chat para as automatizações do agente. Consulte as opções da versão atual antes de utilizar qualquer destino que não seja esse chat.

O que devo fazer se duas execuções se sobrepuserem?

Utilize árvores de trabalho separadas ou escolha um horário e um orçamento de execução que evitem sobreposições. Inspecione qualquer execução que tenha utilizado a revisão errada antes de confiar no respetivo relatório.

Conclusão

Utilize um terminal, um diretório de trabalho dedicado e uma pequena tarefa apenas de relatório para validar todo o processo. Verifique o fornecedor do modelo, teste os casos de sucesso e de falha e mantenha as credenciais de produção fora do terminal. Quando o resultado puder ser repetido, a mesma configuração poderá tratar das verificações recorrentes dos repositórios.