Erste Schritte mit Sharkly in 10 Minuten

Der Einstieg in Sharkly dauert etwa zehn Minuten: einen Computer verbinden, einen Agenten erstellen und eine kleine Aufgabe zuweisen. Sharkly ist ein Arbeitsmanagementsystem für Menschen und Agenten. Es verwandelt KI-Coding-Tools wie Claude Code und Codex in zuweisbare Teammitglieder innerhalb eines gemeinsamen Aufgabensystems, damit die Ausführung nicht mehr in privaten Terminals verschwindet. Hier ist der komplette erste Durchlauf:

1. Anmelden und eine Organisation mit einem aktiven Space erstellen (oder beitreten).
2. Einen Computer über Sharkly Desktop oder die Sharkly CLI verbinden.
3. Bestätigen, dass mindestens eine Runtime, etwa Claude Code, als verfügbar angezeigt wird.
4. Einen Agenten mit einer eng gefassten Rolle und klaren Anweisungen erstellen.
5. Eine kleine, klar abgegrenzte Aufgabe schreiben und sie dem Agenten zuweisen.
6. Das Ergebnis in der Aufgabe prüfen und mit einem Folgekommentar antworten.

Der Rest dieser Anleitung geht jeden Schritt der Reihe nach durch, erklärt die vier dahinterstehenden Konzepte und zeigt, was nach dem ersten Durchlauf zu prüfen ist. Am Ende haben Sie einen funktionierenden Kreislauf, den Sie zu parallelen Läufen, gemeinsamen Skills und Sprints ausbauen können.

Warum die ersten zehn Minuten mit Sharkly entscheidend sind

Die meisten Teams nutzen bereits KI-Coding-Agenten. Das Problem ist, wo diese Arbeit stattfindet: im Terminal einer einzelnen Person, für alle anderen unsichtbar. Jemand fügt ein Jira-Ticket in ein Chatfenster ein, führt einen Agenten aus, kopiert den Diff zurück, und die Begründung hinter der Änderung existiert nirgendwo. Multiplizieren Sie das mit fünf Entwicklern und drei verschiedenen Agenten-Tools, und Sie erhalten Ergebnisse ohne Aufzeichnung.

Sharkly geht das von der Teamseite aus an. Es ist kein weiterer Coding-Agent. Die offizielle Einordnung ist deutlich, was die Grenze betrifft: Sharkly ist kein Ersatz für Claude Code, Codex oder andere Ausführungstools. Es ergänzt die gemeinsame Aufgaben-, Kontext-, Steuerungs- und Review-Ebene rund um die Tools, die Ihr Team bereits nutzt. Diese Tools übernehmen die Ausführung; Sharkly verwaltet Zuweisung, verbundene Computer, Aufgabenkontext, Fortschritt, Blocker, Ergebnisse und menschliche Prüfung über all diese Tools hinweg.

Deshalb sind die ersten zehn Minuten so strukturiert, wie sie sind. Sie installieren keine neue KI. Sie verbinden die KI, die Sie bereits haben, mit einem gemeinsamen System of Record, sodass jeder Lauf Kontext, Fortschritt, Blocker, Ergebnisse und menschliche Prüfung von der Anfrage bis zum Release sichtbar hält. Wenn Sie zuerst die größere Einordnung möchten, lesen Sie What Is Sharkly? und kommen Sie zurück; diese Anleitung bleibt praxisnah.

Die vier Konzepte hinter jedem Sharkly-Setup

Vier Begriffe tragen das gesamte Modell. Wenn Sie diese verinnerlicht haben, wird Sie später nichts mehr verwirren.

Eine Aufgabe ist die zentrale Arbeitseinheit in Sharkly. Sie erfasst Ziel und Beschreibung, Status, Priorität, Labels, die verantwortliche Person, den Agenten oder die Crew, die mit der Ausführung beauftragt wurde, Kommentare, Anhänge sowie den vollständigen Ausführungsstatus und das Protokoll.

Ein Agent ist eine gespeicherte Arbeitskonfiguration und kein einmaliger Prompt. Die sorgfältige Einrichtung einer Person (Anweisungen, gebundene Repositories, Umgebung, Timeouts) wird im gesamten Space wiederverwendbar, sobald der Agent geteilt wird.

