Einführung in die Funktion für parallele Agents in Zed

 (zed.dev)
10 Punkte von GN⁺ 6 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • Es wurde so erweitert, dass sich mehrere Agent-Threads parallel im selben Fenster ausführen und koordinieren lassen. In der neuen Threads Sidebar kann man den Zugriffsbereich jedes Threads auf Ordner und Repositories steuern und den Ausführungsstatus zentral einsehen.
  • Für jeden Thread lassen sich unterschiedliche Agents auswählen und kombinieren. Ein einzelner Thread kann projekt- und repositoryübergreifend lesen und schreiben, und bei Bedarf ist auch Worktree-Isolierung pro Thread möglich.
  • Das Standard-Layout wurde ebenfalls rund um die Threads Sidebar neu angeordnet: Threads und Agent Panel befinden sich links, Project Panel und Git Panel wurden nach rechts verschoben. Bestehende Nutzer können dieses Layout per Opt-in aktivieren.
  • Statt der beiden Extreme, AI entweder vollständig machen zu lassen oder vollständig auszuschließen, liegt der Fokus auf der direkten Arbeit am Code in Kombination mit AI-Tools, um vertrauenswürdige und gut entworfene Systeme zu bauen.
  • Direkt in der neuesten Zed-Version nutzbar und zusammen mit der 120-fps-Umgebung, der frei wählbaren Agent-Struktur und der Open-Source-Veröffentlichung stärkt dies den Workflow für große Agent-Aufgaben in einem einzigen Fenster.

Parallele Agents

  • Zed wurde so erweitert, dass mehrere Agents parallel in demselben Fenster ausgeführt und koordiniert werden können.
    • Mit Parallel Agents lassen sich mehrere Threads gleichzeitig betreiben.
    • In der neuen Threads Sidebar kann genau gesteuert werden, auf welche Ordner und Repositories jeder Thread zugreifen darf.
    • Laufende Threads lassen sich an einer Stelle überwachen.
  • Die Funktion läuft in Zeds 120-fps-Umgebung, man kann den gewünschten Agent auswählen, und das Ganze ist Open Source.

Viele Threads, ein Fenster

  • Die Threads Sidebar zeigt alle Threads nach Projekten gruppiert an und erleichtert so die gleichzeitige Arbeit mit mehreren Agent-Aufgaben.
    • Pro Thread können unterschiedliche Agents kombiniert werden.
    • Mit dem Ansatz choose your agent ist die Auswahl auf Thread-Ebene möglich.
  • Es kann projektübergreifend gearbeitet werden, und ein einzelner Agent-Thread kann über mehrere Repositories hinweg lesen und schreiben.
  • Bei Bedarf lässt sich Worktree-Isolierung aktivieren, ebenfalls pro Thread.
  • In der Sidebar können gemeinsame Aktionen wie Thread stoppen, archivieren oder einen neuen Thread starten direkt ausgeführt werden.
  • Auch in komplexen Abläufen, in denen mehrere Agents gleichzeitig in mehreren Projekten laufen, hilft die Sidebar dabei, die Arbeit übersichtlich zu halten.

Neues Standard-Layout

  • Da die Threads Sidebar zum Zentrum der Projektnavigation wird, wurde auch die Anordnung der Panels neu abgestimmt.
    • Threads sind standardmäßig links angedockt und neben dem Agent Panel angeordnet.
    • Project Panel und Git Panel wurden auf die rechte Seite verschoben.
  • Dieses Layout ist besser auf agentic work ausgelegt und sorgt dafür, dass Agent-Threads auch beim Wechsel zwischen Threads im Vordergrund bleiben.
  • Wer eine andere Anordnung bevorzugt, kann die Docking-Position per Rechtsklick auf das Panel-Symbol in der unteren Leiste ändern oder sie im Settings Editor anpassen.
  • Bestehende Nutzer können dieses neue Layout per Opt-in aktivieren.
  • Auch wenn man an das bisherige Layout gewöhnt ist, kann es sich natürlicher anfühlen, das neue Layout erst einmal auszuprobieren, bevor man wieder zurückwechselt.

