qm – Multiplayer-Agent-Harness für Zusammenarbeit

 (github.com/yc-software)
1 Punkte von GN⁺ 2 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • qm ist ein Multiplayer-Agent-Harness, mit dem Startup-Teams gemeinsam mit Agenten in Slack-Kanälen, Gruppen-DMs und Projekten zusammenarbeiten können, während jedes Mitglied einen eigenen isolierten Arbeitsbereich nutzt
  • Für jede Person und jeden Gesprächsraum werden Memory, Dateien, Keychain, Berechtigungen, geplante Aufgaben, Web-Apps und persistente Sandboxes getrennt; in Slack und im Web bleiben dieselbe Identität und Konfiguration erhalten
  • Pi, OpenCode, Codex und Claude Code lassen sich an denselben Core anbinden; auch Session-Speicher, Sandboxes und Memory liegen hinter Interfaces, um eine Bindung an ein bestimmtes Modell oder einen Anbieter zu vermeiden
  • Bietet die Sicherheitsmodi Strict, Auto und Dangerous und wendet in allen Modi Command Policies und erzwungene Ablehnungen für Aktionen wie rekursives Löschen oder destruktives SQL an
  • Organisationsspezifische Konfiguration und Infrastruktur werden in einem separaten Deployment-Repository oder einem per normalem Klon erstellten privaten Repository gehalten; Betreiber müssen direkt in ihrem eigenen Fly.io- oder AWS-Konto deployen

Arbeitsbereiche für Agenten auf Organisationsebene

  • Entwickelt mit persönlichen und geteilten Scopes als Grundeinheit, um die Komplexität zu reduzieren, die entsteht, wenn persönliche Assistenten-Agenten auf ein ganzes Unternehmen angewendet werden
    • Jede:r Mitarbeiter:in kann in einem eigenen Arbeitsbereich arbeiten, ohne andere zu beeinflussen
    • In Slack-Kanälen, Gruppen-DMs und Projekten können mehrere Personen mit demselben Agenten zusammenarbeiten
  • Jede Person und jeder Gesprächsraum verfügt über eigene Memory, Dateien, Keychain-Ansicht, Berechtigungen, geplante Aufgaben, Web-Apps und persistente Sandboxes
  • Zwischen Slack und der Web-App werden dieselbe Identität und Konfiguration verwendet
  • Administratoren können Einstellungen auf Organisationsebene, Sicherheitsniveau sowie verfügbare Harnesses und Modelle steuern
  • Technische Skills gehören einem Scope und können über Berechtigungen geteilt werden
    • Für eine organisationsweite Hochstufung ist eine Admin-Genehmigung erforderlich
    • Skill-Packs können aus Git-Repositories importiert werden
  • Geplante Aufgaben (cron) und Überwachungsaufgaben (watch) laufen im Hintergrund, auch wenn der Nutzer nicht zusieht

Unterstützte Aufgaben

  • Interne Memos, E-Mails, Dokumente, Datenbanken und das Web können gemeinsam durchsucht werden, um Unternehmenswissen abzurufen
  • Interne Web-Apps können erstellt, für die benötigten Personen freigegeben und mit aktuellen Daten versorgt werden
  • Nach dem Lernen des Schreibstils aus früheren gesendeten Nachrichten kann der Agent den Posteingang nach Zeitplan klassifizieren sowie Labels und Antwortentwürfe erstellen
  • In bestehenden Repositories kann er Tests ausführen, PRs erstellen, CI überwachen und Systemlogs prüfen
  • In geteilten Kanälen kann er Projekte verfolgen sowie Fortschritt und Folgeaufgaben posten

