Wie man einen Coding-Agenten baut

(ghuntley.com)

62 Punkte von GN⁺ 2025-08-25 | 4 Kommentare | Auf WhatsApp teilen

Im Jahr 2025 ist es eines der besten Projekte, die ein einzelner Entwickler selbst ausprobieren kann, einen Coding-Agenten zu bauen
Ein Agent funktioniert allein mit 300 Zeilen Code und einer LLM-Token-Schleife und bietet damit die Chance, sich vom Konsumenten zum AI-Produzenten zu entwickeln
Die grundlegenden Bausteine sind Tools wie Dateien lesen, Dateien auflisten, Bash ausführen, Dateien bearbeiten und Code durchsuchen, mit denen sich echte Automatisierungsfunktionen umsetzen lassen
Bei der Modellauswahl eignen sich agentische Modelle wie Claude Sonnet und Kimi K2; bei Bedarf kann ein Orakel-Modell wie GPT als Tool für höherwertige Verifikation angebunden werden
Auch kommerzielle Produkte wie Amp, Cursor, Claude Code und GitHub Copilot basieren in der Praxis auf einer ähnlichen Struktur

Workshop-Überblick

Ein kostenloser Workshop von Geoffrey Huntley, der praxisnah zeigt, wie man einen Coding-Agenten selbst baut und wie er funktioniert
Bietet die Gelegenheit, Struktur und Prinzipien bestehender kommerzieller AI-Helfer wie Roo code, Cline, Amp, Cursor, Windsurf und OpenCode zu vergleichen und selbst nachzubauen
Durch die Bauerfahrung kann man über die Rolle eines bloßen AI-Nutzers hinauswachsen und sich zu einem Entwickler entwickeln, der mit AI selbst Automatisierungstools baut
Die Kernstruktur besteht darin, mit rund 300 Zeilen Code eine LLM-Token-Schleife zu nutzen, um Agentenfunktionen zu erzeugen
Für jedes Tool werden Primitive wie Lesen, Dateiliste, Ausführen, Bearbeiten und Code-Suche ergänzt; konkrete Beispiele und Code sind im GitHub-Repository veröffentlicht

Was ist ein Agent?

In letzter Zeit wird der Begriff „Agent“ sehr breit verwendet, doch seine tatsächliche Bedeutung und das innere Funktionsprinzip sind oft unklar
Da die Einstiegshürde für den Bau von Agenten sinkt, kann man über den AI-Konsumenten hinaus zu einem Produzenten werden, der Arbeitsautomatisierung aktiv vorantreibt
Stand 2025 ist das Prinzip hinter dem Bau von Agenten zu einem Pflichtwissen geworden, ähnlich wie grundlegende Datenbankkonzepte wie Primary Key
Unternehmen wie Canva empfehlen bereits im Bewerbungsprozess den Einsatz von AI, und Fähigkeiten zur AI-Automatisierung werden zu einem zentralen Einstellungskriterium
Wer heute zurückfällt, tut das nicht wegen AI, sondern weil er sich nicht weiterentwickelt und keine neuen Tools lernt

Das Kernprinzip von Coding-Agenten

Coding-Agenten bestehen lediglich aus 300 Zeilen Code und einer LLM-Token-Schleife und erfüllen ihre Aufgaben durch wiederholte Token-Eingaben
Das Konzept der gleichzeitigen Arbeit (concurrent work) ist wichtig
- Beispiel: Selbst während eines Zoom-Meetings kann ein Agent parallel weiterarbeiten und so die Arbeitseffizienz deutlich steigern
Nicht jedes LLM ist agentisch
- „hohe Sicherheit“ (z. B. Anthropic, OpenAI)
- „niedrige Sicherheit“ (z. B. Grok)
- „Orakel“ (gut für Zusammenfassungen und höheres Denken)
- „agentisch“ (handlungsorientiert, schnelle Iteration und Tool-Aufrufe)
Entwickler sollten die Eigenschaften der einzelnen Modelle verstehen und je nach Zweck das passende Modell auswählen
Eine bedingungslose Zuteilung großer Kontextfenster verschlechtert die Leistung; man sollte bedenken: „Je weniger zugeteilt wird, desto besser das Ergebnis“
- Zu viele registrierte MCP-Tools führen ebenfalls zu Leistungseinbußen
Regel: „Less is more“ → Nur die nötigen Tools und Daten sollten in den Kontext aufgenommen werden, um optimale Leistung zu erzielen

