Die industrielle Revolution im Reverse Engineering.

Was hat sich im August 2026 geändert

Vor dieser Arbeit hatte ich viel manuelles Reverse Engineering gemacht. Ich würde eine Funktion inspizieren, bis ich eine Erklärung hatte, und diese Erklärung dann gegen das Programm testen. Weiter zu kommen bedeutete, mehr Zeit mit der nächsten Funktion zu verbringen. Es bedeutete auch, ein immer größeres Bild in meinem Kopf zu behalten.

Der größte Teil meiner Arbeit dreht sich um Spiele. Ich rekonstruiere sie, damit ihr Verhalten verstanden und schließlich in einen Softwareport oder einen Mod übertragen werden kann. Das ist die Erfahrung hinter diesem Artikel. Die Methode kann an anderer Stelle nützlich sein, aber jedes Feld muss festlegen, was es anhand einer zuverlässigen Referenz überprüfen kann.

Im August 2026 begann ich, agentengesteuerte RE ernsthaft zu erforschen. Ich wollte sehen, wie weit ein Agent mit Zugriff auf das Programm und gewöhnliche Entwicklungstools kommen kann. Touhou Reconstruction gab mir ein umfangreiches Projekt, in dem ich es herausfinden konnte.

Der frühe Fortschritt war verblüffend. Eine Untersuchung könnte weitergehen, ohne dass ich jeden einzelnen Schritt auswähle. Bei einem fehlgeschlagenen Vergleich wird der Agent möglicherweise an einen anderen Anrufer gesendet. Es könnte eine kleine Diagnose schreiben und anhand des Ergebnisses entscheiden, was als nächstes versucht werden soll. Ihm diese Freiheit zu geben, machte einen Unterschied: Ich konnte mehr Aufmerksamkeit auf die Richtung des Projekts richten und darauf, ob seine Überprüfungen vertrauenswürdig waren.

Das Tempo erregte zuerst meine Aufmerksamkeit. Dann begann ich mich zu fragen, was über das aktuelle Projekt hinaus überleben würde. Würde das nächste Spiel von allem profitieren, was wir gerade gelernt hatten?

TH08 : auf menschlicher Arbeit aufbauen

MODELL: TH08 , Unvergängliche Nacht, begann als Fortsetzung von Die Rekonstruktion von GensokyoClub. Ihre öffentliche Quelle gab mir eine substanzielle Grundlage. Es kam mit Kenntnis des Builds und einer Geschichte von Beiträgen, die ich in der Fortsetzung aufbewahrt habe.

Die importierte Historie endet am öffentlichen Kontrollpunkt am 10.August. Meine selbständige Fortsetzung begann am 13.August. Bis zum 19.August zeichnete das Ledger die Quelle für alle 1.107 identifizierten Spielfunktionen auf.

Ein spielbarer Linux-Rekonstruktionsport wurde am 24.August, ungefähr elf Tage nach Beginn der Fortsetzung, festgelegt. Eine Webausgabe folgte. Die native 64-Bit-Version Linux ist am 30.August eingetroffen.

Was mir auffiel, war, dass die Arbeit ein Programm erreicht hatte, das die Leute ausführen konnten. Der Weg dorthin erforderte folgende Probleme, die über eine einzelne Funktion hinausgingen. Selbst wenn zwei Funktionen isoliert richtig aussahen, konnten sie versehentlich separate Kopien des Status verwenden, die gemeinsam genutzt werden sollten.

Dies machte Referenzprüfungen zu einem zentralen Bestandteil der Arbeit. Ich nenne sie Verifikationsreferenzen (Orakel). Ein Codevergleich kann uns sagen, ob eine rekonstruierte Funktion die ursprünglichen Anweisungen reproduziert. Eine Laufzeitprüfung kann uns sagen, ob eine ausgeübte Route den erwarteten Zustand erreicht. Der Agent schlägt eine Erklärung vor und testet sie; Eine Nichtübereinstimmung gibt ihm etwas Spezifisches zu untersuchen.

Eine exakte Übereinstimmung mit der falschen Konstante

Eine Verifizierungsreferenz (Oracle) ist Software, die jemand geschrieben hat. TH08 hat mich deutlich daran erinnert, wie viel von dieser Software abhängen kann.