Core und Ausführungsstruktur

  • Alle Anfragen laufen durch einen headless Core, der Antworten über verschiedene Modelle und Harnesses erzeugt
  • Postgres speichert persistenten Zustand wie Nutzerdaten, Session-Historien, Queues und Memory
  • Die von Agenten genutzte Tool-Oberfläche ist klein und fest definiert; das Tool execute führt Befehle in der isolierten Sandbox des jeweiligen Scopes aus
    • Die Sandbox verhält sich wie ein persistenter Computer, der dem jeweiligen Scope gehört
    • Installierte Tools bleiben auch für spätere Aufgaben erhalten
  • Web-UI, Admin-Panel und öffentliches Portal sind optionale Plugins, die auf der HTTP-API des Cores installiert werden
  • Slack ist ein optionales In-Process-Plugin, das der Core direkt als Service-Client startet und überwacht
  • Der Core führt TypeScript direkt in Node aus und verwendet Fastify für HTTP
    • Das Slack-Plugin verwendet Bolt
    • Die Web-UI wird mit Vite gebaut und mit Lit gerendert
  • Harnesses, Session-Speicher, Sandboxes und Memory liegen jeweils hinter Interfaces; Produktionsimplementierungen lassen sich in einer einzigen Wiring-Datei austauschen

Deployment-Modell je Organisation

  • Unternehmensspezifische Konfiguration, Custom Tools und Skills, Sandbox-Images und Infrastruktur liegen in einem vom Core getrennten Deployment-Verzeichnis
  • Die qm CLI validiert und deployt das Deployment-Verzeichnis
  • In einem organisations­eigenen Repository kann man eine Abhängigkeit zu @yc-software/qm setzen und anschließend so initialisieren:
npm exec --yes --package=@yc-software/qm@latest -- \
  qm init . --org <slug> --target <fly-or-aws>
npm install
  • Die Initialisierung führt durch Infrastruktur, Web-Login, Connector-Credentials, optionalen Slack-Zugriff, Deployment und reale Validierung; ein Source-Checkout ist nicht erforderlich
  • Das Deployment läuft im Cloud-Konto des Betreibers selbst
  • Die Initialisierung erstellt oder aktiviert keine Deployment-CI, und im qm-Repository gibt es keinen Workflow für Produktions-Deployments
  • Das konkrete Verfahren ist in deployment.md beschrieben

Sicherheit und Secrets

  • Agenten handeln mit den Credentials und Berechtigungen der Person, mit der sie arbeiten, und alle ausgeführten Aktionen werden in einem Audit-Log erfasst
  • Eine Organisation wählt ein Sicherheitsniveau; engere Scopes können dieses nicht lockern, sondern nur verschärfen
    • Strict: Pausiert alle Harness-Tool-Aufrufe bis zur menschlichen Genehmigung, mit Ausnahme von zwei wirkungslosen Turn-End-Aktionen
    • Auto: Standardmodus; ein Klassifikator prüft externe Daten mit Herkunftslabel und Tool-Ergebnisse, bevor sie an das Modell weitergegeben werden
      • In der Deployment-Umgebung kann ein eigener Prüf-Proxy angegeben werden
    • Dangerous: Keine Inhaltsprüfung und keine Pausen zwischen Tool-Aufrufen
  • Vordefinierte Command Policies gelten für alle Sicherheitsmodi
    • Zusammen mit Genehmigungsregeln erzwingen sie die Ablehnung von Befehlen wie rekursivem Löschen oder destruktivem SQL
    • Auch der Dangerous-Modus ist keine Ausnahme
  • Threat Model, Betreiber-Voraussetzungen und bekannte Einschränkungen stehen in SECURITY.md

Privates Custom-Repository

  • Organisationen, für die ein Deployment-Repository allein nicht ausreicht, können ein privates Klon-Repository betreiben, damit Core und privater Custom-Code an einem Ort gelesen werden können
  • Es muss als normaler Klon erstellt werden, nicht über GitHubs Fork-Funktion
    • GitHub-Forks öffentlicher Repositories können nicht auf privat umgestellt werden
    • GitHub-Forks teilen das Objekt-Netzwerk mit dem Original, sodass Commits, die in den Fork gepusht wurden, auf der öffentlichen Seite per SHA abgefragt werden können
    • In einem normalen Klon-Repository besteht dieses Problem nicht, allerdings werden upstream-CI-Workflows im Organisationskonto tatsächlich ausgeführt
    • Erforderliche Secrets müssen bereitgestellt oder unerwünschte Workflows deaktiviert werden
  • Organisationsspezifische Konfiguration, Sandbox-Tools und Skills, Plugin-Images und Infrastruktur werden unter deploy/layers/<org>/ gespeichert
  • Der Core wird bytegenau identisch zum upstream gehalten, um den Merge-Umfang zu reduzieren
  • Zwei Skills verwalten die Grenze zwischen öffentlichem Core und privatem Custom-Bereich
    • update-qm mergt upstream qm in das private Repository und erstellt einen Synchronisierungs-PR
    • upstream-pr erstellt einen Branch von upstream/main und sendet organisationsunabhängige Änderungen an qm
    • Vor dem Push werden Diffs, Commit-Messages und Screenshots auf Organisationskennungen geprüft
    • Dateien unter deploy/layers/ werden nicht upstream übertragen

