Um agente centrado em local para trabalho de conhecimento privado e econômico

O Perplexity Portable Computer é um agente centrado em local.

Todo o pilha roda localmente por padrão. O modelo, o harness, a conversa e a trajetória residem na máquina do usuário. O trabalho que necessita do mundo exterior, como busca na web, conectores ou escalonamento para um modelo orientador mais forte na nuvem, é invocado apenas quando necessário e sempre controlado pelo usuário. Portanto, os dados confidenciais nunca deixam o dispositivo sem permissão, e os modelos locais não acarretam taxa de inferência: o sistema é privado e econômico por construção.

Um agente centrado em local eficaz requer que o modelo e o harness sejam projetados em conjunto. Harnesses de propósito geral assumem um modelo de fronteira capaz de absorver contextos longos, navegar por uma ampla superfície de ferramentas e planejar ao longo de horizontes estendidos. Modelos locais são menos confiáveis sob tais exigências. Em vez de pedir a um modelo pequeno que gerencie um harness construído para um grande, moldamos ambos em torno um do outro: um harness adaptado ao perfil de capacidade do modelo e um modelo pós-treinado para usar esse harness de forma eficaz.

Introdução

As capacidades de agentes avançaram rapidamente nos últimos meses em uma ampla gama de tarefas de trabalho de conhecimento. Embora esses avanços tragam grandes ganhos de produtividade e eficiência, eles também apresentam dois desafios.

O consumo de tokens está crescendo rapidamente e, com ele, o gasto geral. Quando a inteligência é acessada por meio das APIs de modelos de código fechado executados em clusters remotos, informações privadas e propriedade intelectual deixam o dispositivo do usuário a cada requisição. Conforme os agentes escalam em fluxos de trabalho individuais e organizações inteiras, o gasto de tokens e a movimentação de dados tornam-se cada vez mais difíceis de governar.

Ao mesmo tempo, os modelos de código aberto melhoraram a uma taxa ainda mais rápida. O progresso é mais visível em modelos muito pequenos e eficientes, como NVIDIA Nemotron 3.5 Lightning (30B de parâmetros no total), Qwen 3.6 (35B) e Qwen 3.8 (27B). Esses modelos pequenos superam suas expectativas e agora são capazes de fluxos de trabalho baseados em agentes complexos. O hardware de inferência local está avançando em paralelo: sistemas como o NVIDIA DGX Spark agora podem executar esses modelos localmente. Juntas, essas tendências tornam a operação totalmente no dispositivo prática, permitindo que os usuários optem por capacidades externas quando necessário, como busca na web, conectores ou escalonamento para modelos em nuvem.

Esta abordagem centrada em local permite economias de custo significativas, uma vez que a inferência local evita taxas de API por token. Ela também resolve naturalmente as preocupações de privacidade e propriedade intelectual: tokens privados nunca precisam ser transmitidos para clusters remotos e permanecem seguros dentro dos limites do dispositivo local.

Em junho, apresentamos o primeiro orquestrador de inferência híbrida local-servidor que decide qual trabalho deve ser executado no dispositivo e qual trabalho deve ir para os agentes na nuvem. Aqui, explicamos como construímos esse agente centrado em local, incluindo o harness e os modelos co-otimizados entre si.

Damos uma visão geral das principais escolhas de design, avaliamos o Computer em relação a harnesses de código aberto de uso geral populares (Hermes e Pi) em três benchmarks públicos e nosso Local Knowledge Work Bench interno. Em nosso benchmark, com o modelo Qwen 3.8 27B rodando em um NVIDIA DGX Spark, o Computer alcança a pontuação mais alta, 82,6% versus 77,6% para o Pi e 74,0% para o Hermes. O PPLX 27B, nosso modelo pós-treinado sobre o Qwen 3.8 27B, eleva ainda mais a pontuação para 85,4%.

Projetar o harness em torno do modelo local

Embora modelos compactos no dispositivo já sejam bastante capazes, eles ainda ficam atrás de modelos de fronteira maiores em desempenho. Um harness cuidadosamente projetado é necessário para guiar esses modelos de forma eficaz e abordar suas limitações.

Harnesses de código aberto populares como Pi e Hermes provaram ser gerais: funcionam bem com uma grande variedade de modelos em vários tamanhos e classes. Mas eles não são otimizados para as capacidades de modelos no dispositivo. Projetamos o harness local especificamente para este cenário, em torno de alguns princípios-chave.

Eficiência de contexto

O foco principal no design do nosso harness foi fazer o melhor uso do contexto do modelo.