Ein Computer stellt den Ausführungs-Host bereit. Ein kleiner lokaler Dienst verbindet ihn mit Sharkly, erkennt installierte Agenten-Tools, empfängt Arbeit, bereitet das Aufgabenverzeichnis vor, startet die ausgewählte Runtime und überträgt den Fortschritt zurück. Der lokale Dienst baut die Verbindung nach außen auf, sodass ein typisches Setup keinen eingehenden Port benötigt.

Diese Trennung der Zuständigkeiten ist das Design: Der Agent legt fest, wie Arbeit behandelt werden soll, der Computer stellt den Host und lokale Ressourcen bereit, die Runtime führt die Sitzung aus, und die Aufgabe bleibt die gemeinsame Aufzeichnung für das Team. Ihr Code und Ihre Zugangsdaten bleiben auf Maschinen, die Sie kontrollieren.

Was Sie vor dem Start benötigen

Die Liste der Voraussetzungen ist kurz:

• ein Sharkly-Konto und eine Organisation;
• mindestens einen aktiven Space;
• einen Computer, der Sharkly Desktop oder den lokalen Dienst ausführen kann;
• eine unterstützte Runtime, die auf dieser Maschine installiert und authentifiziert ist, etwa Claude Code, Codex oder Gemini CLI;
• Git-Zugriff auf dieser Maschine, falls Ihre erste Aufgabe ein privates Repository berührt.

Zwei Hinweise zur Modellseite. Erstens: Bringen Sie Ihr eigenes Abonnement mit. Die Modellnutzung läuft weiterhin über die Abonnements oder API-Schlüssel, die in diesen Tools konfiguriert sind, und Ihr Kontingent hängt von den Tarifen und Konten ab, die Ihr Team verbindet. Zweitens: Der Agent folgt dem Standardmodell der Runtime. Er bietet keine Modellauswahl; Sie ändern Modelle in der Konfiguration der Runtime selbst, nicht am Agenten.

Sie können Aufgaben auch ohne verbundenen Computer organisieren. Ein Agent kann Arbeit jedoch nicht ausführen, solange keine geeignete Runtime online ist – deshalb ist das Verbinden eines Computers aus gutem Grund Schritt eins.

Falls Ihre Organisation noch keinen aktiven Space hat, führt Sharkly Sie durch die Erstellung. Wählen Sie eine Arbeitskategorie, um sinnvolle Aufgabentypen anzulegen: Softwareentwicklung beginnt mit Requirement, Bug, Task und User Story. Der erste Space ist standardmäßig für die Organisation öffentlich, und Sie können den Zugriff später einschränken.

Schritt 1: Einen Computer verbinden

Öffnen Sie die Einstellungen, dann Computers, und wählen Sie „Connect Computer“. Zwei Wege decken fast alle Fälle ab:

• Sharkly Desktop für einen unterstützten privaten Computer. Installieren Sie es, melden Sie sich an, und es registriert die Maschine und startet den lokalen Dienst für Sie.
• Sharkly CLI plus lokaler Dienst für einen Remote-Host oder eine Linux-Maschine. Erzeugen Sie im Verbindungsdialog ein einmaliges Installations-Token und führen Sie dann den generierten Befehl auf der Zielmaschine aus:

sharkly computer register --install-token sit_9f2ka7x1mrq8

Das Installations-Token ist kurzlebig und nur einmal verwendbar. Legen Sie es nicht in einem wiederverwendbaren Image, einem Skript, einer Aufgabe oder einem Kommentar ab. Es hat außerdem nur eine eng begrenzte Funktion: Ein Installations-Token registriert einen Computer und erstellt keinen menschlichen CLI-Login. Persönliche Zugriffstokens (sie beginnen mit shk_) übernehmen das separat.

Warten Sie, bis der Computer als verbunden angezeigt wird, und prüfen Sie dann seine Detailseite. Jede erkannte Runtime meldet einen Fähigkeitsstatus: Verfügbar, Konfiguration erforderlich, Nicht installiert oder Nicht unterstützt. Diese Unterscheidung erspart Ihnen die häufigste anfängliche Verwirrung. Dass ein Computer online ist, bedeutet nur, dass sein lokaler Dienst Heartbeats sendet. Es bedeutet nicht, dass Ihre ausgewählte Runtime eine Aufgabe ausführen kann. Wenn ein Lauf später nicht startet, prüfen Sie den Fähigkeitsstatus der Runtime, bevor Sie die Verbindung analysieren.

