Un agente local para el trabajo de conocimiento privado y rentable

Perplexity Portable Computer es un agente local por diseño.

Todo el stack se ejecuta localmente de forma predeterminada. El modelo, el marco de trabajo (harness), la conversación y la trayectoria residen en la máquina del usuario. El trabajo que requiere el mundo exterior, como la búsqueda web, los conectores o la escalada a un modelo asesor más potente en la nube, se invoca solo cuando es necesario y siempre bajo el control del usuario. Por lo tanto, los datos confidenciales nunca abandonan el dispositivo sin permiso, y los modelos locales no conllevan tarifas de inferencia: el sistema es privado y rentable por diseño.

Un agente local eficaz requiere que el modelo y el marco de trabajo (harness) se diseñen conjuntamente. Los marcos de trabajo de uso general presuponen la existencia de un modelo de frontera capaz de absorber contextos largos, navegar por una amplia superficie de herramientas y planificar a largo plazo. Los modelos locales son menos fiables ante esas demandas. En lugar de pedir a un modelo pequeño que gestione un marco diseñado para uno grande, adaptamos ambos entre sí: un marco de trabajo adaptado al perfil de capacidades del modelo y un modelo post-entrenado para utilizar ese marco de forma eficaz.

Introducción

En los últimos meses, las capacidades agénticas han avanzado rápidamente en una amplia gama de tareas de trabajo de conocimiento. Si bien estos avances aportan importantes mejoras en productividad y eficiencia, también plantean dos desafíos.

El consumo de tokens está aumentando rápidamente y, con él, el gasto total. Cuando se accede a la inteligencia a través de las API de modelos de código cerrado que se ejecutan en clústeres remotos, la información privada y la propiedad intelectual abandonan el dispositivo del usuario con cada solicitud. A medida que los agentes se escalan en los flujos de trabajo individuales y en organizaciones enteras, el gasto de tokens y el movimiento de datos se vuelven cada vez más difíciles de gobernar.

Al mismo tiempo, los modelos de código abierto han mejorado a un ritmo aún mayor. El progreso es más visible en modelos muy pequeños y eficientes como NVIDIA Nemotron 3.5 Lightning (30B de parámetros totales), Qwen 3.6 (35B) y Qwen 3.8 (27B). Estos modelos pequeños superan sus expectativas y ahora son capaces de realizar flujos de trabajo agénticos complejos. El hardware de inferencia local avanza en paralelo: sistemas como NVIDIA DGX Spark ahora pueden ejecutar estos modelos localmente. En conjunto, estas tendencias hacen que la operación totalmente en el dispositivo sea práctica, al tiempo que permiten a los usuarios optar por capacidades externas cuando sea necesario, como búsqueda web, conectores o escalamiento a modelos en la nube.

Este enfoque local permite un ahorro de costos significativo, ya que la inferencia local evita las tarifas de API por token. También resuelve de forma natural las preocupaciones sobre privacidad y propiedad intelectual: los tokens privados nunca necesitan transmitirse a clústeres remotos y permanecen seguros dentro de los límites del dispositivo local.

En junio, presentamos el primer orquestador de inferencia híbrido local-servidor que decide qué trabajo debe ejecutarse en el dispositivo y qué trabajo debe enviarse a los agentes en la nube. Aquí explicamos cómo construimos dicho agente local, incluido el marco de trabajo y los modelos optimizados conjuntamente.

Ofrecemos una visión general de las opciones de diseño clave, evaluamos Computer frente a los populares marcos de trabajo de código abierto de uso general (Hermes y Pi) en tres benchmarks públicos y en nuestro Local Knowledge Work Bench interno. En nuestro benchmark, con el modelo Qwen 3.8 27B ejecutándose en un NVIDIA DGX Spark, Computer alcanza la puntuación más alta, 82,6% frente al 77,6% de Pi y el 74,0% de Hermes. PPLX 27B, nuestro modelo post-entrenado sobre Qwen 3.8 27B, eleva aún más la puntuación hasta el 85,4%.

Diseñar el marco de trabajo en torno al modelo local

Aunque los modelos compactos en el dispositivo ya son bastante capaces, todavía están por detrás de los modelos de frontera más grandes en cuanto a rendimiento. Se necesita un marco de trabajo cuidadosamente diseñado para guiar estos modelos de manera efectiva y abordar sus limitaciones.

Los marcos de trabajo de código abierto populares como Pi y Hermes han demostrado ser generales: funcionan bien con una amplia variedad de modelos de diferentes tamaños y clases. Sin embargo, no están optimizados para las capacidades de los modelos en el dispositivo. Diseñamos el marco local específicamente para este entorno, basándonos en unos pocos principios clave.

Eficiencia de contexto

El enfoque principal al diseñar nuestro marco de trabajo fue aprovechar al máximo el contexto del modelo.