Embora modelos no dispositivo, como o Qwen 3.8 27B, ofereçam janelas de contexto de 260 mil tokens, descobrimos empiricamente que eles começam a ter dificuldades além de 100 mil tokens. Portanto, mantemos o harness principal sucinto: um prompt de sistema mínimo e um pequeno conjunto de ferramentas principais.

Todas as outras capacidades são modularizadas em Skills sob demanda que são carregadas e descarregadas ao longo da trajetória. Projetamos essas Skills para tarefas comuns de trabalho de conhecimento: pesquisa, ciência de dados, visualização de dados, criação de documentos, engenharia de software e muito mais.

O harness também suporta compactação de contexto, resumindo o contexto obsoleto quando uma trajetória se torna longa para que o modelo permaneça dentro de sua janela efetiva.

Conectores como ferramentas de linha de comando

O trabalho de conhecimento diário frequentemente requer conectores como Gmail, GitHub, Outlook e Google Calendar. Estes são geralmente expostos a um harness como servidores MCP, cujas grandes definições de ferramentas consomem uma parcela substancial do contexto. Em vez disso, convertemos os MCPs mais usados em ferramentas de linha de comando compactas e fáceis de usar, complementadas por Skills personalizadas que fazem um uso muito melhor do contexto efetivo limitado.

Autoverificação

O desempenho também melhora quando o agente verifica seu próprio trabalho. A verificação adiciona etapas extras, mas melhora muito os resultados finais e reduz substancialmente a lacuna em relação aos modelos de fronteira. Pode ser acionada pelo próprio modelo ou por um conjunto de ganchos que monitoram a integridade da trajetória e solicitam a autoverificação quando algo dá errado.

Execução em sandbox

O harness executa ferramentas em um sandbox em nível de sistema operacional no dispositivo do usuário. A fronteira restringe processos, caminhos do sistema de arquivos e acesso à rede de acordo com a política. Isso limita o raio de explosão de um comando incorreto. Se o sandbox estiver indisponível, o harness se desativa antes de qualquer chamada de ferramenta, em vez de se degradar para uma execução sem sandbox.

Isso difere de harnesses de código aberto como Pi e Hermes, que executam comandos diretamente com as permissões do usuário por padrão. No Computer, o isolamento está sempre ativado, não requer configuração e as ferramentas não podem ser executadas sem ele.

O diagrama abaixo mostra como esses princípios se encaixam no loop de execução. O orquestrador é um código de harness determinístico, não um LLM: ele mantém o loop, monta o contexto e impõe políticas. O modelo local propõe a próxima ação; o orquestrador executa chamadas de ferramentas aprovadas no sandbox e retorna seus resultados para o modelo. Busca na web, conectores e chamadas de consultores cruzam a fronteira do dispositivo apenas quando habilitados e aprovados.

Um harness local extrai mais do mesmo modelo

Usando o mesmo modelo base no dispositivo, comparamos nosso harness local com alternativas de uso geral em pesquisa na web e compreensão de documentos multimodal. Todos os harnesses usam o modelo Qwen 3.8 27B com raciocínio médio, rodando em um NVIDIA DGX Spark. Esta comparação isola as capacidades trazidas pelo próprio modelo de harness, antes de qualquer pós-treinamento do modelo.

Focamos nessas duas capacidades porque o trabalho de conhecimento frequentemente combina documentos privados no dispositivo do usuário com informações públicas da web para produzir um artefato fundamentado. A busca na web requer conectividade, mas a inferência do modelo e o processamento de documentos privados permanecem locais. Arquivos locais servem como fonte autorizada, fontes públicas adicionam contexto e os usuários podem desativar completamente a busca na web para trabalhos totalmente offline.

Pesquisa na web

Construímos nosso harness local junto com o mecanismo de busca da Perplexity, que alcançou as principais classificações em avaliações independentes. O harness o acessa através da interface Search as Code.

Avaliamos a qualidade da pesquisa em 1.266 tarefas do BrowseComp. O Computer usa a infraestrutura de busca da Perplexity junto com nosso harness local, enquanto Pi e Hermes dependem do Brave, seu provedor de busca recomendado. O Computer atinge 66,7% de precisão, comparado com 50,2% para o Pi e 43,9% para o Hermes.

O Computer também tem o menor tempo médio de parede registrado e uso de tokens: 402,1 segundos e 852 mil tokens por tarefa, comparado com 1.020,9 segundos e 1,01 milhão de tokens para o Hermes, e 826,0 segundos e 2,82 milhões de tokens para o Pi. Portanto, o Computer usa 61% menos tempo de parede e 16% menos tokens do que o Hermes, e 51% menos tempo de parede e 70% menos tokens do que o Pi.