Ablauf beim Aufbau eines Coding-Agenten

1. Tool-Registrierung und Function Calling
- Man registriert im LLM zum Beispiel ein Tool zur Wetterabfrage, sodass das LLM in passenden Situationen im Format eines Function Calls darauf reagieren kann
- MCP (Model Context Protocol) ähnelt einem „Informationsbanner für Funktionen“; schon das Registrieren der Funktionsbeschreibung kann automatische Aufrufe ermöglichen
2. Kernfunktionen der einzelnen primitiven Tools
- Datei lesen (ReadFile): Liest beim Übergeben eines Pfads den Dateiinhalt als Kontext ein
- Dateien auflisten (ListFiles): Liefert eine Liste von Dateien und Ordnern in einem Verzeichnis
- Befehle ausführen (Bash): Das LLM führt Shell-Befehle des Systems aus und gibt die Ergebnisse zurück
- Datei bearbeiten (Edit): Automatisiert das Erstellen oder Ändern einer angegebenen Datei
- Code durchsuchen (CodeSearch): Durchsucht die gesamte Codebasis schnell anhand von Mustern, Keywords oder Funktionsnamen (mit ripgrep)
3. Beispiele und Ergebnisfluss
- Durch die Integration der einzelnen Tools in das LLM lässt sich allein mit natürlichen Sprachprompts zusammenhängende Arbeit automatisieren, etwa FizzBuzz-Code erzeugen und Ausführung prüfen oder Verzeichnisse durchsuchen und Inhalte analysieren
- Die Tool-Funktionen werden passend zu Benutzereingaben oder Szenarien innerhalb einer Schleife nacheinander aufgerufen und liefern wiederholt Ergebnisse zurück
- Die zentrale Abfolge im Agenten lautet: Benutzereingabe → Entscheidung über Tool-Aufruf → Tool-Ausführung → Zuweisung des Ergebnisses zum Kontext → Wiederholung

Erweiterbarkeit und Open Source

Derzeit arbeiten die meisten Coding-Agenten auf Basis bestehender Open-Source-Tools wie ripgrep
Auf GitHub gibt es einfache, aber leistungsstarke Agentenprojekte wie SST Open Code und mini-swe-agent, die in nur 100 Zeilen umgesetzt sind und als Referenz für Leistung und Struktur dienen können
Entwicklern wird empfohlen, statt nur Produkte zu vergleichen die Prinzipien durch eigenes Bauen zu verstehen und anzuwenden
Bei der Anwendung auf reale Arbeit und Automatisierung wird das Erstellen eigener Agenten und ihre Verbreitung im Unternehmen zu einem Wettbewerbsvorteil

Fazit und Implikationen

Coding-Agenten sind keine komplexe Technik, sondern bestehen aus einer einfachen Schleifenstruktur und einer Kombination von Tools
Der Schlüssel zum Bau von Coding-Agenten liegt im Verständnis der Struktur und der Fähigkeit zur schnellen Umsetzung; durch eigene Bauerfahrung kann man aktiv auf Veränderungen in der AI-Technologie reagieren
Wichtiger als AI selbst ist zum jetzigen Zeitpunkt kontinuierliche Selbstentwicklung und die Investition in die Fähigkeit, eigene Tools zu bauen als Strategie für persönliches Wachstum
„Nicht AI nimmt dir die Arbeit weg, sondern deine Kollegen, die mit Agenten bewaffnet automatisieren und schneller arbeiten“

4 Kommentare

GN⁺ 2025-08-25

Hacker-News-Kommentare

