🤖 AI

Argus: A General-Purpose Agentic Runtime for Long-Horizon Reasoning

Argus ist eine universell einsetzbare, Fixed-Weight-Agentic-Runtime, die durch die Nutzung eines persistenten, selbstentwickelnden Zustands, der durch spezialisierte Rollen verwaltet wird, um Missionstrajektorien autonom zu verifizieren, wiederherzustellen und zu verfeinern, eine überlegene Langzeit-Reasoning-Leistung über diverse Benchmarks hinweg erreicht.

Ursprüngliche Autoren: Boxiu Li, Zimo Wen, Yijia Fan, Junxiang Lei, Sufeng Guo, Jiaao Wu, Ruize Tang, Mukai Li, Yifei Shen, Xiaoyu Chen, Wanbo Zhang, Runjing Gu, Yifei Gao, Yuheng Wu, Xuyao Huang, Zelong Zhao, Jiachen Zhang

Veröffentlicht 2026-08-06

📖 8 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Boxiu Li, Zimo Wen, Yijia Fan, Junxiang Lei, Sufeng Guo, Jiaao Wu, Ruize Tang, Mukai Li, Yifei Shen, Xiaoyu Chen, Wanbo Zhang, Runjing Gu, Yifei Gao, Yuheng Wu, Xuyao Huang, Zelong Zhao, Jiachen Zhang, Shibo Hu, Hangxi Guo, Yilin Chen, Yuzhe Zhang, Fan Yang, Chuan Wen, Xian Zhang, Xuanhe Zhou, Zhijie Deng

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Der Langstrecken-Detektiv: Warum KI ein Gedächtnis und einen Coach braucht

Stellen Sie sich vor, Sie versuchen, ein riesiges, mehrtägiges Rätsel zu lösen, wie zum Beispiel herauszufinden, wie man einen funktionierenden Roboter von Grund auf neu baut oder einen Roman schreibt, der tatsächlich Sinn ergibt. Wenn Sie ein Computerprogramm von vor ein paar Jahren wären, hätten Sie vielleicht versucht, es zu lösen, indem Sie die Anweisungen lesen, eine Vermutung anstellen und dann sofort alles vergessen, was Sie gerade getan haben, bevor Sie es erneut versuchen. So funktionierten viele frühe KI-„Agenten“: Sie waren wie ein Detektiv, der einen Hinweis löst, dann aber unter totaler Amnesie leidet und die gesamte Untersuchung jedes Mal von vorne beginnen muss, wenn er auf eine Sackgasse stöst. Sie waren schnell im Lesen, aber schrecklich darin, über einen langen Zeitraum aus ihren eigenen Fehlern zu lernen.

Das Feld des „Long-Horizon Reasoning“ (langfristige Schlussfolgerung) beschäftigt sich genau mit der Behebung dieses Problems. Es stellt die Frage: Wie kann eine KI einen Plan über Tage oder Wochen hinweg aufrechterhalten, sich daran erinnern, was sie gestern versucht hat, und ihre Strategie ändern, wenn sie merkt, dass sie in die falsche Richtung läuft? Die Kernidee hierbei ist, dass Intelligenz nicht nur daraus besteht, ein großes Gehirn (ein leistungsstarkes Modell) zu haben, sondern auch ein gutes Notizbuch (persistentes Gedächtnis) und einen strengen Coach (Verifizierung), der einen stoppt, wenn man sich selbst anlügt, sobald man feststeckt. Dieses Paper befasst sich mit der Frage, wie man ein KI-System baut, das nicht einfach nur im Kreis läuft, sondern seine Methoden im Laufe der Zeit tatsächlich weiterentwickelt und besser darin wird, schwierige Probleme zu lösen, ohne dafür jedes Mal komplett neu trainiert werden zu müssen.

Treffen Sie Argus: Die KI, die lernt, die Richtung zu ändern

