Autor | Zheng Jiamei
Bearbeitung | Cen Feng
Git unterstützt seit mehr als zwanzig Jahren die Softwareentwicklung, doch Anthropic hat beschlossen, es zu ersetzen. Um sicherzustellen, dass das ständig erzeugte Code von Claude problemlos in den Entwicklungsprozess übergeht, haben 7 Ingenieure 5 Monate damit verbracht, das Buchsystem Scion zu entwickeln und den Kerncode-Repository dorthin zu migrieren. Im Mai dieses Jahres fusionierten die Anwender von Anthropic täglich durchschnittlich etwa 2500 Codeänderungen, und im September überstieg diese Zahl bereits 30.000. Das CI-System musste dabei täglich etwa 25 Millionen Code-Extracts ausführen. Die Geschwindigkeit beim Schreiben von Code steigt, während das Vorbereiten des Lagerplatzes, die Synchronisation von Objekten und die Abfrage der Historie immer mehr Energie verbraucht. Fast zur gleichen Zeit ersetzt GitHub den allgemeinen LLM in der Schlüsselscannung durch einen feinjustierten ModernBERT. Institutionen wie die Columbia University und Google DeepMind konvertieren mittels BTTF die Chip-Simulationswellenformen in SQLite, sodass Agenten SQL verwenden können, um Anomalien zu untersuchen. Scion ist standardmäßig online; BTTF wandelt die Wellenformen in eine Abfrageschnittstelle um, und GitHub überträgt die hohen Schwellenbeprüfungen an den Klassifikator. Das System, das auf dem Entwicklungsrhythmus der Menschheit entwickelt wurde, beginnt, eine weitere Belastung durch den Agent zu erleiden.
01
Warum die Offline-Fähigkeit von Git zu einer Last wurde
Das distribuierte Design von Git ermöglicht es Ingenieuren, nach dem Klonen des Repos auch ohne Internetverbindung zu committen, zu mergeen und die Historie anzusehen. Doch die Aufgabe von Anthropic, große Mengen an Code zu lesen, erfordert stets eine online laufende CI-Arbeit und einen Agent-Sandbox, der nach wenigen Minuten zerstört wird – möglicherweise benötigt es nur einige Dateien, einen Diff oder die Bestätigung der Vorfahrenbeziehung zweier Commits. Um diese Operationen vorzubereiten, ist das Aufbauen eines lokalen Repos immer teurer. Die Historie der Hauptlinie von Anthropic beträgt fast 100 GB, und die komprimierte Kopie umfasst mehr als 25 GB. Wenn jede Tag 25 Millionen Checkouts vollständige Kopien erhält, würde der theoretische Datenfluss über 600 PB liegen. Obwohl das Unternehmen leichte Klonungen, dünne Checkouts, Snapshots und Hunderte von Git-Images verwendet, müssen die Images weiterhin synchronisiert werden, die Snapshots verfallen und historische Abfragen erfordern die Ergänzung von Objekten. Je aktiver der Lagerraum ist, desto höher sind die Wartungskosten. Scion reduziert den Client auf einen leichten Eingang. Commit-Generierung, Merge, Base-Conversion und historische Abfragen werden in einem zentralen Service abgewickelt, lokale Überwachung von Dateichanges und ein kleiner Cache werden nur durchgeführt, wenn ein Arbeitsverzeichnis benötigt wird. CI: Wenn man nur den Diff berechnen möchte, kann man direkt die API aufrufen, ohne das gesamte Repository zu synchronisieren. Dies kostet die Offline-Unabhängigkeit, reduziert aber die wiederholten Initialisierungen. Die Commit-Formatierung hat sich auch geändert. Ein Git-Commit verweist auf den Baum des Repos, während Scions Changeset durch vorausgeschriebene Log-Einträge die durch die Inhaltspreferenzpunkte referenzierten Dateien mit dem ersten übergeordneten Commit ändern. Es ist nicht notwendig, ein Git-packfile zu erstellen, um einen Changeset zu erstellen, und es muss nicht sofort der gemeinsame Branch versetzt werden. Erst wenn Referenzen wie main aktualisiert werden, führt das System einen compare-and-swap für die Einzelzeile-Records in Spanner aus. Der Agent kann die Änderungen parallel erstellen, und die Konkurrenz konzentriert sich auf den Branch-Referenzversatz. Doch historische Abfragen sind weiterhin schwierig: Inkrementale Aufzeichnungen können nicht direkt beantworten, wer eine bestimmte Zeile verändert hat oder was das File durchgemacht hat. Scion speichert abgeleitete Daten für Blame, Pfad-Historie und Commit-Tree-Swaps, die vorausberechnet werden, oder erst nach der Abfrage erstellt werden, basierend auf der Beziehung zum Vater-Commit. Die Schreiboperation und die historische Analyse können unabhängig voneinander erweitert werden. Wenn die Lei Feng-Netzwerksuche durchgeführt wird, beginnt der scn-Clientserver im Zielverzeichnisbaum und fordert nur die fehlenden Baumstrukturen und Blobdateien an. Die Anfragen durchlaufen nacheinander den scion-Daemon auf den Knotenpunkten, den Bereichscion-Cache und werden dann vom scion-Server wieder auf Spanner oder Objektverzeichnis zurückgespeist. Nach der Schreibung von Objekten sind sie unveränderlich, die Caching kann zwischen Aufgaben genutzt werden, was die Absprachen, Komprimierung und wiederholten Übertragungen reduziert. Anthropic gibt an, dass die Caching-Erfolgsrate über 99% liegt, und beschränkt den Rückfluss an den Server bei Ausfällen. Nach der Migration ist die Anforderung an CPU und Speicher von Scion im Vergleich zum alten Git-Image-System etwa 200-mal geringer. Die Ausführung von Checkouts sinkt von Minuten auf Sekunden, und das CI nutzt etwa 25% der CPU-Leistung. Die 200-mal ist die Nutzung der Infrastrukturerweiterungen gemeint, nicht die allgemeine Beschleunigung der Git-Aufgaben. Anthropic baut außerdem gleichzeitig Antique-Code-Review-, Quellcode-Such-, IAM- und Batch-Merge-Tools auf, um den neuen Protokollen gerecht zu werden. Die Wartung der Online-Dienste wird ebenfalls zu einem neuen Kostenpunkt.02
Damit die Datenbank die Wellenform liest, kann der Agent den Fehler nachverfolgen
Die Chipsicherung steht vor einem anderen Hindernis. Die von RTL-Simulation erzeugten VCD- und FSDB-Waveformprotokolle zeigen den Zustand großer Signalmengen im Laufe der Zeit, und die Dumpss von komplexen Designs können Zehntausende von GB oder sogar TB umfassen. Die Ingenieure von Leifeng Network (Public Account: Leifeng Network) können in dem Waveform-Visualizer entlang der Zeitachse Anomalien suchen. Wenn der Agent das ursprüngliche Signal als Text umwandelt, wird der Kontext schnell von Zeitstempeln, Signalnamen und wiederholten Sprüngen überlaufen. Um andere Signale zu finden, könnte es auch erneut zu Datei-Readings kommen. Außerdem verwendet der Mensch gerne die Augen, um in Diagrammen nach einer „Kugel im Meer“ zu suchen, aber kein Agent kann auch den größten Kontext nicht einfassen, in dem Dutzende GB physikalische Dateien liegen. Daher ist es die beste Lösung, diese „toten Dateien“ in „lebende Schnittstellen“ umzuwandeln, die durch SQL präzise aufgerufen werden können. BTTF überträgt den Datenaustausch auf SQLite. signal_metadata speichert statische Informationen wie den Signalnamen, den Typ und die Hierarchie, während signal_changes die Signal-ID, das Zeitstempo und den Wert nach dem Wandel aufzeichnet; die beiden Tabellen sind durch eine ID verbunden. Aufruf zur Bestimmung des Zustands eines Signals zu einem bestimmten Zeitpunkt, SQL findet die letzten Veränderungsmeldungen vor diesem Zeitpunkt, um die Umkehrungen innerhalb einer Zeitperiode zu überprüfen, dann wird nach Zeitfenstern gefiltert und aggregiert. Der Zustand bleibt unverändert zwischen zwei Sprüngen, man darf keine neuen Meldungen als Unbekanntes betrachten. Das Modell muss nur Probleme und eine kleine Anzahl von zurückgegebenen Ereignissen verarbeiten. Zum Beispiel, wenn ein Teil des Handshake-Protokolls überschritten wird, kann der Agent zunächst die Veränderungen in Anfragen und Antworten suchen und dann auf den ungewöhnlichen Bereich reduzieren, um die Zeitreihenbeziehung zu überprüfen. Die Datenbank ist für die Suche verantwortlich, das Modell entscheidet, was als Nächstes gesucht wird. Die Abfrage muss die Signal-ID, die Zeitunit und die RTL-Version abgleichen. Doch das Hinzufügen der Wellenform in die Datenbank eliminiert nicht automatisch den Druck. Der hohe Frequenzschlüssel erzeugt dichte Aufzeichnungen, und der Einfügung pro Zeile führt zu Transaktionskosten. BTTF erstellt beim Erfassen eine Zuordnung zwischen der Wellenform-ID und der Datenbank-ID, statistisiert die Signalveränderungen und kombiniert Schleifenfilterung, Ausschneidung von Signalen ohne Veränderungen und Batch-Insertion. Ohne Ausschneidung frisst die Datenbank 1420 MB, die Abfrage dauert etwa 410,5 Millisekunden. Nach dem Filterieren des Schlüssels und der Signalen ohne Veränderungen reduziert sich die Größe auf 395 MB, die Zeitdauer sinkt auf 94,8 Millisekunden. Wenn man weiterhin Signale mit einer Veränderungsrate unter dem Durchschnitt löscht, kann die Datenbank auf 185 MB reduziert werden, aber die Aktivitätsquote liegt nur bei 64,23 %. Seltene Fehler können genau in Kontrollsignalen auftreten, die kaum umgekehrt werden. Die Daten wurden während der Importphase gelöscht, sodass die nachfolgenden Agenten keine Beweise wiederherstellen können. Das Skalieren muss den Anforderungen der Aussagen und der Fehlerbehebung entsprechen. Mit der SQL-Schnittstelle plant BTTF die Aufgaben für die verschiedenen Agenten: Der Orchestrierungs-Agent zerlegt die Aufgaben, der Analyse-Agent erstellt die Abfragen, der Überprüfungs-Agent überprüft die Aussagen und verbindet den RTL-Quellcode, der Bewertungs-Agent prüft das Zeitfenster, die Beziehungen der Felder und die Vollständigkeit der Ergebnisse. Zum Beispiel wenn ASSERT_KNOWN einen Signalzustand X/Z erkennt, der unbekannt ist, sperrt das System zunächst den fehlerhaften Moment ein und überprüft anschließend den Zustand der betreffenden Operationen, um schrittweise mögliche Module zu identifizieren. Ein SQL-Fehler kann auch korrigiert werden, bevor die Arbeit fortgesetzt wird. Im Experiment mit 4,2 GB Wavetabellen, 18450 Signalen und 150 Experten annotierten Anfragen erreichte das Forschungsteam eine Ausführungsgenauigkeit von 95,33 %. Die Qualitätsbewertung für Multi-Agenten ist um 17,3 % höher als bei Einzelagenten, die durchschnittliche Verzögerung hat sich ebenfalls um etwa 1,96-fach erhöht, und die Genauigkeit der statischen SVA-Prüfung beträgt 84,62 %. Das System unterstützt Nachsimulationen, aber die kontinuierliche Aufnahme und die komplexe Zuordnung müssen noch verifiziert werden.03
Warum wurde die Schlüsselscanner-Technik durch einen Klassifizierer ersetzt
Eine hohe Entropie-Zeichenfolge kann eine echte Verifizierung sein, aber auch Testdaten, Platzhalter oder eine Prüfsumme. Reguläre Ausdrücke können ein verdächtiges Format schnell identifizieren, sind jedoch nicht gut darin, den Codekontext zu beurteilen. Allgemeine LLMs können helfen, die Unterschiede zu erkennen, doch je mehr Kandidaten vorhanden sind, desto höher werden die Recheneffekte und die Verzögerung. Für Push Protection, bei der ein Ergebnis vor der Annahme des Code-Submissions erforderlich ist, hat diese Wartezeit direkten Einfluss auf die Entwicklungserfahrung. GitHub behält die regulären Ausdrücke als Eingangspunkt und überlässt die weitere Beurteilung einem feinjustierten ModernBERT. Es liest die Kandidatenzeichen, den Schlüsseltyp, den Variablennamen, den Datepfad und den benachbarten Code, gibt einen Risikoevaluationspunkt aus und entscheidet anschließend über einem Schwellenwert, ob eine Warnung ausgelöst wird. Der Kompressor kann durch vorwärtige Berechnung die Kategorie zurückgeben, ohne wie generativer LLM jede Tokens-Interpretation anzuzeigen, was für die Batch-Verarbeitung ähnlicher Anfragen geeignet ist. Die Schwierigkeit liegt bei harten Negationen: Zeichen ähneln dem Schlüssel, sind aber harmlose Beispiele. GitHub kombiniert Produktfeedback und manuelle Annotationen, Kandidaten mit hoher Rückführung aus echten Lagern sowie speziell synthetisierte schwierige negative Beispiele, und teilt die Trainings- und Bewertungsmengen nach Lagern, Kandidatenwerten und Verbindungen auf, um die durch ähnliche Daten verursachte Bewertungsabweichung zu reduzieren. Andernfalls könnte das Modell den Dateinamen merken, aber es sei schwierig, die Daten in fremden Projekten zu erkennen. Bei der Implementierung wird das Modell als ONNX exportiert und in 8-Bit-Qualität quantisiert, um die Ressourcen für die Berechnung zu reduzieren. Der Schwellenwert muss außerdem mit Precision, Recall und der Online-Traffic-Kalibrierung kombiniert werden: Zu lockere Werte führen zu Fehlalarmen, zu strenge Werte können jedoch echte Schlüssel übersehen. Bei der Einführung neuer Schlüsselformate müssen auch das Trainingsset und die Regeln aktualisiert werden. Im Vergleich zur alten LLM-Pipeline steigt die Offline-Precision des neuen Ansatzes um 13% und die Recall um 19%. Die Online A/B-Experimente zeigen, dass die Medianzeit für die Post-push-Scanning- Ausführung um 86% sinkt, die Kosten für den Modelldienst um mehr als 98% sinken und der gewichtete Alarm-Acceptance-Indikator nach dem Warenhändlerbesitzer um 11,5% steigt. Hier bezieht sich 98% auf die Kosten für das Modelldienstleistung, nicht auf den Gesamtpreis des gesamten Sicherheitssystems. Der Klassifizierer kann nur die von der Regel erkannten Kandidaten beurteilen, und der Abdeckungsbereich der Vorabregeln beschränkt weiterhin Fehlalarme. Wenn Regeln Hinweise finden, führt der Klassifizierer die Beurteilung aus, und die offene Analyse kann weiterhin an ein allgemeines LLM übergeben werden, um den generativen Inferenzaufwand jedes festen Urteils zu vermeiden.04
Vielleicht kommt nun die Reihe auf CI
GitHub hat die Feedbackzeit der Sicherheitsscans verkürzt, doch der Code muss anschließend noch gebaut, getestet und deployt werden. Nachdem Anthropic die Probleme bei der Downloadung des Quellcodes gelöst hatte, stieß es auf neue Schwierigkeiten: Die Testrunde ist noch nicht abgeschlossen, und die Hauptlinie könnte wieder Hunderte oder sogar Tausende von Änderungen einbeziehen. Die weiterhin Nutzung des globalen Locks führt zu einer ununterbrochenen Ansammlung von Änderungen, während das Aufgeben des Konflikts erneut neue Risiken mit sich bringt. Selbst wenn eine Testrunde bereits erfolgreich war, könnte der Codezustand der Version, die bereit zum Deployment ist, sich unterscheiden. Das bedeutet, dass CI nun prüfen muss, wie die Ergebnisse inmitten häufiger Änderungen gültig bleiben. Der Build-Cache muss Veränderungen im Quellcode und in den Abhängigkeiten erkennen, die Testprotokolle müssen mit konkreten Commitments und Build-Produkten verknüpft sein, und das System muss entscheiden, welche Ergebnisse wiederholt werden können und welche Änderungen die vorherigen Tests ungültig machen. Für ein Monorepo mit komplexen Abhängigkeiten ist es schwierig, nur mehr Testmaschinen hinzuzufügen, um die Probleme der Konfliktsänderungen zu lösen. Anthropic hat bereits die Tests nach der Merge und die Vorprüfung vor dem Deployment verstärkt. Für normale Teams ist es realistischer, zunächst die Abhängigkeitsanalyse, incrementale Tests und den Build-Cache zu verbessern, als direkt das Versionen-System neu zu konfigurieren. Da der Agent die Codeproduktion kontinuierlich erhöht, werden die Engpässe in der Softwareentwicklung weiterhin entlang des Delivery-Prozesses nach hinten verschoben. Die Geschwindigkeit, mit der Code in die Hauptlinie gelangt, kann immer schneller werden, aber zwischen Build, Test und Deployment muss eine zuverlässige Validierung bestehen bleiben. In Zukunft könnte es immer mehr Beispiele geben, dass der rasante Fortschritt von AI bei der Code-Erstellung letztendlich dazu führt, dass die gesamte Softwareentwicklungslinie „erneut durchgeführt“ werden muss. Der Wert der Infrastruktur für Ingenieure wird auch darin zum Ausdruck kommen, ob das schnell wechselnde Code weiterhin eine vertrauenswürdige Ausgabebasis erhält. Referenzlink: https://www.anthropic.com/engineering/redesigning-source-controlSteigen Sie ein, ich zeige Ihnen die Highlights der weltweiten AI-Konferenzen
Exklusives Zugangssystem:
Experten-Vortrag PPT
Vollständiger Bericht der Konferenz
Interpretation der beliebten Artikel
Interview mit der akademischen Newstar
Scannen Sie das QR-Code oben
Oder klicken Sie auf „Originalartikel lesen“, um sich im Spezialbereich zu followen.
Artikel von Leifeng.com – ohne Genehmigung ist eine Verbreitung untersagt. Weitere Informationen finden Sie unter Hinweise zur Verbreitung.