Im September führte ein Fehler, der von einem nachgeschalteten Switch-Port gemeldet wurde, zur automatischen Erfassung von Elementen zurück. Die rekonstruierte Quelle überprüfte die Leistung des Spielers gegen 0.0. Das Original verwendet 128.0, der Schwellenwert für die maximale Leistung.

Die normale Leistung ist nicht negativ, so dass die rekonstruierte Leistungsprüfung effektiv immer erfüllt wurde. Oberhalb der Sammellinie könnte das Spiel Gegenstände anziehen, ohne maximale Kraft zu benötigen. Die anderen Ausnahmen in der Bedingung waren korrekt. Diese eine Konstante veränderte das Verhalten.

Doch die Funktion hatte den genauen Vergleich bereits bestanden.

Eine Neuerstellung kann eine Konstante an eine andere Adresse setzen. Das Vergleichstool berücksichtigte dies, indem es die Adressen in den kompilierten Anweisungen anpasste, bevor es sie mit dem Original verglich. Der Gleitkommawert, der an der referenzierten Adresse gespeichert ist, wurde jedoch nie überprüft.

Das hinterließ ein Loch im Scheck. Es könnte die rekonstruierte Anweisung auf die des Originals verweisen 128.0 während die Quelle noch sagte 0.0. Die Befehlsbytes stimmten überein. Die Quelle meinte etwas anderes.

Der 2. September behoben korrigierte die Quelle und ließ den Vergleich die tatsächlichen Bytes der referenzierten Konstante überprüfen. A umfassendere Prüfung dann wurden 1.548 Gleitkommakonstanten-Referenzen untersucht. Es wurden weitere zwölf falsche Referenzen für fünf akzeptierte Funktionen gefunden.

Der Vergleich überprüft nun jede solche Gleitkommakonstante. Seine Tests enthalten absichtlich falsche Werte, um sicherzustellen, dass sie abgelehnt werden. Wir mussten auch Ergebnisse überprüfen, die die schwächere Prüfung bestanden hatten.

Die Verifikationsreferenz (Oracle) musste ebenfalls rekonstruiert werden. Das Reparieren war Teil der Reparatur des Spiels.

Das ist wichtig, wenn das Team hauptsächlich aus einer Person besteht, die mit Agenten arbeitet. Ich kann nicht jede Linie, die sie produzieren, persönlich inspizieren, daher ruht ein Großteil meines Vertrauens auf ihren Kontrollen. Der blinde Fleck einer gemeinsamen Verifizierungsreferenz (Oracle) kann viele Untersuchungen beeinflussen, bevor ich es bemerke. Ich muss verstehen, was der Prüfer tatsächlich überprüft, und es anhand von Fällen testen, die fehlschlagen sollten.

Im weiteren Verlauf der Arbeit wurden diese Überprüfungen Teil des Repositorys. Ebenso die Gründe für Quelländerungen und Notizen, die eine spätere Sitzung dort aufnehmen ließen, wo eine frühere aufgehört hatte. Das Quellcode-Repository wurde zum Arbeitsspeicher des Projekts.

Ein erfolgreicher Batch gab uns sowohl wiederhergestellten Code als auch eine bessere Umgebung für den nächsten Batch.

Zwei verschiedene Rekonstruktionsideen

Von GensokyoClub öffentliche README-DATEI macht seine Ablehnung dieser Art von Arbeit deutlich. In der Bekanntmachung wird angekündigt, dass die weitere Entwicklung bis zur Fertigstellung privat erfolgen wird. Eine Passage lautet:

Der Aufstieg von Griftern (KI-Dekompilierungen und -portierungen) in diesem Bereich, die aus unserer Arbeit stammen, zeichnet ein schlechtes Bild für zukünftige Dekompilierungsbemühungen…

Der Hinweis beschreibt auch die psychologische Belastung der Betreuer. Ihre Beitragsrichtlinie schließt Pull-Anfragen aus, die hauptsächlich mit KI erstellt wurden. Sie haben ihre Freizeit in schwierige Arbeit gesteckt, und diese Arbeit hat dazu beigetragen, dass ich weitermachen konnte. Ich respektiere den Aufwand, der dahinter steckt. Die Meinungsverschiedenheit, die ich diskutieren möchte, betrifft die Frage, wie der Wiederaufbau ablaufen soll und wie ein Beitrag zu bewerten ist.

Im manuellen Workflow, den ich kannte, fiel das Entwickeln eines Funktionsverständnisses und das Rekonstruieren in der Regel derselben Person zu. Ein Projekt stützte sich stark auf das Fachwissen dieser Person. Das Vertrauen in den Mitwirkenden war wichtig, weil so viele Überlegungen während der Arbeit stattfanden.

