Mercury Agent: Ein Agent, der vor dem Ausführen fragt und Erinnerungen in SQLite ablegt

Welches Problem Mercury Agent löst und für wen es gedacht ist

Viele Agenten führen Shell-Befehle, Dateizugriffe und Netzwerkabrufe ohne Rückfrage aus. Mercury Agent setzt dagegen auf einen Freigabe-Workflow: Laut README fragt der Agent zuerst und merkt sich, was wichtig ist. Die Zielgruppe sind Personen, die einen Agenten dauerhaft laufen lassen wollen, ohne ihm blind Schreibrechte auf das gesamte Dateisystem zu geben. Der README nennt drei Betriebsarten: CLI, Telegram und Web. Ein einzelner Entwickler kann den Agenten nach der Installation über npx starten, ein Team kann ihn als Daemon betreiben und Telegram als primären Kanal nutzen, weil im Daemon-Modus kein Terminal für Eingaben vorhanden ist. Die Dokumentation beschreibt außerdem einen Shell-Blocklist, der Befehle wie sudo und rm -rf / niemals ausführt, sowie ein Ordner-Scoping für Lese- und Schreibzugriffe. Das ist der Kern des Versprechens: Der Agent soll nützlich sein, ohne dass jede Aktion eine potenzielle Katastrophe ist.

Soul-Dateien, Second Brain und der tatsächliche Datenfluss

Die Persönlichkeit des Agenten liegt in Markdown-Dateien, die der Nutzer besitzt: soul.md, persona.md, taste.md und heartbeat.md. Der README bezeichnet das als soul-driven und grenzt es von einem corporate wrapper ab. Diese Dateien sind keine Konfiguration im klassischen Sinn, sondern Text, der in den Kontext des Modells einfließt. Das Gedächtnis läuft über eine SQLite-Datenbank mit FTS5-Volltextsuche. Laut README gibt es zehn Speichertypen, automatische Extraktion, Konfliktauflösung und Auto-Konsolidierung. Der Datenfluss ist damit: Eine Unterhaltung erzeugt Text, aus dem das System Einträge ableitet, die in SQLite landen und später über FTS5 durchsucht werden. Was die Dokumentation nicht beschreibt, ist die Genauigkeit dieser Extraktion. Ein Agent, der Präferenzen automatisch ableitet, kann falsche Schlüsse ziehen, und der README nennt keine Möglichkeit, die automatische Extraktion vollständig abzuschalten oder die Qualität zu messen. Wer Wert auf nachvollziehbare Erinnerungen legt, sollte prüfen, ob sich Einträge manuell korrigieren lassen.

Installation und der erste Start

Der README gibt mehrere Wege. Unter macOS und Linux installiert ein Einzeiler ein eigenständiges Binary, ohne dass Node.js vorhanden sein muss: curl -fsSL https://mercuryagent.sh/install.sh | sh. Unter Windows funktioniert irm https://mercuryagent.sh/install.ps1 | iex. Wer Node.js 20 oder neuer hat, kann npx @cosmicstack/mercury-agent verwenden oder das Paket global installieren mit npm i -g @cosmicstack/mercury-agent und danach mercury aufrufen. Der erste Start löst einen Setup-Assistenten aus, der nach Name, Anbieter und optional Telegram fragt. Danach öffnet sich die Ink-TUI und der Agent verlangt die Wahl eines Berechtigungsmodus: Ask Me oder Allow All. Diese Wahl ist pro Sitzung möglich, und der README betont, dass es keine Überraschungen geben soll. Spätere Änderungen an Schlüsseln, Namen und Einstellungen laufen über mercury doctor, plattformspezifische Diagnosen über mercury doctor --platform.

Daemon-Betrieb und was der Dienst auf jedem System tut

Der Befehl mercury up installiert den Systemdienst, startet den Hintergrundprozess und stellt sicher, dass der Agent läuft. Läuft er bereits, zeigt der Befehl nur die PID. Für die Verwaltung gibt es mercury restart, mercury stop, mercury start -d, mercury logs und mercury status. Die Crash-Erholung ist laut README eingebaut und startet den Prozess mit exponentiellem Backoff neu, bis zu zehn Neustarts pro Minute. Die Dienstinstallation unterscheidet sich je Plattform: macOS nutzt einen LaunchAgent unter ~/Library/LaunchAgents/, Linux eine systemd-User-Unit unter ~/.config/systemd/user/, Windows den Task Scheduler über schtasks. In keinem Fall ist laut Tabelle ein Administrator nötig, für Linux wird linger für den Start beim Booten erwähnt. Das ist ein konkreter Vorteil gegenüber Agenten, die nur im Vordergrund laufen. Die Kehrseite: Im Daemon-Modus ist die CLI nur noch ein Log, weil kein Terminal für Eingaben existiert. Telegram wird dann zum primären Kanal, und wer Telegram nicht einrichten will, verliert die Interaktionsmöglichkeit.

Berechtigungen, Token-Budgets und die Grenzen der Kontrolle

