logo
Développement
Rechercher
Comparaison des capacités Web et APP

Comparaison des capacités Web et APP

Aperçu

L'espace de travail GPTBots propose deux modes d'utilisation : le Web (accès via navigateur) et l'APP de bureau (client de bureau macOS/Windows/Linux). Les deux côtés partagent les composants d'interface principaux et l'API back-end, mais il existe une différence fondamentale sur l'endroit où l'Agent s'exécute réellement.

En un mot :

  • Le Web est le cerveau — lancer des conversations, gérer l'espace, consulter les résultats
  • L'APP est les mains et les pieds — exécuter réellement les tâches, manipuler les fichiers, lancer les commandes, se connecter aux messageries instantanées

La distinction en une phrase

Question de l'utilisateur Réponse
Le navigateur seul me suffit-il ? Suffisant pour consulter Work / Search / les flux de travail / les agents / la gestion de l'espace — mais l'exécution réelle des tâches nécessite qu'au moins un nœud APP soit en ligne
L'APP de bureau peut-elle s'utiliser seule, sans le Web ? Oui. L'APP est un espace de travail complet, avec un moteur Agent local
Faut-il que chaque membre de l'équipe installe l'APP ? Non. Dès qu'une seule personne a une APP en ligne, tous les membres de l'équipe peuvent, depuis le Web, envoyer des tâches vers cette APP (le nœud doit être défini sur enterprise)
Où se trouvent les paramètres invisibles sur le Web ? Dans les « Paramètres » de l'APP de bureau — clés de modèle, compétences, outils, tâches planifiées, canaux, sous-agents, mémoire, sécurité d'exécution

Comparaison de la matrice des fonctionnalités