Unser Princeton-SWE-bench-Team hat mit etwa 100 Zeilen Code einen Agenten gebaut, der auf SWE-bench gute Ergebnisse erzielt; wer Interesse hat, sollte sich mini-swe-agent einmal ansehen.
- Ich bin überrascht, wie einfach die Struktur tatsächlich ist, danke fürs Teilen dieser Informationen.
  Der gesamte Code läuft im Grunde über diese Prompts: Quellcode des Basis-Prompts für den Agenten
```
Your task: {{task}}. Please reply
with a single shell command in
triple backticks.

To finish, the first line of the
output of the shell command must be
'COMPLETE_TASK_AND_SUBMIT_FINAL_OUTPUT'.
```
- Unter den Beispiel-Prompts für den Agenten ist der Teil „1. relevante Dateien in der Codebasis finden und lesen 2. ein Skript zur Reproduktion des Issues erstellen 3. das Issue beheben 4. die Behebung mit dem Skript verifizieren 5. Edge Cases testen“ nützlich.
  Ich verwende in Debugging-Loops selbst ähnliche Prompts.
  Der Ansatz „die Codebasis analysieren, mögliche Ursachen auflisten, nach Wahrscheinlichkeit priorisieren und Hypothesen mit Skripten oder Debug-Logging überprüfen“ hilft meiner eigenen Problemlösungsroutine sehr.
- Wenn ein Problem in sich geschlossen in einer einzigen Datei steckt, ist es mit einem LLM sehr einfach zu beheben.
  In einer typischen Codebasis sind Dateien und Kontext jedoch über viele Stellen verteilt, sodass es nicht leicht ist, sie entsprechend der strukturierten Designabsicht und Organisation des Entwicklers zu erfassen.
- Großer Applaus für den Versuch, auch wenn es etwas schade ist, dass es nicht viele Tools gibt.
  Der Großteil des Codes gehört zum Agenten-Framework, und auf SWE spezialisierter Code ist deutlich weniger vorhanden als gedacht.
  Ich habe aus Spaß auch einmal einen SWE-Agenten gebaut; vielleicht lohnt sich daher auch ein Blick auf autocode.
- Als kleines Dankeschön zu den Referenzen hinzugefügt.
Einen sehr ähnlichen „Leitfaden zum Bauen eines Agenten“ von Thorsten Ball gibt es auch als AmpCode How To Guide.
Insgesamt ist Amp ebenfalls ziemlich interessant.
Es ist inzwischen kein geheimer Service mehr, aber es freut mich, dass weiter Tools rund um Agent Coding veröffentlicht werden.
Ich denke, dass solche Agentenmodelle künftig standardmäßig in verschiedenster Software enthalten sein werden.
- Das ist viel angenehmer anzusehen, danke dafür.
- Es wird auch erwähnt, dass der Autor selbst bei Amp arbeitet.
- Ghuntley arbeitet ebenfalls bei Amp.
Man sagt, ein Bild sei 1000 Worte wert, aber in diesem Material wirken die Bilder so, als wären sie um 99,6 % im Wert reduziert.
Ich frage mich, was das überhaupt sein soll.
- Das ist Foliensatzmaterial für einen Konferenz-Workshop.
  Der Text ist ein Diktat der tatsächlichen Formulierungen aus dem Vortrag.
