Was für eine fantastische Idee! Dass zwei KI-Systeme miteinander streiten, und dadurch 95 % der langjährigen Probleme eines traditionellen wissenschaftlichen Softwarepakets behoben werden können?
In den letzten Jahrzehnten ist in der Wissenschaftlichen Computation eine unzählige Anzahl von Open - Source - Tools entstanden, doch nur wenige von ihnen sind „out - of - the - box“ einsetzbar. DeepPotential Technology's Deploy - Master konzentriert sich auf die Ausführung und nutzt einen automatisierten Workflow, um das gleichzeitige Deployen und Validieren von über 50.000 Tools in einem Zug zu ermöglichen, was den Weg für Agentic Science ebnet.
In den letzten Jahrzehnten hat sich in der Wissenschaftlichen Computation eine beispiellose Anzahl von Open - Source - Softwaretools angesammelt.
Von Bioinformatik, chemischen Simulationen bis hin zu Materialberechnungen, physikalischen Simulationen und Ingenieurdesign hat fast jede Disziplin ihre eigene Tool - Ökosystem gebildet. Auf Plattformen wie GitHub behaupten Tausende von Code - Repositories, für wissenschaftliche Praktiken einsetzbar zu sein.
Doch eine seit langem bestehende, aber nie systematisch gelöste Tatsache ist: Die meisten wissenschaftlichen Softwarepakete bleiben auf dem Stand, dass sie „veröffentlicht wurden“, statt „direkt ausführbar“ zu sein.
In der realen wissenschaftlichen Praxis müssen wir oft Tage oder sogar Wochen darauf verwenden, wiederholt Probleme wie fehlgeschlagene Kompilierungen, Abhängigkeitskonflikte und Systeminkompatibilitäten zu beheben, um ein Tool lokal „kaum lauffähig“ zu machen.
Eine solche Laufzeitumgebung ist stark von persönlicher Erfahrung abhängig, oft vorübergehend, nicht portierbar und schwer von anderen zu reproduzieren oder wiederzuverwenden. Jeder Forscher und jedes Labor pflegt manuell seine eigene Laufzeitumgebung, anstatt auf einer gemeinsamen, reproduzierbaren Ausführungsinfrastruktur zu arbeiten.
Das Problem, das dieses Modell mit sich bringt, ist nicht nur die Ineffizienz. Wichtiger noch ist, dass es strukturell drei Dinge bei wissenschaftlicher Software einschränkt: Reproduzierbarkeit, Massenevaluation und systematische Integration.
Selbst wenn Containerisierung, Cloud Computing und HPC - Plattformen die Rechenleistungsschwelle bereits deutlich gesenkt haben, besteht dieser „Deploy - Engpass“ immer noch und hemmt langfristig die Nutzbarkeit wissenschaftlicher Software.
Mit dem Aufstieg von Künstlicher Intelligenz für die Wissenschaft (KI4W) wird dieses Problem noch verstärkt.
In dem neuen wissenschaftlichen Paradigma muss das KI - System nicht nur Vorhersageergebnisse ausgeben, sondern auch eng mit realen wissenschaftlichen Tools interagieren:
1. Einen Solver aufrufen;
2. Ein Simulationsprogramm ausführen;
3. Eine Analysepipeline ausführen;
4. Echte Daten verarbeiten.
Vor diesem Hintergrund ist die Frage, ob ein Tool „wirklich lauffähig“ ist, nicht länger ein Detail der Ingenieurarbeit, sondern eine grundlegende Frage.
Dieses Problem tritt in Agentischer Wissenschaft - Szenarien noch deutlicher hervor.
Wenn die Abhängigkeiten eines Tools von einer impliziten Umgebung abhängen und die Ausführung sehr anfällig ist, kann die Planung eines Agenten nicht wirklich umgesetzt werden, fehlgeschlagene Ausführungen können nicht strukturiert analysiert werden und es ist unmöglich, daraus lernfähige Ausführungspfade zu generieren.
Von dieser Perspektive aus ist die Frage, ob ein Tool deploy - bereit ist, bereits ein struktureller Engpass, der die skalierbare Entwicklung von KI4W und Agentischer Wissenschaft hemmt.
Aufgrund dieser Beobachtungen hat DeepPotential Technology allmählich die Einsicht gewonnen, dass das Problem bei wissenschaftlicher Software nicht darin besteht, dass es zu wenige Tools gibt, sondern dass es an einer fehlenden gemeinsamen Infrastruktur fehlt, die die Tools systematisch in ausführbare Fakten umwandeln kann.
Deploy - Master wurde genau in diesem Kontext entwickelt.
In der realen Welt ist das Deployen kein isolierter Schritt, sondern eine kontinuierliche Kette:
Kann ein Tool gefunden werden?
Wird es richtig verstanden?
Kann die Umgebung aufgebaut werden?
Und kann es tatsächlich ausgeführt werden?
Deploy - Master wurde genau um diese Kette herum als ein zielgerichteter, einheitlicher automatisierter Workflow entwickelt.
Suchagent, Suchen in Millionen von Repositories
In großangelegten Szenarien liegt das erste Problem beim Deployen nicht im Bauen, sondern im Finden. Wenn die Menge der Kandidaten - Tools systematische Abweichungen aufweist, werden alle nachfolgenden Automatisierungen diese Abweichungen verstärken.
Dafür haben sie von 91 wissenschaftlichen und ingenieurtechnischen Bereichen ausgehend einen Disziplinenraum erstellt, der die realen Anwendungsfälle von KI4W abdeckt, und mit Sprachmodellen Suchbegriffe erweitert, um in GitHub und im öffentlichen Netzwerk eine umfassende Suche durchzuführen.
Die anfänglich gefundenen Repositories werden als „Ankerpunkte“ verwendet und über Signale wie Abhängigkeiten, Verweise, gemeinsame Mitwirkende und Dokumentationslinks iterativ erweitert, um die Blindstellen, die nur durch Suchbegriffe entstehen, zu vermeiden.
Anschließend eliminieren sie Repositories, die offensichtlich nicht ausführbar sind, mithilfe strukturerhaltender heuristischer Regeln und lassen einen Agenten eine semantische Beurteilung durchführen, um festzustellen, ob sie ein ausführbares wissenschaftliches Tool darstellen.
Durch diesen mehrstufigen Filterprozess reduzieren sie die anfänglich etwa 500.000 Repositories auf 52.550 Kandidaten für wissenschaftliche Tools, die in den automatischen Deploy - Prozess einbezogen werden.
Die Bedeutung dieses Schritts liegt nicht nur in der Filterung der Tools, sondern auch darin, dass erstmals die Größe und die Grenzen der realen Welt der wissenschaftlichen Tools strukturiert beschrieben werden.
Bauagent, Zwei - Modell - Debatte
Im Bauphase befinden wir uns nicht in einer Welt mit „klaren Anleitungen“.
Die Bauinformationen vieler wissenschaftlicher Software - Repositories sind lückenhaft, unvollständig oder sogar widersprüchlich.
Die README - Dateien können bereits veraltet sein, die vorhandenen Dockerfiles spiegeln möglicherweise nicht den aktuellen Zustand des Codes wider, und die wichtigen Abhängigkeiten befinden sich oft nur in der lokalen Umgebung des Autors.
Der Bauagent durchsucht systematisch die Bauhinweise im Repository und sucht bei Bedarf nach zusätzlichen Informationen, um ein initiales Bauplan zu erstellen.
Frühe Experimente haben gezeigt, dass die Erfolgsrate bei der Erstellung von Bauvorschriften nur auf der Grundlage eines einzigen Modells nur 50 % - 60 % beträgt. Die Fehlschläge stammen hauptsächlich von einer großen Anzahl von impliziten, nicht explizit ausgedrückten Annahmen in den Bauinformationen.
Dafür hat Deploy - Master einen Zwei - Modell - Review - und Debatte - Mechanismus eingeführt:
Ein Modell schlägt eine Bauvorschrift vor,
ein anderes Modell überprüft diese unabhängig und sucht aktiv nach potenziellen Unstimmigkeiten, fehlenden Abhängigkeiten oder Umgebungsannahmen und gibt Korrekturvorschläge.
Beide Modelle interagieren in mehreren Runden, um den Plan ständig zu verbessern, bis eine stabile, ausführbare Bauvorschrift entsteht. Dieser Mechanismus hat die Gesamt - Erfolgsrate auf über 95 % gesteigert.
Jedes Tool wird schließlich durch einen minimalen ausführbaren Befehl validiert.
Nur Tools, die diese Ausführungsvalidierung bestehen, werden als erfolgreich deployed angesehen und weiter strukturiert, registriert und auf Bohr und SciencePedia veröffentlicht, damit sie direkt verwendet oder von anderen Agenten (z. B. SciMaster) aufgerufen werden können.
Betrachtet man die Verteilung der Bauzeiten, wird deutlich, dass das Massendeploy kein „gleichmäßiger“ Prozess ist.
Obwohl die meisten Tools in etwa 7 Minuten gebaut werden können, weist die Gesamtverteilung ein deutliches Langschwanzverhalten auf.
Einige Tools enthalten nur leichte Skripte oder interpretierbaren Code und haben einen relativ einfachen Bauvorgang;
andere Tools hingegen erfordern komplexe Kompilierungsabläufe, tiefe Abhängigkeiten und Systembibliothekskonfigurationen, was deren Bauzeit deutlich verlängert.
Diese Unterschiede hindern den Gesamtprozess nicht, sondern bestimmen die Kostenstruktur bei skalierbarem Deploy.
Unter den 50.112 erfolgreich deployed Tools beobachten wir eine stark heterogene Sprachenverteilung.
Die Tools verwenden über 170 Programmiersprachen, wobei Python den größten Anteil hat, gefolgt von C/C++, Tools in Notebook - Form, R, Java usw.
Die meisten Sprachen haben eine stabile und hohe Deploy - Erfolgsrate.
Die wenigen Sprachen mit einer relativ niedrigen Erfolgsrate konzentrieren sich hauptsächlich auf Szenarien mit komplexen Kompilierungsketten oder Systembibliotheken, wie z. B. C/C++, Fortran und einige R - Tools.
Dies bedeutet nicht, dass diese Sprachen „von Natur aus schwieriger zu deployen“ sind, sondern spiegelt wider, dass ihre Tool - Ketten stärker an die unterliegende Umgebung gekoppelt sind, was die Unsicherheiten in den Bauvorschriften verstärkt.
Von der Perspektive des Deployens ist die Sprache nicht der entscheidende Faktor, sondern die Stärke der Umgebungsabhängigkeit. Bei 2.438 fehlgeschlagenen Bauversuchen haben sie die Fehlerursachen systematisch statistisch ausgewertet.
Die Ergebnisse zeigen, dass die Fehlschläge nicht gleichmäßig verteilt sind, sondern stark auf wenige Problemtypen konzentriert sind. Die Hauptursache der Fehlschläge ist ein fehlerhafter Bauvorgang, einschließlich Unstimmigkeiten zwischen den Bau-Schritten und dem aktuellen Zustand des Repositories, fehlende Schlüsselabhängigkeiten, Inkompatibilitäten zwischen Compiler und Systembibliothek usw. Solche Fehlschläge sind weitaus häufiger als Probleme aufgrund von fehlenden Ressourcen, Netzwerkstörungen oder Berechtigungen.
Zugleich sind Ressourcen - bezogene Fehler in der Phase hoher Parallelität tatsächlich aufgetreten und haben direkt zur Verbesserung der Scheduling - Strategie und des Isolationsmechanismus geführt. Dies zeigt weiter, dass bei skalierbarem Deploy Fehlschläge nicht als Ausnahmen, sondern als Signale für das System angesehen werden sollten, um Probleme aufzuzeigen und sich selbst zu verbessern.
Durch die einheitliche Ausführungsinfrastruktur können sie systematisch das Deploy - Verhalten von wissenschaftlicher Software in der realen Umgebung beobachten:
Welche Schritte am häufigsten fehlschlagen,
Welche impliziten Annahmen am häufigsten ausgelöst werden,
Welche Tool - Ketten die Unsicherheiten am stärksten verstärken.
Diese Beobachtbarkeit ist selbst eine der Grundlagen, die Deploy - Master aufbauen möchte.
Sie verwandelt die Erfahrung, dass wissenschaftliche Software schwer zu deployen ist, in ein engineerbares Objekt, das quantifiziert, analysiert und kontinuierlich verbessert werden kann.
Von lauffähigen Tools zur Ausführungsgrundlage für Agentische Wissenschaft
Das direkte Ergebnis von Deploy - Master ist eine Sammlung von Tausenden von ausführbaren und validierten Tools. Wichtiger noch ist, dass es Community - Agenten und verschiedenen Master - Agenten eine seit langem fehlende Grundvoraussetzung bietet.
Für Agenten ist das Aufrufen von Tools kein abstrakter Vorgang, sondern ein Ausführungsprozess, der in der realen Umgebung erfolgreich umgesetzt werden muss.
Nur wenn die Tools einheitlich gebaut, validiert und als ausführbare Fähigkeiten registriert werden, haben die Agenten ein stabiles Aktionsraum, und die Schleife zwischen Planung, Ausführung und Lernen kann geschlossen werden. Dies ermöglicht es auch Community - Agenten aus verschiedenen Quellen, die gleichen ausführbaren und validierten Tool - Fähigkeiten zu teilen, anstatt jeweils ihre eigenen anfälligen, nicht reproduzierbaren Laufzeitumgebungen zu pflegen.
Die Bedeutung dieser Methodik ist nicht auf die Wissenschaftliche Computation beschränkt.
Wissenschaftliche Tools gelten oft als die schwierigste Art von Software für automatisiertes Deploy:
Komplizierte Abhängigkeiten
Starke Kopplung an das System
Unvollständige Dokumentation
Hohe Sensitivität gegenüber der Umgebung.
Wenn in einem solchen „schwierigsten Szenario“ dennoch durch eine auf die Ausführung ausgerichtete Konstruktion in der Größenordnung von Tausenden stabile, lauffähige Tools erzeugt werden können, dann ist die Schlussfolgerung klar -
Das Problem liegt nicht in der Art der Tools, sondern darin, ob eine auf die Ausführung ausgerichtete Infrastruktur aufgebaut wird.
Diese Einsicht gilt auch für die breitere Ökosystem von Softwaretools: Ingenieurtools, Datenverarbeitungssysteme, professionelle Software und sogar verschiedene Agent - Tooling.
Sobald Tools schließlich ausgeführt werden müssen, kann das Deploy - Problem nicht an der Realität der „unvollständigen Informationen“ vorbeigehen.
Deploy - Master hat nicht alle Probleme gelöst. Heterogene Hardware, verteilte Rechenleistung, semantische I/O - Schnittstellen und die geschlossene Schleife - Integration mit physikalischen Experimentiersystemen bleiben noch zukünftige Herausforderungen.
Aber eines ist bereits klar: In der Ära von Agentischer Wissenschaft ist die Ausführung kein nachgeordneter Schritt nach der Inferenz, sondern die Voraussetzung für die Gültigkeit aller Fähigkeiten.
Wenn die Frage, ob ein Tool „lauffähig“ ist, nicht mehr eine implizite Annahme, sondern ein systematisch validierter Fakt wird, haben wissenschaftliche Agenten erst dann wirklich die Grundlage, um mit der realen Welt zu interagieren. Und Deploy - Master ist ein Versuch, sich dieser Ausführungsrealität zu nähern.