Dimension de capacité 🌐 Web 🖥️ APP
Conversation Work Se connecte au nœud Agent distant via la Gateway Exécution directe par le Sidecar local
Agent Loop Dépend de l'exécution par un nœud distant Boucle autonome locale de 25 tours
Compression du contexte Traitée par le nœud distant Stratégie de compression locale à 5 couches
Système de fichiers ❌ Aucun accès aux fichiers locaux ✅ Lecture/écriture et recherche complètes des fichiers locaux
Exécution en bac à sable ❌ Non pris en charge ✅ Exécution isolée dans une micro-machine virtuelle VirtIO
Outils MCP ❌ Non pris en charge ✅ Trois transports : stdio / SSE / HTTP
Compétences (Skills) ❌ Compétences locales non prises en charge ✅ 21 préconfigurées + personnalisées + compétences d'entreprise
Canaux (IM) ❌ Configuration non prise en charge ✅ Plus de 14 plateformes (Telegram, WhatsApp, DingTalk, etc.)
Tâches planifiées ❌ Non pris en charge ✅ Ponctuelle / périodique / Cron
Sous-agents Dépend du nœud distant ✅ Création locale + envoi inter-nœuds
Gestion de la mémoire ✅ Mémoire d'entreprise (interface administrateur) ✅ Toutes dimensions : compte + entreprise + session
Configuration des modèles ❌ Configuration locale non prise en charge ✅ Gestion des clés API multi-fournisseurs
Panneau de paramètres Aucun (les fonctions correspondantes se trouvent dans la gestion de l'espace) ✅ Paramètres complets
AI Search ✅ Pris en charge ✅ Pris en charge
Agent ✅ Gestion des agents A2A + conversation ✅ Gestion des agents A2A + conversation
Workflow ✅ Liste des flux de travail + détails + exécution ✅ Liste des flux de travail + détails + exécution
Gestion de l'espace ✅ Fonctions d'administration complètes ✅ Accessible via une fenêtre intégrée
Aperçu multimodal ✅ Aperçu de 9 types de fichiers ✅ Aperçu de 9 types de fichiers

Différences d'architecture

Web : modèle de connexion via Gateway

Navigateur ──WebSocket──► Gateway ──WebSocket──► Nœud APP distant │ Routage intelligent (LLM → BM25 → repli)
                      
                      Navigateur ──WebSocket──► Gateway ──WebSocket──► Nœud APP distant
                        │
                    Routage intelligent
                 (LLM BM25 → repli)

                    
Ce bloc de code dans la fenêtre flottante
  • Le Web lui-même n'exécute pas de moteur Agent (Agent Engine)
  • Toute exécution de conversation dépend d'au moins un nœud APP distant en ligne
  • La Gateway se charge de la découverte des nœuds, du routage intelligent et du transfert des messages
  • Adapté à : la consultation légère, la gestion de l'espace, le lancement de tâches à distance

APP : modèle local à trois processus

Interface React ──IPC──► Tauri Rust ──stdio──► Sidecar Node.js (Agent Engine)
                      
                      Interface React ──IPC──► Tauri Rust ──stdio──► Sidecar Node.js (Agent Engine)

                    
Ce bloc de code dans la fenêtre flottante
  • L'APP exécute localement un moteur Agent complet (processus Sidecar)
  • Dispose d'un accès complet au système de fichiers local
  • Peut être enregistrée comme nœud Gateway, appelable à distance par le Web ou d'autres APP
  • Adapté à : le développement approfondi, les tâches automatisées, l'exécution d'outils locaux

Mécanisme de partage de l'interface

Les composants principaux de l'interface de conversation du Web et de l'APP sont partagés via PlatformAdapter + alias de chemin entre dépôts frères — le dépôt Web et le dépôt APP sont placés au même niveau dans un même répertoire de l'espace de travail, et l'APP référence directement le code source du dépôt Web grâce à l'alias Vite/tsconfig ~/*.

Couche Description
Couche partagée (claw-shared) Plus de 40 composants comme WorkPage, PromptInput, SessionList, Preview, dont la source se trouve dans le dépôt Web
Adaptateur Web webPlatformAdapter.ts — mappe le Redux Store vers WorkState
Adaptateur APP appPlatformAdapter.ts — mappe Redux + coworkService vers WorkState

Cela signifie que l'interface de conversation Work vue sur le Web est parfaitement identique à celle vue sur l'APP — le même code, le même ensemble de composants, seul le mode d'exécution sous-jacent diffère.


Recommandations de choix

Votre scénario Recommandation Raison
Échanger occasionnellement avec l'IA, poser une question Web Aucune installation nécessaire, accessible depuis le navigateur
Gérer l'espace de travail (membres, permissions, usage) Web La gestion de l'espace offre la meilleure expérience sur le Web
Traiter des fichiers locaux, écrire du code APP Nécessite l'accès au système de fichiers local + l'outil Bash
Laisser l'IA automatiser mon travail répétitif quotidien APP Les tâches planifiées ne sont prises en charge que par l'APP
Connecter l'IA à la messagerie de l'équipe (Telegram, DingTalk, etc.) APP La configuration des canaux n'est prise en charge que par l'APP
Collaboration multi-appareils (domicile + bureau) Web + plusieurs APP Le Web lance, les nœuds APP exécutent
Je suis administrateur d'entreprise et veux gérer l'usage de l'IA de tous Web Interface de gestion de l'espace

Usage typique de la collaboration multi-appareils

« Vous lancez une conversation depuis le navigateur Web à la maison → la Gateway route vers l'APP du bureau qui reste toujours allumée → l'APP du bureau lit les fichiers locaux et accomplit la tâche → le résultat s'affiche en temps réel dans votre navigateur. »

Dans ce scénario :

  1. L'ordinateur du bureau : installer l'APP, se connecter au compte, définir le nœud sur account (visible par vous seul) ou enterprise (utilisable aussi par les collègues)
  2. Le navigateur à la maison : se connecter au même compte, accéder à Work ; au moment d'envoyer un message, ce nœud APP est automatiquement sélectionné sous la zone de saisie
  3. Exécution de la tâche : toutes les commandes s'exécutent sur l'APP du bureau, et les résultats sont renvoyés en flux via la Gateway vers le navigateur à la maison