Hermes Desktop macht Personal Agents betreibbar

Hermes Desktop gibt Hermes eine Operator Oberfläche: Chat, Dateien, Profile, Cron, Gateway Zugriff und Remote Backends an einem Ort. Die Hermes Desktop Personal Agent Runtime hat jetzt die Kontrollschicht, die dauerhaft laufenden Agents gefehlt hat.

Die nützliche Frage ist einfacher: Können Sie sehen, was der Agent tut, welche Rolle er nutzt und wie Sie ihn reparieren, wenn er bricht?

Deshalb würde ich Hermes Desktop als die eigentliche Nachricht behandeln, auch wenn die Screenshots wie ein Produktupdate aussehen. Die nützlichen Teile sind Profile, ein remote-freundliches Desktop Setup, Portal Onboarding und Policy rund um lokale Agents.

• Hermes Desktop ist eine gemeinsame Oberfläche über demselben Agent Zustand. Die offiziellen Docs sagen, dass Desktop, CLI, TUI, Dashboard und Gateway dieselbe Core Einrichtung wiederverwenden, statt getrennte Agents zu erzeugen.

• Profile sind der Ort, an dem wiederkehrende Agent Rollen jetzt leben. Sie trennen Config, `.env`, `SOUL.md`, Memory, Sessions, Skills, Cron Jobs und Gateway State, während Dateisystem Isolation weiterhin explizite Backend Grenzen braucht.

• Nous Portal entfernt Account Wildwuchs beim ersten Setup. Ein OAuth Flow kann Model Zugriff und Tool Gateway Zugriff setzen, statt Nutzer Search, Browser, Image, TTS und Sandbox Tools einzeln verdrahten zu lassen.

• Die Local Agent Geschichte wird zur Security Geschichte. NVIDIA und Microsoft sprechen jetzt über Identity, Containment, Policy und OpenShell für Agents, die Ihren Hauptcomputer berühren.

Was sich mit Hermes Desktop geändert hat

Hermes Desktop ist wichtig, weil es um denselben Hermes Agent Core gebaut ist wie Terminal und Gateway. Die Docs sind eindeutig: Die App teilt Config, API Keys, Sessions, Skills und Memory mit CLI, TUI und Dashboard.

Das gibt Hermes eine andere Form. Ein Terminal Agent kann für Menschen nützlich sein, die ohnehin in Shells leben. Eine Desktop App mit Chat, Dateibrowser, Preview Rail, Profilen, Skills, Cron, Messaging und Command Center macht den Agent für längere Arbeit prüfbar.

Das Detail, das mich interessiert, ist State Continuity. Sie können eine Session in einer Hermes Oberfläche starten und woanders fortsetzen, weil die Oberflächen mit demselben Agent State sprechen. Dann fühlt sich Hermes weniger wie ein Terminal Command an und mehr wie etwas, das Sie wirklich betreiben können.

Wenn Sie einen wiederkehrenden Agent Workflow in einen Geschäftsprozess verwandeln, ist webvise's AI Automation Service der nächstliegende Service Fit. Der nützliche Scope ist selten das Chat UI. Es geht um Workflow Grenze, Credentials, Review Gate und Recovery Pfad rund um den Agent.

Profile sind jetzt die Agent Rollen

Hermes Profile sind jetzt der sauberste Startpunkt für wiederkehrende Agent Rollen. Ein Profil ist ein eigenes Hermes Home Verzeichnis mit eigener Config, Secrets Datei, Personality Datei, Memories, Sessions, Skills, Cron Jobs und State Database.

Das trennt State gut genug für wiederkehrende Rollen. Ein Research Profil kann Source Review Gewohnheiten und Browser Tools behalten. Ein Writer Profil kann Draft Regeln und Voice Constraints behalten.

Ein Engineer Profil kann Repo Commands und Testgewohnheiten behalten. Jedes Profil kann einen eigenen Gateway Prozess und Service Namen ausführen.

Das hat meine eigenen Setup Notizen am 8. Juni und 9. Juni 2026 geändert. Ich hatte in getrennten Boxen für getrennte Agents gedacht. Nachdem Profile in der tatsächlichen Architektur gelandet waren, wurde der sauberere Default ein Hermes Install, Desktop als Operator Oberfläche und Profile als Rollenschnitt.

Dieselben Docs benennen auch die Grenze klar: Profile sandboxen das Dateisystem nicht. Ein lokales Terminal Backend läuft weiterhin mit demselben Dateisystem Zugriff wie der User Account. Wenn Sie einen vorhersagbaren Startordner für Gateway und Cron Arbeit brauchen, setzen Sie `terminal.cwd` in der Hermes Config. Wenn Sie stärkere Containment brauchen, nutzen Sie ein Backend wie Docker, SSH, Modal, Daytona oder Singularity.

Hier hält der erste Hermes Profile Artikel weiterhin. In unserem Hermes Profiles Guide war die Regel einfach: Erstellen Sie ein Profil, wenn eine Rolle wiederkehrt und getrennte Memory, Tools, Gateway State oder geplante Arbeit braucht. Desktop macht diese Regel leichter lebbar, weil der Profilwechsel jetzt sichtbar ist.

Das Setup, das jetzt Sinn ergibt

Das Setup, das ich heute fahren würde, ist ein Hermes Install auf einer Remote Maschine, Hermes Desktop verbunden über Remote Gateway und Profile als Agent Rollen. Telegram oder ein anderer Message Kanal sollte meistens auf ein Assistant Profil zeigen. Dieser Assistant kann über explizite Commands oder Kanban Tasks an Researcher, Engineer, Writer oder Reviewer Profile delegieren.