Lernen Sie Argus kennen, eine neue Art von KI-„Runtime“ (denken Sie an es als das Betriebssystem oder die Engine, die das Gehirn der KI antreibt). Die Forscher hinter Argus, ein Team von Microsoft und mehreren Top-Universitäten, erkannten, dass eine KI, um wirklich schwierige, langfristige Projekte anzugehen, nicht einfach blind vorwärts marschieren kann. Wenn die KI versucht, einen Bug in einer riesigen Software-Codebasis zu beheben oder ein komplexes mathematisches Theorem zu beweisen, könnte sie Stunden damit verbringen, einen Pfad zu verfolgen, der sich als Sackgasse erweist. Eine normale KI würde vielleicht einfach weiterdrücken und Zeit sowie Energie verschwenden. Argus ist anders: Es ist darauf ausgelegt, zu pivotieren (die Richtung zu ändern).

Stellen Sie sich Argus wie ein hoch organisiertes Forschungsteam vor, das in einem gemeinsamen Büro arbeitet, anstatt wie eine einzelne Person, die alleine arbeitet. Dieses Team hat vier verschiedene Rollen, und sie vermischen ihre Aufgaben niemals:

Der Manager: Der Chef, der den Blick für das große Ganze behält. Er stellt sicher, dass das Team auf das ursprüngliche Ziel fokussiert bleibt (wie „baue einen Roboter“), selbst wenn sich der tägliche Plan ändert.
Der Planer: Der Stratege, der das große Ziel in kleine, machbare Aufgaben für den Tag zerlegt.
Der Ingenieur: Der Erbauer, der tatsächlich den Code schreibt, die Experimente durchführt oder die Mathematik betreibt.
Der Reviewer (Prüfer): Der strenge Qualitätskontrolleur. Seine Aufgabe ist es, sich anzusehen, was der Ingenieur gebaut hat, und zu sagen: „Das ist gut“, „Das muss repariert werden“ oder „Stopp, dieser Pfad ist eine Sackgasse“.

Die Magie von Argus liegt darin, dass es Fehler als Daten behandelt. Wenn der Ingenieur eine Methode ausprobiert und diese fehlschlägt, sagt der Reviewer nicht einfach nur „Ups“. Er zeichnet genau auf, warum es gescheitert ist. Dieser Datensatz wird in einem permanenten „Projektzustand“ (dem gemeinsamen Notizbuch des Teams) gespeichert. Wenn das Team später versucht, denselben Sackgassen-Pfad erneut zu beschrechen, erinnert sich das System: „Hey, das haben wir gestern schon versucht und es hat nicht funktioniert“, und wechselt zu einer neuen Idee. Dies wird als verification-guided persistence (verifizierungsgestützte Beständigkeit) bezeichnet. Das System „lernt“ (aktualisiert sein Gedächtnis) nur dann, wenn der Reviewer verifiziert, dass die neue Information tatsächlich wahr und nützlich ist.

Was sie herausgefunden haben: Besser beim Beheben von Code und beim Schreiben von Papern

Das Team testete Argus bei einigen unglaublich schwierigen Herausforderungen, um zu sehen, ob dieser „Team mit einem Gedächtnis“-Ansatz tatsächlich funktioniert.

1. Der Code-Fixing-Test (SWE-Bench Pro)
Sie gaben Argus 731 reale Software-Bugs zur Behebung. Das ist so, als würde man einem Programmierer eine unordentliche, kaputte Codebasis geben und ihn bitten, sie ohne menschliche Hilfe zu reparieren.

Das Ergebnis: Argus konnte etwa 78 % der Bugs erfolgreich beheben.
Der Vergleich: Ein Standard-KI-Tool (Direct Copilot) konnte nur 59 % davon beheben.
Die Kosten: Argus verbrauchte etwa das 1,41-fache an Computer-„Tokens“ (die Basiseinheiten des Denkens) im Vergleich zum Standard-Tool.
Die Erkenntnis: Argus war signifikant genauer, obwohl es etwas mehr „dachte“. Es bewies, dass es sich auszahlt, die Zeit zu investieren, um die Arbeit zu prüfen und vergangene Fehler zu berücksichtigen.

2. Der „Intelligenter Werden“-Test (Self-Evolution)
Hier ist der coolste Teil. Die Forscher beobachteten Argus über einen längeren Zeitraum. Sie änderten nicht das Gehirn der KI (die Modellgewichte blieben exakt gleich). Stattdessen ließen sie das System einfach sein „Notizbuch“ an Fähigkeiten und Erinnerungen aufbauen.

