Eigent v1.0.4 Release Notes: Dashboards für Skills und Connectors, stabile Multi-Turn-Läufe

Eigent v1.0.4 ist ein Release über Lesbarkeit im Workspace. Skills und Connectors waren bisher gestapelte Einstellungskarten; jetzt sind es bibliotheksartige Dashboards mit echten Sammlungsansichten, Detailseiten und einer gemeinsamen Page-Shell, die Home, Skills und Connectors zusammen nutzen.

Unterhalb dieser Oberfläche schließt dieses Release eine Reihe konkreter Lücken, die erst auftraten, als Tasks länger liefen: Anweisungen, die zwischen verketteten Modellzügen verloren gingen, Checkpoints, die scheiterten, sobald ein Task ein Repository in einem Space klonte, Connectors, die einen anderen Zustand zeigten als die Runtime, die sie tatsächlich ausführen würde, und eine App, die beim Schließen des letzten Fensters nicht sauber beendet wurde.

---

🧩 Skills und Connectors als Verwaltungs-Dashboards

Eine Skill zu verwalten sollte nicht bedeuten, eine Einstellungsseite zu scrollen, bis die richtige Karte auftaucht.

Danke an @Douglasymlai für den Umbau von Skills und Connectors zu Sammlungs- und Detailflächen in PR #1896 und an @4pmtong für das Review.

Skills ist jetzt ein bibliotheksartiges Dashboard. Jede Skill öffnet sich in einer eigenen Detailansicht, die zeigt, woher sie stammt, welchen Zugriff sie hat, ob sie aktiviert ist und welche Dateien sie enthält. Connectors folgt demselben Modell: eine Sammlungsübersicht, ein Ablauf zum Hinzufügen und Erkunden sowie ein Profilkopf mit Icon, Name, Quelle und der Aktion zum Installieren oder Speichern.

Neu:

• Skills-Bibliotheks-Dashboard — durchsuchen Sie Ihre Skills als Sammlung statt als Stapel von Einstellungskarten
• Skill-Detailansichten — Quell- und Zugriffs-Tags, Aktivierungsstatus und Dateibrowser an einem Ort
• Connector-Sammlung und -Entdeckung — ein klarerer Weg vom Erkunden verfügbarer Connectors bis zur Konfiguration
• Connector-Detailkopf — Icon, Name, Quelle sowie Installieren oder Speichern als Profil dargestellt
• Detail-Seitenleisten — der begleitende Kontext bleibt neben der Ressource, die Sie gerade prüfen

Der praktische Unterschied ist die Nachvollziehbarkeit. Sie können beantworten, „woher diese Skill kommt, worauf sie zugreifen kann und was in ihr steckt“, ohne die Seite zu verlassen, auf der Sie begonnen haben.

🔗 PR: https://github.com/eigent-ai/eigent/pull/1896

---

🏠 Eine gemeinsame Page-Shell für Home, Skills und Connectors

Konsistenz ist ein Feature, wenn man dieselbe App täglich benutzt.

v1.0.4 führt Home und Einstellungen in einer einzigen Page-Shell zusammen, gebaut aus gemeinsamen Primitiven: einer Sammlungs-Toolbar, einem Breadcrumb, einer Content-Rail und einem Zurück-Header in der Seitenleiste. Hub-Listen auf Home, leere Zustände und Space-Detail-Tabs folgen jetzt demselben Sammlungs-Layout wie Skills und Connectors.

Verbessert:

• Gemeinsame Layouts — derselbe Header, dasselbe Breadcrumb und dieselbe Lese-Rail in Home, Skills und Connectors
• Einheitliche Sammlungslisten — Hub-Listen und Space-Detail-Tabs folgen einem Layoutmodell
• Klarere leere Zustände — eine nicht konfigurierte Fläche erklärt sich selbst, statt ein leeres Panel zu zeigen
• Vorhersehbare Navigation — Breadcrumbs und Zurück-Header verhalten sich überall gleich

Sobald die Shell geteilt wird, muss man beim Wechsel zwischen Home, einem Space, einer Skill und einem Connector die Seite nicht jedes Mal neu lernen.

🔗 PR: https://github.com/eigent-ai/eigent/pull/1896

---

🔁 Multi-Turn-Arbeit, die ihre Anweisungen behält

Ein langer Task ist eine Kette von Zügen, und jeder Zug braucht dieselben vertrauenswürdigen Anweisungen.