Ich frage mich, ob jemand die Nutzung von Tools erklären kann.
Ich verstehe es so, dass Claude, ChatGPT usw. per API „Tools“ bereitstellen und bei einer Tool-Call-Anfrage der Antwortgeber das Tool tatsächlich ausführt und das Ergebnis wieder zurückgibt.
Aber das Modell ist doch streng genommen textbasiert, daher frage ich mich, wie die API die Modellantwort in mehrere Strukturen umwandelt.
Ich vermute, dass es im Fine-Tuning-Prozess Beispiele gab, in denen bestimmte Tool-Aufrufe in Form spezieller Blöcke eingebettet wurden und das Modell das so gelernt hat, worauf die Claude-/ChatGPT-Server das interpretieren.
Ich würde gern wissen, ob es dazu Dokumentation oder Informationen über intern verwendete Spezial-Token gibt und wie verhindert wird, dass Nutzereingaben diese „bedeutungstragenden“ Token missbrauchen.
- Es gibt eine von Anthropic veröffentlichte Implementierungsdokumentation.
  Anthropic Tool Use Documentation
  Daraus wird klar ersichtlich, dass das Modell in Wirklichkeit nicht mit „Text“, sondern auf Token-Ebene arbeitet.
  Das ist ähnlich wie bei einem Compiler, der Quellcode parst und daraus eine Sequenz von „Tokens“ wie Schlüsselwörtern, Klammern und Strukturen bildet.
  Die Ausgabe kann neben den eigentlichen Wörtern auch Metadaten enthalten.
- Vom Konzept her hast du es richtig verstanden.
  Die einzige echte Schnittstelle zu einem LLM sind „Tokens“; Steuer- und Datenkanal sind nicht getrennt.
  In der Modell-API-Schicht werden Instruktionen für Tool-Aufrufe sowie die Liste verfügbarer Tools in den Prompt eingefügt, jeweils zusammen mit Beschreibungen.
  Wenn ein Tool-Aufruf nötig ist, fügt das Modell einen speziellen Block in die Antwort ein, einschließlich spezieller Tokens sowie des Tool-Namens und der Parameter; die API-Schicht extrahiert das und wandelt es in JSON um.
  Auch die Ergebnisse der Tool-Ausführung werden als spezielle Tokens kodiert und eingefügt.
  Dass Nutzer solche Tokens nicht selbst injizieren können, wird von der API-Schicht verhindert.
  Aktuelle SoTA-Modelle wurden für Tool-Aufrufe erheblich finegetunt, sowohl allgemein für generische Tool-Aufrufe als auch für spezifische Toolszenarien, etwa wenn ein Claude-Sonnet-Modell speziell auf Claude-Code-Tools abgestimmt ist.
  Es ist fast erstaunlich, dass das alles so gut funktioniert; beim Tool-Calling spielt Fine-Tuning wirklich eine Schlüsselrolle.
  Ganz ohne Fine-Tuning kann es zwar auch funktionieren, aber die Erfolgsquote sinkt deutlich.
- Ich denke, die Vermutung „Es wurde darauf finegetunt, Beispiele, die Tool-Aufrufe benötigen, in speziellen Blöcken zurückzugeben“ stimmt.
  Wenn es die Antwort nicht gut kennt oder entsprechend angewiesen wird, wurde es darauf trainiert, im Format für Tool-Aufrufe zu antworten.
  Dabei gab es sowohl Trainingsbeispiele für formatkonforme Tool-Aufrufe selbst als auch auf manche Werkzeuge spezialisierte Trainingsdaten.
  Zum Beispiel neigt gpt-oss dazu, ein Such-Tool zu verwenden, selbst wenn es nirgendwo ausdrücklich erwähnt wird.
  In der Anthropic-Dokumentation gibt es auch eine gesonderte Liste vertrauter Tools wie text_editor oder bash, und es ist sehr wahrscheinlich, dass für diese Tools auch die tiefere Bedeutung ihrer Verwendung separat trainiert wurde.
  In der Praxis ist die Struktur ziemlich fragil und basiert auf Signalen niedriger Ebene wie „Spezial-Token oder Token-Sequenzen“.
In der Aussage „Wenn man immer weiter Tokens in die Schleife wirft, entsteht ein Agent“ wirkt es wie realistischer Sarkasmus, wenn man „Tokens“ durch „Geld“ ersetzt.
Am Ende heißt das dann, dass ein Agent entsteht, wenn man nur weiter Geld verbrennt.
- Ich glaube nicht, dass man sagen kann, Tokens seien vollständig gleichbedeutend mit Geld.
  Lokale Modelle werden ebenfalls immer besser.
  Im Moment braucht man für die besten Ergebnisse zwar noch Tokens (= Geld), aber in Zukunft könnte das anders aussehen.