Beiträge und Lizenz

  • Beiträge werden nicht als Code, sondern als von Menschen verfasste .txt- oder .md-Dokumente angenommen
    • Gewünschte Änderungen können informell in adrs/ beschrieben werden; das Projekt setzt sie nach Einigung um
    • Die detaillierten Regeln stehen in CONTRIBUTING.md
  • Schwachstellen müssen nicht als öffentliches Issue, sondern gemäß dem Verfahren in SECURITY.md privat gemeldet werden
  • Soweit nicht anders angegeben, gilt die MIT License

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2 시간 전
Meinungen auf Hacker News

  • Es ist interessant zu sehen, wie im LLM-Zeitalter neue UI-Grundelemente und Konzepte entstehen, aber es gibt so viele kreative Apps und so wenig Erklärung, dass schwer zu erkennen ist, was die einzelnen eigentlich tun.
    Auf der Webseite des Hermes-Agenten habe ich die Funktionen überhaupt nicht verstanden, und erst nach längerem Herumstöbern auf der qm-Seite fand ich eine passende Erklärung. In letzter Zeit nutze ich für die Verwaltung von Coding-Sessions gern das von YC unterstützte Orca, aber da mir eine PostgreSQL-basierte Session-Datenbank fehlt, ist qm einen Test wert.

    • Letztlich kann man einfach personalisiert zugeschnittene Software selbst bauen. Heutzutage kann man sich von solchen Tools inspirieren lassen und nach ein paar guten Sessions mit Claude das Gewünschte selbst umsetzen.
    • Wenn man die Differenzierungsmerkmale eines Tools betont, läuft man Gefahr, fremdartig und nutzlos zu wirken. Deshalb ähneln sich Marketing-Seiten in der Praxis tendenziell, selbst bei innovativen und unterschiedlichen Tools.
    • Für AI braucht es in vielen Bereichen völlig neue Grundelemente.

  • Ich freue mich, dass diese Richtung zusammen mit Buzz sichtbar wird. Der schwierigste Teil bei Multi-User-Agenten ist nicht die Agent-Schleife, sondern die Scope-Festlegung; die persönlichen Scopes und geteilten Räume von QM sind eine sinnvolle Lösung für unternehmensweite Assistenten.
    Unser Team baut mit AQ (aq.dev) ein Multi-User-Coding-Tool, das Claude Code und Codex gemeinsam ausführt. Dass YC ein Multi-User-Agenten-Tool für die Arbeit herausbringt, bestätigt einerseits die Richtung, fühlt sich zugleich aber etwas surreal an.

  • Es gibt bereits viele ähnliche Produkte, und ich weiß nicht, warum man das hier statt Claude Cowork verwenden sollte. Cowork wirkt einfacher sowie ausgereifter und funktionsreicher, daher braucht es einen Vergleich QM vs Cowork.

    • Es gibt Nachfrage danach, selbst betriebene LLMs und pi- oder opencode-Clients zu nutzen, statt dauerhaft an das Ökosystem geschlossener Weight-Modelle von Anthropic gebunden zu sein und weiter pro Token zu zahlen.
    • Es wirkt, als wolle man auf das Buzzword Multi-User aufspringen, das noch niemand gelöst hat; die UI ist aber schlecht und scheint nicht die Antwort zu sein.
    • Vielleicht möchte man auch andere Modelle verwenden.

  • Man sollte sich ansehen, wie organisationsweiter Kontext und Sicherheit umgesetzt wurden. Es wirkt sehr komplementär zu meinem Coding-Tool, das Einzelpersonen die optimale AI-Schnittstelle bietet; es wäre schön, mit nur ein paar großen Tickets sowohl eine unternehmensweite Architektur als auch ein produktives persönliches Coding-Interface zu haben.

  • Ich frage mich, ob Hermes die beste Wahl unter den zuvor verwendeten Agenten der OpenClaw-Familie ist und wofür Power-User solche Systeme tatsächlich einsetzen.

    • Ständig laufende Agenten, die auf interne Systeme zugreifen und per Webhook ausgeführt werden können, sind sehr praktisch.
      Ich nutze sie für einfache automatische Fixes bei CI-Fehlern, zum Empfangen von Produktionsalarmen mit anschließender Root-Cause-Analyse und Erstellen eines Fix-PRs, zur regelmäßigen Prüfung und Optimierung langsamer Datenbankabfragen sowie zum Erzeugen von Charts als Antwort auf einmalige Datenfragen. Ich habe sie auch fürs Coding unterwegs ausprobiert, bevorzuge aber interaktive Agenten, bei denen ich den Code direkt überprüfen kann.
    • Ich habe Hermes genutzt, fand es aber oft unpraktisch, weil ich ein oder zwei Ebenen tiefer mehr Kontrolle wollte. Seit gestern baue ich eine stark angepasste Version nur für mich selbst; auch wenn es erst ein Tag Honeymoon-Phase ist, macht die Arbeit daran Spaß.
      Ich mag das Bauen von Software an sich und vollständige Kontrolle; die grundlegende Agent-Schleife ist tatsächlich nichts Besonderes. Außerhalb der Kernschleife gibt es sehr viele Stellschrauben, und es macht Spaß, verschiedene Erweiterungsansätze auszuprobieren. Ich muss mir keine Gedanken über Monetarisierung oder Allgemeingültigkeit machen, sondern kann einfach nur die Funktionen hinzufügen, die ich brauche, und muss es auch nicht unendlich pluginfähig machen. Ich bin nanoclaw und Hermes dankbar, dass sie mir die Kernideen gezeigt haben, aber jetzt möchte ich es auf meine Weise abwandeln.
    • Hermes ist riesig und hat viele unnötige Funktionen, daher bevorzuge ich kleine Agenten, die man je nach Bedarf erweitern kann. Ich habe mehrere Projekte auf GitHub ausprobiert, dirge (https://github.com/dirge-code/dirge) fand ich beeindruckend; ich habe keine Verbindung dazu.
      Ich nutze es, um zusätzliche RSS-Feeds und Newsletter zu lesen, nur die für mich wichtigen Informationen herauszufiltern und mir Nachrichten und Markttrends zu liefern.
    • Ich nutze es als On-Call-Hilfstool, das als Erstes auf Produktionsalarme reagiert. In der Grundeinstellung ist es nicht so effizient wie ein Coding-Agent, aber es hilft sehr.
    • Die meisten scheinen es dafür zu verwenden, E-Mails und Instant Messages regelmäßig per LLM zu prüfen.

  • Es wirkt wie ein internes Tool, das YC hastig veröffentlicht hat, um den von Buzz besetzten Raum möglichst klein zu halten. Mich interessiert eine Bewertung von jemandem, der beide Tools direkt verglichen hat.

  • Ich frage mich, was yc software bedeutet.

  • Interessant ist, dass sie auch eine anti-slop-Design-Skill mitliefern, die Interfaces erzeugen soll, die nicht wie Templates aussehen.
    Für hochwertige Konsumgüter verbieten sie Farbpaletten, die AI häufig nutzt, und definieren Landingpages und Portfolios als visuelle Produkte, sodass Textseiten mit nur einem Bereich für Fake-Screenshots als minderwertige Ergebnisse gelten. https://github.com/yc-software/qm/blob/7f2c916360f1797a8ff2a...

    • Am Ende sieht es nur anders aus als das aktuelle minderwertige AI-Design; mit der Zeit könnte es selbst zu einem weiteren Konvergenzpunkt austauschbaren Designs werden.

  • Der Titel wäre nützlicher, wenn er den Zweck des Tools erkennen ließe, etwa qm - a multiplayer agent harness for work.

    • Dass Leser sich ein wenig Mühe geben müssen, um den Titel zu verstehen, ist eine HN-typische Gepflogenheit.