Danke an @4pmtong für die Behebung der Prompt-Guard-Fehler bei verketteten Anfragen der Responses API in PR #1883.

Die erste Anfrage der Kette war erfolgreich — deshalb blieb die Regression unentdeckt. Folgeanfragen verwendeten previous_response_id erneut, doch die instructions auf oberster Ebene wurden nicht automatisch mitgeführt. So verschwand der vertrauenswürdige Agenten-Prompt mitten im Lauf still und leise.

Behoben:

• Anweisungen bei jeder Anfrage — der vertrauenswürdige Agenten-Prompt wird in jedem Zug über instructions der Responses API gesendet, nicht nur im ersten
• Keine doppelten Prompt-Inhalte — System- und Developer-Elemente werden nach der Übernahme in instructions aus der Eingabe entfernt, was doppelte Token und doppelte Abrechnung vermeidet
• Prompt Guard bleibt intakt — die bestehende Ablehnungsmeldung für nicht vertrauenswürdige Prompts bleibt erhalten

Das ist die Art Fehler, die erst mit der Länge auftritt. Kurze Tasks sahen gut aus; der Ausfall saß im dritten Zug.

🔗 PR: https://github.com/eigent-ai/eigent/pull/1883

---

🧰 Tools mit dynamischen Parameterschemata

Nicht jedes Tool hat eine feste Form, und strenge Schemaprüfung sollte jene nicht ablehnen, die keine haben.

Danke an @fengju0213 für das Anheben von camel-ai[eigent] auf 0.2.91a7 und die Aktualisierung des Backend-Lockfiles in PR #1897.

Das neue CAMEL-Release enthält den Strict-Schema-Fallback, den Tool-Parameter mit offenen Mappings benötigen. Damit behält PlanningWorktreeToolkit.planning_exit_plan_mode sein schemawertiges additionalProperties und wird mit strict: false ausgegeben — das vermeidet eine 400-Antwort auf Anbieterseite und erhält zugleich die dynamischen Dictionary-Felder, die das Tool tatsächlich braucht.

Tools mit offenen Parametern funktionieren nun bei Anbietern, die strenge Schemata erzwingen, statt beim Aufruf zu scheitern.

🔗 PR: https://github.com/eigent-ai/eigent/pull/1897

---

🌿 Verschachtelte Repositories in Git-gestützten Spaces

v1.0.3 gab Spaces eine Git-gestützte Versionshistorie. v1.0.4 sorgt dafür, dass diese Historie einen Task übersteht, der darin ein Repository klont.

Danke an @4pmtong für die Unterstützung verschachtelter Repositories in Workspace-Checkpoints in PR #1902.

Git meldet ein nicht verfolgtes verschachteltes Repository als einzelnen Verzeichniseintrag wie ?? child-repository/. Die Checkpoint-Pipeline normalisierte diesen Pfad zu child-repository, wodurch die Pfadprüfung fehlschlug, nachdem der Klon bereits abgeschlossen war — das Tool-Ergebnis galt als unbekannt und der Lauf scheiterte.

Behoben:

• Verschachtelte Repositories sind eigenständige Grenzen — eine geprüfte, nicht verfolgte verschachtelte Git-Wurzel bleibt aus Checkpoint und Statuszuständigkeit des übergeordneten Repositories ausgenommen
• Kein impliziter Gitlink, keine Ignore-Datei-Änderungen — das übergeordnete Repository wird nicht still umgebaut, um das untergeordnete aufzunehmen
• Der Zustand des Elternteils bleibt unverändert — HEAD, Statustoken und verfolgte Pfade bleiben beim Abschluss des Checkpoints unberührt
• Der Inhalt des Kindes bleibt erhalten — verschachteltes Repository und seine Commits bleiben bestehen
• Worktree-Sicherheit bleibt gewahrt — isolierte Worktrees werden nicht bereinigt, solange sie ein nicht gemergtes verschachteltes Repository enthalten

Ein Repository in einen Space zu klonen ist ganz gewöhnliche Agentenarbeit. Nach diesem Release beendet sie den Lauf nicht mehr.

🔗 PR: https://github.com/eigent-ai/eigent/pull/1902

---

🔌 Connector-Zustände, die zur Runtime passen

Ein Connector, der einen falschen Zustand meldet, ist schlimmer als einer, der gar nichts meldet.

Zwei Korrekturen von @4pmtong behandeln zwei Seiten desselben Problems.