Die Berechtigungsschicht besteht aus drei Teilen. Erstens eine Shell-Blocklist, die bestimmte Befehle nie ausführt. Zweitens Ordner-Scoping für Lesezugriffe und Schreibzugriffe. Drittens ein Pending-Approval-Flow, bei dem Aktionen auf Freigabe warten. Dazu kommt ein Token-Budget pro Tag, das der Agent durchsetzt und ab 70 Prozent Verbrauch automatisch knapper antwortet. Der Befehl /budget zeigt den Status, /budget override erlaubt laut README ein Überschreiben, und /status zeigt Konfiguration, Budget und Nutzung. Diese In-Chat-Befehle verbrauchen keine API-Tokens. Die Einschränkung liegt auf der Hand: Eine Blocklist ist eine Negativliste. Sie deckt die genannten Befehle ab, aber sie kann nicht jede gefährliche Kombination kennen. Das Ordner-Scoping ist die stärkere Kontrolle, doch der README beschreibt nicht, wie fein granular es ist und ob symbolische Links oder relative Pfade geprüft werden. Wer den Agenten mit Schreibzugriff auf ein Repository laufen lässt, sollte vorher mercury doctor ausführen und die Standardwerte prüfen, statt sich auf die Blocklist zu verlassen.

Telegram-Zugangskontrolle als eigenes Berechtigungssystem

Telegram ist nicht nur ein Kanal, sondern bringt eine zweite Zugriffsebene mit. Der README listet mercury telegram list, approve, reject, remove, promote, demote und reset. Nutzer werden über einen Pairing-Code oder eine ID freigegeben, es gibt die Rollen Admin und Mitglied, und reset löscht alle Zugriffe. Das ist mehr, als viele Agenten für einen Chat-Kanal bieten, und es ist notwendig, weil ein Telegram-Bot ohne Freigabe von beliebigen Personen angesprochen werden kann. Der Preis ist Verwaltungsaufwand: Jede neue Person braucht einen Genehmigungsschritt, und wer die Rolle Admin vergibt, gibt damit auch Zugriff auf die Verwaltungsbefehle. Der README beschreibt nicht, ob es eine Obergrenze für freigegebene Nutzer gibt oder wie sich ein kompromittierter Bot-Token auswirkt. Wer Telegram als primären Kanal im Daemon-Modus nutzt, sollte den Bot-Token wie einen Zugangsschlüssel behandeln und mercury telegram reset bereithalten.

Erweiterbarkeit über Skills und die Abhängigkeit von einer Spezifikation

Mercury installiert Community-Skills über einen Befehl und kann sie als wiederkehrende Aufgaben planen. Die Grundlage ist die Agent Skills Spezifikation unter agentskills.io. Beim ersten Start legt Mercury laut README einen Standard-Skill web-search unter ~/.mercury/skills/web-search/SKILL.md an. Der Agent bringt 31 eingebaute Tools mit, dazu Kanban-Boards. Das ist ein offenes Modell: Skills sind Dateien, die der Nutzer lesen und ändern kann, und die Struktur folgt einer externen Spezifikation statt einem proprietären Format. Die Abhängigkeit davon ist ein Risiko, das der README nicht adressiert. Ändert sich die Spezifikation, müssen Skills angepasst werden, und der Agent kann nicht selbst entscheiden, welche Version er unterstützt. Cron-Scheduling und Heartbeat-Monitoring sind laut README vorhanden, aber die Dokumentation beschreibt nicht, wie sich überlappende Läufe verhalten oder was passiert, wenn ein Skill während eines Neustarts mitten in der Ausführung war.

Wartung, Lizenz und eine Alternative mit anderem Ansatz

Mercury Agent steht unter der MIT-Lizenz. Das erlaubt kommerzielle Nutzung, Veränderung und Weitergabe, solange Lizenz- und Urheberrechtshinweis erhalten bleiben. Der README gibt keine Garantie, und für Haftungsfragen ist das keine Rechtsberatung. Die Wartung läuft über mercury upgrade, und die Release-Historie zeigt drei Veröffentlichungen zwischen Juni und September 2026: v1.1.13, v1.2.2 und v1.2.3. Die Abstände sind unregelmäßig, was bei einem kleinen Projekt normal ist, aber bedeutet, dass Sicherheitskorrekturen nicht nach einem festen Takt erscheinen. Als Alternative bietet sich ein zustandsloser CLI-Agent an, der pro Aufruf einen Prompt und einen Arbeitsordner bekommt und danach beendet wird. Der Unterschied liegt nicht in den Fähigkeiten, sondern im Zustand: Ein solcher Agent hat kein persistierendes Gedächtnis, keinen Daemon und keine Freigabe-Warteschlange. Er ist reproduzierbar und lässt sich in einer Pipeline testen, weil jeder Lauf bei null beginnt. Mercury Agent ist das Gegenteil davon: Er akkumuliert Erinnerungen in SQLite, läuft weiter, wenn niemand hinsieht, und trifft Entscheidungen auf Basis früherer Unterhaltungen. Wer einen wiederholbaren Schritt in einer CI braucht, ist mit dem zustandslosen Modell besser bedient. Wer einen Assistenten will, der Präferenzen über Wochen behält, braucht genau die Zustandsbehaftung, die Mercury bietet.

Redaktionelles Fazit

Mercury Agent passt zu einzelnen Entwicklern oder kleinen Teams, die einen dauerhaft laufenden Agenten mit expliziter Freigabe und lokalem SQLite-Gedächtnis suchen. Wer einen zustandslosen Einmal-Aufruf in einer CI-Pipeline braucht oder keine Bereitschaft hat, jede Shell-Aktion zu bestätigen, sollte einen anderen Weg wählen. Vor dem Einsatz lohnt es sich, mercury doctor --platform auf der Zielmaschine auszuführen, weil davon abhängt, ob der Dienst als LaunchAgent, systemd-Unit oder Scheduled Task überhaupt startet.

Offizielle Quellen

1. cosmicstack-labs/mercury-agent on GitHub
2. License: MIT
3. Project website
4. README
5. Releases