Compreensão de documentos multimodal no dispositivo

Muitos documentos contêm informações visualmente e são difíceis de analisar como texto simples: PDFs, páginas digitalizadas, capturas de tela, gráficos e apresentações. Esses fluxos de trabalho dependem de OCR e compreensão de imagem, e se beneficiam mais de um modelo nativamente multimodal.

O harness passa páginas de documentos e imagens diretamente para o modelo, que os compreende e combina evidências visuais com o texto extraído. O processamento desses arquivos no dispositivo mantém documentos confidenciais e seu conteúdo extraído privados.

Avaliamos a compreensão de documentos multimodal no ParseBench-100, um subconjunto de 100 tarefas do benchmark ParseBench, com 20 tarefas cada para gráficos, layout, tabelas, conteúdo de texto e formatação.

O Computer atinge uma pontuação média de 65,1%, comparado com 34,6% para o Hermes e 13,9% para o Pi. Ele também conclui tarefas com o menor tempo e o menor número de tokens: em média 60,6 segundos e 20,1 mil tokens por tarefa, comparado com 108,3 segundos e 32,1 mil tokens para o Hermes, e 410,5 segundos e 829,1 mil tokens para o Pi. O Computer lidera em todas as cinco categorias de documentos, com sua maior vantagem em gráficos. O layout continua difícil para os três harnesses.

Tabela 1. Pontuação média do ParseBench-100 por categoria de documento para os harnesses Computer, Hermes e Pi com o modelo Qwen 3.8 27B no dispositivo. O Computer lidera em todas as cinco categorias.

Reduzindo a lacuna de fronteira com o escalonamento de consultor

Mesmo com um harness cuidadosamente projetado, as tarefas mais difíceis ainda excedem as capacidades de um modelo compacto no dispositivo. Para tais tarefas, o harness expõe uma ferramenta de consultor: o modelo local pode consultar um modelo de fronteira mais forte quando precisar de ajuda com planejamento, resolução de ambiguidade, recuperação de falhas repetidas ou verificação do resultado final.

O modelo local decide quando solicitar conselhos, enquanto o orquestrador do harness retém a autoridade de ferramentas e controla qual contexto é enviado. O escalonamento é opcional. O usuário decide se deseja ativá-lo e se deve aprovar cada chamada de consultor manual ou automaticamente.

Antes de uma chamada de consultor, o harness seleciona o contexto relevante, aplica um classificador PII para sinalizar informações confidenciais e mostra ao usuário o que deixaria o dispositivo. O consultor recebe apenas o contexto aprovado e retorna orientação em texto; ele não tem acesso direto aos arquivos, ferramentas ou conversas do dispositivo. Isso melhora tanto o custo quanto a privacidade, e planejamos explorar mais essa direção em trabalhos futuros.

Testamos essa abordagem em tarefas desafiadoras de engenharia de software, que exigem forte raciocínio e são onde um modelo local mais frequentemente fica aquém. Para isso, usamos o Terminal Bench 2.1, um popular benchmark de 89 tarefas para agentes de codificação.

Queremos responder a duas perguntas: quanto da lacuna para um modelo de fronteira o escalonamento de consultor pode fechar e a que custo. Modelos totalmente locais custam praticamente zero para rodar, uma vez que a inferência ocorre no hardware do usuário. No entanto, uma vez que o modelo começa a chamar o consultor, ele passa a incorrer em custos de API.

Como linha de base para o desempenho de fronteira, usamos o Claude Opus 5 operando no harness local; o modelo local é o Qwen 3.8 27B. Por fim, emparelhamos os dois: o Qwen 3.8 27B executa a tarefa e escala para um consultor Claude Opus 5 quando precisa de ajuda. Não avaliamos o escalonamento de consultor com o Pi ou o Hermes porque nenhum deles fornece uma ferramenta de consultor equivalente; adicionar uma exigiria modificar sua superfície de ferramentas e lógica de orquestração, de modo que o resultado não representaria mais o harness padrão.

O escalonamento de consultor eleva a pontuação do Computer de 59,6% para 73,0%, um ganho de 13,5 pontos percentuais, a um custo estimado de API de $0,415 por execução. Executar o Claude Opus 5 sozinho atinge 82,4% a $0,65 por execução. O escalonamento recupera, portanto, cerca de três quintos da lacuna para a fronteira a cerca de dois terços do custo da fronteira, e o usuário decide quando vale a pena fazer essa troca.

Pós-treinamento para o harness e trabalho de conhecimento