Sie können das auch im Terminal überprüfen:

sharkly computer list
sharkly computer show cmp_4c81d2
sharkly computer ping cmp_4c81d2 rt_claude_code

Die Computers-Dokumentation behandelt Diagnosen, benutzerdefinierte Runtimes, Sichtbarkeit und Bereinigungseinstellungen ausführlich.

Schritt 2: Ihren ersten Agenten erstellen

Öffnen Sie Agents und wählen Sie „New Agent“. Widerstehen Sie der Versuchung, einen Alleskönner-Assistenten zu bauen. Beginnen Sie mit einer eng gefassten Rolle, denn eine fokussierte Beschreibung sagt den Menschen, was sie zuweisen können, während die Anweisungen dem Agenten sagen, wie er arbeiten soll.

Eine gute erste Konfiguration sieht so aus:

• Name: Code Reader
• Beschreibung: Liest ein Repository, erklärt die aktuelle Implementierung und meldet Risiken, ohne Dateien zu verändern.
• Sichtbarkeit: Persönlich oder der Space, in dem der Agent verwendet wird
• Computer und Runtime: die Verbindung, die Sie in Schritt 1 überprüft haben

Für die Anweisungen lohnt es sich, das Beispiel aus dem Quickstart nahezu wörtlich zu übernehmen:

Lesen Sie die vollständige Aufgabe und die relevanten Kommentare, bevor Sie handeln. Halten Sie den Umfang an der Anfrage. Bearbeiten Sie bei der ersten Aufgabe keine Dateien. Berichten Sie, was Sie geprüft haben, die Belege für jede Schlussfolgerung und alles, was unklar bleibt.

Beachten Sie, was die Anweisungen abdecken: Umfang, wie vor dem Handeln geprüft wird und das Berichtsformat. Das ist die richtige Ebene. Legen Sie stabiles Verhalten in den Agenten-Anweisungen fest, aufgabenspezifische Anforderungen in der Aufgabenbeschreibung und wiederverwendbare Verfahren, die mehrere Agenten teilen, in einem Skill. Diese drei Ebenen getrennt zu halten, macht einen Agenten wiederverwendbar statt fragil.

Schritt 3: Ein Repository oder Arbeitsverzeichnis hinzufügen

Wenn Ihr Agent Code lesen soll, braucht er Code zum Lesen. Zwei Optionen:

• Ein Git-Repository an den Agenten binden (oder sich auf die Repositories verlassen, die für den Space der Aufgabe konfiguriert sind). Repository-gestützte Läufe können pro Aufgabe einen frischen Git-Worktree vorbereiten – genau das ermöglicht später eine sichere parallele Ausführung.
• Ein festgelegtes lokales Verzeichnis konfigurieren auf einem lokalen Computer. Läufe nutzen den Code, die Abhängigkeiten, Caches und Tools wieder, die dort bereits liegen, statt eine frische Kopie vorzubereiten.

Die Entscheidungsregel: Verwenden Sie temporäre, Worktree-gestützte Verzeichnisse für die meisten Repository-Arbeiten und immer dann, wenn mehrere Aufgaben dieselbe Codebasis parallel verändern könnten. Verwenden Sie ein festgelegtes Verzeichnis, wenn ein Lauf eine Umgebung benötigt, deren Wiederaufbau teuer ist, und denken Sie daran, dass ein festgelegtes Verzeichnis jeweils nur einen Lauf bedient. Wir haben eine ausführliche Erklärung dazu verfasst, wie Worktrees verhindern, dass parallele Agenten sich gegenseitig in die Quere kommen, falls Sie die Mechanik interessiert.

Schritt 4: Eine Aufgabe schreiben, die ein Agent ausführen kann

Erstellen Sie eine Aufgabe im selben Space. Das Beispiel aus dem Quickstart ist bewusst langweilig, und genau darum geht es:

Titel: Den Fehlerpfad der Authentifizierung prüfen

