Hermes Desktop rend les personal agents exploitables

Hermes Desktop donne à Hermes une surface opérateur: chat, fichiers, profils, cron, accès gateway et remote backends au même endroit. La Hermes Desktop personal agent runtime a maintenant la couche de contrôle qui manquait aux agents toujours actifs.

La question utile est plus simple: pouvez-vous voir ce que fait l'agent, quel rôle il utilise et comment récupérer quand il casse?

C'est pour cela que je traiterais Hermes Desktop comme la vraie nouvelle, même si les captures ressemblent à une mise à jour produit. Les parties utiles sont les profils, un setup desktop adapté au remote, l'onboarding Portal et la policy autour des agents locaux.

• Hermes Desktop est une surface partagée sur le même état agent. Les docs officielles disent que Desktop, CLI, TUI, dashboard et gateway réutilisent le même setup core au lieu de créer des agents séparés.

• Les profils sont l'endroit où vivent maintenant les rôles agent récurrents. Ils séparent config, `.env`, `SOUL.md`, memory, sessions, skills, cron jobs et gateway state, tandis que l'isolation filesystem demande encore des limites backend explicites.

• Nous Portal retire la dispersion de comptes au premier setup. Un flux OAuth peut définir l'accès modèle et l'accès Tool Gateway au lieu de demander aux utilisateurs de câbler search, browser, image, TTS et sandbox tools un par un.

• L'histoire des local agents devient une histoire de sécurité. NVIDIA et Microsoft parlent maintenant d'identity, de containment, de policy et d'OpenShell pour des agents qui touchent votre ordinateur principal.

Ce qui a changé avec Hermes Desktop

Hermes Desktop compte parce qu'il est construit autour du même Hermes Agent core que le terminal et le gateway. Les docs sont explicites: l'app partage config, API keys, sessions, skills et memory avec CLI, TUI et dashboard.

Cela donne une autre forme à Hermes. Un agent terminal peut être utile aux personnes qui vivent déjà dans des shells. Une app desktop avec chat, file browser, preview rail, profils, skills, cron, messaging et Command Center rend l'agent inspectable pour un travail plus long.

Le détail qui m'intéresse est la continuité d'état. Vous pouvez démarrer une session dans une surface Hermes et la reprendre ailleurs parce que les surfaces parlent au même agent state. C'est là que Hermes commence à ressembler moins à une commande terminal et plus à quelque chose que vous pouvez vraiment exploiter.

Si vous transformez un workflow agent récurrent en processus métier, le service AI automation de webvise est le service le plus proche. Le scope utile est rarement l'interface chat. Il s'agit de la limite du workflow, des credentials, du review gate et du recovery path autour de l'agent.

Les profils sont maintenant les rôles agent

Les profils Hermes sont maintenant le meilleur point de départ pour les rôles agent récurrents. Un profil est son propre Hermes home directory avec sa propre config, son fichier de secrets, son fichier de personality, ses memories, sessions, skills, cron jobs et state database.

Cela sépare assez bien l'état pour des rôles récurrents. Un profil research peut garder des habitudes de source review et des browsing tools. Un profil writer peut garder des règles de draft et des voice constraints.

Un profil engineer peut garder des commandes repo et des habitudes de test. Chacun peut lancer son propre gateway process et service name.

Cela a changé mes propres notes de setup les 8 et 9 juin 2026. Je pensais en boîtes séparées pour agents séparés. Une fois les profils arrivés dans l'architecture réelle, le default plus propre est devenu une installation Hermes, Desktop comme surface opérateur et les profils comme découpage des rôles.

Les mêmes docs nomment aussi clairement la limite: les profils ne sandboxent pas le filesystem. Un local terminal backend tourne encore avec le même accès filesystem que le compte utilisateur. Si vous avez besoin d'un dossier de départ prévisible pour le travail gateway et cron, définissez `terminal.cwd` dans la config Hermes. Si vous avez besoin d'un containment plus fort, utilisez un backend comme Docker, SSH, Modal, Daytona ou Singularity.

C'est ici que le premier article sur les profils Hermes tient encore. Dans notre guide des profils Hermes, la règle était simple: créez un profil quand un rôle se répète et a besoin d'une memory, de tools, d'un gateway state ou de travail planifié séparés. Desktop rend cette règle plus vivable parce que le changement de profil est maintenant visible.

Le setup qui a maintenant du sens

Le setup que je lancerais aujourd'hui est une installation Hermes sur une machine distante, Hermes Desktop connecté via Remote Gateway et des profils comme rôles agent. Telegram ou un autre canal de messages devrait généralement pointer vers un profil assistant. Cet assistant peut déléguer à des profils researcher, engineer, writer ou reviewer via des commandes explicites ou des Kanban tasks.