Bestehende Projekte bewahren bereits Wissen in ihrer Quelle und bauen Werkzeuge. Was sich für mich geändert hat, war, dass ein Agent dieses Wissen nutzen konnte, um die nächste Untersuchung selbstständig durchzuführen.

In meiner Fortsetzung entscheide ich das Ziel und den Standard für die Annahme eines Ergebnisses. Der Agent hat große Freiheit zu untersuchen. Der vorgeschlagene Wiederaufbau muss dann die entsprechenden Kontrollen überstehen. Ich möchte, dass eine andere Person untersuchen kann, warum wir uns für eine Implementierung entschieden haben, auch wenn ein Agent die meiste Arbeit erledigt hat.

Dies kann ein schwieriger Übergang sein. Jahrelange sorgfältige Arbeit kann die Grundlage für eine Fortsetzung werden, die sich viel schneller bewegt. Das wirft echte Fragen zum Kredit auf. Es ändert auch, was Betreuer wissen müssen, bevor sie einen Beitrag annehmen.

Die industrielle Analogie hilft mir, darüber nachzudenken. In einem Handwerk hängt ein Großteil des Prozesses von den Fähigkeiten der Person ab, die ihn ausführt. Maschinen ändern sich dort, wo diese Fähigkeit benötigt wird. Jemand muss den Prozess noch entwerfen und erkennen, wenn seine Ausgabe falsch ist. Verschiedene Gemeinschaften können wählen, wie viel von dieser Veränderung sie übernehmen möchten.

Meine Entscheidung ist es, offen fortzufahren, wobei das ererbte Werk gutgeschrieben und seine Geschichte bewahrt wird. Ich möchte, dass die neue Arbeit überprüfbar ist. Das gibt uns die Möglichkeit zu fragen, wie weit dieser Ansatz gehen kann und aus dem zu lernen, was auf dem Weg schief geht.

Quelle: GensokyoClubS LIESMICH-Hinweis, überprüft am 10. Oktober 2026, und seine beitragsrichtlinie. Das Zitat ist ein gekürzter Auszug. Von TH08 credits und Provenienz notieren Sie die Fortsetzungsgrenze.

TH095 : Erfahrung beginnt sich zu vermehren

MODELL: TH095 , Schieße auf die Kugel, machte den Wert dieser Erfahrung viel leichter zu erkennen. Das Repository begann am 29. August mit null bestätigten Spielfunktionen im Hauptbuch. Wir mussten das Spiel noch lernen. Aber wir wussten schon viel mehr darüber, wie man einen Wiederaufbau beginnt und wie man ihn in Bewegung hält.

Bis zum 7. September hatten alle 697 identifizierten Spielfunktionen eine Quelle. Bis zum 8. September waren 696 als exakte Vergleiche akzeptiert worden. Das gesamte Programm ist am 9. September verlinkt. Die Windows i386-Rekonstruktion wurde am 10.September, etwa zwölf Tage nach der Initialisierung, als spielbar markiert.

Ich fand das spannender als die Geschwindigkeit des ersten Projekts. Ein neues Ziel könnte von der Arbeit an einem anderen Spiel profitieren. Die Erfahrung war bereits in den Tools und in der Organisation des Projekts vorhanden.

Zum Beispiel hatte uns TH08 beigebracht, frühzeitig auf das zusammengestellte Programm zu achten. Wenn mehrere wiederhergestellte Funktionen vom selben Zustand abhängen, lassen ihre isolierten Vergleiche eine wichtige Frage offen. Wir müssen sehen, wie sie zusammenarbeiten. Diese Lektion hat dazu beigetragen, wie wir uns dem gesamten Programmaufbau von TH095 näherten.

Eine Lektion, die in meinem Kopf bleibt, ist nützlich, während ich dort bin. Sobald überprüft wird, ob eine andere Sitzung ausgeführt werden kann, kann sie weiterhin helfen, nachdem ich weitergezogen bin. Der nächste Agent kann das Ergebnis verwenden, ohne die Untersuchung zu wiederholen, die dazu geführt hat.

Der Gleitkommakonstanten-Fehler gehört auch in diesen Speicher. Es erklärt, warum die Überprüfung einer Referenz auch die Überprüfung der Daten dahinter erfordert. Wenn diese Korrektur im Code beibehalten wird, können spätere Projekte vermeiden, dass der blinde Fleck der alten Prüfung vererbt wird.