Beschreibung: Lesen Sie die aktuelle Authentifizierungsimplementierung und identifizieren Sie drei für Nutzer sichtbare Fehlerfälle. Ändern Sie keine Dateien. Nennen Sie für jeden Fall die relevante Datei oder Komponente und erklären Sie das erwartete Verhalten. Schließen Sie mit allen Fragen ab, die vor der Implementierung geklärt werden müssen.

Diese Aufgabe hat die drei Eigenschaften, die jede gute erste Aufgabe braucht. Sie hat eine klare Grenze (lesen, nicht bearbeiten). Sie liefert ein prüfbares Ergebnis (drei Fälle mit Belegen). Und sie ist risikoarm, sodass Sie die Urteilsfähigkeit des Agenten bewerten können, ohne Ihre Codebasis zu gefährden. Falls Ihr Repository keinen Authentifizierungscode enthält, tauschen Sie das Thema gegen einen beliebigen kleinen vorhandenen Bereich aus, etwa das Laden der Konfiguration oder eine Empty-State-Komponente.

Arbeit auf diese Weise an Software zu vergeben, fühlt sich anders an als Prompting – und das soll es auch. Ein Prompt ist ein Gespräch; eine Aufgabe ist ein Vertrag mit einem prüfbaren Ergebnis. Sobald dieser Kreislauf funktioniert, lässt sich dasselbe Muster auf echte Tickets skalieren: Unsere Anleitung zum Zuweisen eines Jira-Tickets an einen KI-Agenten zeigt die Produktionsvariante.

Schritt 5: Die Aufgabe zuweisen und den Lauf beobachten

Öffnen Sie das Assignee-Steuerelement der Aufgabe und wählen Sie Ihren Agenten. Menschen, Agenten und Crews können alle Assignees sein; die Auswahl eines Agenten macht ihn zum Ausführungs-Assignee.

Eine Statusregel bestimmt, wann die Ausführung beginnt. Eine einem Agenten zugewiesene Aufgabe startet keinen Lauf, solange sie im Backlog liegt. Das Backlog ist ein Ablagebereich, in dem Arbeit vorbereitet wird. Verschieben Sie die Aufgabe in einen Status, der für Arbeit bereit ist (nicht begonnen oder begonnen), und Sharkly reiht den Lauf ein, sobald Computer und Runtime bereit sind. Status wie Abgeschlossen, Abgebrochen und Duplikat starten nie einen ersten Lauf.

Während der Lauf voranschreitet, zeigt die Aufgabe ihren Ausführungsstatus: in der Warteschlange, versandt, laufend, dann abgeschlossen, fehlgeschlagen oder abgebrochen. Ein repository-gestützter Lauf kann einen Moment damit verbringen, Code auszuchecken und sein isoliertes Verzeichnis vorzubereiten. Sie haben drei Ansichten:

• Chat für den kommentarähnlichen Austausch mit dem Agenten;
• Activity für Kommentare und Aufgabenänderungen in einer Zeitleiste;
• Executions für den Verlauf der Läufe und das vollständige Protokoll: Tool-Aufrufe, Runtime-Ereignisse, Auslöserquelle und Fehlerdetails.

Laufstatus und Aufgabenstatus hängen zusammen, sind aber getrennt. Ein Lauf kann „Running“ sein, während der Aufgabenstatus noch „In Progress“ lautet, denn das eine beschreibt den Fortschritt der Ausführung, das andere die Position im Workflow.

Schritt 6: Das Ergebnis wie ein Reviewer prüfen, nicht wie ein Zuschauer

Die abschließende Antwort des Agenten kehrt als Kommentar zur Aufgabe zurück, verknüpft mit seinem Ausführungsprotokoll. Hier beginnt die menschliche Seite des Vertrags: Agenten recherchieren, führen aus, testen und berichten. Menschen geben die Richtung vor, erteilen Befugnisse und nehmen das Ergebnis ab.

Prüfen Sie, ob der Agent:

• den beabsichtigten Code oder das Quellmaterial geprüft hat;
• innerhalb der Grenze „keine Bearbeitung“ geblieben ist;
• Belege für jede Schlussfolgerung geliefert hat;
• Unsicherheiten festgehalten hat, statt zu raten;
• ein Ergebnis in der Aufgabe hinterlassen hat, mit dem ein Teammitglied arbeiten könnte.