Das Ergebnis: Während das System mehr Aufgaben erledigte und sein Notizbuch mit verifizierten Fähigkeiten füllte, wurde es schneller und kostengünstiger. In den späteren Phasen des Tests verbrauchte Argus 21 % weniger Tokens und benötigte 15 % weniger Zeit pro Aufgabe im Vergleich zu Beginn.
Die Bedeutung: Die KI musste nicht neu trainiert werden, um besser zu werden; sie musste nur sich dessen erinnern, was sie gelernt hatte. Sie entwickelte ihren eigenen „Runtime-Zustand“ und wurde zu einem effizienteren Arbeiter, ohne ihr fundamentales Gehirn zu verändern.

3. Der „Lüge dich nicht selbst an“-Test (Intervention des Reviewers)
Das Team verfolgte, wie oft der Reviewer eingriff. Von den 731 Aufgaben wurde der Reviewer bei 466 davon hinzugezogen.

Die Rettung: In 43 Fällen sagte der Reviewer: „Das ist noch nicht fertig, versuch es nochmal.“ Nachdem der Ingenieur es erneut versucht hatte, wurden 34 dieser Aufgaben erfolgreich behoben, und 22 wurden so gut gelöst, dass sie eine zweite, strengere Prüfung bestanden.
Die Blockade: Der Reviewer stoppte das System auch dabei, bei 35 Aufgaben einen Sieg zu beanspruchen, die eigentlich unmöglich oder fehlerhaft waren. Das ist enorm wichtig: Es bedeutet, dass das System lernte, „Ich kann das nicht“ zu sagen, anstatt eine gefälschte Lösung zu halluzinieren.

Jensecht von Code: Mathematik, Chips und Paper

Argus blieb nicht beim Beheben von Code stehen. Das Team zeigte, dass es auch andere „Long-Horizon“-Aufgaben bewältigen kann:

Mathematische Forschung: In einer Kampagne zur Beweisführung eines komplexen mathematischen Theorems führte Argus ein Protokoll über einen Pfad, der als falsch bewiesen wurde (eine „falsifizierte Route“). Anstatt ihn zu löschen, behielt es ihn als „Betreten verboten“-Schild bei. Dies half dem System, diese Sackgasse später zu vermeiden und die Grenzen des Theorems erfolgreich zu stärken.
Schreiben von Papern: Sie ließen sechs verschiedene Forschungsprojekte zur Erstellung wissenschaftlicher Arbeiten durchlaufen. Das System bewältigte 254 Missionen, überstand 16 große Rollbacks (bei denen es den gesamten Plan ändern musste) und schaffte es dennoch, alle sechs Paper fertigzustellen. Ein Projekt verwandelte sogar eine gescheiterte Idee in eine erfolgreiche „Negativresultat“-Studie, was beweist, dass auch das Feststellen dessen, was nicht funktioniert, eine gültige wissenschaftliche Entdeckung ist.
Chip-Design: In einem riskanten Test entwarf Argus einen Computerchip (ACE-2). Das System schrieb den Code, prüfte das Timing, und das finale Design bestand alle strengen Hardware-Checks. Das System wusste sogar genau, was es nicht geprüft hatte (wie z. B. ob der Chip im echten Leben funktionieren würde), und listete diese Grenzen klar auf.

Das Fazentelement

Argus zeigt, dass eine KI für echte, langfristige Arbeit mehr braucht als nur ein großes Gehirn. Sie braucht ein System, das den „Chef“ vom „Arbeiter“ trennt, eine permanente Aufzeichnung darüber führt, was funktioniert hat und was nicht, und einen strengen „Reviewer“ besitzt, der sie stoppt, Antworten zu erfinden.

Das Paper legt nahe, dass eine KI durch die Nutzung dieses „verifizierungsgesteuerten“ Ansatzes schwierigere Probleme lösen, im Laufe der Zeit effizienter werden kann, ohne neu trainiert werden zu müssen, und sogar zugeben kann, wenn sie feststeckt. Es ist kein Zauberstab, der alles sofort löst, aber es ist ein massiver Schritt in Richtung einer KI, die tatsächlich mit uns an langen, komplexen Projekten arbeiten kann, ohne sich zu verlieren oder über ihren Fortschritt zu lügen. Wie die Autoren anmerken, geht es hierbei nicht nur darum, eine höhere Punktzahl in einem Test zu erreichen; es geht darum, ein System zu bauen, das in der Lage ist, zu bestehen, die Richtung zu ändern und seine eigenen Methoden zu entwickeln, um die chaotischen, langfristigen Herausforderungen der realen Welt anzugehen.

