> KI-Agenten evaluieren: Ergebnis- und Trajektorie-Grader, Match-Modi, pass^k, isolierte Umgebungen und LLM-Judges, die belastbar sind.
>
> Web page: https://balazscsorba.com/de/blog/evaluating-ai-agents-trajectories · Language: Deutsch · Also available in: [English](https://balazscsorba.com/blog/evaluating-ai-agents-trajectories.md) · [Magyar](https://balazscsorba.com/hu/blog/evaluating-ai-agents-trajectories.md)
> Author: Balázs Csorba · Published: 2026-10-16 · Keywords: evaluating AI agents, agent trajectory evaluation, agent evals, tool call accuracy, trajectory match evaluator, pass^k metric, tau-bench, LLM as a judge for agents, agent regression testing, outcome vs trajectory evaluation, agentevals, tool correctness metric

[Blog](https://balazscsorba.com/de/blog)/LLMOps & Evals

# KI-Agenten evaluieren: Trajektorien, Ergebnisse und Zuverlässigkeit bewerten

KI-Agenten evaluieren: Ergebnis- und Trajektorie-Grader, Match-Modi, pass^k, isolierte Umgebungen und LLM-Judges, die belastbar sind.

[Balázs Csorba](https://balazscsorba.com/de/about)·16\. Oktober 2026·9 Min. Lesezeit

-   Agent evals
-   Trajectories
-   Tool calling
-   pass^k
-   LLM-as-judge

![Eine Agenten-Trajektorie aus Tool-Aufrufen wird zweimal bewertet: ein Trajektorie-Grader prüft Reihenfolge und Argumente, ein Ergebnis-Grader vergleicht die Datenbank mit dem Zielzustand.](https://balazscsorba.com/images/blog/evaluating-ai-agents-trajectories/cover.webp?v=d4f9ed74c3)

## Das Wichtigste in Kürze

-   Bewerte das Ergebnis gegen den Zustand der Umgebung; die finale Nachricht des Agenten ist das schwächste Erfolgssignal.
-   Nutze Trajektorien-Prüfungen für Invarianten, die auf jedem Pfad gelten müssen, und verlange keinen exakten Pfad, weil Agenten gültige Alternativen finden.
-   agentevals bietet strict, unordered, subset und superset als Trajektorien-Matching plus Argumentregeln pro Tool; DeepEval und Ragas decken Ähnliches ab.
-   pass^k, die Wahrscheinlichkeit, dass alle k Trials gelingen, zeigt Unzuverlässigkeit, die pass@k verbirgt; bei 75 % pro Trial liegt drei von drei bei etwa 42 %.
-   Starte jeden Trial in einer sauberen Umgebung, kalibriere LLM-Judges gegen Menschen und baue Tasks aus 20 bis 50 echten Fehlern.

Auf dieser Seite

1.  [Ergebnis und Trajektorie: die zwei Dinge, die du bewertest](https://balazscsorba.com/#outcome-vs-trajectory)
2.  [Code-, Modell- und menschliche Grader](https://balazscsorba.com/#three-kinds-of-graders)
3.  [Trajektorien-Matching: strict, unordered, subset, superset](https://balazscsorba.com/#trajectory-matching)
4.  [Zuerst Ergebnisse bewerten, Pfade nur für Invarianten](https://balazscsorba.com/#grade-outcomes-not-paths)
5.  [pass@k und pass^k: ein Trial ist keine Messung](https://balazscsorba.com/#pass-at-k-vs-pass-hat-k)
6.  [Isolierte Umgebungen, sonst lügt der Eval](https://balazscsorba.com/#isolated-environments)
7.  [LLM-Judges für Trajektorien](https://balazscsorba.com/#llm-judges-for-trajectories)
8.  [Capability-Suites, Regression-Suites und woher Tasks kommen](https://balazscsorba.com/#capability-and-regression-suites)
9.  [Tooling: wo Traces und Grader leben](https://balazscsorba.com/#tooling)
10.  [Checkliste](https://balazscsorba.com/#checklist)
11.  [Quellen](https://balazscsorba.com/#sources)

Diesen Artikel anhören

0:000:00

Ein Agent, der "Ihre Erstattung wurde bearbeitet" schreibt, und ein Agent, der die Erstattung tatsächlich bearbeitet hat, sehen im Chatverlauf identisch aus. Agenten zu evaluieren heißt, über die letzte Nachricht hinauszuschauen: auf das **Ergebnis** (was sich in der Welt verändert hat) und auf die **Trajektorie** (welche Tools in welcher Reihenfolge mit welchen Argumenten aufgerufen wurden). Wer nur den finalen Text bewertet, baut Agenten, die Evals bestehen und Kunden enttäuschen.

Dieser Artikel ist die agentenspezifische Fortsetzung von [LLM-Evals für Produktfeatures](https://balazscsorba.com/de/blog/llm-evals-for-product-features). Er behandelt das Vokabular, die drei Arten von Gradern, Trajektorien-Matching mit agentevals, DeepEval und Ragas, warum pass^k für kundennahe Agenten wichtiger ist als pass@1 und wie du verhinderst, dass die Eval-Umgebung dich belügt.

## Ergebnis und Trajektorie: die zwei Dinge, die du bewertest

Anthropics Leitfaden vom Januar 2026 liefert ein Vokabular, das sich zu übernehmen lohnt. Ein **Task** ist ein Testfall mit Eingaben und Erfolgskriterien; jeder Versuch ist ein **Trial**. Ein **Grader** bewertet einen Aspekt eines Trials. Das **Transkript** (auch Trace oder Trajektorie) ist die vollständige Aufzeichnung: Ausgaben, Tool-Aufrufe, Reasoning, Zwischenergebnisse. Das **Ergebnis** (Outcome) ist der Endzustand der Umgebung. Das Beispiel dort: Ein Flugbuchungsagent schreibt vielleicht "Ihr Flug ist gebucht", aber das Ergebnis ist, ob in der Datenbank eine Reservierung existiert.

τ-bench, einer der Referenz-Benchmarks für Agenten, bewertet genau so: Er vergleicht den Datenbankzustand am Ende einer Konversation mit einem annotierten Zielzustand. Das ist die stärkste Einzelprüfung, die du bauen kannst, weil sie sich nicht dafür interessiert, was der Agent gesagt hat, sondern nur dafür, was er getan hat.

Bewerte die Trajektorie auf Regeln, die unterwegs gelten müssen, und das Ergebnis auf das, was sich tatsächlich geändert hat. Die finale Nachricht ist das unzuverlässigste der drei Signale.

## Code-, Modell- und menschliche Grader

Jeder Grader betrachtet entweder das Transkript oder das Ergebnis. Anthropics Leitfaden teilt sie in drei Familien, und ein guter Agenten-Eval mischt alle drei:

Grader

Typische Prüfungen

Stärken

Schwächen

tagchildren

Ergebnisprüfung, genutzte Tool-Aufrufe und Parameter, Anzahl der Turns, Token-Verbrauch, String- und Regex-Matches, Tests

Schnell, günstig, objektiv, reproduzierbar

Spröde bei gültigen Varianten; wenig Nuance

tagchildren

Rubrik-Bewertung, Aussagen in natürlicher Sprache, Paarvergleich, referenzbasierte Bewertung

Flexibel, kommt mit offener Ausgabe zurecht

Nicht deterministisch, teurer, muss gegen Menschen kalibriert werden

tagchildren

Expertenreview, Stichproben, A/B-Tests

Goldstandard, entspricht Expertenurteil

Langsam und teuer; zur Kalibrierung der anderen nutzen

Scores lassen sich als gewichtete Summe gegen einen Schwellenwert, binär (alle müssen bestehen) oder hybrid kombinieren. Mein Standard für Business-Agenten: binär bei sicherheitsrelevanten Code-Prüfungen (nie eine Erstattung ohne Verifizierung), gewichtet bei allem anderen.

## Trajektorien-Matching: strict, unordered, subset, superset

Wenn du eine Referenz-Trajektorie hast, ist die Frage, wie genau der Agent ihr folgen muss. LangChains Open-Source-Paket [agentevals](https://github.com/langchain-ai/agentevals) benennt die vier sinnvollen Antworten als Werte von `trajectory_match_mode`:

Modus

Besteht, wenn

Geeignet für

tagchildren

Gleiche Nachrichten, gleiche Reihenfolge, gleiche Tool-Aufrufe (Nachrichtentext darf abweichen)

Abläufe, bei denen die Reihenfolge die Regel ist: erst verifizieren, dann erstatten

tagchildren

Gleiche Tool-Aufrufe in beliebiger Reihenfolge

Informationsbeschaffung, bei der jede Quelle konsultiert werden muss

tagchildren

Der Agent hat keine Tools über die Referenz hinaus aufgerufen

Schutz vor zusätzlichen, teuren oder riskanten Aufrufen

tagchildren

Der Agent hat mindestens die Referenz-Tools aufgerufen

Pflichtschritte, zusätzliche Abfragen erlaubt

Argumente werden separat abgeglichen. Standardmäßig verlangt agentevals identische Argumente; `tool_args_match_mode` lässt sich auf `ignore`, `subset` oder `superset` setzen, und `tool_args_match_overrides` nimmt Regeln pro Tool an, auch eine eigene Vergleichsfunktion (etwa Städtenamen ohne Groß-/Kleinschreibung):

```
from agentevals.trajectory.match import create_trajectory_match_evaluator

# Refund flow: the agent may look things up freely, but must make these calls.
evaluator = create_trajectory_match_evaluator(
    trajectory_match_mode="superset",
    tool_args_match_overrides={
        "issue_refund": ["order_id"],          # only order_id must match exactly
        "lookup_order": "ignore",              # any lookup arguments are fine
    },
)
result = evaluator(outputs=agent_messages, reference_outputs=reference_messages)
# {'key': 'trajectory_superset_match', 'score': True, 'comment': None}
```

Andere Frameworks decken dasselbe Feld mit anderen Namen ab. DeepEvals `ToolCorrectnessMetric` vergleicht erwartete und aufgerufene Tools, standardmäßig nach Namen, optional auch nach Eingabeparametern und Ausgabe, mit Schaltern für Reihenfolge und exakte Übereinstimmung. Ragas bietet `ToolCallAccuracy` (standardmäßig strikte Reihenfolge, mit flexiblem Modus), `ToolCallF1` für Precision und Recall über Aufrufe und `AgentGoalAccuracy`, wenn nur das Ergebnis zählt. Nimm ein Framework pro Projekt; die Konzepte sind übertragbar. Meine Reviews zu [DeepEval](https://balazscsorba.com/de/tools/deepeval) und [Ragas](https://balazscsorba.com/de/tools/ragas) beschreiben die Abwägungen.

## Zuerst Ergebnisse bewerten, Pfade nur für Invarianten

Bei Trajektorien ist die Versuchung groß, exakt den Pfad zu verlangen, den du selbst gewählt hättest. Anthropic rät davon ab: Agenten finden regelmäßig gültige Wege, die der Eval-Designer nicht vorhergesehen hat, daher sei es "oft besser zu bewerten, was der Agent produziert hat, nicht den Weg, den er genommen hat". Ihr eigenes Beispiel ist bemerkenswert. Opus 4.5 löste ein Flugbuchungsproblem aus τ²-bench, indem es eine Lücke in der Richtlinie fand; es "fiel" im Eval wie geschrieben durch und lieferte dem Nutzer trotzdem das bessere Ergebnis.

Deshalb nutze ich Trajektorien-Prüfungen für **Invarianten**, die wenigen Regeln, die auf jedem Pfad gelten müssen, und Ergebnisprüfungen für den Erfolg. Invarianten sind meist kurz und lassen sich leicht im Code ausdrücken:

```
def check_invariants(calls: list[dict]) -> list[str]:
    """calls: tool calls from the transcript, in order: {"name": ..., "args": {...}}"""
    errors, verified = [], False
    for c in calls:
        if c["name"] == "verify_customer":
            verified = True
        if c["name"] == "issue_refund":
            if not verified:
                errors.append("refund before customer verification")
            if c["args"]["amount"] > 500:
                errors.append("refund above approval limit")
        if c["name"] in {"delete_account", "send_bulk_email"}:
            errors.append(f"forbidden tool: {c['name']}")
    if len(calls) > 25:
        errors.append(f"{len(calls)} tool calls, budget is 25")
    return errors
```

Das ist binär und günstig, läuft bei jedem Trial und bestraft keine kreativen Wege. Kombiniert mit der Ergebnisprüfung gegen die Datenbank erwischst du die zwei Fehler, die am meisten zählen: Der Agent hat das Falsche getan, oder er hat das Richtige auf verbotenem Weg getan. Welche Aktionen überhaupt ein menschliches Gate brauchen, beschreibt [Human in the Loop für KI-Agenten](https://balazscsorba.com/de/blog/human-in-the-loop-ai-agents).

## pass@k und pass^k: ein Trial ist keine Messung

Agenten sind nicht deterministisch; ein Task, der einmal besteht, kann beim nächsten Lauf scheitern. Zwei Metriken beschreiben das. **pass@k** ist die Wahrscheinlichkeit, dass mindestens einer von k Trials gelingt; sie steigt mit k. **pass^k** ist die Wahrscheinlichkeit, dass alle k Trials gelingen; sie sinkt mit k. Die Rechnung aus Anthropics Leitfaden: Ein Agent mit 75 % Erfolgsquote pro Trial besteht alle drei von drei Trials mit einer Wahrscheinlichkeit von 0,75³ ≈ 42 %.

Derselbe Agent wirkt unter pass@k fast perfekt und unter pass^k unzuverlässig. Kundennahe Agenten sollten am zweiten Wert gemessen werden.

τ-bench hat pass^k genau wegen dieser Lücke eingeführt. Im Paper von 2024 lösten selbst moderne Function-Calling-Agenten wie gpt-4o weniger als die Hälfte der Tasks, und pass^8 lag in der Retail-Domäne unter 25 %. Ein Coding-Agent kann mit pass@k leben, weil ein funktionierender Patch reicht. Ein Support-Agent kann das nicht: Jeder Kunde bekommt genau einen Trial. Führe jeden Task mindestens drei- bis fünfmal aus und berichte beide Zahlen.

## Isolierte Umgebungen, sonst lügt der Eval

Ergebnisbewertung braucht eine echte Umgebung: eine befüllte Datenbank, eine Sandbox für Datei- und Shell-Tools, gemockte externe APIs. Anthropic betont, dass jeder Trial in einem sauberen Zustand starten muss, weil geteilter Zustand korrelierte Fehler verursacht und Scores aufblähen kann. Ihr Beispiel: In internen Evals verschaffte sich Claude bei manchen Tasks einen unfairen Vorteil, indem es die git-Historie früherer Trials las.

-   **Seed pro Trial.** Datenbank aus einer Fixture hochfahren, laufen lassen, gegen den Zielzustand diffen, wegwerfen.
-   **Zeit und Zufall einfrieren,** wo Tools davon abhängen ("Bestellungen der letzten Woche").
-   **Die Außenwelt deterministisch mocken,** die Fehlerantworten aber realistisch halten: Timeouts, 429er und Validierungsfehler gehören zu dem, was du testest.
-   **Den Harness identisch zur Produktion halten:** gleicher System-Prompt, gleiche Tool-Beschreibungen, gleiche Limits. Anthropics Punkt: Du evaluierst Modell und Harness zusammen.

## LLM-Judges für Trajektorien

Manche Qualitäten kann im großen Maßstab nur ein Modell bewerten: Hat der Agent eine sinnvolle Rückfrage gestellt, hat er die Ablehnung höflich erklärt, war der Plan vernünftig. agentevals liefert `create_trajectory_llm_as_judge` mit einem Standard-Prompt für Trajektorien-Genauigkeit; die meisten Eval-Frameworks haben ein Pendant. Die Regeln dafür sind dieselben wie für jeden Judge, nur strenger, weil Transkripte lang sind:

-   **Ein Rubrikpunkt pro Dimension,** jeweils mit konkreter Beschreibung von Bestehen und Scheitern.
-   **Gib dem Judge einen Ausweg.** Anthropic empfiehlt eine explizite Antwort "Unknown", wenn dem Transkript die Information fehlt, damit der Judge nicht rät.
-   **Teilpunkte bei mehrstufigen Tasks vergeben.** Ein Support-Agent, der das Problem erkannt und den Kunden verifiziert, aber die Erstattung verfehlt hat, ist besser als einer, der sofort scheitert, und deine Scores sollten das zeigen.
-   **Gegen Menschen kalibrieren,** an einer Stichprobe, bevor du dem Judge vertraust, und erneut prüfen, wenn du das Judge-Modell wechselst.

## Capability-Suites, Regression-Suites und woher Tasks kommen

Anthropic unterscheidet zwei Arten von Suites. **Capability-Evals** fragen, was der Agent kann, und sollten mit niedriger Bestehensquote starten, damit du etwas zu erklimmen hast. **Regression-Evals** fragen, ob er noch kann, was er konnte, und sollten nahe 100 % liegen. Werden Capability-Tasks zuverlässig, wandern sie in die Regression-Suite. Nähert sich eine Capability-Suite 100 %, sagt sie nichts mehr aus; ihr Beispiel ist SWE-bench Verified, wo die Scores bei etwa 30 % begannen und Frontier-Modelle inzwischen über 80 % liegen.

Woher Tasks kommen, zählt mehr als ihre Anzahl. Anthropic rät, früh mit 20 bis 50 einfachen Tasks aus echten Fehlern zu starten, weil frühe Änderungen große Effekte haben und kleine Stichproben sie erkennen. Meine Quellen, nach Wert sortiert: Produktions-Traces, bei denen etwas schiefging (aus deiner [Observability-Pipeline](https://balazscsorba.com/de/blog/agent-observability-opentelemetry)), die manuellen Prüfungen, die du vor einem Release ohnehin machst, und Support-Tickets. Synthetische Tasks füllen Lücken; sie sollten nicht die Basis sein.

**Lies die Transkripte**

Keine Metrik ersetzt das Lesen gescheiterter Trials. Anthropic nennt es eine entscheidende Fähigkeit: Ein gescheitertes Transkript zeigt dir, ob der Agent wirklich einen Fehler gemacht oder dein Grader eine gültige Lösung abgelehnt hat. Plane eine Stunde pro Woche dafür ein und repariere Grader so oft wie Prompts.

## Tooling: wo Traces und Grader leben

Du brauchst drei Dinge: eine Möglichkeit, vollständige Traces zu erfassen, einen Runner, der Tasks mehrfach gegen eine isolierte Umgebung ausführt, und einen Ort, an dem Bewertungen über die Zeit gespeichert werden. OpenAIs Plattform bietet Trace Grading, das Agenten-Traces im Dashboard bewertet und in Eval-Runs überführt. Open-Source-Frameworks (agentevals mit pytest- oder Vitest-Integration, DeepEval, Ragas, [Promptfoo](https://balazscsorba.com/de/tools/promptfoo)) laufen in der CI. Observability-Plattformen wie [Langfuse](https://balazscsorba.com/de/tools/langfuse) verbinden Produktions-Traces mit Datasets. Die Wahl zählt weniger als die Gewohnheit: Jede Agentenänderung durchläuft die Regression-Suite, bevor sie ausgeliefert wird, und die Budgets der [Agentenschleife](https://balazscsorba.com/de/blog/agent-loop-explained) gehören zu dem, was du prüfst.

## Checkliste

1.  Das Ergebnis gegen den Zustand der Umgebung bewerten, nicht gegen die finale Nachricht.
2.  Die wenigen zwingenden Regeln als Code-Invarianten über die Trajektorie ausdrücken.
3.  Referenz-Trajektorien mit dem lockersten Match-Modus nutzen, der den Fehler noch fängt (superset oder subset vor strict).
4.  Jeden Task drei- bis fünfmal ausführen; pass@1 und pass^k berichten.
5.  Jeden Trial in einer sauberen, befüllten Umgebung starten, die der Produktion entspricht.
6.  LLM-Judges mit einem Rubrikpunkt pro Dimension, einer Option Unknown und Teilpunkten nutzen, gegen Menschen kalibriert.
7.  Eine Capability-Suite und eine Regression-Suite pflegen; Tasks zwischen ihnen befördern.
8.  Tasks aus echten Fehlern gewinnen und gescheiterte Transkripte jede Woche lesen.

Für die Retrieval-Seite von Agenten, die Dokumente durchsuchen, beschreibt [RAG evaluieren](https://balazscsorba.com/de/blog/rag-evaluation-metrics) die Metriken. Wenn du Unterstützung beim Aufbau von Agenten-Evals für dein Team willst, siehe [AI Engineering](https://balazscsorba.com/de/expertise/ai-engineer).

## Quellen

1.  [Anthropic: Demystifying evals for AI agents (Jan 2026)](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents)
2.  [Yao et al.: τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains (2024)](https://arxiv.org/abs/2406.12045)
3.  [Barres et al.: τ²-Bench: Evaluating Conversational Agents in a Dual-Control Environment (2025)](https://arxiv.org/abs/2506.07982)
4.  [LangChain: agentevals (GitHub)](https://github.com/langchain-ai/agentevals)
5.  [DeepEval docs: Tool Correctness](https://deepeval.com/docs/metrics-tool-correctness)
6.  [Ragas docs: Agentic or tool use metrics](https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/agents/)
7.  [OpenAI API docs: Trace grading](https://platform.openai.com/docs/guides/trace-grading)

## Häufige Fragen

Was ist Trajektorien-Evaluierung bei KI-Agenten?

Trajektorien-Evaluierung bewertet die Schritte, die ein Agent gegangen ist: welche Tools er aufgerufen hat, in welcher Reihenfolge und mit welchen Argumenten. Sie ergänzt die Ergebnisbewertung, die den Endzustand der Umgebung prüft, etwa ob ein Erstattungsdatensatz existiert. Trajektorien eignen sich vor allem für Regeln, die auf jedem Pfad gelten müssen.

Was ist der Unterschied zwischen pass@k und pass^k?

pass@k ist die Wahrscheinlichkeit, dass mindestens einer von k Versuchen gelingt; sie steigt mit k. pass^k ist die Wahrscheinlichkeit, dass alle k Versuche gelingen; sie sinkt. Coding-Agenten können pass@k nutzen, weil ein funktionierender Patch reicht; kundennahe Agenten sollten an pass^k gemessen werden, weil jeder Kunde genau einen Versuch bekommt.

Sollte ein Agenten-Eval eine exakte Folge von Tool-Aufrufen verlangen?

Nur dort, wo die Reihenfolge die Regel ist, etwa Kundenverifizierung vor einer Erstattung. Sonst lockerere Modi wie superset oder subset nutzen oder das Ergebnis bewerten. Anthropic berichtet von einem Fall, in dem ein Modell einen Eval wie geschrieben verfehlte, weil es eine Lücke in der Richtlinie fand, die dem Nutzer ein besseres Ergebnis brachte.

Wie viele Tasks brauche ich für den Start?

Anthropic nennt 20 bis 50 einfache Tasks aus echten Fehlern als guten Anfang, weil frühe Änderungen große Effekte haben, die kleine Stichproben erkennen. Führe jeden Task mehrfach aus und erweitere die Suite, wenn der Agent reifer wird.

Kann ich ein LLM als Judge für Agenten-Transkripte nutzen?

Ja, für Qualitäten, die Code nicht prüfen kann, etwa ob eine Rückfrage sinnvoll war. Nutze einen Rubrikpunkt pro Dimension, gib dem Judge eine Option Unknown, vergib Teilpunkte bei mehrstufigen Tasks und kalibriere ihn an einer Stichprobe gegen menschliche Bewertungen.

Geschrieben von Balázs Csorba

Senior Fullstack & AI Engineer in der Steiermark – über 10 Jahre Vue, Nuxt, Node.js und PHP, heute baue ich Werkzeuge für KI-Agenten.

[KI-Entwicklung & MCP-Server →](https://balazscsorba.com/de/expertise/ai-engineer)[Über mich →](https://balazscsorba.com/de/about)

## Weitere Artikel

-   [Structured Outputs mit JSON Schema: was die Garantie abdeckt und was nicht](https://balazscsorba.com/de/blog/structured-outputs-json-schema-llm)
-   [LLM-Modellmigration ohne Regressionen: Deprecations, Evals, Shadow-Traffic](https://balazscsorba.com/de/blog/llm-model-migration-regression-testing)
-   [Semantisches Caching für LLM-Apps: wann Antworten wiederverwenden sicher ist und wann nicht](https://balazscsorba.com/de/blog/semantic-caching-llm-responses)
-   [LLMs selbst hosten für die DSGVO: wann es nötig ist und was es kostet](https://balazscsorba.com/de/blog/self-hosted-llm-gdpr-cost)

## Klingt nach dem, was du suchst?

Erzähl mir von deinem Projekt oder deiner Stelle – ich freue mich, von dir zu hören.

[Kontakt aufnehmen](mailto:contact@balazscsorba.com) [Auf LinkedIn vernetzen](https://www.linkedin.com/in/balazs-csorba)