Wenn es nur so voller Bilder ist, wird es wirklich schwer zu lesen.
Es fühlt sich an, als würde man einen Scroll-Simulator ansehen.
Ich frage mich, warum man außer einem bash-Tool überhaupt andere Tools braucht.
Dinge wie Dateilisten, Repo-Suche und -Navigation oder das Bearbeiten von Dateiinhalten lassen sich doch alle auch nur mit bash erledigen.
Oder geht es um den Fall, der im obigen Beispiel von mini-swe-agent gezeigt wird?
- Technisch gesehen kann man mit bash allein bereits eine große Bandbreite an Aufgaben erledigen, und ich habe damit tatsächlich auch schon erfolgreich gearbeitet.
  Interessant ist, dass Agenten kreativer vorgehen, je stärker man die Tools einschränkt.
  Wenn man jedoch verschiedene trainierte Tools bereitstellt, kennt das Modell deren Nutzung oft bereits gut, wodurch der Token-Verbrauch effizienter wird und insgesamt auch die Erfolgsquote steigt.
  Wenn nur bash zur Verfügung steht, verheddert es sich zudem oft bei bashisms, Argumentbehandlung oder Leerzeichen.
- Separate Tools zu verwenden ist viel einfacher, als alles in ein einziges bash-Tool zu packen.
  Wenn man alles über bash abwickelt, muss man zusätzlich ein System bauen, das garantiert sichere Kommandos wie etwa Dateilisten sofort ausführt, für andere riskante Befehle aber erst die Zustimmung des Nutzers einholt.
  Wenn man Dateilisten als eigenes Tool bereitstellt, kann man außerdem verhindern, dass Dateien außerhalb des Projektverzeichnisses offengelegt werden.
- Praktisch reichen ein bash-Tool und ein Edit-Tool aus, damit ein Coding-Agent funktioniert, auch wenn Edit nicht zwingend erforderlich ist und es ohne nur ineffizienter wird.
  Schwieriger könnte es aber bei Dingen wie der Codesuche werden.
  Man könnte das vermutlich abfangen, indem man den Prompt so anpasst, dass ripgrep über bash verwendet wird.
- Warum braucht man eine IDE? Man kann doch auch alles in der Shell machen.
  Eine UI beziehungsweise ein Interface dient genau dazu, die jeweils benötigten Informationen und Aktionen im richtigen Moment bereitzustellen.
- Auf die Frage, warum außer dem bash-Tool noch andere Dinge enthalten sind, würde ich sagen, dass man wohl zunächst mit minimalen Tools beginnt und später immer noch bash hinzufügen kann.
Statt ausschweifend zu erklären, wie man einen Agenten baut, würde ich lieber ein Projekt sehen, das tatsächlich von einem Agenten gebaut wurde.
- Es wäre großartig, wenn du selbst einen Agenten baust und ihn auf HN als „Show HN“ teilst.
Kann jemand erklären, was mit den Achsen Oracle, Agent, high safety und low safety gemeint ist?
Ich habe das direkt mit den On-Device-Modellen von Edge und Chrome ausprobiert (phi4-mini, gemini nano) und war überrascht, wie gut es angesichts der Modellgröße funktioniert.
Experiment: how to build an agent on device

crawler 2025-08-25

Man sagt ja, ein Bild sei normalerweise 1000 Worte wert, aber bei diesem Material fühlt es sich so an, als wären die Bilder um 99,6 % im Wert reduziert. Ich frage mich echt, was das sein soll.

Total witzig, lol. Ich wusste erst nicht, was damit gemeint war, aber als ich auf den Link geklickt habe, habe ich es sofort verstanden.

savvykang 2025-08-25

Auch die Thumbnails der anderen Blogbeiträge sind miserabel – sie sehen absolut nicht so aus, dass man darauf klicken möchte.

nemorize 2025-08-25

Hahahahahahahahahahahahaha