Technisches Resümee: Argus – Eine generalisierte agentische Runtime für langfristiges Schlussfolgern

1. Problemstellung

Langfristige Schlussfolgerungsaufgaben (z. B. Software-Reparatur, mathematische Beweise, wissenschaftliche Entdeckungen) sind nicht bloß ein Wettlauf zur Ausführung eines festen Plans über mehr Schritte hinweg. In der Praxis bleibt die intendierte Nutzerabsicht oft stabil, während das operative Ziel, die Randbedingungen und die Verifizierungskriterien im Zuge der Akkumulation von Evidenz verfeinert werden müssen. Bestehende Agentensysteme stehen vor einem kritischen Ambiguitätsproblem: Ein System, das sein erklärtes Ziel aufgibt, könnte entweder entdeckt haben, dass das Ziel misspezifiziert war, oder es könnte sein, dass es das Scheitern lediglich rationalisiert hat. Ohne einen Mechanismus zur Unterscheidung dieser Fälle leiden Systeme unter „Goal Drift“ (Zielabweichung), bei dem sich die Ziele dem degradieren, was der Ausführer gerade noch abschließen kann.

Bestehende Ansätze entfernen diese Wahlmöglichkeit entweder durch das Fixieren des Objekts und die Optimierung der Ausführung darauf, oder sie verlassen sich auf sitzungsbeschränkte Transkripte, die Kontinuität verlieren, wenn Kontexte komprimiert werden. Dies führt zu drei Fehlern bei lang laufenden Agenten:

Kontinuitätsfehler: Die Evidenz, die eine Revision motiviert, geht verloren, wenn Transkripte verworfen werden.
Akzeptanzfehler: Die Komponente, die die Arbeit ausführt, erklärt auch deren Abschluss, was einen Interessenkonflikt erzeugt.
Erfahrungsfehler: Nur die finalen Artefakte überleben, was verhindert, dass widerlegte Pfade als Evidenz für zukünftige Pivotierungen dienen.

2. Methodik: Die Argus-Runtime

Argus ist eine persistente, selbstentwickelnde agentische Runtime, die darauf ausgelegt ist, „verifizierte Pivotierung“ zu ermöglichen und sicher zu verwalten. Sie trennt die festen Parameter des Modells von einem mutablen, dauerhaften Runtime-Zustand.

2.1 Kernarchitektur

Das System operiert auf einem dauerhaften Projektzustand, der in gebundene Missionen unterteilt ist. Es verwendet vier modellgesteuerte Rollen mit distinkten Autoritäten:

Manager: Verankert die stabile Nutzerabsicht ( $\iota$ ), den Kampagnenzustand und die Übergänge zwischen den Stadien. Er lässt materielle Verfeinerungen des operativen Kontrakts zu.
Planner: Zerlegt den aktuellen Zustand in gebundene Aufgaben und Abhängigkeiten.
Engineer: Implementiert Aufgaben, ruft Werkzeuge auf und führt Experimente durch. Er kann eine Selbstprüfung bei risikoarmen, gebundenen Arbeiten durchführen.
Reviewer: Inspiziert unabhängig Artefakte und Ausführungsaufzeichnungen. Er erlässt Abschlussurteile (fertig, fortfahren, blockiert), wenn dies durch Richtlinien oder Anfragen erforderlich ist.

Diese Rollen operieren über drei Ebenen: Control (Steuerung), Execution (Ausführung) und Records (unveränderliche Historie).

2.2 Verifizierungsgesteuerte Persistenz und Selbstentwicklung

Argus führt einen Mechanismus der verifizierungsgesteuerten Zulassung ein. Der Runtime-Zustand ( $H_t$ ) umfasst Speicher, Fähigkeiten, Werkzeuge, Verifizierer und Routing-Richtlinien.