Die Websuche blieb ausgeblendet, wenn sie Konfiguration brauchte. Für Nutzende mit einem benutzerdefinierten Standardmodell galt die Websuche als nicht verbunden, solange Querit nicht aktiviert oder Google-Search-Zugangsdaten nicht hinterlegt waren — und die Connectors-Übersicht filterte jeden nicht verbundenen integrierten Connector heraus. Da diese Zeile zugleich der Einstieg in ihr Einstellungspanel ist, hatten Betroffene gar keine Möglichkeit zur Konfiguration. Die Websuche bleibt jetzt sichtbar und zeigt ihren realen Zustand als Nicht verbunden, während verwaltete Modelle ihren bestehenden Zustand Verbunden behalten. Für alle anderen nicht verbundenen integrierten Connectors bleibt die Filterung unverändert.

Slack meldete verbunden, ohne es zu sein. Im gehosteten Modus behandelte die Einstellungsoberfläche das Vorhandensein einer lokalen Slack-Konfigurationsgruppe als gültige Verbindung, doch gehostete Tasks führen Slack-Aktionen über Connector Gateway aus — wo dieselbe Person womöglich gar keine Slack-Verbindung hat. Das Ergebnis war ein Verbunden-Abzeichen, gefolgt von einem Laufzeitfehler „Verbindung nicht gefunden“. Integrierte Connectors, deren Erstnutzung Connector Gateway gehört, folgen nun einer zentralen Richtlinie: Bei aktiviertem Gateway wird das integrierte Slack auf der Connectors-Seite, im Connector-Auswahlfeld des Chats und bei der Tool-Auswahl neuer Worker ausgeblendet. Bei deaktiviertem Gateway bleibt das integrierte Slack für rein lokale Runtimes verfügbar.

In beiden Fällen funktionieren die bestehende Ausführung des Slack-Toolkits, gespeicherte Konfiguration, die Kompatibilität gespeicherter Worker und die Zugangsdaten von Slack-Triggern weiterhin.

🔗 PR: https://github.com/eigent-ai/eigent/pull/1890

🔗 PR: https://github.com/eigent-ai/eigent/pull/1892

---

🖥️ Sauberes Beenden beim Schließen des letzten Fensters

Die App zu schließen sollte die App beenden.

Danke an @4pmtong für die Korrektur des Beenden-Lebenszyklus in PR #1891. Das Schließen des einzigen Fensters beendet Eigent nun auf allen Plattformen sauber und fährt das lokale Backend mit herunter.

Behoben:

• Ein Beenden-Pfad — natives Fensterschließen, das Fensterschließ-IPC und der Menübefehl Fenster schließen laufen alle über denselben abgesicherten quit-app-Ablauf
• macOS beendet beim letzten Fenster — window-all-closed beendet jetzt auch unter macOS wie unter Windows und Linux, sodass before-quit das lokale Backend aufräumt
• Sicherer Abbau — die gebundene webContents-Referenz wird beibehalten, statt sie aus einem bereits zerstörten BrowserWindow zu lesen
• Zerstörte Objekte werden übersprungen — bei zerstörten Fenstern und Web Contents entfällt das Entfernen von Listenern, und Koordinator-Referenzen werden vor dem Abbau freigegeben

Für die Entwicklung gilt derselbe Gewinn: npm run dev endet nun, statt ein Backend hinter einem geschlossenen Fenster weiterlaufen zu lassen.

🔗 PR: https://github.com/eigent-ai/eigent/pull/1891

---

🧹 Web-Generierungs-Tasks, die verlässlich abschließen

Manche Web-Generierungs-Tasks endeten nicht. Die Ursache waren letztlich zwei Dinge zugleich.

Danke an @4pmtong für die release-sichere Korrektur in PR #1907.

Eigent muss generierte Inhalte nicht mehr in den alten Remote-Deployment-Dienst hochladen. Daher entfällt das Web Deploy Toolkit im Developer Agent von Workforce und im Aufbau des Einzelagenten, und Deployment-Aussagen verschwinden aus dem Prompt des Developer Agent, der Beschreibung des Workforce-Koordinators und den Fähigkeitslisten der Workflows. Alte Toolkit-Konfiguration, die weiterhin web_deploy.enabled=true verlangt, wird ignoriert. web_deploy_toolkit.py und die historische Rendering-Unterstützung bleiben für mögliche spätere Nutzung im Code.