Die Verbindung von Agent und Editor

  • Die Nutzung von AI kann in Extreme abgleiten, aber ein Ansatz, bei dem man AI nutzt und dennoch direkt am Code arbeitet, passt besser zur Entwicklung hochwertiger Software.
  • Der Beitrag von Software Engineers sollte nicht an der Zahl erzeugter Codezeilen gemessen werden, sondern an vertrauenswürdigen, gut entworfenen und leicht veränderbaren Systemen.
  • Das 2025 eingeführte Konzept des agentic engineering etabliert sich als Verbindung aus menschlicher craftsmanship und AI-Tools, um bessere Software zu bauen.
  • Zeds parallele Agents wurden mit genau diesem Grundsatz im Zentrum entwickelt und zielen darauf ab, die Erfahrung mit groß angelegter Agent-Arbeit zu verbessern.
  • Das System wurde über mehrere Tage hinweg mit Hunderten von Threads getestet, und es gab viele UX-Iterationen sowie lange interne Diskussionen, um auch die rauen Kanten zu glätten, die Entwicklern sonst entgehen könnten.
  • Die Entwicklung dauerte länger und war nicht einfach, aber das Ergebnis ermöglicht es, auch anspruchsvollere Aufgaben mit Agents zu bearbeiten, ohne dabei craftsmanship zu opfern.

Erste Schritte

  • Parallel Agents sind in der neuesten Zed-Version verfügbar.
  • Die Threads Sidebar lässt sich über das Symbol unten links öffnen.
  • Sie kann auch per Tastenkürzel geöffnet werden: unter macOS mit option-cmd-j, unter Linux und Windows mit ctrl-option-j.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 6 일 전
