Warum man Agenten selbst bauen sollte

• LLM-Agenten sind eine technische Struktur, deren Funktionsweise man besser versteht, wenn man sie selbst implementiert, statt sie nur als Konzept zu begreifen
• Schon mit wenigen Dutzend Zeilen Python-Code lässt sich mit der OpenAI Responses API ein dialogorientierter Agent bauen; ergänzt man Tool-Calls, wird autonomes Verhalten möglich
• Der Kern eines Agenten ist eine wiederholte Aufrufschleife mit einem zustandslosen LLM; durch direkte Verwaltung des Gesprächskontexts (context) lassen sich Dialoge über mehrere Runden umsetzen
• Context Engineering ist ein Problem auf dem Niveau realer Programmieraufgaben und erfordert ein Design, das Eingaben, Ausgaben und Tool-Beschreibungen innerhalb der Token-Grenzen optimiert
• Agenten-Design ist derzeit ein offener softwaretechnischer Problemraum, in dem auch einzelne Entwickler durch Experimente neue Ansätze ausprobieren können

---

Die Einfachheit beim Schreiben von Agenten

• LLM-Agenten lassen sich ohne komplexe Konfiguration allein mit der OpenAI Responses API umsetzen
  • Im Beispielcode werden die Gespräche zwischen Nutzer und Modell in einer context-Liste gespeichert, die wiederholt übergeben wird, um dialogartige Antworten wie bei ChatGPT zu erzeugen
• Mit zwei Kontexten für eine „gute Persönlichkeit“ und eine „schlechte Persönlichkeit“ lässt sich ein Dialog mit mehreren Persönlichkeiten simulieren
  • Das LLM ist zustandslos; die Kontinuität des Gesprächs bleibt über ein vom Nutzer verwaltetes String-Array (context) erhalten
• Schon diese einfache Struktur ermöglicht mehrturnige Dialoge und macht die Arbeitsweise von LLMs direkt erfahrbar

Tool-Integration und autonomes Verhalten

• Dem Agenten kann eine ping-Funktion als Tool registriert werden, um den Status der Netzwerkverbindung zu prüfen
  • Die OpenAI API verlangt Tool-Definitionen im JSON-Format; fordert das LLM bei Bedarf einen Tool-Call an, führt der Python-Code ihn aus und übergibt das Ergebnis zurück
• Das LLM pingt auch ohne explizite Anweisung mehrere Hosts (google.com, www.google.com, 8.8.8.8) automatisch an
  • Das zeigt, dass ein LLM allein durch die „Berechtigung zur Tool-Nutzung“ autonome Entscheidungen treffen kann
• Die gesamte Schleife folgt einfach der Struktur „Tool-Call anfordern → ausführen → Ergebnis zurückgeben“, sodass sich autonomes Agentenverhalten auch ohne komplexe Steuerlogik umsetzen lässt

Praktische Anwendungen und Kritik an MCP

• Der Beispielcode ist simpel, lässt sich aber praktisch erweitern, etwa durch zusätzliche Tools (wie traceroute) oder kontextbasierte Speicherung mit SQLite
• MCP (Multi-Context Protocol) ist lediglich die Plugin-Schnittstelle von Claude Code oder Cursor und keine zwingend notwendige Technologie
  • Wer direkt mit der API arbeitet, kann dieselbe Funktionalität auch ohne MCP umsetzen
• MCP ist nur in Umgebungen ohne Kontrolle über den Code wirklich nützlich und kann sogar die Flexibilität der Agentenarchitektur einschränken
• LLM-Sicherheit ist komplex, aber durch getrennte Kontexte und eingeschränkte Tools lassen sich sichere Strukturen entwerfen

Die Bedeutung von Context Engineering

• „Prompt Engineering“ ist ein überhöhtes Konzept, Context Engineering hingegen ein reales Programmierproblem
  • Die Token-Zahl im Kontextfenster ist begrenzt, und Eingaben, Ausgaben sowie Tool-Beschreibungen belegen alle Platz
  • Wird diese Grenze überschritten, wird die Antwortqualität des Modells instabil
• Als Lösung kann man Sub-Agenten erstellen, ihnen unterschiedliche Kontexte und Tools zuweisen und sie so entwerfen, dass sie gegenseitig zusammenfassen und Informationen austauschen
  • Solche Strukturen lassen sich zu baumförmigen Agentennetzwerken oder Kompression auf Basis von Echtzeit-Zusammenfassungen erweitern
• Selbst komplexe Ideen haben dabei eine Einfachheit, die eine Implementierung innerhalb von 30 Minuten möglich macht

Offene technische Probleme und der Wert von Experimenten