Die zweite Ursache war das Timing. Das Checkpoint-Budget der Terminal-Hintergrundbereinigung steigt von 5 auf 30 Sekunden, damit ein gestoppter Preview-Server seine Schreibfreigabe abgeben und den Git-Checkpoint des Workspace abschließen kann, bevor der Lauf finalisiert wird.

🔗 PR: https://github.com/eigent-ai/eigent/pull/1907

---

⚙️ Schnellere Leitplanken für Mitwirkende

Langsame CI ist eine Steuer auf alle, die einen Pull Request öffnen.

Der Frontend-Leitplanken-Job brauchte regelmäßig 20 bis 30 Minuten, weil er die komplette Vitest-Suite für Basis- und Pull-Request-Commit ohne Caching ausführte und Fehlschläge dann gegen eine Baseline wiederholte, die bereits bekannte Fehler und 29-Sekunden-Timeouts enthielt.

Danke an @4pmtong für den Ersatz dieses Komplettvergleichs durch einen fokussierten Runner in PR #1898.

Verbessert:

• Runner für geänderte Tests — nur die vom Change hinzugefügten oder aktualisierten Frontend-Testdateien laufen
• Schnelle Prüfungen zuerst — Typ-, Electron-, Designsystem- und Formatierungsprüfungen laufen vor Vitest
• Überholte Läufe werden abgebrochen — ein neuer Push bricht den vorherigen Test-Workflow-Lauf desselben Pull Requests oder Branches ab
• Kürzeres Timeout — das Budget der Frontend-Leitplanken sinkt von 30 auf 15 Minuten

In einem Nachlauf gegen den mit PR #1891 gemergten Change verarbeitete der Runner für geänderte Tests 4 Testdateien und 134 Tests in 1,07 Sekunden.

🔗 PR: https://github.com/eigent-ai/eigent/pull/1898

---

🔁 Kompatibilität mit bestehender Arbeit

Bestehende Spaces, Sessions, Tasks, Skill-Einstellungen, gespeicherte Worker und Connector-Konfigurationen bleiben nach dem Upgrade auf v1.0.4 verfügbar. Für die Standarderfahrung ist keine zusätzliche Konfiguration nötig.

Rein lokale Integrationen bleiben ausdrücklich erhalten. Bei deaktiviertem Connector Gateway funktionieren integriertes Slack, gespeicherte Worker und Slack-Trigger weiter, und die gespeicherte Slack-Konfiguration bleibt in beiden Modi unangetastet.

---

❤️ Ein Workspace, der sich selbst erklärt

Eigent v1.0.4 liefert:

• Skills als Bibliotheks-Dashboard mit Detailansichten für Quelle, Zugriff, Aktivierung und Dateien
• Connectors als Ablauf aus Sammlung, Entdeckung und Profildetail
• Eine gemeinsame Page-Shell mit einheitlichen Breadcrumbs, Seitenleisten, Content-Rails und leeren Zuständen in Home, Skills und Connectors
• Vertrauenswürdige Agenten-Anweisungen, die über verkettete Züge der Responses API erhalten bleiben, ohne doppelte Prompt-Inhalte
• Strict-Schema-Kompatibilität für Tools mit dynamischen Parameterschemata
• Verschachtelte Git-Repositories, die bei Workspace-Checkpoints als eigenständige Grenzen behandelt werden
• Eine Websuche, die auffindbar bleibt, solange sie Konfiguration braucht
• Slack, präsentiert über den Connector-Pfad, der es tatsächlich ausführt
• Sauberes Beenden von App und lokalem Backend beim Schließen des letzten Fensters
• Verlässlicheren Abschluss von Web-Generierungs-Tasks und bessere Bereinigung von Hintergrundprozessen
• Eine Frontend-CI-Leitplanke, die Minuten statt einer halben Stunde braucht

Das Thema dieses Releases ist Lesbarkeit. Ein Dashboard sagt Ihnen, was eine Skill erreichen kann. Ein Connector-Zustand sagt Ihnen, welche Runtime ihn ausführt. Ein Checkpoint sagt Ihnen, welches Repository eine Änderung besitzt. Und ein Task, der lange läuft, behält die Anweisungen, mit denen er begonnen hat.

Arbeit, die man prüfen kann, ist Arbeit, der man vertrauen kann.

🔗 Release: https://github.com/eigent-ai/eigent/releases/tag/v1.0.4

🔗 Vollständiger Changelog: https://github.com/eigent-ai/eigent/compare/v1.0.3...v1.0.4

Lassen Sie uns weiterbauen.