Die Methode wird Teil des Ausgangsmaterials für das nächste Spiel. Wir können mehr von den Anstrengungen des nächsten Projekts darauf verwenden, was an seinem Ziel tatsächlich neu ist.

Der gleiche Vorteil steht Personen zur Verfügung, die später beitreten. Sie können eine Entscheidung einsehen und ihre Prüfung wiederholen, bevor sie die Arbeit fortsetzen. Sie müssen nicht die gesamte Projektgeschichte rekonstruieren, um herauszufinden, warum die Quelle so aussieht, wie sie aussieht.

TH04 : Der Workflow überlebt eine andere Architektur

MODELL: TH04 , Lotus Land Story, nahm diese Arbeit in die PC-98 DOS-Ära auf. Das Ziel war nun eine 16-Bit-Umgebung mit vier kooperierenden Programmen. Um das Hardwareverhalten zu verstehen, waren andere Beweise als bei den Windows-Spielen erforderlich. Bestehenden ReC98 Arbeit gab uns auch hier wertvolles Wissen und Quellenmaterial.

Die DOS-Rekonstruktion funktioniert jetzt. In meinen manuellen Tests habe ich komplette normale Routen durch ihre Enden gespielt und Speicherstände überprüft. Die aktuelle Arbeit ist eine native 64-Bit-Portierung. Das Einrichten einer funktionierenden DOS-Version gibt diesem Port zuerst eine Referenz.

Die Architektur veränderte das, was wir untersuchen mussten. Es hat auch den Compiler und die Laufzeit geändert, mit denen wir unsere Arbeit überprüft haben. Aber der Agent könnte immer noch einer Frage bis zu einem Ergebnis folgen und dieses Ergebnis das nächste Experiment leiten lassen.

Betrachten Sie den Übergang vom Gameplay zu einem Ende. Wir müssen wissen, welcher Staat diese Grenze überschreitet und welches Programm dafür verantwortlich ist. Das können wir gegen das DOS-Produkt untersuchen. Sobald die Beweise und Überprüfungen verfügbar sind, kann ein Agent die Frage ähnlich wie bei einem Windows-Titel bearbeiten.

Aus diesem Grund ist TH04 für das Argument von Bedeutung. Ein wesentlicher Plattformwechsel hat uns nicht gezwungen, mit einer neuen Arbeitsweise von vorne zu beginnen. Die Architektur definierte das Problem; Der Workflow gab uns immer noch einen Weg, es zu lösen.

Für den 64-Bit-Port können wir jetzt die neue Implementierung anhand des Verhaltens untersuchen, das bereits unter DOS wiederhergestellt wurde. Das Wissen aus dem Wiederaufbau gibt dem Hafen etwas, auf dem er aufbauen kann.

Projektstand per 10.Oktober 2026: DOS-Rekonstruktion und manuelles Testen · 64-bit-Anschluss. Der Hafen bleibt in der Entwicklung.

Vom exakten Code zum lesbaren Code

Sobald eine Rekonstruktion funktioniert, möchte ich, dass jemand anderes sie verstehen kann.

Montage und Rohversatz können sich für mich wie alte Freunde anfühlen. Mir ist klar, dass dies eine etwas ungewöhnliche Definition von “lesbar" ist." Die meisten Leute würden es vorziehen, der Logik des Spiels zu folgen, ohne das Speicherlayout der ausführbaren Datei im Kopf zu behalten.

Das ist wo semantische Rekonstruktion hereinkommen. Ein wiederhergestelltes Feld kann immer noch hauptsächlich durch seinen Offset bekannt sein. Wir verfolgen, wie das Spiel es verwendet, bis wir seine Rolle erklären können. Dann können wir ihm einen aussagekräftigen Namen und einen Typ geben, der zu den Beweisen passt. Wir behalten die Begründung bei der Quelle, damit die nächste Person sehen kann, woher diese Interpretation stammt.

Dies wird besonders wichtig für einen Software-Port. Eine absolute Adresse sagt mir, wo etwas in der alten ausführbaren Datei gelebt hat. Es gibt einer 64-Bit-Implementierung wenig Hilfe bei der Entscheidung, welches Objekt diesen Status besitzen soll. Um das Verhalten sicher zu verschieben, müssen wir die Beziehung hinter dem alten Speicherzugriff wiederherstellen.