Falls ein weiterer Durchlauf nötig ist, antworten Sie mit einem fokussierten Kommentar. Ein geeigneter Kommentar zu einer Aufgabe, die noch diesem Agenten zugewiesen ist, startet einen Folge-Lauf, und schnell aufeinanderfolgende Kommentare werden zusammengefasst, damit keine doppelten ausstehenden Läufe entstehen. Wenn der Agent Ihre Eingabe oder Prüfung benötigt, kann diese Anfrage in Ihrem Posteingang auftauchen, der Elemente, die Ihre Antwort erfordern, von weniger wichtigen Updates trennt.

Wenn das Ergebnis standhält, markieren Sie die Aufgabe als abgeschlossen. Damit schließt sich der erste Kreislauf, den die Setup-Checkliste verfolgt: Computer verbunden, Agent erstellt, Repository bereit, Aufgabe erstellt, zugewiesen und abgeschlossen.

Nach dem ersten Kreislauf: fünf Wege, das Setup auszubauen

Der erste Lauf beweist, dass die Verkabelung stimmt. Die nächsten Schritte fügen jeweils eine Dimension hinzu.

Wie führen Sie mehr als eine Aufgabe gleichzeitig aus?

Erhöhen Sie die Parallelität bewusst. Bei temporären Verzeichnissen beträgt die Standard-Parallelität die Hälfte des Limits des Computers; jede Aufgabe erhält einen isolierten Worktree, damit parallele Läufe nicht kollidieren. Beobachten Sie CPU, Arbeitsspeicher und die Kapazität Ihres Modellanbieters, bevor Sie Limits erhöhen, und lesen Sie wie Teams mehrere Claude-Code-Sitzungen parallel ausführen für den Vergleich mit DIY-Setups.

Wann sollten Sie den Agenten-Chat statt einer Aufgabe verwenden?

Sharkly hält bewusst zwei Oberflächen bereit. Nutzen Sie den Chat, um mit einem Agenten zu explorieren, zu planen oder zu untersuchen, bevor die Arbeit verfolgt werden muss. Nutzen Sie eine Aufgabe, wenn die Arbeit Verantwortlichkeit, Status, Ausführungsverlauf oder Review benötigt. Wenn Sie feststellen, dass ein Chat etwas hervorbringt, worauf das Team reagieren muss, wandeln Sie ihn in eine Aufgabe um, damit das Ergebnis eine Aufzeichnung hat.

Wann brauchen Sie eine Crew?

Eine Crew ist eine wiederverwendbare Gruppe aus Menschen und Agenten, die von einem leitenden Agenten koordiniert wird. Für kleine, klar definierte Arbeit weisen Sie die Aufgabe direkt einem Agenten zu und halten die beweglichen Teile bei null. Nutzen Sie eine Crew, wenn der Leiter ein Ziel interpretieren, Spezialisten einbeziehen und deren Ergebnisse in einer Aufgabe zusammenführen muss.

Wann ist ein Skill besser als das Bearbeiten von Anweisungen?

Wenn mehrere Agenten dasselbe Verfahren benötigen (eine Review-Checkliste, ein Migrationsmuster, ein Berichtsformat), verschieben Sie es in einen Skill und binden Sie ihn dort ein, wo er gebraucht wird. Das Handwerk eines Entwicklers wird so zur Infrastruktur der Organisation statt zu einem privaten Prompt.

Was ist mit dem Rest des Teams?

Alles oben Beschriebene funktioniert auch allein. Der Nutzen wächst, wenn Aufgaben in gemeinsamen Spaces leben, Sprints die Arbeit in Zyklen bündeln und Teammitglieder die Ausgaben von Agenten in denselben Ansichten prüfen, die sie bereits für menschliche Arbeit nutzen. Sharklys Projekt-Ebene (Spaces, Projekte, Sprints, Kanban- und Listenansichten) ist so standardmäßig, dass niemand umgeschult werden muss.

Wann Sharkly heute das falsche Tool ist