• Derzeit entwickeln zahlreiche Startups Agenten zur Erkennung von Schwachstellen, und auch einzelne Entwickler können dieselben Experimente durchführen
• Agenten-Design umfasst noch ungelöste technische Aufgaben wie die folgenden
  • das Gleichgewicht zwischen Nichtdeterminismus und strukturiertem Programmieren
  • Ground Truth und das Verhindern eines vorzeitigen Abbruchs von Schleifen
  • Datenformate für den Austausch zwischen mehrstufigen Agenten (JSON, SQL, Markdown usw.)
  • Token-Zuteilung und Kostenkontrolle
• Diese Probleme sind kein Feld nur für groß angelegte Forschung, sondern auch durch Experimente Einzelner erforschbar; jeder Durchlauf lässt sich in wenigen Dutzend Minuten ausprobieren
• Letztlich ist die Erfahrung, selbst einen Agenten zu bauen, der Ausgangspunkt für das Verständnis der LLM-Technologie

[GN⁺]

Hacker-News-Kommentar

• Es gibt wirklich sehr viel, was man machen könnte. Ich würde gern selbst eine CPU aus NAND-Gattern auf einem Breadboard bauen und auch mal ein CDN in Rust schreiben, aber die Zeit fehlt.
  Stattdessen habe ich nach Karpathys Tutorial ein LLM gebaut, und ich finde, solche kleinen Experimente zwischendurch lohnen sich ziemlich.

  • Es fühlt sich wie eine endlose Kurve an. Früher habe ich mal einen 8-Bit-Computer auf einem Breadboard gebaut, und jetzt bin ich beim Flugtraining (PPL) gelandet.
    Immer wenn man denkt: „So, jetzt bin ich fertig“, hat man das Gefühl, dass die Ziellinie noch weiter wegrückt. Letztlich sind wir wohl einfach der Typ Mensch, der nie ganz zufrieden ist.
  • Im ersten Teil des Artikels wird erklärt, wie einfach man so etwas machen kann. Genau das ist der Kernpunkt des Textes.

• Im Beispiel wird GPT-5 verwendet, aber die Query-Schnittstelle ist schon auf Industrie-Standard-Niveau.
  Wenn man zum Beispiel OpenRouter.ai anschließt, kann man Modelle und Anbieter zur Laufzeit leicht wechseln.
  Es gibt auch kostenlose Modelle, etwa DeepSeek, aber die sind langsam und eingeschränkt. Zum Experimentieren sind sie trotzdem großartig.

• Vor ein paar Monaten habe ich mir selbst einen Agenten in Ruby gebaut. Das hat richtig Spaß gemacht.
  Die Kernlogik bestand aus nur vier Zeilen und war konzeptionell erstaunlich einfach.

  until mission_accomplished? or given_up? or killed?
    determine_next_command_and_inputs
    run_next_command
  end
  

• Ich habe vor zwei Jahren einen Agenten in 25 Zeilen PHP gebaut. Damals gab es noch kein Tool Calling, aber er funktionierte trotzdem ziemlich gut.
  LLMs fühlen sich für mich an wie UNIX-Textverarbeitungswerkzeuge wie sed oder awk — man gibt Eingaben und Anweisungen hinein und bekommt Ausgaben zurück.
  Wenn man LLM-Aufrufe auf diese Weise kombiniert und Schleifen oder Verzweigungen baut, entsteht ein ziemlich mächtiges System.
  Passender Code: hubcap, llm

  • Ich mag hubcap wirklich sehr. Es ist wenig Code, aber das Ergebnis war beeindruckend.
    Simon Willisons Beitrag hat mich stark inspiriert.

• Besonders nachvollziehbar finde ich den Teil darüber, sich selbst eine Alternative zu Claude Code zu bauen. Einen sich selbst verbessernden Coding-Agenten zu bauen, fühlt sich fast magisch an.
  Man kann das Modell frei austauschen, und mit schnellen Modellen wie Cerebras merkt man selbst bei interaktiven Tool-Aufrufen einen großen Unterschied.
  Wenn man dann noch Memory, Spracherkennung usw. ergänzt, wird es deutlich effizienter. Das lässt sich in wenigen Minuten umsetzen und macht wirklich Spaß.

  • Mich würde interessieren, welches Spracherkennungsmodell verwendet wird. Whisper war langsam und nicht genau genug, und GPT-Audiomodelle liefern oft Ablehnungsantworten.
    Die Google-Modelle waren qualitativ schwach, und die Mistral-Modelle sind zwar schnell, reagieren aber gelegentlich auf Text.
    Dadurch kommt es manchmal vor, dass statt meiner Worte der Bewusstseinsstrom des LLM mittranskribiert wird.
  • Der Ausdruck „build your own lightsaber“ gefällt mir wirklich gut.
    Anfangs habe ich es gebaut, um die innere Struktur zu verstehen, aber es war einfacher als gedacht, und inzwischen ergänze ich direkt die Funktionen, die ich haben will.
    Funktionen lassen sich schneller einbauen als bei einem Produkt für Teams. Agenten haben eine erstaunlich einfache Struktur.
  • Für den Einstieg wüsste ich gar nicht, wo ich anfangen soll. Von Cerebras habe ich noch nie gehört. Im Moment nutze ich nur Copilot in VS Code.
    Ich frage mich, ob das auf lokalen Modellen basiert.
  • Cerebras bietet inzwischen glm 4.6 an. Es ist immer noch extrem schnell und inzwischen auch deutlich intelligenter.