Aunque los modelos en el dispositivo como Qwen 3.8 27B ofrecen ventanas de contexto de 260K tokens, descubrimos empíricamente que empiezan a tener dificultades más allá de los 100K tokens. Por lo tanto, mantenemos el marco central conciso: un indicador (prompt) de sistema mínimo y un conjunto reducido de herramientas principales.

Todas las demás capacidades se modularizan en habilidades (skills) bajo demanda que se cargan y descargan a lo largo de la trayectoria. Diseñamos estas habilidades para tareas comunes de trabajo de conocimiento: investigación, ciencia de datos, visualización de datos, creación de documentos, ingeniería de software y más.

El marco de trabajo también admite la compactación de contexto, resumiendo el contexto obsoleto cuando una trayectoria se alarga para que el modelo permanezca dentro de su ventana efectiva.

Conectores como herramientas de línea de comandos

El trabajo de conocimiento diario a menudo requiere conectores como Gmail, GitHub, Outlook y Google Calendar. Estos suelen exponerse a un marco de trabajo como servidores MCP, cuyas grandes definiciones de herramientas consumen una parte sustancial del contexto. En su lugar, convertimos los MCP más utilizados en herramientas de línea de comandos compactas y fáciles de usar, complementadas con habilidades personalizadas que hacen un uso mucho mejor del contexto efectivo limitado.

Autoverificación

El rendimiento también mejora cuando el agente verifica su propio trabajo. La verificación añade pasos adicionales, pero mejora enormemente los resultados finales y reduce sustancialmente la brecha con los modelos de frontera. Puede ser activada por el propio modelo o por un conjunto de ganchos (hooks) que supervisan la salud de la trayectoria y solicitan la autoverificación cuando algo sale mal.

Ejecución en entorno aislado (sandbox)

El marco de trabajo ejecuta herramientas en un entorno aislado a nivel de SO en el dispositivo del usuario. El límite restringe los procesos, las rutas del sistema de archivos y el acceso a la red según la política. Esto limita el radio de impacto de un comando erróneo. Si el entorno aislado no está disponible, el marco de trabajo se desactiva antes de realizar cualquier llamada a herramientas en lugar de degradarse a una ejecución sin aislamiento.

Esto difiere de los marcos de código abierto como Pi y Hermes, que ejecutan comandos directamente con los permisos del usuario de forma predeterminada. En Computer, el aislamiento está siempre activado, no requiere configuración y las herramientas no pueden ejecutarse sin él.

El siguiente diagrama muestra cómo se integran estos principios en el bucle de ejecución. El orquestador es código de marco determinista, no un LLM: mantiene el bucle, ensambla el contexto y hace cumplir las políticas. El modelo local propone la próxima acción; el orquestador ejecuta las llamadas a herramientas aprobadas en el entorno aislado y devuelve sus resultados al modelo. La búsqueda web, los conectores y las llamadas a asesores cruzan el límite del dispositivo solo cuando están habilitadas y aprobadas.

Un marco local saca más partido al mismo modelo

Utilizando el mismo modelo base en el dispositivo, comparamos nuestro marco local con alternativas de uso general en investigación web y comprensión de documentos multimodales. Todos los marcos utilizan el modelo Qwen 3.8 27B con razonamiento medio, ejecutándose en un NVIDIA DGX Spark. Esta comparación aísla las capacidades aportadas por el propio marco de trabajo, antes de cualquier post-entrenamiento del modelo.

Nos centramos en estas dos capacidades porque el trabajo de conocimiento a menudo combina documentos privados en el dispositivo del usuario con información pública de la web para producir un artefacto fundamentado. La búsqueda web requiere conectividad, pero la inferencia del modelo y el procesamiento de documentos privados siguen siendo locales. Los archivos locales sirven como fuente autorizada, las fuentes públicas añaden contexto y los usuarios pueden deshabilitar por completo la búsqueda web para trabajar totalmente sin conexión.

Investigación web

Construimos nuestro marco local junto con el motor de búsqueda de Perplexity, que ha alcanzado los primeros puestos en evaluaciones independientes. El marco accede a él a través de la interfaz Search as Code.

Evaluamos la calidad de la investigación en 1.266 tareas de BrowseComp. Computer utiliza la infraestructura de búsqueda de Perplexity junto con nuestro marco local, mientras que Pi y Hermes confían en Brave, su proveedor de búsqueda recomendado. Computer alcanza una precisión del 66,7%, en comparación con el 50,2% de Pi y el 43,9% de Hermes.

Computer también tiene el tiempo de pared y el uso de tokens medio más bajos registrados: 402,1 segundos y 852k tokens por tarea, en comparación con los 1.020,9 segundos y 1,01 millones de tokens de Hermes, y los 826,0 segundos y 2,82 millones de tokens de Pi. Por lo tanto, Computer utiliza un 61% menos de tiempo de pared y un 16% menos de tokens que Hermes, y un 51% menos de tiempo de pared y un 70% menos de tokens que Pi.