Eine ehrliche Grenze spart Ihnen Zeit. Wenn Sie ein einzelner Entwickler sind, der einen Agenten in einem Repository ausführt, reichen Ihnen heute vielleicht ein Terminal und ein Branch. Die Koordinationsebene lohnt sich, wenn Läufe sich vervielfachen: mehr als ein Agent, mehr als eine Person, die Ergebnisse sehen muss, oder Arbeit, die vor dem Merge geprüft werden muss.

Dieselbe Logik gilt für selbst gebaute Tools. Selbstgebaute tmux-Sitzungen und Worktree-Skripte funktionieren wirklich; Teams wachsen darüber hinaus, wenn die unsichtbaren Teile (wer was ausgeführt hat, wohin der Diff ging, wer ihn freigegeben hat) mehr kosten, als die Skripte einsparen. Und wenn Ihr Team durchgängig im Ökosystem eines einzigen Anbieters lebt, prüfen Sie zuerst dessen eigene Orchestrierung. Sharklys Stärke zeigt sich am deutlichsten, wenn Sie Tools, Maschinen und Menschen mischen, weil es über alle drei hinweg neutral bleibt. Der breitere Kontext der Kategorie steht in What Is Agentic Coding?, falls Sie das Feld kartieren möchten.

Was in all diesen Fällen gleich bleibt: Behalten Sie die Tools, die Ihr Team bereits nutzt. Sharklys Einführungspfad besteht darin, eine sichtbare, prüfbare Ebene um sie herum hinzuzufügen, nicht darin, den darunterliegenden Workflow zu ersetzen.

Drei erste Durchläufe, die in der Praxis funktionieren

Das vorsichtige Plattform-Team. Ein DevEx-Engineer verbindet einen gemeinsam genutzten Linux-Computer, erstellt einen schreibgeschützten Code-Reader-Agenten und lässt Teammitglieder eine Woche lang Untersuchungsaufgaben zuweisen. Niemand erteilt Schreibzugriff, bis die Berichte sich als vertrauenswürdig erweisen. Die Akzeptanz breitet sich aus, weil die Ausführungsprotokolle das Urteilsvermögen des Agenten nachprüfbar machen.

Der Solo-Entwickler, der skaliert. Ein Entwickler verbindet einen Laptop, erstellt zwei Agenten (einen für die Implementierung, einen für das Review) und beginnt, kleine Bugs über Aufgaben statt über Ad-hoc-Prompts zu steuern. Der unmittelbare Gewinn ist nicht Geschwindigkeit; es ist die Tatsache, dass jeder Fix jetzt eine Beschreibung, einen Diff, ein Protokoll und eine Aufzeichnung dessen hat, was geprüft wurde.

Das Jira-zentrierte Team. Ein Engineering-Manager behält Jira als Planungsquelle und verbindet Sharkly, damit Tickets zu ausführbaren Aufgaben werden. Entwickler hören auf, Ticket-Kontext in Terminals zu kopieren. Ergebnisse, Blocker und Review-Anfragen kehren zur Aufgabe zurück, wo der Manager sie sehen kann.

Ihre nächsten zehn Minuten

Der kleinste nützliche Sharkly-Workflow ist bewusst klein: einen Computer verbinden, einen Agenten erstellen und eine risikoarme Aufgabe zuweisen. Jede fortgeschrittene Fähigkeit (parallele Worktrees, Crews, Skills, Automatisierungen, Sprints) baut auf diesem Kreislauf auf, ohne ihn zu verändern.

Führen Sie also den Kreislauf aus. Verbinden Sie einen Computer, erstellen Sie einen Agenten und weisen Sie ihm etwas Langweiliges zu. Prüfen Sie das Ergebnis so, wie Sie den ersten PR eines neuen Teammitglieds prüfen würden: mit Aufmerksamkeit, einer Grenze und einer Rückfrage. Entscheiden Sie dann anhand von Belegen, was Sie als Nächstes gewähren. Der Quickstart in der Dokumentation spiegelt diese Schritte mit aktuellen Screenshots, wenn Sie bereit sind zu starten.

Häufig gestellte Fragen

Welche Coding-Agenten funktionieren mit Sharkly?