Cela garde le point d'entrée humain propre. Vous écrivez à un assistant. L'assistant route le travail vers un profil avec la bonne memory et les bons tools. Le travail long devient une tâche durable au lieu de disparaître dans un chat compressé.

Je garderais quand même une surface de réparation hors Hermes. Gardez un outil de réparation hors Hermes pour les logs, les gateway restarts, les config edits et le profile wiring cassé.

Si une équipe demandait à webvise de cartographier cela, je commencerais par la table des permissions avant d'écrire des skills. Notre travail d'AI automation commence à payer quand l'owner, les tools, les credentials et les review gates sont assez clairs pour qu'un mauvais agent run soit visible immédiatement.

Portal retire le désordre des comptes

Les docs officielles de Nous Portal appellent `hermes setup --portal` le chemin de setup le plus rapide. Un flux OAuth définit Nous comme inference provider, laisse l'utilisateur choisir un model et active le Tool Gateway.

Cela compte parce que le setup agent échoue souvent avant le premier workflow utile. Search exige un compte. Browser automation en exige un autre. Image generation, text-to-speech et terminal sandboxing ajoutent encore des keys, dashboards, soldes et failure points.

Portal regroupe l'accès à 300+ models et un Tool Gateway pour search et extract, image generation, text-to-speech, cloud browser sessions et terminal sandbox optionnel. La liste exacte des models changera. La direction produit est stable: Hermes essaie de faire passer le premier setup agent utile à une seule commande au lieu de cinq comptes vendeurs.

Portal change aussi l'endroit où vivent les secrets. Les docs disent qu'OAuth laisse un refresh token dans `~/.hermes/auth.json` et émet des JWT courts par requête, au lieu de remplir `.env` avec une douzaine d'API keys longues. C'est une meilleure hygiène de setup, mais cela exige encore des règles par rôle.

Le travail sérieux reste de décider quel profil possède quel credential, quel tool peut modifier des données et quelle action demande un review. Donnez aux agents des comptes dédiés et des API keys nommées quand vous pouvez. Gardez les secrets dans la config, `.env` ou des chemins d'environnement container, pas dans les chat transcripts.

Les agents locaux ont besoin de policy avant l'autonomie

Hermes Desktop est arrivé au moment où l'histoire hardware devenait plus bruyante. Dans son post RTX AI Garage, NVIDIA a écrit que Hermes avait dépassé 140,000 GitHub stars en moins de trois mois et était, la semaine précédente, l'agent le plus utilisé sur OpenRouter.

Les 31 mai et 2 juin 2026, Microsoft et NVIDIA ont publié le versant Windows de la même histoire. Le post Windows de Microsoft nomme identity, containment et manageability imposés par l'OS. Le post developer de NVIDIA nomme Microsoft eXecution Containers, OpenShell, policy creation, inference routing et PII obfuscation.

C'est la bonne direction pour Hermes. Un personal agent avec file access, terminal access, browser access, memory, voice, cron et gateway routes touche tôt ou tard la même machine que celle que vous utilisez pour la banque, le code, les documents et les comptes de travail. La capability est déjà là. Le plus dur est de limiter qui peut lire des fichiers, dépenser de l'argent, exposer des secrets ou modifier production.

Les docs OpenShell formulent clairement la risk table: data exfiltration, credential theft, unauthorized API usage et privilege escalation. Nous avons déjà défendu dans le day-30 Hermes operator layer que les handoff contracts et permission gates comptent après la première démo. Desktop et les profils rendent ces gates plus visibles. OpenShell et les Windows policy primitives pointent vers la prochaine limite: l'operating system.

Comment tester le setup cette semaine

Commencez avec une runtime et trois profils. Faites du profil assistant la route humaine par défaut. Faites de researcher et writer des workers séparés. Gardez les secrets hors du profil writer.

La première métrique de succès est ennuyeuse: pouvez-vous demander à l'assistant un brief sourcé, voir comment il route la tâche, inspecter la sortie et voir quel profil a touché quels fichiers ou tools? Si oui, vous avez une surface opérateur. Si la réponse est cachée dans un chat transcript, vous avez une démo.

Chez webvise, nous utilisons ce type de recherche sur les setups agent pour décider quels workflows méritent une automation et lesquels doivent rester des tools reviewed. Une bonne première carte est le processus récurrent, les tools qu'il touche et les actions qui feraient mal si un agent les exécutait mal.