Fixed-Model Evolution: Die zugrunde liegenden Modellgewichte ( $\theta$ ) bleiben fix. Die Evolution findet nur im persistenten Zustand und der Steuerungsrichtlinie statt.
Zulassungsprotokoll: Kandidatener updates (Speicher, Fähigkeiten, abgelehnte Pfade) werden erst reaktivierbar nach:
1. Generierung durch eine Rolle (z. B. Engineer).
2. Überprüfung gegen aufgabenspezifische Evidenz und Artefakte.
3. Commitment durch einen autorisierten Besitzer (z. B. Reviewer oder Manager).
Kontraktverfeinerung: Der Arbeitskontrakt wird als $K_t = (\iota, o_t, c_t, v_t)$ modelliert, was die stabile Absicht, das operative Ziel, die Randbedingungen und die Verifizierungskriterien darstellt. Verfeinerungen werden via eines ManagerAdmit-Operators zugelassen, der Evidenz ( $e_t$ ) und Autorität ( $u_t$ ) erfordert, um sicherzustellen, dass Pivotierungen von Drift unterscheidbar sind.

2.3 Process-to-Capability Theorie

Das System betrachtet den Prozess-Trajektor als eine Obermenge des finalen Artefakts. Es definiert die Dichte der intelligenten Information ( $\rho_I$ ) als die Rate relevanter Argumentation, effektiver Handlung und valider Verifizierung pro Zeiteinheit. Es postuliert, dass das Beibehalten der vollständigen Prozessaufzeichnung (einschließlich gescheiterter Zweige) einen entscheidungstheoretischen Vorteil (Blackwell-Informationsordnung) gegenüber dem finalen Artefakt allein bietet, da zukünftige Missionen so Sackgassen vermeiden und verifizierte Ausschlüsse nutzen können.

3. Wesentliche Beiträge

Das Paper skizziert sieben spezifische Beiträge:

Formalisierung: Ein Kontraktmodell ( $K_t$ ) und ein ManagerAdmit-Operator für verifizierte Pivotierung über lange Horizonte.
Runtime-Design: Ein System, in dem die Kontraktverfeinerung rollenbesessen und protokolliert ist, wodurch die stabile Absicht von operativen Änderungen getrennt wird.
Reviewer Routing Metriken: Empirische Daten, die zeigen, dass unabhängige Reviewer für 63,7 % der SWE-Bench Pro Aufgaben aufgerufen werden, mit spezifischen Wiederherstellungsraten für Revisionsanfragen.
Paper-Produktion Fallstudie: Eine Kampagne über sechs Projekte mit 640 Stunden und 254 Missionen, die das End-to-End Research Lifecycle Management inklusive Rollbacks und Negativ-Ergebnis-Pivotierungen demonstriert.
Mathematischer Trace: Eine rollenbasierte Rekonstruktion einer mathematischen Kampagne, die einen falsifizierten Pfad und sechs prüfungsgestützte Updates beibehält.
Benchmark-Leistung: Eine vereinheitlichte Evaluierung über sieben Arenen, die eine Kapazitätsuntergrenze etabliert, ohne die End-Aufgaben-Performance zu opfern.
Upstream-Adoption: Ein Argus-optimierter RWKV6-Kernel, der in das Upstream Flash Linear Attention Repository gemergt wurde.

4. Ergebnisse

4.1 Benchmark-Leistung

Argus wurde in sieben heterogenen Arenen evaluiert:

SWE-Bench Pro: Erreichte ~78 % Genauigkeit im Vergleich zu 59 % bei Direct Copilot, unter Verwendung von 1,41× aggregierten Tokens.
AARRI-Bench: Erreichte 76,8 % bei Research-Intern-Aufgaben (gegenüber 68,3 % Referenz).
Math-Reasoning Data Synthesis: Erzielte eine Differenz von 28,0 (pass@4 - pass@1) und übertraf damit die Referenzen (Arbor: 20,83, Claude: 8,33).
GPU & Training: Erreichte kompetitive Ergebnisse beim B200/H100 nanochat Training (0,9636 BPB vs. menschliches Bestleistung 0,9646) und bei nanoGPT Speedruns (79,77s vs. Mensch 80,18s).
MLE-Bench Lite: Sicherte 9 Medaillen (3 Gold, 3 Silber, 3 Bronze) in Wettbewerben mit externer Verifizierung.