Sharkly erkennt unterstützte Agenten-Tools, die auf einem verbundenen Computer installiert sind, und meldet jedes als Runtime. Claude Code, Codex, Gemini CLI und OpenCode gehören zu den in der offiziellen Dokumentation genannten Tools. Die Detailseite des Computers zeigt die aktuell unterstützte Auswahl für Ihre Maschine, mit einem Link zur Installationsanleitung pro Runtime, und Sie können eine benutzerdefinierte ACP-Runtime hinzufügen, wenn ein Tool nicht automatisch erkannt wird.

Ersetzt Sharkly Claude Code oder Codex?

Nein. Sharkly ist kein Ersatz für Claude Code, Codex oder andere Ausführungstools. Diese Tools führen die eigentliche Agenten-Sitzung auf Ihrem Computer aus. Sharkly ergänzt die gemeinsame Ebene um sie herum: Zuweisung auf Teamebene, Aufgabenkontext, Fortschritt, Ergebnisse und menschliche Prüfung. Sie nutzen die Agenten-Tools und Konten weiter, die Sie bereits haben.

Wie viel kostet Sharkly?

Sharklys Modell ist „Bring your own Subscription“: Die Modellnutzung läuft über die Abonnements oder API-Schlüssel, die in Ihren Agenten-Tools konfiguriert sind, und Ihr Kontingent hängt von den Tarifen ab, die Ihr Team verbindet. Aktuelle Produkttarife finden Sie direkt auf sharkly.ai, da dieser Artikel keine Preise nachverfolgt.

Laufen mein Code und meine Zugangsdaten über Sharklys Server?

Die Ausführung findet auf Computern statt, die Sie verbinden: Ihr Laptop, Ihre Server oder Ihre Container. Der Computer stellt das Betriebssystem, die Dateien, Zugangsdaten und Tools bereit, und der lokale Dienst überträgt Fortschritt und Ergebnisse zurück an die Aufgabe. Repositories werden mit dem Git-Zugriff abgerufen, der auf diesem Computer konfiguriert ist.

Warum startet mein Agent keinen Lauf?

Prüfen Sie drei übliche Ursachen der Reihe nach. Erstens: Die Aufgabe liegt möglicherweise im Backlog; zugewiesene Aufgaben warten dort, bis sie in einen für Arbeit bereiten Status verschoben werden. Zweitens: Die Runtime ist möglicherweise nicht nutzbar; ein online befindlicher Computer bestätigt nur Heartbeats, also öffnen Sie die Computer-Detailseite und prüfen Sie den Fähigkeitsstatus der Runtime. Drittens: Die Kapazität ist möglicherweise ausgelastet; ein online befindlicher Agent kann Arbeit dennoch in die Warteschlange stellen, wenn Parallelitäts- oder Verzeichnislimits erreicht sind.

Können zwei Agenten gleichzeitig am selben Repository arbeiten?

Ja, mit temporären Arbeitsverzeichnissen. Jede Aufgabe erhält ein isoliertes Verzeichnis, und repository-gestützte Läufe bereiten pro Lauf einen separaten Git-Worktree vor, was Störungen zwischen gleichzeitigen Aufgaben reduziert. Bei festgelegten Verzeichnissen ist es umgekehrt: Ein konfigurierter Pfad bedient jeweils nur einen Lauf.

Kann ich Sharkly-Agenten auf einem Remote-Server ausführen?

Ja. Installieren Sie die Sharkly CLI und den lokalen Dienst auf dem Remote-Host und registrieren Sie ihn dann mit einem einmaligen Installations-Token von der Computers-Seite. Der lokale Dienst verbindet sich nach außen mit Sharkly, sodass ein typisches Setup keinen eingehenden Port benötigt. Remote-Computer eignen sich für gemeinsame Team-Kapazität; Laptops für persönliches Experimentieren.

Was sollte meine erste Aufgabe sein?

Etwas Schreibgeschütztes mit einer klaren Grenze und einem prüfbaren Ergebnis. Die Dokumentation schlägt vor, einen Authentifizierungs-Fehlerpfad zu prüfen und drei für Nutzer sichtbare Fehlerfälle mit Belegen zu melden, ohne Dateien zu bearbeiten. Jeder kleine, reale Bereich Ihrer Codebasis funktioniert. Vermeiden Sie vage erste Aufgaben wie „verbessere den Code“; was Sie nicht abgegrenzt haben, können Sie nicht prüfen.