onecli v2.0.1

Das Agent-Harness für Teams.
Ein professioneller Assistent für Unternehmen. Geben Sie jedem Mitarbeiter einen abgesicherten, sandboxed persönlichen Agenten.

Website · Dokumentation · Discord

---

Schnellstart

Cloud-gehostet: onecli.sh

Selbst gehostet

git clone https://github.com/onecli/onecli.git && cd onecli
pnpm install
pnpm run setup

Öffne http://localhost:10254

Unter Kubernetes installiere stattdessen das Helm-Chart: helm install onecli oci://ghcr.io/onecli/charts/onecli. Der Self-Hosting-Leitfaden behandelt beides.

Was ist OneCLI v2?

OneCLI ist eine Open-Source-Plattform, um KI-Agenten als Team zu betreiben. Du erstellst einen Agenten pro Person, gibst jedem Agenten den benötigten Zugriff, und er arbeitet in einer Sandbox, geleitet über ein Gateway, das die Anmeldedaten injiziert und deine Richtlinie durchsetzt.

Warum wir OneCLI gebaut haben

OneCLI begann als Credential-Vault für KI-Agenten, geschrieben in Rust. Wir stellten fest, dass die meiste Nachfrage von Einzelpersonen und Teams kam, die autonome Agenten wie Hermes, OpenClaw und NanoClaw betrieben. Die Leute wollten Agenten, die echte Arbeit für die Person erledigen, die sie betreibt, aber zwei Teile fehlten:

1. die Verwaltung von Secrets und Berechtigungen.
2. und für Teams – die Mehrbenutzerverwaltung.

Jeder autonome Agent da draußen ist für eine Person gebaut. Und für eine Person sind sie großartig. In dem Moment, in dem du das auf ein Team ausweiten musst, wird es unübersichtlich: jeden Agenten hochfahren, entscheiden, was jeder darf und was nicht, sie hosten, den Überblick behalten, welcher Agent wem gehört.

Also haben wir umgeschwenkt und OneCLI v2 gebaut.

Für Teams gebaut

• Dein Identity Provider, integriert: Agenten im Namen der Identität jedes Mitarbeiters bereitstellen, direkt aus dem IdP des Unternehmens.
• Ein Agent pro Person: Jeder im Workspace bekommt seinen eigenen sandboxed Agenten, erreichbar über das Dashboard oder Slack.
• Eine Richtlinie, überall durchgesetzt: Verwalte die Team-Richtlinie an einem Ort, die für jeden Agenten in den Workspaces durchgesetzt wird.
• Deterministische Human-in-the-Loop-Genehmigungen: direkt im Chat, für Dinge, bei denen du 100 % Kontrolle brauchst, wie das Senden der E-Mail, das Löschen des Linear-Tickets, das Leeren eines S3-Buckets.
• Geteilte Verbindungen: einmal auf Teamebene verbunden, wie LLM-Keys oder Service-Accounts, pro Agent gewährt, ohne jemals an einen einzelnen ausgehändigt zu werden.

Der Agent

Ein Agent ist ein dauerhaftes Ding, kein einzelner Prompt. Er hat:

• Einen Computer: seine eigene isolierte Sandbox mit Dateisystem und Shell. Der einzige Weg nach draußen ist das Gateway, sodass er nur das erreicht, was du gewährt hast, und nichts anderes.
• Eine Konversation: seine eigene Seite im Dashboard oder in Slack. Bilder und Dateien inklusive. Eine Nachricht, die gesendet wird, während der Agent arbeitet, leitet ihn sofort um, statt sich dahinter einzureihen.
• Gedächtnis: Was der Agent lernt, wird von der Plattform gespeichert, sodass es nie verloren geht. Du kannst es jederzeit lesen und bearbeiten.
• Skills: Anweisungen und Helfer, die du einmal schreibst und die dem Agenten immer zur Verfügung stehen.
• Einen Zeitplan: Der Agent kann zukünftige Arbeit planen, und die Plattform weckt ihn zur richtigen Zeit.
• Anmeldedaten, die er nie sieht: Jeder Agent erhält nur den Zugriff, den du gewährt hast, und das Gateway setzt dies bei jeder Anfrage durch. Oder verbinde Bitwarden oder 1Password für On-Demand-Injektion, wobei nichts auf dem Server gespeichert wird.
• Seine eigene Slack-App: Einmal verbunden, antwortet er in Kanälen und DMs unter seinem eigenen Namen und Avatar, mit Dateien und Bildern. Lösche den Agenten, und seine Slack-App verschwindet mit ihm.

Agenten laufen auf deiner eigenen Infrastruktur. Der Runner ist nur ausgehend und hat keine eingehenden Ports, sodass ein Laptop, ein Homelab oder eine VPC hinter NAT alle ohne Ingress und ohne Tunnel funktionieren.

Architektur

• Web-Dashboard: Next.js-App. Agents erstellen, mit ihnen chatten, ihren Speicher und ihre Fähigkeiten bearbeiten, Verbindungen, Secrets und Berechtigungen verwalten.
• API-Server: die Steuerungsebene. Besitzt die Datenbank, die Konversationsebene und die Arbeitswarteschlange, die der Runner abfragt.
• Rust-Gateway: fängt ausgehende Anfragen ab (einschließlich HTTPS, via MITM) und injiziert Anmeldedaten. Agents authentifizieren sich mit Access-Tokens über Proxy-Authorization-Header.
• Runner: startet, parkt und räumt Agent-Sandboxes auf. Nur ausgehend und greift nie auf die Datenbank zu.
• Sandbox-Supervisor: läuft in jeder Sandbox und spricht eine herstellerneutrale Harness-Schnittstelle, sodass die Agent-Runtime austauschbar ist.
• SSH-Terminator: das SSH-Frontend — beendet ssh-Verbindungen mit kurzlebigen Zertifikaten und überbrückt sie über ein austauschbares Substrat-Backend in Agent-Sandboxes.
• Channel-Adapter: der Slack-Daemon, eine App pro Agent.
• Secret Store: AES-256-GCM im Ruhezustand, Entschlüsselung nur zur Anfragezeit, Abgleich nach Host- und Pfadmuster, Injektion als Header oder Query-Parameter.

Lokale Entwicklung

git clone https://github.com/onecli/onecli.git && cd onecli
mise install
pnpm install
pnpm dev