Comprensión de documentos multimodales en el dispositivo

Muchos documentos contienen información visual y son difíciles de analizar como texto plano: archivos PDF, páginas escaneadas, capturas de pantalla, gráficos y presentaciones. Estos flujos de trabajo dependen del OCR y de la comprensión de imágenes, y se benefician enormemente de un modelo nativamente multimodal.

El marco de trabajo pasa las páginas de los documentos y las imágenes directamente al modelo, que las comprende y combina la evidencia visual con el texto extraído. El procesamiento de estos archivos en el dispositivo mantiene los documentos confidenciales y su contenido extraído en privado.

Evaluamos la comprensión de documentos multimodales en ParseBench-100, un subconjunto de 100 tareas del benchmark ParseBench, con 20 tareas cada uno para gráficos, diseño (layout), tablas, contenido de texto y formato.

Computer alcanza una puntuación media del 65,1%, en comparación con el 34,6% de Hermes y el 13,9% de Pi. También completa las tareas con el menor tiempo y la menor cantidad de tokens: una media de 60,6 segundos y 20,1k tokens por tarea, frente a los 108,3 segundos y 32,1k tokens de Hermes, y los 410,5 segundos y 829,1k tokens de Pi. Computer lidera en las cinco categorías de documentos, con su mayor ventaja en gráficos. El diseño (layout) sigue siendo difícil para los tres marcos.

Tabla 1. Puntuación media de ParseBench-100 por categoría de documento para los marcos Computer, Hermes y Pi con el modelo Qwen 3.8 27B en el dispositivo. Computer lidera en las cinco categorías.

Reduciendo la brecha con la frontera mediante la escalada a asesores

Incluso con un marco cuidadosamente diseñado, las tareas más difíciles siguen superando las capacidades de un modelo compacto en el dispositivo. Para dichas tareas, el marco expone una herramienta de asesoramiento: el modelo local puede consultar a un modelo de frontera más potente cuando necesita ayuda con la planificación, la resolución de ambigüedades, la recuperación de fallos repetidos o la verificación del resultado final.

El modelo local decide cuándo solicitar asesoramiento, mientras que el orquestador del marco de trabajo conserva la autoridad sobre las herramientas y controla qué contexto se envía. La escalada es opcional. El usuario decide si desea habilitarla y si desea aprobar cada llamada al asesor de forma manual o automática.

Antes de una llamada al asesor, el marco de trabajo selecciona el contexto relevante, aplica un clasificador de PII para marcar la información confidencial y muestra al usuario qué saldría del dispositivo. El asesor recibe solo el contexto aprobado y devuelve orientación en texto; no tiene acceso directo a los archivos, herramientas o conversaciones del dispositivo. Esto mejora tanto el coste como la privacidad, y planeamos explorar más a fondo esta dirección en futuros trabajos.

Probamos este enfoque en tareas desafiantes de ingeniería de software, que exigen un fuerte razonamiento y son aquellas en las que un modelo local suele quedarse corto. Para ello, utilizamos Terminal Bench 2.1, un popular benchmark de 89 tareas para agentes de programación.

Queremos responder a dos preguntas: cuánta brecha con respecto a un modelo de frontera puede cerrar la escalada a asesores y a qué costo. Los modelos totalmente locales no cuestan prácticamente nada de ejecutar, ya que la inferencia ocurre en el hardware del usuario. Sin embargo, una vez que el modelo comienza a llamar al asesor, empieza a incurrir en costos de API.

Como línea base para el rendimiento de la frontera, utilizamos Claude Opus 5 operando en el marco local; el modelo local es Qwen 3.8 27B. Por último, combinamos ambos: Qwen 3.8 27B ejecuta la tarea y escala a un asesor Claude Opus 5 cuando necesita ayuda. No evaluamos la escalada a asesores con Pi o Hermes porque ninguno proporciona una herramienta asesora equivalente; añadir una requeriría modificar su superficie de herramientas y su lógica de orquestación, por lo que el resultado ya no representaría el marco listo para usar.

La escalada a asesores eleva la puntuación de Computer del 59,6% al 73,0%, una ganancia de 13,5 puntos porcentuales, con un costo de API estimado de 0,415 dólares por ejecución. Ejecutar Claude Opus 5 por sí solo alcanza el 82,4% a 0,65 dólares por ejecución. Por lo tanto, la escalada recupera aproximadamente tres quintas partes de la brecha con la frontera aproximadamente a dos terceras partes del costo de la misma, y el usuario decide cuándo vale la pena hacer ese intercambio.