Das hält den menschlichen Einstieg sauber. Sie schreiben einem Assistant. Der Assistant routet Arbeit an ein Profil mit der richtigen Memory und den passenden Tools. Längere Arbeit wird zu einem dauerhaften Task, statt in einem komprimierten Chat zu verschwinden.

Ich würde weiterhin eine Reparatur Oberfläche außerhalb von Hermes behalten. Behalten Sie ein Reparatur Tool außerhalb von Hermes für Logs, Gateway Restarts, Config Edits und kaputte Profile Verkabelung.

Wenn ein Team webvise bitten würde, das zu kartieren, würde ich mit der Permission Tabelle starten, bevor ich Skills schreibe. Unsere AI Automation Arbeit zahlt sich aus, wenn Owner, Tools, Credentials und Review Gates klar genug sind, dass ein schlechter Agent Run sofort sichtbar wird.

Portal entfernt das Account Durcheinander

Die offiziellen Nous Portal Docs nennen `hermes setup --portal` den schnellsten Setup Pfad. Ein OAuth Flow setzt Nous als Inference Provider, lässt den Nutzer ein Model wählen und aktiviert das Tool Gateway.

Das zählt, weil Agent Setup oft vor dem ersten nützlichen Workflow scheitert. Search braucht einen Account. Browser Automation braucht einen anderen. Image Generation, Text-to-Speech und Terminal Sandboxing fügen weitere Keys, Dashboards, Guthaben und Failure Points hinzu.

Portal bündelt Zugriff auf 300+ Models und ein Tool Gateway für Search und Extract, Image Generation, Text-to-Speech, Cloud Browser Sessions und eine optionale Terminal Sandbox. Die genaue Model Liste wird sich ändern. Die Produkt Richtung ist stabil: Hermes versucht, das erste nützliche Agent Setup auf einen Command statt fünf Vendor Accounts zu reduzieren.

Portal ändert auch, wo Secrets leben. Die Docs sagen, dass OAuth einen Refresh Token in `~/.hermes/auth.json` hinterlässt und pro Request kurzlebige JWTs erzeugt, statt `.env` mit einem Dutzend langlebiger API Keys zu füllen. Das ist bessere Setup Hygiene, braucht aber weiterhin Regeln pro Rolle.

Die ernste Arbeit bleibt: entscheiden, welches Profil welches Credential besitzt, welches Tool Daten verändern darf und welche Aktion Review braucht. Geben Sie Agents eigene Accounts und benannte API Keys, wo es geht. Halten Sie Secrets in Config, `.env` oder Container Environment Paths, nicht in Chat Transcripts.

Lokale Agents brauchen Policy vor Autonomie

Hermes Desktop kam zur selben Zeit, in der die Hardware Geschichte lauter wurde. In seinem RTX AI Garage Post schrieb NVIDIA, dass Hermes in weniger als drei Monaten 140,000 GitHub stars überschritten hatte und in der Vorwoche der meistgenutzte Agent auf OpenRouter war.

Am 31. Mai und 2. Juni 2026 veröffentlichten Microsoft und NVIDIA die Windows Seite derselben Geschichte. Microsofts Windows Post nennt OS-erzwungene Identity, Containment und Manageability. NVIDIAs Developer Post nennt Microsoft eXecution Containers, OpenShell, Policy Creation, Inference Routing und PII Obfuscation.

Das ist die richtige Richtung für Hermes. Ein Personal Agent mit Datei Zugriff, Terminal Zugriff, Browser Zugriff, Memory, Voice, Cron und Gateway Routes berührt irgendwann dieselbe Maschine, die Sie für Banking, Code, Dokumente und Work Accounts nutzen. Die Capability ist bereits da. Der harte Teil ist zu begrenzen, wer Dateien lesen, Geld ausgeben, Secrets offenlegen oder Production ändern darf.

Die OpenShell Docs formulieren die Risk Table klar: Data Exfiltration, Credential Theft, Unauthorized API Usage und Privilege Escalation. Wir haben bereits im Day-30 Hermes Operator Layer argumentiert, dass Handoff Contracts und Permission Gates nach der ersten Demo zählen. Desktop und Profile machen diese Gates leichter sichtbar. OpenShell und Windows Policy Primitives zeigen auf die nächste Grenze: das Betriebssystem.

So testen Sie das Setup diese Woche

Starten Sie mit einer Runtime und drei Profilen. Machen Sie das Assistant Profil zur Standardroute für Menschen. Machen Sie Researcher und Writer zu getrennten Workern. Halten Sie Secrets aus dem Writer Profil heraus.

Die erste Erfolgsmetrik ist langweilig: Können Sie den Assistant um ein source-backed Briefing bitten, sehen, wie er die Aufgabe routet, den Output prüfen und sehen, welches Profil welche Dateien oder Tools berührt hat? Wenn ja, haben Sie eine Operator Oberfläche. Wenn die Antwort in einem Chat Transcript versteckt ist, haben Sie eine Demo.

Bei webvise nutzen wir diese Art Agent Setup Research, um zu entscheiden, welche Workflows Automation verdienen und welche reviewed Tools bleiben sollten. Eine gute erste Map ist der wiederkehrende Prozess, die Tools, die er berührt, und die Aktionen, die weh tun würden, wenn ein Agent sie falsch ausführt.