Ein Agent, viele Spezialisten: Warum eine persönliche KI Aufgaben weiterleiten sollte, anstatt alles selbst zu erledigen.
Ein persönlicher KI-Assistent funktioniert besser als Orchesterer: Er leitet Aufgaben an Programmier-Agenten, Modelle und einfache Skripte weiter, wobei dabei schrittweise Berechtigungen vergeben werden.
Quellen: I Stopped Trying to Build One AI Agent That Does Everything
Qwen, Nemotron, Gemma, DeepSeek – lokale Inferenz, AWS Bedrock, Azure. Verschiedene Laufzeiten, verschiedene Größen, verschiedene Preise, unterschiedliche Grade an Enttäuschung. Eine Reihe von Experimenten mit Hermes, Codex, OpenCode, lokalen Modellen sowie Cloud-APIs beginnt in der Regel mit der Annahme, dass es ein einziges korrektes Modell zu finden gibt. Früher oder später stellt sich heraus, dass das der falsche Ansatz ist. Hinter dieser Annahme verbirgt sich eine zweite, interessantere: Warum sollte der persönliche Agent eigentlich alles selbst erledigen?
Der Jarvis-Traum
Die erste Architektur ist fast peinlich einfach: ein Mensch, anschließend ein Agent, und danach alles andere.
Die Nachrichten an diesen Agenten könnten lauten: Überprüfung der Projekte, Behebung eines Problems in einem der Repositorien, Aufstellung des Kalenders für morgen, Meldung darüber, ob der Linux-Server in Ordnung ist, Recherche zu einem Thema und Rückgabe der wichtigsten Teile. Der Agent soll all das bewältigen.
Es klingt wunderbar – doch genau hier fangen die Probleme an, denn alles stellt eine enorme API-Oberfläche dar.
Für einige Aufgaben gibt es bereits bessere Tools
Programmierung ist das klarste Beispiel. Codex und OpenCode sind keine einfachen Chat-Fenster, die an ein Modell angehängt sind. Sie arbeiten innerhalb einer Programmierumgebung. Sie verstehen die Struktur von Repositorien, lesen und suchen in Dateien, bearbeiten mehrere Dateien gleichzeitig, führen Befehle aus, prüfen Fehler, führen Tests durch, betrachten Unterschiede und iterieren. Das ist eine Menge spezialisierter Funktionen.
Nun nehmen wir an, dem persönlichen Agenten wird gesagt, eine Funktion in einem Projekt umzusetzen. Es gibt zwei mögliche Ansätze.
Ansatz A. Geben Sie dem Agenten ein sehr leistungsstarkes Modell, Zugriff auf das Dateisystem sowie Shell-Zugriff. Lehren Sie ihm Repository-Operationen. Entwickeln Sie Funktionen für Kontextverwaltung, Diff-Verarbeitung, Befehlsausführung, Testschleifen und Fehlerbehebung. Verbessern Sie kontinuierlich den Programmierworkflow. Herzlichen Glückwunsch: Ein Programmieragent wird von Grund auf neu erstellt.
Ansatz B. Der Agent erkennt eine Programmieraufgabe und leitet sie an Codex oder OpenCode weiter. Das ist eindeutig sinnvoller.
Ein Assistent muss nicht in allem der Beste sein
Das erfordert eine echte Denkweiseänderung. Ein persönlicher Assistent muss nicht der beste Programmierer, Forscher, DevOps-Engineer, Planer oder Wissenssystem der Welt sein. Er muss wissen, wer die Arbeit übernehmen sollte. Das ist eine andere Verantwortung – und möglicherweise sogar wichtigere.
Menschliche Organisationen funktionieren auf dieselbe Weise. Ein Geschäftsführer schreibt nicht jede Backend-Funktion, konfiguriert nicht jeden Kubernetes-Cluster, erforscht nicht jeden Markt, erstellt nicht jede Tabellenkalkulation, bucht nicht jedes Treffen oder beantwortet nicht jede Support-Anfrage. Ihr Wert ergibt sich teilweise daraus, dass sie verstehen, was erledigt werden muss, wer es übernehmen sollte und ob das Ergebnis akzeptabel ist. Ein persönlicher AI-Orchestrator kann in diesem Sinne betrachtet werden. Er erledigt nicht jede Aufgabe, versteht aber die Absichten gut genug, um die Arbeit richtig zuzuweisen.
Eine andere Form von System
Ersetzen Sie die Kette aus Mensch, Agent, einem riesigen Modell und allem anderen durch etwas wie dieses:
┌──────────────┐
│ Me │
└──────┬───────┘
│
▼
┌─────────────────┐
│ Google Chat │
└────────┬────────┘
│
▼
┌─────────────────┐
│ Hermes │
│ Orchestrator │
└────────┬────────┘
│
┌─────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
Coding Agents AI Models Tools
Codex/OpenCode Local / Cloud APIs / Servers
│ │ │
└─────────────────┼──────────────────┘
│
▼
Final Result
Die Aufgabe des Assistenten wird deutlich klarer. Er versteht die Person, kennt die verfügbaren Fähigkeiten, wählt die richtige aus, liefert den notwendigen Kontext, beobachtet das Ergebnis und berichtet zurück. Das ist ein Assistent, den man wirklich haben möchte.
Chat als einzige Eingangstür
Ein Chat-App wie Google Chat erhält in diesem Design Bedeutung. Sie sollte die darunterliegende Komplexität nicht offenbaren. Für den Benutzer gibt es nur ein Gespräch. Eine Nachricht wie „Überprüfen Sie, ob heute etwas Wichtiges mit Projekt X passiert ist“ könnte dazu führen, dass der Assistent das Aufgabensystem konsultiert, GitHub prüft, den Serverzustand überprüft, relevante Materialien liest, vielleicht ein anderes Modell um Analyse bittet und anschließend zusammenfasst. Der Benutzer sollte nichts davon wissen müssen und auch keine fünf Anwendungen öffnen müssen. Die Benutzeroberfläche repräsentiert die Absicht, alles darunter ist die Implementierung.
Programmieren als Modellfall
Bild von jemandem, der nicht am Computer ist. Eine Nachricht per Telefon besagt, es gäbe ein Problem im Authentifizierungsprozess von Projekt X, und bittet um eine Lösung, falls diese einfach ist. Im Prinzip verläuft die Kette wie folgt: Der Agent ermittelt, um welches Projekt es geht, sammelt genügend Kontextinformationen, um den Repository zu finden, erkennt, dass der Code geändert werden muss, und delegiert die Aufgabe an einen Programmieragenten. Codex oder OpenCode öffnet das Repository, untersucht es, bearbeitet die relevanten Dateien, führt Tests durch, prüft die Änderungen und gibt das Ergebnis zurück. Der Orchestrierer erhält dieses Ergebnis und meldet beispielsweise: Die Validierung des Refresh-Tokens verwendete die falsche Ablaufbedingung, der Programmieragent hat es behoben, die relevanten Tests bestehen, und hier sind die Änderungen.
Welches Modell auf dem Weg welches Token erzeugt hat, ist kaum von Bedeutung. Entscheidend ist, dass die Aufgabe richtig erledigt wurde.
Modelle werden zu Infrastruktur
Sobald der Agent eine Orchestrierungsschicht darstellt, schließen sich Fragen wie die nach der Verwendung von Qwen, DeepSeek, einem lokalen Modell, Bedrock oder Azure nicht mehr gegenseitig aus. Die Antwort kann einfach ja lauten, wobei unterschiedliche Modelle für unterschiedliche Aufgaben eingesetzt werden. Ein kleines lokales Modell kümmert sich um einfaches Routing, ein günstiges Cloud-Modell erstellt Zusammenfassungen, ein leistungsstärkeres Reasoning-Modell trifft die schwierigen Entscheidungen und ein Programmieragent kümmert sich um Repositorien. Ein weiterer Spezialist übernimmt andere Arbeiten. Modelle werden zur Infrastruktur, und Infrastruktur sollte austauschbar sein.
Vermeidung der Abhängigkeit von einem einzigen Anbieter
Modelle ändern sich in atemberaubendem Tempo. Was heute als offensichtliche Wahl gilt, kann bereits nach sechs Monaten mittelmäßig erscheinen. Die Preise ändern sich, Anbieter wechseln, offene Modelle verbessern sich, Kontextfenster werden größer, die Funktionalitäten zur Aufrufung von Tools werden besser und es erscheinen neue Inferenzarchitekturen. Wenn die gesamte persönliche Einrichtung davon ausgeht, dass Modell X alles kann, ist ein Wechsel problematisch. Eine bessere Vorgehensweise ist:
Task
↓
Router
↓
Best available capability
Heute könnte der letzte Schritt bei einem Anbieter liegen und morgen bei einem anderen – das Workflow sollte sich darum nicht kümmern.
Der Router kann wichtiger sein als das Modell
Sehr viel Zeit wird damit verbracht, Modelle miteinander zu vergleichen: A erhält 74 Punkte, B 78 Punkte, C verfügt über eine Million Kontext-Token, D kostet 60 Prozent weniger. Diese Informationen sind nützlich. Stellen Sie sich nun ein System vor, das weiß, dass A am besten für bestimmte kodierungsbezogene Aufgaben geeignet ist, B schnell und günstig für die Klassifizierung, C überflüssig ist, weil die Anfrage lokal beantwortet werden kann, eine weitere Anfrage überhaupt kein LLM benötigt, sondern nur einen API-Aufruf, eine Anfrage direkt an Codex weitergeleitet werden sollte und eine weitere eine Frage an den Benutzer erfordert, bevor etwas geschieht.
Hier liegt ein Teil der Intelligenz im System, das entscheidet, wie die Intelligenz eingesetzt wird – was weitaus interessanter ist als eine weitere Rangliste.
Nicht jeder Schritt benötigt ein LLM
Die Agenten sorgen dafür, dass man das leicht vergisst. Wenn gefragt wird, ob ein Server online ist, benötigt ein Agent kein 200-Milliarden-Parameter-Reasoning-Modell, um zu prüfen, ob der Server existiert. Er führt einen Health-Check durch, interpretiert das Ergebnis und antwortet. Wenn gefragt wird, wie viel Speicherplatz noch verfügbar ist, führt er Folgendes aus:
df -h
Dann wird die Ausgabe analysiert und eine Antwort gegeben. Ein teures Reasoning-Modell bei jedem Schritt ist keine Intelligenz – manchmal handelt es sich dabei einfach um schlechte Ingenieursarbeit.
Berechtigungen
Sobald ein Agent Aufgaben delegieren kann, stellt sich das schwierigere Problem: Was darf er tun? Ein Kalender einsehen unterscheidet sich von der Versendung einer E-Mail. Ein Repository einsehen unterscheidet sich von der Zusammenführung eines Pull-Requests. Einen Server überprüfen unterscheidet sich stark vom Löschen von Dateien. Ein nützlicher persönlicher Agent benötigt daher zusammen mit seinen Tools ein Berechtigungsmodell, ungefähr wie folgt:
- Das Einsehen von Inhalten erfolgt ohne Anfrage.
- Das Erstellen von Entwürfen und Plänen erfolgt ohne Anfrage.
- Aktionen mit geringem Risiko können eigenständig ausgeführt werden.
- Alle bedeutungsvollen Aktionen erfordern eine Zustimmung des Menschen.
Wenn gefragt wird, warum ein Service nicht funktioniert, kann der Agent direkt mit der Lösung beginnen. Sollte er feststellen, dass die Datenbank beschädigt ist und sie löschen sowie neu erstellen wollen, sollte zuerst eine Bestätigung erfolgen. Autonomie sollte nicht binär sein – sie sollte je nach Risiko gestuft werden.
Gedächtnis und Kontext
Ein weiterer Grund dagegen, jedes spezialisierte Tool in einen persönlichen Assistenten umzuwandeln, ist der Kontext. Codex sollte das Repository verstehen, aber nicht das gesamte Leben des Benutzers. Ein Infrastrukturtool sollte die Server kennen, aber nicht jedes je geführte Gespräch. Der Kalender kennt Termine und der Aufgabenmanager kennt Aufgaben. Der Orchestrator kann die Schicht werden, die versteht, wie sich diese Systeme gegenseitig beziehen.
Nehmen wir die Frage, was mit einem bestimmten Projekt vor sich geht. Keine einzige Datenbankabfrage kann diese Frage beantworten. Eine gute Antwort berücksichtigt aktuelle Entwicklungsarbeiten, Aktivitäten auf GitHub, Aufgaben, frühere Entscheidungen, den Bereitstellungsstatus sowie das, was der Benutzer als Nächstes vorhatte. In diesem übergeordneten Kontext mehrerer Systeme wird eine persönliche Orchestrierungsschicht wirklich wertvoll.
Die Falle des Überengineering
Die Gefahr ist offensichtlich. Wenn man so denkt, ist es einfach, ein Diagramm wie dieses zu erstellen:
User
↓
Intent Classifier
↓
Planning Agent
↓
Model Router
↓
Memory Agent
↓
Permission Agent
↓
Coding Agent
↓
Validation Agent
↓
Reflection Agent
↓
Supervisor Agent
↓
Another Agent Watching the Other Agents
Und dann drei Monate damit verbringen, eine KI-Organisation aufzubauen, damit man fragen kann, was heute auf dem Kalender steht. Das hilft niemandem. Die Lektion aus dem gesamten Experiment ist, dass Komplexität ihren Platz erst verdienen muss. Zwölf Agenten nur, weil ein Architekturdiagramm cool aussieht, ist ein schlechter Grund. Fähigkeiten, die wiederholt Zeit sparen, sind ein guter Grund.
Delegation vor Autonomie
Vollständig autonome Agenten erhalten viel Aufmerksamkeit: Man gibt ihnen ein Ziel, lässt sie stundenlang arbeiten, erlaubt den Agenten, miteinander zu kommunizieren und selbst Entscheidungen zu treffen, und kehrt erst zurück, wenn alles erledigt ist. Das ist interessant, aber es ist nicht der richtige Ausgangspunkt für ein persönliches System. Hoch zuverlässige Delegation sollte vor maximaler Autonomie kommen. Das Ziel ist es, „Mach X“ zu sagen und das System dazu zu bringen, zuverlässig das richtige Werkzeug oder den richtigen Agenten auszuwählen und Bericht zu erstatten, was passiert ist. Sobald das hervorragend funktioniert, kann die Autonomie schrittweise gesteigert werden.
Mehr spezialisierte Tools, nicht weniger
Zu Beginn scheint das Ziel die Konsolidierung zu sein: Zu viele KI-Tools, daher soll eine einzige KI entwickelt werden, die sie ersetzt. Das erweist sich jedoch als falsch. Der Endzustand könnte durchaus mehr spezialisierte KI-Systeme beinhalten, wobei der Unterschied darin besteht, dass sie nicht mehr individuell verwaltet werden müssen – genau das löst die Orchestrierungsschicht. Die Zukunft könnte weniger darin bestehen, dass eine einzige KI alles steuert, und mehr darin, dass eine einzige Schnittstelle alles koordiniert. Der Unterschied ist subtil, aber bedeutend.
Wofür der Agent da ist
Nach dem Betrieb eines solchen Systems, dem Zerstören von Komponenten, dem Aufbau einer Chat-Schnittstelle, dem Ausprobieren von Modellen sowie intensiven Überlegungen zu spezialisierten Programmieragenten rückt die Rolle des persönlichen Agenten in den Vordergrund. Er muss nicht die intelligenteste KI im gesamten System sein – er muss vielmehr diejenige sein, die die Person sowie deren Systeme kennt. Er sollte verstehen, was gefragt wird, welcher Kontext relevant ist, welche Fähigkeit geeignet ist, was er tun kann, wann er Bestätigung benötigt und wie er das Ergebnis zurückgeben kann. Das reicht aus, und alles Weitere kann delegiert werden.
Die Architektur, die man sich wünschen sollte
Das Ziel sieht ungefähr so aus:
ME
│
▼
GOOGLE CHAT
│
▼
┌─────────────────┐
│ HERMES │
│ │
│ Intent │
│ Context │
│ Memory │
│ Permissions │
│ Orchestration │
└────────┬────────┘
│
┌──────────────────┼───────────────────┐
│ │ │
▼ ▼ ▼
AI MODELS CODING AGENTS TOOLS
│ │ │
Local / Cloud Codex/OpenCode GitHub/APIs
Fast / Strong Servers/Tasks
│ │ │
└──────────────────┼───────────────────┘
│
▼
HERMES
│
▼
ME
Es geht nicht darum, einzelne Komponenten zu verwenden. Alles, was unter dem Orchesterator liegt, sollte letztendlich austauschbar sein. Ein besseres Kodierungsmodul wird verfügbar: man ersetzt es einfach. Ein besseres lokales Modell wird verfügbar: man ersetzt es ebenfalls. Die Cloud-basierte Inferenz wird günstiger: man leitet mehr Aufgaben dorthin um. Ein Anbieter wird unzuverlässig: man umgeht ihn einfach. Es sollte niemals notwendig sein, jedes Mal, wenn sich die KI-Industrie verändert, die Nutzung des Assistenten neu zu gestalten.
Persönliche KI – möglicherweise rückwärts
Die meisten KI-Produkte konkurrieren darum, wie intelligent das Modell ist – was verständlich ist. Doch je weiter sich die Modelle verbessern, desto wichtiger wird eine weitere Komponente: die Koordination. Das bedeutet, zu wissen, was die Person meint, in welchem Kontext sie sich befindet, welche Systeme relevant sind, welche Tools vorhanden sind, welches Modell am besten passt, welche Aktionen sicher sind, wann man nachfragen sollte und wann man KI überhaupt nicht verwenden sollte. Der Assistent, den man haben möchte, ist nicht unbedingt der mit der höchsten Benchmark-Wertung – sondern der, der all die Intelligenz und Software um die Person herum wie ein einziges System erscheinen lässt.
Kurzfassung des Fazits
Der Ausgangspunkt ist der Wunsch nach einem persönlichen KI-Assistenten. Die Implementierung eines solchen Assistenten zeigt, dass ein ständig verfügbarer Helfer in Wirklichkeit ein Infrastrukturproblem darstellt. Die Suche nach dem perfekten Modell verdeutlicht, dass die Modellwahl im Grunde ein Routing-Problem ist. Die Entscheidung darüber, was der Assistent tun soll, zeigt, dass ein persönlicher Assistent im Kern ein Orchestrierungsproblem sein kann. Die Architektur wandelt sich von der Suche nach dem klügsten Modell und der Bereitstellung aller möglichen Werkzeuge für dieses Modell zu einem System, das Absichten erfasst und Aufgaben an den richtigen Ort leitet. Es handelt sich dabei um eine weitaus weniger „magische“ Beschreibung von Jarvis, aber um eine, die einer Lösung, die tatsächlich gebaut und täglich genutzt werden kann, viel näher kommt.
Verwandte Artikel
- Ein Planungsagent in LangGraph erstellen: Planen, Ausführen, Neuplanen, Berichten — Ein vier Knoten umfassender Planungsagent von LangGraph für Finanzforschung: strukturierte Pläne, ein namensraumbewusstes Tool-Register, Neuplanungsgrenzen sowie ein nachvollziehbarer Beispielaufruf.
- MiniCPM5-2B gegen 4B-Konkurrenten: Warum ein agenter Ansatz eine andere Geschichte erzählt — Ein 2,5 Milliarden Parameter umfassendes Modell, das bei Einzelversuchen bessere Ergebnisse erzielt als 4B-Modelle, liegt in agierenden Umgebungen zwei bis drei Mal zurück. Ursachen sind Verwechslungen bei Index-Versionen, lokale Durchsatzleistung sowie die passenden Anwendungsszenarien.