4.2 Longitudinale Effizienz (Selbstentwicklung)

Im SWE-Bench Pro Durchlauf (731 Aufgaben) demonstrierte das System eine verifizierungsgesteuerte Runtime-Selbstentwicklung:

Reife vs. Startup: Reife Wellen (W19–22) verwendeten 21 % weniger Solve-Input-Tokens und 15 % weniger aktive Workflow-Zeit pro Aufgabe im Vergleich zu Startup-Wellen (W1–6).
Reviewer Recovery: Von 43 Aufgaben, bei denen der Reviewer eine Revision anforderte, bestanden 34 (79,1 %) später den offiziellen Verifizierer, und 22 (51,2 %) schlossen eine strikte Review-Loop-Rettung ab.
Nicht-Monotonie: Die Trajektorie war nicht monoton; schwierige Aufgabenwellen (W23–24) zeigten Ressourcen-Rebounds, und das System verzeichnete 34 Verifizierer-Recoveries und 22 strikte Rettungen, was die Fähigkeit des Systems beweist, sich von anfänglichen Fehlern zu erholen.

4.3 Vertikale Fallstudien

Mathematische Kampagne: Beibehaltung eines falsifizierten Pfades und sechs Theorem-Frontier-Updates. Das System konnte erfolgreich von einer fehlgeschlagenen Reduktion zu einer prüfungsgestützten Stärkung der Schranken pivotieren.
Paper-Produktion: Sechs Projekte erreichten den Abschluss der Einreichung. Eine Kampagne pivotierte von einer positiven Methodenbehauptung zu einer 4.500-Zeilen-Negativresultat-Diagnosestudie nach sieben „No-Go“-Rollbacks.
Hardware (ACE-2): Die Runtime entwarf einen Inferenz-Beschleuniger (Qwen2.5-0.5B W4A8), der für einen spezifischen Scope zertifiziert wurde (Mapped Synthesis, Static Timing) mit expliziten Ausschlüssen (kein Power Signoff, keine Silicon Validation).
Materialwissenschaften: Die Runtime vereinfachte eine veröffentlichte MOF-Generierungsmethode, indem sie einen Confound in der ursprünglichen Vergleichsmethode identifizierte und entfernte, was zu einer einfacheren, effektiveren Methode führte.

5. Bedeutung und Ansprüche

Das Paper behauptet, dass Argus eine generalisierte, selbstentwickelnde Hülle demonstriert, die in der Lage ist, verifizierte Ansätze zu revidieren, zu regenerieren und zu akkumulieren, ohne jeden langfristigen Trajektorienzwang in einen Erfolgsanspruch zu verwandeln.

Unterscheidung von Drift: Durch die Forderung nach evidenzbasierten, rollengesteuerten Zulassungen für Zustandsänderungen unterscheidet das System zwischen rationaler Pivotierung und Fehlerrationalisierung.
Prozess als Datenquelle: Die beibehaltenen Trajektorien bilden strukturierte Daten für zukünftiges Supervised und Reinforcement Learning, indem sie Modell-Outputs mit konkreten Zuständen, Werkzeugen und Review-Entscheidungen verknüpfen.
Bescheidener Umfang: Die Autoren betonen explizit, dass die „Selbstentwicklung“ Fixed-Model ist (zustandsbasiert, nicht gewichtsbasiert) und dass die Ergebnisse beobachtend sind. Sie behaupten nicht, dass das System allgemeine künstliche Intelligenz erreicht hat oder menschliche Forscher vollständig ersetzen kann. Das System wird als Werkzeug präsentiert, das „stoppt“, wenn Ziele unterdefiniert sind, und dadurch Constraints offenlegt, die der Nutzer eventuell übersehen hat, anstatt blindlings auf ein potenziell fehlerhaftes Ziel zu optimieren.

Der Bericht schließt mit der Feststellung, dass die Runtime erfolgreich breite Aufgabenkapazität, verifizierte Akkumulation über Missionen hinweg und nachhaltige Forschungsleistung kombiniert und somit ein neues Paradigma für langfristige agentische Systeme bietet, in denen Persistenz und Pivotierung durch Verifizierung statt durch starre Planung gesteuert werden.