Die Reihenfolge, die ich jetzt benutze, ist:

1. Stellen Sie eine genaue Basislinie wieder her. Kompilieren Sie die rekonstruierten Stücke mit dem historischen Compiler. Vergleichen Sie den relevanten Code und die relevanten Daten mit der ursprünglichen ausführbaren Datei. Zeichnen Sie ungelöste Differenzen auf, damit die nächste Phase einen klaren Ausgangspunkt hat.
2. Baue und spiele es auf der ursprünglichen Plattform. Verknüpfen Sie diese Teile mit der ursprünglichen Architektur und dem ursprünglichen Compiler mit dem realen Programm. Übe wichtige Spielpfade aus. Hier können wir Probleme mit dem gemeinsamen Status oder der Initialisierung finden, die ein isolierter Funktionsvergleich übersehen hat.
3. Rekonstruieren Sie die Semantik anhand beider Referenzen. Nehmen Sie jeweils einen zusammenhängenden Teil des Spiels und stellen Sie fest, was die wiederhergestellte Quelle bedeutet. Verbessere seine Darstellung unter Beibehaltung der genauen Vergleiche und des spielbaren historischen Builds.
4. Machen Sie den modernen Hafen. Verschieben Sie das etablierte Verhalten in die neue Umgebung, z. B. einen nativen 64-Bit-Build. Das rekonstruierte Original-Plattformspiel bleibt eine Referenz für den Vergleich des Verhaltens des Ports.

Der spielbare Build aus der zweiten Stufe wird zu einem zweite Verifizierungsreferenz (Oracle) während der dritten. Die erste Verifikationsreferenz (Oracle) prüft, ob unsere geänderte Quelle noch den relevanten Originalcode und die entsprechenden Originaldaten reproduziert. Die zweite überprüft, ob das rekonstruierte Programm auf den von uns ausgeübten Pfaden noch korrekt aufgebaut ist und sich korrekt verhält.

Sie fangen verschiedene Fehler. Eine Typänderung kann die generierten Anweisungen ändern. Ein Eigentümerwechsel kann dazu führen, dass zwei Teile des Spiels unterschiedliche Kopien des Zustands verwenden. Wenn Sie beide Überprüfungen verfügbar halten, muss der Agent dies konkret untersuchen, bevor er einen Refactor weiterführt.

Ein Name braucht einen eigenen Beweis. Ein genauer Vergleich kann uns nicht sagen, ob ein Feld wirklich “Unverwundbarkeitszeit" bedeutet." Wir müssen das anhand der Art und Weise feststellen, wie das Spiel es schreibt und verwendet. Bleibt die Bedeutung ungewiss, ist ein neutraler Name für den nächsten Leser hilfreicher als eine sichere Vermutung.

Diese Reihenfolge haben wir durch die Projekte gelernt. TH08 hatte bereits vor einigen seiner späteren Audits für historische Plattformen spielbare Ports. Das machte es schwieriger, bestimmte Mängel zu erkennen. Der Aktueller Workflow der Fabrik stellt den ursprünglichen Plattform-Build an die erste Stelle, damit die semantische Arbeit ihn als Referenz verwenden kann, bevor die Portierung beginnt.

Die genaue Rekonstruktion gibt uns einen Hinweis. Die semantische Rekonstruktion macht das gewonnene Wissen nutzbar. Ein Port kann dann auf beiden aufbauen.

Was macht diesen industriellen Wandel aus

Diese Projekte haben sich verändert, wo ich meine Aufmerksamkeit aufgewendet habe. Sobald Agenten einen Großteil einer Untersuchung vorantreiben konnten, wurde die Verbesserung ihres Arbeitsumfelds zu einem der nützlichsten Dinge, die ich tun konnte. Ein besseres Werkzeug könnte bei jeder späteren Funktion helfen, die es benötigt.

Autonomie ist hier wichtig. Der sinnvolle nächste Schritt wird oft erst nach einem gescheiterten Experiment klar. Ein Agent braucht genug Freiheit, um diesem Ergebnis irgendwo unerwartet zu folgen. Wenn es darauf warten muss, dass ich jeden Schritt vorschreibe, bleibt ein Großteil der Arbeit an meine Aufmerksamkeit gebunden.