• Wenn man diesen Beitrag liest, bekommt man Lust, die Unix-Philosophie — Werkzeuge, die genau eine Sache gut machen — neu umzusetzen.
  Dadurch werden Agenten nicht nur einfacher, sondern auch sicherer.

  • Ich habe 2021 einen Agenten gebaut, der Netzwerkverbindungen testet, und wenn man dem Agenten grundlegende Tools wie ping, dig, traceroute gibt, liefert er ziemlich gute Ergebnisse.
    Es ist nicht so perfekt wie ein von Menschen gebautes Telemetriesystem, aber 90 % Nutzen waren damit sehr viel einfacher erreichbar.
  • Man könnte sich auch eine Werkzeugsammlung mit begrenztem Zweck vorstellen, die direkt Menschen zugänglich ist.
  • Um eine Sache wirklich gut zu machen, braucht man mehr Werkzeuge, und damit wächst auch das Kontextverständnis.
    Die ideale Größe eines LLM liegt vermutlich irgendwo dazwischen, etwas größer als klassische Unix-Tools.

• Ich frage mich, ob man wirklich unbedingt Agenten bauen muss.
  In einer Situation, in der alle AI-Anbieter Verluste machen, bin ich skeptisch, ob ein nachhaltiges Geschäftsmodell überhaupt möglich ist.

  • Wenn man selbst einen baut, versteht man die Funktionsweise und die Grenzen von Agenten intuitiv. Genau darum geht es.
  • Der Beitrag handelt einfach davon, mit der Technik zum Spaß zu experimentieren. Mit Monetarisierung hat das nichts zu tun.
    Es ist eine ähnliche Logik wie Astrals Verluste als Argument dafür zu nehmen, Python nicht zu verwenden.
  • Nicht alle AI-Unternehmen machen Verluste.
    Sie brauchen Kapital, weil das Training des nächsten Modells teuer ist, aber die Inferenzphase ist profitabel.
  • Man könnte auch selbst AI-Anbieter werden.
  • In diesem Kommentar schwingt ein wenig emotionale Erschöpfung mit. Ich frage mich, ob das von einem Entwickler mit vielen Berufsjahren kommt.

• Der Teil über Context Engineering hat bei mir besonders Resonanz ausgelöst.
  Ich baue gerade einen persönlichen Assistenten, der mehr Gedächtnis, Aufgabenverfolgung und Problemlösefähigkeit hat als ein allgemeiner Agent.
  Ich habe ihn so entworfen, dass mehrere Agenten miteinander sprechen und gemeinsam Probleme lösen, und der erste Agent übernimmt die Rolle eines Supervisors für Aufgabenmanagement.
  Je tiefer man in diesen Prozess einsteigt, desto mehr wird es zu einem Engineering-Problem.
  Mehr Details habe ich in meinem Blogbeitrag aufgeschrieben.

  • Klingt nach einem wirklich großartigen Projekt.

• Alle bauen gern Agenten, aber Debugging mag niemand.
  Am Anfang funktioniert alles wie Magie, doch nach und nach häufen sich stochastische Fehler, die sich schwer reproduzieren lassen.
  Wenn jeder Schritt 0,5 Sekunden dauert, wartet man schnell 10 bis 20 Minuten, nur um herauszufinden, wo etwas schiefgelaufen ist.

  • Deshalb habe ich ein Parallel-Ausführungstool gebaut, mit dem ich geänderten Code hunderte Male laufen lassen kann.
    Ich lasse auch frühere Szenarien erneut durchlaufen, um zu prüfen, ob nichts kaputtgegangen ist.

• Auf Basis des bereitgestellten Codes habe ich ein MCP gebaut: gurddy-mcp.fly.dev
  Den Source Code kann man im GitHub-Repository ansehen.