Até agora, mantivemos o modelo local inalterado para isolar o que o harness contribui. Com o design do harness em vigor, os maiores ganhos restantes vêm da adaptação do próprio modelo. Os dados de uso do Perplexity Computer nos mostram o que as pessoas realmente fazem para o trabalho de conhecimento, que usamos para sintetizar dados de treinamento. Pós-treinamos o modelo local dentro do harness do Computer, guiados pela distribuição real de tarefas que os usuários executam.

Concretamente, identificamos um conjunto diversificado de casos de uso que exercitam diferentes capacidades de modelo, ferramentas e conectores. A partir desses casos de uso, sintetizamos ambientes de aprendizado por reforço realistas e definimos tarefas desafiadoras, mas verificáveis: cada tarefa consiste em uma instrução, um ambiente e um verificador que pontua o resultado final, onde o ambiente é um contêiner Docker no qual o harness opera. É importante ressaltar que, como as tarefas são sintéticas, elas não contêm documentos reais ou informações de usuários.

Usamos esses ambientes para treinamento em dois estágios: ajuste fino por rejeição seguido por aprendizado por reforço. No primeiro estágio, executamos o modelo em cada tarefa várias vezes, selecionamos as melhores trajetórias por pontuação do verificador e treinamos nelas com aprendizado supervisionado. Este estágio inicializa o modelo para o harness específico e a distribuição de tarefas. No segundo estágio, o aprendizado por reforço ajusta ainda mais o modelo, tornando-o mais robusto.

Um subconjunto de tarefas é mantido fora do treinamento e usado para a avaliação final; chamamos esse conjunto separado de Local Knowledge Work Bench: 53 tarefas abrangendo sete categorias de trabalho de conhecimento diário, desde pesquisa profunda até a criação de documentos. Em breve publicaremos um relatório técnico descrevendo o treinamento do modelo em detalhes, e planejamos abrir o código deste benchmark de avaliação.

Pós-treinamos o Qwen 3.8 27B com esta abordagem, produzindo um modelo que chamamos de PPLX 27B, e o avaliamos no Local Knowledge Work Bench. Com o modelo base Qwen 3.8 27B, o Computer alcança a pontuação mais alta (82,6%, comparado com 77,6% para o Pi e 74,0% para o Hermes) e usa o menor número de tokens (520 mil, versus 681 mil para o Pi e 634 mil para o Hermes). O Pi conclui as tarefas mais rapidamente em 176 segundos por tarefa, comparado com 218 segundos para o Computer e 292 segundos para o Hermes. O PPLX 27B eleva a pontuação do Computer para 85,4%, ao custo de mais tokens (678 mil versus 520 mil). Seu tempo de parede estimado é de 250 segundos.

Tabela 2. Categorias de tarefas do Local Knowledge Work Bench.

Conclusão

Nossa pesquisa mostra que um modelo de código aberto forte, com hardware local capaz e um harness construído para eles, pode lidar com o trabalho de conhecimento real a um custo de inferência próximo de zero, sem exigir que dados confidenciais deixem o dispositivo.

Em vários benchmarks, o Computer igualou ou excedeu o Hermes e o Pi em precisão ao executar o Qwen 3.8 27B em um NVIDIA DGX Spark. Entre os três benchmarks que relatam latência e uso de tokens, o Computer foi o mais rápido no BrowseComp e no ParseBench-100 e usou o menor número de tokens em todos os três; o Pi foi o mais rápido no Local Knowledge Work Bench.

Os ganhos vieram de escolhas que fizemos. Construímos um harness local sucinto com Skills que carregam sob demanda. Convertemos conectores em ferramentas CLI compactas em vez de servidores MCP. A execução foi colocada em sandbox para segurança.

Os resultados também mostram onde os modelos compactos têm margem para melhoria. Por exemplo, nas tarefas de codificação desafiadoras do Terminal Bench 2.1, o modelo local fica atrás do modelo de fronteira em todos os três harnesses. O escalonamento de consultor estreita, mas não fecha completamente, a lacuna; melhorias contínuas nas capacidades dos modelos e no hardware local ainda são necessárias para impulsionar ainda mais o desempenho.

O objetivo de construir o harness e o modelo para restrições locais é dar aos usuários controle explícito sobre quais informações deixam suas máquinas. Também há benefícios de custo para o usuário. Vemos isso como parte de uma mudança mais ampla em que agentes cada vez mais capazes se mudam de infraestrutura remota para dispositivos individuais e locais. Esperamos que os avanços em chips, modelos e dispositivos expandam continuamente a gama de trabalhos de conhecimento que o Portable Computer pode lidar localmente.