Hinweis des Autors: Dieser Artikel erklärt in 5 Schritten, wie man Akzeptanz-Gates für Agenten entwirft – damit lang laufende Agenten einen klaren Endpunkt, verlässliches Feedback und kontrollierbare Kosten bekommen.
Wenn ein Agent stunden- oder sogar tagelang durchläuft und am Ende ein Ergebnis abliefert, das vollständig aussieht, aber niemand es wagt, es direkt zu mergen – das ist ein Problem, mit dem viele Entwicklungsteams konfrontiert sind. Dieser Artikel stellt die 5-Schritte-Methode für das Design von Agent-Akzeptanz-Gates vor. Sie hilft dir, schon vor dem Start einer langen Aufgabe „fertig“ als ein Kriterium zu definieren, das die Maschine immer wieder selbst prüfen kann.
Am 27. Oktober 2026 stellte Gregory Kurtzer, einer der Gründer von CentOS, das Projekt Ginux vor. Berichten zufolge hat er innerhalb von 11 Tagen vor allem mit einer dauerhaft laufenden Codex-Aufgabe rund 139.000 Codezeilen hinterlassen – genug, damit dieser eigenständige Kernel Rocky Linux 10 bootet und systemd ausführt. Auf die Nachfrage, wie er einen aus der Spur geratenen Agenten wieder auf Kurs bringt, gab er eine einfache Antwort: indem man viele Gates einrichtet.
Das ist kein weiterer Artikel mit Tricks zur Eingabeaufforderung. Hier geht es um die Engineering-Struktur, auf die lange Aufgaben tatsächlich angewiesen sind: Ziel, Gates, Belege, Regression und Abbruchbedingungen.
Der Kernnutzen: Nach der Lektüre dieses Artikels kannst du für dein eigenes Projekt eine Reihe von Agent-Akzeptanz-Gates formulieren und einschätzen, welche Schritte du der Maschine überlässt und welche Entscheidungen zwingend beim Menschen bleiben müssen.
Kernpunkte der Agent-Abnahme-Gates
Agent-Abnahme-Gates sind vorab definierte, wiederholt ausführbare Prüfpunkte. Sie zeigen dem Agenten, ob das aktuelle Ergebnis den Anforderungen entspricht, und dem Menschen, welche Belege sich eine Prüfung lohnen.
| Punkt | Beschreibung | Nutzen |
|---|---|---|
| Abnahmekriterien vorab festlegen | Vor dem Start einer langen Aufgabe sind Endzustand und Meilensteine klar beschrieben | Verringert die Gefahr, dass der Agent einen Teilerfolg als vollständige Erledigung ausgibt |
| Gates sind ausführbar | Beurteilung anhand von Befehlen, Skripten, CI oder echten Laufzeitergebnissen | Der Agent kann selbst iterieren, ohne auf einen Menschen zu warten |
| Systemverhalten prüfen | Achten Sie darauf, was das Programm zur Laufzeit tatsächlich tut | Deckt falsche Ausgaben auf, die „glaubwürdig“ wirken |
| Klare Aufgabenteilung zwischen Mensch und Agent | Der Mensch legt Architektur und Abnahmekriterien fest, der Agent übernimmt Implementierung und Regression | Der Mensch ist nicht mehr der langsamste Teil im Kreislauf |
| Budget im Griff | Fehlversuche, Verbrauch und Abbruchbedingungen vorab festlegen | Verhindert, dass lange Aufgaben in die falsche Richtung weiterlaufen |
Agent-Abnahme-Gates im Ginux-Fall
Kurtzer hat dem Agenten nicht einfach die Aufgabe „Schreib einen Kernel“ übergeben, sondern harte Gates gewählt: Läuft ein Linux-Userspace-Programm, startet systemd? systemd hängt von vielen Systemkomponenten ab und ist der zentrale Prozess zum Starten und Betreiben des gesamten Systems. Deshalb eignet es sich gut, um zu prüfen, ob der Kernel wirklich brauchbar ist.
Das Projekt läuft in zwei aufeinander abgestimmten Zyklen. Der äußere Zyklus wird vom Menschen geführt: von der Vision über Architektur und Randbedingungen sowie Abnahme-Gates bis hin zur Prüfung des tatsächlichen Verhaltens und der Entscheidung, ob korrigiert oder abgenommen wird. Den inneren Zyklus übernimmt der Agent: implementieren, bauen und in QEMU ausführen, messen und Fehler analysieren, überarbeiten und Regressionstests durchführen – immer wieder.
Kurtzer warnt außerdem ausdrücklich davor, dass viele Fehler sehr glaubwürdige Ausgaben erzeugen, tatsächlich aber Semantik, Isolationsanforderungen oder Lebenszyklusverhalten verletzen. Fehlen die Gates, erhält man am Ende leicht Code, der an der Oberfläche läuft, strukturell aber schwach ist.
Warum Agent-Abnahme-Gates automatisch laufen müssen
Die Cursor-Engineerin Lauren Tan sieht Verifizierung ebenfalls als die wichtigste Fähigkeit im Umgang mit Agenten an. Unter Verifizierung versteht sie, den Agenten tatsächlich Code ausführen zu lassen, CPU-Traces oder Heap-Snapshots aufzunehmen, den iOS-Simulator zu öffnen und die App so zu bedienen, wie es ein Nutzer tun würde.
Sie gibt öffentlich an, monatlich 4000 PRs in die Produktion mergen zu können. Selbst wenn ein Mensch jeden PR nur 5 Minuten prüft, summiert sich das auf rund 333 Stunden. Bei diesem Umfang muss die Prüfung des Systems also ohne menschliches Eingreifen laufen. Dieser extreme Fall ist durchaus umstritten, veranschaulicht aber einen Grundsatz, der auch für normale Teams gilt: Nur wenn ein Agent seine eigene Ausgabe prüfen kann, kann er kontinuierlich weiterarbeiten. Kann er das nicht, bleibt ihm nichts anderes übrig, als dir den Diff zu übergeben und anzuhalten.
Die im Diagramm gezeigte Doppelschleife lässt sich direkt auf alltägliche Projekte übertragen. Wer Implementierung und Review auf verschiedene Modelle verteilen möchte, kann sie über APIYI apiyi.com anbinden und die Modellaufrufe in den inneren Zyklus einbeziehen.
Agent-Abnahmegates: Schnellstart mit der 5-Schritte-Methode
Das folgende Beispiel verwendet eine gängige Aufgabe: Der Agent soll einen alten REST-Dienst auf ein neues Framework migrieren, ohne dass bestehende Clients beeinträchtigt werden. Sie können die Prüfpunkte im Beispiel durch die Build-, Test- und Deployment-Prozesse Ihres eigenen Projekts ersetzen.
Schritt 1: Systemweite Endpunkte für die Agent-Abnahmegates definieren
Schreiben Sie zunächst einen beobachtbaren Satz, der beschreibt, was am Ende der Aufgabe mit dem System passieren soll. „Dienstmigration abgeschlossen“ ist zu vage, „mit derselben Charge von Replay-Anfragen stimmen Statuscodes und zentrale Antwortfelder des alten und neuen Dienstes überein“ lässt sich dagegen verifizieren.
Gute Endpunkte stammen meist aus realen Nutzungspfaden. Bei Ginux ist der Endpunkt erreicht, wenn Rocky Linux 10 den systemd-Zustand multi-user.target erreicht; bei einer Webanwendung kann der Endpunkt sein, dass der zentrale Nutzerfluss vollständig durchläuft; bei einer Datenaufgabe kann der Endpunkt sein, dass die Ausgabe mit dem Referenzdatensatz übereinstimmt.
Schritt 2: Die Abnahme-Gates des Agenten in fünf Ebenen aufteilen
Ein einzelnes Feedback aus dem finalen Test kommt zu spät, und wenn der Agent scheitert, lässt sich das Problem nur schwer lokalisieren. Setze die Gates deshalb nach aufsteigenden Laufkosten an, sodass billige Prüfungen zuerst offensichtliche Fehler abfangen.
| Gate-Ebene | Prüfinhalt | Beispiel | Aktion nach einem Fehlschlag |
|---|---|---|---|
| L1 Statische Constraints | Format, Typen, Abhängigkeitsgrenzen | Modulübergreifende Importe verboten | Agent behebt sofort |
| L2 Unit-Verhalten | Logik von Funktionen und Modulen | Zentrale Unit-Tests | Agent lokalisiert und behebt |
| L3 Integrationsvertrag | Schnittstellen, Datenbank, externe Abhängigkeiten | Vertragstests der Schnittstellen | Agent vergleicht die Abweichungen und überarbeitet |
| L4 Systemlauf | Reales Verhalten des vollständigen Dienstes | Dienst starten und Anfragen wiedergeben | Agent sammelt Logs und Performance-Daten |
| L5 Manuelle Abnahme | Architektur, Risiken und fachliche Abwägungen | Evidenzpaket prüfen und über den Merge entscheiden | Mensch gibt neue Constraints vor oder stoppt die Aufgabe |
Lauren Tans Dune-Architektur liefert ein extremes Beispiel für L1. Sie hat das Projekt über mehr als 600 PRs umgebaut und lässt die Abhängigkeitsgrafik per CI prüfen, damit die Verzeichnisse main und renderer von Electron sich nicht gegenseitig importieren. Gleichzeitig sind useEffect und Kommentare im Code verboten. Diese Regeln passen nicht unbedingt zu deiner Codebasis, aber der Ansatz, Team-Constraints in automatische Prüfungen zu gießen, ist auf jeden Fall nachahmenswert.
Schritt 3: Agent-Abnahme-Gates als ausführbare Karten formulieren
Für jedes Gate sollte es eine kurze Karte geben, die in der Projektdokumentation liegt, die der Agent beim Start lesen kann. Wenn die Karte klar formuliert ist, muss der Agent nicht raten, was „bestanden“ bedeutet, und Menschen können die Evidenz daran nachvollziehen.
| Feld | Vorgabe | Beispiel: Dienstmigration |
|---|---|---|
| Gate-Name | Nach Verhalten benennen | Konsistenz von Replay-Anfragen |
| Laufzeitumgebung | Feste Versionen und Abhängigkeiten | Isolierte Testumgebung mit festem Daten-Snapshot |
| Einstiegspunkt zur Ausführung | Einen eindeutigen Befehl angeben | make gate-replay (Beispielbefehl) |
| Bestandskriterien | Vergleichbare Ergebnisse verwenden | Statuscodes und alle Schlüsselfelder stimmen überein |
| Evidenzartefakte | Überprüfbare Dateien speichern | Differenzbericht, Dienstprotokolle, Leistungsaufzeichnungen |
| Schutzregeln | Kennzeichnen, was nicht geändert werden darf | Abnahmebeispiele und Bewertungsskripte schreibgeschützt |
| Fehlerstrategie | Nächste Schritte angeben | Bei demselben Fehler nach 3 erfolglosen Runden pausieren |
Dabei werden Schutzregeln am leichtesten übersehen. Der Agent neigt dazu, den kurzfristig bequemsten Weg zu wählen. Wenn er Abnahmebeispiele ändern oder Bewertungsskripte lockern kann, verlieren Testergebnisse ihre Aussagekraft. Es empfiehlt sich, diesen Teil in einem geschützten Verzeichnis abzulegen und Änderungen daran in der CI zu prüfen.
Schritt 4: Das Abnahme-Gate des Agenten in die automatische Regressionsschleife einbinden
Schreiben Sie die innere Schleife in die Aufgabenbeschreibung: Zuerst eine kleine Änderung umsetzen, dann das Gate der aktuellen Ebene ausführen, die Fehlerbelege lesen, überarbeiten und anschließend die bereits bestandenen Gates erneut ausführen. Diese Regression ist wichtig, denn sonst kann der Agent eine Stelle reparieren und dabei unbemerkt eine andere beschädigen.
Lassen Sie den Agenten am Ende jeder Runde festhalten, was geändert wurde, welche Gates ausgeführt wurden, wie die Ergebnisse aussehen und welche Probleme offen bleiben. Der Kontext bei langen Aufgaben wächst ständig; diese Aufzeichnung hilft späteren Sitzungen, den Zustand schnell wiederherzustellen, und erleichtert es Menschen zu beurteilen, ob der Agent kontinuierlich vorankommt oder sich im Kreis dreht.
Das Abnahme-Gate muss außerdem „falsches Bestehen“ verhindern. Die folgenden Fälle treten besonders bei langen Läufen häufig auf:
| Art des falschen Bestehens | Typisches Symptom | Gegenmaßnahme |
|---|---|---|
| Tests wurden geändert | Fehlschlagende Testfälle werden gelöscht oder die Bewertung wird aufgeweicht | Abnahmedateien sind schreibgeschützt, CI prüft Änderungen |
| Nur der Happy Path wird getestet | Normale Anfragen laufen durch, Ausnahmesituationen stürzen ab | Fehlerinjektion und Grenzfallproben ergänzen |
| Simulation ersetzt echte Abhängigkeiten | Alle Mocks sind grün, die Integrationsumgebung schlägt fehl | L4 muss echte Dienste ausführen |
| Ausgabe wirkt korrekt, ist aber semantisch falsch | Logs sind vollständig, das Lebenszyklusverhalten ist falsch | Zustände, Zeitabläufe und Nebenwirkungen vergleichen |
| Teilerfolg verdeckt Risiken | Eine einzelne Kennzahl verbessert sich, die Gesamtstabilität sinkt | Bei jedem Meilenstein die vollständige Regression ausführen |
Schritt 5: Menschliche Entscheidungspunkte und Stoppbedingungen für Agent-Akzeptanz-Gates festlegen
Menschen sollten sich auf die Entscheidungen konzentrieren, die ein Agent nur schwer ersetzen kann. Kurtzer ist verantwortlich für Architektur, Linux-Kompatibilitätsziele, das Betriebsmodell, die Interpretation von Fehlern und Stopp-Entscheidungen. Wenn er mit dem vom Agenten generierten Code unzufrieden ist, schließt er sogar die IDE, um dem Impuls zu widerstehen, selbst Hand anzulegen, und gibt stattdessen neue Anweisungen.
Empfohlen ist, mindestens drei Arten von Pausenbedingungen festzulegen: mehrere fehlgeschlagene Runden am selben Gate, der Versuch des Agenten, geschützte Inhalte zu ändern, oder eine Annäherung des Aufgabenumfangs an das Budget. Nach einer Pause sollte die Prüfung früher ansetzen, nämlich beim Evidenzpaket: zuerst Systemverhalten und Risiken betrachten und erst dann entscheiden, ob man sich eingehender mit dem Diff beschäftigt.
Tipp für den schnellen Einstieg: Wählen Sie zunächst einen kleinen Meilenstein, der sich an einem Tag abschließen lässt, und schreiben Sie nur 3 bis 5 Gate-Karten. APIYI apiyi.com bietet API-Zugriff auf die in diesem Artikel behandelten Modellserien wie GPT und Claude und ist mit den Schnittstellenformaten von OpenAI und Anthropic kompatibel. Bestehende Tools müssen in der Regel nur gemäß der Dokumentation die Schnittstellenadresse und den Schlüssel anpassen; die konkret verfügbaren Modelle lassen sich auf der Preisseite von APIYI prüfen.
Wie Akzeptanzprüfpunkte für Agenten die Kosten langer Aufgaben verändern
Bei langen Aufgaben darf man die Kosten nicht allein an der Frage messen, „wie viele Token insgesamt verbraucht wurden“. Im Bericht heißt es, dass die auf der Cursor-Startseite ausgewiesenen Token mindestens vier Kategorien umfassen: normale Eingabe, Modellausgabe, Cache-Schreiben und Cache-Lesen – und die Preise dafür unterscheiden sich erheblich. In der Community wurde schon mehrfach versucht, mit derselben Nutzungsmenge von 1,5 Billionen Token eine Rechnung zu schätzen, doch die Ergebnisse der verschiedenen Rechenwege lagen weit auseinander. Der Hauptgrund für die Abweichungen liegt in der Abrechnungslogik und im Cache-Anteil.
| Abrechnungsposten | Hauptquelle bei langen Aufgaben | Steuerungsmethode | Preisgrundlage |
|---|---|---|---|
| Normale Eingabe | Aufgabenbeschreibung, Logs, Codeausschnitte | Nur fehlerrelevante Belege übergeben | Maßgeblich sind die tatsächlichen Daten auf der Preisseite von APIYI |
| Modellausgabe | Code, Analyse und Überarbeitungsplan | Ausgabenumfang pro Runde begrenzen | Maßgeblich sind die tatsächlichen Daten auf der Preisseite von APIYI |
| Cache-Schreiben | Neu hinzugekommene oder geänderte stabile Kontexte | Projektregeln strukturell stabil halten | Maßgeblich sind die tatsächlichen Daten auf der Preisseite von APIYI |
| Cache-Lesen | Über mehrere Runden wiederverwendeter Kontext | Treffer beobachten und häufige Präfixänderungen vermeiden | Maßgeblich sind die tatsächlichen Daten auf der Preisseite von APIYI |
Die Gesamtkosten öffentlich dokumentierter Fälle lassen sich nutzen, um die Größenordnung eines Projekts einzuordnen – sie lassen sich aber nicht direkt in einen Stückpreis umrechnen. Die API-Aufrufkosten von Ginux werden mit rund 8000 US-Dollar angegeben, und Nicholas Carlinis Experiment, mit 16 parallelen Claude-Agenten einen C-Compiler zu bauen, kostete etwa 20.000 US-Dollar. Hinter diesen Zahlen stehen jeweils unterschiedliche Modelle, Cache-Konfigurationen und Aufgabenstrukturen. Für Ihr eigenes Projekt müssen Sie die Kosten daher separat kalkulieren.
Der sicherere Weg: Führen Sie zuerst einen vollständigen Meilenstein durch, protokollieren Sie dabei die Nutzung der vier Token-Kategorien sowie die Anzahl der fehlgeschlagenen Prüfpunkte und rechnen Sie anschließend mit den aktuellen Daten auf der APIYI-Preisseite https://docs.apiyi.com/models. So stammt Ihr Budget aus der eigenen Aufgabenstruktur und ist verlässlicher, als einfach den Durchschnittspreis anderer zu übernehmen.
Die Abbildung soll verdeutlichen, dass Prüfpunkte selbst Ressourcen verbrauchen, dass sie aber Fehler früher sichtbar machen. Für normale Teams sollte das Ziel sein, mit einem begrenzten Budget ausreichend Sicherheit zu gewinnen – und nicht, für jede Änderung die teuerste vollständige Validierung laufen zu lassen.
Häufige Fragen zu Agent-Abnahme-Gates (FAQ)
Q1: Was ist ein Agent-Abnahme-Gate?
Es handelt sich um vordefinierte, ausführbare Prüfpunkte, mit denen sich feststellen lässt, ob die Zwischenergebnisse eines Agenten den Standard erfüllen. Ein vollständiges Gate umfasst die Laufzeitumgebung, den Ausführungseinstiegspunkt, die Pass-Kriterien, die Evidenzartefakte und die Fehlerstrategie.
Q2: Worin unterscheiden sich Agent-Abnahme-Gates von gewöhnlicher CI?
CI ist ein gängiger Ausführungsmechanismus; ein Abnahme-Gate ist ein umfassenderes Konzept zur Aufgabensteuerung. Es prüft nicht nur, ob Code Tests besteht, sondern definiert auch Systemverhalten, Evidenz, Regressionsumfang, menschliche Entscheidungspunkte und Pausenbedingungen.
Q3: Wann müssen Agent-Abnahme-Gates unbedingt entworfen werden?
Wenn eine Aufgabe mehrere Änderungsrunden, mehrere Module oder längere Laufzeiten erfordert oder wenn fehlerhafte Ausgaben mit bloßem Auge schwer zu erkennen sind, sollte man die Gates im Voraus entwerfen. Bei einmaligen kleinen Skripten kann man es einfacher halten, aber mindestens einen ausführbaren Verifikationsweg sollte man klar definieren.
Q4: Braucht man mit Agent-Abnahme-Gates noch ein manuelles Code Review?
Ja. Automatische Gates eignen sich für bekannte Standards; Menschen bleiben weiterhin für Architekturentscheidungen, Risikoabwägungen und die finale Abnahme verantwortlich. Auch Kurtzer betont, dass Erfahrung nach wie vor entscheidend ist, wenn beurteilt werden muss, ob ein Ergebnis vollständig ist und ob ein lokaler Erfolg systemische Risiken mit sich bringt.
Q5: Wie bindet man Modelle über eine API ein, um diesen Ablauf umzusetzen?
1. Registrieren Sie sich bei APIYI apiyi.com und erstellen Sie einen API-Schlüssel.
2. Prüfen Sie im Dokumentationsbereich `docs.apiyi.com` die Endpunktadresse und die Aufrufmethode.
3. Wählen Sie je nach Tool das OpenAI- oder Anthropic-Schnittstellenformat und schließen Sie die Konfiguration ab.
4. Prüfen Sie unter `https://docs.apiyi.com/models` Modellbezeichnung und Preis, bevor Sie einen kleinen Testlauf starten.
Q6: Wie kann man Agent-Abnahme-Gates bei begrenztem Budget verschlanken?
Behalten Sie vorrangig die kostengünstigen L1- und L2-Gates bei und lassen Sie sie in jeder Runde laufen; L3 und L4 führen Sie erst bei abgeschlossenen Funktionen oder an Meilensteinen aus. Eine Jellyfish-Statistik über 12.000 Entwickler zeigt, dass typische Nutzer etwa 51 Millionen Token pro Monat verbrauchen – ein großer Unterschied zu Extremfällen. Daher sollte die Verifikationsfrequenz am Aufgabenrisiko ausgerichtet werden. Bei den Modellkosten sind die tatsächlichen Angaben auf der APIYI-Preisseite maßgeblich.
Q7: Welche Grenzen haben Agent-Abnahme-Gates?
Gates können nur die definierten Risiken abdecken; grüne Tests bedeuten nicht, dass der Code langfristig wartbar ist. Ginux kann Rocky Linux 10 starten, ist aber noch weit von einem produktionsreifen Kernel entfernt: Hardwareunterstützung, Schnittstellenstabilität, Sicherheitsprüfungen und Community-Pflege lassen sich nicht mit einem einzigen Lauf nachweisen. Die Kritik der Community am Muster häufiger PRs erinnert uns ebenfalls daran, die Wartbarkeit des Codes kontinuierlich im Blick zu behalten.
Kernaussagen zu Agent-Akzeptanz-Gates
- Zuerst den Endpunkt definieren: Beschreiben Sie die Aufgabenerledigung anhand beobachtbaren Systemverhaltens und vermeiden Sie vage Ziele.
- Gates staffeln: Gehen Sie von statischen Einschränkungen schrittweise zu realem Betrieb und manueller Abnahme über.
- Nachweise aufbewahren: Speichern Sie bei jedem Lauf Logs, Diff-Berichte und Performance-Aufzeichnungen.
- Bewertung unveränderlich halten: Abnahmebeispiele und Skripte sollten geschützt sein, damit der Agent keine Abkürzungen nimmt.
- Regressionen zur Routine machen: Führen Sie nach der Behebung neuer Probleme die relevanten bereits bestandenen Gates erneut aus.
- Menschen behalten die Entscheidung: Architektur, Risiken, Abbruch und endgültige Abnahme entscheidet die verantwortliche Person.
- Kosten zuerst im Testlauf prüfen: Validieren Sie zunächst im kleinen Maßstab über APIYI apiyi.com und kalkulieren Sie das Budget anschließend anhand der Preisseite.
Fazit: Autonome Workflows mit Agent-Akzeptanz-Gates aufbauen
Ob ein Agent lange Zeit autonom arbeiten kann, hängt davon ab, ob er klare Ziele und verlässliches Feedback hat. Beim Entwurf von Agent-Akzeptanz-Gates sollten Sie drei Punkte beachten:
- „Fertig“ zu einem ausführbaren Standard machen: Der Agent soll seinen Fortschritt anhand der Ausführungsergebnisse beurteilen.
- Häufige Prüfungen von Maschinen erledigen lassen: Verkürzen Sie den Feedback-Zyklus mit gestaffelten Gates, automatischer Regression und Nachweispaketen.
- Kritische Entscheidungen Menschen überlassen: Die verantwortliche Person legt Architekturrichtung, Risikogrenzen und den Zeitpunkt zum Anhalten fest.
Beginnen Sie am besten mit der nächsten Aufgabe mittlerer Größe: Schreiben Sie zuerst die Gate-Karte und starten Sie dann den Agenten. Wenn Sie verschiedene Modelle testen möchten, können Sie die Anbindung über Schnittstellen vornehmen, die mit den Formaten von OpenAI und Anthropic kompatibel sind; die Konfiguration ist im Dokumentationszentrum docs.apiyi.com beschrieben. Modellpreise und Abrechnungsmodalitäten richten sich nach den aktuellen Angaben unter https://docs.apiyi.com/models.
📚 Referenzen
- InfoQ – Bericht zum Ginux-Projekt: Wie Codex einen Linux-kompatiblen Kernel entwickelt und abnimmt
- Link:
infoq.cn/article/OiyNEtFwV05opvsLTcvK -
Beschreibung: Enthält die HDAE-Doppelschleife, den Projektumfang sowie eine Analyse der Grenzen
-
InfoQ – Bericht über die Token-Abrechnung eines Cursor-Ingenieurs: Hochintensive Agent-Workflows und die Kostenkontroverse
- Link:
infoq.cn/article/q9iebpvFozfy4bgCYUyE -
Beschreibung: Enthält den Verifikationskreislauf, die Dune-Architektur und Kritik aus der Community
-
Ginux-Technikbericht: Der von Gregory Kurtzer veröffentlichte Projektbericht
- Link:
zenodo.org/records/23682548 -
Beschreibung: Gut geeignet, um Forschungsziele, Methoden und die Grenzen der Ergebnisse näher kennenzulernen
-
Ginux-GitHub-Repository: Projektquellcode
- Link:
github.com/gmkurtzer/ginux -
Beschreibung: Hier können Sie den Projektcode und die Informationen zur Open-Source-Lizenz einsehen
-
APIYI-Dokumentation und Preisseite: Schnittstellenkonfiguration und Modellpreise
- Dokumentationslink:
docs.apiyi.com - Preislink:
https://docs.apiyi.com/models - Beschreibung: Modelltypen, Preise und Abrechnungsdetails entnehmen Sie bitte den tatsächlichen Angaben auf der Seite
Autor: APIYI-Team
Technischer Austausch: Besuchen Sie APIYI apiyi.com und tauschen Sie sich mit uns über Agent-Engineering-Praktiken aus. Weitere Integrationsinformationen finden Sie im Dokumentationszentrum unter docs.apiyi.com.