Ich erwarte, dass der Agent falsche Hypothesen aufstellt. Entscheidend ist, ob wir sie testen und aus dem Ergebnis lernen können. Eine fehlgeschlagene Überprüfung sollte ihm helfen, den Fehler gut genug zu verstehen, um es erneut zu versuchen. Ich muss noch entscheiden, ob die gesammelten Beweise einen Projektmeilenstein unterstützen.

REA gibt dem Agenten Zugriff auf Analysetools. Eine Frage zum Aufrufer einer Funktion kann direkt zur Überprüfung dieses Aufrufers führen. Das Rekonstruktionsprojekt liefert den Compiler und seine eigenen Referenzprüfungen. Der Agent kann diese verwenden, um die von ihm vorgeschlagene Quelle zu testen und zu sehen, wo seine Erklärung steht.

Der Fehler TH08 zeigt, warum diese Überprüfungen eigene technische Aufmerksamkeit verdienen. Wenn derselbe Vergleich über Hunderte von Funktionen hinweg verwendet wird, kann sich eine Lücke darin viel weiter ausbreiten als ein Fehler in einer Implementierung. Das Testen des Prüfers verbessert das Feedback, das für alle späteren Arbeiten verfügbar ist.

Die industrielle Analogie hat hier ein nützliches historisches Beispiel. Boulton und Watt führten ein dampfmaschinenanzeige im Jahr 1796 um die Einstellung der Motorventile zu erleichtern. Eine Aufzeichnungsversion zeichnete den Druck über den Kolbenhub auf. Es stellte das interne Verhalten des Motors zur Inspektion zur Verfügung. Unsere Vergleichstools dienen einem ähnlichen Zweck: Sie lassen uns untersuchen, was die Maschinen tun, während wir sie verbessern.

Wir befinden uns in einem frühen Stadium dieses industriellen Wandels. Ein Großteil der Infrastruktur ist noch unausgereift. Agenten können sich schneller bewegen, als unsere Prüfungen unterstützen sollen, daher muss sich der Prozess neben ihnen entwickeln. Wenn wir einen Defekt in einem gemeinsam genutzten Tool finden, müssen wir ihn reparieren und die betroffenen Ergebnisse erneut überprüfen. Das nächste Projekt kann dann ein stärkeres Werkzeug erben.

Es gibt auch eine praktische Grenze für jedes einzelne Gespräch. Es wird enden, bevor eine große Rekonstruktion abgeschlossen ist. Das Quellcode-Repository muss es ermöglichen, dass eine weitere Sitzung fortgesetzt werden kann, ohne den Grund für die letzte Entscheidung zu verlieren.

Der Touhou-Wiederaufbaufabrik wuchs aus diesem Bedürfnis heraus. Es gibt Projekten eine gemeinsame Möglichkeit, ihre Prüfungen und Lektionen voranzutreiben. Die Arbeit an einem Spiel kann die Startbedingungen für ein anderes verbessern.

Das macht die industrielle Analogie für mich sinnvoll. Erfahrung wird Teil von Werkzeugen, die andere nutzen können. Die Verbesserung dieser Tools ändert, wie viel die nächste Person — oder der nächste Agent - erledigen kann.

Die Projekte, die wir jetzt in Betracht ziehen können

Das Tempo ist wichtig, weil es die Entscheidung ändert, zu beginnen. Ein Spiel könnte faszinierend zu rekonstruieren sein und trotzdem mehr von meiner eigenen Aufmerksamkeit verlangen, als ich es realistisch geben könnte. Viele Projekte würden Ideen bleiben.

Jetzt sehe ich einen Weg, ein solches Projekt durch wiederholte Untersuchungen am Laufen zu halten. Eine funktionierende Rekonstruktion macht einen Software-Port praktischer. Das Wiederherstellen lesbarer Semantik erleichtert es anderen, einen Mod zu erkunden. Der Aufwand, das Spiel zu verstehen, kann sich nach dem Start der ersten Version weiter auszahlen.

Ich schaue mir jetzt ein unbekanntes Programm an und frage: welcher Zugang, welches Feedback und welches gesammelte Wissen würden einen Agenten zuverlässig daran arbeiten lassen?

Diese Frage lässt mich über Projekte nachdenken, die ich vorher in Ruhe gelassen hätte. Jeder kann die Art und Weise verbessern, wie wir uns dem nächsten nähern. Ich möchte weiter erforschen, wie weit uns das bringen kann.

Weitere Artikel · Erkunden Sie eine TH04-Untersuchung