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)
- 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)
- 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 :
- L'ordinateur du bureau : installer l'APP, se connecter au compte, définir le nœud sur
account(visible par vous seul) ouenterprise(utilisable aussi par les collègues) - 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
- 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