Hacker-News-Kommentare

  • Je mehr ich diesen Workflow nutze, desto besser gefällt er mir. Der echte Game Changer ist, dass man (a) parallele Threads pro Worktree laufen lassen kann und (b) genügend Lifecycle-Hooks hat, um sie fast wie VMs zu behandeln.
    Bei mir wird beim Erstellen eines Worktrees eine lokale Konfigurationsdatei kopiert, und Postgres klont die Dev-/Test-DB, damit isolierte Tests möglich sind. Wenn ich den Worktree schließe, wird auch diese DB mit gelöscht.
    Bisher war Conductor für mich am besten, aber im Unternehmen dürfen wir nur Copilot nutzen und das Backend ist fest auf Claude/Codex eingestellt, daher fällt es aus. Arbor ist ähnlich, wird aber weniger aktiv entwickelt und wirkt an vielen Stellen noch rau, und die Opencode-GUI hat zwar einen Create-Hook, aber keinen Teardown.
    Wenn Zed auch diesen Teil sauber verbindet und dabei seine Identität als guter Editor behält, könnte das das Feld wirklich verändern.

    • Freut mich zu hören. Ich bin der Entwickler von Conductor, und solche Use Cases helfen wirklich sehr.
      Ich arbeite gerade daran, mehr Agenten anzubinden, und besonders oft kommen Anfragen nach Unterstützung für Copilot und das OpenCode-Harness.
      Kürzlich habe ich außerdem einen Ausweg eingebaut. Wenn man unter Settings → Experimental → Big Terminal Mode aktiviert, kann man im mittleren Panel ein neues Terminal öffnen (⌘⇧T) und dort einen beliebigen Agenten wie Copilot oder OpenCode verwenden. Es fehlen noch Dinge wie Benachrichtigungen, daher ist das noch kein rundes End-to-End-Erlebnis, aber bis eine offizielle UI kommt, kann man damit immerhin das gewünschte Harness nutzen.
      Feedback jederzeit gern an charlie@conductor.build
    • Wenn ich nichts missverstehe, sieht das für mich so aus, als ließe sich das auch ohne externe Tools mit ein paar Hilfs-Shell-Skripten umsetzen.
      Man erstellt einen neuen Git-Worktree, kopiert die lokale .env oder andere Konfigurationsdateien und trägt pro Worktree kollisionsfreie Ports und Variablen ein. Das dient dazu, localhost-Konflikte zu vermeiden, und man kann das auch mit Docker lösen.
      Dazu noch ein Teardown-Skript, das den Worktree nach dem Merge in main aufräumt, und für automatisierte Tests vergebe ich auch Chrome-Debug-Port und temporäres User-Data-Verzeichnis pro Worktree unterschiedlich.
      Daher ist mir nicht ganz klar, warum man dafür unbedingt noch eine eigene Bibliothek oder ein separates Tool braucht.
    • Ich habe selbst einen Multi-Agent-Workflow auf Basis von JJ-Workspaces gebaut, der nicht an einen bestimmten Agenten gebunden ist. Damit kann man Codex, Claude oder was auch immer laufen lassen.
      https://www.visualjj.com/learn/parallel-ai-agents
    • In VSCode nutze ich dafür https://github.com/jackiotyu/git-worktree-manager.
      Diese Erweiterung hat before create / before destroy hooks, in die man beliebige Schritte einbauen kann. Bei mir werden dabei die Workspace-Datei des main-Checkouts verlinkt, Pakete installiert und einige Dateien kopiert. Ziemlich praktisch.
    • Ouijit ist ebenfalls einen Blick wert. Ich nutze es bei der Arbeit oft; es konzentriert sich auf die gewünschte Umgebung selbst und gibt einem darin eine Shell, in der man beliebige Tools verwenden kann.
      Bei Bedarf ist auch VM-Isolation pro Worktree möglich.
      https://github.com/ouijit/ouijit

  • Inzwischen scheint klar, dass sich alle in Richtung parallele Agenten und Worktrees bewegen, aber dass Zed das jetzt bringt, hat mich überrascht. Bisher war die Ausrichtung ja eher editorzentriert und AI klar optional.
    Zeds Stärke ist, dass es agentenagnostisch ist, pro Repository automatisch Worktrees anlegt, sodass mehrere Repositories in einem Agenten bearbeitet werden können, und dass die eigene Agenten-UI hochwertig ist statt nur ein Wrapper um eine CLI zu sein. Soweit ich weiß, ist das das erste große Tool mit genau dieser Kombination.

    • Stimmt schon, aber es fehlt noch vieles wie Claude-MCP-Integration.
      Ich hänge das an logfire, um Telemetrie zu sehen, und beim Optimieren oder Diagnostizieren von Bugs ist der Unterschied enorm spürbar. Plugins und Skills gibt es auch noch nicht.
      Trotzdem ist es gut, wie leicht sich der Provider austauschen lässt.

  • Das neue Standard-Layout geht genau in die entgegengesetzte Richtung von dem, was ich möchte.
    Für mich müsste die Reihenfolge Projektbaum | Texteditor | Agentenansicht | Threads sein.
    Auf den meisten Laptops lassen sich ohnehin nur etwa zwei Panels sinnvoll gleichzeitig anzeigen; statt einen Vier-Panel-Workflow zu betonen, sollte man sich eher darauf konzentrieren, Panel-Verwaltung und View-Wechsel einfacher zu machen. Wenn man keinen Ultrawide hat, wären Agents in einem separaten Fenster vermutlich besser aufgehoben.
    Ich nutze Zed viel und es ist nur eine Kleinigkeit, die sich per Einstellung ändern lässt, aber es wirkt wie eine recht symbolische Designentscheidung und stört mich deshalb. Ich hoffe nicht, dass daraus irgendwann die Schlussfolgerung wird, Editing sei weniger wichtig und deshalb werde auch VI mode vernachlässigt.

    • Ich habe auch als Erstes alle Positionen wieder auf den alten Stand zurückgesetzt. Diese erzwungene automatische Layout-Änderung hat mich wirklich genervt.
      Wenn ich mir die Changelogs ansehe, scheint inzwischen der Großteil der Arbeit in die Agenten-Seite zu fließen, und das macht mir Sorgen. Ich mag Zed, weil es ein guter Editor ist, der sich ein wenig mit Agenten auskennt — nicht, weil ich möchte, dass es sich immer stärker in Richtung Agenten-Management zubewegt.
    • Wenn VI-Unterstützung wegfällt, bin ich als Mitwirkender wie als Nutzer sofort weg. Genau das war ursprünglich der Grund, warum ich mit Zed angefangen habe.
      Ich glaube allerdings nicht, dass das unmittelbar passieren wird.
    • Daraus zu schließen, dass man Editing für unwichtig hält und deshalb sogar die VI-Unterstützung streicht, ist schon ein ziemlicher Sprung in der Argumentation.

  • Ich vermeide parallele Agenten eher bewusst. Die kognitive Last wird mir zu groß, und während der Arbeit muss man die Agenten oft immer wieder in eine Richtung lenken, die strukturell noch Sinn ergibt.

    • Stimme zu. Für einfache Aufgaben passt das gut, aber solche Aufgaben gehen auch sequenziell ohnehin schnell.
      Bei komplexeren Aufgaben muss man meist die Thinking-Ausgabe offen lassen und zwischendurch unterbrechen oder Hinweise geben. Tut man das nicht, ist das Ergebnis oft chaotisch, und es ist schwer, das später zu korrigieren. Wenn man zusätzlich noch parallele Prozesse im Blick behalten muss, wird es eher noch schwieriger.
    • Geht mir genauso. Auch die Review-Last steigt, und wenn man zusätzlich noch Code-Review machen muss, zerstört Multitasking die Produktivität fast vollständig.
      In letzter Zeit arbeite ich nur noch jeweils an einer Änderung und bleibe in diesem Fluss, bis ich sie mit voller Überzeugung mergen kann.
    • Stimme vollkommen zu. Je mehr Agenten man startet, desto eher driftet es in Vibe Coding ab und desto weniger bleibt von Guide Coding übrig.
      Irgendwann meldet sich im Kopf das Signal, einfach zu committen und weiterzugehen, und man muss dieser Versuchung aktiv widerstehen.

  • Dass das Standard-Layout Code und Dateibaum verdrängt, um Platz für AI-Tools zu schaffen, gefällt mir nicht besonders.
    Ich mag Zed wirklich sehr und nutze es täglich, aber wenn ich beim ersten Installieren dieses Layout gesehen hätte, hätte ich es vermutlich nicht ernsthaft in Betracht gezogen.
    Ich kann mir gut vorstellen, dass das manche neuen Nutzer abschreckt.

    • Es wird wahrscheinlich eher mehr Nutzer anziehen, als es verliert.
      Andere Tools mit ähnlicher Funktionalität sind meist schwerfällig, fehleranfällig und Electron-basiert.
    • Zum Glück lässt sich das sehr leicht ändern. Für neue Nutzer ist es nur nicht besonders intuitiv.
      Man muss einfach das kleine Panel-Icon in der unteren Leiste rechtsklicken und die Docking-Position wählen; Linksklick schaltet nur die Panel-Anzeige um.
    • Ein 4K-Monitor ist für Editoren inzwischen nicht mehr bloß nett zu haben, sondern fast schon Voraussetzung.
      Schon jetzt habe ich Dinge wie Agent, Editor und Files/Git gleichzeitig offen, und wenn noch ein viertes Panel dazukommt, wird es bei niedriger Auflösung viel zu eng. Ich habe zwar einen 4K-Monitor, nutze aber normalerweise halb den Bildschirm für den Editor und halb für den Browser oder andere Fenster, deshalb fühlt sich ein Workflow, bei dem der Editor im Vollbild laufen soll, für mich weiterhin etwas unangenehm an.
      Natürlich ist das nur das Standard-Layout und in Zed gibt es wahrscheinlich eine Möglichkeit, das zu ändern. Wenn sich Panels wie in JetBrains-IDEs in oben links / unten links / unten rechts / oben rechts anordnen und gesammelt ein- oder ausblenden ließen, könnte man zum Beispiel Dateien links oben, Agenten links unten platzieren und die Mitte weiter klar auf den Editor ausrichten.
    • Es könnte sogar noch mehr Nutzer anziehen. Ich will den Code eigentlich gar nicht sehen.
      Mir gefällt eine Codex-artige App besser, in der mehrere Projekte an einem Ort zusammenlaufen und endlose Kontextwechsel leicht fallen.
    • Ich hatte anfangs auch diesen Eindruck, aber tatsächlich scheint die Änderung hauptsächlich darin zu bestehen, auf welche Seite links/rechts einzelne Panels gedockt werden, plus etwas Feinschliff am AI-Panel.
      Unter macOS ist ⌘B weiterhin der Toggle für das linke Dock und ⌘R der Toggle für das rechte Dock.
      Wenn man das neue Layout aktiviert, wandern die Panels, die früher links waren, eher nach rechts. Deshalb will ich es sogar für klassisches Coding einmal ausprobieren. In den Einstellungen kann man die Docking-Position jedes Panels ändern.

  • Für mich sind parallele Agenten eher die Ausnahme als der Standard. Vielleicht liegt das an mir, aber für solche Ausnahmefälle reichen auch einfach ein paar zusätzliche Terminalfenster.
    Ich bin nicht sicher, ob das wirklich der primäre Workflow sein sollte. Mein Gehirn funktioniert besser, wenn ich mich tief in ein Problem eingraben kann.

    • Ich bin exakt derselbe Typ, freue mich auf dieses Update aber trotzdem ziemlich.
      Wichtiger als die parallele Ausführung selbst ist für mich, leicht zwischen Threads wechseln zu können. So kann ich in einem Neben-Thread allerlei Recherche betreiben, ohne den eigentlichen Bearbeitungskontext zu zerreißen.
    • Früher habe ich das fast nie genutzt, inzwischen würde ich es aber gern ausprobieren. Denn so lassen sich Spin-up / Tear-down für beliebige Aufgaben isoliert behandeln.
      Zum Beispiel, indem man vor dem eigentlichen Editieren erst einmal einen Änderungsentwurf vorbereitet oder vor einem Review einen Branch auscheckt und den Code dafür einrichtet.

  • Ich habe Zed ausprobiert und hatte den Eindruck, dass es durchaus als Haupteditor taugt, aber der Mangel an Erweiterungen war schade. TODO-Highlighting, TabOut und andere kleine QoL-Funktionen haben gefehlt, das Springen zu Zeilennummern war nicht so einfach wie in VSCode, und auch der in anderen Kommentaren erwähnte Tab-Filter fehlte mir.
    Außerdem fand ich es seltsam, dass man im Git-Commit-Message-Editor die Schriftgröße nicht einstellen kann.
    Von den neueren Ergänzungen fand ich die Dev-Container-Integration wirklich gut.
    Ich drücke Zed die Daumen.

    • Nur als Hinweis: Es gibt inzwischen eine Erweiterung für TODO-Highlighting. Ich sitze gerade nicht am Rechner, aber sie heißt vermutlich so etwas wie Comments Highlighter.
    • Fehlende Zed-Erweiterungen kann man mit Zed Agents auch einfach selbst bauen.

  • Die Agenten-UI von Zed ist die verwirrendste UI, die ich bisher gesehen habe. Die Icons sind klein und mehrdeutig, und wenn man auf das X klickt, wird mal der Editor geschlossen, mal der Agent und mal das Panel — das Verhalten ist kaum vorhersehbar.
    Ich wollte es wegen der neuen Funktionen noch einmal ausprobieren, habe es aber am Ende wegen dieses unvorhersehbaren Verhaltens wieder gelöscht. Dazu kommt, dass mein abonniertes opencode Go nicht unterstützt wird.

  • Warp hat vor etwa einer Woche etwas Ähnliches veröffentlicht, aber aus meiner Sicht ist Zeds Umsetzung deutlich logischer.
    Ich sollte Zed wohl mal wieder ausprobieren. Gerade ist wieder dieser monatliche Drang da, es vielleicht diesmal mit genau diesem Terminal oder dieser IDE zu versuchen.

    • Ich mag Warp auch, aber irgendetwas daran wirkt opak und verwirrend.
      Vielleicht habe ich die Lernkurve einfach noch nicht richtig genommen, oder es liegt daran, dass es sich noch eher nach Alpha anfühlt und sich oft verändert.

  • Die Funktion Parallel agents scheint auf Git-Worktrees oder lokale Projekte zugeschnitten zu sein, aber gerade dieser Fokus auf lokale Projekte verwässert für mich eher den Kern.
    Mein täglicher Entwicklungs-Workflow ist inzwischen vollständig auf jj workspaces umgestellt, daher werde ich diese Funktion nicht nutzen, solange Zed jj nicht unterstützt.
    Außerdem hat die Änderung jetzt auch noch das Layout unerwartet durcheinandergebracht, und ich weiß momentan nicht einmal genau, wie ich es wieder auf den alten Stand zurücksetze.