Post-entrenamiento para el marco de trabajo y el trabajo de conocimiento

Hasta ahora, hemos mantenido el modelo local sin cambios para aislar lo que aporta el marco de trabajo. Una vez establecido el diseño del marco, las mayores ganancias restantes provienen de adaptar el propio modelo. Los datos de uso de Perplexity Computer nos muestran lo que la gente realmente hace en su trabajo de conocimiento, los cuales utilizamos para sintetizar datos de entrenamiento. Post-entrenamos el modelo local dentro del marco de Computer, guiados por la distribución real de las tareas que realizan los usuarios.

Concretamente, identificamos un conjunto diverso de casos de uso que ejercitan diferentes capacidades del modelo, herramientas y conectores. A partir de estos casos de uso, sintetizamos entornos de aprendizaje por refuerzo realistas y definimos tareas desafiantes pero verificables: cada tarea consta de una instrucción, un entorno y un verificador que califica el resultado final, donde el entorno es un contenedor Docker en el que opera el marco de trabajo. Es importante destacar que, dado que las tareas son sintéticas, no contienen documentos reales ni información de usuarios.

Utilizamos estos entornos para el entrenamiento en dos etapas: ajuste fino por rechazo seguido de aprendizaje por refuerzo. En la primera etapa, ejecutamos el modelo frente a cada tarea varias veces, seleccionamos las mejores trayectorias según la puntuación del verificador y entrenamos con ellas mediante aprendizaje supervisado. Esta etapa inicializa el modelo para el marco de trabajo específico y la distribución de tareas. En la segunda etapa, el aprendizaje por refuerzo ajusta aún más el modelo, haciéndolo más robusto.

Un subconjunto de tareas se reserva del entrenamiento y se utiliza para la evaluación final; llamamos a este conjunto reservado Local Knowledge Work Bench: 53 tareas que abarcan siete categorías de trabajo de conocimiento diario, desde investigación profunda hasta la creación de documentos. Pronto publicaremos un informe técnico que describe en detalle el entrenamiento del modelo, y planeamos abrir el código de este benchmark de evaluación.

Post-entrenamos Qwen 3.8 27B con este enfoque, produciendo un modelo que llamamos PPLX 27B, y lo evaluamos en el Local Knowledge Work Bench. Con el modelo base Qwen 3.8 27B, Computer alcanza la puntuación más alta (82,6%, en comparación con el 77,6% de Pi y el 74,0% de Hermes) y utiliza la menor cantidad de tokens (520k, frente a 681k para Pi y 634k para Hermes). Pi completa las tareas más rápido, a 176 segundos por tarea, en comparación con los 218 segundos de Computer y los 292 segundos de Hermes. PPLX 27B eleva la puntuación de Computer al 85,4%, a costa de más tokens (678k frente a 520k). Su tiempo de pared estimado es de 250 segundos.

Tabla 2. Categorías de tareas del Local Knowledge Work Bench.

Conclusión

Nuestra investigación demuestra que un modelo de código abierto sólido, con hardware local capaz y un marco de trabajo diseñado para ellos, puede gestionar el trabajo de conocimiento real a un coste de inferencia casi nulo sin necesidad de que los datos confidenciales abandonen el dispositivo.

En los distintos benchmarks, Computer igualó o superó a Hermes y Pi en precisión al ejecutar Qwen 3.8 27B en un NVIDIA DGX Spark. Entre los tres benchmarks que informan sobre la latencia y el uso de tokens, Computer fue el más rápido en BrowseComp y ParseBench-100 y utilizó la menor cantidad de tokens en los tres; Pi fue el más rápido en el Local Knowledge Work Bench.

Las ganancias provienen de las decisiones que tomamos. Construimos un marco de trabajo local conciso con habilidades que se cargan bajo demanda. Convertimos los conectores en herramientas CLI compactas en lugar de servidores MCP. La ejecución se aisló en un entorno seguro por motivos de seguridad.

Los resultados también muestran dónde los modelos compactos tienen margen de mejora. Por ejemplo, en las desafiantes tareas de programación de Terminal Bench 2.1, el modelo local va por detrás del modelo de frontera en los tres marcos. La escalada a asesores reduce pero no cierra por completo la brecha; todavía se necesitan mejoras continuas en las capacidades de los modelos y en el hardware local para impulsar aún más el rendimiento.

El propósito de construir el marco de trabajo y el modelo para restricciones locales es dar a los usuarios un control explícito sobre qué información abandona sus máquinas. También hay beneficios de coste para el usuario. Consideramos esto parte de un cambio más amplio en el cual agentes cada vez más capaces se desplazan desde la infraestructura remota hacia dispositivos individuales y locales. Esperamos que los avances en chips, modelos y dispositivos amplíen continuamente el abanico de tareas de conocimiento que Portable Computer puede manejar localmente.